Ministerul Educației, Culturii și Cercetării

Universitatea Tehnică a Moldovei

Facultatea Calculatoare, Informatică și Microelectronică
Departamentul Ingineria Software și Automatică

Raport
Lucrarea de laborator nr. 4

Analiza și Modelarea Orientată pe Obiecte.

Tema: Analiza rezultatelor modelări din diagramele cazurilor de utilizare și

dezvoltarea în diagramele de colaborare.

A îndeplinit: st.gr. TI-195 Rotaru Dan

A verificat: lector universitar Duca Ludmila

Chișinău 2021
Scopul lucrării: studierea noțiunii de obiect, colaborare legături între aceste entități

Sarcina lucrării: de realizat 4 diagrame de colaborare ( 2 diagrame nivelul de exemple și 2

diagrame nivelul de specificare) pentru sistemul informațional ales.

Considerații teoretice
Un obiect în UML reprezintă o entitate care are atât atribute, cât şi un comportament, dat
de metodele aferente acestuia. Astfel, obiectele în UML:

 Sunt entităţi care au atît atribute cît şi o comportare: de exemplu, un tip de date abstract împreun ă cu
operaţiile definite pentru acesta;
 Comunicarea inter-obiecte trebuie văzută ca o transmitere de mesaje între dou ă obiecte;
 Sunt instanța unor clase;

Diagrama de colaborare și diagrama de strucură sunt numite și digrame de

interacțiune. Diagrama de Secvență accentuează factorul timp, arătînd cum au loc interacțiunile
în timp ce Diagrama de Colaborare accentuează contextul și organizarea de ansamblu a
obiectelor care interactionează. De asemenea, Diagrama de Secvență este aranjată în funcție de
factorul timp, iar Diagrama de Colaborare în funcție spațiu.

O diagramă de colaborare la nivelul instanțelor este un graf, avînd ca noduri obiectele

participante la colaborare și ca arce legăturile dintre ele, însoțite de stimulii transmiși prin
intermediul acestora. Obiectele sunt reprezentate la fel ca în diagramele de obiecte, prin
dreptunghiuri ce conțin numele obiectului subliniat, dar fără a ilustra valorile atributelor. Se
poate prezenta și rolul obiectului în colaborare, folosind următoarea notație generală:
NumeObiect'/'NumeRolClasificator':'NumeClasificator['.'NumeClasificator]*

Figura.1 Elemente ale diagramelor de colaborare la nivelul instanțelor

Legăturile apar ca linii, avînd la capete, opțional, numele rolului de asociație corespunzător;
pot apărea și auto-legături, marcate prin stereotipul << self >>. Stimulii se reprezintă prin săgeți
mici, atașate legăturilor și indicînd navigabilitatea diagramei.
 Figura 2 – Log in (nivel de exemplu)

În Figura 2 este reprezentată diagrama de colaborare nivel de exemplu, pentru procesul de logare.
Actorul (sau utilizatorul) introduce login-ul și parola (1), apoi apasă butonul Login (1.1). După
aceasta datele introduse (login-ul și parola) se verfică în baza de date (1.2), dacă totul este fain
atunci chemăm ok (1.3) după ce redirecționăm către aplicație (1.4). Dacă utilizatorul va apăsa
ResetPassword (2) el va trebui să introducă email-ul (2.1) după ce email-ul introdus se va verifica la
veridicitate (2.2) după se va verifica dacă în baza de date există așa email (2.3), dacă există
întoarcem că email-ul este valid (2.4) și trimitem un mesaj pe email-ul respectiv cu link-ul la
resetare (2.5). Utilizatorul accesează acest link (2.6) și introduce parola nouă (2.7). După ce a
introdus parola nouă (2.8) aceasta se salvează (2.9) și chemăm funcția password changed (3) ulterior
redirecționând utilizatorul către aplicație (3.1)
 Fig. 2.1 – Pașii nivelului de exemplu (log in)

Figura 3 – Register (nivel de exemplu)

În Figura 3 este reprezentată diagrama de colaborare nivel de exemplu, pentru procesul de

înregistrare. Actorul (sau utilizatorul) introduce username (1), apoi login-ul introdus se verifică la
cerințele necesare (1.1), după se verifică dacă este login-ul dat este disponibil (1.2), dacă este
disponibil întoarcem funcția username available (1.3). După aceasta utilizatorul introduce email-ul și
parola (1.4) ulterior apăsând butonul Register (1.5). Pașii următori vor fi de verificare a datelor
introduse: verificăm dacă email-ul corespunde cerințelor de email (1.6), dacă da întoarcem valid
email (1.7) și ulterior verificăm dacă email-ul dat este disponibil (1.8), dacă da întoarcem email
available (1.9). Acum vom verifica parola, dacă aceasta corespunde cerințelor (2) atunci întoarcem
valid password (2.1) apoi salvăm toate datele în baza de date (2.2) ulterior întoarcem Register (2.3)
și redirecționâm utilizatorul către aplicație (2.4)
 Fig. 3.1 – Pașii nivelului de exemplu (register)

Figura 4 – Access level (nivel de specificare)

În Figura 4 este reprezentat diagrama Access level care reprezintă nivelul de acces a aplicației. Prin
această diagramă este modelat nivelul de specificare integrat în aplicație , care va delimita în două
categorii accesul utilizatorilor la diverse categori ale sistemului. Va conține o categorie pentru
utilizatorii care sunt înregistrați (care au access direct către funcționalitatea aplicației) și o altă
categorie pentru utilizatorii neînregistrați (oaspeți) care vor putea vedea o landing page (o pagină
unde vor putea vedea descrierea aplicației, descrierea funcționalului, design-ului ci nu și access
direct la aplicație).

Figura 5 – Data storage (nivel de specificare)

În Figura 5 am reprezentat nivelul se specificare a procesului de stocarea datelor. Mai apoi toate
datele acumulate vor fi stocate pe storage cloud Swift așa cum se arătat în diagramă.

Concluzie
Ca concluzie pot spune că în lucrarea dată am analizat, studiat și implimentat diagramele de
colaborare , nivel de specificare și nivel de exemple. Am ajuns la idea că diagrama
de colaborare nu reprezintă doar consicutivitatea interacțiunilor, dar și relații de structură dintre
obiecte. Spre deosebire de nivelul de exemple unde sunt reprezentate obiectele și legăturile din
cadrul colaborării, nivelul de specificare reprezintă rolurile entităților și rolul asocierilor în cadrul
colaborării dintre obiecte.