UTM

MODELAREA PROCESELOR UTILIZAND

UML
 Ciclul de viaţă a produselor software
Un ciclu de viață al unui produs software reprezintă un set de activități care conduc
spre producearea unui produs software. Aceste activiăți implica dezvoltarea software
de la zero într-un limbaj conceptual precum Java sau C.

Un ciclu de viață al produsului ar putea consta din următoarele etape :

•1) Analiza și colectarea cerințelor
•2) Proiectare
•3) Implementare și dezvoltare
•4) Testare și validare
•5) Vânzarea și folosirea propriu zisă a produsului
•6) Mentenanță
 Analiza

În această etapă a proiectului are loc definirea a ceea ce

trebuie dezvoltat. Obiectivul aici este să se afle nevoile
clientului şi să se definească foarte clar cerinţele privind
viitorul produc software.

Specificațiile ce pot fii:

Cine va folosi sistemul?
Cum vor folosi acest sistem?
Ce fel de date se vor introduce în sistem?
Ce fel de date vor ieși din sistem?
 Proiectarea
Această etapă are ca obiectiv modelarea viitorului sistem, văzut ca
soluţie a problemelor determinate în faza de analiză. Dacă Analiza
îşi propunea să determine ce trebuie făcut, faza de proiectare
trebuie să arate cum trebuie făcut. În această fază sunt proiectate
funcţionalităţile pe care viitorul sistem va trebui să le aibă.
În această etapă sistemul și arhitectura sistemului sunt pregătite
urmând modelul documentului cu specificațile produsului realizat
în prima etapă. Tot în această etapă se stabilesc componentele
hardware și necesitățile sistemului din punct de vedere al
arhitecurii sistemului. Specificațile de proiectare a sistemului vor
fii folosite ca model de plecare pentru faza următoare.
 Implementare și dezvoltare
După primirea specificaților de design a
sistemului și implicit detalii despre arhitectura
acestuia, munca de implementare este împărțită
în mai multe etape și se dă drumul la programarea
propriu zisă. Cum în această etapă are loc
programarea, este o etapă ce reprezintă cea mai
importantă parte pentru programator. Această
etapă reprezintă de altfel și cea mai lungă etapă
din ciclu de viată.
 Testarea și validarea
După ce codul a fost implementat în
totalitate, produsul este testat amănunțit în
conformitate cu specificațile din prima etapă
pentru asigurarea faptului ca produsul chiar
rezolvă problemele pentru care a fost creat si
funcționează asa cum a fost stabilit cu clientul la
începutul dezvoltării. În această etapă se
realizează mai multe tipuri de teste precum:
testare unitară, acceptarea sistemului, test de
integritate, testul final de accept.
 Deployment-ul și acceptanța

În urma testării cu succes, produsul este trimis

la client unde se instalează pentru a fii folosit.
Acceptanța este faza în care clientul
recepţionează sistemul software, acceptă că
acesta corespunde cerinţelor lui şi îşi dă acordul
pentru intrarea în faza de mentenanţă. 
 Mentenanţa
După ce clientul începe folosirea propriu zisă a
produsului atunci există riscul ca anumite probleme de soft
sa apară în timp, probleme ce trebuiesc rezolvate tot de
programatorul inițial. Acest proces în care după livrare se
asigură o garanție a produsului și posibilitate de reparare
ulterioară se numește Mentenață. Intrarea în faza de
mentenanţă înseamnă încetarea includerii oricăror noi
cerinţe în sistem şi corectarea bug-urilor (anomaliilor în
funcţionare). Această fază este importantă pentru că ea
constituie adesea o fază costisitoare, dar şi prea adesea
ignorată.
 Limbajul de Modelare Unificat
• Limbajul de Modelare Unificat (UML) : limbaj de modelare orientat obiect
considerat standard de catre dezvoltatorii software din toata lumea.
• UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare
orientate obiect (Booch, OMT, and OOSE- Object-oriented software engineering)
ce au fost unificate, obtinandu-se astfel un limbaj superior, mult mai expresiv.

• UML este un limbaj de reprezentare vizuala ce poate fi utilizat pentru: modelarea

proceselor de afaceri, reprezentarea structurii unei aplicatii, descrierea arhitecturii
unui sistem, surprinderea comportamentului unui sistem, modelarea structurilor de
date sau pentru construirea unei specificatii detaliate a unui sistem.
• Reprezentarea se face utilizand elementele standard ale UML: notatiile si diagramele.
• Notatiile sunt elemente ce se regasesc in cadrul fiecarei diagrame si sunt de tipul:
conectori, simboluri, valori, etc.
• Diagramele sunt reprezentari ale unui proces, ale unui sistem sau ale partilor lor
componente.
 Diagrame definite in UML
În cadrul UML 2.2 sunt definite 14 tipuri de diagrame ce se impart in trei
categorii:
 
Diagrame de structura
•Evidentiaza componentele ce trebuie sa existe in cadrul sistemului modelat;
sunt in general folosite pentru documentarea arhitecturii sistemelor software.
Diagrame de comportament
•Evidentiaza ce trebuie sa se intample in sistemul modelat; ilustreaza
comportamentul sistemului si sunt utilizate in general pentru a descrie
functionalitatea sa.
Diagrame de interactiune
•Diagramele de interactiune reprezinta diagrame de comportament care
evidentiaza modul in care circula datele si se transfera controlul in sistemul
modelat.
 Diagrame de structura
• Diagrama de clasa: descrie structura unui sistem prin evidentierea
claselor din sistem, a atributelor lor si a relatiilor dintre clase.
• Diagrama de componente: descrie modul in care un sistem este
descompus in partile sale componente si arata dependentele dintre
acestea.
• Diagrama structurii compozite: descrie structura interna a unei
clase si colaborarile posibile datorate acestei structuri.
• Diagrama de constructie: descrie componentele hardware utilizate
in implementarea sistemului
• Diagrama de obiecte: prezinta obiectele si relatiile dintre ele;
• Diagrama de pachet: descrie modul in care un sistem este impartit
in grupuri logice aratand legaturile intre aceste grupuri;
• Diagrama de profil: opereaza la nivel de metamodel.
 Diagrame de comportament

• Diagrama de activitate: descrie succesiunea de activitati

operationale ale componentelor unui sistem;
• Diagrama de stare: descrie starile si starile de tranzitie ale
sistemului;
• Diagrama cazurilor de utilizare: descrie functionalitatea oferita de
sistem din perspectiva actorilor, a scopurilor lor lor reprezentate la si
cazuri de utilizare si a oricaror dependente dintre aceste cazuri.
 Diagrame de interactiune

• Diagrama de comunicare: arata interactiunile dintre obiecte sau

componente dpdv al mesajelor. Reprezinta o combinatie a
informatiilor preluate de la diagramele de clasa, de secventa si de
cazuri de utilizare ce descriu atat structura statica cat si pe cea
dinamica a unui sistem;
• Diagrama de interactiune de ansamblu: confera o privire de
ansamblu asupra sistemului, nodurile reprezentand diagrame de
interactiune;
• Diagrama de secventa: arata modul in care obiectele comunica
intre ele dpdv al secventierii mesajelor;
• Diagrama de incadrare in timp: un tip specific de diagrame de
interactiune in care focusul este dat de restrictiile de timp.
Diagrama cazurilor de utilizare (Use-case Diagram)
• Un use case este o reprezentare la nivel conceptual a unei interactiuni dintre un actor si un
sistem si a activitatilor care se produc si pe care sistemul le face.
• Un caz de utilizare este o secventa a tranzactiilor realizate de sistem ca raspuns la
evenimentele declansate de un actor sistemului.
• Un caz de utilizare contine toate evenimentele care pot surveni in cadrul perechii actor -
caz de utilizare, nu neaparat unul ce va apare in orice scenariu particular.
• Un caz de utilizare poate de asemenea descrie comportamentul unui set de obiecte, ca de
exemplu o organizatie.
• O diagrama use case este folosita în general pentru a indica sau caracteriza functionalitatile
si comportamentul sistemului ce interactioneaza cu unul sau mai multi actori. Un actor
poate fi un utilizator sau orice sistem ce poate interactiona cu sistemul modelat.
• Atât timp ce actorii reprezinta utilizatorii, ei ajuta la construirea unei imagini clare a ceea
ce se asteapta a se întâmpla în sistem. Cazurile de utilizare sunt construite pe baza nevoilor
pe care le au actorii (utilizatorii). Aceasta asigura faptul ca sistemul va produce ceea ce s-a
dorit.
 Diagrama cazurilor de utilizare
Element Descriere Notaţie

Un actor este, în principiu, un utilizator al sistemului, dar poate fi şi un

Actor
alt sistem informatic care interacţionează cu sistemul analizat.

Use Case-urile se reprezintă sub forma unei elipse în interiorul căreia

Use
este scris numele Use Case-ului respectiv. Numele incepe de obicei cu
Case
un verb
Asocierea este utilizată pentru a indica legătura dintre un Actor şi un
Asociere Use Case, în sensul că acel actor participă într-un fel oarecare în acel
Use Case.
 Diagrama Use case
Diagrama de tip caz de utilizare pentru extragerea de bani de la
bancomat sau cumpărarea unui produs cu card de credit

Diagrama de tip caz de utilizare cu reprezentarea tipurilor de

legături intre cazurile de utilizare
 Relaţii între use case-uri

• Relaţia de tip extensie (şi implicit use case-urile de extensie)

se folosesc atunci când se modelează un comportament
opţional sau excepţional, care nu condiţionează finalitatea use
case-ului de bază.
Ex.: un cumparator ce achizitioneaza un LCD poate să mearga la
bancul de probe pentru verificare.
• Relaţia de tip includere: se foloseşte atunci când use case-ul
inclus nu este o parte esenţială a fluxului din use case-ul de
bază sau este un comportament care se repetă în mai multe use
case-uri.
EX. Verificarea statusului unui colet si eventual schimbarea
destinatiei presupune in primul rand identificarea utilizatorului
 Diagrame de clasa
• Class diagram este un tip de diagramă utilizată pentru descrierea
structurii statice, adică a entităţilor sau claselor existente într-un
sistem.

• utilizat de către dezvoltatori pentru specificarea claselor dar poate fi

foarte util şi pentru specificarea structurii unor sisteme sau subsistem
dintr-un business real.

• arata relatiile dintre clase de tipul: mostenire, agregare si asociere,

precum si operatiile si atributele aferente fiecareia.

• Clasa are instanţe, sau realizări. Aceste instanţe sunt obiectele clasei.
Prin conceptul de clasă se descriu structura şi comportarea obiectelor
clasei. Structura conţine atributele fiecărui obiect din clasă.
 Diagrama de clasa
Element Descriere Notaţie
O clasă este reprezentată printr-un dreptunghi cu trei
compartimente: în cel de sus se trece numele clasei, în mijloc
Clasă
se trec atributele clasei iar jos se trec operaţiile specifice
clasei.

Moştenirea este o relaţie care indică faptul că o clasă

Moştenire
moşteneşte caracteristicile unei clase părinte.

Asocierea este o relaţie generică între două clase. Aceste

Asociere relaţii pot fi de tipurile unu la unu, unu la mulţi, mulţi la
mulţi.

Atunci când o clasă depinde de o altă clasă, în sensul că

Dependenţă utilizează acea clasă ca şi atribut al său, se foloseşte relaţia
de dependenţă.

Agregarea indică o relaţie de tip întreg-parte (se poate spune

Agregare despre clasa părinte că are clase de tip copil). În această
relaţie, clasa copil poate exista şi fără clasa părinte.

Această relaţie derivă din agregare dar se utilizează atunci

Compoziţie când o clasă copil nu poate exista decât în cazul existenţei
clasei părinte.
 Diagrama de clasa
• În reprezentarea clasei atributele şi operaţiile sunt declarate în
compartimentele speciale:
– atributele: numele atributului: tipul atributului = valoare
implicită
– operaţiile: numele operaţiei (parametri): tipul valorii
returnate

• se pot folosi tipurile de date specifice business-ului, ca de

exemplu: unitati monetare, unitati de timp, unitati de greutate,
etc.
Vizibilitatea: pentru a specifica vizibilitatea unui atribut sau a unei
operatiuni/metode, vom utiliza inaintea acestora urmatoarele notatii:
+ Public – orice clasa poate avea acces la informatie
# Protejat – numai clasa respectiva si succesorii sai pot accesa
informatia
- Privat – numai clasa respectiva poate avea acces la informatie.  
Moştenirea este o relaţie prin care se indică faptul că o clasă moşteneşte
caracteristicile clasei părinte. În plus, clasa copil poate avea propriile
caracteristici.
Asocierea arată existenţa unei relaţii între clase. Asocierile de tip binar
(cu doua capete) sunt reprezentate in mod obisnuit printr-o linie care
face legatura intre doua clase. Asocierile de ordin mai mare pot fi
reprezentate ca avand mai mult de doua capete.
•O asociere poate primi un nume iar capete pot avea diverse roluri, grad
de multiplicitate, vizibilitate si alte proprietati.

Ex. O universitate este condusa de un singur rector si un rector conduce

o singura universitate.

Ex. O universitate are mai multe facultati.

Exemplu: între persoană şi card bancar putem avea următoarea relaţie:
o persoană poate avea zero, unul sau mai multe carduri.
Un tip special de asociere este indicat printr-o clasă de asociere. Ca si
clasele, asocierile pot avea atribute si operatii. Pentru a arata grafic
acest lucru, o clasa de asociere se conecteaza printr-o linie intrerupta.
Altfel spus, relaţia în sine este o clasă.

Exemplu: relaţia de asociere dintre Banca si Persoana este intermediata

de existenta unui card Bancar.
• Dependenţa indică faptul că o clasă depinde de altă clasă, în sensul
în care o modificare a celei de-a doua clase produce modificari in
clasa dependenta. Verbul folosit este „a utiliza”.
Agregarea indică faptul că o clasă părinte are elemente de tipul clasei
copil. Daca in cazul asocierii utilizam verbul „a avea” pentru a exprima
legatura dintre doua clase, in cazul agregatii vom folosi verbul „a
contine”.
Exemplu: Catalogul poate avea mai multe Produse în acelaşi timp, un
Produs poate exista chiar şi daca acel catalog nu exista.

•Într-o relaţie de tip compoziţie clasa copil nu poate exista decât

dacă există o instanţă a clasei părinte. O componenta nu poate
apartine decat unui singur intreg si daca acesta dispare, in mod
automat dispare si componenta. Exemplu: instanta clasei Comisie
există atâta timp cât există instanţa clasei Examen.
Restrictii si note:
Restrictiile pot fi atasate sub forma de nota pe care o ancoram de
asocierea careia ii apartine. Restrictiiile mai pot fi atasate
caracteristicii la care fac apel.

Exercitiul 1: Sa se realizeze diagrama de clase pentru o aplicatie

ce simuleaza asignarea de proiecte in cadrul unei companii in
care avem urmatoarele clase: angajat, departament, proiect.
Avem urmatoarele doua restrictii:
– fiecare angajat poate lucra la mai multe proiecte cu
conditia ca proiectul sa apartina departamentului in care
lucreaza;
– bugetul proiectului nu trebuie sa depaseasca bugetul
departamentului.
Cum identifici componentele necesare?
•verifica specificatiile: legislatia, standardele- vor ajuta la identificarea atributelor
si restrictiilor
•identifica lucrurile tangibile: ordin, factura, card, cec, inventar
•identifica roluri: client, manager, operator calculator
•identifica actiuni: plasarea comenzii, anularea comenzii, incasarea banilor,
trimiterea comenzii
•urmareste interactiunile: dept. de vanzari primeste comenzi de la clienti,

Substantivele folosite in descriere vor indica clase, atribute si obiecte

Verbele vor conduce la operatii, metode si relatii.

Din toate clasele identificate se vor opri clasele ce reprezinta obiecte fizice,
entitati conceptuale, categorii de clase (ce vor deveni de fapt superclase) si clasele
ce reprezinta interfete cu mediul exterior sistemului considerat.

Exercitiu: Identificati clasele componente ale unui sistem de tip hotel

Fig. 1.8. Diagrama de tip clasă pentru o aplicaţie de grafică 2D
 Diagrama activitatilor
• Activity Diagram reprezintă o modalitate de modelare vizuală
a fluxurilor.

• Cu ajutorul activity diagram pot fi modelate foarte bine use

case-urile, dar, în aceeaşi măsură, aceste diagrame pot fi
folosite pentru modelarea proceselor de business (fără legătură
cu sistemul informatic).

• Notatiile sunt foarte asemănătoare cu cele din diagrama de

stare deoarece activity diagram nu sunt altceva decât o variaţie
a statechart diagram.
Element Descriere Notaţie
Prin activitate vom desemna întreaga activitate modelată
Activitate prin diagramă (formată dintr-o succesiune de acţiuni). -
Aceasta corespunde unui task de business.
Teoretic, acţiunile sunt numite activity states şi reprezintă
Acţiune o acţiuni desfăşurate în cadrul unui task, sau, privite altfel,
acţiuni ale unui obiect.
Reprezintă punctul de intrare în activitatea respectivă.
Stare iniţială Punctul iniţial este unic şi din el porneşte întotdeauna o
singură tranziţie.
Reprezintă punctul de ieşire din activitate. Pot fi mai
Stare finală
multe puncte de ieşire dintr-o activitate.
La încheierea unei acţiuni se trece întotdeauna la o altă
Tranziţie acţiune sau la starea finală. Tranziţia reprezintă trecerea
de la o acţiune la alta.
Printr-o decizie (sau punct de decizie) se modelează un
punct din cadrul fluxului unde se face o alegere, pe o
anumită ramură din flux. În acest caz tranzacţiile de ieşire
Decizie
trebuie să fie de tip condiţie. Aceeaşi notaţie se foloseşte
şi pentru reunirea fluxurilor după o decizie precedentă
(caz în care nu mai sunt necesare condiţiile).
Este un tip special de tranziţie, utilizată la fiecare dintre
Condiţie ieşirile posibile dintr-o decizie. Se marchează ca un text
(guard) pe săgeată şi arată condiţia care trebuie îndeplinită pentru
a urma acel flux.
Este folosită pentru cazurile în care anumite acţiuni se pot
desfăşura în paralel. Într-un asemenea punct poate avea
loc fie separarea fluxurilor, fie reunirea lor, după o
Bara de separare anterioară. Reunirea a două fluxuri înseamnă, de
sincronizare fapt, introducerea unei condiţii, prin care o activitate nu
poate începe decât după terminarea activităţilor finale din
fluxurile ce trebuie sincronizate (de aici termenul de
sincronizare).

Culoarele sunt reprezentări care permit separarea

Culoar
activităţilor din flux după criteriul responsabilităţii
(swimlane)
realizării activităţii.
• Punctele de decizie sunt puncte din fluxul de activităţi în care se
face o anumită alegere între mai multe variante posibile.
• Acţiunile paralele (asincrone) sunt acţiuni care pot desfăşura în
paralel. În viaţa reală, aceste acţiuni sunt acţiuni care nu depind una
de cealaltă. Paralelizarea acţiunilor se reprezintă pe diagramă în felul
următor:
• Această reprezentare ne arată că acţiunile „Verificare stoc” şi
„Verificare bonitate client” sunt declanşate de apariţia unei comenzi
de la client şi că aceste acţiuni sunt independenta între ele (începerea
uneia nu depinde de rezultatul celeilalte).
• Revenirea la fluxul unic (cu acţiuni sincronizate) se face în felul
următor:

• Această reprezentare ne arată că livrarea la client depinde de

finalizarea acţiunilor independente "Verificare stoc" şi
"Verificare bonitate client", astfel că acţiunea "Livrare la
client" nu poate începe decât după finalizarea ambelor acţiuni.
• Pentru a adăuga pe diagrame informaţia privind responsabilitatea
executării acţiunilor se folosesc elementele denumite swimlanes,
plasându-se fiecare acţiune pe "culoarul" actorului care execută acea
acţiune.
 Diagrama de stare
Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stări prin care
poate trece un obiect şi modul în care se poate trece de la o stare la alta (modelare
work-flow-uri, modelare fluxuri de documente, diagrame de stări).
O stare reprezinta o etapa din comportamentul unui obiect; astfel, putem avea stari
initiale si stari finale.
– Starea initiala: cea in care se regaseste obiectul atunci cand a fost creat pentru
prima data;
– Starea finala: nu mai trece prin nicio tranzitie.

Trecerea de la o stare la alta este determinată de tranzacţiile intermediare - acestea

corespund Acţiunilor pe care le-am întâlnit la Activity Diagram (până la urmă,
Statechart Diagram reprezintă un alt mod de a vedea un flux ce poate fi modelat
exclusiv prin Activity Diagram, inventată pentru a exprima mai elocvent trecerile de
la o stare la alta).

Exemplu o comandă primită de la un client poate fi iniţial în stare de aşteptare,

pentru ca un operator să verifice bonitatea clientului şi stocul şi să accepte comanda.
După acceptare, se poate produce livrarea produselor comandate şi comanda trece în
starea de „comandă livrată” după care urmează facturarea şi închiderea comenzii.
 Diagrama de stare
Element Descriere Notaţie

Stare Indică starea în care se găseşte obiectul la un moment dat.

Stare Reprezintă punctul de intrare sau punctul în care obiectul

iniţială este iniţiat. Punctul iniţial este unic.
Stare Reprezintă punctul de final când starea obiectului nu se mai
finală modifică.
Tranziţia reprezintă trecerea de la o stare la alta, provocată
Tranziţie
de apariţia unui anumit eveniment.
Exemplu de folosire a
elementelor specifice
statechart diagram,
pentru cazul unei
comenzi: