Capitolul 3

Modelarea Cazurilor de Utilizare: Use-Case Modeling

3.1.Cazurile de Utilizare(CU): func]ionalitatea, actorii [i sistemul.

Cazul de utilizare(CU) este o tehnic\ de modelare prin care se descrie ce trebuie s\ fac\
noul sistem sau ce realizeaz\ `n mod normal sistemul existent. Modelul CU este o
construc]ie prin care se declan[eaz\ procese complexe iterative desf\[urate `ntre
dezvoltatorii de sistem [i utilizatorii finali, `n vederea realiz\rii specifica]iilor agreate de
to]i clien]ii sistemului; CU con]ine secven]e finite [i uNeori repetabile, de tranzac]ii `n
interac]iunea cu sistemul, prin intermediul actorilor [i rela]iilor dintre CU, omogene din
punct de vedere comportamental. CU modeleaz\ dialogul interactiv, de multe ori `n timp
real dintre Actori-Sistem(S).
Modelarea CU a fost creat\ de Ivar Jacobson, `n anul 1994, pe baza experien]ei avute la EXE
System, Ericsson.
Componentele fundamnetale ale modelului CU sunt: actorii [i sistemul modelat. CU con]ine
secven]e de tranzac]ii de mesaje omogene din punct de vedere comportamental,
derulate interactiv cu sistemul(privit din punct de vedere generic); CU modeleaz\
comunicarea [i dialogul dintre A-S. CU poate interac]iona dinamic cu S, A sau alte CU
prin intermediul stereotipurilor <<extends>>,<<include>>,<<uses>>.
Func]ionalitatea este reprezentat\ printr-un num\r de CU, fiecare asemenea CU
asigur`nd o func]ionalitate complet\; c`nd func]ionalitatea este complet\, atunci CU
trebuie s\ guverneze `ntreaga func]ie, aceasta fiind decla[at\ de c\tre un actor at`ta timp
c`t este realizat\ func]ionalitatea solicitat\.
Agen]ii economici sun structura]i `n OE [i OFBM care au func]ii, subfunc]ii, activit\]i, subactivit\]i [i
opera]ii specifice, pentru care pot fi dezvoltate CU ata[ate direct; rezult\ c\ nivelul de agregare al CU
este dependent de ”sistemul” la nivelul c\ruia este dezvoltat CU: OE /OFBM, func]ii, subfunc]ii,
activit\]i, subactivit\]i [i opera]ii.
”Sistemul” utilizat pentru aplicarea CU poate fi deci la nivel de OE /OFBM, func]ii,
subfunc]ii, activit\]i, subactivit\]i [i opera]ii.

fig.3.1. Stabilirea nivelelor de abordare ale CU

Pentru a se asigura aceste elemente, CU trebuie s\ trimit\ `ntotdeauna valori c\tre un actor,
valoarea fiind transmis\ actorului de un element al sistemului. Actorul(A) este privit ca orice
entitate extern\ ce manifest\ interes `n interac]iunea cu sistemul; dar accep]iunea poate
fi generoas\,deoarece prin actor se pot `n]elege utilizatorii finali ai sistemului, alte
sisteme externe, diferite tipuri de echipamente, dar, pentru sistemele informatice
gestiune, actori pot fi mesaje primite/transmise de c\tre sistem, documente de
intrare/rapoarte de ie[ire, compartimente func]ionale, alte tipuri de diviziuni
organizatorice etc. Sistemul este privit ca o cutie neagr\(“black box”) ce furnizeaz\ CU,
cu men]iunea c\ func]ionarea intern\ a sistemului, modul de implementare particular\ a
CU, tehnologia intern\, specific\ de lucru, nu sunt importante.
Scopurile primare [i imediate ale CU sunt urm\toarele
 descrierea cerin]elor func]ionale ale sistemului deduse din solicit\rile tuturor tipurilor de
utilizatori(manageri, compartimente func]ioanle, sec]ii/sectoare de produc]ie, etc) sau chiar ale
re]elelor de calculatoare pe care se va grefa noul sistem.
 descrierea clar\ [i consistent\ a ceea ce va trebui s\ rezolve sistemul, deci ce model va fi utilizat
pentru dezvoltarea proceselor de comunica]ie aferente tuturor cerin]elor.
 furnizarea elementelor de baz\ pentru realizarea testelor necesare verific\rii sistemului.
 furnizarea abilit\]ilor pentru trasarea cerin]elor func]ionale ale sistemului prin prisma claselor [i
opera]iilor specifice sistemului, dac\ acest lucru este posibil.
Crearea unui CU presupune definirea sistemului, determinarea actorilor implica]i `n func]ionarea
CU, descrierea acestor CU [i eventual, definirea rela]iilor dintre clasele utilizate, pentru ca `n final s\
se realizeze validarea modelului.
Modelul CU consist\ `n diagrama CU(DCU), prin intermediul c\reia sunt reprezenta]i actorii, CU
[i rela]iile specifice. Men]ion\m c\ modelele verbale nu pot furniza toate informa]iile necesare
`n descrierea complet\ [i consistent\ a modelului CU, dar, DCU plus descrierea textual\ sunt
suficiente pentru cuantificarea corect\ a modelului CU. Utilizatorii finali au un rol deosebit `n
modelarea CU, deoarece modelul CU trebuie s\ specifice func]ionalitatea sistemului, iar descrierea
acestui CU va putea fi realizat\ `n limbajul [i terminologia utilizatorilor/clien]ilor sistemului. ~n plus,
proiectan]ii sistemului au nevoie de modelele CU pentru a `n]elege cum lucreaz\ sistemul `n
infrastructura sa, inclusiv mecanismele viitoare ce vor fi necesare a fi ata[ate noului sistem. Echipa
de integrare [i testare a sistemului realizat au nevoie de modelele CU pentru a asigura
func]ionalitatea specificat\ `n modelele CU. ~n mod normal, mai pot fi interesa]i `n `n]elegerea
modelelor CU [i alte elemente implicate `n interac]iunea cu sistemul proiectat(sistemul de servicii
de orice tip, marketing, sisteme externe etc).
Modelele CU sunt reprezentate prin intermediul vederilor CU asociate sistemului, dar men]on\m c\
acestea sunt influen]ate de arhitectura fizic\ [i logic\, deoarece func]iile redate `n modelele CU sunt
implementate prin aceste arhitecturi logico-fizice.
Mai mult, modelele CU sunt folosite nu numai pentru precizarea cerin]elor noului sistem, dar [i
pentru dezvoltarea unor noi genera]ii de sisteme, prin inserarea de noi actori [i CU, sau prin
modificarea specifica]iilor curente ale CU curente.

3.2. Diagrama CU(Use-Case Daigram).

3.2.1. Semntica, semnifica]ii [i simboluri.

Modelul CU este descris `n UML prin intermediul diagramei CU-DCU(Use-Case Diagram) ce

con]ine elementele modelului specifice sistemului, actorii, CU precum [i iferitele rela]ii cum ar fi
generalizarea, asocierea sau dependen]a dintre aceste elemente.
DCU poate fi agrementat\ prin intermediul unor descrieri sub form\ de text create pentru a
documenta propriet\]ile elementelor CU. Aceste descrieri trebuie s\ con]in\ informa]ii vitale privind
definirea cerin]elor actuale [i func]ionalit\]ii sistemului, dar facem precizarea c\ se poate utiliza, ca
alternativ\ la descrierea sub form\ de text, diagrama de activitate.

3.2.2. Sistemul.

Sistemul este grani]a sau limita `n care se vor reprezenta CU, acesta put`nd s\ dispun\ de
subsisteme specifice, activit\]I, subactivit\]I, opera]ii [i faze, dup\ caz. Sistemul poate sau nu con]ine
sisteme software dedicate, deci agentul economic poate avea sau nu un sistem informatic
dezvoltat. Pentru sistemul realizat trebuie identificate [i particularizate func]iile de baz\, `n vederea
realiz\rii unui catalog central de concepte ce va con]ine entit\]ile [i termenii utiliza]i. Aceste
procese sunt necesare de fapt, pentru identificarea terminologiei folosite, care la r`ndul s\u
va fi descris\ `n CU. De asemenea, acest catalog central mai poate con]ine [i rela]iile simple
existente `n sistem, precum [i un text adi]ional prin intermediul c\ruia s\ se poat\ realiza
descrieri scurte privind func]ionalitatea [i infrastructura sistemului.
Func]iile specifice sistemului sunt dependente de domeniul de activitate al operatorului
economic [i particularizate `n raport de specificul activt\]ii acestuia. Pentru fiecare sistem se vor
defini subsisteme le, activit\]ile, subactivit\]ile [i opera]iile specifice.
Sistemul.poate fi considerat ca fiind OE /OFBM, func]iile sale specifice, subfunc]iile
derivabile din func]ii, activit\]ile `n care sunt structurate subfunc]iile, subactivit\]ile
componente ale activit\]ilor [i/sau opera]iile ob]inute ca rezultat al decup\rii
subactivit\]ilor. Sistemul poate fi cinsiderat orice nivel dorit de agregare: OE/ OFBM,
func]ia, subfunc]ia, activitatea, subactivitatea sau opera]ia.
.
 Diagrama Cazurilor de Utilizare
Simboluri generale folosite `n DCU

Actor intern/extern
de tip activ/inactiv Asociere(association)
Numele
`ntre A-A, A-CU sau CU-CU
Numele sistemului/ cazului
<<actor> de
subsistemului/
> utilizare
aplica]iei
(system name) (use case name)

Simboluri generale folosite pentru asocierile A-CU

Asociere(association)

0 sau 1 sau 0..* sau 0 sau 1 sau 0..* sau

1..* 1..* CU

<<actor>
>
Simboluri generale folosite pentru asocierile CU-CU

generalizare specializare utilizare

CU CU CU

<<extende> <<include> <<uses>

> > >

CU CU CU

Simboluri generale folosite pentru asocierile A-A

<<actor>
<<actor>
>
>

specializare `ntre A generalizare `ntre A

<<actor> <<actor>
> >

fig. 3.2. Simbolurile utilizate `n Diagrama CU.

 Sistemul solicitarea, acordarea [i. rambursarea creditelor
bancare <<actor>
0.. 1
1..
* Serv.
* 1
Solicitare CREDITE
credit
<<include>
0.. <<actor>
1
* MANAGER
0..
aprobarea
aprobarea 1 CREDITE
*
<<include>
creditului
<<actor>
creditului <<actor>
1.. 0..
1
* * GHI{EU
0.. 1 BANC|
1.. acordarea
acordarea
* \ a
Clie* <<include>
efectiv
efectiv\
creditul a
<<actor>
nt ui creditulu
1..
bnac 1..
i* 1 Serv.
ar *
1.. 1 FINANCIAR
derulareaderularea
*
generalizare creditului
<<include> creditului
<<actor>
1..
<<uses>> 1 Serv.
* 1..
CONTABILITATE
*
eviden]a eviden]a \ a creditul
eviden]a
contabil\ contabil ui contabil\
a creditul
analitic\ ui
P PJ <<extends>> <<extends>>
F
<<actor><<actor> <<extends>>

Actualizar Opera]i Opera]ii

e i creditar
cont cu debitar e
sold e cont
ini]ial cont
fig. 3.3. DCU(Use-Case Diagram) cu exemplificarea rela]iilor A-A(prin generalizare, specializare),A-CU
multiplicitate de tipul 1, 0.*, 1.*) [i CU-CU(prin stereotipurile <<uses>>, <<extends>>, <<include>
(`n cazul acord\rii [i ramburs\rii creditelor bancare)

OPERATOR ECONOMIC

AGENT ECONOMIC AGENT FINANCIAR-BANCAR-

(societ\ ]I comerciale `n domeniul
industriei, construc]iilor, agricul
turii, transporturilor, prest\ ri ser
vicii, comer]ului interior/ exterior
etc )
Func]ia CERCETARE-DEZVOLTARE
Func]ia COMERCIAL|
Func]ia PRODUC}IE/SERVICII
Func]ia FINANCIAR-CONTABIL|
Func]ia RESURSE UMANE
MONETAR (Ministerul Finan]elor,
societ\ ]I bancare, Bursa de valo
ri, Fonduri mutuale, societ\ ]i de
investi]ii, societ\ ]i de asigurare-
reasigurarea, Case schimb
valutar etc.)
Func]ia DEZVOLTARE
Func]ia RELA}II FINANCIAR-
BANCARE-MONETARE
Func]ia SERVICII FINANCIAR-
BANCARE-MONETARE
Func]ia FINANCIAR-CONTABIL|
Func]ia RESURSE UMANE

Cadrul legislativ-normativ
specific [i adaptat

fig.3.4. Func]iile esen]iale specifice operatorului economic utilizabile `n CU

 Sistemul bancar al CEC

Opera]iuni Opera]iuni Opera]iuni Opera]iuni Opera]iuni Opera]iuni

DEPUNERI RESTITUIRI CALCUL CERTIFICATE CERTIFICATE CONTURI
carnete CEC carnete CEC DOB~NZI ANIVERSARE de DEPOZIT CURENTE

carnete CEC PERSONALE

fig.3.5. Exemplu privind includerea subsistemelor specifice CEC `n modelul CU.

3.2.3. Actorii.

Actorul este un concept fundamental `n teoria CU, caracterizat prin urm\toarele elemente
particulare:
Tabel 3.1
elemente Descriere sintetic\
particu lare
specifice con
ceptului de
“actor”
Semantica -actorii sunt cineva sau ceva care interac]ionaez\ cu sistemul, deci cineva
sau ceva care utilizaeaz\ sistemul. ~n aceast\ viziune prin “interac]iune
cu sistemul” se `n]elege ac]iunea prin care actorii trimit sau primesc
mesaje la [i de la sistem, sau schimb\ informa]ii cu acesta, deci `n sen]\,
actorii transmit ie[iri c\tre CU. ~n practica economic\ actorii pot avea
diverse accep]iuni, `n raport de urm\to\rele criterii fundamentale:

a.criteriul strcutural-organizatoric utilizat `n raport de tipul AE,

care poate fi organism ale statului(Guvern, Parlament, Pre[edin]ia,
Curtea de Conturi, Garda Financiar\, Direc]ia General\ a Finan]elor Publice
[i Controlul Financiar de Stat etc.), Ministere Economice, OFBM(societ\]i
bancare, burse de valori, societ\]i de asigur\ri-reasigur\ri, case de schimb
valutar, fonduri mutuale, fonduri de investi]ii financiare, OFB
interna]ionale cu sediul `n Rom^nia) sau OE(societate comercial\, S.A.,
SRL, regie na]ional\, societate na]ional\ etc).

b.criteriul func]ional axat pe utilizarea unor func]ii, activit\]i, sub

activit\]i, opera]ii documente/rapoarte specifice etc
~n raport de utlizarea efeectiv\ -domeniul financiar-contabil:
-criteriul strcutural-organizatoric: OE de orice tip(clien]i, furnizori,
dealer-i specializa]i), departamente, serivcii func]ionale, ghi[ee, magazine,
sec]ii, ateliere, forma]ii de lucru, gestiuni, manageri, economi[ti, anali[ti
economici, casierie etc
-criteriul func]ional: comanda, contractul, anexa la contract, factura,
NRCD, Bon de Consum, Bon de Materiale, Fi[a Contului, BVA, BVS, Bilan]ul
Contabil, CPP, Situa]ia Patrimoniului, Decont TVA, Jurnale de Cump\r\ri,
Jurnale de V`nz\ri etc
-domeniul financiar-bancar-monetar: -criteriul strcutural-
organizatoric: OFB de orice tip, client bancar, serviciu bancar, ghi[eu
bancar, punct de schimb valutar, departamente financiar-bancare,
sucursale financiar-bancare, filiale, manageri, econo mi[ti, anali[ti
economici, casierie etc
-criteriul func]ional: Contract, Extras de Cont, Fi[a Contului, BVA, BVS,
Bilan]ul Contabil, CPP, Situa]ia Patrimoniului etc.
 -comunica]iile actorilor cu sistemul prin trimiterea/recep]ia de mesaje,
ac]iuni de determin\ formalismul specific\rii `n czul de utilizare, deoarece
`ntotdeauna un CU este este ini]iat de un actor ce trimite un
mesaj c]tre acest CU denumit stimul.
-actorii pot fi ierarhiza]i dup\ mai multe criterii:
1. Dup\ gradul de implicare al actorilor `n func]ionarea
sistemului:
-Actorii primari: utilzeaz\ func]iile primare ale sistemului,
asemenea func]ionalit\]ii principale(ex. `n subsis temul financiar-contabil,
un actor primar poate fi persoana care realizeaz\ `nregistrarea
documentelor primare conta bile).
-Actorii secundari: utilizeaz\ func]iile secundare ale
sistemului, cum ar putea fi, de exemplu, managerul financiar-contabil.
2. Dup\ modul de activare
-Actorii activi: are rolul de a ini]ia CU dorit de c\tre acesta
-Actorii pasivi: are de asemenea rolul de a ini]ia un CU, dar
numai dup\ participarea acestuia la unul sau mai multe CU.
Identificarea -prin identificarea actorilor se `n]elege stabilirea acelor entit\]i
actorilor interesate `n utilizarea [i interac]iunea cu sistemul, de fapt identificarea
presupune, stabilirea actorilor ce determin\ cerin]ele sistemului [i
CU necesare acestora.
-selec]ia actorilor trebuie s\ aib\ `n vedere toate categoriile de
utilizatori care interac]ioneaz\ direct sau indirect cu sistemul sau
utilizeaz\ serviciile sistemului.
-vor fi valida]i numai actorii reali care exist\ [i se manifest\ `n
func]ioanrea efectiv\ a sistemului, deoarece actorii sunt un rol, o clas\,
ace[tia nefiind o instan]\.
-identificarea actorilor se poate realiza, `n principiu, prin intermediul
urm\toarelor `ntreb\ri:
 Care sunt activit\]ile/subactivit\]ile necesare func]io n\rii optimale a
organismului economic, ce implic\ apelul unor func]ii
principale/secundare ale sistemului ?
 Care sunt echipamentele de calcul(re]ele de calcula toare, sta]ii
de lucru, server-e, imprimante etc ) utilizate de c\tre sistem
 Care sunt cerin]ele de prelucare specifice sistemului `n raport de
aplicarea adaptiv\ a legisla]iei ce guverneaz\ func]ionarea
sistemului ?
 Cine utilizeaz\ func]iile de baz\ ale sistemului(actorii principali) ?
 Cine utilizeaz\ zilnic func]iile sistemului pentru realizarea
sarcinilor ?
 Cine are nevoie de sistem pentru administrare [i
management(actorii secundari) ?
 Care sunt alte sisteme ce interac]ionaez\ cu siste mul propriu al
organismului economic ?
Actorii `n -actorii UML sunt clase de au stereotipuri denumite <<actor>> [i care
UML numele clasei este de fapt numele actorului, ce reflect\ rolul acestuia
-actorii clas\ pot avea atribute [i comportament specific, ace[tia put`nd fi
defin]i prin icoane standard de stereotip(
Rela]iile -deoarece actorii au clase, ace[tia pot avea leg\turi/rela]ii ca `n cazul
dintre actori claselor, cu precizarea c\ `n CU numai rela]iile de generalizare pot fi
utilizate `n descrierea comun\ a comportamentului `ntre numele actorilor
Generalizare -generalizarea apare `n Situa]ia `n care unii actori, prin rolurile speciifice,
a joac\ mai mult rolul de generalizare, atunci ace[tia vor fi descri[i prin
generalizare
-`n cadrul generaliz\rii, actorii specializa]i `n p\strarea comportamentului
mo[tenirii existente `n supercalas\, vor fi mo[tenitorii acestui
comportament.
 Sistemul bancar al CEC

Opera]iuni Opera]iuni Opera]iuni Opera]iuni Opera]iuni Opera]iuni

DEPUNERI RESTITUIRI CALCUL CERTIFICATE CERTIFICATE CONTURI
carnete CEC carnete CEC DOB~NZI ANIVERSARE de DEPOZIT CURENTE

carnete CEC PERSONALE

<<actor>> <<actor>> <<actor>> <<actor>> <<actor>> <<actor>>

operator operator operator operator operator operator
ghi[ eu ghi[ eu ghi[ eu ghi[ eu ghi[ eu ghi[ eu

operator ghi[ eu

fig. 3.6. Reprezentarea unui actor `ntr-o clas\

Director sucursal\ bancar\

Director opera]iuni Director opera]iuni

credite conturi curente

Operator Operator
Operatorl opera]iuni opera]iuni
Ordonator
eviden]\ curente `n curente `n
credite
contabil\ LEI VALUT|

fig. 3.7. Reflectarea generaliz\rii `ntre actori.

3.2.4. Cazurile de Utilizare(Use Cases).

CU sunt definite ca un set de secven]e de ac]iuni ale sistemului `n care rezultatele

valorilor sunt transmise unui actor particular. Ac]iunilie pot implica comunicarea cu un
num\r de actori, privi]i ca utilizatori sau alte sisteme, la fel de bine ca performan]ele de
calcul [i lucrul `n interiorul sistemului.
Pentru descrierea CU vom parcurge mai multe faze:
1. Caracteristicile CU
2. Desemnarea CU
3. Utilizarea CU `n UML
4. Rela]iile dintre CU
1.Caracteristicile CU sunt urm\toarele:
Tabel 3.2
Caracteristicile Descriere general\
CU
CU este `n mod -actorul trebuie s\ permit\ ordonarea direct\/indirect\ a sistemului `n vederea
invariabil apel\rii [i interpret\rii CU
declan[at de un -este posibil, ca total aleator, un actor s\ nu ini]iexe un CU, de[ii `n mod
actor standard rolul actorului este acela de a activa [i utiliza CU cu care acesta
este conex.
CU trebuie s\ fie CU trebuie s\ fie descriptibile, `n sensul c\ aceste CU nu sunt complete at`ta
complet timp c`t valorile finale nu sunt produse.
CU furnizeaz\ -rolul CU este de a livra c`teva tipuri/feluri valori c\tre utilizatori, dar aceste
valori c\tre un valori nu trebuie `ntotdea una s\ fie semnificative, dar acestea vor trebui s\
actor aib\ calit\]ile de vizibilitate [i observabilitate.
Asocierile de -CU sunt conectate cu actorii prin interme diul unor asocieri denumite
comunica]ie asocieri de comunicare (communication associations)

2.Desemnarea CU

Procesele pentru stabilirea CU `ncep cu definirea actorilor furnizori, astfel `nc`t pentru fiecare actor
identificat trebuis s\ se r\spund\ la urm\toarele `ntreb\ri:
 Care func]ii realizate de c\tre actor sunt necesare sistemului?
  Are nevoie actorul de actualizarea(citirea, [tergerea, modificarea sau memorarea) unor
tipuri de informa]ii vehiculate de c\tre sistem?
 Are nevoie actorul de evenimentele care apar `n sistem sau actorul are nevoie de a
schimba func]iile sistemului?
 Poate actorul zilnic s\ lucreze simplificat cu sistemul sau pot fi realizate mai eficient noile
func]ii ale sistemului?
 Care sunt intr\rile/ie[irile de care sistemul are novoie? C`nd apar aceste intr\ri/ie[iri sau
unde sunt transmise acestea?
 Care sunt problemele majore cu care se confrunt\ implementarea curent\ a sistemului?

3. Folosirea CU `n UML

CU sunt reprezentate `n UML prin intermediul unei elipse ce va con]ine numele CU, iar `n mod
normal un CU va fi plasat `n mod normal `n interiorul sistemului, de unde va fi conectat cu actorii
prin asocieri sau comunica]ii asocieri.

4. Rela]iile dintre actori-actori, actori-CU, CU-CU.

a. Rela]iile dintre actori-actori(A-A): extensiile [i utiliz\rile rela]iilor pot avea diferite

forme de mo[tenire, motiv pentru care exist\ trei tipuri de rela]ii `ntre CU: extensie,
grupare [i utiliz\ri. Acestea sunt descrise prin intermediul unor stereotipuri, metode de
grupare tehnic\ a CU [i conectivitatea dintre actori-CU. Stereotipurile sunt
concepte UML care permit extensia elementelor de modelare fundamentale
pentru generarea unor elemente noi de modelare, `n timp ce gruparea este o
tehnic\ de `nglobare relativ\ a CU `n structura unor pachete. UML admite defini]ii
ale rela]iilor de generalizare dintre actori(generalizare, specializare) [i CU(extensia,
gruparea, utilizarea)
Rela]iile de generalizare dintre actori sunt urm\toarele:
Semantica genaraliz\rii dintre actori este axat\ pe coceptul de taxonomie, taxonomia fiind
[tiin]a clasific\rii; generalizarea este o rela]ie `ntre un element foarte general [i unul cu
caracter specific, cu men]iunea c\ elementul specific este deosebit de consistent `n
raport de elementul general, dar poate con]ine, `n mod concret, [i alte informa]ii
adi]ionale. Instan]a elementului specific poate fi utilizat\ c`nd elementul general este
utilizat; aceast\ generalizare se mai nume[te [i mo[tenire, moment `n care elementele pot fi
specializate prin noi elemente, cum ar putea fi cazurile de extensie sau speciale. ~n mod uzual
generalizarea este utilizat\ pentru actori, clase, cazuri de utilizare [i elemente de model de tip
pachet (package). Generalizarea este denumit\ [i rela]ia “este o”/ “este un”; generalizarea
modeleaz\ transmiterea/mo[tenirea proprit\]ilor actorilor, `ntre respectivii actori. Actorul general
este denumit superactor, `n timp ce actorul specilizat se nume[te subactor.
Generalizarea pentru actori poate fi de dou\ tipuri:
a1.Actorul general este denumit superactor, este cel care monitorizeaz\, determin\ [i controleaz\
ac]iunea/ac]iunile actorului/actorilor specializat/specializa]i.
a2.Actorul specializat se nume[te subactor, fiind actorul dependent de rolul, func]ionalittaea [i
ac]iunilie superactorului.
b. Conectivitatea dintre actori-CU(A-CU), este redat\ prin intermediul multiplicit\]ii care
specific\ num\rul CU care pot asociate cu un Actor instan]iabil; multiplicitatea poate avea valorile:
1: maxim o asociere `ntre A-CU;
0.1:zero sau maxim o asociere `ntre A-CU;
0.*:zero sau maxim n asocieri `ntre A-CU;
1.*:una sau maxim n asocieri `ntre A-CU.
c.Rela]iile dintre CU(CU-CU) sunt urm\toarele:
c1.Extensia rela]iilor CU prin stereotipul <<extends>>: `n Situa]ia `n care extensiile unui CU
se aplic\ asupra alt CU, atunci aceasta `nseamn\ c\ primul CU poate include c`teva elemente de
comportament ale CU extins, acesta `ns\ nu poate include integral comportamentul existent, dar
acesta poate alege c`teva p\r]i din com portamentul CU general, care este de fapt, reutilizabil. CU
devenit extins trebuie s\ fie complet, acesta fiind descris prin intermediul unui model verbal sub
form\ de text. Totu[i, acest CU poate fi definit ca parte `n CU extins, care este reutilizabil din cazul
cazul generalizat de utilizare, care este redefinit [i care este adi]ionat la cazul generalizat de
utilizare. Folosirea rela]iilor este activ\ atunci c`nd un num\r de CU au un comportament comun care
poate fi modelat printr-un singur CU care este apelat `n alt CU. C`nd un CU folose[te un alt caz,
atunci `ntregul caz trebuie s\ fie utilizat. Dac\ un CU este nefolosit `n utiliz\rile proprii, atunci acesta
se nume[te caz abstract de utilizare(.
c2.Gruparea CU prin stereotipul <<include>>: este utilizat\ `n Situa]ia `n care
comportamentul [i descrierea unui CU folose[te anumite p\r]i [i descrieri ale altui CU, prin procese
de absor]ie totale/par]iale; CU priincipal conduce `n mod sigur la activarea comportamentului altor
CU considerate secundare sau subordonate.
c3.Utilizarea CU prin stereotipul <<uses>>: presupune posibilitatea refolosirii unor
secven]e finite, repetabile, reutilizabile [i complementare de tranzac]ii, `n interac]iunea cu
sistemul, prin intermediul actorilor [i rela]iilor omogene din punct de vedere
comportamental.
fig.3.8. Variante complexe de utilizare a CU

3.2.5. Descrierea CU.

Specifica]ia privind descrierea CU trebuie s\ indice modul `n care actorii interac]ioneaz\ cu sistemul
prin intermediul CU. Aceste specifica]ii trebuie s\ indice comportamentul sistemului [i s\ ignore
func]ionalitatea intern\ a sistemului. Exist\ dou\ variante de descriere a CU:
1.Descrierea textual\: aceast\ explica]ie descriptiv\ trebuie s\ con]in\ urm\toarele elemente
definitorii:
tabel 3. 3.
Elemente definitorii ale Descrierea sintetic\
descrierii textuale
 Obiectivele cazului de utili  proiectanul trebuie s\ r\spund\ la urm\toarele `ntreb\ri cheie:
zare  care sunt obiectivele generale [i finale ale cazului de
utilizare `n raport de cerin]ele specfice rzultate din aplicarea
cadrului legislativ `n materie ?
 care este scopul pe care `ncearc\ s\-l ating\ CU ?
 CU are un scop orientat iar acest scop pentru fiecare CU
va fi previzibil `n viitor ?
 Obiectivele CU  proiectanul trebuie s\ r\spund\ la urm\toarele `ntreb\ri cheie:
 care sunt obiectivele generale [i finale ale cazului de
utilizare `n raport de cerin]ele specfice rzultate din aplicarea
cadrului legislativ `n materie ?
 care este scopul pe care `ncearc\ s\-l ating\ CU ?
 CU are un scop orientat iar acest scop pentru fiecare CU
va fi previzibil `n viitor ?
fig.3.9. Folosirea asocierilor dintre CU
 Numele Subsistemul OPERA}IUNI
sistemului/subsistemului CEC

Emitere
Cazul de
a
carnetul
utilizare
1
ui CE
C
<<extend <<extend <<extend <<extend
s>> s>> s>> s>>

Caz Caz
Depune Restitui
deul deul
ri CE ri CE
utilizare
2 utilizare
3
C C

Numele Gestiunea operativ\ a

sistemului/subsistemului MPM
<<uses <<uses
Stocuri
CU CU
Gestiunea
>> >>
operativ\ a
MPM
<<includ
e>>
1 <<includ 2 <<includ
e>>
MPM
<<includ
e>> e>>

<<includ <<includ
e>> e>>

CU CU CU Intr\
ri
Ie[iri Transfe
r
MPM MPM
3 4 5 MPM

Numele Gestiunea operativ\ a contractelor de asiguare-

sistemului/subsistemului reasigurare
<<uses <<uses
Gestiun Poli]e
CU >>
CU ea
contract
>>
asigur

<<includ
e>>
1 <<exten 2 <<includ
e>>
e
asigurar
e
<<exten
are
ds> ds>

<<includ <<includ
e>> e>>
Opera]
CU CU CU Opera
]ii
Opera]i
i I
`ncasa
3 4 5 asigur
\ri
reasigu
r\ri re
prime
de
asigur
are

fig. 3.10. Elemente privind folosirea rela]iilor prin stereotipurile

<<uses>>,<<include>>,<<extends>>.

 Activarea CU  proiectanul trebuie s\ defineasc\ modul `n care actorul ini]iaz\ execu]ia

CU inclusiv situa]iile specifice de apel.
 Diagrama  proiectanul va trebui s\ identifice care mesaje sau evenimente vor fi
secven]elor princi executate de c\tre CU [i actorii care vor interschimba respectivele mesaje,
pale de mesaje `ntre inclusiv ac tualizarea [I reg\sirea sau `ntre]inerea informa]iilor. De
actori [i CU asemenea, proiectanul va trebui s\ precizeze cum vor fi descrise mesajele
dintre sistem [i actori, precum [i care entit\]i ale sistemului sunt utilizate
sau modificate.
 Diagrama  proiectanul va trebui s\ identifice care sunt execu]iile alternative
secven]elor secun depenedente de condi]ii sau excep]ii, prin intermediul unor scenarii ce vor
dare de mesaje `ntre defini modul de aplicare [i func]ionare al condi]iilor sau excep]iilor.
actori [i cazul de
utilzare
 Finalizarea ac]iunii  proiectanul va trebui s\ descrie `n ce mod CU va fi considerat finalizat [i
CU care tipuri de valori vor fi transmise actorilor.
Descrierea cazurilor de utilizare.poate presupune [i specificarea urm\toarelor aspecte
secundare:
Elemente privind descrierea CU Specifica]ii minimale
-coduri utilizate `n CU -sunt precizate codurile utilizate pentru CU,
intr\ri, procese, ie[iri etc
-principalele func]ii de gestiune realizate -vor fi indicate cerin]ele cadrului legal `n
de CU materie, paralel cu modul efectiv de ac]iune `n
condi]iile concrete ale AE
-actorii implica]i `n activarea [i utilizarea -codul actorilor implica]i [i modul `n care
CU(stereotipul <<actor>> ) interac]ionea z\ cu S
-asocierile utilizate `n CU -codurile mesajelor [i informa]iilor care circul\ pe
rela]ia informa]ional\ A->S
-proces\rile efectuate prin CU -logica [i semantica -proces\rilor efectuate prin
CU
-ie[irile ob]inute din proces\rile CU -codurile mesajelor [i informa]iilor care circul\ pe
rela]ia informa]ional\ S->A
-alte informa]ii considerate esen]iale -alte mesaje, informa]ii, procese, stereotipuri,
privind CU coduri considerate semnificative care circul\ pe
rela]ia A<->S<->CU

Toate aceste elemente definitorii trebuie s\ prezinte, sintetic [i exact, elementele

relevante ale actorilor externi prin intermediul unor descrieri clare [i consistente
2. Utilizarea Diagramelor de activitate au rolul de a descrie modelarea dinamic\ a sistemului
prin intermediul unor elemente de principiu, dintre care cele mai importante sunt urm\toarele:
 Modelul CU trebuie s\ con]in\ descrieri generale [i complete `n vederea descrierii
modului `n care scenariile actuale sunt utilizate `n vederea preciz\rii proceselor interne
specifice `n momentul `n care respectivul CU este instan]iat
 Modelul CU trebuie s\ permit\ comunica]ia direct\ [i facil\ cu utilizatorul, dar nu
descriere excesiv de formal\
 Ilustra]iile scenariului de descriere specifice unui CU trebuie s\ indice actorii [i CU
`n cadrul instan]elor actuale.

3.2.6. Testarea CU.

Testarea CU presupune fazele de verificare, validare [i testare-simulare descrise succint `n

continuare:

Tabel 3.4.
Testarea Descriere sintetic\
cazuri lor de
utilizare
Verificarea -verificarea confirm\ faptul c\ sistemul este dezvoltat corect sau este
acordat la specifica]iile solicitate [i con]inute `n cerin]ele impuse de
cadrul legislativ `n materie.
-testele specifice verific\rii sistemului atest\ faptul c\ specifica]iile sunt
sau nu `n conformitate cu cerin]ele acestuia(cerin]ele specifice ale
clientului, sistemului propriu de management [i organiza]ional)
-verificarea trebuie s\ demonstreze gradul de adaptare a sistemului la
solicit\rile utilizatorilor finali
Validarea -asigur\ c\ sistemul este dezvoltat `n viziunea orient\rii sale
preponderent c\tre client sau cerin]ele utilizatorilor finali sunt execuate
de c\tre sistem.
-validarea trebuie s\ arate dac\ sistemul este deschis c\tre un proces de
dezvoltare, iar acesta va putea fi descris prin intermediul unui model de
tip CU, orientat exclusiv c\tre clien]i [i utilizatorii finali.
-validarea trebuie s\ arate gradul `n care modelul de descriere este corect [i
complet [i dac\ acesta are `n vedere specifica ]iile de excep]ie ale sistemului.
Testarea [i -aceasta presupune c\ anumi]i “utilizatori finali fictivi” vor stabili cum
simu larea vor lucra efectiv actorii cu sistemul, cum vor fi executate diferite CU, sau
dac\ vor fi execuate toate cazurle de utlizare dup\ ce to]i actorii vor
interac]iona cu sistemul
-dac\ rezultatul acestei simul\ri este corect [i validat de c\tre cclientul
sistemului, atunci `nseamn\ c\ `ntregul test este corect realizat iar
modelul CU este complet
~n sintez\, rezult\ c\
exist\ o
coresponden]\
direct\ `ntre
perspectivele din
care proiectantul
vede sistemul, tipul
de model utilizat,
limbajul de
modelare utilizat [i
modelul/documentul
de reprezentare
 face Descrieri prin :
Perspectivele Tipul Limbajul
referin]e
asupra de de Modelul
la:
sistemului model modelare document

Sistemul
Descrierea
privit CAZUL CAZULUI
Text `n
din de limbaj natural de
UTILIZARE UTILIZARE
exterior

este o
realizare sau
implementare

este o Digrama
timp
instan]\ a: de
secevn]\

Interiorul COLABOR| RI spa]iu Diagrama de Descrierea

(context INTER-
grani]elor colabor\ ri
+ AC}IUNII
sistemului intrac]iune)
lucru Diagrama
con]ine de
unul
activitate

sau mai
este o multe scenarii
Diagrama
instan]\ timp de
din: secven]e
Direc]ia
Diagrama Descrierea
execu]iei spa]iu SCE-
de
prin SCENARII colabor\ ri NARIILOR
structura lucru
Diagrama
sistemului de
activitate

fig.3.11. Coresponden]a dintre perspectivele proiectantului: viziunea asupra sistemului, tipul de

model utilizat, limbajul de modelare utilizat [i modelul/documentul de reprezentare.

3.2.7. Realizarea CU.

CU vor implementa independent descrierile specifica]iilor sistemului func]ional, ceea ce `nseamn\

c\ respectivele CU sunt realizate `n sistem, prin intermediul urm\toarelor principii UML:

Tabel 3.5
principii UML utilizate `n Descriere sintetic\
realizarea CU

CU este realizat `n -colaborarea este o solu]ie intern\ de implemen tare a unui CU prin
colaborare folosirea termenilor de clase/obiecte [i rela]iilor specifice
acestora(denumite generic contextul colabor\rii) [i interac]iunile
utilizate `n vederea realiz\rii scopului privind
 func]ionalitatea(denumite generic interac]iunea colabor\rii)
-colaborarea este reprezentat\ prin intermediul unei elipse `n care se
va insera numele colabor\rii.
Colaborarea este repre -deoarece participan]ii la o colaborare au un num\r de clase,
zentat\ `n UML prin diagramele corespunz\toare sunt diagrame secven]\(viziunea
intermediul unui num\r de timpului),de colabo rare(viziunea spa]iului), [i activitate(viziunea de
diagrame ce arat\ contextul lucru)
[i interac]iunea dintre -rolul diagramelor de secven]\, colaborare [i activitate constau `n
participan]ii unei colabor\ri: reprezentarea corect\ [i consistent\ a colabor\rilor ce depind de CU
diagrame secven]\, actual.
colaborare [i activi tate. -men]ion\m c\ pot fi situa]ii `n care o singur\ diagram\ este suficient\
pentru reprezentarea CU, dar uneori pot fi necesare toate
diagramele men]ionate
Scenariul este privit ca o -scenariul este o cale de execu]ie specific\ eveni mentelor ce
instan]\ a unui CU sau reprezint\ instan]a specific\ unui CU
colabor\ri -utilizarea acestor scenarii este specific\:
-c`nd scenariul este vizualizat drept un CU va fi descris numai
contextul comportamental al actorilor
-c`nd scenariul este vizualizat ca o vizualizare a unei instan]e
asociate unei colabor\ri, atunci implementarea intern\ are `n vedere
utilizarea [i descrierea claselor, opera]iilor [i comunica]iilor dintre
acestea

Solu]ia trecerii de la colabor\ri la CU este redat\ `n figura 3.12, prin intermediul unui exemplu de
opera]iuni bancare particularizate prin clasele OPERA}II_CREDIT [i
PERA}II_CONTURI_CURENTE_BANCA RE, cu atributele specifice, [i colaborarea
OPERA}IUNI_BANCARE

. Use-case
colaborare <<realiz\ ri>>
OPERA}IUNI OPERA}IUNI
BANCARE BANCARE

implementare implementare Descrierea cazului de utilizare

OPERA}II_CREDIT
atributele clasei
………………….
verif_identitate_client()
verificare_bonitate()
OPERA}II_CONTUIR_
CURENTE_BANCARE
atributele clasei
………………….
verif_identitate_client()
identificare_tip_opera]ie()
1-verif_identitate_client()
2-verificare_bonitate()
3-verificare_garan]ii()
4-actualizare_cont_crt()
5-calcul_dob`nda_credit()
6-calcul_termen_final()
7-calcul_suma_final\ ()
8-identificare_tip_opera]ie()

verificare_garan]ii() verificare_sold_cont_curent() 9-verificare_sold_cont_curent()

actualizare_cont_crt() calcul_dob`nzi() 10-calcul_dob`nzi()

calcul_dob`nda_credit() calcul_penaliz\ ri() 11-calcul_penaliz\ ri()

calcul_termen_final() calcul_comisioane() 12-calcul_comisioane()

calcul_suma_final\ () operare_sume() 13-operare_sume()

actualizare_sold_final() 14-actualizare_sold_final()

fig. 3.12.conversia dintre colabor\ri-CU.

fig.3.13.DCU complex\ pentru activit\]ile PROGRAMAREA FABRICA}IEI, ATM, EVIDEN}A MPM, [i ANALIZA UT
P2: programe de fabrica]ie pe sec]ii/ateliere, P3: programe de fabrica]ie pe intervale calendaristice(lun
consum, NA: necesarul de ATM, PR-ATM: program de ATM, R1: program de fabrica]ie pe firm\, G-MPM
R2: Situa]ia intr\rilor de MPM, R3: Situa]ia consumurilor [i transferurilor de MPM, CP: comenzi de produc]
pe sec]ii, CTB-A: contabilitatea analitic\ a MPM, CTB-S: contabilitatea sintetic\ a MPM, R4: BVA pentru
operative la nivelul sec]iilor de fabrica]ie, EOF: eviden]e operative privind facturile de MPM, AZ-MPM: an
analiza `ncadr\rii `n NC la MPM, R7: Situa]ia utiliz\rii MPM, R8: Situa]ia consumurilor de MPM pe produse,

Descrierea CU.

Descrierea CU(exemplificare pentru PTF [i CTB- Explica]ii sintetice

MPM).
Denumirea CU PTF
-coduri utilizate `n CU PTF, CF, CR, NC, NA, R1, :PR-ATM, P1, P2, P3
-principalele func]ii de gestiune realizate -corelarea obiectivelor programului de fabrica]ie
de CU cu programul de ATM
-`ncadrarea `n normele de consum
-corelarea comenzilor de fabrica]ie-repara]ii cu
progra mul de ATM
-actorii implica]i `n activarea [i utilizarea Serviciul PTF
CU(stereotipul <<actor>> )
-asocierile A-A serviciul PTF--specializare--> serv ATM
serviciul PTF--specializare--> gestiuni de
MPM
-asocierile A-CU 1 la 1..12
-asocierile CU-CU <<use>>: CF, CR
<<include>>: NC, NA, R1, :PR-ATM
<<extends>>: P1, P2, P3
-proces\rile efectuate prin CU -corelarea programului de fabrica]ie cu
comenzile de fabrica]ie-repara]ii [I programul de
ATM, paralel cu `ncadrarea `n normele de
consum
-ie[irile ob]inute din proces\rile CU R1, PR-ATM
Denumirea CU CTB-MPM
-coduri utilizate `n CU PR-ATM, CTB-A, CTB-S, R4, R5, R6, EOS, EOF, AZ-

-principalele func]ii de gestiune realizate
de CU
-actorii implica]i `n activarea [i utilizarea
CU(stereotipul <<actor>> )
-asocierile CU-CU
-asocierile A-A
-asocierile A-CU
-proces\rile efectuate prin CU
-ie[irile ob]inute din proces\rile CU
MPM
-contabilittaea sintetic\ a MPM
-contabilittaea analitic\ a MPM
-elaborarea rapoartelor contabile R4, R5, R6
-serviciul Contabilitate, furnizori interni/externi,
transpor tatori interni/externi
<<use>>: PR-ATM, CTB-A, CTB-S
<<include>>: R4, R5, R6
<<extends>>:EOS, EOF, AZ-MPM
-serviciul ATM--specializare--> serv
Contabilitate
-Furnizor intern/extern--generalizare-->
Furnizor
-Transportator intern/extern--generalizare--
> Transpor tatori
1 la 1..*
-eviden]a analitic\ a MPM
-eviden]a analitic\ a facturilor interne/externe
-eviden]a analitic\ a cheltuielilor de transport
pe par curs intern/extern
R4, R5, R6