CUPRINS

1. Etapele principale de dezvoltare a limbajului UML ........................................................................3

2. Componente de baza ale limbajului UML .......................................................................................5
2.1. Structura general a limbajului UML........................................................................................ 7
2.2. Particularitatea (specificul) limbajului UML ............................................................................ 8
2.2.1. UML limbaj de vizualizare ..............................................................................................9
2.2.2. UML limbaj de specificare ..............................................................................................9
2.2.3. UML limbaj de construire ...............................................................................................9
2.2.4. UML limbaj de documentare.........................................................................................10
2.3. Entiti n UML ....................................................................................................................... 11
2.4. Relaii UML ............................................................................................................................ 14
2.5. Diagrame UML ....................................................................................................................... 16
3. Diagarama cazurilor de utilizare (use case diagram) .....................................................................17
3.1. Cazul de utilizare ..................................................................................................................... 18
3.2. Actori ....................................................................................................................................... 18
3.3. Interfee ................................................................................................................................... 19
3.4. Legturile n diagrama a cazurilor de utilizare ........................................................................ 20
3.4.1. Relaia de asociere ...........................................................................................................21
3.4.2. Relaia de extindere ..........................................................................................................22
3.4.3. Relaia de generalizare ....................................................................................................23
3.4.4. Relaia de tip include........................................................................................................24
3.5. Exemplu de construirea diagramei cazurilor de utilizare ........................................................ 24
4. Diagrama de clase (class diagram) .................................................................................................27
4.1. Clasa ........................................................................................................................................ 28
4.1.1. Numele clasei ...................................................................................................................28
4.1.2. Atributele clasei................................................................................................................29
4.1.3. Operaiile .........................................................................................................................31
4.2. Relaii ntre clase ..................................................................................................................... 32
4.2.1. Relaia de dependena ......................................................................................................32
4.2.2. Relaia de asociere ...........................................................................................................33
4.2.3. Relaia de agregare ..........................................................................................................34
4.2.4. Relaia de compoziie .......................................................................................................34
4.2.5. Relaie de generalizare.....................................................................................................35
4.3. Interfee ................................................................................................................................... 36
4.4. Obiecte .................................................................................................................................... 36
5. Diagrama de stri (statechart diagram) ..........................................................................................37
5.1. Automate ................................................................................................................................. 37
5.2. Stare ......................................................................................................................................... 38
5.2.1. Numele strii ....................................................................................................................39
5.2.2. Starea iniial ...................................................................................................................39
5.2.3. Starea final .....................................................................................................................39
5.3. Tranziie .................................................................................................................................. 39
5.3.1. Eveniment .........................................................................................................................40
5.3.2. Condiie gard..................................................................................................................40
5.3.3. Expresia aciunei ..............................................................................................................41
5.4. Stare i substare compus ........................................................................................................ 42
5.4.1. Substri disjuncte .............................................................................................................42
5.4.2. Substri concurente ..........................................................................................................43
6. Diagrama de activiti (activity diagram).......................................................................................45
6.1. Starea activitii ....................................................................................................................... 45
6.2. Tranziii ................................................................................................................................... 46
6.3. Partiii ...................................................................................................................................... 48

6.4. Obiecte .................................................................................................................................... 50

7. Diagrama de secven (sequence diagram) ....................................................................................51
7.1. Obiecte .................................................................................................................................... 51
7.1.1. Linia de via al obiectului...............................................................................................52
7.2. Focus control ........................................................................................................................... 52
7.3. Mesaje ..................................................................................................................................... 52
7.3.1. Stereotipuri de mesaje ......................................................................................................53
7.4. Restricii temporale n diagrama de secven .......................................................................... 53
8. Diagrama de colaborare (collaboration diagram) ...........................................................................54
8.1. Obiecte .................................................................................................................................... 54
8.1.1. Multiobiect .......................................................................................................................56
8.1.2. Obiect activ ......................................................................................................................56
8.1.3. Obiect compus ..................................................................................................................57
8.2. Legturi ................................................................................................................................... 57
8.2.1. Tipuri de legturi .............................................................................................................58
8.3. Colaborare ............................................................................................................................... 59
8.3.1. Diagrama de colaborare la nivel de specificare ..............................................................60
9. Diagrama de componente (component diagram) ...........................................................................61
9.1. Componente ............................................................................................................................ 62
9.1.1. Numele componentului .....................................................................................................63
9.1.2. Feluri de componente .......................................................................................................64
9.2. Interfee ................................................................................................................................... 65
9.3. Dependene .............................................................................................................................. 65
9.4. Recomandri la construirea diagramei de componente ........................................................... 67
10. Diagrama de plasare (deployment diagram) ................................................................................68
10.1. Nod ........................................................................................................................................ 69
10.2. Conexare................................................................................................................................ 71
10.3. Recomandri la construirea diagramei de plasare ................................................................. 73

1. Etapele principale de dezvoltare a limbajului UML

Unele limbaje de modelare obiect orientate au nceput s apare n perioada ntre mijlocul anilor
1970 i sfritul anilor 1980, cnd diferii cercettori i programatori propuneau diverse metode de
analiza i proiectare obiect orientat (APOO). n perioada ntre anii 1989-1994 numrul total al
limbajelor de modelare cele mai cunoscute a crescut de la 10 pna la mai mult dect 50. Muli
utilizatori au avut dificulti serioase la alegerea limbajului de APOO, fiindc nici unul din
limbajele propuse nu satisfcea toate cerinele ctre modelarea (construirea modelelor) sistemelor
compuse. Acceptarea unor metode i notaii grafice n calitatea de standarde (IDEF0, IDEF1X) nu a
putut s schimbe situaia de concuren acut ntre limbaje la nceputul anilor 90ci.
Spre mijlocul anilor 1990 unele metode au fost esenial perfecionate i au obinut semnificaie
proprie la rezolvarea diferitor probleme APOO. Cele mai cunoscute n acea perioad au devenit:

Metoda lui Grady Booch, care este cunoscut ca Booch sau Booch91, Booch Lite (mai
trziu Booch93).
Metoda lui James Rumbaugh, cunoscuta ca Object Modeling Technique OMT (mai
trziu OMT-2).
Metoda lui Ivar Jacobson, cunoscuta ca Object-Oriented Software Engineering OOSE.

Fiecare metod a fost orientat spre susinerea unor etape aparte ale APOO. De exemplu, metoda
OOSE coninea mijloace de prezentare a cazurilor de utilizare, care au semnificaie esenial la
etapa analizei cerinelor n timpul proiectrii business-aplicaiilor. Metoda OMT-2 era cea mai
potrivit pentru analiza proceselor de prelucrare a datelor n sistemele informaionale. Metoda
Booch93 era cea mai aplicabil la etapele de proiectare i exploatare a diferitor sisteme program.
Istoria dezvoltrii limbajului UML ncepe n luna octombrie a anului 1994, cnd Grady Booch i
James Rumbaugh din Rational Software Corporation au nceput s lucreze mpreun asupra
unificrii metodelor Booch i OMT. Cu toate c aceste metode fiecare n parte erau destul de
cunoscute, lucrul n comun era organizat pentru cercetarea tuturor metodelor OO cu scopul
unificrii celor mai avantajoase trsturi ale lor. Proiectul acestei aa zise metode unificate (Unified
Method) versiunea 0.8 a fost pregtit i publicat n luna octombrie anului 1995. n toamna aceluiai
an a aderat la ei i Iv. Jacobson, tehnologul principal al companiei Objectory AV (Suedia), cu
scopul integrrii metodei sale OOSE cu celelalte dou precedente.
ncepnd lucrul spre unificarea metodelor, G. Booch, J. Rumbaugh i Iv. Jacobson au formulat
urmtoarele cerinele ctre limbajul de modelare. El trebuie:

S ofere posibilitatea de a modela nu numai produse soft dar i clase mai largi de sisteme i
business-aplicaii cu utilizarea noiunilor obiect orientate.
S asigure n mod evident legatura ntre noiunile de baz ale modelelor nivelurilor
conceptual i fizic.
S asigure scalarea modelelor, ce este o calitate important a sistemelor complicate.
S fie clar pentru analiti i programatori, de asemenea trebuie s fie susinut de ctre
mijloace instrumentale speciale, realizate pe diferite platforme de calculator.

Dezvoltarea sistemei de notaii pentru APOO s-a dovedit s nu fie asemntoare cu dezvoltarea
unui nou limbaj de programare. n primul rnd era necesar de rezolvat dou probleme:
1. Notaia dat trebuie s includ n ea i specificarea cerinelor?
2. Este necesar de extins notaia dat pna la nivelul limbajului de programare vizual?

n al doilea rnd era necesar de gsit echilibrul ntre expresivitatea i simplitatea limbajului. Pe o
parte, o prea simpl notaie limiteaz sfera problemelor poteniale care pot fi rezolvate cu ajutorul
sistemului de notaii corespunztor. Pe de alt parte, o prea complicat notaie creaza dificulti
adugatoare pentru studierea i aplicarea de ctre analiti i programatori. n cazul unificrii
metodelor existente este necesar de a lua n consideraie interesele specialitilor, care au experien
de lucru cu aceste metode, fiindc introducerea schimbrilor semnificative poate atrage dup sine
nenelegerea i respingerea din partea utilizatorilor altor metode. Pentru a exclude opunerea
neevident din partea unor specialiti, este necesar de a lua n considerarie interesele pturilor largi
ale utilizatorilor. n continuare lucrul asupra limbajului de modelare unificat (Unified Modeling
Language) a trebuit s ia n consideraie toate aceste circumstane.
n aceast period suportul elaborrii limbajului UML devine unul din scopurile consoriului OMG
(Object Management Group). Cu totate c consoriul OMG a fost creat nca n anul 1989 cu scopul
de a elabora propuneri de standartizare a tehnologiilor orientate pe obiecte i componente CORBA,
limbajul UML a captat statutul de a doua direcie strategic n lucrul OMG. Anume n cadrul
OMG este creat comanda de elaboratori sub conducerea lui Richard Soli care va asigura lucrul de
mai departe asupra unificrii i standartizrii limbajului UML.
Eforturile lui G. Booch, J. Rumbaugh i Iv. Jacobson au dus la apariia primelor documente care
conineau descrierea limbajului UML versiunea 0.9 (n iunie 1996) i versiunea 0.91 (n octombrie
1996). Aceste documente cu statut de propuneri RTP (Request For Proposals) au servit ca
catalizator pentru discutarea n mas a limbajului UML de ctre diferite categorii de specialiti.
Primele preri i reacii n ce privete limbajul UML indicau necesitatea de a-l completa cu notaii i
construcii.
Compania Rational Software mpreun cu cteva organizaii, care au manifestat dorina de a aloca
resurse pentru elaborarea definiiei stricte a versiunii 1.0 limbajului UML, au fondat consoriul
partenerilor UML n care iniial au intrat aa companii ca Digital Equipment Corp., HP, i-Logix,
Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI
Unisys. Aceste companii au asigurat suportul lucrului n continuare asupra definirii unei notaiei
nc mai stricte i precise, ceea ce a dus la apariia versiunii 1.0 limbajului UML.
Particularitatea limbajului UML const n aceea ca limbajul definete metamodelul semantic, dar nu
modelul unei interfee concrete i metodele de prezentare i realizare a componentelor.
n prezent toate ntrebrile elaborrii n continuare a limbajului UML sunt concentrate n limitele
consoriului OMG. Grupul corespunztor de specialiti asigur publicarea materialelor care conin
descrierea versiunilor urmtoare ale limbajului UML i a propunerilor RFP de standardizarea. O
urmtoare etap de dezvoltare a acestui limbaj s-a terminat n martie anului 2003 cind consoriul
OMG a publicat descrierea limbajului UML 2.0. Istoria elaborrii i dezvoltrii urmtoare al
limbajului UML este reprezentat grafic n fig. 1.
Pe baza tehnologiei UML Microsoft, Rational Software i ali furnizori de medii de dezvoltare a
sistemelor de programare au elaborat modelul informaional unic care a fost numit UML
Information Model. Se presupune c acest model va da posibilitatea diferitor programe care suport
ideologia UML s fac schimb de componente i descrieri. Toate acestea vor permite crearea
interfeei standarde ntre mijloacele de elaborare i mijloacele de modelare vizuala.

Fig. 1. Istoria dezvoltrii limbajului UML.

Deja n prezent sunt elaborate mijloace de programare vizual pe baza lui UML care asigura
integrarea, inclusiv generare directa i invers a codului de programe cu cele mai raspndite limbaje
i medii de programare, aa cum sunt MS Visual C++, Java, C#, Object Pascal/Delphi, Power
Builder, MS Visual Basic, Forte, Ada, Smalltalk. Deoarece la elaborarea limbajului UML au fost
luate n consideraie multe idei i metode de frunte se poate de ateptat c versiunile urmtoare ale
limbajului UML vor fi influenate i de alte tehnologii i conceptii de perspectiv. n plus la aceasta
n baza limbajului UML pot fi definite multe metode perspective noi. Limbajul UML poate fi extins
fr o redefinire nucleului su.

2. Componente de baza ale limbajului UML

Limbajul UML reprezint limbajul de destinaie general al modelrii vizuale, care este elaborat
pentru specificarea, vizualizarea, construirea i documentarea componentelor produsului soft,
business-proceselor i altor sisteme. Totodat limbajul UML este un mijloc de modelare simplu i
puternic care poate fi utilizat efectiv pentru construirea modelelor conceptuale, logice i grafice ale
sistemelor complexe de diferit destinaie. Acest limbaj conine cele mai bune caliti ale metodelor
ingineriei de program care au fost utilizate cu succes pe parcursul ultimilor ani la modelarea
sistemelor complexe.
Limbajul UML este bazat pe un anumit numr de noiuni principale care pot fi studiate i aplicate
de ctre majoritatea programitilor i elaboratorilor cunoscui cu metodele de analiza i proiectarea
obiect orientate. Totodat noiunile de baz pot fi combinate i extinse n asa fel c specialitii
modelrii orientate pe obiecte pot elabora de sinestttor modele ale sistemelor complexe n diferite
domenii de aplicare.

Utilizarea constructiv a limbajului UML este bazat pe inelegerea principiilor comune de

modelare a sistemelor complexe i a particularitilor procesului de analiza i proiectarea obiect
orientate. Alegerea mijloacelor expresive pentru construcia modelelor ale sistemelor complexe
stabilete din vreme problemele care pot fi rezolvate cu ajutorul utilizrii acestor modele. Totodat
unul din principiile de baz pentru construirea modelelor ale sistemelor complexe este principiul de
abstractizare care presupune includerea n model numai a acelor aspecte ale sistemului proiectat,
care au nemijlocit legtura cu executarea de ctre sistem a funciilor sale sau cu destinaia lui de
baza. Totodat toate detalii de importana secundar sunt omise pentru ca procesul de analiza i
cercetare a modelului primit s nu fie foarte complicat.
Alt principiu de construcie a modelelor ale sistemelor complexe este principiul de multi-modele.
Acest principiu reprezint afirmaia c nici un model unic nu poate descrie diferite aspecte ale
sistemului complex. Cu privire la metodologia APOO aceasta nseamn c un model destul de
complet al unui sistem complex admite un anumit numr de reprezentri (views) legate reciproc,
fiecare din ele reflectnd adecvat un anumit aspect de comportare sau structura a sistemului.
Totodat cele mai generale reprezentri ale unui sistem complex sunt considerate reprezentri
statice i dinamice care la rndul lor pot fi divizate n alte reprezentri particulare.
nca un principiu al analizei aplicate de sistem este principiul de construire ierarhic a modelelor
sistemelor complexe. Acest principiu presupune cercetarea procesului de construire a modelului la
diferite nivele de abstractizare sau detaliere n limitele reprezentrilor stabilite. Totodat modelul
iniial sau elementar al unui sistem complex are reprezentarea cea mai generala (meta-reprezentare).
Un astfel de model se construiete la etapa iniial de proiectare i poate s nu conin multe detalii
i aspecte ale sistemului modelat.
Reprezentare logica

Reprezentare realizrii

Utilizatorul final
Relaii structurale
exterioare i inferioare

Programistul
Relaii ntre componente
ale produsului soft

Reprezentare procesului de
funcionare
Integratorul de sistem
Randamentul i volumul
componentelor al unui sistem

Model conceptual

Model al
unui sitem
complex

Reprezentare deplasrii
componentelor
Administratorul de sistem
Topologia legaturilor i
comunicaiilor ale
componentelor

Model
static

Model
dinamic

Model fizic

Fig. 2 Schema comun legturilor modelelor i reprezentrilor ale unui sistem complex n procesul
APOO.
n aa fel, un proces APOO poate fi reprezentat ca o coborre pe nivele: de la cele mai generale
modele i reprezentri de nivel conceptual spre reprezentri mai particulare i detaliate ale nivelului
6

logic i fizic. Totodat la fiecarea etap a procesului APOO modelele date sunt completate
consecvent cu un numr din ce n ce mai mare de detalii ce le premite s reflecte mai adecvat
diferite aspecte ale realizrii unui anumit sistem complex. Schema comun legturilor modelelor
APOO este reprezentat n fig. 2.

2.1. Structura general a limbajului UML

UML const din dou pari interdependente:

Semantica limbajului UML reprezint un careva metamodel, care definete sintaxa abstracta
i semantica noiunilor modelrii orientate pe obiecte n limbajul UML.
Notaia limbajului UML reprezint o notaie grafica pentru reprezentarea vizual a
semanticii limbajului UML.

Sintaxa abstract i semantica limbajului UML sunt descrise cu ajutorul unei anumite submulimi
de notaii ale UML. n completare la aceasta, notatia UML descrie corespunderea sau reprezentarea
notaiei grafice n semantica noiunilor de baza. n aa fel din punct de vedere funcional aceste
dou pri completeaz una pe alt. Totodat semantica limbajului UML este descris pe baza unui
metamodel care are trei reprezentri aparte: sintaxa abstract, reguli de construcia corect a
expresiilor i semantica. Cercetarea semanticii limbajului UML presupune un careva stil semiformal
de redare, care unifica limbaje naturale i formale pentru reprezentarea noiunilor de baza i
regulilor de extindere a lor.
Semantica se definete pentru dou tipuri de modele de obiecte: de structura i de comportare.
Modelele de structur, cunoscute ca modele statice, descriu structura entitilor sau a componentelor
unui sistem inclusiv clase, interfee, atribute i relaii. Modelele de comportare, numite uneori
dinamice, descriu comportarea sau funcionarea obiectelor unui sistem, inclusiv metodele lor,
colaborarea ntre ele, i procesul de schimbare a strilor unor componente aparte i al sistemului
ntreg.
Pentru rezolvarea unui diapazon att de larg de probleme de modelare este elaborat semantica
destul de complet pentru toate componentele notaiilor grafice. Cerinele semanticii limbajului
UML sunt concretizate la construirea anumitor tipuri de diagrame. Notaia limbajului UML include
n sine descrierea elementelor semantice care pot fi utilizate la construcia diagramelor.
Descriere formal a limbajului UML se bazeaza pe careva structur ierarhic comun a
reprezentrilor de model care const din patru nivele:

Meta-metamodelul
Metamodelul
Modelul
Obiectele utilizatorului

Nivelul de meta-metamodel creaz o baz iniial pentru toate reprezentri de metamodele.

Destinatia principal a acestui nivel const n definiia limbajului pentru specificarea
metamodelului. Meta-metamodelul definete modelul limbajului UML la cel mai nalt nivel de
abstractizare i cea mai compact descriere a lui. Din alt parte, meta-metamodelul poate specifica
cteva metamodele ce permite atingerea flexibilitii poteniale de includere a noiunilor
adugtoare. Ca exemple de notaii ale acestui nivel pot fi meta-clasa, meta-atribut, meta-operaie.
Semantica meta-metamodelului nu intra n descrierea limbajului UML. Aceasta face limbajul UML
mai simplu pentru studiere, fiindc nu cere cunoaterea teoriei limbajelor formale i a logicii
formale.
7

Metamodelul este un exemplar sau concretizarea meta-metamodelului. Scopul principal acestui

nivel este definirea limbajului pentru specificarea modelelor. Acest nivel este mai constructiv dect
cel precedent, fiindc semantica lui ale noiunilor de baz este mai dezvoltat. Toate noiunile de
baz ale limbajului UML sunt noiunile nivelului de metamodel. Exemple de aceste notiuni sunt
clasa, atributul, operaia, componenta, asocierea i multe alte.
Modelul n contextul limbajului UML este exemplarul metamodelului n sensul c fiecare model
concret a unui sistem trebuie s utilizeze numai noiunile lui metamodel concretizndu-le cu privire
la situaia dat. Acest nivel este pentru descrierea informaiei despre un domeniu concret (de
obiecte).Ca exemple a acestui nivel pot fi numele cmpurilor ale bazei de date proiectate, de
exemplu, numele i prenumele angajatului, vrsta, postul, adresa, numrul de telefon. Totodat
noiunile date sunt utilizate numai ca nume ale atributelor informaionale corespunztoare.
Descrierea semanticii limbajului UML presupune cercetarea noiunilor de baz numai ale nivelului
metamodel care reprezint numai exemplu sau caz particular al nivelului meta-metamodel.

2.2. Particularitatea (specificul) limbajului UML

UML este un instrument standard pentru crearea carcaselor de documentare (desenelor) ale
produsului soft. UML este un limbaj de vizualizare, specificare, construcie i documentare
artefactelor sistemelor de program. Vom aminti c artifactul o diagrama, un document, un model,
o lege .a. este ceva ce descrie o anumit noiune a domeniului de obiecte. UML este elaborat n
aa fel c s poat satisface cerinele ctre modelarea oricrui sistem ncepnd cu sisteme
informaionale de dimensiunea unei ntreprinderi pna la Web-aplicaii distribuite i sisteme
integrate n timp real. UML este un limbaj expresiv care permite cercetarea sistemei din toate
punctele de vedere care au legtura cu elaborarea i desfsurarea ei urmtoare. Nectind la numrul
mare de posibilitti expresive, acest limbaj rmne simplu pentru intelegere i utilizare.
Cercetarea UML vom incepe cu modelul lui conceptual care conine trei elemente de baz:
construcii de baz, reguli, care determin felul n care construcii pot fi combinate, i unele
mecanizme comune ale limbajului.
Cu totate c UML nu depinde de realitate modelat este mai bine s fie utilizat cnd procesul de
modelare este bazat pe cercetarea descrierei textuale a proceselor executate n domeniu de obiecte i
sistemul are arhitectura strict evideniat. n asa fel limbajul este ideal pentru Unificarea procesului
de elaborare.
Ca i oricare limbaj, UML const dintr-un dicionar i reguli care permit combinarea cuvintelor de
intare i primirea construciilor cu sens. n limbajul de modelare dicionarul i regulile sunt orientate
spre reprezentarea conceptual i fizic ale unui sistem. Limbajul de modelare, aa cum este UML,
este un mijloc standard pentru elaborarea desenelor produsului soft.
Modelarea este necesar pentru inelegerea sistemului. n mod obinuit un model unic nu poate fi de
ajuns. Din contra, pentru inelegerea practic a oricrui sistem netrivial este necesar dezvolaterea
unui numr enorm de modele interdependente. n aplicare ctre sisteme de program aceasta
nseamn necesitatea unui limbaj cu ajutorul cruia din toate punctele de vedere poate fi descris
arhitectura unui sistem pe parcursul ciclului de dezvoltare.
Dictionarul i regulile unui aa limbaj ca UML explic modul de creare i de citire a anumitor
modele, dar nu explic care modele sunt mai potrivite pentru diferite cazuri. Aceasta este sarcina
principal pentru tot procesul de elaborare a produsului soft. Organizarea unui aa proces este un
lucru deosebit de individual n limitele diferitor companii de program i grupelor de elaboratori ai
8

produsului soft. Un proces bine organizat trebuie s arate care artefacte trebuiesc, care resurse sunt
necesare pentru crearea lor, cum pot fi utilizate aceste artefacte pentru aprecierea lucrului executat
i administrarea proiectului n ntregime.

2.2.1. UML limbaj de vizualizare

Trstura caracteristica a majoritii programitilor este faptul c gndurile despre realizarea
proiectului sunt echivalente scrierei codului pentru acest proiect. Dac gndim despre proiectul
nseamn c l codificm, desigur, unele lucruri sunt mai bine exprimate n codul al unui anumit
limbaj de programare, fiindc codul sursei (listingul programului) este cel mai scurt drum spre
scrierea algoritmelor i calcului.
n unele cazuri programistul se ocup cu modelarea cu toate c acest proces nu este formal. Tratare
de aa fel este plin de neplceri. Mai nti schimbarea prrilor despre modelul proiectat se poate
numai atunci cnd toi participanii se exprim n acelai limbaj. Aceasta nseamn ca compania Dstr n-ar putea s angajeze un programist excelent n C dac el utilizeaz Delphi! Sau noul angajat
n-ar putea s ineleag despre ce merge vorba. n al doilea rnd nu putem s inelegem aspectele de
program al unui sistem fr modelul respectiv marginele cruia nu intr n cadrul limbajului textual
de programare. De exemplu rolul ierarhiei claselor se poate de ineles studiind codul fiecrei clase,
dar de ineles toat structura este foarte greu. Analogic cercetarea codului unui sistem nu permite s
avei o imagine complet despre distribuirea fizic sau despre migraia obiectelor n aplicaii Web.
n al treilea rnd dac analistul de sistem al companiei D-stre niciodat n-a creat modelurile
proiectate n form clar toat informaia va fi pierdut daca analistul va fi atras de firma
concurent. n cel mai bun caz rezultatele analizei acestui analist vor fi restabilite parial reieind
din realizarea lor.
Utilizarea UML-lui permite rezolvarea acestor problemelor. Acest limbaj de programare nu este
doar un set de simboluri grafice, fiecare din ele se bazeaz pe semantica respectiv, ce nseamn c
modelul creat de un elaborator poate fi uniform interpretat de altul i nu neaparat de alt om, n
calitate de al doilea elaborator poate fi i un anumit mijloc instrumental. Sfritul primei probleme.
Unele trsaturi ale sistemului sunt mai bine modelate ca textuale, alte ca grafice. Pratica arat ca
n toate sistemele interesante exist structuri care nu pot fi interpretate fr ajutorul unui limbaj de
programare. UML este un limbaj grafic ce permite rezolvarea acestei probleme (a doua problem).
n sfrit modelul clar uureaz comunicarea, ce nseman c a treia problem nu se mai pune.

2.2.2. UML limbaj de specificare

n contextul dat prin specificare subnelegem construirea modelelor precise i complete. UML
permite specificarea tuturor soluiilor importante care se refer la analiza, proiectarea i realizarea n
procesul elaborrii produsului soft.

2.2.3. UML limbaj de construire

UML nu este un limbaj de programare vizual, dar toate modele elaborate n baza lui pot fi
transformate n codul surs a diverselor limbaje de programare obiect orientate. Acele noiuni care
sunt uor reprezentate grafic aa i sunt transformate (incluse) n UML, dar acele care mai bine sunt
decrise n codul sursei se transform cu ajutorul limbajului de programare.
Aa mod de reprezentare n limbaj de programare permite proiectarea direct sau generarea codului
dup modelul UML ntr-un anumit limbaj de programare. Problema invers tot poate fi rezolvat, ea
permite reconstruirea unui model conform realizrii existente. Aceast proiectare invers nu
prezint ceva neobinuit. Daca n-am codificat informaia n realizare atunci ea poate fi pierdut la
9

trecerea direct de la modelul la codul sursei. nseamn c pentru proiectarea invers (indirecta)
sunt necesare mijloace instrumentale i colaborarea programistului sau analistului de sistem.
Combinarea generrii directe a codului i proiectrii indirecte permite a lucra n prezentare grafic
i textual dac programele instrumentale asigur coordonare ntre aceste dou prezentri al
proiectului.
n afar de reflectare direct datorit expresivitii i uniformitii limbajul UML permite executarea
modelelor, imitarea colaborrii sistemului i controlul sistemului care funcioneaz.

2.2.4. UML limbaj de documentare

Compania ce lanseaz programul soft pe lnga codul surs produce i alte artefacte, inclusiv:

cerine ctre sistem;

arhitectura;
proiectul;
codul iniial;
planuri de proiecte;
teste;
prototipuri;
versiuni s.a.

n dependena de metodica elaborrii stabilit unele lucrurile se execut mai formal dect altele.
Artifactele menionate mai sus sunt necesare pentru administrarea, aprecierea rezultatelor i ca
mijloc de comunicare ntre membrii colectivului n timpul elaborrii proiectului i desfurrii lui.
UML permite rezolvarea problemei de documentare a arhitecturii sistemului, ofer limbajul pentru
definirea formal a cerinelor ctre sistemul i ctre teste, definete mijloace pentru modelarea
lucrurilor pe etapa planificrii proiectului i administrrii versiunelor.
Limbajul UML este destinat n primul rnd elaborrii sistemului de programare. Utilizarea lui este
cu mult mai eficienta n urmatoarele sfere:

sisteme informaionale;
servicii bancare i financiare;
telecomunicaie;
transport;
industria de aprare, aviaie, cosmonautic;
sisteme comerciale;
electronica medical;
tiina;
distribuirea sistemului Web.

Sfera de aplicare a limbajului UML nu se limiteaz la modelarea produsului soft. Expresivitatea lui
permite modelarea documentelor n sisteme juridice, modelarea structurii i functionalitatea
sistemelor de deservire a pacienelor n spitale, proiectarea aparaturii.
Pentru inelegerea limbajului este necesar de cunoscut principiile de baz a structurii acestui limbaj.
Sunt numai trei principii i limbajul parc const din trei pri: construcii de baz ale limbajului,
reguli de colaborare i anumite mecanizme comune. tiind toate aceste ideile vom putea citi
modelele n UML i s le proiectm, desigur c vom ncepe cu cele mai simple. Pe parcursul

10

obinerii experienei de lucru cu limbajul vom nva s utilizm posibilitile limbajului mai
avansate.
Dicionarul limbajului nclude trei tipuri de construcii de baz:

entiti abstracii ce sunt elemente de baz a modelului;

relaii legturi ntre entiti;
diagrame ce grupeaz interesele entitilor i relaiilor.

2.3. Entiti n UML

n UML sunt patru tipuri de entiti:

de structur;
de comportament;
de grupare;
de adnotare.

Entiti sunt elementele OO de baz ale limbajului. Cu ajutorul entitilor este posibil crearea
modelelor corecte. Entittile de structur sunt substantivele n modelurile ale limbajului UML. De
regul ele reprezint pri statice ale modelelor care corespund elementelor conceptuale i fizice ale
sistemului. Exist apte varieti de entiti de structur:
Clasa (class) este o descriere a unei totaliti de obiecte cu atribute, operaii, relaii i semantica
comun. Grafic o clasa se reprezint printr-un dreptunghi n care se specific numele, atributele i
operaiile clase, exemplu este artat n fig. 3.
NumeleClasei
<<->> AtributPrivat : char
<<#>> AtributProtejat
<<+>> AtributPublic
<<+>> op1()
<<+>> op2()

Fig. 3. Clasa.
Interfaa (interface) este o totalitate de operaii care definesc servicii oferite de clas sau
component. n diagrame interfaa se reprezint printr-un cerc etichetat cu numele interfeei, fig. 4.
Interfaa foarte rar exist aparte de obicei ea este legat cu clasa sau componenta care o realizeaz.

Interfata1

Fig. 4. Interfaa.
Colaborarea (collaboration) definete o interaciune, ea reprezint o totalitate de roluri i alte
elemente care produc un efect cooperativ i care nu se aduce numai la suma termenilor unei
adunri. Grafic colaborarea se reprezint printr-o elips cu linie ntrerupt, interiorul creia conine
numai numele colaborrii, fig. 5.

11

Colaborare1

Fig. 5. Colaborare.
Cazul de utilizare (use case) este o descriere a consecutivitii de aciuni ndeplinite de sistem care
produc un rezultat semnificativ pentru un anumit actor. Grafic cazul de utilizare se reprezint
printr-o elips cu linie continue n interiorul creia se conine denumirea cazului de utilizare, fig. 6.

Cazul de
utilizare 1

Fig. 6. Caz de utilizare.

Clasa activ (active class) se numete o clas obiectele creia sunt antrenate n unul sau mai multe
procese sau n iruri (threads) i deaceea ele pot iniia o aciune administrativ. Grafic o clas activ
se reprezint ca i o clas simpl, dar se limiteaz cu un dreptunghi cu marginile groase i care
conine numele, atributele i operaiile clasei date, fig. 7.
NumeleClasei
<<->> AtributPrivat : char
<<#>> AtributProtejat
<<+>> AtributPublic
<<+>> op1()
<<+>> op2()

Fig. 7. Clasa activ.

Componenta (component) este o parte fizic a sistemului, care corespunde unui anumit set de
interfee i asigur realizarea lui. Grafic o component se reprezint printr-un dreptunghi cu anexe,
care de obicei conine numai numele componentei, fig. 8.
Componenta1

Fig. 8. Component.
Nodul (node) este un element real (fizic) al unui sistem care reprezint un mijloc de calcul cu un
anumit volum de memorie i deseori cu capacitate de prelucrare a informaiei i care exist n
timpul funcionrii unui produs soft. Grafic pentru reprezentarea nodului se utilizeaz cubul care
conine numele nodului, fig. 9.
Nod 1

12

Fig. 9. Nod.
apte elemente de baz enumerate: clase, interfete, colaborri, cazuri de utilizare, clase active,
componente i noduri sunt entitile principale de structur care pot fi utilizate n diagramele UML.
Exist i alte varietti ale entitilor de structur: actori, semnale, utilite (tipurile de clase), procese
i iruri (tipuri de clase active), aplicaii, documente, fiiere, biblioteci, pagini i tabele (tipuri de
componente).
Entitile de comportament (behaviour things) sunt prile dinamice ale modelului UML. Acestea
sunt verbele limbajului care descriu comportarea modelului n timpul i n spaiu. Exist numai
doua tipuri de entiti de comportament.
Interaciunea (interaction) este un mod de comportare care const n schimb reciproc de mesaje
(messages) ntre obiecte n cadrul unui anumit context pentru a atinge un anumit scop. Cu ajutorul
interaciunii se descrie att o operaie ct i comportarea unui set de obiecte. Interaciunea
presupune un ir de alte elemente ca mesaje, consecutivitate de aciuni (comportare, iniializat de
ctre mesaje) i legturi (ntre obiecte). Grafic mesajul se reprezint print-o sgeat deasupr careia
se indic numele mesajului, fig. 10.
CreazaObiect()

Fig. 10. Mesaj.

Automatul (state machine) este un algoritm de comportare care definete o succesiune de stri prin
care trece un obiect sau o interaciune pe parcursul ciclului de viaa rspunznd la diferite
evenimente i reaciile lui la aceste evenimente. Cu ajutorul automatului se descrie comportarea
unei clase sau a unei colaborri de clase. Cu automatul este legat un ir de alte elemente: stri,
tranziii de la o stare la alt, evenimente care sunt entitti ce iniiaz tranziii i tipuri de actiuni reacii la tranziii. Grafic o stare se reprezint printr-un dreptunghi cu coluri rotungite care conine
numele strii sau posibil i strile intermediare, fig. 11.
Stare 1

Fig. 11. Stare.

Interaciunile i automatele sunt entitile principale de comportament care pot fi utilizate n
diagramele UML. Semantic ele sunt legate cu diferite elemente de structur, n primul rnd cu clase,
cooperri i obiecte.
Entitile de grupare sunt prile organizatorice ale modelului UML. Ele reprezint blocuri n care
poate fi divizat modelul. O astfel entitate primar este unic pachetul.
Pachetele (packages) reprezint un mecanism universal de organizare n grupe. n pachet pot fi
plasate entitile de structur, de comportament i alte entiti de grupare. Spre deosebire de
componentele care exist real, n timpul execuiei unui program, pachetele au caracter pur
conceptual, adic ele exist doar n timpul elaborrii. Pentru reprezentarea unui pachet se utilizeaz
notaia unei mape cu semn de carte care conine deseori numai numele i doar uneori i coninutul,
fig. 12.
13

Fig. 12. Pachet.

Entitile de adnotare sunt prile explicative ale unui model UML. Acestea sunt comentarii
destinate descrierii adiionale, explicaiei sau observaiei ctre orice element al unui model. Exist
numai un singur tip de baz al elementelor de adnotare remarca.
Remarca (note) este numai un simbol pentru reprezentarea comentariilor sau a constrngerilor,
legate de un element sau de un grup de elemente. Grafic o remarc se reprezint printr-un
dreptunghi cu colul de sus din dreapta ndoit i care conine comentariul textual sau grafic, fig. 13.

Fig. 13. Remarca.

Acest element este entitatea de adnotare principal care poate fi utilizat n modelul UML. De
obicei remarca se utilizeaz pentru a asigura diagramele cu comentarii sau cu constrngeri care pot
fi reprezentate sub form de text formal sau neformal. Exist i variante ale acestui element, de
exemplu cerine care descriu comportarea dorit a unui sistem din punct de vedere exterior
modelului.

2.4. Relaii UML

In limbajul UML sunt definite patru tipuri de relaii:

Dependena
Asocierea
Generalizarea
Realizarea

Aceste relaii sunt construcii principale de legare n UML i sunt utilizate pentru construirea
modelelor corecte.
Dependena (dependency) este o relaie semantic ntre dou entiti astfel nct modificarea uneia
din ele,a celei independente, poate influena semantica celeilalte, dependente. Grafic pentru
reprezentarea dependenei se utilizeaza o linie ntrerupt, deseori cu sgeat care poate conine o
etichet.

Fig. 14. Dependena.

Asocierea (association) este o relaie de structur care descrie o totalitate de legturi, prin legtur
se subnelege conexiunea semantic ntre obiecte. n calitate de simboluri suplementare pot fi
utilizate numele unei asocieri, numele i multiplicitatea claselor rolurile asocierii. Numele
asocierii nu este un element obligatoriu. Dac numele este dat, atunci el se scrie cu majuscul lnga

14

linia ce corespunde asocierei. Grafic asocierea se reprezint printr-o linie (care uneori se termin cu
o sgeat sau este etichetat), fig. 15.
NewClass

Angajeaza

1
-Angajat

NewClass2

-Angajator

Fig. 15. Asocierea.

O form special sau caz particular al relaiei de asociere se socoate relaia agregrii care la rndul
su are o form special compoziia.
Agregare (aggregation) este o anumit relaie ntre ntreg i prile lui componente. Aceast relaie
are un sens fundamental pentru descrierea sistemelor complexe fiindc se utilizeaz pentru
reprezentarea legturilor parte-ntreg. Dezvluind structura interioar a sistemului, relaia de
agregare arat din ce elemente const sistemul i cum elementele sunt legate. Din punct de vedere al
modelului prile aparte ale sistemului pot fi socotite ca elemente i ca subsisteme care la rndul lor
pot crea componente sau subsisteme. Grafic relaia de agregare se reprezint printr-o linie continu,
unul din capetele creia reprezint un romb gol. Acest romb arat ntregul i restul - prile,
fig. 16.
Intreg

Parte

Fig. 16. Agregare.

Relaia compoziie este cazul particular al relaiei de agregare. Aceast relaie este destinat
prezentrii formei speciale a relaiei parte-ntreg n care prile componente sunt n interiorul
priii ntregi. Specifica legturii ntre ele const n aceea c prile componente nu pot exista fr
partea ntreag, adic cu distrugerea ntregului se destrug i prile componente a lui.
Grafic relaia de compoziie se reprezint printr-o linie continu, unul din capetele cruia reprezint
un romb haurat. Acest romb arat clasa-compoziie sau ntregul i restul sunt prile lui, fig.
17.

Fig. 17. Compoziie.

Generalizarea (generalization) este o relaie de tip specializare/generalizare n urma creia un
obiect al elementului specializat (descendent) poate substitui obiectul elementului generalizat
(printe). Descendentul (child) motenete structura i comportamentul printelui (parent) su.
Grafic relaia de generalizare se reprezint printr-o linie cu o sgeat goal care arat printe, fig.
18.
Child

Parent

Fig. 18. Generalizarea.

15

Realizarea (realization) este o relaie semantic ntre clasificatori n care un clasificator definete un
contract, iar cellat garanteaz ndeplinirea lui. Relaia de realizare se ntlnete n cazurile
urmtoare: ntre interfee i clase sau componente care realizeaz aceste interfee, i ntre cazuri de
utilizare i colaborri care le realizez. Relaia de realizare se reprezint printr-o linie ntrerupt cu o
sgeat goal, ca ceva intermediar ntre relaiile generalizare i dependena, fig. 19.

Fig. 19. Realizare.

2.5. Diagrame UML

n cadrul limbajului UML toate reprezentrile modelului unui sistem complex sunt fixate n calitate
de construcii speciale grafice care deseori sunt reprezentate sub form de graf conex cu noduri
entiti i muchii relaii. n UML sunt definite nou tipuri de diagrame:

Diagrame cazurilor de utilizare (use case diagram)

Diagrame de clase (class diagram)
Diagrame de comportament (behavior diagrams)
o Diagrame de stri (statechart diagram)
o Diagrame de activiti (activity diagram)
o Diagrame de interaciune (interaction diagrams)
Diagrame de secven (sequence diagram)
Diagrame de colaborare (collaboration diagram)
Diagrame de realizare (implementation diagrams)
o Diagrame de componente (component diagram)
o Diagrame de plasare (deployment diagram)

Lista acestor diagrame i denumirilor respective este canonica n caz dac diagramele reprezint
partea integrant a notaiei grafice a limbajului UML. Mai mult dect att, procesul APOO este
strns legat de procesul construirii acestor diagrame. Totodat o totalitate de diagrame construite n
aa fel este suficient n caz dac diagramele conin informaia necesar pentru realizarea
proiectului unui sistem complex.
Fiecare din aceste diagrame detalizeaz i concretizeaz diferite reprezentri despre modelul unui
sistem complex n termenii limbajului UML. Totodat diagrama cazurilor de utilizare reprezint cel
mai general model conceptual al unui sistem complex care este iniial pentru construirea tuturor
celorlalte diagrame. Diagrama de clase este un model logic care reflect aspectele statice ale
procesului de construire structural a unui sistem complex.
Diagramele de comportament la fel sunt varieti ale unui model logic care reflect aspectele
dinamice ale procesului de funcionare a unui sistem complex. Diagramele de realizare sunt
destinate reprezentrii fizice a componentelor sistemului complex i de aceea sunt atribuite
modelului fizic. Modelul integrat al unui sistem complex n notaia UML (fig. 20) se reprezint ca
totalitatea diagramelor enumerate mai sus.

16

Fig. 20. Model al unui sistem complex n notaia UML.

3. Diagarama cazurilor de utilizare (use case diagram)

Modelarea vizual n UML poate fi reprezentat ca un oarecare proces de lansare pe niveluri de la
cel mai general i abstract model conceptual al sistemului iniial ctre model logic i mai apoi fizic,
ce corespunde unui sistem de program. Pentru atingerea acestui scop de la nceput se creaz un
model n form de diagarama cazurilor de utilizare (use case diagram) care descrie destinaia
functional a sistemului sau cu alte cuvinte descrie ceea ce sistemul va executa n procesul su de
funcionare. Diagrama cazurilor de utilizare reprezint un model iniial conceptual al unui sistem n
procesul de proiectare i exploatare.
Proiectarea a unei diagrame a cazurilor de utilizare urmrete scopurile urmtoare:

determinarea limitelor comune i a contextului domeniului de modelare la etapele iniiale de

proiectare a unui sistem;
formularea cerinelor comune ctre comportare funcional a sistemului proiectat;
elaborarea modelului iniial conceptual al unui sistem pentru detalierea de mai trziu n
forma modelelor logice i fizice;
pregtirea documentrei iniiale pentru interaciunea elaboratorilor unui sitem cu clienii i
utilizatorii.

Esena acestei diagrame const n faptul c: sistemul proiectat se reprezint ca o colecie de entiti
i actori care colaboreaz cu sistemul cu ajutorul aa numitor cazuri de utilizare. Totodat orice
entitate care colaboreaz cu sistemul din afar poate fi numit actor. Aceasta poate fi un om, o
instalare tehnic, un program sau oricare alt sistem care poate fi surs de aciune pentru sistemul
proiectat n aa mod, cum l determin colaboratorul. La rndul su, use case-ul este creat pentru
descrierea serviciilor pe care sistemul le ofer actorului. Cu alte cuvinte fiecare caz de utilizare
definete o colecie de aciuni executate de sistem n timpul dialogului cu actorul. Totodat nimic nu
este spus despre aceea n ce mod va fi realizat colaborare ntre actori i sistem.
n caz general, diagrama cazurilor de utilizare reprezint un graf deosebit, care este o notaie grafic
pentru prezentarea cazurilor de utilizare concrete, actorilor, poate i a unora interfee i pentru
prezentarea legturilor ntre aceste elemente. Totodat componente aparte ale diagramei pot fi
incluse ntr-un dreptunghi, care semnific sistemul proiectat n ntregime. Trebuie de specificat c
legturile acestui graf pot fi de numai anumite tipuri de interaciuni ntre actori i cazuri de utilizare,
care mpreun descriu servicii i cerine funcionale ctre sistemul modelat.
17

3.1. Cazul de utilizare

Structura sau elementul standart al limbajului UML caz de utilizare se folosete pentru
specificarea particularitilor comune ale comportrii unui sistem sau a oricrei alte entitti n
domeniul de lucru fr cercetarea structurii interne a acestei entiti. Fiecare caz de utilizare
determin o succesiune de aciuni care trebuie sa fie executate de ctre sistemul poiectat la
colaborarea lui cu actorul corespunztor. Diagrama cazurilor de utilizare poate fi completat cu text
explicativ, care desfoar sensul sau semantica componentelor ce o compun. Acest text se numete
adnotare sau scenariu.
Cazul de utilizare aparte se noteaz cu o elips n interiorul creia se conine denumirea prescurtat
sau numele n form de verb cu cuvinte explicative (fig. 6).
Scopul cazului de utilizare const n determinarea aspectului terminal sau fragmentului de
comportare a unei entiti fr desfurarea structurii interne a acestei intiti. n calitate de aa
entitate poate fi un sistem iniial sau un element al modelului care dispune de comportament
propriu, precum este subsitemul sau clasa n modelul unui sistem.
Fiecare caz de utilizare corespunde unui serviciu aparte, care reprezint o entitate modelat sau un
sistem la cererea utilizatorului (actorului), mai precis determin metoda aplicat ctre anumit
entitate. Serviciul care este iniializat la cererea utilizatorului reprezint o succesiune terminat de
aciuni. Aceasta nseamn c dup ce sistemul va termina prelucrarea cererii utilizatorului el
(sistemul) trebuie sa se intoarc n starea iniial n care este gata pentru a indeplini cererile
urmtoare.
Cazurile de utilizare descriu nu numai colaborarea ntre utilizatori i entiti, dar i reacia entitii
la primirea anumitor mesaje de la utilizatori i asupra percepiei acestor mesaje n afar entitii.
Cazurile de utilizare pot include (conine) descrierea specificaiilor modurilor de realizare a
serviciului i a diferitor situaii excepionale, aa cum este prelucrarea corect a erorilor unui sistem.
Mulimea cazurilor de utilizare n total poate determina toate aspecte posibile comportrii ateptate
a unui sistem. Pentru comoditate mulimea cazurilor de utilizare poate fi considerat ca un pachet
aparte.
Din punct de vedere sistemo-analitic cazurile de utilizare pot fi folosite pentru specificarea
cerinelor externe ctre sistemul proiectat i pentru specificarea comportrii funcionale a sitemului
deja existent.
Exemple de cazuri de utilizare pot fi aciunile urmtoare: verificarea strii contului curent al
clientului, intocmirea comenzii la procurarea mrfii, obinerea informaiei suplimentare despre
solvabilitatea clientului, reprezentarea formei grafice la ecranul monitorului s.a.

3.2. Actori
Actorul reprezint orice entitate extern sistemului modelat, care colaboreaz cu sistemul i
utilizeaz posibilitile lui funcionale pentru atingerea anumitor scopuri i pentru rezolvarea
problemelor particulare. Totodat actorii sunt utilizai pentru notarea mulimii rolurilor coordonate
ale utilizatorilor n procesul de colaborare cu sistemul proiectat. Fiecare actor poate fi considerat un
anumit rol aparte relativ unui caz de utilizare concret. Notaia grafic standard a unui actor n
diagram este omuleul sub care se indic numele actorului (fig. 21).

18

Fig. 21. Actor.

n unele cazuri actorul poate fi notat ca dreptunghiul clasei cu cuvntul-cheie actor i cu
elementele comune ale clasei. Numele actorilor trebuie s fie scrise cu litere majuscule i trebuie s
respecte recomandrile la utilizarea numelor pentru tipurile i clasele modelului. Totoadat simbolul
actorului aparte leag descrierea corespunztoare a actorului cu un anumit nume. Numele actorilor
abstraci, aa cum i a altor elemente abstracte n limbajul UML, se recomand de notat n italic.
Ca exemplu de actori pot fi: clientul unei bnci, angajatul unei bnci, vnztorul unui magazin,
managerul seciei de vnzare, pasagerul unui avion, conductorul unui auto, administratorul unui
hotel, celularul i alte entiti, care au legtur cu modelul conceptual care corespunde domeniului
de lucru.
Actorii sunt utilizai pentru modelarea entitilor exeterne sitemului de entiti proiectat, care
acioneaz reciproc cu sistemul i pe care l utilizez n calitate de utilizatori separai. n calitate de
actori pot fi i alte sisteme, subsisteme ale sistemului proiectat sau clase aparte. Este important s
intelegem c actorul definete o anumit mulime de roluri coordonate, care pot fi utilizatorii unui
sistem dat n procesul de colaborare. n fiecare moment de timp cu sistemul colaboreaz un anumit
utilizator n unul din roluri date. Ca exemplu evident de actor poate fi un anumit utilizator al
sistemului cu parametri de autentificare proprie.

3.3. Interfee
Interfaa (interface) specific parametrii modelului care sunt vizibili din afar fr indicarea
structurii lor interne. n limbajul UML interfaa este clasificatorul care caracterizez numai o parte
limitat a comportrii unei entiti modelate. Referitor la diagrama cazurilor de utilizare interfeele
definesc o totalitate de operaii ce asigur serviciile necesare sau funcionalitatea pentru actorii.
Interfeele nu pot conine nici atribute, nici stri, nici asocieri dirijate. Ele conin numai operaii fr
indicarea specificaiilor de realizare a lor. O interfa este formal echivalent clasei abstracte fr
atribute i metode numai cu prezena operaiilor abstracte.
n diagrama cazurilor de utilizare o interfa este reprezentat ca un cercule mic lng care este
indicat numele lui. (fig. 22, a). n calitatea de nume poate fi un substantiv, ce caracterizeaza
informaia corespunztoare sau serviciu (de exemplu, sirena, camera video), dar mai des este
oricare rnd de text (de exemplu, sensor, interpolare ctre baza de date, forma de
introducere, dispozitiv de semnalizare sonor). Dac numele este nscris n limba englez,
atunci acest nume trebuie s inceap cu majuscula I, de exemplu, ISecurelnformation, ISensor (fig.
22, ).

Fig. 22. Reprezentarea grafica a interfeelor n diagrama cazurilor de utilizare.

19

Simbolul grafic al unei interfee aparte n diagram poate fi conectat cu cazul de utilizare ce l
susine cu o linie nentrerupt (continu). Linia nentrerupt n acest caz indic faptul c cazul de
utilizare legat cu interfaa trebuie s realizeze toate operaiile necesare pentru aceast interfa, sau
poate i mai mult (fig. 23, a). n afar de aceasta, interfeele pot fi legate cu cazurile de utilizare cu o
linie ntrerupt cu o sgeat (fig. 23, b), ce nseamna c cazul de utilizare specific numai cel
serviciu, care este necesar pentru realizarea interfeei date.

Fig. 23. Reprezentarea grafic a legturilor ntre interfee i cazuri de utilizare.

Din punct de vedere sistemo-analitic interfaa nu numai separ specificaia operaiilor unui sistem
de la realizarea lor, dar i definete limetele comune ale sistemului proiectat. Ulterior interfaa poate
fi specificat cu indicarea acelor operaii care specific un aspect de colaborare al sistemului. n
acest caz el se reprezint n forma de dreptunghi cu cuvnt-cheie interface n secia de nume, cu
secia de atribute goala i cu secia de operaii completat. Dar aa fel de reprezentare grafic se
utilizeaz n diagrama claselor sau n diagrame ce caracterizeaz comportarea sistemului modelat.
Importana interfeelor const n faptul c ele definesc noduri de jonciune n sistemul proiectat, ce
este necesar pentru organizarea lucrului colectiv asupra proiectul. Mai mult dect att, specificaia
interfeelor contribuie la modificarea uoarla trecerea la soluii tehnologice ale unui sistem deja
existent. n acest caz schimbrii este supus numai realizarea operaiilor, dar nu funcionalitatea
sistemului. Aceasta asigur compatibilitatea versiunilor urmtoare de program cu cele iniiale la
folosirea tehnologiei n spiral de creare sistemelor de program.

3.4. Legturile n diagrama a cazurilor de utilizare

ntre componentele diagramei cazurilor de utilizare pot s existe diferite legturi care desciu
colaborarea exemplarelor unor actori i cazurilor de utilizare cu exemplarele altor actori i cazuri.
Un anumit actor poate s colaboreze cu mai multe cazuri de utilizare. n acest caz actorul dat se
adreseaz ctre cteva servicii ale sistemului dat. La rndul su un anumit caz de utilizare poate s
colaboreze cu mai muli actori, pentru care el acord serviciul su. Trebuie de observat c dou
cazuri de utilizare definite pentru aceeai entitate nu pot colabora unul cu altul, fiindc fiecare din
ele descrie o variant propie terminal de utilizare a acestei entiti. Mai mult dect att, cazurile de
utilizare ntotdeauna presupun careva semnale i mesaje pentru colaborarea cu actorii n afara
limetelor sistemului. n acelai timp pot fi definite alte metode de colaborare ntre elemente n
nteriorul sistemului.
n limbajul UML sunt cteva tipuri standarde de relaii ntre actori i cazuri de utilizare:

relaia de asociere (association relationship)

relaia de extindere (extend relationship)
relaia de generalizare (generalization relationship)
relaia de cuplare (include relationship)

Totodat proprietile generale ale cazurilor de utilizare pot fi reprezentate prin trei metode diferite,
i anume cu ajutorul relaiei de extindere, generalizare i cuplare.

20

3.4.1. Relaia de asociere

Relaia de asociere este o noiune fundamental n limbajul UML i mai mult sau mai puin se
utilizeaz la crearea tuturor modelelor grafice n forma diagramelor canonice.
Cu privire la diagrama cazurilor de utilizare relaia de asociere specific rolul deosebit al actorului
n cazul de utilizare aparte. Cu alte cuvinte, asocierea specific particularitatea semantic de
colaborare a actorilor i cazurilor de utilizare n modelul grafic. n aa mod aceast relaie stabilete
ce rol joac actorul la colaborarea cu exemplarul cazului de utilizare. n diagrama cazurilor de
utilizare precum i n alte diagrame relaia de asociere se noteaz cu o linie nentrerupt ntre actor
i cazul de utilizare. Aceast linie poate s aib condiii suplementare, de exemplu, numele i
multiplicitatea (fig. 24).

Fig. 24. Reprezentare grafic relaiei de asociere ntre acotr i caz de utilizare.
Multiplicitatea (multiplicity) asocierei se indic lnga notaia componentului diagramei care este
membru acestei asocieri. Multiplicitatea caracterizeaz cantitate total de exemplare concrete al
unui component anumit care pot fi n calitate de elemente acestei asocieri. Cu privire la diagrame
cazurilor de utilizare multiplicitate are o notaie specific n forma de una sau mai multe cifre i
posibil simbolul special *.
Pentru diagrama cazurilor de utilizare mai rspndite sunt patru forme de nscriere a multiplicitii
relaiilor de asociere:

Numr ntreg nenegativ (inclusiv cifra 0) este destinat indicaiei multiplicitii care este
strict fixat pentru elementul corespunztor asocierii. n acest caz cantitate de exemplare a
actorilor sau cazurilor de utilizare, ce pot fi i elemente ale relaiei de asociere, ntocmai este
egal cu numrul indicat.

Ca exemplu a acestei forme de nregistrare a multiplicitii relaiilor de asociere este indicarea

multiplicitii 1 pentru actorul Clientul bncii (fig. 24). Aceast nregistrare nseamna c
fiecare exemplar al cazului de utilizare Perfectarea creditului pentru clientul bncii poate s aib
n calitate de element propriu un singur exemplar de actor Clientul bncii. Cu alte cuvinte, la
perfectarea creditului n banc trebuie de luat n vedere c fiecare credit concret se perfecteaz
pentru un singur client al acestei bnci.

Dou numere ntregi nenegative, separate cu dou puncte i scrise n forma: primul
numr..al doilea numr. Aceast nregistrare n limbajul UML corespunde notaiei pentru o
mulime sau pentru un interval de numere ntregi, care se utilizeaz n unele limbaje de
programare pentru indicarea limitelor masivului de elemente. Aceast nregistrare trebuie s
fie neleas ca o mulime de numere ntregi nenegative care sunt n ordinea crescatoare:
{numar_1, numar_1+1, numar_1+2, , numar_2}. Evident c primul numr trebuie s fie
strict mai mic dect al doilea numr n sens aritmetic, totodat primul numr poate fi egal cu
0.

Ca exemplu a acestei forme de nregistrare a multiplicictii asocierii 1..5. Aceast nregistrare

nseamna c cantitatea de exemplare ale acestui component care pot fi i elemente ale acestei
21

asocieri, este egal unui numr preliminar necunoscut din mulimea numerelor ntregi {1, 2, 3, 4,
5}. Aceast situaie are loc cnd n calitate de actor este clientul bncii, dar n calitate de caz de
utilizare este procedura deschiderii contului n banc. Totodat cantitatea de conturi ale fiecrui
client n aceast banca, reieind din consideraii tactice, poate fi nu mai mult dect 5. Aceste
consideraii tocmai i sunt cerinele exterioare sistemului proiectat i sunt definite de ctre client la
etapele iniiale de APOO.

Dou simboluri separate cu doua puncte. Totodat primul dintre ele este un numr ntreg
nenegativ sau 0, iar al doilea este simbolul special *. Aici simbolul * nseamn un
numr arbitrar ntreg nenegativ, valoarea cruia este necunoscut la momentul nregistrrii
unei relatii de asociere.

Ca exemplu acestei forme de nregistrare de multiplicitate asocierei 2 ..*. Aceast nregistrare

nseamn c cantitatea de exemplare ale acestui component, care pot fi i elementele acestei
asocieri, este egal cu un numr anticipat necunoscut din mulimea numerelor ntregi {2, 3, 4}.

Simbolul *, care este prescurtarea nregistrrii intervalului 0..*. n acest caz cantitatea
de exemplare ale acestui component al relaiei de asociere poate fi oricare numr ntreg
nenegativ. Totodat 0 nseamn c pentru careva exemplare ale componentului
corespunztor aceast relaie de asociere poate nici s nu aib loc.

Ca exemplu acestei forme de nregistrare poate fi cercetat multiplicitatea asocierei pentru cazul de
utilizare ntocmire creditului pentru clientul bncii (fig. 24). n acest caz * nseamn fiecare
client aparte al acestei bnci poate ntocmi pentru sine cteva credite, totodat numrul lor comun
este necunoscut i nelimitat. Unele clieni pot s nu aib credite deloc (cazul valorii 0).
Dac multiplicitatea asocierei nu este indicat atuinci implicit se ia valoarea egal cu 1.

3.4.2. Relaia de extindere

Relaia de extindere definete interconexiunea exemplarelor cazului de utilizare cu cazul general,
proprietile cruia sunt definite pe baza modului de uniune a exemplarelor date. n metamodelul
relaie de extindere este direct i indic care condiii concrete pot fi utilizate pentru unele exemple
unui anumit caz de utilizare, definite pentru extinderea cazului de utilizare dat. Dac are loc relaie
de extindere de la cazul de utilizare A la cazul de utilizare B, acest lucru nseamn c proprietile
exemplarului cazului de utilizare B pot fi adugate datorit proprietilor extinse a cazului de
utilizare A.
Relaia de extindere ntre cazurile de utilizare reprezint o linie punctat cu sgeat (cazul relaiei
de dependen), direct de la acel caz de utilizare, care reprezint extinderea cazului de utilizare
iniial. Aceast linie cu sgeat este marcat cu cuvntul extend (extinde), fig. 25.

Fig. 25. Exemplu de reprezentare grafic a relaiei de extindere ntre cazurile de utilizare.
Relaia de extindere indic acel fapt c unul din cazurile de utilizare poate fi conectat la
comportamentul su care-va comportament adugtor, definit pentru un alt caz de utilizare. Relaia
dat include o anumit condiie i exilri la puncte de extensie n cazul de utilizare de baz. Pentru
alocarea extinderii este necesar de a executa o anumit condiie a relaiei date. Exilri la puncte de
22

extensie definesc acele locuri n cazul de utilizare de baz n care trebuie s fie pus extinderea
respectiv n timpul executrii condiiei.
Unul din cazurile de utilizare pot fi extinderea pentru cteva cazuri de baz i pot avea ca extinderi
proprii nc cte-va alte cazuri. Cazul de utilizare de baz poate fi adugtor independent de la alte
extensii.
Semantica relaiei de extensie este definit n felul urmtor. Dac exemplarul cazului de utilizare
execut anumit consecven de aciuni, care definete comportamentul lui i n urma cruia exist
un punct de extensie la alt exemplar a cazului de utilizare, care este unul din primele puncte de
extensie a cazului iniial, atunci controleaz condiia relaiei date. Dac condiia este executat,
consecvena iniial de aciuni extinde datorit includerea aciunii altui exemplar a cazului de
utilizare. Trebuie de meninut, c condiia relaiei de extensie este controlat numai o dat n timpul
exilrii la un punct de extensie i dac aceasta este executat, atunci toate cazurile de extindere
utilizate se folosesc n cazul de baz.

3.4.3. Relaia de generalizare

Relaia de generalizare este folosit pentru indicarea faptului c care-va caz de utilizare A poate fi
generalizat la cazul de utilizare B. n urma cruia, cazul A va fi cazul special cazului B. n urma
cruia cazul B se numete printe relativ A, iar cazul A descendent relativ cazului de utilizare B.
Este nevoie de menionat, c descendentul motenete toate proprietile i comportamentul
printelui su i poate avea proprietile i comportamentul su adugtor. Grafic relaia dat este
reprezentat cu linia ntreag cu sgeat n forma de triunghi nehaurat, care indic cazul de
utilizare printe (fig. 26). Aceast linie cu sgeat are un nume specific sgeata generalizare.

Fig. 26. Exemplu de reprezentare grafic a relaiei de generalizare ntre cazuri de utilizare.
Relaia de generalizare ntre cazurile de utilizare este folosit n acele cazuri cnd este necesar de
indicat c cazul de utilizare derivat conine toate atributele i particularitile comportamentului
cazurilor de baz. n urma cruia cazurile de utilizare derivate pot participa n relaii cazurilor de
baz. n urma sa cazurile derivate pot avea proprieti noi de comportament, care nu au cazurile de
utilizare de baz, dar i de a preciza sau modifica proprietile de comportament motenite.
Relativ cu relaia dat un variant de utilizare poate avea cte-va cazuri de baz. n acest caz se
realizeaz motenirea multipl a proprietilor i comportamentului cazurilor de baz. Din alt parte
un caz de utilizare poate fi printe pentru cte-va cazuri de utilizare derivate, ce corespunde
caracterului taxonometric relaiei de generalizare.
ntre actori aparte de asemenea poate exista relaia de generalizare. Aceast relaie este direct i
indic faptul c specializarea unor actori este relativ cu alii. De exemplu, relaia de generalizare de
la actorul A la actorul B indic faptul c fiecare exemplar a actorului A este concomitent cu
exemplarul actorului B i are toate proprietile lui. n acest caz actorul B este printe relativ cu
actorul A, iar actorul A este descendentul actorului B. n urma cruia actorul A are posibilitatea de
joac a aceleeai mulimi de roluri ca i actorul B. Grafic relaia dat este reprezentat cu sgeata de
generalizare, adic cu linia ntreag cu sgeat n form de triunghi nehaurat, care indic printele
actorului (fig. 27).

23

Fig. 27. Exemplu de reprezentare grafic a relaiei de generalizare ntre actori.

3.4.4. Relaia de tip include

Relaia de tip include n dou cazuri de utilizare indic un comportament stabilit pentru un caz de
utilizare este inclus ca component compus n consecutivitatea comporatamentului a altui caz de
utilizare. Relaia dat este relaie binar ndrepatat, n acel sens c perechea de exemplare a cazului
de utilizare ntodeauna se afl la locul ei n relaia de tip include.
Semantica acestei relaii este definit n felul urmtor. Cnd exemplarul primului caz de utilizare n
timpul executrii ajunge la punctul de includere n consecutivitatea comporatamentului
exemplarului al doilea a cazului de utilizare, exemplarul primului caz de utilizare execut
consecutivitatea aciunilor, care definesc comportamentul exemplarului al doilea a cazului de
utilizare, dup ce continu executarea aciunilor comportamentului su. n urma cruia se presupune
c dac exemplarul primului caz de utilizare poate include cteva exemplare a altor cazuri de
utilizare, aciunile lor trebuie s se sfreasc ntr-un anumit moment, dup ce trebuie s continue
executarea aciunilor ntrerupe exemplarele primului caz de utilizare n conformitate cu
comportamentul lui dat.
Unul din cazurile de utilizare poate fi inclus n alte cazuri i poate include alte cazuri. Cazul de
utilizare ce este inclus poate fi independent de cazul de baz, anume el d ultimului un
comportament incapsulat, detalii realizaiei cruia sunt ascunse i pot fi liber mprite ntre cte-va
cazuri de utilizare incluse. Mai mult, cazul de baz poate depinde numai de rezultatele executrii
comportamentului inclus n el, sar nu de la structura cazurilor incluse n el.
Relaia de tip include orientat de la cazul de utilizare A la cazul de utilizare B indic c fiecare
exemplar al cazului A include proprieti funcionale stabilite pentru cazul B. Aceste proprieti
specializeaz comportamentul cazului respectiv A n diagrama dat. Grafic relaiile date sunt
indicate cu linia punctat cu sgeat (cazul relaiei de dependen), ndreptate de la cazul de
utilizare de baz la cazul ce este inclus. n urma cruia linia cu sgeata este indicat cu cuvntulcheie include, (fig. 28).

Fig. 28. Exemplu de reprezentare grafic a relaiei de tip include ntre cazuri de utilizare.

3.5. Exemplu de construirea diagramei cazurilor de utilizare

Ca exemplu vom lua procesul de modelare a sistemului de vindere a mrfurilor dup catalog, care
poate fi utilizat n timpul crerii sistemelor informaionale respective.
n calitate de actori a sistemului dat pot fi dou subiecte, unu din care este vnztor, iar altul
cumprtor. Fiecare din actori interacioneaz cu sistemul de vindere a mrfurilor dup catalog i
este utilizatorul lui, adic ambele se adreseaz la servisul respectiv A perfecta comanda de
24

cumprare a mrfii. Este evedent din cerinele adresate la sistem c servisul reprezint cazul de
utilizare a diagramei, strutura de baz poate include numai doi actori i un singur caz de utilizare
(fig. 29).

Fig. 29. Diagrama cazurilor de utilizare pentru exemplu de perefectare a sistemului de vindere a
mrfurilor dup catalog.
Valorile divizibilitilor n diagrama dat reflect regulile de baz sau logica de formare a cerinelor
la vinderea mrfurilor. Conform regulilor respective un vnztor poate participa n formarea a ctorva comenzi, n acelai timp fiecare comand poate fi format numai de un singur vnztor, care are
responsabilitatea pentru corectitudinea formrii lui i respectiv va avea rsplat pentru formarea
dat. Din alt parte, fiecare cumprtor poate forma cteva comenzi i n acelai timp fiecare
comand trebuie s fie format la un singur cumprtor, care va avea drepturile de proprietate la
marf dup achiziionarea ei.
Etapul urmtor n diagrama dat este A perfecta comanda de cumprare a mrfii poate fi precizat
pe baza ntroducerii a patru cazuri de utilizare adugtoare. Acest lucru este evident din analiza mai
detaliat a procesului de vindere a mrfii, ce permite de alege ca servicii separate acele aciuni ca
asigurarea cumpratorului cu informaia despre marf, coordonarea condiiilor de plat i
comandarea mrfii de la depozit. Evident c aciunile indicate desfoar comportamentul cazului
de utilizare iniial i anume concretizarea lui i de aceea ntre ele v-a exista relaia de tip include.
n cazul nostru catalogul cu mrfuri poate fi comandat de cumprtor sau vnztor cnd apare
necesitatea de a alege marfa i precizarea detaliilor de vindere. Corect este reprezentat serviciul
Cererea catalogului cu mrfuri ca caz de utilizare independent.
Dup detalizare diagrama cazurilor de utilizare va avea 5 cazuri de utilizare i 2 actori (fig. 30),
ntre care este stabilit relaia de tip includ i extend.

25

Fig. 30. Variantul mai detaliat a diagramei cazurilor de utilizare pentru exemplu de perefectare a
sistemului de vindere a mrfurilor dup catalog.
Diagrama cazurilor de utilizare de mai sus, la rndul su poate fi mai detaliat pentru precizarea mai
adnc, ce se cere de la sistemul de comand i concretizarea detaliilor pentru realizarea urmtoare.
Detalizarea poate fi executat pe baza indicrii relaiilor adugtoare de tipul relaiei generalizareaspecializarea pentru componentele diagramei deja existente. n sistemul de vindere a mrfurilor
poate avea valoarea independent i proprietile specifice o categorie independent de mrfuri
calculatoare. n acest caz n diagram poate fi adugat un caz de utilizare Perfectarea comenzii de
achiziionare a calculatorului i cu actori Cumprator de calculatoare i Vnztor de
calculatoare, care sunt legate cu componentele corespunztoare a diagramei relaiei de generalizare
(fig. 31).

26

Fig. 31. Unul din variantele de concretizare a diagramei cazurilor de utilizare pentru exemplul de
sistem de vindere.
Construirea diagramei cazurilor de utilizare este primul etap a procesului analizei a obiectului
orientat i proiectri, scopul cruia este de reprezentarea totalitii de cereri la comportamentul
sistemului proiectat. Specificaia de cereri la sistemul proiectat n form de diagram a cazurilor de
utilizare reprezint un model independent, care se numete modelul cazurilor de utilizare n limbajul
UML i are un nume propriu stanadard sau steriotip UseCaseModel.

4. Diagrama de clase (class diagram)

Locul central n APOO l ocup elaborarea modelului logic al unui sistem n forma diagramei de
clase. Notaia claselor n limbajul UML este simpl i clar pentru toi. O notaie asemntoare se
utilizeaz i pentru obiecte care sunt exemplare ale clasei, unica diferen este n aceea c la
numele clasei se adaug numele obiectului i toat nregistrarea se subliniaz.
Notaia limbajului UML ofer multe posibiliti pentru reflectarea informaiei suplimentare (operaii
abstracte sau clase, stereotipuri, metode comune i particulare, interfee detaliate, clase
parametrizate). Totodat este posibil utilizarea reprezentrii grafice pentru asocieri i proprietile
lor specifice, astfel cum sunt relaiile de agregare, cnd ca pri componente ale clasei pot fi alte
clase.
Diagrama de clase (class diagram) se utilizeaz pentru reprezentarea structurii statice a unui model
de sistem n terminologia claselor programrii OO. Diagrama de clase poate reflecta diferite legturi
ntre entitile domeniului de obiecte (obiecte i subsisteme) i descrie structura lor intern i
tipurile de relaii. n aceast diagram nu este menionat informaia despre aspectele temporare ale
funcionrii sistemului. Din acest punct de vedere diagrama de clase este dezvoltarea ulterioar a
modelului conceptual al sistemului proiectat.

27

Diagrama de clase reprezint un graf cu noduri elemente de tip clasificatori care sunt legate
prin diferite tipuri de relaii de structur. Trebuie de menionat c diagrama de clase poate conine
interfee, pachete, relaii i chiar exemplare, aa ca obiecte i legturi. Prin diagrama de clase se
subnelege modelul structural static al sistemului proiectat, de accea diagrama de clase deseori se
socoate o reprezentare grafic a legturilor structurale ale modelului logic al sistemului care sunt
independente i invariante n timp.

4.1. Clasa
Clasa (class) n limbajul UML definete totalitatea de obiecte care au aceeai structur,
comportament i relaii cu obiectele din alte clase. Grafic o clas se reprezint printr-un dreptunghi
care poate fi divizat de linii orizontale n seciuni, fig. 3.
Elementul obligtoriu n notaia clasei este numele lui. Pe etapele iniiale ale elaborrii diagramei,
clase aparte pot fi notate prin dreptunghiuri simple cu indicaia numelui clasei respective. Pe
parcursul elaborrii componentelor diagramei descrierea claselor este completat cu atribute i
operaii.
Se presupune c varianta final a diagramei conine descrierea complet a claselor care const din
cele trei seciuni. Uneori n notaia claselor se utilizeaz a patra seciune suplementar n care se
indic informaia semantic de caracter informativ i se indic situaiile excepionale.
Dac seciunea atributelor i operaiilor clasei nu este completat, n notaia clasei ea se evidentiaz
cu o linie orizontal pentru a deosebi clasa de alte elemente ale limbajului UML. Exemple de notaii
grafice ale claselor n diagrama de clase sunt artate n fig. 32. n primul caz pentru clasa
Dreptunghi (fig. 32, a) sunt indicate numai atributele clasei punctele pe planul de coordonate
care i definesc poziia. Pentru clasa Fereastr (fig. 32, b) sunt indicate numai operaiile, seciunea
de atribute este lsat necompletat. Pentru clasa Contul (fig. 32, c) suplementar este indicat
seciunea de excepii refuz de la prelucrarea cartelei bancare expirate (nevalabile).
Dreptunghi
p1.Pont
p2.Pont

Fereastra
arata()
ascunde()

Cont
verifica()
exceptiile
cartela bancara
nu este valabila

a)

b)

c)

Fig. 32. Exemple de notaii grafice ale claselor n diagrame.

4.1.1. Numele clasei

Numele clasei trebuie s fie unic n cadrul pachetului, care este descris de ctre o totalitate de
diagrame de clase. Numele se indic n prima seciune de sus a dreptunghiului. n completare la
regula general de denumire a elementelor n limbajul UML numele clasei se scrie n centrul
28

seciunii cu caracter semigros (bold) i trebuie s inceap cu majuscula. Se recomand n calitate de

nume a claselor sa fie utilizate substantivele scrise fr spaii. Este necesar de menionat c numele
claselor formeaz dicionarul domeniului de obiecte pentru APOO.
n prima seciune a notaiei clasei pot fi referine la modelele (abloanele) standarte sau la clasele
abstracte de la care este format clasa dat i respectiv de la care clasa motenete proprietile i
metodele. n aceast seciune poate fi indicat informaia despre elaboratorul clasei date i starea
elaborrii, nc pot fi indicate i alte proprieti comune ale acestei clase care au legtura cu alte
clase ale diagramei sau cu elementele standarde ale limbajului UML.
Ca exemple de nume ale claselor pot fi aa substantive ca: Angajatul, Compania,
Conductorul, Clientul, Vnztorul, Managerul, Oficiu .a. care au legtur cu
domeniul de obiecte proiectat i cu destinaia funcional a sistemului proiectat.
Clasa poate s nu aib exemplare sau obiecte. n acest caz clasa devine abstract, i pentru notaia
denumirii acestei clase se utilizeaz caractere italice. n limbajul UML este adoptat o inelegere
(acord) despre ceea c orice text care se refer la elementele abstracte se scrie n italic. Aceast
circumstan este un aspect semantic pentru descrierea elementelor respective ale limbajului UML.
n unele cazuri este necesar de indicat clar la care pachet se refer clasa. Pentru acest scop se
utilizeaz un simbol special de divizare dou puncte duble ::. Sintaxa liniei ce conine numele
clasei n acest caz va fi urmatoarea: <Numele_pachetului>::<Numele_clasei>. Cu alte cuvinte
nainte de numele clasei trebuie s fie indicat clar numele pachetului la care clasa se refer. De
exemplu, dac este specificat pachetul cu numele Banca, atunci clasa Cont n aceast banca
poate fi scris n fel urmtor: Banca::Cont.

4.1.2. Atributele clasei

n a doua secie a dreptunghiului de clas se nscriu atributele lui sau prorietile. n limbajul UML
standardizarea nscrierii atributelor de clas se supune regulelor sintactice. Fiecrui atribut de clas
i corespunde rndul textului, care este format din specificatorul de vizibilitate a atributului, numelui
lui, tipul sensului i, posibil sensul final:
specificatorul de vizibilitate numele atributului [multiplicitate]:
tipul atributului=sensul final {aliniat-proprietate}
Specificatorul de vizibilitate poate primi unul dintre cele trei sensuri i concomitent reflect cu
ajutorul simbolurilor speciale:

Simbolul + nseamn atributul cu regiunea de vizibilitate de tip public (public). Atributul

cu aceast regiune de vizibilitate poate fi accesat sau vzut din alt clas de pachet, n care
este stabilit diagrama.
Simbolul #. nseamn atributul cu regiunea de vizibilitate de tip protecie (protected).
Atributul cu aceast regiune de viyibilitate nu poate fi accesat sau vzut pentru toate clase n
afar de subclasele acestui clas.
n sfrit, simbolul atributul cu regiunea de vizibilitate tipului privat. (private). Atributul
cu aceast regiune de vizibilitate nu poate fi accesat sau vzut pentru toate clasele fr
excepie.

Specificatorul de vizibilitate poate fi omis. n acest caz nu este present, pur i simplu nseamn c
vederea acestui atribut nu este indicat. Aceast situaie difer de nelegerile de baz n limbile de
29

tradiionale programare, cnd nu este prezent specificatorul de vizibilitate este tratat ca public sau
privat.
Numele atributului prezint aliniat de text, care este folosit n calitate de identificator a atributului
corespunztor i de aceea trebuie s fie unic n clasa corespunztoare. Numele atributului este unic,
un element obligator al nsemnrii sintaxice al atributului.
Ca exemplu de multiplicitate al atributelor putem vedea urmtoarele variante:

[0..1] nseamn c, multiplicitatea atributului poate primi semnificaia 0 sau 1. n acest caz 0
nseamn c semnificaia pentru acest atribut nu este prezent.
[0..*] nseamn c, multiplicitatea atributului poate primi orice semnificaie pozitiv
ntreag mai mult sau egal cu 0. Aceast multiplicitate poate fi scris mai scurt n calitate
de simbolul - [*].
[1.:*] nseamn c, multiplicitatea atributului poate primi orice semnificaie pozitiv
ntreag mai mult sau egal cu 1.
[1..5] nseamn c, multiplicitatea atributului poate primi orice semnificaie din numerele: 1,
2, 3, 4, 5.
[1..3,5,7] nseamn c, multiplicitatea atributului poate primi orice semnificaie din
numerele: 1, 2, 3, 5, 7.
[1..3,7.. 10] nseamn c, multiplicitatea atributului poate primi orice semnificaie din
numerele: 1, 2, 3, 7, 8, 9, 10.
[1..3,7..*] nseamn c, multiplicitatea atributului poate primi orice semnificaie din
numerele: 1, 2, 3, de asemenea orice semnificaie pozitiv ntreag mai mult sau egal cu 7.

Dac multiplicitatea atributului nu este specificat, atunci dup starea iniial voloarea ei este egal
cu 1..1, adic exact 1.
Tipul atributului prezint o expresie, semantica cruia este definit dup limbajul specificaiei al
modelului corespunztor. n notaii UML-ului tipul atributului uneori este specificat n dependen
de limbajul de programare, care va fi utilizat pentru realizarea modelului dat. n cazul elementar
tipul atributului este specificat n rndul textului, care are un sens n limita pachetului sau modelului,
la care are atitudinea clasa dat.
Sublinierea rndului atributului nseamn c acest atribut corespunztor poate avea o submulime de
valori din oarecare domeniu al valorilor atributului, definit de tipul lui. Aceste valori pot fi
considerate ca trus de notie cu acelai tip sau ca masiv, care n ansamblu caracterizeaz fiecare
obiect al clasei.
De exemplu, dac oarecare atribut este dat n form de forma: Dreptunghi, aceasta va semna c
toate obiectele clasei date poate avea cteva forme diferite, dintre care fiecare prezint un
dreptunghi. Ca alt exemplu poate fi atribut n form de numrul_contului:Integer, ce poate nsemna
pentru obiect Colaborator prezena submulimii de conturi, valoarea total crora nu este fixat din
timp.
Aliniat proprietatea este utilizat pentru indicarea valorilor atributului, care nu poate fi shimbat
n program n lucrul cu tipul dat al obiectelor. n paranteze ... anume este indicat valorea fix al
atributului propriu pentru toat clas, care trebuie s conin toate exemplarele clasei, care vor fi
create, fr excepie.
Aceast valoare este considerat ca valoare iniial a atributului, care nu poate fi reiniializat n
continuare. Absena aliniatului proprietatea de baz se trateaz n felul urmtor, valoarea
30

atributului corespunztor pot fi shimbat n program. De exemplu, aliniat proprietate n nscrierea

atributului salariu:Currency = = {$500} poate fi utilizat pentru indicarea salariului fixat pentru
fiecare obiect al clasei Colaborator pentru o funcie definit n oarecare organizaie. Din alt
parte, nscrierea atributului dat n form de salariu:Currency = = {$500} nseamn alt ceva, i
anume n timpul formrii a unui nou exemplar Colaborator (angajarea la lucru unui nou
colaborator) pentru el salariul de $500 este stabilit automat. Totui, pentru careva colaboratori pot fi
fcute excepii, cum ar fi n cretere sau descretere, ce ar trebui fi prevzut n program.

4.1.3. Operaiile
n a treia secie a dreptunghiului de clas se nscriu operaii sau metodele clasei. Operaia
(operation) prezint un anumit serviciu, care prezint fiecare exemplar al clasei dup anumit
cerin. Totalitatea de operaii caracterizeaz un aspect funcional n comportamentul clasei. Notaia
operaiei clasei n limbajul UML este la fel standartizat i este subordonat de careva regulli
sintactice. n urma acesteia fiecare operaie clasei corespunde un rnd aparte, care este compus din
specificator de vizibilitate al operaiei, numele operaiei, expresiei de tipul valoarei returnat de
opearaia i posibil, aliniat proprietate operaiei date:
<specificator de vizibilitate><numele operaiei>(lista de parametri):
<expresie de tipul valoarei returnate>{aliniat - proprietate}
Specificator de vizibilitate ca i n cazul atributelor clasei, poate primi unul din trei valori posibile i
n mod corespunztor este specificat cu un simbol special. Simbolul + nseamn operaia cu
specificator de vizibillitate de tip public(public). Simbolul # nseamn operaia cu specificator de
vizibilitate de tip protecie(protected). n sfrit, simbolul este utilizat pentru identificarea
operaiei cu regiunea de vizibilitate de tip privat (private).
Specificator de vizibilitate pentru operaie poate fi absent. n acest caz absena lui nseamn c
vizibilitatea operaiei nu este indicat. n locul nsemnrii grafice convenionale de asemenea poate
nscrie un cuvnt cheie corespunztor: public, protected, private.
Numele operaiei prezint aliniat de text, care este utilizat ca identificator al operaiei
corespunztoare i de aceea trebuie s fie unic n mediul clasei date. Numele atributului este un
element unic obligator n indicarea sintactic operaiei.
Operaia, care nu poate schimba starea sistemului i n mod corespunztor nu are nici un efect
suplimentar, este specificat cu aliniat proprietate {interpelare} ({query}). n caz contrar
operaia poate schimba starea sistemului, dei nu sunt garanii c ea va face acest lucru.
Lista parametrilor formate i tipul de valoare redus pot fi nespecificate. Specificator de vizibilitate
atributelor i operaiilor pot fi indicate de un semn sau simbol special, care sunt utilizate pentru
prezena modelelor grafice n careva mijloace de instrumente. Numele operaiilor la fel ca i a
atributelor, sunt scrise cu minuscule, iar tipurile lor cu majuscule. n urma cruia o parte obligatorie
al aliniatului de text al operaiei este prezena numelelui i parantezelor rotunde.
Ca exemplu al nscrierei operaiei pot fi urmtorii specificatori al operaiilor:

+a crea() pot indica o operaie abstract n fondarea obiectului separat, care este public i
nu conine parametri formali. Aceast operaie nu reduce nici o valoare dup executarea sa.

31

+a desena(forma: multilateral=dreptunghi, culoarea_inundrii: Color =(0,0,255)) pot

indica o operaiune de nfiare pe ecranul monitorului regiunii dreptunghiului cu culoare
albastr, dac nu indic alte valori n calitate de argumente operaiei date.
cererea_contulului_clientului(numrul_contului: Integer): Currency nseamn, operaiunea
de indicare n contul curent a clientului bncii. n urma cruia argumentul operaiei date este
numrul contului clientului, care este scris ca numr ntreg (de exemplu: 123456). Ca
rezultat al executrii operaiei date va fi un numr ntreg scris n formatul monetar(de
exemplu: $1,500.00).
a da_mesajul():{Eroare mpririi la nul} sensul operaiei acestea nu este nevoie de a
explica, deoarece este ntreinut n aliniat proprietatea operaiei. Mesajul dat poate aprea
pe ecranul monitorului n cazul cnd desprim un numr la nul, ce este inadmisibil.

4.2. Relaii ntre clase

n afar de organizarea intern sau structur claselor n diagrama corespunztoare sunt indicate
diferite relaii ntre clase. n urma cruia totalitatea tipurilor astfel de relaii este fixat n limbajul
UML i este presupus de semantica astfel tipurilor de relaii. n limbajul UML relaiile de baz i
legturile sunt:

Relaia de dependena (dependency relationship)

Relaia de asociere (association relationship)
Relaia de generalizare(generalization relationship)
Relaia de realizare(realization relationship)

Fiecare din relaiile aceste are reprezentare grafic proprie pe diagram, care reflect
interconexiunele ntre obiectele claselor corespunztoare.

4.2.1. Relaia de dependena

Relaia de dependen n caz general indic o relaie semantic ntre dou elementele modele sau
ntre dou mulimi de aceste elemente, care nu este o relaie de asociere, generalizare sau realizare.
Ea se refer numai la elementele modele i nu cere o mulime de exemple pentru explicarea sensului
su. Relaia de dependen se folosete n situaia n care o schimbarea unui element al modelului
poate cere dup sine o schimbare n elementul dependent de elementul precedent al modelului.
Grafic relaie de dependen se prezint grafic, printr-o linie punctat ntre elementele cu sgeat n
captul entitii dependente(-> sau <-). n diagrama de clase aceast relaie unete clase
separate ntre sine, n urma cruia sgeat este ndreptat de la clasa client, dependent de clasa
independent sau clasa iniial (fig. 33). Pe desenul urmtor sunt prezentate dou clase: Clasa_A
i Clasa_B, n urma cruia Clasa_B reprezint sursa unei relaii, iar Clasa_A este clientul acestei
dependene.
Clasa_A

Clasa_B

Fig.33. Reprezentarea grafic relaiei de dependena n diagrama de clase.

Sgeata poate fi indicat sau nu poate fi indicat cu cuvntul-cheie standart n ghelimele i nu este
necesar nume individual. Pentru relaia de dependen exist cuvintele cheie, care indic careva
feluri de relaii speciale. Aceste cuvintele cheie (stereotipuri) sunt scrise n ghelimele alturi de

32

sgeat, care corespunde relaiei date. Exemple de stereotipuri pentru relaie de dependen sunt
urmtoarele:

access servete ca indicator de accesibilitate unor atribute i operaii clasei surs

pentru claseclienii;
bind clasaclient pote utiliza careva ablon pentru urmtoarea parametrizare;
derive atributul clasei client poate fi calculat dup atributele clasei surs;
import atribute deschise i operaii publice clasei surs devine o parte a clasei
client, care dac ar fi nemijlocit n el;
refine indic c clasa client servete ca precizie a clasei surs n cauza caracterului
istoric, cnd n timpul lucrului la un proiect apare informaia adugtoare.

4.2.2. Relaia de asociere

Relaia de asociere corespunde prezenei unei relaii ntre clase. Relaia dat se reprezint printr-o
linie cu simboluri speciale adugtoare, care caracterizeaz unele proprieti a asocierii concrete. n
calitate de simboluri adugtoare speciale poate fi folosit numele asocierii, dar i numele i
multiplicitatea claselor rolurilor asocierii. Numele asocierei nu este un element obligatoriu pentru
indicarea ei. Dac numele este indicat, atunci este scris cu litera majuscul alturi de linia asocierii
corespunztoare.
Cel mai simplu caz asocierii asociaia binar. Ea conecteaz exact dou clase, dar ca excepie
poate conecta clasa cu sine. n diagrama pentru asociaia binar poate fi indicat ordinea consecinei
claselor cu ajutorul triunghiului n form de sgeat alturi de numele asocierii date. Direcia acestei
sgei indic ordinea claselor, unul dintre care este primul (din partea treunghiului), iar al doilea
(din partea vrfului treunghiului). Absena acestei sgeei alturi de numele asocierii nseamn c
ordinea consecinei a claselor n aceast relaie nu este indicat.
Cel mai simplu exemplu a relaiei asociaiei binare poate fi relaia ntre dou clase clasa
Companie i clasa Colaborator (fig. 34). Ele sunt legate ntre ele cu asociaia binar Lucru,
numele cruia este indicat pe desen alturi de linia asocierii. Pentru relaia dat este indicat
ordinea consecinei a claselor, prima este clasa Colaborator, iar al doilea clasa Companie.

Fig. 34. Reprezentarea gafic a relaiei asocierii binare ntre clase.

Unul dintre simboluri adugtoare este numele rolului a clasei aparte, care ntr n asociere. Numele
rolului reprezint aliniat de text alturi de captul asocierii pentru clasa respectiv. Ea indic un rol
specific, care joac clasa, ce reprezint captul asociaiei. Numele rolului nu este un element
obligatoriu i poate lipsi n diagram.
Urmtorul element de indicare este multiplicitatea claselor, care sunt capetele asociaiei.
Multiplicitatea unei clase reprezint un interval de numere intregi, analogic cu multiplicitatea
atributelor i operaiilor claselor.

33

Forma special sau caz particular a relaiei de asociere este relaia de agregare, care n rndul su are
o form special relaie de compoziie. ntruct relaiile acestea au notaii speciale i aparin
noiunelor de baz a limbajului UML, vor fi examinate consecutiv.

4.2.3. Relaia de agregare

Relaia de agregare exist ntre cteva clase n cazul cnd o clas reprezint o careva entitate care
include n sine n calitate de pri componente alte entiti.
Aceast relaie are un sens fundamental n descrierea structurei sistemelor compuse, deoarece este
utilizat pentru reprezentarea interaciunelor sistematice de tipul parte-intreg. Dezvluind
structura sistemei interne, relaia de agregare ne arat din care componente este compus sistema i
cum este legat ntre ele. Din punct de vedere a modelului prile sistemului pot fi reprezentate n
calitate de elemente dar i n calitate de subsistem. Aceast relaie descrie decompoziia sau
mprirea unui sistem compus la un sistem de structurp mai simpl, care de asemenea pot fi
decompuse dac aceast lucru va fi necesar n viitor.
Ca exemplu de relaie de agregare vom lua interaciunea de tipul parte-ntreg, care este ntre
entitate Calculator i componente Bloc de sistem, Monitor, Tastatura, Mouse.
Reprezentarea grafic a relaiei de agregare este artat cu linia ntreag, unul din capetele cruia
reprezint un romb nehaurat. Acest romb indic acea clas, care reprezint un ntreg. Alte clase
prezint prile lui (fig. 35).
Calculator

Bloc de sistem

Monitor

Tastatura

Mouse

Fig. 35. Reprezentarea grafic a relaiei de agregare pentru PC n diagrama claselor.

4.2.4. Relaia de compoziie

Relaie de compoziie este un caz particular al relaiei de agregare. Aceast relaie se folosete
pentru o form special de relaii parte-ntreg, n care componentele aparin unui ntreg
(compozit). Specificarea interaciunii ntre ele const: prile nu pot exista independent, adic cu
destrugerea compozitului se vor distruge toate prile lui componente.
Relaia grafic de compoziie este reprezentat ca o linie ntreag, una din capetele cruia reprezint
un romb haurat nauntru.Acest romb indic acea clas, care reprezint clasa compoziie sau
ntregul. Alte clase sunt prile lui. n calitate de notaii adugtoare pentru relaii de
compoziie i de agregare pot fi folosite notaii adugtoare folosite pentru relaia de asociere. i
anume, specificarea divizibilitii clasei de asociere i numele asocierii date, care nu este
obligatoriu. Ca exemplu de descriere vom lua clasa Fereastra programului i diagrama claselor va
fi urmtoare (fig. 36).

34

Fig. 36. Reprezentarea grafic a relaiei de compoziie pentru Fereastra programului n diagrama
claselor.
Acest exemplu poate ilustra i alte proprietile programei computerizate, care nu a fost specificat
pentru acest exemplu. Deci, specificarea divizibitii 1 lng clasa Regiunea de lucru este utilizat
n anexe unidocumentate (aplicaii).

4.2.5. Relaie de generalizare

Relaia de generalizare este o relaie taxonometric ntre dou elemente de acelai tip: elementul
generalizat (printe) i elementul specializat (descendent). Aceast relaie poate fi utilizat pentru
reprezentarea interaciunilor ntre pachete, clase, cazurile de utilizare i alte elemente ale limbajului
UML.
n diagrama de clase relaia dat descrie structura ierarhic a claselor i motenirea proprietilor i
comportamentului lor. n urma cruia clasa-descendent motenete proprietile i comportamentul
clasei-printe, dar are proprietile i comportamentul su propriu, care nu are clasa-printe. n
diagrame relaiile de generalizare sunt reprezentate ca o linie ntreag cu sgeat n form de
triunghi la unul din capete. Sgeata arat clasa generalizat (clasa-printe sau superclas), iar
absena ei indic clasa special (clasa-descendent sau subclasa).
Pentru simplificarea notaiei n diagrama claselor totalitatea de linii ce indic aceeai relaie de
generalizare, poate fi unit ntr-o linie. n acest caz liniile sunt adunate la o singur sgeat i au un
punct comun de intersecie (fig. 37).

Fig. 37. Variantul grafic a relaiei de generalizare n cazul unirii liniilor aparte.
Lng sgeat de generalizare poate fi amplasat aliniat de text, care specific care-va proprieti
adugtoare a acestei relaii. Textul dat va fi referitor la toate linile de generalizare, care trec n
clase descendente. Cu alte cuvinte, proprietatea marcat se refer la toate subclase relaiei date. n
urma cruia textul trebuie s fie examinat ca restricie i atunci el va fi scris n paranteze.
Ca restricie pot fi folosite urmtoarele cuvintecheie din limbajul UML:

{complete} nseamn c n aceast relaie de generalizare sunt specificate toate clasele

descendente i alte clase descendente nu pot exista n clasa dat. De exemplu, clasa
Clientul_bncii este clasa printe pentru dou clase: Persoana_fizic i Companie i alte
35

clase descendente el nu are. n diagrama acestei clase poate fi indicat evident cu ajutorul
scrierii liniei de generalizare cu aceast aliniat limit;
{disjoint} nseamn c clasele descendente nu pot conine obiecte, care concomitent sunt
exemplare a dou sau mai multor clase. n exemplu precedent acest condiie se
ndeplinete, deoarece este presupus c nici o persoan fizic nu poate fi concomitent i
companie concret. n cazul acesta alturi de linie de generalizare poate fi scris aliniat
limit dat;
{incomplete} este cazul contrar a primului caz. Anume, presupune c n diagrama nu sunt
indicate toate clase descendente. n continuare poate fi restabilit lista lor fr schimbarea
n diagrama construit. Exemplu: diagrama de clas Automobil, pentru care indicarea
tuturor modelelor de automobile este echivant cu formarea catalogului respectiv. Din alt
parte, pentru o alt problem ca elaborarea sistemului de vindere automobilelor de modele
concrete nu este necesitate. Iar indicarea structurii incomplete a claselor descendente este
necesar;
{overlapping} nseamn c care-va exemplare a claselor descendente pot aparine mai
multor clase. Exemplu: clasa Multilateral este clasa printe pentru clasa Dreptunghi i
clasa Rombul. Totui exist clasa Ptrat, exemplarele cruia concomitent sunt obiectele
a primelor dou clase. Este clar c aceast situaie trebuie s fie marcat cu aliniat limit.

4.3. Interfee
Interfeele sunt exemplarele diagramelor cazurilor de utilizare. Totui n construirea diagramei de
clas care-va interfee pot fi precizate i n cazul dat pentru reprezentarea lor este folosit un simbol
grafic special dreptunghi de clas cu cuvntul-cheie i stereotip interfaa (fig. 38). n urma
cruia secia de atribute a dreptunghiului lipsete, iar este indicat numai secia de operaii.
"interface" Element_termomentric
valoarea_temperaturii()

Fig.38. Exemplu de reprezentarea grafic a interfeei n diagrama de clase.

4.4. Obiecte
Obiect (object) este un exemplar special al clasei, care este creat n timpul executrii programului.
El are un propriu nume i valoare concret atributelor. n urma care-va motivelor poate aprea
necesitatea de reprezentare a interconexiunelor nu numai ntre clasele modelului, dar i ntre obiecte
aparte, care realizeaz clase date. n acest caz poate fi elaborat diagrama de obiecte, care nu este
canonic n metamodelul limbajului UML, dar are destinaie proprie.
Pentru reprezentarea grafic a obiectelor este utilizat acelai simbol a dreptunghiului ca i pentru
clase. Diferena este n indicarea numelelor obiectelor, care n cazul de obiecte este obligatoriu
subliniat (fig. 39). n urma cruia notarea numelelui obiectului reprezint aliniat de text numele
obiectului: numele clasei, separat cu dou puncte (fig. 39 a, b). Numele obiectului poate lipsi, n
acest caz presupunem c obiectul este anonim i dou puncte indic acest lucru (fig. 39 d). Numele
clasei poate lipsi. Atunci este indicat numele obiectului (fig. 39 c). Atributele obiectelor primesc
valorile concrete.

36

Fig. 39. Exemplu de reprezentare grafic a obiectelor n diagramele limbajului UML.

5. Diagrama de stri (statechart diagram)

Pentru modelarea comporatamentului la nivelul logic n limbajul UML pot fi utilizate la rnd cteva
diagrame canonice: de stri, de activitate, de secven i de cooperare, fiecare din care pune
accentul la aspectul specificat de funcionare a sistemului. Spre deosebire de alte diagrame,
diagrama de stri descrie procesul de modificare a strilor numai pentru o clas, pentru un exemplar
a unei clase, adic de a modela toate modificrile posibile n starea unui propriu obiect. n urma
cruia modificarea strii obiectului poate fi provocat de influena extern a altor obiecte sau din
exterior. Anume pentru descrierea reaciei obiectelor la aa fel de influene externe sunt utilizate
diagramele de stri.
Aceast diagram este folosit pentru descrierea consecutivitilor de stri posibile i trecerilor, care
n ansamblu caracterizeaz comportamentul elementelor modelului n timpul ciclului de via.
Diagrama de stri reprezint comportamentul dinamic a entitilor n baza specificaiei reaciei lor
la perceperea cror-va evenimente concrete.
Dei diagramele de stri sunt mai rar utilizate pentru descrierea comporatamenrului de care-va
exemplare a claselor (obiectelor), dar ele de asemenea pot fi utilizate i pentru specificarea
funcionalitilor altor componente a modelului, aa cum cazurile de utilizare, actorii, subsisteme,
operaii i metode.
Diagrama de stri n realitate este un graf de nfiare special, care reprezint un automat.
Definiia de automat n contextul UML are o semantic prea specific, bazat pe teoria automatelor.
Vrfurile acestui graf sunt strile i alte elemente a automatului (pseudostri), care sunt reprezentate
cu ajutorul simbolilor grafice speciale. Razele grafului sunt pentru marcarea trecerilor de la o stare
la alt. Diagramele de stri pot fi depuse una n alta, formnd diagramele depuse de reprezentarea
mai detaliat a cror-va elemente a modelului. Pentru nelegerea semanticii diagramei de stri
concrete este necesar de a imagina nu numai deosebirile n comportamentul entitii modelate, dar
i de a ti noiuni generale din teoria automatelor.

5.1. Automate
Un automat (state machine) n limbajul UML reprezint o formalizare pentru modelarea
comportamentului elementelor modelului i a sistemului ntreg. n metamodelul UML automatul
este un pachet, n care sunt definite o mulime de definiii, necesare pentru reprezentarea
comportamentului entitii modelate n form de spaiu discret cu un numr finit de stri i treceri.
Din alt parte, automatul descrie comportamentul obiectului n forma consecutivitilor de stri,
care conine toate etapele ciclului de via, ncepnd cu formarea obiectului i sfrind cu
destrugerea lui. Fiecare diagrama de stri reprezint un automat.

37

Ca un simplu exemplu de reprezentare vizual de stri i treceri pe baz de formalizmul automatului

poate servi situaia descris de mai sus cu funcionizarea echipamentului tehnic ca calculator. n
acest caz sunt introduse dou stri: funcioneaz i nu funcioneaz i dou treceri: defect i
reparare. n mod grafic aceast informaie poate fi reprezentat n form de urmtoarea diagram
de stri pentru un calculator (fig. 40).

Fig. 40. Un simplu exemplu de diagram de stri pentru echipamentul tehnic de tip calculator.
Noiunile de baz care intr n formalizmul automatului sunt starea i trecerea. Diferena principal
ntre ele este durata aflrii sistemului n stare aparte, care depete mult timpul, care este utilizat
pentru trecerea de la o stare la alt. Presupune c iniial timpul de trecere de la o stare la alta este
egal cu zero (dac nu exist informaie suplimentar). Cu alte cuvinte, trecerea obiectului de la o
stare la alt este momental.
n cazul general automatul reprezint aspecte dinamice a sitemului modelat n forma de graf
orientat, vrfurile crui corespunde cu strile, iar arcurile cu trecerile. n urma cruia
comportamentul modeleaz ca deplasare consecutiv n graful de stri de la vrf la vrf dup arcurile
legate innd cont de orientaia lor.

5.2. Stare
n limbajul UML starea este subneles ca metaclas abstract, ce se utilizeaz pentru modelarea
situaiei aparte, pe parcursul crei este prezent executarea anumitei condiii.
Starea (state) poate fi n form de valori concrete a atributului clasei sau obiectului, n acest caz
modificarea anumitelor valorilor va respinge modificarea clasei modelate sau obiectului.
Trebuie de meninut c nu fiecare atribut al clasei poate caracteriza starea lui. Ca regul, sunt
valoroase numai acele proprieti a elementelor sistemului, care respinge aspectul dinamic i
funcional a comportamentului lui. n acest caz starea va fi caracterizat ca o condiie invariat, care
include n sine numai cele mai semnificative clase a atributului pentru comportarea i semnificarea
lor.
De exemplu, invariant poate reprezenta o situaie static, cnd obiectul este n stare de ateptare a
aprrii care-va eveniment extern. Din alt parte, invariantul este utilizat pentru modelarea
aspectelor dinamice, cnd n timpul procesului sunt executate anumite aciuni. Atunci n cazul dat
elementul modelat trece n starea dat n momentul iniial al activitii respective i iese din starea
dat n momentul finalizrii ei.

Fig. 41. Reprezentarea grafic strilor n diagrama de stri.

38

Starea pe diagram este reprezentat ca dreptunghi cu vrfurile rotungite (fig.41). Acest dreptunghi,
la rndul su, poate fi desprit n dou seciuni cu ajutorul liniei orizontale. Dac este indicat
numai o seciune, atunci n ea este scris numai numele strii (fig. 41, a). n caz contrar n prima din
ele este scris numele strii, iar n a doilea lista cror-va aciuni interne sau treceri n starea dat
(fig. 41, b). n urma cruia dup aciunea limbajului UML se subnelege o anumit operaie
atomic, executarea creia duce la schimbarea strii sau red o anumit valoare (exemplu, adevr
sau fals).

5.2.1. Numele strii

Numele strii reprezint aliniat de text, care dezvluie sensul strii date. Numele este ntodeauna
scris cu litera majuscul. Deoarece starea sistemului este partea compus a procesului de
funcionare, este recomandat de folosit n calitate de nume verbele n timpul prezent (sun,
tiprete, ateapt) sau participiu corespunztor (ocupat, liber). Numele strii poate lipsi, adic el nu
este obligatoriu pentru anumite stri. n acest caz starea este anonim i dac n diagrama de stri
sunt cteva din ele, atunci ele toate trebuie s fie diferite ntre ele.

5.2.2. Starea iniial

Starea iniial reprezint un caz particular de stare, care nu conine nici o aciune intern
(pseudostare). n acest caz exist iniial un obiect n starea iniial a timpului. Ea este utilizat
pentru indicarea pe diagrama de stri a spaiului grafic, de la care ncepe procesul de modificare a
strilor. Grafic starea iniial n limbajul UML este reprezentat n form de cerc haurat (fig. 42, a),
de la care poate iei numai sgeata corespunztoare cu trecere.

Fig. 42. Reprezentarea grafic a strii iniiale i finale n diagrama de stri.

La cel mai nalt nivel de reprezentare a obiectului trecerea de la starea iniial la starea final poate
fi marcat ca aciunea de creare (iniializare) a obiectului dat. n cazul contrar tranziia nu esre
marcat deloc. Dac acest tranziie nu este marcata, atunci ea este prima trecere n starea
urmtoare.

5.2.3. Starea final

Starea final reprezint un caz particular al strii, care nu conine nici o aciune intern
(pseudostare). n aceast stare obiectul se v-a afla n starea iniial dup finisarea lucrului
automatului n ultimul moment de timp. El este utilizat pentru indicarea spaiului grafic pe diagrama
de stri, unde se sfrete procesul de schimbare a strii sau ciclului de via a obiectului dat. Grafic
starea final n limbajul UML este reprezentat n form de cerc haurat deplasat n circumferin
(fig. 42, b), n care poate intra numai sgeata corespunztoare cu trecerea.

5.3. Tranziie
O simpl tranziie reprezint o relaie ntre dou stri consecutive indicnd faptul schimbrii a unei
stri cu alt. Prezena obiectului modelat n prima stare va efectua anumite aciuni, dar trecerea n
starea a doua va fi atunci cnd anumite aciuni vor fi terminate i dup ndeplinirea anumitor
condiii adugtoare. Tranziia ncepe cnd un anumit eveniment se petrece: terminarea executrii
39

aciunii (do activity), trimiterea mesajului sau emiterea semnalului. n trecere se indic numele
aciunii. Mai mult, n tranziie poate fi indicat aciunea produs de un obiect ca reacia tranziiei de
la o stare la alta. Executarea tranziiei poate depinde nu numai de petrecerea unui anumit eveniment,
dar i de la ndeplinirea condiiei corespunztoare, care se numete condiie gard. Obiectul va trece
de la o stare la alta, numai n caz dac a fost aciunea indicat i condiia de gard este adevrat.
n diagrama de stri tranziia este reprezentat ca linie ntreag cu sgeat, care este ndreptat n
starea de int (exemplu, defect n fig. 40). Fiecare tranziie poate fi marcat cu aliniat de text,
care are urmtorul format general:
<signatura evenimentului>'['<condiia de paz>']' <exprimarea aciunii>.
Signatura aciunii descrie un anumit eveniment cu argumentele necesare:
<numele evenimentului>'('<lista parametrilor mprite cu virgule>')'.

5.3.1. Eveniment
Termenul eveniment (event) trebuie explicat aparte, deoarece el este un element independent al
limbajului UML. Opional evenimentul reprezint specificaia anumitui fapt, care are ataat o
locaie n timp i n spaiu. Despre fapte se spune c ele se petrec, n acelai timp evenimente
aparte trebuie s fie aranjate n timp. Dup sosirea evenimentului este imposibil de a ne ntoarce la
evenimentul precedent, dac aceast posibilitate nu este prevzut n model.
n limbajul UML evenimentele joac rol de stimule, care iniializeaz treceri de la o stare la alta. n
calitate de evenimente destingem semnale, apeluri, terminarea intervalurilor fixate de timp sau
momentele de finisare a executrii anumitor aciuni. Numele evenimentului identific fiecare
tranziie aparte n diagrama de stri i pot conine aliniat de text, care ncepe cu minuscul. n acest
caz tranziia va fi triger, adic care specific un eveniment triger. De exemplu, tranziii n fig. 40
sunt trigere, deoarece cu fiecare din ei sunt legate care-va eveniment triger, care petrece asincron
n momentul ieirii din funciune a echipamentului tehnic sau n timpul terminrii reparaiei lui.
Dac alturi de sgeata trecerii nu este indicat nici un aliniat de text, atunci trecerea corespunztoare
este netriger i n acest caz din contextul diagramei de stri trebuei s fie clar dup care terminare a
aciunii el ncepe a funciona. Dup numele evenimentului pot urma paranteze rotungite pentru
parametrii evenimentului triger. Dac nu exist aa parametri, atunci lista parametrilor cu
paranteze pot lipsi.

5.3.2. Condiie gard

Condiia gard (guard condition), dac exist, atunci ntodeauna este scris n paranteze
dreptungiulare dup evenimentul triger i reprezint expresie bulean. ntroducerea condiiei
gard pentru tranziie permite specificarea semanticii lui de executare. Dac condiia gard primete
valoarea adevrat, atunci tranziia respectiv poate executa, i ca rezultat obiectul va trece la
starea obiectiv pe aceast tranziie.
n cazul general de la o stare pot exista cteva tranziii cu tot acealai eveniment triger. Nici o
condiie gard nu trebuei s conin concomitent valoarea adevr. Fiecare din condiii gard este
necesar de calculat fiecare dat cnd sosete triger eveniment respectiv.
Grafic fragmentul de modelare de logic programului potal poate fi reprezentat n forma de
urmtoarea diagram de stri (fig. 43). Dup necesitatea emiterii potei, utilizatorul trebuie s
40

stabileasc conectarea telefonului cu provaiderul, ce este indicat n diagrama cu trecerea de sus. Cu

alte cuvinte, utilizatorul iniializeaz evenimentul triger de a stabili conectarea telefonului. Ca
parametru al acestui eveniment trece un numr de telefon concret a provaiderului. Apoi urmeaz
verificarea condiiei gard conectarea este stabilit, care se subnelege ca ntrebare. Numai n
cazul rspunsului da, adic adevr, se ntmpl trecerea programului potal de la starea
activarea programului potal n starea ncrcarea potei de la servelul provaiderului. n caz
contrar (linie ocupat, parol incorect) nici o ncrcare a potei nu va fi i programul va lsa n fosta
stare.

Fig.43. Diagrama de stri pentru modelarea programului client potal.

A doua trecere de triger pe diagram iniializeaz ntreruperea automat a conectrii telefonice cu
provaiderul dup terminarea ncrcrii potei n calculatorul utilizatorului. n acest cazul eveniment-triger de a finisa ncrcarea potei se petrece dup verificarea condiiei gard pota
electronic pe server este deeart, care tot trebuie sa fie subneles n form de ntrebare. Dac
rspunsul este pozitiv (toat pota este ncrcat sau ea nu este n pota electronic) programul
potal ntrerupe ncrcarea potei i trece n starea de activaie. Dar n cazul rspunsului negativ
ncrcarea potei va continua.

5.3.3. Expresia aciunei

Expresia aciunii (action expression) se execut atunci i numai atunci cnd se execut tranziia.
Reprezint operaia atomic, care se execut dup efectuarea tranziiei respective nainte de oricare
aciune n starea obiectiv. Activitatea atomic nseamn c ea nu poate fi ntrerupt de nici o alt
activitate pn cnd nu termin executarea lui. Aceast aciune poate influena ca la obiectul, dar i
la mijlocul lui, dac aceast este evident din contextul modelului. Expresia se scrie dup semnul /
n linia textului conectat cu tranziia respectiv.
n cazul general, expresia aciunii poate conine o list ntreag de activiti particulare, separate cu
simbolul ;. Condiie obligatorie toate aciune din list trebuie s fie difer ntre ele i s urmeze
n ordinea scrierii lor. Sintaxa notaiei expresiei de aciune nu are care-va limite. Cel mai principal
notarea lor trebuie s fie clar pentru elaboratorii modelului i programitilor. De aceea expresiile
sunt scrise mai rar n unul din limbajele de programare, care este presupus de utilizare pentru
realizarea modelului.
Ca exemplu de expresie a aciunii (fig. 43) poate servi de a ntrerupe conectarea (numrul
telefonului), care trebuie efectuat exact dup stabilirea adevrului (adevrul) condiiei gard
pota electronic pe server este deeart.
Ca un alt exemplu poate fi situaia evident cu alocarea obiectelor grafice pe ecranul monitorului
prin apsarea butonului stng a mouse-ului. n acest caz tranziia respectiv poate avea urmtorul
aliniat de text: este apsat i eliberat butonul stng a mouse-ului (coordonate) [coordonate n
regiunea obiectului grafic] / de alocat obiectului (culoarea). Rezultatul trecerii acestui triger poate
41

fi de exemplu activizarea anumitor proprieti a obiectului (dimensiunea failului n linia de stare)

sau extragerea.

5.4. Stare i substare compus

Stare compus (composite state) este o stare compus, care este alctuit din alte stri depuse.
Ultimile vor fi substrile (substate) pentru primul element. Dei ntre ele exist relaia de
compoziie, grafic toate vrfurile diagramei, care corespund substrilor depuse, sunt reprezentate
nuntrul simbolului strii compuse (fig. 44). n acest caz dimensiunele simbolului grafic a strii
compuse se mrete n aa fel ca toate substrile vor fi incluse.

Fig. 44. Reprezentarea grafic a strii compuse.

Starea compus poate conine dou sau mai multe subautomate paralele sau cte-va substri
consecutive. Fiecare substare compus poate fi precizat numai ntr-un singur mod, artat mai sus.
n urma cruia oricare din substri la rndul su pot fi stare compus i conine nuntru alte substri
depuse. Cantitatea nivelelor depuse a strilor compuse nu sunt fixate n limbajul UML.

5.4.1. Substri disjuncte

Substri disjuncte (sequential substates) sunt utilizate pentru modelarea aa fel de comportament a
obiectului, n timpul cruia n fiecare moment de timp obiectul poate fi numai ntr-o substare.
Comportamentul obiectului n acest caz reprezint schimbarea disjunct a substrilor, ncepnd cu
starea iniial i sfrind cu substarea final. Dei obiectul continu de a fi n starea compus,
ntroducerea n examinarea substrilor disjuncte d posibilitatea de a enumera mai fin aspectele
logice a comporatamentului lui intern.
Ca exemplu lum n consideraie n calitate de obiectul modelat un telefon obinuit. El poate fi n
diferite stri, una din care este starea conectrii cu abonatul. Evident, c pentru conectare este
necesar de redicat receptorul, s ascult tonul semnalului, dup care formm numrul de telefon
respectiv. n aa fel, starea de conectare cu abonatul este stare compus i const din dou substri
disjuncte: ridicarea receptorului i formarea numrului de telefon. Fragmentul de diagram de
stri pentru acest exemplu conine o stare compus i dou substri disjuncte (fig. 45).

42

Fig. 45. Exemplu de stare compus cu dou substri disjuncte depuse.

Oarecare lmuriri pot necesita tranziii. Dou din ele specific eveniment triger formarea
numrului, care are numele de cifra cu parametru n. Ca exemplu parametrului menifest o cifr
n discul telefonului. Tranziia din substarea iniial este netriger, deoarece ea nu conine nici un
aliniat de text. Ultima tranziie n substarea final nu are eveniment-triger, dar are condiie gard,
care verific corectitudinea formrii numrului abonatului. Numai n cazul cnd aceast condiie
este adevrat aparatul de telefon poate duce n substarea final, care caracterizeaz superstarea
conectarea cu abonatul n ntregime.
Starea compus poate conine ca depozit substarea iniial i final. n urma creia substarea iniial
este punct de plecare, cnd se ntmpl tranziia obiectului n starea compus. Dac starea compus
conine nuntru substarea final, atunci tranziia n aceast stare final depus nseamn finisarea
considerrii obiectului n starea depus. Este imporatant ca pentru substri disjuncte starea iniial i
final trebuie s fie unic n fiecare stare depus.

5.4.2. Substri concurente

Substri concurente (concurrent substates) pot specifica dou sau mai multe subautomate, care pot
executa paralel nuntrul strii compuse. Fiecare din subautomate ocup un anumit region nuntrul
strii compuse, care este desprit de la altele cu linia orizontal punctat. Dac n diagrama de stri
exist starea compus cu substrile paralele depuse, atunci obiectul poate fi concomitent n fiecare
din aceste substri.
Totui substrile paralele pot fi compuse din cte-va substri concomitente (subautomatele 1 i 2 n
fig. 46). n acest caz dup definiia obiectul poate s se afle numai n una din substrile disjuncte
automatului. Aadar, pentru un exemplu abstract (fig. 46) permitem prezena concomitent a
obiectului n substrile (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Inadmisibil este prezena concomitent
a obiectului n substrile (1,2,3) sau (3, 4, 5).

Fig.46. Reprezentarea grafic a strii compuse su substrile concurente depuse.

Pentru ca fiecare region a strii depuse specific un anumit subautomat, atunci pentru fiecare din
subautomate depuse pot fi definite substarea iniial i final (fig. 46). n timpul tranziiei n starea
depus dat fiecare din subautomate devine n substarea sa iniial. Mai departe se ntmpl
executarea concurent a fiecrui din subautomatele date, iar ieirea din starea depus va fiposibil
numai n cazul cnd toate automatele vor fi n strile sale finale.

43

Dac unul din subautomate a venit n starea sa final mai degrab dect altele, atunci el trebuie s
ateapte pn cnd alte subautomate vor veni n strile sale finale.
Exemplu a diagramei de stri, care reprezint modelarea comportamentului obiectului concret este
procesul funcionrii aparatului de telefon (fig. 47). Aceast diagram de stri reprezint un automat
cu o stare depus. Din exteriorul strii depuse exist numai o stare ateptare, care caracterizeaz
aparatul de telefon funcionat i conectat. Tranziia n starea urmtoare se ntmpl dup riricarea
receptorului. Tranziia cu aciunea atomic emiterea semnalului de ton transfer aparatul n starea
compus, adic n substarea lui iniial.

Fig. 47. Diagrama de stri a procesului de funcionare a aparatului de telefon.

Apoi aparatul de telefon va fi n starea semnalul de ton. n urma cruia el va scoate acest semnal
pn cnd nu v-a avea loc evenimentul-triger formarea cifrei(n), sau nu trec 15 secunde de la
momentul ridicrii receptorului. n primul caz aparatul va trece n starea formarea numrului, dar
n starea doua sfrirea timpului de ateptare. Ultima situaie poate fi ca rezultat a ndoielii s
sun sau s nu sun!? n urma cruia auzim bipuri n receptor, n urma cruia noi nu avem ce s
facem, n afar de a pune receptorul.
n timpul formrii numrului se execut evenimentul-triger formarea cifrei (n) cu condiia gard
numrul incomplet. Aceast luru nseamn c numrul format nu conine numrul necesar de cifre,
atunci este nevoie de a continua formarea cifrei urmtoare, rmnnd n starea formarea
numrului.
Dac numrul format este incomplet, atunci putem duce n starea numrul greit sau
conectarea. n cazul numrului greit (condiia gard greit este adevr) nu avem alt
alternativ dect s ieim din starea compus cu punerea receptorului. Dar dac numrul este corect,
atunci are loc conectarea pe acest numr.
44

Totui n rezultatul conectrii poate s se ntmple ca aparatul abonatului este ocupat (trecerea n
starea ocupat) sau liber (trecerea n starea sunetul la abonat). n primul caz sunetul poate fi
repetat, dup punerea receptorului (ieirea din starea compus). n al doilea caz se ntmpl
controlarea condiiei gard convorbirea este accesibil. Dac ea este adevrat, ceea ce
corespunde cu ridicarea receptorului cu abonatul, ncepe convorbirea telefonic. n caz contrar
(aceast condiie nu se execut, adic este fals) telefonul abonatului va continua s sune, ceea ce ne
spune c ori abonatul nu este, sau din care-va alt motiv nu putem continua cinvorbirea la telefon. n
urma cruia noi nu avem alt soluie dect s punem receptorul.
Dac convorbirea a avut loc, atunci dup cuvinte de adio i executarea condiiei de gard
confirmarea la terminarea convorbirii noi iari punem receptorul la loc. n urma cruia aparatul
de telefon trece n starea ateptarea, n care poate s se afle un timp nelimitat.

6. Diagrama de activiti (activity diagram)

Pentru modelarea procesului de executare a operaiilor n limbajul UML se utilizeaz aa numitele
diagrame de activiti. Notaia grafica acceptat pentru aceste diagrame are mult comun cu notaia
diagramei de stri ce se evideniaz prin notarea strilor i tranziiilor. Deosebirea const n
semantica strilor care sunt utilizate pentru prezentarea aciunilor dar nu activitilor, i n aceea c
tranziiile evenimentelor nu sunt etichetate. Fiecare stare n diagrama de activiti corespunde
executrii unei operaiuni elimentare, dar trecere n alt stare se execut numai la terminarea
operaiei n starea precedent. Grafic diagrama de activiti se reprezint n forma unui graf de
activitate cu nodurile stri activitate i muchile tranziii de la o stare la alt.
n aa fel, diagramele de activiti pot fi considerate cazuri particulare ale diagramelor de stri.
Anume aceste diagrame permit realizarea administrrii procedurale i sincrone care depinde de
terminarea activitii interne n limbajul UML. Sensul principal al utilizrii acestor diagrame const
n vizualizarea particularitilor operaiilor unor clase pentru reprezentarea algoritmilor executrii
lor. Totodat fiecare stare realizeaz operaiile unei clase anumite i permite utilizarea diagramei de
activiti pentru descrierea reaciilor la evenimente interne acestui sistem.
n contextul limbajului UML activitatea (activity) reprezint o totalitate de calcule executate de
ctre automat. Totodat calculele elementare pot duce la un anumit rezultat sau careva aciune
(action). n diagrama de activiti se reflect logica sau consecutivitatea tranziiilor de la o aciune la
alta, totodat se evideniaz rezultatul activitii. Rezultatul, la rndul su poate duce la schimbarea
strii sistemului dat sau la returnarea unei valori.

6.1. Starea activitii

Starea activitii este un caz particular a strii. Starea activitii nu poate avea tranziii interne
fiindc ea nu este elementar. Starea activitii se utilizeaz pentru modelarea unui pas de
executarea a algoritmului (procedurii) sau a unui flux de control.
Grafic starea activitii se reprezint printr-o figur asemanatoare cu dreptunghiul, laturile laterale
ale cruia sunt substituite cu arcuri convexe (printr-un dreptunghi cu coluri rotunjite) (fig. 48). n
interiorul acestei figure se indic expresia unei aciuni care trebuie s fie unic n cadrul unei
diagrame de activiti.

45

Fig. 48. Starea activitii (a actiune simpl, b expresie).

O aciune poate fi indicat n limbaj natural, n pseudocod sau n limbaj de programare. Nu sunt
restricii suplimentare pentru indicarea aciunilor. Se recomand n calitate de nume al unei aciuni
simple s se utilizeze un verb cu cuvinte explicative (fig. 48, a). Dac aciunea nu poate fi
reprezentat ntr-un mod formal, atunci este util a-l indica n limbaj de programare pentru realizarea
proiectului dat (fig. 48, b).
Uneori este necesar a reprezinta n diagrama de activiti o aciune complex care la rndul su
const din mai multe aciuni simple. n acest caz poate fi utilizat notaia special a strii de
subactivitate (subactivity state). Aa fel de stare este un graf de activitate care se noteaz cu un
semn special n colul drept de jos (fig. 49). Aceast construcie poate fi aplicat oricrui element al
limbajului UML care susine imbricarea pentru structura sa. Totodat semnul special poate fi
etichetat cu tipul structurii.

Fig. 49. Starea subactivitii.

Fiecare diagrama de activiti trebuie s aib o singur stare iniial i o singur stare final.

6.2. Tranziii
Tranziia ca element al limbajului UML a fost studiat n capitolul despre diagrama de stri. La
construirea diagramei de activiti se utilizeaz careva tranziii netrigere care acioneaz deodat
dup perfectarea activitii sau dup executarea aciunii corespunzatoare. Aceast tranziie transmite
activitatea n urmtoarea stare imediat dup ce se termin aciunea din starea precedent. n
diagram aceast tranziie se reprezint printr-o linie continu cu o sgeat.
Dac din starea dat iese numai o tranziie atunci ea poate s nu fie marcat (indicat), dar dac
tranziiile de ieire sunt mai multe atunci poate s acioneze numai una din ele. Anume n acest caz
pentru fiecare din tranziii trebuie s fie indicat n paranteze patrate o condiie de supraveghere.
Totodat pentru toate strile de ieire trebuie s fie executat numai o cerin de veridicitate a unei
tranziii. Acest caz are loc cnd activitatea consecvent executat trebuie s fie divizat n ramuri
alternative independent de valoarea unui rezultat intermediar. Aceast situaie se numete
ramificaie. Grafic ramificaie se reprezint printr-un romb gol (fig. 50). n acest romb numai o
sgeat de la o aciune corespunztoare poate s intre. Sgeata de intrare se unete cu vrful de sus
sau cu cel din stnga al simbolului de ramificaie. Pot fi mai multe sgei de ieire, dar pentru fiecare
din ele trebuie s fie indicat condiia de supraveghere sub form de expresie boolean.
Ca exemplu vom cerceta calcularea costului total al produciei procurate cu o cartel bancar. Dac
costul depete 50$ atunci se acioneaz identificarea proprietarului cartelei bancare. n caz dac
46

cartela este valabil i contul nu depete suma n 50$ atunci suma se scoate de pe cont i se achit
producia procurat. n caz contrar (dac cartela nu este valabil) achitarea nu se execut i
producia rmne la vnztor.

Fig. 50. Diverse variante ale ramificaiilor n diagrama de activiti.

Unul din cele mai semnificative neajunsuri ale schemelor-block sau ale schemelor ce reprezint
algoritmi este legat cu problema reprezentrii ramurilor paralele ale unor calcule. Din motiv c
divizarea calculelor n ramuri aparte marete viteza produsului soft, sunt necesare primitive grafice
pentru reprezentarea proceselor paralele. n limbajul UML pentru acest scop se utilizeaz simboluri
pentru diviziune i unire a calculelor paralele sau a fluxurilor de control. Acest simbol este o linie
dreapt analogic notaiei unei tranziii n formalismul reelelor Petri.
De regul aceast linie se reprezint printr-un segment al unei linii orizontale, grosimea creia este
mai mare dect grosimea liniilor n diagrama de activiti. Totodat fork (diviziunea concurrent
fork) are o tranziie de intrare i mai multe de ieire (fig. 51, a). Join (unirea concurrent join)
invers are mai multe tranziii de intrare i numai o tranziie de ieire (fig. 51, b).

Fig. 51. Fork i join a mai multor fluxurilor paralele de control.

Pentru ilustrarea particularitilor proceselor paralele de executare a aciunilor este util a cerceta
exemplul devenit clasic de pregtire a a unei buturi. Avantajul acestui exemplu const n faptul c
exemplul practic nu cere explicaii adugtoare, fiindc este considerat evident (fig. 52).

47

Fig. 52. Diagrama de activitate pentru un exemplu de preparare a buturii.

6.3. Partiii
Diagramele de stri pot fi utilizate nu numai pentru specificarea algoritmelor de calculare sau
fluxurilor de control n sistemele de programare. Un domeniu de utilizare este legat cu modelarea
busimes-proceselor. ntra-devr, activitatea oricrei companii reprezint totalitatea aciunilor
independente ndreptate la atingerea rezultatului. Totui relativ de businesprocese este de dorit
efectuarea fiecarei aciuni asociative cu subdivizare a companiei concrete. n acest caz aceste
subdiviziuni au responsabilitatea de realizare a unor aciuni, iar businesprocesele reprezint
trecerea aciunilor de la o subdivizare la alta.
48

Pentru modelarea acestor particulariti n limbajul UML se folosete construcia special, care are
denumire de partiii (swimlanes), care sunt divizate unul cu altul cu linii verticale. Dou linii vecine
formeaz o partiie, iar un grup de stri ntre aceste linii sunt executate de subdiviziunea separat
(secie, filial, diviziuni) a companiei (fig. 53).
Denumirele subdiviziunelor sunt indicate n partea de sus a partiiei. A ntretia linia partiiei pot
numai tranzaciile, care n acest caz indic ieirea sau intrarea fluxului de control n subdiviziunea
respectiv a companiei. Ordinea trecerii partiiilor nu are care-va informaie simantic i este
definit dup motivele de comfortabilitate.
Ca exemplu vom lua fragmentul diagramei de activitate a companiei de vindere, care servesc
clienii cu ajutorul telefonului. Subdiviziunele companiei sunt secia de acceptare i perfectare a
cerinelor, secia de vindere i depozitul. Acestor subdiviziuni vor corespunde trei partiii n
diagrama de activitate, fiecare din care specific zona de responsabilitate a subdiviziunei. n cazul
dat diagrama de activitate ntreine nu numai informaie despre consecutivitatea executrii a aciunii
lucrtorilor, dar i care subdiviziuni a companiei de vindere trebuie s execute o aciune sau alta
(fig. 53).

Fig. 53. Fragmentul diagramei de activitate pentru compania de vindere.

Din aceast diagram de activitate este evident c dup acceptarea comandei de la client a seciei de
acceptare i perfectare a cerinelor se realizeaz diviziunea activitii la dou fluxuri (tranzacie diviziune). Primul din ei rmne n aceeai secie i este legat cu acceptarea mrfurilor n secia de
vindere (modelul mrfii, dimensiuna, culoarea, anul de editare etc.). Dup finisarea lucrului acesta
iniializeaz aciunea de eliberare a marfurilor din depozit. Totui pregtirea mrfii pentru
expedierea n secia de vindere ncepe numai dup achizionarea mrfii de la client i marfa va fi
expediat din depozit (tranziie - conectare). Numai dup aceasta marfa este expediat la client i
devine proprietatea lui.
49

6.4. Obiecte
n cazul general aciunile n diagrama de activitate sunt efectuate cu obiecte. Aceste obiecte sau
iniializeaz executarea aciunelor sau definesc un anumit rezultat a acestor aciuni. n urma cruia
aciunile specific apelurile, care trec de la un obiect a grafului de activitate la altul. ntruct n acest
racurs obiectele joac un anumit rol n nelegerea procesului de activitate, uneori apare necesitatea
indicrii lor n diagrama de activitate. Pentru reperezentarea grafic a obiectelor sunt utilizate
dreptunghiurile clasei cu o deosebire: numele obiectului se subliniaz. Dup nume poate fi indicat
caracteristica strii obiectului n paranteze ptrate. Aceste dreptunghiuri a obiectelor sunt unite cu
strile de activiti a relaiei de dependen cu linia punctir cu sgeat. Dependena respectiv
definete starea concret a obiectului dup efectuarea aciunii precedente.
n diagrama de activitate cu partiii deplasarea obiectelor poate avea un sens adugtor. i anume,
dac obiectul este amplasat la hotarul ambilor partiii, aceast lucru nseamn c trecerea la starea de
aciune urmtoare n partiia vecin este asociat cu un document finit (obiectul n care-va stare).
Dar dac obiectul este amplasat nuntrul partiiei, atunci starea acestui obiect este definit de
aciunile partiiei date.
Revenind la exemplul precedent cu compania de vindere, poate nota c obiectul central a procesului
de vindere este comanda, anume starea ei de executare. La nceput, pn la primirea sunetului de la
client, comanda ca obiect lipsete i apare numai dup ce a am primit sunetul de la client. Totui,
aceast comand nu este ndeplinit pn la urm, deoarece este necesar de alege o marf concret
din secia de vindere. Dup pregtirea lui el transfer marfa la depozit, unde mpreun cu eliberarea
mrfurilor comanda este perfectat. La sfrit, dup trimiterea confirmrii despre achiziionarea
mrfii aceast informaie nscrie n comand i el este ndeplinit i sfrit (fig. 54).

Fig. 54. Fragmentul diagramei de activitate a companiei de vindere cu obiect comand.

50

7. Diagrama de secven (sequence diagram)

n limbajul UML colaborarea ntre entiti se cerceteaz n aspectul informativ al comunicaiilor lor,
adic obiectele care interacioneaz ntre ele fac un oarecare schimb de informaii. Pentru modelarea
colaborrii ntre obiecte n limbajul UML se utilizeaz diagramele de interaciune. Vorbind despre
aceste diagrame se iau n consideraie dou aspecte.
Mai nti, colaborarea ntre obiecte poate fi cercetat n timp i atunci pentru reprezentarea
particularitilor temporale i modului de acceptare a mesajelor se utilizeaz diagrama de secven.
n al doilea rnd pot fi cercetate particularitile structurale ale colaborrii ntre obiecte. Pentru
reprezentarea particularitilor de transmitere i acceptare a mesajelor ntre obiecte se utilizeaz
diagrama de colaborare.

7.1. Obiecte
n diagrama de secven se descriu numai obiectele care sunt direct implicate n interaciune i nu
reflect asocierile statice cu alte obiecte. Pentru diagrama de secven momentul principal este
dinamica colaborrii ntre obiecte n timp. Grafic fiecare obiect se reprezint printr-un dreptunghi i
se plaseaz n partea de sus a ciclului su de via (fig. 54). n nteriorul dreptunghiului se indic
numele obiectului i numele clasei desprite prin dou puncte. Totodat toat nregistrare se
subliniaz, ce indic c obiectul este exemplarul unei clase. n caz dac numele obiectului lipsete,
atunci se indic numai numele clasei i obiectul se consider anonim.

Fig. 55. Primitivele grafice ale diagramei de secven.

Obiectul din stnga diagramei este cel care iniiaz colaborarea (obiectul 1 n fig. 55). Mai la dreapt
se reprezint obiectul care interacioneaz cu primul. Totate obiecte n diagrama de secven
formeaz o anumit ordine determinat de activitatea colaborrii lor.
A dou msur a diagramei de secven este axa vertical (de sus n jos). Momentului iniial de timp
i corespunde partea de sus al diagramei. Totodat colaborarea obiectelor este realizat prin
mesajele transferate. Mesajele se reprezint sub forma de sgei drepte cu numele mesajelor, ele de
asemenea sunt ntr-o ordine anumit n timp. Cu alte cuvinte, mesajele plasate n diagrama de
secven mai sus sunt iniiate mai devreme dect cele din jos. Totodat proporiile pe axa temporal
nu se indic fiindc diagrama de secven modeleaz doar ordonarea n timp a legturilor de tip
mai devrememai trziu.

51

7.1.1. Linia de via al obiectului

Linia de via a obiectului (object lifeline) se reprezint printr-o linie vertical punctat asociat cu
un singur obiect n diagrama de secven. Linia de via definete intervalul de timp n care obiectul
exist i interacioneaz cu sistemul dat.
Obiecte aparte, dup finisarea activitiilor sale n sistem, pot fi distruse pentru eliberarea resurselor
allocate lor n sistemul priectat. Pentru aceste obiecte linia lor de viata se rupe n momentul de
distrugere. Pentru reprezentarea momentului de distrugere al unui obiect n limbajul UML se
utilizeaz un simbol special sub forma de litera latin X. Mai jos de acest simbol, linia punctat
nu poate fi desenat fiindc obiectul n sistemul deja nu este i acest obiect este exclus din toate
interaciunile ulterioare.
Nu este obligatoriu a crea obiecte la momentul iniial de timp. Obiecte pot fi create la necesitate,
economisind resursele acestui sistem i majornd randamentul lui. n acest caz dreptunghiul
obiectului respectiv se desenaz n partea diagramei care corespunde momentului de creare a
obiectului.

7.2. Focus control

n procesul de funcionare a sistemelor OO unele obiecte pot fi n stare activ executnd aciuni
anumite sau pot fi pasive ateptnd mesaje de la alte obiecte. Pentru a evidenia obiectele active n
limbajul UML se utilizeaz notaia special focus control (focus of control). Focus control se
reprezint n form de dreptunghi subire, latura de sus a cruia indic (reflect) nceputul activitii,
latura de jos finisarea activitii (focusului de control).
n unele cazuri ca iniiator al activitii n sistem poate fi un actor sau utilizatorul extern. n acest
caz actorul se deseneaz primul din stnga cu focus control respectiv. Totodat actorul poate s aib
un nume propriu sau s rmn anonim.

7.3. Mesaje
Scopul colaborrii n contextul limbajului UML const n specificarea comunicaiei ntre o mulime
de obiecte. Fiecare interaciune este descris de un set de mesaje cu care obiectele-participante se
schimb intre. n acest sens mesajul (messaje) reprezint un fragment de informaie care este
transferat de ctre un obiect altuia. Totodat acceptarea mesajului iniializeaz anumite aciuni
ndreptate spre rezolvarea problemei de ctre obiectul cruia mesajul i este transferat.
Mesajele nu numai transmit informaia, ci i presupun executarea aciunilor ateptate de ctre
obiectul acceptabil. Mesajele pot iniia executarea operaiilor de ctre obiectul unei clase, dar
parametrii acestor operaii sunt transferai mpreun cu mesajul. n diagrama de secven toate
mesajele sunt coordonate dup timpul de apariie n sistemul modelat.
n acest context, fiecare mesaj are o direcie de la obiect, care iniiaz i trimite un mesaj la obiectul
care le primete. Uneori, expeditorul mesajului se numete client i beneficiar - server. Totodat
mesajul de la client este sub form de iniializare a unui anumit serviciu, iar reacia aa numitului
server dup primirea mesajului presupune executarea anumitor aciuni i transmiterea informaiei
sub forma a unui mesaj ctre client.
n limbajul UML pot fi folosite mai multe tipuri de mesaje, fiecare dintre ele are propria
reprezentare grafic.
52

n unele cazuri, obiectele pot transmite mesaje sie nsui, iniiind aa-numita comunicare reflexiv.

7.3.1. Stereotipuri de mesaje

n limbajul UML sunt presupuse numai aciuni standarde, care se execut la primirea mesajului
respectiv. Ele pot fi indicate n diagrama de secven sub forma de stereotipuri ataate mesajelor
respective i se scriu n ghilimele. Pentru diagrama de secven sunt urmtoarele stereotipuri de
mesaje:

"call" invoc chemarea operaiei sau procedurei obiectului-destinatar;

"return" returneaz valoarea operaiei executate sau procedurei obiectului apelant;
"create" creaz un alt obiect pentru executarea anumitor aciuni;
"destroy" mesaj cu o cerin clar de a distruge obiectul corespunztor.Se transmite n
cazul cnd este necesar pentru a opri aciunile nedorite a obiectului din sistemul existent, sau
atunci cnd obiectul nu mai este necesar i ar trebui s elibereze resursele alocate lui;
"send" trimiterea unui semnal care este iniializat asincron de ctre un obiect i este
acceptat de altul. Diferena ntre un semnal i un mesaj const n fapt c semnalul trebuie s
fie descris n clasa obiectul cruia iniializeaz transmiterea lui.

n afar de stereotipuri, mesajul poate avea denumirea sa proprie, a operaiunii. n acest caz lng
sgeat se scrie numele operaiei cu paranteze rotunde n care se indic parametrii sau argumentele
operaiei respective. Dac parametrii lipsesc atunci parantezele rmn neaprat dup numele
operaiei.

Fig. 56. Notaiile mesajelor in diagrama de secven.

7.4. Restricii temporale n diagrama de secven

n unele cazuri executarea unor aciuni n diagrama de secven poate necesita specificaia unor
restricii temporale ctre intervalul executrii unei operaii sau transmiterii mesajelor. n limbajul
UML pentru scrierea restriciilor temporale se utilizeaz acoladele figurate. Ca exemple de restricii
n diagrama de secven sunt situaii de specificare a timpului pentru transmiterea a unui mesaj de la
client ctre server sau situatii de prelucrare a cerinei clientului.

{timpul_de_ateptare_a_rspunsului < 5 sec.}

{timpul_de_trnsmitere_a_pachetului < 10 sec.}
53

c: Aparat de
telef on
ridica receptorul

: Comutator

a : Abonat

d: Aparat de
telef on

b : Abonat

signal ton()
roteste discul
f ormeaza un
numar

: Conv orbire
"create"
conexare()

"send"
"send"

ridica receptorul

termina
conv orbire

pune receptorul

conexare(a)
pune receptorul

sunet()

conexare(b)
termina
conv orbire
"destroy "

Dupa conexare Abonatul a si

Abonatul b pot incepe conv orbire

Fig. 57. Exemplu de construcie a unei diagrame de secven.

8. Diagrama de colaborare (collaboration diagram)

Particularitatea principal a diagramei de colaborare const n posibilitatea de a reprezenta grafic nu
numai consecutivitatea colaborrii dar i toate relaii structurale ntre obiecte. n primul rnd n
diagrama de colaborare sub form de dreptunghiuri se reprezint obiectele care conin numele
obiectului, clasei, valorile atributului. Mai departe, ca i n diagrama de clase se indic asocierile
ntre obiecte sub forma de linii de conectare. Totodat pot fi indicate numele asocierilor i al
rolurilor obiectelor pentru asocierea dat. Suplimentar pot fi reprezentate legturile dinamice
fluxurile de mesaje. Ele se reprezint ca linii ntre obiecte cu sgei care indic derecia, numele
mesajului i numrul de ordine n consecutivitatea de iniializare a mesajelor.
Spre deosebire de diagrama de secven n diagrama de colaborare sunt reprezentate relaiile ntre
obiecte care sunt importante pentru colaborare. Din alt parte n aceast diagrama nu se indic
timpul n calitate de msur. Consecutivitatea de aciuni i flux paralel pot fi determinate cu ajutorul
numerelor de ordine, deci este posibil specificarea legturilor ntre obiecte n timp real.
Pentru atingerea unui scop sau pentru realizarea unui serviciu comportamentul unui sistem poate fi
descris la nivelul obiectelor care fac schimb de mesaje. Din punct de vedere a unui analist sau a
unui constructor este important reflectarea legturilor structurale ale obiectelor aparte. Diagrama
de colaborare reflect un fel de reprezentare static a unui sistem ca totalitate de obiecte
dependente.

8.1. Obiecte
Obiecte sunt elementele de baz sau primitivele grafice din care const diagrama de colaborare.
Pentru reprezentarea grafic a obiectelor se utilizeaz acelai dreptunghi ca i pentru reprezentarea
clasei.
54

Obiectul (object) este un exemplar aparte al clasei care este creat la etapa executrii a unui program.
El poate avea un nume propriu i valorile atributelor. Referitor la obiecte formatul liniei ce conine
clasificatorul se completeaz cu numele obiectului:
<Numele obiectului>'/' <Numele rolului al clasificatorului> ':' <Numele clasificatorului>
[':' <Numele clasificatorului >]*
Aici Numele rolului clasificatorului poate s nu fie indicat. n acest caz el se exclude din context
mpreun cu dou puncte. Numele rolului poate fi omis n caz daca exist mai multe roluri n
colaborarea obiectelor create pe baza clasei date. Pentru definirea rolului clasificatorului este de
ajuns a indica numele clasei (mpreuna cu dou puncte) sau numele rolului (mpreuna cu /). n caz
contrar dreptunghiul va corespunde clasei ordinare. Dac rolul unui obiect se motenete de la mai
multe clase, atunci ele toate trebuie s fie indicate i desprite prin virgul i dou puncte.
Urmtoarele sunt variante de indicare a textului n nteriorul dreptunghiului.

: un obiect anonim creat pe baza clasei .

/ R un obiect anonim cu rolul R.
/ R : un obiect anonim creat pe baza clasei cu rolul R.
/ R un obiect cu numele O cu rolul R.
: un obiect cu numele O creat pe baza clasei .
/ R : un obiect cu numele O creat pe baza clasei cu rolul R.
sau obiectul cu numele .
: un "obiect orfan" cu numele .
/ R un rol cu numele R.
: un rol anonim pe baza clase .
/ R : un rol cu numele R pe baza clase .

Fig. 58. Exemple de moduri de indicare a numelor obiectelor, rolurilor i claselor n diagrama de
colaborare.
n primul caz (fig. 58, a) obiectul cu numele client cu rolul iniiatorul cerinei. n cazul
(fig. 58, b) este indicat un obiect anonim cu rolul iniiatorului cerinei. n ambele cazuri nu este
indicat clasa pe baza creia sunt create aceste obiecte. n cazul (fig. 58, c) clasa este determinat,
dar obiectul rmne anonim. Referitor la nivelul de specificare n diagramele de colaborare pot fi
specificate clase denumite cu indicarea rolurilor (fig. 58, d) sau clase anonime dar tot cu indicarea
rolurilor (fig. 58, e). Ultimul caz reflect situaia cnd n model pot fi prezente cteva clase cu
numele Client, de aceea este necesar specificarea numelui pachetului Baza de date (fig. 58, f).

55

8.1.1. Multiobiect
Multiobiect (multiobject) reprezint o mulime de obiecte n una din terminaiile asocierei. n
diagrama de colaborare multiobiectul se utilizeaz pentru a arat operaiile i semnalele care sunt
adresate ctre toat mulimea de obiecte. Multiobiectul se reprezint n forma a dou dreptunghiuri,
unul din care iese n afara laturei de sus a altui dreptunghi (fig. 59, a). Totodat sgeata mesajului se
refer la toat mulime de obiecte care definesc multiobiect dat. n diagrama de colaborare poate fi
indicat relaia compoziiei (structura) ntre multiobiect i un obiectul aparte din mulime care l
definete (fig. 59, b).

Fig. 59. Multiobiect.

8.1.2. Obiect activ

n contextul limbajului UML toate obiecte se mpart n doua categorii: pasive i active. Obiectul
pasiv folosete numai datele i nu poate iniializa activitatea de control. Obiecte pasive pot
transmite semnale pe parcursul procesului de realizare a cerinelor.
Obiectul activ (active object) are un fir (thread) de control propriu i poate iniializa activitatea de
control. Totodat sub noiune de fir se subnelege un anumit flux de control care poate fi executat
n paralel cu alte fire de calcul sau cu fire de control n cadrul unui proces de calcul sau control.
Obiectele active n diagramele canonice sunt reprezentate n form de dreptunghi cu laturi groase
(fig. 60). Uneori pentru a evidenia obiectul activ n diagram poate fi indicat cuvntul-cheie
(valoarea marcat) {active}. Fiecare obiect activ poate iniia un singur fir sau proces de control i s
prezinte punctul iniial al fluxului de control. n fragmentul diagramei de colaborare dat obiect activ
a: Abonatul arogant este iniiatorul procesului de stabilire convorbirii pentru schimb de
informaie ntre aboneni.
1: create
a : Abonatul
arogant

c:
Conectare

Fig. 60. Obiect activ.

n exemplu urmtor se cerceteaz situaia de apelare a funciei de tipar a unui redactor textual
(fig. 61). Obiectul activ anonim Redactor textual mai nti trimite mesajul ctre multiobiectul
Imprimant care iniiaz alegearea unui singur obiect Imprimant care satisface cerinele
suplementare. Dup aceea obiectului ales i se transmite mesajul de tipar al unui document ncrcat
n redactorul textual.

56

1: aImprimanta:=alege()
: Redactor
textual

: Imprimanta
F

2: tipar(document)
: Imprimanta

Fig. 61. Fragmentul diagramei de colaborare pentru apelare funciei de tipar din redactor textual.

8.1.3. Obiect compus

Obiectul compus (composite object) sau obiectul-container este destinat pentru reprezentarea
obiectului care are structura proprie i fire interne de control. Obiectul compus este exemplarul
clasei compuse care este legat cu parile sale prin relaii de agregare sau compoziie. Relaii
analogice leag obiectele respective.
n diagramele de colaborare aa fel de obiecte compuse se reprezint n forma a unui obiect ordinar
care const din dou secii. n secia de sus se indic numele obiectului compus, n cea de jos
prile compuse n locul listei atributelor lui (fig. 62). Totodat n calitate de pri pot fi obiecte
compuse.

Fig. 62. Obiect compus.

8.2. Legturi
Legtura (link) este exemplarul sau exemplul asocierii arbitrare. Legtura ca element al limbajului
UML poate fi ntre dou sau mai multe obiecte. Legtura binar n diagrama de colaborare se
reprezint n form de segment al liniei drepte care leag dou dreptunghiuri ale obiectelor (fig. 61).
La fiecare terminal al acestui segment pot fi indicate numele rolurilor asocierii date. Lng linie, n
mijlocul ei, se indic numele asocierii respective. Legturile nu au numele proprii fiindc sunt
identice ca exemplare ale asocierii. Cu alte cuvinte toate legturile n diagrama de colaborare pot fi
numai anonime i se indic fr dou puncte naintea numelui asocierii. Pentru legaturi nu se indic
nici multiplicitatea. ns alte reprezentri ale cazurilor particulare de asociere (agregare,
compoziia) pot fi la terminaiile legturilor. De exemplu, simbolul de tip compoziia ntre
multiobiectul Imprimant i obiectul aparte Imprimant (fig. 61).
57

8.2.1. Tipuri de legturi

Tipul de legtura se nscrie lnga terminaia ei i indic posibilitatea realizrii acestei legturi. n
limbajul UML pentru acest scop se utilizeaz:

"association" asociere (se presupune implicit, de aceea acest tip poate s nu fie indicat).
"parameter" parametrul metodei. Obiectul respectiv poate s fie doar paramentru al unei
metode.
"local" variabila local a metodei. Domeniul ei de vizibilitate este limitat de ctre obiectul
vecin.
"global" variabila global. Domeniul ei de vizibilitate este toat diagrama de colaborare.
"self" legtura reflexiv a obiectului care presupune transferul mesajelor ctre sine. n
diagrama de colaborare legtura reflexiv se reprezint n form de bucl n partea de sus al
dreptunghiului obiectului.

Unele exemple de legturi cu diferite stereotipuri sunt prezentate n fig. 63. Aici este reprezentat
schema unei companii cu numele C care const din secii (multiobiect anonim Secie). Seciile
constau din angajai (multiobiect anonim Angajat). Legtura reflexiv indic faptul c managerul
seciei este i angajatul acesteia.
c : Compania

"local" subsectie

: Sectie
"self" manager
"local" executa lucrul

: Angajat

Fig. 63. Legturi de diferite tipuri.

Pentru obiectul Convorbire2 se indic valoarea {transient} care nseamn c obiectul este creat pe
parcursul executrii procesului i se distruge nainte de terminaia lui.

58

5: comutatie(a,b)

: Comutator
4: formeaza un numar(i)

8: apeleaza_abonatul(b)

legatura telefonica

legatura telefonica
c : Aparat
de telefon

1: ridica_receptorul()
3: roteste_discul()

"local"

7: confirma()

2: signal_ton()

6: creaza()

: Convorbire

d : Aparat
de telefon

10: ridica_receptorul()

"local"

transient

12: incepe_convorbire()

11: incepe_convorbire()

"global" participant_convorbirei

"global" participant_convorbire

a : Abonat

9: sunet()

b : Abonat

Fig. 64. Exemplu de construire a diagramei de colaborare.

8.3. Colaborare
Noiune de colaborare (collaboration) este una din noiunile fundamentale ale limbajului UML. Ea
nseamn o mulime de obiecte care interacioneaz n contextul comun al sistemului modelat.
Scopul colaborrii const n specificarea particularitilor realizrii a celor mai semnificative
operaii n sistem. Colaborarea determin structura comportamentului sistemului dat n termeni de
colaborare a participanilor.
Colaborarea poate fi prezentat n dou nivele:

Nivelul de specificare arat rolurile clasificatorilor i rolurile asocierilor n colaborarea

dat.
Nivelul de exemple indic exemplare i legturi, roluri n colaborare.

Diagrama de colaborare la nivel de specificare arat rolurile elementelor ce particip n colaborare.

Elementele colaborrii la acest nivel sunt clase i asocieri care reprezint rolurile unor clasificatori
i asocieri ntre participanii acestei colaborari.
Diagrama de colaborare la nivel de exemple reprezint o totalitate de obiecte (exemplare de clase)
i legturi (exemplare de asociere). Totodat legturi sunt completate cu sgeile mesajelor. La acest
nivel sunt reflectate numai obietce relevante, adic obiectele care au legtur cu realizarea operaiei
sau clasificatorului.
n colaborare la nivel de exemple sunt definite proprieti fiecrui exemplar pentru participarea n
colaborare. n afara de proprietile obiectului, n diagrama de colaborare sunt indicate asocierile
ntre obiectele acestei colaborri. n momentul cnd clasificatorul necesit descrierea complet a
tuturor exemplarilor, rolul clasificatorului necesit descrierea numai proprietilor i asocierilor
pentru participarea ntr-o colaborare anumit.
59

Una i aceeai totalitate de obiecte poate participa n mai multe colaborri. Totodat, n dependen
de colaborarea cercetat, unele proprieti ale obiectelor pot s se schimbe aa precum i legturile
ntre ele. Anume acest fapt deosebete diagrama de colaborare de diagrama de clase n care sunt
indicate toate proprietile i asocierile ntre elementele diagramei.

8.3.1. Diagrama de colaborare la nivel de specificare

Colaborarea la nivel de specificare se reprezint printr-o elips punctat n interiorul creia se indic
numele acestei colaborri (fig. 65). Aa fel de reprezentare se refera la un caz de utilizare particular
i care detaliaz particularitile realizrii lui urmtoare. Simbolul elipsei a colaborrii se leag cu
fiecare din participanii acestei colaborri (care pot fi obiecte sau clase) cu segmente de linie
punctat. Fiecare din aceste segmente punctate se marcheaz cu rolul (role) participantului. Rolurile
corespund numelor elementelor n contextul ntregii colaborri. Aceste numele sunt tractate ca
parametrii care limiteaz specificarea elementelor la orice apariie a lor n reprezentrile modelului.

Fig. 65. Colaborarea n diagrame la nivel de specificare.

Clasa elementar n diagrama de colaborare se reprezint printr-un dreptunghi n nteriorul creia se
indic textul. Acest text este (definete) rolul clasificatorului (classifier role). Rolul clasificatorului
specific utilizarea obiectelor clasei date. Deseori n dreptunghi se indic numele clasei, dar nu se
exclude posibilitatea de a indica atribute i operaii.
Textul n dreptunghi este de fel urmtor:
'/' <Numele rolului clasificatorului> ':' <Numele clasificatorului>
[':' < Numele clasificatorului >]*
Aici Numele clasificatorului poate s conin direcia tuturor pachetelor componente. Totodat un
pachet se divezeaz de altul prin dou puncte duble ::. Dac aceast nu ncurc atunci se poate de
indica numai pachetul apropiat care conine colaborare dat. Simbolul * arat posibilitatea de
repetare iterativ a numelui clasificatorului.
Dac colaborarea permite reprezentarea generalizat, atunci n diagrame pot fi indicate relaii de
generalizare a elementelor respective. Acest principiu determin colaborri aparte, care sunt cazuri
particulare sau specializare ale altei colaborri. Aceasta situaie deseori se reprezint n form de
sgeat de generalizare ndreptat de la simbolul colaborrii al descendentului spre simbolul
colaborrii alunui printe (fig. 66).

60

Fig. 66. Relaii de generalizare ntre colaborrii la nivel de specificare.

n unele cazuri apare necesitatea de a indica faptul c colaborarea este realizarea unei operaii sau a
unui clasificator. Acest fapt poate fi reprezentat n doi feluri.
n primul rnd simbolul colaborrii poate fi conectat cu ajutorul liniei punctate cu sgeata
generalizrii cu simbolul clasei, realizarea operaiei cruia specific colaborarea data (fig. 67, a).
Dac n calitate de clas va fi cercetat Comanda la procurarea produciei care are operaia
ntocmirea_comandei() atunci realizarea ei poate fi specificat n form de colaborare.

Fig. 67. Metode de reprezentare a colaborrii care realizeaz operaiunea clasei.

n al doilea rnd este uor de reprezentat simbolul colaborrii n nteriorul cruia se poate de indicat
toat informaia necesar conform regulii speciale (fig. 67, b). Aceste reguli definesc formatul de
nregistrare a numelui de colaborare, dup care se scriu dou puncte i numele clasei, dup numele
clasei se scriu dou puncte duble i numele operaiei.
Aa fel de reprezentare generalizat a colaborrii la nivel de specificare se utilizeaz la etapele
iniiale de proiectare. Ulterior fiecare din colaborri poate fi detaliat la nivel de exemple, la care se
desfoar coninutul i structura legturilor elementelor acestei colaborri n diagrama de
colaborare aparte. Totodat n calitate de elemente ale diagramei pot fi obiecte i legturi
completate cu mesaje. Anume astfel de elemente sunt obiectul cercetrii n capitolul dat.

9. Diagrama de componente (component diagram)

Toate diagramele cercetate mai sus reflectau aspectele conceptuale de proiectare a unui model de
sistem i se referiau la nivelul logic de reprezentare. Specificul reprezentrii logice const n faptul
c el utilizeaz noiuni care nu au personificare material proprie. Cu alte cuvinte diferite elemente
ale reprezentrii logice (clase, asocieri, stri, mesaje) nu exist n mod material sau fizic. Ele numai
reflect nelegerea noastr despre sistemul fizic sau despre aspectele comportamentului acestui
sistem.

61

Destinaie principala a reprezentrii logice const n analiza relaiilor structurale i funcionale ntre
elementele unui model de sistem. Pentru crearea unui sistem fizic real este necesar a transforma
toate elementele reprezentrii logice n entiti materiale. Pentru descrierea acestor entiti este
destinat aspectul reprezentrii modelare fizice.
Pentru a explica diferena ntre reprezentarea logic i fizic vom cerceta procesul de elaborare a
unui sistem de program. n calitate de reprezentare logic iniial a acestui sistem pot fi schemele
structurale ale algoritmelor i procedurilor, descrieri a unor interfee i baza de date conceptual.
Pentru realizarea acestui sistem este necesar de a elabora codul surs n anumit limbaj (C++, Pascal,
Basic/VBA, JAVA). Totodat n codul surs se presupune divizarea acestui cod n module aparte.
Cu toate c codurile surs iniiale sunt fragmente ale reprezentrii fizice a unui proiect, ele nu
prezint realizarea final a lui. Sistemul program poate fi considerat realizat numai n caz daca el va
putea executa funciile destinaiei sale. Aceasta este posibil dac codul surs al unui sistem va fi
realizat n forma de module executate, biblioteci ale claselor i procedurilor, interfeelor grafice
standarde, fiierelor bazelor de date. Anume aceste componente sunt necesare pentru reprezentarea
fizic a unui sistem.
Proiectul complet al unui sistem al programului reprezint o totalitate de modele ale reprezentrii
logice i fizice care sunt coordonate ntre ele. n limbajul UML pentru reprezentarea fizic a unui
model al sistem sunt utilizate diagramele de realizare (implementation diagrams) care includ dou
diagrame canonice: diagrama de componente i diagrama de plasare. Specifica crerii primei din ele
va fi cercetat n capitolul dat, al ultimei diagrame n capitolul urmtor.
Diagrama de componente, spre deosebire de diagramele cercetate, descrie particularitile
reprezentrii fizice a unui sistem. Diagrama de componente permite determinarea arhitecturii
sistemului elaborat prin stabilirea dependenei ntre componentele de program n calitate de care
poate fi codul iniial, binar i executabil. n mai multe domenii de elaborare modul i componenta
corespund fiierului. Sgeile punctate care leag modulele arat relaiile de dependena analogice
celor ce au loc la compilarea codurilor sursei iniiale. Elementul grafic de baz al diagramei de
componente sunt componentele, interfeele i dependenele ntre ele.
Diagrama de componente se elaboreaz pentru urmatoarele scopuri:

Vizualizarea structurii comune a codului surs a unui sistem de program.

Specificarea variantei executabile a unui sistem de program.
Asigurarea utilizrii repetate a unor fragmente ale codului surs.
Reprezentarea conceptual i fizic a schemelor bazei de date.

n elaborarea diagramei de componente particip analitii de sistem, arhitectorii, i programitii.

Diagrama de componente asigur trecere coordonat de la reprezentare logic spre o realizare a
unui proiect n form de cod surs. Unele componente pot exista numai la etapa compilrii codului
sursei, altele la etapa realizrii lui. Diagrama de componente reflect dependenele ntre
componente la cercetarea componentelor n calitate de clasificatori.

9.1. Componente
Pentru reprezentarea entitilor fizice n limbajul UML se utilizeaz componenta (component).
Componenta realizeaz un set de interfee i desemneaz elementele reprezentrii fizice a unui
model. Grafic componenta se reprezint printr-un dreptunghi cu anexe (fig. 67). n nteriorul acestui
dreptunghi se indic numele componentei i posibil informaia suplementar. Reprezentarea acestui
simbol variaz n dependen de informaia asociat cu componenta dat.
62

n metamodelul limbajului UML componentul este descendentul clasificatorului. El reprezint

organizaia n cadrul unui pachet fizic cu care el este asociat cu ajutorul elementelor unui model. n
calitate de clasificator componentul poate s aib aa proprieti ca atribute i operaii.

Fig. 68. Componenta.

n primul caz (fig. 68, a) cu exemplarul componentei se leag numai numele lui, n al doilea caz
(fig. 68, b) se leag n completare numele pachetului i valoarea marcat.
Adnotare
Reprezantarea componentului devine de la marcare modulului programului, care a fost utilizat un
anumit timp pentru reprezentarea particularitilor incapsularii datelor i procedurilor. n aa fel, un
dreptunghi mic de sus se asociaz cu datele, care realizeaz acest component (anterior a fost semnat
cu oval). Un dreptunghi mic de jos se asociaz cu operaii i metode, realizate de component. n
cazurile mai simple numele de date i metode au fost scrise n aceste dreptunghiuri mici, totui ele
nu sunt indicate n limbajul UML.

9.1.1. Numele componentului

Numele componentului este subardonat de regulele generale a numelelor elementelor modelului n
limbajul UML i poate fi compus din orice numr de litere, cifre i anumite semnuri de punctuaie.
Un component poate fi reprezentat la nivel de tip sau de exemplar. Dei reprezentarea grafic lui n
ambele cazuri este identic, regulile de notare a numelui componentului difer puin. Dac
componentul este reprezentat la nivelul tipului, atunci ca numele lui este scris numai numele tipului
cu majuscul.
Dar dac componentul este reprezentat la nivelul exemplarului, atunci numele este scris <numele
componentului:numele tipului>. n urma cruia toat alinierea numelui este subliniat.
Adnotare
Dei regulile de notare a obiectelor n limbajul UML cere sublinierea numelor anumitor exemplare,
relativ de componentele n literatur sublinierea numelelor lor nu este obligatorie. n acest caz
notarea numelui componentului cu majuscul va caracteriza componentul nivelului de exemplar.
n calitate de nume simple sunt utilizate numele fiierelor executabile (cu indicarea extensiei.exe
dup punct), numele librriilor dinamice (cu extensia .dll), numele Web paginilor (cu extensia
.html), numele fiierilor de text (cu extensia .txt sau .doc) sau fiiere de adeverin (.hip), numele
fiierelor bazelor de date (.db) sau numele fiierelor cu texturi iniiale a programelor( cu extensia .h,
.cpp pentru limbajul C++, cu extensia .java pentru limbajul Java), scripturi (.pi,.asp) i altele.
ntruct realizarea concret reprezentrii logice modelului a sitemei depinde de instrumentarea
programului utilizat, de aceea numele componentelor vor fi definite de particularitile sintaxei
limbajului de programare respectiv.

63

9.1.2. Feluri de componente

ntruct componentul ca element a realizrii fizice a modelului reprezint un modul al codului,
deseori el este comentat cu indicarea simbolelor grafice adugtoare, care marcheaz
particularitile concrete realizrii lui.
Aceste notaii adugtoare pentru adnotare nu sunt specificate n limbajul UML. Totui utilizarea
lor simplific nelegerea diagramei de componente i perfecioneaz reprezentarea ei grafic. Unele
notaii pentru componente sunt prezentate mai jos (fig. 69).
n limbajul UML sunt specificate trei feluri de componente:

n primul rnd componente de regrupare, care specific executarea de ctre sistem a

funciilor sale. Aa fel de componente pot fi librrii conectate dinamic cu extensia .dll
(fig. 69, a), Web pagini n limbajul de trasare hipertextului cu extensia .html (fig. 69, b) i
fiierele de adeverin cu extensia .hip (fig. 69, c).
n al doilea rnd, componente produse de lucru. Ca regul acestea sunt fiierele cu texte
iniiale a programului, de exemplu, cu extensia .h sau .cpp pentru limbajul C++ (fig. 69, d).
n al treilea rnd, componentele de executare, ce reprezint modulele fiierele cu extensia
.exe. Ei se indic obinuit.

Fig. 69. Variantele reprezentrii grafice a componentelor diagramei de componente.

Aceste elemente sunt uneori numite artefacte, subliniaz n aa fel coninutul lor informaional finit,
dependent de tehnologie de realizare concret a componentelor respective. Mai mult dect att,
elaboratorii pentru acest scop pot utiliza notaii independente, deoarece n limbajul UML nu exist
notare strict pentru reprezentarea grafic a notaiilor.
Un alt mod de specificare a diferitor feluri componentelor este indicarea steriotipului
componentului naintea numelui lui. n limbajul UML pentru componente sunt specificate urmtori
steriotipuri:

Librrie (library) definete prima specie a componentuluui, care reprezent librrie

dinamic sau static.
Tabel (table) definete prima specie a componentului, care reprezent un tabel de baze de
date.
Fiier (file) definete a doua specie a componentului, care reprezint un fiier cu texte
iniiale a programului.
Document (document) definete a doua specie a componentului, care reprezint un
document.
Executare (executable) definete a treia specie componentului, care poate fi executat n
nod.

64

9.2. Interfee
Urmtorul element a diagramei a componentelor sunt interfeele. Ultimele au fost desrise mai sus,
de aceea aici vor fi indicate numai acele proprieti, care sunt tipice pentru reprezentarea la
diagramele de componente. Ne reamentim c n cazul general interfaa este reprezentat n form de
circumferin, care este legat cu componentul cu ajutorul liniei fr sgeat (fig. 70, a). n urma
cruia numele interfeei, care obligatoriu trebuie s fie scris cu majuscul I, este scris alturi de
circumferin. Semantic linia nseamn interfaa, iar prezena interfeelor la componente nseamn
c componentul dat realizeaz trus de interfee respective.

Fig. 70. Reprezentarea grafic interfeelor n diagrama de componente.

Un alt mod de reprezentare a interfeelor n diagrama de componente este reprezentarea lui n forma
de dreptunghi a clasei cu stereotipul interfaa i cu seciuni posibile a atributelor i operaiilor
(fig. 70, b). Ca regul, acest caz de notare este utilizat pentru reprezentarea structurii interne a
interfeei, care poate fi important pentru realizarea.
n urma elaborrii sistemelor de programare interfeele asigur nu numai coinciderea diferitor
versiuni, dar i posibilitatea de ntroducere a schimbrilor n unele pri a programului neschimbnd
altele pri a ei. n aa fel, destinaia interfeilor este mai adnc, dect specificaia interaciunii cu
utilizatorii sistemului (actorii).
Adnotare
Caracter de utilizare a interfeelor cu unele componente poate fi diferit. De aceea exist dou feluri
de legtur a interfeei i componentului. Dac componentul realizeaz o anumit interfa, atunci
aceast interfa este numit de export, deoarece acest component prezint n el modul de serviciu
pentru altele componente. Dac componentul utilizeaz o anumit interfa, care este realizat de un
alt component, atunci acea interfa pentru primul component este numit de import.
Particularitile interfeei de import const n aceea c n diagrama de componente aceast relaie
este reprezentat cu ajutorul dependenei.

9.3. Dependene
n cazul general relaia de dependen a fost examinat mai sus. Reamentim c relaia de
dependen nu este asociere, dar este utilizat numai pentru reprezantarea faptului existenei acestei
legturi, cnd modificarea unui element a modelului nflueneaz sau duce la schimbarea altui
element a modelului. Relaia de dependen n diagrama de componente reprezint o linie punctir
cu sgeat orientat de la client (element dependent) la surs (element independent).
Relaia poate indica legturile modulelor programului la etapa de compilare i generare a codului.
n alt caz dependena poate indica existena n componentul independent descrierea clasei, care sunt
utilizate n componentul dependent pentru crearea obiectelor respective. n diagrama de
65

componente dependenele pot conecta componentele i interfeele de import de component, dar i

diferite feluri de componente ntre sine.
n primul caz se deseaneaz sgeat de la component client la interfaa de import (fig. 71).
Prezena sgeii nseamn c componetul nu realizeaz interfaa respectiv, dar utilizeaz n ea
procesul su de executare. n aceast diagram mai poate exista i un alt component, care realizeaz
aceast interfa. De exepmplu, fragmentul diagramei de componente prezentat mai jos reprezint o
informaie despre componentul cu numele main.exe dependent de interfaa de import I dialog,
care la rndul su este realizat de componentul cu numele image.java. Pentru al doilea
component aceai interfa este de export.

Fig. 71. Fragmentul diagrameide componente cu relaie de dependena.

Observm, c de a reprezentarea al doilea component cu numele image.java n form de variant
de adnotare nu este posibil, deoarece acest component realizeaz interfaa.
Un alt caz de relaie de dependen n diagrama de componente este relaia ntre diferite feluri de
componente (fig. 72). Prezena dependenei acestea nseamn c shimbrile n texte a programelor
sau librrii dinamice vor duce la schimbarea componentului. n urma cruia caracterul schimbrii
poate fi indicat adugtor.

Fig. 72. Reprezentarea grafic relaie de dependena ntre componente.

i n sfrit, n diagrama de componente pot fi reprezentate relaiile de dependen ntre componente
i realizate n ele clase. Aceast informaie este foarte imporatant pentru coordonarea reprezentrii
logice i fizice a modelelor sistemului. Shimbrile n structura descrierii claselor poate duce la
schimbarea componentului. Mai jos este prezentat fragmentul dependenei, cnd un anumit
component depinde de clase respective.

Fig. 73. Reprezentarea frafic dependenei ntre componente i clase.

66

n cazul dat, din diagrama de componente nu reiese c clasele sunt realizate de acest component.
Dac este necesar de subliniat c care-va component realizeaz anumite clase, atunci pentru
indicarea componentului este utilizat simbolul n form de dreptunghi. n urma cruia dreptunghiul
componentului divizeaz n dou seciuni cu linia orizontal. Secia de sus este utilizat pentru
notarea numelui componentului, iar cea de jos pentru indicarea informaiei adugtoare (fig. 74).

Fig. 74. Reprezentarea grafic a componentului cu informaia adugtoare despre clase realizate.
nuntrul simbolului a componentului sunt indicate alte elemente a notaiei grafice, aa clase ca
(componentele nivelului de tip) sau obiectele (componentele nivelului de exemplare). n acest caz
simbolul componentului este reprezentat n aa fel ca s ntroduc aceste simboluri adugtoare. De
exemplu, componentul realizat mai jos (fig. 75) este exemplar i realizeaz trei obiecte.

Fig. 75. Reprezentarea grafic a componentului nivelului de exemplar, ce realizeaz obiectele.

Obiecte, care se afl n componentul exemplar sunt reprezentate ntr-un fel de elementele depuse
n simbolul componentului dat. Aa fel de depunere nseamn c efectuarea componentului duce la
executarea obiectelor respective. Cu alte cuvimte, existena componentului n timpul executrii
programului a aprozivionat existena i posibil accesul tuturor obiectelor depuse. Ce se refer la
accesul acestor obiecte, el poate fi adugtor specificat cu ajutorul specificatorul de vizibilitate ca i
la vizibilitile pachetelor. Sensul vizibilitii poate fi diferit pentru diferite feluri de pachete.
De exemplu, pentru pachetul programului cu text iniial vizibilitatea nseamn posibilitatea
ntroducerii schimbrii n texte a programului respectiv cu recompilarea lor. Pentru componente cu
codul programului executabil vizibilitatea poate caracteriza posibilitatea de a executa componentul
respectiv sau chemarea operaiilor sau metodelor realizate n el.

9.4. Recomandri la construirea diagramei de componente

Elaborarea diagramei de componente presupune utilizarea informaiei despre reprezentarea logic a
modelului sistemului, dar i despre particularitile realizrii ei fizice. nainte de elaborare este
necesar de a face o decizie despre alegerea programei de calcul i sistemului operaional, dup care
s realizm sistema, dar i alegerea bazelor de date concrete i limbajelor de programare.

67

Dup ce putem duce la structurizarea general a diagramei de componente. n primul rnd este
necesar de a hotr din care pri (fiiere) fizice va fi compus sistemul de programare. La aceast
etap este necesar de a ateniona la aa fel de realizare a sistemului care va garanta nu numai
posibiliatea utilizrii repetate a codului pe seama decompoziiei componentelor, dar i crearea
obiectelor n urma necesitii.
Merge vorba despre producerea general sistemului de programare care n mare parte depinde mult
de utilizarea raional a ei de resursele de calcul. Pentru acest scop este necesar descrierea marii
pri a claselor, operaiilor i metodelor lor de a scoate n librriile dinamice, lsnd n
componentele de executare numai cele mai necesare fragmente pentru iniializare a codului
programului.
Dup structurizarea general reprezentrii fizice a sistemului este necesar de adugat modelul cu
interfee i schemele bazei de date. n elaborarea interfeelor este necesar de a atrage atenia la
coordonarea diferitor pri a sistemului de programare. Includerea n modelul bazelor de date
presupune specificarea tabelelor i stabilirea legturilor informaionale ntre tabele.
n sfrit, etapa final de construire a diagramei de componente este legat de stabilirea i depunerea
n diagram a nteraciunilor ntre componente i relaiile de realizare. Aceste relaii trebuie
desfurate n toate aspectele importante a realizrii fizice a sistemului, ncepnd cu particularitile
compilrii textelor iniiale a programului i terminnd cu ndeplinirea unor pri a programului la
etapa de executare. Pentru aceast scop pot fi utilizate diferite feluri de reprezentare grafic a
componentelor.
n timpul alaborrii programului trebuie de inut cont de principiile generale a crerii modelului n
limbajul UML. i anume, n primul rnd este necesar de a utiliza componente i stereotipuri, care
exist n limbajul UML. Pentru majoritatea proiectelor tipice aceast trus nu este suficient pentru
reprezentarea componentelor i dependenelor ntre ele.
Dar dac proiectul conine anumite elemente fizice, descrierea crora lipsete n limbajul UML,
atunci trebuie de utilizat mecanizmul de extindere. i anume, utilizarea stereotipuri adugtoare
pentru unele componente netipice sau valorile marcate pentru precizarea unor caracteristici a lor.
n sfrit trebuie de atras atenia c diagrama de componente este, ca regul, elaborat cu diagrama
de plasare, care reprezint informaia despre deplasarea fizic a componentelor sistemului a
programei dup nodurile ei. Particularitile construirii diagramei de plasare vor fi definite n
capitolul urmtor.

10. Diagrama de plasare (deployment diagram)

Reprezentarea fizic a sistemului de programare nu poate fi plin, dac lipsete informaia despre
programele i metode de realizare a calcului. Dac este elaborat un simplu program, care poate fi
executat local la calculatorul utilizatorului fr ntroducearea echipamentelor periferice i
resurselor, atunci n acest caz nu este necesitate de a elabora diagrame adugtoare. Totui, n
timpul elaborrii anexei situaia este alta.
n primul rnd, sistemele de programare compuse pot fi realizate n form de reea n diferite
programe de calcul i tehnologiile de accesare la baze de date. Prezena reelei locale corporative
necesit rezolvarea totalitii de probleme adugtoare despre amplasarea raional a componentelor
dup nodurile reelei, ce definesc producerea general a sistemului de programare.

68

n al doilea rnd, integrarea sistemului de programare cu Internet definete necesitatea deciziei

ntrebrilor adugtoare n timpul proiectrii sistemului n aa fel ca asigurarea securitii, ... i
accesul stabil la informaie pentru clienii corporativi. Aceste aspecte depind mult de realizarea
proiectului n form de noduri a sistemului, care exist fizic, aa ca serveri, centralele funcionale,
brandmauzeri, canale de conectare i pstrrile de date.
Tehnologiile de acces i de manipulare a datelor n schema general clientul-server tot trebuie de
amplasat baze de date mair n diferite segmente de reelei corporative, copierea lor rezerv,
arhivarea pentru garantarea producerii necesare a sistemului. Aceste aspecte tot necesit
reprezentarea vizual pentru specificarea particularitilor tehnologice i de programare a realizrii
arhitecturei distribuite.
n capitolul 9 prima diagrama reprezentrii fizice este diagrama de componente. Al doilea form de
reprezentarea fizic sistemului de programare este diagrama de plasare. Ea este utilizat pentru
reprezentarea general configurarei i topologiei sistemului de programare distribuite i conine
repartizarea componentelor dup nodurile a sistemului. Pe lng c diagrama de plasare indic
prezint legturile fizice rutele de transfer a informaiei ntre echipamente, utilizate n realizarea
sistemului.
Diagrama de plasare este specific pentru vizualizarea elementelor i componentelor a programului,
ce exist numai la etapa executrii lui (runtime). n urma cruia sunt prezentate numai componente exemplare a programului, care sunt fiiere de executare sau librriile dinamice. Acele
componente, care nu sunt utilizate la etapa executrii, n diagrama de plasare nu sunt indicate.
Componente cu texte iniiale a programului pot fi numai n diagrama de componente. n diagrama
de rezervare nu sunt indicate.
Diagrama de rezervare conine reprezentarea grafic a procesorilor, echipamentelor, proceselor i
legturilor ntre ele. n deosebire de diagrama reprezentrii logice, diagrama de plasare este un
sistem unic, deoarece trebuie s desfoare toate particularitile realizrii ei. Aceast diagram
finalizeaz procesul pentru un sistem concret de programare i elaborarea ei este ultima etapa de
specificarea a modelului.
Aadar, enumrm scopurile, ce sunt urmrite n timpul elaborrii diagramei de plasare:

De definit distribuirea componentelor a sistemului dup nodurile fizice.

De prezentat legturile fizice ntre toate nodurile de realizare a sistemului la etapa de
executare.
De a gsi locurile nguste a sistemului i de a reconfigura topologia ei pentru atingerea
producerii necesare.
Pentru garantarea cerinelor diagramei de plasare se elaboreaz mpreun cu analistele a
sistemului, ingineri de reele i altele. Apoi vom examena elemente din care sunt coninute
diagramele de plasare.

10.1. Nod
Nodul (node) reprezint un anumit element fizic a sitemului, care are o anumit resurs de
calculare. Ca resurs de calculare a nodului poate fi o valoarea electronic sau magnitioptic a
memoriei sau procesorului. n ultima versiune a limbajului UML definiia nodului este extins i
pot conine nu numai echipamente pentru calculare, dar i mprimant, modemuri, camere digitale,
scanere i altele.

69

Adnotare
Posibilitatea de a include oamenii (personal) n definiia nodului d posibilitate de a crea mijloacele
limbajului UML modele a diferitor sisteme, inclusiv bisnes procese i complexe tehnice.
Realizarea business logicei ntreprinderii trebuie de examinat n calitate de noduri a sitemului,
subdiviziunele organizatorice, care este compus din personal. Automatizarea conducerii
complexurilor tehnice trebuie de examinat ca element independent omul operator, care are
posibilitate de a accepta deciziile n situaii complicate i de a purta rspunderea pentru diferite
consecine a deciziilor lui.
Reprezentaea grafic a nodului n diagrama de plasare este n form de cub trigonometric. Nodul
are un propriu nume, care este indicat nuntrul acestui simbol grafic. Nodurile pot fi prezentate n
form de tipuri (fig. 76, a), dar i n calitate de exemplare (fig. 76, b).

Fig. 76. Reprezentarea grafic a nodului n diagrama de plasare.

n primul caz numele nodului este scris fr subliniere i ncepe cu majuscul. n al doilea caz
numele nodului exemplar este scris n form de <numele nodului ':' numele tipului nodului>.
Numele tipului nodului indic specia nodurilor, ce se afl n modelul sistemului.
De exemplu, partea de aparat a sistemului poate fi compus din cte-va calculatoare, fiecare din cre
corespunde nodului exemplar n model. Totui toate nodurile exemplare sunt legate cu un tip de
noduri, anume nodul cu numele de tip Calculator. n desenul precedent (fig. 76, a) nodul cu
numele Server se refer la tipul general i nu se concretizeaz. Al doilea nod (fig. 76, b) este
nodul exemplar anonim a modelului concret a imprimantei.
La fel ca n diagrama de componente reprezentarea nodurilor poate fi extins pentru includerea
informaiei adugtoare despre specificarea nodului. Dac informaia adugtoare este legat cu
numele nodului, atunci ea este scris mai jos de nume ca valoare marcat (fig. 77).

Fig. 77. Reprezentarea grafic a nodului exemplar cu informaie adugtoare ca valoare marcat.
Dac este necesar de indicat componentele, care sunt deplasate n nodul separat, atunci pentru
aceast exist dou moduri. Primul din ei d posibilitate de a mpri simbolul grafic n dou secii
70

cu linie orizontal. n seciunea cea de sus este scris numele nodului, iar n cea de jos- componente
deplasate la nodul dat (fig. 78, a).
Al doilea mod permite deplasarea n diagrama de plasare nodurile cu componentele depuse
(fig. 78, b). Ca componente depuse pot fi numai componentele executante.

Fig. 78. Reprezentarea grafic a nodurilor exemplare cu componentele deplasate.

Ca adugare la numele nodului pot fi utilizate diferite stereotipuri, care specific destinaia nodului.
Dei n limbajul UML stereotipuri pentru noduri nu sunt specificate, n literatur exist urmtoarele
variante: procesorul, modem, reea i altele, care pot fi specificate de elaborator. Mai mult
dect att, n diagramele de plasare pot fi indicaii speciale pentru diferite echipamente fizice,
reprezentarea grafic clarific destinaia sau funciile lor.
Adnotare
Vorbind despre reprezentri grafice adugtoare pentru nodurile diagramei de plasare au n vedere
evidena lor n prezentare. De exemplu, procesorul poate fi prezenat ca un nod general (Fig. 11.1) i
ca interfaa calculatorului. n mod corespunztor, consoli pot fi prezentate n mod de tastatur.
Elaboratorul trebuie s aib adugtor i nsuiri creatoare.

10.2. Conexare
Pe lng reprezentarea nodurilor n diagrama de plasare sunt indicate relaiile ntre ele. n calitate de
relaii sunt conectri fizice ntre noduri i dependena ntre noduri i componente, reprezentarea
crora poate fi n diagramele de plasare.
Conectrile sunt un fel de asociere i sunt prezentate n form de linii fr sgei. Prezena liniei
indic necesitatea organizrii canalului fizic pentru schimbarea informaiei ntre nodurile respective.
Caracter de conectare poate fi adugtor specificat de adnotare, indicat de valoare sau restricie. n
fragmentul prezentat mai jos n diagrama de plasare (fig. 79) sunt specificate nu numai cererea la
viteza de transfer a datelor n reea local cu ajutorul valorii indicate, dar i recomandarea la
tehnologia fizic a realizrii conexelor n form de adnotare.

Fig. 79. Fragmentul diagramei de plasare cu conectri ntre noduri.

71

n afar de conectri n diagrama de plasare pot fi relaiile de dependen ntre nod i componentele
lui. Acest caz este alternativ pentru reprezentarea componentelor depuse nuntrul simbolului al
nodului, ce nu este ntodeauna comod, deoarece simbolul devine valoros. De aceea cnd exist
mulimea de componente desfurate n nod, o informaie respectiv poate fi reprezentat n fel de
relaie de dependen (fig. 80).
Diagrama de plasare poate avea o structur mai compus, care include componentele, interfee i
alte echipamente. n diagrama de plasare mai jos (fig. 81) este prezentat fragmentul reprezentrii
fizice a sistemului serviciului ndreptat pentru clienii bncii. Nodurile acestui sistem sunt
terminalul ndreptat (nodul - tip) i serverul bncii (nodul - exemplar).

Fig. 80. Diagrama de plasare cu relaia de dependen ntre nod i componenii desfurrii n el.

Fig. 81. Diagrama de plasare pentru sistemul serviciului ndreptat clienelor bncii.
n aceast diagram de plasare este indicat dependena componentul de realizare a dialogului
dialog.exe n terminalul ndreptat de la interfaa Iuthorise, realizat de componenii main.exe,
care la rndul su se desfoar la nodul exemplar anonim Serverul bncii. Ultimul depinde de
componentul bazei de date Clienii bncii, care de asemenea este desfurat la acest nod.
Adnotarea indic necesitatea utilizrii liniei protejate de comunicare pentru schimbarea datelor n
sistemul dat. Alt variant a acestei notaii a informaiei este n adugarea nodului n diagrama cu
stereotipul reea inchis.
Elaborarea sistemelor depuse presupune nu numai crearea codului programului, dar i coordonarea
totalitii de mijloace de aparate i echipamente macanice. Ca exemplu, vom urmri fragmentul
modelul de conducere a mijloacelor mecanice ndreptate de tip platformei de transport. Aceast
platform este specificat pentru deplasarea n regiunele de agresiune, unde prezena omului este
imposibil n urma cazurilor fizice.

72

Platforma de transport are un propriu microprocesor, camer digital, cu indicatoare de temperatur

i amplasament, de asemenea dispozitiv de conducere pentru schimbarea direciei i vitezei de
deplasare a platformei. Informaie de conducere i telemetric de la platform dup linii radio este
transferat n centrul de conducere, dotat cu calculator de conducere, manipulatoare de conducere i
un tablou mare de informaie.
n microprocesor platformele sunt desfurate componentele de program pentru realizarea influenei
simple de conducere la dispozitive, ce permite de a schimba discret direcia i viteza de deplasare a
platformei. n calculator centrele de conducere sunt desfurate componentele de program a analizei
informaiei telemetrice, care caracterizeaz starea unor echipamente a platformei i sunt realizate
algoritmele conducerii deplasrii platformei.
Varianta reprezentrii grafice acestui sistem de transport este prezentat n urmtoare diagrama de
plasare (fig. 82).

Fig. 82. Diagrama de plasare pentru modelul sistemului de conducere a platformei de transport.
Diagrama dat conine informaia general despre desfurarea sistemului i n continuare poate fi
detalizat n timpul elaborrii componentelor de conducere a programului. Este evident din desen c
n timpul elaborrii acestui program de plasare sunt utilizai steriotipul adugtor receptoremitor, care lipsete n descrierea limbajului UML i descriere special pentru care-va
echipamente mecanice.

10.3. Recomandri la construirea diagramei de plasare

Elaborarea diagramei de plasare nncepe cu identificarea tuturor tipuri de echipamente, care sunt
necesare pentru executarea de ctre sistem funciilor sale. n primul rnd sunt specificate nodurile de
calculare a sistemului,ce conin memorie i/sau procesorul. n urma cruia sunt utilizate steriotipuri
limbajului UML, iar n cazul de lipsirea lor, elaboratorii pot specifica stereotipurile noi. Unele
cerinele la coninutul mijloacelor de aparate pot fi n forma de restricie, particulariti i valorilor
marcate.
Construirea urmtoare a diagramei de plasare este legat de deplasare tuturor componentelor
executabile a diagramei dup nodurile sistemului. Dac unele componente executate n-au fost

73

deplasate, atunci aceast situaie trebuie s fie exclus prin introducerea n modelul nodutilor
adugtori, care conin procesorul i memorie.
n timpul elaborrii programelor simple, care sunt executate local n un calculator aa ca n cazul de
diagrama de componente necesitatea n diagrama de plasare pot lipsi deloc. n cazurile mai
compuse diagrama de plasare este construit pentru aa restricii ca:

Modelarea sistemelor de programare, ce realizeaz tehnologie de acces la datele clientserver. Pentru aa fel de sisteme este caracter divizare strict a puterilor i respectiv
componentelor ntre stanii lucrtoare a clienilor i serverul bazei de date. Posibilitatea
realizrii clienelor fine n terminalele sau organizarea accesului la depozitul de date duce
la necesitatea preciziei nu numai topologiei sistemului,dar i la coninutul componentelor .
Modelarea arhitecturilor desfurate diferite. Aceast este despre intrareelele corporative,ce
conin sute de calculatoare i altor echipamentelor pereferice, care funcioneaz n diferite
platforme i sub diferite sisteme operaionale. n urma cruia unele noduri sistemului acest
au distana ntre sine sute de kilometre (filialele companiei). n cazul acest diagrama de
plasare devine un instrument important de vizualizare topologiei generale a sistemului i
controlului migraiei unor componente ntre noduri.
n sfrit, sistemele cu microprocesoare, care pot funciona autonom. Aa fel de sisteme pot
conine diferite echipamente adugtoare, care garanteaz autonomia funcionrii lor i
rezolvarea problemelor. Pentru aceste sisteme diagrama de plasare d posibilitate de a
vizualiza coninutul acestor echipamente i intreconexiunea lor n sistemul.

Ca regul, elaborarea diagramei de plasare este realizat la etapa final a OOAP, ce caracterizeaz
sfiritul fazei de proiectare reprezentrii fizice. Din alt parte, diagrama de plasare poate fi
construit pentru analiza sistemului respectiv cu scopul analizei i modificrii urmtoare. n urma
cruia analiza presupune elaborarea acestei diagrame la etapa ei iniial ,ce caracterizeaz direcia
general analizei de la reprezentarea fizic la logic.
n timpul modelrii busines-proceselor diagrama de plasare n afar de calculatoare reelei
corporative poate conine n calitate de noduri diferite mijloace a orgtehnicei (fax, staii multicanale
de telefon). n urma cruia fiecare din echipamente respective poate funciona autonom i n
structura reelei corporative.
Dac este necesar de introdus n model surs de Internet, atunci n diagrama de plasare Internet
reprezint norul cu numele respectiv. Aceast indicare nu este specificat n limbajul UML, totui
ea este rar utilizat n timpul elaborrii modelelor a sistemelor desfurate.
n sfrit este necesar de a nota o situaie important, caracter elaborrii tuturor diagramelor
canonive. Dei n limbajul UML este definit notarea grafic pentru toate elemente a diagramelor
canonice, metode de reprezentare grafic a unor mijloacelor instrumentale au particularitile
specifice. Utilizarea CASE- mijloc instrumental duce la restricie la vizualizarea modelelor
sistemelor de programare. Merge vorba despre aceea c, unele elemente a limbajului UML pot lipsi
n CASE mijloace. Ieirea din aceast situaie poate fi legat ori cu alegearea altui instrument, ce
susine ultimile versiuni a limbajului UML, ori simplificarea modelului la baza de tipizrii ei.
n capitolul 12 care-va din aceste aspecte vor fi desfurate mai detaliat n exemplul CASE
mijloace Rational Rose 98/981.

74