Diagrame pentru managementul modelului (Model Management

diagrams)

Diagramele de management al modelului se folosesc pentru organizarea produselor

rezultate in procesul de dezvoltare al unui sistem software. Acestea sunt:

Diagrama de pachete

Diagrama de subsisteme

Diagrama Model

Pachete (Package)

Pachetul este principala constructie UML pentru gruparea elementelor de modelare.

Are exact aceeasi functionalitate ca si un director pe disc (folder). Permite
organizarea elementelor grupandu-le si amplasandu-le intr-un container. Un pachet
poate contine alte pachete, deci se poate crea o ierarhie de pachete.
Un pachet are asociat un spatiu de nume (namespace). Elementele amplasate in
acelasi pachet trebuie sa aiba nume unice, dar elemente amplasate in pachete
diferite pot avea acelasi nume.

Un pachet este reprezentat printr-un simbol de folder. Numele pachetului

poate fi amplasat in centrul simbolului sau in coltul stanga sus, ca in figura
urmatoare:

Reprezentarea pachetelor

Copyright Prof.univ. dr. ing. Florica Moldoveanu 1

 Un pachet poate avea un stereotip, caz in care este amplasat deasupra
numelui pachetului. Un pachet poate fi abstrat, caz in care este adnotat cu
constrangerea {abstract}.

Un pachet este o grupare logica de elemente de modelare. De exemplu,

poate grupa elemente care participa la furnizarea unui serviciu. Gruparea
poate avea drept scop controlul vizibilitatii elementelor din grup, specificarea
si documentarea.

Un pachet poate contine: clase, interfete, componente, noduri, colaborari,

cazuri de utilizare, diagrame, alte pachete.

De regula, un pachet este redat grafic doar prin numele sau dar reprezentarea poate

include si continutul pachetului.

Atunci cand se lucreaza cu un instrument de modelare UML, acesta
reprezinta gruparea elementelor de modelare in pachete printr-un arbore
similar cu cel afisat de Windows Explorer.

Elementele publice ale unui pachet constituie interfata pachetului.

Elementele protejate sunt vizibile din pachetele care mostenesc de la
pachetul respectiv. Generalizarea intre pachete este la fel ca intre clase.

Interfata unui pachet este accesibila numai din pachetele care declara explicit
accesul.

Relatia de acces este o relatie de dependenta intre pachete: elementele din

pachetul sursa pot accesa legal elementele din pachetul tinta (catre care este

Copyright Prof.univ. dr. ing. Florica Moldoveanu 2

 orientata sageata). Unele instrumente de modelare deseneaza automat
relatia de Acces intre pachete dupa ce s-au stabilit relatiile intre elementele de
modelare incluse in pachete. Relatia de acces este modelata prin stereotipul
<<access>>.

UML 1.x permite specificarea relatiei de import intre pachete: prin import se
poate obtine o copie a unui element din alt pachet. Copia apartine pachetului
care a importat-o dar varianta sa originala exista in pachetul de origine.

SISTEME si MODELE

Copyright Prof.univ. dr. ing. Florica Moldoveanu 3

Un sistem este o grupare de elemente organizate pentru realizarea unui scop.
Sistemele pot fi descompuse in subsisteme separate, fiecare subsistem putand fi
vazut la randul sau ca un sistem, la un nivel de detaliu mai coborat. Subsistemele
sunt grupari de elemente care pot fi modelate si dezvoltate relativ independent.
Descompunerea are loc in etapa de proiectare arhitecturala, cand se decide cum vor
fi realizate cerintele. Relatiile sistem-subsisteme pot fi reprezentate printr-o diagrama
de pachete.
Principala relatie intre un sistem si un subsistem este aceea de agregare.
Intre sisteme si subsisteme pot fi definite si relatii de generalizare.

In UML 1.x, un subsistem este un tip particular de pachet. Se reprezinta ca un

pachet cu stereotipul <<subsistem>>. In UML 2, un subsistem este un
tip particular de componenta si pentru reprezentarea sa se foloseste
simbolul de componenta cu stereotipul <<subsistem>>.

Modelul unui sistem este o simplificare a realitatii, o abstractie a sistemului,

creata pentru a intelege mai bine sistemul si a-l specifica.

O vedere este o proiectie a unui model dintr-un punct de vedere in care sunt omise
aspectele nerelevante din punctul de vedere respectiv.
Cele 5 vederi ale unei arhitecturi software sunt:

1. Use Case View

Copyright Prof.univ. dr. ing. Florica Moldoveanu 4

 Cuprinde cazurile de utilizare care descriu comportarea sistemului vazuta de
utilizatori, analisti si testori. se folosesc diagrame de cazuri de utilizare,
diagrame de interactiune, de stari si de activitati.

2. Design View
Cuprinde:
clasele, interfetele, colaborarile, pentru modelarea aspectelor statice
diagrame de interactiune, de stari si activitati, pentru modelarea
aspectelor dinamice

3. Process View
Descrie procesele si firele de executie care formeaza mecanismele de
concurenta si de sincronizare ale sistemului. Cuprinde aceleasi tipuri de
diagrame dar cu accent pe clasele si obiectele care reprezinta fire si procese
de executie.

4. Implementation View descrie componentele care alcatuiesc sistemul fizic

final. Se folosesc:
diagrame de componente pentru a modela aspectele statice
diagrame de interactiune, de stari si activitati pentru modelarea
aspectelor dinamice.

5. Deployment View cuprinde nodurile care formeaza topologia hardware a

sistemului. Se folosesc:
diagrame de distributie, pentru mdelarea aspectelor statice
diagrame de interactiune, de stari si de activitate, pentru modelarea
aspectelor dinamice

Copyright Prof.univ. dr. ing. Florica Moldoveanu 5

 Cele 5 vederi ale unei arhitecturi software

Elementele de modelare care constituie o vedere asupra unui sistem pot fi

grupate intr-un model. Acesta este un pachet cu stereotipul <<model>> sau
unul care include simbolul triunghi in coltul dreapta sus:

Copyright Prof.univ. dr. ing. Florica Moldoveanu 6