Inginerie Software

Curs 3

Introducere în UML

1. Apariţie şi evoluţie

UML este un limbaj vizual de modelare. El nu este un limbaj de programare deoarece nu

dispune de întreg sprijinul semantic pentru a înlocui acest tip de limbaje. UML este destinat
vizualizării, specificării, construirii şi documentării sistemelor de aplicaţii, dar are limitări în
ceea ce priveşte generarea codului. Limbajul reuneşte cele mai bune tehnici şi practici din
domeniul ingineriei software, care şi-au dovedit eficienţa în construirea unor sisteme complexe.
 În octombrie 1994, Grady Booch, lider ştiinţific la Rational Corporation, autor al
metodei ce-i poartă numele şi al unor cărţi de referintă în domeniu face echipă cu
James Rumbaugh, autorul principal al metodei OMT, pe care-l determină să-şi
părăsească (cel puţin temporar) vechiul loc de muncă (General Electric) şi să treacă la
firma Rational. După un an de activitate, Booch şi Rumbaugh prezintă în octombrie
1995 cu ocazia conferinţei OOPSLA, caracteristicile de bază ale unei noi metode de
analiză şi proiectare, rezultată prin unificarea Metodei lui Booch (OOD) cu OMT,
metodă denumită Metoda unificată (Unified Method). Prima documentaţie a metodei
menţionată anterior a fost făcută publică în decembrie 1995, având numărul de
versiune 0.8. La sfârşitul aceluiaşi an celor doi li se alătură şi Ivar Jacobson.
 În luna iunie 1996 apare versiunea 0.9, urmată la scurt timp, în luna octombrie din
acelaşi an, de apariţia versiunii 0.91. Versiunea 0.9 aduce şi schimbarea denumirii din
Metoda unificată (Unified Method) în Limbaj unificat de modelare (Unified
Modeling Language). Cooptarea lui Jacobson în echipă se concretizează printre altele
în detalierea conceptului de cazuri de utilizare (use case) şi prezentarea unei descrieri
mai amănunţite pentru diagramele cazurilor de utilizare. Conceptul de stereotip este
mai bine explicat, se modifică denumirile unor diagrame.
 La data de 11 ianuarie 1997 este prezentată versiunea 1.0 care, însoţită de o
documentaţie mult mai detaliată decât la versiunile precedente, este trimisă către
OMG pentru standardizare.
 1 septembrie 1997 a reprezentat un alt moment deosebit de important în istoria
evoluţiei limbajului UML. Rational şi alte firme care sprijină UML, printre care şi doi
fosti competitori, IBM/ObjectTime şi Taskon/Reich, a propus OMG o nouă versiune
1.1. Noutatea semnificativă pentru această versiune o reprezintă introducerea
limbajului OCL, un limbaj folosit pentru descrierea regulilor de corectitudine ale
metamodelului UML.
1
Inginerie Software

 La 17 noiembrie 1997, OMG a anuntat adoptarea specificaţiei UML ca limbaj

standard de modelare.
Schimbarea denumirii din Metoda Unificată în Limbaj de Modelare Unificat a fost
justificată prin:
 reacţiile primite din partea utilizatorilor care au sugerat că este mult mai important să
se acorde o atenţie sporită conceptelor utilizate în dezvoltarea aplicaţiilor.
Recomandările referitoare la desfăşurarea etapelor de realizare şi înlănţuirea lor au
fost lăsate în planul secund;
 faptul că eforturile de unificare au fost concentrate asupra limbajului grafic de
modelare, asupra semanticii lui şi abia după aceea asupra modului de utilizare a
conceptelor;
 UML a fost conceput ca un limbaj universal care să fie utilizat la modelarea
sistemelor (indiferent de tipul şi scopul pentru care au fost construite), la fel cum
limbajele de programare sunt folosite în diverse domenii.
Sublinierea aspectelor de limbaj nu semnifică nicidecum ignorarea modului de folosire a
lor. UML presupune că metodologia este “ghidată” de cazurile de utilizare, că ea se bazează pe
arhitectura sistemului, iar procesul de aplicare a metodologiei este iterativ şi incremental.
Detaliile acestui proces trebuie adaptate la domeniul aplicaţiei, la modul de organizare al echipei
de realizatori, la experienţa echipei. UML nu tratează aspecte de metodologie, permitând astfel
separarea limbajului de modelare de procesul aplicării metodologiei.

2. Principalele părţi ale UML

Principalele părţi ale UML sunt:

 Vederile (View) – surprind aspecte particulare ale sistemului de modelat. Un view
este o abstractizare a sistemului, iar pentru construirea lui se folosesc un număr de
diagrame.
 Diagramele – sunt grafuri ce descriu conţinutul unui view. UML are nouă tipuri de
diagrame, ce pot fi combinate pentru a forma toate view-urile sistemului.
 Elementele de modelare – sunt conceptele folosite în diagrame care au
corespondenţă în programarea orientată-obiect, cum ar fi clase, obiecte, mesaje şi relaţii
între acestea precum asocierea, dependenţa şi generalizarea. Un element de modelare
poate fi folosit în mai multe diagrame diferite şi va avea acelaşi înţeles şi acelaşi mod de
reprezentare.
 Mecanismele generale – permit introducerea de comentarii şi alte informaţii despre
un anumit element.

2
Inginerie Software

2.1 View-uri

Modelarea unui sistem poate fi o muncă foarte dificilă. Ideal ar fi ca pentru descrierea
sistemului să se folosească un singur graf, însă de cele mai multe ori acesta nu poate să surprindă
toate informaţiile necesare descrierii sistemului. Un sistem poate fi descris luând în considerare
diferite aspecte:
 Funcţional: este descrisă structura statică şi comportamentul dinamic al sistemului;
 Non-funcţional: necesarul de timp pentru dezvoltarea sistemului;
 Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod.
Aşadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare
reprezentând o proiecţie a descrierii întregului sistem şi care reflectă un anumuit aspect al său.
Fiecare view este descris folosind un număr de diagrame ce conţin informaţii relative la
un anumit aspect particular al sistemului. Aceste view-uri se acoperă unele pe altele, deci este
posibil ca o anumită diagramă să facă parte din mai multe view-uri.

View-ul View-ul
Componentelor Logic
nt View-ul
Cazurilor
de Utilizare
View-ul View-ul
de de concurenţă
desfaşurare

Figura 1: View-urile din UML

View-ul cazurilor de utilizare (Use-case View)

Acest view surprinde funcţionalitatea sistemului, aşa cum este ea percepută de actorii
externi care interacţionează cu sistemul - de exemplu utilizatorii acestuia sau alte sisteme. În
componenţa lui intră diagrame ale cazurilor de utilizare şi ocazional, diagrame de activitate.
Cei interesaţi de acest view sunt deopotrivă clienţii, designerii, dezvoltatorii dar şi cei
care vor realiza testarea şi validarea sistemului.

View-ul logic (Logic View)

Spre deosebire de view-ul cazurilor de utilizare, un view logic “priveşte” înăuntrul

sistemului şi descrie atât structura internă a acestuia (clase, obiecte şi relaţii) cât şi colaborările
ce apar când obiectele trimit unul altuia mesaje pentru a realiza funcţionalitatea dorită.
Structura statică este descrisă prin diagrame de clasă, în timp ce pentru modelarea
dinamicii sistemului se vor folosi diagramele de stare, de secvenţă, de colaborare sau de
activitate. Prin urmare, cei care sunt interesaţi de acest tip de vizualizare a sistemului sunt
proiectanţii şi dezvoltatorii.

3
Inginerie Software

View-ul componentelor (Component View)

Componentele sunt module de cod de diferite tipuri. În funcţie de conţinutul lor acestea pot
fi: componente ce conţin cod sursă, componente binare sau executabile.
View-ul componentelor are rolul de a descrie componentele implementate de sistem şi
dependenţele ce există între ele, precum şi resursele alocate acestora şi eventual alte informaţii
administrative, cum ar fi, de exemplu, un desfăşurător al muncii de dezvoltare. Este folosit în
special de dezvoltatorii sistemului, iar în componenţa sa intră diagrame ale componentelor.

View-ul de concurenţă (Concurent View)

Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect,
care este unul nonfuncţional, este util pentru o gestionare eficientă a resurselor, execuţii paralele
şi tratări asincrone ale unor evenimente din sistem, precum şi pentru rezolvarea unor probleme
legate de comunicarea şi sincronizarea thread-urilor.
Cei care sunt interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şi
integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secvenţă,
colaborare şi activitate) precum şi diagrame de implementare (ale componentelor sau de
desfăşurare).

View-ul de desfăşurare (Deployment View)

Desfăşurarea fizică a sistemului, ce calculatoare şi ce echipamente (numite şi noduri) vor
fi folosite pentru realizarea efectivă a implementării, cum sunt acestea conectate, precum şi ce
componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe
fiecare calculator), toate sunt surprinse în view-ul de desfăşurare.
Aceast tip de vizualizare a sistemului prezintă interes pentru dezvoltatori, integratorii de
sistem şi cei care realizează testarea sistemului, pentru construirea view-ului fiind folosită
diagrama de desfăşurare.

2.2 Diagrame

Diagramele sunt grafuri ce prezintă simboluri ale elementelor de modelare (model

element) aranjate astfel încât să ilustreze o anumită parte sau un anumit aspect al sistemului. Un
model are de obicei mai multe diagrame de acelaşi tip. O diagramă este o parte a unui view
specific, dar există posibilitatea ca o diagramă să facă parte din mai multe view-uri, în funcţie de
conţinutul ei. În UML sunt nouă tipuri de diagrame pe care le vom prezenta în cele ce urmează.

Diagrama cazurilor de utilizare (Use Case Diagram)

Un caz de utilizare este o descriere a unei funcţionalităţi (o utilizare specifică a
sistemului) pe care o oferă sistemul. Diagrama prezintă actorii externi şi cazurile de utilizare
identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, aşa
cum este el perceput de utilizatorii lui) nu şi din interior, precum şi conexiunile identificate între

4
Inginerie Software

actori şi cazurile de utilizare. Un exemplu de diagramă a cazurilor de utilizare este prezentată în

figura 2.

Semnarea unei
poliţe de asigurare

Client
Situaţia Societate
vânzărilor de asigurări

Situaţia
clienţilor

Figura 2: O diagramă a cazurilor de utilizare dintr-un sistem de asigurări.

Diagrama claselor (Class Diagram)

O diagramă a claselor prezintă structura fizică a claselor identificate în sistem. Clasele
reprezintă “lucruri” gestionate de sistem; clasele pot fi legate în mai multe moduri: asociate
(conectate între ele), dependente (o clasă depinde/foloseşte o altă clasă), specializate (o clasă este
specializarea altei clase) sau împachetate (grupate împreună în cadrul unei unităţi). Toate aceste
relaţii se materializează în structura internă a claselor prin atribute şi operaţii.
Diagrama este considerată statică, în sensul că este validă în orice moment din ciclul de
viaţă al sistemului. Un exemplu de diagramă a claselor este prezentat în figura 3.

Poliţa de
asigurare

0..1

exprimă este exprimat prin

1
1 are 0..* Contract de
Companie
asigurare
de asigurări aparţine

0..*
refera are

1..*
Persoana

Figura 3: O diagramă a claselor pentru un sistem de asigurări.

Diagrama obiectelor (Object Diagram)

Acest tip de diagramă este o variantă al diagramei claselor care, în locul unei clase,
prezintă mai multe instanţe ale acesteia. Diagrama obiectelor foloseşte aproape aceleaşi notaţii ca

5
Inginerie Software

şi diagrama claselor cu două mici diferenţe: obiectele sunt scrise subliniat şi sunt vizualizate
toate instanţele relaţiei (vezi figura 4).
Deşi nu este la fel de importantă ca diagrama claselor, diagrama obiectelor este folosită
pentru exemplificarea unei diagrame a claselor de complexitate mare, permiţând vizualizari ale
instanţelor actuale şi a relaţiilor exact aşa cum sunt ele realizate. Mai poate fi folosită ca o parte a
diagramelor de colaborare, în care sunt vizualizate colaborările dinamice existente în cadrul unei
mulţimi de obiecte.

Calculator
Angajat
foloseşte
nume:String Diagrama claselor
nume:String
varsta:Integer
0..1 1..* memorie:Integer

PCServici : Calculator
nume=”Dell 466”
Popescu : Angajat memorie=64
nume=”Popescu Ion” Diagrama obiectelor
varsta=30

PCAcasa : Calculator
nume=”Compaq Pentium
MMX”
memorie=32

Figura 4: O diagramă a claselor şi o diagramă a obiectelor (instanţele claselor).

Diagrama de stare (State Diagram)

O stare este de obicei complementară descrierii unei clase. O diagramă de stare prezintă
toate stările prin care trece un obiect al clasei precum şi evenimentele care-i cauzează
modificările de stare. Modificarea stării se numeşte tranziţie. Un exemplu de diagramă de stare
este prezentat în figura 5.

urca (etaj) Mută sus

La parter
do/ schimbă nivelul

soseşte la parter

urcă (etaj)
Mută la
parter soseşte

Staţionează
Mută jos timp=0
soseţte
do/creşte timp
do/ schimba nivelul

Time-out

Figura 5: O diagramă de stare pentru un ascensor

6
Inginerie Software

Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea
care au un număr de stări bine definit iar comportamentul clasei este afectat şi modificat de
acestea.

Diagrama de secvenţă (Sequence Diagram)

O diagramă de secvenţă prezintă colaborarea dinamică între un număr de obiecte (vezi
figura 6), mai precis secvenţele de mesaje trimise între acestea pe măsura trecerii timpului.
Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul este reprezentat
pe axa verticală de sus în jos. Mesajele sunt reprezentate prin săgeţi între liniile verticale ce
corespund obiectelor implicate în mesaj.

:Calculator :Server de imprimantă :Imprimantă :Coadă

Print (fisier) [imprimanta liberă]

Print (fişier)

[imprimanta ocupată]
Stochează (fişier)

Figura 6: Diagrama de secvenţă pentru un server de imprimantă

Diagrama de colaborare (Collaboration Diagram)

Această diagramă surprinde colaborarea dinamică între obiecte, într-o manieră similară cu
a diagramei de secvenţă, dar pe lângă schimbul de mesaje (numit şi interacţiune) prezintă
obiectele şi relaţiile dintre ele (câteodată referite ca şi context).
Desenarea unei diagrame de colaborare se face asemănător cu a unei diagrame a obiectelor.
Mesajele vor fi reprezentate prin săgeţi între obiectele implicate în mesaj şi pot fi însoţite de
etichete ce specifică ordinea în care acestea vor fi transmise. De asemenea se pot vizualiza
condiţii, iteraţii, valori returnate, precum şi obiectele active care se execută concurent cu alte
obiecte active (vezi figura 7).

:Calculator [imprimanta ocupată] :Coada de aşteptare

1.2: Stochează(fişier)

1: Print (fisier)

[imprimanta liberă]
1.1: Print(fişier)
:ServerImprimantă :Imprimantă

Figura 7: O diagramă de colaborare pentru un server de imprimantă.

7
Inginerie Software

Cum decidem ce tip de diagramă să folosim? Dacă cel mai important aspect este timpul
sau secvenţa de mesaje vom folosi diagrama de secvenţă, dar dacă trebuie scos în evidenţă
contextul, vom apela la o diagramă de colaborare.

Diagrama de activitate (Activity Diagram)

O diagramă de activitate prezintă fluxul secvenţelor de activităţi, ca în figura 8, şi este de
obicei folosită pentru a descrie activităţile realizate în cadrul unei operaţii, folosind, dacă este
cazul, decizii şi condiţii. Diagrama conţine stări de acţiune (action states), şi mesaje ce vor fi
trimise sau recepţionate ca parte a acţiunii realizate.
Afişează mesajul
[disc full] “Disc Full”
[Link]() Afişează pe ecran pe ecran
fereastra de mesaj
“Printing”

Afişeaza mesajul
[spaţiu liber pe disc] “Printing”
pe ecran

Şterge ^[Link](fisier) Creaza

fereastra de fişierul
mesaj postscript

Figura 8: O diagramă de activitate pentru un server de imprimantă.

Diagrama componentelor (Component Diagram)

O diagramă a componentelor prezintă structura fizică a codului în termenii
componentelor de cod, realizând o mapare de la view-ul logic la view-ul componentelor. O
componentă poate să conţină un cod sursă sau poate să fie într-o forma binară sau executabilă. În
cadrul diagramei vor fi ilustrate şi dependenţele dintre componente, ceea ce permite o vizualizare
simplă a componentelor ce vor fi afectate de modificarea uneia dintre ele.

Window
Hander
([Link])
Window Graphic
Hander Lib
([Link]) ([Link]

Command
Hander Command
([Link]
Hander Program
([Link] Client
([Link])

Main Main
Class Class
([Link]) ([Link])

Figura 9: O diagramă a componentelor

8
Inginerie Software

Diagrama de desfăşurare (Deployment View)

Arhitectura fizică pe care va fi implementat sistemul, calculatoarele, device-urile (referite
ca noduri ale sistemului), împreună cu conexiunile dintre acestea, vor putea fi prezentate în
cadrul unei diagrame de desfăşurare. Componentele şi obiectele executabile sunt alocate în
interiorul nodurilor, ceea ce ne va permite o vizualizare a unităţilor ce se vor executa pe fiecare
nod.

Client A: <<TCP/IP>>
Compaq
Pro PC
<<Net 8>>
Application Database
<<TCP/IP>> Server: Server:
Silicon Oracle
Graphics O2

Client B:
Compaq
Pro PC

Figura 10: O diagramă de desfăşurare ce prezintă structura fizică a sistemului.

9
Inginerie Software

Modelarea cu UML

1. Elemente de modelare

Conceptele utilizate în cadrul diagramelor se numesc elemente de modelare. Un element

de modelare are o semantică (o definiţie formală a elementului sau un înţeles exact a ceea ce
reprezintă el într-un anumit context), şi o reprezentare grafică sau un simbol grafic prin
intermediul căruia se reprezintă în cadrul diagramelor.

Un element poate fi regăsit în mai multe tipuri de diagrame, şi pentru fiecare context
există propriile reguli. În figura 11 sunt prezentate câteva exemple de elemente de modelare
împreună cu modul lor de reprezentare.

Clasă Obiect
Stare
Atribute Atribute

Operaţii Operaţii

Caz de Interfaţă
utilizare
Nod

Pachet Nota Componentă

Figura 11: Exemple de elemente de modelare

2. Modelarea cu UML

A modela cu UML înseamnă a construi mai multe modele pentru diferitele faze ale
dezvoltării cât şi pentru diverse scopuri.
În faza de analiză, scopul modelării se referă la a surprindere necesităţile sistemului şi să
modeleze clasele de bază din “lumea reală” precum şi colaborările existente între acestea.
În faza de design, este detaliat modelul din faza de analiză şi este formulată o soluţie
tehnică luându-se în considerare caracteristicile mediului în care acesta va fi reprezentat.

10
Inginerie Software

În faza de implementare, modelul este transpus în cod sursă şi apoi este compilat într-un
program, pentru ca în final, în modelul de desfăşurare, să se utilizeze o descriere care să explice
modalitatea prin care sistemul va fi adaptat arhitecturii fizice concrete.

Model
Sistem
Modelul de Modelul Modelul de Modelul de
Analiză Design Implementare Desfăşurare

Figura 12: Un sistem este descris folosind mai multe modele.

Toate modelele construite de-a lungul procesului de modelare vor fi salvate, fiind uşor
astfel să se revină în orice moment asupra unuia dintre ele, în vederea extinderii analizei
modelului iniţial prin rafinări succesive, sau să se introducă, treptat, modificări în modelele de
design sau de implementare.
UML este o un limbaj independent de fază, ceea ce înseamnă că acelaşi limbaj generic şi
aceleaşi diagrame pot fi folosite pentru modelarea lucrurilor distincte în faze de modelare
diferite. Limbajul de modelare furnizează numai posibilitatea de a crea modele într-o manieră
expresivă şi consistentă.
În mod normal, în momentul în care construim un model sau o simplă diagramă vom
începe prin a colecta informaţii de la clienţi sau de la potenţialii utilizatori ai sistemului. Această
fază continuă până în momentul în care participanţii nu mai au de făcut adaugări sau sugestii
modelului de bază. Modelul este transpus apoi în diagrame conform regulilor impuse de limbajul
de modelare, după care urmează un proces iterativ şi incremental, pe parcursul căruia sunt
adăugate noi detalii soluţiei şi este realizată o documentare a modelului. În final, modelul este
verificat, evaluat şi sunt corectate eventualele deficienţe înregistrate în funcţionalitatea lui, de
exemplu lipsuri în funcţionalitate, performanţă scăzută, preţ ridicat de dezvoltare etc., toate
acestea presupunând reluarea paşilor ce cauzează aceste carenţe şi găsirea unor soluţii
satisfăcătoare.

11
Inginerie Software

3. Modelarea cazurilor de utilizare (Use Case Modeling)

Un caz de utilizare reprezintă o tehnică de modelare folosită pentru a descrie ce va face un

sistem nou sau ce face un sistem deja existent. Modelarea cazurilor de utilizare a fost folosită
pentru prima dată de Ivar Jacobson în cadrul metodelor de modelare OOSE şi Objectory. Scopul
urmărit în acest tip de modelare este descrierea funcţionalităţii sistemului aşa cum este aceasta
văzută din exterior de un număr de actori şi a conexiunilor acestora la cazurile de utilizare
furnizate de sistem. Aşadar, pentru crearea modelului cazurilor de utilizare vor trebui identificaţi
actorii, cazurile de utilizare, relaţiile dintre acestea cât şi relaţiile cu actorii. Toate aceste faze
presupun realizarea unor discuţii cu clienţii şi, eventual, cu persoanele care reprezintă actorii.
În această fază de modelare sistemul este văzut ca o “cutie neagră”, ce trebuie să poată
realiza anumite sarcini, fără a ne interesa cum le face, cum vor fi implementate, sau cum lucrează
intern. Scopul principal al construirii acestui tip de diagramă este:
 Să decidă şi să descrie cerinţele funcţionale ale sistemului, cerinţe ce au fost deduse
după o discuţie între client şi/sau utilizatorii sistemului şi viitorii dezvoltatori ai acestuia.
 Să ofere o descriere clară şi consistentă a ceea ce va trebui să facă sistemul (prin
urmare, modelul este folosit pentru comunicarea cerinţelor tuturor persoanelor implicate în
construirea sistemului) şi să constituie un punct de plecare în realizarea muncii viitoare
(alte modele, design arhitectural, implementarea propriu-zisă).
 Să constituie o bază pentru realizarea testelor de verificare dacă funcţionalitatea finală
a sistemului concordă cu cerinţele iniţiale ale acestuia.
 Să permită o transformare uşoară a cerinţelor funcţionale în viitoare clase şi operaţii.

2.1 Diagrama cazurilor de utilizare (Use Case Diagram)

Un model use case (caz de utilizare) este descris folosind una sau mai multe diagrame use
case. Acestea pot să conţină următoarele elemente de modelare: actori, cazuri de utilizare şi
diferite relaţii între aceste elemente (generalizare, asociere, dependenţă).

Actorul

Un actor poate fi orice sau oricine interacţionează cu sistemul, adică trimite sau
recepţionează mesaje de la sistem sau schimbă informaţii cu acesta. Actorul joacă un rol în
cadrul sistemului, nefiind un utilizator individual al acestuia - prin urmare reprezintă un tip (o
clasă) nu o instanţă. În descrierea “Studentul Popescu vrea să împrumute o carte de la
bibliotecă”, rolul persoanei este de abonat al bibliotecii. Orice mesaj trimis de către actor
sistemului reprezintă un caz de utilizare, câteodată numit şi stimul.
Un actor poate fi:
 Actor primar, dacă foloseşte funcţionalitatea de bază a sistemului - de exemplu într-un
sistem de gestiune a unei biblioteci, bibliotecarul.
12
Inginerie Software

 Actor secundar, dacă foloseşte o funcţionalitate secundară - cum ar fi gestionarea unei

baze de date, comunicare, backup şi alte operaţii administrative.
O altă clasificare ce se poate realiza constă din:
 Actor activ – cel care iniţiază cazurile de utilizare,
 Actor pasiv – cel care participă numai, în unul sau mai multe cazuri de utilizare.

Identificarea actorilor

Operaţia de identificare a actorilor revine la a stabili care sunt entităţile interesate de

utilizarea sistemului sau de interacţiunea cu acesta. Pentru acest scop putem să ne folosim de
următoarele întrebări:
 Cine va folosi funcţionalitatea principală a sistemului? Aceştia vor fi actorii principali.
 Cine va avea nevoie de sistem în munca de zi cu zi?
 Cine va administra şi păstra în stare de funcţionare sistemul? Aceştia vor fi actorii
secundari.
 Ce dispozitive (device-uri) hardware vor avea nevoie de sistem?
 Cu ce alte sisteme va interacţiona? Acestea pot fi împărţite în sisteme (sisteme de
calculatoare, aplicaţii) ce vor iniţia un contact cu sistemul ;i sistemele pe care acesta le va
contacta.
 Cine este interesat de rezultatele (valorile) generate de sistem?
Modul de reprezentare al actorilor în cadrul diagramelor de modelare UML este prezentat
în Figura 13.
<<Actor>>
Abonat

Bibliotecar

Figura 13: Reprezentarea actorilor în UML.

2.2 Cazuri de utilizare

Un caz de utilizare reprezintă o funcţionalitate completă a sistemului, aşa cum este ea
percepută de un actor. În UML acesta este definit ca “o mulţime de secvenţe de acţiuni pe care
sistemul le realizează în vederea furnizării unei valori către un actor particular”. Acţiunile pot
presupune comunicarea cu un număr de actori (utilizatori sau alte sisteme) sau realizarea unor
calcule în interiorul sistemului.
Caracteristicile cazurilor de utilizare sunt:
 Un caz de utilizare este iniţiat întotdeauna de un actor - actorul trebuie să ceară direct
sau indirect sistemului realizarea unui caz de utilizare.
 Un caz de utilizare furnizează o valoare unui actor.
 Un caz de utilizare trebuie să fie complet. O greşeală frecvent întâlnită este să împărţim
un caz de utilizare în altele mai mici şi să le implementăm ca apeluri de funcţii într-un

13
Inginerie Software

limbaj de programare. Un caz de utilizare nu este complet până când nu se obţine valoarea
finală, chiar dacă pentru realizarea acestui lucru sunt necesare câteva dialoguri.
Un caz de utilizare este o clasă şi nu o instanţă a acesteia. Clasa descrie funcţionalitatea ca
un întreg, incluzând alternative posibile, erori şi excepţii ce pot să apară pe parcursul execuţiei.
O instanţiere a unui caz de utilizare se numeşte scenariu şi reprezintă o utilizare actuală a
sistemului, de exemplu “Studentul Popescu cere bibliotecarului să îi facă o rezervare pentru
cartea de programare care în momentul respectiv nu este disponibilă”.
Cazurile de utilizare sunt conectate cu actorii prin asocieri, numite şi asocieri de
comunicare. În mod normal acestea sunt relaţii unu-la-unu nedirecţionate ceea ce înseamnă că o
instanţă actor comunică cu o instanţă a cazului de utilizare şi că această comunicare se realizează
în ambele sensuri.

Identificarea cazurilor de utilizare

Procesul de identificare a cazurilor de utilizare începe de la actorii deja identificaţi. Pentru

fiecare actor se vor pune următoarele întrebări:
 Care sunt funcţiile pe care actorul le aşteaptă de la sistem? Ce trebuie să poată face
actorul?
 Are nevoie actorul să citească, să creeze, să modifice, să distrugă sau să păstreze
anumite tipuri de informaţii în sistem?
 Trebuie să ştie actorul de apariţia unui anumit eveniment în sistem? Ce funcţionalitate
reprezintă aceste evenimente?
 Poate actorul să-şi simplifice munca de zi cu zi sau să lucreze mai eficient folosind
funcţii noi ale sistemului?
Alte întrebări care nu presupun un actor curent:
 Ce intrări/ieşiri sunt necesare în sistem? De unde vin acestea şi unde merg?
 Care sunt problemele majore în implementarea curentă a acestui sistem? Poate fi
înlocuit un sistem manual cu unul automat?

Nume sistem
Use Case
A
Nume Actor
Asociere de
comunicare Use Case
B
Nume
Use Case
Use Case
C

Figura 14: Reprezentarea cazurilor de utilizare

3.3 Relaţii între cazurile de utilizare

Există cinci tipuri de relații într-o diagramă a cazurilor de utilizare. Acestea sunt:

14
Inginerie Software

1. relaţia de asociere între un actor și un caz de utilizare;

2. relaţia de generalizare a unui actor;
3. relaţia de extindere între două cazuri de utilizare;
4. relaţia de includere dintre două cazuri de utilizare;
5. relatia de generalizare a unui caz de utilizare.

Relaţia de asociere între un actor și un caz de utilizare

Acestă relaţie este prezentă în fiecare diagramă a cazurilor de utilizare.

 Un actor trebuie să fie asociat cu cel puțin un caz de utilizare.
 Un actor poate fi asociat cu mai multe cazuri de utilizare.
 Mai mulți actori pot fi asociați cu un singur caz de utilizare.

Figura 15: Relaţia de asociere actor – caz de utilizare

Relaţia de generalizare a unui actor

Relaţia de generalizare a unui actor înseamnă că un actor poate moșteni rolul altui actor.
Descendentul moștenește toate cazurile de utilizare ale strămoșului său. Descendentul are unul
sau mai multe cazuri de utilizare specifice acestui rol.
În exemplul următor diagrama de cazuri de utilizare anterioară este extinsă pentru a
conţine relaţia de generalizare a unui actor.

Figura 16: Relaţia de generalizare a unui actor.

15
Inginerie Software

Relaţia de includere între două cazuri de utilizare

Relația de includere presupune că comportamentul cazului de utilizare inclus este parte a

cazului de utilizare de bază (cel ce include). Motivul principal al folosirii relaţiei de includere
este dat de reutilizarea acțiunilor comune în mai multe cazuri de utilizare. În unele situații, relaţia
este folosită pentru a simplifica comportamentele complexe.
 Cazul de utilizare de bază este incomplet fără cazul de utilizare inclus.
 Cazul de utilizare inclus este obligatoriu și nu este opțional.

Figura 17: Relaţia de includere între două cazuri de utilizare

Semnarea politei de asigurare

<<include>> <<include>>

Semnarea asigurarii Semnarea asigurarii

de viata pentru masina

Figura 18: Relaţia de includere – exemplul al doilea.

Relaţia de extindere între două cazuri de utilizare

Multe persoane confundă relația de extindere pentru cazurile de utilizare. După cum îi
spune şi numele, relaţia extinde cazul de utilizare de bază și adaugă mai multe funcționalități
sistemului.
 Cazul de utilizare extins depinde de cazul de utilizare de bază. În diagrama din figură,
cazul de utilizare „Calculate bonus” nu are sens fără cazul de utilizare „Deposit funds”.
 Cazul de utilizare extins este, de obicei, opțional și poate fi declanșat în mod condiționat.
În diagramă, puteți vedea că cazul de utilizare extins este declanșat numai pentru
depozitele peste 10.000 de unităţi sau când vârsta depășește 55 de ani.

16
Inginerie Software

 Cazul de utilizare de bază trebuie să aibă sens atunci când este singur. Aceasta înseamnă
că ar trebui să fie independent și nu trebuie să se bazeze pe comportamentul cazului de
utilizare extins.
Deși extinderea unui caz de utilizare este opțională, de cele mai multe ori nu este obligatoriu.
Un caz de utilizare extins poate avea și un comportament non-opțional. Acest lucru poate fi
întâlnit mai ales atunci când se modelează comportamente complexe.

Figura 19: Relaţia de extindere între două cazuri de utilizare

Relaţia de generalizare a unui caz de utilizare

Această relaţie este similară cu relaţia de generalizare a unui actor. Comportamentul

strămoșului este moștenit de către descendent. Relaţia este utilizată atunci când există un
comportament comun între două cazuri de utilizare și, de asemenea, un comportament specializat
specific fiecărui caz de utilizare.
În exemplul anterior, ar putea exista un caz de utilizare numit „Pay Bills”. Acest lucru
poate fi generalizat la „Pay by Credit Card”, „Pay by Bank Balance” etc.
Dacă mai multe cazuri de utilizare gestionează funcţiuni similare sau sunt într-un fel
legate unul de altul, acestea pot fi grupate în pachete UML. Pachetele nu au un înţeles semantic.

3.4 Descrierea cazurilor de utilizare

Descrierea cazurilor de utilizare se face de obicei printr-un text ce conţine o specificare
simplă dar consistentă a modului de interacţiune între actori şi cazurile de utilizare ale
sistemului. Descrierea va surprinde comportamentul sistemului şi va ignora modul în care acesta
va fi implementat în sistem.
Descrierea va conţine:
 Obiectivele cazurilor de utilizare.
 Modalitatea de iniţiere a unui caz de utilizare; ce actori iniţiază execuţia şi în ce situaţii.
 Fluxul de mesaje între actori şi cazurile de utilizare.
 Fluxul alternativ pentru cazurile de utilizare - un caz de utilizare poate să aibă o
execuţie alternativă în funcţie de anumite condiţii sau excepţii.

17
Inginerie Software

 Momentul în care un caz de utilizare este considerat terminat, şi care va fi valoarea

transmisă actorului.
Un caz de utilizare poate fi descris printr-o diagramă de activitate, ce va permite
vizualizarea secvenţelor de activităţi, ordinea lor şi, opţional, deciziile luate pentru a specifica
operaţia ce urmează a fi realizată. Trebuie să reţinem un lucru important: modelul cazurilor de
utilizare trebuie să fie uşor de comunicat utilizatorului/clientului.
După ce au fost descrise cazurile de utilizare vor trebui specificate relaţiile existente între
acestea. Întrebările care vor trebui puse în această fază sunt:
 Toţi actorii implicaţi comunică cu cazuri de utilizare?
 Există asemănări între actori? Poate fi descrisă/identificată o clasă actor de bază?
 Există asemănări între cazurile de utilizare existente? Există un flux comun de activităţi
care să poată fi descris ca o relaţie de folosire a unui caz de utilizare?
 Există cazuri de utilizare care să poată fi descrise ca extinderi (extend)?
 Sunt actori sau cazuri de utilizare fără asocieri de comunicare? Dacă există aşa ceva
este greşit!
 Sunt cerinţe funcţionale încă necuprinse în cazuri de utilizare? Dacă da, vor trebui
rezolvate.
Cazurile de utilizare sunt folosite şi în etapa de testare a sistemului; sunt două tipuri de
teste care se pot realiza: verificarea, în care se confirmă sau nu dacă sistemul a fost dezvoltat
corect, în concordanţă cu specificaţiile cerute şi respectiv validarea, ce verifică dacă sistemul
construit este util atât pentru client cât şi pentru utilizatorul final.

18