Introducere în UML

Introducere in UML 1 

1. Aparitie si evolutie 

Introducere în UML 

UML este un limbaj vizual de modelare, el nu este încă un limbaj vizual de programare, 

deoarece nu dispune de întreg sprijinul semantic şi vizual pentru a înlocui limbajele de 

programare. Limbajul este destinat vizualizării, specificării, construirii şi documentării 

sistemelor de aplicaţii, dar are limitări în ceea ce priveşte generarea codului. UML reuneşte 

cele mai bune tehnici şi practici din domeniul ingineriei programării, care şi-au dovedit 

eficienţa în construirea sistemelor complexe. 

Câteva date semnificative referitoare la apariţie şi evoluţie: 

În octombrie 1994, Grady Booch lider stiinţific la Rational Corporation, autor 

al metodei ce-i poartă numele şi a unor cărţi de referintă în domeniu face echipă 

cu James Rumbaugh, autorul principal al metodei OMT, pe care-l determină să-si 

părăsească (cel puţin temporar) vechiul loc de muncă (General Electric) şi să 

treacă la firma Rational. După un an de activitate Booch şi Rumbaugh, prezintă în 

octombrie 1995 cu ocazia conferinţei OOPSLA, caracteristicile de bază ale unei 

noi metode de analiză şi proiectare, rezultată prin unificarea Metodei lui Booch 

(OOD) cu OMT, metodă denumită Metoda unificată (Unified Method). Prima 

documentaţie a metodei menţionată anterior a fost făcută publică în decembrie 

1995, având numărul de versiune 0.8. La sfârsitul aceluiaşi an celor doi li se 

alatură şi Ivar Jacobson. 

In iunie 1996 apare versiunea 0.9, urmată la scurt timp, octombrie 1996, de 

apariţia versiunii 0.91. Versiunea 0.9 aduce şi schimbarea denumirii din Metoda 

unificată (Unified Method) în Limbajul unificat de modelare (Unified Modeling 

Language). Cooptarea lui Jacobson în echipă se concretizează printre altele în 

detalierea conceptului de cazuri de utilizare (use case) şi prezentarea unei descrieri 

mai amănunţite pentru diagramele cazurilor de utilizare. Conceptul de stereotip 

este mai bine explicitat, se modifică denumirile unor diagrame. 

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com


La 11 ianuarie 1997 este prezentată versiunea 1.0 care, însoţită de o 

documentaţie mult mai detaliată decât versiunile precedente, este trimisă către 

OMG pentru standardizare. 

1 septembrie 1997, a reprezentat un alt moment deosebit de important. 

Rational şi alte firme care spijina UML, printre care şi doi fosti competitori, 

IBM/ObjectTime şi Taskon/Reich, a propus OMG o nouă versiune 1.1. Noutatea 

semnificativă pentru această versiune o reprezintă introducerea limbajului OCL, 

un limbaj folosit pentru descrierea regulilor de corectitudine ale metamodelului 

UML. 

La 17 noiembrie 1997, OMG a anuntat adoptarea specificaţiei UML ca limbaj 

standard de modelare 

Schimbarea denumirii din Metoda Unificată în Limbaj de Modelare Unificat a fost 

justificată prin: 

reacţiile primite din partea utilizatorilor care au sugerat că este mult mai 

important să se acorde o atenţie sporită conceptelor utilizate în dezvoltarea 

aplicaţiilor. Recomandările referitoare la desfăşurarea etapelor de realizare şi 

înlăntuirea lor au fost lăsate în planul secund, 

faptul că eforturile de unificare au fost concentrate asupra limbajului grafic de 

modelare, asupra semanticii lui şi abia după aceea asupra modului de utilizare a 

conceptelor, 

UML a fost conceput ca un limbaj universal care să fie utilizat la modelarea 

sistemelor (indiferent de tipul şi scopul pentru care au fost construite), la fel cum 

limbajele de programare sunt folosite în diverse domenii. 

Sublinierea aspectelor de limbaj nu semnifică nicidecum ignorarea modului de folosire 

a lor. UML presupune că metodologia este “ghidată” de cazurile de utilizare, că ea se bazează 

pe arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ şi incremental. 

Detaliile acestui proces trebuie adaptate la domeniul aplicaţiei, la modul de organizare al 



echipei de realizatori, la experienţa echipei. UML nu tratează aspecte de metodologie, 

permitând astfel separarea limbajului de modelare de procesul aplicării metodologiei. 

2. Principalele părţi ale UML 

Principalele parti ale UML sunt: 

Vederile (View) – surprind aspecte particulare ale sistemului de modelat. Un 

view este o abstractizare a sistemului, iar pentru construirea lui se folosesc un număr 

de diagrame. 

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. 

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. 

2.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; 

cod; 

Non-funcţional: necesarul de timp pentru dezvoltarea sistemului 

Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de 



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 

nt 

View-ul 

de 

desfaşurare 

View-ul 

Cazurilor 

de Utilizare 

View-ul 

Logic 

View-ul 

de concurenţă 



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ăsurare (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. 



2.2 Diagrame 

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ă. 

Diagrama cazurilor de utilizare (Use Case Diagram) 

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. 

Client 

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

Diagrama claselor (Class Diagram) 

Semnarea unei 

poliţe de asigurare 

Situaţia 

vânzărilor 

Situaţia 

clienţilor 

Societate 

de asigurări 

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 considerată statică, în sensul că este validă în orice moment din ciclul de 

viaţă al sistemului. Un exemplu de diagramă a claselor este prezentat în figura 3. 

Companie 

de asigurări 

Figura 3: O diagramă a claselor pentru un sistem de asigurări. 

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 (vezi 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. 

1 are 0..* 

apartine 

Poliţa de 

asigurare 

expimă 

Contract de 

asigurare 

0..* 

refera 

0..1 

are 

Persoana 

este expimat prin 

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com 

1..* 

1


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

Diagrama de stare (State Diagram) 

O stare este de obicei un complement al descrierii unei clase. 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. 

M 

ută la 

Angajat 

nume:String 

virsta:Integer 

Popescu:Angajat 

nume=”Popescu Ion” 

virsta=30 

La parter 

soseste la parter 

Mută jos 

foloseste 

0..1 1..* 

do/ schimba nivelul 

Time-out 

urca (etaj) 

soseste 

Calculator 

nume:String 

memorie:Integer 

PC Servici:Calculator 

nume=”Dell 466” 

memorie=64 

PC Acasa:Calculator 

nume=”Compaq 

Pentium MMX” 

Mută sus 

do/ schimbă nivelul 

soseste 

Staţionează 

timp=0 

do/creşte timp 

Figura 5: O diagramă de stare pentru un ascensor 


Diagrama claselor 

Diagrama obiectelor 

urcă (etaj)


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. 

Diagrama de secvenţă (Sequence Diagram) 

O diagramă de secvenţă prezintă colaborarea dinamică între un număr de obiecte (vezi 

figura 6), mai precis secvenţele de mesaje trimise între acestea pe măsura scurgerii timpului. 

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. 

:Calculator :Server de imprimanta :Imprimanta :Coada 

Print (fisier) [imprimanta liberă] 

Print (fişier) 

[imprimanta ocupată] 

Stochează (fişier) 

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

Diagrama de colaborare (Collaboration Diagram) 

Această 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). 



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. 

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). 

:Calculator 

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

Diagrama de activitate (Activity Diagram) 

O diagramă de activitate prezintă fluxul secvenţelor de activitaţi, ca în figura 8, şi este 

de obicei folosită pentru a descrie activitaţile realizate în cadrul unei operaţii, folosind dacă 

este cazul decizii şi condiţii. 

1: Print (fisier) 

[imprimanta liberă] 

1.1: Print(fişier) 

:ServerImprimantă :Imprimanta 

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. 

[imprimanta ocupată] 

1.2: Stochează(fişier) 

:Coada de aşteptare 



FereastraClient.AfiseazaTotiClientii() Afişează pe ecran 

fereastra de mesaj 

“Printing” 

Figura 8: O diagramă de activitate pentru un server de imprimantă. 

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. 

Main 

Class 

(main.cpp) 

Window 

Hander 

(whnd.cpp) 

Command 

Hander 

(comhnd.cpp) 

Şterge 

fereastra de 

mesaj 

[disc full] 

[spaţiu liber pe disc] 

^Printer.Print(fisier) 

Window 

Hander 

(whnd.obj) 

Command 

Hander 

(comhnd.obj) 

Main 

Class 

(main.obj) 

Figura 8: O diagramă a componentelor 

Afişează mesajul 

“Disc Full” 

pe ecran 

Afişeaza mesajul 

“Printing” 

pe ecran 

Creaza 

fişierul 

postscript 


Graphic 

Lib 

(graphic.dll) 

Program 

Client 

(client.exe)


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. 

Client A: 

Compaq 

Pro PC 

Client B: 

Compaq 

Pro PC 

 

 

Application 

Server: 

Silicon 

Graphics O2 

 

Database 

Server: 

Oracle 

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

Introducere în UML

Create successful ePaper yourself

Delete template?

Save as template?