Sunteți pe pagina 1din 11

Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea de

modele i specificaii pentru software. Limbajul a fost creat de ctre consoriul Object
Management Group (OMG) care a mai produs printre altele i limbajul de programare CORBA.
UML a fost la baz dezvoltat pentru reprezentarea complexitii programelor orientate pe obiect,
al cror fundament este structurarea programelor pe clase, i instanele acestora (numite i
obiecte). Cu toate acestea, datorit eficienei i claritii n reprezentarea unor elemente abstracte,
UML este utilizat dincolo de domeniul IT. Aa se face c exist aplica ii ale UML-ului pentru
management de proiecte, pentru business Process Design etc.
Prima versiune de UML, UML 1.0, a aprut n anul 1990 ca reac ie a numeroaselor
limbaje de modelare propuse pe pia. UML i are ca fondatori pe Grady Booch, Ivar Jacobson i
James Rumbaugh, aa numiii cei trei Amigos. Ei au dezvoltat limbajul bazndu-se inclusiv pe
limbaje de modelare deja existente, ns incomplete ca gam de func ionalit i. Printre acestea se
numr i OOSE, RDD, OMT, OBA, OODA, SOMA, MOSES i OPEN/OML.
Dezvoltarea versiunii 2 a UML a nceput n anul 1999 atunci cnd OMG a publicat un
request for information referitor la UML 2. De atunci, UML s-a aflat ntr-un continuu ciclu de
mbuntire, astzi ajungnd la varianta UML 2.4.1 (publicat n august 2011).
Principalele instrumente de lucru cu limbajul UML sunt Rational Rose i Enterprise Architect.
Rational Rose este un instrument care ofer suport pentru dou elemente eseniale n
abordarea modern a unui proiect software: dezvoltare bazat pe componente i controlul
dezvoltrii iterative. Dei aceste elemente sunt conceptual independente, folosirea lor mpreun
este natural i benefic.
Enterprise Architect reprezint un set de instrumente UML pentru profesionitii care se
ocupa cu dezvoltarea, testarea produselor soft. Enterprise Architect ntrunete n sine puterea
limbajului UML 2.1, avnd o interfa intuitiv i simpl. Proprietile principale a instrumentului
sunt: crearea documentaiei, creare i reverse engineering, vizualizarea aplicaiilor, suport pentru
sistemul de modelare Model Driven Architecture.
META
Descriere formala a limbajului UML se bazeaza pe careva structura ierarhica comuna a
reprezentarilor
de model care consta din patru nivele:
Meta-metamodelul
Metamodelul
Modelul
Obiectele utilizatorului
Nivelul de meta-metamodel creaza o baza initiala pentru toate reprezentari de metamodele.
Destinatia principala a acestui nivel consta n definitia limbajului pentru specificarea
metamodelului.
Meta-metamodelul defineste modelul limbajului UML la cel mai nalt nivel de abstractizare si
cea mai compacta descriere a lui.
Din alta parte, meta-metamodelul poate specifica cteva metamodele ce permite atingerea
flexibilitatii potentiale de
includere a notiunilor adaugatoare. Ca exemple de notatii ale acestui nivel pot fi meta-clasa,
meta-atribut, meta-operatie.

Semantica meta-metamodelului nu intra n descrierea limbajului UML. Aceasta face limbajul


UML mai simplu pentru studiere,
fiindca nu cere cunoasterea teoriei limbajelor formale si a logicii formale.
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, fiindca semantica lui ale notiunilor de baza
este mai dezvoltata.
Toate notiunile de baza ale limbajului UML sunt notiunile nivelului de metamodel. Exemple de
aceste notiuni sunt clasa,
atributul, operatia, componenta, asocierea si multe alte.
Modelul n contextul limbajului UML este exemplarul metamodelului n sensul ca fiecare model
concret a unui
sistem trebuie sa utilizeze numai notiunile lui metamodel concretizndu-le cu privire la situatia
data.
Acest nivel este pentru descrierea informatiei despre un domeniu concret (de obiecte).
Ca exemple a acestui nivel pot fi numele cmpurilor ale bazei de date proiectate,
de exemplu, numele si prenumele angajatului, vrsta, postul, adresa, numarul de telefon.
Totodata notiunile date sunt utilizate numai ca nume ale atributelor informationale
corespunzatoare.

1. Diagrama Use-Case
O diagram Use-Case este folosit n general pentru a indica sau caracteriza
funcionalitile i comportamentul sistemului ce interacioneaz cu unul sau mai muli actori.
Un actor poate fi un utilizator sau orice sistem ce poate s interacioneze cu sistemul modelat.
Att timp ce actorii reprezint utilizatorii, ei ajut la construirea unei imagini clare a ceea
ce se ateapt a se ntmpla n sistem. Cazurile de utilizare sunt construite pe baza nevoilor pe
care le au actorii (utilizatorii). Aceasta asigura faptul c sistemul va produce ceea ce s-a dorit.
Elementele diagramei Use Case:
Element
Caz utilizare

Actorul

Interfaa

Descriere
Notaie
Se
utilizeaz
pentru
specificarea
particularitilor comune a unui sistem. Scopul
elementului const n determinarea aspectului
final sau a unui fragment de comportare a unei
entiti fr desfurarea structurii interne a
entitii date.
An actor este un utilizator al sistemului , dar
poate fi i un alt sistem informatic care
interacioneaz cu sistemul analizat.
Specific parametrii modelului care sunt
vizibili din exteriorul sistemului fr indicarea
structurii interne a lor. La use-case, interfaa

INume

definete o totalitate de operaii ce asigura


serviciile necesare pentru un anumit actor.
Tipuri de relaii n diagrama Use Case:
Relaia de generalizare este atunci cnd un actor sau un use case poate fi asimilat
unei clase de actori, respectiv de use case-uri. O generalizare intre dou cazuri
de utilizare indic faptul c cazul de utilizare poate mprti comportamentul
definit n unul sau mai multe cazuri de utilizare. O generalizare ntre actori arat
c un actor motenete structura i comportamentul ale unui actor sau mai muli
actori.
Relaia de tip extensie (i implicit use case-urile de extensie) se folosesc atunci
cnd se modeleaz un comportament opional sau excepional, care nu
condiioneaz finalitatea use case-ului de baz.
Relaia de tip includere: se folosete atunci cnd use case-ul inclus nu este o
parte esenial a fluxului din use case-ul de baz sau este un comportament care
se repet n mai multe use case-uri.
Asocierea este utilizat pentru a indica legtura dintre un Actor i un Use Case, n
sensul c acel actor particip ntr-un fel oarecare n acel Use Case.

2. Diagramele de interaciune
Diagramele de interaciune arat cum conlucreaz obiectele prin transmiterea de mesaje
pentru a satisface cerinele sistemului. Diagrama de interaciuni ilustreaz cum interac ioneaz
obiectele ntre ele cu ajutorul mesajelor. Este folosit pentru a modela comportamentul unei
mulimi de obiecte dintr-un anumit context, care interacioneaz n vederea ndeplinirii unui
anumit scop.
Scop diagramei de interaciune: specific modul n care se realizeaz o operaie sau un
caz de utilizare.
Diagrama de interaciuni poate conine:
obiecte, actori clase;
relaii;
mesaje.
Obiectele:
pot fi lucruri concrete sau prototipuri;
ntre ele se pot stabili conexiuni semantice (legturi);
comunic ntre ele prin schimburi de mesaje. Mesaj:
specific o comunicare ntre obiecte;
i este asociat o aciune care poate avea ca efect schimbarea strii actuale a
obiectului;
forma general a unui mesaj: [condiia gard] aciune (lista parametrilor).
Tipuri de aciuni n UML

call: invoc o operaie a unui obiect.


return: returneaz o valoare apelantului.
send: trimite un semnal.
create: creeaz un obiect.
destroy: distruge un obiect.

Exist dou tipuri de diagrame de interaciune:


diagrama de colaborare
diagrama de secven.
ntre cele dou tipuri de diagrame nu exist diferene majore: diagramele de secven scot
n eviden ordinea n timp a mesajelor, iar diagramele de colaborare scot n eviden legturile
dintre obiecte.
3.1 Diagramele de secven
Diagrama de secven pune accentul pe aspectul temporal (ordonarea n timp a mesajelor).
Notaie grafic:
1. dimensiunea orizontal (axa ox): obiecte;
2. dimensiunea vertical (axa oy):
linia vieii obiectelor (grafic: linie punctat);
perioada de activare n care un obiect preia controlul execu iei (grafic:
dreptunghi pe linia vieii);
mesaje ordonate n timp (grafic: sgei).
Comunicare sincron. Controlul execuiei trece de la A la B i revine la A dup ce B i termin
execuia. Exemplu: apel de funcie.
Comunicare asincron. A trimite un semnal dup care i continu execu ia mai departe.
Exemplu: aruncarea unei excepii.
Return. ntoarcere dintr-o funcie (procedur). n cazul n care este omis se consider implicit c
revenirea se face la sfritul activrii.

3.2

Diagramele de colaborare

Particularitatea principal const n reprezentarea grafic nu numai a interac iunii dintre


obiecte ci i relaiile structurale dintre obiecte. Spre deosebire de diagrama de secven n
diagrama de colaborare se reprezint relaiile ntre obiecte care au o oarecare semnificaie n
timpul colaborrii. n diagrama de colaborare nu se indic timpul interaciunii obiectelor. ns n

diagrama de colaborare exist posibilitatea de a numerota mesajele (interaciunile), ceea ce ne


permite de a vedea schimbul de mesaje n timp.
Ca i n diagrama de secven, principalul element este obiectul (instana unei clase).
Multiobiect
Multiobiect reprezint o mulime de obiecte la una din terminaiile asocierii. n diagrama de
colaborare entitatea multiobiect se utilizeaz pentru a reprezenta opera iile i semnalele care sunt
adresate ctre multitudini sau totaliti de obiecte. Multiobiectul se reprezint grafic printr-un
dreptunghi n alt dreptunghi.
*Relaia dintre multiobiect i obiectul care face parte din el se numete compoziia.
Obiecte active i pasive
n UML obiectele se mpart n active i pasive.
Obiectele pasive folosesc numai datele care sunt transmise i nu pot avea activitate de control.
ns ele pot transmite semnale pe parcursul timpului de realizare a cererii.
Obiect activ are un flux de control propriu i poate iniializa activitate de control.
Obiect compus
Obiectul compus se mai numete obiect container. El este destinat pentru reprezentarea
obiectului care are structur proprie i flux intern de control. Obiectul compus este exemplarul
unei clase compuse care este legat cu prile sale componente prin rela ia de agregare sau
compoziie. Obiectul compus se reprezint prin dreptunghi din 2 componente: numele obiectului
i numele obiectelor interne.
Stereotipuri de legturi
association asociere, stereotip implicit
parameter parametrul metodei. Obiectul crui i s-a transmis stereotipul parameter
poate fi doar parametru al unei metode
local variabil local a metodei. Nivelul de vizibilitate a variabilei locale e limitat
pn la obiectul vecin.
global variabil global a metodei. Vizibil pentru toate elementele diagramei de
colaborare.
self relaie recursiv.
Elementul colaborare
Noiunea de colaborare nseamn o mulime de obiecte care interacioneaz n context
comun. Scopul colaborrii const n specificarea particularitilor realizrii celor mai
semnificative operaii n sistem.
Niveluri
Diagrama de colaborare poate fi reprezentat n 2 nivele:
1. Nivel de specificare se reprezint rolul clasificatoarelor i rolurile asocierilor n
colaborarea dat

2. Nivel de exemplu diagrama reprezint obiectele i legturile dintre ele cu


mesaje
Diagrama de colaborare de nivel de specificare reprezint rolurile elementelor (nivel de clase) ce
particip la colaborare. La nivel de exemple sunt reprezentate doar obiectele care au legtur cu
realizarea operaiilor.

3. Diagrama de clas
Diagrama de clas este folosit pentru reprezentarea structurii statice a unui model de
sistem n terminologia POO. Diagrama de clas reflect diferite legturi ntre entit i i descrie
structura lor intern.
Poate conine
Pachet
Clase/Interfee
Obiecte
Relaii
a. Asociere relaia semantic ntre dou entiti
b. Agregare caz specific a asocierii; relaia dintre partea ntreag i partea
component
c. Compoziia caz specific a agregrii; relaia dintre partea ntreag i
partea component i prile date nu pot exista independent
d. Generalizare relaia dintre parinte i copil
e. Dependen se utilizeaz n situaia cnd un element al modelului poate
s duc la schimbarea altui element.
f. Realizare relaia dintre dou entiti una dintre care garanteaz
mplinirea relaiei
1) Clasa definete o totalitate de obiecte care au aceeai structur, comportament i rela ii cu alte
clase. Elementele unei clase:
Nume: identific o clas
Atribute: proprieti ale clasei
Metode: implementarea unui serviciu care poate fi cerut oricrei instane a clasei.
2) Pachetul mecanism universal de grupare a pachetelor n grup.
3) Interfaa o clas abstract care poate conine careva metode.
4) Relaii
Sunt 4 tipuri de relaii n diagrama claselor:
Dependena relaia dintre 2 entiti (clase), una independent (cu sgeata spre
ea) i cealalt dependent.
Stereotipuri:

a) access - servete ca indicator de accesibilitate pentru atributele i


operaiile clasei surs pentru clasa client
b) bind - clasa client (dependent) poate utiliza abloane pentru
urmtoarea parametrizare a sa
c) derive - atributele clasei client pot fi calculate dup atributele clasei
surs
d) import - atribute i metode publice ale clase surs pot fi considerate ca
atribute i metode ale clasei client
e) refine - indic c clasa client servete ca precizie pentru clasa surs (ca
caracter istoric)
Asocierea legtur semantic dintre 2 clase. Rol = nivel acces (+, -, #) + nume
rol. Triunghi haurat indic cine are primul acces la obiect. Multitudini (0, 0..1, 1,
0..*, 1..*, *, 7, 2..5) standard e 1.
Generalizarea relaie semantic. Linie nentrerupt cu triunghi nehaurat.

Restriciile ntre paranteze figurate:


a) {complete} n diagram sunt reprezentate toate clasele descendente, iar
altele nu mai pot exista
b) {incomplete} nu sunt reprezentate toate clasele descendente
c) {disjoin} clasele descendente nu pot conine obiecte care concomitent
sunt exemplare a 2 sau mai multor clase
d) {overlapping} motenire multipl
Realizarea clasa realizeaz interfaa.

4. Diagramele de comportament
Diagramele de comportament evideniaz ce trebuie sa se ntmple n sistemul modelat.
Ele ilustreaz comportamentul sistemului i sunt utilizate n general pentru a descrie
funcionalitatea sa.
Exist dou tipuri de diagrame de comportament:
diagrama de stri
diagrama de activiti
5.1 Diagrama de stri
Pentru modelarea comportamentului la nivel logic n UML pot fi folosite urmtoarele
diagrame:
Stare
Activiti
Secven
Colaborare
Spre deosebire de alte diagrame, diagrama de stare descrie procesul de modificare a strilor
pentru o anumit clas (pentru obiectul, exemplarul unei clase), cu alte cuvinte reprezint

procesul de modificare a strilor a unui anumit obiect. Schimbarea strii obiectului poate fi
provocat de alte obiecte din exterior sau din interior. Diagrama dat se utilizeaz pentru
descrierea consecutivitii de stri posibile i treceri care mpreun caracterizeaz
comportamentul obiectului pe perioada ciclului su de via.
Automat
Automatul n UML reprezint o formalitate pentru modelarea comportamentului
modelului a unui sistem ntreg. Automatul este un pachet n care putem defini o mul ime de
definiii care sunt necesare pentru a reprezenta comportamentul entitii modelate.
Automatul diagram de stare.
Starea
Noiune de baz care intr n formalismul automatul sunt strile i tranziiile (trecere).
Diferena principal dintre stare i tranziie const n:
Durata aflrii sistemului n stare depete cu mult timpul care este destinat
trecerii. Se presupune c timpul tranziiei este 0 i se trece dintr-o stare n alta
momentan
n limbajul UML sub-stare se subnelege o meta-clas abstract care se utilizeaz pentru
modelarea situaiilor concrete. Pe parcursul cruia sunt prezente careva aciuni, din cadrul clasei
ct i n afar clasei. Starea poate fi n form de valori concrete, a atributului sau a obiectului
clasei, n cazul acestuia modificarea a unor valori va duce spre modificarea strii obiectului. E de
menionat c nu fiecare atribut a clasei poate s caracterizeze starea obiectului. Starea n UML se
reprezint grafic n form de dreptunghi cu colurile rotunjite.
n afar de nume starea poate avea i aciuni interne.
Numele strii
Numele strii nu este altceva dect un text care dezvluie sensul strii date de regul
numele se scrie cu majuscul, verbul la timpul prezent sau participiu. n unele cazuri numele
strii poate lipsi n acest caz starea este anonim.
n diagrama de stri putem utiliza i pseudo stri. Pseudo stri sunt de 2 tipuri:
1. Pseudo stare iniial.
2. Pseudo stare final.
Ambele sunt cazuri particulare a ale strii care nu conin nici o aciune intern. Pseudo stare
iniial se utilizeaz pentru a ne reprezenta momentul de la care ncepe modificarea strilor
obiectului. Pseudo starea final ne reprezint sfritul de reprezentare a strii sau sfr itul
ciclului de via a obiectului.
n diagrama de stare poate fi doar o singur pseudo stare iniial i din ea iese doar o singur
tranziie. Iar pseudo stri finale pot fi 1,2 i mai multe n dependen de caz i n ea doar se intr.
n cazul cnd avem mai multe pseudo stri finale este obligatoriu de a le diferenia prin atribuirea
diferitor nume.
Tranziia
Trecerea dintr-o stare n alta.

Tranziia reprezint o relaie dintre 2 stri consecutive ceea ce ne indic trecerea de la o stare la
alta. Ea poate fi de 2 tipuri:
1. Trigher
2. Netrigher
Dac trecerea nu are suplimentar careva aliniat de text (de regul eveniment) atunci astfel de
tranziie se numete netrigher, n rest trigher.
Signatura_evenimentului[condiia_gard]/aciunea
Signatura_evenimentului specificaia unui fapt
Condiia_gard - se verific dac este true sau false
Aciunea are loc numai cnd se executa tranziia
Starea compus
Starea compus - este starea compus care este alctuit din 2 sau mai multe stri depuse.
Strile depuse vor fi sub-stri pentru starea iniial. Relaia dintre sub-stri i starea iniial va fi
compoziia.
Substri disjuncte
Substri disjuncte se utilizeaz pentru modelarea comportamentul obiectului n timpul
cruia obiectul se poate afla doar ntr-o singur sub-stare.
Substare compus cu stri concurente.
Substri concurente pot specifica 2 sau mai multe subautomate care pot executa n
paralel. Fiecare subautomat are regiunea sa n starea compus. Subautomatul poate fi att stare
compus cu substri depuse ct i starea compus cu stri disjuncte.
5.2 Diagrama de activiti
Pentru modelarea proceselor de executare a operaiilor n limbajul UML se utilizeaz
diagrama de activiti. Diagrama de activiti poate fi numit ca un caz particular diagrama de
stri (are aceleai tipuri de activiti i elemente). Fiecare stare de activitate corespunde unei
operaii elementare i ca i n cazul diagramei de stri trece n diagrama de activitate dup
executarea diagramei de stri.
Sensul principal al acestei diagrame const n vizualizarea particularitilor , operaiilor al
unor clase pentru a reprezenta algoritmul de execuie. Diagrama de activitate - este un caz
particular a strii ns nu poate avea tranziii interne. Grafic se reprezint printr-un dreptunghi
unde are prin pri 2 bucle.
Uneori este necesar de a meniona c starea de activitate este o stare compus.
Diagrama de tranziie - n comparaie cu diagrama de stri toate tranziiile sunt netrigher.
Pseudostri
ntr-o diagram de stare poate fi doar o intrare/ieire.
n diagrama de activiti este o pseudo-stare iniial i o pseudo-stare final.
Fork i Join

Cel mai mare neajuns al schemelor bloc const n aceea c nu putem reprezenta stri
paralele. n UML exist elemente speciale pentru reprezentarea calculelor paralele, acest simbol
se reprezint prin linie dreapt, vertical sau orizontal, analogic notaii unei tranzi ii n
formalismul reelelor Petre. Sunt 2 entiti fork i join.
1. Fork divizarea n mai multe fluxuri paralele, deci are 1 intrare i 2 sau mai multe
ieiri.
2. Join unirea fluxurilor paralele, mai multe intrri i 1 ieire.
Partiia
Diagrama de activiti poate fi folosit nu numai pentru specificarea algoritmilor de
calcul
sau a fluxului de control a sistemelor de programare, dar i n modelarea business proceselor.
Activitatea oricrei companii reprezint o totalitate de ac iuni independente care sunt ndreptate
spre un anumit rezultat. Modelarea business proceselor la se utilizeaz pentru reprezentarea
subdivizrii. Subdivizrile sunt responsabile de careva aciuni iar business procesele reprezint
trecerea de la o subdiviziune la alta. Pentru modelarea aa tipuri de particularit i n limbajul
UML se utilizeaz partiiile. Partiiile sunt divizate prin linii verticale nentrerupte. 2(dou) linii
verticale reprezint partiia sau subdiviziunea. Linia partiiilor pot fi ntretiate doar de tranziie.
Obiectul
Obiectul n afar de nume poate conine i careva caracteristici (se scriu dup numele
obiectului n paranteze ptrate []). ntre obiect i oriicare element dintre diagram poate fi
utilizat relaia de dependen (linie nentrerupt cu sgeat). Obiectele pot fi plasate ct

5. Diagrama de componente
Diagrama de componente permite determinarea arhitecturii sistemului elaborat
prin determinarea dependenilor ntre componente care pot fi fiiere text, fiiere cu cod
surs,
biblioteci, fiiere dinamice, etc. n majoritatea cazurilor componenta corespunde unui
anumit fiier. Diagrama de componente se utilizeaz pentru urmtoarele scopuri:
1. Vizualizarea structurii comune a codului surs a careva aplicaii.
2. Specificarea variabilei executabile a careva aplicaii.
3. Reutilizarea unor fragmente din cod surs.
4. Reprezentarea conceptual i fizic a sistemelor de baze de date.
Elementele principale a diagramei de componente sunt:
1. Componenta
2. Interfaa (entiti)
3. Dependena (relaiile)
Componenta
Pentru reprezentarea entitilor fizice n limbajul UML se utilizeaz componenta, ea
poate realiza un set de interfee i desemneaz elementele reprezentrii fizice a unui
model.

n diagrama de componente sunt specificate 3 feluri de componente:


1. Componente de regrupare - care specific executarea de ctre sistem a fuciilor
sale, aa componente pot fi: biblioteci dinamice (*.dll), web pagini (html, xml,
php), fiierele help (*.hlp).
2. Produse de lucru pentru limbajul c++ aceste sunt fiierele cu extensia *.h i
*.cpp.
3. Componente de executare aceste elemente n unele cazuri mai sunt numite
artefacte (n aa fel se subliniaz coninutul lor informaional).
Un alt mod de specificare a tipurilor de componente este indicarea stereotipurilor
componentei care de regul este plasat deasupra numelui.
Stereotipuri:
1. Library se refer la primul tip de componente (de regrupare) i de obicei indic
sau reprezint bibliotecile dinamice sau statice.
2. Table se refer la primul tip de componente (de regrupare) care reprezint
tabele bazei de date.
3. File se refer la al doilea tip de componente care de regul reprezint fi ierele
cu textul iniial a programului.
4. Document - se refer la al doilea tip de componente produs de lucru i reprezint
un document.
5. Executable - se refer la al treilea tip de componente.
Interfaa element realizat de component
Dependena - este considerat relaia principal. Modificarea unei component a modelului
va influena la schimbarea altei component.

6. Diagrama de amplasare
Diagrama de amplasare se utilizeaz pentru reprezentarea elementelor reale n program.
Pentru produsele program rulate local nu este nevoie de a realiza diagrama de amplasare.
Se utilizeaz n urmtoarele scopuri:
1. Definirea componentelor sistemului
2. Reprezentarea legturilor dintre toate nodurile sistemei
3. Posibilitatea reconfigurrii topologiei sistemului
n model poate exista doar o singur diagram de amplasare.
Elementele de baz a diagramei de amplasare sunt:
Nodul (procesor sau dispozitiv) element fizic a sistemului care are o anumit
resurs de calcul (elementul poate primi informaia, stoca, prelucra i a o
transmite)
Relaia de asociere
Adugtor: interfaa, componenta, relaia de dependen i de realizare