Universitatea Tehnică a Moldovei

Facultatea Calculatoare, Informatică și Microelectronică

Departamentul ISA

Raport
la Lucrarea de laborator nr. 5
la disciplina Analiza si proiectarea orientata pe obiecte

Tema: DIAGRAME UML APLICATE

Diagrama de clase în modelarea orientata pe obiecte
folosind UML

Student: Victoria Popescu

Grupa: TI 173
Verificat de catre lect. Univ Radu Melnic
Sava Nina

Chisinau 2019
Sarcina lucrarii:
Studierea și modelarea modelului “Classe” pentru un sistem de aplicații cu ajutorul
Enterprise Arhitect.
Clase
⮚ O clasă de obiecte reprezintă un grup de obiecte care au:
o proprietăţi similare (atribute);
o un comportament comun (operaţii),;
o relaţii comune cu alte obiecte şi o aceeaşi semantică.

Regulile de vizibilitate se aplica atat atributelor cat si operațiilor din clase si se refera la
domeniul de acces permis la un membru al unei clase. Fiecare nivel de vizibilitate este
reprezentat printr-un simbol:

● Private ( - ) : accesibiltate numai din interiorul clasei

● Public (+) : accesibiltate la nivelul intregului sistem
● Protected (#) : accesibiltate in arborele de mostenire
● Package (~) : accesibiltate din interiorul pachetului care contine clasa
Dependenţa: Apare când o clasă foloseşte pentru scurt timp o altă clasă. Apare între două
elemente dintre care unul este unul independent şi altul dependent. Orice modificare a
elementului independent va fi reflectată şi asupra elementului dependent. Putem avea o relaţie
de dependenţă de exemplu în cazul în care o clasă foloseşte ca parametru un obiect al altei
clase, sau o clasă accesează un obiect global al altei clase, sau o operaţie a unei clase este
apelată într-o altă clasă.
Asocierea: legătură (conexiune) între două clase (relaţie şi între obiecte, instanţe ale celor
două clase) ce permite claselor respective să comunice între ele. Pot exista asocieri
unidirectionale sau bi-directionale (indică dacă fiecare clasă transmite mesaje celeilalte sau
doar una poate transmite mesaje).
Agregarea: Este o formă specială de asociere a claselor, utilizată în cazul în care relaţia
dintre cele două clase este de tipul parte din întreg.
Compozitia: Compunerea este un concept similar cu agregarea, însă mai puternic deoarece
implică faptul că întregul nu poate exista fără părţi.
Generalizarea: Relaţie între o clasă şi subclasele sale, este prezentă ori de câte ori se
semnalează de-a lungul unei ierarhii proprietăţi comune sau operaţii ce evidenţiază
comportament comun.
Folosirea diagramelor de clase:

1. In modelarea conceptuala (analiza oriectata obiect)

● Clasele corespund conceptelor / obiectelor (entitatilor) din domeniul aplicatiei
● Nu exista neaparat o legatura directa cu clasele de obiecte utilizate in
implementare si deci diagrama de clase nu face parte din modelul structu al
sistemului
● De regula, nu sunt definite operatiile din clase prin tipurile parametrilor ralsi
nici tipul atributelor.
● Diagrama de clase poate fi folosita in modelarea conceptuala a unei baze de
date. In modelul fizic al BD clasele se implementeaza prin tabele ale bazei de
date
2. Pentru specificarea software
● Se pune accent pe interfata si nu pe implementare
● Adesea se foloseste cuvantul “tip” in legatura cu interfata unei clase: un tip
poate fi implementat de mai multe clase si o clasa poate implementa mai multe
tipuri
3. In proiectarea de detaliu si implementare
● Diagramele contin clase de obiecte intr-un anumit limbaj de programare
● Diagramele fac parte din modelul structural al sistemului

Modelarea unui sistem de billing pentru o IPcompanie de telecomunicatii.

Descrierea sistemului:
Sistemul BIllingTelcom reprezinta o aplicație desktop care are un funcțional vast de
servicii. În interiorul aplicației userii pot monitoriza volumul de trafic, redirecționa traficul,
adaugă price listuri, genera oferte si invoice-uri.
Diagrama de clasa:
În prima diagrama de clasa se descrie modelarea conceptuala a “Routing Management”
(Figura 1).

1. Carrier ; 4. CodeScheme;
2. carrierDetails; 5. Destination;
3. Routing; 6. proxyRouting.

Fig. 1. Diagrama de clasa “Routing Management”

În prima diagrama de colaborare se descrie procesul de trimitere a notificărilor (Figura
2).

7. User; 10. Accounter;

 8. SendNotification; 11. SenAlertNotification;
9. db. 12. TrafficControl.

Fig. 2. Diagrama de clasa.

În Figura 3 este reprezentat funcționalul de bază aplicație dupa logarea utilizatorului și

accesarea “Generate Invoice”. Aici sunt descrise multitudinea te operații care pot fi executate
la acest compartiment:
1. Cerere;
1.1. Stabilirea conexiunii;
1.2. Generare facturi;
 Fig. 3. Diagrama de clasa la nivel de interfata - meniu.

În Figura 3 sunt reprezentate clasele de baza care comunica intre ele și realizează
componentele de interfață. Totodată sunt descrie relațiile de comunicare și specificare
rolurilor.
 Fig. 4. Diagrama de clasa.

În Figura 4 sunt reprezentate clasele de baza care funcționează pe servere separate si

care împreuna cu rolurile dintre ele realizează comunicarea dintre servere si realizarea
funcționalitate de baza.
 Concluzie

În urma efectuării lucrării de laborator, s-a analizat și modelat o aplicație de billing -

BillingTelcom. S-au construit 4 diagrame de clase pentru sistemul informațional ales și s-au
analizat entitățile de bază: clase, relatii dintre clase.

Diagramele de clase reprezintă un rol semnificativ pentru limbajul UML în elaborarea

modelului inițial conceptual a modelului pentru următoarea lui detaliere pentru nivelul fizic și
logic.