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.

UML este un element fundamental pentru Model-Driven Architecture ®, care reprezinta legaturile
dintre mediul de afaceri si mediul de programare, prin modelarea arhitecturala şi aplicarea lor in
dezvoltare, implementare, întreţinere şi evoluţie.

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;

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.

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

Descrie modul de functionare al aplicatiei. Diagrama prezintă actorii externi (ex. client, server) ,
cazurile de utilizare identificate precum şi conexiunile dintre actori. Nu descrie modul interior de
functionare al aplicatiei. Un exemplu de diagramă a cazurilor de
utilizare este prezentată în figura 2.

Figura 2 O diagrama a cazurilor de utilizare dintr-un sistem de asigurari.

3
Diagrama claselor (Class Diagram)
O diagramă a claselor prezintă structura fizică a claselor identificate în sistem. Clasele
reprezintă “obiecte” 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 aplicatiei. Un exemplu de diagramă a claselor este prezentat în figura 3.

Figura 3 Diagrama claselor.

Diagrama obiectelor (Object Diagram)
Acest tip de diagramă este o varianta a diagramei claselor care în locul unei clase

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

Figura 4 O diagrama a claselor si o diagrama a obiectelor (instantele 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.

5
 Figura 5 O diagrama de stare pentru un ascensor.
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.

6
 Figura 6 Diagrama de secventa pentru un server de imprimanta.
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).

7
 Figura 7 O diagrama de colaborare pentru un server de imprimanta.
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.

Figura 8 O diagrama de activitate pentru un server de imprimanta.

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.

8
 Figura 9 O diagrama a componentelor.
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 10 O diagrama de desfasurare care prezinta structura fizica a sistemului.

9
 3. Versiuni UML
Versiunea Data Aparitiei Descriere
1.4 09-2001 Cea mai importanta schimbare adusa de UML 1.4 consta in adaugarea profilurilor,
ceea ce permite colectarea unui grup de extensii intr-un ansmblu coherent.
Documentatia UML contine doua exemple de profiluri. Totdata , formalismul
definirii de stereotipuri a crescut si elementele modelului au putut avea mai
multe stereotipuri, in timp ce in UML 1.3 exista unul singur.

S-a lucrat asupra vizibilitatii pachetelor Java in metamodele si asupra marcarii

asincronismelor prin sageti in diagrame de secventa.
2.0 08-2005 Una din cele mai importante schimbari este cea legata de tipurile de diagrame.
Diagramele de obiecte si diagramele de pachete devin diagrame oficiale.
Diagramele de colaborare devin diagrame de comunicare. In aceasta versiune sunt
introduce, de asemenea, noi tip de asamblu a interactiunilor, timing si structuri
composite.

Atributurile si asocierile unidirectionare devin doua notatii esential diferite pentru

a reprezenta conceptul sub-adiacent de proprietate. S-au adaugat noi cuvinte cheie
pentru dependente. Cuvintele cheie <<parameter>> si <<local>> nu se mai
utilizeaza.

Diagrame de secventa:

Modificarea cea mai importanta este notatia cadrelor de interactiune, care permite
gestionarea structurilor interative, conditionale si a altor structuri de control a
comportamentului. Puteti exprima aproape in intregime algoritmii in diagramele
de secventa. Vechile marcaje de iteratii si notatiile lor au fost abandonate. Antetele
de linii de viata nu mai sunt instante, acestea fiind definite prin termenul
participant. Diagramele de colaborare se numesc acum diagrame de comunicare.

Referitor la diagramele de clase: concept avansate

Stereotipurile sunt definite de o maniera mai stricta. In consecinta, exista cuvinte

cheie pentru a define expresiile intre ghilimele, numai unele dintre acestea din
urma fiind stereotipuri. In diagramele de obiecte, instantele sunt acum specificatii
de instante. Clasele pot solicita interfete si le pot realiza. Clasificarea multipla
utilizeaza ansamblu de generalizare pentru a regrupa generalizarile. Componentele
nu mai sunt reprezentate printr-un simbol special. Obiectele active au linii duble
vertrical in loc de linii groase.

Diagramele de stare

Daca UML 1 facea distinctia intre actiuni si activitati, UML 2 numeste cele doua
10
 activitati si utilizeaza acest termen in toate cazurile.

Diagramele de activitati

UML 1 trata diagramele de activitati ca pe un caz particular al diagramelor de

stare. UML 2 a rupt legatura intre acestea si a suprimat regulile de corespondenta a
ramificatiilor si jonctiunilor pe care le instaurase UML 1. Au aparut noi notatii,
printre care acelea de semnale temporare si de acceptare, paramatri, specificatii de
jonctiune, conectori, transformatori de fluxuri, greble de sub-diagrame, regiuni de
expansiune si terminatii de fluxuri. UML 1 considera mai multe fluxuri de intrare
intr-o activitate ca pe o fuziune implicita, in timp ce UML 2 le trateaza ca pe o
jonctiuni implicita. Pentru a evita confuziile, recomandam utilizarea fuziunilor si
jonctiunile explicite in diagramele de activitati.
2.1 04-2006 Modificari minore fata de versiunea UML 2.0 - corecţii şi îmbunătăţiri de
consistenţă.
2.1.1 02-2007 Modificari minore fata de versiunea UML 2.1
2.1.2 11-2007 Modificari minore fata de versiunea UML 2.1.1
2.2 02-2009 Imbunatatirea aduse numeroaselor probleme de consistenta si adaugarea unor
clarificari la UML 2.1.26

4. Tool-uri pentru generarea diagramelor UML

Exista mai multe tipuri de programe utilizate.

In functie de tipul licentei acestea se impart in :

• Freeware (soft gratuit) - care sunt puse la dispozitia tuturor utilizatorilor. Ex.: StarUML,
UMLet, ArgoUML .

• Commercialware (contra cost) – profesionale, prezinta un set mai mare de optiuni pentru
realizarea diagramelor. Ex.: Altova Umodel, Edraw UML Diagram.

In functie de interactiunea cu IDE (Integrated Development Environment)

• Independente de IDE. Ex.: Altova Umodel, StarUML.

 Altova Umodel - > OS: Microsoft Windows

- > v. 2011 Service Pack 1 (SP1)

 StarUML - > OS: Microsoft Windows

- > v.5.0, 30 Decembrie 2005

11
 • Pluginuri pentru IDE. Ex.: MaintainJ Plugin, SDE IntelliJ IDEA.

 MaintainJ Plugin -> OS: Cross-platform

- > IDE: min. Eclipse 3.2

- > v 2.9, 29 Martie 2010

 SDE IntelliJ IDEA - > OS: Cross-platform

- > IDE: min. Intelli JIDEA 9

- > v 4.0, 16 Octombrie 2010

Ultima vesiune de UML este 2.3.

4.1 Instalarea unui plugin in Eclipse

Pasi necesari:

1. Programele necesare pentru instalarea plugin-ului sunt disponibile pe site-ul

http://www.eclipse.org/modeling/mdt/downloads/?project=uml2tools. Prima data se
instaleaza programele din categoria Build Dependencies, ulterior cele din sectiunea UML2
Tools.

2. Din interiorul programului Eclipse se selecteaza categoria Help->Install new software. In

noua fereastra care se va deschide vom introduce cuvantul cheie “model” pentru a gasi toate
plugin-urile necesare modelarii diagramelor UML. Se vor selecta toate plugin-urile
mentionate in pasul anterior.
12
3. Dupa instalarea plugin-urilor, diagramele UML se pot crea prin selectarea meniului File-
>New->Other->UML 2.1 Diagrams->Class Diagram.

13
4. In continuare vom selecta proiectul a carui diagram o vom realiza.

5. Selectam noul fisier .uml creat. Din cadrul sectiunii palette vom selecta tipul de element pe
care dorim sa il cream: clase, interfete, variabile, etc.

14
6. In continuare se pot realiza diagramele dorite cu ajutorul elemetelor puse la dispozitie de
meniul “Palette”.

4.2 Generare diagrame utilizand aplicatia Altova Umodel 2009

Pasi necesari:

1. Descarcarea (contra cost) si instalarea aplicatie de pe sit-ul producatorului:

http://www.altova.com/download/umodel/uml_tool_enterprise.html

15
2. Creeare proiect nou utilizand optiunea File -> New din meniu

3. Importarea fisierelor ce contin codul aplicatiei dupa care se vor genera diagramele.
(utilizand meniul Project -> Import Binary Tipes )

16
Se adauga fisierele necesare.

17
4. Dupa adaugarea fisierelor din fereastra Model Tree se pot genera diagramele dorite.
(click dreapta pe numele pachetului ce contine fisierele aplicatiei -> Show in new
diagram -> content).

18
Selctarea tipului de diagrama dorit.

19
 5. Exemplu de diagrame generate:

-Diagrama de clase

-Analog in cazul in care aplicatia are mai multe pachete (diagrama de pachete).
20
5. Diagrame statice vs. Dinamice
• Diagrame statice: Prezinta structura statica a unui model, cu alte cuvinte elementele care
exista (clasele, atributele, metodele, etc.), structura interna a elementelor si relatiile dintre
ele. Sunt utilizate pentru a creea diagrame care reprezinta concepte din lumea reala si
relatiile dintre ele sau diagrame de clase care descompun un sistem software in partile
sale componente.

• Diagrame dinamice: Sunt diagrame realizate la un moment dat in timpul rularii unui
program. Acestea descriu obiectele active la un moment dat si relatiile dintre ele si difera
21
 in functie de momentul in care este surprins programul in timpul rularii (Ex. diagrame de
secventa, diagrame de stare, diagrame de activitate).

6. Notatii UML:

Figura 11 Reprezentarea grafică în UML a unei agregări partajate

Figura 12 Reprezentarea grafică în UML a unei compoziţii

Figura 13 Reprezentarea grafică în UML a unei tranziţii

Figura 14 Reprezentarea grafică în UML a unei dependenţe

22
Figura 15 Reprezentarea grafică în UML a unei relaţii de derivare

Figura 16 Reprezentarea grafică în UML a unei relaţii de extensie

Figura 17 Reprezentarea grafică în UML a unei relaţii de realizare

Figura 18 Simbolul folosit în UML pentru reprezentarea interfeţelor

Figura 19 Simbolul folosit in UML pentru reprezentarea interfetelor

Figura 20 Simbolul folosit în UML pentru reprezentarea claselor

23