5 Modelarea Cazurilor de Utilizare 1

7/26/2019 5 Modelarea Cazurilor de Utilizare 1

http://slidepdf.com/reader/full/5-modelarea-cazurilor-de-utilizare-1 1/7

Modelarea cazurilor de utilizare 1

Modelarea cazurilor de utilizare

Un caz de utilizare este o tehnica de modelare folosit pentru a descrie ce va face unsistem nou sau ce face deja un sistem existent. Modelarea cazurilor de utilizare a fostfolosit pentru prima dat de Ivar Jacobson în metodele de modelare OOSE #i Objectory.Scopul urmrit în acest tip de modelare este descrierea func&ionalit&ii sistemului a#a cumaceasta este vzut din exterior de un numr de actori #i a conexiunilor acestora lacazurile de utilizare furnizate de sistem. A#adar, pentru crearea modelului cazurilor deutilizare vor trebui identifica&i actorii, cazurile de utilizare, rela&iile dintre acestea cât #irela&iile cu actorii. Toate aceste faze presupun discu&ii cu clien&ii #i eventual cu persoanele care reprezint actorii.

În aceast faz de modelare sistemul este vzut ca o “cutie neagr ”, care trebuie s poatrealiza anumite sarcini, f r a ne interesa cum le face, cum vor fi implementate, sau cumlucreaz intern. Scopul principal al construirii acestui tip de diagram este:

S decid #i s descrie cerin&ele func&ionale ale sistemului, cerin&e care au fost dedusedup o discu&ie între client #i/sau utilizatorii sistemului #i viitorii dezvoltatori ai acestuia.S ofere o descriere clar #i consistent a ce va trebui s fac sistemul, prin urmaremodelul este folosit pentru comunicarea cerin&elor tuturor persoanelor implicate înconstruirea sistemului #i s constituie un punct de plecare în realizarea muncii viitoare(alte modele, design arhitectural, implementarea propriu-zis).

S constituie o baz pentru realizarea testelor de verificare dac func&ionalitatea final asistemului concord cu cerin&ele ini&iale ale acestuia.S permit o transformare u#oar a cerin&elor func&ionale în viitoare clase #i opera&ii.

D i ag r a ma ca z u r i l o r d e u t i l i z a r e (Use Case D i a g r a m )

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

Acestea con&in urmtoarele elemente de modelare: actori, cazuri de utilizare #i diferite

rela&ii între aceste elemente: generalizare, asociere, dependen&.

Actorul

Un actor poate fi orice sau oricine interac&ioneaz cu sistemul, adic trimite sau

recep&ioneaz mesaje de la sistem sau schimb informa&ii cu acesta. Actorul joac un rol

PDF created with FinePrint pdfFactory Pro trial version http://www.fineprint.com

http://www.fineprint.com/





în cadrul sistemului, nu este un utilizator individual al acestuia, prin urmare reprezint un

tip (o clas) nu o instan&. “Studentul Popescu vrea s împrumute o carte de la

bibliotec”, rolul lui este de abonat al bibliotecii. Orice mesaj trimite actorul sistemului

este un caz de utilizare, câteodat numit #i stimul .

Un actor poate fi:

Ø Actor primar , dac folose#te func&ionalitatea de baz a sistemului, de exemplu

într-un sistem de bibliotec, bibliotecarul, sau

Ø Actor secundar , dac folose#te func&ionalitatea secundar , cum ar fi gestionarea

unei baze de date, comunicare, backup #i alte opera&ii administrative.

O alt clasificare ar fi în:

Ø Actori activi, care ini&iaz cazurile de utilizare, sau

Ø Actori pasivi, care particip numai în unul sau mai multe cazuri de utilizare.

Identificarea actorilor

Opera&ia de identificare a actorilor revine la a stabili care sunt entit&ile interesate

de utilizarea sistemului sau de interac&iunea cu acesta. Pentru aceasta putem s ne folosim

de urmtoarele întrebri:

Ø Cine va folosi func&ionalitatea principal a sistemului (ace#tia vor fi actorii

principali)?

Ø Cine va avea nevoie de sistem în munca de zi cu zi?

Ø Cine va administra #i &ine în stare de func&ionare sistemul (ace#tia vor fi actorii

secundari)?

Ø Ce unit&i (device-uri) hardware vor avea nevoie de sistem?

Ø Cu ce alte sisteme va interac&iona? Aceste pot fi împr &ite în sisteme (sisteme de

calculatoare, aplica&ii) care vor ini&ia 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 în cadrul diagramelor de modelare UML este

prezentat în Figura 1.

Figura 1: Reprezentarea actorilor în UML.

Cazuri de utilizare

Un caz de utilizare reprezint o func&ionalitate complet a sistemului, a#a cum este

ea perceput de un actor. În UML el este definit ca: “un set de secven # e de ac # iuni pe care

sistemul le realizeaz pentru a furniza o valoare unui actor particular ”. Ac&iunile pot

presupune comunicarea cu un numr de actori (utilizatori sau alte sisteme) sau realizarea

unor calcule în interiorul sistemului.

Caracteristicile cazurilor de utilizare sunt:

Ø Un caz de utilizare este ini # iat întotdeauna de un actor ; actorul trebuie s cear

direct sau indirect sistemului realizarea unui caz de utilizare;

Ø Un caz de utilizare furnizeaz o valoare unui actor ;

Ø Un caz de utilizare trebuie s fie complet . O gre#eal frecvent întâlnit este s

împr &im un caz de utilizare în altele mai mici #i s le implementm ca apeluri de

func&ii în limbajele de programare. Un caz de utilizare nu este complet pân când

Bibliotecar

<<Actor>>

Abonat







nu este produs valoarea final, chiar dac pentru aceasta sunt necesare câteva

dialoguri.

Un caz de utilizare este o clas nu o instan& a acesteia. Clasa descrie

func # ionalitatea ca un întreg, incluzând alternative posibile, erori #i excep&ii care pot s

apar pe parcursul execu&iei. O instan&iere a unui caz de utilizare se nume#te scenariu #i

reprezint o utilizare actual a sistemului, de exemplu “Studentul Popescu cere

bibliotecarului sa-i fac o rezervare pentru cartea de UML care în momentul respectiv

nu este disponibil ”.

Cazurile de utilizare sunt conectate cu actorii prin asocieri, numite #i asocieri de

comunicare. În mod normal acestea sunt rela&ii unu-la-unu nedirec # ionate ceea ceînseamn ca o instan& actor comunic cu o instan& a cazului de utilizare #i c aceast

comunicare este în ambele sensuri.

Identificarea cazurilor de utilizare

Procesul de identificare a cazurilor de utilizare începe de la actorii deja identifica&i.

Pentru fiecare actor se vor pune urmtoarele întrebri:

Ø Care sunt func&iile pe care actorul le a#teapt de la sistem? Ce trebuie s poat

face actorul?

Ø Are nevoie actorul s citeasc, s creeze, s modifice, s distrug sau s pastreze

anumite tipuri de informa&ii în sistem?

Ø Trebuie s #tie actorul de apari&ia unui anumit eveniment în sistem? Ce

func&ionalitate reprezint aceste evenimente?

Ø Poate actorul s-#i simplifice munca de zi cu zi sau s lucreze mai eficient

folosind func&ii noi ale sistemului?

Sau alte întrebri care nu presupun un actor curent:

Ø Ce intr ri/ie#iri sunt necesare în sistem? De unde vin acestea #i unde merg?







Ø Care sunt problemele majore în implementarea curent a acestui sistem? Poate fi

înlocuit un sistem manual cu unul automat?

Figura 2: Reprezentarea cazurilor de utilizare

Relaii între cazurile de utilizare

Sunt trei tipuri de rela&ii ce pot fi definite între cazurile de utilizare: extindere,

utilizare $i grupare.

Rela ia de extindere

Rela # ia de extindere este o generalizare a unui use case prin adugarea de ac&iuni

noi. Un extend poate include comportamentul use case-ului extins, în func&ie de condi&iile

de extindere. Un use case extins poate gestiona excep&iile specifice cazurilor din use

case-ul general care nu sunt u#or de tratat în acesta, sau care apar în sistem pe msura

dezvoltrii lui. O rela&ie de extindere între cazuri de utilizare este vzut ca o

generalizare (se folose#te stereotipul <<extend>>).

Rela ia de util izare

Când mai multe cazuri de utilizare au un comportament comun, acesta poate fi modelat

într-un singur caz de utilizare #i apoi folosit #i de altele. Dac use case-ul nu este folosit

niciodat direct se nume#te caz de utilizare abstract . O rela&ie de utilizare folose#te

stereotipul <<uses>>.

Nume Actor Asociere de

comunicare

Use Case

C

Nume

Use Case

Use Case

A

Use Case

B

Nume sistem







Dac mai multe cazuri de utilizare gestioneaz func&iuni similare sau sunt într-un fel

legate unul de altul, acestea pot fi grupate în pachete UML. Pachetele nu au un în&eles

semantic.

Descrierea cazurilor de utilizare

Descrierea cazurilor de utilizare se face de obicei printr-un text care con&ine o

specificare simpl dar consistent a modului de interac&iune între actori #i cazurile de

utilizare ale sistemului. Aceasta va surprinde comportamentul sistemului #i va ignora

modul în care acesta va fi implementat în sistem.

Descrierea va con&ine:

Ø Obiectivele cazurilor de utilizare;

Ø Cum este ini&iat un caz de utilizare? Ce actori ini&iaz execu&ia #i în ce situa&ii?

Ø Care este fluxul de mesaje între actori #i cazurile de utilizare;

Ø Fluxul alternativ în cazurile de utilizare; Un caz de utilizare poate s aib o

execu&ie alternativ în func&ie de anumite condi&ii sau excep&ii;

Ø Când un caz de utilizare este considerat terminat, #i care va fi valoarea transmis

actorului;

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

vizualizarea secven&elor de activita&i, ordinea lor #i op&ional deciziile luate pentru a

specifica opera&ia care urmeaz a fi realizat. Trebuie s re&inem un lucru important:

modelul cazurilor de utilizare trebuie s fie u#or de comunicat utilizatorului/clientului.







Dup ce au fost descrise cazurile de utilizare vor trebui specificate rela&iile

existente între acestea. Întrebrile care vor trebui puse în aceast faz sunt:

Ø To&i actorii implica&i comunic cu cazuri de utilizare?

Ø Sunt asemnri între actori, poate fi descris o clas actor de baz?

Ø Sunt asemnri între cazurile de utilizare existente? Exist un flux comun de

activita&i care s poat fi descris ca o rela&ie de utilizare a unui caz de utilizare?

Ø Exist cazuri de utilizare care s poat fi descrise ca extend-uri?

Ø Sunt actori sau cazuri de utilizare f r asocieri de comunicare? Dac exist a#a

ceva este gre#it!

Ø Sunt cerin&e func&ionale înc necuprinse în cazuri de utilizare? Dac da, vor

trebui rezolvate.

Cazurile de utilizare sunt folosite #i la testarea sistemului; sunt dou tipuri de teste

care se pot realiza: verificarea, în care se confirm sau nu dac sistemul a fost dezvoltat

corect, în acord cu specifica&iile cerute #i respectiv validarea, care verific dac sistemul

construit este util pentru client #i utilizatorul final.

PDF created with FinePrint pdfFactory Pro trial version http://www fineprint com



Documents

5 Modelarea Cazurilor de Utilizare 1