Șef lucrări dr. ing. Popa Sorin -Eugen Mihăică (Tonegaru) Petronela -Daniela Anul II 2019 TEMA PROIECTULUI DIAGRAME UML ( Unified Modeling Language )… [608896]

UNIVERSITATEA „VASILE ALECSANDRI” BACĂU
FACULTATEA DE INGINERIE
CONVERSIE INFORMATICĂ

PROIECT
INGINERIA PROGRAMĂRII

Profesor: Cursant
Șef lucrări dr. ing. Popa Sorin -Eugen Mihăică (Tonegaru) Petronela -Daniela
Anul II

2019

TEMA PROIECTULUI

DIAGRAME UML ( Unified Modeling Language )

3
INTRODUCERE

UML este un limbaj de modelare bazat pe nota ții grafice folosit pentru a specifica, vizualiza,
construi și documenta componentele unui program. UML este un l imbaj cu ajutorul căruia se pot
construi (descrie) modele. Un model surprinde un anumit aspect a l unui program și acela și model
poate fi descris la diferite nivel e de abstractizare. Fiecărui model îi corespunde o diagramă. Tipurile
de diagrame existente în UML sunt:
I) Diagrama cazurilor de utilizare (Use Case Diagram)
II) Diagrama de clase (Class Diagram)
III) Diagrame care descriu comportamentul:
1) Diagrame de interacțiuni (Interactions Diagrams)
a) Diagrama de secvență (Sequence Diagram)
b) Diagrama de colaborare (Collaboration Diagram)
2) Diagrama de stări (State chart Diagram)
3) Diagrama de activități (Activity Diagram)
IV) Diagrame de implementare:
1) Diagrama de componente (Component Dia gram)
2) Diagrama de plasare (Deployment Diagram)
Fiecărei din cele trei mari faze din dezvoltarea un proiect software îi corespunde una sau mai
multe diagrame UML și anume:
 pentru faza de analiza se utilizează diagrama cazurilor de utilizare și diagrama de a ctivități;
 în faza de analiză se folosesc: diagrama de clase pentru precizarea structurii sistemului și
diagramele de stări și interacțiune pentru descrierea comportamentului acestuia;
 în faza de implementare se utilizează diagramele de implementare.

4
DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM)

Nici un program nu este izolat, el interacționând cu oameni sau cu alte sisteme pentru îndeplinirea
unui scop.
O diagramă use case este una din diagramele folosite în UML pentru a modela aspectele dinamice
ale unui program alături de diagrama de activități, diagrama de stări, diagrama de secvență și
diagrama de colaborare.
Elementele componente ale unei diagrame use case sunt:
 use case -uri;
 actori;
 relațiile care se stabilesc între use cas e-uri, între actori și între use case -uri și actori.
Problemă
Sa se realizeze diagrama cazurilor de utilizare pentru un produs software ce urmeaz ă să
deserveasc ă o cas ă de marcat din cadrul unui supermagazin. Pentru aceasta c onsideram urm ătorul
scenariu:
1. Clientul solicită produsul.
2. Vânzătorul realizează facturarea acestuia. Pentru acesta:
a. se scanează codul de bare
b. se caută în baza de date codul produsului
c. daca produsul este găsit se adaugă la factura
d. daca produsul nu este găsit este respins
Din enunț ul anterior se identifică următorii actori:
 Client
 Vânzător
Cazurile de utilizare corespunzătoare funcționalității descrise sunt următoarele:
 Solicitarea produsului
 Facturarea
 Citirea codului de bare
 Căutarea in baza de date
 Adăugarea produsului la factura
 Respingerea produsului
În figura de mai jos avem Diagrama Use Case:

5

DIAGRAMA DE CLASE

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.
Relațiile pot fi de tipul:
 asociere;
 agregare;
 generalizare;
 dependență;
 realizare.
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.

6
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 mod elează. Aceste
elemente formează vocabularul sistemului. Fiecare dintre aceste elemente are o mulțime de
proprietăți.
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.
În figura de mai jos este o diagramă de clase pentru desenarea unei forme.

DIAGRAMA DE STĂRI (STATE CHART DIAGRAM)
Diagrama de stări este folosită pentru a modela comportamentul unui singur obiect.
Diagrama de stări specifică o secvență de stări prin care trece un obiect de -a lungul vieții sale ca
răspuns la evenimente împreună cu răspunsul la aceste eve nimente.
Un eveniment reprezintă ceva (atomic) ce se întâmplă la un moment dat și care are atașată o
locație în timp și spațiu. Evenimentele modelează apariția unui stimul care poate conduce la
efectuarea unei tranziții între stări. Evenimentele nu au dura tă în timp.
Evenimentele pot fi clasificate în felul următor:

7
 sincrone sau asincrone
 externe sau interne
Prin stare se înțelege o condiție sau situație din viața unui obiect în timpul căreia acesta:
 satisface anumite condiții;
 efectuează o activitate;
 așteaptă apariția unui eveniment.
Să se creeze diagrama de stare pentru cazul de utilizare Înregistrare comandă nouă.
În figura de mai jos avem diagrama de stare pentru clasa Comandă.

Prima stare a comenzii este In curs de aprobare , ca urmare a execuție i operațiunii
creareComanda declanșată de evenimentul -semnal Primire comanda . Trecerea comenzii în această
stare va declanșa automat operațiunea verificareLimitaCredit , în funcție de rezultatul căreia comanda
va trece în una din doua stări posibile: Aproba tă, dacă limita de creditare nu este depășită, și
Neaprobată dacă limita este depășită, caz în care se va continua imediat prin invocarea operațiunii
marireLimitaCreditare . Dacă mărirea limitei este aprobată și înregistrată, atunci comanda va trece în
starea Aprobata , iar dacă nu în starea Respinsă , caz în care va fi declanșată execuția operațiunii
notificareComandaRespinsa .

8
Trecerea comenzii în starea aprobată va declanșa operațiunea verificareStoc , în urma căreia se
pot ivi două situații: stocul este sufi cient, caz în care se va continua cu livrarea produselor și trecerea
comenzii în starea Onorata ; stocul este insuficient, caz în care se va executa operațiunea
notificareProductie , iar comanda va fi trecută în starea Lansata în fabricație .
O altă stare pos ibilă este Anulata , evenimentul declanșator fiind solicitarea de anulare din partea
clientului. Însă, trecerea comenzii în această stare este posibilă numai dacă ea nu a fost deja onorată.
Astfel, am dorit să evidențiem în mod expres că nu este posibilă tr anziția din starea Onorata în starea
Anulata .
Toate schimbările de stare ale comenzii sunt realizate prin operațiunea actualizareStare .
Ar mai putea fi adăugată o stare, Fabricata , prin care sa se evidențieze faptul că o comandă este
gata de livrare. Eveni mentul declanșator ar fi unul de tip semnal, adică o notificare primită de la
sistemul de producție.

DIAGRAME DE INTERACȚIUNI – DIAGRAMA DE SECVENȚĂ
Diagramele de interac țiuni sunt folosite pentru a modela comportamentul unei mul țimi de obiecte
dintr -un anumit context care interac ționează în vederea îndeplinirii unui anumit scop.
Scopul specifică modul în care se realizează o opera ție sau un caz de utilizare.
Contextul unei interac țiuni (unde pot găsi interac țiuni) poate fi:
 sistem / un subsistem (uzual) – mulțimea obiectelor din sistem care colaborează între ele;
 opera ție – interac țiuni între parametri, variabile locale și globale;
 clasă – interac țiuni între atributele unei clase (cum co laborează ele), interacțiuni cu obiecte
globale, sau cu parametrii unei opera ții.
Obiectele care participă la o interac țiune pot fi lucruri concr ete sau prototipuri. De obicei, într-o
colaborare obiectele reprezintă prototipuri ce joacă diferite roluri, și nu obiecte specifice din lumea
reală.
Între obiectele care partici pă la o colaborare se pot stabili legături.
O legătură (link) reprezintă o conexiune semantică între obi ecte. Ea este o instanță a unei asocieri
și poate avea toate atributele specifice asocierii (nume, roluri, navigare, agregare), dar nu și
multiplicitate .
Obiectele care interac ționează comunică între ele, comuni carea făcându -se prin schimb de
mesaje.
Un mesaj specifică o comunicare între obiecte. El poartă o informație și este urmat de o activitate.
Primirea unei instan țe a unui mesaj poate fi considerată o instan ță a unui eveniment.

9
Unui mesaj îi este asociată o ac țiune care poate avea ca ef ect schimbarea stării actuale a
obiectului.
Forma generală a unui mesaj este :
[cond_gard ă] acțiune (lista_parametrilor)
unde :
 condi ție_gardă – condi ție booleană care s e evaluează la fiecare apariție a mesajului
specificat; ac țiunea se execută doar când rezultatul evaluării este true;

În figura de mai jos avem o diagramă de frecvență utilizată la o bibliotecă

DIAGRAME DE IMPLEMENTARE

Diagrama de componente este o diagramă de implementare care modelează dependen țele dintre
componentele software ale sistemului și entită țile care le im plementează (fi șiere cod sursă, cod binar,
executabile, scripturi etc.).
Într-un proiect de dimensiune mare, vor exista multe fi șiere care realizează sistemul.

10
Aceste fi șiere depind unele de altele. Natura acestor dependen țe e dată de limbajul (limbajelor)
folosite pentru dezvoltarea proiectului. Dependen țele pot exista în momentul compilării, link -editării
sau rulării. Există de asemene a dependen țe între fi șiere sursă și cele executabile s au obiect, rezultate
din primele prin compilare.
În exemplul de mai jos vom face o asociere simplă între două clase: PROFESOR și CURS.
Cele două clase asociate se pot defini în limbajul C++ folosind do uă variabile de asociere în
modul următor:
const MAX = 100;
class Profesor;
class Curs{
char* denumire;
// Variabila de asociere: vector de pointeri
Profesor* profesori[MAX];
int nr_profesori;
public:
// Metode publice de obtinere a obiectelor asociat e
Profesor* getProfesor(int index){return profesori[i];
. . . . . . . . . . . . . . . .
};
class Profesor{
char *nume;
// Variabila de asociere: vector de pointeri
Curs* cursuri[MAX];
int nr_cursuri;
// Metode publice de obtinere a obiectelor asociate
Curs* getCurs(int index) ){return cursuri[i];
. . . . . . . . . . . . . . .
};

Variabila profesori din clasa CURS permite ca fiecare obiect, instanță a clasei CURS, să
memoreze lista tuturor profesorilor cu care acesta este asociat (ca vector de pointeri la clasa
PROFESOR, având nr_profesori elemente din dimensiunea maximă admisă MAX), asigurând
navigarea dinspre clasa CURS spre clasa PROFESOR.
Variabila cursuri din clasa PROFESOR permite ca fiecare obiect, instanță a clasei PROFESOR,
să memo reze lista tuturor cursurilor cu care acesta este asociat (ca vector de pointeri la clasa CURS,
având nr_cursuri elemente din dimensiunea maximă admisă MAX), asigurând navigarea dinspre
clasa PROFESOR spre clasa CURS.
Această soluție este cea mai simplă, exemplificată ca idee de implementare; soluțiile mai
elaborate pot folosi vectori cu alocare dinamică sau liste înlănțuite de pointeri.

11

BIBLIOGRAFIE

1. Cornelia Novac Ududec Ingineria programării, Edi ție adăugită și revizuită, Editura
Alma Mater , Bacău, 2011
2. Florica Moldovan Ingineria Programării , Universitatea Politehnică București
3. Pilat Florin, s.a. Metode, tehnici și instrumente în ingineria programării,
Editura Tehnică, Bucure ști 1985
4. Rotar Dan Ingineria programelor, Editura Alma Mater, Bacău, 2007
5. Văduva Ilie, Baltac Vasile,
Florescu Vasile Ingineria programării. Volumul I, II , Editura Academiei,
Bucure ști, 1986

12
CUPRINS
INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. . 3
DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM) ………………………….. ……… 4
DIAGRAMA DE CLASE ………………………….. ………………………….. ………………………….. ……………….. 5
DIAGRAMA DE STĂRI (STATE CHART DIAGRAM) ………………………….. ………………………….. .. 6
DIAGRAME DE INTERACȚIUNI – DIAGRAMA DE SECVENȚĂ ………………………….. …………… 8
DIAGRAME D E IMPLEMENTARE ………………………….. ………………………….. ………………………….. . 9
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. 11