Documente Academic
Documente Profesional
Documente Cultură
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.
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
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
3.2
Diagramele de colaborare
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:
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.
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