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

Analiza și Modelarea Orientată pe Obiecte.

Tema: Studiul şi analiza abstracţiilor OO şi claselor în UML (diagramele de clase).

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

A verificat: lector universitar Duca Ludmila

Chișinău 2021
Scopul lucrării: studierea noțiunilor de clasă, atribut și funcție, moștenire, compoziție, agregare,
asociere, dependență

Sarcina lucrării: de realizat 3-4 diagrame de clase pentru sistemul informațional ales

Considerații teoretice

Diagrama de clase este folosită pentru a modela structura (viziunea statică asupra) unui
sistem. O astfel de diagramă conţine clase / interfeţe, obiecte şi relaţii care se stabilesc între
acestea.
Clasele sunt folosite pentru a surprinde vocabularul sistemului ce trebuie dezvoltat. Ele pot
include:
 abstracţii care fac parte din domeniul problemei;
 clase necesare la momentul implementării.

O clasă poate reprezenta entităţi software, entităţi hardware sau concepte. Modelarea unui
sistem presupune identificarea elementelor importante din punctul de vedere al celui care
modelează. Aceste elemente formează vocabularul sistemului. Fiecare dintre aceste elemente are
o mulţime de proprietăţi.

Clase
Elementele unei clase sunt:
Nume - prin care se distinge de alte clase - o clasă poate fi desenată arătându-i numai
numele;
Atribute - reprezintă numele unor proprietăţi ale clasei;
Operaţii (metode) - reprezintă implementarea unor servicii care pot fi cerute oricărui
obiect al clasei.

Notaţia grafică pentru clasă poate fi observată în figura 1.

User

Figura 1. Notaţia grafică pentru clasă

 Specificatorii de vizibilitate au următoarea semnificaţie:
 + public (dreptul de utilizare se acordă şi celorlalte clase);
 - private (numai clasa dată poate folosi atributul sau operaţia);
 # protected (posibilitatea de utilizare este accesibilă numai claselor succesoare)

O clasă poate avea oricâte atribute şi operaţii sau poate să nu aibă nici un atribut sau nici
o operaţie. Modelarea vocabularului unui sistem presupune identificarea elementelor pe care
utilizatorul sau programatorul le foloseşte pentru a descrie soluţia problemei. Pentru fiecare
element se identifică o mulţime de responsabilităţi (ce trebuie să facă acesta), după care se
definesc atributele şi operaţiile necesare îndeplinirii acestor responsabilităţi.

Relaţii

O relaţie modelează o conexiune semantică sau o interacţiune între elementele pe care le

conectează. În modelarea orientată obiect cele mai importante relaţii sunt relaţiile de asociere,
dependenţa, generalizare şi realizare. Un caz particular al relaţiei de asociere îl constituie relaţia
de agregare. Între clase se pot stabili relaţii de generalizare, dependenţă şi realizare. Relaţiile de
asociere şi agregare se stabilesc între instanţe ale claselor.

Figura 2. Notaţii grafice pentru diferite tipuri de relaţii

Relația de asociere (a, b) este o relație de structură care descrie o totalitate de legături. Prin
legătură se subînțelege conexiunea între obiecte. Asocierea poate avea nume, rol, nivel de access.
Relația de agregare (c) este un caz particular a asocierii – o relație dintre partea întreagă și partea
componentă.

Relația de dependență (d) reprezintă relația sematică între 2 entități astfel încât modificarea unei
dintre ele poate influența modificarea celei de-a 2-a (dependentă).

Relația de generalizare (e) (sau numită moștenirea) este o relație de tipul specializare – realizare în
urma căruia un element specificat (descendent sau fiu) poate substitui elementul generalizat
(părinte).

Relația de realizare (f) este o relație semantică între două entități unde o entitate definește un
“contract” iar cea de-a doua garantează realizarea lui. Relația de realizare se utilizează în
următoarele cazuri: între interfețe și clase sau componente care o realizează.

Relația de compoziție (g) este un caz particular a agregării – o relație mai strictă decât agregarea
de parcă părțile componente se află în partea întreagă, partea componentă nu poate exista fără
partea întreagă, la distrugerea părții întregi se va distruge și partea componentă.

În următoarea diagramă (fig. 3) putem vedea o diagramă de clasă „Access Level”. În diagrama
respectivă am arătat 6 clase (Guest, User, Admin, Account, Privileged_mode și App).
Clasa Guest – are doar o metodă Register().

Clasa User – are 4 atribute, toate fiind private: username (de tip string), password (de tip string), ip
(de tip string), auth_date (de tip DateTime) și 3 metode: login() de tip string, change_password() cu
parametrul string – de tip void și restore_password() cu 2 parametri string – de tip void.

Clasa Admin – are 4 atribute, toate fiind protected: username (de tip string), password (de tip
string), ip (de tip string) și auth_date (de tip DateTime)

Toate aceste clase moștenesc de la clasa Account care are următoarele atribute (toate fiind de tip
public): username (de tip string), email (de tip string), password (de tip string), balance (de tip
double), reg_date (de tip DateTime), auth_date (de tip DateTime), Ip (de tip string), vip_user (de tip
boolean), vip_user_time (de tip int) și 4 metode: verify() – de tip void, logout() – de tip void,
addTransaction() – de tip void, showTransaction() – de tip void.

Figura 3. Diagrama de clasă – access level

În figura ce urmează (fig. 4) putem vedea patru clase (Transactions, AddTransaction, History, Stats),
trei fiind dependente de una. Clasele AddTransaction, Histroy și Stats sunt dependente de clasa
Transaction, adică fără ea nu poate exista. Toate aceste clasa au relație de dependență cu
stereotipul <<access>> - ceea ce înseamnă că toate atributele și metodele clasei Transaction sunt
disponibile și în celelalte clase.

Clasa Transaction are 5 atribute (toate fiind private) și o metodă (iarăși fiind privată): atributele
clasei sunt id (de tip int), amount (de tip double), user_id (de tip int), name (de tip string),
description (de tip string), date (de tip DateTime) și metoda: set() de tip void.

Clasa AddTransaction reprezintă clasa unde putem adăuga tranzacții noi în aplicație. Ea are 5
atribute (toate fiind publice) și o metodă publică, atributele clasei sunt: name (de tip string),
description (de tip string), amount (de tip double), category_id (de tip int), date (de tip DateTime) și
metoda: addTransaction() cu 4 parametri (string, double, int, string) de tip void.

Clasa History reprezintă clasa unde arătăm istoria tranzacțiilor, aici sunt 2 metode afișare a
tranzacțiilor (după dată și după id). Ea are 5 atribute (toate fiind publice) și o metodă publică,
atributele clasei sunt: maxCount (de tip int), id_start (de tip int), id_end (de tip int), date_start (de
tip DateTime), date_end (de tip DateTime) și metoda: display() de tip void.

Clasa Stats reprezintă clasa unde arătăm statistica tranzacțiilor. Ea are 5 atribute (toate fiind
publice) și o metodă publică, atributele clasei sunt: amount (de tip double), date_start (de tip
DateTime), date_end (de tip DateTime) și metoda: display() de tip void.
 Figura 4. Diagrama de clasă – Transactions
În figura ce urmează (fig. 5) avem reprezentată diagrama de clasă Sign in (de autentificare).
Aici putem vedea 3 clase – User, Login Page, Database.
Clasa User are 2 atribute: username (de tip string), password (de tip string) și 2 metode:
restore_password() – de tip void, isLogged() – de tip boolean.
Clasa Login_page are doar un atribut: status (de tip boolean) și o metodă: checkData() de tip void.
Clasa Database care are doar un atribut: status (de tip boolean) și o metodă: user_exist() de tip
boolean.
De asemenea putem observa numărul de obiecte care este transmis de la o clasă la alta. User (de la
1 până la n) – Login_page (1), Login_page (de la 1 la n) – Database (1).

Figura 5. Diagrama de clasă – Sign in

Concluzie

În concluzie pot afirma că în lucrarea dată am analizat, studiat și implementat diagramele de clase.
Am studiat tipurile de relații dintre clase, stereotipurile acestora (rolurile, denumirile și
numerotările). Am creat 3 diagrame de clase Access Level, Transactions, Sign in în care am
implementat teoria obținută în practică.