Ministerul Educaţiei, Culturii şi Cercetării al Republicii

Moldova Universitatea Liberă Internaţională din Moldova

Facultatea Informatică, Inginerie şi Design

Disciplina: Limbaje de Modelare

Lucrare de laborator Nr.5

Tema: Diagrame

A efectuat

Student gr. TIR-46

Pîrlog Andrei
A verificat
Bunici Sergiu

Chişinău 2020
 1.Diagrama de comunicare / colaborare
Diagrama de comunicare (anterior UML 1.5 a fost numita diagrama de colaborare)
este o diagrama de interactiune in care accentul cade pe organizarea structurala a obiectelor
care schimba mesaje intre ele.

2.1. Continutul diagramei de comunicare

Diagrama de comunicare au un nume si un continut grafic, similar diagramei de
secventa.
Continutul grafic:
- obiecte,
- legaturile dintre obiecte (asocieri, generalizari, etc.)
, - mesaje, optional,
poate contine:
- note
- constrangeri
a. Obiectele se reprezinta sub forma de dreptunghiuri plasate in orice loc pe
diagrama. La fel ca in diagrama de secventa, pot fi obiecte sau instante anonime ale unor
clase.
b. Mesaj.
Notatia UML pt mesaj este o sageata care are asociat numele operatiei invocate.
Deoarece diagrama este monodimensionala (timpul nu apare explicit ca o
dimensiune separata) ordinea mesajelor se ilustreaza prin numere.
Mesajele pot fi stereotipizate. Exemple: <<create>>, <<destroy>>.
Mesajele, de obicei, sunt apeluri ale unor operatii ale unui obiect, inclusiv apelarea
unei metode proprii.

Comparatie intre diagrama de secventa si diagrama de comunicare:

- Linia vietii (lifeline) exista doar in diagrama de secventa;
- Legaturile dintre obiecte se reprezinta doar in diagrama de comunicare;
- Numerotarea mesajelor este obligatorie in diagrama de comunicare

Diagramele de comunicare permit o mai buna vizualizare a iteratiilor si a

ramificatiilor complexe, precum si a fluxurilor de control concurente, multiple
pe cand diagramale de secventa permit vizualizarea
iteratiilor si a ramificatiilor simple

Curgerea timpului nu este reprezentata explicit in diagrama de comunicare, dar faptul

ca mesajele sunt numerotate e un indiciu suficient pentru a putea converti reciproc cele doua
tipuri de diagrame.

2.2. Etapele crearii diagramelor de colaborare:

- stabilirea contextului interactiunii (sistem ,subsistem, clasa, operatie,
scenariu al unui caz de utilizare, colaborare);
- identificarea obiectelor care participa la interactiune. Acestea se aseaza in
orice loc din diagrama asemenea unor noduri intr-un graf; este indicat ca
obiectele mai importante sa fie plasate in centrul diagramei
 - stabilirea proprietatilor initiale ale obiectelor; rareori, daca starea sau rolul
unui obiect se schimba semnificativ pe timpul interactiunii, se va plasa o
copie a obiectului pe diagrama, cu noile valori, si se conecteaza cu
obiectul initial prin mesaje stereotipizate cu <,become>> sau <<copy>>.
- se reprezinta legaturile dintre obiecte (de fapt se deseneaza diagrama de
obiecte pentru un scenariu dat):
- mai intai asocierile (care sunt de fapt conexiuni structurale)
- apoi celelalte relatii (dependente, generalizari);
- se incepe cu mesajul care initiaza interactiunea si se continua in ordinea
cronologica cu celelalte mesaje, numerotandu-le;
- mesajele se reprezinta sub forma de sageata pe (sau sub) conexiunea
care leaga obiectul emitator si obiectul receptor;
- se pot adauga constrangeri, iar mesajelor li se pot atasa pre si
postconditii.
Se poate observa ca parcurgem aproape aceleasi etape ca in cazul diagramei de
secventa.

Inginerie directa. In cazul ambelor tipuri de diagrame de interactiune este posibila

generarea codului pornind de la model, mai ales atunci cand contextul diagramei este o
operatie. Calitatea codului generat, evident, depinde atat de softul (tool-ul) folosit, cat si de
cantitatea si acuratetea informatiei continuta de model.

Inginerie inversa este deasemenea posibila pentru ambele tipuri de diagrame de

interactiune.

Exemplu: Retragere bani de la un ATM.

 2.Diagramele de arhitectura
Evaluarea arhitecturii unui sistem soft presupune:

- Dimensionarea logica (operarea cu modele care se pot referi la clase, interfete,

colaborari, interactiuni, masini de stare).

- Dimensionarea fizica (operarea cu modele care se refera la componente, noduri

si pachete care grupeaza elemente arhitecturale).

Diagramele de arhitectura redau o vedere a arhitecturii unei aplicatii software la nivel

inalt, fara a intra in detalii de implementare.

Aici sunt definite pachetele (subsistemele), incluzand dependentele si mecanismele

primare de comunicatie intre pachete.

In general, se prefera o arhitectura clara si simpla, in care avem putine dependente

iar dependentele bidirectionale se evita pe cat e posibil.

Daca proiectam bine arhitectura unui sistem soft, asiguram extensibilitatea si

modificarea cu ususrinta a aplicatiei.

Ca exemple: diagrama de desfasurare (deployment) sau de noduri, diagrama de componenete,

diagrama de straturi sau diagrama de pachete.

Aceste diagrame se pot combina pentru a reda mai multe detalii.

2.1 Diagrama de pachete

Diagrama de pachete este o diagrama structurala (sau arhitecturala) care ilustreaza
pachetele si relatiile dintre acestea.

O diagrama de pachete poate reda arhitectura unei aplicatii software la nivelul cel
mai grosier.

Scop:

- Comunicarea semanticii solutiei (intre partenerii de proiect);

- Stapanirea complexitatii solutiei

in cazul sistemelor complexe in care e necesara manipularea unui mare

numar de elemente (zeci sau sute de clase, etc.).

Conceptele UML folosite in diagramale de pachete

Entitate:

 Pachetul (entitate cu functie de grupare)

Relatii:

 Generalizarea
  Dependenta (stereotipizata: <<import>>, <<acces>>, <<merge>>)

 Compozitie – un element apartine unui pachet – permite

descompunearea ierarhica a modelelor.

Pachetul (entitate UML cu functie de grupare) este un mecanism de interes general

pentru organizarea elementelor in grupuri.

Intr-un pachet pot fi grupate EFS, EFC si, inclusiv alte EFG (pachete):

- clase,

- interfete,

- componente,

- noduri,

- colaborari,

- cazuri de utilizare,

- diagrame)

- alte pachete.

In timp ce componenetele se manifesta in timpul executiei unui sistem soft, pachetele

se manifesta mai degraba la nivel conceptual.
Reprezentare

Numele pachetului p oate fi nume simplu sau nume cu cale (in cazul pachetelor
cuibarite unele in altele – nested) .

Pachetul, pentru elementele sale, este ceea ce in limbajele de programare este

spatiul de nume (namespace).
 Un element este unic in cadrul unui pachet.

Vizibilitatea elementelor unui pachet: +Public, -Private, #protected, ~Package.

- Pachetele imbricate vad toate elementele vizibile din pachetele de ordin superior.

- <<import>> - pentru a avea acces la clasele altui pachet trebuie sa il importi in

pachetul tau. Ex: using namesapce std.

- <<acces>> - accesarea unei clase din alt pachet poate fi facuta si prin calificarea
numelui clasei cu numele pachetului. Ex: std.cout<<”exemplu”.

- <<merge>> - pachetele sunt unite si isi vad continutul vizibil reciproc. F

asemanatoare cu relatia de generalizare.

Indicatie: pachetele ar trebui sa fie inalt coezive (sa grupeze elemente apropiate
semantic care se comporta similar la schimbari), iar cuplajul dintre pachete ar trebui sa fie
cat mai slab.

Observatie. In diagramele UML, pachetele sunt asemanatoare, in mare masura,

claselor.

Mecanismul pachetelor rezolva:

- clasificarea claselor: clasele cu relatii stranse (generalizari, asocieri, agregari) se

grupeaza in acelasi pachet, cele nelegate sau cu anumite relatii de dependenta,
in pachete diferite.

- Reglarea relatiilor de vizibilitate dintre clase

In aceasta diagrama pot fi utilizate pachete care reprezinta difertite layere pentru
ilustrarea arhitecturii unui sistem software.
 2.2 Diagrama de componente
Diagrama de componente este o diagrama arhitecturala care ilustreaza alcatuirea
fizica a unui sistem soft (componentele si relatiile dintre acestea).

Scop: - Organizarea proiectelor mari si complexe;

Conceptele UML folosite in diagramale de componente

Entitate:

 Componenta (entitate cu functie structurala)

Relatii:

 Dependenta;

 Realizarea – intre componente si interfete

Componenta (entitate UML) este o parte fizica, inlocuibila, a unui sistem soft (fisiere
EXE, fisiere sursa, DLL, COM, tabele BD, fisiere, documente, fisiere din kitul de instalare).

Componentele au o contributie la modelarea fizica a formei executabile a unui sistem

soft.

Reprezentare:
 Componente vs clase:

Asemanari:

o au nume,

o pot realiza interfete, o pot participa la relatii de asociere, generalizare si

dependenta; o pot fi instantiate (pot avea instante)

Deosebiri:

o clasele sunt abstractii logice (conceptuale); componentele sunt parti

fizice (se regasesc sub forma de biti rezidenti intr-un nod); o
componentele sunt impachetari fizice ale unor entitati logice (clase, etc);

o clasele au atribute si operatii, componentele au doar operatii (de obicei)

Componente vs interfete:

Interfetele (colectie de operatii expuse de o clasa sau de o componenta) sunt liantul

care tin legate intre ele mai multe elemente (clase sau componente).

- relatie de realizare - intre componenta care expune (exporta) o interfata si

interfata expusa (interfata sa);

- relatie de dependenta – intre o componenta care acceseaza (utilizeaza,

importa) serviciile unei interfete ale altei componente si interfata respectiva;

O componenta poate asigura (exporta) una sau mai multe interfete si poate importa
una sau mai multe interfete.

Componenete vs pachete:

In timp ce componenetele se manifesta in timpul executiei unui sistem soft, pachetele

se manifesta mai degraba la nivel conceptual.

Marele avantaj al componentelor (in dezvoltarea orientata pe componente) este ca

acestea pot fi inlocuite atata timp cat se pastreaza aceeasi interfata.
 Astfel un sistem software bine proiectat arhitectural, poate fi dezvolatat in mai multe
limbaje de programare si poate fi modificat pentru a rula pe mai multe sisteme de operare,
cu schimbari minore, deci cu costuri mici.

Tipuri de componente:

- componente desfasurare (implementare) – componente suficiente si necesare

pentru a alcatui un sistem executabil pe un claculator (exe, dll, drv, ocx, php, asp,
jsp, js, table BD, etc).

- componente – secundare – produse reziduale folosite in crearea, modificarea si

dezvoltarea sistemelor executabile (fisiere de cod sursa, fisiere de date).

- componente create in executie de catre sistemele soft.

Stereotipuri ce pot fi aplicate componentelor: <<executable>>, <<library>>, <<table>>,

<<file>>, <<document>>.

Frecvent, in diagramale de componente, se modeleaza componentele desfasurare!!!

Daca sistemul soft consta dintr-un singur fisier executabil, modelarea componentelor
este inutila.
 2.3 Diagrama de desfasurare (noduri)
Pentru a putea fi executate, componentele trebuie desfasurate pe dispozitive hard
adecvate executiei lor.

Diagrama de noduri (deployment) ilustreaza relatiile fizice dintre hard si soft in

cadrul unui sistem.

Conceptele UML folosite in diagramale de noduri

Entitate:

 Nodul (entitate cu functie structurala)

Relatii:

 Asocierea – conexiune fizica dintre noduri (conexiune net,

magistrala, etc)

 Dependenta – intre componentele incluse in noduri;

Nodul (entitate UML) este un element fizic (procesor, resursa de calcul sau un
dispozitiv fizic) pe care pot fi desfasurate componente.

Este identificat dupa nume (simplu sau cu cale).

Reprezentare:

Diagramele de noduri pot fi folosite pentru a reprezenta:

- Arhitectura sistemelor de calcul si a perifericelor (vazute ca interfete cu lumea

reala)

- Distribuirea (topologica) a componentelor unei aplicatii software in sistemul

(sistemele) fizic de calcul;

Alocarile componentelor se fac folosind relatia de dependenta Exemple:

Arhitectura sistem cumparare locuinta

Arhitectura Client - Server

Sursa: https://www.lucidchart.com/pages/uml-deployment-diagram

Sursa: http://diagram.premamaz.com/deployment-diagram-web-based-application/
2.4 Diagrama de straturi (layer diagram)
Exemple:

DTO

Sursa: http://www.dotnetcurry.com/visualstudio/848/layer-diagram-visual-studio-2012

Sursa: https://dzone.com/articles/the-vsta-layer-diagram-and-pp-
Sursa: https://dzone.com/articles/the-vsta-layer-diagram-and-pp-
Sursa: https://www.uml-diagrams.org/multi-layered-application-uml-model-diagram-example.html
Sursa: http://www.peej.co.uk/articles/3-tiered-rest-architecture.html