uml – scurtă prezentare

8/14/2019 UML – Scurtă Prezentare

http://slidepdf.com/reader/full/uml-scurta-prezentare 1/346

UML – Scurtă prezent



- Ce este UML (Unified Modelling Language)?

- Unde se poate folosi UML?

- Nota ţii ş i meta-modele

- Diagrame UML

- UML - limbaj cu reguli descriptive sau prescriptive

- Semnifica ţia UML



Ce este UML (Unified Modelling Language)?

UML este un limbaj de modelare grafică , care ajutădesign-ul sistemelor software, în particular al sist

construite folosind stilul orientat-obiect (OO).

Obs . Problema limbajelor de programare este că nu suficient de ridicat de abstractizare pentru a uşura ddesign.

Obs . UML e controlat de OMG (Object Managemconsor ţiu deschis de companii. OMG a fost format pstandarde ce suport ă interoperabilitatea, în interoperabilitatea sistemelor orientate-obiect.

Obs . A apă rut pe piaţă în ianuarie 1997. Sunt acreditaUMLGrady Booch, Ivar Jacobson ş i Jim Rumbaugh (T



Unde se poate folosi UML?

UML se poate folosi în 3 moduri:

1) ca schi ţă (sketch)

2) ca plan (blueprint)

3) ca limbaj de programare



1) UML ca schiţă . Dezvoltatorii folosesc UML pencomunice anumite aspecte ale sistemului.Schiţele se pot folosi în forward-engineering, care

diagrama UML înainte de a

reverse-engineering, care diagrama UML dintr-un cideea de a ajuta la în ţelegere

Obs . La schiţe, esen ţialul este selectivitatea.

La schiţarpun în evidenţă doar anumite chestiuni, nu tot codureverse , se explică doar anumite pă r ţi ale sistemului toate clasele).



2) UML ca plan. Se foloseş te tot în direcţiileforward ş i

In direcţia forward , planurile (blueprints) sunt dedesigner, a c ă rui sarcină este s ă construiască un

pentru ca un programator s ă scrie codul.Obs . Un designer poate desena planuri doar pentru o asistemului.

În direcţia reverse , planurile se folosesc pentru a predetaliate despre cod, fie în documente (clasice), fie

grafic interactiv. Planurile pot ar ă ta fiecare detaliu despformă grafică , care e mai u şor de înţeles de dezvoltator

Planurile necesită instrumente mult mai sofisticate defolosesc instrumente CASE (Computer Aided Softwspecializate. Instrumentele care pot face atât inginerie

reverse se numesc intrumente round-trip.Concluzie . Diferenţa dintre UML ca schiţă ş i UML cfaptul că schiţele sunt incomplete, iar planurile comprehensive, reducând uneori programarea lamecanică .



3) UML ca limbaj de programare. În acest caz, dezvoltatodiagrame UML care sunt compilate direct în cod exedevine codul sursă . E clar că utilizarea în acest mod a instrumente sofisticate (ingineria forwardş i reverse nu sens

şi UML si codul surs

ăreprezint

ăacela

şi lucru).



Nota ţii ş i meta-modeleUML, în stadiul actual defineş te o nota ţie ş i un meta-mod

Nota ţia este sintaxa grafică a limbajului de modelare.

Cât de riguros e un limbaj de modelare grafică?Chiar dacă se poate demonstra c ă un program îndeplinspecificaţie matematică (dată de domeniul metodelor poate demonstra c ă specificaţia matematică îndeplireale ale sistemului.Majoritatea limbajelor de modelare grafică nu suntapeleaz ă , cu precădere, la intuiţie, dar se dovedesc (totfolositoare.

Metodologiş tii caută că i de îmbună tăţ ire a rigorii msacrifica gradul de utilitate a limbajelor de modelare graO soluţie ar fi meta-modelul: o diagramă , de obicei clasă (class diagram) care defineş te conceptul limbajul



Exemplu de meta-model



Diagrame UML



Este UML un limbaj cu reguli descriptiveprescriptive ?

Un limbaj cureguli prescriptivee controlat de o organiza

stabileş te ce e ş i ce nu e legal în limbaj.Un limbaj cureguli descriptivee cel în care îi înţelegi regla modul cum foloseş te lumea limbajul în practică .

Limbajele de programare tind să aibă reguli prescriptivecomitet de standardizare, în timp ce limbajele naturale tind să aibă reguli descriptive care sunt stabilite prin convUML este un limbaj destul de precis ş i ne-am aş tepta prescriptive. Dar UML e considerat a fi echivalentul softw(blueprints) în alte discipline de engineering ş i aceste pnotaţii prescriptive (notaţiile au fost acceptate prin convUML e aşa de complex încât standardul e deschis diverselor interpretă ri.

Obs . Deş i standardul UML e sursa principală de informapoate s ă nu fie singura sursă .



UML - limbaj cu reguli descriptive sau pres(continuare)

Când privim o diagramă UML, trebuie avut în vedere

general în UML a acela că orice informaţie poate fi elimanumită diagramă .

Eliminarea poate fi: general ă – ascundem toate atrib

specific ă – nu ar ă tăm aceste 3 c

De aceea, într-o diagram ă nu se poate deduce nimic dinmultiplicitatea lipseş te, nu se poate deduce ce valoare are)

Concluzie. E important să nu se pun ă accentul în a avdacă e folosit pentru schiţe sau planuri, ci mai importan

un bun design pentru sistem: “Mai bine ilegal, decât să radar legal”. (Trebuie să fie legal UML ca limbaj de progva rula corect!)



Semnifica ţia UML

Ce semnificaţie are UML în afara lumii meta-modelului • Nu există nicio definiţie formală care arate cum se maun anumit limbaj de programre.• Nu putem privi o diagramă ş i să spunem exact cum (deş i ne putem face o idee, ce poate fi suficientă îconcrete)

În multe locuri, diferite diagrame pot fi folositoareş i nu tr

folosi diagrame non-UML dacă nicio diagramă UML nevoii utilizatorului.



Exemplu: Mai jos e data o diagramă care arat ă ecraninterfaţă utilizator ş i cum ne putem muta (comuta) între e(vezi http://c2.com/cgi/wiki)



Sintaxa ş i semanticlimbajului de modelare



Alfabet ş i cuvinte

Alfabetul defineş te cele mai mici pă r ţi ale limbajului; UMLsimboluri (dreptunghiuri, liniiş i alte elemente grafice) ş i dinş iCuvântul este cea mai mic ă unitate semantică de limbaj. Ungrup format din elementele alfabetului, care are un înţeles.

În UML, cuvintele sunt grupate în două categorii mari:• entit ăţ i sau concepte – desemnează o serie de abreprezentate prin simboluri etichetate cu nume;• rela ţ iile dintre entit ăţ i – desemneaz ă tipurile de legă turi car

entităţ i. Ele sunt reprezentate prin linii de legă tur ă între simnume.Cuvintele limbajului alcă tuiesc vocabularul limbajului.



Propozi ţii ş i paragrafe

Propozi ţ iile UML suntfragmente de diagrame sau diagrame s

• O companie de asigur ă ri are contract de asigurare cu o• O persoană are un contract de asigurare cu o companie

Paragrafele UML se numesc diagrame .

Sintaxa limbajului UML implică diagrame .

Semantica limbajului UML se bazează pe paradigma orient ă!



În UML, diagramele fac parte din două categorii:

• Diagrame statice sau structurale - descriu structura, sistemului informatic, componentele executabile ale sifizice de execuţie ş i nodurile de stocare a datelor. Din afac parte diagrame ale claselor, ale obiectelor, ale cazuale componentelor ş i diagrame de exploatare.

• Diagrame dinamice sau comportamentale – descriuş i interacţiunile dintre diverse entităţ i ale sistemuluaceast ă categorie, fac parte diagramele de secven ţă , dstare ş i de activitate.



A) Modelare structural ă (modelare static

• Se refer ă la vizualizarea, la specificarea, la construirea şaspectelor statice ale unui sistem, adică la relaţiile invariante d

unui sistem. Din punct de vedere al modelă rii sistemelor orienperspectiva UML, aspectele statice sunt: clasele ş i relainterfe ţele , topologia hard necesar ă execuţiei aplicaţiei.

A1) Diagrama claselor (Class Diagram)

• Descrie structura unui sistem în general. În componenstereotipuri ş i relaţiile dintre acestea. Acest tip de diagrame

întâlnit în modelarea sistemelor orientate pe obiecte.

A2) Diagrama obiectelor (Object Diagram)

• Descrie structura unui sistem la un anumit moment . Acest tio variantă a diagramei claselor, care, în locul unei clase, pinstanţe ale ei ş i este formată din obiecte ş i relaţiile (legă turfolosită în exemplificarea unei diagrame a claselor de cpermiţând vizualiză ri statice ale instanţelor actuale ş i ale relaţiil



A3) Diagrama cazurilor de utilizare (Use Case Diagram)

• Descrie func ţ ionalitatea unui sistem.

• Prezintă actorii externi, cazurile de utilizare identificate nvedere al actorilor (comportamentul sistemului, aşa cum utilizatorii lui), nuş i din interior, precum ş i relaţiile dintre autilizare.

• Un actor poate fi orice sau oricine interacţionează cu sirecep ţionează mesaje de la sistem sau schimb ă informaţii cu a

• Actorul are un rol în cadrul unui sistem, nu este un utiacestuia, ş i din acest motiv, el este o entitate (o clas ă ), nu o iutilizare este ini ţ iat mereu de un actor ş i furnizează o valoare a

• Diagramele cazurilor de utilizare reflectă modul static de vizualiz

de utilizare asupra sistemului (diferite tipuri de relaţii între cazurş i modul de organizare ş i de modelare a comportamentului



A4) Diagrama componentelor (Component Diagram)

• O diagram ă a componentelor, cunoscută ş i sub numele implementare , descrie structura fizic ă a codului în termenicod ş i relaţiile dintre acestea.

• Acest tip de diagramă realizează o mapare de la view-ul staticomponentelor . O componentă poate s ă conţină un cod suformă binar ă sau executabilă . O componentă se mapeaz ă , de mai multe clase, interfeţe sau colabor ă ri; din aceastăcomponentelor are legă tur ă cu diagrama claselor .

• Diagramele de componente reflectă vederea static ă de implsistemului.

5) Diagrama de desf ăţ urare (Deployment Diagram)

• Diagrama de desf ăş urare indică arhitectura fizic ă pe caresistemul, calculatoarele, device-urile (noduri ale sistemului)şele.



B) Modelare dinamic ă (modelare comportamentalB1) Diagrama de interac ţiune (Interaction Diagram)

• Descrie interac ţ iunile în timp între obiecte, rela ţ iile ş i mesa între acestea. Diagramele de interac ţiune reflectă vederea dinam

de proces .• Pot fi: a) Diagrama de secven ţă

b) Diagrama de colaborare

a) Diagrama de secven ţă (Sequence Diagram)

- Prezintă colaborarea dinamică dintre un numă r de obiecte, pusecven ţ e de mesaje trimise între acestea pe m ăsura scurgerii t- Au două axe: timpul , pe axa verticală , ş i setul de obiecte , pe

a) Diagrama de colaborare (Collaboration Diagram)- Este o diagramă de interacţiune, dar, pe lângă interacţiun(schimbul de mesaje), prezintă ş i obiectele ş i legă turile dintre edecidem ce tip de diagramă trebuie folosit pentru a ilustra o invedere aspectul cel mai important de evidenţiat.

Obs. Se vor folosi diagramele de secven ţă dacă cel mai imtimpul sau secven ţa de mesaje ş i vom folosi diagramele de cotrebuie evidenţiat contextul .



B2) Diagrama de stare (State Diagram)• Descrie ciclul de via ţă al unui element (al obiectelor, al ssistemelor), prin specificarea stă rilor în care se găse ş te evenimentelor (mesaje, erori, condiţii care devin adevă rate) care

(tranziţie).Obs. Este indicat să se construiasc ă diagrame de stare numaisistem care au un num ă r de stă ri bine definit ş i în care comeste influenţat de acestea. Aceste diagrame intr ă în modurile dş i de proces asupra sistemului.

B3) Diagrama de activitate (Activity Diagram)• Prezintă activităţ ile ş i responsabilităţ ile elementelor sistemului• Diagramele de activitate au ca elemente constitutive st ă ri deStates ) ş i mesaje care vor fi trimise sau recepţionate ca parte a

• Reflectă vederea dinamic ă de design ş i de proces ş i sumodelarea funcţiilor sistemului.



Sec ţiuni (Views)

Sec ţ iunile UML sunt perspectivele arhitecturale sau modur(arhitectural views). Din punct de vedere gramatical, ele sunmulte paragrafe.

Obs. Un model UML descrie ce trebuie să facă un sistemimplementeze sistemul.

Sec ţiunile UML sau modurile de vizualizare sunt grupuri deadreseaz ă unei anumite mulţimi de concepte (entităţ i).

Modelul capturează cunoş tinţe ş i le comunică sub formă de msau, pe scurt, “view” (arhitectural views).

Fiecare view focalizează aten ţia echipei de realizatori asupra probleme ş i de aspecte privind subiectul tratat ş i se adreseaspeciale de firme sau de instituţii.

Un sistem poate fi descris luând în considerare urmă toarele aspe• func ţ ional - este descris ă structura statică ş i comportamentul d• non-func ţ ional - necesarul de timp pentru dezvoltarea sistemu• organizatoric - organizarea lucrului, maparea modulelor de co



Elementele care construiesc un view se numesc elemente de vizelements ).

Fiecare view este descris folosind un numă r de diagrame carreferitoare la un anumit aspect particular al sistemului.

Aceste view-uri se acoper ă unele pe altele, deci este posibdiagramă să facă parte din mai multe view-uri.



V1) Modul de vizualizare cazuri de utilizare(The use-case or user view)

• Acest view surprinde funcţionalitatea sistemului, aşa cum esteactorii externi care interacţionează cu sistemul, precum ş i de ude diferiţi membri ai echipei realizatoare sau de alte sisteme.

• În componenţa lui intr ă diagramele cazurilor de utilizarestatică a aspectului funcţional ş i ocazional.

• Se pot folosi ş i diagrame de activitate pentru a încapsula funcţionalităţ ii.

• Cei interesaţi de aceast ă perspectivă sunt clien ţii, designeriicei care vor testa ş i vor valida sistemul realizat.



V2) Modul de vizualizare structural sau logic sau design(The structural or logic or design view)

• Se refer ă la cerin ţ ele func ţ ionale ale acestuia, adic ăasigurate de sistem utilizatorilor să i.

• Vizualizarea logică tratează din interior sistemul ş i descrie atâa acestuia, formată din clase, obiecte ş i relaţii, cât ş i colaborurma schimbului de mesaje între obiecte, pentru a realiza funcţio

• Structura statică

este descrisă

de diagramele de clasă ş

iinclud elementele ş i rela ţiile care alcă tuiesc sistemul.

• Pentru modelarea dinamicii sistemului, se vor folosidiagramsecven ţă , de colaborare sau de activitate .

• Cei care sunt interesa ţi de acest tip de vizualizare a sistemuluidezvoltatorii .



V3) Modul de vizualizare componente sistem sau implementare(The implementation or component view)

• View-ul componentelor se concentrează pe descrierea comimplementează sistemul, dependen ţele care există între ele, acestora, precum ş i rezolvarea unor probleme legate de reutilizcodului, informaţii administrative, cum ar fi un desf ăş ur ă tdezvoltare.• Este folosit de dezvoltatorii sistemului, iar în componenţa sa intcomponente , care descriu cum este implementat sistemul.

V4) Modul de vizualizare comportamental sau dinamic sau proces sauconcuren ţă (The behavioral or dinamic or process or concurent view

• Acest mod de vizualizare ia în considerare cerinţele de fiabilitate, de utilitate, etc.• Pentru descrierea comportamentului ş i a dinamicii sistemdiagramele de stare , de secven ţă , de colaborare ş i de activitat

• În reprezentarea acestui mod de vizualizare a sistemuluidiagramele de implementare (ale componentelor).• Cei interesaţi de o astfel de vizualizare a sistemului suninterogatorii de sistem .



V5) Modul de vizualizare desf ăş urare sau mediu(The deployment or environment view)

• În acest mod de vizualizare sunt surprinse desf ăş urarea fiziccalculatoare ş i ce tipuri de device-uri (noduri) vor fi folosite pesistemului, cum sunt acestea conectate, precum ş i ce componvor executa în fiecare nod.• Acest tip de vizualizare este reprezentat cu ajutorul undesf ăş urare , care indică modul de implementare a sistemului.poartă etichete care specifică repartizarea pe tipuri de activ

despre procesele executate în noduri.• De acest tip de vizualizare sunt interesaţi dezvoltatorii ,sistem , precum ş i cei care realizează testarea sistemului.



Documente (Modele)

Un document este format dintr-un numă r de sec ţiuni care dcomun ş i pot fi că r ţi, articole etc.

Documentele UML suntmodel e . Un model este o reprezentaView-urile (secţiunile) sunt grupate formând modelul (documesistemului studiat.

Pentru paradigma de modelare UML, cel mai adecvat este moda sistemului dirijat de cazurile de utilizare, centrat pe arhiteceste iterativă sau cascad ă .



Pachete (Packages)

Un pachet reprezintă un mecanism de grupare a elementelor de

În UML, un pachet defineş te un mecanism de organizare a elemlegate semantic. Rezultă că un element de modelare nu poamulte pachete, dar un pachet poate importa elemente de mpachete, iar după import le consider ă ca ş i când ar fi proprietate

Putem stabili relaţii între pachete, dar numai între tipuri, n(pachetele nu au semantic

ădefinit

ăde instan

ţe).

Un pachet poate s ă aibă vizibilitate , ca ş i clasele, prin camodalitatea prin care alte pachete pot s ă -i acceseze con ţinutul.

Un pachet poate s ă aibă o interfaţă care îi redă comportamentul



Note (Notes)

O not ă cuprinde ipotezele ş i deciziile aplicate în timpul analize

Notele sunt corespondentul comentariilor din limbajele de progNotele pot conţine orice informaţie, inclusiv fragmente de cod documente, ş i se pot folosi în orice tip de diagrame. Ele se rdreptunghi cu colţul dreapta sus îndoit, în interiorul că ruia se află

Nota este ata şată unui element dintr-o diagramă printr-o linie pu

O notǎ poate s ă nu fie conectată , dacă aceasta se refer ă la între



Stereotipuri (Stereotypes)

Stereotipul este un concept introdus în UML, care permiteextindde bază pentru a crea noi elemente .

Un stereotip reprezintă un înţeles specific asociat unui elemenprintr-un cuvânt între paranteze unghiulare duble (“<< >>”), dedesubtul numelui elementului asociat.

Obs. Un stereotip transformă un element în altul cu un înţeles no

Exemplu. Dacă se ata şează stereotipul <<table>> clasei Exreprezenta o baz ă de date tabelar ă .



Reprezentarea grafic ă a elementelor de modela



Reprezentarea grafic ă a elementelor de modelare (cont



Concepţiiş i princip

orientate-obiect



CLASE, OBIECTE, INSTANŢE

O clas ă descrie structura ş i comportarea unei mulţ

similare.

Un obiect este o instan ţă prezentă la rulare ş i care pentru varibilele instanţei; se comportă conform protoco

Clasă (class) Obiect (Ob

Class Objec«instance of »



ATRIBUTE, OPERAŢII, RESTRICŢII, R

(Attributes, Operations, Constraints, Relati

Principiul încapsul ă rii (encapsulation) : Clasele combinopera ţii într-o singur ă unitate. Atributele sunt accesibintermediul operaţiilor (adică indirect ).

• Atribute: definesc structura obiectelor, i.e. componentele lo

sau datele con ţinute în ele•Opera ţ ii : descriu comportarea (behaviour) obiectelor; termenii servicii , metode sau (eronat) proceduri sau func ţ ii

•Restric ţ ii : condiţiile, cerinţele ş i regulile pe care obiectelesatisfacă

•Rela ţ ii : de moş tenire (inheritance), asociere ş i de asem ăna



Pe de o parte, în timpul analizei ş i design-ului, clasele sunadică se iau în considerare propriet ăţ ile ş i relaţiile.

Pe de alt ă parte, diagramele use case ş i altele sunt foloreprezenta interac ţiunea dintre clase ş i să simulezselectate. În loc de clase, aceste diagrame folosesc obiectreprezint ă precum clasele (doar c ă sunt subliniate), cu de a introduce valori pentru atribute.

Numele instan ţei

Numele atributelor

Num

Valori



Identitatea obiectelor

Principiul identit ăţ ii obiectelor : Fiecare obiect e prin definde toate celelalte obiecte, independent de valorile concrete sale.



Principiul coerenţei

Principiul coeren ţ ei : Fiecare clasă trebuie să fie respon(exact) un aspect (logic) al întregului sistem. Proprietăţaceast ă arie de responsabilităţ i trebuie grupate într-o singudisipate în mai multe clase. Mai mult, o clasă nu trebuproprietăţ i care nu sunt în aria ei de responsabilitate.

Responsabilităţ ile trebuie formulate succintş i în modul gene



Taxonomie ş i moş tenire (inheritanc

Principiul mo ş tenirii : Clasele pot reprezenta specializă ri ai.e. clasele pot fi organizate ierarhic ş i “moş tenesc” (inherit)claselor situate deasupra; la nevoie, pot fi suprascrise (overeliminate.

Principiul substitu ţ iei : Obiectele din subclase pot fi întotd în locul obiectelor din supraclasa(e).

Mo ş tenirea = reutilizarea propriet ăţ ilor

Rela ţ ia de mo ş tenire e reprezentat ă printr-o săgeată ,

punctând pe supraclas ă .

Evita ţ i mo ş tenirea dacă aveţi alternative.



Exemplu (moş tenire simplă )

Obs. Operaţiile

trebuie să fie oGeomFigure , doar îdevin operaţii conc

Obs. Operaţia setPimple-menta inGeo

Clasa GeomFigure e o generalizare a clasei Circle , ş i claspecializare a clasei GeomFigure.



Moş tenire: restricţiiş i probleme

Principiul responsabilit ăţ ii restric ţ iilor : O subclasă n

includă nici o restricţie asupra proprietăţ ilor supraclasei.



Clase abstractePrincipiul claselor abstracte : Clasele pentru care nconcretă nu poate fi creată se numesc clase abstracte .

ClaseIns



Asocieri

O asociere e o relaţie între diferitele obiecte ale uneia sauclase.

O asociere primeş te un nume ş i o specifica ţ ie numeric ă

care arat ă câte obiecte dintr-o parte a asocierii sunt asoobiecte din cealaltă parte.

Se pot ad ăuga ş i nume de roluri, care descriu semnificaţia c

Obs . Dacă nu e specificată direcţia în asociere, se conasociere bidirecţională .



Agregă ri

O agregare e o formă specială de asociere. Este tot o asociclase, cu observa ţia că aceste clase se refer ă una la alta pla pă r ţile sale.

Un formă specială e cea în care p ăr ţile individuale depind existenţa lor; se numeş te compozi ţie (composition)

Co

A

Obs . Cel puţin la început, e permisă cardinalitatea 0 pentru



Agregări (continuare) Într-o agregare, partea întregului e marcată cu un romb. Compoziţiileromb plinş i au totdeauna o multiplicitate 1 (sau 0..1) de partea unde rom

1)

2)



Schimb de mesage (Message Exchang

Principiul schimbului de mesaje : Obiectele sunt unităţ icare coopereaz ă ş i interacţionează prin intermediul mesajle trimit unul altuia.

Un mesaj e reprezentat de numele opera ţiei (cu arparanteze, dac ă e cazul) ş i o săgeată care arat ă sensul mes

Obs . Un mesaj nu e o opera ţie (adică , în sensul clasi

procedur ă sau funcţie).



Colecţii

Colec ţ iile sunt clase definite uzual în libr ă riile de clase stacomun faptul că ele adună ş i gestionează mulţimi de onumesc ş i clase container (container classes) .

Colec ţ iile au toate opera ţiile pentru adăugarea ş i ş tergeverificarea dacă un obiect dat e conţinut în mulţime ş i deterobiecte sunt conţinute curent în mulţime.

Secven ţ iale : obiectele sunt adunate însecven ţială - ex: tablou (array)Colec ţ ii

Asociative : păstrează obiectele, dar ş i o cheiobiect prin intermediul că reia poate fi identific



Polimorfism

Polimorfismul înseamnă că o opera ţie se poate comporta ddiferite).

Polimorfism static : supraîncă rcarea operatorilor, fundiferite

dinamic :o precondiţie este late binding

D.p.d.v. fizic,binding e punctul în viaţa unui program la car

opera ţii e dat de adresa de memorie a opera ţiei. Uzual, compilare sau link-are. Acest tip de binding se numeş te earl

În late binding , locaţia de memorie a unei opera ţii e decând apelul are loc, i.e. atunci când mesajul corespunobiectului. Prin urmare, asocierea între mesaj ş i operaţie aprulare, nu la compilare.

Moş tenirea înseamn ă că o clasă moş teneş te toatesupraclasei sale. Îi este permis totu ş i să redefineascmoş tenită ş i s-o rescrie cu o nouă definiţie. Care dintre aceva folosi ca r ăspuns pentru un mesaj (adic ă din ce clasăapelată ) se decide doar la rulare.



Polimorfism dinamic (continuare)

În momentul în c întâlneş te un obieţie concretă va fi pentru un dreptunRectangle.display().totdeauna opera ţspecializată . Acepolimorfismului (

Cercuri şi dreptunghiuri



Paradigma OO

- completă ri -



Clase

Numele claselor este, de obicei, un substantiv la singulasă fie cât mai sugestiv faţă de abstrac ţia modelată .

Atributele sunt de două feluri:• atribute de instan ţ iere , care au valori specifice unui ob• atribute de clas ă , care au valori comune tuturor instase reprezintă subliniat

Atributele au urmă toarele tipuri:• integer • real• boolean• string• enumerare• boolean• alte tipuri sau chiar clase



Sintaxa unui atribut va fi urmă toarea:[vizibilitate] nume:tip_expresie [=valoarea_ini ţ ial ă {list ă de

Atributele clasei se pot clasifica după gradul de vizibilita

-atribute publice , care sunt atribute vizibile, pot fi fclase ş i sunt precedate de semnul "+"; mulţimea acnumeş te ş i interfaţă ;-atribute private (informaţionale), care pot fi accesaterespectivă ş i care sunt precedate de semnul "-";

-atribute protejate , care pot fi accesate de clasa carprecum ş i de generaliză rile sau de specializă rile ei, ş ide semnul "#".

Exemplu . Clasa Asigur ă ri poate avea urm ă toarele atribute:



Mesaje ş i metode

Obiectele nu sunt izolate, ele acţionează asupra altopermit să se ac ţioneze asupra lor. Rela ţiile dintre ob

linkuri sau leg ă turi , iar comunicarea dintre obiecte se numComportamentul se refer ă la modul în care un obie(schimbă starea) la cererile altor obiecte din sistem, precum ac ţ ioneaz ă (trimite mesaje altor obiecte).

Un mesaj este o comunicare între clase via asocieri, a şeste comunicarea dintre obiecte via legă turi.

Opera ţ ia este abstractizarea unui mesaj care poate fi tprimirea unui mesaj, o clasă execută o opera ţie.

Sintaxa unei operaţii este:[vizibilitate] nume_opera ţ ie ([arg1 :tip1,............argn :tipn ] )

public (+)privat (-)partajat (#)



Mesaje ş i metode (continuare)

Implementarea opera ţiei se numeş te metod ă , adică ounitate de cod, scris într-un limbaj de programare orienta

Dacă , într-un limbaj de programare, se defineş te o fucodul care determină ce trebuie să execute funcţia, funcţiei este o opera ţie, iar corpul funcţiei este o metodă .

Metodele se clasifică în:

a) Constructori

b) Destructori

- sunt metode care creaz ă noi instaclase îi pot corespunde mai mulţi co

- sunt metode care elimină un obiect

se aplică numaiclasei

c) Selectori - sunt metode care acceseaz ă stareo modifica.

d) Modificatori - sunt metode care schimb ă starea o



Mesaje ş i metode (continuare)

Ceea ce obiectele ş tiu ş i pot să facă se nume ş te caracteri

Caracteristicile sunt de două tipuristructurale

comportamenta

Asocierile ş i atributele alcă tuiesc caracteristicile structura

features) , deoarece ele indică structura clasei, similastructurală , care indică structura modelului realizat

Operaţiile ş i metodele sunt caracteristici dinamice (behaviordeoarece comunic ă comportamentul clasei, asemănă todinamică , folosită pentru a comunica comportamentul un



Interfe ţe

Mesajele primite de obiect pot fi:• mesaje publice – mesaje care pot fi recep ţionate de obcine trimite mesajul;• mesaje private – mesaje trimise obiectului de diferite psau chiar de el însu ş i.

Interfa ţ a unui obiect cuprindemesajele publice ale obiec

Obs. Obiectele din aceea ş i clasă au aceea ş i interfaţă ,unui obiect poate fi considerată ca o interfa ţă a clasei .Obs. Interfaţa conţine numai operaţiile, nu ş i metodimplementează opera ţiile.

Obs. În UML, interfeţele vor fi redate printr-un cerc, că r

numele interfeţei.Obs. Accesul că tre datele obiectului se poate face prin sepe care acesta le ofer ă clienţilor să i. Aceste operaţii carevalorile atributelor se numesc getters ş i setters . În obiectului este privat ă , în timp ce serviciile sale sunt publice



Clase abstracte

O clasă care are, cel pu ţin, o opera ţie abstract ă (operaţidată decât signatura) se nume ş te clas ă abstract ă .

Obs. O clasă abstractă nu poate fi instan ţiat ă .Obs. Clasa care mo ş teneş te o clasă abstractă va trebuiopera ţile abstracte din superclas ă ; în caz contrar, ş i abstractă .



Mo ş tenire

Atributele ş i operaţiile cu vizibilitate publică (precedsuperclas ă vor fi publiceş i în subclasă , pe când cele priv

'-') vor fi moş tenite în subclasă , dar nu vor fi accesibile aş i operaţiile cu vizibilitate protejată (precedate de '#') nu palte clase, ci numai de clasa respectiv ă ş i de subclasele ei

Când o clasă are o singur ă superclas ă , spunem că exsimpl ă .

Poate s ă existe ş i o ierarhie de clase , adică o clasă săcât ş i superclas ă , ş i, în acest caz, avem o mo ş tenire multip

Există mai multe scenarii de moş tenire :• ad ăugarea unor noi metode ş i/sau stă ri subclasei;• rescrierea unor metode din superclasă , din motive de e



Polimorfism

Polimorfismulconstă în abilitatea de a folosi mai multeopera ţie (de exemplu: desenarea unei figuri sau calculul a

Datorită polimorfismului, o subclasă poate s ă redefinmoş tenită chiar dacă opera ţia nu este abstract ă în supercl

Implementarea unei opera ţii va fi aleasă în funcţie de obaplică opera ţia. Se caut ă metoda întâi în clasa cea mobiectului; dacă aceasta nu se g ăse ş te, se merge la suurmă toare, pân ă la găsirea ei în ierarhia de clase defidacă există o clasă abstractă de baz ă , toate celelalte cconcrete pot deriva din aceast ă clasă de baz ă .



Procese software

- introducere -



Proces software

“Because software, like all capital, is embodied knowledgbecause that knowledge is initially dispersed, tacit, latenincomplete in large measure, software development is a learning process. The process is a dialogue in which the knowthat must become the software is brought together and embodithe software. The process provides interaction between usersdesigners, between users and evolving tools, and between desigand evolving tools [technology]. It is an iterative process in whevolving tool itself serves as the medium for communication, witnew round of the dialogue eliciting more useful knowledge fr

people involved.”

How



Ce este procesul software?O “hartă” a drumului ce trebuie urmat pentru conprodus sau sistem, de calitate crescut ă ş i într-un timp

Cine face procesul software?Inginerii de sistem (software engineers) ş i manageimplicaţi ş i cei că rora li se adreseaz ă .

De ce este important procesul software?Deoarece dovede ş te stabilitate, controlş i organizare.

Care sunt pa ş ii?Depind de software-ul pe care îl construim.

Care este produsul muncii? În ochii inginerului de sistem produsul este format documentaţie ş i datele produse ca urmare a activităţ isoftware definită de proces.



Proces software – o tehnologie pe nivele

IEEE defineş te astfel Ingineria software:(1)Aplicarea unei abord

ări sistematice, disciplinate

asupra dezvoltă rii, punerii în funcţiune ş i mentenanţei(2)Studiul abordă rilor de la (1).



Nivelul Proces : defineş te un cadru pentru o mulţime dproces (key process areas ). Aceste zone formeazămanagementului proiectului software ş i stabileş te conteaplicate metodele tehnice, sunt ob ţinute produsele documente, date, rapoarte, forme etc.), sunt stabilite “p(milestones ), e asigurată calitatea ş i se administrează pot

Nivelul Metode : r ăspunde la întrebarea : Cum construim cuprinde un spectru larg de sarcini, care includ: a

designul, construirea programului ş i testarea. Metodsoftware includ activităţ i de modelare ş i alte tehnici descri

Nivelul Instrumente : furnizează suport automat pentru pCând instrumentele sunt integrate, astfel încât informaţinstrument să fie folosite de altul, se creează CASE Software Engineering), care combină software, hardwadate a ingineriei software (ce conţine informaţii importandesign, construcţia programuluiş i testare).



Modele de procese software

1) Modelul secven ţial liniar

2) Modelul prototipului (prototyping model)

3) Modelul RAD

4) Modele pentru procese software evolutive

a) Modelul incremental

b) Modelul spiral ă

c) Modelul spiral WINWIN

d) Modelul de dezvoltare concurent ă



2) Modelul prototipului

Adesea, un client defineş te o serie de obiective pentru sidentifică în detaliu cerinţele de input, de procesare sau d

cazuri, dezvoltatorul poate să aibă îndolieli cu prialgoritmului, adaptabilitatea la un SO sau la forma om/calculator. Pentru aceste e indicat acest model.



Ce facem cu prototipul dac ă îndepline ş te condi ţiile?

“In most projects, the first system built is barely usable. It may slow, too big, awkward in use or all three. There is no alternative

start again, smarting but smarter, and build a redesigned versiwhich these problems are solved . . . When a new system concenew technology is used, one has to build a system to throw awaeven the best planning is not so omniscient as to get it right thtime. The management question, therefore, is not whether to b

pilot system and throw it away. You will do that. The only quewhether to plan in advance to build a throwaway, or to promdeliver the throwaway to customers . . .” (Brooks, F., ThMonth, Addison-Wesley, 1975.)

Concluzie. Deş i pot apă rea probleme, modelul prototparadigma eficientă pentru ingineria software.



3) Modelul RAD

Rapid application development (RAD) e un model dezvoltare software incrementală , care pune accentul

dezvoltare extrem de scurt.Modelul RAD e o adaptare “high-speed” a modelului sec

Modelul RAD cuprinde urmă toarele etape:

i) Business modeling . Fluxul informaţiilor printre funcţimodelat într-un mod ce r ăspunde la întrebă rile:

• Ce informaţii conduc procesul de business?• Ce informaţii sunt generate?• Cine le genereaz ă?• Unde se duc informaţiile?

• Cine le proceseaz ă?ii) Data modeling . Fluxul informaţiilor ca parte a etapemodeling sunt rafinate într-o mulţime de obiecte de dpentru a sus ţine business-ul.



Fiecare funcţie major ă e acoperită separat de o echintegrată în întreg.

Concluzii• Pentru proiecte mari, dar scalabile, RAD necesită rimportante pentru a crea numă rul corect de echipe RAD.

• RAD necesită dezvoltatori ş i clienţi care se obligă la necesare pentru a ob ţine un sistem complet într-un timp

• Nu toate aplicaţiile sunt potrivite pentru RAD. Dacă un sfi modularizat, construirea componentelor necesare pentproblematică .

• RAD nu e potrivit când riscurile tehnice sunt mari. Acând o nouă aplicaţie foloseş te intens o nouă tehnologsoftware nou cere un grad înalt de interoperabilitate existente.



Business modelingScopul business process engineering (BPE) este arhitectura ce va permite business s ă utilizeze eficient in

Se analizeaz ă ş i se specifică design-ul pentru

Arhitectura datelor Arhitectura aplicaţiilInfrastructura tehnol

1) Arhitectura datelor are ca blocuri constitutive obiectele object ). Un obiect de date conţine o mulţime de atribute anumit aspect, calitate, caracteristică a datelor ce sunt de

Exemplu: obiectulCustomer

O relaţie (relationship ) indică cum sunt conectate obiecteExemplu: pentru obiectele Customer ş i produsA, o cump ă r ă .



2) Arhitectura aplicaţiei cuprinde acele elemente ale stransformă obiectele în cadrul arhitecturii datelor pentrude business.

3) Infrastructura tehnologică asigur ă fundaţia pentru arhiş i aplicaţiei. Cuprinde hardware-ul ş i software-ul carcomputere, SO, re ţele, legă turi de telecomunicaţii, tehnoş i arhitectura (ex: client – server).Pentru a modela arhitecturile descrise, se define ş teactivităţ ilor ingineriei proceselor business.

World view e obţinută prin Information strategy planning (ISP) întreg întregul business ca o entitate ş i izolează domenii(ex: inginerie, manufacturare, marketing etc.). ISP defde date care sunt vizibile la nivelul întreprinderiiş i relaţiil

Domain view se ob ţine cu o activitate a BPE numită analysis (BAA) , care identifică în detaliu datele (sub entităţ ilor, adică a obiectelor de date) ş i cerinţele funcţproceselor) ale domeniilor de business în timpul ISinteracţiunile dintre ele.



Odat ă un information system izolat, BPE face o tranzisoftware. Invocând pasul business system design (BSD),cerin ţele de baz ă ale unui information system ş i aceste cerin

în arhitectur ă de date ş i de aplica ţie ş i infrastructur ă tehnologi



Data modeling

Răspunde la un set de întreb ă ri specifice:• Care sunt obiectele de date primare procesate ini ţial

• Care e compoziţia fiecă rui obiect de date ş i ce obiectul?• Unde “stau” în mod curent obiectele?• Care sunt relaţiile dintre obiecte?• Care sunt relaţiile dintre obiecteş i procesele care le

Apelează la diagrama relaţiilor dintre entităţ i (ERD – EntiDiagram)



4GT (Fourth Generation Techniques)Termenul 4GT cuprinde o gamă largă de instrumente soun lucru în comun: fiecare permite inginerului softwanumite caracteristici ale software-ului la un nivel în(tool) generează apoi automat cod surs ă bazat pdezvoltatorului.

Paradigma 4GT pentru ingineria software pune accentul a specifica software folosind forme de limbaj specia

grafice ce descriu problema propusă spre rezolvare în tclientul poate să -i înţeleagă .

În mod curent, un mediu de dezvoltare software ce sup4GT include o parte dintre urmă toarele instrumente (tools• limbaje neprocedurale pentru interogă rile bazei de date;• capabilităţ i grafice de nivel înalt;• capabilităţ i de tip spreadsheet;• generare automat ă a HTML ş i a limbajelor similarecrearea site-urilor Web utilizând instrumente software av



4GT (Fourth Generation Techniques) (continuare)

Concluzii privind paradigma 4GT:1) Folosirea 4GT e o abordare viabilă pentru multe zoCombinată cu alte instrumente CASE ş i generatoarereprezintă o soluţie de încredere pentru multe probleme s

2) Folosind 4GT, timpul necesar pentru producerea softwredus pentru aplicaţii mici ş i mijlociiş i de asemenea design ş i analiză pentru aplicaţiile mult e mult redus..

3) Folosirea 4GT pentru dezvoltarea unui software comfel de multă sau chiar mai multă muncă pentru analiză , d

în ciuda timpului salvat obţinut din eliminarea codului.



4) Modele pentru procese software evolutive : sunt ipermit dezvoltarea cresc ă toare a unor versiuni din ce îcomplete ale software-ului.a) Modelul incremental : combină elemente ale mo(aplicat repetat) cu filozofia iterativă a modelului prototip

Fiecare secven ţă liniar ă produce un “increment” livrabil



Exemplu : Software pentru editor de texte, poate livra mbază al fiş ierelor ş i editarea la primul increment; editareal doilea increment; spellingş i verificare gramaticală în alş i capabilităţ i avansate de proiectare a paginii la al patrule

Obs . Primul increment e adesea un miez al produsuluadică cerinţele de baz ă sunt îndeplinite, dar mai multe cunoscute, altele necunoscute) r ămân nepredate.Acest core product e folosit de client. Ca rezultat aevaluă rii, se dezvoltă un plan pentru urmă torul increme

modificarea core product-ului pentru îndeplinirea maiclientului ş i furnizarea funcţionalităţ ilor adiţionale. Acestdupă livrarea fiecă rui increment, până se contureaz ă întrConcluzii.• Modelul incremental e iterativ (ca ş i modelul pro

concentreaz ă pe livrarea unui produs operaţional la fVersiunile iniţiale nu se regăsesc în produsul finalcapabilităţ i nesecare utilizatorului.• Modelul incremental e util când echipa de dezvoltatotoată perioada. Core product-ul poate fi realizat cu mai p



b) Modelul spiral ă : combină natura prototipului cu aspecontrolate ale modelului cascadă . Software-ul e dezvoltlivr ă ri incrementale. În timpul primelor iter ă ri, livrarea poahârtie sau un prototip. În timpul iter ă rilor ulterioare, sunt

don ce în ce mai complexea sistemului.

Sunt între 3 ş i 6 task regions într-un proiect



Cele 6 regiuni reprezentate în figur ă sunt:

• Comunicarea cu clientul: tasks pentru stabilirea unei com între dezvoltator ş i client

• Planificarea: tasks pentru definirea resurselor, a planifiş i a altor informaţii în legă tur ă cu proiectul

• Analiza riscurilor : tasks pentru stabilirea în egală măehnice ş i manageriale

• Tehnologia (engineering): tasks pentru construirea unmultor reprezentă ri ale aplicaţiei

• Construirea ş i livrarea: tasks pentru construirea, testarasigurarea suportului utilizatorului (ex: documentaţie ş i tra

• Evaluarea clientului: tasks pentru ob ţinerea unui feed-clientului, bazat pe evaluarea reprezentă rilor software etapei de engineering ş i implementate în timpul etapei de



Echipa de dezvoltatori se mişcă în spirală în sensul acel începând din centru.Primul circuit în jurul spiralei ajută la dezvoltarea specifica

Urmă toarele circuite ajută la dezvoltarea prototipuluiş i aversiuni mai sofisticate ale software-ului.

Fiecare trecere prin dreptul zonei de planificare ( planning rrezultate în ajustarea planului proiectului.

Costul ş i planificarea temporală sunt ajustate pe bazderivat din evaluarea clientului.

Managerul proiectului ajustează numă rul de iteraţii necompleta software-ul.

Obs . Spre deosebire de modelele clasice, care se termsoftware-ului, modelul spirală poate fi adaptat pentru

întreaga durată de viaţă a software-ului.



O privire alternativă asupra modelului spirală se ob ţine epunctelor de intrare în proiect ( project entry point axis ).

Fiecare cub plasat de-a lungul axelor poate fi utilizat pepunctul de plecare pentru diferite tipuri de proiect.Un “concept development project” porneş te de la mcontinuă până ce devine completă dezvoltarea conceptulu



Concluzii

• Modelul spirală e o abordare potrivită pentru sist

dimensiuni.• Modelul spirală foloseş te prototipul ca un mecanismriscurilor dar, mai important, permite dezvoltatorului să aprototipului la orice etapă din evoluţia proiectului.

• Modelul spirală menţine abordarea sugerat ă de ciclul deo incorporează într-un cadru iterativ care reflectă mai real• Modelul spirală cere luarea în calcul a riscurilor tehniceproiectuluiş i, dacă se aplică corect, ar trebui să reducă ridevină problematice.

• Modelul spirală nu este folosit aşa cum se folosescsecven ţial ş i modelul prototipului.



c) Modelul WINWIN

“Eliciting software requirements demands negociation. Sunegotiation occurs when both sides « win ». ”

Stakeholder = cineva din organizaţie care are un interes în construirea sistemului sau produsului ş i care va fi recsucces ş i criticat pentru un eşec.

Modelul spiral al lui Boehm (Boehm, B., “Using the WINWINCase Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44)dede activităţ i de negociere la începutul fiecă rei treceri în ju1. Identificarea stakeholders ai sistemului sau subsistem

2. Determinarea condiţiilor de câş tig (“win conditions ”) al

3. Negocierea acestor condi ţii pentru a le reconcilia într-win-win pentru toţi cei implicaţi (inclusiv pentru esoftware).



În afar ă de cele 3 activităţ i de negociere men ţionate, mointroduce 3 anchor points:• Life cycle objectives (LCO ): define

şte un set de o

fiecare activitate major ă de inginerie software.• Life cycle architecture (LCA ): defineş te obiectiv

îndeplinite când se defineş te arhitectura software-ului.• Initial operational capability (IOC): defineş te obiectiv

pregă tirea pentru instalarea / distribuirea software-ului



d) Modelul de dezvoltare concurent ă ( numit ş i concurrent“ Most software development process models are driven by time; the lathe later in the development process you are. A concurrent process mdriven by user needs, management decisions, and review results.” Sitaram, 1994)

Modelul concurent se foloseş te caparadigmă pentru dezvoltareaaplicaţiilor client-server.

Toate activităţ ile există concurent,dar se g ăsesc în diferite stă ri.



Inginerie software

-generalităţ i-



Scopurile pe care dezvoltarea software caut ă sa le îndeplineas

a) satisfacerea cerin ţelor utilizatorilor

b) cost redus de realizare a software-ului

c) performanţă înaltă

d) portabilitate

e) cost redus de mentenan ţă

f) fiabilitate sporită

g) livrare la timp



a) Satisfacerea cerin ţelor utilizatorilor

Principala problemă e analiza cerinţelor

Sarcina încercă rii de a asigura că software-ul face ce vor utnumeş te validare .



b) Costul realiz ă rii software-ului

• Se estimeaz ă că în lume se cheltuieş te pentru produceaproximativ 1500 miliarde dolariş i că în fiecare an se prognoz

acestei cifre cu 15%.• Se estimeaz ă că productivitatea unui programator mediu estprogram pe zi, datorită urmă toarelor aspecte:

- un software de sistem se scrie mult mai greu decât un softwa- în studiul efectuat există mari diferenţe între programatorii in- aceast ă cifr ă include ş i timpul petrecut pentru clarificarea pro

codul, testarea etc..

• Privire paralelă hardware - software



b) Costul realiz ă rii software-ului (continuare)

• Costuri relative în dezvoltarea software-ului

• Numă rul relativ de erori facute în dezvoltarea software

• Costul relativ de reparare a diverselor erori



c) Performan ţele software : trebuie să fim siguri că :• un sistem interactiv r ăspunde într-un timp rezonabil de scur• un joc rulează suficient de repede pentru ca anima ţia să nu

• o anumită sarcină nu ia 15 ore în loc de una

Tem ă : Identificaţi sisteme software în care viteza e un factor im

Obs . Viteza mare ş i economia de memorie sunt contradictorii

d) Portabilitate : cum pot transfera software de la un tip de cominimum de efort

e) Mentenan ţa : e termenul pentru efortul care trebuie pus în sacesta a fost scris ş i pus în aplicare.

de remediere (corectarea bug-ur

de adaptare (care modifică socererea utilizatorilor, fie la schim

Mentenan ţă



e) Mentenan ţa (continuare)

Obs . Mentenanţa de remediere e practic inevitabilă , datorită fadificilă ş i consumatoare de timp ş i lasă cu siguranţă elemente de

Obs . Se estimeaz ă că mentenan ţa reprezintă 67% din totalpentru dezvoltarea diferitelor pă r ţi ale software-ului.

Exemplu de mentenan ţă : Problema anului 2000. Ce tip de men

f) Fiabilitatea

O parte a software-ului e fiabil ă dacă lucrează f ă r ă să producă l

Uzual se vorbeş te de bugs în software, dar pentru claritate se d

• eroare (error) - o decizie greş ită luată în timpul dezvoltă rii sof

• defect (fault) - o problemă care face ca software-ul s ă scomportarea dorită ; poate s ă nu apar ă până când condiţiile nsinonim cu bug.• e ş ec (failure) – un eveniment care face ca software-ul să scomportarea dorită



f) Fiabilitatea (continuare)

• O eroare cauzeaz ă unul sau mai multe defecte.

• Un defect cauzează unul sau mai multe eşecuri.

• Eşecurile apar când sistemul este testat.

Obs . Îndepă ratea bug-urilor ş i încercarea de a asigura fiabiverificare .

Obs . Deoarece este practic imposibil de îndepă ratare a tuturor bconceptul de good enough software (software suficient de bun)software-ului se produce când numă rul ş i severitatea defecacceptabile

Obs . Există ş i conceptul de zero defect software

Obs . Se estimeaz ă că hardware-ul “pică” de trei ori mai repede



Concluzii

Dezvoltarea software ridică probleme mari. Metodele ş i instrupentru îmbună tăţ irea acestei situa ţii sunt cunoscute ca inginerie aceste idei, amintim:

• accent crescut pe realizarea sistematic ă a tuturor etapelor de d• realizare de instrumente software pentru dezvoltare• accent crescut pe determinarea cât mai exact ă a cerin(requirements engineering ş i validation )

• prezentarea unei versiuni prototip utilizatorilor

• folosirea unor limbaje de programare noi, inovatoare



Diagrame de clas ă

- exemple -



Scopuri urm ă rite:

• S ă se fac ă distinc ţia dintre agreg ăcompuneri

• Folosirea corect ă a generaliz ă riloclaselor abstracte

• Folosirea corect ă a asocierilor • Restric ţii dintre asocieri

• Noi analysis patterns



Se consider ă enun ţurile:

1. Un director con ţine fi ş iere

2. O camer ă con ţine pere ţi

3. Modemurile ş i tastaturile sunt periferice de intrare/i

4. O afacere bursier ă presupune vânzare sau cump

5. Un cont bancar poate apar ţine unei persoane juridice

6. Doi oameni pot fi c ă s ă toriţi

Tem ă . Determina ţi rela ţia static ă potrivit ă (agregaregeneralizare sau asociere) pentru fiecare dintre propozisus. Desena ţi diagrama corespunz ă toare.



2. O camer ă con ţine pere ţi

E agregare .

Poate fi compunere?Nu , pentru c ă multiplicitatea nu e cel mult 1 (un perete poate apar multe camere al ă turate)

Obs. Se consider ă (pentru completarea multiplicit ăţ iipoate con ţine cel pu ţin un perete (circular).



5. Un cont bancar poate apar ţine unui persoane fizice sau

Deoarece cuvântul cheie e apar ţine ş i nu este o , atunci avem asociere .

O solu ţie imediat ă (de ş i incorect ă ) ar fi:

Obs . Contul va fi deschis unei persoane fizice sau juPersFizica ş i PersJuridica trebuie excluse mutual.

Vezi Glosar de termeni



6. Doi oameni pot fi c ăs ă tori ţi

Aceast ă propozi ţie introduce caracteristica de definire a unei obiectele aceleia ş i clase (Asociere reflexiv ă ).

Se poate ad ă uga restric ţia ca dou ă persoane de acela şcă s ă toreasc ă :



Glosar de termeni

Asocierea exclusiv ă sau asocierea XOR este o constrângere mai multor asocieri ş i specific ă faptul c ă o clas ă poate participasociere la un moment dat. Se reprezint ă ca o linie punctat

împreun ă cu restric ţia {xor}. inapoi la slide

Generalizarea incomplet ă ({incomplete}) este generalizarecare nu exist ă restric ţii cu privire la num ă rul de subclase ale unecaz în care ne este permis s ă ad ăug ăm noi descenden ţi. inap

http://0.0.0.0/

http://0.0.0.0/

http://0.0.0.0/

http://0.0.0.0/



Diagrame de clasă

- exemple -



Tem ă . Modela ţi enun ţul : “ O ţar ă are o capital

Ţara va fi o clasă cu unul dintre atributele sale capitala. Autilă doar dacă vrem să avem acces la numele capitalei u

Eventual se pot completa, ulterior, alte atribute: nume,etc.

Pe de alt ă parte, ce se întâmpl ă dacă vrem să adăuconceptului de capitală , cum ar fi populaţie, suprafaţă etc

Capitală va deveni clasă



Asocierea “are” poate fi o agregare sau compunere? D

Pe de altă parte, modelul de mai sus nu aminteş tenoţiunea de ora ş : dacă o capitală nu mai e capitală (din doraşul în sine nu dispare, ci doar statutul său de capitală .

Vom modela aşadar faptul că o capitală e un oraş cu un a



În final, dacă vrem să ar ă tăm că o capitală e un oraş şspecifice oraşului, atunci putem face clasa Capitala ca oclasei Oras .

Dependen ţa <<refine>> indică faptul că multiplicitateaclasei Tara în compunerea cu Capitala înlocuieş te mai multiplicitate “1..*” din partea claseiTara pentru oraşe.

Obs . Clasa Oras din figura de mai sus nu e o clasă abstr



Diagrame de clasă

- exemple -



Temă . Modelaţi enun ţurile urmă toare (îndeplinite

1) Fiş ierele, shortcut-urile ş i directoarele sunt directoare ş i au un nume;

2) Un shortcut implic ă (se refera la) un fi ş ier sau un d

3) Într-un anumit director, un nume poate identifelement (fiş ier, shortcut sau director);



1) Fiş ierele, shortcut-urile ş i directoarele sunt directoare ş i au un nume;

Conceptele de fisier , shortcut , director trebuie modelate î

Din moment ce un fiş ier, shortcut sau director nu poate într-un director (în alte directoare pot fi eventual copii odată cu dispariţia directorului pă rinte dispar ş i fiş ierele,(sub)directoarele conţinute în el, relaţia dintre claseleDirector cu clasa Director trebuie să fie compunere.



2) Un shortcut implic ă un fiş ier sau un director;

Obs. Asocierea exclusiv ă sau asocierea XOR este o constsau a mai multor asocieri ş i specifică faptul că o clas ă pcel mult o asociere la un moment dat .



Soluţia vine din propoziţia a 3-a:3) Într-un anumit director, un nume poate identifica d

(fiş ier, shortcut sau director);

Adăugând o supraclas ă ,Element

, care s ă generalizezeShortcut ş i Director , cele 3 compuneri se pot îmbina într-



În aceast ă soluţie:

• Director e “composite” în relaţie cu Element

• Director e subclas ă a clasei Element

Ce este pattern-ul “composite”?E o soluţie elegantă pentru a modela ierarhii de eleme

Designerul poate lucra cu obiecte individuale (frunze combinaţiile lor (composite) în acelaş i fel.



Diagrame de clasă ş i

obiecte- Concepte, exemple -



Noţiunile open ş i close sunt concepte dinamice. Ele privescstarea unui obiect Flight prin ordinul altui obiect AirlineCompa

Se va insera un atribut state , de tip enumerare, ilustrat în fig

Obs1 . Soluţia de mai sus nu e totu ş i cea mai fericită . De astare (state) va fi modelată cu ajutorul diagramelor diagram).Obs2 . În diagramele de clas ă , singurele elemente dinamiprin intermediul opera ţiilor .



Mesajele vor circula între obiectele ce reprezint ă instan

astfel:



(conti

O solu ţie tentant ă ar fi să se creeze dou ă subclase din clasa

Obs . Soluţia e incorect ă , deoarece fiecare aeroport e uplecare pentru anumite zboruri ş i aeroport de sosire pentrprin urmare clasele DepartureAirport ş i ArrivalAirport au ac



(conti

Se va folosi no ţiunea de rol, care se potrive ş te perfect situa



Obs . Rămâne problema multiplicit ăţ ii în partea stâng ă a De câte aeroporturi e servit un ora

ş?

Obs . Dacă se consider ă că verbul “a servi” se refer transport aerian care se g ăses ş te la cel mult 30 km demultiplicitatea este 0..*, ca în figura de mai jos:



Pasul 3. Modelarea propoziţiilor 8ş i

Obs . O escal ă (stopover) e în conexiune cu zborurile ş i aee indicat s ă se creeze o clas ă Stopover :



Obs. O escal ă se produce într-un ş i numai un aeroportpoate fi folosit pentru mai multe escale. Întrebare. O escal ă apar ţine unui zbor ş i numai unul ?Răspuns. Nu, există contraexemple date de speciali ş ti. poate apar ţine mai multor zboruri.Pentru a completa diagrama, facem observa ţiile:• asocierea dintre Flight ş i Stopover e o agregare, dar nu e c• escalele sunt ordonate conform cu zborurile



Obs. Clasa Stopover e strâns legat ă de clasa Airport (mnu exist ă ea îns ăş i, ci ca parte a clasei Flight .

O idee ar fi s ă consider ăm clasa Stopover ca specializare a

Obs. Nu e solu ţia recomandat ă , din cauza a ş a numiteimplementare”.



Se poate folosi no ţiunea de escal ă (stopover) ca al treileaaeroport cu privire la zboruri.

Obs. Clasa Stopover dispare, fiind înlocuit ă de o clas ă de StopoverInfo .



Pasul 4. Modelarea propoziţiilor 3,4ş

Obs. Trebuie s ă se fac ă distinc ţie între customer ş i passenun client (customer) poate fi un angajat al celui care c ă lă torObs. Din propoziţia 4, reies multiplicit ăţ ile: single flight, sin

Obs. Propoziţia 5 poate fi îndeplinit

ăprin ad

ăugarea a d

clasa Booking .



Obs. O solu ţie mai simplă se ob ţine dac ă vom consi(passenger) ca atribut în clasa Booking .

Obs. Totuş i, dacă vrem s ă gestion ăm informaţii legate de fi: adresa, numar telefom, e-mail etc) e mai recomandabil sPassenger , cum am descris anterior.



Revenim la:

Începutul propozi ţiei e confuz, deoarece pare c ă implică dirflight . De aceea, pentru evitarea confuziei, propozi ţia poate fi

Obs. O rezervare (booking ) este f ăcută de (doar) un custzbor (flight ) poate fi afectat de 0 sau mai multe rezerv ări.



Adăugând ş i clasa Passenger , se pune întrebarea:Câte rezerv ări poate s ă aibă un pasager?

Răspuns. La prima vedere, cel pu

ţin una (altfel nu ar fi pasag

Răspuns complet. E necesar s ă anticipăm că putem avea 0



Pasul 5. Adăugarea atributelor ( attributes ), r(constraints ) ş i calificatorilor (qualifie

Reluăm modelul preliminar ob ţinut pân ă acum:



Pentru fiecare clas ă , identificăm principalele atributele (foloUML):



Completăm modelul cu atribute derivateUn atribut derivat (vezi Glosar de termeni ) este o propriepentru analist, dar redundant ă ca valoare, pentru c ă poate fielemente existente în model.Exemplu: durata unui zbor (length), care se ob ţine carrivalTime ş i departureTime , ţinând cont (eventual) ş i departureDate.

http://0.0.0.0/

http://0.0.0.0/



Atribute derivate (continuare)

Cum convertim un atribut derivat într-o metod ă de design?

Designer-ul are de ales între dou ă metode:

• păstreaz ă un atribut concret în design, care va avea metodel(set ş i get ); trebuie activat procesul de update ori de câte informaţie, de care depinde atributul, se modific ă ; - se necesar ca valoarea atributului derivat s ă fie prezent ă în permse calculeaz ă greu;• nu stocheaz ă valoarea redundant ă , dar o calculeaz ă la cmetod ă publică ; - se folose ş te dac ă nu e cerut prea des saucalcula cu u ş urinţă



Adăugarea restric ţiilor (constraints) ş i calificativilo

Pentru a schimba un zbor (flight ) sau client (customrespectiv

ătrebuie anulat

ă şi creat

ăuna nou

ă.

Acest fapt se poate realiza folosind restricţia {frozen}pe as(vezi Glosar de termeni)

Pe de alt ă parte, fiecare zbor e identificat în mod unicPutem s ă convertim atributulnumber (în clasa Flight ) în ca(vezi Glosar de termeni) al asocierii offers dintre clasele AFlight .

Nu trebuie exagerat cu restricţiile. Se recomandă folosirea foarte importante, altfel diagrama poate deveni greu de urm

http://0.0.0.0/

http://0.0.0.0/

http://0.0.0.0/

http://0.0.0.0/



Clasa Flight în versiunea iniţială



Separarea responsabilit ăţ ilor claseiFlight



Pentru updatarea modelului, trebuie:• distribuirea atributelor, operaţiilor ş i asocierilor clasei FlGenericFlight ş i Flight;

• adăugarea unei asocieri “1-*” între claseleGenericFlight ş

În plus, adăugăm două atribute în clasa GenericFlight care a s ăptămânii e planificat zborulş i în ce perioadă a anul(validityPeriod ).E adăugată o restricţie care leagă valorile atributuluidclasei Flight ş i din clasa GenericFlight Obs . validityPeriod nu e un atribut simplu: putem fi interperioadei, sfâr ş itul, durata etc. Soluţia ar fi crearea unei cla

Trebuie adăugată o asociere între Flight ş i AirlineCompany



Metaclass patternSepararea responsabilit ăţ ilor poate fi generalizată în formpattern ”, care poate reutilizat în alte ocazii.

Fie o clasă XX, cu multe responsabilităţ i, care nu sunt prinstanţă .

Adăugăm o clasă TypeXX , distribuim proprietăţ ile între alegăm într-o asociere de tipul “*-1”.TypeXX se numdeoarece con ţine informaţii ce descriu clasa XX.



Pasul 7. Structurarea în pacheteStructurarea trebuie s ă ţină seama de dou ă princindependen ţ a .

Criteriile de coerenţă presupun a fi îndeplinite:• obiective: clasele trebuie s ă returneze servicii de aceeautilizatori;• stabilitate: izol ăm clasele care sunt stabile de cele care trebuiparcursul proiectului• durata de via ţă a obiectelor.

Independen ţa presupune c ă divizarea în pachete trebuie fsă fie minimizate dependenţele dintre pachete.

Propunem divizarea în două pachete:• primul priveş te definirea zborurilor, foarte stabile (cele din G

• al doilea se refr ă la rezervări, împreuă cu toate asocierile lor



O soluţie posibilă :



Pasul 8. Generalizarea ş i reutilizareSe pune problema: putem reutiliza modelul de rezervarcă lă torie cu avionul la o problemă legată de rezervarea c

ălătorie cu autobuzul.

O că lă torie cu autobuzul are un oraş de plecare ş i un orespectiv timp ş i dată de plecare ş i destinaţie. Un client sau mai multe că lă torii pentru unul sau mai mulţi pasageri.

Modelul va fi foarte asemănă tor cu modelul că lă toriei cumai simplu, datorat urmă toarelor aspecte:

• noţiunea de aeroport nu are echivalent, iar clasa City e clasa JourneyByBus;

• distincţia dintre GenericFlight ş i Flight nu e transfecă lă toriile cu autobuzul nu sunt aşa regulate ş i nu sunt pla



Propunerea unei arhitecturi logice îmbinatUrmă rim obiectivele:• izolarea claselor care sunt împă r ţite (shared) într-un nou reutilizate• factorizarea propriet ăţ ilor împăr ţite într-o clas ă abstract ă .

Izola



Pe de altă parte, clasele Customer ş i Passenger înrezervare. De aceea, e bine s ă le izolăm într-un nou acela ş i (Geography ), ci separat.

Există asem ănare între pachetele FlightBookings ş i BusBdiferen ţă fiind la clasele FlightBooking (redenumit ă peBooking ) ş i BusBooking : au acelea ş i atribute ş i aproape acel



Se va crea a ş adar o supraclas ă abstract ă Bookings



Soluţia finală va fi urmă toarea:



Glosar de termeniUn element derivat , de exemplu atribute sau asocieri, este p”/”. Un atribut derivat nu va fi stocat în obiectele clasei, ci fiecare dat ă . Vezi figura de mai jos

Asocierea derivat ă mai poate fi reprezentat ă ş i printr-o rela ţetichetat ă cu stereotipul << derive >>.

inapoi

http://0.0.0.0/

http://0.0.0.0/



Studiu de caz

-ATM (Automatic teller mach



Enun ţarea problemeiSe presupune c ă un ATM ofer ă urmă toarele servicii:1) Distribuirea banilor că tre orice posesor de card (smartcard

unui cititor de card2) Consultarea soldului contului, facilităţ i de plată ş i de dep

pentru clienţii băncii (bank customers) care deţin un card (sm

Trebuie avut în vedere că :3) Toate tranzac ţiile trebuie f ăcute în siguranţă4) E necesar uneori ca bancomatul s ă se reumple etc.

De aceea, trebuie îndeplinite sarcinile:• Să se identifice actorii

• Să se identifice cazurile de utilizare

• Să se construiasc ă o diagramă use-case

• Să se descrie textual cazurile de utilizare

• Să se completeze descrierile cu diagrame dinamice

• Să se organizeze ş i să se structureze cazurile de utilizare

Obs. Enupoate fi cum se realitate)



Pasul 1. Identificarea actorilor

1.1 Care sunt entităţ ile externe care interacţionează direc

Prima propoziţie indică ş i primul actor :1) Distribuirea banilor că tre orice posesor de card

intermediul unuicititor de card

Atenţie! Cititorul de card face parte din ATM, deci nu poa

Întrebare. Este cardul un actor (deoarece este einteracţionează cu el)?Răspuns. Poate fi, dar se aplică urmă torul principiu: elim

în dauna actorilor “logici”!, deoarece actorii reprezintă cinbeneficiaz ă în urma utiliză rii sistemului.

Cardul nu beneficiază prin folosirea ATM, ci cel care deţincardul nu va fi considerat actor.Aşadar, primul actor va fiposesorul de card (CardHolder )



Pasul 1. Identificarea actorilor (continu

A doua propoziţie specifică :2) Consultarea soldului contului, facilităţ i de plată ş i de dep

pentru clienţii băncii (bank customers) care de ţin un card

Aşadar, se contureaz ă ş i alt actor:clientul băncii (bank cu

A treia propoziţie specifică :3) Toate tranzac ţiile trebuie f ăcute în siguran ţăCine ofer ă siguranţă ?

În exemplul considerat (preluat după sistemul bancar didentifică alţi doi actori:

• Visa authorisation system (VISA AS ) pentru tranzac ţii deintermediul unui smatcard Visa

• Sistemul informa ţional al băncii (Bank IS ) care s ă autranzac ţiile f ăcute de un client prin intermediul smartcard-ulaccesarea soldului



Pasul 1. Identificarea actorilor (continu

A patra propoziţie specifică :4) E necesar uneori ca bancomatul s ă se reumple etc.

Aceasta sugereaz ă că e nevoie activitate de mentenbancomatului, recuperarea smartcard-urilor care au fost “înghiţit

Aceste sarcini identifică un alt actor : Operatorul (Maintenan

CardHolder

Bank Customer

Concluzie . Actorii sunt: Visa AS

Bank IS

Maintenance Operator



Pasul 1 bis. Reprezentarea unei diagram

Pentru o mai bună înţelegere a celor deduse la pasudesenarea unei diagrame, pe care o s-o numim diagcontext (static context diagram)



Pasul 2. Identificarea cazurilor de utili

Un caz de utilizare reprezint ă specificarea unei secvenincluzând variante , pe care sistemul le poate efectua, interactorii din sistem.Vom lua actorii, unul câte unul, ş i vom lista modurile interac ţionează cu sistemul:

1) CardHolder:

• retrage bani2) Bank customer:

• retrage bani• consultarea soldului• depozitarea banilor (cash)• depozitarea cecurilor



Pasul 3. Crearea diagramelor use casO diagrama use case arat ă relaţiile dintre actori ş i siscazurile de utilizare (use cases).

ATM

Retragere bani

Consultare sold

Depozitează bani

Depozitează cecuri

Umple bancomatul

Recupereaz ă cardur

Recupereaz ă cecurFrontierasistemului



Pasul 3. Crearea diagramelor use case (contO variantă se ob ţine considerând Bank customer ca specializ

ATMRetragere bani

Consultare sold

Depozitează bani

Depozitează cecuri

Umple bancomatul

Recupereaz ă cardur

Recupereaz ă cecur

Obs. Vom redenumi actorul CardHolder în Visa CardHolder



Pasul 3. Crearea diagramelor use case (contAdăugarea actorilor secundari

Recomand ări:• Implicit, rolul unui actor e “principal” (“primary”); dacă nu rolul e “secundar” (“secondary”) pe asociere, de partea ac• Pe cât e posibil, plasa ţi actorii principali în stânga diasecundari în dreapta

Obs. Dacă actorul principal e Visa CardHolder , atuncisolicitat; pe de altă parte, ATM va solicita Bank IS directun client al băncii (bank customer).

O solu ţie ar consta în ad ăugarea unei asocieri cu fiecare dinsecundari.



O altă solu ţie ar fi să se fac ă distic ţie între cele dou ă creferitoare la retragerea banilor:• Retragere bani cu Visa card

• Retragere bani cu un card bancar



Pasul 4. Descrierea textual ă a cazurilor deCazul de utilizare trebuie s ă aibă un început ş i un sfâr ş itTrebuie specificate, de asemenea, variante posibile, cum ar

succes , secven ţe alternative , în timp ce, simultan, se încearcdescrierile într-o ordine secven ţială , pentru a îmbun ă tăţ i înţe

ScenariiNumim fiecare unitate de descriere a secven ţelor de ac ţiune

Un scenariu reprezint ă o succesiune particular ă a secven ţella începutul la sfâr ş itul unui caz de utilizare.Un scenariu poate fi folosit pentru a ilustra o interac ţiune unei instan ţe a unui caz de utilizare.



Pasul 4. Descrierea textual ă a cazurilor de(continuare)

Înregistrarea descrierii textuale nu e standardizat ă în UML.

a) Rezumatul de identificare ( Identification summary ) (obltitlu, rezumat, datele de creare ş i modificare, versresponsabil ă , actorii...

b) Fluxul de evenimente ( Flow of events) (obligatoriu): dscenariu de succes ( main success scenario sau basic flownormal path ), secven ţele alternative ş i secve ţele de eprecondi ţiile ş i postcondi ţiile.

c) Cerinţe UI (UI requirements ) (opţional): adăugarea constrGUI.

d) Cerinţe nefunc ţionale (Non-functional constraints ) (oadăuga informa ţiile: frecven ţă , disponibilitate, acuratconfiden ţialitate, performan ţă etc.



a) Rezumatul de identificare ( Identification summary )

Titlu: Retragere bani folosind Visa card

Rezumat: Acest caz de utilizare permite unui posesor deCardHolder), care nu e client al băncii, să retragă bani în limita z

Actori: Visa CardHolder (primary), Visa AS (secondary).

Creation date: xx/11/09

Date of update: zz/11/09

Version: 2.2

Person in charge: Nume Prenume



b) Fluxul evenimentelor (Flow of events)Precondi ţii:• ATM e aprovizionat cu bani• Nu e niciun card în cititorul de card

Main success scenario:1. Visa CardHolder introduce cardul în cititor.2. ATM verifică dacă este valabil cardul.3. ATM cere Visa CardHolder pin-ul.4. Visa CardHolder introduce pin-ul.5. ATM verifică dacă datele sunt corecte.

6. ATM cere autorizaţie de la VISA authorisation system.7. VISA authorisation system confirmă ş i indică limita zilnică de r8. ATM cere Visa CardHolder să introducă suma dorită .9. Visa CardHolder introduce suma dorită .10. ATM verifică dacă suma e sub limita zilnică .11. ATM întreabă Visa CardHolder dacă doreş te chitanţă .12. Visa CardHolder cere chitanţa.13. ATM returnează cardul că tre Visa CardHolder.14. Visa CardHolder ia cardul.15. ATM ofer ă banii ş i chitanţa.16. Visa CardHolder ia baniiş i chitanţa.



O altă prezentare posibilă constă în separarea ac ţiunii actorilor ş1. Visa CardHolder introduce cardulîn cititor.

2. ATM verifică dacă este 3. ATM cere Visa CardHo

4. Visa CardHolder introduce pin-ul. 5. ATM verifică dacă date6. ATM cere autorizaţie deauthorisation system.

7. VISA authorisation systemconfirmă ş i indică limita zilnică deretragere.

8. ATM cere Visa CardHosuma dorită .

9. Visa CardHolder introduce sumadorită . 10. ATM verifică dacăzilnică .11. ATM întreabă Visadoreş te chitanţă .

12. Visa CardHolder cere chitanţa. 13. ATM returneazăCardHolder.

14. Visa CardHolder ia cardul. 15. ATM ofer ă banii ş i chi

16. Visa CardHolder ia banii ş ichitanţa.



b) Fluxul evenimentelor (Flow of events) (continuare)Secven ţe alternative:

A1) Număr de pin incorect : intervine la pasul 56. ATM informează CardHolder că pin-ul e incorect pentru prima7. ATM înregistrează eşecul pentru card.Scenariul se reîntoarce la pasul 3.

A2) Suma cerută e mai mare decât limita zilnic ă : intervine la

11. ATM informează CardHolder că suma cerută e mai mare decScenariul se reîntoarce la pasul 8.

A3) Visa CardHolder nu vrea chitan ţă : intervine la pasul 1112. Visa CardHolder declină oferta de a primi o chitanţă .13. ATM returneaz

ăcardul c

ătreVisa CardHolder.

14. Visa CardHolder ia cardul.15. ATM ofer ă banii.16. Visa CardHolder ia banii.



Pasul 5. Descrierea grafic ă a cazurilor de

Deş i descrierea textuală a cazurilor de utilizare e esedezavantajul că nu specifică în ce ordine vor fi secvmoment intervin actorii secundari.

E recomandat s ă completăm descrierea textuală cu undiagrame UML mai dinamice.



Obs. Pentru cazurile de utilizare se recomandă diagramele dediagram), dar pot fi utile diagramele de secvenţe (Sequence diag

Obs. Pentru anumite scenarii se recomand ă Sequence diagramSystem sequence diagram, în care se reprezint ă sistemul cactorul principal la stânga, iar actorii secundari în dreapta sist



Crearea unei Systemsequence diagram cares

ădescrie un main

success scenario pentrucazul Retragere banifolosind un Visa card.



Activity state; Action state

O activity state modelează realizarea unei activităţ i care:

• e complexă ş i poate fi divizată în mai multe activităţ i;

• poate fi întreruptă de un eveniment.

O action state modelează realizarea unei activităţ i care:

• e simplă ş i nu poate fi divizată ;• nu poate fi întreruptă de un eveniment.



Completarea diagramei desecven ţe

Se introduc:-activităţ ile principale alesistemului (prin mesajeletrimise că tre sistem);

-referinţe la secven ţelealternative ş i de eroare (prinnote).



Identificarea unei relaţii de generalizare ce implică cazu

Consider ăm cazurile de utilizare: Depunere cash ş i Depunereimplică aceiaş i actori: Bank customer ca actor principal ş i

secundar.



Structurarea cazurilor de utilizare folosindStrategii posibile: gruparea după actor, după domeniu funcţional

În acest exemplu, folosim gruparea după actorii principali



Crearea cazurilor de utilizare pentru pachetul Visa W



Crearea cazurilor de utilizare pentru pachetul Customer



Crearea cazurilor de utilizare pentru pachetul Main



Elementele unei diagrame de activit

O diagramă de activitate este o extensie a unei diagAceasta înseamn ă că o diagramă de activitate vcaracteristicile unei diagrame de stare, plus unele noi.

Elementele componente ale unei diagrame de activitate suurmă toarele:

1) stă ri de acţiune2) tranziţii3) bloc de decizii4) linii de sincronizare5) culoare



1) Stări de ac ţiune ş i stări de activitate

Prin activitate înţelegem o prelucrare (procesare) neatomicdesf ăş urare, în cadrul unei ma ş ini de stare. Activit ăţ ile se pş i nu sunt atomice, în sensul c ă pot fi întrerupte. Activităţdin secven ţe de ac ţiuni, care sunt prelucr ări atomice ş i caschimbarea st ării sau returnarea unei valori.

Există trei tipuri de ac ţiuni, ş i anume: simple, ini ţiale ş i finpoate fi alc ă tuită dintr-o ac ţiune iniţială , una sau mai multe afinale.

ActivitateReprezentare

O ac ţ iune ini ţ ial ă reprezint ă prima ac ţiune într-o diagram ă do ac ţiune iniţială se reprezint ă ca ş i o stare ini ţială , adică pri

O ac ţ iune final ă reprezint ă ultima ac ţiune dintr-o diagram ăUML, o acţiune finală se reprezint ă ca ş i o stare final ă , pmici concentrice, din care cel interior este plin .



2) Tranziţii

Tranzi ţ iile sunt legă turile dintre acţiuni ş i se reprezintă cadiagramele de stare, printr-o săgeată îndreptată spre ac ţiu

În diagramele de activitate, tranziţiile nu sunt etichetatreprezintă încheierea activităţ ii respective. Tranziţiile petichetate cu condiţii, reprezentate printr-o afirmaţiparanteze drepte, care restric ţionează tranziţia spre ac ţiun

Există două tipuri de fluxuri de tranzi ţii:a) fluxul de control;

b) fluxul obiectelor.



a) Fluxul de control al tranzi ţiilor

Fluxul de control al tranzi ţiilor indică ordinea ac ţiunilor în tranziţiilor arată cum sunt ordonate ac ţiunile în secven ţă . Înactivitate, activit ăţ ile sunt legate prin tranzi ţii automate, spdiagramele de stare, unde tranzi ţiile între stări sunt evenimente.

Atunci când o ac ţiune este încheiat ă , se va executa acieş irii, dacă există , după care tranzi ţia este declan ş ată cac ţiune sau activitate. Urmeaz ă executarea ac ţiunii specific

stare, dac ă există ş i executarea ac ţiunii sau a activit ăţ ii asetc.

Exemplu. Pentru un anumit sistem, aflat în starea drapoartelor, avem urm ă toarele activit ăţ i:- iniţială- stabilirea criteriilor raportului- generarea raportului- tipărirea raportului- finală



Fluxul de control al tranzi ţiilor se poate omite atunci când eobiectelor care s ă indice ordinea ac ţiunilor, adic ă atunci creeaz ă un obiect de ie ş ire, care s ă fie obiect de intrare penac ţiune din secven ţă .



3) Bloc de decizii

O decizie reprezintă selectarea unui anumit flux de contdin mai multe, în funcţie de o condiţie de gardă .

Într-o diagramă de activităţ i, blocul deciziei este repreromb mic, în care intr ă o singur ă tranziţie, ş i pot ieş i doutranziţii.

Fiecare tranziţie de ieş ire, este etichetat ă cu o condiţie d între paranteze drepte, ş i care indică condiţia care trepentru ca tranziţia să se producă . În cazul în care lipsegardă , acestea sunt considerate, implicit, ca fiind false.



4) Linii de sincronizare

Concuren ţa (concurrency) implic ă faptul că mai multe trasimultan. În UML, sincronizarea între fluxurile de control sajutorul barelor de sincronizare .

O bar ă de sincronizare permite îmbinarea (join) ş i bramificaţiilor paralele în interiorul unui fir de execu ţie al unusau al unei metode.

Tranziţiile care pleac ă dintr-o baz ă de sincronizare se declanDacă mai multe tranzi ţii intr ă într-o bază de sincronizare, acese întâmple, înainte ca bara s ă fie trecut ă de una sau mai mieş ire din bara de sincronizare. Bara de sincronizare se reprelinie îngroş ată .

Dacă o bar ă are o singur ă tranziţie de intrare ş i două sa

ieş ire, aceasta indic ă faptul că toate tranzi ţiile de ieş ire se ptranziţia de intrare. Acest flux se nume ş te splitting control .

Dacă o bar ă are mai multe intr ări ş i o singur ă ieş ire, aceastatoate intr ările trebuie s ă se produc ă înainte s ă se produc ă trAcest flux se nume ş te synchronization control .



5) Culoare

Deoarece o diagram ă de activitate nu ofer ă indicii referitocare este responsabil pentru fiecare activitate, UML compenslăbiciune, oferind tehnica culoarelor (swimlanes) . Ace împăr ţirea unei diagrame de activitate în zone paralele, numactivit ăţ i (aş a cum o piscin ă este împ ăr ţită în culoare de neviden ţia care element este responsabil pentru ac ţiunefiecărei zone.

Fiecare responsabilitate este repartizat ă unei clase sau unefiecare activitate este alocat ă unui culoar. Pozi ţia relativăare nici o semnifica ţie, tranziţiile fiind libere să traverseze cnu se refer ă .

În UML, culoarele se reprezintă prin regiuni verticale, paralel

linii solide. Fiecare culoar are, în partea de sus, o etichetelementul responsabil pentru acea activitate (o clas ă , udepartament al unei organiza ţii).



Exemplu.



SemnaleUML ofer ă două simboluri pentru semnale.

Primul simbol mesaj indic ă recep ţionarea unui semnal. Num

este trecut într-un pentagon concav (un dreptunghi cu o laturtriunghi concav). Recep ţionarea unui semnal este reprediagram ă de activitate, printr-o rela ţie de dependen ţă de trimite semnalul, la simbolul semnalului, urmat ă de o simbolul semnalului la urm ă toarea ac ţiune.

Al doilea simbol semnal indic ă trimiterea unui semnal. Numeste trecut într-un pentagon convex. Trimiterea unui reprezentat ă într-o diagram ă de activitate, printr-o rela ţie dla simbolul semnalului spre obiectul care prime ş te semnalul



Exemplu de diagram ă de activitaPentru exemplul discutatanterior (vezi figura al ă turată)se adug ă cerin ţele:

- după realizarea unui raport,se poate cere execu ţia altuia;- simultan cu generarea unuiraport se poate genera ş i altă opera ţie (interogare,actualizare, etc);

- un raport se listeaz ă laimprimantă ş i interogarea lamonitor;- un raport ş i o interogare potfi listate numai dac ă generarea a fost f ăcută cusucces;- se trimit semnale c ă treimprimantă ş i monitor ş i seprimesc semnale lageneratoarele de rapoarte ş ide interog ări.



Introducere

O diagramă de stare poate fi ata şată orică rei clase caridentificate ş i un comportament complex. O diagramă deistorie a vieţii obiectelor unei clase ş i poate fi consideratăpe stă ri conectate prin tranziţii.

Diagramele de stare specifică modul în care reacţioneprimirea unui mesaj.

O diagramă de stare are o singur ă stare iniţială , una sausimple, una sau mai multe stă ri finaleş i tranziţii între stă ri.



Elementele unei diagrame de stare

Elementele principale ale unei diagrame de stare sunt ur1) st

ări

2) tranziţii3) evenimente4) acţiuni

1) Stă ri

Starea acoper ă toate proprietăţ ile statice ale unui ocurente pentru fiecare proprietate. Toate instan ţele uneaceea ş i stare. Starea curent ă a unui element se nume ş t

a) simplăb) iniţialăc) finală

Stare



a) Stare simplă : este o condiţie specială sau o situa ţie alungul ciclului lui de viaţă .

Exemplu de stă ri de obiecte:• obiectulbec poate avea st

ările:aprins

şi stins;

• obiectul factur ă poate avea st ă rile: pl ă tit ş i nepl ă tit;• obiectul lift poate avea st ă rile:sta ţ ioneaz ă , urc ă , coboar • obiectulcalculator poate avea st ă rile:

inactiv – calculatorul nu este pornit sau nuutilizatorilor;

activ – calculatorul este pornit ş i este funcţional psă i;blocat – calculatorul nu este alimentat sau are unel

Reprezentarea grafic ă a unei stă ri simple: dreptughi cu



b) Stare iniţială : indică starea unui element ş i momeExistă o singur ă stare iniţială . Se reprezintă , în UML, cerc plin, de la care pleacă o săgeată .

c) Stare finală : indică starea unui element la sfâr ş itul vieste distrus. Într-o diagramă de stare, putem avea zero stă ri finale. Se reprezintă , în UML, printr-un mic cercaltui cerc gol, la care sosesc s ăgeţi de la stă rile sistemulu



2) Tranziţii

Tranziţiile sunt relaţiile dintre stă ri. O tranziţie reprezistă rii sursă a unui obiect, în urma unor acţiuni, datorită

eveniment.Tranziţiile dintre stă ri se produc în felul urmă tor:- un obiect este în stare surs ă ;- se produce un eveniment (de exemplu recep ţionarea unui- se execut ă o ac ţiune;- obiectul intr

ăîn starea

ţint

ă.

Într-o diagramă de stare pot exista:- una sau mai multe tranzi ţii dintr-o stare, deoarece fiecare ede un eveniment unic; în acest caz, spunem c ă existămulte ţinte;- din mai multe st ări pleacă aceea ş i tranziţie, deoarece acpoate declan ş a o tranzi ţie de la mai multe st ări surs ă ; în tranziţia cu mai multe surse;- tranziţie de la o stare la ea îns ăş i.



Tranziţiile se reprezintă , în UML, printr-o săgeată solidsursă spre starea ţintă , etichetată cu numele evenimentuseparat ă prin caracterul slash (‘/’), astfel:

Elementele etichetei sunt opţionale, dar nu poate exista În cazul în care un eveniment cauzează o tranziţie f ă r ă aatunci trebuie să lipsească ş i ‘/’ din eticheta unei tranziţii.

Uneori, o tranziţie se produce nu datorită unui evenimfaptului că o stare completeaz ă o acţiune. În acest cazetichetă se numesc tranzi ţ ii automate (automatic transitions).



3) Evenimente

Un eveniment este ceva ce se produce asupra unui elefrecvente evenimente sunt mesajele recep ţionate de un o

În UML, un eveniment are urmă toarea sintaxă :nume eveniment (list ă parametri) [condi ţ ia de g

unde:-nume eveniment – este, de obicei, acelaş i cu nelementului care corespunde în diagrama de stare ş i pentru evenimentul respectiv (de exemplu, achitarepornirea unui calculator, etc);

-lista de parametri – este opţională ş i conţine parametsepara ţi prin virgulă . Fiecare parametru poate fi o valoarvariabilă . Dacă evenimentul nu are parametri, se omit ş i p

- condi ţ ia de gard ă – este, de asemenea, op ţională ş i care trebuie satisf ăcută pentru ca o tranziţie să aibă loc. fi exprimată în limbaj natural, în limbaj de programare sa



În exemplul unui calculator, putem avea evenimentele urm

-Startup – indică faptul că un calculator trece din starea starea

ţint

ă, activ . Dac

ăcalculatorul este parolat, atunci e

UserID . De asemenea, exist ă posibilitatea ca un calculatpornit din anumite motive (pană de curent), atunci se impgardă : dac ă calculatorul poate fi pornit .

-Shutdown – indică faptul că un calculator, din starea activinactiv . Acest eveniment poate avea parametrul UserIDexistă posibilitatea ca un calculator să nu poate fi încmotive (de exemplu, nu au fost închise toate aplicaţiile), condiţia de gardă : dac ă calculatorul poate fi închis .

-Reset – indică faptul că respectivul calculator poate blocat în starea activ .

- Eroare Sistem – indică faptul că respectivul calculator atrece din starea activ în starea blocat .



4) Acţiuni:reprezintă o prelucrare executată de un obiectsursă , declanşată în urma producerii unui evenimerecep ţionarea unui mesaj). O ac ţiune nu poate fevenimente.

În UML, o acţiune are urmă toarea sintaxă :Valoare_returnat ă := element_ ţ int ă .nume_ac ţ iune (list

unde:- Valoare_returnat ă – este opţională ş i indică numelerezultată de ac ţiunea declanşată de un eveniment. Dac

câmp sau dac ă acţiunea nu întoarce nici o valoare, atuncaracterele “:=”.- Element_ ţ int ă – este numele elementului care va eDacă elementul care enun ţă acţiunea este acela ş i cuprimeş te evenimentul declanşator al acţiunii respective, ase omite, împreună cu caracterul punct (‘.’).- Nume ac ţ iune – este, de obicei, acela ş i cu numele operespectiv sau al opera ţiei elementului –ţintă , dacă acesta- List ă de argumente – este op ţională ş i indică parametriacţiune, separa ţi prin virgulă . Fiecare parametru poate fi valoare explicită .



Tipuri de evenimente ş i acţiuni În UML, există patru tipuri de evenimente: a)apeb)semnale; c)schimbarea condi ţiilor; d)scurgerea unui in

a) Eveniment – apel de opera ţie Apelul de opera ţ ie este un eveniment care, atunci câdetermină schimbă ri în starea elementului care primeş te a

Acest tip de eveniment este numit mesaj , se implementeaun mesaj sincron ş i apare în eticheta unei tranziţii. Astfetransmite un mesaj altui obiect (sau lui însuş i) ş i invcontrolul trece de la obiectul expeditor la obiectul deapelat execută tranziţia asociată evenimentului respecstarea ş i transmite apelantului controlul. Apelurile de opasincrone, dac ă limbajul care le implementează suportă c



b) Eveniment – semnal

Semnalul este un obiect expediat asincron de un obiectalt obiect. Acest tip de eveniment se numeş te tot mesajsemnă tur ă de eveniment într-o stare de tranziţie. declanşa o ac ţiune obiectului receptor într-o maş ină decă reia obiectul respectiv î ş i schimbă starea, sau poaasincron într-o diagramă de interacţiune. Semnalele pot care se scriu între paranteze rotunde.

Semnalele sunt definite ca un tip special de clas ă , s<<signal >>. Aceste clase sunt folosite numai pentru trimnu pot avea opera ţii, iar eventualii parametri ai semnalucompartimentul atributelor. Se poate construi o ierarhieadică între semnale pot exista rela ţii de generalizare, dorice relaţii cu clasele obişnuite.



Dacă o tranziţie are o semn ă tur ă de eveniment semnsubsemnalele vor putea fi recep ţionate prin acelaş i semnilustrat în figura de mai jos:



c) Eveniment – schimbareUn eveniment schimbare reprezintă trecerea unui obiectfuncţie de satisfacerea unei condi ţii. Condiţia apare în consemnă turii unei tranziţii. În UML, un astfel de evenimen

cuvântul cheie when , urmat de o expresie boolean ă . Sexpresie booleană pentru a indica o valoare (exemplu pentru testarea continu ă a unei expresii (ca de exemplu, [

d) Eveniment – temporalUn eveniment temporal este o întâmplare care depindtimpului. El se reprezintă în UML prin cuvântul cheieaftinterval de timp care reprezintă timpul scurs din momenla schimbarea st ă rii. Intervalul de timp poate fi redat expresie de timp, sau în orice mod, dar trebuie să fie Această combinaţie after+expresie_timp se trece în

tranziţii, la condiţia de gardă .De exemplu, putem reprezenta evenimentele temporale, [aft[after 2 secunde de la p ăr ăsirea st ării], etc. Într-un evenexpresia din condi ţia de gard ă poate s ă nu fie precedat ă dafter (de exemplu, putem scrie [timp = timpdat], în loc de [afte



Activităţ ile stărilor Pentru reprezentarea unei st ă ri, se foloseş te tot dreptunrotunjite, compartimentat în trei zone:

- Compartimentul superior este dedicat numelui stă rii, cscris indiferent dacă dreptunghiul este compartimentat sa

- În compartimentul din mijloc se scriu eventualele v(contori, date, constrângeri, etc.).

- În zona inferioar ă se trec activităţ ile, unde voevenimentele ş i acţiunile.



În cazul descrierii activităţ ilor, evenimentele ş i acţiunile auca ş i în cazul tranziţiilor ş i anume:

Nume eveniment (list ă _parametri) [condi ţ ie_ga /element_ ţ int ă .nume ac ţ iune (list ă _argumente

Nume eveniment poate fi orice, dar, de obicei, existăstandard care pot declan şa ac ţiuni stă rilor,ş i anume:- entry – specifică acţiunea care se produce atunci când starea respectiv ă ;- exit – specifică acţiunea care se execut ă atunci când ob

starea respectiv ă ;- do – specifică acţiunea care se execut ă atunci când obstarea respectiv ă .



Diagrame de stare

- Concepte ş i exemple -



Studiu de caz: ceas cu alarm ă1. Putem seta alarma “pornit” sau “oprit”;2. La timpul setat, alarma sună continuu;

3. Putem opri soneria.

Pasul 1. Desenarea unei diagrame de stareModelarea propoziţiei 1: Putem seta alarma “pornit” sa



Modelarea propoziţiei 2: La timpul setat, alarma sună c

Obs. Alarma trebuie să se opreasc ă si singur ă , dupăanumit interval de timp

O activitate în cadrul unei stă ri poate fi:

• “continuă”: se produce doar atunci când un evenim

face ca obiectul să iasă din stare;• “finită”: poate fi oprită de un eveniment, dar se poate odupă trecerea unui anumit interval de timp sau la încondiţii.



În exemplul de faţă , se adaug ă o activitate “Sună” în statranziţie automată care s ă iasă din starea Sonerie . O asse mai numeş te completion transition ş i se reprezintă în de eveniment sau cuvânt cheie.

Obs. Dacă se dore ş te dezactivarea alarmei în timp ce adaugat ă o tranziţie din starea Sonerie în starea Oprit ă .



Desenarea diagramei statice de context extinse ( excontext diagram ).



Diagrame de stare

- Concepte ş i exemple -



Studiu de caz: ceas digital

1. Modul curent e modul “Afişare”;

2. Când se apas ă o dată butonul, ecranul trece în “scpoate schimba ora (prin incrementare cu 1) prin apăsabutonului de Avans;

3. Dacă apăsa ţi butonul de mod din nou, ecranul treceminute”. Apăsând butonul Avans repetat, se modificăunitate.

4. Apăsând încă o dată butonul Mod, ceasul trece în “A



Desenarea diagramei de stare

Obs. În starea Afi ş are , e posibil să fie apăsat buton

apăsarea lui nu produce nici un eveniment, de aceereprezentat.



Se consider ă urmă toarea comportare: dac ă se apas ăAvans (mai mult de 2 secunde), incrementarea orei sapoate face mai repede

Cum poate fi modelat un asemenea comportament?

În exemplul de faţă , apăsarea butonului Avans o dată eperechea «apasa» ş i «eliberează». În condiţiile nouluise introduce evenimentul “eliberează buton” penteficient timpul de apăsare.

O primă soluţie ar fi inserarea unei condiţii asupapăsare, precum ş i a unei noi stă ri, numite “Increm(vezi figura de pe pagina urmă toare).



Obs . Soluţia de mai sus e incorect ă , pentru că apăsarpoate fi contorizată în timp (acţiunile sunt atomice).



Soluţii posibile:• introducerea unei activităţ i finite , “aş teaptă 2 sec”;• folosirea cuvântului cheie «after».



Să presupunem acum c ă se introduc alte două facilităţ i celumină ş i buton de alarmă .

În acest caz, avem 3 comportamente concurente:

1. controlul afisă rii;

2. controlul alarmei;3. controlul luminii.



Le tratăm în ordinea simplităţ ii:

3. Controlul luminii

Obs . Controlul luminii poate fi modelat independent de controlul alarmei.

1. Controlul alarmeise poate face ca în exemplul “Ceas cu



1. Controlul afişă rii depinde de st ă rile de pînă acum, înputem modifica, prin apăsarea butonului Mod, ş i timpulalarmei (prin modificarea oreiş i minutelor). De aceea, trenoi stă ri.



Să punem toate comportamentele împreun ă .- O primă soluţie: prin intermediul unei diagrame de clasă



- A doua soluţie: ar ă tând “regiunile concurente” din cadrul diagmai puţin folosită decât prima soluţie.



Introducere

Diagramele de interac ţiune permit specificarea în detaliu a mobiectele interac ţionează pentru a executa un task.

UML furnizează 2 tipuri de diagrame de interac ţiune:- diagrame de colaborare- diagrame de secven ţă .

Principala utilizare a acestor diagrame este de a ilustra msistemul realizeaz ă un caz de utilizare sau un anumit scenarde utilizare.



Diagrame de colaborare

Obiectele care interacţionează pentru a executa un taslegă turile dintre ele formează o colaborare .

Interac ţ iunea este reprezentat ă de secven ţă de mestransmise între obiecte.

Diagrama de colaborare cuprinde urmă toarele elemente:a) Obiecte : dreptunghi în care sunt scrise numele obiecclasei, separate prin “:”, toate subliniate. Dacă numele obanumită semnificaţie, poate fi omis (:NumeClasa); naceast ă utilizare dacă există două obiecte din aceea ş i cla

b) Leg ă turi : se reprezintă la fel ca asocierile

c) Actori : se reprezintă la fel ca în diagramele use-case. Îcolaborarea descrie un caz de utilizare, actorii din corespunde cu actorii din diagrama use-case corespunz ă tmai mulţi actori, însă numai unul singur va iniţia cazul de u



d) Mesaje : pe o diagram ă de colaborare, numele mesajeloală turi de liniile ce descriu legaturile dintre obiecte, itransmitere a mesajului e indicat ă printr-o s ăgeat ă .Dacă un mesaj este transmis de la un obiect a:A c ă tre obiec

destinatar (b) trebuie s ă înţeleag ă mesajul, adic ă este necedin care face parte obiectul (B) s ă existe o opera ţie mesajului. Cu alte cuvinte, construirea unor diagrame dcontribuie la identificarea asocierilor dintre clase ş i a operaposibil ca prima solu ţie să nu fie cea optim ă .Cum circul ă mesajele? (în varianta procedural ă )

Un obiect începe s ă lucreze atunci când prime ş te un mesajacel moment obiectul este activat . În cele din urmă , el trebr ăspuns celui care a trimis mesajul, iar între timp el poate fie poate trimite mesaje altor obiecte pentru a le face pe acestea sDacă trimite un mesaj, el va fi în continuare activ, dar nu va pupână când nu va primi r ăspuns la acest mesaj. Cu alte cuvintesincron , adică la transmiterea unui mesaj se transmite controprimeş te mesajul. În fiecare moment, totul poate fi imaginatactivări, fiecare activare fiind asociat ă cu un obiect care a pricare nu a r ăspuns înc ă . Obiectul asociat cu activarea aflatare controlul ş i poate s ă lucreze; obiectele asociate cu ceaş teapt ă r ăspuns la mesajele pe care le-au trimis.



Dacă obiectul asociat activ ării din vârful stivei trimite un care prime ş te mesajul prime ş te ş i controlul, iar activpoziţionată în vârful stivei.Pe de alt ă parte, obiectul asociat activ ării din vârful st

termine lucrul ş i să r ăspund ă la mesajul care l-a activat, fiinddin stivă . În acest caz, urm ă toarea activare va deveni vobiectul asociat acesteia va rec ăpă ta controlul.Obs. Nu este necesar ă reprezentarea mesajelor de r ăspuns de colaborare.

Pentru a ţine eviden ţa numărului de stive de activare, numerotate, folosind urm ă toarea regul ă : primul mesaj traobiect la altul este numerotat cu 1 (nu este socotit primulactorul care ini ţiază interac ţiunea la un obiect). Când un obun mesaj, num ărul acelui mesaj va fi folosit ca prefix pentrutrimise pân ă când a r ăspunde la acest mesaj.

Exemplu: dac ă mesajul care îl activeaz ă pe a este numerotatoate mesajele trimise între acest moment ş i r ăspunsul la acnumerotate cu 2.1.n.



Fig. Exemplu de numerotare a mesajelor



Diagrame de secven ţăO astfel de diagram ă pune în eviden ţă transmiterea mesajetimpului.

Obiectele ş i actorii sunt reprezenta ţi la capă tul de sus al unocare reprezint ă linia de via ţă a obiectelor, adic ă timpuperceput el de obiecte .Timpul cât este activat un obiect este reprezentat ca un drepce acoper ă linia de viaţă .



Opţional, păr ţi din acest dreptunghi pot fi ha ş urate, pentru a de timp cât acesta lucreaz ă . Tot op ţional pot fi reprezentatela mesaje, printr-o linie punctat ă .



Facilităţ i suplimentare ale diagramelor de interMesaje de la un obiect c ă tre el însu ş i Într-o diagramă de colaborare, se reprezint ă printr-o leg ă turespectiv ş i el însuş i. Într-o diagramă de secven ţă , se repsăgeat ă de la linia de via ţă a obiectului c ă tre ea îns ăşdreptunghiul sub ţire reprezentând noua activare este pu ţincel reprezentând vechea activare.



Reprezentarea valorilor returnate de mesaje În UML o valoare returnată este reprezentat ă pe s ăgeamesajul ini ţial ca o atribuire c ă tre o variabilă având un figura de pe pagina urm ă toare).

Crearea ş i distrugerea obiectelor a) Diagramele de colaborare arat ă care obiecte sunt createtimpul interac ţiunii folosind stereotipurile «create» ş i «dmesajelor corespunz ă toare. Alternativ, faptul c ă un obiect distrus în cadrul interac ţiunii se poate reprezenta prin constrârespectiv {destroyed} plasate în dreptunghiul care reprezintfigura de pe pagina urm ă toare). Dacă un obiect este atât crea în timpul interac ţiunii, se poate folosi constrângerea {transi

b) Diagramele de secven ţă arată că un obiect este creatacestuia în josul paginii. Distrugerea unui obiect este reprezen

X la sfâr ş itul dreptunghiului reprezentând perioada de activobiect e distrus de alt obiect va exista un mesaj de la efectueaz ă opera ţia de distrugere c ă tre semnul X.



Reprezentarea constrângerilor de timp

La diagramele de secven ţă , e util de ş tiut ş i momentele efecmesajele. Modalitatea eficient ă furnizată de UML esteconstrângeri de timp.



Reprezentarea la diferite nivele de abstrac ţie

Pentru ca interac ţiunea s ă fie descris ă la un nivel mai înalt poate folosi o subcolaborare , adică o submul ţime de obieclegă turile dintre ele. O subcolaborare poate fi privit ă ca un spoate fi reprezentat ă ca un pachet.



Exprimarea condi ţiilor

În UML transmiterea unui mesaj poate depinde de îndeplinire În cadrul diagramei, condiţiile vor apărea în paranteze d

poziţionate în fa ţa mesajelor corespunz ă toare.Dintr-un punct pot pleca orice num ăr de mesaje, cu condi ţaibă condi ţii disjuncte. O diagram ă de secven ţă cu me înso ţite de condi ţii poate fi implementat ă folosind structu“case”.

În cazul în care mai multe mesaje alternative sunt trimise acpentru a scoate în eviden ţă că una dintre alternativele respecaleas ă decât una ş i ele nu pot exista simultan, în diagramelinia de viaţă a obiectului destinatar va avea mai multe ramcorespunzând unei alternative.



Exemplu. Să presupunem exemplu cu centrul de închirieri CDadăugăm ipoteza c ă există 2 tipuri de CD-uri: obiş nuite ş i sobiş nuite pot fi împrumutate pentru o perioad ă mai lungă (timp ce CD-urile speciale mai pu ţin (1 săptămână).



IteraţiiPentru a ar ă ta că un mesaj poate fi trimis în mod repetat sasterisc pozi ţionat dup ă numărul mesajului. În plus, dup ă aindica o clauz ă de itera ţie (plasat ă între paranteze drepte), de câte ori va fi trimis mesajul.Exemple:• [n<10]: este echivalentul condiţiei while;

• [not x];

• [i:=1..10]: este echivalentul condiţiei for;• [y in Y]: mesajul e trimis în mod repetat pentru fiecare y din c



Figura de mai jos reprezint ă diagrama de secven ţă pentru ccare cump ăr ă un num ăr de produse dintr-un magazin.



Dacă un mesaj care e transmis în mod repetat are ca rezultatunui alt mesaj, atunci transmiterea acestuia din urm ă va fcâte ori e transmis ş i primul mesaj, dar acest lucru nu diagram ă .

Exemplul1. Ce rezultat va avea figura de mai jos?

Răspuns: xyxy.



Exemplul1. Ce rezultat va avea figura de mai jos?

Răspuns: xyyxyy.



Concuren ţa

Până acum s-a considerat tipuri de interac ţiune procedural transmiterea unui mesaj, obiectul care trimite mesajul a ş t

înainte de a- ş i continua func ţionarea. Este cazul cel mai întâdeoarece majoritatea sistemelor func ţioneaz ă pe un singur p

În cadrul sistemelor concurente, exist ă cazurile:

• un obiect trimite simultan mai multe mesaje: se reprezintsăge ţi care pleac ă din acela ş i loc, f ăr ă a avea asociate condi

• un actor sau un obiect activ trimite un mesaj la un anumit obiectul care lucreaz ă în acel moment este alt obiect din siste• un obiect trimite un mesaj asincron, adic ă un mesaj care pobiect s ă lucreze f ăr ă ca obiectul care atrimis mesajul s ă-ş i

În primul caz, schema de numerotare îmbricat ă descris ă mextins ă , în sensul posibilit ăţ ii ca la numerotarea mesajelor sau litere care s ă diferen ţieze mesajele trimise simultansitua ţii, schema de numerotare îmbricat ă î ş i pierde senfolosi numerotarea secevn ţială .



Tipuri de mesaje

Există mai multe tipuri de mesaje în UML:

• mesaje sincrone : specifice func ţionării procedurale

• mesaje de r ăspuns : reprezentarea e op ţională

• mesaje asincrone : nu a ş teapt ă r ăspuns, obiectul r ămâne a

• mesaje simple : nu a ş teapt ă r ăspuns, obiectul pierde contro



Exemplul1. La centrul de închirieri se consider ă că există şde statistic ă , responsabil ă cu eviden ţa CD-urilor care devinun moment dat (toate copiile au fost împrumutate).

Figura arat ă folosirea unui mesaj asincron.



Exemplul2 (pentru folosirea mesajelor simple). Automat pcerin ţe

• casa de bani va verifica dac ă suma de bani introdus ă de cl

cu pre ţul băuturii selectate;• dac ă suma este egal ă cu pre ţul, containerul de b ăuturi va l• dac ă suma este mai mare decât pre ţul, casa de bani va calcverifica dac ă acesta e disponibil în cas ă;• în cazul în care restul e disponibil, casa de bani returneazmagazia ofer ă produsul selectat;• dac ă restul nu e disponibil, casa de bani va returna banii clie• dac ă suma introdus ă de client e mai mic ă decât pre ţul probani va a ş tepta mai mul ţi bani ş i nu va face nimic.



Diagrame de componende desf ăş urare



Diagrame de componente

O diagramă de componente prezintă dependen ţele diverse componente software (cod surs ă , cod binar, execu legă turi dinamice-DLL, etc.) care compun un sistem dependen ţe sunt statice (au loc în etape de compilare ssau dinamice (au loc în timpul execuţiei).

O component ă este o parte fizică dintr-un sistem, un

există pe un calculator. În UML, noţiunea de compondesemneze atât un tip (o categorie) de obiecte, cât ş i fitipul respectiv (instanţa tipului).

De exemplu, o aplicaţie executabilă este o component ă

un tip (o categorie), în timp ce o aplicaţie care se executdat, care are o identitate în momentul execu ţiei, este o itip.



Reprezentare

Exemplu



Relaţia dintre componente ş i clase

Asemănări:- Au un nume format dintr-un ş ir de caractere.- Au instan ţe, care au un nume separat prin “:” de numele cl

al componentei.- Pot realiza interfe ţe.- Pot participa la rela ţii de asociere, de generalizare, de drealizare ş i de agregare (clase sau componente incluse îrespectiv componente).

Deosebiri:- Clasele sunt abstrac ţii ale unui set de atributecomponentele sunt p ăr ţi fizice dintr-un sistem, rezidente îutilizează componente când model ăm un lucru rezident celelalte cazuri, folosim, în modelare, clase.- Clasele au atribute ş i opera ţii, pe când componentele au

accesibile numai prin intermediul interfe ţelor lor.- O component ă este implementarea fizic ă a uneia sau a maconceptuale, cum sunt clasele ş i colabor ările; între implementările ei există o rela ţie de dependen ţă .



Componentele folosite în UML pot fi împăr ţite în trei categor• Componente fundamentale (desf ăş urare) – care

sistemelor executabile, ca de exemplu: executabile, DLLActiveX, JavaBeans, componente COM+, pagini WEB,

de date, etc.• Componente create de utilizator – care sunt produsprocesul de dezvoltare ş i care formeaz ă componentele fude exemplu: fi ş iere cu codul surs ă ş i de date. Aceste cofolosite în crearea, în modificarea ş i în dezvoltarea execut

• Componente de execu ţ ie – create ca o consecin ţă a foloexecutabil.

UML folose ş te ş i stereotipuri standard:• <<executable>> - pentru o component ă care poate fi

noduri;• <<library>> - pentru o component ă care reprezint ă bibliot• <<file>> - pentru o component ă care reprezint ă un fi ş

fi ş

ier sursă

;• <<table>> - pentru o component ă care reprezint ă o tabel

date;• <<document>> - pentru o component ă care reprezi

document.



InterfeţeComponentele au numai opera ţii, care pot fi accesaintermediul interfe ţelor lor. Interfe ţele unei entit ăţ i (clase sareprezint ă un set de opera ţii pe care entitatea le pune la dispentităţ i ş i care sunt ascunse prin încapsulare.

Reprezentare

O interfaţă realizată de o component ă se nume ş te interfa

sensul c ă interfaţa furnizeaz ă serviciile componentei celorlalO component ă poate furniza mai multe interfe ţe de export.

O interfaţă folosită de o component ă se nume ş te interfasensul c ă o component ă care acceseaz ă serviciile alteiconformeze interfe ţei acesteia.



Relaţiile de dependen ţă dintre componente

Rela ţ ia de dependen ţă dintre componente este o rcomponentă client la o componentă furnizor (server) ş i

că entităţ ile (clasele) incluse în componenta client pot msau utiliza clasele incluse în componenta furnizor (server)

Dependen ţele dintre componente se reprezintă , ca ş i înprin linii punctate între componenta utilizator (clientfurnizor de servicii (server), cu o săgeată orientată spfurnizor.

Se folosesc trei tipuri speciale de dependen ţe stereotipiza

a) dependen ţe de utilizare (use dependencies);b) dependen ţe de apartenen ţă (reside dependencies);c) dependen ţe de desf ăş urare (deploy dependencies).



a) Dependen ţe de utilizare (use dependencies)

O dependen ţă de utilizare este o rela ţie de la componenta ula componenta furnizor (server), care indic ă faptul că cofolose ş te sau depinde de componenta furnizor.

O dependen ţă de utilizare este reprezentat ă în mod asemde dependen ţă dintre clase, printr-o linie punctat ă , cu componenta furnizor sau spre interfa ţa acesteia.



b) Dependen ţe de apartenen ţă (reside dependencies)

O dependen ţă de apartenen ţă este o rela ţie de la o componeelement UML furnizor ş i indică faptul că elementul fucomponentei (asem ănă tor rela ţiei de agregare dintre cla

furnizor poate fi o clas ă concret ă sau o clas ă stere<<implementation class>>, <<interface>>), pachete sau subsi

Exemplucomponente :- Interfa ţ a Utilizator, care furnizeaz ă o interfa ţă prin care uinterac ţiona cu sistemul;- Dat e – pentru implementarea func ţionalităţ ii datelor memor

pachete ş i subsisteme :- Interfa ţ a Utilizator, care grupeaz ă clasele care furnizeautilizatorul;- Utilit

ăţ i – con

ţine date, timpul

şi alte clase de utilit

ăţi;

- Date - subsistem pentru prelucrarea datelor.

interfe ţe:IProduse – produse realizate (create sau scrise);IConsumabile – produse folosite (citite sau distruse).



- pachetul Utilit ăţ i apar ţine ambelor componente;- componenta Date con ţine ş i subsistemul Date , care în interiorul componentei (modul doi de reprezentarpachetul Utilit ăţ i este legat printr-o rela ţie de componenta client Date (modul întâi de reprezentare);- deoarece între pachetele Utilit ăţ i ş i Interfaţă Utilizatode dependen ţă , ele trebuie s ă facă parte din aceea ş i copachetul Interfa ţă Utilizator nu va putea fi utilizat.



Diagrame de desf ăş urareDiagrama de desf ăş urare descrie structura sistemului execu ţiei. Ea prezintă dispunerea fizic ă a diferitelor elemnumite noduri , care intr ă în componen ţa unui sistem,

programelor executabile pe aceste elemente. În diagrama dese indic ă nodurile ş i conexiunile unui model.

NoduriUn nod este resursa care este disponibil ă în timpul execusoftware ş i reprezint ă un procesor sau un dispozitiv , desf ăş urate ş i executate componentele sistemului.Un procesor este un nod care poate executa o component ăreţea). Fiecare nod trebuie s ă aibă un nume. La nivelul fiec ăfi identificate procese. Un procesor trebuie s ă aibă memcapabilităţ i de procesare (dispozitive de calcul, resurse umane

Un dispozitiv (echipament periferic) reprezint ă un element hsistemul din care face parte, nu are putere de calcul. Fiectrebuie s ă aibă un nume, care poate fi generic, ca de exemimprimantă , tastatur ă , modem, etc.



Distincţia dintre un dispozitiv ş i un procesor depinde de punasupra acestora. De exemplu: un terminal T va fi privit ca ucă tre utilizatorul terminalului ş i ca un procesor pentru un prcare se execut ă pe procesorul terminalului T.

În UML, un nod se reprezintă printr-un paralelipiped (de mcub), care este etichetat cu numele nodului, ca în figura de ma

Observa ţii privind numele unui nod:- în cazul în care nodul este o clas ă , numele poate fi ster- în cazul în care nodul face parte dintr-un pachet, numelde numele pachetului ş i separat de acesta prin simbolul “- în cazul în care nodul este un nod exemplu, numele ssimbolul “:” ş i de numele clasei de noduri, având toate psubliniate; ambele nume sunt op ţionale, iar simbolul numai dac ă este specificat numele clasei de noduri;



Exemple

- Client – tip procesor, pe care se execut ă componenta Inte- ServerBaze – tip procesor, pe care se execut ă componen- Imprimant ă – tip dispozitiv, folosit ă de sistem pentru a lis

Clase de noduri:

Instan ţe de clase de noduri:

- Andrei: Client; Ana: Client;- O instan ţă a nodului Server;- Hp100: Imprimant ă .



Organizarea nodurilor ş i legă turile dintre ele

Nodurile pot fi organizate în pachete, în acela ş i mod componentele.

O conexiune reprezint ă un tip hardware care realizeaz ă cupnoduri. Conexiunea poate fi direct ă , ca de exemplu prEthernet, linii telefonice, etc., sau indirect ă , ca de exemplu satelit.



Dependen ţe de desf ăş urare

O dependen ţă de desf ăş urare este o rela ţie de la o componcomponent ă client , la un nod, numit nod furnizor , ş i indicăcon ţine componenta respectiv ă .

O dependen ţă de desf ăş urare poate fi reprezentat ă în două- printr-o rela ţie de dependen ţă (o linie punctat ă cu o component ă la nod ş i având stereotipul <<desf ăş urare>> sa- componenta este reprezentat ă în interiorul nodului desf ăş urată (modul cel mai des utilizat).



Exemplu de diagram ă de componente ş i de desf ă

Se consider ă , iniţial, pachetele: Interfa ţă Utilizator ş i Utilităţ

Raportare, care furnizeaz ă interfeţele: IVizualizare (pentruecran a rapoartelor) ş i IPrintare (pentru printarea rparcurs se rafineaz ă diagrama cu urm ă toarele cerin ţe:

1. Pachetul Interfa ţă Utilizator foloseş te interfe ţele IVizualfurnizate de subsistemul Raportare.

2. Pachetele Interfa ţă Utilizator ş i Utilităţ i apar ţinInterfaţă Utilizator.

3. Subsistemul Raportare ş i pachetul Utilităţ i apar ţin Raportare.

4. Componenta Interfa ţă Utilizator este desf ăş urată pe nod5. Componenta Raportare este desf ăş urată pe nodul Server6. Nodul Client este conectat la nodul Server Raport, iar

Raport este conectat la nodul Imprimant ă .



Completă ri



Interfe ţe

O clasă serveş te două scopuri principale: defineş te interf în care clasa interacţionează cu mediul înconjur ă t

implementarea acestei interfeţe. Pentru claritate, unesepararea acestor dou ă aspecte.

În UML, ointerfa ţă specifică o colecţie de opera ţii pe cfurnizeze o clasă sau o component ă . Interfaţa nu cuprindacestor opera ţii ş i nici nu face nicio referire la stare

corespunde acestei interfe ţe. Cu alte cuvinte, interfaţa nuInterfaţa specifică opera ţiile unui element, de exemplu ovizibile în afara acestuia. Ea nu trebuie să specifice tocare le poate efectua acel element, astfel încât acela şcorespunde mai multor interfeţe, iar o interfaţă poate multor elemente.



O interfaţă e definită într-o diagramă de clase printr-un dopera ţiile listate în compartimentul de jos, la fel ca lacompartiment pentru atribute). În primul compartiment,

clasei, va apă rea stereotipul «interface».Producă tor

.....

marfaLivrata():Marfa

«interface»Livrare

marfaLivrata():Marfa

◄ distribuie marfa

Clasa Produc ă tor realizează interfaţa Livrare . Acest lucprin săgeată . Realizarea poate fi privită ca o moş tenire: furnizează cel puţin toate opera ţiile furnizate de interfaţafurniza ş i operaţii suplimentare. Pe de altă parte, clasa Prsă furnizeze singur ă implementă rile acestei opera ţii.



Reprezentarea unei interfe ţe se poate face ş i printr-unLivrare , ataşat dreptunghiului ce reprezintă clasa Produc de mai jos).

Clasa Distribuitor depinde numai de interfaţa LIvrare , reprezentat printr-o săgeată de dependen ţă



Stereotipul «implementation class»

O clasă care are stereotipul «implementation cimplementarea fizică a opera ţiilor ş i atributelor sale. Opoate realiza o clas

ă«type».

O clasă care are stereotipul «type» este la fel ca o interfaptului că poate avea stare, adic ă poate avea ş i atriparte, aceast ă clasă nu poate include elemente de implem

Un obiect poate avea o singur ă clasă «implementation cavea mai multe clase «type».

Exemplu. Un joc de şah poate avea o clas ă «type», caredeclaraţiile mută rilor ş i coordonatele tablei de şah ş i o aconţină implementarea lor.



Dependen ţe

În general, o clasa A depinde de o clasă B dacă o mpoate produce modificarea lui A. Dependenţa se reprepunctat

ăcu o s

ăgeat

ăde la A la B.

Care e diferenţa dintre o dependen ţă ş i o asociere? Asoo relaţie între obiectele din clasele respective, pe când do relaţie dintre clase



Pachete

Un pachet e o colec ţie de elemente. În UML, pacheteleorice fel de diagramă . În plus, e posibilă reprezenta(dependen

ţe, asocieri) între pachete sau între un pachet

din afara acestuia pentru a pune în eviden ţă că opachetului participă la o anumită relaţie.

Un pachet poate fi folosit în mai multe feluri:

• pentru a ascunde anumite detalii dintr-o diagramă (câirelevante)• pentru a înţelege mai bine modul în care o componeinteracţionează cu celelalte ş i a specifica aceast ă comde restul sistemului

• pentru a separa p ă r ţi ale sistemului care pot fi impleeventual de echipe diferite; în acest caz, se folose ş te upachet, numit subsistem.



Importulş i accesarea unui pachet : pentru ca un element P să vadă în interiorul unui pachet Q care nu îl conecesar ca P s ă îl importe pe Q. Importul sau accesarereprezintă printr-o săgeată de dependen ţă pe care se

«import» sau «access». Diferenţa dintre import ş i accfaptul că în primul caz elementele din pachetul importaş i cum se află în pachetul car eface importul.

Un pachet poate con ţine elemente publice sau private, csu simbolurile “+”, respectiv “-”.

Între pachete pot exista ş i relaţii de moş tenire. Între pachete pot exista ş i dependen ţe, dac ă exisdependen ţă între două elemente (clase) ale acDependen ţa nu e tranzitivă .

Un subsistem e un pachet ce prezint ă o parte independefiind reprezentat ca un pachet care are specif«subsystem» ş i numele lui. Subsistemele sunt folosite sistemului în pă r ţi care pot fi proiectate ş i implemindependent.



Aplica ţia Microsoft VISIO

1. Scurt ă prezentare a programului VISIO

Elementele interfeţei utilizatorului:• Bara de meniu

• Bara standard de unelte

• Bara de formatare

• Bara de stare

Când lansăm Visio pentru prima oar ă ni se va afişa o listă de categoriişi template-uri(numărul lor difer ă datorită tipurilor de instalări; aici s-a folosit instalarea typical) care ne ajută să începem lucrul:



2. Crearea diagramelor UML utilizând aplica ţia VISIO

Accesăm de pe bara standard meniulFile-> New-> Software-> UML Model Diagram

şi se va deschide în stâna panoul cu diagramele UML:



Pentru a-i da un alt aspect, de exemplu pentru a face o săgeată, se dă dublu clic pe formă. Înfereastra care apare se bifează în Association Ends în coloana IsNavigable, End 1 sau End 2 (după preferinţă).

d) Extends (relaţia de extindere). În figura de mai jos se dă un exemplu de folosire a relaţiei«extends»:



e) Uses . Această formă se foloseşte atunci când o altă formă A va includeşi comportamentulformei B. Pentru a nu se afişa stereotipulşi numele, se dă clic dreapta pe formă, de unde se alegeopţiuneaShape Display Options. Se va deselectaName şi Stereotype:

f) System boundary. Pentru a-i da un nume sistemului, se va da clic pe numele care apareimplicit (în acest caz “System”) şi se va putea da noul nume.

Într-o diagramă, o astfel de formă se foloseşte ca o limită care înconjoar ă cazurile de

utilizare. Pentru a-i da dimensiunea dorită, se va da clic pe formă şi se vo rtrage marcajele de pe perimetrul formei.Pentru a face o formă în cadrul unui sistem, se va lua acea formă cu Drag&Drop şi se va

introduce în sistem ca în figura de mai jos.



2.2 Desenarea diagramelor de clas ă În panoul din stânga, se alege matriţa UML static structure.

a) Pentru adăugarea unei interfeţe claselor, componentelor sau altor elemente, într-ocomponentă de diagramă de clasă sau diagramă de componenteşi de desf ăşurare, se trage o formă

Interface (reprezentată cu o linieşi cu un cerc) pe pagina de desen.Se lipeşte sfâr şitul de cursorul f ăr ă cerc, la o conexiune x din componenta clasă sau altelement. Se dă dublu-clic pe forma Interface pentru a adăuga un nume, operaţiile şi alte proprietăţide valori.

Se poate de asemenea să reprezentaţi o interfaţă cu o formă Interface dreptunghiular ă ceacare seamănă cu o clasă. Se foloseşte această formă atunci când se vrea afişarea unei liste cuoperaţiile interfeţei. Pentru a schimba tipul formei care apare pentru o interfaţă se dă clic dreapta peforma Interfaceşi clic peShow as Class-like Interface sauShow as Lollipop Interface .



Într-o diagramă de structur ă statică se poate realiza o relaţie între o clasă şi o interfaţă sau un

alt element. Se dă clic dreapta pe orice formă (Class, Parameterized Class, Utility sau MetaClass),clic peShape Display Options:



şi apoi, sub grupulGeneral Options se selectează Realization Link .

Se lipeşte bara conducătoare pentru a realiza legătura pe o formă clasă la o conexiune x peinterfaţa, clasă sau alt element.



b) Pentru crearea unui obiect ca un exemplu al unei clase, într-o diagramă de structur ă statică se trage o formă Class pe pagina de desen pentru a reprezenta obiectul dorit. Opţional dubluclic pe forma Class pentru a deschide fereastra de dialog UML Class Properties. Clic peAttributes şi apoi clicNew pentru a adăuga atributele clasei.

c) Se trage o formă Object pe pagina de desenşi apoi dublu clic pe forma. În fereastra dedialogUML Object Properties clic peObject şi se tastează un nume pentru obiect.



Clic peAttribute Values şi se selectează atributul căruia i se adaugă o valoare dorită şi apoiclic peProperties . Se tastează o valoare pentru atribut. Clic peAttribute Link , se adaugă orice proprietate dorită şi apoi clic OK. Se repetă ultimii paşi pentru toate atributele care se doresc să fieadăugate.

Ştergerea parametrilor formali de la o clasă se face cu dublu clic pe forma (ParameterizedClass, Class, Utility, Metaclass sau Bound Element) care reprezintă elementul cu parametrii care seşterg şi apoi clic peTemplate Parameters . Se selectează parametrul care seşterge, clic pe deleteşiapoi clic OK.

Pentru a edita parametrii formali pentru o clasă se dă dublu-clic pe forma (ParameterizedClass, Class, Utility, Metaclass, sau Bound Element) care reprezintă elementul cu parametrii editaţişi apoi clicTemplate Parameters . În Template pentru fiecare parametru editat clicType apoi clic pe săgeată şi se selectează un tip din listă. În Template pentru fiecare parametru editat se tastează unnume nou. În casetaDocumentation se tastează documentaţia dorită.

Clic New pentru a se adăuga alt parametru sau clic OK pentru a închide cutia de dialogUML Class Properties .



Ascunderea atributelor şi secţiilor de operaţii ale unei clase se realizează cu clic dreapta pe formaClass şi apoi clicShape Display Option .

În caseta de dialogUML Shape Display Options , sub Suppress, se selectează Attributes pentru a ascunde partea de atributşi apoi se selectează Operations pentru a ascunde secţia deoperaţii.



Pentru indicarea claselor dintr-un pachet, într-o diagramă pachet se trage o formă

Dependency pe pagina de desen. Se lipeşte sfâr şitul de cursor din Dependency f ăr ă vârful desăgeată la o conexiune spre pachet care va dori referinţa claselor în alt pachet.

Se lipeşte sfâr şitul de cursor din Dependency cu vârful de săgeată la o conexiune x pe pachetcare conţine ţinta claselor care va fi referinţa. Dublu clic pe forma Dependency pentru a deschide

fereastra de dialogUML Dependency Properties . Sub Name se tastează un nume pentrudependenţă. SubStereotype se alegeImport :



Pentru a ar ăta implementarea unui tip cu o clasă implementată, într-o diagramă de structur ă statică se trage o formă Class pe pagina de desen. Dublu clic pe formă. În fereastra de dialogUMLClass Properties clic peClass şi se tastează un nume pentru clasă. SubStereotype se alegeType şi apoi clic OK.

Se trage a doua formă Class pe pagina de desen. Dublu-clic pe formă. În fereastra de dialogUML Class Properties clic Classşi se tastează un nume pentru clasă. Sub Stereotype se alegeImplementation Class.



Clic-dreapta pe caseta de implementareşi clic Shape Display Options. În fereastra de dialogUML Shape Display Options, sub General Option se selectează Realization Link.

Se lipeşte bara conducătoare pe forma de clasă de implementare pentru a crea un conector care reprezintă o relaţie. Dublu-clic pe orice formă pentru a deschide caseta de dialog a proprietăţilor UML, unde se pot adăuga atribute, operaţii şi alte proprietăţi.



Clic-dreapta pe orice formă de clasă sau obiectşi apoi clic pe SHAPE DISPLAY OPTION pentru a selecta ce proprietate se afişează pe formă şi ce compartiment de formă se interzice (cumar fi atributele, operaţiile şi parametrii formali)

Pentru a indica relaţiile între clase şi obiecte folosim formele Association, Link,Dependency, Generalization sau Composition.

Pentru adăugarea calificativelor la o asociaţie se dă dublu-clic pe forma Binary Association,Association Class, N-ary Association sau N-ary Association Class căreia i se adaugă un calificativ.În Association Ends se selectează asocierea de sfâr şit căreia i se adaugă un calificativşi apoi clicProperties.

Clic Qualifier Attributes, clic NEWşi apoi clic PROPERTIES. Se scrie sau se alege valorile pentru proprietăţile calificativului.

Pentru a indica o relaţie de compoziţie între clase se trage o formă Composition dindiagrama de clasă UML în pagina de desen aproape de clasa relatată.

Se duce cursorul lângă diamant către un punct de legătur ă x din clasă şi celălalt element dincomponenta sa. Se duce cursorul f ăr ă diamant către un punct de legătur ă al clasei din componentasa. Dublu-clic pe forma Composition pentru a se adăuga un numeşi asocierile adăugărilor desfâr şit.



De asemenea, se poate indica poziţia adăugând asocierile de final a formelor BinaryAssociation, Association Class sau N-ary Association. Dublu-clic pe formă. Se selectează sfâr şitulîn care se vrea adăugarea compoziţiei diamantşi apoi clic pe proprietăţi. Clic pe Association Endşisub Aggregation se alege Composite.



2.3 Diagrama de componente şi de desf ăş urare

Din panoul din stânga cu diagramele UML se alege prin clic eticheta diagramei dorite, înacest caz diagrama de componenteşi de desf ăşurare (Collaboration and Deployment Diagrams).

Pentru toate simbolurile utilizate se foloseşte procedeul “Drag & Drop”, iar pentru a le

completa se dă dublu click pe desenşi se completează conform ferestrei de mai jos astfel: la Name,numele instanţei şi la Component selectaţi New pentru a completa numele componentei.

[Nume instanta] : Num e Com ponenta

Reprezentarea interfeţei unei componente. După ce se aduce diagrama Interface în pagina dedesen, se dă dublu click pe diagramă şi se scrie numele acesteia.



Reprezentarea dependen ţei. Se selectează Dependencyşi se trage în pagina de desen.Pentru a avea o linie dreapta se dă clic pe desenşi se selectează Straight Connector.

Desen.cpp Desen.exe



Reprezentarea nodului. Se selectează NodeInstanceşi se trage în pagina de desen. Se dă dublu click pe desenşi se completează numele la opţiunea Nameşi la opţiunea Node se dă New pentru a se alege instanţele ale acestor noduri.

I m p r im a n t a H P 1 0 0 :I m p r im a n t a



2.4 Diagrama de colaborare

Din panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, înacest caz – diagrama de de colaborare (Collaboration Diagram).

Din eticheta aleasă se va extinde o pagină ce conţine toate obiectele (formele) ce pot fi folositeîntr-o diagramă de secvenţă.

În continuare se alege pe rând câte un obiect din panoul din stângaşi se trage pe suprafaţa delucru. Cu click-dreapta i se completează sau modifică proprietăţile.Pentru crearea unui obiect se alege din panoul din stânga obiectul cu denumirea Classifier

Roleşi se trage pe pagina de lucru.

Pentru a se completa sau modifica proprietăţile se dă click-dreapta pe obiectşi se alegeopţiunea Properties. Se va deschide fereastra UML Classifier Role Properties.

Se completează numele obiectului în câmpul Nameşi se alege clasa din care face parte din

câmpul Classifier. Dacă nu găsiţi clasa respectivă se poate crea una nouă cu butonul New. Se vadeschide fereastra UML Class Properties în care se creează clasa din care face parte obiectul.



Se completează numele clasei în câmpul Nameşi eventual alte proprietăţi pe care le găsiţi înlista din stânga.

Dacă există constrângeri, acestea se pot completa la a doua proprietate Constraints. Pentrusalvarea acestor informaţii se alege butonul OK.

Alte proprietăţi – cele de afişare – se pot seta apelândopţiunea Shape Display Option cu click-dreapta pe State.

Se va deschide fereastra UML Shape Display Option. De aici se aleg opţiunile care se potseta :



Există opţiunea de a afişa numele obiectului sau/şi clasa din care face parte obiectul. Deasemenea se poate ataşa semnul de destructor.

Crearea unui comunicări – Se alege din panoul din stânga obiectul cu denumirea AssociationRoleşi se trage pe pagina de lucru.

Pentru a modifica proprietăţile se acţionează click dreapta pe săgeată şi se va deschidefereastra UML Association Role Properties care prezintă în partea stângă o listă cu proprietăţi.

Alegem a doua linie Messagesşi în tabelul alăturat completăm denumirea mesajului, direcţia deorientare a mesajuluişi tipul mesajului (simplu, sincron, asincron):

Apoi se apelează butonul Properties din dreapta. Se va deschide fereastra UML MessageProperties. La prima apelare se va deschide automatşi fereastra UML Operation Properties:

Se completează numele operaţiei (în cazul de faţă Print)şi apoi dacă există argumente pentruaceastă operaţie de apelează din lista din stânga Arguments :



Pentru a adăuga un argument se apelează butonul New din dreapta. Operaţia se va repeta

pentru fiecare nou argument. Se validează cu OK. Se revine în fereastra UML Message Properties:

Operaţia va fi completată în câmpul Operation. Se validează cu OK.

2.5 Diagrama de secven ţă

Din panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, în

acest caz – diagrama de secvenţă (Sequence Diagram).Din eticheta aleasă se va extinde o pagină ce conţine toate obiectele (formele) ce pot fi folositeîntr-o diagramă de secvenţă. În continuare se alege pe rând câte un obiect din panoul din stângaşise trage pe suprafaţa de lucru. Cu click-dreapta i se completează sau modifică proprietăţile.



Pentru a crea un obiect se alege din panoul din stânga obiectul cu denumirea ObjectLifelineşise trage pe pagina de lucru.

Pentru a se completa sau modifica proprietăţile se dă click-dreapta pe obiectşi se alegeopţiunea Properties. Se va deschide fereastra UML Classifier Role Properties.

Pentru prima proprietate – Classifier Role - se furnizează un nume pentru obiectul ce s-a creat:

Dacă există constrângeri, acestea se pot completa la a doua proprietate Constraints.Pentru a completa alte proprietăţi – cele de afişare – se pot seta apelând opţiunea Shape

Display Option cu click-dreapta pe State ca în cazul diagramei de mai sus.Linia de viaţă aferentă unui obiect se creează în Visio automat.Pentru crearea unei activări se alege din panoul din stânga obiectul cu denumirea Activation şi

se trage pe pagina de lucru.Pentru crearea unui mesaj se alege din panoul din stânga obiectul cu denumirea Message şi se

trage pe pagina de lucru.Pentru a modifica proprietăţile se acţionează click dreapta pe săgeată şi se va deschide

fereastra UML Message Properties La Message se poate modifica conţinutul mesajului în câmpul Name.

2.6 Diagrama de stareDin panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, în

acest caz – diagrama de stare (State Diagram). În continuare se alege pe rând câte un obiect din panoul din dreaptaşi se trage pe suprafaţa de lucru. Cu click-dreapta i se completează sau modifică proprietăţile.

Pentru crearea unei stări se alege din panoul din stânga obiectul cu denumirea Stateşi setrage pe pagina de lucru.

Pentru a se completa sau modifica proprietăţile se dă click-dreapta pe stareşi se alegeopţiunea Properties. Se va deschide fereastra UML Class Properties care în partea dreaptă cuprindeo listă cu proprietăţile ce pot fi modificate sau completate.

Pentru prima proprietate - State - se poate modifica numele stării:



La alegerea celei de-a treia poziţii – Exit – se apelează butonul New pentru a adăuga oacţiune. Se deschide fereastra New Action Type, din care se alege tipul dorit.

Pentru a doua opţiune – Entry – ce simbolizează acţiunea care se produce atunci cândobiectul intr ă în starea respectivă – se procedează asemănător.

Alte proprietăţi – cele de afişare – se pot seta apelând opţiunea Shape Display Option.

Există opţiunea de a suprima la afişare anumite păr ţi ale unei stări: de exemplu, por ţiuneaTransition (care cuprinde evenimentele standard – de intrare (Entry)şi de ieşire(Exit)).

Pentru crearea unei stări compuse se alege din panoul din stânga obiectul cu denumirea Statesi se trage pe pagina de lucru. În structura arborescentă şi pe suprafaţa de lucru va apărea o nouă pagină în care se vor desena substări concurente, mutual exclusive sau imbricate ale stării.

Pentru a reprezenta o tranziţie se alege forma Transition din panoul din dreapta.Pentru a modifica proprietăţile se acţionează click dreapta pe tranziţie şi se va deschide

fereastra UML Transition Properties. La Transition se poate modifica numele tranziţiei şi se potcompleta evenimentul/ evenimentele asociate tranziţiei astfel:

Se acţionează butonul Events; se va deschide fereastra UML Events care cuprinde lista

evenimentelor.



2.7 Diagrama de activitate

Din panoul din stânga cu diagramele UML se alege prin click eticheta diagramei dorite, înacest caz – diagrama de activitate (Activity Diagram). Din eticheta aleasă se va extinde o pagină ceconţine toate obiectele (formele) ce pot fi folosite într-o diagramă de activitate. În continuare sealege pe rând câte un obiect din panoul din dreaptaşi se trage pe suprafaţa de lucru. Cu click-dreapta i se completează sau modifică proprietăţile.

Pentru crearea unei activităţi se alege din panoul din stânga obiectul cu denumirea Action.Pentru a se completa sau modifica proprietăţile se dă click-dreapta pe activitateşi se alege

opţiunea Properties. Se va deschide fereastra UML Action State Properties care în partea dreaptă cuprinde o listă cu proprietăţile ce pot fi modificate sau completate.

Pentru prima proprietate - Action State - se poate modifica numele acţiunii:

La alegerea celei de-a doua poziţii – Call Action – se apelează butonul New pentru a adăuga

o acţiune. Se deschide fereastra New Action Type, din care se alege tipul dorit.Fluxul de control al tranziţiilor indică ordinea acţiunilor în secvenţă. Pentru a reprezenta un

flux de control se alege cu click forma Flow Control din panoul din dreaptaşi se trage pe pagina delucru. Pentru a modifica proprietăţile se acţionează click dreapta pe fluxul de control respectivşi seva deschide fereastra UML Transition Properties care prezintă în partea stângă o listă cu proprietăţile. La Transition se poate modifica numele tranziţiei şi se pot completa evenimentul/evenimentele asociate tranziţiei astfel:

uml – scurtă prezentare

Documents