CONSTANTIN AVORNICULUI MIHAI AVORNICULUI

DIANA MOISUC

CAIET DE LUCRĂRI PRACTICE LA

MANAGEMENTUL ŞI PROIECTAREA
SISTEMELOR INFORMATICE DE
GESTIUNE

CLUJ-NAPOCA, 2011

1
2
Coordonator:
Prof. Univ. Dr. Constantin AVORNICULUI

Contribuţia autorilor:
Prof. Univ. Dr. Constantin AVORNICULUI (Capitolele: 1, 2, 3, 4)
Lect. Univ. Dr. Mihai AVORNICULUI (Capitolele: 3,4)
Asist. Univ. Drd. Diana MOISUC (Capitolul: 1, 2)

3
 INTRODUCERE

Scopul acestei discipline este de a familiariza studenţii cu aceste categorii de sisteme

informatice folosite în managementul firmelor moderne, cărora li se mai pot
alătura şi alte sisteme, cum ar fi sistemele informatice organizaţionale inteligente.
Realizarea unui sistem informatic cu baze de date constituie o activitate complexă,
care presupune îmbinarea strânsă a cunoştinţelor economice cu cele privind teoria
sistemelor, structurarea datelor, programarea şi utilizarea calculatoarelor.
Această carte se doreşte a se adresa studenţilor ce studiază disciplina de
Managementul şi proiectarea sistemelor informatice, se mai adresează şi altor categorii de
specialişti ce lucrează în domeniul proiectării sistemelor informatice şi nu numai acestora.
Dorim să credem că această carte aduce unele completări în privinţa problemelor teoretice
şi practice de elaborare a proiectelor informatice şi în alte privinţe privind sistemele
informatice.
Lucrarea are menirea să asigure însuşirea cunoştinţelor de specialitate în domeniul
analizei, conceperii, realizării, implementării şi utilizării sistemelor informatice cu baze de
date la un agent economic sau o firmă.
Am urmărit integrarea unor concepte, metode şi tehnici moderne de proiectare a
diverselor tipuri de baze de date, într-o metodologie unitară care să răspundă cerinţelor
actualilor şi viitorilor specialişti, considerăm că lucrarea răspunde stadiului actual de
dezvoltare ale economiei noastre naţionale.
Cartea este concepută să prezinte în mod logic principiile, metodele şi tehnicile
necesare unei proiectări cât mai logice a unei baze de date în domeniul economic şi în alte
domenii.
În acest scop au fost alese două moduri de proiectare a bazelor de date, unul pentru
cele clasice şi altul pentru noile tipuri de apărute, pe care le-am numit neoclasice.
Prezenta carte este structurată pe nouă capitole al cărui conţinut sintetic îl prezentăm
în continuare.
În capitolul 1 se arată cum se face analiza sistemului existent.
Capitolul 2 prezintă o temă de proiectare generală şi modul de execuţie al acesteia.
Capitolul 3 prezintă proiectarea de detaliu a unei aplicaţii cu DFD – uri şi cu UML.
Capitolul 4 prezintă conţinutul proiectului ce trebuie să-l elaboreze studenţii pentru
parte practică a examenului..
Lucrarea încearcă să prezinte metode şi tehnici de elaborare a modelului conceptual
al viitorului sistem informatic pe bază de criterii funcţionale, prin stabilirea conţinutului şi
structurii bazei informaţionale, cu tehnica de modelare entitate-atribut-corespondenţă şi
diagramele entitate-relaţie.
Transformarea modelului conceptual în model operaţional este asigurată de
proiectarea de detaliu sau tehnică. Acest obiectiv impune alegerea soluţiei optime de
gestiune a datelor şi a calculatorului, ce sunt prezentate pe parcursul acestei cărţi, în
capitolele aferente.
Caietul de lucrări studenţilor care fac această disciplină şi se vrea a fi un bun ghid
studenţilor ce elaborează lucrări de diplomă în domeniul proiectării de aplicaţii informatice
economice, precum şi specialiştilor ce doresc să elaboreze diverse sisteme informatice.
Autorii mulţumesc cu anticipaţie cititorilor ce vin cu sugestii de îmbunătăţire a
conţinutului şi formei de prezentare.

Autorii

4
PLANUL CALENDARISTIC DE SEMINAR PENTRU SEMESTRUL 2 la
Managementul şi proiectarea sistemelor informatice.
Anul 2 Contabilitate şi informatică de gestiune
Săptămâna 1. Organizatorică şi se prezintă ce se face la lucrări practice, materialele folosite
şi organizarea semigrupelor.
Săptămâna 2. Fluxuri informaţionale şi reprezentarea lor cu ASME şi BISAD.
Săptămâna 3. Continuare fluxuri şi prezentarea temei de proiectare ce se va rezolva la
seminar, cu încadrarea aplicaţiei în sistemul informatic al firmei.
Săptămâna 4. Macheta situaţiilor de ieşire, analiza datelor şi algoritmi.
Săptămâna 5. Macheta documentelor de intrare şi organigramele de sistem.
Săptămâna 6. Prezentarea Diagramelor Fluxurilor de Date, cu exemple.
Săptămâna 7. Prezentarea diagramelor UML, cu exemple.
Săptămânile 8 – 13. Timp pentru elaborarea proiectului individual şi participare la
consultaţiile stabilite în acest scop cu cel ce se fac lucrările.
Săptămâna 14. Predarea proiectului la ora aferentă grupei respective, nu la alte grupe.
Anul 3 Informatică economică
Săptămâna 1. Organizatorică şi se prezintă ce se face la lucrări practice, materialele folosite
şi organizarea semigrupelor.
Săptămâna 2. Fluxuri informaţionale şi reprezentarea lor cu ASME şi BISAD.
Săptămâna 3. Continuare fluxuri şi prezentarea temei de proiectare ce se va rezolva la
seminar, cu încadrarea aplicaţiei în sistemul informatic al firmei.
Săptămâna 4. Macheta situaţiilor de ieşire, analiza datelor şi algoritmi, macheta
documentelor de intrare şi organigramele de sistem.
Săptămâna 5. Prezentarea Diagramelor Fluxurilor de Date, cu exemple.
Săptămâna 6. Prezentarea diagramelor UML, cu exemple.
Săptămâna 7 - 11. Timp pentru elaborarea proiectului individual şi participare la
consultaţiile stabilite în acest scop cu cel ce se fac lucrările.
Săptămâna 12. Predarea proiectului la ora aferentă grupei respective, nu la alte grupe.
Modul de notare se va face astfel:
- 60% va reprezenta testul ce se dă din curs în sesiune şi care va conţine 20
întrebări grilă cu un singur răspuns din patru adevărat;
- 30% nota la proiectul ce se va elabora individual pe baza modelului făcut la
seminar şi care se va preda cel mai târziu în ultimul seminar, fără care nu se poate trece
examenul;
- 10% nota pentru activitatea de la seminarii şi prezenţă;
Dacă una din cele trei note este sub nota 5(cinci) atunci nu se face media şi se va
repeta testul de teorie obligatoriu dacă a fost dat, cei care nu au dat proiectul se pot
prezenta doar pentru a verifica ce au învăţat, sau la acceptul acestora cu o penalizare de
trei puncte cât valorează proiectul, deci nota nu poate depăşi nota 7 (şapte).

5
 CUPRINS

Capitolul 1. Analiza sistemului existent pag. 7

Capitolul 2. Proiectare generală şi modul de execuţie al acesteia pag. 19
Capitolul 3. Prezintă proiectarea de detaliu a unei aplicaţii cu DFD – uri şi cu UML pag. 31
Capitolul 4. Conţinutul proiectului ce trebuie elaborat şi temele de proiect propuse pag. 122

6
 Capitolul 1. ANALIZA SITEMELUI EXISTENT

Aici ne propunem să prezentăm simbolurile cu care se reprezintă fluxurile

informaţionale dintr-o firmă şi 3 (trei) exemple de reprezentare pe baza unui text de flux scoc
de la o firmă. Precizăm că acest nu este un flux cadru pentru toate firmele şi instituţiile din
România. Simbolurile ASME specifice unei analize de flux informaţional dintr-o firmă,
simbolurile BISAD sunt folosite în general al prezentarea fluxurilor informaţionale unor
nespecialişti în analiză de sistem. În continuare prezentăm aceste simboluri:

Simboluri ASME, pentru diagrame de flux

FLOW-CHART

- crearea unui document nou, concomitent cu efectuarea unei operaţii în el

- adăugarea de date pe un document

- operaţii asupra unui document, prin care nu se adaugă informaţii

- verificarea, compararea, corectarea, revizuirea unui document

- mişcarea sau transportul unui document de la un compartiment la altul

- staţionarea sau îndosarierea temporară a unui document

- arhivarea unui document

- distrugerea unui document

- verificarea unui document împreună cu o operaţie de îndosariere, capsare,

etc.

- verificarea unui document împreună cu operaţia de semnare sau modificare a

sa

2 - crearea unui document în trei exemplare

7
 Linii de influentă:

1
- documentul de la nivelul unu influenţează apariţia altui document la
nivelul doi

1 1
- documentul ce circulă la nivelul unu influenţează a
scrie pe documentul de la nivelul doi, apoi o capsare
sau
îndosariere a sa
2 2

1
- documentul ce circulă la nivelul unu influenţează o verificare
cu
semnare a documentului de la nivelul doi

1
2 - înregistrarea concomitentă trei exemplare
3

- linie neinfluentă în acea operaţie

1
2 - transportul celor trei exemplare
3

- Aici se scrie numele documentului care participă la flux

Principii de utilizare a simbolurilor în diagramele ASME:

1. Nu pot să apară mai multe documente la acelaşi nivel.
2. Un document de la apariţie până la dispariţie îşi păstrează nivelul.
3. Un document intră în circuit astfel:
 din afara compartimentului
 scos din dosar sau arhivă

8
  ca nou document într-un exemplar sau mai multe
4. Un document îşi termină circuitul astfel:
 când iese afară din unitate
 staţionează la acel compartiment
 arhivare la acel compartiment
 distrugerea sa
5. Un compartiment poate apare într-o diagramă de flux de câte ori este necesar
6. Nu se admit întoarceri ale documentului într-un flux, deoarece îşi schimbă nivelul de
circulaţie.

Simboluri BISAD

Ce ? C
â
n - prelucrare
d
Cine ? ?

- fişier de orice tip

- document într-un singur exemplar

1
2
3 - document în 3 exemplare

- direcţia de circulaţie a documentelor şi informaţilor

- contor de continuare flux pe altă pagină

- contor de circulaţie flux pe aceeaşi pagină

- simbol de document arhivat

9
 Principii de utilizare ale simbolurilor BISAD:
1. În flux nu pot să apară două simboluri de acelaşi fel consecutiv. Între ele trebuie să
apară o prelucrare sau între două prelucrări trebuie să apară un document sau fişier.
2. Circuitul trebuie să înceapă cu un document sau cu un fişier ce se prelucrează.
3. Orice document sau fişier ce intră într-o prelucrare, trebuie să iasă din acea prelucrare,
cu excepţia operaţiilor de consultare a fişierelor.

În continuare prezentăm cele trei teme scrise cu rezolvările aferente celor două tipuri
de simboluri prezentate anterior. Temele se referă la circulaţia materialelor într-o firmă,
pentru care se va face în capitolul următor şi Proiectarea generală.

Tema 1
Flux informaţional de intrare a materialelor la un agent economic
La magazia de materiale, comisia de recepţie întocmeşte Nota de intrare recepţie în 4
exemplare, pe baza celor constatate la recepţie şi pe baza datelor din Factura ce însoţeşte
marfa. După care se verifică şi semnează acest document de către comisia de recepţie şi se
distribuie astfel:
- exemplarele 1-2 se predau la contabilitatea materialelor
- exemplarul 3 se predă la aprovizionare
- exemplarul 4 se predă magazionerului
Pe baza exemplarului 4 magazionerul înregistrează cantitatea intrată în fişa de
magazie şi calculează stocul materialului respectiv. Reţine exemplarul 4 al notei ca şi act
justificativ de intrare a materialului.
Pe baza exemplarului 3 la aprovizionare se va consemna cantitatea realizată din
contract în Fişele de urmărire a realizării contractelor, apoi reţine acest document ca şi act
justificativ.
La contabilitatea materialelor pe cele 2 exemplare ale notei se va trece preţul
materialelor intrate, ce se ia din Catalogul de preţuri, după care se calculează valoarea
materialelor intrate şi se trece pe cele 2 exemplare ale notei. Exemplarul 1 al notei se va
trimite furnizorului ca şi act justificativ de intrare a mărfii şi achitate a contravalorii facturii.
Pe baza exemplarului 2 al notei la contabilitatea materialelor se va înregistra
cantitatea intrată în Fişele cantitativ-valorice, apoi se va calcula stocul şi soldul materialului
respectiv. Tot la acest compartiment, lunar se va întocmi pe baza exemplarului 2 al notei,
Centralizatorul materialelor intrate, ce se va trimite la contabilitatea generală. La
contabilitatea generală pe baza Centralizatorului lunar se întocmeşte Jurnalul (Nota
contabilă), după care Centralizatorul se arhivează ca act justificativ la acest compartiment.
Tot lunar la acest compartiment pe baza datelor din Jurnal se fac înregistrări în Cartea Mare,
jurnalul rămânând ca şi act justificativ la acest compartiment. Pe baza datelor din Cartea
Mare tot la acest compartiment, lunar se întocmeşte Balanţa de verificare. Tot la acest
compartiment trimestrial, semestrial sau anual pe baza datelor din Cartea Mare se întocmeşte
de către un economist Bilanţul în 4 exemplare. Apoi, Bilanţul se trimite conducerii pentru
avizare şi semnare. După care este trimis astfel:
- exemplarul 1 la Camera de comerţ;
- exemplarul 2 la Banca de care aparţine;
- exemplarul 3 la Administraţia financiară
- exemplarul 4 la unitate şi ca act justificativ.

10
11
12
 Tema 2
Flux informaţional de ieşire a materialelor spre consum la un agent economic
La compartimentul producţie se întocmeşte Bonul de consum în 3 exemplare pe baza
datelor din Planul de producţie şi pe baza Normelor de consum. După care se verifică şi
semnează de şeful compartimentului, apoi se predă secţiilor (atelierelor) de producţie, primele
două exemplare, pentru a-şi ridica materialele şi a le da în consum. Exemplarul 3 rămâne la
acest compartiment. Pe baza bonurilor, secţiile (atelierele) ridică materialele de la magazie, iar
magazionerul reţine exemplarele bonului. Pe baza lor se face înregistrarea cantităţii eliberate în
Fişa de magazie, apoi se calculează stocul materialului eliberat. Magazionerul pe baza bonului
întocmeşte Borderoul de predare al documentelor, apoi la sfârşitul zilei de lucru predă Bonurile
şi Borderoul de predare a documentelor la compartimentul contabilitatea materialelor. Aici se
va face verificarea documentelor după care se semnează de primire predare. Magazionerul
primeşte Bon de predare a documentelor ca şi act justificativ de predare a documentelor.
La compartimentul contabilitatea materialelor, pe cele 2 exemplare ale bonului se va
trece preţul, ce se ia din Catalogul de preţuri, după care se calculează valoarea şi se trece pe cele
2 exemplare ale bonului. După care exemplarul 2 al bonului se trimite compartimentului
Postcalcul. Pe baza exemplarului 1 al bonului la contabilitatea materialelor se face înregistrarea
materialelor în fişele cantitativ - valorice, apoi se calculează stocul şi soldul acelor materiale. Tot
la acest compartiment, lunar pe baza exemplarului 1 al bonului se întocmeşte Centralizatorul
materialelor ce se predă compartimentului contabilitate generală.
La compartimentul Postcalcul pe baza exemplarului 2 al bonului se întocmeşte lunar
Centralizatorul materialelor pe locuri de consum şi pe baza acestuia tot lunar se fac înregistrări
în Fişele de postcalcul, după care Centralizatorul materialelor pe locuri de consum se trimite
compartimentului contabilitate generală. La contabilitate generală pe baza celor două
centralizatoare, lunar se întocmeşte Jurnalul. Cele două centralizatoare rămân ca şi acte
justificative la acest compartiment. Tot la acest compartiment pe baza datelor din Jurnal (nota
contabilă) lunar se fac înregistrări în Cartea Mare. Pe baza datelor din Cartea Mare lunar la acest
compartiment se întocmeşte Balanţa de verificare. La acelaşi compartiment trimestrial,
semestrial sau anual pe baza datelor din Cartea Mare se întocmeşte de către un economist
Bilanţul în 4 exemplare. Bilanţul se trimite conducerii pentru avizare şi semnare. Apoi este
trimis astfel:
- exemplarul 1 la Camera de comerţ; - exemplarul 2 la Banca de care aparţine;
- exemplarul 3 la Administraţia financiară; - exemplarul 4 la unitate ca şi act justificativ.

13
14
15
 Tema 3
Fluxul informaţional al vânzărilor de materiale din stoc supranormativ al unui agent
economic
Se primeşte la Registratură (secretariat) o Comandă privind cumpărarea de materiale din
stoc supranormativ, ce se va înregistra în Registrul de intrări-ieşiri al agentului economic,
atribuindu-se un număr de intrare. După aceea se trimite compartimentului Aprovizionare. La
Aprovizionare pe baza Comenzii primite se întocmeşte Dispoziţia de livrare - Avizul de
expediţie în 4 exemplare. Acesta se verifică de către şeful compartimentului şi după aceea se
trimite conducerii spre avizare şi semnare. Conducerea avizează şi semnează documentul, după
care se predă următoarelor destinaţii: - exemplarul 1 la Beneficiar; - exemplarul 2 la Magazie;
- exemplarul 3 la Desfacere; - exemplarul 4 la aprovizionare ca act justificativ.
La magazie pe baza ex. 2 al dispoziţiei se înregistrează în fişa de magazie cantitatea
vândută şi apoi se calculează stocul acelui material. Apoi magazionerul pe baza exemplarului 2
al dispoziţiei se întocmeşte Borderoul de predare al documentelor şi la sfârşitul zilei de lucru
predă documentele la contabilitatea materialelor. Aici este verificată existenţa documentelor şi
se semnează de primire predare apoi se restituie magazionerului Borderoul de predare a
documentului ca şi act justificativ. Pe baza exemplarului 3 al dispoziţiei la Desfacere se
întocmeşte Factura în 4 ex., apoi se verifică de şeful compartimentului şi se semnează. Apoi ex.
1 şi 2 ale Facturii sunt trimise compartimentului financiar, exemplul 3 se trimite beneficiarului
pentru a se plăti materialele, iar ex. 4 rămâne ca act justificativ la acest compartiment.
La compartimentul financiar pe baza celor două exemplare ale Facturii se întocmeşte
Borderoul de predare al facturii de încasat, acesta se verifică şi semnează de şeful
compartimentului. Apoi ex. 1 Factura şi Borderoul de predare al facturii de încasat se trimit
conducerii spre semnare, urmărind ca apoi să se trimită băncii pentru încasare.
La compartimentul contabilitatea materialelor se confruntă ex. 2 al Facturii cu ex. 2 al
dispoziţiei, apoi pe baza ex. 2 al Facturii se înregistrează cantitatea de materiale vândută în fişele
cantitativ-valorice, calculându-se stocul şi soldul acestora. Aici, lunar pe baza ex. 2 al Facturii
se întocmeşte Centralizatorul materialelor vândute ce se va trimite la biroul contabilitate
generală. La biroul contabilitate generală pe baza Centralizatorului se întocmeşte Jurnalul (nota
contabilă), iar Centralizatorul rămâne ca şi act justificativ .La acelaşi birou lunar pe baza datelor
din Jurnal (nota contabilă) se fac înregistrări în Cartea Mare. Tot lunar la contabilitatea generală
pe baza datelor din Cartea Mare lunar se întocmeşte Balanţa de verificare.

16
17
18
 Capitolul 2. PROIECTAREA GENERALĂ A UNEI APLICAŢII
Prezentăm tema pe care dorim să o proiectăm, după care facem proiectarea generală a
acesteia.
Ne propunem să executăm o parte din Aplicaţia gestiunea materialelor la un agent
economic şi de aceea în continuare prezentăm doar următoarele situaţii de ieşire:
S1: Situaţia intrărilor şi ieşirilor de materiale la data de.........
S2: Situaţia stocurilor la data de.......
S3: Situaţia stocurilor supranormative la data de.......
S4: Situaţia stocurilor de siguranţă la data......
S5: Balanţa valorilor materiale.

Conţinutul acestor situaţii este următorul:

S1: - Cod material N(10)
- Denumire material C(22)
- Unitate de măsură C(3)
- Preţ unitar N(8.2)
- Cod gestiune N(2)
- Cod furnizor N(5)
- Cantitate intrată N(9.3)
- Valoare intrări N(11.2)
- Cod cont corespondent N(8)
- Cantitate ieşită N(9.3)
- Valoare ieşiri N(11.2)

S2.: - Cod material N(10)

- Cod gestiune N(2)
- Denumire material C(22)
- Unitate de măsură C(3)
- Preţ unitar N(8.2)
- Stocul zilei N(9.3)
- Soldul zilei N(11.2)

S3.: - Cod material N(10)

- Cod gestiune N(2)
- Denumire material C(22)
- Unitate de măsură C(3)
- Preţ unitar N(8.2)
- Stoc normat N(9.3)
- Stocul zilei N(9.3)
- Abatere faţă de stocul normat N(9.3)

S4.: - Cod material N(10)

- Cod gestiune N(2)
- Denumire material C(22)
- Unitate de măsură C(3)
- Preţ unitar N(8.2)
- Stoc siguranţă N(9.3)
- Stocul zilei N(9.3)
- Abatere faţă de stocul de siguranţă N(9.3)

19
S5.: - Cod material N(10)
- Cod gestiune N(2)
- Denumire material C(22)
- Unitate de măsură C(3)
- Preţ unitar N(8.2)
- Stoc iniţial N(9.3)
- Cantitate intrată N(9.3)
- Cantitate ieşită N(9.3)
- Stoc final N(9.3)
- Sold final N(11.2)

Se cere rezolvarea următoarelor probleme:

A. Să se facă încadrarea acestei Aplicaţii în cadrul Sistemului informatic.
B. Să se întocmească macheta de imprimare (afişare) pentru situaţiile date anterior.
C. Să se întocmească formularul de analiza datelor, după care să se stabilească
algoritmii de calcul, elementele schemei bazei informaţionale şi documentele de culegere a
datelor de intrare.
D. Să se întocmească organigramele de sistem ale unităţilor funcţionale necesare acestei
aplicaţii.
E. Să se facă proiectarea de detaliu a unităţilor de prelucrare ce compun această
aplicaţie.

Se va începe cu punctul A încadrarea aplicaţie în sistemul informaţional şi

informatic al firmei pentru care se va face proiectul, exemplu în continuare:

20
21
 B. Se va întocmi macheta de imprimare (afişare) pentru situaţiile date.

Exemplu: pentru Situaţia S2

SOCIETATEA COMERCIALĂ VIITORUL CLUJ

STRADA PROGRESULUI Nr. 117
Telefon 0264418564, Fax 024418659
CI RO12345678

SITUAŢIA STOCURILOR LA DATA: ZZ.LL.AA

TOTAL PE GESTIUNE N(11.2)

TOTAL PE FIRMĂ N(11.2)

Pentru a se întocmi o machetă lizibilă se are în vedere o imprimantă de tip economic de 132
caractere pe rând.
Se poziţionează antetul în stânga sus începând din Rândul 1 Coloana 1 apoi celelalte rânduri
ale antetului se poziţionează tot din Coloana 1 dar la câte un rând liber pentru a fi citibil.
Apoi se poziţionează antetul la mijlocul situaţiei, calculând câte caractere are titlul situaţiei
cu câte un caracter între cuvintele titlului. Exemplul nostru: titlul are 37 caractere se scade
din 132 şi obţinem 95 care se împarte la 2 obţinând 47 rest 1, deci nu este exact şi în acest caz
se ia un caracter în plus în faţă, deci titlul începe din Coloana 49 Rândul 9, apoi se lasă un
rând liber şi se calculează mărimea situaţie calculând suma mărimilor fiecărei coloane, apoi
se adaugă câte un caracter pentru coloanele despărţitoare şi câte două caractere în cadrul
fiecărei coloane pentru spaţiul lăsat liber la scrierea textului sau cifrelor, ca să nu se lipească
de coloana despărţitore pentru a fi lizibilă situaţia. Exemplu: 71 + 8 + 14 = 93, deci 132 – 93
= 39, deci nu e par şi se va lua o coloană în plus la început de tabel, prin urmare situaţia
începe din coloana 20 rândul 9 şi se termină în coloana 110. Apoi se aranjează situaţia ca să
fie cât mai estetică şi lizibilă (citibilă de utilizator). Dacă este necesar se dau şi totalurile
aferente situaţiei, ca în exemplul de mai sus, deci numai dacă acestea adună coloane
calculabile şi care au semnificaţie.

22
C. Se întocmeşte formularul de analiza datelor, după care să se stabilească
algoritmii de calcul, elementele schemei bazei informaţionale şi documentele
de culegere a datelor de intrare.
ANALIZA DATELOR

Date de Bază Algo- Cod Denumirea datelor Situaţii de ieşire

intrare informaţională ritmi date de ieşire
E.P. E.S. E.V ieşi- S1 S2 S3 S4 S5
. re
I1 X X X - E1 Cod material X X X X X
I2 X - E2 Denumire material X X X X X
I3 X - E3 Unitate de mătură X X X X X
I3 X - E4 Preţ unitar X X X X X
I4 X - E5 Cod gestiune X X X X X
I5 X - E6 Cod furnizor X
I7 X - E7 Cantitate intrată X X
- A1 E8 Valoarea intrată X
I8 X - E9 Cont corespondent X
I9 X - E10 Cantitate ieşită X X
- A2 E11 Valoare ieşită X
- A3 E12 Stocul zilei X X X
- A4 E13 Soldul zilei X
I10 X - E14 Stoc normat X
- A5 E15 Abatere faţă de X
stocul normat
I11 X - E16 Stoc de siguranţă X
- A6 E17 Abatere faţă de X
stocul de siguranţă
I12 X - E18 Stocul iniţial X
- A7 E19 Socul final X
- A8 E20 Soldul final X

Explicaţii:
E.P. Entitate Permanentă şi va conţine datele de intrare care rămân neschimbate pe parcursul
unei perioade de gestiune (la noi o lună, referitor la tema aplicaţiei). La noi: Cod material,
Denumire material, Unitate de măsură, preţ unitar.

E.S. Entitate de Stare şi va conţine datele care reflectă starea la un moment dat (adică
stocurile), la noi: Stoc normat, Stoc de siguranţă ş Stoc iniţial care este stocul final al lunii
precedente.

E.V. Entitatea Variabilă şi va conţine datele care sunt diferite de la o mişcare la lata de
materiale, la noi: Codul de gestiune, Codul furnizor, Cantitate intrată, Cont corespondent şi
Cantitate ieşită.

23
Codul material apare la celelalte entităţi pentru a face legătura datelor referitoare la
material.

ALGORITMI:
A1: VALI = CANTI * PREŢU

A2: VALE = CANTE * PREŢU

A3: STOCZ = STOCI + CANTI – CANTE Se calculează la acel material în momentul

editării şi nu se memorează.

A4: SOLDZ = STOCZ * PREŢU

A5: ABASN = STOCN – STOCZ şi se vor lista doar acele materiale care dau valoare
negativă.

A6 : ABASS = STOCS – STOCZ şi se vor lista doar acele materiale care dau valoare
pozitivă.

A7: STOCF = STOCI + TCANTI – TCANTE se calculează la sfârşit de lună şi este stoc
iniţial al lunii următoare.

A8: SOLDF = STOCF * PREŢU

24
 DOCUMENTE DE INTRARE

Se face pe baza ANALIZEI DATELOR, care ne arată conţinutul fiecărei entităţi, iar
mărimea datelor este dată de tema de proiectare. Avem următoarele documente de intrare:

DOCUMENT DE CULGERE DATE PERMANENTE

Cod Denumire Unitate de Preţ

Material Material măsură unitar

N(10) C(22) C(3) N(8.2)

DOCUMENT CULEGERE DATE DE STARE

Cod Stoc Stoc Stoc

Material Normat Siguranţă Iniţial

N(10) N(9.3) N(9.3) N(9.3)

DOCUMENT CULEGERE DATE VARIABILE

Cod Cod Cod Cantitate Cont Cantitate

Material Gestiune Furnizor Intrată Corespondent Ieşită

N(10) N(2) N(5) N(9.3) N(8) N(9.3)

25
 D. Se întocmesc organigramele de sistem ale unităţilor funcţionale necesare
acestei aplicaţii.
UF. 1. Crearea şi actualizarea Entităţii permanente

Document de culegere
Confruntare Document de actualizare
date permanente
a Entităţii Permanente

UP. 14 Actualizare
UP. 11 Creare structură, Entitate Permanentă
încărcare date şi validare
formală Entităţii
Permanente Mesaj eroare
Entitate
Permanentă
Mesaje de eroare corectă

Entitate
Permanentă
validă formal

K = CODM Se va proiecta Documentul de

actualizare a Entităţii Permanente, care
are o ultimă coloană ce va conţine Codul
Entitate P sortată
de actualizare, astfel: A – pentru
adăugare, M – pentru modificare şi S -
pentru ştergere.
UP. 12 Validarea în
conţinut a Entităţii
Permanente

Mesaj de eroare
Entitatea
Permanentă
corectă

UP.13 Listare Entitate

Permanentă

Listare conţinut
Entitate Permanentă

26
 UF. 2 Crearea şi actualizarea Entităţii de Stare

Document de culegere
date de Stare Confruntare Document de actualizare
a Entităţii de Stare

UP. 24 Actualizare
UP. 21 Creare structură, Entitate de Stare
încărcare date şi validare
formală Entităţii de
Stare Mesaj eroare
Entitate de
Stare
Mesaje de eroare corectă
Entitate de
Stare
validă
formal

K = CODM,
Entitate de Stare sortată
UP. 22 Validarea în
conţinut a Entităţii de
Stare
Se va proiecta
Documentul de actualizare a Entităţii de
Stare, care are o ultimă coloană ce va
conţine Codul de actualizare, astfel: A –
pentru adăugare, M – pentru modificare
şi S - pentru ştergere.

Mesaj de eroare
Entitatea
de Stare
corectă

UP.23 Listare Entitate

de Stare

Listare conţinut
Entitate Permanentă

27
 Proiectarea documentelor de actualizare a entităţilor Permanente şi de
Stare.
DOCUMENT DE ACTUALIZARE ENITATE PERMANENTĂ

Cod Denumire Unitate de Preţ Cod

Material Material măsură unitar actualizare

N(10) C(22) C(3) N(8.2) C(1)

Cod actualizare, ia valorile: A pentru adăugare, M pentru modificare şi S pentru

şterge.

DOCUMENT DE ACTUALIZARE ENTITATE DE STERE

Cod Stoc Stoc Stoc Cod

Material Normat Siguranţă Iniţial Actualizare

N(10) N(9.3) N(9.3) N(9.3) C(1)

Cod actualizare, ia valorile: A pentru adăugare, M pentru modificare şi S pentru şterge.

28
UF. 3. Crearea Entităţii Variabile

Document de culegere
date Variabile

UP. 31 Creare structură,

încărcare date şi validare
formală Entitate
Variabilă

Mesaje de eroare
Entitate
Variabilă
validă
formal

S K1 = CODM
K2 = CODGEST

Entitate Varibilă sortată

UP. 32 Validarea în
conţinut a Entităţii
Variabile

Mesaj de eroare
Entitatea
Variabilă
corectă

29
UF. 4. Listarea Situaţiilor Finale ale aplicaţiei

Entitate Entitate de Entitatea

Permanentă Stare Variabilă
corectă corectă corectă

UP. 41 Crearea Fişierului

Temporal de Listare a
Situaţiilor Finale

Fişier
Temporal
de Listare

UP.41 UP. 43 UP. 44 UP. 45 UP.46

Listare S1 Lisare S2 Listare S3 Listare S4 Listare S5

Situaţia S1 Situaţia S2 Situaţia S3 Situaţia S4 Situaţia S5

30
 Capitolul 3. Proiectarea de detaliu a aplicaţie

E. Se face proiectarea de detaliu a unităţilor de prelucrare ce compun

această aplicaţie.

A. Proiectarea de detaliu în cazul aplicaţiilor clasice.

Modelarea proceselor (modelarea prelucrărilor)
Aici trebuie avute în vedere probleme ca:
 fiecărei metodologii de analiză a cerinţelor îi corespunde o notaţie proprie de
modelare;
 în analiză modelele se numesc esenţiale, deoarece ele pun accentul pe
comportamentul sistemului;
 instrumentul specific de modelare a proceselor în metodele de analiză structurată
este diagrama de flux de date.

1. Diagrama de flux de date(DFD)

Diagrama de flux de date, (data flow diagram DFD), are în vedere:
• reprezentare schematică a proceselor complexe într-o formă cât mai abstractă;
• instrument de modelare a proceselor care ilustrează fluxul de date în sistem şi prelucrările
efectuate de acesta.

DFD este abstractă şi nu ia în considerare aspectele de implementare, anume:

• suportul pe care sunt memorate datele
• mijloacele şi mediile de comunicaţie
• calculatoarele pe care se fac prelucrările
Ea este introdusă de metodele analiză şi proiectare structurată şi utilizează metodele:
 De Marco, Yourdon, Constantine
 Gane, Sarson

a. Notaţii

(1) Procesul

(2) Fluxul de date

(3) Entitatea externă

(4) Depozitul de date

31
 Exemplu pentru o bibliotecă, cu aceste notaţii, care sunt cele mai folosite:

CITITOR CITITOR

Carte
Cerere împrumutată
înscriere Permis Carte
restituită

PE 2 PE 3
EVIDENTÃ EVIDENTÃ
CITITORI ÎMPRUMUTURI

D
Modelul de date al aplicaţiei

b. Fluxul de date
El desemnează elementele:
o datele ce intră într-un proces (intrările);
o datele care sunt produse de un proces (ieşirile);
o actualizările într-un depozit de date.
El se reprezintă printr-o linie continuă ce leagă un proces cu un alt simbol din DFD,
astfel:
o linia este etichetată şi are o direcţie (săgeată);
o eticheta indică ce informaţie se transportă (ce reprezintă fluxul de date);
o săgeata indică sensul propagării informaţiei.

c. Fluxul de control
El desemnează,evenimentele produse de procese sau entităţi care influenţează
comportamentul altor procese sau entităţi şi se reprezintă printr-o linie întreruptă ce leagă un
proces cu un alt simbol din DFD, având are aceleaşi caracteristici ca şi fluxul de date
(etichetă, orientare).

d. Entitate externă
Ea defineşte frontiera sistemului supus modelării, având elementele:
o produce date de intrare în sistem;
o foloseşte date produse de sistem.
Are ca sinonime:
– agent;
– sursă, destinaţie.
Ea se reprezintă sub formă de dreptunghiuri (pătrate), cu elementele:
o numele entităţii (substantiv la singular);
o fiecare flux de date se ilustrează separat;

32
 o dacă aceeaşi entitate apare de mai multe ori în diagramă, se marchează colţul
din dreapta jos (paralelă la diagonala secundară);
o numerotare Xm, m indice (deasupra numelui).

e. Depozit de date
El descrie entităţile despre care sistemul trebuie să înmagazineze date şi conţine toate
realizările (instanţele) unei entităţi.
Exemple de categorii de depozite de date:
– roluri: clienţi, furnizori, angajaţi, studenţi, profesori;
– obiecte: produse, subansamble, cărţi;
– locaţii: magazii, clădiri, depozite;
– evenimente: comenzi, note, cursuri.
El se reprezintă prin:
 dreptunghi deschis la ambele capete (notaţia Yourdon/De Marco);
 dreptunghi închis la un capăt (notaţia Gane/Sarson, uneori şi Yourdon/De Marco);
 nume;
 etichetă (notaţia Gane/Sarson);
 dacă acelaşi depozit de date apare de mai multe ori în diagramă, capătul închis
este cu line dublă o paralelă la acesta.

2. Deosebirea dintre DFD şi schemele logice

Care este paralelismul:

– scheme logice: prelucrări secvenţiale;
– DFD: procesele se pot executa în paralel.
Ce exprimă fiecare din ele:
– schema logică: numai prelucrări (structuri secvenţiale, alternative, repetitive);
– DFD: modul de propagare a datelor din sistem + prelucrarea acestora.
Frecvenţa prelucrărilor din ele:
– schema logică: exprimă un proces de calcul;
– DFD: fiecare proces are frecvenţa proprie de prelucrare (zilnic, săptămânal,
decadal, lunar, trimestrial, semestrial, anual).

3. Reguli privind trasarea DFD

Fiecare proces trebuie să aibă cel puţin o intrare şi cel puţin o ieşire, iar dacă procesul
are numai o intrare şi numai o ieşire, s-ar putea ca el să fie critic (şi se pune întrebarea: nu s-
ar putea combina cu alt proces?).
Cel puţin un capăt al fiecărui flux de date trebuie conectat la un proces, iar celălalt
capăt poate fi conectat la:
• un proces
• un depozit de date
• o entitate externă
Fiecare depozit de date trebuie să aibă cel puţin un flux de date de intrare şi unul de
ieşire, iar dacă depozitul are numai o intrare şi numai o ieşire, trebuie analizat cu atenţie,
pentru a vedea dacă depozitul de date este o cerinţă funcţională sau numai un depozit
temporar care nu este necesar conceptual.

33
 4. Procese
Procese esenţiale, acele procese care reprezintă acţiuni care trebuie efectuate
indiferent de modul în care se implementează sistemul şi sunt efectuate:
• manual (de oameni);
• mecanizat (de diverse maşini, dispozitive, roboţi);
• automat (de calculator).
Ele clasifică după scop (ce fac):
• efectuarea de calcule (calculul salarului, calculul mediei de absolvire, etc.);
• luarea de decizii (stabilirea bursei unui student pe baza mediei şi a situaţiei
materiale, stabilirea statutului de promovare a unui concurs, stabilirea drepturilor de
bursă);
• descompunerea fluxurilor de date complexe în fluxuri mai simple (separarea
corespondenţei primite de universitate pe facultăţi, dispecerarea apelurilor la o staţie
de salvare, etc.);
• combinarea fluxuri de date mai simple într-un singur flux mai complex (combinarea
fluxurilor de date despre discipline, profesori, grupe de studenţi şi săli pentru a
construi orarul);
• filtrarea sau efectuarea de calcule statistice asupra fluxurilor de date pentru a obţine
alte fluxuri de date (selectarea studenţilor care au ales un anumit curs opţional în
vederea stabilirii grupelor; numărarea opţiunilor studenţilor pentru a vedea care
cursuri sunt cele mai puţin solicitate).

Numerotarea proceselor şi scheme de numerotare, avem următoarele probleme:

– trebuie să se aibă în vedere:
• respectarea ordinei logice în care se desfăşoară;
• să ilustreze descompunerea proceselor în subprocese.
– schema de numerotare poate fi:
• procesul rădăcină (procesul sistem) se numerotează cu 0;
• descompunerea procesului sistem: subsistemele (funcţiile majore) 1, 2, …, n;
• descompunerea unui subsistem i netrivial în funcţiile i.1, i.2, ..., i.m;
• descompunerea unei funcţii i, j netriviale în procesele i.j.1, i.j.2, ..., i, j, q;
• procesele primitive (care nu se mai descompun) au sufixul ‘p’.

4. Clasificarea DFD - urilor

Clasificarea DFD după nivelul de detaliere a proceselor:
 DFD de nivel înalt (nivelele 0 şi 1);
 DFD de nivel mediu (nivelul 2 şi următoarele);
 DFD de nivel jos (conţin numai procese primitive).

5. Analizarea proceselor după trasarea DFD

Se pot descoperi erori în identificarea proceselor, astfel:
– procese care au numai fluxuri de date de intrare;
– procese care au numai fluxuri de date de ieşire ;
– procese care au prea puţine fluxuri de intrare pentru a produce ieşirea specificată.
În aceste situaţii impun reanalizarea proceselor în cauză din DFD.

34
 6. Analiza fluxuri de date
Acestea trebuie să ilustreze minimul de date esenţiale de care are nevoie un proces sau
pe care acesta le produce, cum ar fi:cerinţa de minimalitate are ca scop reducerea cuplării
între procese, adică reducerea efortului de întreţinere.
Numele fluxului de date trebuie să:
– conţină substantive descriptive;
– trebuie să fie unic într-o DFD (cu excepţia fluxurilor spre sau dinspre depozitele de
date);
– se pot folosi adjective sau adverbe pentru a califica mai exact substantivele
respective.
Avem următoarele categorii de fluxuri de date după nivelul de detaliere al DFD:
– fluxuri de date compuse, cu elemente ca :
• sunt proprii DFD de nivel înalt;
• sunt formate din mai multe fluxuri de date primitive.
– fluxuri de date primitive, cu elemente ca:
• apar în DFD de nivel mediu;
• sunt formate din atribute de date bine precizate, care se transportă (propagă)
împreună, într-un singur pachet;
• corespund de regulă unui document bine precizat (de intrare sau de ieşire).

7. Analiza entităţi externe

Avem de văzut următoarele:
• ele stabilesc frontiera, marginile sistemului studiat;
• adjectivul extern se referă la sistemul studiat, nu la organizaţia ţintă (mediul) în
care acesta funcţionează.

8. Analiză depozite de date

Avem de văzut următoarele:
• ele conţin date esenţiale, reutilizabile, persistente care sunt colectate, memorate,
regăsite şi actualizate de sistemul ţintă;
• sunt variante de abordare a modelării în analiza cerinţelor;
• identificarea depozitelor de date este simplă: fiecărui tip de entitate din diagrama E-
R îi va corespunde un depozit de date;
• într-o DFD, numai procesele se pot conecta cu depozitele de date;
• datele din depozitele de date D nu se folosesc şi nu se actualizează decât prin
intermediul proceselor P.

9. Modelarea prelucrărilor în ciclul de dezvoltare a unei aplicaţii

Instrumente folosite în abordările:
– structurate: DFD, diagrama ierarhică;
– obiectuale: diagrame de tranziţie de stare.
Unde se face modelarea proceselor , în analiza de sistem, anume:
• modelul de context al organizaţiei - diagramă de context, deci:
– DFD cu un proces, entităţi externe, fluxuri de date compuse;
• modelul de procese al organizaţiei: diagramă ierarhică, deci:
– descompune activitatea organizaţiei în subsisteme şi funcţii majore;
• modelul de procese al ariei de activitate, deci:
– DFD mai detaliată: entităţi externe, procese, depozite de date, fluxuri de date

35
 Analiza cerinţelor de modelare:
• modelul contextului aplicaţiei - diagramă de context, deci:
– DFD cu un proces, entităţi externe, fluxuri de date compuse, modelul de date;
• diagrama de descompunere a proceselor, deci:
– primul nivel de descompunere a sistemului studiat în subsisteme şi funcţii;
• modelul esenţial al prelucrărilor, deci:
– ierarhie de DFD rezultate din modelul contextual urmând descompunerea.

Exemplu, modelul de context al unei biblioteci, în cele de mai jos.

PROFESOR
CITITOR
UNIVERSITAR

Cerere Permis Cerere

înscriere achizitie
carte

Carte Aplicaţie

CITITOR restituită Carte

BIBLIOTECA împrumutată CITITOR

Factură Carte
achizitionată
Comandă Prospect
carte cãrti noi

EDITURĂ EDITURĂ

Modelul de procese al bibliotecii, în desenul următor:

Aplicaţie

BIBLIOTECA

UF 1 UF 2 UF3
EVIDENTÃ
EVIDENTĂ EVIDENTÃ
CĂRTI CITITORI ÎMPRUMUTURI

36
 10. Exemple de diagrame de flux de date
Enunţul problemei:

Firma DANTE S.R.L are ca domeniu de activitate comerţul en-gros cu produse. Se

cere realizarea unui sistem de gestiune a comenzilor de la clienţi, expediţie şi facturare.

Descrierea sistemului

Aplicaţia de gestiune a comenzilor, expediţie şi facturare (numită pe scurt aplicaţia

COMENZI) trebuie să gestioneze comenzile de produse emise de clienţi. Fiecare comandă
conţine produsele cerute de client şi cantitatea care trebuie livrată din fiecare produs. Preţul
produsului se stabileşte la prelucrarea comenzii, prin consultarea nomenclatorului de produse,
iar disponibilitatea produsului în magazie prin consultarea fişierului de stocuri. Dacă
produsul este disponibil, se rezervă cantitatea cerută în comandă şi comanda se păstrează
pentru prelucrările ulterioare (expediere şi facturare) într-un fişier de comenzi ordinare. Dacă
produsul nu este disponibil, se creează o comandă în aşteptare. Comenzile în aşteptare sunt
consultate periodic, iar când produsele conţinute in ele există în magazie ele sunt
transformate înapoi în comenzi ordinare. Din fişierul de comenzi ordinare se preiau loturi de
comenzi şi acestea se planifică pentru expediţie, folosindu-se informaţiile despre maşinile
disponibile şi rutele geografice spre clienţi oferite de departamentul Transporturi. Pentru
fiecare lot de comenzi se pregătesc liste de magazie, care permit muncitorilor ca dintr-o
singură parcurgere a magaziei să ia toate produsele de un anumit tip care se încarcă într-un
camion. Livrările efectuate, ca şi produsele negăsite se notează pe listele de magazie, care se
folosesc pe urmă la actualizarea stocului de produse din magazie. După ce s-au luat din
magazie toate produsele pentru o rută şi s-au încărcat în camionul aferent, se completează
avizele de expediţie (care cuprinde produsele care se livrează la fiecare client). Ajunse la
client, acesta face recepţia produselor livrate şi notează toate neconcordanţele pe avizul de
expediţie, care este folosit ulterior pentru elaborarea facturii pentru produsele recepţionate de
către client şi pentru actualizarea conturilor de încasări.

37
 Exemplu de DFD Gane Sarson:
Client
2 Infor. C-dă
Comandă Prelucrează
client
D3 Fişier Comenzi
comanda
Stare c-dă
vânzare

Comandă Client nou

validă
Infor.
3 client nou
Creează
client
nou

Stare
cont nou
Comandă 1
respinsă Verifică
Interogare
credit
credit
client

Stare D2 Fişier Clienţi

Comandă credit
aprobată

4
Verifică Interog. Prod
Disponibil - listare D1 Fişier Produse
produs Stare Prod

Infor.
Produs 6 C-dă
disponibil Produs Creează în aştept.
epuizat comandă
în aşteptare
5
Factură Creează Stare
factură c-dă
în aştept

Notificare C-dă în aşteptare D4 Fişier C-zi Aşt.

11. Abordarea pas cu pas a modelării prelucrărilor

Paşi de parcurs:
• 1. Trasarea unei diagrame de context
• 2. Trasarea unei diagrame de descompunere pentru procese

38
 • 3. Identificarea depozitelor de date
• 4. Trasarea unei diagrame de flux de date generale (legătură aplicaţii)
• 5. Trasarea diagramelor de flux de date de nivel mediu (intermediare, legătură
UF)
• 6. Trasarea diagramelor de flux de date de nivel jos (primitive, legătură UP)
Pasul 1. Trasarea unei diagrame de context pentru sistemul studiat

Diagrama de context a unui sistem, are ca sinonime:

• diagramă de flux de date de context;
• model de context al sistemului;
• model de mediu.
Ea defineşte domeniul şi frontiera sistemului sau proiectului, deci, domeniul unui sistem
este supus în permanenţă schimbării, prin urmare şi diagrama de context se modifică după
necesităţi

Caracteristici acestei diagrame:

o conţine un singur proces, sistemul studiat, considerat cutie neagră, care ocupă
locul central;
o entităţile externe sunt dispuse de jur împrejurul procesului;
o nu există depozite interne de date, singurele depozite de date permise fiind cele
externe;
o fluxurile de date definesc interacţiunile dintre sistem şi entităţile externe, respectiv
depozitele de date externe.

Cerinţe ale acestei diagrame:

o să conţină numai fluxurile de date esenţiale (care reprezintă intrările şi ieşirile
tipice) ale acestuia, deci, fluxurile de date mai puţin importante (care reprezintă
intrări/ieşiri ocazionale) se vor trasa pe DFD de detaliu;
o să folosească fluxuri de date compuse pentru rapoarte, interogări sau alte
tranzacţii complexe.

Strategie pentru trasarea diagramei de context:

• Gândeşte sistemul ca un container pentru a distinge interiorul de exteriorul său.
• Ignoră ceea ce se întâmplă înăuntrul sistemului (sistemul este considerat ca o cutie
neagră, black box).
• Întreabă utilizatorii la ce evenimente sau tranzacţii trebuie să răspundă sistemul.
Există evenimente care introduc date noi în sistem (ca de exemplu o comandă).
Sistemul trebuie să răspundă (să le prelucreze, să le memoreze şi eventual să
genereze răspunsuri).
• Pentru fiecare eveniment, întreabă utilizatorii ce răspunsuri trebuie să producă
sistemul. Spre exemplu, pentru o comandă sistemul poate produce ca răspunsuri o
comandă amânată, o factură, o expediere de articol(e). Alt gen de răspunsuri sunt
situaţiile (listele, rapoartele, statisticile) produse de sistem.
• Întreabă utilizatorii ce fel de rapoarte de format predefinit trebuie produse de
sistem (nu se includ aici rapoartele ad-hoc şi interogările, ci rapoarte precum lista
membrilor inactivi, situaţia la zi a contului unui membru, etc.).
• Identifică sursele de date pentru fiecare eveniment. Aceste surse pot fi agenţi
externi sau interni în diagramele trasate.

39
 • Identifică receptorii răspunsurilor pentru fiecare răspuns (ieşire) a sistemului.
Aceştia pot fi agenţi externi sau interni (entităţi externe) în diagramele trasate.
• Identifică toate depozitele de date externe sistemului. Multe sisteme necesită
accesul la surse externe de date (fişiere sau BD) care aparţin altor (sub)sisteme. De
cele mai multe ori sistemul studiat va folosi aceste surse (depozite) externe de date
numai pentru consultare, însă pot fi şi situaţii în care el face actualizări. Ca regulă
generală, proiectarea sistemului curent nu are voie să modifice structura fişierelor
(schema BD) sau depozitelor de date externe.

Vom exemplifica o astfel de detaliere în cele ce urmează:

Diagramă de context pentru Activitatea serviciu clienţi

D8 CONTURI ÎNCASĂRI

Comandă
răspuns de Plafon şi
ENTITATE 7 la membru bonitate
credit
CLUB
CLIENT
Reducere sau
comandă
specială

Material ENTITATE 5
promoţional Comandă de
Activitatea
prelucrat MAGAZIE

ENTITATE 4 Cerere SERVICIULUI

(comandă) CLIENŢI Acţiune promo lunară
CLIENT
POTENŢIAL de înscriere
Plan de noi
Cerere membri
(comandă)
reînscriere Statistici analiză
vânzări şi ENTITATE 3
Ofertă de acţiuni promo
ENTITATE 6 reînscriere SERVICIUL
FOST MARKETING
CLIENT Statistici analiză
membri
ENTITATE 2
SERVICIUL
CLIENŢI

40
Pasul 2. Trasarea unei diagrame de descompunere pentru Aplicaţiile activităţii şi restul
Aici diagrama de descompunere a proceselor, are în vedere:
– rădăcina - procesul din diagrama de context;
– schema de descompunere;
– schemă de numerotare.

Diagramă de descompunere

41
 În continuare dăm o explicarea descompunerii:
 nivelul 1: activitatea Servicii clienţi se descompune în trei subsisteme majore:
 subsistemul Evidenţă clienţi;
 subsistemul Prelucrare comenzi;
 subsistemul Acţiuni promoţionale.
 nivelul 2: fiecare dintre aplicaţiile de pe nivelul 1 se descompune în procese şi/sau funcţii:
 aplicaţia Evidenţă clienţi se descompune în funcţiile:
 Prelucrare tranzacţii clienţi;
 Generare rapoarte clienţi;
 Întreţinere date clienţi.
 aplicaţia Prelucrare comenzi se descompune în procesele şi funcţiile:
 Prelucrare tranzacţii comenzi – funcţie;
 Întreţinere date comenzi – proces;
 Întreţinere date comenzi amânate – proces;
 Întreţinere date produse - proces
 Aplicaţi Acţiuni promoţionale se descompune în procesele:
 Înregistrare promoţie lunară (înregistrarea datelor privind activitatea promoţională
prevăzută pentru luna curentă);
 Generare promoţie lunară;
 Generare raport sintetic promoţie;
 Întreţinere date promoţie.
 nivelul 3: funcţiile de pe nivelul 2 al descompunerii se descompun la rândul lor în:
 Unitatea funcţională Prelucrare tranzacţii clienţi se descompune în Unităţile de
prelucrare:
 Prelucrare cereri reînscriere (ale foştilor clienţi)-,
 Prelucrare cereri înscriere (ale clienţilor noi);
 Unitatea funcţională Generare rapoarte clienţilor se descompune Unităţile de
prelucrare:
 Generare raport obligaţii client - situaţia la zi a unui client în raport cu obligaţiile
acestuia asumate prin convenţia semnată;
 Generare raport reduceri membru - situaţia la zi a modului în care clientul a folosit
reducerile de preţuri oferite;
 Generare raport clienţii inactivi - date despre clienţii care nu au cumpărat nimic în
ultimele l luni;
 Unitatea funcţională Întreţinere date clienţi se descompune în Unităţile de prelucrare:
 Întreţinere date clienţi;
 Întreţinere date grupuri de clienţi;
 Întreţinere date convenţii;
 Unitatea funcţională Prelucrare tranzacţii comenzi se descompune în Unităţile de
prelucrare:
 Prelucrare comenzi automate pentru comenzile generate automat care nu au
răspunsuri de la clienţi;
 Prelucrare răspuns clienţi pe baza răspunsurilor acestora (anularea comenzii pentru
selecţia lunii curente, schimbarea selecţiei);
 Prelucrare comenzi speciale pentru comenzile referitoare la articolele cu reducere.

Regulile generale de descompunere a proceselor

 funcţiile care reprezintă tranzacţii trebuiesc descompuse până când se ajunge
la un proces per eveniment (document, tranzacţie) de prelucrat;

42
  funcţiile care reprezintă generarea de rapoarte (situaţii) trebuiesc descompuse
până când se ajunge la un proces per raport în format fix (în afară de situaţia
când se produc simultan mai multe tipuri de rapoarte - de exemplu un raport
detaliat şi un raport sintetic cu acelaşi conţinut (coloane);
 funcţiile de întreţinere a datelor trebuiesc descompuse până când se ajunge la
un proces per depozit de date; prin întreţinerea datelor se înţelege adăugarea,
modificarea, ştergerea şi listarea înregistrărilor dintr-un depozit de date (fişier
sau tabelă a unei BD);
 procesele care sunt asociate tranzacţiilor, rapoartelor sau activităţilor de
întreţinere nu mai trebuiesc descompuse în această etapă a analizei; pentru
trasarea DFD procesul este ultimul nivel de descompunere, iar CE face
procesul se va specifica la proiectare, utilizând instrumente specifice.

Ca regulă generală:
– tranzacţiile (reprezentate în general prin documente sau prin acţiuni asupra unor
documente) şi activităţile de întreţinere a datelor introduc informaţii noi în sistem;
– generarea rapoartelor extrage informaţie din sistem.

Pasul 3: Identificarea depozitelor de date

Se foloseşte modelul conceptual de date, exemplu : descompunerea modelului de date

în depozite de date:

D MODELUL DE DATE SERVICII

MEMBRI
este format din

D1 CLIENŢI

D2 GRUPURI DE CLIENŢI

D3 CONVENŢII

D4
COMENZI

D5 COMENZI
AMÂNATE

D6 PRODUSE

D7 ACŢIUNI
PROMOŢIONALE

D8 CONT ÎNCASĂRI

43
 Pasul 4. Trasarea unei diagrame de flux de date generale (legătura aplicaţiilor)

În acest scop se folosesc:

• diagrama de descompunere a proceselor (DDP);
• diagrama de context (DC).
Aceasta se construieşte astfel:
– se păstrează din DC:
• fluxurile de date dintre entităţile/depozitele de date externe;
• entităţile şi depozitele de date externe;
– în locul procesului se pun procesele în care el se descompune (nivelul 1) din DDP;
– depozitele de date specifice se înlocuiesc cu modelul de date;
– apar fluxuri de date între subsisteme:
• directe;
• indirecte - prin modelul de date.

Exemplu de descompunere pentru Activitatea serviciului CLIENŢI

DFD generală legătura Aplicaţiilor din Activitate.

E6 E4 E2 E1
CLIENT SERVICIUL GRUP DE D8 CONTURI
FOST POTENŢIAL CLIENţI CLIENŢI ÎNCASĂRI
CLIENT Reducere sau Comandă
Cerere de Plafon şi
înscriere comandă răspuns de
bonitate
Cerere de specială la grup
credit
reînscriere
Statistici analiză
clienţi

APLICAŢIA 1 APLICAŢIA 2
Cerere Comandă de E5
aprobată prelucrat
EVIDENŢĂ PRELUCRARE
CLIENŢI Actualizări COMENZI
Statistici Statistici MAGAZIE
membri, analiză
Actualizare
Informaţii grup
Informaţii vânzări
comenzi comenzi
grup de
existente
clienţi E3
D MODELUL DE DATE SERVICIUL
SERVICII CLIENŢI
MARKETING
Plan de Actualizare Informaţii acţiuni
promo promo existente
noi
clienţi E1
APLICAŢIA 3 Material
MEMBRU
promoţional
ACŢIUNI
GRUP
Acţiune promo
lunară PROMOŢIONALE
E3
Ofertă de
E6
SERVICIUL Statistici analiză
MARKETING acţiuni promo reînscriere
FOST CLIENT

44
 Pasul 5: Trasarea diagramelor de flux de date de nivel mediu (Aplicaţia 2, legătura
Unităţilor funcţionale ale cestea)

E1
CLIENT

Reducere sau Comandă Cerere

comandă răspuns de probată CONTIN.
E5 specială la Pag. următ.
MAGAZIE Comandă de
prelucrat membru
UF 2.1 Plafon şi bonitate
credit
Informaţii comenzi existente PRELUCRARE
TRANZ.COMEN D8 CONTURI ÎNCASĂRI
ZI
Comandă automată revizuită Există produs
Comandă în STOC
amânată nouă
D4 COMENZI D5 COMENZI AMÂNATE D6 PRODUSE
Actualizare Actualizare Actualizare
comenzi comenzi amânate PRODUSE

UF 2.2. UF 2.3. UF 2.4.

ÎNTREŢINE- ÎNTREŢINERE ÎNTREŢINE-

DATE DATE COM. DATE
COMENZI AMÂNATE PRODUSE

Modificare Modificare Modificare

sau anulare Modificare sau stoc linie produse şi
comandă anulare preţ
E7 comandă E9 E3
SERVICIUL amânată SISTEMUL DE SERVICIUL
PRELUC.COMENZI GEST. STOCURI MARKETING

45
Pasul 5: Trasarea diagramelor de flux de date de nivel mediu (Unitatea funcţională 2,
legătura Unităţilor ei de prelucrare)

E1

MEMBRU
GRUP(CLIENT)
Comandă
răspuns
de la
client UP 2.1.2
Plafon şi bonitate
D8 CONTURI ÎNCASĂRI credit PRELUCRARE
RĂSPUNS
Plafon şi VEZI PE ANT. CLIENT
bonitate
credit Plafon şi Cerere Comandă automată revizuită
bonitate aprobată
credit D4 COMENZI
UP 2.1.1 UP 2.1.3
Reducere sau E1
PRELUCRARE PRELUCRARE comandă
COMENZI COMENZI specială MEMBRU
AUTOMATE SPECIALE GRUP(CLIENT)

Comandă de
Informaţii prelucrat Comandă de
comenzi prelucrat
existente
Comandă de
D4 COMENZI E5 prelucrat

MAGAZIE

46
Pasul 6: Trasarea DFD de nivel jos (primitive, a Unităţii de prelucrare 212, în Module
componente, necesare programării)

Comandă
E1 de la MOD. 2.1.2.1
membru D1 CLIENŢI
MEMBRU REVIZUIRE Adresă şi
GRUP CL. COMANDĂ sold
AUTOMAT CLIENT
Comandă automată Ă MOD .2.1.2.7
revizuită Comandă
CERERE DE
automată Cerere de
PLATĂ ÎN
Membru
D4 COMENZI insolvabil AVANS plată avans

Comandă MOD. 2.1.2.2

Stare în
aşteptare E1
Plafon şi
VERIFICA-
bonitate credit RE CREDIT D4 COMENZI MEMBRU
CLIENT
D8 CONTURI ÎNCASĂRI Comandă Stare GRUP CL.
Comandă eliberată aşteptare
aprobată ştearsă Plată avans
MOD 2.1.2.8 E8
C-dă în
D6 PRODUSE MOD. 2.1.2.3 aşteptare ELIBERARE Avans
eliberat C-DĂ ÎN c-dă SERV.
Există produs ÎNCASĂRI
VERIFI- ă AŞTEPTARE
în stoc?
CARE STOC
E5 PRODUS C-dă fără stoc

C-dă realizabilă MOD. 2.1.2.6

MAGAZIE
Comandă de prelucrat
MOD. 2.1.2.4 ÎNŞTIINŢEAZĂ
MEMBRU DE
Aviz expediţie D1 CLIENŢI TRIMITE
AMÂNARE

Incarcă sold cont C-DA LA

Înştiinţare c-dă
EXPEDIERE
MOD 2.1.2.5 amânată
Stare în prelucrare
ÎNCHIDERE Stare în prelucrare E1
COMANDĂ ştearsă D4 COMENZI
C-dă închisă MEMBRU
C-dă gata de GRUP
facturare CLIENT
Indeplinire obligaţii C-dă amânată nouă
E8
D3 CONVENŢII D5 COMENZI
SERV. AMÂNATE
ÎNCASĂRI

47
 B. Proiectarea de detaliu în cazul aplicaţiilor obiectuale.
Introducere privind folosirea UML – ului

Natura şi scopul modelelor

1. Ce este un model
2. La ce se folosesc modelele
3. Niveluri de modele
4. Ce conţine un model
5. Ce înseamnă un model

1. Ce este un model
 Reprezentarea simplificată a unui sistem, lucru sau fenomen:
 capturează aspectele semnificative ale obiectului modelării dintr-un anumit punct de
vedere;
 simplifică sau omite restul.
 Modalităţi de exprimare:
 desene pe hârtie;
 machete 3D;
 formule (modele matematice);
 limbaje de modelare: UML.

2. La ce se folosesc modelele
 Pentru capturarea şi exprimarea precisă a cerinţelor şi cunoştinţelor domeniului cu scopul
obţinerii unui nivel comun de înţelegere şi acord pentru stakeholders:
 cerinţe despre domeniul aplicaţiei, modul în care va fi folosit sistemul de către
utilizatori, descompunerea în module, şabloane comune folosite la construire;
 stakeholders: arhitect, analist, programator, manager de proiect, sponsor, client,
utilizator, operator.
 Pentru a permite proiectarea sistemului:
 modelul sistemului soft ajută dezvoltătorii să exploreze mai multe arhitecturi şi soluţii
de proiectare înainte de scrierea codului;
 un limbaj de modelare bun permite proiectantului să obţină arhitectura generală
înainte de începerea proiectării de detaliu.
 Pentru a captura deciziile de proiectare într-o formă mutabilă şi separată de cerinţe:
 un model al sistemului soft poate captura comportamentul extern al unui sistem şi
informaţia din domeniul lumii reale reprezentată de sistem;
 un alt model al sistemului ilustrează clasele interne şi operaţiile care implementează
comportamentul extern;
 există multe modalităţi de implementare a comportamentului extern; modelul final de
proiectare ilustrează acea abordare pe care proiectantul o consideră cea mai potrivită.
 Pentru a genera produse utilizabile:
 modelul sistemului soft se poate folosi pentru a genera declaraţii de clase, corpuri de
proceduri, interfeţe cu utilizatorul, scheme de baze de date, scenarii de folosire legală,
scripturi de configurare etc..
 Pentru organizarea, filtrarea, regăsirea, examinarea şi editarea informaţiei despre
sistemele mari:

48
  în modelul sistemului soft informaţia este organizată în mai multe vederi: structura
statică, maşini cu stări, interacţiuni, cerinţe etc. Fiecare vedere este o proiecţie a
informaţiei din modelul complet în raport cu un scop anume:
 se foloseşte un editor de diagrame;
 informaţia este prezentată în diverse formate;
 informaţia nerelevantă în raport cu un anumit scop este ascunsă;
 operaţiile înrudite se grupează împreună.
 Pentru explorarea cu costuri mici a multiplelor soluţii:
 se propun şi se compară mai multe soluţii de proiectare;
 modelele nu se construiesc complet, ci doar până la nivelul la care se pot face
comparaţiile.
 Pentru construirea de sisteme complexe:
 permite tratarea complexităţii;
 modelul poate abstractiza până la un nivel comprehensibil pentru om, fără a recurge la
detalii care ascund esenţa;
 calculatorul poate face analize complicate pe un model;
 modelul poate determina impactul potenţial al unei modificări înainte de efectuarea
acesteia, prin explorarea dependenţelor din sistem;
 modelul poate arăta cum se poate restructura sistemul pentru a reduce dependenţele.

3. Niveluri de modele
 Nivel înalt: ghid pentru procesul de gândire:
 modelele de nivel înalt construite în fazele timpurii ale unui proiect servesc la
focalizarea procesului de gândire pe clienţi şi pe punerea în evidenţă a opţiunilor
posibile:
 capturează cerinţele şi reprezintă un punct de plecare pentru proiectare;
 ajută dezvoltătorii să exploreze opţiunile (soluţiile) posibile înainte de a converge
spre un concept de sistem;
 pe măsură ce proiectarea avansează, modelele timpurii sunt înlocuite de modele
tot mai detaliate;
 modelele de nivel înalt folosesc un subset al construcţiilor UML.
 Specificări abstracte ale structurii esenţiale a sistemului:
 se folosesc în analiză sau proiectarea preliminară;
 pun accentul pe conceptele şi mecanismele cheie ale sistemului, pe aspecte semantice;
 corespund într-o măsură sistemului final, fără a pune în evidenţă detaliile;
 scop: să se obţină corect elementele de nivel înalt înainte de a intra în detaliere.
 Specificări complete ale sistemului final:
 model de implementare: conţine suficientă informaţie pentru construirea sistemului;
 include:
 semantica sistemului;
 algoritmi, structuri de date şi mecanisme ce asigură performanţa corespunzătoare;
 decizii organizaţionale despre artefactele sistem care sunt necesare pentru munca
cooperativă a oamenilor şi sunt prelucrate de instrumente.
 Exemple de sisteme tipice sau posibile:
 exemple bine alese pot da informaţii suplimentare oamenilor şi pot valida specificările
şi implementările sistemelor;
 exemple de structuri de date, secvenţe de interacţiuni, istorii de obiecte tipice pot ajuta
la înţelegerea situaţiilor complicate.

49
 Descrieri complete sau parţiale ale sistemelor:
 variante: modelul este:
 descriere completă a unui singur sistem, fără referinţe exterioare;
 mulţime de unităţi distincte şi discrete, fiecare memorată şi manipulată separat ca
parte a unei descrieri integrale:
 au terminaţii ce se pot lega cu alte modele, pentru a forma un sistem complet;
 reutilizare: piesele au coerenţă şi semantică, putând fi combinate cu alte piese
pentru a forma mai multe sisteme diferite;
 modelele evoluează în timp:
 modelele mai detaliate sunt obţinute din modele mai abstracte;
 modelele mai concrete sunt obţinute din modele mai logice;
 exemplu:
 nivel înalt: vedere a întregului sistem, cu câteva servicii cheie descrise pe
scurt;
 pe urmă: se adaugă detalii, se discută variante ;
 pe urmă: accentul se deplasează de la o vedere abstractă front-end, centrată pe
utilizator, la o vedere fizică back-end, centrată pe implementare;
 iteraţiile modelului trebuie să acopere toate nivelele, pe măsură ce
dezvoltătorii îl înţeleg mai bine.

4. Ce conţine un model
 Două aspecte majore: semantică şi prezentare vizuală:
 aspectul semantic:
 capturează înţelesul aplicaţiei ca reţea de construcţii logice: clase, asociaţii, stări,
cazuri de utilizare, mesaje;
 elementele modelului semantic se folosesc pentru generarea codului, verificarea
validităţii, metricile de complexitate etc.;
 informaţia semantică se numeşte de regulă model;
 prezentarea vizuală:
 ilustrează informaţia semantică într-o formă ce se poate vedea, parcurge şi
modifica de oameni;
 elementele de prezentare ilustrează modelul într-o formă uşor de înţeles de către
oameni:
 organizează prezentarea într-o formă care accentuează aranjamentul modelului
într-o formă utilizabilă;
 semantica elementelor vizuale este derivată din elementele modelului semantic.
 Contextul:
 organizarea internă a modelului:
 folosirea simultană de mai multe grupuri fără interferenţe reciproce;
 adnotaţiile despre folosirea fiecărui model în procesul general de dezvoltare;
 o mulţime de valori implicite şi de ipoteze privind crearea şi manipularea elementelor;
 o relaţie cu mediul în care se folosesc elementele.

5. Ce înseamnă un model
 Modelul este generator de configuraţii potenţiale de sisteme.
 Modelul este o abstractizare, capturând aspectele esenţiale ale unui sistem.

50
 Elemente de discuţie:
 Abstractizare versus detaliu:
 ce este esenţial depinde de scopul modelului;
 limbajul de modelare este de regulă mai imprecis decât cel de programare.
 Specificare versus implementare:
 specificare: ce trebuie făcut:
 prima dată: să ştim ce (fără a şti cum);
 separarea specificării de implementare;
 implementare: cum trebuie făcut.
 Descriere versus instanţă:
 modelele sunt descrieri:
 instanţele apar în model numai ca exemple;
 modelele descriu instanţe:
 instanţele reale apar numai la execuţie;
 unele instanţe sunt descrieri ale altor date – metadate.
 Variaţiuni în implementare:
 diverse interpretări ale modelelor într-un limbaj de modelare.

3. Concepte UML

Glosar:
 clasă: descriptor pentru o mulţime de obiecte ce au aceleaşi atribute, operaţii, metode,
relaţii şi comportament;
 obiect: entitate discretă cu o frontieră bine definită şi cu identitate, ce încapsulează stare şi
comportament; instanţă a unei clase;
 instanţă: entitate individuală cu identitate şi valoare proprie; un descriptor specifică forma
şi comportamentul mulţimii instanţelor cu proprietăţi similare;
 atribut: descrierea unei poziţii cu nume şi tip specific dintr-o clasă; fiecare obiect al clasei
are o valoare proprie de tipul respectiv;
 operaţie: specificarea unei transformări sau interogări pe care un obiect le poate executa;
are un nume şi o listă de parametri;
 metodă: implementarea unei operaţii; specifică algoritmul sau procedura care produce
rezultatele operaţiei;
 relaţie: conexiune (legătură) semantică între elementele unui model; tipuri de relaţii sunt
asocierea, generalizarea, metarelaţia, fluxul şi relaţii de dependenţă;
 relaţii între clase:
 asocierea: relaţie semantică între două sau mai multe clasficatoare ce implică
legături între instanţele lor;
 generalizarea: relaţie de clasificare între un element mai general şi unul mai
specific:
 elementul mai specific este complet consistent cu elementul mai general şi
conţine informaţie suplimentară;
 polimorfism: oriunde este se cere folosirea unei instanţe a elementului mai
general se poate folosi o instanţă a elementului mai specific;
 dependenţa: relaţie între două elemente în care schimbarea unui element
(furnizorul, elementul independent) poate afecta sau furniza informaţia necesară
celuilalt element (clientul, elementul dependent):

51
  realizarea: relaţie între o specificare şi implementarea acesteia; indicaţie a
moştenirii comportamentului fără moştenirea structurii;
 folosirea: relaţie de dependenţă în care clientul necesită prezenţa altui element
(furnizorul) pentru funcţionarea sau implementarea corectă a sa - de regulă din
motive de implementare;
 comportament: efectele observabile ale unei operaţii sau unui eveniment, inclusiv
rezultatele;
 vedere (view): o submulţime de construcţii UML ce reprezintă un aspect al sistemului.

Tipuri majore de vederi (nivelul de sus):

 clasificare structurală: descrie lucrurile din sistem şi relaţiile lor cu alte lucruri:
 clasificatori: clase, cazuri de utilizare, componente, noduri;
 vederi de clasificare: vederea statică, vederea cazurilor de utilizare, vederea de
implementare, vederea de instalare/configurare;
 comportament dinamic: descrie comportamentul sistemului în timp:
 se poate descrie ca o succesiune de schimbări ale clişeelor sistemului descrise de
vederile statice;
 vederi de comportament: vederea maşinii cu stări, vederea activităţilor şi vederea
interacţiunilor;
 gestiunea modelului: organizarea modelelor în unităţi ierarhice:
 pachetul: unitatea generică de organizare a modelelor;
 modele, subsisteme: tipuri speciale de pachete .

Tabel. Vederi şi diagrame UML

Tipul major de
Reprezentanţi Diagrame Concepte majore
vedere
clasă, asociere, generalizare,
vederea statică diagrama de clase
dependenţă, realizare, interfaţă
vederea caz de utilizare, actor, asociere,
diagrama cazurilor
cazurilor de extindere, includere, generalizare de
de utilizare
utilizare caz de utilizare
structural
vederea de diagrama de componentă, interfaţă, dependenţă,
implementare componente realizare
vederea de diagrama de
nod, componentă, dependenţă, locaţie
instalare/ instalare/
configurare configurare
vederea maşinii
diagrama de stări stare, eveniment, tranziţie, acţiune
cu stări
vederea diagrama de stare, activitate, tranziţie de terminare,
activităţilor activităţi fork, join
dinamic
diagrama de
interacţiune, obiect, mesaj, activare
vederea secvenţe
interacţiunilor diagrama de colaborare, interacţiune, rol în
colaborări colaborare, mesaj
vederea
gestiunea
gestiunii diagrama de clase pachet, subsistem, model
modelului
modelului
constrângere, stereotip, valori cu
extensibilitate toate toate
atribute

52
 Analiza cerinţelor. Diagrame UML
A. Analiza cerinţelor

1. Începutul unui proiect

Un proiect poate începe:
 cu o idee a clientului;
 cu o idee a unei echipe de dezvoltare.
Aceasta idee poate fi:
 clară, bine definită;
 vagă, prost definită.
Pentru a continua cu succes, este nevoie de modelare cerinţelor.

2. Cerinţa: ce, cum, cât?

Exemplu de cerinţă: Pe o cale ferată uscată, locomotiva trebuie să fie capabilă să
pornească un tren de 100 tone, iar pe o pantă de maxim 5% cu o acceleraţie de cel puţin
30km = h2.
Caracteristici ale acestei cerinţe:
 Spune ce vrea clientul [ok];
 Nu spune cum sa fie realizate cerinţele [ok(?)];
 Cerinţele sunt cuantificabile [ok];
 Nu menţionează nimic despre preţ¸ [!];
 Nu specifică termenul de realizare [!].

3. Specificaţie bună
Spune ce trebuie făcut, nu cum:
 Este clară (neambiguă);
 Este suficient de detaliată;
 Este completă.

4. Detalii de implementare la analiza?

 NU:
1. Clientul nu este competent în detalii tehnice.
2. E necesar să restrângem mulţimea posibilelor soluţiile tehnice?
 DA:
1. Este nevoie să integram într-un sistem existent.
2. Timpul de dezvoltare depinde de implementare.
3. Întreţinerea (costul) depinde de implementare.

5. Responsabilităţile analistului:
 să extragă şi să clarifice cerinţele clientului;
 să ajute la rezolvarea diferenţelor de opinie între clienţi şi utilizatori;
 să sfătuiască clientul despre ce este tehnic posibil sau imposibil;
 să documenteze cerinţele;
 să negocieze şi să obţină o înţelegere cu clientul.

6. Activităţile analistului:
 Ascultare: Înregistrează cerinţele clientului.

53
  Reflectare: Traduce cerinţele în limbaj tehnic. Verifică pertinenţa.
 Scriere: Se cade de acord asupra formulărilor.
 Repeta până când se ajunge la o înţelegere cu clientul în ceea ce priveşte
cerinţele.

7. Probleme potenţiale
Procesul iterativ poate fi lung şi complicat:
 Negocieri (dure).
 Diferenţă culturală dintre client şi analist.
 Diferenţe între cerinţele clientului şi ale utilizatorilor.
 Filmele SF văzute de client.
 Filmele SF văzute de programatori.

8. Rezultatele analizei
Document de specificare a cerinţelor:
 Acest document este folosit ca referinţă.
 Provocări.
Nivelul de detaliu:
 Mare: mai precis, obţinut mai greu, muncă inutilă.
 Mic: prea vag, nu poate ghida eficient dezvoltarea.
Audienţa documentelor:
 2 versiuni: una pentru client, alta pentru dezvoltători?
Notaţia folosită:
 Informală, semiformală, formală

9. Tipuri de cerinţe
Cerinţe funcţionale:
 Ce trebuie să facă sistemul.
Cerinţe privind datele:
 Formatul datelor la intrare/ieşire.
 Formatul datelor din interiorul sistemului.
Constrângeri:
 Cerinţe de respectat ad-literam.
 Influenţează direct implementarea.
Recomandări:
 Ajută la luarea deciziilor de proiectare când sunt mai multe opţiuni.

Exemple:
Cerinţe funcţionale:
 Sistemul se va opri în maxim 5 secunde după ce temperatura procesorului
atinge 80 grade Celsius.
 Sistemul va permite căutarea şi afişarea titlurilor cărţilor scrise anumit
autor.
Cerinţe privind datele:
 Datele vor fi exportate în format XML.
 Datele din tampoanele de intrare şi ieşire vor fi criptate.
Constrângeri:
 Implementarea se va realiza folosind un limbaj orientat obiect.
Recomandări

54
  Se va folosi cât mai puţină memorie.
10. Scenarii:
 Prezintă sistemul din perspectiva utilizatorului şi înţelegem ce se cere.
 Extragerea cerinţelor, testare.
 Frecvenţa de utilizare a scenariilor, deci, priorităţi asignate cerinţelor.
 Documentaţia utilizatorilor.
 Prezentarea sistemului utilizatorilor.

B. Diagrame UML

UML este un limbaj de modelare bazat pe notaţii grafice şi este folosit pentru a:
specifica, vizualiza, construi , documenta, componentele unui program (sistem software).

1. Tipuri de diagrame UML

 Analiză:
o Diagrama cazurilor de utilizare (Use Case Diagram)
o Diagrama de activităţi (Activity Diagram)
 Proiectare:
o Structura: Diagrama de clase (Class Diagram)
o Comportamentul:
 Diagrama de stări (Statechart Diagram)
 Diagrame de interacţiuni (Interactions Diagrams)
 Diagrama de secvenţă (Sequence Diagram)
 Diagrama de colaborare (Collaboration Diagram)
 Implementare:
o Diagrama de componente (Component Diagram)
o Diagrama de plasare (Deployment Diagram)

a. Diagrama cazurilor de utilizare (Use-Case) folosite în faza de analiză a

cerinţelor
Folosită pentru a capta cerinţele sistemului:
o Delimitează graniţele sistemului.
o Punctul de plecare îl constituie scenariile de folosire a sistemului.
o Poate prezenta:
o specificarea cerinţelor (externe) din punctul de vedere al utilizatorului;
o specificarea funcţionalităţii sistemului din punctul de vedere al
sistemului.
Poate conţine:
o Use Case-uri = funcţionalităţi ale sistemului.
o Actori = entităţi externe cu care sistemul interacţionează.
o Relaţii.
o Este o descriere a unei mulţimi de secvenţe de acţiuni (incluzând variante) pe
care un program le execută atunci când interacţionează cu entităţile din afara
lui (actori) şi care conduc la obţinerea unui rezultat observabil.
o Poate fi un sistem, un subsistem, o clasă, o metodă.
o Reprezintă o funcţionalitate a programului.
o Precizează ce face un program sau subprogram.
o Nu precizează cum se implementează o funcţionalitate.

55
 o Identificarea use case-urilor se face pornind de la cerinţe ale clientului şi
analizând descrierea problemei.

b. Elemente Use Case:

o Actor:
 Reprezintă un rol pe care utilizatorii unui use case îl joacă atunci când
interacţionează cu acesta.
 Este o entitate exterioară sistemului.
 Interacţionează cu sistemul.
 Iniţiază execuţia unor cazuri de utilizare.
 Oferă funcţionalitate pentru realizarea unor cazuri de utilizare.
Poate fi:
 utilizator (uman);
 sistem software;
 sistem hardware;
 Actor : notaţie în dreapta.

o Atribute:
 Nume = indica rolul pe care actorul îl joacă în interacţiunea cu un
UseCase.
 Restricţii, doar Numele este unic.
o Relaţii, care se stabilesc între:
 Actor - UseCase: asociere
 Actor - Actor: generalizare
 Use Case – Use Case: asociere, generalizare, dependenta
(<<include>>, <<extend>>)

c. Asociere:
- Modelează o comunicare între elementele pe care le conectează.
- Notaţie:
- Poate să apară între:
o un actor şi un Use Case (actorul iniţiază execuţia cazului de
utilizare sau oferă funcţionalitate pentru realizarea acestuia);
o două Use Case-uri (transfer de date, trimitere de
mesaje/semnale).

Exemplu:

56
 d. Generalizare:
o Se realizează între elemente de acelaşi tip de ierarhii.
o Modelează situaţii în care un element este un caz particular al
altui element.
o Elementul particular moşteneşte relaţiile în care este implicat
elementul general.
o Notaţie:

e. Dependenta:
o Apare între două Use Case-uri.
o Notaţie
o Modelează situaţiile în care:
o Un Use Case foloseşte comportamentul definit în alt Use Case
(<<include>>);
o Comportamentul unui Use Case poate fi extins de către un alt
Use Case (<<extend>>).

Realizarea diagramei cazurilor de utilizare folosind: ArgoUML, Rational Rose,

Star UML, NetBeans IDE 6,etc.

57
 1. Crearea diagramelor UML ale cazurilor de utilizare şi a diagramelor UML de clase
folosind mediul NetBeans IDE 6

Această lucrare de laborator vor fi acoperite următoarele probleme:

- Crearea diagramelor UML ale cazurilor de utilizare în NetBeans 6.
- Crearea diagramelor UML de clase în NetBeans 6 .
- Studiu de caz - diagrama UML de clase .
Atenţie: La începutul laboratoarelor ştergem mai întâi toate proiectele existente
(click dreapta pe nodul proiectului în fereastra Projects, selectăm Delete şi confirmăm că
dorim să fie şterse sursele – în cazul proiectelor Java). La finalul laboratoarelor ştergem
proiectele create.
a. Crearea diagramelor UML ale cazurilor de utilizare in NetBeans 6
În continuare vom învăţa cum să folosim caracteristicile UML ale IDE-ului NetBeans
pentru a crea o diagramă UML a cazurilor de utilizare (Use Case) simpla.
Folosind modelul diagramei Use Case, vom arăta relaţia dintre actori (entităţile
externe) şi cazurile de utilizare în cadrul unei aplicaţii. Diagrama Use Case pe care o creăm
urmăreşte diferitele funcţii şi entităţile care interacţionează cu acele funcţii în cadrul unei
aplicaţii bancare teoretice.
O diagramă Use Case este folositoare atunci când descrieţi cerinţele unui sistem în
stadiile de analiză, proiectare (design), implementare şi documentare. Scopul acestui tutorial
este de a prezenta diagramele UML ale cazurilor de utilizare în IDE-ul NetBeans, fără a
insista pe conceptele UML sau limbajul de programare Java (vezi şi
http://www.netbeans.org/kb/60/uml/index.html).

b. Crearea proiectului UML şi a diagramelor cazurilor de utilizare

În această secţiune, vom crea proiectul UML şi diagrama cazurilor de utilizare pentru
aplicaţie.
1 Creăm un nou director numit UMLTutorial pe drive-ul D: în directorul \isw, în
subdirectorul propriu, (de exemplu: D:\isw\441E\UMLTutorial).
2 Din meniul principal, selectăm File> New Project şi apoi facem următoarele în New
Project Wizard:
Sub Categories, selectăm UML.
Sub Projects, selectăm Java-Platform Model.
Facem Click pe Next.
Se va deschide caseta de dialog New Java-Platform Model.
1. În câmpul Project Name, scriem UMLTutorialProject.
Observăm că atunci când scriem Project Name, IDE-ul sugerează automat acest
nume.
2. Pentru câmpul Project Location, facem click pe Browse.
3. În căsuţa de dialog a Select Project Location, selectăm UMLTutorial, care este
directorul pe care l-am creat în pasul 1.
4. Facem click pe Open pentru a elimina căsuţa de dialog.
5. În pagina Name and Location, click Finish.

IDE-ul creează proiectul UML, se deschide New Wizard şi afişează căsuţa de

dialog Create New Diagram.
1 În lista Diagram Type, selectăm Use Case Diagram.
2 În câmpul Diagram Name, scriem UseCaseDiagram.
3 Lăsăm UMLTutorialProject în câmpul Namespace şi click Finish. IDE-ul face

58
următoarele: Creează nodul Use Case Diagram sub nodul Model
Afişează noua diagramă în editorul diagramei (diagrama este goală în acest moment)
Deschide (Modeling) Palette.

c. Adăugarea şi etichetarea elementelor Use Case (caz de utilizare)

În această secţiune vom adăuga elementele Use Case (caz de utilizare) folosind
Palette în IDE-ul NetBeans.
1. Din secţiunea Basic a Palette.
2. Selectăm pictograma Use Case şi facem click o singură dată în partea de sus
stânga a editorului de diagrame.
Acesta acţiune plasează un element Use Case în diagrama.
1 Deselectăm pictograma făcând click-drepta oriunde în editorul de diagrame sau
apăsând tasta ESC.
2 Dacă nu este deja selectat, selectaţi noul element adăugat făcând click pe el o dată.
3 Scriem Withdraw Money şi apăsăm Enter. Acesta etichetează elementul cu textul
Withdraw Money.
4 Selectăm pictograma Use Case din nou şi plasăm încă 7 elemente Use Case în
diagrama. Plasăm elementele în patru rânduri conţinând câte două elemente în fiecare rând.
5 Deselectăm pictograma făcând click-drepta oriunde în editorul de diagrame.
6 Selectăm elementul Use Case aflat sub Withdraw Money.
7 Scriem Withdraw Cash from ATM şi apăsăm Enter.
8 Etichetăm elementele Use Case ramase după cum urmează:
Deposit Money Process a LoanApply for LoanDeposit Cash at ATM Service
ATMs Update Customer Database Observatie:
Când am adăugat şi etichetat elementele diagramei, le putem redimensiona după
nevoie făcând click-dreapta pe element şi selectând Resize to Element to Contents din pop-
up menu.
Diagrama ar trebuie să se asemene cu figura următoare:

59
 1. Adăugarea şi etichetarea elementelor Actor
Acum veţi adăuga elementele cazurilor de utilizare folosind Palette în IDE-ul
NetBeans.
1 Din secţiunea Basic a Palette, selectaţi pictograma Actor.
2 Facem click o dată în dreapta elementului caz de utilizare Apply for a Loan pentru a
plasa elementul Actor în diagramă. Un element Actor nedenumit este plasat în editorul de
diagrame.
3 Facem click pe ESC pentru a deselecta pictograma.
4 Selectăm elementul Actor pe care tocmai l-aţi plasat în diagramă, scriem Customer
şi apăsăm Enter. Elementul Actor este astfel etichetat.

Observaţie: Când aţi adăugat mai multe elemente diagramei, facem click pe butonul
Fit To Window din bara de instrumente (toolbar-ul) Diagram pentru a rearanja
diagrama astfel încât să puteţi vedea întreaga diagramă în editorul de diagrame.
Apoi:
1 Plasăm încă 5 elemente Actor sub actorul Customer în editorul de diagrame.
2 Deselectăm pictograma Actor făcând click oriunde în editorul de diagrame.
Apoi:
3 Etichetăm noile adăugate elemente Actor după cum urmează: Employees Bank
Teller Loan Officer Technician Bank Computer
4 Click-dreapta pe tab-ul UseCaseDiagram şi alegem Save Document din pop-up
menu.
Diagrama ar trebui să se asemene cu figura următoare.

60
 2. Legarea elementelor Actor între ele

În această secţiune veţi lega elementele Actor între ele folosind Generalization.
1. Din secţiunea Basic a Palette, selectăm pictograma Generalization.
2. Facem click pe elementul Bank Teller, apoi click pe elementul Employees. Apare o
legătură (link) între cele două elemente Actor. Informaţiile legate de relaţia Generalization
apar în fereastra Properties.
3. Facem click-drepta oriunde în editorul de diagrame pentru a deselecta pictograma
Generalization.
4. În editorul de diagrame, selectăm legătura Generalization.
5. În fereastra Properties, facem click pe butonul proprietăţii Stereotypes
. Apare expertul Stereotypes.
1 Facem click pe Add, apoi facem click în câmpul gol Name şi scriem
implementation.
2 Click pe OK. legătura este eticheta <<implementation>>.
3 Adăugăm legături Generalization pentru următoarele:

Loan Officer to Employees Technician to Employees

3. Legarea elementelor Actor de elementele Use Case

În această secţiune veţi lega elementele Actor între ele folosind Association.
1 Din secţiunea Basic a Palette, selectăm pictograma Association
2. Facem click pe elementul Customer, apoi click pe elementul Withdraw Cash from
ATM.
Apare o legătură (link) între Actor si Use Case.
3. Facem click-drepta oriunde în editorul de diagrame pentru a deselecta pictograma
Association.
4. Cu nouă legătură Association încă selectat plasăm cursorul în mijlocul liniei ce
reprezintă legătură şi facem click dreapta.
Nota: Când legătura este selectată, aceasta devine albastră. Poate fi riscant să ţinem
cursorul pe link. Dacă cursorul este poziţionat în spaţiul alb când facem click-dreapta, am
putea vedea meniul pop-up pentru editorul de diagrame mai degrabă decât meniul pop-up
pentru legătură. Dacă se întâmplă asta încercaţi din nou, asigurându-vă că legătura este
albastră, click-dreapta şi ar trebui sa vedem meniul pop-up corect pentru legătura, după cum
se arată în figura următoare.
2 Alegem Labels > Link Name din meniul pop-up. Legătura este etichetată cu textul
Unnamed, care este evidenţiat.
3 Scriem textul uses şi apăsăm Enter. Legătura este etichetată acum cu textul uses.
4 Din secţiunea Basic a Palette, selectăm pictograma Association şi adăugăm încă 7
legături, conectând Actori şi Use Cases făcând click pe elementul Actor întâi şi apoi făcând
click pe elementul Use Case după cum urmează:
Customer la Deposit Cash to ATM Customer la Apply for Loan Bank Teller la
Withdraw Money Bank Teller la Deposit Money Bank Computer la Update Customer
Database Technician la Service TMs Loan Officer la Process a Loan.
8. Deselectaţi pictograma Association.

61
 4. Utilizarea legăturilor Extend (extindere)

O legătură Extend arată relaţia dintre un Use Case şi altul, specificând felul în care
comportamentul definit pentru cazul de utilizare extins poate fi inserat în
comportamentul definit pentru cazul de utilizare de baza.
1 Din secţiunea Basic a Palette, select[m pictograma Extend.. Faceţi click o singură
dată pe elementul Withdraw Cash From ATM şi click din nou pe elementul Withdraw
Money.
O legătură etichetată <<extend>> este desenată cu o săgeată ce arată spre elementul
Withdraw Money.
2 Repetăm paşii anteriori pentru a desena legături Extend între următoarele Use Cases:
Deposit Cash at ATM > Deposit Money Process a Loan > Apply for Loan.
3 Click-drepta oriunde în editorul de diagrame pentru a deselecta pictograma Extend
Link.
4 Pentru a rearanja diagrama, faceţi click pe butonul Orthogonal Layout

din bara de instrumente (toolbar-ul) Diagram şi click Yes în căsuţa de avertisment

Layout.

Observaţie: Ar putea fi necesar sa extindeţi diagrama pentru a vedea butonul

62
Orthogonal Layout din toolbar. Pentru a face aceasta, faceţi dublu-click pe tab-ul Use Case
Diagram. Puteţi deasemenea să facem click-dreapta în editorul de diagrame şi să alegem
Layout > Orthogonal din meniul pop-up. IDE-ul rearanjeză diagrama Use Case Diagram
într-un stil dreptunghiular de aşezare (layout).
Diagrama terminată ar trebui să se asemene cu figura următoare. Diagrama poate avea
însă un layout uşor diferit. Atâta timp cat relaţiile şi elementele sunt corect reflectate, orice
diferenţă uşoară de format este normală.

6. Apăsaţi Ctrl+S oriunde în editorul de diagrama pentru a salva modificările făcute în

model.

5. Concluzii
În acest tutorial am învăţat să creaţi o diagrama Use Case pentru o simplă aplicaţie
bancară şi a-ţi învăţat cum să efectuaţi următoarele activităţi:
 Să creaţi un proiect UML.
 Să creaţi o diagrama Use Case.
 Să folosiţi pictogramele UML din Palette pentru a crea cazuri de utilizare
şi actori.
 Să conectaţi cazurile de utilizare şi actorii pentru a arăta funcţiile
aplicaţiei.

63
 2. Crearea diagramelor UML de clase în NetBeans 6

În continuare vom învăţa cum să folosiţi caracteristicile UML ale IDE-ului

NetBeans pentru a crea diagrame UML de clase. Acest material vă arată diferite tehnici de
creare a elementelor unei diagrame de clase şi cum sa generaţi un cod de sursa Java pentru
diagrama. Scopul este de a vă prezenta câteva dintre funcţionalităţile IDE-ului dedicate
modelării UML cu diagrame de clase.
O diagrama de clase este o reprezentare vizuală a unei aplicaţii care îi arată
clasele şi relaţiile dintre acele clase. Când deschideţi o diagramă de clase, IDE-ul afişează o
selecţie specifică de pictograme ale elementelor UML în (Modeling) Palette. Folosind
modelul diagramei de clase, vom descrie structura statică a elementelor din aplicaţia
dorită. IDE-ul va permite să creaţi grafic diagrame ce conţin clase. Clasele sunt aranjate în
ierarhii care împart structura comună şi comportamentul, deci, sunt asociate cu alte
clase.

a. Crearea diagramei de clase şi adăugarea elementelor ei

Clasele definesc atributele elementelor instanţă precum şi operaţiile pe care
fiecare element le executa sau le suporta. Când reprezentaţi o clasa într-un model UML,
puteţi realiza următoarele: Crearea elementului ce reprezintă clasa, Denumirea clasei,
Definirea atributelor clasei, Definirea operaţiilor clasei, Descrierea legăturilor şi a asociaţiilor
Adăugarea documentaţiei în Secţiunile următoare unde arătăm cum se creează o
digramă de clase simplă pentru o aplicaţie bancară ipotetică. După ce am parcurs pas cu
pas procedurile schiţate în acest material, digrama de clase ar trebui să arate ca în figura
următoare.
Diagrama este prezentată doar pentru referinţă.

64
Folosiţi instrucţiunile începând cu secţiunea următoare pentru a desena propria
diagrama de clase.

Modul de Crearea diagramei de clase:

În această secţiune vom crea diagrama de clase a aplicaţiei.

1 Dacă este necesar, pornim NetBeans IDE şi deschidem proiectul creat anterior
UMLTutorialProject.
2 În fereastra Projects, expandăm nodul UMLTutorialProject şi apoi facem click-
dreapta pe nodul Model.
3 Selectăm Add > Diagram din meniul pop-up. Se va deschide New Wizard şi va afişa
pagina Create New Diagram.
4 În lista Diagram Type, selectăm Class Diagram.
5 În câmpul Diagram Name, scriem ClassDiagram.

65
6 Lăsăm setarea implicită în câmpul Namespace şi apăsăm Finish. NetBeans IDE face
următoarele: Creează nodul ClassDiagram sub nodul Model Afişează noua diagramă în
editorul de diagrame (diagrama este goală în acest moment) Deschide Modeling Palette

Apoi adăugăm şi denumirea elementelor clasei:

Acum vom adăuga elementele claselor folosind Palette în IDE-ul NetBeans.

1. Din secţiunea Basic a Modeling Palette, selectăm pictograma Class şi facem
click în editorul de diagrame. Aceasta acţiune plasează un element Class pe diagrama.
2. Deselectăm pictograma prin click-dreapta oriunde în editorul de diagrame.
Observaţie: De fiecare dată când selectăm o pictograma, putem plasa instanţe
multiple ale acelui element în editorul de diagrame apăsând click de mai multe ori.
3. Dacă nu este încă selectat, selectăm noul element Class apăsând o data pe el.
4. Scriem EntryStation şi apăsăm Enter. NetBeans IDE face următoarele: Atribuie
elementului Class denumirea EntryStation Creează o metodă publică numită
EntryStation() Afişează proprietăţile clasei în fereastra Properties. Adaugă un
element Class cu numele EntryStation în fereastra Projects sub nodul Model.

Apoi vom adăuga atributele folosind meniul pop-up

Acum vom adăuga atributele clasei EntryStation.

1. Daca nu este selectat, selectăm elementul EntryStation în editorul de diagrame.
2. Facem click-dreapta pe cuvântul Attributes şi alegem Insert Attribute din meniul pop-up.
O linie editor se deschide şi afişează următoarele informaţii:
visibility type name[ranges]=initialValue{name=value}
3. Scriem stationID şi apăsăm Enter. Un atribut numit stationID de tip int apare în clasa
EntryStation, şi următoarele operaţii sunt create pe clasa:

public int getStationID()

public void setStationID (int val)

Observaţie: metodele get() şi set() sunt create pentru că ampăstrat setările implicite.

Apoi vom adăuga operaţiile

Acum vom adăuga alte operaţii clasei EntryStation.

1 În editorul de diagrame selectăm elementul clasa numit EntryStation.
2 Click-dreapta pe cuvântul Operations şi alegem Insert Operation din meniul pop-up. O
linie editor se deschide şi afişează următoarele informaţii:
visibility returnType name(parameter) {properties...}

3. Scriem validateEntryStation şi apăsăm Enter. NetBeans IDE creează o nouă metodă.

Apoi vom edita atribute sau operaţiile

Când facem dublu-click pe un atribut sau o operaţie a unei clase, o fereastră editor
combo se deschide ca în figura următoare.

66
 Pe măsură ce facem click pe fiecare parte a atributului sau operaţiei, eticheta acelei
părţi apare evidenţiată cu bold în fereastra combo. Dacă e posibil, partea selectată a operaţiei
sau atributului are o lista drop-down de valori.
De exemplu:
1 Facem dublu-click pe atributul stationID în clasa EntryStation.
2 Facem click pe cuvântul private. Observaţi faptul că visibility apare evidenţiat cu bold.
3 Apăsăm Ctrl + down arrow. O lista drop-down se deschide şi sunt afişate valorile pe
care le putem selecta pentru atributul visibility. Alegem o nouă valoare din lista drop-
down şi apăsăm Enter. Atributul este actualizat cu noua valoare.
Observaţie: Putem scrie direct noua valoare în editor. Dacă nu vedem ceea ce avem
nevoie în lista drop-down, folosim tastele dreapta şi stânga arrow pentru a poziţiona cursorul
şi a scrie valoarea corespunzătoare..
4 Pentru acest material folosim valoarea private şi apăsăm Enter pentru a închide editorul.

Apoi vom adăuga operaţiile

Acum trebuie să adăugăm mai multe clase pentru a completa diagrama de clase pentru
aplicaţia din domeniul bancar. După ce adăugaţi clasele, le denumiţi şi adăugaţi atribute şi
metode după cum apar mai jos folosind tehnicile pe învăţate până acum în acest tutorial.
1. Din secţiunea Basic a Modeling Palette, selectăm pictograma Class şi apăsăm de
5 ori în editorul de diagrame pentru a plasa elemente adiţionale de tip clasă după cum
se vede în figura:

67
 Apoi deselectăm pictograma Class printr-un click-dreapta oriunde în editorul de
diagrame.
Observaţie: Putem selecta şi trage noile elemente de tip clasă pentru a le aranja aşa
cum apar în figura precedentă, pentru a putea fi distinse una de cealaltă în mod clar.
1 Selectăm primul element fără nume de tip clasă de sub elementul EntryStation şi-l
denumim ATM.
2 Având elementul clasă ATM încă selectat, adăugăm un atribut după cum urmează:
private float cashOnHand.

5. Adăugăm un al doilea atribut clasei ATM şi-l definim după cum urmează:
private float dispensed.

Atributele apar în diagrama de clase.

Observaţie: Pe măsură ce adăugăm atribute şi metode claselor, mărimea elementelor
clasei se măreşte. Pentru a îmbunătăţi aspectul diagramei mutaţi elementele de tip clasă astfel
încât fiecare să se vadă în mod clar. Când realizăm acest lucru avem grijă să selectăm
elementul Class şi nu un atribut sau o metodă a acesteia.
1 Selectăm primul element de tip clasă situat sub clasa ATM şi-l denumim Consortium.
2 Adăugăm o metodă în clasa Consortium. Adăugarea metodelor este similară cu
adăugarea atributelor. Click-dreapta pe cuvântul Operations şi selectăm Insert
Operations.
3 Scriem validateAccountInfo şi apăsăm Enter. NetBeans IDE creează o nouă metodă
după cum urmează:
public void validateAccountInfo(). Apoi:

68
1 Selectăm elementul Class din dreapta clasei ATM şi-l denumim CashierStation.
2 Adăugăm 2 metode pentru această clasă după cum urmează:
public int verifyCard();
public float verifyAmountAvailable() .
3 Denumim cele 2 clase ramase Branch şi User. Pentru clasa User nu există atribute sau
metode.
4. Pentru clasa Branch, adăugăm un atribut după cum urmează:
private char connected

3. Găsirea elementelor diagramei în diferitele ferestre ale IDE-ului NetBeans

Putem utiliza diferite metode pentru a localiza rapid obiecte într-o diagrama sau în
fereastra Projects. Toate atributele şi operaţiile pe care le adăugăm elementelor Class în
editorul de diagrame apar în fereastra Projects. Atributele sunt reprezentate de pictograma
atribut . Operaţiile sunt reprezentate de pictograma operaţie .

3.1. Localizarea obiectelor din fereastra Projects în editorul de diagrame

In fereastra Projects, dăm dublu-click pe nodul EntryStation, iar În editorul de

diagrame elementul de tip clasa numit EntryStation este selectat şi centrat.

3.2. Localizarea obiectelor din editorul de diagrame in fereastra Projects

În editorul de diagrame selectăm clasa Consortium şi dăm click-dreapta pe ea.
Alegem Select in Model din meniul pop-up şi în fereastra Projects, numele obiectului ţintă
este subliniat.

4. Documentarea claselor şi a diagramelor

Există 3 metode diferite dintre care putem să alegem atunci când dorim să
introducem o documentaţie descriptivă pentru clase, atribute, metode şi diagrame.
Procedurile nu le prezentăm, ele pot fi găsite la adresa
http://www.netbeans.org/kb/60/uml/class-diagram.html#enterdoc

5. Adăugarea asocierilor şi a generalizărilor

O asociere descrie un grup de legături care împart o structura şi o semantica (un

înţeles) comune. Multiplicitatea specifica numărul de instanţe ale unei clase care se pot corela
cu o instanţa a clasei asociate. Multiplicitatea limitează numărul total de componente
corelate. Aceasta secţiune conţine următoarele proceduri:

5.1. Adăugarea unei asocieri între clase, se va face astfel:

1 Din secţiunea Association a Modeling Palette, selectăm pictograma
Aggregation
2 Facem click în interiorul elementului ATM şi apoi dăm click pe elementul
Consortium. O legătură apare între cele doua clase.
3 Efectuăm click-dreapta oriunde în editorul de diagrame pentru a deselecta
pictograma. Relaţia este reprezentată în fereastra Projects aşa cum apare mai
jos.

69
 4 Selectăm legătura Aggregation dintre ATM şi Consortium. Când legătura
este selectată, culoarea ei va deveni albastră.
5 Poziţionăm cursorul în apropierea mijlocului liniei selectate şi facem click-
dreapta.
6 Alegem Labels > Link Name din meniul pop-up.
7 Scriem AccountVerification în câmpul Name şi apăsăm Enter. Legătura
primeşte o etichetă după cum apare în figura următoare.
Apoi din secţiunea Association a Modeling Palette, selectăm pictograma
Association şi desenăm o legătură între CashierStation şi Branch.
8 Efectuăm click-dreapta oriunde în editorul de diagrame pentru a deselecta
pictograma.

70
 5.2. Adăugarea unei asocieri calificate între clase
O asociere calificată corelează două clase şi un calificator. Calificatorul este un atribut
special care reduce multiplicitatea efectivă a asocierii. Putem descrie o asociere calificată ca
fiind o căsuţa la capătul liniei de asociere în apropierea clasei pe care o califică. Următorul
pas va arăta cum putem crea o asociere calificata între clasa ATM şi clasa Consortium.
Efectuăm click-dreapta pe legătura Aggregation ce uneşte clasa Consortium şi
alegem Show Qualifier. Un calificator se va ataşa de elementul clasă Consortium ca în
figura:

71
 5.3. Adăugarea multiplicităţii unei asocieri
În mod implicit etichetele de multiplicitate sunt ascunse.
Pentru a stabili multiplicitatea unei asocieri trebuie să urmăm paşii de mai jos, pentru
a afişa etichetele pe legătura de asociere corespunzătoare.
1 Facem click-dreapta pe legătura dintre Consortium şi ATM, apoi alegem Labels >
Both End Multiplicities. Meniul pop-up se închide şi apar etichetele pentru legătura.
2. Face click-dreapta pe micul romb din partea superioara a legăturii de agregare (în
apropierea elementului ATM ) şi alegem Set Multiplicity.
Observaţie: Dacă avem dificultăţi în a face să apară meniul pop-up corect, lungim
săgeata de agregare mutând elementul Consortium mai departe de elementul ATM.
2 Selectăm 1..*, observăm că porţiunea inferioară a legăturii este etichetata 1 după cum
apare in figura următore.
3 Executăm aceeaşi procedură şi setăm multiplicitatea pentru legătura de asociere între
CashierStation şi Branch după cum apare în figura următoare.

72
 5.4. Adăugarea generalizării şi a moştenirii
Generalizarea este relaţia dintre o clasă şi una sau mai multe versiuni extinse ale
acelei clase. Clasa care va fi extinsă se numeşte superclasă, iar fiecare versiune extinsă va
fi numită subclasă.
Atributele şi metodele din superclasă pot fi utilizate în subclase şi astfel, fiecare
subclasă se spune că moşteneşte toate facilităţile superclasei. Putem organiza clasele
folosind moştenirea astfel încât acestea să aibă o structură comună. O legătură de
generalizare semnifica faptul că o clasă poate moşteni o mulţime de atribute şi metode de la
clasa părinte.
1 Din secţiunea Basic a Modeling Palette, selectăm pictograma Generalization
2. Facem click în interiorul elementului clasă ATM şi apoi click pe elementul clasă
EntryStation. Va apărea fereastra de dialog Select Methods to Redefine.
3. Bifăm căsuţa de lângă nodul ATM pentru a selecta toate metodele şi apăsăm OK.
Metodele selectate sunt adăugate elementului clasa ATM şi apare o legătură de
generalizare între cele 2 clase.
4. Desenăm încă o legătură de generalizare apăsând întâi pe CashierStationş şi apoi pe
EntryStation.
5. În fereastra de dialog Select methods to Redefine, bifăm căsuţa de lângă nodul
CashierStation pentru a selecta toate metodele şi apoi apăsăm OK.
6. Facem click-dreapta oriunde în editorul de diagrame pentru a deselecta pictograma
Generalization.
7. Diagrama finala ar trebui să arate ca în figura următoare:

73
 Concluzii
Acest material va învăţat să creaţi o diagramă de clase pentru o aplicaţie bancară
simplă. S-a învăţat cum să realizăm următoarele lucruri: crearea unei diagrame de clase,
utilizarea pictogramelor din Pallete pentru a adăuga elemente în diagrama, adăugarea şi
definirea atributelor şi metodelor pentru elementele de tip clasă, descrierea legăturilor şi
asocierilor între elementele clasă.

74
 Exemplu de diagrama UML de clase
Se reiau paşii anteriori pentru a crea următoarea diagrama UML de clase:

Atenţie: La final este de dorit să ştergem proiectele create (click dreapta pe nodul
proiectului în fereastra Projects, selectaţi Delete .

2. Crearea diagramelor UML de activităţi în NetBeans IDE 6

Aici se vor fi acoperite următoarele probleme:
- Crearea diagramelor UML de activităţi (organigrama) în NetBeans 6
- Studiu de caz complex pentru documentarea unui proiect folosind UML în
NetBeans 6
- Alegerea temelor de documentare – noi detalii
- Cerinţele pentru proiect – o nouă categorie adăugată
Atenţie: La început ştergem mai întâi toate proiectele existente (click dreapta pe nodul
proiectului în fereastra Projects, selectaţi Delete şi confirmăm că dorim să fie
şterse sursele). La final ştergem proiectele create.

1. Crearea diagramelor UML de activităţi (organigrame)

În continuare vom învăţa cum să folosim funcţiile UML ale IDE pentru a crea
diagrame UML de activităţi.
Diagrama UML de activităţi este o formă de organigrama care permite reprezentarea

75
activităţilor oricărui sistem şi a fluxului de date şi/sau de decizii între activităţi.
Diagrama UML de activităţi este o forma de organigrama care poate fi utilizata
pentru:
- Descrierea activităţilor oricărui sistem şi a fluxurilor de date şi/sau decizii între
activităţi.
- O vedere de ansamblu a proceselor aplicaţiei (business process).
- Descrierea activităţilor ce apar în interiorul unui caz de utilizare Ilustrarea
diferitelor tipuri de activităţi utilizând diferite simboluri şi ilustrarea firelor paralele
de execuţie .

1.1. Crearea unui proiect UML independent de platforma

1 Pentru a crea un proiect UML, selectăm File> New Project şi apoi facem
următoarele: Sub Categories, selectăm UML. Sub Projects, selectăm Platform-Independent
Model. Facem Click pe Next.
2 În câmpul Project Name completăm ActivityDiagProj.
3 Pentru câmpul Project Location, click Browse şi navigăm la orice director de
pe computer. Click Open şi completăm ActivityDiagTut.
4 Facem Click pe Finish. IDE-ul creează proiectului UML şi apare caseta de
dialog Create New Diagram.
5 Facem Click pe Cancel. IDE-ul va face următoarele. Creează un proiect de
modelare Platform-Independent gol. Afişează pictograma proiectului în fereastra Project .

1.2. Crearea unui pachet pentru diagrama de activităţi

1 Pentru a crea un pachet pentru diagrama de activităţi, click-dreapta pe nodul Model şi

selectaţi New > Package din meniul pop-up.
2 În câmpul Name completăm numele pachetului: ActDiagPkg. Acceptăm valoarea
implicită în câmpul Namespace .
3 Bifăm caseta Create Scoped Diagram în câmpul Diagram Name completăm numele
diagramei: actDiagram.
4 Din lista Diagram Type selectăm Activity Diagram şi apăsăm Finish. IDE-ul va face
următoarele: Creează un nod pachet sub nodul Model având numele ales anterior. Creează un
nod diagrama sub nodul pachet. Afişează o noua diagramă în editorul de diagrame (diagrama
e goală în acest moment). Deschide (Modeling) Pallete şi afişează pictogramele folosite
pentru a construi diagrame de activităţi.
IDE-ul va arăta astfel:

76
 1.3. Plasarea părtiţiilor
IDE-ul permite adăugarea unor partiţii (coridoare, swimlanes) în diagrama de
activităţi, acestea divizând pe verticală diagrama pentru a putea reprezenta activităţile
efectuate în paralel.
1 Din secţiunea Data a (Modeling) Pallete selectăm pictograma Partition .
2 Click în editorul diagramelor pentru a plasa elementul Partition în diagrama. Un
element Partition fără nume este plasat în editorul diagramelor .
3 Deselectăm pictograma Partition prin click-dreapta în interiorul editorului
diagramelor .
4 Lărgim dreptunghiul elementului către stânga. Cu elementul Partition selectat, click-
dreapta şi selectăm Partitions > Add Partition Column to the Right din meniul pop-up.
5 Lărgim dreptunghiul elementului către dreapta şi in jos.
6 Denumim partiţia prin dublu click pe cuvântul Unnamed aflat central deasupra şi
înlocuirea lui cu Bank, apoi apăsăm Enter.
7 Denumim coloana din stânga a partiţiei prin dublu click pe cuvântul Unnamed aflat
în stânga şi înlocuirea lui cu Bank Lobby.
8 Denumim coloana din dreapta Teller.

Diagrama va arăta astfel:

77
 1.4. Adăugarea elementelor de tip nod

Această secţiune conţine urătoarele proceduri:

1.4.1. Adăugarea unui grup de activităţi

1 Din secţiunea Basic a Pallete selectăm pictograma Activity Group
2 Facem click în subpartiţia Bank Lobby pentru a plasa elementul Activity Group în
subpartiţia din stânga.
3 Deselectăm pictograma Activity Group.
4 Redenumim elementul Activity Group cu dublu-click pe cuvântul Unnamed şi
înlocuirea lui cu Customer, apoi apăsăm Enter.
5 Selectăm elementul Activity Group adăugat, apoi redimensionăm pentru a ocupa
aproape toata subpartiţia din stânga.

1.4.2. Adăugarea unei invocări

1 Din secţiunea Basic a Pallete selectăm pictograma Invocation.
2 Facem click în elementul Activity Group Customer din subpartiţia Bank Lobby
pentru a plasa 2 elemente Invocation unul sub altul.
3 Deselectăm pictograma Invocation.
4 Selectăm elementele invocare, apoi redimensionaţi-le pentru a se potrivi cât mai bine
în elementul Activity Group Customer ca mai jos.
5 Denumim nodul invocare de deasupra prin dublu-click pe el şi editarea textului
Approach Teller Counter, apoi apăsăm Enter.
6 Denumim nodul invocare de desupt Enter Transaction.
7 Plasăm încă 6 elemente invocare în interiorul subpartiţiei Teller şi denumiţi-
le astfel Receive Transaction Request Search Customer Info Send to Customer
Service Process Transaction Update Account Info Notify Customer
Diagrama ar trebui să arate astfel:

78
79
 1.4.3. Adăugarea unui element nod iniţial
1 Din secţiunea Basic a Pallete selectăm pictograma Initial Node.
2 Facem click în subpartiţia Bank Lobby în stânga elementului Approach Teller
Counter.
3 Deselectăm pictograma.

1.4.4. Adăugarea unui element bifurcaţie orizontală

1 Din secţiunea Control a Pallete selectăm pictograma Horizontal Fork.
2 Plasăm bara reprezentând elementul Horizontal Fork deasupra elementelor invocare
Update Account Info şi Notify Customer.
3 Deselectăm pictograma.
4 Lungim bara pentru a acoperi lăţimea ambelor elemente invocare.
5 Plasăm un alt element Horizontal Fork sub elementele invocare Update Account
Info şi Notify Customer.
6 Lungim bara pentru a acoperi lăţimea ambelor elemente invocare.

1.4.5. Adăugarea unui element nod activitate finală şi a unui nod decizie

1 Plasăm elementul Final Node sub elementul Horizontal Fork aflat mai jos.
2 Deselectăm pictograma Activity Final Node.
3 Din secţiunea Control a Pallete selectăm pictograma Decisio.n
4 Plasm elementul Decision între elementele Send to Customer Service, Process
Transaction şi Search Customer Info.
5 Deselectăm pictograma
Diagrama ar trebui să arate astfel:

80
 1.5. Adăugarea elementelor de tip legături (tranziţie şi dependenţă)
Această secţiune conţine următoarele proceduri:

1.5.1. Adăugarea unui element tranziţie între activităţi

1 Din secţiunea Basic a Pallete selectăm pictograma Activity Edge . Vom folosi
elementul Activity Edge pentru a conecta elementul Initial Node cu un element Invocation.
2 Facem click în elementul Initial Node şi din nou click pe elementul Invocation cu
numele Approach Teller Counter. O legătură Activity Edge uneşte acum cele două
elemente. Etichetele pentru legăturile Activity Edge sunt ascunse, dar trebuie să fie afişate.
3 Deselectăm pictograma Activity Edge.
4 Selectăm elementul Activity Edge şi click-dreapta pe el.
5 Selectăm din meniul pop-up Labels > Show Name. Legătura este acum etichetată cu
Unnamed.
6 Pentru a denumi legătura scriem Initiate Cash Withdrawal şi apăsăm Enter.

1.5.2. Adăugarea mai multor elemente tranziţie între activităţi

1 Din secţiunea Basic a Pallete selectăm pictograma Activity Edge.
2 Adăugăm următoarele legături:
De la Approach Teller Counter la Enter Transaction.
De la Enter Transaction la Receive Transaction Request.
De la Receive Transaction Request la Search Customer Info.
De la Search Customer Info la nodul Decision.
De la nodul Decision la Send to Customer Service.
De la nodul Decision la Process Transaction.
De la Process Transaction la bara Horizontal Fork de deasupra.
De la bara Horizontal Fork de deasupra la Update Account Info.
De la bara Horizontal Fork de deasupra la Notify Customer.
De la Notify Customer la bara Horizontal Fork de desupt.
De la Update Account Info la bara Horizontal Fork de desupt.
De la Lower Horizontal Fork la elementul Final State.
3 Deselectăm pictograma Activity Edge.

1.6. Lucrul cu condiţii şi grupuri

Aceasta secţiune conţine următoarele proceduri:

1.6.1. Adăugarea condiţiilor logice la tranziţiile între activităţi
1 În editorul diagramelor click-dreapta pe elementul Activity Edge aflat între nodul
Decision şi elementul Send to Customer Service.
2 Selectăm din meniul pop-up Labels > Show Guard Condition.
3 În interiorul parantezelor drepte ale condiţiei logice scriem No Customer Info şi
apasăm Enter.
4 Repetăm paşii 1 si 2 pentru elementul Activity Edge aflat între nodul Decision şi
elementul Process Transaction.
5. Scriem [ Customer Info ] pe post de condiţia logică.

1.6.2. Selectarea şi modificarea proprietăţi GroupKind

IDE-ul reprezintă buclele din fluxurile de activităţi ca elemente Activity Group.
Există 3 tipuri de elemente Activity Group diferite: Iteration, Structured şi Interruptible.

81
1 În editorul diagramelor click-dreapta pe elementul Activity Group denumit
Customer.
2 În fereastra Properties pe linia proprietăţii GroupKind facem click pe săgeată în jos.
3 Selectăm Structured din lista şi elementul Activity Group denumit Customer este
reetichetat pe diagrama ca grup structurat.

Diagrama finală ar trebui să arate astfel:

82
 3. EXEMPLE DE DIAGRAME UML PENTRU DIFERITE APLICAŢII

Exemplul 1: Problema Liftului

Enunţ.
Se cere realizarea unui produs soft care să controleze n lifturi într-o clădire cu m etaje.
Mişcarea lifturilor între etaje respectă următoarele reguli (restricţii):
1. Fiecare lift are m butoane, câte unul pentru fiecare etaj (nivel). La apăsare,
butoanele se luminează şi provoacă deplasarea liftului la etajul corespunzător.
Butonul corespunzător unui etaj se stinge când liftul a ajuns (a oprit) la etajul
respectiv.
2. Fiecare etaj, cu excepţia primului şi a ultimului, are două butoane: Sus (cere un
lift care urcă) şi Jos (cere un lift care coboară). La apăsare, butoanele se luminează
şi provoacă deplasarea liftului la etajul respectiv. Butoanele se sting când liftul
vizitează etajul curent şi se mişcă în direcţia corespunzătoare.
3. Când nu există nici o cerere, liftul rămâne la etajul curent cu uşile închise.

1. Modelarea cazurilor de utilizare

 Modelul cazurilor de utilizare (Use Case Model) descrie funcţionalitatea propusă a
unui sistem.
 Cazul de utilizare reprezintă o unitate discretă de interacţiune dintre un utilizator (om
sau maşină), actor şi sistem.
 Cazul de utilizare reprezintă o singură acţiune: logare în sistem, înregistrare în sistem,
crearea unei comenzi, etc..
 Fiecare caz de utilizare are o descriere a funcţionalităţii ce va fi încorporată în noul
sistem.
 Descrierea cuprinde următoarele:
 Comentarii generale şi note ce descriu cazul de utilizare.
 Cerinţe: acţiunile pe care cazul de utilizare le permite utilizatorilor (<abilitatea de
a crea o comandă>, <abilitatea de a modifica o comandă>, etc..
 Constrângeri: Reguli privitoare la ce se poate face şi ce nu. Includ:
 Pre-condiţii: predicate cu valoarea true înainte de începerea execuţiei cazului
de utilizare (<creare comandă> trebuie să preceadă <modificare comandă> .
 Post-condiţii: predicate cu valoarea true după terminarea execuţiei cazului de
utilizare (<comanda este modificată şi consistentă>).
 Invarianţi: predicate ce au întotdeauna valoarea true (<comanda conţine
întotdeauna codul clientului>).
 Scenarii: Descrieri secvenţiale ale paşilor de urmat pentru execuţia cazului de
utilizare. Se pot include mai multe scenarii, pentru a surprinde şi cazurile de
excepţie şi variantele alternative de execuţie:
 Scenariu normal.
 Scenariu de excepţie (Alternative).
 Diagrame de scenarii: diagrame de secvenţă pentru ilustrarea fluxului de lucru,
similare cu scenariile, însă grafice.
 Atribute adiţionale: faza de implementare, numărul de versiune, etc.
 Actori: actorul este un utilizator al sistemului. Actorul foloseşte cazul de utilizare
pentru a executa o anumită bucată de lucru care are relevanţă pentru activitatea sa.
Mulţimea cazurilor de utilizare la care actorul are acces defineşte rolul său general în
sistem şi domeniul acţiunilor sale.

83
  Între cazurile de utilizare există relaţii de includere şi extindere:
 Un caz de utilizare poate include funcţionalitatea unui alt caz de utilizare. Cazul
de utilizare inclus va fi apelat ori de câte ori se execută cazul ce-l include.
Exemplu: (<listează comenzi>) listarea comenzilor din care să se selecteze
comanda ce se modifică; cazul <listează comenzi> se poate include în <modifică
comandă>.
 Un caz de utilizare se poate include într-unul sau mai multe alte cazuri de
utilizare; aceasta ajută la reducerea duplicării funcţionalităţii prin gruparea
comportamentului comun în cazuri de utilizare reutilizabile.
 Un caz de utilizare poate extinde comportamentul altuia - de regulă în
circumstanţe excepţionale. De exemplu, înainte de modificarea unui anumit tip de
comandă, utilizatorul ar putea avea nevoie de aprobarea unui şef; prin urmare,
cazul de utilizare <obţine aprobare> ar putea extinde cazul de utilizare obişnuit
<modifică comandă>.

Diagrama de cazuri de utilizare - forma generală

caz de utilizare
extins

legături
ă caz de utilizare

Actor caz de utilizare

inclus

Exemplu (Schach): Problema liftului

Lift

apasă un buton din lift

apasă un buton de la un etaj

Utilizator

Diagrama cazurilor de utilizare pentru problema liftului

Scenariul normal (prima iteraţie):

1. Utilizatorul A apasă butonul Sus la etajul 3. El doreşte să ajungă la etajul 7.

2. Butonul Sus de la etajul 3 se luminează.
3. La etajul 3 se opreşte un lift. În lift se găseşte utilizatorul B, care a intrat în lift la
etajul I şi a apăsat butonul pentru etajul 9.
4. Butonul Sus de la etajul 3 se stinge.
5. Uşile liftului se deschid.
6. Porneşte cronometrul.
Utilizatorul A intră în lift.
7. Utilizatorul A apasă butonul din lift pentru etajul 7.
8. Butonul pentru etajul 7 din lift se luminează.

84
9. Uşile liftului se închid după ce s-a scurs un timp.
10. Liftul urcă la etajul 7.
11. Butonul din lift pentru etajul 7 se stinge.
12. Uşile liftului se deschid pentru ca utilizatorul A să poată ieşi din lift.
13. Porneşte cronometrul.
Utilizatorul A iese în lift.
14. Uşile liftului se închid după ce s-a scurs un timp.
15. Liftul urcă la etajul 9 cu utilizatorul B în el.

Scenariu de excepţie:

1. Utilizatorul A apasă butonul Sus la etajul 3. El doreşte să ajungă la etajul 1.

2. Butonul Sus de la etajul 3 se luminează.
3. La etajul 3 se opreşte un lift. În lift se găseşte utilizatorul B, care a intrat în lift la
etajul I şi a apăsat butonul pentru etajul 9.
4. Butonul Sus de la etajul 3 se stinge.
5. Uşile liftului se deschid.
6. Porneşte cronometrul.
Utilizatorul A intră în lift.
7. Utilizatorul A apasă butonul din lift pentru etajul 1.
8. Butonul din lift pentru etajul 1 se luminează.
9. Uşile liftului se închid după ce s-a scurs un timp.
10. Liftul urcă la etajul 9.
11. Butonul din lift pentru etajul 9 se stinge.
12. Uşile liftului se deschid pentru ca utilizatorul B să poată ieşi din lift.
13. Porneşte cronometrul.
Utilizatorul B iese în lift.
14. Uşile liftului se închid după ce s-a scurs un timp.
15. Liftul coboară la etajul 1 cu utilizatorul A în el.

2. Modelarea claselor
 Clasa este o construcţie UML standard folosită pentru a detalia planul de construcţie a
obiectelor la execuţie. Clasa este o specificare, iar obiectul este instanţă a clasei.
Clasele pot moşteni de la alte clase (ele moştenesc de la părinţi tot comportamentul şi
toată starea acestora şi adaugă stare şi comportament specific), pot avea ca atribute
alte clase, pot delega responsabilităţile lor la alte clase şi pot implementa interfeţe
abstracte.
 Modelul claselor (class model) stă la baza dezvoltării OO. El exprimă atât starea
persistentă a sistemului, cât şi comportamentul acestuia. Clasa încapsulează stare
(atribute) şi oferă servicii pentru manipularea stării (comportament). Practicile de
proiectare OO recomandă ca accesul la atributele claselor să se facă numai prin
intermediul metodelor. Ascunderea datelor şi expunerea serviciilor asigură că
actualizările atributelor se fac numai într-o manieră controlată şi cu verificarea unor
reguli specifice.
 O clasă se reprezintă astfel:
nume clasă nume clasă
atribute
metode
 numele clasei este un substantiv la singular, scris cu bold;

85
  zona de atribute conţine specificaţii de forma Vnume atribut: tip de date;
 zona de metode conţine specificaţii de forma Vnume metodă(parametri)[: tip
rezultat];
 V indică vizibilitatea:
 + public;
 - private;
 # protected.
 Relaţiile dintre clase:
 generalizare (ISA) ; Subclasă Superclasă
 asociere;
 navigare; Sursă Ţintă
 agregare; Întreg Parte
 compunere. Întreg Parte

 Generalizarea este un sinonim pentru moştenire. Moştenirea este definită în

documentele UML astfel: "Moştenirea este o relaţie taxonomică dintre o superclasă şi
subclasele sale. Frecvent, ea este numită generalizare sau specializare, depinzând de
punctul de plecare: de la subclasă la superclasă <superclasa este o generalizare a
subclasei> sau de la superclasă la subclasă <subclasa este o specializare a
superclasei>.
 Asocierile reprezintă relaţii structurale dintre obiecte din clase diferite, reprezentând
informaţie care trebuie păstrată o perioadă de timp; ele sunt navigabile în ambele
direcţii. În timpul analizei ele sunt de obicei rafinate, adăugându-se agregare sau
semantică de referire, identificându-se diferitele multiplicităţi şi făcându-se rolurile
explicite.
 Asocierile navigabile impun o implementare simplă trimiterii de mesaje de la un
obiect Sursă la un obiect Ţintă. Pentru aceasta, obiectul Sursă trebuie să cunoască
identitatea obiectului Ţintă. O modalitate de obţinere a identităţii obiectului Ţintă
este traversarea de-a lungul unei asocieri.
 Agregarea înseamnă că instanţele clasei Parte sunt înglobate într-o instanţă a clasei
Întreg. Prin urmare, un obiect din clasa Întreg este obiect compus. De regulă,
obiectele Parte şi obiectul Întreg au existenţa separată - de regulă la crearea
obiectului Întreg obiectele Parte sunt deja create, iar distrugerea obiectului Întreg nu
provoacă şi distrugerea obiectelor Parte.
 Compunerea este o formă specială de agregare, în care existenţa obiectelor Parte
depinde de obiectul Întreg. Obiectele Parte se creează când se creează obiectul
Întreg şi se distrug când acesta este distrus.

Paşi în modelarea claselor

 Identificarea claselor.
 Identificarea atributelor.
 Identificarea relaţiilor.
 Reprezentarea claselor şi relaţiilor folosind o diagramă de clase (E-R).

Identificarea claselor, atributelor şi relaţiilor. Abordări:

 se deduc din cazurile de utilizare şi scenariile aferente acestora:

86
  se studiază toate scenariile, atât cele normale cât şi cele de excepţie, şi se identifică
componentele care joacă un rol în cazurile de utilizare.
Din scenariile de mai sus, clasele candidate sunt butoanele liftului, butoanele etajelor,
lifturile, uşile şi cronometrele.
Posibile dezavantaje: când sunt multe scenarii, din care rezultă un număr mare de
clase potenţiale. Un dezvoltator neexperimentat ar fi tentat să lucreze cu un număr
mare de clase candidate;
 se folosesc card-urile CRC:
 dacă dezvoltătorii sunt familiarizaţi cu domeniul problemei;
 se extrag substantivele, urmând un procedeu în trei paşi:
1. Definirea concisă a problemei: se defineşte sistemul cât mai concis posibil, de
preferinţă într-o singură propoziţie
Butoanele din lifturi şi de la fiecare etaj controlează mişcarea a n lifturi într-o clădire cu m
etaje.
2. Strategie informală. Trebuie luate în considerare restricţiile (regulile, constrângerile),
aşa cum au fost ele precizate în enunţ. Strategia informală, construită pe baza lor, se poate
acum exprima textual, de preferat într-un singur paragraf.
Butoanele din lifturi şi de la fiecare etaj controlează mişcarea a n lifturi într-o clădire cu m
etaje. Butoanele se luminează la apăsare când se cere ca liftul să oprească la un anumit
etaj; iluminarea se stinge când cererea a fost satisfăcută. Când un lift n-are nici o cerere,
el rămâne la etajul curent cu uşile închise.
3. Formalizarea strategiei. În strategia informală se identifică substantivele, din
care se elimină cele ce nu aparţin domeniului problemei. Substantivele rămase sunt
candidaţi pentru clasele iniţiale. Strategia informală este reprodusă mai jos, cu
substantivele identificate marcate cu bold.
Butoanele din lifturi şi de la fiecare etaj controlează mişcarea a n lifturi într-o clădire
cu m etaje. Butoanele se luminează la apăsare când se cere ca liftul să oprească la un
anumit etaj; iluminarea se stinge când cererea a fost satisfăcută. Când un lift n-are nici
o cerere, el rămâne la etajul curent cu uşile închise.
S-au identificat opt substantive: buton, lift, etaj, mişcare, clădire, iluminare, cerere şi
uşă. Trei dintre ele - etaj, clădire şi uşă - nu aparţin domeniului problemei, deci se pot
ignora. Trei dintre cele rămase - mişcare, iluminare şi cerere - sunt substantive
abstracte. Ele indică idei sau cantităţi care nu au existenţă fizică (de regulă, ele vor fi
atribute ale altor clase; de exemplu iluminare este atribut al lui buton). Rămân două
substantive, deci două clase candidat: Lift şi Buton. Regula UML este ca numele claselor
să fie scris cu bold, iar prima literă să fie majusculă.Diagrama de clase este prezentată
mai jos. Clasa Buton are atributul boolean iluminat pentru a modela evenimentele 2, 4, 8
şi 11 din scenariile prezentate. Problema specifică două tipuri de butoane, deci se vor
defini două subclase ale clasei Buton, ButonLift şi ButonEtaj. Fiecare ButonLift şi
ButonEtaj comunică cu Lift. Ultima clasă are atributul boolean uşi deschise, pentru a
modela evenimentele 5, 9, 12 şi 14 din scenarii.
Figură. Prima iteraţie a diagramei de clase

87
 Buton
iluminat: Boolean

ButonLift ButonEtaj

m 2m-2
comunică comunică
cu 1 n cu
Lift
uşi deschise:
Boolean
Din păcate, am început cu stângul. Într-un lift real, butoanele nu comunică cu lifturile,
ci se foloseşte un controler de lift. Acesta decide care lift va răspunde la o cerere anume de la
un etaj. Desigur, enunţul problemei nu face nici o referire la controler, deci această clasă n-a
avut cum să fie identificată printre substantivele din enunţ.
Un al doilea motiv pentru care prima iteraţie a diagramei nu este adecvată este
prezenţa unei asocieri m:n între clasele Lift şi ButonEtaj. Fiecare lift comunică cu cele 2m-2
butoane de la etaje (cîte 2 la etajele 1 - m-1 şi câte unul la parter şi la ultimul etaj). Fiecare
buton de etaj poate comanda oricare dintre cele n lifturi.
Dacă la diagrama de clase anterioară se adaugă clasa ControlerLift, se obţine
diagrama de mai jos.
Buton
iluminat: Boolean

ButonLift ButonEtaj

mn 2m-2
controlează controlează
1 ControlerLift 1

1
controlează
n
Lift
uşi deschise:
Boolean

Figură. A doua iteraţie a diagramei de clase

3. Modelarea dinamică
 Scop: producerea unei diagrame de stări, o descriere a sistemului similară cu o maşină
cu stări finite, pentru fiecare clasă

88
 [buton apăsat, [nici o cerere,
buton aprins] uşile închise]

Bucla de evenimente a liftului

[buton apăsat, [liftul se mişcă [liftul oprit, [liftul oprit, nu

buton stins] în direcţia d, există există cereri
Prelucrează urmează etajul cereri de de
cererea f] prelucrat] prelucrat]
Treci în
Aprinde buton
aşteptare
Actualizează cereri Închide uşile
liftului după
timeout
Stabileşte dacă s-a cerut oprire Închide uşile
Verifică cereri liftului
Închide uşile liftului
după timeout
[utilizatorul a
[nici o cerut oprire la [buton [buton
cerere de la etajul f] etaj etaj
etajul f]
Continuă Oprire la etaj aprins] stins]
Stinge buton
deplasarea
Deplasează liftul un etaj Opreşte liftul etaj
Stinge butonul
în direcţia d Deschide uşile şi etajului
porneşte
cronometrul
Actualizează
cereri
[buton [buton Prelucrează cererea
lift lift urm.
aprins] Deplasează liftul un etaj în
Stinge buton stins] direcţia cererii următoare
lift
Stinge butonul
liftului

Metoda
 se pleacă de la scenarii
 evenimentele specifice (particulare) se generalizează
1. Utilizatorul A apasă butonul Sus la etajul 3
S-a generalizat la un buton arbitrar de la un etaj arbitrar. Sunt două alternative
a) butonul este deja aprins - nu se petrece nimic
b) butonul nu este aprins - se trece în starea Prelucrează cererea, când se execută
două lucruri (butonul se aprinde - rezultă din pasul 2, apoi se actualizează cererile -
apăsarea butonului la un etaj semnifică o cerere de lift)
3. La etajul 3 se opreşte un lift
S-a generalizat la un lift arbitrar ce se deplasează între etaje. Guardul este
[liftul se mişcă în direcţia d, urmează etajul f] iar starea este Verifică dacă s-a
cerut oprire. Există două alternative:
a) nu s-a cerut oprire (guardul [nici o cerere de la etajul f]) - liftul trece în starea
Continuă deplasarea

89
 b) s-a cerut oprire la etajul f (guardul [utilizatorul a cerut oprire la etajul f]). Liftul
intră în starea Opreşte la etaj. Din evenimentul 3 al scenariului rezultă oprirea
liftului, iar din evenimentele 5 şi 6 rezultă deschiderea uşilor şi pornirea
cronometrului. Este necesară, de asemenea, actualizarea cererilor.
4. Butonul Sus de la etajul 3 se stinge.
După ce liftul a oprit la etajul f, butonul corespunzător etajului se stinge (dacă a fost
aprins). Aceasta este modelată de starea Stinge buton lift.
9. Uşile liftului se închid după ce s-a scurs un timp.
S-a generalizat la starea Închide uşile liftului.
10. Liftul urcă la etajul 7.
S-a generalizat la starea Prelucrează cererea următoare.
Starea Treci în aşteptare rezultă din generalizarea unui eveniment dintr-un alt
scenariu, când utilizatorul iese din lift şi în lift nu rămâne nici un buton aprins.

Diagramele de stare pentru celelalte clase - exerciţiu.

4. Revizuirea modelelor în OOA

Instrument recomandat: card-urile CRC (Class-Responsibility-Collaboration):

 se completează pentru fiecare dintre clasele din diagrama de clase;
 se folosesc informaţiile din diagrama de clase şi diagrama de stări.

CLASS
ControlerLift
RESPONSIBILITY
1. Aprinde un buton din lift
2. Stinge un buton din lift
3. Aprinde un buton de etaj
4. Stinge un buton de etaj
5. Mută liftul un etaj în sus
6. Mută liftul un etaj în jos
7. Deschide uşile liftului şi porneşte
cronometrul
8. Închide uşile liftului după timeout
9. Verifică cererile
10. Actualizează cererile
COLLABORATION
1. Clasa ButonLift
2. Clasa ButonEtaj
3. Clasa Lift

Prima iteraţie a card-ului CRC pentru clasa ControlerLift:

 analiza CRC:
1. nu se respectă paradigma OO:
 obiectele clasei ButonLift ştiu singure să se aprindă şi să se stingă;
 obiectele clasei ButonEtaj ştiu singure să se aprindă şi să se stingă;
 principiul ascunderii informaţiei: ControlerLift nu vede elementele interne ale
claselor ButonLift şi ButonEtaj;

90
  responsabilitate corectă: transmitere de mesaje (iteraţia nr. 2 a card-ului CRC
pentru clasa ControlerLift.
2. clasa este aglomerată:
 responsabilitatea: 7. Deschide uşile liftului şi porneşte cronometrul:
 uşile liftului au stare (deschise, închise);
 o componentă care are stare este modelată de regulă ca o clasă;
 rezultă că este nevoie de o nouă clasă, UşăLift;
 iteraţia nr. 3 a modelului de clase;
 responsabilitatea este descompusă în două responsabilităţi.
3. responsabilităţile Verifică cererile şi Actualizează cererişe ale clasei ControlerLift
necesită adăugarea atributului cereri la clasa ControlerLift.

CLASS
ControlerLift
RESPONSIBILITY
1. Trimite mesaj la ButonLift să aprindă butonul
2. Trimite mesaj la ButonLift să stingă butonul
3. Trimite mesaj la ButonEtaj să aprindă butonul
4. Trimite mesaj la ButonEtaj să stingă butonul
5. Trimite mesaj la Lift să mute liftul un etaj în sus
6. Trimite mesaj la Lift să mute liftul un etaj în jos
7. Trimite mesaj la UşăLift să se deschidă
8. Porneşte cronometrul
9. Trimite mesaj la UşăLift să se închidă după
timeout
10. Verifică cererile
11. Actualizează cererile
COLLABORATION
1. Subclasa ButonLift
2. Subclasa ButonEtaj
3. Clasa UşăLift
4. Clasa Lift
A doua iteraţie a card-ului CRC pentru clasa ControlerLift

Figură. A treia iteraţie a diagramei de clase

91
 Buton
iluminat: Boolean

ButonLift ButonEtaj

mn 2m-2
controlează controlează
1 UşăLift
1 ControlerLift 1 n uşi deschise:
cereri: tipCerere controlează
Boolean
1
controlează
n
Lift

 Diagramele de cazuri de utilizare şi diagramele de stare trebuie reexaminate pentru a

vedea dacă nu trebuie modificate:
 diagrama de cazuri de utilizare este bună;
 diagramele de stare trebuie modificate:
 acţiunile trebuie să semnifice transmiteri de mesaje, după cum ilustrează a doua
iteraţie a CRC;
 trebuie creată o diagramă de clase nouă pentru clasa UşăLift;
 scenariile trebuie actualizate;
 exemplu: iteraţia a doua a scenariului normal.

Scenariul normal (a doua iteraţie):

1. Utilizatorul A apasă butonul Sus la etajul 3 pentru a cere un lift. El doreşte să

ajungă la etajul 7.
2. Butonul Sus de la etajul 3 informează controlerul liftului că a fost apăsat
3. Controlerul liftului trimite un mesaj butonului Sus de la etajul 3 să se aprindă.
4. Controlerul liftului trimite o serie de mesaje la lift să se deplaseze în sus spre
etajul 3. În lift se găseşte utilizatorul B, care a intrat în lift la etajul I şi a apăsat
butonul pentru etajul 9.
5. Controlerul liftului trimite un mesaj butonului Sus de la etajul 3 să se stingă.
6. Controlerul liftului trimite un mesaj la uşile liftului să se deschidă.
7. Controlerul liftului porneşte cronometrul.
Utilizatorul A intră în lift.
8. Utilizatorul A apasă butonul din lift pentru etajul 7.
9. Butonul pentru etajul 7 din lift informează controlerul liftului că a fost apăsat.
10. Controlerul liftului trimite un mesaj butonului pentru etajul 7 din lift să se
aprindă.
11. Controlerul liftului trimite un mesaj la uşile liftului să se închidă după un timp
(timeout).
12. Controlerul liftului trimite o serie de mesaje la lift să se deplaseze în sus spre
etajul 7.
13. Controlerul liftului trimite un mesaj butonului pentru etajul 7 din lift să se stingă.

92
14. Controlerul liftului trimite un mesaj la uşile liftului să se deschidă pentru ca
utilizatorul A să poată ieşi din lift.
15. Controlerul liftului porneşte cronometrul.
Utilizatorul A iese în lift.
16. Controlerul liftului trimite un mesaj la uşile liftului să se închidă după un timp
(timeout).
17. Controlerul liftului trimite o serie de mesaje la lift să se deplaseze în sus spre
etajul 9 cu utilizatorul B în el.

Un alt fel de rezolvare a problemei Liftului.

O firmă doreşte realizarea unui program software care să asigure controlul lifturilor
într-o clădire cu m(10) etaje şi mai multe scări. Acest program va trebui să asigure logica
deplasării lifturilor între etaje respectând următoarele constrângeri:
Fiecare lift are un set de m butoane, câte unul pentru etaj. Acestea se aprind în
momentul care sunt apăsate şi determina liftul să se deplaseze la etajul corespunzător.
Butonul se stinge în momentul în care liftul ajunge la etajul corespunzător.
Fiecare etaj, cu excepţia primului şi ultimului are două butoane, unul pentru a chema
liftul pentru a urca şi unul pentru a chema liftul pentru a coborî. Aceste butoane se aprind în
momentul în care sunt apăsate. Butoanele se sting când liftul ajunge la etaj şi apoi liftul se
deplasează în direcţia dorită.
Când un lift nu are nici o cerere, rămâne la etajul curent cu uşile închise.

A. Unified Modeling Language

UML este un limbaj de modelare utilizat pentru reprezentarea şi specificarea
semantici proceselor. Astfel, în continuare vom realiza analiza problemei noastre utilizând
următoarele tipuri de diagrame:

ANALIZA MODELULUI CU LIFTUL

1. Diagrama Use Case
Diagrama Use Case:
• oferă o descriere generală a modului în care va fi utilizat sistemul;
• furnizează o privire de ansamblu a funcţionalităţilor ce se doresc a fi oferite de sistem,
în Figura 1 este prezentata diagrama Use Case pentru problema liftului.

93
 Figura 1: Diagrama Use Case pentru Problema Liftului
Din aceasta diagrama use case putem extrage următorul scenariu de funcţionare al
liftului:
Pasagerul apasă butonul de pe etaj .
Sistemul detectează etajul la care a fost apăsat butonul.
Liftul se deplasează la etajul respectiv.
Se deschid uşile .
Pasagerul intra în lift şi apasă un buton din lift corespunzător etajului la care doreşte
să se deplaseze.
Se închid uşile liftului .
Liftul se deplasează la etajul solicitat.
Se deschid uşile liftului.
Pasagerul iese.
Se închid uşile liftului.
În continuare vă mai propune o variantă de Diagramă use case pentru Lift:

Diagrama USE CASE:

Pers oana

Lift

Cheama

Porneste

94
 2. Diagrama de clase
Diagrama de clase arată structura statică a obiectelor, structura lor internă şi relaţiile
dintre acestea. În Figura 2 este prezentată diagrama de clase pentru problema liftului.

Figura 2: Diagrama de Clase pentru Problema Liftului

Vă mai propunem şi o altă variantă a acestei diagrame:

Diagramă de clasă:

Buton

Persoana
(f rom Use Case View)

Lift
(f rom Use Case View)

Cabina Usa Lumina

3. Diagrama de stare
O diagramă de stare arată secvenţa de stări prin care trece un obiect pe parcursul
existentei ca răspuns la stimuli, împreună cu răspunsurile şi acţiunile realizate de acesta, iar
cea de activitate modul de desfăşurare a cestei activităţi, conform figurii următoare:

95
 Diagramă de activitate:

Persoana [Daca este

merge la lift acolo]
Nu

Cheama Intra
liftul

MODELAREA PROBLEMEI LIFTULUI

În faza de modelare se va realiza diagrama de secvenţă, diagrama de colaborare şi
diagrama de obiect.
1. Diagrama de secvenţă
Diagrama de secvenţă prezintă secvenţa de mesaje corespunzătoare sistemului real-
time modelat. În Figura 3 este prezentată diagrama de secvenţă pentru servirea unui buton din
interiorul unui lift.

Figura 3: Diagrama de Secvenţă pentru servirea unui buton din lift

Vă mai prezentăm o variantă a acestei digrame, în următoarea figură:

96
 Diagramă de secvenţă:

: Buton : Cabina : Lumina : Usa

: Persoana : Lift

Cauta()
Chemare()
Pornire()

Semnal()

Deschide()

Inchide()

2. Diagrama de colaborare
Diagrama de colaborare: descrie mulţimea de interacţiuni dintre clase sau tipuri arată
relaţiile dintre obiecte.
În Figura 4 este prezentată diagrama de colaborare pentru servirea unui buton din
interiorul unui lift.

Figura 4: Diagrama de Colaborare pentru servirea unui buton din lift

97
 Vă mai propunem o variantă a acestei diagrame:
Diagramă de colaborare:

1: Cauta()
: Buton

: Persoana

6: Inchide() 2: Chem are()

: Usa : Cabina

5: Deschide() 3: Pornire()
: Lift
4: Sem nal()

:
Lumina

3. Diagrama de obiect
Avem nevoie de o diagramă de obiect, deoarece o persoană în acelaşi timp nu poate fi
decât la un etaj:

Ion: Persoana

(from Use Case View)

Etaj 0: Buton Etaj10: Buton

IMPLEMENTAREA PROBLEMEI LIFTULUI
Aici se au în vedere diagramele de colaborare şi exploatare. În continuare pentru acest
exemplu vă prezentăm doar digrama de exploatare, la celelalte exemple le prezentăm pe
amândouă.
1. Diagramă de exploatare:
Calculator principal ce Mas ina de s em nal
coordoneaza Liftul

98
Exemplul 2: Organizarea unui curs de UML de către o firmă specializată
în acest domeniu
O firmă organizează un curs de UML, vom încerca să scriem o aplicaţie ce va permite
înscrierea la curs prin Internet. Conducătorii ce vor coordona cursul se vor arhiva din când în
când.
Aplicaţia se va organiza astfel:
 candidat;
 conducător;
 organizator;
 arhivă.
Conducătorul anunţă cursul ce-l poate întrerupe sau arhiva cursul. Candidatul trebuie
să vadă cursul, iar dacă vrea se poate înscrie şi va trebui să primească ştirea dacă a fost înscris
Organizatorul poate definitiva un curs sau îl poate şterge.
Avem următoare diagrame în UML:

ANALIZA PROBLEMEI CURSULUI UML

Cu diagramele: use case sau pachet, clase, stare sau activitate:

1. Diagrama Use Case:

Conducator Organizator

Arhiveaza Arhiva

Organizeaza

Intrerupe Defineste

Renunta Sterge

Anunta

<<extend>>

Candidat
<<extend>> <<extend>>
Inscriere
Observare

Modifica oferta Incheiere contract

99
Pachet (Package):

Conducator Organizator

<<System>>
Seminar

Coordonare

Arhivare

Arhiva
Candidat
Observare
Utility

Observaţie: Actorii devin clase obligatorii

2. Digramă de Clase:

Conducator

*
{Denunta} {Organizeaza}
*
Candidat Arhiva Organizator

* *
{Observare} {Sterge}
* * 1
Curs * 1 Firma

Instintare

100
 3. Diagramă de activităţi:

Anunta

Asteptare Observare

[Sunt candidati]

Stergere Finalizare
Inscriere

[este loc?] else

Acceptare Optiuni pentru

inscriere alt curs

Se tine
cursul

Terminare
curs

MODELAREA PROBLEMEI CURSULUI DE UML

Aici se au în vedere digramele: secvenţă, colaborare şi obiect.

1. Digramă de secvenţă:
: Curs

: Organizator : Candidat
Definitivare()

Inscriere()

Instiintare()

101
2. Digramă de colaborare
1: Definitivare()
: Curs

: Organizator

2: Ins criere()
3: Ins tiintare()

: Candidat
3. Digramă de obiecte:

IOAN : Candidat
OR

{Înscriere} {Înscriere}

UML 1 : Curs UML 2 : Curs

IMPLEMENTAREA PROBLEMEI CURSULUI DE UML

Aici se au in vedere diagramele de componente şi exploatare:

1. Diagramă de componente:
Gestionarea
Seminar cursului

Seminar - server

Gestionarea
inscrerii
Inscriere
Web -
browser
Cgi
Seminar -
Gestionarea
online
Cuntinut curs

102
8. Diagrama de exploatare:

Calculat Calc.
Intranet Intranet
-or firma arhiva

Intranet Calac.
mesaje

Exemplul 3: Alegerea disciplinelor opţionale la o facultate

Cerinţele impuse sistemului:
 Secretarul şef preia listele cu cursurile existente din semestrul specificat şi o
disciplină poate fi predat de mai mulţi profesori.
 Fiecare student alege din 4 discipline opţionale 2 discipline.
 Studenţi după alegere, dar înaintea începerii semestrului, se pot înscrie la alte
discipline sau pot elimina altele.
 Profesorii pot afla lista grupelor la care predau, dacă au fost aleşi.
 Sistemul are parolă şi utilizatorii trebuie să-l folosească.

ANALIZA PROBLEMEI
Cu diagramele: use case sau pachet, clase, stare sau activitate:

1. Diagrama de cazuri de utilizare(Use Case Diagram)

Gestionarea listei cu discipline

Secretar sef

Prezentare
Student

Profesor Interogarea listei cu studenti

103
 Pachete:

Persana

Inscrieri Discipline

Pachetele de mai sus conţin următoarele clase:

 Persoana: Utilizator, Secretar sef, Profesor, Student, Verificarea parolei
 Discipline: Gestionarea listei cu discipline, Disciplina, Prezentare
 Inscrieri: Gestionarean inscrisilor

2. Diagrama de clase (Class diagram)

104
 3. Diagrama de stări (State Diagram)

Initializare Deschis
Do / initializare disciplina Entry / admitere student
Student nou Exit / student++

Ştergere

Sters Ştergere Încheiere

Do / anuntarea candidatilor
Incheiat
Do / definitivarea disciplinei

Ştergere

MODELAREA PROBLEMEI
Aici se au în vedere digramele: secvenţă, colaborare şi obiect.

1. Diagrama de secvenţă (Sequence Diagram)

pwd: Verificare t: Gestionarea listei cu discipline

a : Secretar sef parola

1: Cerere de identificare

2: Nume, Parola

3: [verificare(nume, parola) = TRUE] Parola corecta

4: Alegerea opetiei
5: [introducere] alegerea discipline (nume, credit)

6: [stergere] stergerea discipline daca e cazul (nume)

7: [interogare] interograrea bazei daca e cazul

8: Iesire

105
 2. Diagrama de colaborare (Collaboration Diagram)

2: Nume, Parola
pwd: Verificare
parola
1: Cerere de identificare
a : Secretar sef 3: [verificare(nume, parola) = TRUE] Parola corecta

5: [introducere] alegerea discipline (nume, credit)

6: [stergere] stergerea discipline daca e cazul (nume)
7: [interogare] interograrea bazei daca e cazul
8: Iesire

4: Alegerea opetiei

t: Gestionarea listei
cu discipline

3. Diagrama de obiect

IOAN : Candidat
OR

{Alege din:} {Se înscriere la:}

Două care
Din 4 opţionale vrea

106
 IMPLEMENTAREA PROBLEMEI
Cu diagramele de componente şi exploatare.

1. Diagrama de componente (Component Diagram)

Admin_courses.exe
Course

Person
Register.exe
2.
Diagrama de exploatare (Deployment Diagram)

Statie de
administaratie

TCP/IP
Server de date

TCP/IP
Statie de lucru

Staţia de administraţie conţine Admin_course.exe, serverul de date conţine Course şi

Person, iar staţiile de lucru Register.exe.

107
Exemplul 4: Aplicaţie utilă pentru un restaurant

Aplicaţia realizată este o aplicaţie utilă pentru restaurantele mai mici. Numele acesteia
este Restaurant. Se vor realiza operaţii adăugare, ştergere, modificare şi vizualizare pentru
ospătari, produs, comenzi.
Aplicaţia va avea 2 tipuri de utilizatori: Ospătarul şi Administratorul.
Un ospătar va avea distribuite mai multe produse, pe care să le adauge la o comandă,
sau să le şteargă, să realizeze o comandă astfel eliberând masa la care s-a făcut comanda
respectivă, şi oferind posibilitatea că masa respectivă să fie din nou ocupată de alţi clienţi.
Administratorul poate realiza mai multe operaţii asupra datelor din bd. Astfel el poate
vizualiza toţi ospătarii din restaurant împreună cu datele lor personale (nume utilizator şi
parola acestora), poate vizualiza de asemenea şi mesele repartizate fiecărui ospătar în parte,
produsele disponibile restaurantului, comenzile făcute de către ospătari şi lista tuturor
produselor vândute de către restaurant. Administratorul mai are posibilitatea în afară de
vizualizări şi de a face operaţii de adăugare, ştergere sau modificare asupra datelor
vizualizate şi anume asupra ospătarilor din restaurant (asupra numelui de utilizator, sau a
parolei, asupra numelui meselor conţinute de către ospătar) şi produselor deţinute de către
restaurant (numele produselor, sau asupra preţului fiecărui produs în parte).
Un ospătar are un nume de utilizator şi o parolă, date doar de el cunoscute cu care se
va autentifica la intrarea în program. El mai conţine una sau mai multe mese care sunt unice
(aceeaşi masă nu apare la mai mulţi ospătari). Fiecare masă are un nume şi un id personal.
Un produs are un id propriu unic un nume prin care produsul se identifică şi un preţ
care reprezintă valoarea cu care un produs este vândut în restaurantul respectiv.
Un produs vândut are şi el un id propriu, numele produsului, preţul care reprezintă în
cazul în care s-au vândut mai multe produse cu acelaşi nume (id) suma preţurilor acestora, şi
cantitatea reprezentând numărul de produse vândute cu acelaşi nume (id).

O comandă are id personal, conţine id-ul ospătarului care a făcut comanda respectivă,
masa la care s-a făcut comanda şi preţul total reprezentând valoarea comenzii (suma tutror
produselor vândute de către ospătar la masa respectivă.

Utilizatorii aplicaţiei sunt:

Administratorul – va opera asupra bazei de date
Ospătarul
Categorii de informaţii gestionate
 ospătari
 mese
 produse
 produse vândute
 comenzi

Fiecare ospătar este caracterizat de: idOspatar, nume, parola

Fiecare masă este caracterizat de: idOspatar (ospătarul de care este legată), idMasa, şi
numele ei: masa.
Fiecare produs este caracterizat de: idProdus, numele lui şi preţProdus care este preţul
fiecărui produs în parte.
Fiecare produs vândut este caracterizat de: ID care este id-ul unic al produsului
vândut, idComanda care leagă produsul vândut de comanda din care face parte, idMasa care

108
este id-ul mesei la care s-a vândut produsul, pretProdus care este fie preţul produsului vândut
dacă acesta este singurul din comanda respectivă sau suma tuturor produselor de acelaşi
nume din comandă, cantitate care este numărul de produse de acelaşi fel vândute în comanda
noastră.
Fiecare comandă este caracterizată prin: idComanda care este unic pentru fiecare
comandă în parte, idOspatar care este id-ul ospătarului care a efectuat comanda respectivă,
isMasa care este masa la care s-a efectuat comanda respectivă, pretTotal care este preţul
tuturor produselor vândute în cadrul aceleaşi comenzi.
Toate datele necesare problemei vor fi memorate într-o bază de date.

Modelul de analiză

Modelul de utilizare
Actori: Administrator, Ospătar, Login
Cazuri de utilizare:
Login:
- Alege baza de date
- Login
o Pentru ospătar
Vizualizează mesele ospătarului logat
Vizualizează produsele restaurantului
Vizualizează preţul fiecărui produs
Vizualizează cantitatea pentru fiecare produs
o Pentru Administrator
Vizualizează lista ospătarilor
Vizualizează lista meselor fiecărui ospătar
Vizualizează lista produselor
Vizualizează produsele vândute
Vizualizează comenzile
Administrator:
- Gestionează ospătari:
vizualizează ospătar
adaugă ospătar
şterge ospătar
modifică ospătar
- Gestionează mese:
vizualizează masă
adaugă masă
şterge masă
modifică masă
- Gestionează produse
vizualizează produs
adaugă produs
şterge produs
modifică produs
Ospătar:
- Adaugă produs vândut
- şterge produs vândut
- Adaugă comandă

109
Descrierea cazurilor de utilizare
1) Nume: Alege baze de date
Actori: Login
Descriere: Clientul selectează tipul bazei de date la care doreşte să se conecteze.
Introduce datele ce caracterizează fie baza de date din Acces (calea unde se află baza
de date din Acces), fie baza de date din SQL (numele serverului pe care se află baza
de date şi numele acesteia).
Pre: date ne vide;
Post: se stabileşte ce conexiune se va utiliza şi la care baza de date ne vom loga
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Selectează tipul bazei de date
2. Introduce datele
3. Deschide conexiunea la baza de date selectată

Excepţii: 1. date eronate sau vide => mesaj de atenţionare, revenire pas 1

2) Nume: Login
Actori: Login
Descriere: Clientul introduce numele de utilizator şi parola specifice unui ospătar sau
introduce ca şi nume utilizator “admin”, apasă butonul “Login” şi se deschide fie
fereastra specifică ospătarului fie fereastra specifică administratorului.
Pre: datele introduse să nu fie vide;
Post: se logează
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se introduce datele
2. Apasă “Login”
3. Verifică datele introduse
4. Trimite eroare pentru date eronate
5. Încearcă toate datele în funcţie de ce s-a introdus

Excepţii: 1. datele sunt eronate sau vide => mesaj de atenţionare, revenire pas 1

110
 3) Nume: vizualizează ospătar
Actori: Administrator
Descriere: Administratorul selectează un ospătar din lista ospătarilor
Pre: să fie selectat un ospătar
Post: se vizualizează datele personale ale ospătarului selectat şi se actualizează datele
din lista ospătarilor şi lista meselor
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează un ospătar din listă
2. Încarcă datele din baze de date

4) Nume: Adaugă ospătar

Actori: Administrator
Descriere: Administratorul apasă butonul “Adauga”, introduce numele utilizator şi
parola noului ospătar, id-ul ospătarului se incrementează singur
Pre: datele introduse să nu fie vide
Post: se salvează ospătarul în baza de date şi se actualizează datele din lista
ospătarilor şi lista meselor
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se apasă butonul “Adaugă”
2. Se completează datele ne
vide
3. Se apasă butonul “OK”
3. Se adaugă ospătarul în baza de date
4. Se actualizează datele din lista ospătarilor şi lista
meselor

Excepţii: 1. datele sunt vide => mesaj de atenţionare, revenire pas 1

5) Nume: Şterge ospătar

Actori: Administrator
Descriere: Administratorul selectează un ospătar în vederea ştergerii acestuia
Pre:
Post: se şterge ospătarul selectat şi mesele asociate lui

111
 Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează un ospătar din listă
2. Se apasă butonul “Şterge”
3. Se şterge ospătarul selectat şi mesele acestuia din
baza de date
4. Se actualizează datele din lista ospătarilor

6) Nume: Modifică ospătar

Actori: Administrator
Descriere: Administratorul selectează un ospătar din lista ospătarilor, apasă butonul
“Modifică”, introduce datele (modifică numele şi parola).
Pre: să fie selectat un ospătar
Post: se actualizează în bd
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se apasă butonul “Modifică”
2. Se completează datele personale
ne vide
3. Se apasă butonul “OK”
3. Se actualizează în baza de date

Excepţii: 1. numele sau parola sunt vide => mesaj de atenţionare, revenire pas 1

7) Nume: Vizualizează masă

Actori: Administrator
Descriere: Administratorul selectează o masă din lista meselor
Pre: să fie selectată o masă
Post: se vizualizează datele personale ale mesei selectate
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează o masă
2. Încarcă datele din baze de date

112
 8) Nume: Adaugă masă
Actori: Administrator
Descriere: Administratorul apasă butonul “Adaugă” şi introduce datele (numele noi
mese)
Pre: numele noi mese să nu fie vid
Post: se adaugă o nouă masă în baza de date şi se actualizează datele din lista meselor
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se apasă butonul “Adauga”
2. Se completează datele nevide
2. Se salvează în baza de date noua masă cu datele
introduse şi id-ul ospătarului selectat din lista
ospătarilor
3. Se actualizează datele din lista meselor şi lista
ospătarilor

Excepţii: 1. datele sunt vide => mesaj de atenţionare, revenire pas 1

9) Nume: Şterge masă

Actori: Administrator
Descriere: Administratorul selectează o masă din lista meselor.
Pre: să fie selectată o masă
Post: se şterge masa din baze de date
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează o masă din listă
2. Se apasă butonul “Şterge”
3. Se şterge masa din bd având ca idOspatar id-ul
ospătarului selectat în lista ospătarilor

10) Nume: Modifică masă

Actori: Administrator
Descriere: Administratorul selectează o masă din lista meselor, apasă butonul
“Modifica” şi introduce noile date (modifică numele mesei)
Pre: să fie selectată o masă

113
 Post: se şterge masa din baze de date
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

2. Se apasă butonul “Modifica”
1. Se selectează o masă din listă
3. Se apasă butonul “OK”
3. Se modifică masa în bd având ca idMasa id-ul
mesei selectate în lista meselor şi idOspatar id-ul
ospătarului selectat în lista ospătarilor

11) Nume: Vizualizează produs

Actori: Administrator
Descriere: Administratorul selectează un produs din lista produselor
Pre: să fie selectat un produs
Post: se vizualizează datele personale ale produsului selectat
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează un produs
Încarcă datele din baze de date

12) Nume: Adaugă produs

Actori: Administrator
Descriere: : Administratorul apasă butonul “Adaugă” şi introduce datele (numele
noului produs, preţul noului produs)
Pre: numele şi preţul noului produs să nu fie vid
Post: se adaugă un nou produs în baza de date şi se actualizează datele din lista
produselor
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se apasă butonul “Adaugă”
2. Se completează datele ne vide
2. Se salvează în baza de date noul produs cu datele
introduse
3. Se actualizează datele din lista produselor

Excepţii: 1. datele sunt vide => mesaj de atenţionare, revenire pas 1

114
 2. în cadrul preţului s-au introdus caractere => mesaj de atenţionare, revenire
pas 1

13) Nume: Şterge produs

Actori: Administrator
Descriere: Administratorul selectează un produs din lista produselor
Pre: să fie selectat un produs
Post: se şterge produsul din baze de date
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează un produs din listă
2. Se apasă butonul “Şterge”
3. Se şterge produsul din baza de date

14) Nume: Modifică produs

Actori: Administrator
Descriere: Administratorul selectează un produs din lista produselor, apasă butonul
“Modifica”şi introduce noile date (modifică numele produsului, preţul acestuia)
Pre: să fie selectat un produs
Post: se modifică produsul selectat în baze de date
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

2. Se apasă butonul “Modifica”
1. Se selectează un produs din listă
3. Se apasă butonul “OK”
3. Se modifică produsul în baza de date

15) Nume: Adaugă produs vândut

Actori: Ospătar
Descriere: Ospătarul selectează un produs, apasă butonul “Adaugă la comanda”
Pre: să fie selectat un produs
Post: se salvează produs vândut în baza de date şi se actualizează datele din lista
produselor vândute

115
 Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează un produs
2. Se apasă butonul “Adaugă la
comanda”
3. Se adaugă produsul vândut în baza de date
4. Se actualizează datele din lista produselor
vândute

16) Nume: Şterge produs vândut

Actori: Ospătar
Descriere: Ospătarul selectează un produs vândut în vederea ştergerii acestuia, apasă
butonul “Sterge din comanda”
Pre: să fie selectat un produs vândut
Post: se şterge produsul vândut selectat
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se selectează un produs din lista
produselor vândute
2. Se apasă butonul “Şterge din
comanda”
3. Se şterge produsul vândut selectat din baze de
date
4. Se actualizează datele din lista produselor
vândute

17) Nume: Adaugă comandă

Actori: Ospătar
Descriere: Ospătarul apasă butonul “Nota de plată”
Pre:
Post: se salvează o nouă comandă în baza de date şi se actualizează datele din lista
produselor vândute devenind goale
Desfăşurare normală:

Acţiune utilizator Răspuns sistem

1. Se apasă butonul “Nota de plată”
2. Se adaugă comanda în baza de date
3. Se actualizează datele din lista produselor
vândute

116
Diagrama cazurilor de utilizare

Vizualizeaza lista ospatari

Adauga ospatar

Gestioneaza ospatari

Modifica ospatar

Sterge ospatar

Vizualizare lista mese

Adauga masa
Gestioneaza mese

Administrator

Modifica masa
Sterge masa

Vizualizare lista produse

Adauga produs
Gestioneaza produse

Modifica produs

Sterge produs

Alege bd Se conecteaza

Vizualizeaza pret/produs

FOspatar
Vizualizeaza cantitate/produs
Client

Login

Vizualizeaza lista produselor

Vizualizeaza lista meselor

Admin

Vizualizeaza lista ospatarilor

Vizualizeaza lista produselor vandute

Vizualizeraza lista comenzilor

117
 Adauga produs vandut

Sterge produs vandut

Ospatar

Adauga comanda

Diagrama de clase

User
-idUser: Integer
-numeUser: String
-parola: String
Ospatar
-idOspatar: Integer
-nume: String
-parola: String
-listaMese: ArrayList
-listaProduse: ArrayList
Admin -listaComenzi: ArrayList
+are +apartine
-listaProdV: ArrayList
-listaOspatari: ArrayList
1 1..* +Ospatar()
+ListOspatari()
+Nume()
+Parola()
+idOspatar()
+ListMese()
Comanda +ListaProduse()
+listComenzi()
-idComanda: Integer
ProdusVandut +listProduseVandute()
-idOspatar: Integer
-idMasa: Integer
-ID: Integer
-prettotal: Decimal 1 +contine
-idComanda: Integer
+Comanda() +continue -idMasa: Integer
+IdComanda() -idProdus: Integer
+IdOspatar() 1 -numeM: String
+continue-numeP: String
+IdMasa() +apartine
-pretcalc: Decimal 1..*
+PretTotal()
1..* +cantitate: Decimal
0..* Masa
+ProdusVandut()
1 +IdProdusVandut()
1 -idOspatar: Integer
+IdComanda() +apartine
-idMasa: Integer
+contine+IdMasa()
Produs +contine -masa: String
+IdProdus()
1 +NumeM() +Masa()
-idProdus: Integer
-numep: String +NumeP() +IdOspatar()
+contine
-pret: Decimal +PretCalculat() +IdMasa()
+Cantitate() +Masa()
+Produs()
+IdProdus()
+NumeP()
+Pret()

118
Modelul conceptual

Diagrama de secvenţă

Şterge ospătar:

AdministratorUI ComponentaTcp DataManager

: Administrator

1 : selecteaza ospat. pt. stergere()

2 : apasa butonul "Sterge"()

3 : Ms: "vrei sa styergi osp si mesele asociate lui"()

4 : selecteaza "Yes"()

5 : delete ospatar()

6 : delete mese()

7 : delete ospatar din bd()

8 : delete mese din bd()

9 : Incarca date in bd()

10 : afiseaza datele()

119
Modifică masă:

AdministratorUI Masa DataManager

: Administrator

1 : Selecteaza o masa()

2 : Apasa butonul "Modifica"()

3 : Introdu noile date()

4 : Apasa butonul OK()

5 : Instantiaza un obiect de tip masa()

6 : Salveaza masa in bd()

7 : Incarca date in bd()

8 : Afiseaza noile date()

Plăteşte:

: Ospatar OspatarUI : Comanda DataManager

1 : Adauga produse la comanda()

2 : Apasa butonul "Nota de plata"()

3 : Se elibereaza masa selectata()

4 : Instantiaza un obiect de tip comanda()

5 : Salveaza Comanda in bd()

6 : Incarca datele in bd()

7 : Afiseaza datele()

120
Bazele de date folosite pentru memorarea datelor sunt identice din punctul de vedere al
structurii, numelor de tabele, câmpurilor din fiecare tabelă, etc…

Ospatari(idOspatar, Nume, Parola)

Mese(idMasa, Masa, idOspatar)

Produse(idProdus, NumeP, Pret)

ProduseVandute(idComanda, idMasa, idProdus, PretProdus, Cantitate)

Comenzi(idComanda, idOspatar, idMasa, PretTotal)

121
 Capitolul 4. Cuprinsul proiectului PSI
Aceste elemente minime ce trebuie să le cuprindă proiectul predat de student în
ultimul laborator.
1. Prezentare generală a aplicaţiei alese
2. Prezentare text flux informaţional şi reprezentarea sa prin ASME sau BISAD
3. Prezentarea generală a aplicaţiei şi a situaţiilor finale aferente
4. Încadrarea aplicaţiei în cadrul sistemului Informatic
5. Machetele situaţiilor finale
6. Analiza datelor şi algoritmii aferenţi
7. Machetele documentelor de culegere date de intrare
8. Organigramele de sistem aferente unităţilor funcţionale
9. Enunţ pe scurt al problemei pentru DFD, apoi elaborarea acestora:
- Diagrama de context.
- Diagrama de descompunere.
- Depozitul general şi componentele sale.
- DFD general.
- DFD subsisteme.
- DFD activităţi.
10. Diagramele UML aferente aplicaţiei alese şi anume:
- Diagrama Use Case
- Diagrama de clase
- Diagrama de secvenţe
- Diagrama de colaborare
- Diagrama de stări
- Diagrama de componente
- Diagrama de exploatare

122
 Teme pentru proiect la disciplina P.S.I.
1. Planificarea şi urmărirea investiţiilor
2. Gestiunea obiectelor de inventar şi a echipamentului de lucru la …..
3. Bugetul de venituri şi cheltuieli la banca ………………….
4. Întocmirea planului de aprovizionare
5. Urmărirea disciplinei contractuale în aprovizionare şi desfacere
6. Gestiunea produselor finite
7. Bugetul de venituri şi cheltuieli pentru o administraţie financiară
8. Gestiunea (mijloace fixe) activelor
9. Drepturile şi obligaţiile salariale, la ….
10. Acordarea şi urmărirea creditelor pe termen lung pentru persoană juridice la bancă.
11. Contabilitatea de gestiune a unui agent economic
12. Acordarea şi urmărirea creditelor pe termen scurt pentru persoane juridice la bancă
13. Bilanţul şi anexele sale pentru un agent economic
14. Acordarea şi urmărirea creditelor pe termen lung şi scurt pentru persoane fizice la banca
15. Contabilitatea bancară la banca ……………….
16. Evidenţa populaţiei municipiului sau oraşului …………..
17. Contabilitatea bugetară la administraţia financiară
18. C.A.R (casa de ajutor reciproc) al unităţii economice
19. Bilanţul şi anexele sale la banca ……………
20. Evidenţa şi bursele studenţilor unei facultăţi
21. Casa de schimb valutar a unui agent economic
22. Întocmirea planului de desfacere al unui agent economic
23. Întocmirea unui catalog de bibliotecă şi întreţinerea sa
24. Impozitele şi taxele persoanelor fizice şi juridice către administraţia financiară.
25. Evidenţa consumului de alimente la cantina ……..
26. Gestiunea mărfurilor pentru magazinul ………….
27. Evidenţa mărfurilor EN GROS şi EN DETAIL la un agent economic
28. Acordarea şi urmărirea creditelor pe termen scurt şi lung pentru persoane fizice la C.E.C.
29. Activitatea de vânzare şi cumpărare a acţiunilor la o societate de valori mobiliare
30. Bugetul de venituri şi cheltuieli pentru a unei agenţii mobiliare
31. Bugetul de venituri şi cheltuieli a unui agent economic
32. Bilanţul şi anexele sale la administraţia financiară
33. Gestiunea activităţilor pentru o asociaţie de locatari
34. Contabilitatea financiară la nivelul unui agent economic
35. Sistem expert de atribuire a creditelor la o bancă ..
40. Evidenţa şi urmărirea încasării facturilor telefonice la nivelul unui oraş sau municipiu
41. Sistem expert de examinarea al studenţilor la o anumită disciplină
42. Activitatea de cumpărare şi vânzare pentru o societate de valori imobiliare
43. Bugetul de venituri şi cheltuieli a unei societăţi imobiliare
44. Întocmirea şi modificarea orarului unei facultăţi
45. Urmărirea şi încasarea debitorilor unei administraţii financiare
46. Învăţământul la distanţă, teste, note, taxe, etc.
47. Sistem informatic pentru agenţii economici mici şi mijlocii din domeniul comerţului
48. Analiza economico-financiară a unei societăţi comerciale
49. Alternative de gestiune a portofoliului de acţiuni
50. Lansarea şi urmărirea producţiei la un agent economic…..
51. Gestiunea fondurilor proprii şi împrumutate (trezoreria) la un agent economic.
52. Trezoreria unei bănci.

123
53. Activitatea de compensare a datoriilor între agenţii economici.
54. Activitatea de garantare a creditelor pentru agenţii economici.
55. Gestionarea execuţiei produselor la un agent economic.
56. Gestionarea serviciilor la un prestator de servicii.
57. Calculul şi interpretarea indicatorilor statistici la un agent economic.
58. Sistem expert de administrare a unei clinici.
59. Gestiunea patrimoniului unei instituţii de cultură (muzeu).
60. Gestionarea activităţii unei burse de mărfuri zonală.
61. Gestionarea fondurilor unei primării.
62. Gestionarea fondurilor unei prefecturi.
63. Gestionarea activităţii unei agenţii de vânzări bilete de avion.
64. Gestionarea activităţii unei sucursale judeţene Loto-pronosport.
65. Gestiunea activităţii unui consiliu local.
66. Gestiune activităţii unui consiliu judeţean.
67. Planificarea şi urmărirea activităţilor la o societate de consultanţă economico-socială şi
reflectarea în Bugetul de venituri şi cheltuieli.
68. Gestiune alimentelor la o PIZZERIE cu reţetele aferente acestora.
69. Gestiunea activităţii unei societăţi de asigurare
70. Evaluarea unei societăţi comerciale
71. Proiectarea unui magazine virtual pe internet.
72. Comerţul electronic la o agenţie de turism intern şi internaţional.
73. Soluţia E- Business în domeniul agenţilor imobiliari.
74. Gestiunea activităţii unei societăţi de LEASING.
75. Gestiunea activităţii unei societăţi hoteliere.
76. Gestiunea activităţii societăţilor de cablu.

124
 BIBLIOGRAFIE

1. Avornicului C. şi alţii – Aplicaţie informatică privind gestiune obiectelor de inventar

la un agent economic, Editura RISOPRINT, Cluj-Napoca, 1998
2. Avornicului C. şi alţii – Aplicaţii informatice, Editura RISOPRINT, Cluj-Napoca,
2003
3. Avornicului C., Tomai N, Avornicului M. – Proiectarea obiectualǎ şi UML, Editura
RISOPRINT, Cluj-Napoca, 2004
4. Avornicului C., Tomai N. – Proiectarea sistemelor informatice economice şi utilizarea
internetului în diverse domenii, Editura RISOPRINT, Cluj-Napoca, 1999
5. Avornicului C., Avornicului M. – Sisteme – Analiză – Proiectare, Editura
RISOPRINT, Cluj-Napoca, 2006
6. Avornicului C., Avornicului M., Managementul şi proiectarea sistemelor informatice,
Editura RISOPRINT, Cluj, 2007
7. Avornicului C., Avornicului M., MANAGEMENTUL ŞI PROIECTAREA
SISTEMELOR INFORMATICE DE GESTIUNE, Editura RISOPRINT, Cluj, 2010
8. *** - Indicaţii metodologice pentru realizarea sistemelor informatice şi a procedurilor
program, Volumele I-II, Bucureşti, 1997
9. *** - Îndrumar pentru proiectarea sistemelor informatice cu baze de date relaţionale,
Bucureşti, 1999
10. www.fineprint.com
11. www.sparxsystems.com
12. www.uml.org

125