Limbajul de modelare unificat (UML) 1

Limbajul de modelare unificat (UML)

2009-2010
 Limbajul de modelare unificat (UML) 2

CUPRINS

1. Introducere 3
2. Strategii de formalizare 6
2.1 Arhitectura UML 6
2.2 Modele 7
3. Modelarea cu UML 8
3.1 View-uri 9
3.2 Diagrame 11
4. Concluzii 17
5. Bibliografie 19
 Limbajul de modelare unificat (UML) 3

1. Introducere

Pentru analiza si proiectarea programelor s-au creat limbajele de modelare. Unul din
aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling
Language).
UML nu este un simplu limbaj de modelare orientat pe obiecte, ci în prezent, este
limbajul universal standard pentru dezvoltatorii software din toata lumea. UML este
succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare orientate pe
obiecte (Booch, OMT, and OOSE). Uml se constituie din unirea acestor limbaje de modelare
si în plus detine o expresivitate care ajuta la rezolvarea problemelor de modelare pe care
vechile limbaje nu o aveau. 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.
Limbajul de modelare modificat (UML - The Unified Modeling Language) ofera
arhitecturi de sisteme ce functioneaza pe analiza si proiectarea obiectelor cu un limbaj
corespunzator pentru specificarea, vizualizarea, construirea si documentarea artefactelor
sistemelor sofware si de asemenea pentru modelarea în întreprideri. 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 (reprezintă)
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. UML reuneşte cele mai bune tehnici şi practici din domeniul ingineriei
programării, care şi-au dovedit eficienţa în construirea sistemelor complexe.
Aşa cum spune şi vorba populară, „o imagine exprimă cât o mie de cuvinte”. Mai mult
decât atât, cele o mie de cuvinte pot fi ambigue sau pot fi interpretate diferit. Aşa cum ştim,
fiecare cuvânt poate avea mai multe sensuri (iar în limba română aproape orice frază poate fi
 Limbajul de modelare unificat (UML) 4

interpretată lejer ca o propunere indecentă). Cu siguranţă că exprimarea cea mai sofisticată,

mai completă şi mai sigură se poate face direct în limbaj de programare, care, cel puţin după
ştiinţa mea, rareori lasă loc de interpretări.
Î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ânt1' să
fie înţeles, să ştim unde şi cum se foloseşte, astfel încât să ne putem exprima în „fraze1'
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.
 Limbajul de modelare unificat (UML) 5

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.

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
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ă nici decum ignorarea modului de
folosire a lor. UML presupune că metodologia este "ghidată" de cazurile de utilizare,
 Limbajul de modelare unificat (UML) 6

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. Strategii de formalizare

Strategiile de formalizare considerate sunt legate de una din cele doua abordari care au
fost investigate relativ la UML. Abordarea adoptata îsi propune descrierea UML la meta-
nivel. Avantajele acestei abordari este utilitatea acesteia particulara de a investiga
ambiguitatile din meta-modelul UML si devine astfel un mijloc de a dezvolta reguli generale
si tehnici pentru constructia, manevrarea si rafinarea diagramelor UML.
Cealalta abordare este una tranzactionala. Aceasta atribuie o semantica fiecarei
diagrame UML prin translatarea acesteia într-o formula de logica modala. Deoarece logica
modala ar e semantici bine definite, translatia da o semantica fiecarei diagrame. Tehnicile de
probare care au fost dezvoltate pentru logica modala pot fi, în consecinta, aplicate, formulei
astfel rezultate. Aceasta abordare este utila pentru probarea proprietatilor relative la sisteme
exprimate prin diagrame UML (în opozitie cu diagramele UML însele).
2.1 Arhitectura UML

Pentru a întelege arhitectura UML se considera modul în care programele si limbajele

de programare sunt relationate între ele. Exista multe limbaje de programare, pe de o parte, iar
fiecare program este dezvoltat utilizând un limbaj de programare specific. Toate aceste
limbaje vor sustine diferite constructii declarative pentru a declara datele, aspectele
procedurale, definirea logicilor care manipuleaza datele. Deoarece modelul este o
abstractizare, fiecare dintre aceste concepte 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 ntr-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
 Limbajul de modelare unificat (UML) 7

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
 Limbajul de modelare unificat (UML) 8

- 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
 Limbajul de modelare unificat (UML) 9

 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
 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:

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

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

 Limbajul de modelare unificat (UML) 10

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 pe care le vom prezenta pe scurt în cele ce
urmează. Diagramele UML pot fi împărţite în: diagrame pentru modelarea structurii statice şi
diagrame pentru modelarea comportamentului.
 Limbajul de modelare unificat (UML) 11

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.

2. 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ă.
 Limbajul de modelare unificat (UML) 12

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.

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
(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. Un exemplu de diagrama a claselor este prezentat in figura 3.

Figura 3: O diagramă a claselor

pentru un sistem de asigurări.
 Limbajul de modelare unificat (UML) 13

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.

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

Diagrama de stare (State Diagram)

Figura5
 Limbajul de modelare unificat (UML) 14

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

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

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).
 Limbajul de modelare unificat (UML) 15

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.

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.
 Limbajul de modelare unificat (UML) 16

Figura 8: O diagramă 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 9: O diagramă de desfaşurare care prezintă structura fizică a sistemului.

 Limbajul de modelare unificat (UML) 17

4. Concluzii

În trecut, programatorii dezvoltau programe fără o bună analiză şi o bună proiectare a

respectivelor programe. Faza de analiză şi proiectare a unui sistem informatic trebuie să fie
gata înainte de realizarea codului, pentru a obţine o atenţie mărită din partea diverşilor
dezvoltatori. Aceste etape au fost ignorate în trecut, dar în prezent orice dezvoltator
recunoaşte importanţa acestor faze, deoarece s-a dovedit că de acestea depinde producerea de
software adecvat şi competitiv.
Pentru analiza şi proiectarea sistemelor s-au creat limbajele de modelare. Unul din
aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling
Language).
UML nu este un simplu limbaj de modelare orientat obiect, ci în prezent, este limbajul
universal standard pentru dezvoltatorii software din toată lumea. UML deţine o
expresivitate, care ajută la rezolvarea problemelor de modelare pe care vechile limbaje nu o
aveau.
În prezent, 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.
Este absolut necesar deci să cunoaştem principalele elemente ale unui limbaj de
modelare înainte de a iniţia proiectarea şi dezvoltarea unui sistem, mai ales dacă acesta este
atât de complex ca sistemul informatic cadastral. Vom încerca, drept preocupare de viitor, să
introducem prezentarea sub formă de diagrame UML chiar în procesul de prezentare didactică
a unor fluxuri de activitate - nu neapărat din domeniul cadastral, deoarece modalitatea aceasta
de descriere este mult mai inteligibilă şi mai fidelă, precum şi mai uşor de asimilat, reţinut şi
reprodus, dezvoltând totodată şi logica celor care o studiază.
 Limbajul de modelare unificat (UML) 18

BIBLIOGRAFIE:

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

2. Badea, A.C. (2004) - Contribuţii privind integrarea cadastrului general şi a cărţii funciare,
3. Badea, G., Badea, A.C., Sion, I.G. (2004) - Sisteme Informatice de Evidenţă Cadastrală, Curs
postuniversitar de perfecţionare, volumul I, modulul A, "Evidenţă cadastrală", Ed. Conspress,
Bucureşti;
4. Bédard, Y. (1999) - Visual Modeling of Spatial Databases: Towards Spatial PVL and UML,
Geomatica, vol. 53, no. 2, pg. 169-186;
5. Brown, A.W. ş.a. (1994) - Principles of CASE Tool Integration, Oxford University Press,
Oxford;
6. Fowler, M.(2000) - UML Distilled, A Brief Guide to the Standard Object Modeling Language,
Addison-Wesley;
7. Gheorghieş, O., Apetrei, A. (2003) - Ingineria Programării, Facultatea de Informatică,
Universitatea "Al. I. Cuza", Iaşi;
8. Giurcă, A. (2004) - Proiectare în UML, Universitatea din Craiova, Facultatea de Matematică -
Informatică;
9. Ioniţă, A.D. (2003) - Modelarea UML în ingineria sistemelor de programe, Ed. BIC ALL,
Bucureşti, 2003;