SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr.

ION LUNGU

T5 . Limbajul unificat de modelare

Ce este UML-ul?
Componentele limbajului unificat de modelare
Diagrama cazurilor de utilizare
Diagrama claselor
Diagrama obiectelor
Diagrama de secven
Diagrama de stare
Diagrama de colaborare
Diagrama de activitate
Diagrama de desfurare
Diagrama pachetelor
Interaciunea dintre diagramele UML
Avantajele utilizrii UML

Ce este UML-ul?
Tendina actual din industria software impune dezvoltarea de sisteme extrem de
complexe i n cel mai scurt timp posibil. Se impune cu necesitate adaptarea procesului de
dezvoltare a sistemelor informatice la cerinele din ce n ce mai complexe a produselor
informatice.
n plus, odat cu impunerea pe pia a limbajelor orientate obiect i a mediilor vizuale
de programare, au aprut n ultimii ani mai multe propuneri de procese de dezvoltare orientat
obiect a sistemelor informatice.
n aceste condiii, trei dintre cei mai importani autori din domeniul proiectrii de
software orientat obiect Ivar Jacobson, Grady Booch i James Rumbaugh au conlucrat
pentru realizarea unui limbaj de modelare standard i a unui proces standard de dezvoltare a
produselor informatice. Limbajul pus la punct de acetia UML (Unified Modeling
Language) nregistreaz un mare succes, fiind adoptat ca standard de Object Management
Group (OMG), organismul de standardizare pentru comunitatea orientat obiect.
n 1996, Object Management Group (OMG) a emis o cerere de ofert pentru un model
semantic i notaii standard pentru analiza orientat obiect. Versiunea UML 1.0 a fost trimis
ca rspuns la aceast cerere n ianuarie 1997. Au existat i alte cinci proiecte concurente. n
cursul anului 1997, toi cei ase rivali s-au unit i au prezentat o versiune revizuit
organizaiei OMG, cunoscut ca UML versiunea 1.1. Acest document a fost aprobat de OMG
n noiembrie 1997 sub denumirea OMG UML versiunea 1.1.
UML-ul reprezint o sintez a celor mai multe notaii i concepte utilizate n
proiectarea orientat obiect. Apariia acestui standard reprezint un mare avantaj dac ne
gndim la multitudinea de notaii i metode utilizate pn nu de mult n proiectarea orientat
obiect i pe care UML le substituie cu succes. n prezent este suficient ca proiectanii s
cunoasc acest unic sistem de notaii.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Componentele limbajului unificat de modelare

UML-ul prescrie un set standard de diagrame i notaii pentru analiza i proiectarea
orientat obiect a diverselor tipuri de sisteme (sisteme software, sisteme hardware sau
organizaii), descriind totodat i semantica acestor diagrame i simboluri.
Limbajul unificat de modelare ofer pentru aceasta zece tipuri de diagrame ce pot fi
grupate astfel:
Diagram pentru modelarea proceselor de afaceri, respectiv:
Diagrama cazurilor de utilizare n cazul metodologiilor orientate pe cazuri de
utilizare, aceast diagram dirijeaz ntreg procesul de dezvoltare al sistemului
Diagrame pentru modelarea structurii statice, respectiv:
Diagrama claselor pentru modelarea structurii statice a claselor sistemului
Diagrama obiectelor pentru modelarea structurii statice a obiectelor sistemului
Diagrame pentru modelarea dinamicii:
Diagrame de interaciune, respectiv:
Diagrama de secven pentru modelarea circuitului mesajelor ntre obiecte
Diagrama de colaborare pentru modelarea interaciunilor ntre obiecte
Diagrame de comportament, respectiv:
Diagrama de stare pentru modelarea comportamentului obiectelor din sistem
Diagrama de activitate - pentru modelarea comportamentului cazurilor de utilizare,
obiectelor sau operaiilor
Diagrame de implementare, respectiv:
Diagrama componentelor pentru modelarea componentelor
Diagrama de desfurare pentru modelarea distribuirii sistemului
Diagrama pachetelor mijloc de grupare a elementelor diagramelor n pachete
n figura 1 se prezint grafic aceast clasificare a diagramelor UML.
Mecanismele de extensibilitate incluse permit ca n UML s poat fi abordate aspecte care nu sunt
specificate n standard. Aceste mecanisme permit extinderea notaiilor i semanticii UML.
Stereotipul este cel mai utilizat dintre mecanismele de extensibilitate ale UML-ului. Un stereotip
reprezint un mecanism de calificare din punct de vedere al utilizrii. El se poate aplica oricrui element
de modelare, inclusiv claselor, pachetelor, relaiilor de motenire etc.
De exemplu, o clas cu stereotipul <<actor>> este o clas utilizat ca agent extern n modelarea
proceselor de afaceri. O clas ablon (template) este modelat ca o clas cu stereotipul
<<parameterized>>, cu semnificaia c aceasta cuprinde parametrii.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

M O D ELA R EA PR O C ESELO R D E A FA C ER I

D i a g r a m a c a z u r i l o r d e u til i z a r e
M O D E L A R E A S T R U C T U R II S T A T IC E

D ia g ra m a c la s e lo r
D i a g r a m a o b i e c te l o r
M O D E L A R E A D IN A M IC II

D ia gra m a d e s e c v e n
D ia g ra m a d e c o la b o ra re
D ia g r a m a d e s ta r e
D i a g r a m a d e a c ti v i ta te
IM P L E M E N T A R E A

D i a g r a m a c o m p o n e n te l o r
D ia g r a m a d e d e s f u r a r e
D i a g r a m a p a c h e te l o r

Figura 7.16. Diagramele UML

Figura 1. Diagramele UML

Exist o seciune special n specificaiile UML care prevede stereotipuri specifice

pentru clasele i asocierile utilizate n modelarea proceselor de afaceri. Aceasta prevede
stereotipuri ca actor, executant sau entitate pentru o clas i stereotipuri de genul comunicare
simpl sau cale ntre surs i destinaie pentru o asociere.
Un model grafic nu poate descrie dect o anumit parte din comportament, dup care
alte detalii trebuie specificate n cuvinte. De multe ori ns, utilizarea cuvintelor induce
ambiguitate. Object Constraint Language (OCL) este standardul UML pentru specificarea
detaliilor suplimentare sau precizarea constrngerilor modelului. Dezvoltat n cadrul diviziei
de asigurri a IBM ca un limbaj de modelare a proceselor de afaceri, OCL este un limbaj
formal uor de utilizat. OCL este mai formal ca un limbaj natural, dar nu la fel de precis ca un
limbaj de programare, ceea ce nseamn c nu poate fi utilizat pentru a descrie logica
programului sau pentru controlul fluxurilor. Cum acesta este un limbaj destinat expresiilor,
frazele sale nu au efecte secundare, ele furnizeaz pur i simplu o valoare fr a schimba
starea sistemului.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

O tehnic extrem de utilizat pentru a deslui funcionarea modelului orientat obiect
este analiza orientat pe responsabiliti cu fie CRC (CRC cards Class Responsibility and
Collaborator cards). Cu ajutorul acestei tehnici clasele identificate n cursul etapei de analiz
sunt analizate i selectate pentru a obine doar clasele cu adevrat necesare pentru modelarea
sistemului.
Dei bazele de date orientate obiect devin din ce n ce mai populare, bazele de date
relaionale rmn modalitatea curent de stocare a datelor. Diagrama claselor poate fi utilizat
pentru a modela baza de date relaional pe care se bazeaz sistemul, cu toate astea tehnicile
tradiionale de proiectare a bazelor de date relaionale cuprind mai mult informaie i sunt
mult mai nimerite pentru astfel de sarcini. Aceast lucrare propune modelul entitate asociere
(Entity Relationship ER) ca extensie a UML-ului pentru proiectarea bazelor de date
relaionale.

Diagrama cazurilor de utilizare

Cu ajutorul acestei diagrame analistul stabilete aria de cuprindere a sistemului.
Simbolurile folosite ntr-o diagram a cazurilor de utilizare sunt redate n figura 2.

Figura 7.17. Simbolurile diagramei cazurilor de utilizare

Figura 2. Simbolurile diagramei cazurilor de utilizare

Diagrama cazurilor de utilizare este reprezentarea grafic a cazurilor de utilizare i a

actorilor (figura 3) i este adesea nsoit de o descriere textual. Aceast diagram
documenteaz interaciunile sistemului cu mediul, respectiv interaciuni cu factorul uman,
interaciuni cu alte sisteme i interaciuni ntre calculatoare.

Figura 7.18. Diagrama cazurilor de utilizare (Use Case Diagram)

Figura 3. Diagrama cazurilor de utilizare (Use Case Diagram)

Diagrama cazurilor de utilizare furnizeaz un mecanism de colectare a cerinelor de

exploatare a sistemului. Ea identific utilizrile solicitate i comportamentul necesar pentru a
susine aceste utilizri i ajut la identificarea cerinelor sistemului.
4

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Un scenariu de caz de utilizare este o instan a unui caz de utilizare, aa cum un
obiect este instan a unei clase. Un scenariu de caz de utilizare este alctuit din informaii
text care detaliaz evenimentele i rspunsurile la acele evenimente pentru a satisface cazul de
utilizare. Fiecare scenariu de caz de utilizare furnizeaz o latur vital pentru nelegerea
soluiei de afaceri i a soluiilor tehnice posibile care o susin.
Fiecare diagram a cazurilor de utilizare are cel puin un caz i un actor.
Un caz de utilizare reprezint secvena aciunilor pe care sistemul le realizeaz pentru
a produce ceva de valoare pentru actorul care interacioneaz cu sistemul.
Actorul poate fi o persoan sau un alt sistem extern. Un actor poate participa la mai
mult de un caz i, invers, la acelai caz de utilizare pot participa mai muli actori.
O diagram a cazurilor de utilizare poate conine trei tipuri de asocieri, i anume:
asocieri de comunicare (<<communicate>>, <<comunic>>);
asocieri de utilizare (<<uses>>, <<utilizeaz>>);
asocieri de extindere(<<extends>>, <<extinde>>).
O asociere de comunicare arat care actor particip ntr-un caz de utilizare. Este tipul
implicit de asociere astfel nct nu este obligatorie precizarea acestuia prin stereotipul
<<comunicate>>.
Asocierea de utilizare arat c un caz de utilizare trebuie s includ comportamentul
altui caz de utilizare. Cu ajutorul stereotipului <<uses>> se evideniaz un comportament
obligatoriu, uneori mprtit n comun de mai multe cazuri de utilizare.
Asocierea de extindere arat c un caz de utilizare poate include opional, n anumite
condiii, un alt caz de utilizare (de extindere) i arat dependena dintre ele.

Diagrama claselor
Diagrama claselor este cea mai important diagram n cadrul analizei i proiectrii
orientate obiect. Scopul diagramei claselor este de a prezenta natura static a claselor punand
in evidenta atributele, operaiile i asocierile (figura 4).
Majoritatea instrumentelor de modelare orientate obiect genereaz codul surs numai
din diagrama claselor.
Celelalte diagrame UML furnizeaz diferite puncte de vedere din care s fie identificate atributele, operaiile i asocierile dintre clase. Ele ajut la validarea diagramei claselor,
putnd servi la clarificarea unei probleme specifice .
Diagrama claselor conine clase i asocieri ntre clase. O clas este un model pentru
obiecte cu structur, comportament i relaii similare. Fiecare clas are un nume, atribute i
operaii. n general numele claselor se scriu cu litere mari.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Figura 7.19. Diagrama claselor (Class Diagram)

Figura 4 . Diagrama claselor (Class Diagram)

Proprietile atributelor definesc datele i pot include:

Vizibilitate (public (+), protejat (#) sau privat (-)).
Tip (implementare specific limbajului tipului de atribut, cum ar fi caracter sau
ntreg).
Valoare iniial (valoare cu care se iniializeaz obiectul).
irul de proprieti (valori care se aplica atributului, cum ar fi o serie de
numere).
Proprietile operaiilor definesc comportamentul i pot include:
Vizibilitate (public, protejat sau privat).
Lista parametrilor (elemente transmise operaiei care includ tipul su propriu
i valoarea iniial).
Tipul de rezultat (implementare specific limbajului tipului de atribut a valorii
rezultate dintr-o operaie).
irul de proprieti (valori care se aplic argumentului n lista de parametri).
O clas reprezint cel mai important bloc (structur) dintr-un sistem orientat obiect. i
totui, n UML clasele sunt doar un tip de clasificatori denumire dat mai multor structuri
(blocuri) UML.
Un clasificator este un mecanism care descrie caracteristicile structurale i funcionale
(comportamentale). Clasificatorii includ clase, interfee, tipuri de date, semnale (signal),
componente, noduri, cazuri de utilizare i subsisteme.
UML mai are i ali clasificatori n afar de clase, i anume:
Interfaa (interface) - o colecie de operaii care sunt folosite pentru a specifica un
serviciu al unei clase sau componente.
Tip de date (data type) - un tip cu valori care nu au o anumit identitate, inclusiv
tipurile de date primare (cum ar fi numeric sau string), ca de altfel i enumerrile.
Semnal (signal) - specificaia unui stimul asincron comunicat ntre instane.
Componenta (component) - partea fizic i substituibil a unui sistem din care face
parte i care asigur realizarea unui set de interfee.

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Nod (node) - elementul fizic care exist la execuie i care reprezint o resurs de
calcul, de obicei avnd memorie i procesor.
Cazuri de utilizare - descrierea unui set de secvene a aciunilor.
Subsistem - un grup de elemente care constituie specificaia comportamental.

n UML, clasificatorii, deci implicit i clasele, se caracterizeaz prin urmtoarele

proprieti: vizibilitatea, scopul i multiplicitatea.
Vizibilitatea unui clasificator este acea caracteristic care specific dac acesta poate
fi folosit sau nu de ali clasificatori.
Exist trei niveluri de vizibilitate n UML:
public (+) - are acces orice alt clasificator;
protected (#) - are acces orice descendent;
private (-) - numai clasificatorul nsui poate folosi aceast caracteristic.
Scopul determin dac elementul apare n fiecare instan a clasificatorului sau exist
o singur instan a elementului pentru toate instanele clasificatorului.
n UML, dup acest scop, se pot specifica dou tipuri de clasificatori:

instance valori distincte ale elementului pentru fiecare instan a clasificatorului;

classifier o singur valoare pentru toate instanele.
n UML se indic faptul c o clas este abstract scriindu-i numele italic. O clas
concret (normal) este scris cu fonturi normale. O clas care nu are descendeni (o clas
frunz) este specificat scriind leaf sub numele clasei. O clas care nu are ascendeni se
numete clas rdcin i se specific scriind root sub numele clasei.
Operaiile au proprieti similare (vizibilitatea i scopul). De obicei o operaie e
polimorf, ceea ce nseamn c ntr-o ierarhie de clase poi specifica operaii cu aceeai
semntur n puncte diferite din ierarhie. Operaiile din clasele copii suprancarc operaiile
din clasele printe. Operaiile, deci, pot fi: abstracte (ex.: funciile virtuale din C++) i
concrete (leaf) operaii care nu pot fi suprascrise (exemplu, operaii nonvirtuale din C++).
Multiplicitatea reprezint numrul de instane al unei clase. Exist clase:
cu zero instane, este o clas utilitar care confer doar atribute i operaii;
cu o singur instan, singleton class;
cu un numr dat de instane;
cu multe instane (cazul implicit).
Atragem atenia c n acest context multiplicitatea are o alt semnificaie fa de
aceeai proprietate aplicat asocierilor .
Multiplicitatea se specific scriind un numr n colul dreapta al clasei. Ea se poate
aplica i atributelor scriind n paranteze o expresie dup numele atributului.
n UML sintaxa unui atribut este:
[vizibilitate] nume [multiplicitate] [:tip] [=valoare iniial] [(ir-de-proprieti }]
Exist trei tipuri de proprieti definite pentru atribute:
changeable, fr restricii de modificare;

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

addOnly, pentru atribute cu multiplicitate mai mare ca unu odat creat nu mai poate
fi ters sau modificat;
frozen - valoarea atributului nu poate fi modificat (ex.: constante din C++).
Sintaxa unei operaii n UML este:
[vizibilitate] nume [(list-parametri)] [:tip-returnat] [{ir-de-proprieti}]
n semntura unei operaii se pot specifica unul sau mai muli parametrii conform
urmtoarei sintaxe:
[direcie] nume :tip [=valoare implicit]

Direcia poate fi: in (parametru de intrare), out (parametru de ieire), in-out (parametru
de intrare care poate fi modificat).
Exist patru proprieti care pot fi folosite pentru operaii:
isQuery, starea sistemului rmne neschimbat;
sequential, trebuie coordonat apelul operaiei astfel nct s se execute doar una la un
moment dat,
guarded, semantica i integritatea obiectu1ui este garantat n prezena mai multor
fluxuri (operaii executate n acelai timp), este redus la un ape1 secvenial
executndu-se cte una pe rnd,
concurrent se pot apela de mai multe ori din fluxuri concurente.
Ultimele trei proprieti sunt relevante doar n prezena obiectelor active, proceselor i
fluxurilor de execuie (threads).
Clasele template sunt elemente parametrizate (figura 5). Rezultatul instanierii unei
clase template este o clas care poate fi folosit ca orice alt clas.

Figura 7.20. Notaii UML pentru clasele template

Figura 5. Notaii UML pentru clasele template

Figura 5 indic modul de scriere n UML a claselor template. Clasele template se pot
specifica implicit prin nume sau utiliznd bind care arat c sursa instaniaz template-ul
pentru parametrii actuali.

Diagrama obiectelor

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Diagrama obiectelor modeleaz instanele elementelor coninute n diagrama claselor.
O diagram obiectual reprezint un set de obiecte i relaiile dintre acestea la un anumit
moment.
O instan este o manifestare concret a unei abstractizri a crui set de operaii poate
fi aplicat i care are o stare care arat efectele operaiilor. Instana i obiectul sunt sinonime.
Grafic, o instan este reprezentat subliniindu-i numele.

Cele mai multe instane modelate cu UML sunt instane ale claselor (i se numesc
obiecte), dei exist i instane de componente, noduri, cazuri de utilizare, asocieri. Instanele
modelate se plaseaz n diagrame obiectuale.
Operaiile care se fac asupra unui obiect sunt definite n abstractizarea obiectului. n
funcie de motenire operaiile pot fi sau nu polimorfe.
Un obiect are o stare care reprezint proprietile obiectului (cele statice de obicei) i
valorile curente (dinamice) ale acestor proprieti. Aceste proprieti includ atributele
obiectului i prile lui agregate. Deci, starea unui obiect este dinamic.
UML definete dou stereotipuri standard care se aplic relaiilor de dependen ntre
obiecte i ntre clase:
instanceOf - obiectul client este o instan a clasificatorului furnizor;
instantiate - clasa client creeaz o instan a clasei furnizor.
Exist dou stereotipuri relative la obiecte, care se aplic la mesaje i tranziii:
become clientul este acelai obiect cu furnizorul, dar la un moment ulterior i cu
valori, stri sau roluri diferite;
copy obiectul client este o copie exact, dar independent a obiectului furnizor.
UML definete restricii standard care se aplic obiectelor:

tranzient o instan a unui rol este creat n timpul execuiei, dar e distrus naintea
terminrii execuiei.
Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, pot conine
note i restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind folosit pentru a
grupa elementele modelului.
Aceste diagrame se folosesc pentru modelarea static a unui sistem, ca diagramele de
clase, dar din perspectiva unor instane reale sau prototip.

Diagrama de secven
Scenariile cazurilor de utilizare se dezvolt n mod natural din diagrama de secven.
Diagramele de secven transform evenimentele identificate n scenariile cazurilor de
utilizare , ntr-o reprezentare grafic a utilizrilor sistemului de ctre actor (figura 6). Fiecare
eveniment are ca rezultat un mesaj trimis unui obiect cu perspectiva c acel obiect va realiza o

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

operaie. Rafinarea operaiei i a atributelor utilizate n semntura operaiei (ca argumente)
actualizeaz clasa n diagrama claselor.
Diagrama de secven descrie cronologic interaciunea obiectelor, identificnd
mesajele schimbate ntre obiecte ca rspuns la un eveniment, mpreun cu secvena mesajelor.
Este prima vizualizare a intercomunicrii claselor pentru un anumit scenariu al cazurilor de
utilizare. Scopul este nelegerea ordinii evenimentelor pentru a parcurge ntregul scenariu. Pe
msur ce ordonarea devine stabil, un eveniment devine o operaie specific pe care o
iniializeaz obiectul receptor.Diagramele de secven sunt recomandate pentru realizarea de
specificaii n timp real i pentru scenarii complexe
Diagrama de secven listeaz obiectele diagramelor de secven implicate ntr-un
scenariu al cazurilor de utilizare n partea superioar de la stnga ctre dreapta. Cnd se
include numele clasei cu numele obiectului, se separ clasa de obiect prin :.
Se plaseaz mesajele schimbate ntre obiecte, pe vertical de sus n jos. Perioada de existen se
propag n jos, de la fiecare obiect.
Pentru fiecare pas n scenariul cazurilor de utilizare, un obiect trimite mesajul din linia sa de
viaa ctre linia de viaa a unui alt obiect. Mesajul conine informaii necesare obiectului doi s
acioneze. Cu alte cuvinte, mesajul declaneaz o aciune la obiectul receptor.
Un obiect poate s fie att receptor, ct i emitor (recursiv).
Opional se poate include un actor care s participe n scenariul cazurilor de utilizare ca fiind un
obiect care trimite i primete mesaje.
Un singur pas n timpul scenariului cazurilor de utilizare uneori poate crea sau distruge un
obiect.
Linia de via a obiectului se monitorizeaz prin alinierea vertical a obiectului cu pasul su de
instaniere.
Se marcheaz cu X sfritul liniei de via, adic pasul n care obiectul este distrus.

Figura 7.21. Diagrama de secven (Sequence Diagram)

Figura 6. Diagrama de secven (Sequence Diagram)

10

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Dreptunghiul de-a lungul liniei de via a obiectului arat durata aciunii, numit
activare sau amplificarea controlului, ncepnd cu mesajul primit i terminnd cu mesajul
trimis.
Forma diferit a sgeilor reprezint tipuri diferite ale mesajelor. Mesajul sincron, unde
obiectul care l-a trimis ateapt rspunsul de la obiectul care l-a recepionat, este reprezentat
prin urmtoarea sgeat:
Sgeata mesajului de rspuns are aceeai form. Cnd obiectul care trimite mesajul nu
ateapt rspunsul, cazul mesajului asincron, sgeata are urmtoarea forma:
Se spune c procedura are vrful de sgeat substituit. Mesajul de rspuns nu are nici
un vrf pe sgeat i n schimb are liniua vertical plasat n apropierea mesajului original
trimis. Daca paii se repet, mesajele se plaseaz n interiorul unui dreptunghi. Se poate
aduga textul iteraiei pentru indicarea numrului de iteraii i a condiiei de ieire. Textul are
forma: [i:=1..n] cu semnificaia: repetare folosind variabila i, de la 1 pn la un numr n.

Diagrama de stare
Modeleaz starea dinamic a unui obiect specific. Diagrama de stare const din stri,
aciuni, activiti i tranziii (figura 7).

Figura 7 . Diagrama de stare (Statechart Diagram)

Diagrama de stare identific evenimentele care fac tranziia unui obiect dintr-o stare n alta.
Conform UML, o stare este o condiie sau o situaie din momentul existenei unui obiect care
satisface n acel moment anumite condiii, efectueaz anumite activiti sau ateapt anumite
evenimente.
Diagrama de stare descrie toate operaiile i atributele unei clase n timpul unui eveniment.
Diagrama identific stimulii care declaneaz aciunea.
Diagrama include numele strii, oricrei variabile, n timp ce obiectul este n funciune, i
evenimentul care declaneaz tranziia la o nou stare.

11

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Dreptunghiul cu marginile rotunjite reprezint stri distincte.
Orice diagram de stare include o stare iniial reprezentat printr-un cerc mic de
culoare neagr i o stare final reprezentat prin acelai cerc, dar inclus ntr-un cerc puin mai
mare. Starea iniial apare la crearea obiectului. Starea final apare la dispariia obiectului.
Cu excepia strii iniiale i a celei finale fiecare stare are un nume, atributele proprii
unei stri, aciunile i activitile efectuate. Acestor aciuni i activiti le este atribuit un nume
de eveniment, precum i argumente i expresii ale aciunii. Slash-ul separ expresiile aciunii
de numele evenimentului i argumente.
Aciunile speciale includ:
Entry / intrare - aciune efectuat la intrare ntr-o stare.
Exit / ieire - aciune efectuat la ieire dintr-o stare.
Do / aciune efectuat aflndu-se ntr-o stare; evenimentele externe pot ntrerupe
aciunile Do.
Obiectul tranziteaz dintr-o stare n alta cnd apare un eveniment i cnd sunt
ndeplinite anumite condiii.
Tranziia este artat cu liniue simple de la o stare existent ctre o stare de intrare /
int.
Tranziia conine:

semntura unui eveniment, care include un nume i argumentele separate de virgule care se
afl ntre paranteze;

o condiie de securitate opional, care interzice tranziia de stare pn cnd nu sunt

ndeplinite toate condiiile;
o aciune introdus cu slash .
n timpul tranziiei se execut o aciune. Aciunea poate s fie o operaie efectuat de
obiect, un mesaj trimis altui obiect, sau o condiie n cadrul obiectului care declaneaz
schimbarea strii. Aciunea nsi poate include o semntur cnd aciunea trimite un mesaj
altui obiect. Expresia aciunii poate include obiectul receptor i parametrii transmii acelui
obiect receptor.
O sgeat reprezint trimiterea unui mesaj ctre un alt obiect. Acest mesaj poate fi
trimis de la obiect n timp ce este ntr-o anumit stare sau n timpul tranziiei.

Diagrama de colaborare
Diagrama de colaborare descrie o examinare nonsecvenial a modului n care interacioneaz
obiectul. Diagrama de colaborare suport multiple modaliti de modelare a obiectului. O modalitate
arat modul n care obiectele colaboreaz n cadrul unui singur scenariu al cazurilor de utilizare
similar cu diagrama de secven.
O interaciune interesant se produce ntre diagramele de secven i diagramele de colaborare,
rezultnd operaiuni noi i descoperirea unor atribute adiionale. Ambele diagrame furnizeaz puncte
de vedere diferite ale aceleiai informaii. Ambele arat implementarea unui scenariu al cazului de
utilizare.
Diagrama permite studiul asocierilor statice i comportamentelor dinamice ale obiectelor
implicate n interaciune. Avem tendina s gndim secvenial, dar, cteodat, procesele nu sunt att de
procedurale cum ni le imaginm. Utilizarea diagramei de colaborare poate ajuta la clarificarea
contextului.

Diagrama de colaborare poate fi utilizat pentru a arta legtura tuturor operaiunilor

unei anumite clase. Pentru fiecare operaie este artat obiectul int al operaiei i orice alt
obiect pe care l solicit pentru a implementa operaia. Diagrama de colaborare, astfel, devine
un context al tuturor obiectelor i al asocierilor care interacioneaz cu un obiect (figura 8).

12

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Figura 7.23. Diagrama de colaborare (Collaboration Diagram)

Figura 8. Diagrama de colaborare (Collaboration Diagram)

Deoarece permite focalizarea asupra unei anumite clase, diagrama de colaborare ajut
la rafinarea diagramei claselor, adugnd atribute i operaii.
Furnizeaz, de asemenea, informaii cu privire la ceea ce face o clas atunci cnd
valideaz codul asociat acesteia.
Notaia UML a diagramei de colaborare este asemntoare cu diagrama de secven cu
obiecte, mesaje i semnturi.
Fiecare mesaj poate include un numr secvenial care s ordoneze etapele colaborrii.
Virgulele separ secvenele i se termin cu un slash . Un predecesor n numrul secvenei
indic faptul c alt mesaj trebuie completat naintea transmiterii acestui mesaj.
Diagrama de colaborare poate arta un comportament repetat cu un asterisc, , urmat de numrul
de iteraii i de condiia de ieire ncadrat ntre paranteze, de exemplu, [i:= 1..n].

Diagrama de activitate
O diagram de activitate permite o mai bun nelegere a operaiilor, n special a celor
foarte complexe, o mai bun nelegere a detaliilor din cadrul unei operaii a unei clase.
Diagramele de secven i de colaborare nu prezinta acest nivel de detaliere suficient de exact
pentru c ele arat doar mesajele schimbate ntre obiecte, nu i detaliile asociate acestor
obiecte.X
Diagrama de activitate este un tip de grafic de stare care specific activitatea unei
anumite clase (figura 9).Diferena consta n faptul c un grafic de stare reprezint ntregul
obiect, n timp ce o diagram de activitate reprezint n mod tipic doar o operaie n cadrul
unui obiect. Terminologia diagramei de activitate este uor confundat cu terminologia
diagramei de stare, ntruct ambele utilizeaz termenul stri. Starea din cadrul diagramei de
activitate este starea unei aciuni, noiune distinct de stare a obiectului.
Starea aciunii reprezint starea unei activiti n cadrul unei operaii. Descrie
descompunerea strii de aciune i tranziiile n cadrul unei anumite stri a obiectului, mai
mult dect de la o stare la alta. Descompunerea strii nu nseamn c obiectul i modific
starea. O aciune a strii reprezint, mai degrab, prelucrarea intern care intervine n timpul
aciunii sau activitii surs. Procesarea intern, mai mult dect un eveniment extern,
declaneaz tranziia de la o stare a aciunii la alta. Diagrama de activitate este utilizat pentru
a arata aceast prelucrare intern.

13

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Figura 7.24. Diagrama de activitate (Activity Diagram)

Figura 9. Diagrama de activitate (Activity Diagram)

S lum drept exemplu un automat. Cnd consumatorul introduce banii ntr-un

automat, activitatea de a da consumatorului un produs poate traversa mai multe aciuni de
stare. De exemplu, oferirea restului, lsarea produsului s cad n tav, avansarea liniei de
produse. Totui, nici una dintre aceste stri ale aciunii nu reprezint stare a obiectului
automatului (ateptarea seleciei, livrarea produsului).
Starea aciunii poate fi declanat de:
Completarea unei operaii;
Completarea unei stri, a unei aciuni anterioare;
Disponibilitatea unui obiect (starea necesar unei aciuni pentru a ncepe).
Activitatea const n etape procedurale sau operaii declanate mai degrab de
prelucrarea intern dect de evenimente externe. O stare specific unui obiect sau completarea
uneia din operaiile sale declaneaz o operaie, o aciune n cadrul unei stri a aciunii este
deseori ea nsi o operaie. Cnd se termin o aciune, poate face un obiect disponibil pentru
o aciune urmtoare. Cnd se ntmpl acest lucru, activitatea s-a mutat ctre starea sa de
aciune urmtoare.
Un dreptunghi cu colurile rotunjite reprezinta aciunea; capetele deschise ale sgeilor
indic fluxul controlului. Poate include atributele utilizate de o aciune, dar poate doar s
utilizeze atributele i link-urile obiectului care le deine (de exemplu, obiectul pentru care se
definete activitatea).
O diagram de activitate poate avea ramuri de control comune sau separate. Aceste
fluxuri de aciune au drept etichet condiia care declaneaz fluxul.

Diagrama componentelor
Diagrama componentelor adun informaiile din diagrama claselor pentru a crea
componente (figura 10).

14

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Figura 7.25. Diagrama componentelor (Component Diagram)

Figura 10. Diagrama componentelor (Component Diagram)

Notaia UML pentru componente este dreptunghiul cu dou dreptunghiuri mai mici
scoase n afar, pe una din pri. O component are un nume i opional un tip, separate prin
:. Componenta poate include obiectele pe care le conine.
Un vrf de sgeat deschis de la o component la alta indic o dependen a sursei de
int. O relaie de dependen reprezentat de un cerc deschis i o etichet de interfa pot fi
trasate ctre interfaa obiectului( aceasta este iniierea dependenei). O dependen poate fi, de
asemenea, trasat direct ctre component fr trecerea printr-o interfa( aceasta este o
dependen de compilare).

Diagrama de desfurare
Componentele sunt plasate pe echipamente hardware prin intermediul diagramei de
desfurare (figura 11).

15

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Figura 7.26. Diagrama de desfurare (Deployment Diagram)

Figura 11. Diagrama de desfurare (Deployment Diagram)

Diagrama de desfurare reprezint partiionarea componentelor i a obiectelor active

(de exemplu, o baz de date) pe locaia lor fizic. Acest tip de diagram detaliaz locul de
amplasare a componentelor n cadrul infrastructurii sistemului. Cel mai adesea sunt definite
mai multe diagrame de desfurare independente.
Diagrama de desfurare utilizeaz noduri pentru a reprezenta procesoare i
echipamente. Fiecare nod are un nume i, opional, un tip, separate de dou puncte, :.
O linie continu de la un nod la altul indic faptul c nodurile comunic, de exemplu,
printr-un canal sau o reea. Un vrf de sgeat deschis indic faptul c o component
comunic cu un obiect activ.

Diagrama pachetelor
UML furnizeaz mijloace de grupare a elementelor din cadrul diagramelor, numite
pachete. ntr-un pachet pot fi incluse alte pachete, clase, cazuri de utilizare, colaborri etc. Un
pachet arat doar structurile pe care le conine (figura 12).
Un pachet nu arat comportamentul elementelor sale. Un element de modelare
aparine unui singur pachet, dar alte pachete pot consulta acest element. Dac se arat explicit
coninutul pachetului, atunci numele pachetului se trece pe etichet.
Un pachet este un mecanism destinat unor scopuri generale, care organizeaz
elementele n grupuri. Fiecare pachet are un nume care poate fi simplu sau cu cale (path
name).

16

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Figura 7.27. Diagrama pachet (Package Diagram)

Figura 12. Diagrama pachet (Package Diagram)
Un pachet poate conine clase, interfee, componente, noduri, colaborri, cazuri de utilizare,
diagrame i chiar alte pachete. A conine este o relaie compus, ceea ce nseamn c fiecare element
este declarat n pachet. Din punct de vedere al vizibilitii, pachetele se comport precum clasele.

UML definete cinci stereotipuri care se aplic pachetelor:

facade - un pachet care este doar o vizualizare a altui pachet;
framework - un pachet care conine n principal modele (patterns);
stub - este un proxy pentru coninutul public al altui pachet;
subsystem - un pachet ce reprezint o parte independent a sistemului modelat;
system - un pachet ce reprezint tot sistemul modelat.

Interaciunea dintre diagramele UML

Pe parcursul ciclului de via al unui sistem informatic diagramele UML interacioneaz ntre ele sau cu alte modele (modelul entitate asociere).
Cazurile de utilizare i diagramele de interaciune

Toate procesele care trebuie executate de sistem se regsesc ntr-un caz de utilizare.
Procesele sunt descrise apoi textual sau printr-o succesiune de pai. Pentru modelarea grafic
a scenariilor poate fi utilizat diagrama de activitate. Odat ce comportamentul sistemului a
fost astfel surprins, cazurile de utilizare sunt mai departe analizate pentru a identifica cum
interacioneaz obiectele pentru a modela acest comportament. Diagramele de secven i de
colaborare sunt utilizate pentru a modela aceast interaciune ntre obiecte.

17

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Clasele, obiectele i diagramele de implementare
Pe msur ce sunt identificate obiectele, acestea pot fi grupate i clasificate n cadrul
diagramei claselor i a obiectelor. Diagrama claselor devine astfel elementul central al
procesului de proiectare orientat obiect, fiind diagrama care descrie structura static a
sistemului. Diagrama claselor poate fi mprit pe trei straturi care s evidenieze clasele ce
descriu interfaa cu utilizatorul (business layer), clasele responsabile de logica aplicaiei
(application layer) i clasele pentru stocarea datelor (data layer). Diagrama componentelor
este utilizat pentru a grupa clasele n componente sau module. Distribuirea fizic n
ansamblul sistemului este modelat cu ajutorul diagramei de desfurare.
Fie CRC o extensie informal a UML-ului
Ca extensie a UML-ului, tehnica fielor CRC poate fi utilizat pentru a supune
sistemul analizei orientate pe responsabiliti. Clasele sunt analizate, selectate i rafinate pe
baza responsabilitilor lor n cadrul sistemului i a claselor cu care acestea trebuie s
colaboreze pentru a-i ndeplini aceste responsabiliti.
Diagramele de stare
Cu ajutorul diagramelor de stare se modeleaz comportamentul n timp real al fiecrei
clase cu un comportament semnificativ dinamic. Diagrama de activitate poate fi i ea folosit,
de aceast dat ca extensie a diagramei de stare, pentru a detalia aciunile de rspuns ale
obiectelor la evenimente interne acestora. Diagrama de activitate poate fi utilizat i pentru a
reprezenta grafic aciunile metodelor claselor.
Implementarea proiectrii (realizarea sistemului)
Realizarea sistemului presupune transformarea informaiei cuprins n mai multe
modele UML n cod i structur a bazei de date. n cazul unui sistem de mari dimensiuni este
extrem de util descompunerea acestuia n trei subsisteme: subsistemul afacerii, care include
i elementele de interfa cu utilizatorul (business layer), subsistemul aplicaiei, care include
obiectele de implementare a funcionalitii sistemului (application layer) i subsistemul
datelor, care include structura bazei de date i obiectele de acces la aceast structur (data
layer).
Implementarea aplicaiei (codificarea)
Diagrama claselor este utilizat pentru a genera scheletul aplicaiei n limbajul de programare ales
cu ajutorul unui CASE. Diagramele de interaciune, de stare i de activitate furnizeaz informaii
suplimentare pentru detalierea prii procedurale a codului.

Proiectarea bazei de date

Stratul datelor (data layer) din diagrama claselor poate fi utilizat pentru a proiecta
direct o baz de date orientat obiect sau pentru a construi corespunztor un model entitate
asociere (ER - Entity Relationship) pentru o analiz mai detaliat a relaiilor. Pe baza
modelului entitate asociere se poate construi apoi modelul fizic al bazei de date relaionale.
Testarea cerinelor
Diagrama cazurilor de utilizare este folosit i pentru a testa dac sistemul rspunde
cerinelor iniiale. Se parcurg toate cazurile de utilizare pentru a vedea dac sistemul
corespunde cerinelor clientului.

18

SISTEME INFORMATICE PENTRU MANAGEMENT Prof. univ. dr. ION LUNGU

Avantajele utilizrii UML

Dei nu garanteaz succesul unui proiect informatic, UML poate contribui la reducerea
costurilor de instruire i schimbare a instrumentelor de lucru atunci cnd se face trecerea de la
un proiect la altul sau de la o organizaie la alta. UML ofer o baz pentru integrarea
instrumentelor, proceselor i domeniilor. n primul rnd, UML asigur o terminologie unic i
permite realizatorilor de sisteme s se concentreze asupra obiectivelor proiectelor i nu asupra
instrumentelor de modelare.
Aa cum a fost precizat n documentul UML Summary, Version 1.1, elaborat la 1
septembrie 1997 de Rational Software i ceilali realizatori, scopurile pentru care a fost creat
UML sunt urmtoarele:
s pun la dispoziia utilizatorilor un limbaj de modelare vizual uor de folosit,
expresiv. Este foarte important ca standardul pentru analiz i proiectare s suporte
un limbaj de modelare care s fie folosit pentru realizarea de taskuri generale de
modelare. Dac standardul ofer numai o descriere de meta-nivel care reclam
ajustarea la un anumit set de concepte de modelare, atunci nu se poate realiza
schimbul de modele fr pierdere de informaii;
s asigure extensibilitatea, precum i mecanismele de specializare prin care s fie
extinse conceptele de baz;
s permit formularea de specificaii independente de un anumit limbaj de
programare i de procesele de realizare a sistemului;
s ofere o baz formal pentru nelegerea limbajului de modelare;
s ncurajeze creterea pieei instrumentelor orientate pe obiecte;
s suporte concepte precum: componente, colaborri, cadre, paternuri;
s permit diseminarea celor mai bune practici n domeniul realizrii sistemelor
software.
UML reunete conceptele din Booch, OMT i OOSE. Rezultatul l reprezint un
limbaj de modelare posibil de utilizat de ctre utilizatorii acestor metode, dar i a altor metode
orientate pe obiecte.
n plus, UML extinde posibilitile oferite de metodele menionate mai sus. De
exemplu, prin utilizarea UML se poate realiza modelarea sistemelor concurente i a celor
distribuite.
UML asigur un standard de limbaj, nu i de proces. Dei UML poate fi folosit n
cadrul unei metodologii, experiena echipei de proiect i specificitatea domeniului pot reclama
utilizarea unor procese specifice. UML asigur un acelai meta-model, care unific semantica
i o aceeai notaie, pentru interpretarea acestei semantici.
UML promoveaz construirea iterativ i incremental a sistemelor software dirijat
de cazurile de utilizare i centrat pe arhitectura acestor sisteme.

19