Universitatea de Vest Timisoara

Facultatea de Economie si de Administrarea a Afacerilor

Contabilitate si Sisteme Integrate in Corporatii

Analiza obiectuala a sistemelor

informationale
( aplicatie UML )

2011

1
Cuprins :

1. The Unified Modeling Language (UML) ……………..…………………pg.2

2. Use-case Diagram …………………………………..…………………

pg.5
3. Class Diagram ……………………………………….….….…………….pg. 8
4. Action diagram …………………………………………….….………… pg. 12
5. Collaboration diagram ……………………………………..…………….pg. 14
6. Sequence Diagram ……………………………………….….………...…pg. 17
7. Component and Deployment Diagrams ………………………………...pg. 18
8. Bibliografie ………………………………………………………………..pg. 23

The Unified Modeling Language (UML)

La crearea unui produs software exista patru faze importante dictate de ingineria
programarii si anume: analiza (analiza cerintelor clientului), proiectarea (descompunerea in

2
module cat mai mici a produsului pentru usurinta implementarii), implementarea (scrierea
efectiva a codului) si testarea.
In cadrul lucrului la un proiect software sunt implicate mai multe persone, fiecare are
atribuţii complementare celorlalţi. Se pot distinge mai multe specialitati:
utilizatori - exploatatorul softului;
şefi de proiect - totdeauna trebuie să existe cineva cu această funcţie;
analişti de sistem - execută modelul informatic al aplicaţiei;
proiectanţi de sistem - execută arhitectura programului aplicaţiei;
programatori - execută modulele;
ingineri de test - verifică ceea ce s-a creat.
Activitatea în echipă este puternic interactivă, comunicarea dintre membrii personalului
cu specialitati diferite facandu-se de obicei prin intermediul formularelor si rapoartelor, care de
obicei devin greu de urmarit din pricina formatarii sau a lipsei de organizare a acestora sau chiar a
omiterii anumitor detalii despre o anumita componenta (modul).
In cadrul fazei de proiectare se construieste de obicei un modul al proiectului la care se
lucreaza. Modelarea este o parte esentiala a unui proiect software, el jucând un rol analog cu
proiectul architectural al unei cladiri de mari dimensiuni. Folosind un model ce-i responsabili
pentru succesul sau esecul unui proiect se pot asigura inca dinainte de inceperea scrierii codului
ca :
• functionalitatea proiectului va fi corecta si completa
• toate necesitatile utilizatorului final vor fi satisfacute
• designul programului va satisface cerintele de scalabilitate, robustete, extendabilitate etc.
In cadrul operatiunii de modelare se pleaca de la premisa ca sistemele software sunt
complexe, de aceea avem nevoie de o multitudine de viziuni simple ale acestora asfel incat in
final sa stapanim complexitatea.
Principalele astfel de viziuni sau vederi sunt:
• Use-case view
• Logical view
• Component view
• Concurrency view
• Deployment view
Limbajul UML este o tehnica folosita pentru descrierea specificarea si documentarea
functiilor unei aplicatii in timpul fazei de design.
UML este produsul a multi ani de munca a mai multor companii cu renume in lumea IT
dintre care amintim Sun Micro Systems , Oracle Corporation, Hewlett-Packard Company, IBM
Corporation, SAP sub patronajul si sponsorizarea concernului OMG (Object Management Group
fondat in 1989).
UML este un limbaj grafic creat pentru vizualizarea, specificarea, construirea si
documentarea sistemelor software incluzând atat structura cât şi designul acestora ce poate fi
aplicat si in alte domenii cum ar fi afaceri sau alte sisteme non-software. Chiar daca UML nu
poate garanta succesul unui proiect, el constituie o unealta foarte importanta reprezentand de fapt
o colectie de practici ingineresti care s-au dovedit de succes in modelarea de sisteme mari si
complexe.

Unul din principalele scopuri ale dezvoltatorilor limbajului UML a fost acela de a crea un
set de notatii semantice care sa se adreseze tuturor tipurilor de proiecte arhitecturale complexe
indiferent de domeniu (industrial, software, marketing, constructii etc.).

3
 UML ofera un model standard de a scrie documentatie de sistem, functii de sistem
precum si alte lucruri concrete cum ar fi declaratii intr-un anumit limbaj de programare, scheme
ale bazelor de date si componente software reutilizabile.
Unified Modelling Language (UML) este un limbaj de modelare si nu o metoda sau un
proces. UML are notatii specifice si reguli gramaticale bine precizate pentru construirea
modelelor software.
Exista o bogata colectie de elemente notationale grafice suportate de UML. Exista o serie
de elemente care descriu clase, componente, noduri, activititati, work flow, obiecte, stari dar
exista si elemente grafice care ajuta la modelarea relatiilor intre elementele amintite.
UML suporta notatii pentru extinderea puterii limbajului de modelare (referirea se face
aici la elementele de tip stereotype si constraints), asigurand avantaje semnificante ingineriei
software ajutand la construirea de modele rigurase, usor de urmarit si intretinut, care sa suporte
intregul ciclu de dezvoltare software.
Modelele si diagramele create au o importanta influenta asura felului in care o anumita
problema este abordata si a felului in care o anumita solutie prinde forma. Prin abstractizare
atentia se concentreaza asupra detaliilor semnificante ignorandu-le pe celelalte. Aceasta este
cauza pentru care:
• fiecare sistem complex este abordat printr-un set de vederi diferite ale unui model. (o
singura vedere nu este suficienta)
• fiecare model poate fi reprezentat cu un grad diferit de fidelitate
• cele mai bune modele sunt cele inspirate din realitate
Este necesara constructia unui model pentru sistemele complexe deoarece mintea umana
nu poate acoperi toate detaliile unui astfel de sistem. Cu cat complexitatea unui sistem creste cu
atat creste si importanta folosirii unei bune tehnici de modelare si implicit a unui limbaj riguros
de modelare cum este UML.
UML, un limbaj de modelare vizual nu a fost creat si nu este in masura sa inlocuiasca un
limbaj de programare insa cu ajutorul limbajului UML se poate modela orice tip de aplicatie care
ruleaza pe orice combinatie de hardware, sistem de operare sau tip de retea. Flexibilitatea lui
permite modelarea aplicatiilor distribuite ce folosesc orice tip de middleware de pe piata, iar
datorita faptului ca obiectele si clasele sunt definite drept concepte fundamentale un model
construit in UML va putea fi relativ usor de implementat intr-o serie de limbaje de tip OOP (C++,
Java, C#). Trebuie precizat insa ca limbajul UML se poate folosi si pentru a modela aplicatii non-
OOP in limbaje precum Cobol, Fortran, sau Visual Basic .
Designul software nu este un simplu proces automat de transformare a unei specificatii in
alta. El implica si luarea unor decizii complexe care se vor repercuta asupra produsului final.
Uneltele pentru design, cele care ajuta designerii in luarea deciziilor sunt un mijloc important de a
creste productivitatea si calitatea designurilor software rezultate.
Astfel au aparut uneletele CASE (Computer Aided Software Engineering), care se gasesc
in numar foarte mare si au grade diferite de utilizabilitate. Din ele se pot distinge: Rational Rose,
ArgoUml, Poseidon (Gentleware).
Motive pentru care ArgoUml (aparut in1998) se distinge din multitudinea de unelte Case:
• ofera mijloacele necesare pt cresterea productivitatii realizarii softurilor de tip
OOP
• foloseste doar standarde deschise (open standards) ceea ce inseamna in primul
rand posibilitatea unei colaborari cu alte aplicatii care folosesc aceste standarde. Printre
aceste standarde folosite se afla: in primul rand UML-ul, apoi XML Metadata
Interchange (XMI), Scalable Vector Graphics (SVG), Object Constraint Language
(OCL).

4
 • implementeaza toate specificatiile limbajului UML 1.3., fiind singura unealta
care implementeaza meta-modelul UML exact asa cum a fost specificat
• este o aplicatie 100% Java deci se bucura de tote calitatile unui produs Java
• este open-source (in plina dezvoltare)

In plus ArgoUml a fost inspirat si a tinut cont de cele trei teorii din psihologia cognitiva:
• reflection-in-action: designerii unor sisteme complexe nu concep un design in
totalitatea sa. De aceea ei trebuie sa construiasca un design partial, sa-l evalueze, eventual
sa-l modifice pana cand vor fi pregatiti sa extinda acel design partial ( “tirania paginii
albe” este un efect similar)
• design oportunistic: descompunerea ierarhica este o strategie uzuala in designul
sistemelor complexe . Totusi in practica s-a observat ca designerii lucreaza la module
alese oarecum oportunistic, functie de efortul mental pe care trebuie sa-l depuna la un
moment dat
• generare si explorare: in prima faza sunt generate noi idei care mai apoi, in faza a
doua vor fi explorate iar implicatiile lor vor fi evaluate

In figura de mai jos sunt prezentate toate diagramele precizate in specificatiile UML:

Diagramele UML

• Class diagrams: descriu clasele, package-urile, proprietatile lor si diferitele relatii care
pot aparea intre acestea.

• Object diagrams: descriu un anumit scenariu, in loc de clase, ca la class diagrams vor
aparea obiecte, instante ale acestor clase.

• Use-case diagrams: descriu use cases, actorii implicati (cei care interactioneaza cu
sistemul), pus diferitele relatii existente.

5
 • Sequence diagrams and Collaboration diagrams: descriu secventa de mesaje
schimbate de obiecte la run-time.

• Statechart diagrams: prezinta starile pe care le pot avea obiectele in cadrul unui sistem.

• Activity diagrams: prezinta algoritmi sau data-flow.

• Component diagrams: descriu componentele implementate (Ex: source & object files)

• Deployment diagrams: descriu felul cum componentele sunt repartizate pe diferitele

computere.

Use-case Diagram

Un caz de uz (use case) este o tehnica de modelare folosita pentru a descrie functionalitatea
unui sistem, deci ce ar trebui sa faca un nou sistem sau ce face deja un anumit sistem. S-ar putea
spune chiar ca o diagrama use-case descrie ceea ce face un sistem din punctul de vedere al unui
observator extern, aceasta descriere fiind independenta de implementare. Adesea, o astfel de
diagrama este folosita in etapele preliminarii a procesului de design pentru a colecta cererile
clientului cu privire la proiect. Asadar, constructia unui model use-case, reprezentat printr-o
diagrama use-case (sau mai multe) se face de obicei dupa lungi discutii intre dezvoltatori si
clienti pe baza specificatiilor asupra carora au cazut cu totii de acord.
Un model use-case va descrie si va trebui sa surprinda felul in care un actor va folosi un
anumit sistem.
Pentru a crea un model use-case trebuie parcursi mai multi pasi si anume: definirea sistemului,
identificarea actorilor si a use-case-urilor, descrierea use-case-urilor, definirea relatiilor dintre
use-cases iar in final validarea modelului. Descrierea use-case-urilor se face fie printr-un text
scris, fie prin conceperea unei diagrame de activitate.
Cel mai important scop al unei diagrame use-case este de a ajuta dezvoltatorii de sisteme software
sa vizualizeze cerintele functionale ale unui astfel de sistem sau unitati de sistem.
Dintre use-cases, actori si dependente, actorii sunt pentru programatori cele mai neimportante
elemente ale unei diagrame use-case. Relatiile sunt de fapt cele mai importante deoarece acestea
le sugereaza care dintre use-case-uri sa fie implementat prima data. De regula se incepe cu use-
case-ul cu cele mai multe dependente deoarece alte use-case-uri depind de acesta.
Din punct de vedere grafic o diagrama use-case este un graf avand drept noduri actori si use-
cases, iar drept muchii diferite relatii intre aceste elemente.
• Actor este o entitate externa (persoana sau echipament) care are un interes in a
interactiona cu sistemul, deci va face un schimb de informatii cu sistemul (schimba
mesaje). Un actor reprezinta un rol nu un utilizator individual al sistemului. Asadar un
actor reprezinta o clasa nu o instanta avand stereotipul <<actor>> si deci poate avea atat
atribute cat si operatii (behaviours), precum si o documentatie in care sunt descrise
acestea.

6
 Sterotipii extind vocabularul UML sunt folositi la etichetarea artefactele UML pentru a
indica ca acestea apartin unei anumite categorii, sau pur si simplu pentru a reda mai multe
informatii despre artefactul UML.
Un actor are un nume, iar numele acestuia trebuie sa reflecte rolul actorului. Actorii pot fi
categorisiti in actori primari si secundari sau in actori activi (cel care initiaza use-case-ul) sau
pasivi (doar participa intr-un use-case). Intr-o diagrama actorii pasivi se pot deosebi de cei activi
dupa sensul asocierilor.
Identificarea actorilor din cadrul unui sistem se face raspunzand la urmatoarele intrebari:
1. Cine va folosi principalele functionalitati ale unui sistem? (actori primari)
2. Cine are nevoie de sprijin in realizarea indatoririlor zilnice? (useri)
3. Cine va trebui sa intretina, administreze si sa mentina in stare de functionalitate
sistemul?(actori secundari)
4. Cu ce alte sisteme va trebui sistemul nostru sa interactioneze?(sistem = alt
computer sau alte aplcatii de pe computerul pe care se dezvolta sistemul)
5. Cine are un interes in rezultatele pe care le va produce sistemul?

Use cases – Activitati semnificante pentru sistem (nu trebuie sa fie mai multe de 30; daca
se depaseste numarrul, proiectul se va sparge in mai multe bucati). De fapt un use-case
reprezinta o functionalitate completa a unui sistem asa cum este vazuta de catre un actor.
Identificarea use-case-urilor ce trebuiesc modelate intr-un sistem se face raspunzand la
urmatoarele intrebari:
1. Ce vrea un actor de la sistem? Ce anume vrea el sa faca?
2. Are nevoie un actor sa citeasca, creeze, distruga, modifice sau depoziteze vre-un
tip de informatie in cadrul sistemului?
3. Actorul trebuie sa fie anuntat de evenimentele din sistem, sau actorul trebuie sa
anunte ceva sistemului?
4. Munca zilnica a unui actor poate fi simplificata prin adaugarea de functii noi
sistemului?
Principalele caracteristici ale unui use-case sunt:
1. este initiat intotdeauna de catre un actor
2. intoarce o valoare catre un actor
3. este complet (valoarea finala este produsa)

Un use-case trebuie sa aiba un nume care de regula este o fraza care descrie cat mai bine
functinalitatea use-case-ului. La fel ca si actorii, un use-case este o clasa si nu o instanta, aceasta
clasa descriind functionalitatea ca un intreg, incluzand posibile alternative, erori si exceptii care
pot sa apara in timpul executiei unui use-case. O instanta a unui use-case poarta numele de
scenariu, reprezentand de fapt un caz de folosinta a sistemului.

• Extension Points - Este o referinta catre o locatie dintr-un use-case unde se pot insera
secvente din alte use-cases (fiecare extension point are un nume unic in cadrul use-case-
ului).

Relatiile care se pot modela intr-o diagrama use-case sunt:

Generalizare – Este o relatie intre un element parinte (mai general) si un element fiu (mai
specific) care este perfect compatibil cu elementul parinte adaugand insa si elemente aditionale.

7
Generalizarea este folosita pentru actori, use-cases, clase, package-uri etc, deci pentru tipuri,
niciodata pentru instante. Relatiile de generalizare sunt numite cateodata relatii “este un/o” (“O
masina este vehicul => generalizarea masinii este un vehicul”) si sunt folosite pt a descrie
comportamentul comun al unui anumit numar de elemente. Elementul specializat (fiu) mosteneste
comportamentul elementului general (superclasa sau parintele) extinzand intr-un anumit fel acest
comportament. O astfel de relatie poate avea un nume si un stereotip.
Exemplu de generalizare: un proiect este un proiect intern sau extern.

Associeri: Apar intre diferite elemente (Ex: actori si use-cases) si pot fi navigabile in
ambele directii, intr-o singura directie sau nenavigabile. O asociere intre doua elemente ar
insemna (s-ar traduce) ca elementele aflate intr-o relatie de asociere “stiu una de alta”, “sunt
conectate”, sau “pentru fiecare X exista un Y (sau mai multi de Y, asta depinzand de
multiplicitate)”. Reprezentarea grafica a unei asociatii este o linie simpla care poate avea si un
stereotip. In cadrul diagramei use case-urile sunt conectate de actori cu ajutorul asociatiilor, care
arata cine cu cine comunica precum si care este actorul care initializeaza un use-case. Lipsa unei
sageti indica faptul ca comunicarea se face in ambele directii. O asociere poate avea si ea un
nume care este de preferinta sa fie ales astfel incat sa descrie cat mai bine in ce consta respectiva
asociere.
O asociere are doua capete. Multiplicitatea unui capat al asociatiei reprezinta numarul
posibil de instante asociate cu o singura instanta a celuilalt capat.
Numarul respectiv poate fi un singur numar sau o serie de numere. De exemplu poate fi un
singur client pentru o comanda, dar un client poate face oricate comenzi.
Iata principalele multiplicitati folosite:
• 0..1 zero sau o instanta
• 0..* nici o limitare la nr. de instante
• 1 exact o instanta
• 1..* cel putin o instanta

Aggregation- O asociatie in care un element este “parte” a unui “intreg” reprezentat de

celalalt element. Exista mai multe tipuri de agregari cum ar fi:
1. agregari fixe (au un nr. prestabilit de componente)
2. agregari variabile (numar variabil dar finit de componente) Ex: liste, vectori
3. agregari recursive Ex: arborii binari contin arbori binari

Composition – Este o puternica forma de agregare in care elementul “parte” este distrus
automat in momentul distrugerii elementului “intreg”. In cadrul unei agregari elementul parte mai
exista si dupa ce elementul “intreg este distrus”. Ca si la agregare pot fi compozitii fixe, variabile
si recursive.

Dependente – Pot exista o serie de dependente semantice intre diferite element ale
modelului (si intre use-cases) si are rolul de a sugera ca un element foloseste un alt element, deci
depinde de acel element. Urmand sensul dependentei, o schimbare in specificatia unui element ar
putea afecta si pe elementul aflat in relatie de dependenta cu primul. Acestea au de obicei un
stereotip pentru o mai buna definire a rolului dependentelor. Exista doua tipuri speciale de
dependente: <<extend>> si <<include>>.
• Extend relationship – O relatie unidirectionala intre doua use-cases. O relatie de tip
extend intre B si A (B, A = use-cases) inseamna ca caracteristicile lui B pot fi incluse in
A.

8
 • Include relationship - O relatie unidirectionala intre doua use-cases. O astfel de
relatie intre use-case-urile A si B inseamna ca, inseamna ca caracteristicile lui B vor fi
intotdeauna incluse in A .

In timpul crearii unei diagrame use-case trebuie avute tot timpul in vedere urmatoarele:
• Daca exista similaritati intre o serie de actori atunci s-ar putea crea o clasa de baza a
acelor actori din care sa derive acestia folosind relatia de generalizare.
• Daca exista similaritati intre o serie de use-cases care cum ar fi un flux comun de
activitati (eventual folosit in mod repetat) atunci s-ar putea crea un nou use-case care sa
fie folosita de catre primele folosind relatia de incluziune (<<uses>>).
• Daca exista un caz apecial al unui use-case atunci se va folosi o relatie de tip
<<extends>>.
• Nu trebuie sa existe vre-un actor fara nici o asociere
• Daca exista o functionalitate cunoscuta care nu este abordata de vre-un use-case atunci se
va crea un nou use-case pt respective functionalitate.

Class Diagram

Class diagrams sunt probabil cele mai importante diagrame UML. In modelarea orientata
pe obiecte , clasele, obiectele si relatiile dintre ele sunt principalele elemente pentru modelare.
Cand se foloseste programarea orientata pe obiecte pentru realizarea sistemelor software, clasele
si relatiile devin chiar codul insusi.
O class diagram arata cum diferitele entitati (persoane, lucruri si date) sunt relationate
intre ele, scopul ei principal fiind acela de a descrie structura statica a sistemului care este
modelat. Spunem ca diagramele claselor sunt statice deoarece nu descriu ceea ce se intampla in
momentul in care clasele relationate interactioneaza.
Clasele sunt cele mai importante concepte in programarea orientata pe obiecte si s-ar
putea spune si in limbajul UML. Principalele proprietati ale unei clase sunt: numele, stereotipul si
vizibilitatea (public, protected sau private).
Modeland structura statica a claselor, o class-diagram prezinta structura interna a fiecarei
clase (atribute, operatii) precum si cel mai important aspect si anume relatiile pe care fiecare
dintre clase le are cu celelalte clase (asocieri, generalizari etc).
Pentru a crea o class diagram, clasele trebuie sa fie identificate si descrise.
Identificarea claselor o putem face raspunzand la urmatoarele intrebari:
• Avem un tip de informatie care trebuie depozitat sau analizat?
• Avem sisteme externe inglobate in activitatea sistemului modelat?
• Exista dispozitive pe care sistemul trebuie sa le mânuiasca?
• Exista biblioteci sau componente din alte proiecte care vor fi folosite in sistem?
• Actorii folositi (din use-cases) au un rol in sistem a.i. vor trebui implementati ca fiind
clase?
Daca se raspunde cu da la una dintre aceste intrebari atunci vom avea un posibil candidat
de a fi implementat drept clasa.
Clasele pot fi impartite in clase:
• active: cele care initiaza si contoleaza fluxul activitatii

9
 • pasive: depoziteaza informatii si servesc celorlaltor clase
sau clase
• abstracte: nu pot fi instantiate obiecte de tipul acestor clase (folosite pentru mostenire: o
clasa care mosteneste o clasa abstracta, avand functii abstracte, va trebui neaparat sa
implementeze aceste operatii => sa le scrie codul)
• concrete: opusul a ceea ce se numeste clasa abstracta
In ambele cazuri, cand exista o mostenire, daca se rescrie codul unei operatii, un obiect
apartinand acestei clase va folosi noul cod al operatiei respective.

Figura de mai sus demonstreaza ca o clasa are atat atribute cat si operatii.
Notatia UML pentru o clasa este un dreptunghi imparit in trei parti: numele clasei,
atributele si operatiile. O clasa abstracta va avea numele scrise cu caractere italice. Relatiile dintre
clase vor fi reprezentate de liniile conectoare. Unele dintre aceste tipuri de relatii sunt deja
cunoscute ele aparand si la diagramele de tip use-case.

10
 Primul compartiment al dreptunghiului clasei si anume numele clasei este de obicei un
substantiv care trebuie sa fie derivat din domeniul problemei analizate si de asemenea trebuie sa
fie cat mai putin ambiguu posibil.
Pentru un mai mare grad de abstractizare se poate apasa “Hide all compartments”, ceea
ce va duce la afisarea clasei sub forma unui mic dreptunghi simplu (nu vor mai fi afisate
compartimentele aferente atributelor si operatiilor).
Celelalte compartimente sunt cele corespunzatoare atributelor si operatiilor.
Un atribut este folosit pentru a pastra informatii care descriu si identifica o instanta
specifica a clasei. Un atribut are un tip care poate fi predefinit sau primitiv (integer, real, String,
byte, char …) sau poate fi o instanta a unei clase construite tot de noi. (In lista tipurilor ne vor
aparea si clasele definite de noi deci unui atribut va putea fi de un astfel de tip). Ceea ce trebuie
mentionat este faptul ca aceste tipuri primitive nu apartin limbajului UML, ci unui anumit limbaj
de programare setat in cadrul unealtei CASE folosite.
Din figura de mai sus se observa ca in cadrul diagramei se pot specifica declaratorii de
acces (specifica vizibilitatea) si sunt cei cunoscuti si folositi in mediile de programare OOP.
Acestia sunt public (accepta referirea din alte clase), private (nu accepta referirea din alte clase) si
protected (accepta referirea numai din clasele fiu => protected este folosit impreuna cu o relatie
de generalizare sau specializare). Asadar declaratorii de acces sunt folositi pentru specificarea
modului de acces la informatiile incapsulate in clase.
Am vazut ca atributele sunt valori care caracterizeaza obiectele clasei, cateodata valorile
atributelor fiind o cale de a descrie starea obiectului. Operatiile, cele afisate in al treilea
compartiment al figurii ce reprezinta clasa sunt folosite pentru a manipula atributele sau pentru a
performa alte actiuni. Operatiile sunt de obicei numite functii sau metode, dar ele sunt interioare
unei clase si deci vor putea fi aplicate numai obiectelor clasei. O operatie are un tip returnat, un
nume si zero sau mai multi parametrii. Impreuna, tipul returnat, numele si parametrii sunt numite
signatura operatiei. Signatura descrie tot ce este nevoie pentru a folosi operatia.
Pentru a performa o operatie, o operatie este aplicata unui obiect al clasei (este numit pe
un obiect). Operatiile intr-o clasa descriu ce poate face o clasa, ce servicii ofera, si pot fi vazute
ca fiind interfata unei clase.
Este posibil ca o operatie sa aiba o valoare de tip default pentru un parametru. Aceasta
inseamna ca in cazul in care apelantul operatiei nu specifica un parametru operatia va folosi
valoarea default pt acel parametru.
Cand un obiect (instanta al unei clase) este creat, atributele si linkurile ar trebui sa fie
automat initializate. Pentru acest lucru am putea avea o operatie statica care sa faca acest lucru
sau am putea crea un asa-zis constructor, cel care va corespunde unui constructor dintr-un anumit
limbaj de programare (C++, Java). In UML un constructor este redat printr-o operatie avand
acelasi nume cu clasa care are stereotipul “create”. O operatie avand stereotipul “destroy” este
echivalentul unui destructor din C++ si va fi responsabila in eliberara spatiului de memorie alocat
obiectelor dinamice.
Cuvantul cheie “leaf” pentru o clasa indica faptul ca acea clasa nu este conceputa pentru
a avea subclase, pe cand cuvantul “root” indica faptul ca acea clasa este radacina unui arbore de
derivare.

11
 Atat operatiile cat si atributele pot fi statice (afisate subliniat), deci nu vor apartine unei
instante a clasei din care provine ci vor apartine chiar clasei, fiecare dintre instantele clasei avand
acces la acestea. Un atribut static mai poate fi denumit si o variabila a clasei putand fi accesat si
fara sa existe vre-o instanta a unei clase, pe cand o operatie statica este folosita cu scopuri
generice cum ar fi crearea sau gasirea unui obiect acolo unde un obiect specific nu exista.
Principalele tipuri de relatii care se pot gasi intr-o class-diagram sunt:
Relatii de asociere: este o legatura intre doua clase (=>este o relatie si dintre obiectele,
instante ale celor doua clase). In UML o asociere este o legatura, o conexiune semantica intre
doua clase. (! Priviti codul sursa generat pentru clasele Cerc si Punct pentru o mai buna intelegere
a notiunii de asociere). O relatie de asociere trebuie sa fie o linie simpla daca ambele clase sunt
constiente de existenta celeilalte, sau o sageata orientata in cazul in care asocierea este cunoscuta
doar de una dintre clase. Asocierile au mai fost intalnite si la diagramele use-case, insa intr-o
class-diagram mai poate aparea un tip de asociere numita asociere recursiva. O clasa poate fi
conectata de ea insasi printr-o asociere ca in exemplul de mai jos:

Observati in exemplu de mai sus ca asocierea numit “casatorit(a) cu” are cele doua capete
denumite “sot” respectiv “sotie”, aceste denumiri fiind de fapt rolurile jucate de instante ale clasei
in cadrul asocierii.

Relatiile de mostenire – Sunt niste relatii care pot aparea intre interfete sau clase, insa nu
si intre interfete si clase. Simbolul UML pentru o relatie de mostenire ar fi o linie cu un triunghi
alb in capatul dinspre superclasa. Clasa specializata (subclasa) mosteneste atributele, operatiile si
chiar si asocierile clasei generale (superclasei).

12
 Relatii de dependenta – reprezinta o legatura semantica intre doua elemente ale
modelului, unul dependent de cel pe care il vom numi independent. O schimbare in elementul
independent va afecta si elementul dependent.
Relatii de tip realization – Relatii care exista doar intre interfete si clase. Asta inseamna
ca o clasa va “mosteni” toate operatiile interfetei, si bineinteles, va putea avea si alte operatii
proprii.

Packages – Un package este un mecanism de grupare folosit pentru organizarea

elemntelor in grupuri de elemente avand o legatura semantica. Asadar package-urile sunt folosite
pt structurarea modelului (un element poate fi continut doar de un singur package), iar in cadrul
unei class-diagram ele sunt folosite pt specificarea explicit a ierarhiilor. Asa cum clasele se pot
plasa direct intr-un model, asa se pot situa si in interiorul package-urilor exprimand astfel
interdependentele existente intre anumite package-uri. Un package prezinta similaritati cu o
agregare in sensul ca package-ul isi detine elementele; daca insa importa elemente din alte
package-uri vom spune ca avem de-a face cu o shared aggregation. Importarea dintr-un package
este vazuta ca o dependenta, avand stereotipul <<imports>>.

Interfete – sunt un fel de clase restrictionate in a contine doar operatii nu si atribute. Din
punct de vedere grafic o interfata este reprezentata printr-un dreptunghi cu doua compartimente
(nume+operatii), avand stereotipul <<interface>>. Operatiile sunt abstracte si nu au nici o
implementare in cadrul interfetelor. Despre clasele care au o legatura cu o interfata vom spune ca
implementeaza acea interfeta si ele vor fi nevoite sa implementeze aceste operatii (metode),
respectiv sa scrie codul acestora.

13
 Action diagram

Scopul diagramele de activitate este acela de a modela actiunile (munca + activitati)

implementate in operatii, in special in cele dintre doua sau mai multe clase si de a prezenta
rezulatele acestor actiuni.
In proiectele in care sunt prezente use-cases, o diagrama de activitate poate modela un
use-case anume, la un grad de detaliere mai mare, insa aceste diagrame pot exista si independent
de use-cases, si folosite pentru:
• reprezentarea actiunilor executate odata cu o operatie (instanta implementarii unei
operatii)
• reprezentarea activitatii interne a unui obiect
• a arata cum un set de actiuni pot fi execuate si cum vor afecta obiectele din jur
• a arata cum functioneaza anumite sisteme, referirea facandu-se la actori (muncitori),
organizare, cursul activitatii…
Exemplu: modelarea unor functionalitati ale unui sistem sau subsistem.
O diagrama de activitate se concentreaza asupra succesiunii in executie a actiunilor si
asupra conditiilor (trigger sau guard) care declanseaza aceste actiuni. De asemenea, o diagrama
de activitate se concentreaza asupra actiunilor interne ale activitatilor si nu asupra actiunilor care
apeleaza activitatea in plin progres, sau asupra triggerelor ce declanseaza activitatea.
O actiune este facuta pentru a produce un rezultat. Implementarea unei operatii poate
poate fi descrisa ca un set de actiuni avand legatura, actiuni care mai tarziu vor f transformate in
cod.
Notatiile diagramelor de activitate sunt foart asemanatoare cu a celor de stari (statechart
diagram), de fapt conform specificatiilor UML o diagrama de activitate poate fi considerata o
varianta a unei diagrme de stari.
Asadar, la fel ca si o diagrama de stari, diagramele de activitate incep cu un Initial State
care este conectat de prima stare, printr-o tranzitie, iar activitatile care termina modelul sunt
conectate de un FinalState, la fel ca la diagramele statechart.
Exemplu:

In diagramele de activitate, trecerea de la o stare la alta (stare = action-state) se face

atunci cand actiunea starii respective este terminata ( => nu este necesara specificarea unui
eveniment ca in diagramele statechart ).
Specificatiile UML permit existenta unei singure stari initiala care sa aiba doar o singura
tranzitie care conecteaza starea initiala de o alta stare.
Este posibil insa ca o activity diagram sa aiba mai multe stari finale, care sa reprezinte
terminarea unei ramuri logice, cu alte cuvinte o activitate poate sa se termine in diferite maniere.
Pentru definirea unor astfel de ramuri logice se folosesc punctele de decizie. Acestea vor
avea atasate niste guard-uri, adica o conditie care la un moment dat poate lua valoarea Adevarat
sau Fals. In functie de aceasta valoare de adevar activitatea va urma un curs sau altul.
Guardurile vor fi atasate de tranzitiile care pleaca din punctul de decizie si in mod normal
la un moment dat numai unul dintre aceste guarduri trebuie sa aiba valoarea de adevar True.
Tranzitiile dintre stari au aceeasi sintaxa ca la statechart, exceptie facand evenimentele.
Evenimentele pot fi atasate doar de tranzitiile care leaga punctul de start de primul action-state.
Ele pot avea atasate conditii guard sau actiuni, insa atunci cand acestea lipsesc (de cele mai multe
ori) tranzitia va avea loc atunci cand toate activitatile din action-state se vor termina.

14
 Cand tranzitiile sunt protejate de conditii guard, tranzitia se va face numai atunci cand
conditia va lua valoarea de adevar True.
Folosind un Fork, o tranzitie poate fi divizata in doua sau mai multe tranzitii. Aceste
actiuni vor fi executate concurent, iar in cazul in care aceste tranzitii paralele se vor uni (printr-un
Join) este foarte important ca ele sa-si termine actiunea inainte de unire.
Pentru a arata explicit unde sunt facute actiunile (in ce obiect), se folosesc asanumitele
swimlanes. Acestea se prezinta sub forma unor dreptunghiuri, iar activitatile corespunzatoare
unor astfel de swimlanes vor fi plasate in interiorul dreptunghiurilor. Fiecarui swimlane ii este dat
un nume, care este pus in partea superioara a dreptunghiului.

15
 Collaboration diagram

Collaboration diagrams descriu atat natura statica cat si natura dinamica a unui sistem.
O colaborare defineste rolurile care vor fi jucate atunci cand se executa subrutinele unui
sistem. Aceste roluri vor fi jucate de instante ale claselor aflate in directa interactiune.
Collaboration

Rol
e role
name
role
name
role
Class role name
name

Diagramele de colaborare sunt o alta modalitate de reprezentare a interactiunilor si a

relatiilor dintre obiecte. Spre deosebire de diagramele de tip sequence, ele nu se concentreaza pe
succesiunea in timp a interactiunilor ci mai degraba pe conexiunile structurale dintre obiectele
care colaboreaza si pe rolurile pe care acestea le joaca in cadrul unei colaborari.
Un interes special il au in diagramele collaboration mesajele schimbate de obiecte
precum si scopul pentru care sunt schimbate aceste mesaje.
La fel ca si o diagrama de secventa, o diagrama de colaborare poate fi folosita sa ilustreze
executia unei operatii, a unui use-cases sau pur si simplu sa ilustreze un scenariu de interactiune
intr-un sistem.
O diagrama de colaborare descrie un set de obiecte impreuna cu relatiile dintre ele
precum si interactiunile dintre acestea, adica felul in care respectivele obiecte coopereaza pentru a
defini functionalitatea unui sistem sau subsistem. Este foarte utila modelarea interactiunilor
pentru un sistem in timp real, pentru ca astfel se poate ilustra atat structura statica cat si cea
dinamica a obiectelor care se afla in interactiune. O singura diagrama de colaborare poate
reprezenta mai mult de un fir de executie, precum si o transmitere simultana a mai multor mesaje.
Diagramele de colaborare arata obiecte si legaturile dintre acestea, precum si felul in care
mesajele sunt trimise intre obiectele conectate (prin legaturi). Obiectele sunt desenate la fel ca si
clasele (in forma restransa), insa numele obiectului este subliniat (numele simbolului obiect).
Legaturile arata foarte mult cu asocierile insa le lipseste multiplicitatea.
O diagrama de colaborare incepe cu un mesaj care initiaza intreaga interactiune sau
colaborare. Mesajele (stimulii) sunt folositi pentru a descrie interactiunea dintre obiecte si lor li se
pot atasa cate o eticheta-mesaj care defineste printre alte lucruri si un numar de secventa pentru
mesajul respectiv. Mesajul acesta va fi de cele mai multe ori un apel de procedura (operatie), ca
in figura de mai jos.

16
 Un actor trimite un mesaj pentru printare catre un computer. Computerul trimite un mesaj
de printare serverului, care la randul lui va trimite un mesaj de imprimare catre imprimanta (daca
aceasta este libera).
Mesajele sunt numerotate astfel:
- primul mesaj, cel care porneste o secventa intreaga de mesaje va fi numerotat cu 1
- mesajul 1.1 este primul mesaj care decurge din rezolvarea primului mesaj
- mesajul1.2 este urmatorul
- mesajele trimise in paralel, adica cele concurente pot fi descrise folosind litere in cadrul
expresiei numerice care exprima succesiunea mesajelor. De exemplu 2.1.a si 2.1.b vor fi
folosite pentru doua mesaje care vor fi trimise in paralel.
Un Link este o conexiune dintre doua obiecte care colaboreaza. Mesajele (stimulii) vor fi
pozitionati de-a lungul acestora.
Rolul jucat de un obiect intr-o colaborare va fi aratat la capetele link-urilor. Unui
astfel de rol i se pot atasa diferite stereotipuri cum ar fi:
- global: specifica faptul ca instanta respectiva este vazuta in intregul sistem si poate fi
apelata folosind un nume cunoscut oriunde in sistem
- local: specifica faptul ca instanta respectiva este vazuta deoarece este o variabila locala
intr-o operatie.
- parameter: specifica faptul ca instanta respectiva este vazuta deoarece este un parametru a
unei operatii
- association: specifica faptul ca instanta respectiva este vazuta doar de catre obiectele
aflate in asociere
- self: specifica faptul ca instanta respectiva este vazuta doar de catre ea insasi
Obiectelor create in timpul unei colaborari vor avea constrangerea {new}, iar cele care
sunt distruse in timpul colaborarii vor avea constrangerea {destroyed}. Obiectele care sunt si
create si distruse in cadrul aceleiasi colaborari vor avea constrangerea {transient}care este
echivalenta cu {new}{destroyed}.
Obiectele, cele care joaca rolurile din digrama de colaborare, vor fi etichetate cu nume de
clase, de obiecte sau cu ambele. Numele claselor sunt precedate de “:”, iar fiecare mesaj din
diagrama are un numar care va indica succesiunea acestora. Primul mesaj va fi numerotat cu 1, iar
mesajele de pe acelasi nivel (trimise in timpul aceluiasi apel) au acelasi prefix, dar vor continua
cu un sufix diferit in ordinea in care mesajele vor fi transmise.
Exista mai multe tipuri de mesaje si anume:
- simple: arata cum controlul este pasat de la un obiect la altul fara a se da vre-un detaliu
despre comunicare; acest tip de mesaj este folosit este folosit cand nu se cunosc detalii
despre comunicare sau cand aceste detalii nu sunt considerate relevante in diagrama la
care se lucreaza; mesajele simple mai sunt folosite pentru a arata faptul ca controlul este
dat inapoi de la obiectul care a primit un mesaj sincron la cel care a initiat acel mesaj.
- sincrone: similare cu un apel al unei operatii; operatia care primeste mesaul isi termina toate
operatiile (inclusiv transmiteea de alte mesaje), inainte ca obiectul care a initiat primul mesaj sa-si
continue executia; aceasta reintoarcere catre primul obiect poate fi reprezentata ca un mesaj sau
poate fi considerata implicita la terminarea operatiei care se ocupa de mesajul transmis.
- asincrone: sunt folosite acolo unde nu exista o reintoarcere explicita in cadrul obiectului
care initiaza mesajul, acesta continuandu-si executia dupa transmiterea mesajului, fara sa
astepte rezultatul operatiilor care se vor executa odata cu transmiterea mesajului; acest tip
de mesaj este folosit in sistemele in timp real unde obiectele se au o executie concurenta.
Un mesaj simplu si unul sincron pot fi combinate pentru a arata ca la transmiterea mesajului,
returnarea controlului are loc aproape instantaneu.
Adnotari cu privire la timp pot fi adaugate diagramelor de colaborare, insa nu asa clar ca
intr-o diagrama de tip sequence. Aceste adnotari vor fi de fapr notite sau constrangeri atasate
diferitelor elemente din diagrama.

17
 Diagrama de colaborare din figura de mai sus arata interactiunile care au loc cand un
senzor al unei alarme detecteaza ceva. Acesta trimite un semnal de alarma asincron catre Cell
Handler. In continuare Cell Handler trimite in paralel semnale (mesaje) asincrone paralele catre
toate alarmele (in acest caz, un telefon si un alarma sonora) si un semnal de tot asincron catre
System Handler. System Handler folosind Superviser, va trimite un stimul pentru declansarea
alarmei interne, iar apoi va scrie evenimentul intr-un fisier log. O diagrama de colaborare
furnizeaza o poza buna a ambelor structuri a obiectelor implicate si interdependenta lor.
Un obiect activ se executa deodata cu thread-ul sau de control.

Un actor de la un anumit etaj apasa un buton. Elevator control creeaza o noua sarcina pt
lift pe care o introduce in coada liftului. Obiectul elevator este activ, ruleaza concurent si isi
extrage noile sarcini din coada sa.

18
 Sequence Diagram

O diagrama de secventa este o diagrama ce descrie structura dinamica a unui sistem

aratand interactiunile dintre instantele unor clase (obiecte) in momentul rularii programului
(functionarii sistemului), oferind o harta a modului de transmitere a mesajelor intre obiecte in
timp (=> se modeleaza operatiile care vor trebui incluse in clasele sistemului precum si
evenimentele suportate de clase).
Frecvent acest tip de diagrame vor fi situate sub Use-Cases sau sub diferite componente
pentru a ilustra un scenariu (nu un algoritm), sau niste succesiuni de pasi care sunt parcursi la
aparitia unui eveniment. O astfel de diagrama va arata ce obiect initiaza activitatea intr-un sistem,
ce procese si schimbari vor avea loc intern in cadrul sistemului si ce date de iesire vor fi generate
in urma interactiunilor dintre obiecte.
Asadar o diagrama de secventa va reprezenta un scenariu Use Case (sau o parte a unui
scenariu Use Case) sau un curs al evenimentelor, concentrandu-se pe succesiunea in timp a
interactiunilor din timpul executiei, care este determinata prin citirea diagramei de sus in jos.
O diagrama de secventa are doua dimensiuni:
- dimensiunea verticala: arata succesiunea mesajelor/apelurilor ordonate in functie de momentul
in care apar (functie de timp)
- dimensiunea orizontala: arata obiectele catre care sunt trimise mesajele (Obiectele implicate
sunt listate de la stanga la dreapta dupa momentul in care sunt implicate in secventa de mesaje)
Obiectele care vor participa la interactiuni vor avea urmatoarea sintaxa: InstantaClasa :
NumeClasa (ex. myReportGenerator : ReportGenerator).
Ca notatie UML, o diagrama de secventa va consta dintr-un set de obiecte, fiecare avand
o linie verticala punctata care reprezinta viata obiectului respectiv (linia vietii). Aceasta linie a
vietii reprezinta timpul cat obiectul respectiv continua sa existe si ajuta la reprezentarea mesajelor
(atat cele primite cat si cele transmise) si activarii obiectelor.
Mesajele (stimulii), sunt desenate ca fiind sageti trasate de la un obiect la altul. Daca o
instanta a unei clase trimite un mesaj (stimul) unei alte instante, se va desena o sageata (deschisa)
orientata spre instanta care va primi mesajul.
Numele mesajului (stimulului) precum si a actiunii care se va executa vor fi plasate
deasupra acestei sageti. Actiunea executata este de cele mai multe ori o operatie implementata in
cadrul clasei obiectului care primeste mesajul. Daca aceasta operatie returneaza o valoare care
este importanta in desfasurarea executiei programului, se poate desena o sageata punctata,
orientata spre obiectul apelant (numita return stimulus in Poseidon).
Elementele uneidiagrame de secventa:
• Objects – Elementele responsabile cu transmiterea si receptionarea mesajelor
• Call stimuli – Reprezinta un mesaj sincron (care este vazut ca un apel de functie)
• Send stimuli – Reprezinta un mesaj asincron (care este vazut ca un semnal)Cel care transmite
mesajul nu asteapta un raspuns de la cel care primeste mesajul.
• Return stimuli – Reprezinta ceea ce se returneaza in urma unui call stimulus.
• Create stimuli – Folosit pentru a crea un nou obiect la un anumit dat in cadrul secventei de
interactiuni.
• Destroy stimuli - Folosit pentru a distruge un obiect la un anumit dat in cadrul secventei de
interactiuni. Linia vietii acelui obiect care va fi distrus se va termina printr-o cruce in momentul
trimiterii stimulului.

19
 Component and Deployment Diagrams

Majoritatea uneltelor Case existente permit crearea unei astfel de diagrame sub
denumirea de deployment diagram, ArgoUML, nici Poseidon nefacand exceptie de la aceasta. In
Poseidon se pot edita chiar si Object Diagrams in cadrul sectiunii diagramei Deployment
deoarece s-au introdus si notatiile pentru Object in toolbar-ul aferent.
O astfel de diagrama ofera o vedere din punct de vedere fizic asupra sistemului. Scopul ei
este de a arata dependentele pe care software-ul dezvoltat le are cu alte componente software din
cadrul sistemului (Ex: biblioteci de functii). O diagrama de componenta poate reprezenta sistemul
la un nivel superior (high-level), ilustrand numai principalele componente la un nivel de detaliere
foarte mic, sau la un nivel inferior (low-level) unde vor fi ilustrate componentele pana la nivelul
package-urilor.
Diagramele de componenta sunt foarte folositoare in cazul in care se lucreaza la un
proiect cu un numar relativ mare de echipe de dezvoltare. Ele ajuta la modelarea si apoi
identificarea componentelor software si a interfetelor acestora. O data ce interfetele au fost
definite si acceptate de echipe este mult mai usor de organizat efortul de dezvoltare al
subechipelor.
Principalele elemente ale unei Component Diagram:
• Nodes and Instances of Nodes – nodurile reprezinta elementele hardware ale sistemului
distribuit (acestea sunt folosite numai in cazul diagramelor de tip deployment)
• Components and Instances of Components – componentele tin locul elementelor software
care sunt repartizate in hardware-ul sistemului.
• Links – sunt folosite pentru conectarea obiectelor sau instantelor de noduri.
• Dependencies – acestea exista intre diferite componente si pot fi specificate utilizand stereotipi
(predefinite sau nu).
• Associations - sunt folosite pentru a ilustra relatiile de comunicare dintre noduri. La fel ca
dependentele si asocierile pot fi specificate folosind stereotipi.
• Objects, Classes, Interfaces - componentele si nodurile pot include obiecte, clase sau interfete.
Dupa un timp, clusterele de clase cu interactiune puternica vor forma un fel de unit si vor
iesi in relief in cadrul arhitecturii. Aceste clustere vor putea fi reprezentate in limbajul UML sub
forma unor componente. Componentele sunt de fapt fisierele existente in mediul de dezvoltare
folosit pentru constructia unui system. Ele sunt blocurile care alcatuiesc sistemul distribuit pe
diferite alte elemente hardware (aceste elemente hardware pot fi si computere diferite). De fapt
ele sunt artefacte de nivel inalt cum ar fi java beans, dll-uri, ocx’s-uri si alte produse software, de
multe ori compuse din alte elemente mai simple cum ar fi clase si functii din biblioteci.
Componentele mai pot fi vazute si ca implementarea in arhitectura fizica a unui sistem a
conceptelor si functionalitatilor definite in arhitectura logica (clase, obiecte, diferite relatii si
colaborari). Fiecare componenta va oferi servicii altor componente (numite clienti), aceste
servicii numite contracte facandu-se de obicei prin intermediul interfetelor.
Exemple de componente:
• ActiveX Control: set de tehnoloogii Microsoft care ofera continut interactiv pt World
Wide Web (efecte multimedia, obiecte interactive)
• Dll (dynamic link library)
• JavaBean (suport pt servere de aplicatii)
• Pagini Web

20
 O componenta software poate fi:
• source component (Compile-Time Components): un fisier continand cod sursa in care sunt
implementate una sau mai multe clase; o astfel de componenta are un inteles la momentul
compilarii (compile time), celelate tipuri de componente fiind generate de componente de
acest tip
Pentru Compile-Time Components se pot folosi urmatoarele stereotipuri:
- <<file>>: fisier continand cod sursa
- <<page>>: o reprezentare a unei pagini web
- <<document>>: reprezentate a unui fisier continand documentatie nu cod

• binary component (Link-Time Component): cod obiect care este rezultatul compilarii a unuia
sau mai multor componente sursa; o astfel de componenta poate fi un fisier cu cod obiect
(obj), un fisier static sau dinamic de functii (library files) care are un inteles la link-time sau
in cazul unei librarii dinamice la run-time (o astfel de biblioteca este incarcata de o
componenta executabila doar in momentul rularii)
Pentru Link-Time Components se pot folosi urmatoarele stereotipuri:
- <<process>>: simplu proces
- <<thread>>: fir de executie

• executable component (Run-Time Component): un fisier executabil (exe) care este rezultatul
procesului de linking al tuturor componentelor binare (statrice la link-time si dinamice la run-
time), sau cateodata direct din Compile-Time Components (ex. Java); o astfel de componenta
reprezinta unitatea executabila care va fi rulata de catre processor (computer)
Pentru Run-Time Components se pot folosi urmatoarele stereotipuri:
- <<application>>: reprezinta un fisier executabil
- <<table>>: o reprezentare a unui tabel dintr-o baza de date folosit drept
componenta la run-time

21
 Sa presupunem ca dorim sa construim un software pentru muzica de pe CD-uri (un
player) a carui interfata, simpla ar include doar butoanele obisnuite . Atunci am avea urmatoarea
diagrama de componenta:

In UML o componenta este ilustrata sub forma unui dreptunghi uneori avand o elipsa
plus inca doua mici dreptunghiuri in stanga. Componentele sunt niste tipuri, insa numai
componentele executabile pot avea instante (atunci cand programul pe care-l reprezinta este
executat de compilator ).
Principiile designului de componente:
• nu trebuie sa existe cicluri de forma A  B  C  A unde sageata reprezinta o relatie
de dependenta
• daca o clasa localizata intr-o anumita componenta este schimbata atunci acest lucru nu
trebuie sa afecteze clase din afara componentei respective
• daca o clasa dintr-o componenta trebuie sa fie reutilizata va trebui sa fie reutilizate toate
clasele incluse in acea componenta (niciodata nu se va reutiliza numai o parte a unui element
software)
• abstractiile nu trebuie sa depinda de detalii ci detaliile vor trebui sa depinda de abstractii
• elementele software vor trebui sa fie deschise pentru extindere dar inchise pentru
modificare
• daca A depinde de B atunci B ar trebui sa fie mai stabila (mai putin probabil de a suferi
modificari)
• componenta trebuie sa fie suficient de abstracta pentru ca sa poata fi extinsa fara a-I fi
afectata stabilitatea.
In timp, construind astfel de componente in cadrul unei arhitecturi, se poate ajunge la o
structura arhitecturala reutilizabila care va putea fi folosita cu succes in cadrul altor si altor
sisteme.
O component diagram arata felul cum sunt organizate componentele software (source,
binary, executable), relatiile dintre si dependentele existente intre acestea, felul in care comunica
etc. O astfel de diagrama este folosita de obicei pentru prezentari de marketing sau rezumate a
arhitecturii unui sistem.
O sageata punctata intre doua componente inseamna ca o componenta are nevoie de o
alta pentru a fi definite complet. O astfel de dependenta intre o source component A si o source
component B inseamna ca, o schimbare in B necesita o recompilare si a lui A. Daca
componentele intre care exista o dependenta sunt executabile atunci citind o astfel de diagrama
vom putea identifica de ce librarii dinamice are nevoie un program pentru a putea rula.
O componenta poate sa implementeze una sau mai multe interfete care sa poata fi vazute
de alte componente (=>publica comportamentul componentei respective). Aceste interfete pot fi
definite la nivel cod (ex: interfete Java) sau binary, folosite la run-time (ex. OLE).

22
 Legatura unei componente cu o anumita interfata poate fi reprezentata in doua moduri,
dupa felul acestei legaturi. Componenta ofera de obicei o interfata si in acest caz se va folosi
notatia tip lollypop. Incepand cu UML2 a fost introdusa simbolul de socket pentru a indica faptul
ca este nevoie de implementarea unei interfete. Acest simbol poate fi considerat un stereotip
vizual pentru o dependenta. (in locul lui poate fi folosita o dependenta obisnuita cu stereotipul
<<require>>).
Un port (notatia UML = patrat mic), va fi o caracteristica a unei componente ce specifica
un punct de interactiune a componentei cu mediul extern. Aceste porturi care pot avea si un nume
vor putea suporta o comunicatie unidirectionala sau bidirectionala, dupa caz.
Nu este nevoie sa fie folosite toate interfetele unei componente.

Figura de mai jos ilustraza patru componente: Reporting Tool, Billboard Service,
Servlet 2.2 API, and JDBC API. Existenta sagetilor care pleaca de la componenta Reporting Tool
catre componentele Billboard Service, Servlet 2.2 API, and JDBC API inseamna ca Reporting
Tool este dependent de aceste trei componente.

O component diagram va arata o componenta numai sub forma unui tip, deci daca avem
nevoie de reprezentarea unei instante a unei componente vom trebui sa folosim o deployment
diagram.
O deployment diagram sa o network diagrams cum i se mai spune descrie felul cum
componentele sunt repartizate pe diferitele computere existente in cadrul unui sistem. Notatiile
dintr-o deployment diagram includ elementele notationale folosite intr-o component diagram,
avand insa si cateva adaugari cum ar fi conceptul de nod care reprezinta de fapt o masina (reala
sau virtuala). Scopul unei astfel de diagrame este de a ilustra unde vor rula (dpdv fizic) diferitele
componente si cum vor comunica una cu alta, asadar s-ar putea spune ca o deployment diagram
modeleaza sistemul la run-time.
Cel mai simplu exemplu de deployment diagram ar fi diagrama care descrie un PC:

23
 Diagrama de tip deployment din figura de mai sus arata faptul ca userul acceseaza
Reporting Tool folosind un browser care ruleaza pe o masina locala si se conecteaza la Reporting
Tool prin intranetul companiei folosind protocolul HTTP. Aceasta ruleaza (dpdv fizic) pe
serverul de aplicatii.
Diagrama arata componenta Reporting Tool desenata inauntul componentei IBM
WebSphere, care la randul ei este desenata inauntrul nodului care reprezinta serverul de aplicatii.
Reporting Tool se conecteaza la baza sa de date folosind limbajul Java si interfata IBM JDBC
API, care apoi comunica cu baza de date Reporting aflata pe serverul MySQL Server folosind
interogari SQL. Componenta Report Tool comunica folosind SOAP over HTTPS cu Billboard
Service.

24
Bibliografie:

1) http://www.ici.ro/RRIA/ria2004_3/art08.htm
2) http://www.sparxsystems.com.au/uml-tutorial.html
3) http://www.uml.org/
4) http://www.visual-paradigm.com/
5) http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in
%20UML.pdf
6) http://funinf.cs.unibuc.ro/~gheorghe/curs/metDezvSoft/lec/l05four.pdf
7) http://cs.ubbcluj.ro/~vcioban/Informatica/Anul3/SIPP/Esit/curs/Modelare
%20OO%20UML%20GRAPPLE.doc
8) http://thor.info.uaic.ro/~adrianaa/uml/
9) http://www.techit.ro/tutorial_uml_1.php
10) http://www.techit.ro/tutorial_uml_2.php
11) http://www.techit.ro/tutorial_uml_3.php

25