Seminar 3

Realizarea sistemelor informatice

pentru management

Diagrama cazurilor de utilizare UML

Caz de utilizare
Specific un set de aciuni executate de ctre un

sistem sau un subiect i care conduc la un anumit

rezultat.
Rezultat, n mod normal, este important pentru un
actor sau un beneficiar.

Actori
Un actor interacioneaz cu sistemul n contextul unui caz

de utilizare.
Actorii reprezint roluri care pot include factori umani,
hardware extern sau alte sisteme.
Rspunde la ntrebri de genul:
CINE solicit informaii din sistem
CINE modific informaiile din sistem
CINE interacioneaz cu sistemul

Se reprezint folosind simbolul specific al unui omule.

Diagrama cazurilor de utilizare

Descrie relaiile dintre un set de cazuri de utilizare i

actorii care particip la realizarea acestor CU.

Diagramele de CU nu descriu comportamente sau
fluxuri.
Poate delimita graniele sistemului analizat prin
includerea CU n interiorul unui dreptunghi.

Relaii ntre actori

Sunt de tipul generalizare/specializare, ntre un actor

abstract i unul sau mai muli actori concrei

Relaii ntre actori i cazuri de utilizare -1

Asocierile simple sunt folosite pentru a conecta un

actor cu un caz de utilizare.

Aceasta reprezint o cale de comunicare ntre cei doi.
Comunicarea poate fi i unidirecional.

Relaii ntre actori i cazuri de utilizare -2

La acest nivel sunt permise multiplicitile.
multiplicitatea mai mare dect unu la captul:
corespunztor CU actorul este implicat n mai multe cazuri de utilizare de
acel tip i poate iniia cazuri de utilizare: n paralel (concurent), la diferite
momente de timp sau mutual exclusiv n timp.
corespunztor actorului mai multe instane ale actorului sunt implicate n
iniierea cazului de utilizare putnd realiza aciuni simultane sau succesive.
UML nu are notaii standard pentru situaiile de mai sus.

Relaii ntre cazuri de utilizare -1

ntre dou cazuri de utilizare care se refer la acelai subiect

(sistem) nu pot exista relaii simple. Fiecare descrie un mod de

utilizare complet al sistemului.
1. Generealizare
Se folosete cnd exist dou sau mai multe CU care au n comun

comportament, structur i scop.

Comportamentul CU printe poate fi suprascris.
Se specific numai diferenele dintre cele dou n CU specializat.

Relaii ntre cazuri de utilizare -2

2. Includere
Are ca scop integrarea unui CU n alt CU, primul devenind astfel o parte logic din acel CU. CU
care l include pe un altul nu este complet.
Se folosete atunci cnd:

exist pri de comportament comune n mai multe CU.

pentru a simplifica CU mari.

Este echivalent cu apelul unei subrutine n programare.

Denot un comportament obligatoriu, nu opional.
Nu se motenesc proprieti de la un CU la altul.
Se evit redundana prilor cu comportament identic.

Relaii ntre cazuri de utilizare -3

3. Extindere
Este folosit atunci cnd un CU are loc doar n anumite condiii sau
opional.
CU extins este complet i independent de cel care l extinde.
Extinderea are loc n unul sau mai multe puncte de extindere, definite
n cazul de utilizare extins.
Se pot asocia note sau constrngeri pe aceast relaie pentru a ilustra
condiiile n care comportamentul extins trebuie executat.

Descrierea textual a unui CU

Element al cazului de
Descriere
utilizare
Cod
Un identificator unic asociat cazului de utilizare
Stare
Stadiul de finalizare n care se gsete, de exemplu: schi,
finalizat sau aprobat
Scop
Sistemul (parte a sistemului) sau aplicaia creia i aparine
Nume
Numele cazului de utilizare, ct mai scurt i reprezentativ
Actor principal
Beneficiarul care iniiaz cazul de utilizare i care urmrete un
anumit scop
Descriere
Prezentare scurt, in text liber, a cazului de utilizare
Precondiii
Ce condiii trebuie satisfcute pentru ca scenariul s poat
ncepe
Postcondiii
Ce condiii trebuie ndeplinite pentru a garanta un final reuit al
scenariului
Declanator
Un eveniment sau o succesiune de evenimente care iniiaz
cazul de utilizare
Flux de baz
Fluxul de baz descrie niruirea evenimentelor atunci cnd
totul se petrece conform unui scenariu prestabilit; nu exist
excepii sau erori
Fluxuri alternative
Cele mai semnificative alternative i excepii ale scenariului de
baz
Relaii
Ce relaii are cu alte cazuri de utilizare (de tipul includes sau
extends)
Frecvena utilizrii
Ct de des se estimeaz c va fi folosit aceast funcionalitate
a sistemului
Reguli ale afaceri
Ce reguli guverneaz cazul de utilizare; ce prerogative trebuie s
aib actorii

Lucru la seminar
S se ntocmeasc diagrama de cazuri de utilizare i descrierea textual a unui caz de
utilizare pentru scenariul de mai jos.
Scopul proiectului este realizarea aplicaiei informatice pentru gestiunea activitii unei uniti
hoteliere. n vederea cazrii, un client poate solicita rezervarea uneia sau mai multor camere
prin e-mail sau telefonic. Pentru aceasta furnizeaz recepionerului informaii privind perioada
de cazare i tipurile de camere solicitate. Clienii vor beneficia de reduceri dac rezerv cel
puin 3 camere sau dac perioada de cazare depete 5 zile. Recepionerul verific
disponibilitatea camerelor i l ntiineaz pe client de acest lucru precum i de costul estimat
al cazrii. Dac nu exist camere disponibile conform solicitrii, recepionerul poate oferi
clientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu),
iar recepionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerul
hotelului. n situaia n care clientul este de acord cu preul propus, se va proceda la realizarea
rezervrii. Pentru clienii noi, recepionerul solicit datele de identificare, pe care le introduce
n aplicaie.

Odat ajuns la hotel, i dac a fcut n prealabil o rezervare, clientul va furniza datele de
identificare ale sale i/sau ale rezervrii i se face cazarea. Dac nu exist o rezervare, se va
verifica disponibilitatea camerelor pentru perioada cerut. Atunci cnd se gsete o astfel de
camer, se face cazarea. La finalul sejurului, recepionerul ntocmete o list cu toate serviciile
solicitate de client i preul acestora. Lista trebuie validat de client, dup care se ntocmete
factura final. Factura poate fi pltit parial sau integral, prin transfer bancar, numerar sau
folosind un card bancar. Totodat, nainte de a prsi hotelul, clientul este rugat s completeze
un formular prin care s evalueze serviciile oferite de unitatea hotelier.

Descrierea textual a unui CU

Element al cazului de utilizare
Cod
Stare
Scop
Nume
Actor principal
Descriere
Precondiii
Postcondiii
Declanator

Descriere
CU01
Schi
Gestiunea cazrilor unei uniti hoteliere
Rezerv camer
Client
Presupune realizarea unei rezervri pentru una sau mai multe camere
Recepionerul are logat n sistem
Rezervarea a fost realizat i clientul primete o confirmare a rezervrii
Clientul solicit rezervarea uneia sau mai multor camere prin e-mail sau telefonic

Flux de baz

1.

Fluxuri alternative

Relaii
Frecvena utilizrii
Reguli ale afaceri

Clientul furnizeaz recepionerului informaii privind perioada de cazare i tipurile de camere

solicitate.
2.
Recepionerul verific disponibilitatea camerelor.
3.
Recepionerul l ntiineaz pe client c exist camere disponibile. [Curs alternativ A: Nu exist
camere disponibile conform cerinelor clientului]
4.
Recepionerul l ntiineaz pe client de costul estimat al cazrii. [Punct de extindere: CU07
Decide acordare discount]
5.
Clientul confirm perioada de cazare i este de acord cu preul propus. [Curs alternativ B:
Clientul nu este de accord cu condiiile rezervrii ]
6.
Recepionerul solicit datele de identificare ale clientului. [Curs alternativ C: Datele clientului
sunt dj introduse]
7.
Recepionerul introduce datele clientului n sistem.
8.
Recepionerul realizeaz rezervarea.
9.
Clientul primete confirmara rezervrii.
A: 1. Recepionerul ofer alternative de cazare la cele solicitate.
2. Clientul selecteaz o alternativ, altfel scenariul se ncheie.
B: 1. Clientul nu confirm rezervarea i scenariul se ncheie.
C: 1. Se trece la punctul 8.
Se extinde prin CU07 Decide acordare discount
Foarte frecvent
Recepionerul poate acorda discounturi la cererea clientului numai cu acordul managerului.