Unitatea de învaţare 4

Diagrame UML construite pentru obţinerea unui model al

activităţilor desfăşurate într-o organizaţie

Obiective:
Studenţii dobăndesc abilități în realizarea unor proiecte în echipă. Se dezvoltă capacitatea de
abordare modulară in proiectarea orientată obiect, de evaluare şi autoevaluare, de colaborare cu
experţi din diferite domenii. Aprofundează cunoștinte privind:
. identificare şi ierarhizarea proceselor corespunzătoare activităţilor desfăşurate în organizaţie
(Business modelling).
. faza de analiză (Analysis), care cuprinde analiza cerinţelor şi analiza de sistem.
. faza de proiectare (Design), în care se adaugă detalii necesare implementării.
. faza de implemntare (Implementation), în care se obţin soluţii aplicabile pentru optimizarea
activiţăţii din organizaţie.
. utilizarea diagramelor UML în construirea sistemului informatic.

Utilizarea limbajului UML depinde de complexitatea sistemului real ce urmează a fi

modelat, de metoda de management şi realizare a proiectelor, de tipul sistemului informatic ce
se doreşte realizat, precum şi de nivelul de detaliere dorit în faza de proiectare. Fiecare diagramă
se construieşte într-un anumit moment al dezvoltării sistemului şi are o anumită utilitate în
proiect. O aceeaşi diagrama poate fi construită în diferite faze ale dezvoltării modelului, cu
implicaţii diferite. Deciziile sunt luate de echipa de realizare a proiectului, ţinând cont de
cerinţele funcţionale ale sistemului şi de resursele disponibile.

Teoretic, întregul ciclu de viaţă al sistemului informatic poate fi împărţit în mai multe
etape. Acestea sunt:
A modelarea activitaţilor desfăşurate în organizaţie (Business modelling) ;
B analiza (Analysis);
C proiectarea (Design);
D implementarea. (Implementation).

. importanţa şi amploarea etapelor se stabileşte în funcţie de dimensiunea şi scopul sistemului;

. aceste etape se parcurg formal sau nu, conştient sau nu, dar se parcurg;
. fiecare etapă are nevoie de intrări provenite din cea anterioară şi produce iesire pentru
următoarea;
. etapele se desfăşoară succesiv; dacă însă lucrează echipe specializate pe faze de dezvoltare, se
pot desfăşura şi în paralel, pentru că dezvoltarea orientată obiect urmează un model în spirală.

A Modelarea activitaţilor desfăşurate în organizaţie este etapa în care se identifică procesele

desfăşurate în organizaţie şi modul în care ele interacţionează. Procesele se reprezintă cu ajutorul
diagramelor de activităţi, în 3 etape:
..A1.. se identifică procesele şi se includ, pe mai multe nivele, într-o diagramă generală a
activităţilor desfăşurate. Diagrama este mai degrabă cuprinzătoare decât precisă, ascunzând
structura organizaţională şi descriind doar funcţionalitatea organizaţiei.

Exemplu:
O organizaţie asamblează calculatoare pe care le vinde clienţilor. Componentele asamblate sunt
aprovizionate de la furnizori. Detaliat, activităţile desfăşurate în această organizaţie conduc la
identificarea mai multor procese, ce pot fi grupate pe 3 nivele:

Activităţile desfăşurate conduc la identificarea mai multor procese, ce pot fi grupate pe 3 nivele:

Nivel 1:
.1- Planificare = dezvoltă şi monitorizează planul tactic şi strategic al organizaţiei: investiţii,
resurse, evaluare performanţe, monitorizare riscuri şi oportuinităţi.
.2- Aprovizionare = cuprinde toate activităţile legate de aprovizionare, inclusiv achitarea
facturilor primite de la furnizor; include contractarea precum şi asigurarea calităţii articolelor
aprovizionate.
.3- Vânzare = înregistrează întreaga activitate de vânzare, incluzând marketingul, comenzile de
la clienţi, facturarea, distribuţia.
.4- Producţie = include producţia şi depozitarea, transportul între secţia de producţie şi depozite.
.5- Dezvoltare = se referă la construcţii pentru fabrici, secţii de producţie, birouri, depozite.
.6- Finanţe = vizează circuitul banilor şi controlul activităţilor financiare: investiţii, gestiune a
conturilor bancare, raportări legale.
.7- Cercetare = urmăreşte cercetările întreprinse pentru dezvoltarea şi optimizarea activităţii
desfăşurate.

Nivel 2:
De exemplu, procesul .3- Vânzare se poate detalia astfel:
.3.1 negociere contract;
. 3.2 preluare comenzi;
. 3.3 livrare articole;
.3.4 acceptare refuzuri;
. 3.5 facturare;
. 3.6 încasare facturi.

Nivel 3:
De exemplu,
▪ procesul .3.2. preluare comenzi se poate detalia astfel:
.3.2.1 se confirmă alegerea clientului
.3.2.2 se preia comanda de la client
3.2.3 se negociază data livrării
3.2.4 se stabileşte data livrării
3.2.5 se confirmă detaliile din comandă

▪ procesul .3.5 facturare se poate detalia astfel:

. 3.5.1 identificare a bunurilor livrate şi acceptate;
. 3.5.2 stabilire a preţului de vânzare;
. 3.5.3 aplicare a reducerilor;
. 3.5.4 completare a fcaturilor;
. 3.5.5 editare şi trimitere a facturilor ce însoţesc produsele.

Schematic, procesele pot fi prezentate în următoarea structură ierarhică:

1 2 3Vânzare 4 ….

3.1
…

3.5 Facturare
…

3.5.2 Stabilirea preţului de vânzare

….

Exerciții:
. Descompuneţi pe nivele 2 şi 3 alte două procese evidenţiate pe nivelul 1.
. Descrieţi activitatea desfăşurată în organizaţie astfel încât să evidenţiaţi într-o manieră
personală procesele cuprinse în descriere. Evidenţiaţi procese suplimentare pentru descrierea .

..A2.. se construiesc diagrame de activităţi pentru procesele analizate.

Pentru o mai bună înţelegere a structurii şi dinamicii organizaţiei se includ obiecte. Plasând
obiecte în diagrama de activităţi, putem vedea unde sunt create şi manipulate obiectele în
desfăşurarea procesului, unde se schimbă starea lor. La acest nivel, obiectele sunt privite doar ca
având o stare ce poate fi schimbată prin acţiuni asupra obiectului.

Exerciții:
. Contruiţi diagrame de activităţi pentru alte procese.
. Includeţi obiecte corespunzătoare documentelor primare care circulă în organizaţie în
diagramele de activităţi.

Exemplu:
Diagrama de activităţi pentru procesul .3.2. - preluare comenzi este (fig. 1):
 fig. 1
B Analiza, în sens larg, acoperă investigarea activităţii desfăşurate în organizaţie şi
definirea unui sistem informatic pentru optimizarea ei
. începe dezvoltarea sistemului de la definirea proceselor, de la identificarea cazurilor de utilizare
care descriu aceste procese şi merge până la momentul în care dezvoltatorii de sistem au un
model comprehensiv al comportamentului sistemului, pot prezenta utilizatorilor viitorul sistem,
împreună cu tipurile de informaţii memorate şi regăsite de el.
. se disting două faze: analiza cerinţelor şi analiza de sistem.

B1 Analiza cerinţelor, clasificate în cerinţe funcţionale, care evidenţiază ce face sistemul şi

cerinţe nefuncţionale, ce vizează performanţele sistemului ( fiabilitate, calitate a interfeţei).
. se centrează în jurul diagramei cazurilor de utilizare, cea care exprimă interacţiunea cu mediul
exterior;
. conduce la definirea comportamentul extern al sistemului şi la includerea sistemul în contextul
activităţii desfăşurate (business environment);

Schematic, intrările şi ieşirile acestei etape pot fi reprezentate ca în figura 2, unde:

. diagrama cazurilor de utilizare prezintă actorii şi acţiunile declanşate de ei.
. descrierea unui caz de utilizare constă în prezentarea scenariilor. Se iau în calcul următoarele
recomandări :
. se clarifică toate problemele cu persoanele implicate (stakeholders);
. se identifică setul de scenarii ce acoperă toate alternativele şi excepţiile;
. pentru fiecare scenariu se construieşte o diagramă de secvenţe;
 . în cazul scenariilor cu alternative şi excepţii se recomandă construirea diagramelor de
activităţi pentru evidenţierea detaliilor.
. prototipurile pentru interfaţa cu utilizatorul ajută la vizualizarea modului în care sistemul
lucrează.

Participanţi Scop Procesele

existente

Analiza cerinţelor

Diagrama cazurilor Descrierea cazurilor Prototipuri pentru

de utilizare de utilizare interfaţă

fig. 2

Pentru exemplul ales,avem:

Scop: Dezvoltarea unui sistem informatic pentru activităţile ce vizează aprovizionarea cu
componente, conform comenzilor primite de la clienţi pentru asamblarea unor sisteme de calcul
(produse finite).
Procese existente:
. gestiunea comenzilor primite de la clienţi
. contractarea componentelor de la furnizor
. aprovizionarea cu componente
. gestiunea componentelor aprovizionate
. achitarea furnizorilor
Participanţi:
. utilizatori
. beneficiari
. analişti
Participanţii la dezvoltarea viitorului sistem stabilesc în această etapă sarcini pe grupuri de
persoane implicate, iau decizii privind oportunitatea definirii unui nou sistem informatic.
Sarcini:
. documentarea viziunii proiectului
. construirea cazurile de utilizare
. descrierea cazurilor de utilizare
. definirea arhitecturii preliminare a sistemului
. analiza riscului
Decizii:
. ce îşi propune sistemul pentru fiecare din utilizatori?
. tehnic şi organizaţional este posibil?
. ce riscuri pot afecta fezabilitatea?
. beneficiile justifică costurile?

Diagrama cazurilor de utilizare pentru procesele ce vizează aprovizionarea conform

contractelor încheiate cu furnizorii este (fig. 3):

fig. 3

Descrierea cazurilor de utilizare.

Pentru exemplul ales, prezentăm în continuare câteva scenarii ce descriu cazuri de
utilizare reprezentative, cu eventuale alternative sau excepţii.

= scenariul 1
Denumire: Încheierea contractului pentru aprovizionarea cu componente
Descrierea derulării:
.. stabilirea necesarului de aprovizionat;
.. analiza ofertelor de la furnizori;
.. alegerea furnizorului;
.. stabilirea condiţiilor contactuale;
.. semnarea contractului de ambele părti.

= scenariul 2
Denumire: Gestiunea componentelor aprovizionate
Descrierea derulării:
.. se înregistrează factura cu care au sosit componentele;
.. gestionarul verifică componentele; în funcţie de calitatea şi cantitatea existentă,
.. gestionarul înscrie componentele corespunzătoare pe NIR; pentru o factură se
completează un NIR/mai multe NIR-uri;
.. NIR-urile se păstrează în arhiva gestiunilor.
SAU
.. întocmeşte proces verbal pentru componentele necorespunzătoare calitativ sau lipsă
cantitativ;
.. furnizează informaţii pentru stornarea facturilor la compartimentul aprovizionare.

= scenariul 3
Denumire: Gestionarea cererii de la aprovizionare/vânzare
Descrierea derulării:
.. gestionarul primeşte o comandă de la departamentul aprovizionare/vânzare;
.. gestionarul verifică cantitatea şi calitatea cerută;
.. gestionarul calculează preţul mediu pentru analiza ofertei în cazul aprovizionării/preţul de
vânzare pentru livrare;
.. în cazul vânzării, descarcă gestiunea după scoaterea din gestiune a mărfii.

= scenariul 4
Denumire: validarea unui client când acesta sună pentru o comandă
Descrierea derulării:
. clientul furnizează un număr de identificare pe care operatorul îl tastează în fereastra de
interfaţă;
. sistemul răspunde cu numele şi adresa clientului şi o parolă de acces;
. operatorul cere confirmarea pentru nume, adresă şi parolă şi închide fereastra dacă răspunsurile
date sunt conforme cu datele de pe ecran.
Alternative:
1. clientul nu are un număr de identificare pentru a fi gestionat; operatorul trebuie să ceară
clientului să aibă un număr de identificare înaintea intrării în sistem.
2. sistemul nu poate găsi înregistrarea cu numărul de identificare dat al clientului şi se afişează
un mesaj de eroare. Operatorul cere un nou număr de identificare şi reia operaţia de validare de
la pasul 1.
3. clientul nu poate furniza numele, adresa sau parola; operatorul închide aplicaţia. Sistemul
trebuie să înregistreze încercarea nereuşită pentru a permite cercetarea fraudei.
Excepţii:
. dacă sistemul nu e disponibil, operatorul preia numele şi numărul de telefon al clientului şi-l
sună imediat ce sistemul e disponibil.

= scenariul 5
Denumire: preluarea detaliilor unei comenzi pentru un client
Descrierea derulării:
. clientul furnizează codul produsului şi cantitatea; operatorul tastează aceste informaţii pe ecran;
. clientul cere o dată anume pentru livrare, operatorul o tastează pe ecran. Sistemul confirmă că
aceata e acceptabilă/acceptată
. operatorul citeşte comanda şi comunicată data livrării clientului, care acceptă
. operatorul închide ecranul de interfaţă şi sistemul răspunde că această comandă a fost acceptată.
Operatorul mulţumeşte clientului şi întreabă dacă există altă comandă
Alternative:
1. clientul nu are un cod al produsului, dar ştie numele produsului. Sistemul poate permite
acceptarea numelui şi regăseşte codul.
2. sistemul nu poate accepta data livrării şi oferă o dată apropiată pe care o negociază cu clientul.
3. se constată nereguli în detaliile unei comenzi:
. clientul a făcut o greşeală în furnizarea datelor şi operatorul trebuie să facă modificări în detalii;
. comanda excede limita de creditare a clientului sau cere un produs neinclus în ofertă; după
discuţii cu clientul se fac modificări.
4. se renunţă la comandă din diferite motive.

Observaţii:
. în situaţia în care preluarea comenzii se face prin telefon, este indicat să se construiască o
diagramă de activităţi care să ia în calcul şi alternativele prezentate în scenariu (fig. 4).
. iesirile evidenţiate în diagramă reprezintă intrări în alte procese (procesul de vânzare după
transferul apelului)

fig.4

B2 Analiza de sistem, fază în care se exprimă comportamentul sistemului în termeni din

domeniul computerelor, într-un limbaj al dezvoltatorilor.
. evidenţiază interacţiunile dintre obiecte pornind de la scenariile descrise anterior; se defineşte o
primă formă a structurii viitorului sistem.
. conduce la construirea unui model obiect, imagine a modului în care sistemul se prezintă
utilizatorilor, a tipurilor de informaţii memorate şi regăsite de sistem.
Schematic, această etapă poate fi reprezentată ca în figura 5 , unde:
Diagrama cazurilor de utilizare construită în etapa de analiză a cerinţelor se completează cu
noile cazuri de utilizare rezultate din prezentarea scenariilor, în special a excepţiilor şi a
alternativelor.
Modelul obiect cuprinde:
.. diagrama claselor, ce evidenţiază structura statică a sistemului;
.. diagramele de secvenţă, de colaborare şi de stare, ce evidenţiază dinamica sistemului.

Analiza de sistem

Diagrama cazurilor Modelul

de utilizare obiect

fig.5

Exemplu:
Diagrama claselor pentru contractarea componentelor în vederea asamblării produselor conform
comenzilor primite de la clienţi este prezentată în figura 6.

Pentru definirea diagramelor de secvenţă, de colaborare şi de stare, noţiunea de obiect

este esenţială în această etapă; obiectele sunt prezentate ca aparţinând unui stereotip, văzut ca cel
mai important dintre mecanismele de extensie. Stereotipul permite ca elemente cu aceeaşi
strucutră să poată primi semnificaţie sau utilizare particulară.
Obiectele definite pentru descrierea unui caz de utilizare pot fi:

▪ obiecte de gestiune (entity) – stereotip << entity>>

= corespund obiectelor din sistemul real; reflectă concepte şi elemente ce aparţin domeniului de
activitate, afacerii reprezentate; sunt persistente în timp şi sunt translatate în tabele ale bazelor de
date relaţionale.
Exemple: facturi, mărfiri, clienţi.
▪ obiecte de control – stereotip << control>>
= organizează comportamentul complex al sistemului. Se definesc în situaţii care implică mai
multe obiecte de interfaţă sau obiecte de gestiune.
Exemple: un obiect ce compară conţinutul unei facturi de aprovizionare cu datele din NIR, un
obiect care identifică diferenţele rezultate din comparaţia anterioară, un obiect care tratează
situaţii posibile menţionate la excepţii.

▪ obiecte de interfaţă (boundary) – stereotip << boundary>>

Fig.6

= controlează interacţiunea cu mediul exterior (outside world). Rolul lor este să translateze
informaţiile furnizate de actori în evenimente interne la care răspund obiecte de control sau
obiecte de gestiune şi să prezinte răspunsul acestor obiecte astfel încât să poată fi înţelese de
actor.
Exemple: fereastră de ecran, formular, casetă de text, butoane, liste derulante.

▪ obiecte de implementare (factory)

= grupează elemente legate de structura internă a sistemului. Ele preiau responsabilitatea pentru
crearea obiectelor când sunt definite pentru prima dată şi pentru transferul lor în/din baza de date
pe timpul duratei lor de viaţă. Cel mai des sunt utilizate ca obiecte legate de persistenţă,
asigurând comunicarea între obiecte şi baza de date.
Exemplu: Pentru a apela un obiect client dintr-o bază de date relaţională, acesta este preluat via
un obiect de control într-un obiect de implementare. Atributul cod client este utilizat pentru a
regăsi în baza de date o înregistrare cu al cărui conţinut se populează atributele obiectului client.
După ce obiectul a fost creat în memorie, alte obiecte îl pot referii. Trebuie apoi returnat în baza
de date; obiectul de implementare poate fi chemat să transfere atributele modificate în baza de
date şi să distrugă obiectul de gestiune.
Exemple:
Prezentăm în continuare diagrame de secvenţă construite pentru câteva din scenariile definite
anterior.

▪ în diagrama de secvenţe pentru scenariul 4 (fig. 7.a) se include două obiecte: un obiect de
interfaţă utilizat pentru interacţiunea cu operatorul şi un obiect de gestiune client.
1. prin intermediul obiectului de interfaţă operatorul tastează numărul clientului şi-l trimite
sistemului;
2. sistemul răspunde cu numele, adresa şi numărul clientului; aceasta implică definirea unui
obiect de gestiune (al clasei client) care să memoreze nume, adresă, număr client.

fig. 7.a

Clasa Client poate fi reprezentată astfel:

3. dacă datele afişate pe ecran corespund cu cele furnizate de client, operatorul confirmă clientul.
Faptul că datele unui client trebuie validate impune definirea unui obiect de control (Validare)
care preia sarcinile confirmării:

<<control>>
Validare

esteValidat()

Diagrama de secvenţe este cea din figura 7.b:

fig. 7.b

In acest moment poate fi construită diagrama de colaborare între clasele implicate în

preluarea comenzilor şi livrarea produselor corespunzătoare lor (figurile 8.a şi 8.b).
 Fig.8.a Diagrama de colaborare cu simboluri obiect

fig. 8.b Diagrama de colaborare cu atribute şi operaţii

Diagrama de stare pentru clasa Comanda este reprezentată în figura 9

Fig. 9

Exerciții recapitulative:
. Completaţi diagrama cazurilor de utilizare din figura 3 cu noi cazurile de utilizare.
. Construiţi diagrame ale cazurilor de utilizare pentru excepţiile şi alternativele prezentate în
cadrul scenariilor în faza de analiză a cerinţelor.
. Construiţi diagrama claselor pentru cazurile de utilizare descrise.
. Completaţi diagrama de colaborare din figura 8.b, cu operaţii.
. Completaţi diagrama claselor din figura 6 cu informaţii obţinute din diagramele construite
anterior.
. Construiţi diagrama de stare pentru clasa client.
. Construiţi diagrama de stare pentru produse livrate.

C Proiectarea se ocupă de cum va opera sistemul şi-l descompune în componente ce pot fi

dezvoltate individual, oferind totodată o vedere de ansamblu asupra sistemului.
. proiectarea sistemului implică împărţirea sa în subsisteme, şi alocarea resurselor hardware şi
software.
. proiectarea obiectelor continuă strategia aleasă în etapa de proiectare a sistemului şi rafinează
detaliile.
Schematic, intrările şi ieşirile acestei etape pot fi reprezentate astfel:

Descrierea cazurilor Modelul

de utilizare obiect

Proiectare

Specificaţii
Modelul pentru
componentelor interfaţă

Modelul Vedere
datelor Model arhitectura
obiect

Cazurile de utilizare interacţionează şi interferează unele cu altele, prin intermediul unor obiecte
de bază (comanda este folosită de cazul de utilizare ce reflectă preluarea comenzii şi de de cazul
de utilizare ce reflectă livrarea unei comenzi).
Diagrama de secvenţe –
. evidenţiază noi interacţiuni între obiecte (pentru actori sau obiecte ale claselor noi introduse
după faza de analiză);
. poate evidenţia crearea unui nou obiect, distrugerea unui obiect sau apelarea unui obiect printr-
o operaţie proprie;
. verifică dacă obiectele definite în faza de analiză sunt viabile pentru implementare sau trebuie
restructurate; se adaugă informaţile schimbate;
. interacţiunile din diagramă (mesajele dintre obiecte) trebuie să se regăsească printre operaţiile
clasei obiectului destinatar.
Diagrama de colaborare –
.evidenţiază funcţionalităţile rezultate din interacţiunile cazurilor de utilizare;
. înlocuieşte mesajele specificate în faza de analiză cu operaţii adăugate claselor de obiecte
destinatar;
Diagrama de activităţi –
. detaliază interacţiunile dintre cazurile de utilizare;
. descrie algoritmi ai unor operaţii complexe.
Diagrama claselor evidenţiază acum un set de obiecte legate unele de altele şi organizate astfel
încât permit implementarea scenariilor ce descriu cazurile de utilizare; cuprinde detalii necesare
implementării:
. atributelor le sunt adăugate gradele de vizibilitate, eventual valori implicite sau valori iniţiale;
. pot exista alte obiecte ca atribute (stare,ClsMatAprov);
. operaţiile pot manipula atributele obiectelor din clasă, pot apela operaţii ale altor obiecte sau
pot manipula atribute ale altor obiecte, dacă acestea aparţin interfeţei;
. interacţiunile dintre obiecte specificate în faza de analiză sunt reprezentate acum prin operaţii;
se specifică semnătura operaţiilor şi nu ce face operaţia;
. se fac precizări suplimentare privind asocierile dintre obiecte; ele sunt implementate prin
atribute memorate într-una ori în ambele clase care se asociază, sau prin evidentierea legăturile
dintre tabele în cazul bazelor de date relaţionale .
Exemple:
In etapa de proiectare se construiesc diagrame de secvenţe pentru a evidenţia crearea unui obiect
persistent (fig.10).

Fig.10
Diagrama de activităţi construită pentru a detalia operaţia de editare a unei facturi este (fig.11):
Fig.11
Descrierea în pseudo-code a operaţiei detaliate în diagrama din figura 11 este:

Editeaza Factura
Jurnal-de-vânzări.open
Jurnal-de-vânzări.getRindVanzare
While Jurnal-de-vânzări.hasItems
Clienti.getClienti(RindVanzare.clientID)
Print detalii factura
While RindVanzare.clientID nu se schimba
Print RindVanzare
Add RindVanzare.valoare to total
Jurnal--de-vânzări.getRindVanzare
EndWhile
Print total factura
Apply discount
Calculate TVA
Print valoarea de plata
Skip next factura
EndWhile

Diagrama claselor din figura 6, completată cu atribute şi operaţii noi, adăugate după construirea
diagramelor de secvenţă, de colaborare şi de stare este (fig.12):
Teste recapitulative:
. Evidenţiaţi în diagrame cazuri de utilizare care interacţionează şi interferează unele cu altele.
. Construiţi diagrame de colaborare pentru evidenţierea funcţionalităţilor rezultate din
interacţiunile cazurilor de utilizare.
. Construiţi diagrame de activităţi ce detaliază interacţiunile dintre cazurile de utilizare.
. Construiţi diagrama claselor pentru activităţile ce vizează preluarea comenzilor şi livrarea
produselor.
. Construiţi diagrame ale claselor pentru procesele descrise în etapa de analiză.