Diagrama cazurilor de utilizare (Use Case Diagram)

Diagrama cazurilor de utilizare (Use Case Diagram)

Un model use case este descris folosind una sau mai multe diagrame use case.

Acestea contin urmatoarele elemente de modelare: actori, cazuri de utilizare si diferite

relatii intre aceste elemente: generalizare, asociere, dependenta.

Actorul

Un actor poate fi orice sau oricine interactioneaza cu sistemul, adica trimite sau

receptioneaza mesaje de la sistem sau schimba informatii cu acesta. Actorul joaca un rol

in cadrul sistemului, nu este un utilizator individual al acestuia, prin urmare reprezinta un

tip (o clasa) nu o instanta. "Studentul Popescu vrea sa imprumute o carte de la

biblioteca", rolul lui este de abonat al bibliotecii. Orice mesaj trimite actorul sistemului

este un caz de utilizare, cateodata numit si stimul.

Un actor poate fi:

Ø Actor primar, daca foloseste functionalitatea de baza a sistemului, de exemplu

intr-un sistem de biblioteca, bibliotecarul, sau

Ø Actor secundar, daca foloseste functionalitatea secundara, cum ar fi gestionarea

unei baze de date, comunicare, backup si alte operatii administrative.

O alta clasificare ar fi in:

Ø Actori activi, care initiaza cazurile de utilizare, sau

Ø Actori pasivi, care participa numai in unul sau mai multe cazuri de utilizare.

Identificarea actorilor

Operatia de identificare a actorilor revine la a stabili care sunt entitatile interesate

de utilizarea sistemului sau de interactiunea cu acesta. Pentru aceasta putem sa ne folosim

de urmatoarele intrebari:

Ø Cine va folosi functionalitatea principala a sistemului (acestia vor fi actorii

principali)?

Ø Cine va avea nevoie de sistem in munca de zi cu zi?

Ø Cine va administra si tine in stare de functionare sistemul (acestia vor fi actorii

secundari)?

Ø Ce unitati (device-uri) hardware vor avea nevoie de sistem?

Ø Cu ce alte sisteme va interactiona? Aceste pot fi impartite in sisteme (sisteme de

calculatoare, aplicatii) care vor initia un contact cu sistemul sau sisteme pe care

acesta le va contacta.

Ø Cine este interesat de rezultatele (valorile) generate de sistem?

Modul de reprezentare a actorilor in cadrul diagramelor de modelare UML este

prezentat in Figura 1.

Figura 1: Reprezentarea actorilor in UML.

Cazuri de utilizare

Un caz de utilizare reprezinta o functionalitate completa a sistemului, asa cum este

ea perceputa de un actor. In UML el este definit ca: "un set de secvente de actiuni pe care sistemul le realizeaza pentru a furniza o valoare unui actor particular". Actiunile pot presupune comunicarea cu un numar de actori (utilizatori sau alte sisteme) sau realizarea unor calcule in interiorul sistemului.

Caracteristicile cazurilor de utilizare sunt:

Ø Un caz de utilizare este initiat intotdeauna de un actor; actorul trebuie sa ceara

direct sau indirect sistemului realizarea unui caz de utilizare;

Ø Un caz de utilizare furnizeaza o valoare unui actor;

Ø Un caz de utilizare trebuie sa fie complet. O greseala frecvent intalnita este sa

impartim un caz de utilizare in altele mai mici si sa le implementam ca apeluri de

functii in limbajele de programare. Un caz de utilizare nu este complet pana cand

nu este produsa valoarea finala, chiar daca pentru aceasta sunt necesare cateva

dialoguri.

Un caz de utilizare este o clasa nu o instanta a acesteia. Clasa descrie

functionalitatea ca un intreg, incluzand alternative posibile, erori si exceptii care pot sa

apara pe parcursul executiei. O instantiere a unui caz de utilizare se numeste scenariu si

reprezinta o utilizare actuala a sistemului, de exemplu "Studentul Popescu cere

bibliotecarului sa-i faca o rezervare pentru cartea de UML care in momentul respectiv

nu este disponibila".

Cazurile de utilizare sunt conectate cu actorii prin asocieri, numite si asocieri de

comunicare. In mod normal acestea sunt relatii unu-la-unu nedirectionate ceea ce

inseamna ca o instanta actor comunica cu o instanta a cazului de utilizare si ca aceasta

comunicare este in ambele sensuri.

Identificarea cazurilor de utilizare

Procesul de identificare a cazurilor de utilizare incepe de la actorii deja identificati.

Pentru fiecare actor se vor pune urmatoarele intrebari:

Ø Care sunt functiile pe care actorul le asteapta de la sistem? Ce trebuie sa poata

face actorul?

Ø Are nevoie actorul sa citeasca, sa creeze, sa modifice, sa distruga sau sa pastreze

anumite tipuri de informatii in sistem?

Ø Trebuie sa stie actorul de aparitia unui anumit eveniment in sistem? Ce

functionalitate reprezinta aceste evenimente?

Ø Poate actorul sa-si simplifice munca de zi cu zi sau sa lucreze mai eficient

folosind functii noi ale sistemului?

Sau alte intrebari care nu presupun un actor curent:

Ø Ce intrari/iesiri sunt necesare in sistem? De unde vin acestea si unde merg?

Ø Care sunt problemele majore in implementarea curenta a acestui sistem? Poate fi

inlocuit un sistem manual cu unul automat?

Figura 2: Reprezentarea cazurilor de utilizare

Relatii intre cazurile de utilizare

Sunt trei tipuri de relatii ce pot fi definite intre cazurile de utilizare: extindere,

utilizare si grupare.

Relatia de extindere

Relatia de extindere este o generalizare a unui use case prin adaugarea de actiuni

noi. Un extend poate include comportamentul use case-ului extins, in functie de conditiile

de extindere. Un use case extins poate gestiona exceptiile specifice cazurilor din use

case-ul general care nu sunt usor de tratat in acesta, sau care apar in sistem pe masura

dezvoltarii lui. O relatie de extindere intre cazuri de utilizare este vazuta ca o

generalizare (se foloseste stereotipul <<extend>>).

Relatia de utilizare

Cand mai multe cazuri de utilizare au un comportament comun, acesta poate fi modelat

intr-un singur caz de utilizare si apoi folosit si de altele. Daca use case-ul nu este folosit

niciodata direct se numeste caz de utilizare abstract. O relatie de utilizare foloseste

stereotipul <<uses>>.

Daca mai multe cazuri de utilizare gestioneaza functiuni similare sau sunt intr-un fel

legate unul de altul, acestea pot fi grupate in pachete UML. Pachetele nu au un inteles

semantic.

Descrierea cazurilor de utilizare

Descrierea cazurilor de utilizare se face de obicei printr-un text care contine o

specificare simpla dar consistenta a modului de interactiune intre actori si cazurile de

utilizare ale sistemului. Aceasta va surprinde comportamentul sistemului si va ignora

modul in care acesta va fi implementat in sistem.

Descrierea va contine:

Ø Obiectivele cazurilor de utilizare;

Ø Cum este initiat un caz de utilizare? Ce actori initiaza executia si in ce situatii?

Ø Care este fluxul de mesaje intre actori si cazurile de utilizare;

Ø Fluxul alternativ in cazurile de utilizare; Un caz de utilizare poate sa aiba o

executie alternativa in functie de anumite conditii sau exceptii;

Ø Cand un caz de utilizare este considerat terminat, si care va fi valoarea transmisa

actorului;

Un caz de utilizare poate fi descris printr-o diagrama de activitate, care va permite

vizualizarea secventelor de activitati, ordinea lor si optional deciziile luate pentru a

specifica operatia care urmeaza a fi realizata. Trebuie sa retinem un lucru important:

modelul cazurilor de utilizare trebuie sa fie usor de comunicat utilizatorului/clientului.

Daca mai multe cazuri de utilizare gestioneaza functiuni similare sau sunt intr-un fel

legate unul de altul, acestea pot fi grupate in pachete UML. Pachetele nu au un inteles

semantic

Descrierea cazurilor de utilizare

Descrierea cazurilor de utilizare se face de obicei printr-un text care contine o

specificare simpla dar consistenta a modului de interactiune intre actori si cazurile de

utilizare ale sistemului. Aceasta va surprinde comportamentul sistemului si va ignora

modul in care acesta va fi implementat in sistem.

Descrierea va contine:

Ø Obiectivele cazurilor de utilizare;

Ø Cum este initiat un caz de utilizare? Ce actori initiaza executia si in ce situatii?

Ø Care este fluxul de mesaje intre actori si cazurile de utilizare;

Ø Fluxul alternativ in cazurile de utilizare; Un caz de utilizare poate sa aiba o

executie alternativa in functie de anumite conditii sau exceptii;

Ø Cand un caz de utilizare este considerat terminat, si care va fi valoarea transmisa

actorului

Un caz de utilizare poate fi descris printr-o diagrama de activitate, care va permite

vizualizarea secventelor de activitati, ordinea lor si optional deciziile luate pentru a

specifica operatia care urmeaza a fi realizata. Trebuie sa retinem un lucru important:

modelul cazurilor de utilizare trebuie sa fie usor de comunicat utilizatorului/clientului.

Dupa ce au fost descrise cazurile de utilizare vor trebui specificate relatiile

existente intre acestea. Intrebarile care vor trebui puse in aceasta faza sunt:

Ø Toti actorii implicati comunica cu cazuri de utilizare?

Ø Sunt asemanari intre actori, poate fi descrisa o clasa actor de baza

Ø Sunt asemanari intre cazurile de utilizare existente? Exista un flux comun de

activitati care sa poata fi descris ca o relatie de utilizare a unui caz de utilizare?

Ø Exista cazuri de utilizare care sa poata fi descrise ca extend-uri?

Ø Sunt actori sau cazuri de utilizare fara asocieri de comunicare? Daca exista asa

ceva este gresit!

Ø Sunt cerinte functionale inca necuprinse in cazuri de utilizare? Daca da, vor

trebui rezolvate.

Cazurile de utilizare sunt folosite si la testarea sistemului; sunt doua tipuri de teste

care se pot realiza: verificarea, in care se confirma sau nu daca sistemul a fost dezvoltat

corect, in acord cu specificatiile cerute si respectiv validarea, care verifica daca sistemul

construit este util pentru client si utilizatorul final.