Cazuri de utilizare - sistem

I. Jacobson (inceputul anilor 1990)

Modelul cazurilor de utilizare:

Descrie comportamentul sistemului din punct de vedere al utilizatorului

Doua parti principate: sistem (incluzand componente si descrierea acestora) si utilizatori (elemente externe)

Cuprinde

Diagrama cazurilor de utilizare

Descrierea cazurilor de utilizare

Elementele diagramei cazurilor de utilizare:

Cazuri de utilizare (componente ale sistemului): unitate coerenta de functionalitate sau task; reprezentata printr-un oval

Actori (utilizatori ai sistemului): elemente externe care interactioneaza cu sistemul; reprezentati prin figurine

Asociatii de comunicare: legaturi intre actori si cazuri de utilizare; reprezentate prin linii solide

Observatie: fiecare dintre elementele componente reprezinta de fapt seturi de elemente (similar cu clasele)

Descrierea cazurilor de utilizare: un document (narativ) care descrie secventa evenimentelor pe care le executa un actor pentru a efectua un caz de utilizare

Actori

Un actor reprezinta un rol jucat de un utilizator.

Nu reprezinta un singur utilizator, ci o clasa de utilizatori.

Acelasi utilizator poate avea diferite roluri (Personal sau ClientCarte), dupa cum un rol poate fi avut de mai muti utilizatori (de obicei in practica)

Identificarea actorilor = identificarea rolurilor avute de utilizatori in cadrul sistemului

Pot exista actori primari si actori secundari:

Actorii primari sunt cei pentru care folosirea sistemului are o anumita valoare (beneficiari); de exemplu ClientCarte. De obicei actorii principali initiaza cazul de utilizare

Actorii secundari sunt cei cu ajutorul carora se realizeaza cazul de utilizare; de exemplu un sistem pentru gestiunea unei biblioteci, daca o carte inexistenta poate fi imprumutata de la aceasta biblioteca. Actorii secundari nu initiaza cazul de utilizare, dar participa la realizarea acestuia.

Numai actorii primari (beneficiarii) sunt de obicei reprezentati in diagrama cazurilor de utilizare

Pe de alta parte, atat actorii principali cat si cei secundari sunt mentionati in descrierea cazului de utilizare

Actorii pot fi atat actori umani cat si sisteme externe; de exemplu Internet (in cazul cand imprumutul se poate face prin Internet) sau un sistemul de gestiune al unui alt centru de inchieri.

Exista unii autori care sugereaza ca actorii trebuie sa fie doar umani, dar in acest caz este necesara o analiza suplimentara a sistemului exterior, pentru identificarea actorilor.

Cazuri de utilizare

Un caz de utilizare este o unitate coerenta de functionalitate.

Un caz de utilizare inglobeaza un set de cerinte ale sistemului care reies din specificatiile initiale si sunt rafinate pe parcurs.

Cazurile de utilizare pot avea complexitati diferite; de exemplu Imprumuta carte si Cauta carte

Observatie: Un caz de utilizare este o multime de scenarii referitoare la utilizarea unui sistem; un scenariu este o instanta a unui caz de utilizare; de exemplu, urmatoarele doua scenarii sunt instante ale cazului de utilizare Imprumuta caseta:

Persoana X imprumuta o caseta de la centru de inchirieri. Pentru ca ea nu mai are casete imprumutate, sistemul modifica informatia in mod corespunzator;

Persoana Y incearca sa imprumute o caseta de la centru de inchirieri, dar este refuzata pentru ca mai are deja imprumutate trei casete, adica numarul maxim posibil.

Un caz de utilizare trebuie sa fie insotit de o descriere; un sablon va fi furnizat mai tarziu

Aplicarea cazurilor de utilizare

Cazurile de utilizare se folosesc pentru a captura comportamentul pe care trebuie sa-l ia sistemul fara a specifica modul in care acest comportament este implementat; un caz de utilizare nu trebuie sa specifice si modul de implementare al acestuia; un caz de utilizare arata care este comportamentul sistemului, nu si cum este realizat acesta.

Cazurile de utilizare permit analistului sa comunice cu utilizatorii si dezvoltatorii (care construiesc sistemul ce trebuie sa satisfaca cerintele); la acest nivel detaliile sunt ignorate, ele vor fi luate in considerare mai tarziu.

Identificarea cazurilor de utilizare

O metoda de identificare a cazurilor de utilizare este bazata pe actori

i)        se identifica actorii unui sistem sau a unei organizatii

ii)      pentru fiecare actor se identifica cazurile de utilizare pe care le initiaza sau la care participa

O a doua metoda este baza pe evenimente

i)        se identifica evenimentele externe

ii)      se face legatura dintre aceste evenimente si actorii sau cazurile de utilizare

Pentru centrul de inchieriere prima metoda este mai naturala

Frontiera sistemului

Este important de a defini frontiera sistemului astfel incat sa se poate face distinctia intre mediul extern si mediul intern (responsabilitatile sistemului)

Cazurile de utilizare sunt inauntru, iar actorii in afara

Daca se dezvolta un sistem software frontiera se stabileste la frontiera hardware si software

Trasarea frontierei este optionala; este indicata atunci cand exista mai multe subsisteme, pentru a le delimita clar

Relatii dintre cazuri de utilizare

Relatia <<include>>

Cea mai intalnita situatie este cea in care doua sau mai multe cazuri de utilizare au o componenta comuna, care poate fi reutilizata la definirea fiecaruia dintre ele.

In acest caz componenta refolosita este reprezentata tot printr-un caz de utilizare legat prin relatia « include » de fiecare dintre cazurile de utilizare de baza.

Practic relatia « include » arata ca secventa de evenimente descrisa in cazul de utilizare inclus se gaseste si in secventa de evenimente a cazului de utilizare de baza.

Sageata este orientata catre cazul de utilizare care este folosit si este etichetata cu numele stereotipului « include ». Aceasta notatie este facuta prin analogie cu notatia pentru apelul unei subrutine (sageata de dependenta).

Pentru mai multa claritate, putem spune ca scenariile care reprezinta instante ale cazului de utilizare de baza contin subscenarii ce sunt instante ale cazului de utilizare inclus.

Atunci cand cazul de utilizare inclus se schimba, acest lucru va afecta cazul de utilizare de baza, in schimb cazul de utilizare inclus nu va depinde de cazul de utilizare de baza.

Documentarea unei astfel de functionalitati intr-o diagrama de cazuri de utilizare are mai multe avantaje.

In primul rand, este un mod convenabil de a inregistra decizia ca o componenta sa fie reutilizata sau de a evita inregistrarea aceleiasi informatii de mai multe ori.

In al doilea rand, separarea anumitor parti din descrierea unui caz de utilizare poate face ca aceasta sa fie mai scurta sau mai usor de inteles.

In sfarsit, identificarea functionalitatilor comune intre cazurile de utilizare poate fi un mod de a descoperi posibilele reutilizari ale unei componente ce poate fi implementata o singura data.

Relatia <<extend>>

Relatia « extend » se foloseste pentru separarea diferitelor comportamente ale cazurilor de utilizare.

Daca un caz de utilizare contine doua sau mai multe scenarii semnificativ diferite (in sensul ca se pot intampla diferite lucruri in functie de anumite circumstante), pentru a clarifica anumite aspecte se poate lua decizia de a reprezenta aceste scenarii ca un caz de utilizare principal si unul sau mai multe cazuri de utilizare exceptionale.

De obicei, se folosete pentru a pune in evidenta exceptiile. De exemplu, putem separa cazul de utilizare Imprumuta carte intr-un caz de utilizare frecvent intalnit (principal), in care utilizatorului ii este permis sa imprumute o caseta si un caz de utilizare mai rar intalnit (exceptional), in care utilizatorului ii este refuzat imprumutul deoarece depaseste numarul maxim de casete permise.

Puncte de extensie

Generalizare

Spre deosebire de celelalte relatii, acest tip de relatie poate exista atat intre doua cazuri de utilizare cat si intre doi actori.

generalizare intre doua cazuri de utilizare indica faptul ca un caz de utilizare poate mosteni comportamentul definit in unul sau mai multe cazuri de utilizare.

generalizare intre actori arata ca un actor mosteneste structura si comportamentul unuia sau a mai multor actori.

Relatia de generalizare intre doua cazuri de utilizare este destul de apropiata din punct de vedere conceptual de relatia de tip « extend ». Pentru a le diferentia, putem lua decizia de a folosi o relatie « extend » daca se doreste descrierea unui comportament exceptional care depinde de o conditie testata in timpul executiei si de a folosi generalizarea pentru a evidentia o anumita versiune a unui task.

Sablon pentru descrierea cazurilor de utilizare

Derek Coleman (1998)

Caz de utilizare

Fiecare caz de utilizare trebuie sa aiba un nume unic ce va sugera scopul sau.

Numele trebuie sa exprime ce se intampla atunci cand se executa cazul de utilizare.

Este recomandabil ca numele sa inceapa cu un verb, de exemplu Plaseaza ordin.

Este convenabil sa se introduca si un numar de referinta pentru a indica legaturile cu alte cazuri de utilizare.

Campul trebuie sa mai contina si o istorie a crearii si modificarii cazului de utilizare precedata de cuvantul cheie istorie.

Descriere

Fiecare caz de utilizare trebuie sa contina o scurta descriere a scopului principal in care este executat.

Aceasta descriere trebuie sa contina si sursa de provenienta a cerintelor functionale precedata de cuvantul cheie surse.

Actori

Contine lista actorilor implicati in executia cazului de utilizare.

In mod optional un actor poate fi indicat ca primar sau secundar.

Un actor primar este direct interesat de executia cazului de utilizare beneficiind de pe urma lui (este beneficiar al sistemului).

Un actor secundar este cel de la care cazul de utilizare cere ajutor pentru a se putea executa.

Ipoteze

Contine lista tuturor ipotezelor necesare ca un caz de utilizare sa se execute cu succes.

Fiecare ipoteza trebuie sa fie exprimata printr-o expresie ce poate fi adevarata sau falsa.

Daca o ipoteza este falsa atunci nu se va specifica ce trebuie sa faca in aceasta situatie cazul de utilizare deoarece acest lucru va fi exprimat cu ajutorul relatiei « extend ».

Cu cat un caz de utilizare are mai putine ipoteze cu atat acesta este mai robust.

Pasi

Interactiunile dintre actori si sistem sunt structurate in unul sau mai multi pasi exprimati intr-un limbaj natural.

Un pas este terminat atunci cand toate interactiunile componente sunt terminate.

Un pas are urmatoarea forma:

<numar secvential><interactiune>

Executia unuia sau mai multor pasi poate fi facuta conditional utilizand constructia if-then-else din limbajele de programare. De exemplu:

1. IF test THEN 1.1 interactiunea a

1.2 interactiunea b

ELSE 1.3 intercatiunea c

Pentru a indica repetarea unui grup de interactiuni se poate folosi constructia while-do sau repeat-until. De exemplu:

1. REPEAT

1.1 interactiunea a

1.2 interactiunea b

UNTIL test

Daca un numar de interactiuni trebuie sa se execute in paralel atunci vom folosi:

IN PARALLEL <interactiune>||<interactiune>||..

sau

CONCURRENTLY DO <interactiune>||<interactiune>||..

Un pas ce contine mai multe interactiuni concurente este terminat atunci cand toate interactiunile componente sunt terminate. De exemplu:

1.IN PARALLEL interactiunea a||interactiunea b||interactiunea c

2.interactiunea d

reprezinta faptul ca interactiunea a interactiunea b si interactiunea c opereaza concurential. Ordinea in care interactiunile incep si se sfarsesc nu este specificata, dar pasul 2 nu poate incepe pana cand executia tuturor acestora nu va fi teminata.

Daca ordinea in care incep interactiunile este cunoscuta, atunci se pot subnumerota pasii (vezi exemplul de mai jos). Si in aceasta situatie ordinea in care interactiunile se sfarsesc nu este specificata.

1.IN PARALLEL 1.1 interactiunea a||

1.2 interactiunea b||1.3 interactiunea c

2.interactiunea d

Alternative

Pentru a se furniza mai multe amanunte despre un anumit pas se pot descrie toate alternativele intalnite, mai precis modul in care a inceput executia unui pas. O alternativa are urmatorul format:

<numar pas><lista alternativelor separate prin or>

De exemplu:

Cumparatorul transmite o cerere de cumparare

atunci alternativele pot fi:

#1.Cumparatorul poate telefona, or

transmite un fax, or

utiliza Internetul

Cerinte non-functionale

cerinta non-functionala poate fi descrisa prin urmatorul format:

<cuvant cheie>:<cerinte>

Cuvintele cheie pot fi performanta, fiabilitate, toleranta la erori, frecventa si prioritate. Aceasta lista de cuvinte cheie ale cerintelor non-functionale nu este limitata numai la cuvintele enumerate mai sus.

Probleme

Contine lista problemelor ce asteapta rezolvare. In afara de aceasta lista se pot face si diferite notari despre strategiile posibile de implementare sau impactul asupra altor cazuri de utilizare.

Exemplu de utilizare a sablonului

Exemplul urmator contine descrierea unui caz de utilizare referitor la repararea unei retele de telefonie mobila. Scopul acestuia este repararea retelei de catre operator (actorul principal). Un alt actor implicat in efectuarea cazului de utilizare este si inginerul ce administreaza reteaua. Sursele de informatii pentru cazul de utilizare sunt [Manualul Operatorului 1999] si [Reguli 2001]. Pentru ca acest caz de utilizare sa se execute cu succes, se presupune ca orice modificare facuta asupra retelei de telefonie mobila nu va esua.

Descrierea relatiilor « include »

Atat descrierea cazului de utilizare de baza cat si a cazului de utilizare inclus se face folosind sablonul de mai sus.

Pentru a arata aceasta relatie, cazul de utilizare de baza va contine un pas ce apeleaza cazul de utilizare inclus. Acest lucru este exprimat prin cuvantul cheie INCLUDE, prin analogie cu apelul unei subrutine.

De exemplu, cazul de utilizare de baza Imprumuta carte va contine:

INCLUDE Verificare rezervare

In locul cuvantului cheie INCLUDE pot fi folosite si cuvantele cheie PERFORM sau USING

Descrierea relatiilor « extend »

sablon de descriere a cazului de utilizare exceptional:

Forma si semantica noilor campuri este urmatoarea:

Extensie caz de utilizare

Include un identificator unic al cazului de utilizare exceptional si o referinta catre cazul de utilizare principal asupra caruia este aplicata aceasta extensie.

Modificari

Descrie scopul in care e folosit cazul de utilizare exceptional, mai exact situatia in care ipoteza cazului de utilizare principal este falsa.

Pasi

Modificarile asupra pasilor cazului de utilizare principal la punctul de extensie se exprima cu ajutorul urmatorului format:

<numar pas> if <conditie>
then <modificari asupra pasului>

Exemplu:

Importanta cazurilor de utilizare

Cazurile de utilizare descriu functionalitatea (modul de folosire) sistemului; functionalitatea asa cum este ea perceputa de utilizatori (actorii externi)

Scopul final al sistemului este de a realiza functionalitatea descrisa in modelul cazurilor de utilizare (alaturi de cerintele nefunctionale)

Modelul cazurilor de utilizare este folosit pentru dezvoltarea si testarea sistemului (in toate fazele de dezvoltare)

Analiza: modelul cazurilor de utilizare este folosit pentru a captura functionalitatea ceruta si de a valida aceasta functionalitate cu clientii

Design si Implementare: cazrile de utilizare trebuie realizate

Testare: Cazurile de testare verifica sistemul; ele devin baza pentru generare de cazuri de testare