Sunteți pe pagina 1din 31

ISS Curs 4

4. LIMBAJUL UNIFICAT DE MODELARE (UML)

4. LIMBAJUL UNIFICAT DE MODELARE UML


4.1. UML. Prezentare generală
4.1.1. Istoric. Efortul de unificare şi standardizare
4.1.2. Organizare
4.1.3. Tipuri de diagrame
4.2. Modelarea cerinţelor
4.2.1. Diagrama cazurilor de utilizare
4.2.2. Diagrama de activităţi
4.3. Modelarea claselor
4.3.1. Diagrama de clase
4.3.2. Diagrama de obiecte
4.4. Modelarea dinamică
4.4.1. Diagrame de interacţiune
4.4.2. Diagrama de stări
4.5. Modelarea arhitecturii
4.5.1. Diagrama de pachete
4.5.2. Diagrama de distribuire
4.5.3. Diagrama de componente

4.1 UML. Prezentare generală

4.1.1. Istoric. Efortul de unificare şi standardizare


UML este o notaţie generală folosită pentru
• vizualizarea
• specificarea
• construirea şi
• documentarea
artefactelor unui sistem soft.
artefact = specificarea unei informaţii folosită sau produsă în timpul procesului soft (precum
un document extern sau produs rezultat al procesului), sau în timpul desfăşurării sau
exploatării sistemului soft
• poate fi un model, o descriere, sau o componentă a sistemului soft
UML este rezultatul unui efort de unificare, simplificare şi standardizare a notaţiilor folosite
de diverse metodologii OO:
– Shlaer-Mellor [1988]
– CRC - Wirfs-Brook [1990]
– Coad/Yourdon [1991]
– Booch [1991]
– OMT - Rumbaugh [1991]
– Objectory - Jacobson [1992]

Efortul de unificare
• Fusion (Coleman 94)
– concepte preluate de la OMT, Booch, CRC
• Rational Software Corp
1
– 1994: Rumbaugh se alătură lui Booch: Rational
– 1995: prima propunere - concepte din OMT şi Booch
– 1995: Jacobson se alătură Rational -> UML
• Object Management Group – www.omg.org
– 1996: RFP pentru o abordare standard a modelării obiectuale (RFP = Request
For Proposal)
– sept 1997: Rational trimite propunerea UML finală la OMG
• mulţi oameni au contribuit la produsul final

Efortul de standardizare
• Object Management Group – www.omg.org
– nov 1997: UML adoptat ca standard [UML 98]
– OMG preia responsabilitatea pentru evoluţia standardului UML
• 1998: UML 1.1
• UML 1.2
• 1999: UML 1.3
• UML 1.4
• 2003: UML 1.5
• UML 2.0
– propuneri: Nov 2000 - Jul 2003
– specificaţia adoptată

UML: Istoric (vezi şi http://vinci.org/uml/index.html)

2
4.1.2. Organizare
Concepte UML
• model: o descriere completă semantic a unui sistem
• element al modelului: o abstractizare extrasă din domeniul sistemului supus modelării
– elemente din lumea reală (domeniul problemei)
– elemente artificiale (domeniul soluţiei)
• nivele de organizare
– domeniu major major area: nivelul cel mai general
– vedere view: subset de construcţii de modelare care reprezintă un aspect al
sistemului
– diagramă: prezentare grafică a unei colecţii de elemente ale modelului, având
de regulă forma unui graf în care vârfurile reprezintă elemente ale modelului,
iar arcele relaţii dintre acestea
– concept: idee, noţiune sau entitate abstractă, universală

Domenii majore şi vederi


• pentru clasificarea structurală
– descriu lucruri (obiecte) din sistem şi relaţiile acestora cu alte lucruri (obiecte)
– conceptul de clasificare: modelarea lucrurilor din sistem
• classificatori: clasa, cazul de utilizare, actorul, nodul, colaborarea,
componenta
– vederi: vederea statică, vederea de proiectare, vederea cazurilor de utilizare
• pentru comportamentul dinamic
– descriu comportamentul dinamic (în timp) al sistemului
– vederi: vederea stărilor, vederea activităţilor, vederea interacţiunilor
• fizice
– descriu resursele de calcul folosite de sistem şi maparea artefactelor pe ele
– vedere: vederea de desfăşurare
• pentru gestiunea modelelor
– descriu organizarea modelelor în unităţi ierarhice
– vederi: vederea gestiunii modelului, profiluri

Vederi şi diagrame pentru clasificarea structurală


• vederea statică
– modelează concepte din domeniul aplicaţiei şi din domeniul soluţiilor
(modelarea logică)
– diagrame: diagrama de clase
• vederea de proiectare
– modelează structura de proiectare a sistemului soft precum
• descompunerea în alte componente şi colaborările ce asigură
funcţionalitatea
• asamblarea din componente cu interfeţe bine definite
– diagrame: diagrama structurii nterne, diagrama de colaborări, diagrama de
componente
• vederea cazurilor de utilizare
– modelează funcţionalitatea sistemului aşa cum este ea percepută de actori
(agenţi externi), care interacţionează cu sistemul dintr-un anumit punct de
vedere
• caz de utilizare: unitate de funcţionalitate exprimată ca o interacţiune
(tranzacţie) între actori şi sistem
• scopul vederii cazurilor de utilizare este să enumere actorii şi cazurile
de utilizare
– diagrame: use case diagram
• vederea stărilor
– modelează posibilele stări ale unui obiect o instanţă a clasei C
3
• conţine stări (noduri) conectate prin tranziţii de stare (arce)
• fiecare stare modelează o perioadă din viaţa lui o în care acesta
satisface anumite condiţii
– diagrame: diagrama de (maşinilor cu) stări
• vederea activităţilor
– ilustrează fluxul de control dintre activităţile implicate în execuţia unui proces
de calcul sau workflow
• acţiune: pas de calcul elementar (primitiv)
• nod de activitate: grup de acţiuni sau subactivităţi ce descriu atât
procese de calcul secvenţiale, cât şi concurente
– diagrame: diagrama de activităţi
• vederea interacţiunilor
– descrie şirul de schimburi de mesaje dintre părţile sistemului
• mesaj: comunicare de la un obiect la altul
– diagrame: diagrama de secvenţe, diagrama de comunicare (colaborări)

Vederi şi diagrame pentru domeniul fizic şi gestiune


Domeniul fizic
• vederea de desfăşurare
– reprezintă desfăşurarea la execuţie a artefactelor în noduri (resurse:
calculatoare, dispozitive, memorie)
– diagrame: diagrama de desfăşurare
Gestiunea modelelor
• vederea gestiunii modelelor
– modelează organizarea modelului
• model: set of pachete care ce conţin elemente ale modelului: clase,
maşini cu stări, cazuri de utilizare
– descriere completă a sistemului cu o precizie dată şi dintr-un
anumit punct de vedere
• pachet: unitate pentru
– manipularea conţinutului modelului
– controlul accesului şi configuraţiei
– diagrame: diagrama de pachete
• profile şi constrângeri
– permit particularizarea UML la domenii sau platforme particulare domains or
platforms
– construcţii de extensibilitate: constrângeri, stereotipuri, valori cu tag-uri
– diagrame: diagrama de pachete

4.1.3. Tipuri de diagrame


Diagrame pentru vederile structurale
vederea statică
• diagrama de clase: mulţime de clase (noduri) şi relaţiile dintre ele (arce)
– clasă: descriere a unui concept din domeniul aplicaţii
• atribute, operaţii
– relaţii: asociere, generalizare, dependenţe: realizare şi folosire
vederea de proiectare
• diagrama de structură internă: ilustrează descompunerea unei clase (UML 2.0)
• diagrama de colaborări: ilustrează relaţiile contextuale dintre o mulţime de obiecte
care colaborează pentru a realiza un scop anume (UML 2.0)
– conţine o colecţie de roluri (rol: apariţie individuală într-un context specific)
• diagrama de componente: ilustrează componentele unui sistem şi interdependenţele
lor
– componentă: unitate software folosită la construirea aplicaţiilor
4
• parte modulară a unui proiect de sistem care-şi ascunde implementarea
în spatele unui set de interfeţe externe
vederea cazurilor de utilizare
• diagrama de cazuri de utilizare: descrie interacţiunile dintre sistem şi actori
– relaţii: include, extend

Diagrame pentru vederile dinamice


vederea stărilor
• diagrama stărilor: cum reacţionează un obiect la evenimente din exterior
– se foloseşte pentru a descrie: interfeţele cu utilizatorul, controlerele de
periferice, alte subsisteme reactive
vederea activităţilor
• diagrama de activităţi: fluxul de control dintre activităţi
– se foloseşte pentru modelarea conceptuală - workflow-urile din domeniul
aplicaţiei, din organizaţia reală
vederea interacţiunilor
• diagrama de secvenţe: o secvenţă temporală de mesaje între roluri
– rolurile prezentate ca linii de viaţă - verticale
– mesajele prezentate ca linii orientate între liniile de viaţă
• diagrama de comunicare (din UML 2.0, înainte colaborări): rolurile în interacţiune
– rolurile prezentate ca dreptunghiuri
– mesajele prezentate ca linii orientate între obiectele ce joacă diverse roluri

Diagrame pentru vederile de desfăşurare şi gestiune


vederea de desfăşurare
• diagrama de desfăşurare: repartizarea artefactelor fizice pe noduri
– resurse de calcul (noduri)
– componente software (artefacte)
vederea gestiunii modelului
• diagrama de pachete: organizarea modelului
– modelul: mulţime (set) de pachete
• relaţii de dependenţă
– un pachet poate conţine alte pachete
• diagrame structurale – ilustrează aspectele statice ale sistemului soft
– de clase şi de obiect, de componente, de desfăşurare
• diagrame funcţionale – ilustrează funcţiile sistemului soft
– de cazuri de utilizare, de activităţi
• diagrame de comportament – ilustrează aspectele dinamice ale sistemului soft
– de interacţiune, de stări
• UML 2.0: http://www.agilemodeling.com/essays/umlDiagrams.htm

5
6
4.2 Modelarea cerinţelor cu UML

4.2.1. Diagrama cazurilor de utilizare


Referinţe
• UML Reference Manual, ed.a II-a, Cap. 6
• UML 2.0:
– http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
– http://www.agilemodeling.com/style/useCaseDiagram.htm
Se folosesc în activităţi diferite şi în scopuri/nivele de detaliere diferite
• modelul iniţial al organizaţiei
– în activitatea de analiză a cerinţelor
• modelul dinamic iniţial
– în activitatea de analiză

Definiţii
• vederea cazurilor de utilizare
– modelează funcţionalitatea unui sistem aşa cum este ea percepută de agenţi
externi, numiţi actori, care interacţionează cu sistemul dintr-un punct de
vedere particular
• caz de utilizare
– unitate de funcţionalitate exprimată ca tranzacţie (interacţiune) dintre actori şi
sistem
– mulţimea cazurilor de utilizare formează funcţionalitatea sistemului
• diagrama cazurilor de utilizare
– diagramă ce ilustrează relaţiile dintre actorii şi cazurile de utilizare dintr-un
sistem
• fiecare caz de utilizare descrie secvenţa de interacţiuni dintre actori şi
sistem

7
Actor
• definiţie:
– set de roluri pe care utilizatorii cazurilor de utilizare le joacă atunci când
interacţionează cu sistemul
– rol: comportament specific al unei entităţi care participă la un context
particular
– context - mulţime de elemente înrudite pentru un scop bine determinat, ca de
exemplu specificarea unei operaţii
• alte nume: entitate externă (sistemului)
• reprezentanţi
– utilizator al sistemului
– alt sistem
• exemple
– Client, Funcţionar, Student, Cititor
– Aplicaţia de salarii, Baza de date Studenti

Caz de utilizare
• definiţii:
– scenariu: secvenţă de acţiuni care ilustrează comportamentul, folosită pentru
ilustrarea execuţiei unei instanţe de caz de utilizare
– instanţă de caz de utilizare: execuţia secvenţei de acţiuni specificată în cazul
de utilizare
• exemple
– împrumut carte, prelucrare înscriere, stabilire
• capturează un aspect funcţional al sistemului, perceput de utilizator
– granularitatea funcţionalităţii depinde de nivelul de detaliere al modelului
– prin fiecare caz de utilizare se obţine o singură funcţie (a sistemului), dorită de
utilizator
• se exprimă prin
– diagrame de cazuri de utilizare: actori, interacţiuni, relaţii
– descrieri de scenarii: secvenţa de acţiuni

Componente
• cazuri de utilizare
• actori
• relaţii
• graniţa sistemului (opţional)
Exemplu: POST (Point Of Sale Terminal)
• sistem de gestiune a vânzărilor, stocurilor, încasărilor într-un magazin
• include
– staţii de lucru (case de marcat)
• cititoare de coduri de bare
– terminale pt magazie şi administraţie
• imprimante pt coduri de bare
– reţea de comunicaţie
– sistemul soft

8
POST: modelul iniţial al organizaţiei (activităţii)
actori
Client
Casier
evenimente
Client
cumpără mărfuri
returnează mărfuri cumpărate
Casier
intră în sistem (parolă)
înregistrează vânzările şi
încasează c/v mărfurilor
cazuri de utilizare
Cumpărare marfă
Returnare marfă
Intrare în sistem

diagrama cazurilor de utilizare


caseta sistemului
System boundary box
interior
funcţionalitate proprie
sistemului
numele sistemului
cazuri de utilizare
exterior
funcţionalitate neacoperită
de sistem
actori

Crearea cazurilor de utilizare


• paşi:
– capturarea dezideratelor utilizatorilor (ce doresc aceştia să facă sistemul)
– capturarea interacţiunilor utilizatorilor cu sistemul (cum folosesc ei sistemul
pentru a-şi atinge dezideratele)
– identificarea secvenţelor de interacţiuni
– scrierea scenariilor
• metode de creare
– metoda bazată pe actori
• identifică actorii care interacţionează cu sistemul
• pentru fiecare actor, identifică prelucrările care le iniţiază sau la care
participă
9
– metoda bazată pe evenimente
• identifică evenimentele externe la care sistemul trebuie să răspundă
• leagă evenimentele de actori şi cazuri de utilizare

Relaţii
• asociere:
– actor - caz de utilizare
– caz de utilizare - caz de utilizare
• include: relaţie de utilizare (CU de bază <<include>> CU inclus)
– CU de bază foloseşte CU inclus (CU inclus este o parte din
funcţionalitatea CU de bază)
– CU de bază ştie despre CU inclus
– CU inclus se instanţiază separat
• extend: relaţie de dependenţă (CU extensie <<extend>> CU de bază)
– CU extensie adaugă comportament incremental la CU de bază
– CU de bază nu are cunoştinţă de CU extensie
– CU estensie nu se instanţiază separat, ci doar ca extensie a CU
de bază
• generalizare
– CU părinte - CU fiu
• CU fiu moşteneşte de la CU părinte şi adaugă funcţionalitate nouă
– actor părinte - actor fiu
• actor fiu moşteneşte de la actor părinte şi are
comportament/caracteristici suplimentar(e)

4.2.1. Diagrama cazurilor de utilizare: relaţii (din UML Ref Man 2.0)

10
4.2.1. Diagrama cazurilor de utilizare: relaţii de generalizare

4.2.1. Diagrama cazurilor de utilizare: sfaturi


Cazurile de utilizare
numele începe cu un verb
numele conţine cuvinte din
vocabularul domeniului problemei
cazurile de utilizare primare se pun
în colţul de stânga sus al diagramei
dependenţele temporale se
marchează prin aliniere pe verticală
la fiecare caz de utilizare trebuie să
existe cel puţin un actor

Actorii
• numele: substantiv sugestiv, la singular, cuvânt din domeniul problemei
• fiecare actor trebuie să aibă asociat cel puţin un caz de utilizare
• actorii semnifică roluri, nu funcţii
• actorii principali se pun în colţul de stânga sus
• actorii sistem se marchează cu stereotipul <<system>>
• între actori nu există decât relaţii de generalizare

Relaţiile
• dacă (interacţiunea cu) actorul apare în cazul de utilizare, se pune o relaţie între actor
şi caz
11
• de obicei relaţiile actor - caz de utilizare sunt bidirecţionale
• relaţia <<include>> este direcţionată de la CU de bază la CU inclus
• relaţia <<extend>> este direcţionată de la CU extensie la CU de bază
• relaţia de generalizare este direcţionată de la
– CU fiu la CU părinte
– actorul fiu la actorul părinte

Prezentarea textuală a cazurilor de utilizare


• succintă: modelul iniţial
– actorii
• cine participă
• cine iniţiază
– tipul cazului
• primar: funcţionalitate obligatorie
• secundar: funcţionalitate importantă, nu neapărat obligatorie
• opţional: de dorit
– descrierea
• descrierea textuală a principalelor acţiuni
• detaliată: modelul de analiză
– prezentare separată a acţiunii actorilor - reacţiei sistemului
– prezentare structurată (paşi numerotaţi)
– scenariu principal, scenarii de excepţie

Exemplu de prezentare succintă: POST Cumpărare marfă


• actorii
– Client (iniţiator)
– Casier
• tipul cazului: primar
• descrierea
Clientul ajunge la casa de marcat cu coşul de cumpărături. Casierul înregistrează fiecare
marfă din coş şi apoi încasează contravaloarea lor de la client. După ce primeşte bonul de casă
şi (eventual) restul, clientul părăseşte magazinul cu mărfurile cumpărate.

4.2.1. Diagrama cazurilor de utilizare


Exemplu de prezentare detaliată: POST Cumpărare marfă

12
4.2.1. Diagrama cazurilor de utilizare
Exemplu de prezentare detaliată: POST Cumpărare marfă
Cazul de utilizare Cumpărare marfă
Scenariul tipic (uzual)
Acţiunea actorilor Răspunsul sistemului
1. Cazul de utilizare începe când clientul se prezintă la casa de 2. Incepe o nouă tranzacţie.
marcat cu mărfuri în coş.
3. Casierul înregistrează codul şi cantitatea din fiecare marfă 4. Afişează denumirea, preţul unitar al mărfii şi cota TVA.
(dacă există mai multe exemplare). Calculează valoarea mărfii, valoarea TVA şi le adună la
subtotalurile tranzacţiei curente.
5. Semnalează sistemului când a terminat de înregistrat mărfurile 6. Calculează şi afişează totalul de plată şi totalul TVA.
din coş.
7. Casierul comunică Clientului suma de plată.
8. Clientul comunică Casierului metoda de plată:
(a) Dacă plăteşte în numerar, iniţiază Plăteşte în numerar.
(b) Dacă plăteşte cu card-ul de credit, iniţiază Plăteşte cu card.
(c) Dacă plăteşte cu cec, iniţiază Plăteşte cu cec.
9. Înregistrează tranzacţia şi actualizează stocurile.
10. Tipăreşte bonul de casă.
11. Casierul înmânează Clientului bonul de casă.
12. Clientul părăseşte casa de marcat cu mărfurile în coş.
Scenarii alternative (de excepţie)
3. Casierul introduce un cod de marfă incorect. 4. Afişează un mesaj de eroare
8. Clientul nu poate plăti suma cerută 9. Anulează tranzacţia curentă

4.2.1. Diagrama cazurilor de utilizare


Exemplu de prezentare detaliată: POST Plăteşte în numerar
Cazul de utilizare Plăteşte în nume rar
Scenariul tipic (uzual)
Acţiunea actorilor Răspunsul sistemului
1. Clientul înmînează Casierului o sumă, posibil
mai mare decât totalul de plată.
2. Casierul introduce suma primită. 3. Calculează şi afişează restul de plată.
4. Casierul pune suma primită în sertarul casei şi
extrage restul de plată, pe care-l înmânează
clientului împreună cu bonul de casă.
Scenarii alternative (de excepţie)
2. Suma introdusă este mai mică decât totalul de 3. Afişează un mesaj de eroare
plată.
4. În sertar nu există bancnote/monede potrivite
pentru restul de plată. Casierul înştiinţează şeful
de tură.

13
4.2.2. Diagrama de activităţi
Vederea activităţilor
graf (reţea) de noduri şi fluxuri care ilustrează
fluxul de control şi date (opţional)
aferent paşilor unui proces
execuţia paşilor poate fi secvenţială sau concurentă
diagrama de activităţi se foloseşte pentru a explora
o operaţie complexă
o regulă de activitate complexă
un caz/mai multe cazuri de utilizare
un proces organizaţional
un proces soft
Se foloseşte în activităţi diferite şi în
scopuri/nivele de detaliere diferite
modelul iniţial al organizaţiei
în activitatea de analiză a cerinţelor
modelul dinamic iniţial
în activitatea de analiză
modelul de proiectare
detalierea proceselor

4.2.2. Diagrama de activităţi


Definiţii (UML 2.0)
Nod de control: tipuri
despărţire/reunire fork/join - bare de sincronizare
controlul se ramifică în thread-uri concurente
agregare: fiecare object are propriul
său thread (fir de execuţie)
controlul din thread-uri concurente se uneşte
ramificare/contopire branch/merge - romb
punct de decizie (decision point)
Guard
condiţie care trebuie să fie adevărată pentru ca
tranziţia să fie traversată
Culoar (swimlane)
grupează activităţile pe actori

14
4.2.2. Diagrama de activităţi: sfaturi
Sfaturi generale
obligatoriu nod iniţial şi nod final
(noduri finale)
nodul iniţial - în colţul de stânga sus
Nodurile de activitate se reprezintă ca
dreptunghiuri cu colţuri rotunjite
şi reprezintă:
apelul unei operaţii
un pas într-un proces organizaţional
un proces organizaţional
Reguli pentru nodurile de activitate
cel puţin o tranziţie de intrare şi una de ieşire
noduri activitate gaură neagră (black hole):
numai tranziţii de intrare
noduri de activitate miracol (miracle):
numai tranziţii de ieşire

4.2.2. Diagrama de activităţi: sfaturi


Puncte de decizie
se reprezintă sub forma unui romb
o singură tranziţie de intrare
cel puţin două tranziţii de ieşire
fiecare tranziţie de ieşire reprezintă o
situaţie separată
nu are etichetă
trebuie să refere nodul activitate precedent
sfaturi
evită punctele de decizie superflue
activităţile pot include puncte de decizie
implicite

15
4.2.2. Diagrama de activităţi: sfaturi
Guarzi: reguli
fiecare tranziţie de ieşire dintr-un punct
de decizie trebuie să aibă un guard
guarzii tranziţiilor de ieşire pentru un
punct de decizie/o activitate
nu trebuie să se suprapună
(condiţii reciproc exclusive)
trebuie să acopere toate situaţiile
când sunt mai mult de doi guarzi,
se foloseşte [altfel]
sunt opţionali
un guard se adaugă numai dacă

4.2.2. Diagrama de activităţi: sfaturi


Bare de sincronizare
tipuri
fork: tranziţia de intrare se ramifică în
mai multe tranziţii de ieşire
join: tranziţiile de intrare se unesc
într-o singură tranziţie de ieşire
activităţi paralele: tranziţii multiple
între un fork şi un join
reguli:
fork şi join sunt în perechi
orice fork trebuie să aibă join-ul
corespunzător
fork are o singură tranziţie de intrare
join are o singură tranziţie de ieşire
un fork se pune numai dacă
îmbunătăţeşte gradul de înţelegere
şi precizia exprimării

16
4.2.2. Diagrama de activităţi: sfaturi
Culoar (swimlane)
grupează activităţile executate de
acelaşi actor
procese liniare
nu mai mult de 5 culoare
orizontale
procese organizaţionale
obiecte acţiune - pe graniţa culoarelor
verticale
alte procese

4.2.2. Diagrama de activităţi: sfaturi


Culoare (swimlane)

17
4.2.2. Diagrama de activităţi: exemplu

4.3 Modelarea claselor cu UML


4.3.1. Diagrama de clase
Tipuri de clase
• clase entitate
– aparţin domeniului problemei (Model)
– aka model / business; instanţele lor se numesc entity objects, business objects
– funcţionalitate: reprezintă obiecte reale
• clase frontieră
– aparţin domeniului soluţiei; instanţele lor se numesc obiecte de interfaţă
– sunt folosite pentru construirea interfeţei cu utilizatorul (View)
– funcţionalitate: prezentarea datelor, prezentarea şi capturarea interacţiunii
• clase controler
– aparţin domeniului soluţiei; instanţele lor se numesc obiecte controler
– gestionează o prelucrare ( “unit of work”) de la început până la sfârşit
• crearea sau actualizarea obiectelor entitate;
• crearea obiectelor de interfaţă şi popularea interfeţei cu informaţie din
obiectele entitate;
• comunicarea complexă dintre colecţiile de obiecte;
• validarea datelor transmise între obiecte sau de la utilizator la aplicaţie.
Se foloseşte în activităţi diferite şi în scopuri/nivele de detaliere diferite
• modelul iniţial al organizaţiei
– în activitatea de analiză a cerinţelor
– clasele entitate, relaţiile dintre ele
• modelul static iniţial
– în activitatea de analiză
– clase, atribute, relaţii
• modelul de proiectare
– detalierea claselor
– clase entitate, clase frontieră, clase controler
– metode
• modelul de implementare
18
– cod sursă
Clasă
• definiţii
– UML 2.0: descriptor pentru o mulţime de obiecte care au aceleaşi atribute,
operaţii, metode, relaţii şi comportament
– implementare a unui TAD
– tip de date definit de utilizator
• elemente (UML 2.0)
– atribut: descrierea unui element cu nume de un tip specificat dintr-o clasă
– operaţie:specificarea unei transformări sau interogări executată de un obiect
– metodă: implementarea unei operaţii
– relaţie: legătură semantică între două sau mai multe clase
• clasă bine gândită
– reprezintă abstractizarea a ceva din domeniul problemei sau domeniul soluţiei
– număr mic de responsabilităţi, legate una de alta (coeziune)
– separare clară între abstractizare, specificare şi implementare
– uşor de înţeles, de extins şi adaptat
Obiect
• definiţii
– UML 2.0: entitate discretă cu frontieră şi identitate bine definite ce
încapsulează stare şi comportament
– instanţă (realizare) a unei clase
• stare: mulţimea valorilor atributelor
• comportament: specifică modul în care se modifică starea obiectului
– tranziţii de stare, transmitere de mesaje
– operaţiile clasei
• identitate
– proprietate a obiectului prin care el se deosebeşte de toate celelalte obiecte
– testarea identităţii; egalitatea obiectelor
• durată de viaţă
– creare: primeşte identitate, i se alocă resurse
– distrugere

Simboluri
• Clase
– nume
• italic: abstractă
– atribute
• subliniat: membru de clasă
– operaţii
• subliniat: membru de clasă

• Relaţii
asociere
asociere direcţională
generalizare
realizare
dependenţă
• Vizibilitate
- private
# protected
+ public
19
Relaţii
• asociere: o legătură între instanţele a două clase
– caracteristici
• unul dintre capete poate avea nume de rol (role name)
• unul din capete poate avea o săgeată
– indică direcţia în care se traversează relaţia asociativă
– indică cine deţine implementarea asocierii
• multiplicitatea: numărul de instanţe ce participă în relaţie
– tipuri speciale de asociere
• agregare:
• compunere
• generalizare: moştenire de la clasa părinte la clasa fiu
– clasa fiu este o specializare a clasei părinte
• realizare: legătura dintre o specificare (interfaţă) şi implementare (clasă)
• dependenţă: clasa client depinde de clasa furnizor
– dacă se modifică clasa furnizor, s-ar putea ca să fie afectată clasa client
– utilizare: pentru a funcţiona corect, clasa client are nevoie de clasa furnizor

4.3.1. Diagrama de clase


Exemplu: Prelucrare comenzi

Relaţia de asociere
• legătură structurală între instanţele a două clase
• elemente
– nume (opţional)
– direcţie (opţională)
• indică cine deţine
implementarea
asocierii
– capete: fiecare capăt are (opţional)
• numele rolului: câmp din clasa de la celălalt capăt
• tipul rolului: clasa de la capătul respectiv
• vizibilitate: + public, - private, # protected
• multiplicitate: câte instanţe ale clasei de la capătul respectiv sunt
asociate unei instanţe ale clasei de la celălalt capăt: 0, 1, *, m..n
– implicit 1

20
4.3.1. Diagrama de clase: multiplicitatea relaţiei de asociere

4.3.1. Diagrama de clase


Asocieri cu atribute
relaţiile de asociere au atribute
(proprietăţi) la fel ca şi clasele
atributele salariu şi funcţie
caracterizează relaţia dintre
instanţele claselor Persoană şi
Întreprindere
clasa asociere Post
Asocieri reflexive
între instanţele aceleiaşi clase
Asocieri direcţionate
indică cine deţine implementarea
asocierii

Relaţia de agregare
• relaţie întreg-parte)
– întregul: assembly, aggregate
– partea: part
• întregul şi partea există separat
– întregul nu controlează durata de viaţă a părţii
• când se folosesc
– părţile sunt elemente (părţi ale) agregatului (PART-OF)
– agregatul este compus din părţi (HAS)
– cine controlează sau deţine agregatul controlează sau deţine şi părţile acestuia
21
Relaţia de compunere
• când agregatul este creat/distrus, se creează/distrug părţile sale
• agregatul controlează durata de viaţă a părţilor

Relaţia de dependenţă
• definiţie: relaţie semantică între două clase, clasa furnizor şi clasa client
• tipuri de dependenţe între clase (UML 2.0)
– apel: o metodă a clasei client apelează o operaţie a clasei furnizor
– creare: clasa client creează instanţe ale clasei furnizor
– derivare: instanţa clasei client se poate crea din instanţa clasei furnizor
– instanţiere: o metodă a clasei client creează instanţe ale clasei furnizor
– permisiune: clasa client are permisiunea să folosească conţinutul clasei
furnizor
– transmitere: clasa client trimite un semnal clasei furnizor
– folosire: clasa client are nevoie de prezenţa clasei furnizor pentru a funcţiona
corect
• include apelul, crearea, instanţierea, transmiterea)
• stereotip: <<use>>
Relaţia de dependenţă: exemplu

Relaţia de generalizare
• definiţie: relaţie dintre clase, clasa părinte şi clasa fiu
– clasa părinte (superclasa) este o generalizare a clasei fiu (subclasa)
– clasa fiu este o specializare (ISA) a clasei părinte
• tipuri de moştenire
– simplă: o clasă fiu are o clasă părinte
• ierarhia de clase: arbore de moştenire
– multiplă: o clasă fiu are mai multe clase părinte
22
• ierarhia de clase: graf de moştenire
• polimorfism: instanţa clasei fiu se poate folosi
oriunde se cere o instanţă a clasei părinte
• operaţii
– concrete
– abstracte
• clase
– concrete
– abstracte
• interfeţe
– au numai operaţii abstracte
exemplu:

4.3.2. Diagrama de obiecte


Scop:
 explicarea relaţiilor
complicate, în
special a celor
recursive, într-o
diagramă de clase
Reprezentare
 fiecare dreptunghi
corespunde
unei singure instanţe
 numele instanţelor
sunt subliniate
Exemplu:
 diverse obiecte de tip
Compartiment cu
relaţiile de agregare dintre ele
23
4.4 Modelarea dinamică folosind UML
Tipuri de diagrame pentru modelarea dinamică
• diagrama de activităţi (detaliată)
• diagrame de interacţiune
– diagrama de secvenţe
– diagrama de comunicare (până la UML 1.5: diagrama de colaborări)
• diagrama de stări
Vederea interacţiunilor: descrie schimbul de mesaje între părţile unui sistem
• componente
– noduri: roluri (obiecte, participanţi)
– arce: mesaje - modalităţi de comunicare între roluri
• cine iniţiază comunicarea
• cine este destinatarul mesajului
• detaliază cazurile de utilizare
– cel puţin o diagramă de interacţiune per caz de utilizare
• diagrama de secvenţe: secvenţa de mesaje aranjată în ordine cronologică
– rolurile: obiecte, linii de viaţă (lifeline)
– mesajele: linii cu săgeţi, de la rolul ce iniţiază comunicarea la rolul destinatar
• diagrama de comunicare (colaborări): cu ce roluri comunică (colaborează) un rol
– rolurile: obiecte
– mesajele: linii cu săgeţi, de la rolul ce iniţiază comunicarea la rolul destinatar
• numerotare

4.4.1. Diagrame de interacţiune


Diagrama de secvenţe
Definiţii (UML 2.0)
• linie de viaţă (lifeline)
– rol într-o interacţiune care reprezintă un participant într-un interval de timp
determinat
– linie punctată dispusă pe verticală
– la capătul de sus are numele şi tipul (obiect)
– la capătul de jos poate avea bară de activare
• bară de activare
– porţiunea din linia de viaţă în care obiectul este activ
– linie dublă continuă
• mesaj
– transmitere de informaţie (cerere) de la un rol la altul, într-un context la altul
• comunicare de la un obiect (expeditor, sender - apelant, caller) la altul
(destinatar, receiver)
– tipuri
• semnal: asincron (sender; receiver)
• apel de operaţie: sincron (sender, caller; receiver)
– nume, parametri
– particularităţi
• repetiţie *
• condiţie [cond]
• apel recursiv
• return

24
4.4.1. Diagrame de interacţiune: exemplu de diagramă de secvenţe

Diagrame de interacţiune: exemplu de diagramă de secvenţe

25
Diagrame de interacţiune: cazul de utilizare CumpărareMarfă

Diagrame de interacţiune: reguli


• ordinea obiectelor (de la stânga la dreapta)
– actor
– obiect de interfaţă
– obiect specific aplicaţiei
– obiect entitate
– bază de date
• tipuri de mesaje
– apel (call)
– semnal (send)
– return
• stereotipuri
– creare <<new>>, <<create>>
– distrugere <<destroy>>, X

Diagrama de comunicare (până la UML 1.5: diagrama de colaborări)


• ilustrează interacţiunile organizate în jurul
– părţilor unei structuri compuse
– rolurilor unei colaborări
• deosebiri faţă de diagrama de secvenţe
– ilustrează explicit relaţiile dintre elemente
– este monodimensională: timpul nu apare ca dimensiune separată
– ordinea mesajelor se ilustrează prin numere

26
Diagrame de interacţiune
Diagrama de comunicare: exemplu

Diagrama de comunicare: exemplu pentru scaneazăMarfă

4.4.2. Diagrama de stări


Vederea stărilor:
• Descrie comportamentul dinamic al obiectelor prin modelarea ciclului de viaţă al
obiectelor unei clase
– fiecare obiect este tratat ca entitate izolată care comunică cu restul lumii prin
detectarea evenimentelor şi răspunzând la ele
• Definiţii (UML 2.0)
– eveniment: un gen de schimbare pe care obiectul îl poate detecta
– tipuri de evenimente
• call: recepţionarea unui apel sincron explicit de la alte obiecte op(a:T)
• signal: recepţionarea unui semnal explicit şi asincron de la alte obiecte
sName (a:T)
• change: modificarea valorii unei expresii booleene when(exp)
• time: trecerea timpului after(timp)
– stare: mulţime de seturi de valori de atribute (ale obiectelor unei clase) care
produc acelaşi răspuns calitativ la evenimentele ce apar
• toate obiectele aflate într-o stare răspund în acelaşi mod la evenimente
– tranziţie: leagă două stări s1 şi s2
• răspunsul obiectului aflat în starea sursă s1 la apariţia unui eveniment
• componente:

27
– declanşator de evenimente
– condiţie de gardă
– efect
– starea ţintă s2
– tipuri de tranziţii
• de intrare (entry) entry/activity
– specificarea unei activităţi care se execută când obiectul intră în
starea respectivă
• de ieşire (exit) exit/activity
– specificarea unei activităţi care se execută când obiectul iese din
starea respectivă
• externă (external) e(a:T)[guard]/activity
– răspunsul la un eveniment care provoacă o tranziţie de stare
împreună cu un efect
– poate provoca execuţia de activităţi de intrare sau de ieşire
aferente stărilor sursă sau ţintă
• internă (internal) e(a:T)[guard]/activity
– răspunsul la un eveniment care provoacă un efect fără a provoca
o tranziţie de stare
– maşină cu stări (state machine): descrie stările unui obiect şi tranziţiile de stare
• graf în care nodurile sunt stări şi arcele sunt tranziţii de stare
• ataşată unei clase
• pentru fiecare stare, maşina cu stări specifică consecinţele recepţionării
unui anumit eveniment prin
– acţiune (efect)
– schimbare (tranziţie la o altă stare)
– diagramă de stări: conţine o maşină cu stări
• descrie comportamentul unui singur obiect
• se foloseşte când obiectul este complex
• stări speciale
– stare iniţială
– stare finală
– super-stare: toate stările din ea au o aceeaşi tranziţiile la o altă
stare
Diagrama de stări: exemplu: obiectul CursOpţional

28
Diagrama de stări: exemplu: obiectul CursOpţional
Detalierea stării Înscriere contracte (Composite)

Diagrama de stări: exemplu: obiectul CursOpţional


Diagrama completă

4.5 Modelarea arhitecturii cu UML

4.5.1. Diagrama de pachete


Vederea manegementului modelului
• elementele de model se pot grupa (logic) în pachete
• pachet: mecanism pentru organizarea elementelor în grupuri
– stabileşte cine este proprietarul elementelor
– oferă nume unice pentru referirea elementelor: spaţiu de nume
• dependenţe între pachete
– dependenţă de folosire
– import de elemente din alte pachete
– vizibilitatea elementelor din pachet
• private
• public
• protected
• package

29
Diagrama de pachete

4.5.2. Diagrama de distribuire


 ilustrează relaţiile fizice dintre hard şi soft în sistem
 conţine
 noduri: de regulă componente hard ale sistemului
 resursă de calcul (server, maşină client, alt dispozitiv)
 artefacte: componente soft, fişiere
 conţinute în noduri
 expun interfeţe
 conexiuni: de regulă căi de comunicare dintre noduri, împreună cu metoda
(protocolul) folosit(ă)

Diagrama de distribuire

30
4.5.3. Diagrama de componente
Definiţii
• componentă: parte modulară a unui proiect de sistem care ascunde implementarea în
spatele unor interfeţe externe
– componentele ce implementează aceleaşi interfeţe se pot înlocui una cu alta
• interfaţă: declaraţia unei mulţimi de caracteristici şi obligaţii publice
– contract între furnizorii şi consumatorii unui serviciu
• interfeţe de intrare (required interfaces)
– interfeţe pe care le cere de la alte componente
– are nevoie de ele pentru a funcţiona corect
• interfeţe de ieşire (provided interfaces)
– interfeţe pe care le implementează componenta
• porturi: unde intră/ies mesaje
– de intrare
– de ieşire
• componente compuse: conţin alte componente
Se folosesc la proiectare

31