Академический Документы
Профессиональный Документы
Культура Документы
Introducere in UML
Laborator 1
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.
Inginerie Software Candea Radu
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
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
• Statechart diagrams: prezinta starile pe care le pot avea obiectele in cadrul unui sistem.
• Component diagrams: descriu componentele implementate (Ex: source & object files)
Laborator 2
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:
Inginerie Software Candea Radu
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
Inginerie Software Candea Radu
.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)
Inginerie Software Candea Radu
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
Inginerie Software Candea Radu
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”.
• 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).
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
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>>).
Inginerie Software Candea Radu
• 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.
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
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.
Laborator 5
• 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:
Inginerie Software Candea Radu
• 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..
Inginerie Software Candea Radu
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)
Inginerie Software Candea Radu
Action diagram
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
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
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
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
Inginerie Software Candea Radu
Laborator 8
Sequence Diagram
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.
Inginerie Software Candea Radu
Laborator 9
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:
Inginerie Software Candea Radu
• 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:
Inginerie Software Candea Radu
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
Inginerie Software Candea Radu
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:
Inginerie Software Candea Radu
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.
Inginerie Software Candea Radu
Laborator 10
Caz de studiu
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.
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.