UNIVERSITATEA PETROL-GAZE DIN PLOIEŞTI

Specializarea INGINERIA ŞI INFORMATICA PROCESELOR

CHIMICE ȘI BIOCHIMICE
- Învăţământ cu frecvenţă –

SISTEME INFORMATICE INTEGRATE

Suport de curs

Ploiești 2020
 Unitatea de învățare 6. Limbajul unificat de modelare, UML
Unitatea de învățare 6. Limbajul unificat de modelare, UML .................................................... 2
6. 1. Modelarea ............................................................................................................... 2
6. 2. Limbajul unificat de modelare ................................................................................. 3
6. 3. Diagramele UML 2.0 ................................................................................................ 5
6.3. 1. Diagrama cazurilor de utilizare............................................................................. 5
6.3. 2. Scenarii ................................................................................................................. 9
6.3. 3. Diagrama de activitate ....................................................................................... 11
6.3. 4. Diagrama de clase .............................................................................................. 12
6.3. 5. Diagrama de secvențe ........................................................................................ 14

Durata: 2 ore
Cunoștințe și deprinderi
La finalul parcurgerii acestei unității de învățare veți înțelege:
- care este utilitatea modelării unui sistem;
- care sunt diagramele utilizate în limbajul de modelare UML;
- ce diagrame pot fi utilizare în evidențierea mesajelor dinte obiecte din punct de vedere
temporal.

La finalul parcurgerii acestei unități de învățare veți putea să:

- descrieți principalele tipuri de diagrame utilizate in limbajul de modelare UML 2.0;
- definiți actorii și cazurile de utilizare ale unui sistem;
- descrieți diagrama claselor unui sistem.

6. 1. Modelarea

Un model reprezintă o simplificare a unui anumit sistem, care permite analizarea unora
dintre proprietățile acestuia. Utilizarea modelelor facilitează abordarea problemelor complexe,
comunicarea și înțelegerea acestora [1].
Se poate crea un model pentru:
▪ Descrierea elementelor componente sau a subsistemelor ce se regăsesc în
sistemul real;
▪ Simularea fenomenelor și proceselor ce au loc în sistemul real;
▪ Anticiparea anumitor consecințe;
▪ Predicția evoluției anumitor parametri ai sistemului real etc.
 Construirea unui model trebuie să satisfacă în mod echilibrat două cerințe: prima
impune ca modelul să fie destul de simplu, să fie o reprezentare a sistemului real cu un anumit
grad de abstractizare. A doua cerință prevede ca modelul să fie destul de fidel sistemului real
[7].
În funcție de contextul în care este utilizat un model se poate construi în orice limbaj
“intern” (dacă nu există un context formal) sau utilizând un limbaj standardizat (într-un context
formal, înțeles de toți utilizatorii).
Necesitatea utilizării unui limbaj standardizat a rezultat din faptul că până la începutul
anilor 90 erau folosite aproximativ 50 de limbaje de modelare software, fiecare cu propriile
notații.

6. 2. Limbajul unificat de modelare

La mijlocul anilor 90 trei metode erau preponderent utilizate, dovedindu-se printre cele
mai eficiente [1]:
▪ metoda OOADA, creată de către Grady Booch. S-a dovedit eficientă mai ales în
etapa de proiectare și cea de implementare, cu dezavantajul unor notații
complicate.
▪ metoda OMT, Object Modeling Technique, dezvoltată de Jim Rumbaugh. Este
o metodă pentru analiza și proiectarea orientată obiect a unor sisteme informatice
cu multe date.
▪ metoda OOSE, Object Oriented Software Engineering (Ivar Jacobson). Inovația
acestei metode constă în propunerea utilizării așa-numitele cazuri de utilizare,
care ajută la înțelegerea comportamentului sistemului în ansamblu.
În ianuarie 1997, cei trei autori au lansat prima versiune a limbajului unificat de
modelare, UML – ce conținea elemente de analiză și proiectare preluate din cele trei metode
(OOADA, OMT, OOSE). În scurt timp, UML a fost ales ca standard al limbajelor de modelare
orientate obiect.
UML este un limbaj grafic care oferă dezvoltatorilor instrumente pentru vizualizarea,
specificarea, construirea și crearea documentației componentelor unui sistem software. El poate
fi util în toate domeniile ingineriei software oferind posibilitatea de a include în proiectarea
sistemului atât a obiectelor conceptuale și a funcțiilor de sistem, precum și a obiectelor concrete
cum ar fi declarațiile din limbajul de programare, scheme ale bazelor de date și componente
software reutilizabile [3].
Ca orice limbaj, UML are notații (alfabetul de simboluri) și reguli pentru combinarea
simbolurilor (sintaxă și gramatică). Diagramele puse de către UML la dispoziția utilizatorilor
se împart în 2 mari categorii (Figura 1) [8]:
• Diagrame de structură, ce prezintă elementele unei specificații independent
de timp;
• Diagrame comportamentale, ce prezintă trăsăturile comportamentale ale
sistemului software.
 Figura 1 Diagrame UML 2.0 [8]

Diagramele de structură includ:

• diagramele de clase (Class Diagram);
• diagramele de componente (Component Diagram);
• diagramele de desfășurare (Deployment diagram);
• diagramele de obiecte (Object Diagram);
• diagramele de pachete (Package Diagram);
• diagramele de structuri compuse (Composite Structure Diagram).
Diagramele de comportament cuprind:
• diagramele de activități;
• diagramele de mașini de stare;
• diagramele de cazuri de utilizare;
• 4 diagrame de interacțiune:
o diagramele de secvențe (Sequence diagram);
o diagrame de comunicare (Communication diagram);
o diagrame de interacțiuni generale (Interaction Overview Diagram);
o diagrame de cronometrare (Timing Diagram).
Dintre acestea digramele de clasă, diagramele de activități, diagramele cazurilor de
utilizare și diagramele de secvențe prezintă o utilitate ridicată [1].
 6. 3. Diagramele UML 2.0

Diagramele UML 2.0 ce vor fi prezentate cu utilitate ridicată în cadrul acestui curs sunt:
diagramele cazurilor de utilizare, diagramele de activitate, diagramele de clase, diagramele de
secvență. Ele vor fi dezvoltate cu ajutorul produsului software Visual Paradigm Community
Edition 15.0 [9].

Exercițiul 1
Descrieți în ce alte scopuri mai poate fi utilă modelarea unui sistem.

Pentru exemplificare, în cadrul acestei unități de învățare, se va considera sistemul

informatic MonitAer. Acesta este utilizat în rețeaua de calculatoare a unei Agenții Gardă de
Mediu pentru monitorizarea și analiza calității aerului.
Scopul sistemului este acela de a oferi informații legate de principalii poluanți
atmosferici (descriere, surse, limite superioare ale valorilor, posibile efecte asupra sănătății
populației, valorile concentrațiilor înregistrate) și parametri meteorologici ce influențează
calitatea aerului cât și legate de indicele specific de calitatea aerului (sistemul de codificare,
condiții de calculare).
Sistemul este utilizat de către responsabilul cu monitorizarea calității aerului. Acesta
poate introduce noi valori înregistrate pentru anumiți parametri, poate afișa anumite valori
măsurate pentru unul sau mai mulți poluanți, poate afișa descrierea unui anumit poluant, poate
afișa valoarea indicelui specific etc. aplicația trebuie sa permită generarea diferitelor rapoarte,
să permită introducerea unor măsurători noi, a unor parametri atmosferici noi etc.
Stabilirea indicelui specific de calitatea aerului se realizează conform legislației
românești în vigoare [10]. Atât indicele general, cât și indicii specifici reprezintă un sistem de
codificare prin numere întregi cuprinse între 1 si 6, fiecare număr corespunzând unei culori
(Figura 2). Pentru a putea fi stabilit indicele general trebuie să fie disponibili cel puțin trei
specifici corespunzător poluanților monitorizați (dioxid de sulf, dioxid de azot, ozon, monoxid
de carbon, particule în suspensie). Valoarea indicelui general este cea mai mare valoare dintre
indicii specifici corespunzători poluanților monitorizați.

Figura 2. Sistem național de codificare a indicelui specific al calității aerului [10]

6.3. 1. Diagrama cazurilor de utilizare

Diagrama cazurilor de utilizare este folosită cu precădere în etapa de analiză pentru a
defini comportamentul sistemului sau a unei entități, fără a specifica structura internă. Noțiunile
întâlnite în proiectarea acestui tip de diagramă sunt: actor, caz de utilizare, relații de utilizare
(includere), relații de extindere, relații de generalizare și de asociere [3].
În limbajul UML se utilizează denumirea de actor pentru orice rol jucat de către un
utilizator uman sau alt sistem care interacționează cu sistemul analizat. Un actor poate fi un
student ce se înscrie la un curs, un client al unui magazin online, administratorul unei biblioteci
virtuale etc.
Pentru sistemul informatic MonitAer singurul actor uman este Responsabilul de
monitorizare (Figura 3). Un alt actor poate fi considerat sistemul online de informare a
populației cu privire la calitatea aerului, către care sistemul informatic furnizează date periodic.

Figura 3 Exemple de actori

Un caz de utilizare reprezintă un ansamblu de acțiuni la care participă unul sau mai mulți
actori și care permite modelarea comportamentală a sistemului studiat [5]. Comportamentul
unui caz de utilizare este specificat prin descrierea setului de acțiuni [3]. Pentru sistemul
MonitAer putem exemplifica in Figura 4 câteva cazuri de utilizare (PornesteAplicatia,
AdaugaParametruAtmosferic, AdaugăMasuratori, AfiseazaValoriParametruAtmosferic etc).

Figura 4 Exemple de cazuri de utilizare

Identificarea principalelor cazurilor de utilizare pentru sistemul informatic MonitAer

cuprinde identificarea cazurilor de utilizare specifice fiecărui actor prezent.
Astfel, principalele cazuri de utilizare ale responsabilului sunt (Figura 5):
▪ Pornirea aplicației;
▪ Adăugarea unui nou parametru atmosferic;
▪ Adăugarea unor noi măsurători ale unui parametru specific;
▪ Afișarea unor informații despre un anumit parametru atmosferic;
▪ Afișarea valorilor măsurate într-un anumit interval orar;
▪ Afișarea valorii indexului specific la o anumită oră.

Exercițiul 2
Descrieți câteva cazuri de utilizare pentru un alt actor al sistemului MonitAer (Un alt actor
poate fi considerat sistemul online de informare a populației cu privire la calitatea aerului, către
care sistemul informatic furnizează date periodic).
 Figura 5. Cazuri de utilizare pentru navigator

Relații dintre cazurile de utilizare sunt de incluziune, de extensie și de generalizare.

Relațiile de incluziune se folosesc atunci când există un comportament care se repetă
identic în situația mai multor cazuri de utilizare. Această relație este formalizată prin cuvântul
cheie <<include>>. Astfel, în Figura 6, cazul de utilizare 2 este înglobat în cazul 1 și se execută
obligatoriu odată cu 1.

Figura 6 Relația de incluziune

Relația de extensie se utilizează atunci când există un caz de utilizare similar cu un alt
caz, dar care face ceva în plus față de acesta. Cuvântul cheie <<extend>>, în Figura 7,
precizează că după execuția procedurii Cazul 4 se poate eventual, continua cu procedura Cazul
3.

Figura 7. Relația de extensie

 Relația de generalizare este o relație opusă specializării și se utilizează cu precădere
când una sau mai multe cazuri de utilizare derivate, moștenesc datele și comportamentul unui
caz de utilizare de bază (Figura 8) [5].

Figura 8. Relația de generalizare

În Figura 9, cazul de utilizare Afișare unor informații despre parametru atmosferic

generalizează diferitele posibilități de afișare a informațiilor (Afișare descriere parametru
atmosferic, Afișare surse parametru atmosferic, Afișare limite superioare ale valorilor, Afișare
posibile efecte asupra sănătății populației etc).

Figura 9 Relația de generalizare a cazului de utilizare Afișare informații parametru

atmosferic

Exercițiul 3
Dați exemple de cazuri de utilizare între care există relația de incluziune, respectiv relația
de extensie.

Descrierea cazurilor de utilizare

Pornirea aplicației: la pornire, aplicația prezintă o fereastră – interfața utilizator de

unde Responsabilul să poată alege ce dorește să facă.
Adăugarea unui nou parametru atmosferic: aplicația prezintă fereastra Adăugare
parametru nou și așteaptă responsabilul să introducă denumirea, unitatea de măsură, limitele
superioare ale posibilelor valori, descrierea parametrului atmosferic, surse și posibile efecte ale
poluantului asupra populației. Astfel se inserează o nouă înregistrare în lista parametrilor
atmosferici monitorizați.
Adăugarea unor noi măsurători ale unui parametru specific: programul prezintă
fereastra adăugare valori noi pentru un parametru atmosferic, astfel se poate adăuga numele
parametrului, valoarea înregistrată, stația, data și ora la care s-a măsurat respectiva valoare.
Programul va căuta în lista parametrilor numele introdus. Dacă este pentru prima dată când se
monitorizează acest poluant atunci se creează o nouă înregistrare în lista parametrilor.
Afișarea unor informații despre un anumit parametru atmosferic: sistemul afișează
denumirea, surse, limitele superioare valorilor concentrațiilor, posibile efecte asupra populației.
Afișarea valorilor măsurate într-un anumit interval orar: sistemul afișează pentru
parametrul selectat, valorile concentrațiilor măsurate in intervalul orar ales.
Afișarea valorii indexului specific la o anumită oră: aplicația prezintă fereastra
interfață utilizator, unde Responsabilul introduce stația de monitorizare, data și ora pentru
analiză. Sistemul caută datele necesare (existența valorilor înregistrate pentru minim 3 poluanți
atmosferici), calculează valoarea indicelui general ca fiind maximul dintre indicii specifici și
afișează valoarea indexului de calitate calculat.

6.3. 2. Scenarii
Un scenariu reprezintă o succesiune de pași care descrie o posibilă interacțiune între
actor și sistem.
De exemplu, pentru cazul de utilizare Afișarea valorii indicelui specific la o anumită
oră pot exista următoarele scenarii:
Scenariul (1)
1. Responsabilul, care dorește să afișeze valoarea indexului specific la o anumită
oră, completează rubricile afectate datei și orei cât și a stației de monitorizare
dorite și apoi apasă butonul “Afișare”;
2. Sistemul preia datele si verifica dacă stația există în lista stațiilor de
monitorizare, iar pentru data și ora cerute sunt valori înregistrate;
3. Responsabilul primește mesajul: „Stația de monitorizare nu există în cadrul
rețelei de monitorizare. Introduceți o stație validă”.
Scenariul (2)
1. Responsabilul, care dorește să afișeze valoarea indexului specific la o anumită
oră, completează rubricile afectate datei și orei cât și a stației de monitorizare
dorite și apoi apasă butonul “Afișare”;
2. Sistemul preia datele și verifică dacă stația există în lista stațiilor de
monitorizare, iar pentru data și ora cerute sunt valori înregistrate;
3. Responsabilul primește mesajul: „Pentru data și ora selectată nu există
înregistrări în cadrul rețelei de monitorizare”.
Scenariul (3)
1. Responsabilul, care dorește să afișeze valoarea indexului specific la o anumită
oră, completează rubricile afectate datei și orei cât și a stației de monitorizare
dorite și apoi apasă butonul “Afișare”;
 2. Sistemul preia datele și verifică dacă stația există în lista stațiilor de
monitorizare, iar pentru data și ora cerute sunt valori înregistrate;
3. Responsabilul primește mesajul: „Nu se poate calcula valoarea indexului
specific deoarece nu există valori măsurate pentru minim trei poluanți
atmosferici”.
Scenariul (4)
1. Responsabilul, care dorește să afișeze valoarea indexului specific la o anumită
oră, completează rubricile afectate datei și orei cât și a stației de monitorizare
dorite și apoi apasă butonul “Afișare”;
2. Sistemul preia datele și verifică dacă stația există în lista stațiilor de
monitorizare, iar pentru data și ora cerute sunt valori înregistrate;
3. Sistemul afișează valoarea indicelui general calculat la stația, data și ora indicată
de Responsabil.

Descrierea unui caz de utilizare cuprinde un set de scenarii corelate, de exemplu, toate
scenariile de afișare a valorii indicelui specific la o anumită oră. Formatul descrierii consta
dintr-o secvență tipică de pași si alternativele, ca variante ale secvenței tipice. Exemplu:
Cazul de utilizare Afișarea valorii indicelui specific la o anumită oră
1. Responsabilul, care dorește să afișeze valoarea indexului specific la o anumită
oră, completează rubricile afectate datei și orei cât și a stației de monitorizare
dorite și apoi apasă butonul “Afișare”;
2. Sistemul preia datele si verifica dacă stația există în lista stațiilor de
monitorizare, iar pentru data și ora cerute sunt valori înregistrate;
3. Sistemul verifică datele introduse de Responsabil;
3a). Dacă stația de monitorizare nu este validă, se execută alternativa “Stație
invalidă”;
3b). Dacă data sau ora introduce nu sunt valide, se execută alternativa “Dată sau
oră invalidă”;
4. Sistemul caută valorile dorite;
4a). Dacă nu există minim trei valori măsurate pentru poluanții vizați se execută
alternativa “Imposibilitate de calcul”;
5. Sistemul afișează valoarea indicelui general calculat la stația, data și ora indicată
de Responsabil.

Alternativa „Stație invalidă”

1. Responsabilul primește mesajul: „Stația de monitorizare nu există în cadrul rețelei
de monitorizare. Introduceți o stație validă”.
Alternativa „Data sau ora invalidă”
2. Responsabilul primește mesajul: „Pentru data și ora selectată nu există înregistrări
în cadrul rețelei de monitorizare”.
Alternativa „Data sau ora invalidă”
 3. Responsabilul primește mesajul: „Nu se poate calcula valoarea indexului specific
deoarece nu există valori măsurate pentru minim trei poluanți atmosferici”.
6.3. 3. Diagrama de activitate
O diagramă de activitate evidențiază evoluția unui anumit proces de-a lungul acțiunilor
sale. Este utilizată mai ales atunci când este necesară modelarea legăturii fiecărei activități cu
celelalte sau este dorită evidențierea mai multor procese paralele. O acțiune reprezintă un singur
pas într-o activitate (Figura 10).
La nivelul unei diagrame de activitate se întâlnesc următoarele tipuri de noduri: noduri
de control (nod inițial, noduri de decizie, noduri de ramificare – Fork, noduri de unificare –
Join, nod final), noduri executabile (noduri acțiune și noduri “Tratare excepție”), noduri obiect
[6]. De asemenea, există posibilitatea organizării fluxului de control pe culoare (swimlanes),
corespunzătoare obiectelor ce execută fiecare activitate.

Figura 10 Diagrama de activitate [6]

Pentru sistemul MonitAer, putem exemplifica diagrama de activitate pentru cazul de

utilizare Afișarea valorii indicelui specific la o anumită oră în Figura 11. Astfel, după ce se
afișează ecranul de pornire, responsabilul introduce stația de monitorizare dorită, apoi data și
ora de analiză, în urma căruia sistemul afișează valoarea indicelui general de calitate a aerului
sau un mesaj corespunzător prin care responsabilul este informat că valoarea indicelui nu s-a
putut calcula.
Astfel, o diagramă de activitate poate fi utilizată pentru a modela scenarii, fluxul
controlului la diferite nivele ale sistemului sau schimbul de informație între diferite obiecte ale
unei aplicații etc [6].
 Figura 11. Diagrama de activitate pentru cazul de utilizare Afișarea valorii indicelui specific la o
anumită oră

6.3. 4. Diagrama de clase

Scopul diagramei de clase este acela de a prezenta clasele din cadrul sistemului și
relațiile dintre ele. O clasă este reprezentată în UML printr-un dreptunghi împărțit în trei zone:
în zona de sus este trecut numele clasei, în cea de mijloc atributele iar în cea de-a treia funcțiile
membru (Figura 12).
Reprezentarea unei clase în UML depinde de etapa de dezvoltare a produsului software.
În faza de analiză a cerințelor, se pot trece doar numele clasei și al atributelor (fără specificarea
tipului de date), eventual unele operații. În etapa de proiectare detaliată, trebuie specificate toate
informațiile necesare unei implementări ulterioare (vizibilitatea datelor membru, lista de
parametri a fiecărei metode, tipul parametrilor etc.).
În reprezentarea unei clase se ține cont de câteva reguli de scriere: membrii statici sunt
subliniați, membrii privați sunt precedați de simbolul minus (-), membrii publici de plus (+),
membrii protejați de diez (#)
 Figura 12 Reprezentarea UML a unei clase

Din descrierea detaliată a cazurilor de utilizare și modelarea acestora cu ajutorul

diagramelor UML, se pot identifica clasele și mesajele trimise între obiectele sistemului.
Această etapă cuprinde [11]:
Pasul 1. Se identifica substantivele în cazurile de utilizare;
Pasul 2. Se rafinează lista de substantive;
Pasul 3. Se identifica atributele claselor utilizate;
Pasul 4. Se identifică mesajele din cazurile de utilizare.
Pentru aplicația MonitAer, acești pași pot fi descriși astfel:
Pasul 1: ecranul interfață, ecran adăugare parametru atmosferic, denumire parametru,
caracteristici parametru, unitatea de măsură, limitele superioare ale posibilelor valori, surse,
efecte posibile asupra populației, ecran adăugare noi valori ale unui parametru, denumire
parametru, valoare înregistrată, stația, data, ora, ecran afișare informații parametru, ecran
afișare valori măsurate pentru un parametru atmosferic, ecran afișare index general la o anumită
oră, index general,
Pasul 2. Clase identificate: EcranulUI, ParametruAtmosferic, EcranAdaugaParametru,
ListaParametri, EcranAdaugaValoareMasurata, EcranAfișarInformațiiParametru,
EcranAfișareValoriMăsurate, IndexGeneral, EcranAfișareIndexGeneral.
Pasul 3. Descoperirea atributelor se poate face prin identificarea substantivelor eliminate
la pasul 2. De exemplu, pentru clasa ParametruAtmosferic, date membru pot fi: denumire
parametru, caracteristici parametru, unitatea de măsură, limitele superioare ale posibilelor
valori, surse, efecte posibile asupra populației.
Pasul 4. Se parcurge fiecare caz de utilizare în parte și se identifică acele verbe care au
rolul de a invoca o funcție. De exemplu, pentru cazul de utilizare Afișarea valorii indexului
specific la o anumită oră, se identifică verbul afișează, deci ar trebui să existe o funcție
membru ce afișează valoarea indicelui. De asemenea, se regăsesc verbele introduce, caută,
calculează ce pot sta la baza unor alte funcții membru.
Diagrama claselor pentru sistemul MonitAer se poate reprezenta ca în Figura 13.
 Figura 13 Diagrama de clase pentru sistemul MonitAer

6.3. 5. Diagrama de secvențe

Diagramele de secvență reprezintă interacțiunile între obiecte din punct de vedere
temporal, nefiind prezentat în mod explicit contextul acestora ca în cazul diagramelor de
colaborare. Obiectivul principal al acestui tip de diagramă este acela de a evidenția ordonarea
în timp a mesajelor prin care comunică obiectele.
O diagramă secvențială cuprinde obiecte, componente implicate într-o interacțiune și
mesajele schimbate între ele. Un obiect este reprezentat printr-un dreptunghi și o linie verticală
reprezentând linia de viață a acestuia. Mesajele sunt săgeți orizontale de la emitent la
destinatarul acestuia. Ordinea de trimitere este dată de poziția lor pe axa verticală, de sus în jos.
Acest tip de diagramă se construiește pornind de la scenariile identificate în etapa de
analiză și sunt utilizate fie ca mijloc de documentare a cazurilor de utilizare iar interacțiunea
este descrisă în termeni apropiați utilizatorului (Figura 14) fie ca mijloc de reprezentare exactă
a mesajelor schimbate între obiecte (Figura 15).
 Figura 14 Diagrama de secvență a cazului index general

În Figura 15 este reprezentată diagrama de secvență a cazului de utilizare Adăugarea

unui parametru atmosferic. Simbolurile X indică sfârșitul de viață al obiectului.

Figura 15 Diagrama de secvență a cazului Adăugare parametru

 Bibliografia UI
1. Leon, F., Ingineria programarii, notite de curs, Facultatea de Automatica si
Calculatoare Iasi, 2016, http://florinleon.byethost24.com/curs_ip.htm?i=1, accesat 1
iulie 2017
2. Iftene, A., Ingineria programarii, notite de curs Facultatea de Informatica, Iasi, 2016,
https://profs.info.uaic.ro/~adiftene/studenti.html, accesat 12 iulie 2017
3. Ududec Novac, C., Ingineria sistemelor de programe, Editura Alma Mater, Bacău,
2011
4. Oprea, M., Programare orientată pe obiecte – Exemple în limbajul C++,, editura
Matrix Rom, București, 2003
5. Ioniță, I., Programare orientată pe obiecte – notițe de curs, Universitatea Petrol Gaze
din Ploiești, Facultatea Litere și Științe, specializarea Informatică, 2017
6. Moldoveanu F., Ingineria programarii- notite de curs, UPB, Facultatea de Automatică și
Calculatoare, sectia Calculatoare si Tehnologia Informatiei 2014,
http://andrei.clubcisco.ro/cursuri/anul-3/semestrul-2/ingineria-programelor.html, accesat 1
august 2017
7. ***, Modelul unui sistem, https://ro.wikipedia.org/wiki/Modelul_unui_sistem, accesat
23 iulie 2017
8. ***, Diagrame UML 2.0, http://tsort.info/iabok/unified_modeling_language.htm,
accesat 12 iulie 2017
9. ***,Visual Paradigm Community Edition 15.0, https://www.visual-
paradigm.com/solution/freeumltool/?gclid=CjwKCAjwwbHWBRBWEiwAMIV7E8d
DIhWyWKMUBnA0PAXln4SGAfuFzc181UO1cFjdf4T2viOnsYBm_RoCTLEQAvD
_BwE, accesat 20 iulie 2017
10. ***, Rețeaua Națională de Monitorizare a Calității Aerului,
http://www.calitateaer.ro/public/monitoring-page/quality-indices-page/?__locale=ro,
accesat 14 iulie 2017
11. Lafore, R., Object-Oriented Programming in C++, Fourth Edition,Sams Publishing,
2002