Introducere in Uml

Inginerie Software Candea Radu
Introducere in UML
Autor: Radu Candea

Laborator 1
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
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 cei 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.).
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 pt 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).
• 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.
• 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.
Laborator 2
ArgoUML - unealta de modelare
Suprafata de lucru a lui ArgoUML este separata in cinci parti. In partea de sus se afla meniul
principal precum si o bara cu unelte care permite acesul la principalele functionalitati ale
ArgoUML. Sub acestea se afla patru subferestre. Cea mai mare dintre ele (dreapta-sus) este
numita subfereastra diagramelor (sau Edit Pane Toolbar) si este locul in care se vor edita in
mod grafic si in care vor fi afisate diferitele diagrame. Deasupra ei se afla o alta bara de unelte
numita EditPaneToolbar. In stanga sus se afla subfereastra pentru navigare (navigation pane)
sau Explorer-ul de unde se poate naviga prin modelul curent. Aceasta subfereastra listeaza toate
clasele, interfetele si tipurile de date ale modelului sub forma unui arbore (tree).
Cele doua subferestre de jos sunt subfereastra To Do si subfereastra detaliilor. Subfereastra To
DO reaminteste designerilor ceea ce acestia mai trebuie sa faca. Itemii din aceasta subfereastra
pot reprezenta si note ale designerului insusi, dar cei mai multe sunt generate de asanumitii
design critics.
Ce este un critic? Un critic este un proces din cadrul ArgoUML care furnizeaza sugestii despre
cum ar putea fi imbunatatit modelul designului la care se lucreaza. Un critic poate fi considerat
“un program ce critica solutiile generate de om” (Miller in Attending).
Aceste sugestii sunt bazate pe cele trei teorii cognitive despre care s-a discutat in primul
laborator: reflection-in-action, design oportunistic, generare si explorare. Criticii analizeaza in
mod continuu designul in lucru cautand chestiuni incomplete sau problematice. Cand o potentiala
problema este gasita este generat un item “to do” care est adaugat in lista din subfereastra ToDo.
Cand designerul va rezolva problema identificata, itemul corespondent acelei probleme va
disparea din lista.
Pentru o buna gestionare a listei itemilor generati de diferiti critici acestia pot fi grupati dupa
prioritate, tipul de decizie suportat, tipul elementului de design care pricinuieste acel item s.a.m.d.
Subfereastra detaliilor din ArgoUML permite editarea elementului sau itemului “to do” selectat.
Aceasta subfereastra contine dupa cum se vede si in imagine mai multe taburi si anume:
Tabul ToDo Item arata descrierea itemului selectat in subfereastra ToDo. In subfereastra
diagramelor elementul “cu probleme” va fi marcat cu rosu. Descrierea itemului va consta din trei
paragrafe dupa cum urmeaza:
1. descrierea problemei
2. se spune de ce este importanta aceea problema pt designer
3. se enumera pasii care trebuie parcursi pentru rezolvarea acelei probleme (uneori pasii
sunt parcursi cu ajutorul unui Wizard care nu sunt modali, deci se pot folosi alte unelte in timpul
folosirii unui Wizard)
Exista si o serie de iconite care permit inserarea unui item personal (notita de aducere aminte),
destituirea itemului curent, trimiterea unui e-mail catre autorul criticului ce produce itemul sau se
poate dezactiva criticul respectiv pentru 10 minute prin selectarea iconitei “Snooze”.
Tabul Properties arata proprietatile elementului de design selectat. Continutul acestui tab este
definit pentru orice element si variaza in functie de tipul de element selectat. (Selectia se poate
face atat in subfereastra pentru navigare cat si in subfereastra diagramelor). Aceasta fereastra
poate contine si diferite butoane specifice deasemenea fiecarui tip de element.
Tabul Documentation permite introducerea documentatiei pentru elementul selectat
indiferent de natura lui. Exista mai multe sectiuni pentru introducerea de date cu privire la autor,
versiune, referiri s.a.
Tabul Style permite editarea proprietatilor vizuale a elementului de design selectat.
Continutul acestui tab poate varia putin functie de tipul elementului selectat. Principalele astfel de
proprietati vizuale ar fi: culoarea, pozitionarea, umbra etc.
Tabul Source permite un preview asupra codului sursa care va fi generat pentru elementul de
design selectat. Limbajul acestui cod sursa poatefi selectat cu ajutorul unui combo-box. O
instalare standard a ArgoUML va include limbajele UML si Java, dar cu ajutorul unor plug-ins se
poate genera cod sursa si in limbajele C++, PHP si C# si speram altele in viitorul apropiat. Tot in
versiunile viitoare, ArgoUML va permite editarea codului direct in acest tab, iar modelul UML sa
fie updatat in consecinta in mod automat.
Tabul Constraints permite intrarea si vizualizarea constrangerilor de tip OCL (Object
Constraint Language) pentru elementul curent. OCL este un limbaj simplu orientat pe predicate
logice care permite adaugarea de mai mult inteles designurilor. In timpul editarilor
constrangerilor tabul Constraints se schimba intr-un editor care ofera multe functii de ajutor
pentru generarea de sintaxa corecta.
Tabul Tagged Values permite pentru obiectul curent introducerea unor perechi de tipul cheie-
valoare cu rolul de indicatii care vor fi memorate cu elementul de design, dar care insa nu sunt
interpretate de sistem.
Tabul Checklist contine o lista de intrebari cu raspuns DA sau NU care ajuta designerul sa
realizeze daca elementul selectat a fost proiectat bine sau nu.
De fiecare data cand ArgoUML este pornit sau cand se selecteaza pentru un nou proiect, se va
deschide un proiect continand un model numit untitledModel. Acest model contine o diagrama de
clase goala, numita diagram1 precum si o diagrama de caz goala numita diagram1.
Modelul si cele doua diagrame goale pot fi vazute in explorer, care este principala unealta de
navigare prin model. In versiunea curenta, ArgoUML (0.16.1) nu poate contine activ decat un
singur proiect care la randul lui suporta un singur model UML. Din moment ce un model UML
poate contine un numar nelimitat de elemente si diagrame, acest lucru nu reprezinta o limitare
serioasa chiar si pentru modele mari si complexe.
ArgoUML salveaza informatiile continute in diagrame intr-un fisier PGML (cu extensia .pgml),
informatia din model intr-un fisier XMI (cu extensia .xmi) si informatia despre proiect intr-un
fisier .argo. PGML si XMI sunt open standards, iar in viitorul indepartat standardul PGML va fi
inlocuit de standardul SVG (Scalable Vector Graphics creat de Adobe) cel care in viitor va putea
fi generat din XMI . Toate aceste fisiere (.pgl, .xmi) sunt mai apoi arhivate intr-un fisier de tip
.zargo. Se pot extrage foarte usor fisierele .xmi si .pgml folosind o traditonala aplicatie ZIP. Alte
unelete CASE (Computer Aided Software Engineering) isi creaza propriile tipuri de fisiere
specifice lor => non open standard. (Rational Rose creaza modele cu extensia .ptl, iar proiectele
cu .mdl).
Cu ajutorul lui ArgoUML se pot crea mai multe tipuri de diagrame UML si anume:
Class Diagram: este o diagrama UML in care se reprezinta relatiile structurale dintre clasele,
interfetele si tipurile de date ale modelului la care se lucreaza.. Variante ale acestei diagrame sunt
folosite pentru a arata structurile package-urilor folosite intr-un model cu tot cu relatiile dintre
ele.
Use Case Diagram: este o diagrama UML in care se reprezinta relatiile dintre actori si
cazuri de uz (use cases).
Statechart Diagram: este o diagrama UML care reda comportarea dinamica a unui obiect
(obiect activ) la toate nivelele.
Activity Diagram: o diagrama UML care reda comportarea dinamica a unui anumit sistem
sau subsistem, care implica o mai mare interactiune cu user-ul.
Collaboration Diagram: o diagrama UML care descrie felul in care mesajele (procedurile)
sunt schimbate intre diferite obiecte.
Deployment Diagram: o diagrama UML care arata cum un sistem se va desfasura din punct
de vedere fizic intr-un anumit mediu hardware.
Sequence Diagram: analog cu Collaboration Diagram. Care reprezentare se foloseste
depinde de problema luata in considerare (acest tip de diagrama se foloseste in general unde se
iau in considerare subsisteme statice in timp).
Bibliotecile ArgoUML:
• GEF (Graph Editing Framework), inclusa in gef.rar este responsabila pentru reprezentarea si
modificarea grafica a diagramelor oferind si abilitatea miscarii elementelor in subfereastra
diagramelor
• NSUML (NovoSoft UML) reprezinta implementarea Java a specificatiilor limbajului UML
• OCL (Object Constraint Language) folosita pentru generare de cod direct din expresii OCL
Exercitiu:
Sa se reprezinte printr-o diagrama use-case procesul de criticare (cel facut de un critic)
Laborator 3
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.
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 nr 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. De exemplu pt use-case-ul din
figura de mai jos un scenariu ar putea fi: ”John Doe contacteaza sistemul prin telefon si semneaza
o asigurare la masina lui Dacia 1100 pe care tocmai a cumparat-o”.
In figura de mai sus dreptunghiul reprezinta marginile a ceea ce inseamna sistemul.
• 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.
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.
• 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 respectiva functionalitate.
Exercitiu:
Sa se construiasca diagrama folosirii unui bancomat (use case). Mai intai trebuie sa se identifice
toti actorii implicati, iar apoi toate cazurile de uz pentru bancomat, cele principale.
Laborator 4
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
• 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 dntre
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.
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.
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 pt clasele Cerc si Punct pt 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).
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.

D.p.d.v 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.
Laborator 5
Modelare dinamica – Diagramele de stare
Toate sistemele au o structura statica, (descrisa de obicei de diagramele de clase) si un

comportament dinamic care va putea fi descris printr-o serie de diagrame UML cum ar fi
statechart (sau state in unele unelte CASE), sequence, colaboration si activity diagrams.
• diagramele statechart (state): descriu starile pe care un obiect le poate avea pe durata
“vietii” sale si comportamentul obiectului aflat in respectivele stari impreuna cu
evenimentele care au cauzat schimbarea starii
• diagramele sequence: descriu felul in care obiectele comunica si interactioneaza intre
ele, concentrandu-se in special pe notiunea de timp ; descriu felul in care o serie de
mesaje sunt schimbate intre diferite obiecte pentru a realiza o functie
• diagramele collaboration: descriu de asemenea felul in care interactioneaza obiectele,
atentia concentrandu-se mai ales asupra notiunii de spatiu. Intr-un fel s-ar putea
spune ca o astfel de diagrama contine aceeasi informatie ca o sequence-diagram insa
intr-o alta forma.
• diagramele activity: sunt un alt mod de a descrie interactiunile care insa se
cocentreaza pe descrierea muncii (activitatii) obiectelor care schimba mesaje.
!Pentru un sistem nu este obligatorie realizarea tuturor diagramelor mentionate mai sus
(=> este necesara luarea unei decizii pentru alegerea diagramei potrivite functie de aspectul
considerat a fi cel mai important)
Obiectele din cadrul sistemelor interactioneaza, comunica unele cu altele, prin
intermediul asanumitelor mesaje. Un mesaj este de fapt doar un apel al unei functii (operatii) in
care un anumit obiect invoca un altul. Cum comunica obiectele si efectele unei astfel de
comunicari sunt referite ca a fi dinamica unui sistem, adica felul in care obiectele colaboreaza
prin prisma comunicarii si felul cum obiectele isi schimba starea in timpul ciclului de viata al
sistemului.
De obicei diagrmele statechart sunt folosite pentru a descrie comportamentul instantelor
de clase, dar ele mai pot descrie si comportamentul altor entitati cum ar fi: use-cases, actori,
subsisteme, operatii.
Diagramele statechart sunt folosite pentru a ajuta dezvoltatorii sa inteleaga
functionalitatile complexe ale anumitor portiuni din sistemul modelat, aratand toate starile
posibile ale unui obiect si tranzitiile care cauzeaza trecerile de la o stare la alta.
O diagrama de tip statechart arata comportamentul dinamic al claselor (sau al unui
sistem, subsistem) ca raspuns al unor stimuli externi. Acest tip de diagrama modeleaza cursul
dinamic si are multe elemente notationale similare cu o diagrama de activitate.
Orice clasa are una sau mai multe stari, dar nu fiecare clasa va trebui sa fie modelata
printr-o diagrama statechart, ci doar cele care prezinta mai multe stari potentiale pe parcursul
activitatii unui sistem
Principalele elemente ale unei diagrame statechart sunt:
• Starile (states): reprezinta o situatie din timpul existentei unui obiect intr-un anumit
moment (=>starile difera la momente diferite in timp). O stare modeleaza o situatie in
timpul careia, atata timp cat o conditie este satisacuta, un anumit obiect se afla intr-o
anumita situatie sau stare care poate fi o stare statica, de asteptare a unui eveniment
extern sau dinamica (o activitate in progres). O stare poate fi determinata de un singur
atribut al clasei, ca in exemplul de mai jos:
Exemplu: O factura este platita sau nu.

Motorul merge sau nu.
Diagrama de stare pentru o instanta a clasei Factura
Un State are urmatoarele proprietati :

Name:
Stereotype:
Entry-Action: activitate care trebuie executata in momentul in care se intra in state
Exit-Action: activitate care trebuie executata in momentul in care se iese in state
Do-Activity: activitate care trebuie executata in timpul in care obiectul se afla intr-o anumita stare
(Poate fi intrerupta de un eveniment extern)
Incoming: listeaza tranzitiile care aduc obiectul in starea respectiva
Outgoing: listeaza tranzitiile care scot obiectul din starea respectiva
Internal tranzition listeaza toate tranzitiile interne (nu scot un obiect din starea respectiva=>Entry
si Exit actions nu sunt invocate).
• Composite states: un state care poate contine mai multe states (stari) care de data aceasta
nu trebuie sa mai aiba o stare initiala. Tranzitiile (care vin sau pleaca) vor fi conectate
direct de unul dintre substates. Aceste substates sunt intr-o relatie de tip OR, deci daca un
obiect se afla intr-un composite state atunci el va fi in unul din aceste substates.
• Tranzitii: sagetile care reprezinta calea parcursa de un obiect pentru a trece dintr-o stare
(stare sursa) in alta (stare destinatie). De obicei o tranzitie are atasat un eveniment. O
tranzitie este reprezentata drept o sageata orientata de la state-ul sursa la cel destinatie.
Langa aceasta sageata este un string cu urmatorul continut: “nume_tranzitie : trigger
action [guard] / expression_of_action ^ send_clause”.
Trigger: arata, daca exista numele evenimentul care declanseaza tranzitia respectiva. UML nu
necesita neaparat un trigger, daca este definit un guard.
Un eveniment nu este local, deci nu este vazut doar de o instanta a unei clase si este
reprezentat prin numele sau si poate fi de mai multe feluri:
1. SignalEvent. Asociata cu un semnal, acest eveniment este produs de respectivul semnal.
(signal = semnal transmis de regula cu ajutorul unei operatii adresat de regula unui alt
obiect).
2. CallEvent. Asociata cu o operatie a unei clase, acest eveniment este produs de un apel a
acelei operatii. Efectul ar fi ca pasii acestei operatii vor fi executati.
3. TimeEvent. Un eveniment cauzat de expirarea timpului. (timpul se calculeaza incepand
de la producerea ultimului eveniment)
4. ChangeEvent. Un eveniment cauzat de o expresie particulara (a atributelor sau
asocierilor) care devine adevarata..
O eroare poate fi considerata un eveniment. Pentru ca in UML nu exista un element

special de modelare a unei erori ea va fi coniderata un tip de model careia ii vom atasa un
stereotip de tip <<error>>.
Exista si posibilitatea ca o tranzitie sa nu aiba atasata nici un trigger nici un guard. Un
exemplu avem in diagrama de mai jos unde tranzitiile de la o stare la alta au loc automat la
terminarea activitatii interne a starii (Do-Activity).
Guard : este de fapt o conditie care este evaluata ori de cate ori un eveniment are loc.
Evenimentul respectiv poate fi atasat tranzitiei in cauza sau nu. Tranzitia are loc daca aceasta
conditie guard devine adevarata. O conditie de tip guard este evaluata o singura data, la momentul
producerii evenimentului (daca conditia este falsa => evenimentul este pierdut).
Daca nu exista un eveniment atasat tranzitiei ci numai un guard, tranzitia se va face cand expresia
booleana a guardului va deveni adevarata.
Effect: arata, daca exista actiunea care se va face in momentul in care are loc tranzitia. O actiune
este de fapt o abstractie a unei proceduri care poate schimba starea unui model. Daca exista mai
multe actiuni , acestea vor aparea despartite de “ / ” si se vor executa pe rand incepand de la
stanga. Intr-un metamodel UML pot exista mai multe tipuri de actiuni (este atomica si poate fi
executata doar in timpul unei tranzitii):
1. CreateAction. Se creeaza o instanta a unui clase, interface, use-case, signal etc.
2. CallAction. Actiunea de apeleare a unei anumite operatii
3. AssignmentAction. O actiune in care se atribuie o valoare unui atribut sau pointer
(referinta).
4. ReturnAction. O actiune prin care se intoarce o valoare apelantului anterior
5. SendAction. Asociata cu un semnal, aceasta actiune cauzeaza transmiterea
semnalului.
6. TerminateAction. Actiune prin care obiectul care invoca se va autodistruge.
7. UninterpretedAction. Actiune folosita pentru a specifica o actiune specifica unui
imbaj de programare care nu se poate clasifica in alt tip de actiune
8. DestroyAction. Actiune care distruge obiectul tinta.
O actiune este reprezentata intr-o diagrama prin textul care o descrie. Proprietatile unei
actiuni sunt numele, expresia actiunii si limbajul de programare in care a fost scrisa expresia
actiunii.
Check-boxul Concurrent,atunci cand este bifat semnifica faptul ca composite state-ul este format
din doua sau mai multe composite-states cu executie concurenta.
In afara de proprietatile pe care oricare state le are un sub-state mai are si Subvertices care
reprezinta o lista cu toate substate-urile continute
• Pseudostates:
1. Starea initiala (defaultul) punctul de start cand starea obiectului nu are nici o
variabila care sa-l descrie si de asemenea nu realizeaza nici o activitate
2. Branch: folosita pentru introducerea de alternative specificate prin diferite
conditii (guards)
3. Forks: divide secventa de tranzitii in subsecvente concurente (care se executa in

acelasi timp)
4. Join: uneste anumite subsecvente (tranzitii concurente).
5. History states: cateodata avem nevoie ca un obiect sa intre intr-o stare de
asteptare, iar apoi in momentul in care un anumit eveniment are loc, obiectul respectiv sa
reintre in ultima stare dinainte de asteptare. Aceasta situatie este modelata folosind
history states
6. Starea finala: reprezinta elementul care finalizeaza diagrama (intr-o diagrama
poate sa existe sau sa nu existe)
Diagrama de stare a unui ascensor
Diagrama de stare a unei stive

Laborator 6
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.
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.
Pt use-case-ul admitere facultate Pt use-case-ul scoala de soferi

Laborator 7
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.
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 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.
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.
Laborator 8
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.
O diagrama de secventa este foarte simplu de citit, ea ilustrand succesiunea in care

obiectele isi vor juca rolul inr-un anumit scenariu precum si diferitele apeluri intre aceste obiecte.
Asadar, pentru citirea unei diagrame de secventa se incepe de la coltul din stanga sus, unde va fi
instanta care va incepe secventa. Apoi se urmeaza sagetile, sau mesajele, de sus in jos, tinandu-se
cont de faptul ca return messages sunt optionale.
Interactiunea dintre obiecte este descrisa specificand diferitele tipuri de mesaje schimbate
de acestea. Mesajele sau stimulii pot fi de mai multe feluri (simple, sincrone, asincrone), care
difera in reprezentare prin forma varfului sagetii care este simbolul grafic pentru un mesaj.
Clasele active sunt folosite sa modeleze comportamentul concurent al lumii reale, si sa
creeze un model care foloseste resursele sistemului cat de eficient posibil.. O clasa activa este o
clasa care poseda un fir de executie si poate initia si controla o activitate. O clasa activa (respectiv
un obiect al acestei clase) isi executa operatiile in paralel cu alte obiecte active si initiaza actiuni
de una singura (prin propriul cod sau prin prin trimiterea mesajelor altora).
In contrast cu clasele active sunt clasele pasive, care sunt toate clase “normale” in
sistem. Un obiect pasiv (a unei clase pasive) este capabil sa execute numai cand alte cateva
obiecte (pasive sau active) executa cateva operatii pe el (ii trimite un mesaj).
Asadar dupa cum am vazut obiectele pot fi de doua tipuri: active si pasive dupa tipul
claselor de care apartin.
Se poate specifica obiectul care are controlul prin bifarea check-boxului Active. In acel
moment se va schimba si reprezentarea grafica a obiectului (o bordura mai groasa plus linia vietii
se schimba din linia punctata intr-un dreptunghi).
In Poseidon, toate tipurile de mesaje (stimuli), in afara de create stimuli, pot fi trimisi la
obiectul care le initiaza..
Cand un mesaj este primit se porneste o activitate in obiect. Vom spune ca obiectul
respectiv se va activa. O activare arata perioada de timp in timpul in care un obiect va face o
actiune (operatie implementata in clasa din care provine) sau asteapta executia unui alt obiect
catre care a trimis un mesaj mai devreme. O activare este reprezentata drept un mic dreptunghi
avand partea de sus aliniata cu punctul in care se initiaza activitatea si cu partea de jos aliniata cu
punctul in care se termina activarea. Dreptunghiul acesta numit bara de activare reprezinta de fapt
durata executiei mesajului. Cand un obiect primeste un stimul (mesaj), o activare existenta este
terminata la coada sagetii care pleaca. Exista insa si doua exceptii de la aceasta regula, deci cand
obiectul care trimite mesajul va ramane activ:
• cand mesajul trimis este asincron (sent stimulus)
• cand obiectul care transmite mesajul este activ (are bifat checkboxul respectiv in
tabul Properties)
Ca si in diagramele de colaborare mesajele pot avea numere de secventa insa acestea sunt
rareori folosite deoarece succesiunea mesajelor este data explicit intr-o diagrama de secventa.
Crearea unui raport cu privire vanzarea de Cd-uri la un magazin de profil.
Obiectul aServlet trimite un mesaj unei instante a clasei ReportGenerator numita gen.
Mesajul este etichetat cu generateCDSalesReport, ceea ce inseamna ca ReportGenerator va
implementa handler-ul acestui tip de mesaj; cdId este o variabila trimisa in cadrul mesajului (=>
se afla intre paranteze). La primirea mesajului gen trimite un mesaj de tip create stimulus catre
clasa CDSalesReport (=> se creeaza o instanta a acestei clase numita aCDReport care este
returnata lui gen printr-un return stimulus). Apoi instanta gen face apeluri catre acest aCDReport,
caruia ii paseaza parametrii la fiecare apel (data, saptamana, vanzari). La sfarsitul secventei, gen
va returna acest aCDReport catre aServlet.
Laborator 9
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
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
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).
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:
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.
Laborator 10
Caz de studiu
In urmatoarele doua laboratoare ne propunem sa realizam modelul unei aplicatii care sa

ruleze in cadrul unui bancomat si sa realizeze principalele functii ale acestuia (retragere bani si
citire sold), incercand abordarea acestui model din mai multe puncte de vedere sau altfel spus
vom prezenta mai multe viziuni (vederi) asupra proiectului realizat.
Asadar viziunile (vederile) arata diferite aspecte ale sistemului modelat. Numai definind
un numar de viziuni, fiecare aratand un aspect particular al sistemului se poate construi imaginea
completa a sistemului. Privind sistemul prin viziuni diferite este posibila concentrarea pe un
anumit aspect al sistemului la un moment dat.
Fiecare vedere este descrisa intr-un numar de diagrame continand informatie care descrie
un aspect particular al sistemului. Exista si o mica suprapunere, astel incat o diagrama poate face
parte din mai multe viziuni. O diagrama, facand parte dintr-o anumita vedere trebuie sa fie destul
de simpla pentru a fi usor de inteles si a fi coerenta cu celelalte diagrame si viziuni, scopul
principal fiind acela de a contura o imagine clara si completa a sistemului incluzand toate
functionalitatile pe care acesta le va avea.
In limbajul UML sunt definite urmatoarele tipuride viziuni:
• Use-case view: vederea centrala (pe baza ei se vor contura celelalte vederi)
aratand functionalitatea unui sistem asa cum este perceputa de actorii externi (cei care
interactioneaza cu sistemul); aceasta vedere este descrisa de obicei prin diagrame de tip use-
case si activity insa se pot folosi orice tip de diagrame care ne-ar putea ajuta sa ne atingem
scopul. Aceasta vedere este pentru clienti, designeri, dezvoltatori, si inginerii de testare, la
sfarsitul proiectarii trebuie ca sistemul sa indeplineasca toate functionalitatile care au fost
propuse in aceasta vedere.
• Logical view: o vedere aratand cum functionalitatea va fi implementata in cadrul
unui sistem, in contrast cu Use-case view, aici vom privi in interiorul sistemului descriind atat
structura statica (clase, obiecte, relatii implementate in diagrame de tip class si objects) cat si
cea dinamica a sistemului (mesaje transmise intre obiecte in momentul functionatii sistemului
implementate in diagrame de tip state, sequence, collaboration si activity). Aceasta vedere
este pentru designeri si dezvoltatori.
• Component view: o vedere aratand organizarea si structura componentelor (de
cod) si relatiile (dependentele) dintre acestea. Aceasta vedere este pentru dezvoltatori si va fi
implementata cu ajutorul diagramelor de tip component.
• Concurrency view: o vedere care se va concentra pe problemele de comunicare si
sincronizare care sunt prezente in sistemele concurente in timp real. Aici se va prezenta
modul in care sistemul va fi divizat in procese si procesoare, o astfel de vedere va fi folosita
de dezvoltatori si de cei care se ocupa cu integrarea sistemului si va consta din diagramele
pentru descrierea structurii dinamice a sistemului.
• Deployment view: o vedere aratand modul in care va fi desfasurat sistemul in
arhitectura fizica (formata din computere si alte sisteme hardware). Aceasta vedere este
pentru dezvoltatori, integratori si testeri si va fi implementata prin diagramede tip
deployment.
Inginerie software - proiecte
1. Aplicatie folosita in cadrul procesului de admitere la o universitate. Vor trebui

acoperite : gestionare a bazelor de date de date, calcularea mediilor de admitere functie de
diferitele criterii (pe facultati), ordonarea acestor medii...
2. Administrarea unui parc de automobile. Informaţiile relative la un automobil sunt: nr.

de locuri, puterea, marca, nr. de înmatriculare, tipul de carburator (benzină sau motorină),
natura (break, berlină, decapotabilă). Se va permite intrarea unei maşini, ieşirea unui maşini,
înlocuirea unei maşini cu alta de acelaşi model (având alt număr de înmatriculare).
3. Administrearea funcţionarii unei staţii meteorologice. Se va permite citirea

temperaturilor din oră în oră, precum şi cantităţile zilnice de precipitaţii dintr-o anumită lună a
anului. Apoi se va permite afişarea temperaturilor maxime (împreună cu ziua şi ora asiciată),
temperatura minimă (cu ziua şi ora asociată), lista zilelor, ordonată descrescător în funcţie de
cantitatea de precipitaţii, media precipitaţiilor zilnice dintr-o anumită lună a anului.
4. Aplicatie de gestionare a unui concurs sportiv. Aceasta va permite stocarea într-un

fişier a datelor sportivilor şi a punctajelor acestora. Aplicatia va trebui modelata astfel incat sa
acopere toate detaliille organizatorice a acestui concurs, inclusiv masa, cazarea sportivilor,
vanzarea de bilete s.a.m.d.
5. Aplicatie folosita in cadrul procesului de recensamant, la nivel de tara. Aceasta va

permite crearea de diferite statistici referitoare la locul naşterii unor persone, varsta populatiei
dintr-un anumit judet sau localitate s.a.m.d.
6. Modelarea unui magazin virtual, care sa aiba toate facilitatile oferite cumparatorilor
dar si un mod de administrare usor prin logare prin internet folosind semnaturi digitale. In plus
se cere modelarea unui subsistem care sa verifice zilnic cursurile BNR a principalelor monede
(dolarului + euro), precum si site-urile principalilor furnizori pt colectarea anumitor date aflate
pe o anume pagina dinamica.
7. Aplicatie pentru gestionarea unei biblioteci. Se cere administrarea personalului,

cartilor si a cititorilor. Personal: date personale, salariu, incadrare, vechime, programde lucru,
planificarea pt concedii etc. Carti: titlu, autor, ISBN, frecveta imprumautarii, ultima zi a
inapoierii etc. Cititori: date personale, domeniu de interes, etc.
8. Agenda telefonica, lucrand cu baze de date, accesibila pe Net, care sa permita

principalele operatii suportate de o agenda telefonica (introducere inregistrare, stergere
inregistrare, modificare inregistrare, cautare inregistrare, vizualizare inregistrari agenda). In
plus agenda va avea o sectiune pt administrare care seva face prin specificarea unui username
si a unei parole.
9. Aplicatie pentru rulare de fisiere audio, asemanatoare Winamp. Cerintele sunt: sa aiba
prinipalele functionalitati (butoane Play, Stop, ….), sa includa un Playlist unde se pot introduce
doar fisiere audioacceptate, sa se poata face cautarea in playlist dupa cuvinte cheie etc.
10. Aplicaţie pentru administrarea unei benzinării, deci care să ajute atât la gestionarea
stocurilor de benzină (mai multe tipuri), motorină etc, cât şi să înregistreze plata, eventual in
orice fel de monedă… Totodată se doreşte o administrare a angajaţilor şi a o rarului lor zilnic şi
săptămânal.
!!! Toate proiectele chiar si care nu specifica vor trebui sa includa folosirea unor baze
de date (sau fisiere externe), folosirea de interfete grafice (eventual pagini html), iar
diferitele componente sa ruleze pe masini diferite. Fiecare model va trebui sa includa
diagrame de tip Use-Case, Class, Activity, Sequence, State, Deployment.

Introducere in Uml

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Introducere in Uml

Încărcat de

Drepturi de autor:

Formate disponibile

Inginerie Software Candea Radu

Autor: Radu Candea

The Unified Modeling Language (UML)

Interchange (XMI), Scalable Vector Graphics (SVG), Object Constraint Language

• Sequence diagrams and Collaboration diagrams: descriu secventa de mesaje

• Activity diagrams: prezinta algoritmi sau data-flow.

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

ArgoUML - unealta de modelare

In figura de mai sus dreptunghiul reprezinta marginile a ceea ce inseamna sistemul.

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

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

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

Interfete – sunt un fel de clase restrictionate in a contine doar operatii nu si atribute.

Modelare dinamica – Diagramele de stare

Toate sistemele au o structura statica, (descrisa de obicei de diagramele de clase) si un

Exemplu: O factura este platita sau nu.

Diagrama de stare pentru o instanta a clasei Factura

Un State are urmatoarele proprietati :

O eroare poate fi considerata un eveniment. Pentru ca in UML nu exista un element

3. Forks: divide secventa de tranzitii in subsecvente concurente (care se executa in

Diagrama de stare a unui ascensor

Diagrama de stare a unei stive

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

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

Pt use-case-ul admitere facultate Pt use-case-ul scoala de soferi

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

reprezentata ca un mesaj sau poate fi considerata implicita la terminarea operatiei care se

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

O diagrama de secventa este foarte simplu de citit, ea ilustrand succesiunea in care

Crearea unui raport cu privire vanzarea de Cd-uri la un magazin de profil.

Component and Deployment Diagrams

In urmatoarele doua laboratoare ne propunem sa realizam modelul unei aplicatii care sa

Inginerie software - proiecte

1. Aplicatie folosita in cadrul procesului de admitere la o universitate. Vor trebui

2. Administrarea unui parc de automobile. Informaţiile relative la un automobil sunt: nr.

3. Administrearea funcţionarii unei staţii meteorologice. Se va permite citirea

4. Aplicatie de gestionare a unui concurs sportiv. Aceasta va permite stocarea într-un

5. Aplicatie folosita in cadrul procesului de recensamant, la nivel de tara. Aceasta va

7. Aplicatie pentru gestionarea unei biblioteci. Se cere administrarea personalului,

8. Agenda telefonica, lucrand cu baze de date, accesibila pe Net, care sa permita

S-ar putea să vă placă și