iss - seminar 4 · se poate observa ca parcurgem aproape aceleasi etape ca in cazul diagramei de...

Inginerie software – seminar 4 Ioan Sima

1

ISS - Seminar 4 11 aprilie 2018

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.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.


3

Exemplu: Retragere bani de la un ATM.


4

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


5

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 poate 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).


6

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.


7


8


9

Sursa: https://www.visual-paradigm.com/VPGallery/diagrams/Package.html

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

https://www.visual-paradigm.com/VPGallery/diagrams/Package.html


10

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.


11

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.


12

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).


13

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


14

Arhitectura Client - Server

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

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


15

Sursa: http://diagram.premamaz.com/deployment-diagram-web-based-application/

http://diagram.premamaz.com/deployment-diagram-web-based-application/


16

2.4 Diagrama de straturi (layer diagram)

Exemple:

DTO

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

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


17

Sursa: https://dzone.com/articles/the-vsta-layer-diagram-and-pp-

https://dzone.com/articles/the-vsta-layer-diagram-and-pp-


18

Sursa: https://dzone.com/articles/the-vsta-layer-diagram-and-pp-

https://dzone.com/articles/the-vsta-layer-diagram-and-pp-


19

Sursa:

https://www.uml-diagrams.org/multi-layered-application-uml-model-diagram-example.html

https://www.uml-diagrams.org/multi-layered-application-uml-model-diagram-example.html


20

Sursa: http://www.peej.co.uk/articles/3-tiered-rest-architecture.html

http://www.peej.co.uk/articles/3-tiered-rest-architecture.html

iss - seminar 4 · se poate observa ca parcurgem aproape aceleasi etape ca in cazul diagramei de...

Documents