Introducere in UML 1

Introducere în UML

1. Aparitie si evolutie
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

 Introducere in UML 2

Ø 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

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

 Introducere in UML 3

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;
Ø Non-funcţional: necesarul de timp pentru dezvoltarea sistemului
Ø Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de
cod;

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

 Introducere in UML 4

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.

View-ul View-ul
Componentelor Logic
nt View-ul
Cazurilor
de Utilizare
View-ul View-ul
de de concurenţă
desfaşurare

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.

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

 Introducere in UML 5

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.

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

 Introducere in UML 6

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.

Semnarea unei
poliţe de asigurare

Client
Situaţia Societate
vânzărilor de asigurări

Situaţia
clienţilor

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

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

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

 Introducere in UML 7

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

Poliţa de
asigurare

0..1

expimă este expimat prin

1
1 are 0..* Contract de
Companie
asigurare
de asigurări apartine

0..*
refera are

1..*
Persoana

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.

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

 Introducere in UML 8

Calculator
Angajat
foloseste
nume:String Diagrama claselor
nume:String 0..1 1..* memorie:Integer
virsta:Integer

PC Servici:Calculator

nume=”Dell 466”
Popescu:Angajat
memorie=64
Diagrama obiectelor
nume=”Popescu Ion”
virsta=30

PC Acasa:Calculator

nume=”Compaq
Pentium MMX”

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.

urca (etaj) Mută sus

La parter
do/ schimbă nivelul

soseste la parter

urcă (etaj)
M soseste
ută la
Staţionează
Mută jos timp=0
soseste
do/creşte timp
do/ schimba nivelul

Time-out

Figura 5: O diagramă de stare pentru un ascensor

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

 Introducere in UML 9

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

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

 Introducere in UML 10

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 :Coada de aşteptare

[imprimanta ocupată]
1.2: Stochează(fişier)

1: Print (fisier)

[imprimanta liberă]
1.1: Print(fişier)
:ServerImprimantă :Imprimanta

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

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

 Introducere in UML 11

Afişează mesajul
[disc full] “Disc Full”
FereastraClient.AfiseazaTotiClientii() Afişează pe ecran pe ecran
fereastra de mesaj
“Printing”

Afişeaza mesajul
[spaţiu liber pe disc] “Printing”
pe ecran

Şterge ^Printer.Print(fisier) Creaza

fereastra de fişierul
mesaj postscript

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.
Window
Hander
(whnd.cpp)
Window Graphic
Hander Lib
(whnd.obj) (graphic.dll)

Command
Hander
(comhnd.cpp)
Program
Command
Client
Hander (client.exe)
(comhnd.obj)

Main
Class
(main.cpp)

Main
Class
(main.obj)

Figura 8: O diagramă a componentelor

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

 Introducere in UML 12

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: <<TCP/IP>>
Compaq
Pro PC
<<Net 8>>
Application Database
Server: Server:
<<TCP/IP>>
Silicon Oracle
Graphics O2

Client B:
Compaq
Pro PC

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

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