Sunteți pe pagina 1din 14

2 Concepte UML

Dezvoltarea unui sistem informaţional, indiferent de abordarea folosită (structurată sau


orientată obiect), trebuie să conţină, sub o anumită formă, şi etape indispensabile: culegerea
cerinţelor, analiza, proiectarea, programarea, testarea, instalarea şi întreţinerea. Aceste etape
au loc aproape în ordinea prezentată mai sus; „aproape” pentru că testarea este o componentă
ce apare în toate stadiile dezvoltării. Restul ordinii se respectă, măcar din considerente logice:
nu execuţi şi apoi vezi ce ai de făcut, înţelegi vechiul sistem şi îl schiţezi pe cel nou. Cu toate
acestea abordarea orientată-obiect a apărut mai întâi doar la nivelul programării, apărând o
ruptură de concepte şi principii faţă de etapele de analiză şi proiectare.
Metodele de analiză şi proiectare orientate-obiect au apărut ulterior programării orientate-
obiect, pe la sfârşitul anilor 1980. Utilizarea unei metode de analiză şi proiectare orientate-
obiect semnifică un proces conceptual complex, subiectiv, independent de limbajul de
programare utilizat. Apariţia metodelor de analiză şi proiectare a fost vestea bună, vestea
proastă fiind aceea că au apărut în număr mare, fiecare cu proprii termeni pentru aceleaşi
concepte şi fiecare cu notaţiile şi metodele de abstractizare proprii. Altfel spus fiecare metodă
folosea propriul limbaj.
Un limbaj de modelare, privit la modul general, poate fi definit ca o serie de concepte,
principii, procedee şi mecanisme de extensie utilizabile pentru abstractizarea unor probleme
din anumite domenii.
Limbajul unificat de modelare, cunoscut şi prin acronimul UML (de la Unified Modeling
Language), este un limbaj grafic destinat analizei şi proiectării orientate-obiect a sistemelor
informaţionale menit să pună capăt diferenţelor majore dintre limbajele de modelare orientate-
obiect.
În 1994, Grady Booch, de la Rational Corporation, autorul unei metode de proiectare
orientată-obiect ce îi poartă numele şi al unor cărţi de referinţă în domeniu, împreună cu
James Rumbaugh, de la General Electric, autorul principal al metodei OMT, pun bazele unei
echipe ce se va dovedi productivă. Rezultatele se văd după un an (în octombrie 1995, cu
ocazia conferinţei OOSLA), când cei doi stabilesc caracteristicile de bază ale unei noi metode
de analiză şi proiectare, rezultată prin unificarea metodei lui Booch (OOD) cu OMT, metodă
denumită iniţial metoda unificată (The Unified Method).
La sfârşitul anului 1995, celor doi li se alătură Ivar Jacobson, un alt nume de referinţă din
domeniu, autorul metodei OOSE (Object-Oriented Software Engineering).
În 1996, metoda unificată îşi schimbă numele în limbajul unificat de modelare (Unified
Modeling Language) datorită faptului că eforturile iniţiale de unificare au fost concentrate
asupra limbajului grafic de modelare, a semanticii lui şi abia după aceea a modului de
utilizare a conceptelor. Schimbarea denumirii a fost justificată şi prin faptul că acest efort
ştiinţific nu a tratat iniţial şi aspecte de metodologie, permiţând astfel separarea limbajului de
modelare de procesul aplicării metodologiei. Punerea accentului pe limbaj nu echivalează cu
ignorarea modului de folosire a acestuia.
În 1997, apare versiunea 1.0, ce conţinea o documentaţie mai detaliată decât versiunile
anterioare, versiune ce este propusă OMG-ului (Object Management Group) pentru
standardizare. Răspunsul pozitiv al celor de la OMG vine în acelaşi an, UML devenind astfel
un limbaj standard de modelare orientată-obiect.
De la standardizare şi până în prezent au mai apărut şi alte versiuni ale limbajului unificat
de modelare, cum ar fi: versiunea 1.5, din martie 2003, şi versiunea 2.0, din septembrie 2005.

1
Principalele caracteristici ale UML

UML nu este o metodă de proiectare, ci un limbaj universal pentru modelarea şi


realizarea oricărui tip de sistem, de orice mărime, asigurând posibilităţi unitare de
reprezentare grafică în toate fazele dezvoltării unui sistem informatic: definirea cerinţelor,
analiză, proiectare, implementare, testare, instalare, întreţinere.
Conform definiţiei date chiar de OMG1, UML este un limbaj vizual pentru specificarea,
construirea şi documentarea elementelor sistemelor. Este un limbaj de modelare universal ce
poate fi folosit cu toate metodele obiectuale şi în toate domeniile de aplicaţii (de exemplu,
economie, sănătate, telecomunicaţii, gestiunea fluxurilor de lucru) şi pe toate platformele de
implementare (de exemplu, J2EE, .NET).
Nu toate posibilităţile de modelare pe care le oferă sunt necesare în toate domeniile de
aplicaţii. Acest lucru sugerează că limbajul trebuie structurat modular, cu posibilitatea de a
selecta doar acele părţi ale limbajului care sunt de interes într-un anumit proces de modelare.
Pe de altă parte, un exces de flexibilitate creşte probabilitatea ca două instrumente diferite
UML să suporte subseturi diferite de limbaj, ducând la probleme de interacţiune între ele.
UML 2.0 conţine două specificaţii complementare: infrastructura UML (UML
Infrastructure) şi superstructura UML (UML Superstructure). Dacă prima specificaţie
prezintă componentele fundamentale ale limbajului, partea a doua prezintă constructorii
accesibili utilizatorilor acestui limbaj.
UML a fost creat ţinându-se cont de următoarele principii:
 principiul modularităţii se asigură printr-o coeziune strânsă şi cuplare slabă cu
ajutorul pachetelor şi organizarea metaclaselor;
 principiul stratificării presupune separarea conceptelor pe diferite niveluri de
abstractizare;
 principiul partiţionării folosit pentru a organiza zone în cadrul aceluiaşi nivel de
abstractizare;
 principiul extensibilităţii se asigură prin două modalităţi:
– definirea de profile (Profiles) pentru a adapta limbajul anumitor platforme (de
exemplu, J2EE sau .NET) şi domenii (de exemplu, economie, finanţe etc.);
– definirea unui nou limbaj, înrudit cu UML, prin reutilizarea unor elemente din
infrastructura UML şi adăugarea metaclaselor necesare;
 principiul refolosirii, asigurat de un metamodel flexibil.
În domeniul dezvoltării de sisteme informaţionale, UML poate fi aplicat oricărei metode
de analiză şi proiectare orientate-obiect ce respectă principiile de mai sus. Exemple de metode
de analiză şi proiectare orientate-obiect ce ar putea folosi ca limbaj grafic UML sunt: Rational
Unified Process (RUP), DMR Macroscope, IBM Global Services Method şi Fujitsu SDEM.
Dintre aceste metode se remarcă RUP, denumit şi procesul unificat (Unified Process), ea
având ca autori aproape acelaşi grup de cercetători de la Rational Corporation ce au participat
şi la realizarea UML.
UML presupune o metodologie sistemică aplicată unui proces iterativ şi incremental,
condus prin cazuri de utilizare şi centrat pe o arhitectură, acestea fiind chiar principalele
caracteristici ale procesului unificat. Detaliile acestui proces se adaptează la factori cum ar fi:
domeniul aplicaţiei, experienţa şi organizarea echipei de dezvoltatori.
Un proces software iterativ presupune o detaliere succesivă a arhitecturii, astfel încât
fiecare nouă versiune a acesteia se bazează pe experienţa şi rezultatele obţinute din versiunea
anterioară.

1
*** – Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, OMG, 2004, p. 10.

2
Un proces software incremental presupune că fiecare trecere printr-un ciclu de viaţă, de
la culegerea cerinţelor şi până la întreţinere, conduce spre o detaliere treptată a deciziilor
strategice şi tactice, obţinându-se în ultimă instanţă soluţionarea cerinţelor reale ale
utilizatorului, sistemul rămânând însă simplu, fiabil şi adaptabil.
Vocabularul UML conţine patru mari componente:
1) Elemente
2) Relaţii (între elemente)
3) Extensii (aplicabile elementelor şi relaţiilor)
4) Diagrame (alcătuite din elemente şi relaţiile dintre acestea)

Elemente UML

Elementele UML sunt de patru tipuri:


1) Elemente structurale
2) Elemente comportamentale
3) Elemente de grupare
4) Elemente explicative

Elemente structurale
Elementele structurale sunt substantivele din modelele UML, reprezentând elemente
statice atât conceptuale, cât şi fizice.
Principalele elemente structurale UML sunt clasele. Cum în abordarea orientată obiect
orice este un obiect şi celelalte elemente structurale UML sunt în esenţă tot clase: interfeţele,
colaborările, cazurile de utilizare, actorii, clasele active, componentele şi nodurile.
Simbolul folosit în UML pentru reprezentarea unei clase este un dreptunghi în care sunt
evidenţiate trei componente: numele clasei, atributele şi operaţiile clasei. Completarea
acestor trei părţi se face ţinând cont de următoarele reguli:
 dacă respectiva clasă este abstractă (neinstanţiabilă direct), numele ei se scrie cu
caractere italice;
 deasupra numelui clasei, se scrie stereotipul acesteia între caracterele „<< >>”, dacă
există;
 în faţa numelui clasei se scrie, dacă există, metaclasa specializată prin aceasta;
 în faţa numelor atributelor şi a operaţiilor se scrie simbolul de vizibilitate („+” pentru
public, „#” pentru protejat, „-” pentru privat, „~” pentru pachet);
 numele fiecărui atribut este urmat de tipul de dată al acestuia;
 atributele au de obicei o singură valoare şi tot de obicei nu li se prezintă obligativitatea
existenţei cel puţin a unei valori; cu toate acestea în UML există posibilitatea
specificării multiplicităţii unui atribut între două paranteze drepte scrise între numele
atributului şi tipul acestuia, de exemplu: data_receptie[0..1] : Date
 tipurile de dată ale atributelor pot fi precedate de valorile iniţiale ale acestora;
 dacă o operaţie este abstractă (nu are nici o metodă care să o implementeze), toate
proprietăţile ei se scriu cu caractere italice;
 operaţiile sunt urmate de lista de parametri, prezentată între paranteze rotunde „( )”;
 în lista de parametri se specifică: tipul (in - intrare, out - ieşire, inout - intrare/ieşire),
numele, tipul de dată şi o eventuală valoare implicită;
 în faţa numelui fiecărui parametru se specifică tipul acestuia;

3
 după numele fiecărui parametru se scrie caracterul două puncte „:” şi tipul de dată al
acestuia;
 parametrii operaţiilor, cu toate proprietăţile acestora, se despart cu caracterul virgulă;
 chiar dacă o operaţie nu are nici un parametru, după numele acesteia, tot se scriu
parantezele rotunde;
 dacă o operaţie întoarce o valoare, după închiderea parantezei rotunde, destinate
specificării parametrilor, se scrie caracterul două puncte şi tipul de dată al valorii
întoarse.

«Stereotip»
Nume_MetaClasa::Nume_Clasa
+Atribut public : Tip_Data = Valoare_Initiala
#Atribut protejat : Tip_Data = Valoare_Initiala
-Atribut privat : Tip_Data = Valoare_Initiala
+Operatie publica(in Parametru_1 : Tip_Data = Valoare_implicita, out Parametru_N : Tip_Data) : Tip_Data
#Operatie protejata(in Parametru_1 : Tip_Data, inout Parametru_i : Tip_Data, out Parametru_N : Tip_Data) : Tip_Data
-Operatie privata() : Tip_Data

Fig. 2.1 Simbolul folosit în UML pentru reprezentarea claselor

Simbolul folosit în UML pentru reprezentarea unui obiect instanţiat dintr-o anumită clasă
este tot un dreptunghi în care sunt evidenţiate doar două din cele trei părţi: identitatea şi
starea. A treia parte, comportamentul, nu se reprezintă şi în simbolul fiecărui obiect, deoarece
acesta este comun tuturor obiectelor instanţiate din aceeaşi clasă. În partea destinată stării se
prezintă valorile curente ale fiecărui atribut, ca în figura 2.2:
«Stereotip»
Nume_Obiect : Nume_MetaClasa::Nume_Clasa
Atribut public : Tip_Data = Valoare_Curenta
Atribut protejat : Tip_Data = Valoare_Curenta
Atribut privat : Tip_Data = Valoare_Curenta
Fig. 2.2 Simbolul folosit în UML pentru reprezentarea obiectelor

În figura 2.3, se prezintă un exemplu de reprezentare grafică a clasei „Angajat” şi a


obiectului „Popescu Ion” instanţiat din această clasă.
Angajat Popescu Ion : Angajat
-Marca : Char Marca : Char = 1001
-Nume : Char Nume : Char = Popescu
-Prenume : Char Prenume : Char = Ion
-Functia : Char Functia : Char = agent vânzari
-CNP : Char CNP : Char
+Informeaza(in Raport : Char)

Fig. 2.3 Exemplu de clase şi obiecte

Termenul de interfaţă desemnează serviciile (grupurile de operaţii) oferite de clase sau


componente. Operaţiile sunt implementate cu ajutorul metodelor.
Interfeţele descriu comportarea vizibilă din exterior a claselor sau componentelor; nu
specifică niciodată implementarea acestor operaţii. Interfeţele pun în practică unul din
conceptele abordării orientate-obiect, de separare a structurii unui obiect de implementarea sa.
Aşadar, o interfaţă poate fi privită ca un protocol de comunicare între obiecte. O clasă poate
implementa una sau mai multe interfeţe, depinzând de funcţionalităţile pe care le
implementează.
O interfaţă se reprezintă în UML cu un dreptunghi în care sunt prezentate: numele
acesteia şi operaţiile ei publice, ca în figura 2.4:

4
«interface»
Interfata
+Operatie1()
+Operatie2()
Fig. 2.4 Simbolul folosit în UML pentru reprezentarea interfeţelor

De exemplu, într-o aplicaţie economică, clasele de tranzacţii ce modifică patrimoniul


unităţii pot să implementeze următoarea interfaţă destinată contabilizării respectivelor
modificări:
«interface»
Contabilizare
+Get_Note_Contabile(out Debit, out Credit, out Suma)
+Set_Plan_de_conturi(in Plan_de_conturi)
Fig. 2.5 Exemplu de interfaţă

O interfaţă poate fi reprezentată şi sub forma unui cerc. De obicei interfeţele se prezintă
ataşate de clasele sau componentele care le implementează.
O colaborare defineşte o interacţiune şi este un grup de roluri şi de alte elemente ce
conlucrează pentru asigurarea unei funcţionalităţi. O colaborare are astfel atât o dimensiune
structurală, cât şi una comportamentală. Ea se reprezintă grafic cu o elipsă desenată cu o linie
întreruptă, în care se scrie de obicei numai numele acesteia.
Un caz de utilizare este o funcţionalitate a unui sistem destul de mare încât să poată fi
descrisă cel puţin cu o secvenţă de acţiuni realizate de sistem (o colaborare) şi care duc la un
rezultat cerut de un anumit utilizator (un actor). Cazurile de utilizare sunt folosite în
organizarea elementelor comportamentale ale unui sistem. Se reprezintă grafic cu o eclipsă
desenată cu o linie continuă în care se scrie numele acestuia.
Tipuri aparte de clase sunt cele ce reprezintă grupurile de utilizatori ai sistemului
(inclusiv alte sisteme) cu care se interacţionează. Termenul folosit pentru desemnarea acestora
este de actor. Actorii nu fac parte din sistem, fiind doar generatori de evenimente, având
acelaşi rol ca şi entităţile externe (sursele sau destinaţiile fluxurilor de date) din modelarea
structurată cu ajutorul diagramelor fluxurilor de date. În figura 2.6, se prezintă modalitatea de
reprezentare grafică a actorilor în UML.

Actor

Fig. 2.6 Simbolul UML de reprezentare a unui actor

O clasă activă este o clasă ale cărei obiecte au unul sau mai multe procese sau fire de
execuţie şi prin urmare pot iniţia activităţi de control. O clasă activă se reprezintă cu un
dreptunghi, ca orice clasă, cu deosebirea că marginile acestuia sunt îngroşate.
O componentă este o parte fizică a sistemului ce implementează un grup de interfeţe. O
componentă reprezintă de obicei gruparea fizică (la implementare) a unor elemente de natură
logică, cum ar fi clase şi interfeţe. Această grupare se face în funcţie de nevoile de coeziune şi
cuplare identificate. Tipuri particulare de componente pot fi considerate: aplicaţiile,
bibliotecile, documentele şi fişierele.
Reprezentarea grafica a unei componente este cea din figura 2.7.
Un nod este reprezentarea unei resurse de prelucrare necesare, de obicei a unui
calculator. Într-un nod pot exista mai multe componente. Grafic, un nod se reprezintă sub
forma unui cub în care îi este scris numele.

5
Nume

componentă

Fig. 2.7 Simbolul UML de reprezentare a unei componente

Elemente comportamentale

Elementele comportamentale sunt părţile dinamice ale modelelor UML. Ele sunt
verbele unui model, ce ajung să fie implementate printr-un schimb de mesaje (apelările de
metode).
Există două tipuri de elemente comportamentale: interacţiuni şi stări maşină.
O interacţiune este un set de mesaje schimbat într-un grup de obiecte pentru
atingerea unui anumit obiectiv.
O stare de tranziţie este starea prin care trece un obiect ca răspuns la apelări ale
anumitor metode.
Semantic, interacţiunile şi stările de tranziţie sunt conectate la diverse elemente
structurale, în special clase.

Elemente de grupare

În cazul sistemelor informaţionale de mărime medie sau mare, UML pune la


dispoziţie un mecanism general de organizare a elementelor în grupuri, şi anume pachetul.

Pachet

Fig. 2.8 Simbolul UML pentru pachete

Spre deosebire de componente (care există în momentul rulării), pachetele sunt


doar elemente conceptuale (există doar în timpul dezvoltării), neconcretizându-se obligatoriu
în fişiere. Într-un pachet pot fi introduse elemente structurale, elemente comportamentale şi
chiar alte pachete.

Elemente explicative

Dacă elementele de modelare specifice UML nu fac referire şi la informaţii mai greu de
structurat, ce se concretizează doar în note explicative sau comentarii, în cadrul
reprezentărilor grafice pot fi adăugate elemente pentru adnotări, redate prin simbolul utilizat
în figura 2.9.

Nota explicativa:

Fig. 2.9 Simbolul UML pentru note explicative

6
Relaţii UML

Între elementele UML se pot stabili o serie de relaţii, şi anume: asocieri, dependenţe,
derivări şi realizări.

Asocieri
Asocierile sunt relaţii între două sau mai multe clase, prin care se modelează
interdependenţe între obiectele instanţiate din clasele respective. Un exemplu de asociere
poate fi: „un mijloc fix este în gestiunea unui anumit gestionar”.
O instanţă a unei asocieri poartă numele de legătură, ea descriind relaţia dintre două sau
mai multe obiecte. Un exemplu de legătură poate fi: „Mijlocul fix cu numărul de inventar
331265 este în gestiunea lui Gestionărescu Fix”.
Asocierile dintre clase au câte un rol (o explicaţie) pentru fiecare clasă participantă. Un
rol poate fi privit ca o imagine a unui obiect. Între două clase pot exista mai multe asocieri,
fiecare cu roluri distincte. De exemplu, între clasa „Bon_de_transfer” şi clasa „Gestiune” pot
exista două asocieri, una privind gestiunea în care se transferă şi cea de a doua asociere
privind gestiunea de la care se transferă.
Asocierile au pentru fiecare element pe care îl leagă o cardinalitate (multiplicitate)
corespunzătoare numărului de obiecte ce pot apărea la instanţiere sub forma:
- 1 – unul şi doar un obiect;
- 0..1 – nici unul sau maxim un obiect;
- 0..* - nici unul sau mai multe obiecte;
- * - tot zero sau mai multe obiecte;
- 1..* - unul sau mai multe obiecte;
- 1..n - unul sau maxim n obiecte;
- 0..n sau n – nici unul sau maxim n obiecte;
- nl, n2, n3 - înşiruire de numere, care exprimă numărul de obiecte;
- n - m - număr de obiecte cuprins între n şi m.
În funcţie de numărul de elemente pe care le leagă, asocierile pot fi: binare sau n-are. În
UML, o asociere binară se reprezintă grafic printr-o linie dreaptă ce uneşte cele două
elementele implicate. Când elementele unite sunt actori, cazuri de utilizare sau clase, pe
aceste linii se pot specifica rolurile şi cardinalităţile elementelor.

1 *

Fig. 2.10 Reprezentarea grafică în UML a unei asocieri binare

Asocierile n-are se reprezintă, în UML, cu ajutorul unui romb, de la care pleacă spre
fiecare element implicat în relaţie câte o linie dreaptă, pe care se poate ataşa cardinalitatea şi
rolul specific elementului respectiv.

* *
*

Fig. 2.11 Reprezentarea grafică în UML a unei asocieri n-are

7
Când un element se asociază cu el însuşi se obţine o asociere reflexivă. De exemplu,
acest tip de asociere poate arăta legăturile dintre obiectele aceleiaşi clase.
0..1

Doc_insotire
-Numar : Char
-Data : Date
-Doc_anterior : Doc_insotire -corespunde
+Get_Valoare_fara_TVA() : Decimal
+Get_TVA() : Decimal
+Get_Valoare_cu_TVA() : Decimal 0..1

Fig. 2.12 Reprezentarea grafică în UML a unei asocieri reflexive

Asocierea reflexivă din figura 2.12 arată faptul că unele documente însoţitoare (cum ar fi
avizele de expediţie) pot corespunde altor documente justificative (cum ar fi facturile). Tot
asocieri reflexive s-ar obţine şi la prezentarea asocierilor dintre un angajat şi şeful său
ierarhic, sau la asocierea dintre un document justificativ şi documentul său de stornare.
Când o asociere are caracteristicile unei clase ea este denumită clasă de asociere. De
exemplu, asocierea dintre clasa ce defineşte notele de recepţie şi clasa ce defineşte materialele
dintr-un sistem de gestiune a materiilor prime, poate avea propriile atribute (cantitatea şi
preţul fiecărui material) şi propriile operaţii (calcularea cantităţii rămase de consumat dintr-un
anumit material şi o anumită notă de recepţie necesară într-un sistem ce foloseşte metoda
FIFO, ca metodă de evaluare a stocurilor). Simbolul folosit în UML pentru reprezentarea unei
clase de asociere este cel al unei clase, unite de asocierea respectivă printr-o linie întreruptă.
Clasa de asociere

* *

Fig. 2.13 Reprezentarea grafică în UML a unei clase de asocieri binare

O clasă de asociere poate uni mai mult de două elemente, caz în care ea este denumită
clasă de asociere n-ară.
Clasa de asociere

* *
*

Fig. 2.14 Reprezentarea grafică în UML a unei clase de asocieri n-are

Uneori, asocierile dintre două elemente presupun o anumită ordine a obiectelor


instanţiate. De exemplu, mărfurile dintr-o anumită factură sunt ordonate într-un anumit mod,
în aşa fel încât reproducerea exactă a unei anumite facturi presupune şi persistenţa ordinii
mărfurilor referite. În aceste cazuri se vorbeşte de o asociere ordonată.
Când o clasă este implicată în mai multe asocieri şi nu pot exista instanţe simultane ale
claselor cu care se află în asociere, asocierile se conectează printr-o linie întreruptă, cu
eticheta XOR.

8
Un tip aparte de asociere este agregarea, cu ajutorul căreia o clasă poate fi modelată, ca
fiind parte a unei alte clase. O clasă agregat este o clasă ale cărei obiecte conţin alte obiecte.
De exemplu, o comandă conţine, pe lângă datele specifice acestui tip de tranzacţie, şi obiecte
de tipul produselor.
Agregările se pot clasifica în:
 agregări fixe: au număr fix de componente; de exemplu, un lot de produse poate avea
fix cinci tipuri de produse;
 agregări variabile: au un număr finit, dar variabil de componente; de exemplu, mai
multe produse pot face parte dintr-un lot pregătit pentru livrare, dar numărul acestora
nu este fix;
 agregări recursive: au componente de acelaşi tip; de exemplu, asocierea dintre un
departament şi birourile componente.
În cazul în care părţile componente au aceeaşi durată de viaţă cu a întregului şi se pot
regăsi fizic în cadrul acestuia, avem de-a face cu un caz particular de agregare, numit
compoziţie. În cadrul compoziţiei, clasa compusă nu poate să participe şi la alte agregări, pe
când operaţia clasică de agregare, numită şi agregare partajată, permite participarea unei clase
agregat la oricâte agregări.
Simbolul UML pentru agregare este rombul. În cazul agregărilor partajate acest romb
este gol la mijloc, iar în cazul agregărilor compuse acesta este plin.
-partajeaza

1 *
Fig. 2.15 Reprezentarea grafică în UML a unei agregări partajate

-Contine

1 1..*

Fig. 2.16 Reprezentarea grafică în UML a unei compoziţii

Alt tip de asociere este comunicarea, care indică o asociere între un actor şi un caz de
utilizare, reprezentându-se grafic ca o asociere binară simplă, ce poate avea anumite
cardinalităţi şi anumite roluri.
Asocierea ce reprezintă trecerea unui obiect dintr-o stare într-o altă stare se numeşte
tranziţie. Ea se reprezintă grafic prin adăugarea la linia unei asocieri a unei săgeţi care arată
starea destinaţie.

Fig. 2.17 Reprezentarea grafică în UML a unei tranziţii

Dependenţe
Dependenţa este o relaţie între două elemente prin care schimbările într-un element sursă
pot determina schimbări în elementul destinaţie. O dependenţă leagă elementele fără a fi
necesară o instanţiere, de aceea nu are cardinalităţi. Relaţia de dependenţă este
unidirecţională, un element fiind considerat independent, iar celălalt, dependent. Modificările
asupra elementului independent se vor reflecta şi asupra elementului dependent.
De exemplu, dependenţa apare în cazul relaţiilor dintre două clase între care există relaţii
de încredere, denumite clase prieten (friend), în care o clasă oferă altei clase accesul la
elementele protejate, chiar dacă între ele nu există asociere directă. Simbolul folosit în UML

9
pentru reprezentarea dependenţelor este o linie întreruptă care are la un capăt o săgeată ce
arată elementul dependent.

Fig. 2.18 Reprezentarea grafică în UML a unei dependenţe

Derivări
Derivarea este o relaţie între două sau mai multe clase, prin care se modelează
similitudinile şi diferenţele specifice dintre acestea. Derivarea este capacitatea de a declara un
tip pe baza unor elemente (atribute şi operaţii) ale unui tip declarat anterior. Pornind de la o
clasă, se pot deriva noi clase ce adaugă diferenţe specifice.
Conceptul de derivare este probabil cel mai important concept al abordării orientate-
obiect, după conceptul de clasă. Aşa cum toate limbajele orientate-obiect sprijină conceptul de
clasă, toate aceste limbaje sprijină şi conceptul de derivare. Lipsa posibilităţii de derivare într-
un mediu de programare, ce foloseşte clase şi obiecte, împiedică folosirea în acest caz a
termenului de programare orientată-obiect, vorbindu-se doar de o programare bazată pe
obiecte sau, altfel spus, abstractizare a datelor.
Termenii de specializare, generalizare, moştenire se referă la relaţia de derivare.
Termenul de moştenire este folosit mai mult în legătură cu reutilizarea atributelor şi metodelor
clasei de bază. Prin intermediul acestei relaţii, obiectele unei clase derivate moştenesc atribute
şi metode ale clasei de bază la care se adaugă membrii clasei proprii.
Relaţia de derivare este reprezentată în UML printr-o linie dreaptă care are la un capăt un
triunghi gol, ce arată clasa generală ce este supusă specializării.

Fig. 2.19 Reprezentarea grafică în UML a unei relaţii de derivare

Un tip particular de derivare este extensia. Prin ea, un element (clasă, componentă sau
caz de utilizare) extinde comportamentul unui alt element prin adăugarea unor comportamente
noi. Extensia se reprezintă în UML prin specificarea stereotipului extends pe simbolul unei
derivări.
«extends»

Fig. 2.20 Reprezentarea grafică în UML a unei relaţii de extensie

Termenul de ierarhie de clase desemnează clase între care există relaţii de derivare. Clasa
din care derivă o altă clasă poartă numele de metaclasă. După aceeaşi regulă morfologică, un
model din care derivă alt model poartă numele de metamodel. Clasa derivată dintr-o altă clasă
poartă numele de subclasă.
O clasă poate deriva dintr-o singură clasă, când apare moştenirea simplă, sau din mai
multe clase, vorbind de moştenire multiplă. Nu toate mediile de programare orientate-obiect
au implementată moştenirea multiplă, deoarece este dificil de utilizat şi dezvoltat în timp.
Problemele moştenirii multiple apar când metaclasele au atribute şi/sau operaţii cu acelaşi
nume, iar clasa specializată din acestea trebuie să facă referire numai la una sau la o
combinaţie a acestora. Când o clasă moşteneşte un element de la mai mult de o clasă, se
vorbeşte de generalizare suprapusă (overlapping). Opusul generalizării suprapuse poartă
numele de generalizare disjunctă (disjoint).
În funcţie de capacităţile de derivare, clasele pot fi clase rădăcină (root classes), în
sensul că nu pot avea predecesori, şi clase frunză (leaf classes), indicând faptul că nu pot avea
descendenţi.

10
Atunci când unei clase nu i se mai pot face alte specificaţii de subclase se vorbeşte de
generalizare completă. Generalizarea incompletă apare atunci când o clasă se mai poate
specializa şi în alte subclase.
Avantajele oferite de derivare sunt date de posibilităţile de reutilizare a codului şi
de extensibilitate a sistemului creat. O serie de resurse de bază, puse la punct în anumite
aplicaţii, pot fi uşor refolosite în alte aplicaţii, prin derivări succesive. Timpul de testare
scade, aceste resurse de pornire fiind probabil deja testate. Mai mult, pot fi refolosite resurse
chiar şi fără o înţelegere temeinică a implementării ce se ascunde în spatele lor.
O resursă existentă poate fi extinsă, atât prin versiune, adică prin adăugare de
metode noi, cât şi prin re-specializare, prin derivarea de noi ramuri în cadrul unei ierarhii de
clase. Chiar şi bibliotecile de clase, a căror implementare nu este disponibilă sub formă de
fişiere sursă, pot fi uşor extinse prin derivări (specializări) succesive.
Relaţia de derivare prezintă şi un dezavantaj: astfel de relaţii nu pot să apară pe
parcursul rulării unei aplicaţii.

Realizări
O realizare este o relaţie semantică între două părţi în care una din ele defineşte o
funcţionalitate, iar cealaltă o execută. Relaţii de realizare pot exista între interfeţe şi clasele
sau componentele care le implementează şi între cazuri de utilizare şi colaborările care le
realizează.
Grafic, o realizare se reprezintă cu un simbol obţinut prin combinarea simbolurilor
folosite pentru dependenţe (linia întreruptă) şi derivări (capătul de săgeată sub forma unui
triunghi alb).

Fig. 2.21 Reprezentarea grafică în UML a unei relaţii de realizare

Extensii UML

UML conţine trei mecanisme de extensie pentru ca dezvoltatorii de soluţii


software să nu fie nevoiţi să modifice limbajul când au nevoie de posibilităţi suplimentare de
proiectare: etichete (tag values), restricţii şi stereotipuri.
1) Etichetele asigură o formă de definire a noi proprietăţi unor elemente deja
existente.
2) Restricţiile impun reguli asupra elementelor UML şi a proprietăţilor acestora.
3) Stereotipurile asigură completarea semanticii unor elemente deja existente.
Extensiile UML nu trebuie asociate doar cu anumite tipuri de diagrame UML, ele
fiind valabile pentru întregul limbaj, deci pentru orice diagramă.

Etichete
OMG defineşte etichetele ca fiind o pereche (nume, valoare) ce permite asocierea
unor date unui anumit element dintr-un model. Numele etichetei este numele unei anumite
proprietăţi pe care proiectantul vrea să o adauge elementului, iar valoarea etichetei este
valoarea acelei proprietăţi.
Unele nume de etichete sunt predefinite ca elemente standard. Nume predefinite
de etichete sunt:

11
- documentation, nume folosit pentru un comentariu, o descriere sau o explicaţie a
elementului corespunzător;
- location, pentru a arăta nodul sau componenta de care aparţine elementul;
- semantics, aplicat unei clase sau unei operaţii specifică înţelesul acesteia.
Etichetele pot fi folosite pentru a stoca orice informaţie despre elemente, inclusiv
informaţii necesare în administrarea proiectelor, cum ar fi: autorul elementului, autorul
ultimelor modificări, data creării, data ultimei modificări, versiunea curentă, motivul ultimei
modificări sau stadiul de dezvoltare. Etichetele pot fi folosite şi pentru a adăuga informaţiile
necesare generatoarelor de cod.
Reprezentarea grafică a unei etichete se face prin scrierea sub numele elementului
corespunzător şi între acolade („{}”) a numelui etichetei urmat de semnul egal şi valoarea
acesteia.

Restricţii
Restricţiile extind semantica blocurilor UML, permiţând adăugarea de noi reguli.
Restricţiile pot fi adăugate unui element dintr-o listă, asociate unei relaţii de dependenţă sau
incluse într-un comentariu.
O restricţie este o condiţie semantică reprezentată ca o expresie de tip text. Fiecare
expresie are o limbă implicită de interpretare, ce poate fi o notaţie formală matematică, un
limbaj de programare, un limbaj natural informal sau un sublimbaj din UML (Object
Constraint Language = OCL).
Unele nume de restricţii sunt predefinite, cum ar fi:
• Incomplete, restricţie folosită atunci când o serie de specializări este
incompletă, fiind posibilă adăugarea de noi clase copii.
• New, arată că o instanţă a unui rol este creată la fiecare execuţie a interacţiunii şi
că aceasta instanţă continuă să existe după terminarea execuţiei.
• Xor, se poate aplica unui set de asocieri ce împart aceeaşi conexiune cu o clasă;
specifică faptul; că toate obiectele clasei respective vor avea conexiuni doar de la o asociere.
• Complete, se poate aplica unui simbol de generalizare atunci când au fost
specificate toate clasele copil.

Stereotipuri
Stereotipurile constituie principalul mecanism de extensie al UML. Dacă se
doreşte folosirea unui element de modelare ce nu este specific, ci dar similar unui element
UML, acesta se tratează ca un stereotip. Acelaşi mecanism se foloseşte şi când se doreşte nu
un element nou, ci doar o informaţie suplimentară unui element. Această informaţie
suplimentară poate fi chiar rolul pe care îl are respectivul obiect în cadrul sistemului văzut pe
ansamblu.
Stereotipurile pot fi folosite pentru a evidenţia diferite tipuri de clase
(<<metaclass>>, <<interface>>) sau relaţii (<<become>>, << history>>).
Colecţiile de stereotipuri, restricţii şi etichete pot fi refolosite de la un proiect la
altul, creându-se aşa numitele profiluri.
Instrumentele CASE folosite de dezvoltatori pentru modelarea cu UML a
sistemelor pot conţine stereotipuri predefinite, dar utilizatorii acestora îşi pot defini propriile
stereotipuri.

12
Diagrame UML

În UML putem apela la următoarele tipuri de diagrame pentru modelarea sistemului:


 diagramele cazurilor de utilizare arată funcţiile de prelucrare la care au acces
diferitele categorii de utilizatori (actori);
 diagramele de clase conţin seturi de clase (inclusiv interfeţe) şi relaţiile dintre acestea,
prezentând o parte a dimensiunii statice a sistemului;
 diagramele de obiecte conţin mulţimi de obiecte şi relaţiile acestora;
 diagramele stărilor de tranziţie arată o serie de stări, tranziţii, evenimente şi activităţi
ale obiectelor;
 diagramele de activitate arată succesiunea de activităţi specifică unei functionalităţi;
 diagramele de secvenţă sunt diagrame de interacţiune ce evidenţiază ordinea realizării
prelucrărilor (transmiterii mesajelor);
 diagramele de comunicare sunt diagrame de interacţiune ce evidenţiază organizarea
structurală a obiectelor ce trimit şi primesc mesaje;
 diagramele de componente arată organizarea şi dependenţa între un set de
componente;
 diagramele de implementare arată configuraţia la rulare a nodurilor şi a
componentelor ce există în ele.
Aceste diagrame UML pot fi împărţite în două mari categorii: diagrame de structură şi
diagrame de comportament.
Diagramele de structură arată structura statică a elementelor unui sistem, prin
prezentarea acestora într-o specificaţie independentă de factorul timp. Elementele dintr-o
diagramă de structură reprezintă conceptele semnificative ale unei aplicaţii şi pot include
concepte abstracte, ale lumii reale sau de implementare. Diagramele de structură nu arată
detaliile comportamentului obiectelor, căci acestea sunt ilustrate în diagramele de
comportament. Diagramele de comportament prezintă dinamica unui sistem prin descrierea
seriilor de schimbări posibile ale acestuia în decursul timpului.
Această taxonomie asigură o organizare logică a tipurilor de diagrame, dar nu înlătură
mixarea lor, cum ar fi combinarea unor elemente structurale cu altele comportamentale, prin
prezentarea unor stări de tranziţie într-o structură internă. În consecinţă, graniţele dintre
diferite tipuri de diagrame nu sunt impuse în mod strict.
Diagramă

Diagramă de Diagramă de
structură comportament

Diagramă Diagramă de Diagramă Diagramă de Diagramă de Diagramă a


de clase componente de obiecte activitate cazuri de stărilor de
utilizare tranziţie

Diagramă Diagramă de Diagramă Diagramă de


de structură amplasare de pachete interacţiune
compozită

Diagramă Diagramă de
de secvenţă comunicare

Fig. 2.22 Tipurile de diagramă de structură şi de comportament

13
Figura 2.22 reflectă împărţirea tipurilor de diagrame în cele două categorii, aşa cum este
ea prezentată chiar în cadrul standardului UML.
Folosirea diagramelor UML ca modalitate de reprezentare a unui sistem informaţional
economic, nu exclude folosirea unor descrieri narative ale sistemului, în toate etapele de
dezvoltare a acestuia.

14