UNIVERSITAREA „POLITEHNICA” BUCURESTI

Facultatea Electronica, Telecomunicatii si Tehnologia Informatiei

Referat Inginerie Software

UML

Berevoianu Adelina
Epure Adriana
Tinta Mihaita

Grupa 443 A

2011
Cuprins

1. Introducere
2. Strategii de formalizare
2.1 Arhitectura UML
2.2 Modele
3. Modelarea cu UML
3.1 View-uri
3.2 Diagrame
3.2.1 Diagrame structurale
3.2.1.1 Diagrama claselor (Class Diagram)
3.2.1.2 Diagrama obiectelor (Object Diagram)
3.2.1.3 Diagrama componentelor (Component Diagram)
3.2.1.4 Diagrama de desfăşurare (Deployment View)
3.2.2 Diagrame comportamentale
3.2.2.1 Diagrama cazurilor de utilizare (Use Case Diagram)
3.2.2.2 Diagrama de activitate (Activity Diagram)
3.2.2.3 Diagrama de stare (State Diagram)
3.2.2.4 Diagrama de interactiune (Interaction Diagram)
3.2.2.4.1 Diagrama de Secventa (Sequence Diagram)
3.2.2.4.2 Diagrama de Colaborare ( Collaboration
Diagram)
4. Concluzii
5. Bibliografie
 1. Introducere
UML (Unified Modelling Language) reprezinta un limbaj vizual de modelare folositor
în domeniul software, dedicat construirii sistemelor complexe si realizarii documentelor de
specificaţii, facand referire in mare parte la vizualizarea, specificarea, construirea şi
documentarea sistemelor de aplicaţii. Prezinta si limitări cu privire la generarea codului şi
reprezinta de asemenea un mijloc bun pentru domeniul ingineriei programării.
Scopul unui limbaj de modelare este analiza si proiectarea programelor. UML
reprezinta limbajul universal standard pentru dezvoltatorii software de pretutindeni, si de
asemenea o combinatie excelenta a celor mai bune trei limbaje de modelare anterioare
orientate pe obiecte (Booch, OMT, and OOSE). Asadar limbajul UML reuneşte cele mai bune
tehnici şi practici din domeniul ingineriei programării, care şi-au dovedit eficienţa în
construirea sistemelor complexe, rezultatul avand o expresivitate foarte buna care ajuta la
rezolvarea diverselor probleme de modelare pe care vechile limbaje nu reuseau sa le
indeplineasca foarte bine. UML ar putea indeplini pe langa rolul de limbaj vizual de modelare
si cel de limbaj vizual de programare, dar momentan nu dispune de întreg sprijinul semantic
şi vizual pentru a înlocui limbajele de programare
Limbajul de modelare modificat (UML - The Unified Modeling Language) consta
in arhitecturi de sisteme ce functioneaza pe analiza si proiectarea obiectelor cu un limbaj
corespunzator pentru specificarea, vizualizarea, construirea si documentarea artefactelor
sistemelor software si de asemenea pentru modelarea în întreprinderi. UML este un limbaj
de modelare care ofera o exprimare grafica a structurii si comportamentului software.
Pentru aceasta exprimare grafica se utilizeaza notatiile UML.
UML este un limbaj de modelare vizual, orientat obiect, care descrie proprietăţile
structurale şi dinamice ale unui sistem software. Prin sistem software se întelege o BD sau un
modul de cod în general. Spre deosebire de modelul EAE, UML este o colecţie de tehnici de
modelare, folosite pentru tratarea multor aspecte ale procesului de concepere şi dezvoltare a
software-ului, de la proiectarea BD la interacţiunea modulelor de cod.
Fiecare tehnică de modelare de mai sus dă o vedere diferită, statică sau dinamică, a unei
aplicaţii. Colecţia de vederi se numeşte model. Iată unele din tehnicile de modelare UML:
diagrame de clase, sau diagrame statice de structură, care modelează entităţile unui sistem
prin clase cu atribute şi comportare. Diagramele de clasă descriu, de asemenea, asocierile
dintre clase şi constrângerile asupra acestora. Apoi, alte tehnici: diagrame de obiecte,
diagrame de "caz de utilizare", diagrame de stare, diagrame de secvenţe, diagrame de
activitate, diagrame de colaborare.
Notatiile UML constituie un element esential al limbajului pentru realizarea propriu-zisa
a modelarii si anume partea reprezentarii grafice pe care se bazeaza orice limbaj de modelare.
Modelarea în acest limbaj se realizeaza prin combinarea notatiilor UML în cadrul elementelor
principale ale acestora denumite diagrame. În cadrul UML-ului descoperim 9 tipuri de
diagrame: diagrama cazurilor de utilizare, diagrama de secventa, diagrama de colaborare,
diagrama de clase (cea mai utilizata), diagrama de stari, diagrama de componente, diagrama
de constructie, diagrama de obiecte, diagrama de activitati. În cele ce urmeaza vor fi
prezentate notatiile UML care vor fi grupate dupa diagramele corespunzatoare fiecarei notatii
în parte.
Adoptarea specificaţiei UML ca limbaj standard de modelare a fost semnalată la 17
noiembrie 1997.
În ingineria mecanică pentru a realiza modelul complet al unei piese, inginerul
foloseşte desenul tehnic ca limbaj pentru comunicare, iar ca mod de reprezentare, vederea
în epură. Această vedere în epură înseamnă vizualizarea unei piese din trei puncte (din faţă,
de sus şi din lateral) astfel încât piesa să fie definită complet. Un cititor avizat al desenului
în epură va şti întotdeauna să refacă mental piesa desenată.

Dacă din cauza complexităţii piesei, cele trei „fotografii” nu sunt suficiente, inginerul va
desena şi alte detalii, sau secţiuni ale piesei, dar privite din aceleaşi trei unghiuri. Fiecare dintre
cele trei puncte de vizualizare a piesei (noi le vom zice, view-uri) reprezintă un submodel
capabil să descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare
view arată piesa văzută dintr-un anumit punct de vedere iar modelul complet utilizează toate
punctele de vedere relevante.

Aşa cum inginerul proiectant comunică prin desen tehnic, echipei, sau oricărei
alte persoane interesate într-un limbai standard, vizual (adică desenul tehnic), făcut să
permită descrierea completă dar, in acelaşi timp, scutită de detalii inutile, inginerii
software pot comunica cu maximă eficientă Tn limbajul UML.
”
La fel ca oricare limbai acesta trebuie învăţat şi exersat astfel încât fiecare „cuvânt să
”
fie înţeles, să ştim unde şi cum se foloseşte, astfel încât să ne putem exprima în „fraze
coerente, care să „spună" exact ceea ce vrem să comunicăm. Limbajul UML ne permite
realizarea mai multor figuri, ca nişte fotografii din diverse unghiuri, ale unei realităţi, astfel
încât această realitate să fie surprinsă prin toate aspectele ei relevante. In software vom
utiliza două puncte de vedere necesare unei descrieri suficiente a realităţii: (1) structural şi
(2) comportamental.

În standardul UML sunt definite următoarele diagrame, pe cele două categorii:

a. pentru descrierea structurală:

- Class Diagram;
- Object Diagram;
- Component Diagram;
- Deployment Diagram.
b. pentru descrierea comportamentală:
- Use Case Diagram;
- Activity Diagram;
- Statechart Diagram;
- Sequence Diagram;
- Collaboration Diagram.
2. Strategii de formalizare

2.1 Arhitectura UML

Pentru a întelege arhitectura UML luam in considerare modul în care programele si
limbajele de programare sunt relationate între ele. Exista multe limbaje de programare, iar
fiecare program in parte este dezvoltat utilizând un limbaj de programare specific. Toate
aceste limbaje vor sustine diferite constructii declarative pentru a declara datele si aspectele
procedurale, precum si definirea logicilor care manipuleaza datele. Deoarece modelul
reprezinta o abstractizare, fiecare dintre aceste concepte luat in parte poate fi captat într-o
multime de modele relationate. Conceptele limbajelor de programare sunt, la rândul lor
definite în metamodel. Fiecare limbaj de programare este definit printr-un model care
utilizeaza si specializeaza conceptele din interiorul metamodelului. Fiecare program
implementat într-un limbaj de proiectare poate fi definit într-un model care se va numi model
utilizator care utilizeaza si instantiaza conceptele modelului printr-un limbaj convenabil.
Aceasta schema a metamodelului, de reprezentare a constructorilor de programare, modele
care sa reprezinte, la rândul lor limbaje de programare si modele utilizator care sa reprezinte
programe, exemplifica arhitectura UML. UML este definit în cadrul conceptual al modelarii
care consta din urmatoarele patru nivele distincte de abstractizare:

 Nivelul meta-metamodelului, consta din elementele fundamentale pe care se bazeaza

UML -conceptul de 'thing', care reprezinta orice ce poate fi definit. Acest nivel de
abstractizare formalizeaza notiunea unui concept si defineste un limbaj pentru specificarea
metamodelului.

 Nivelul metamodelului - consta din acele elemente care constituie UML, incluzând
concepte din paradigmele orientate obiect si orientate componente. Fiecare concept al
nivelului este o instanta (prin intermediul stereotipurilor) a conceptului meta-
metamodelului 'Thig' Acest nivel de abstractizare este utilizat pentru formalizarea
conceptelor paradigmei si la definirea unui limbaj pentru specificarea modelelor
 Nivelul model - consta din modele UML. Acesta este nivelul la care se produce:
modelarea problemelor, solutia sau sistemul. Fiecare concept din acest nivel este o
instanta (prin intermediul stereotipurilor) a unui concept din nivelul metamodelului. Acest
nivel de abstractizare este utilizat la formalizarea conceptelor si la definirea limbajului
pentru comunicarea expresiilor cu privire la un subiect dat. Modelele de pe acest nivel mai
sunt numite clase sau modele ale tipurilor.

 Nivelul model utilizator - consta din acele elemente care exemplifica modelele UML.
Fiecare concept din acest nivel este o instanta (prin intermediul clasificarii) a conceptelor
din nivelul model si o instanta (prin stereotipuri) a unui concept din nivelul metamodel.
Acest nivel de abstractizare este utilizat pentru a formaliza expresiile specifice cu privire
la un subiect dat. Modelele din acest nivel sunt numite si obiecte sau instante ale
modelului
2.2 Modele
Modelele capteaza caracteristicile structurale sau statice ale sistemelor si
comportamentul, sau caracteristicile dinamice ale acestuia. Modelele pot fi privite ca prin
intermediul unei multimi de dimensiuni (aspecte) independente care etaleaza calitati
particulare ale modelului. Fundamental, modelele capteaza cunostinte (semantici).
Perspectiva arhitecturala
Perspectiva arhitecturala organizeaza modelele si cunostintele în jurul unei multimi
specifice de interese (focusarea arhitecturala). UML da urmatoarele perspective arhitecturale
cu privire la modele sau probleme si solutii:
 modelul utilizator - contine o problema si o solutie ca întelese de elementele individuale
carora li se adreseaza respectiva problema (solutie). Aceasta perspectiva este de asemenea
numita use case sau scenariu;
 modelul structural - cuprinde dimensiunea structurala a unei probleme si solutii. Aceasta
perspectiva este cunoscuta ca fiind perspectiva statica sau logica;
 modelul comportamental - cuprinde dimensiunea comportamentala a problemei si solutiei.
Aceasta perspectiva este cunoscuta de asemenea ca fiind: dinamica, de proces, concurenta
sau colaborativa;
 modelul implementarii cuprinde dimensiunea comportamentala si structurala a realizarii
solutiilor, fiind cunoscuta si ca: de dezvoltare sau de componente;
 modelul de mediu - cuprind dimensiunea structurala si comportamentala a domeniului în
care este realizata solutia. Este cunoscuta si ca perspectiva fizica;
Se pot defini si alte perspective, în cazul în care este remarcata necesitatea acestora. O
orientare arhitecturala este definita printr-o multime de continuturi. O perspectiva
arhitecturala este definita prin intermediul unei multimi de elemente dintr -un model care
refera o orientare arhitecturala. De exemplu, securitatea poate fi definita ca o orientare
arhitecturala. O arhitecturalitate a securitatii va include multime a elementelor modelului care
adreseaza securitatea.
Fundamental, perspectiva arhitecturala organizeaza cunostintele în concordanta
cu ghidurile date de exprimarea idiomurilor necesare utilizarii. Diagrame
Diagramele prezinta cunostinte într-o forma comunicabila. UML furnizeaza
urmatoarele diagrame, organizate în jurul perspectivei arhitecturale cu privire la
modelele problemelor si a solutiilor: e perspectiva modelului utilizator
- diagrame de scenarii care descriu functionalitatea
sistemului e perspectiva modelului structural
- clasa de diagrame care descriu structura statica a sistemului
- diagrame obiect care descriu structura statica a sistemului la un
moment particular de timp.
e perspectiva comportamentala
- diagrame de secvente care descriu o interactiune de-a lungul
elementelor sistemului organizat în secventa temporale
- diagrame de colaborare care descriu o interactiune de-a lungul elementelor
unui sistem si a relatiilor acestora, organizate în timp si spatiu
- diagrame de stare care descriu conditiile de stare si raspunsurile
elementelor sistemului
- diagrame de activitate care descriu activitatea elementelor
sistemului. e perspectiva modelului implementare
- diagramele de componente care descriu organizarea elementelor care realizeaza
sistemul e perspectiva modelului de mediu
- diagrame de desfasurare care descriu configuratia elementelor de mediu si
maparea elementelor care realizeaza sistemul peste acestea e alte diagrame pot
fi definite si utilizate dupa necesitati. Mecanismele de modelare
Mecanismele sunt practici pentru abordarea modelarii si a realizarii diagramelor care
valideaza creare de modele din ce în ce mai precise si ceea ce este mai important, din ce în ce
mai comunicabile.
 Perspectivele definesc un punct de vedere particular de la care se pot elabora sau citi
diagrame. Acestea valideaza asocierea de puncte de vedere clare cu diagrame si sunt
utilizate pentru eficientizarea comunicarilor;
 Dihotomiile definesc modul în care ceva poate fi privit din doua perspective diferite.
Acestea valideaza o privire asupra unei entitati din puncte de vedere multiple si sunt
utilizate (fiind foarte eficiente în acest scop) la depistarea inconsistentelor dintre modele;
 Nivelele de abstractizare definesc un nivel particular si stabilesc nivelul de detaliu cu
privire la un subiect (problema sau solutie). Acestea permit orientarea spre comunicare si
sunt utilizate pentru organizarea tuturor diagramelor care apartin unui singur model într-
un singur corp de cunostinte, coerent;
Extensia mecanismelor defineste mijlocul prin care se poate realiza personalizarea si
extinderea UML. Aceasta permite UML sa fie flexibil si adaptiv si este utilizat pentru a
asigura UML evolueaza, solutie mai buna decât redefinirea necesara pentru descrierea
nevoilor de modificare sau a cerintelor. Într-un proces problema - solutie, cunostintele cu
privire la o problema si o solutie sunt captate, organizate în jurul deciziei si descrise utilizând
UML astfel încât pot fi comunicabile si plasate pe diferite nivele.

3. Modelarea cu UML
Conceptele folosite în cadrul diagramelor UML se numesc elemente de modelare. Un
element de modelare are o semantică, o definiţie formală a elementului sau un înţeles exact a
ceea ce reprezintă el într-un anumit context, şi o reprezentare grafică, sau un simbol grafic cu
care se reprezintă în cadrul diagramelor.
Un element poate fi regăsit în mai multe tipuri de diagrame şi pentru fiecare context
există propriile reguli. În figura 1 sunt prezentate câteva exemple de elemente de modelare
împreună cu modul lor de reprezentare.
A modela cu UML înseamnă a construi mai multe modele pentru diferitele faze ale
dezvoltării şi pentru diverse scopuri.
Există mai multe faze ce trebuie parcurse:
■ faza de analiză - surprinde necesităţile sistemului şi modelează clasele de
bază din "lumea reală" şi colaborările dintre acestea;
■ faza de design - se detaliază modelul din faza de analiză şi se formulează o
soluţie tehnică luând în considerare caracteristicile mediului în care acesta va
fi reprezentat;
■ faza de implementare - modelul este transpus în cod iar apoi compilat
în programe;
■ modelul de desfăşurare - se foloseşte o descriere care explică modul cum va fi
adaptat sistemul arhitecturii fizice concrete.

Analiza unei aplicaţii implică realizarea mai multor categorii de modele, dintre
care cele mai importante sunt:

 Modelul de utilizare. realizează modelarea problemelor şi a soluţiilor acestora în

maniera în care le percepe utilizatorul final al aplicaţiei. Diagramă asociată:
diagramă de cazuri de utilizare
0 Modelul structural: se realizează pe baza analizei statice a problemei şi
descrie proprietăţile statice ale entităţilor care compun domeniul problemei.
Diagrame asociate: diagramă de module, diagramă de clase
1 Modelul comportamental: priveşte descrierea funcţionalităţiilor şi a succesiunii în timp
a acţiunilor realizate de entităţile domeniului problemei. Diagrame asociate: diagrama
(harta) de stări, diagrama de colaborare, diagrama de interacţiune

Principalele părţi ale UML sunt:

0 Vederile (View) - surprind aspecte particulare ale sistemului de modelat. Un view
este o abstractizare a sistemului, iar pentru construirea lui se foloseşte un număr de
 diagrame.
1 Diagramele - sunt grafuri care descriu conţinutul unui view. UML are nouă tipuri
de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.
2 Elementele de modelare - sunt conceptele folosite în diagrame care au
corespondenţă în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje şi
relaţii între acestea: asocierea, dependenţa, generalizarea. Un element de modelare
poate fi folosit în mai multe diagrame diferite şi va avea acelaşi înteles şi acelaşi
mod de reprezentare.
Mecanismele generale - permit introducerea de comentarii şi alte informaţii
despre un anumit element

3.1 View-uri
Modelarea unui sistem poate fi o muncă foarte dificilă. Ideal ar fi ca pentru descrierea
sistemului să se folosească un singur graf, însă de cele mai multe ori acesta nu poate să
surprindă toate informaţiile necesare descrierii sistemului. Un sistem poate fi descris luând în
considerare diferite aspecte:

 Funcţional: este descrisă structura statică şi comportamentul dinamic al sistemului;

 Non-funcţional: necesarul de timp pentru dezvoltarea sistemului
 Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;

Aşadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare
reprezentând o proiecţie a descrierii intregului sistem şi care reflectă un anumuit aspect al sau.
Fiecare view este descris folosind un număr de diagrame care conţin informaţii relative la un
anumit aspect particular al sistemului. Aceste view-uri se acoperă unele pe altele, deci este
posibil ca o anumită diagramă să facă parte din mai multe view-uri.

Figura 1: View-urile din UML

VIEW-UL CAZURILOR DE UTILIZARE (USE-CASE VIEW) - Acest view surprinde funcţionalitatea

sistemului, aşa cum este ea percepută de actorii externi care interacţionează cu sistemul,
de exemplu utilizatorii acestuia sau alte sisteme. În componenţa lui intră diagrame ale
cazurilor de utilizare şi ocazional, diagrame de activitate. Cei interesaţi de acest view
sunt deopotrivă clienţii, designerii, dezvoltatorii dar şi cei care vor realiza testarea şi
validarea sistemului.
VIEW-UL LOGIC (LOGIC VIEW) - Spre deosebire de view-ul cazurilor de utilizare, un view logic
"priveşte" înăuntrul sistemului şi descrie atât structura internă a acestuia (clase,
obiecte şi relaţii) cât şi colaborările care apar când obiectele trimit unul altuia mesaje
pentru a realiza funcţionalitatea dorită. Structura statică este descrisă în diagrame de
clasă, în timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de
stare, de secventă, de colaborare sau de activitate. Prin urmare, cei care sunt interesaţi
de acest tip de vizualizare a sistemului sunt designerii şi dezvoltatorii.

VIEW-UL COMPONENTELOR (COMPONENT VIEW) - Componentele sunt module de cod de

diferite tipuri. În funcţie de conţinutul lor acestea pot fi: componente care conţin cod
sursă, componente binare sau excutabile. View-ul componentelor are rolul de a descrie
componentele implementate de sistem şi dependenţele ce există între ele, precum şi
resursele alocate acestora şi eventual alte informaţii administrative, cum ar fi de
exemplu un desfaşurător al muncii de dezvoltare. Este folosit în special de
dezvoltatorii sistemului, iar în componenţa sa intră diagrame ale componentelor.

VIEW-UL DE CONCURENŢĂ (CONCURENT VIEW) - Sistemul poate fi construit astfel încât să

ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncţional, este util
pentru o gestionare eficientă a resurselor, execuţii paralele şi tratări asincrone ale unor
evenimente din sistem, precum şi pentru rezolvarea unor probleme legate de
comunicarea şi sincronizarea theadu-urilor. Cei care sunt interesaţi de o astfel de
vizualizare a sistemului sunt dezvoltatorii şi integratorii de sistem, iar pentru construirea
lui se folosesc diagrame dinamice (stare, secventă, colaborare şi activitate) şi diagrame
de implementare (ale componentelor sau de desfăşurare).

VIEW-UL DE DESFĂŞURARE (DEPLOYMENT VIEW) - Desfăşurarea fizică a sistemului, ce calculatoare

şi ce device-uri (numite şi noduri) vor fi folosite pentru realizarea efectivă a
implementării, cum sunt acestea conectate, precum şi ce componente se vor executa pe
fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate
sunt surprinse în view-ul de desfăşurare. Aceast tip de vizualizare a sistemului prezintă
interes sunt dezvoltatori, integratorii de sistem şi cei care realizează testarea sistemului,
iar pentru construirea view-ului este folosită diagrama de desfăşurare.

3.2 Diagrame
În UML sunt nouă tipuri de diagrame, care vor fi prezentate pe larg în cele ce
urmează. Diagramele UML pot fi împărţite în: diagrame pentru modelarea structurii statice şi
diagrame pentru modelarea comportamentului.

1. Diagramele structurale sunt folosite pentru a vizualiza, specifica, construi şi documenta

aspectele statice ale sistemului. Acestea sunt organizate în jurul grupelor majore de
elemente ce
pot fi găsite în modelarea unui sistem. Din această categorie fac parte:
■ Diagrama claselor (Class Diagram) - prezintă structura fizică a claselor
identificate în sistem. Clasele reprezintă "lucruri" gestionate de sistem. Este cel mai
utilizat tip de diagrame în modelarea sistemelor orientate obiect.
■ Diagrama componentelor (Component Diagram) - prezintă structura fizică a
 codului în termenii componentelor de cod. Se foloseşte pentru a ilustra vederea
statică de implementare a unui sistem.
■ Diagrama obiectelor (Object Diagram) - este o variantă a diagramei claselor care,
în locul unei clase, prezintă mai multe instanţe ale ei.
■ Diagrama de stare (State Diagram) - prezintă toate stările prin care trece un obiect
al clasei, precum şi evenimentele care-i cauzează modificările de stare.

3. Diagramele comportamentale sunt folosite pentru a vizualiza, specifica, construi şi

documenta
aspectele dinamice ale unui sistem. Acestea sunt organizate în jurul modalităţilor
principale de a
modela dinamica unui sistem. Din această categorie fac parte:
■ Diagrama cazurilor de utilizare (Use Case Diagram) - prezintă actorii externi şi
cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este
comportamentul sistemului, aşa cum este el perceput de utilizatorii lui ?) nu şi din
interior, precum şi conexiunile identificate între actori şi cazurile de utilizare.
■ Diagrama de secvenţă (Sequence Diagram) - prezintă colaborarea dinamică între
un număr de obiecte, mai precis, secvenţele de mesaje trimise între acestea, pe
măsura scurgerii timpului.
■ Diagrama de colaborare (Collaboration Diagram) - surprinde colaborarea
dinamică între obiecte, într-o manieră similară cu a diagramei de secvenţă, dar pe
lângă schimbul de mesaje (numit şi interacţiune) prezintă obiectele şi relaţiile
dintre ele (câteodată referite ca şi context).
■ Diagrama de activitate (Activity Diagram) - prezintă fluxul secvenţelor de
activităţi şi este de obicei folosită pentru a descrie activităţile realizate în cadrul
unei operaţii, folosind dacă este cazul decizii şi condiţii.
■ Diagrama de tranziţie - se foloseşte pentru a ilustra vederea dinamică a unui
sistem. Cum luăm decizia folosirii unui anumit tip de diagramă ? Dacă cel mai
important aspect este timpul sau secvenţa de mesaje vom folosi diagrama de secvenţă,
dar dacă trebuie scos în evidenţă contextul, vom apela la o diagramă de colaborare.
Mesajele vor fi reprezentate prin săgeţi între obiectele implicate în mesaj şi pot fi
însoţite de etichete care specifică ordinea în care acestea vor fi transmise. De
asemenea, se pot vizualiza condiţii, iteraţii, valori returnate, precum şi obiectele active
care se execută concurent cu alte obiecte active.

Diagramele sunt grafuri care prezintă simboluri ale elementelor de modelare (model
element) aranjate astfel încât să ilustreze o anumită parte sau un anumit aspect al sistemului.
Un model are de obicei mai multe diagrame de acelaşi tip. O diagramă este o parte a unui
view specific, dar există posibilitatea ca o diagramă să facă parte din mai multe view-uri, în
funcţie de conţinutul ei. În UML sunt nouă tipuri de diagrame pe care le vom prezenta în cele
ce urmează.

3.2.1 Diagrame structurale

3.2.1.1 Diagrama claselor (Class Diagram)
O diagramă a claselor prezintă structura fizică a claselor identificate în sistem. Clasele
reprezintă "lucruri" gestionate de sistem; clasele pot fi legate în mai multe moduri: asociate
(conectate între ele), dependente (o clasa depinde/foloseşte o altă clasă), specializate (o clasă
este specializarea altei clase) sau împachetate (grupate împreună în cadrul unei unitaţi). Toate
aceste relaţii se materializează în structura internă a claselor în atribute şi operaţii.
Diagrama este considerata statica, in sensul ca este valida in orice moment din ciclul de viata
al sistemului.
Class diagram este un tip de diagramă utilizată pentru descrierea structurii statice, adică a
entităţilor sau claselor existente într-un sistem. Acest tip de diagramă este utilizat cel mai
adesea de către dezvoltatori pentru specificarea claselor dar poate fi foarte util şi pentru
specificarea structurii unor sisteme sau subsistem dintr-un business real.

Diagrama de clase nu este utilizata doar pentru vizualizarea, descrierea şi documentarea

diferitelor aspecte ale unui sistem, ci, de asemenea, pentru construirea codului executabil al
aplicaţiei software. Ea descrie atributele şi operaţiunile unei clase şi, de asemenea,
constrângerile impuse asupra sistemului. Schemele de clasa sunt utilizate pe scară largă în
modelarea sistemelor orientate obiect, deoarece acestea sunt diagrame UML singurul care
poate fi mapate direct cu limbaje orientate obiect.

Diagrama de clase prezinta o colectie de clase, interfeţe, asociaţii, colaborări şi constrângeri.

De asemenea, este cunoscuta ca o diagramă structurală.

Scop:
Scopul diagramei de clase este de a modela opinia statica a unei aplicatii. Diagramele de clasă
sunt singurele diagrame care poate fi mapate direct cu limbaje orientate pe obiect şi, astfel,
utilizate pe scară largă în momentul de construcţie.

Diagramele UML ca diagrama de activitate, diagrama de secvenţă pot da doar fluxul de ordine
al aplicatiei, dar diagrama de clase este un pic diferita. Deci, aceasta este cea mai populara
diagrama UML în comunitatea programatorilor.

Deci, scopul diagramei de clase pot fi rezumate astfel:

 Analiza şi proiectarea reprezentarii statice a unei cereri.

 Descrieţi responsabilităţile unui sistem.

 Componenta de bază pentru diagramele de implementare si componente.

 Compilare si inversa.

Cum se deseneaza diagrama de clase?

Diagramele de clase sunt cele mai populare diagramele UML utilizate pentru construirea de
aplicatii software. Deci, este foarte important a afla procedura de desenare a diagramei de
clase. Diagramele de clase au mulţime de proprietăţi care se iau în considerare în timpul
reproducerii schemei, dar aici diagrama va fi considerata dintr-o perspectivă la nivel de top.

Diagrama de clase este de fapt o reprezentare grafică a vederii statice a sistemului şi reprezintă
aspecte diferite ale aplicatiei. Deci, o colectie de diagrame de clase reprezintă întregul sistem.
Ar trebuii sa se tina cont de următoarele puncte în timp ce desenaţi o diagrama de clase:
  Numele diagramei de clase ar trebui să fie semnificativ pentru a descrie aspectul
sistemului.
 Fiecare element şi relaţiile lor ar trebui să fie identificate în prealabil.

 Responsabilitatea (atribute şi metode) ale fiecarei clase ar trebui să fie identificate în

mod clar.

 Pentru fiecare clasa ar trebuii specificat numărul minim de proprietăţi. Deoarece

proprietăţile inutile vor face diagrama de complicat.

 Utilizaţi note oricand este necesar pentru a descrie unele aspecte ale diagramei.
Deoarece la sfârşitul reprezentarii ar trebui să fie înţeles de către dezvoltator /
programator.

 În cele din urmă, înainte de a face versiunea finală, diagrama ar trebui să fie elaborata
pe o simpla hârtie şi revizuita de câte ori este posibil pentru a o face corect.

Acum diagrama de mai jos este un exemplu de un Sistem Ordonat al unei aplicatii. Deci,
aceasta descrie un anumit aspect al intregii aplicatii.

 Mai întâi de toate, Order şi a Customer sunt identificati ca fiind cele două elemente ale
sistemului şi au o relaţie unu la mai multe, deoarece un client poate avea mai multe
comenzi.
 Clasa Order este o clasă abstractă şi are două clase (relaţia moştenire) şi SpecialOrder
si NormalOrder.

 Cele două clase au moştenit toate proprietatile ca si clasa Order. În plus, acestea au
funcţii suplimentare, cum ar expediere () şi să primească ().

Astfel, urmatoarea diagrama de clase a fost elaborata luând în considerare toate punctele
menţionate mai sus:
Unde se utilizeaza diagramele de clase?
Diagrama de clase este o diagrama statica şi este folosit pentru a vizualiza modelul static al
unui sistem. Punctul de vedere static descrie vocabularul sistemului.

Diagrama de clase este, de asemenea, considerata ca fundament pentru diagramele de

componente si de implementare. Diagramele de clase nu sunt folosite doar pentru a vizualiza
reprezentarea statică a sistemului, dar acestea sunt, de asemenea, utilizate pentru a construi
codul executabil pentru compilare si inversa al oricarui sistem.

În general, diagramele UML nu sunt direct cartografiate cu orice limbaje de programare

orientate pe obiect, dar diagrama de clase este o excepţie.

Diagrama de clase arată în mod clar maparea cu limbaje orientate obiect cum ar fi Java, C + +,
etc. Deci, din experienţa practică diagrama de clase este, în general, utilizata în scopul
construirii.

Deci, mai pe scurt, diagramele de clase sunt utilizate pentru:

 Descrierea reprezentarii statice a sistemului.

 Arata colaborarea dintre elementele de tip static.

 Descrie funcţionalităţile efectuate de către sistem.

 Construirea de aplicatii software folosind limbaje orientate pe obiect.

Elementele utilizate şi notaţiile lor sunt următoarele:

Element Descriere Notaţie
O clasă este reprezentată printr-un dreptunghi cu trei
compartimente: în cel de sus se trece numele clasei, în
Clasă
mijloc se trec atributele clasei iar jos se trec operaţiile
specifice clasei.
Moştenirea este o relaţie care indică faptul că o clasă
moşteneşte caracteristicile unei clase părinte. Sensul săgeţii
Moştenire
indică sensul în care se poate spune despre clasa copil că
este o<-i>, sau este de tipul<-i> clasă părinte.
Asocierea este o relaţie generică între două clase. Aceste
relaţii pot fi de tipurile pot defini şi regulile numerice de
Asociere
asociere (unu la unu, unu la mai mulţi, mai mulţi la mai
mulţi).

Atunci când o clasă depinde de o altă clasă, în sensul că

Dependenţă utilizează acea clasă ca şi atribut al său, se foloseşte relaţia
de dependenţă.

Agregarea indică o relaţie de tip întreg-parte (se poate

Agregare spune despre clasa părinte că are clase de tip copil). În
această relaţie, clasa copil poate exista şi fără clasa părinte.

Această relaţie derivă din agregare dar se utilizează atunci

Compoziţie când o clasă copil nu poate exista decât în cazul existenţei
clasei părinte.

În reprezentarea clasei atributele şi operaţiile sunt declarate în compartimentele speciale din

dreptunghi, astfel:
- atributele:
numele atributului : tipul atributului = valoare implicită

- operaţiile:
numele operaţiei (parametri) : tipul valorii returnate

Atunci când diagrama este folosită pentru a modela structuri de business se pot folosi tipurile
de date specifice business-ului, nu programării, de exemplu: minut, dată calendaristică, minut
etc.

Moştenirea este o relaţie prin care se indică faptul că o clasă moşteneşte caracteristicile clasei
părinte. În plus, clasa copil poate avea propriile caracteristici.
Asocierea arată existenţa unei relaţii între clase. În exemplul de mai jos, între Persoană şi
Autovehicul următoarea relaţie: o Persoană poate avea zero, unul sau mai multe Autovehicule.

Un tip special de asociere este indicat printr-o clasă de asociere. Altfel spus, relaţia în sine este
o clasă.
În exemplul de mai jos, relaţia dintre Articol şi Lista de preţuri este de tip mai mulţi la mai
mulţi: un Articol poate să apară pe mai multe Liste şi o Listă poate avea mai multe Articole. Pe
Liste diferite Articolele pot avea preţuri diferite.

Dependenţa indică faptul că o clasă depinde de altă clasă, în sensul în care o funcţie oarecare
depinde de un parametru al său.

Agregarea indică faptul că o clasă părinte are elemente de tipul clasei copil. În exemplul de mai
jos.Ţara poate avea mai multe Judeţe dar, în acelaşi timp, un Judeţ poate exista chiar şi în cazul
în care clasa Ţara nu există.

Într-o relaţie de tip compoziţie clasa copil nu poate exista decât dacă există o instanţă a clasei
părinte. În exemplul de mai jos instanţa clasei Comisie există atâta timp cât există instanţa
clasei Examen.

Figura 3: O diagramă a claselor

pentru un sistem de asigurări.

3.2.1.2 Diagrama obiectelor (Object Diagram)

Acest tip de diagramă este un variant al diagramei claselor care în locul unei clase
prezintă mai multe instanţe ale ei. Diagrama obiectelor foloseşte aproape aceleaşi notaţii ca şi
diagrama claselor cu două mici diferenţe: obiectele sunt scrise subliniat şi sunt vizualizate
toate instantele relaţiei (figura 4).
Deşi nu este la fel de importantă ca diagrama claselor, cea o obiectelor este folosită
pentru exemplificarea unei diagrame a claselor de complexitate mare, permiţând vizualizari
ale instanţelor actuale şi a relaţiilor exact aşa cum sunt ele realizate. Mai poate fi folosită ca
o parte a diagramelor de colaborare, în care sunt vizualizate colaborările dinamice existente
în cadrul unui set de obiecte.

Diagramele obiect sunt derivate din diagramele de clase, astfel diagrame de obiecte sunt
dependente de diagrame de clase; reprezinta o instanta a unei diagrame de clase. Conceptele de
bază sunt similare pentru diagramele de clase şi diagramele obiect. Diagrame obiect reprezintă,
de asemenea, punctul de vedere static al unui sistem, dar acest punct de vedere static este un
instantaneu al sistemului la un moment dat.

Diagramele obiect sunt utilizate pentru a face un set de obiecte şi relaţiile lor ca o instanţă.
Scop:
Scopul unei diagrame ar trebui să fie înţeles în mod clar pentru a putea fi pus în aplicare
practic. Scopul diagramelor de obiect este similar cu cel al diagramelor de clase.

Diferenta este ca o diagrama de clase reprezintă un model abstract format din clase şi relaţiile
lor. Dar un obiect diagramă reprezintă o instanţă la un moment dat, care este concretă în natură.
Aceasta înseamnă că diagrama obiect este mai aproape de comportamentul sistemului actual.
Scopul este de a captura vederea statica a unui sistem la un anumit moment.

Deci, scopurile diagramei obiect pot fi rezumate astfel:

 Compilare si inversa.
 Relaţiile obiectului unui sistem

 Vedere statica a unei interacţiuni.

 Înţelegerea comportamentului obiect şi relaţia lor din punct de vedere practic

Cum se deseneaza diagrama obiect?

Am discutat deja că o diagrama obiect este o instanta a unei diagrama de clase. Aceasta implică
faptul că un obiect diagramă este format din instanţe de lucruri utilizate într-o diagrama de
clase.

Deci, ambele diagrame sunt facute din aceleasi elemente de bază, dar în diferite forme. În
diagrama de clase sunt elemente într-o formă abstractă pentru a reprezenta imprimare albastru
şi în diagrama obiect elementele sunt într-o formă concretă pentru a reprezenta obiectul in
lumea reală.

Pentru a captura un anumit sistem, numărul de diagrame de clase sunt limitate. Dar, dacă luăm
în considerare diagramele obiect, atunci putem avea un număr nelimitat de instanţe, care sunt
unice în natură. Deci, sunt luate în considerare numai acele cazuri care au un impact asupra
sistemului.

Din discuţia de mai sus este evident că o singura diagrama obiect nu poate capta toate
instanţele necesare sau, mai degrabă nu poate specifica toate obiectele dintr-un sistem. Deci,
soluţia este:

 În primul rând, o analiză a sistemului şi să se decidă care sunt instanţele care au date
importante şi de asociere.
 În al doilea rând, se ia în considerare numai acele cazuri care vor acoperi
funcţionalitatea.

 În al treilea rând, se fac unele optimizari avand in vedere ca numărul de instanţe sunt
nelimitate.

Înainte de a se desena diagramele unui obiect, trebuie tinut seama de următoarele lucruri :

 Diagramele obiect sunt formate din obiecte.

 Legatura din diagrama de obiect este folosita pentru a conecta obiecte.
  Obiectele şi link-urile sunt două elemente folosite pentru a construi o diagramă obiect.

Acum, după aceasta, trebuie tinuta seama de urmatoarele lucruri care urmează să fie stabilite
înainte de a începe construcţia diagramei:

 Diagrama de obiect ar trebui să aibă un nume semnificativ pentru a indica scopul său.
 Cele mai importante elemente trebuie să fie identificate.

 Asocierea dintre obiecte ar trebui să fie clarificata.

 Valorile unor elemente diferite ar trebui să fie capturate si apoi incluse în diagrama de
obiect.

 Adăugarea de note corespunzătoare în punctele în care este necesară mai multă

claritate.

Diagrama de mai jos este un exemplu de o diagramă obiect. Ea reprezintă sistemul de

management al comenzii pe care le-am discutat în diagrama de clase. Diagrama de mai jos este
o instanta a sistemului la un anumit moment de cumpărare. Acesta are următoarele obiecte

 Customer
 Order

 SpecialOrder

 NormalOrder

Acum obiectul Customer (C) este asociat cu trei obiecte de ordine (O1, O2 şi O3). Aceste
obiecte de ordine sunt asociate cu ordine speciale şi obiecte normale de comandă (S1, S2 şi
N1). Customer are următoarele trei ordine cu numere diferite (12, 32 şi 40) pentru anumite
perioade luate în considerare.

Acum clientul poate creste numarul de Order, în viitor, şi în acest scenariu diagrama obiect va
reflecta acest lucru. Dacă Order, SpecialOrder şi NormalOrder sunt observate, atunci vom găsi
că acestea au anumite valori.

Pentru Orders valorile sunt 12, 32, şi 40 ceea ce implică faptul că obiectele sunt cu aceste
valori pentru un moment anume (aici, momentul particular de timp în cazul în care achiziţia se
face este considerat ca fiind momentul), atunci când instanţa este capturata.

Acelaşi lucru este si pentru SpecialOrder şi NormalOrder, care au numarul de Orders ca 20, 30
şi 60. În cazul în care un alt moment de cumpărare este considerat, atunci aceste valori se vor
schimba în consecinţă.

Asadar, urmatoarea diagrama a fost elaborat luând în considerare toate punctele menţionate
mai sus:
Unde folosim diagramele obiect?
Diagramele obiect pot fi imaginate ca o imagine dintr-un sistem care rulează la un moment dat.
Acum, pentru a se clarifica putem lua un exemplu de un tren in miscare.

Acum, dacă luati un anumit moment din circulaţia trenului, veţi găsi o imagine statică a
acesteia având următoarele:

 O situatie speciala, care se execută

 Un anumit număr de pasageri. care se va schimba în cazul în care momentul este luat
la un alt moment de timp.

Deci, aici ne putem imagina ca momentul de circulaţie al trenului este un obiect având valorile
de mai sus. Şi acest lucru este valabil pentru orice sistem de viaţa reală simplu sau complex.
Mai pe scurt diagramele obiect sunt utilizate pentru:

 Producerea prototipului unui sistem.

 Decompilarea.

 Modelarea structurilor complexe de date.

 Înţelegerea sistemului din punct de vedere practic.

 Figura 4: O diagramă a claselor şi o diagramă a obiectelor (instanţele claselor).

3.2.1.3 Diagrama componentelor (Component Diagram)

O diagramă a componentelor prezintă structura fizică a codului în termenii componentelor de

cod, realizând o mapare de la view-ul logic la view-ul componentelor. O componentă poate să
conţină un cod sursă sau poate să fie într-o forma binară sau executabilă. În cadrul diagramei vor
fi ilustrate şi dependenţele dintre componente, ceea ce permite o vizualizare simplă a
componentelor care vor fi afectate de modificarea uneia dintre ele.

Diagrama componentelor este diferita în ceea ce priveşte natura şi comportamentul, si este

folosita pentru a modela aspectele fizice ale unui sistem. Acum întrebarea este care sunt aceste
aspecte fizice? Aspecte fizice sunt elemente cum ar fi executabile, biblioteci, fişiere,
documente, etc care îşi are reşedinţa într-un nod. Deci, diagramele componente sunt folosite
pentru a vizualiza organizarea şi relaţiile dintre componente într-un sistem. Aceste diagrame
sunt, de asemenea, folosite pentru a face crea sisteme executabile.

Scop:
Diagrama Componentelor este un tip special de diagrama în UML. Scopul este, de asemenea,
diferit de toate celelalte diagrame discutate până acum. Ea nu descrie funcţionalitatea
sistemului, dar descrie componentele utilizate pentru a face aceste funcţionalităţi.

Deci, din acest punct de vedere diagrama componentelor este folosita pentru a vizualiza
componentele fizice într-un sistem. Aceste componente sunt biblioteci, pachete, fisiere, etc
Diagrama componentă poate fi, de asemenea, descrisa ca o vizualizare a unei implementari
statice al unui sistem. Implementarea statica reprezinta organizarea de componente la un
anumit moment.

O singura diagramă a componentelor nu poate reprezenta întregul sistem, de aceea se foloseste

o colecţie de diagrame pentru a reprezenta întregul sistem.

Deci, scopul diagramei componentelor poate fi rezumat astfel:

 Vizualizati componentele unui sistem.

 Construirea de executabile prin utilizarea de compilare si inversa.

 Descrieţi organizarea şi relaţiile dintre componente.

Cum se deseneaza diagrama componentelor?

Diagramele componentelor sunt folosite pentru a descrie artefactele fizice ale unui sistem. Un
astfel de artefact include imagini, executabilele, biblioteci etc Deci, scopul acestei diagrame
este diferit, diagramele de componente sunt utilizate în timpul fazei de implementare a unei
cereri. Dar este bine pregătită în avans pentru a vizualiza detaliile de implementare.

Iniţial, sistemul este proiectat folosind diagrame UML diferite şi atunci când artefactele sunt
gata diagramele componente sunt folosite pentru a obţine o idee de punere în aplicare.

Această diagramă este foarte importanta, deoarece fără ea cererea nu poate fi pusă în aplicare
eficient. O diagramă componentă bine pregătita este, de asemenea, importanta pentru alte
aspecte precum performantele de aplicare, întreţinere etc.

Deci, înainte de elaborarea unei diagrame a componentelor, trebuie sa identificam în mod clar
următoarele artefacte:

 Fişierele utilizate în sistem.

 Bibliotecile şi alte obiecte relevante pentru punerea în aplicare.

 Relaţiile dintre artefacte.

Acum, după identificarea artefactelor, trebuie sa urmam următoarele puncte:

 Utilizaţi un nume semnificativ pentru a identifica componenta pentru care diagrama va

fi construita.
 Se pregateste un idee de baza înainte de producerea instrumentelor de ajutor.

 Utilizaţi note pentru a clarifica punctele importante.

Ceea ce urmează este o diagrama componentă pentru sistemul managerial de comandă. Aici
artefactele sunt fişiere. Deci diagrama prezinta fişierele din aplicatie şi relaţiile lor. În realitate
diagrama de componente conţine, de asemenea DLL-uri, biblioteci, foldere, etc

În următoarea diagramă patru fişiere sunt identificate şi relaţiile lor sunt produse. Diagrama de
componente nu poate fi compensată în mod direct cu alte diagrame UML discutate până acum.
Deoarece este întocmită în scopuri complet diferite.

Deci diagrama următoare de componente a fost elaborata luând în considerare toate punctele
menţionate mai sus:
În ce cazuri folosim Diagrama de componente?
Am descris deja că diagramele componentelor sunt folosite pentru a vizualiza implementarea
statica a unui sistem. Diagramele de componente sunt un tip special de diagrame UML folosite
pentru scopuri diferite. Aceste diagrame arată componentele fizice ale unui sistem. Pentru a
clarifica aceasta, putem spune că diagramele de componente descriu organizarea
componentelor într-un sistem.

Organizarea poate fi descrisa în continuare drept locaţia componentelor într-un sistem. Aceste
componente sunt organizate într-un mod special pentru a îndeplini cerinţele unui sistem. Aşa
cum am discutat mai inainte, aceste componente sunt biblioteci, fişiere, executabilele etc.
Acum, înainte de punerea în aplicare a cererii aceste componente vor fi organizate. Această
organizaţie componentă este, de asemenea proiectat separat, ca parte a proiectului de execuţie.

Diagramele de componente sunt foarte importante din punct de vedere al implementarii. Deci,
echipa de implementare a unei aplicatii ar trebui să aibă o cunoaştere corectă a detaliilor
componentei.

Acum, utilizarea de diagrame componente pot fi descrise ca:

 Modelarea componentelor unui sistem.

 Modelarea schemei bazei de date.

 Modelarea executabila a unei aplicatii.

 Modelarea codului sursa a sistemului.

Figura 8: O diagramă a componentelor

 3.2.1.4 Diagrama de desfăşurare (Deployment View)
Arhitectura fizică pe care va fi implementat sistemul, calculatoarele, device-urile
(referite ca nodurile sistemului), împreună cu conexiunile dintre ele, vor putea fi prezentate
în cadrul unei diagrame de desfaşurare. Componentele şi obiectele executabile sunt alocate
în interiorul nodurilor, ceea ce ne va permite o vizualizare a unitaţilor care se vor executa pe
fiecare nod.

Figura 9: O diagramă de desfaşurare care prezintă structura fizică a sistemului.

Prezentare:
Diagramele de desfăşurare sunt utilizate pentru a vizualiza topologia componentele fizice ale
unui sistem în care componentele software sunt implementate. Asadar, diagramele de
desfăşurare sunt folosite pentru a descrie desfasurarea statica a unui sistem, si consista din
noduri si relatia intre ele.

Scop:
Numele de „desfăşurare” se descrie pe sine în scopul de diagrama. Diagramele de desfasurare
sunt utilizate pentru a descrie componentele hardware in care componentele software sunt
vizualizate.Aceste diagrame de desfasurare şi diagramele componentelor sunt strâns legate.

Diagramele Componentelor sunt folosite pentru a descrie componentele şi schemele de

desfăşurare arată modul în care acestea sunt dislocate în hardware. UML este în principal
destinat să se concentreze pe artefactele software ale unui sistem. Dar aceste două diagrame
sunt diagrame de construcţii utilizate pentru a se concentra pe componente software şi
componente hardware.

Deci, cele mai multe diagrame UML sunt utilizate pentru a manipula componente logice, dar
diagramele de desfăşurare sunt făcute ca să se concentreze asupra topologiei hardware a unui
sistem. Diagramele de desfăşurare sunt utilizate de către inginerii de sistem.

Scopul diagramelor de desfăşurare pot fi descrise ca:

 Vizualizarea topologiei hardware a unui sistem.

 Descrie componentele hardware utilizate pentru a implementa componente software.

 Descrie noduri runtime de prelucrare.

Cum se deseneaza diagrama de desfăşurare?

Diagrama de desfăşurare reprezintă vizualizarea implementarii unui sistem. Este legata de
diagrama de componente, deoarece componentele sunt dislocate cu ajutorul diagramelor de
desfăşurare. O diagramă de desfasurare/implementare este formata din noduri. Nodurile sunt
nimic altceva decât produse hardware fizice utilizate pentru a implementa aplicatia.

Diagrame de implementare sunt utile pentru inginerii de sistem. O diagramă de implementare

eficientă este foarte importanta, deoarece controleaza următorii parametri

 Performanţă
 Scalabilitate

 Mentenabilitatea

 Portabilitate

Deci, înainte de elaborarea unei diagrame de implementare ar trebuii identificate următoarele:

 Noduri
  Relaţiile între noduri

Urmatoarea diagrama de desfăşurare reprezinta un exemplul pentru a va da o idee legata de

implementarea sistemului de management. Aici am aratat ca noduri:

 Monitor
 Modem

 Caching server de

 Server

Aplicatia se presupune a fi o aplicaţie web care este implementata într-un mediu cluster
folosind serverul 1, 2 şi serverul 3. Utilizatorul se conecteaza la aplicaţie folosind internetul.
Traseul se desfasoara de la serverul de caching catre mediul cu clustere.

Deci, urmatoarea diagrama de desfăşurare a fost elaborata luând în considerare toate punctele
menţionate mai sus:

Unde se folosesc diagramele de desfasurare?

Diagramele de desfăşurare sunt folosite în principal de către inginerii de sistem. Aceste
diagrame sunt folosite pentru a descrie componentele fizice (Hardwares), distribuirea si
asocierea acestora. Pentru a clarifica acest lucru în detalii, putem vizualiza diagramele de
desfăşurare ca şi componentele hardware / nodurile pe care sunt implementate componente
software.

Aplicaţiile software sunt dezvoltate pentru a modela procesele complexe legate de afaceri.
Doar utilizarea unor aplicaţii software eficiente nu sunt suficiente pentru a satisface cerinţele
unei afaceri. Cerinţele de afaceri pot fi descrise in scopul de a sprijini creşterea numărului de
utilizatori, timp de răspuns rapid, etc. Pentru a satisface aceste tipuri de componente hardware,
cerinţele ar trebui să fie proiectate eficient şi într-un mod rentabil.

Acum, aplicaţiile software sunt foarte complexe în natură; pot fi de sine statatoare, bazate pe
web, distribuite, bazate pe mainframe şi multe altele. Deci, este foarte important sa se
proiecteze componentele hardware intr-un mod eficient.

Deci, utilizarea de diagrame de implementare poate fi descrisă după cum urmează:

 Pentru a modela topologia hardware a unui sistem.

 Pentru a modela un sistem integrat.

 Pentru a modela detalii hardware pentru un sistem client / server.

 Pentru a modela detalii hardware a unei aplicatii distribuite.

 Compilare si inversa.

3.2.2 Diagrame comportamentale

3.2.2.1 Diagrama cazurilor de utilizare (Use Case

Diagram)
Use case diagram este un tip de diagramă din care reiese modul de utilizare a sistemului
informatic - modul în care utilizatorii interacţionează cu acesta (în corespondenţă directă cu
task-urile acestor utilizatori.). Utilizarea use case diagram nu este absolut necesară pentru a
scrie o specificaţie cu use case-uri dar este utilă pentru a crea o imagine generală asupra
sistemului.

Prezentare:
Pentru a modela un sistem, cel mai important aspect este acela de a capta comportamentul
dinamic. Pentru a clarifica in detalii, prin comportamentul dinamic se înţelege comportamentul
sistemului atunci când se execută / opereaza.

Deci, numai comportamentul static nu este suficient pentru a modela un sistem,

comportamentul dinamic este mai important decât comportamentul static. În UML există cinci
diagrame disponibile pentru modelul de natură dinamică şi diagrama caz de utilizare este unul
dintre ele. Acum, ar trebuii sa discutam despre faptul că diagrama caz de utilizare este
dinamica în natură, si ar trebui să existe anumiti factori interni sau externi pentru efectuarea
acestei interacţiuni.

Aceşti agenţi interni şi externi sunt cunoscuti drept actori. Deci, diagramele caz de utilizare se
compun din actori, cazuri de utilizare şi relaţiile lor. Diagrama este utilizata pentru a modela
sistemul / subsistem unei cereri. O singura diagrama a unui caz de utilizare capturează o
funcţionalitate specială a unui sistem.

Deci, pentru a modela întregul sistem sunt folosite un anumit numar de diagrame caz de
utilizare.

Scop:
Scopul diagramei caz de utilizare este de a surprinde aspectul dinamic al unui sistem. Dar
această definiţie este prea generica pentru a descrie scopul, deoarece alte patru diagrame
(activitate, secvenţa, colaborare şi stare) au, de asemenea, acelaşi scop. Deci, ne vom orienta
asupra unui scop specific, care o va distinge de celelalte patru diagrame.

Diagramele caz de utilizare sunt folosite pentru a aduna cerinţele unui sistem, inclusiv
influenţe interne şi externe. Aceste cerinţe sunt în general cerinţele de proiectare. Deci, atunci
când un sistem este analizat pentru a aduna funcţionalităţile sale, cazurile de utilizare sunt
pregătite şi actorii sunt identificati.

Cand sarcina iniţială este completa, diagramele caz de utilizare sunt modelate pentru a prezenta
punctul de vedere exterior. Deci, pe scurt, scopul diagramelor caz de utilizare pot fi, după cum
urmează:

 Folosit pentru a aduna cerinţele unui sistem.

 Folosit pentru a obţine o imagine în afara unui sistem.

 Identificarea factorilor externi şi interni care influenţează sistemul.

 Arată ca cei care interacţionează între cerinţe sunt actori.

Cum se elaboreaza diagrama caz de utilizare?

Diagramele caz de utilizare sunt luate în considerare pentru analiza de nivel înalt a unui sistem.
Deci, în cazul în care cerinţele unui sistem sunt analizate funcţionalităţile lor sunt capturate în
cazurile de utilizare.

Deci, putem spune că aceste cazuri de utilizare nu sunt altceva decat funcţionalităţile
sistemului scrise într-un mod organizat. Acum, alte doua lucrurile care sunt relevante pentru
cazuri de utilizare sunt actorii. Actori pot fi definiti ca ceva care interacţionează cu sistemul;
pot fi utilizatorii umani, unele aplicaţii interne sau poate unele aplicaţii externe. Deci, mai pe
scurt atunci când planificam desenarea unei diagrame caz de utilizare trebuie să tinem cont de
următoarele elemente identificate.

 Funcţionalităţi de a fi reprezentate ca un caz de utilizare

 Actori

 Relaţiile între cazurile de utilizare şi de actori.

Diagramele caz de utilizare sunt trase pentru a captura cerinţele funcţionale ale unui sistem.
Astfel, după identificarea elementele de mai sus, trebuie să respectam liniile directoare
următoare pentru a desena o eficienta diagrama caz de utilizare.
  Numele unui caz de utilizare este foarte important. Deci, numele ar trebui să fie alese în
aşa fel, astfel încât să poată identifica funcţionalităţile efectuate.
 Daţi un nume potrivit pentru actori.

 Afişare relaţii şi dependenţele în mod clar în diagrama.

 Nu încercaţi să includă toate tipurile de relatii. Deoarece scopul principal al schemei

este de a identifica cerinţele.

 Utilizaţi notă atunci când vreodată necesare pentru a clarifica anumite puncte
importante.

Ceea ce urmează este un exemplu al diagramei use case care reprezintă sistemul de gestionare
al comenzilor. Deci, dacă ne uităm în diagramă atunci vom gasi trei use case-uri (Order,
SpecialOrder şi NormalOrder) şi un actor, care este clientul.

Use case-urile SpecialOrder şi NormalOrder sunt extinse de la case-ul Order , deci au o relatie
extinsa.Un alt punct important este de a identifica graniţele sistemului, care este prezentat în
imagine. Actorul Customer se află în afara sistemului deoarece acesta este un utilizator extern
al sistemului.

Unde folosim diagramele use-case?

Aşa cum am discutat deja sunt cinci diagrame în UML pentru a vizualiza modelul dinamic al
unui sistem. Acum, fiecare model are un scop specific de a fi utilizat. De fapt, aceste scopuri
specifice sunt diferite unghiuri ale unui sistem de rulare.

Deci, pentru a înţelege dinamica unui sistem avem nevoie de a utiliza diferite tipuri de
diagrame. Diagrama use case este una dintre ele şi scopul său specific este de a aduna cerinţele
de sistem şi actori. Diagramele use case specifica evenimentele unui sistem şi fluxurile lor, dar
niciodată nu descrie modul în care acestea sunt implementate. Diagrama use case poate fi
imaginata ca o cutie neagră în care numai intrarea, ieşirea şi funcţia cutiei negre este cunoscuta.
Aceste diagrame sunt utilizate la un nivel foarte ridicat de design, iar acest design de nivel înalt
este rafinat din nou şi din nou pentru a obţine o imagine completă şi practică a sistemului. Un
use case bine structurat descrie, de asemenea, conditia pre, post si excepţiile. Şi aceste
elemente suplimentare sunt folosite pentru a face cazuri de testare atunci când se efectuează
testarea.

Deşi use case-urile nu sunt un bun candidat pentru compilare si decompilare, dar totuşi ele sunt
folosite într-un mod usor diferit pentru acestea. Şi acelaşi lucru este valabil şi pentru
decompilare. În cazul de compilare diagramele use case se utilizează pentru a face cazuri de
testare şi, în cazurile de decompilare sunt utilizare pentru a pregăti detaliile cerinţelor de la
aplicatia existentă.

Deci, acestea sunt următoarele locuri în care diagramele caz de utilizare sunt utilizate:

 Cerinţa de analiză şi proiectare la nivel înalt.

 Modelarea cadrului unui sistem.

 Decompilarea.

 Compilarea..

Elementele utilizate şi notaţiile lor sunt următoarele:

Element Descriere Notaţie

Un actor este, în principiu, un utilizator al sistemului, dar poate fi şi

Actor
un alt sistem informatic care interacţionează cu sistemul analizat.

Use Case-urile se reprezintă sub forma unei elipse în interiorul căreia

Use Case
este scris numele Use Case-ului respectiv.

Asocierea este utilizată pentru a indica legătura dintre un Actor şi un

Asociere Use Case, în sensul că acel actor participă într-un fel oarecare în acel
Use Case.

Un exemplu simplu de utilizare a diagramei este următorul:

Între actori şi use case-uri pot să existe relaţii de generalizare / specializare atunci când un
actor sau un use case poate fi asimilat unei clase de actori, respectiv de use case-uri.
Relaţia de tip extensie între use case-uri
Relaţiile de tip extensie (şi implicit use case-urile de extensie) se folosesc atunci când se
modelează un comportament opţional sau excepţional, care nu condiţionează finalitatea use
case-ului de bază. De exemplu, un utilizator poate, în cazuri excepţionale să aleagă să depună o
reclamaţie după efectuarea unei comenzi:

Relaţia de tip includere

Relaţia de tip includere se foloseşte atunci când use case-ul inclus nu este o parte esenţială a
fluxului din use case-ul de bază sau este un comportament care se repetă în mai multe use case-
uri. De pildă autentificarea în sistem, deşi condiţionează introducerea unei comenzi, nu este
specific introducerii comenzii şi de asemenea, poate fi folosit în mai multe use case-uri:

Un caz de utilizare este o descriere a unei funcţionalităţi (o utilizare specifică a

sistemului) pe care o oferă sistemul. Diagrama prezintă actorii externi şi cazurile de utilizare
identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului,
aşa cum este el perceput de utilizatorii lui) nu şi din interior, precum şi conexiunile
identificate între actori şi cazurile de utilizare. Un exemplu de diagramă a cazurilor de
utilizare este prezentată în figura 2.

Figura 2: O diagramă a cazurilor de utilizare dintr-un sistem de asigurări.

3.2.2.3 Diagrama de activitate (Activity Diagram)

O diagramă de activitate prezintă fluxul secvenţelor de activitaţi şi este de obicei
folosită pentru a descrie activitaţile realizate în cadrul unei operaţii, folosind dacă este cazul
decizii şi condiţii.
Diagrama conţine stări de acţiune (action states), şi mesaje care vor fi trimise
sau recepţionate ca parte a acţiunii realizate.

Diagrama de activitate este o diagrama importanta în UML care descrie aspectele dinamice ale
sistemului. Poate fi considerata o diagramă de flux care reprezinta fluxul de control de la o
activitate la alta. . Acest flux poate fi secvenţial, ramificat sau concurent. Diagrama de
activitate se referă la toate tipurile de control al fluxului prin utilizarea diferitelor elemente.
Activitatea poate fi descrisă ca o operaţiune a sistemului.

Scop:
Scopurile de bază ale diagramei de activitate sunt similare cu cele ale celorlalte patru diagrame.
Ea surprinde comportamentul dinamic al sistemului. Celelalte patru diagrame sunt utilizate
pentru a afişa fluxul de mesaje de la un obiect la altul, dar diagrama de activitate este utilizată
pentru a arăta fluxul de mesaje de la o activitate la alta.

Activitatea este o operaţiune specială a sistemului. Diagramele de activitate nu sunt folosite

numai pentru vizualizarea dinamică a naturii unui sistem, dar acestea sunt, de asemenea,
utilizate pentru a construi sistemul de executabil cu ajutorul unor tehnici de compilare si
decompilare. Singurul lucru care lipseste din diagrama de activitate este mesajul.

Ea nu arată nici un flux de mesaje de la o activitate la alta. Diagrama de activitate este uneori
considerata ca fiind un grafic de flux, si deşi diagrama arata ca un grafic de flux dar nu este. Se
prezinta diverse fluxuri cum ar fi ramificat paralel,concurente şi singure.

Deci, scopul poate fi descris ca:

 Desenaţi activitatea fluxului unui sistem.

  Descrieţi secvenţa de la o activitate la alta.

 Descrie fluxul paralel, ramificat şi concomitent al sistemului.

Cum se deseneaza diagrama de activitate?

Diagramele de activitate sunt utilizate în principal ca un grafic de flux ce consista din activităţi
desfăşurate de către sistem. Dar, diagrama de activitate nu este tocmai un grafic de flux,
deoarece prezinta anumite capacităţi suplimentare. Aceste capacităţi suplimentare includ
ramificare, flux paralel, swimlane etc

Înainte de întocmirea unei diagrame de activitate trebuie să avem o înţelegere clară cu privire
la elementele folosite în diagrama de activitate. Elementul principal al unei diagrame de
activitate este activitatea în sine. O activitate este o funcţie realizată de către sistem. După
identificarea activităţilor avem nevoie să înţelegem modul în care acestea sunt asociate cu
constrângeri şi condiţii.

Deci, înainte de desenarea unei diagrame de activitate, ar trebui să identificam următoarele

elemente:

 Activităţi
 Asociaţie

 Starea

 Restrictii

Odata ce parametrii de mai sus sunt identificati avem nevoie pentru a face o imagine mentala a
întregului flux. Aceasta imagine mentala este apoi transformată într-o diagramă de activitate.

Ceea ce urmeaza este un exemplu de diagrama de activitate pentru sistemul de management

comandă. În diagrama, patru activităţi sunt identificate care sunt asociate cu condiţii. Un
aspect important ce ar trebui înţeles în mod clar este că o diagrama de activitate nu poate fi
compensată exact cu codul. Diagrama de activitate este facuta pentru a intelege fluxul de
activităţi şi, utilizata în principal de către utilizatorii de afaceri.

Diagrama de mai jos este reprodusa cu patru activităţi principale:

 Trimite o comandă de către client

 Primeste ordinului de comanda

 Confirmare comandă

 Expedierea comandă

După primirea cererii sunt efectuate condiţia de Order pentru a verifica dacă aceasta este
SpecialOrder sau NormalOrder. După ce tipul de ordin este identificat, activitatea de expediere
este efectuată şi acest lucru este marcat de încetarea procesului.
Unde să utilizaţi diagrame de activitate?
Utilizarea de bază a diagramei de activitate este similara cu cea a celorlalte patru diagrame
UML. Uzajul specific este de a modela fluxul de control de la o activitate la alta. Acest flux de
control nu include mesaje.

Diagrama de activitate este potrivita pentru modelarea fluxului de activitate al sistemului. O

aplicatie poate avea mai multe sisteme. Diagrama de activitate surprinde, de asemenea, aceste
sisteme şi descrie fluxul de la un sistem la altul. Acest lucru specific de utilizare nu este
disponibil în alte diagrame. Aceste sisteme pot fi de baze de date, cozi de externe sau orice alt
sistem.

Acum ne vom uita în aplicaţiile practice ale diagramei de activitate. Din discuţia de mai sus,
este clar că o diagrama de activitate este trasată de la un nivel foarte ridicat. Deci, va da o
vedere de nivel ridicat al unui sistem. Acest punct de vedere la nivel înalt este în principal
pentru utilizatorii de afaceri sau orice altă persoană care nu este o persoană tehnică.

Această diagramă este folosita pentru a modela activităţile care nu sunt altceva decât cerinţele
de afaceri. Deci diagrama are un impact mai mare pe înţelegerea de afaceri mai, decat pe
detaliile de implementare.

Urmatoarele sunt uzurile principale ale diagramei de activitate:

 Modelarea fluxului de lucru prin utilizarea de activităţi.

 Modelarea cerintelor de business.
  Înţelegere la nivel înalt a funcţionalităţilor sistemului.

 Investigheaza cerinţele de business într-o etapă ulterioară.

Figura 8: O diagramă de activitate pentru un server

de imprimantă.

3.2.2.3 Diagrama de stare (State Diagram)

Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stări prin care poate
trece un obiect şi modul în care se poate trece de la o stare la alta (modelare work-flow-uri,
modelare fluxuri de documente, diagrame de stări).

Prezentare:

Trecerea de la o stare la alta este determinată de tranzacţiile intermediare - acestea corespund

acţiunilor pe care le-am întâlnit la Activity Diagram ( Statechart Diagram reprezintă intr-un fel
un alt mod de a vedea un flux ce poate fi modelat exclusiv prin Activity Diagram, inventat
pentru a exprima mai elocvent trecerile de la o stare la alta).

Numele diagramei în sine clarifică scopul de diagramă şi alte detalii. Acesta descrie diferite
stări ale unei componente într-un sistem, aceste stari sunt specifice pentru o componentă /
obiectul unui sistem.

O diagramă Statechart descrie o maşină de stare. Acum, pentru a clarifica aceasta, maşina de
stare poate fi definită ca o maşină care defineşte diferite stări ale unui obiect şi aceste stari sunt
controlate de evenimente externe sau interne. Diagrama de activitate explicata în capitolul
anterior, este un tip special de diagramă Statechart. Deoarece diagrama Statechart defineşte
stari este folosita pentru a modela durata de viata a unui obiect.
Scop:
Diagrama Statechart este una dintre cele cinci diagrame UML utilizate pentru a modela natura
dinamică a unui sistem. Ele definesc diferite stări ale unui obiect în timpul vieţii sale. Şi aceste
stari sunt modificate de evenimente. Deci, diagrame Statechart sunt utile şi pentru sistemele
reactive modelului. Sistemele reactive pot fi definite ca un sistem care răspunde la evenimente
externe sau interne.

Diagrama Statechart descrie fluxul de control de la o stare la alta. Starile sunt definite ca o
conditie in care un obiect există şi se schimbă atunci când un eveniment este declanşat. Deci,
scopul cel mai important al diagramei Statechart este de a modela durata de viaţă a unui obiect
de la creatie pana la terminare.

Diagramele Statechart sunt, de asemenea, utilizate pentru compilarea si decompilarea unui

sistem. Dar scopul principal este acela de a modela sistemul reactiv.

Principalele scopuri ale folosirii diagrame Statechart sunt:

 Pentru modelarea aspectul dinamic al unui sistem.

 Pentru modelarea duratei de viata al unui sistem reactiv.

 Pentru a descrie diferite stări ale unui obiect în timpul duratei sale de viaţă.

 Definiţi o maşină de stare pentru a modela starile unui obiect.

Cum se deseneaza diagrama Statechart?

Diagrama este folosita pentru a descrie stările unor diferite obiecte diferite în ciclul lor de
viaţă. Astfel, accentul este pus pe seama modificărilor de stare asupra unor evenimente interne
sau externe. Aceste stări de obiecte sunt importante pentru a analiza şi a le pune în aplicare cu
acurateţe. Starile pot fi identificate ca fiind conditia obiectelor atunci când un anumit
eveniment are loc.

Înainte de întocmirea unei diagrame Statechart trebuie să avem clarificate următoarele puncte:

 Identifica obiectele importante pentru a fi analizate.

 Identifica starile.

 Identifica evenimentele.

Următorul este un exemplu de diagramă Statechart în cazul în care starea de obiect Order este
analizata. Prima stare este o starea de repaus, de unde începe procesul. Starile următoare apar
pentru evenimente cum ar fi cerere trimitere, cerere confirmare, şi expediere comanda. Aceste
evenimente sunt responsabile pentru schimbarile starilor ale unor obiecte.

În timpul ciclului de viaţă al unui obiect, se trece prin următoarele stări şi pot exista de
asemenea, niste iesiri anormale. Aceste ieşiri anormale pot să apară din cauza unor probleme în
sistem. Atunci cand întregul ciclu de viaţă este complet, este considerat ca tranzacţia completă
după cum se menţionează mai jos.

Starea iniţială şi finală a unui obiect este, de asemenea, prezentata mai jos.
Cand folosim diagrame Statechart?
Din discuţia de mai sus putem defini aplicaţiile practice ale unei diagrame Statechart.
Diagrame Statechart sunt folosite pentru a modela aspectul dinamic al unui sistem ca alte patru
diagrame dezafectate în acest tutorial. Dar are unele caracteristici distinctive pentru modelarea
natură dinamică.

Diagrama Statechart defineşte stările unei componente şi modificările acestei stari sunt
dinamice în natură. Deci, scopul său specific este de a defini schimbarile de stari declanşate de
evenimente. Evenimentele sunt factori interni sau externi care influenţează sistemul.
Diagramele Statechart sunt utilizate pentru a modela starile şi, de asemenea, evenimentele de
operare pe sistem. Atunci când se implementeaza un sistem este foarte important să se clarifice
diferitele stări ale unui obiect în timpul vieţii sal, iar diagramele statechart sunt folosite în acest
scop. Atunci când aceste stari şi evenimente sunt identificate acestea sunt utilizate pentru a
modela şi aceste modele sunt folosite în timpul punerii în aplicare a sistemului.

Dacă ne uităm la punerea în practică a diagramei Statechart, atunci este folosit în principal
pentru a analiza starile obiectului influenţat de evenimente. Această analiză este utila pentru a
înţelege comportamentul sistemului în timpul execuţiei sale.

Principale uzaje pot fi descrise ca:

 Pentru a modela starile obiectului unui sistem.

 Pentru a modela un sistem reactiv. Sistemul reactiv constă în obiecte reactive.

 Pentru a identifica evenimentele responsabile pentru modificările de stare.

 Compilare si decompilare.

De exemplu o comandă primită de la un client poate fi iniţial în stare de aşteptare, pentru ca

un operator să verifice bonitatea clientului şi stocul şi să accepte comanda. După acceptare,
 se poate produce livrarea produselor comandate şi comanda trece în starea de „comandă
livrată” după care urmează facturarea şi închiderea comenzii.

Elementele utilizate şi notaţiile lor sunt următoarele:

Element Descriere Notaţie

Stare Indică starea în care se găseşte obiectul la un moment dat.

Stare Reprezintă punctul de intrare sau punctul în care obiectul

iniţială este iniţiat. Punctul iniţial este unic.
Stare Reprezintă punctul de final când starea obiectului nu se
finală mai modifică.
Tranziţia reprezintă trecerea de la o stare la alta, provocată
Tranziţie
de apariţia unui anumit eveniment.

În afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie şi acţiunile
paralele (asincrone) la Activity diagram.

În figura de mai jos este exemplu de folosire a elementelor specifice statechart diagram, pentru
cazul unei comenzi:
Interpretarea acestei diagrame se găsesc despre Activity Diagram.

Figura5

O stare este de obicei un complement al descrierii unei clase. Asadar, o diagramă de

stare prezintă toate stările prin care trece un obiect al clasei precum şi evenimentele care-i
cauzează modificările de stare. Modificarea stării se numeşte tranziţie. Un exemplu de
diagramă de stare este prezentat în figura 5.
Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai
pentru acelea care au un număr de stări bine definit iar comportamentul clasei este
afectat şi modificat de acestea.

3.2.2.4 Diagrama de interactiune (Interaction Diagram)

Prezentare:
Din numele de Interacţiune, este clar faptul că diagrama este utilizata pentru a descrie un
anumit tip de interacţiuni între diferitele elemente ale modelului. Deci, această interacţiune este
o parte a comportamentului dinamic al sistemului.Acest comportament interactiv este
reprezentată în UML de către cele două diagrame cunoscut sub numele de diagrama de
secventa şi diagrama de colaborare. Scopurile de bază ale ambelor diagrame sunt similare.

Diagrama de secvenţă pune accent pe secvenţa de timp a mesajelor şi diagrama de colaborare

pune accentul pe organizarea structurală a obiectelor care trimit şi primesc mesaje.

Scop:
Scopul diagramelor de interacţiune este de a vizualiza comportamentul interactiv al sistemului.
Acum, vizualizarea interacţiunii este o sarcină dificilă. Deci, soluţia este de a utiliza diferite
tipuri de modele pentru a surprinde diferite aspecte ale interacţiunii.

Acesta este motivul pentru care diagramele de secventa si colaborare sunt folosite pentru a
capta natura dinamica, dar dintr-un unghi diferit.

Deci, scopurile diagramei de interacţiune pot fi descrie ca fiind:

 Pentru a capta comportamentul dinamic al unui sistem.

 Pentru a descrie fluxul de mesaje în sistem.

 Pentru a descrie organizarea structurală a obiectelor.

 Pentru a descrie interacţiunea dintre obiecte.

Cum se deseneaza diagrama de interacţiune?

Aşa cum am discutat deja, scopul diagramelor de interacţiune sunt pentru a surprinde aspectul
dinamic al unui sistem. Deci, pentru a captura aspectul dinamic avem nevoie să înţelegem ce
este un aspect dinamic şi modul în care este vizualizat. Aspectul dinamic poate fi definit ca o
imagine de moment a sistemului care rulează la un moment dat.

Avem două tipuri de diagrame de interacţiune în UML. Una este diagrama de secvenţă, iar
cealalta este o diagrama de colaborare. Diagrama de secvenţă surprinde secvenţa de timp a
fluxului de mesaj de la un obiect la altul şi diagrama de colaborare descrie organizarea de
obiecte într-un sistem care ia parte la un flux de mesaje.
Deci, lucrurile enumerate mai jos sunt identificate în mod clar înainte de desenarea diagramei
de interacţiune:

 Obiecte care iau parte la interacţiune.

 Fluxurile de mesaje printre obiecte.

 Secvenţa în care mesajele se transmit.

 Organizarea obiectului

Voi prezenta in urmatoarele randuri două diagrame de interacţiune pentru modelarea sistemului
de management. Prima diagrama este o diagrama secvenţă, iar a doua este o diagrama de
colaborare.

3.2.2.4.1 Diagrama de Secventa (Sequence Diagram)

Diagrama de secventa prezinta patru obiecte (Customer, Order, SpecialOrder şi NormalOrder).
Diagrama de mai jos a arătat secvenţa de mesaje pentru obiectul SpecialOrder şi acelaşi lucru
poate fi utilizat în cazul obiectului NormalOrder. Acum este important să se înţeleagă secvenţa
de timp a fluxurilor de mesaj. Fluxul de mesaje nu este altceva decat un apel de metoda a unui
obiect.

Primul apel este sendOrder (), care este o metodă a obiectului Order. Următorul apel este
confirm (), care este o metodă a obiectului SpecialOrder şi ultima cerere este Dispatch (), care
este o metodă a obiectului SpecialOrder. Deci, aici diagrama descrie în principal, metoda de
apeluri de la un obiect la altul şi acest lucru este, de asemenea, scenariul real atunci când
sistemul este pornit.
 Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul este
reprezentat pe axa verticală de sus în jos. Mesajele sunt reprezentate prin săgeţi între
linile verticale ce corespund obiectelor implicate în mesaj.

Figura 6: Diagrama de secvenţă pentru un server de imprimantă

3.2.2.4.2 Diagrama de colaborare (Collaboration

Diagram)
A doua diagrama de interactiune este diagrama de colaborare.Aceasta prezinta organizarea
obiectelor aşa cum se arată mai jos. Aici, în diagrama de colaborare, secvenţa metodei de apel
este indicată printr-o tehnica de numerotare după cum se arată mai jos. Numărul indică modul
în care metodele sunt solicitate una după alta. Am luat acelaşi sistem de management pentru a
descrie diagrama de colaborare.

Cum decidem ce tip de diagramă să folosim? Dacă cel mai important aspect este timpul
sau secvenţa de mesaje vom folosi diagrama de secvenţă, dar dacă trebuie scos în evidentă
contextul, vom apela la o diagramă de colaborare.

Metodele solicitate sunt similare cu cea a unei diagrama secvenţă. Dar diferenţa este că
diagrama de secvenţă nu descrie organizarea obiectelor, in timp ce diagrama de colaborare
prezinta organizarea obiectelor.

Acum, pentru a alege între aceste două diagrame, accentul principal este dat de tipul de cerinţă.
În cazul în care secvenţa de timp este importanta, atunci diagrama de secventa este utilizata şi
în cazul în care organizarea este necesară, atunci diagrama de colaborare este utilizata.
 Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor.
Mesajele vor fi reprezentate prin săgeţi între obiectele implicate în mesaj şi pot fi însoţite de
etichete care specifică ordinea în care acestea vor fi transmise. De asemenea se pot vizualiza
condiţii, iteraţii, valori returnate, precum şi obiectele active care se execută concurent cu alte
obiecte active (vezi figura 7).

Figura 7: O diagramă de colaborare pentru un server de imprimantă.

Cand folosim diagramele de interacţiune?

Am discutat deja că diagramele de interacţiune sunt folosite pentru a descrie natura dinamică a
unui sistem. Acum ne vom uita în scenariile de practică în cazul în care aceste diagrame sunt
folosite. Pentru a înţelege aplicarea în practică avem nevoie să înţelegem natura de bază a
secvenţei şi diagrama de colaborare.

Principalele scopuri ale ambelor diagrame sunt similare, deoarece ambele sunt folosite pentru a
capta comportamentul dinamic al unui sistem. Dar scopurile specifice sunt mai importante
pentru a clarifica şi a intelege.

Diagramele de secventa sunt utilizate pentru a captura ordinea de mesaje care se transmit de la
un obiect la altul. Şi diagramele de colaborare sunt folosite pentru a descrie organizarile
structurale ale obiectelor care iau parte la interacţiune. O singura diagramă nu este suficientă
pentru a descrie aspectul dinamic al unui întreg sistem, astfel este folosit un set de diagrame
pentru a captura tot sistemul ca un întreg.

Diagramele de interacţiune sunt utilizate atunci când vrem să înţelegem fluxul de mesaje şi
organizarea structurală. Acum, flux de mesaje înseamnă secvenţa de debit de la un obiect la
altul şi organizarea structurală înseamnă organizarea vizuala a elementelor într-un sistem.

Acestea sunt următoarele intrebuintari ale diagramei de interacţiune:

 Pentru a modela fluxul de control de către secvenţa de timp.

 Pentru a modela fluxul de control de către organizarile structurale.

 Pentru compilare.

 Pentru decompilare.

4. Concluzii
Cu multi ani in urma, programatorii dezvoltau diverse programe fără o bună analiză şi o
bună proiectare a respectivelor programe. Avand in vedere ca faza de analiză şi proiectare a
unui sistem informatic trebuie să fie gata înainte de realizarea codului, era necesara o atenţie
mărită din partea dezvoltatorilor. Multe dintre aceste etape au fost ignorate în trecut, dar cu
timpul dezvoltatorii au inceput sa recunoasca importanţa acestor faze, deoarece s-a dovedit
că de acestea depinde producerea de software adecvat şi competitiv.
Limbajele de modelare au fost create pentru analiza şi proiectarea sistemelor, iar unul din
aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling
Language). El reprezinta limbajul universal standard pentru dezvoltatorii software din toată
lumea. UML este foarte popular si folosit deoarece deţine o expresivitate foarte buna care
ajută la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau.
UML oferă arhitecturi de sisteme ce funcţionează pe analiza şi proiectarea obiectelor
cu un limbaj corespunzător pentru specificarea, vizualizarea, construirea şi documentarea.
Notaţiile UML constituie un element esenţial al limbajului pentru realizarea propriu-zisă a
modelării şi anume, partea reprezentării grafice pe care se bazează orice limbaj de modelare.
Mai pe scurt, ideea de baza este ca este absolut necesar să cunoaştem principalele
elemente ale unui limbaj de modelare înainte de a iniţia proiectarea şi dezvoltarea unui
sistem.
5.Bibliografie
http://www.techit.ro/tutorial_uml.php

http://www.scribd.com/doc/46196747/Uml

http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf

http://www.tutorialspoint.com/uml/uml_component_diagram.htm

Gheorghe Andrei Avram (2002) - Sisteme informationale, Editura Aisteda

MasteringUMLwithRationalRose2002

Wiley - Enterprise Java with UML

Bédard, Y. (1999) - Visual Modeling of Spatial Databases: Towards Spatial PVL

and UML, Geomatica, vol. 53, no. 2, pg. 169-186;

Brown, A.W. ş.a. (1994) - Principles of CASE Tool Integration, Oxford

University Press, Oxford;

Fowler, M. (2000) - UML Distilled, A Brief Guide to the Standard Object

Modeling Language, Addison-Wesley;

Gheorghieş, O., Apetrei, A. (2003) - Ingineria Programării, Facultatea de

Informatică, Universitatea "Al. I. Cuza", Iaşi;

Giurcă, A. (2004) - Proiectare în UML, Universitatea din Craiova, Facultatea de

Matematică - Informatică;

Ioniţă, A.D. (2003) - Modelarea UML în ingineria sistemelor de programe, Ed.

BIC ALL, Bucureşti, 2003
Repartizarea documentatiei:

Berevoianu Adelina
3.2.2 Diagrame comportamentale
3.2.2.1 Diagrama cazurilor de utilizare (Use Case Diagram)
3.2.2.2 Diagrama de activitate (Activity Diagram)
3.2.2.3 Diagrama de stare (State Diagram)
3.2.2.4 Diagrama de interactiune (Interaction Diagram)
3.2.2.4.1 Diagrama de Secventa (Sequence Diagram)
3.2.2.4.2 Diagrama de Colaborare ( Collaboration Diagram)

Epure Adriana
3.2.1 Diagrame structurale
3.2.1.1 Diagrama claselor (Class Diagram)
3.2.1.2 Diagrama obiectelor (Object Diagram)
3.2.1.3 Diagrama componentelor (Component Diagram)
3.2.1.4 Diagrama de desfăşurare (Deployment View)

Tinta Mihaita
1. Introducere
2. Strategii de formalizare
2.1 Arhitectura UML
2.2 Modele
3. Modelarea cu UML
3.1 View-uri
4. Concluzii