Curs 2 Page 1 of 6

Analiza si gestiunea sistemelor informatice complexe

Curs 2
Objectory. UML. Diagrame de cazuri de utilizare

Objectory

Procesul Objectory de dezvoltare a unui sistem informatic este structurat pe dou dimensiuni:
- dimensiunea temporal: diviziunea ciclului de via al sistemului informatic n faze i iteraii
- componentele procesului producerea unei mulimi specifice de elemente (documente, diagrame, etc) i a unor activiti bine definite

Componentele procesului au fost detaliate in cursul precedent, acestea fiind: culegerea de specificatii (analiza functionala), analiza, proiectarea,
implementarea si testarea.

Structurarea unui proiect n funcie de dimensiunea temporala induce urmtoarele faze:

- Lansare specificarea succint a proiectului
- Elaborarea planificarea activitilor necesare i a resurselor necesare. Specificarea caracteristicilor i proiectarea arhitecturii
- Construcie construirea produsului printr-o serie de iteraii incrementale
- Tranziie furnizarea produsului comunitii (distribuire, instruire etc)

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 2 Page 2 of 6

Figura 1. Procesul de dezvoltare a sistemelor informatice (Rational Objectory)

UML (Unified Modeling Language)

n anii 90 a aprut o serie de metode de dezvoltare a aplicaiilor, fiecare dintre acestea introducnd notaii (grafice sau formale) particulare. Printre
cele mai populare metode se numrau:
- OMT (Object Modeling Technique) James Rumbaugh
- OOD (Object Oriented Design) Greedy Booch
- OOSE (Object-Oriented Software Engineering) Ivar Jacobson

Fiecare dintre aceste metode avea puncte tari i slabe. OMT era potrivit pentru etapa de analiz, OOD pentru etapa de proiectare iar OOSE avea n
vedere n special etapa de analiz comportamental. Anii 90 sunt caracterizai de aa-numitul 'rzboi al metodelor', n care fiecare dintre autori (numii i
guru) ncerca s impun propria metod de analiz i proiectare a aplicaiilor.

Limbajul UML s-a nscut din dorina de a unifica cele mai importante concepte introduse de fiecare dintre aceste metode precum i pentru a gsi o
notaie standard de modelare a acestor concepte.

n septembrie 1997 'rzboiul metodelor' ia sfrit prin adoptarea de ctre OMG a limbajului UML ca limbaj standard de modelare a aplicaiilor. OMG
(Object Management Group) reprezint un consoriu internaional al crui obiectiv principal l constituie promovarea abordrii orientate obiect n cadrul
ingineriei softului.

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 2 Page 3 of 6

Limbajul UML s-a format avnd la baz cele trei metode amintite mai sus, la care se adaug contribuii notabile n diverse faze ale etapelor de analiz
i proiectare: clasificare Odell, hri de stri David Harel, ciclu de via al obiectelor Shlaer-Mellor, abloane de proiectare Gamma .a. etc.

UML reprezint un standard de notaie. Introduce un numr de 9 diagrame de descriere a unui sistem informatic i semantica acestor diagrame. UML nu
propune i un proces de utilizare a acestor diagrame n construcie unei aplicaii.

Cele nou tipuri de diagrame propuse de UML sunt:

- de activiti,
- de cazuri de utilizare,
- de clase,
- de colaborare,
- de componente,
- de exploatare,
- de obiecte,
- de secven,
- de stri.

Aceste diagrame pot fi mprite n 3 categorii:

- diagrame statice descriu structura i responsabilitaile sistemului informatic (diagramaele de cazuri de utilizare, clase, obiecte)
- diagrame dinamice descriu comportamentul i interaciunile care au loc ntre diverse entiti n cadrul sistemului informatic (diagrame de activiti,
colaborare, secven, stri, cazuri de utilizare)
- diagrame arhitecturale descrie componentele executabile ale sistemului i determin loacaiile fizice de execuie i nodurile de stocare a datelor
(diagrame de componete, exploatare)

Diagrame de cazuri de utilizare

Una dintre condiiile ce trebuiesc indeplinite ca un proiect sa aib succes este aceea ca cerinele proiectului s fie definite ntr-o manier care s
permit o uoar nelegere, indiferent de nivelul de pregtire informatica al celui care este implicat n proiect. De asemenea, modificrile ce apar pe
parcurs n cerine trebuie s fie cu uurin asimilate de ctre membrii echipei de dezvoltare. Diagramele de cazuri de utilizare au rolul de a reprezenta intr-
o forma grafica functionalitatile pe care trebuie sa le indeplineasca sistemul informatic in faza sa finala. De aceea modelul realizat de diagramele de cazuri
de utilizare alaturi de documentele de descriere succinta a fiecarui caz de utilizare determinat poarta numele de model al cerinelor.

Diagramele de cazuri de utilizare sunt formate din doua categorii de entitati (actori si cazuri de utilizare) si relatii intre acestea.

Actorii sunt roluri jucate de diverse persoane sau sisteme informatice i care interacioneaz cu sistemul informatic aflat n dezvoltare. Este important de
retinut faptul ca o persoan poate juca mai multe roluri i un rol poate caracteriza mai multe persoane. Reprezentare grafica a actorilor in UML este un
omulet stilizat avand la subsol un text ce reprezinta rolul jucat de actor (figura 2).

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 2 Page 4 of 6

Figura 2. Reprezentarea grafica a actorilor in UML

Determinarea actorilor se face rspunzand la ntrebrile:

- cine ce este interesat,
- cine modifica date,
- cine se interfaeaz, sau
- cine dorete informaii de la sistem.

Raspunsurile concrete la cele patru intrebari de mai sus se introduc intr-o asa-numita tabel de evenimente cu 4 coloane: Subiect(actor), Verb, Obiect,
Frecven. Aceasta tabela de evenimente permite de asemenea detectarea tuturor cazurilor de utilizare a sistemului.

Cazurile de utilizare reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care sunt nrudite din punct de vedere comportamental. Practic, un
caz de utilizare modeleaza un dialog intre un actor si sitemul informatic. Multimea de cazuri de utilizare a unui sistem reprezinta toate modalitatile in care
sistemul poate fi folosit.

Cazurile de utilizare :
- sunt uniti de sine stttoare, bine delimitatate (nceputul i sfritul unui caz de utilizare sunt cuprinse n acesta).
- trebuie s fie iniiate de un actor i terminarea lor s fie 'vzut' de un actor
- trebuie s ndeplineasc anumite scopuri de de logica a problemei (dac nu se poate gsi un astfel de obiectiv atunci cazul de utilizare trebuie
regndit)
- trebuie s lase sistemul ntr-o stare stabil (nu poate fi ndeplinit doar pe jumtate)

Cazurile de utilizare sunt orientate pe scop: reprezint ceea ce sistemul trebuie s fac i nu cum. Ele sunt neutre din punct de vedere tehnologic, potand fi
utilizate n orice proces sau arhitectur de aplicaie.

Reprezentarea grafica a cazurilor de utilizare in UML se realizeaza prin intermediul unui oval avznd la baza numele cazului de utilizare (figura 3).

Figura 3. Reprezentarea grafica a cazurilor de utilizare in UML

Fiecare caz de utilizare ce apare in una din diagramele ce modeleaza functionalitatea sistemului informatic trebuie sa fie insotite de un document de
descriere a sa ce va respecta urmatorul sablon:

Nume
Descriere
Autori
Stare
Prioritate
Precondiii

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 2 Page 5 of 6

Postcondiii
Calea principal (sau BCE - Basic Course of Events)
Ci alternative (sau ACE - Alternate Course of Events)
Ci de excepie

Relatii ntre actori i cazuri de utilizare:

- relatia de asociere (comunicare) (figura 4) - directia de navigare a relatiei (sageata) sugereaza cine initiaza comunicarea. In general comunicare
intre actor si caz de utilizare este bi-directionala

Figura 4. Reprezentarea grafica relatiei de comunicare intre

actori si cazuri de utilizare

Relaii ntre cazuri de utilizare (figura 5):

- relatia de utilizare: are loc intre un caz de utilizare si oricare alt caz de utilizare ce utilizeaza functionalitatea acestuia. Se reprezinta grafic printr-o linie
avand la capatul corespunzator cazului de utilizare folosit un triunghi si este etichetat cu stereotipul <<Uses>> (stereotipul este un concept introdus in UML
care permite extinderea elementelor de modelare de baza pentru a creea noii elemente).
- relatia de extindere: este folosita pentru a sugera un comportament optional, un comportament care are loc doar in anumite conditii sau fluxuri
diferite ce pot fi selectate pe baza selectiei unui actor. Reprezentarea grafica este similara cu cea a relatiei de utilizare, dar eticheta este <<Extends>>.

Figura 5. Reprezentarea grafica a relatiilor de extindere si utilizare

intre cazuri de utilizare

Relaii ntre actori (figura 6):

- relatia de generalizare: semnifica faptul ca un actor poate interactiona cu sistemul in toate modalitatile prin care interactioneaza un altul. Se
reprezinta ca o relatie de extindere intre doua cazuri de utilizare fara a avea stereotip.

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com
 Curs 2 Page 6 of 6

- relatia de dependen: semnifica faptul ca, pentru a interactiona cu sistemul informatic prin intermediul unui caz de utilizare, un actor depinde de alt
actor. Se reprezinta printr-o linie franta avand la un capat o sageata.

Figura 6. Reprezentarea grafica a relatiilor de generalizare si dependenta

intre actori

Observatie: Exista o serie de cazuri de utilizare asa-zis 'ascunse' care nu sunt identificate intotdeauna in fazele analizei functionale (in special din cauza
faptului ca interlocutorii nu sunt familiarizati cu informatica): securitate, arhivare, infrastructura arhitectural, verificare. Se recomanda introducerea acestor
cazuri de utilizarea in toate modelele de cerinte.

http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/Curs2.htm 3/2/03
PDF created with FinePrint pdfFactory trial version http://www.pdffactory.com