lab2 (1)

Lab.2. Modelare funcional. Cazuri de utilizare 1 Inginerie software 2014 Conf.dr. Cristina Mndru

Lab.2 Modelare funcional. CAZURI DE UTILIZARE Bibliografie: Tom Pender, UML Bible http://www.agilemodeling.com http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html http://www.gatherspace.com/static/use_case_example.html

Def. (Wikipedia): Un caz de utilizare n ingineria software i ingineria sistemelor este descrierea comportamentului unui sistem ca rspuns la o solicitare generat din exetriorul su.

Un caz de utilizare definete interaciunile dintre actorii externi i sistem n scopul realizrii unui anumit obiectiv.

Def. Actor specific un rol1 jucat de o persoan sau o alt entitate (un alt sistem, un dispozitiv) atunci cnd interacioneaz cu sistemul.

Actorii exist n afara sistemului studiat i particip la o secven de activiti n dialog cu sistemul, n scopul ndeplinirii unui anumit obiectiv.

Un caz de utilizare TREBUIE s:

descrie ce va face sistemul pentru a a ndeplini obiectivul exprimat de actor. nu includ limbaj specific implementrii. fie la un nivel corespunztor de detaliu. includ un prototip initial al UI (interfaa cu utilizatorul). (Detaliile ulterioare referitoare la

ecranele UI vor fi reprezentate mai trziu n procesul dezvoltrii software-lui, n timpul activitii de proiectare a UI lab.4)

1 Obs. Aceeai persoan poate utiliza sistemul ca actori diferii deoarece aceasta poate juca roluri diferite la momente de timp diferite.

Analiza a cazurilor de utilizare este forma primar de culegere a cerinelor de utilizare pentru un nou program software sau sarcin de ndeplinit.

Obiectivele primare ale analizei cazurilor de utilizare sunt: - Proiectarea unui sistem din perspectiva utilizatorului, - Comunicarea comportamentului sistemului n termenii utilizatorului, - Specificarea tuturor comportamentelor vizibile din exetrior.

Un set mai particular de obiective pentru analiza cazurilor de utilizare se refer la o comunicare mai clar a:

- Cerinelor sistem, - Modului n care va fi utilizat sistemul, - Rolurile jucate de utilizatori n sistem, - Ce face sistemul ca rspuns la stimulii generai de utilizator, - Ce recepioneaz utilizatorul de la sistem,

id9778080 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com

http://www.agilemodeling.comhttp://www.andrew.cmu.edu/course/09-754/umlucdfaq.htmlhttp://www.gatherspace.com/static/use_case_example.html


A. DIAGRAMA CAZURILOR DE UTILIZARE (UCD)

1. Introducere

Scop : (CE TREBUIE S FAC SISTEMUL!!!) Descrie funcionalitatea sistemului din punctul de vedere al utilizatorului. NIvel superior de abstractizare.

UCD Nivele de granularitate: ntreaga ntreprindere sau linie de business sistem individual sub-sistem sau component.

Modelare centrat pe obiectiv:

- scopul (caracteristicile, funcionalitatea) sistemului (CE). - NU soluii de atingere a scopului (nu CUM).

2. ELEMENTE DE MODELARE Actor entitate ce interacioneaz cu sistemul; rol jucat de o persoan, de un alt sistem sau de un dispozitiv hardware. Sistem sistemul modelat. Caz de utilizare (Use case) un serviciu pe care sistemul tie s-l furnizeze; funcie cheie a sistemului. Tipuri de relaii:

Cazurile de utilizare pot fi descrise la nivel abstract (cazuri de utilizare business, numite uneori cazuri de utilizare eseniale), sau la nivel sistem (cazuri de utilizare sistem). Diferena const n zona acoperit de fiecare.

Cazul de utilizare business este descris n terminologie independent de tehnologie care trateaz procesul business ca pe o cutie neagr (black box) i descrie procesul business care este utilizat de actorii business (persoane sau sisteme exterioare domeniului business) pentru a-i atinge obiectivele (e.g., procesarea plii manuale, aprobarea raportului de cheltuieli, etc.). Cazurile de utilizare business vor descrie un proces care ofer valoare actorului business, i descrie ce face procesul. Business Process Modeling este o alt metod pentru acest nivel de descriere business.

Cazurile de utilizare sistem sunt descrise n mod normal la nivelul funcionalitii sistemului (de exemplu, creare raport rezultate examen) i specific funcia sau serviciul pe care sistemul l ofer utilizatorului. Un caz de utilizare sistem va descrie ce obine actorul n urma interaciunii cu sistemul. De aceea se recomand ca specificarea unui caz de utilizare sistem s nceap cu un verb (e.g., creare raport examen, selectare pli, anulare not). n general actorul poate fi un utilizator uman sau un alt sistem ce interacioneaz cu sistemul definit prin cazurile de utilizare.


asociere interaciune ntre actor i caz de utilizare. ntre dou cazuri de utilizare; cazul de utilizare inclus este un

caz de utilizare reutilizabil care este incorporat necondiionat n executarea cazului de utilizare ce l include; cazul de utilizare apelant decide cnd i de ce utilizeaz cazul de utilizare inclus.

ntre dou cazuri de utilizare; cazul de utilizare care extinde este un caz de utilizare reutilizabil care ntrerupe condiional execuia cazului de utilizare extins pentru a-i extinde funcionalitatea; cazul de utilizare care extinde decide cnd va fi folosit.

generalizare relaie de motenire ntre actori sau ntre cazuri de utilizare.

3. NOTAIE 3.1 Actor:

o persoan un alt sistem un dispozitiv extern

Fiecare actor este asociat cu cel puin un caz de utilizare. 3.2 Caz de utilizare (Use-case):

Numele cazului de trebuie s nceap cu un verb !. 3.3 Relaii: generalizare


Cazul de utilizare "Select Course" va fi executat de fiecare dat cnd va fi lansat "Register for Courses" sau "Study Course".

Cazul de utilizare "View Course Data" va fi executat doar n punctul de extensie "View Course Data" al cazului de utilizare "Study Course". Punctul de extensie poate fi activat prin apsarea unui buton sau prin ndeplinirea altei condiii. Similar pentru cazul de utilizare "Exercise". DISCUIE: Un caz de utilizare care extinde continu comportamentul cazului de utilizare de baz (pe care l extinde). Cazul de utilizare care extinde realizeaz acest lucru prin inserarea conceptual a unei secvene suplimentare de aciuni n secvena cazului de utilizare de baz. Aceasta permite unui caz de utilizare care extinde s continue secvena de activiti a cazului de utilizare de baz atunci cnd n cazul de utilizare de baz este atins punctul de extensie i ndeplinit condiia de extensie. La ncheierea secvenei de activiti a cazului de utilizare care extinde, cazul de utilizare de baz continu.

Un caz de utilizare care extinde este, de fapt, un curs alternativ al cazului de utilizare de baz. Ca regul de baz, se introduce un caz de utilizare care extinde ori de cte ori logica asociat unui curs alternativ este la un nivel de complexitate similar cu cel al cursului (fluxului) de baz. De asemenea, se poate introduce un caz de utilizare care extinde ori de cte ori ntr-un un curs alternativ este necesar un alt curs alternativ; n acest caz, cazul de utilizare care extinde va ncapsula ambele cursuri altenative.

Lab.2. Modelare funcional. Cazuri de utilizare 5 Inginerie software 2014 Conf.dr. Cristina Mndru Aplicarea unei relaii extend necesit patru elemente:

Cazul de utilizare de baz: Cazul de utilizare care va fi extins de ctre cazul de utilizare care extinde (ex. Cazul de utilizare "Study Course").

Cazul de utilizare care extinde: Cazul de utilizare care ofer comportamentul adugat (ex. Cazurile de utilizare "View Course Data" i "Exercise" sunt cazuri de utilizare care extind).

Relaia extend: O sgeat punctat cu baza spre cazul de utilizare care extinde i cu sgeata spre cazul de utilizare extins.

Puncte de extensie: Una sau mai multe locaii n cazul de utilizare de baz unde este evaluat o condiie pentru a se determina dac extensia va ntrerupe execuia cazului de utilizare de baz. Punctele de extensie pot fi listate n interiorul pictogramei ce reprezint cazul de utilizare sau pot s apar doar n descrierea textual a cazului de utilizare.

Punctul de extensie este asociat cu o condiie care determin dac extensia va fi utilizat. n cazul relaiei include nu exist o astfel de condiie. Punctul de extensie definete ce urmrete cazul de utilizare care extinde pentru a afla cnd trebuie s se insereze n cazul de utilizare de baz.

Extinde comportamentul cazului de utilizare de baz.

Extinde comportamentul cazului de utilizare de baz.

Cazul de utilizare inclus este folosit ntotdeauna pentru a extinde cazul de utilizare n curs de execuie.

Cazul de utilizare care extinde ar putea fi folosit (uneori) pentru a extinde cazul de de utilizare n curs de execuie.

Cazul de utilizare n curs de execuie decide cnd apeleaz cazul de utilizare inclus. Cazul de utilizare inclus nu este contient de cazul de utilizare de baz.

Cazl de utilizare care extinde decide cnd se va insera n execuia cazului de utilizare de baz. Cazul de utilizare de baz nu este contient de cazul de utilizare care extinde.

Sgeata este desenat ctre cazul de utilizare inclus.

Sgeata este desenat ctre cazul de utilizare extins.

3.4 Marcarea limitelor sistemului (opional).

Cazurile de utilizare pot fi incluse ntr-un dreptunghi care va delimita sistemul de contextual su. Tot ce e coninut n acest dreptunghi reprezint funcionalitatea aflat n zona sistemului i tot ce

este n afara acestuia se afl n afara sistemului.

Lab.2. Modelare funcional. Cazuri de utilizare 6 Inginerie software 2014 Conf.dr. Cristina Mndru Reprezentarea limitelor poate fi utilizat i pentru a identifica ce cazuri de utilizare vor fi livrate n fiecare versiune major a sistemului.

4. REGULI

1. Un caz de utilizare definete un serviciu (ntr-o singur sesiune/cerere) nu o secven de operaii.

2. Identificai doar un singur sistem cu care vor comunica toi actorii. Actorii nu comunic direct ntre ei.


3. Identificai integral comportamentul de nivel nalt adic ceea ce sistemul tie s fac.

CE !!! , nu cum.

4. Analizai vs.

B. DETALIILE CAZULUI DE UTILIZARE

Diagrama UC ilustrateaz actori i cazuri de utilizare ca pri ale unui comportament i relaiile dintre aceste entiti, fr detalii referitoare la comportament.

Detaliile cazului de utilizare (UC narrative) : document ce descrie cazul de utilizare sub form de comportament al sistemului, avnd un nceput (declanator), un cuprins (dialog) i un final.

Detaliile cazului de utilizare reprezint o serie complet de eveniment, descrise din punctul de vedere al Actorului.

Detaliile2 descriu modul n care Actorul va interaciona cu sistemul pentru a ndeplini un anumit obiectiv.

Dintr-un caz de utilizare se pot genera unul sau mai multe scenarii, corespunztoare detaliilor fiecrui mod prin care se poate ndeplini obiectivul.

Elementele unei descrieri a detaliilor unui caz de utilizare includ:

1. Numele cazului de utilizare 2. Versiunea 3. Obiectivul 4. Rezumat 5. Actorii implicai 6. Precondiii 7. Declanatoare 8. Fluxul de baz al evenimentelor 9. Fluxuri alternative de evenimente 10. Excepii ce pot s apar 11. Punctele de extensie

2 Recomandare referitoare la limbaj: evitai jargonul tehnic; se va prefera limbajul utilizatorului final sau al expertului domeniului aplicaiei.

X include(utilizeaz) Y X implic ntotdeauna realizarea lui Y cel puin o dat.

Y extends X Y este un caz de comportament special de acelai tip ca i mai generalul Y; va fi executat uneori.


12. Postcondiii 13. Reguli business 14. Note 15. Autor i Dat

Numele cazului de utilizare Numele cazului de utilizare are rolul de identificator unic pentru acesta. Trebuie scris ntr-un fomat verb-substantiv (e.g., mprumut cri, Extragere bani), trebuie descris un obiectiv ce poare fi realizat i trebuie s fie suficient pentru ca utilizatorul final s poat nelege la ce se refer cazul de utilizare. Analiza cazurilor de utilizare condus pe baz de obiectiv va denumi cazurile de utilizare conform obiectivelor actorului, asigurnd astfel centrarea pe utilizator a cazurilor de utilizare. Dou sau trei cuvinte este optim.

Versiunea Seciunea de versiune este necesar pentru a informa cititorul despre stadiul la care a ajuns cazul de utilizare. Cazul de utilizare iniial dezvoltat pentru analiza business poate fi foarte diferit de versiunea la care s-a ajuns n timpul dezvoltrii software-lui. Versiunile mai vechi ale cazului de utilizare pot rmne n documentaie, fiind valoroase pentru diferite grupuri de utilizatori.

Obiectiv Descrie pe scurt ce anume dorete utilizatorul s obin de la sistem n cadrul acestui caz de utilizare.

Rezumat Seciune utilizat pentru a captura esena unui caz de utilizare nainte de completarea coninutului descrierii. n mod ideal va conine cteva propoziii i va include obiectivul i actorul principal.

Actori implicai Un actor este cineva sau ceva din afara sistemului care fie acioneaz asupra sistemului actor primar fie sistemul acioneaz asupra lui actor secundar. Un actor poate fi o persoan, un dispozitiv, un alt sistem sau sub-sistem, sau timpul. Actorii reprezint diferitele roluri pe care entiti din afara sistemului le joac n relaia cu sistemul ale crui cerine funcionale sunt specificate. Un individ din lumea real poate fi reprezentat de mai muli actori dac acesta joac mai multe roluri n utilizarea sistemului.

Precondiii Seciunea de precondiii definete toate condiiile ce trebuie s fie ndeplinite (TRUE) (i.e., descrie starea sistemului) astfel nct s aib sens iniierea cazului de utilizare de ctre declanator. Dac sistemul nu se afl n starea descris de precondiii comportamentul cazului de utilizare este nedeterminat. Pe de alt parte, simplul fapt c precondiiile sunt ndeplinite NU iniiaz cazul de utilizare.

Declanatoare Seciunea "declanatoare" descrie evenimentul care produce iniierea cazului de utilizare. Acest eveniment poate fi extern, temporal sau intern. Dac declanatorul nu este un eveniment trivial (e.g., clientul apas un buton), ci reprezint ndeplinirea unui set de condiii, este necesar un proces de declanare care se execut continuu (sau periodic) pentru a testa ndeplinirea condiiilor de declanare: evenimentul declanator este un semnal de la acest proces care indic ndeplinirea tuturor condiiilor din set. Exist mai multe metode de a descrie ce se face cnd apare declanatorul dar precondiiile nu sunt ndeplinite.

O metod este tratarea "erorii" n cadrul cazului de utilizare (ca excepie). O alt metod este punerea tuturor precondiiilor n declanator i crearea unui

alt caz de utilizare care s trateze problema.

Lab.2. Modelare funcional. Cazuri de utilizare 9 Inginerie software 2014 Conf.dr. Cristina Mndru Fluxul de baz al evenimentelor

Fiecare caz de utilizare trebuie s transmit un scenariu primar, sau un curs tipic de evenimente, numit i "flux de baz", "happy flow" sau "happy path". Cursul de baz al evenimentelor este reprezentat deseori ca un set de pai numerotai. Exemplu: 1.Sistemul cere utilizatorului s se conecteze, 2.Utilizatorul introduce numele i parola, 3.Sistemul verific informaia introdus, i 4.Sistemul conecteaz utilizatorul la sistem.

Fluxuri alternative de evenimente Cazurile de utilizare pot conine ci secundare, sau scenarii alternative, care sunt variaii ale temei principale. Fiecare regul testat poate conduce la o cale alternativ, iar dac sunt mai multe reguli atunci numrul cilor crete rapid, ceea ce conduce la documente foarte complexe. Uneori este mai bine s se utilizeze logica condiional sau diagrame de activitate pentru descrierea cazurilor de utilizare cu multe reguli i condiii. Excepiile, sau ceea ce se ntmpl dac lucrurile merg prost la nivelul sistemului, pot fi descrise de asemenea nu prin utilizarea acestei seciuni ci ntr-o seciune dedicat lor. Cile alternative utilizeaz numerotarea cursului de baz al evenimentelor pentru a indica punctele n care difer de scenariul de baz, i, dac e cazul, unde se reunific cu acesta. . Pe diagrama de activitate se pot reprezenta simultan fluxul de baz, fluxurile alternative i tratarea excepiilor.

Postcondiii Seciunea post-condiii descrie starea sistemului dup ncheierea cazului de utilizare. Post-condiiile sunt garantate a fi TRUE la terminarea cazului de utilizare.

Reguli business Regulile business sunt reguli scrise (sau nescrise) sau politici care determin modul n care o organizaie i conduce afacerea n privina cazului de utilizare. Regulile business sunt un tip special de cerine. Regulile business pot fi specifice unui caz de utilizare sau se pot aplica tuturor cazurilor de utilizare sau ntregii companii. Cazurile de utilizare trebuie s fac referire clar la regulile business care sunt aplicabile i unde sunt implementate acestea. Regulile business trebuie codificate npreun cu logica cazului de utilizare iar execuia poate conduce la diferite post-condiii. E.g. Regula2: o extragere de bani va conduce la actualizarea contului i jurnalizarea tranzaciei conduce la o post-condiie referitoare la o extragere reuit dar numai dac Regula1: trebuie s fie suficiente fonduri este ndeplinit.

Note Seciune ce permite nregistarea de informaii, mai puin structurate dar necesare, ce nu au loc n alte seciuni ale ablonului.

Autor i dat Conine data crerii acestei versiuni a cazului de utilizare i autorul (autorii) documentului. Trebuie s conin i lista tuturor versiunilor anterioare care fac parte din documentaia curent a sistemului.

C. METODOLOGIE

La scrierea efectiv a cazurilor de utilizare, este important productivitatea dar fr perfeciune.

La scrierea efectiv a cazurilor de utilizare nu se urmrete obinerea descrierii perfecte de prima dat. Dezvoltarea cazurilor de utilizare trebuie privit ca un process iterativ cu rafinri successive ale detaliilor.

1. PAII DEZVOLTRII UNEI DIAGRAME UC (UCD):


1. Definirea contextului sistemului: identificarea actorilor i a responsibilitilor lor.

2. Identificarea cazurilor de utilizare: funciile sistemului n termeni de obiective specifice i/sau rezultate ce trebuie produse.

3. Evaluarea actorilor i cazurilor de utilizare pentru gsirea oportunitilor de rafinare (ca divizarea sau gruparea definiiilor).

a. Evaluarea cazurilor de utilizare pentru gsirea relaiilor . b. Evaluarea cazurilor de utilizare pentru gsirea relaiilor . c. Evaluarea actorilor i cazurilor de utilizare pentru a detecta

oportunitile de generalizare (proprieti comune). 1.1 Identificarea actorilor.

Identificarea ROLURILOR reprezentative (nu persoane individuale !).

1.2. Identificarea cazurilor de utilizare. Procedur: Identificarea serviciilor poteniale punnd urmtoarele ntrebri d.p.d.v. al fiecrui actor:

Ce ncearc s obin utilizatorii acestui rol? Ce trebuie s poat face utilizatorii pentru a ndeplini acest rol? Care sunt principalele sarcini ale utilizatorilor acestui rol? Ce informaii trebuie s examineze, s creeze sau s modifice utilizatorii acestui rol? Ce informaii trebuie s primeasc de la sistem utilizatorii acestui rol? Ce informaii trebuie s transmit sistemului utilizatorii acestui rol?

Schiai obiectivele fiecrui actor. (n urma stabilirii actorilor i obiectivelor fiecruia rezult o list iniial cu cazurile de utilizare de nivel nalt).

1.3. Evaluarea actorilor i a cazurilor de utilizare pentru gsirea oportunitilor de rafinare

Lab.2. Modelare funcional. Cazuri de utilizare 11 Inginerie software 2014 Conf.dr. Cristina Mndru 1.3.c. Identificarea oportunitilor de reutilizare a cazurilor de utilizare

n prima versiune a diagramei cazurilor de utilizare din exemplul nostru apare un comportament duplicat att la Student ct i la Professor care include "Login". Putem introduce un actor mai general care are acest comportament iar cei doi actori iniiali vor "moteni" acest comportament de la noul actor. Urmtoarea diagram ilustreaz faptul c un utilizator generic se conecteaz la sistem iar studentul i profesorul posed comportamente proprii dar i comportamentul utilizatorului generic.

Beneficiile generalizrii constau n eliminarea duplicrii comportamentului i atributelor, ceea ce va conduce la un sistem mai uor de neles i totodat mai flexibil.

Motenirea se poate aplica att la actori ct i la cazuri de utilizare.

1.3.a. Evaluarea cazurilor de utilizare pentru gsirea relaiilor

Pentru a opera cu un curs, att profesorul ct i studentul trebuie ca n prealabil s selecteze unul din cele pe care le pred, respectiv la care este nscris.

Considerm c selectarea unui curs este suficient de complex pentru a deveni un caz de utilizare.

Selectarea unui curs trebuie fcut pentru nregistrarea notelor studenilor, pentru nregistrarea studentului la curs, pentru gestionarea cursului sau pentru studiul acestuia.

n consecin, cazul de utilizare "Select Course" va fi executat ntotdeauna ca sprijin pentru fiecare din cazurile de utilizare "Submit Grades", "Manage Course", "Register for Courses" sau "Study Course".

Aceasta se reprezint prin relaia pe diagrama UC, ca n figura de mai jos:


1.3.b. Evaluarea cazurilor de utilizare pentru gsirea relaiilor

Atunci cnd studiaz un curs studentul poate fie s citeasc documentaia cursului fie s exerseze folosind temele i testele oferite mpreun cu acest curs.

n consecin, fie cazul de utilizare "View Course Data" fie cazul de utilizare "Exercise" va fi executat, conform unei selecii fcut de student.

Aceasta se reprezint prin relaia pe diagrama UC, ca n figura urmtoare:


2. PAII DEZVOLTRII DETALIILOR CAZULUI DE UTILIZARE: 2.1. Identificarea componentelor cheie ale cazului de utilizare Cazul de utilizare este reprezentat textual ilustrndu-se o secven de evenimente. Tabela urmtoare conine elementele de baz ale unei astfel de descrieri.

Element al cazului de utilizare Descriere

Numrul cazului de utilizare ID ce reprezint cazul de utilizare

Aplicaia Sistemul sau aplicaia de care aparine

Numele UC Numele (scurt) al UC

Descrierea UC Descriere scurt a UC.

Actorul principal Actorul principal ce utilizeaz sistemul n acest caz

Precondiii Condiii ce trebuie ndeplinite nainte de lansarea UC

Declanator Evenimentul ce declaneaz cazul de utilizare

Flux principal (de baz) Fluxul de evenimente pentru scenariul principal. Erorile i excepiile vor fi tratate ca fluxuri alternative.

Fluxuri alternative Variantele cele mai semnificative ale scenariului de baz i excepiile.

2.2. Denumii i descriei pe scurt cazul de utilizare Numr 1

Lab.2. Modelare funcional. Cazuri de utilizare 14 Inginerie software 2014 Conf.dr. Cristina Mndru UC: Nume UC: Cumprtorul indic o ofert de pre

Descriere: Un cumprtor a identificat un produs pe care dorete s-l achiziioneze i indic o ofert de pre cu intenia de a ctiga licitaia i de a plti produsul.

2.3. Crearea fluxului principal al UC

Fluxul principal al UC reprezint fluxul cel mai important al evenimentelor, care are loc de cele mai multe ori (numit i "Happy Day Scenario" deoarece are loc atunci cnd totul decurge normal, fr erori sau excepii). Cursul principal este important ca referin pentru nelegerea excepiilor. De asemenea, deoarece reprezint n medie 70% din sistem, este mai probabil ca echipa de dezvoltare s implementeze codul corect nc din primele etape.

2.4. Crearea fluxurilor alternative ale UC

Fluxul de baz este ingredientul cheie al cazului de utilizare i se poate argumenta c este suficient descrierea lui. n realitate continuarea descrierii depinde de nivelul de detaliu pe care dorim s l atingem. Experiena arat c este bine ca s oferim clienilor ct mai multe detalii referitoare la cazul de utilizare. Fluxurile altrernative ofer urmtoarele:

o Un flux de excepie sau de eroare pentru orice linie din fluxul de baz. o Un flux adiional, nu neaparat bazat pe eroare, dar un flux ce S-AR PUTEA s apar.

2.5. Producerea efectiv a documentului

Cteva motive pentru care este mai uor de neles un sistem prin cazuri de utilizare dect printr-un document tradiional de descriere a cerinelor sunt: introducerea conceptelor de nivel nalt, parcurgerea scenariilor i n final prezentarea detaliilor. Scopul cazurilor de utilizare este transferul eficient de cunotine din domeniul expertului ctre dezvoltatorul de software cazurile de utilizare servesc ca cerine software. Dac nu au sens pentru persoanle ce construiesc software-ul, atunci nu sunt eficiente.

2.6. Utilizarea diagramei de secvene la nivel de sistem

Pentru fiecare caz de utilizare se poate reprezenta dialogul (schimbul de mesaje) ntre actori i sistem cu diagrame de secvene (o diagram pentru fluxul principal i cte o diagram pentru fiecare flux alternativ) la nivel de sistem. ntr-o astfel de diagram sistemul este vzut ca obiect unic n dialog cu unul sau mai muli actori.

D. UTILIZAREA VISUAL PARADIGM for UML Elemente: o Analiza textual, o variant pentru identificarea actorilor i cazurilor de utilizare (pas 2 i 3 n

seciunea 1.3). o Diagramele UC o Planificarea cazurilor de utilizare: Planificarea cazurilor de utilizare pe baza acordrii de

prioriti.

Lab.2. Modelare funcional. Cazuri de utilizare 15 Inginerie software 2014 Conf.dr. Cristina Mndru o Descrierea UC (UC details):Descrierea detaliilor cazului de utilizare, incluznd precondiii,

postcondiii, fluxuri de evenimente, etc.

E. ACTIVITATE INDIVIDUAL 1. a). Studiai la http://www.visual-paradigm.com/product/vpuml/provides/umlmodeling.jsp urmtorul DEMO: Use case diagram i opional la http://www.visual-paradigm.com/product/vpuml/provides/usecasedetails.jsp urmtoarele DEMO-uri: Flow of events editor Specify testing procedures Generate sequence diagram from flow of events b). Studiai urmtoarele prezentri din folder-ul laboratorului:

- Part_1_Using_Use_Case_Diagram.pdf - Part_2_Use_Case_Diagram_Tutorial.pdf, exercises 1-5; pentru a exersa, utilizai

datele din folder-ul resurse_ Use_Case_Diagram_Tutorial. - Document_Use_Case_using_Use_Case_Detail.pdf

sau Subscribe la Study FREE courses at http://www.visual-paradigm.com/training/ Studiai Using use case diagram course Part1 and Part2:exercises 1-5. Studiai Document Use Case using Use Case Detail course. c). Studiai detalierea UC din fiierul aflat n folder-ul laboratorului: - Process Order Use Case Document.pdf (extras din http://www.cragsystems.co.uk/development_process/develop_use_case_document.htm). Exerciiul 1: Utiliznd VP-UML reprezentai diagrama UC din 1.3.b , seciunea C. Exerciiul 2: Utiliznd diagrama de secvene n VP-UML reprezentai schimbul de mesaje (dialog) ntre actorul "Sales assistant" i Sistem, pentru fluxul de baz descris n Process Order Use Case Document.pdf. Exerciiul 3: Desenai diagram UC a urmtorului robot telefonic.

UC: Leave a Message o Actor: Caller o Pre-Condiie: Room on Tape o Post-Condiie: New Message

UC: Review Messages o Actor: Owner

http://www.visual-paradigm.com/product/vpuml/provides/umlmodeling.jsphttp://www.visual-paradigm.com/product/vpuml/provides/usecasedetails.jsphttp://www.visual-paradigm.com/training/http://www.cragsystems.co.uk/development_process/develop_use_case_document.htm


o Cale principal: Review New Messages o Cale alternativ: No New Messages

UC: Review Messages Locally o Cale principal: Review New Messages o Cale alternativ: No New Messages o Extinde: Review Messages

UC: Review Messages Remotely o Cale principal: Review New Messages o Cale alternativ: No New Messages o Extinde: Review Messages o Utilizeaz: Authorize Access

UC: Authorize Access o Cale principal: User Authorized o Cale alternativ: User Not Authorized

Exerciiul 4: Creai o diagram UC pe baza urmtoarelor cerine. nainte de a desena diagrama rspundei la ntrebrile ataate. Dezvoltm un sistem cu care profesorii pot nregistra i actualiza notele studenilor. Profesorii trebuie s poat distribui rapoarte cu notele. Iat lista complet a cerinelor sistemului: Un profesor poate nregistra note. De cte ori sunt nregistrate note, acestea sunt salvate pe

disc. Un profesor poate actualiza note. De cte ori sunt actualizate note, nota existent este

ncrcat. Dup modificare noua not este salvat pe disc. Profesorul, secretara i studentul pot vizualiza note. Pentru a vizualiza note, solicitantul trebuie s se conecteze la sistem. Dac eueaz

conectarea, solicitantul trebuie s se re-autentifice indicnd nume i parol. Un student cu tax este un tip de student. O secretar poate genera rapoarte cu notele. Un profesor poate distribui rapoarte cu notele. (1) Identificai actorii (i.e. numii-i): (2) Exist actori care sunt specializri ale altor actori mai generali? Dac da, identificai care este

actorul general i care este actorul specializat. Ce tip de relaie trebuie reprezentat ntre actorul general i specializarea sa?

(3) Identificai cazurile de utilizare (i.e. denumii-le): (4) Exist cazuri de utilizare folosite ntotdeauna de alte cazuri de utilizare? Dac da, ce tip de

relaie exist ntre acestea? Identificai cazurile de utilizare folosite ntotdeuna i cazurile de utilizare ce le folosesc.

(5) Exist cazuri de utilizare folosite uneori de ctre un alt caz de utilizare? Dac da, ce tip de

relaie exist ntre acestea? Identificai cazurile de utilizare folosite uneori i cazurile de utilizare ce le folosesc.

(6) Desenai diagrama UC corespunztoare, incluznd toi actorii, cazurile de utilizare, i relaiile.

Atenie la folosirea notaiilor corespunztoare i a etichetelor pentru actori, cazuri de utilizare i relaii.

Lab.2. Modelare funcional. Cazuri de utilizare 17 Inginerie software 2014 Conf.dr. Cristina Mndru Exerciiul 5: Desenai o diagram UC pentru urmtoarea aplicaie. O bibliotec conine cri i jurnale. Se cere dezvoltarea unui sistem softwarea pentru mprumutul de cri. Pentru a mprumuta o carte, clientul trebuie s fie membru al bibliotecii. Exist o limit a numrului de cri ce pot fi simultan mprumutate de un membru al bibliotecii. Biblioteca poate deine mai multe exemplare ale unei anumite cri. O carte se poate rezerva. Unele cri pot fi mprumutate doar pe termen scurt. Alte cri pot fi mprumutate pentru 3 sptmni. Utilizatorii pot extinde nprumuturile. Detaliai textual urmtoarele cazuri de utilizare. mprumut exemplar carte Extinderea mprumutului Dialogurile ntre actori i sistem vor fi reprezentate cu o diagram de secvene la nivel de sistem care va fi apoi exportat ca fiier grafic. Importai apoi documentul grafic n fiierul text cu descrierea detaliilor cazului de utilizare. Exerciiul 6: Considerai urmtoarea descriere a procesului business al unei firme de nchiriere maini. Pentru aceast firm trebuie dezvoltat o aplicaie software pentru a asista angajaii companiei n activitatea de rezervare i nchiriere maini. Datele aplicaiei vor fi memorate n fiiere text structurate. Identificai actorii i utilizai descrierile de mai jos ca baz pentru definirea cazurilor de utilizare. Desenai un model al cazurilor de utilizare ilustrnd toate relaiile dintre cazurile de utilizare. Reprezentai apoi n VP - UML diagrama cazurilor de utilizare, editai detaliile (adaptate pe baza descrierii urmtoare) i reprezentai fluxurile de evenimente cu diagrame de secvene la nivel de sistem. Activitile procesului business desfurat curent la firma de nchiriere maini: REZERVARE Un client contacteaz angajatul de la rezervare n legtur cu nchirierea unei maini. Clientul indic data iniial i data final, vehicolul preferat i oficiul de nchiriere de unde dorete s nchirieze maina. Angajatul de rezervare consult un registru de preuri i indic un pre. Clientul accept preul. Se verific disponibilitatea pentru a vedea dac este disponibil un vehicol corespunztor pentru intervalul solicitat i la oficiul de nchiriere indicat. Dac vehicolul solicitat este disponibil la oficiul de nchiriere indicat, atunci se face o rezervare n numele clientului solicitant. Rezervarea este nregistrat n datele ce indic disponibilitatea vehicolului. Angajatul de rezervare i d clientului un numr de nchiriere. Se creaz un acord de nchiriere ntr-un registru de nchiriere, incluznd numrul de nchiriere,perioada nchirierii, tipul vehicolului i oficiul de nchiriere. Excepii 1. Nu este disponibil un vehicol corepunztor la oficiul de nchiriere ales. Clientului i se ofer un alt vehicol.

Lab.2. Modelare funcional. Cazuri de utilizare 18 Inginerie software 2014 Conf.dr. Cristina Mndru 2. Clientul nu este de acord cu preul i cere un alt vehicol i/sau o alt perioad. VERIFICARE DISPONIBILITATE Se verific disponibilitatea pentru a vedea dac este disponibil un vehicol de un anumit tip, la un anumit oficiu de nchiriere, pentru o perioad dat de timp. Pentru fiecare vehicol exist o nregistrare ce include intervalale de timp cnd este disponibil i cnd este nchiriat. Dac este disponibil, vehicolul este rezervat pentru perioada solicitat. Excepii 1. Dac nu se poate face o rezervare datorit lipsei de vehicole se trimite un raport ce va fi utilizat la planificarea activitii firmei. INIIERE NCHIRIERE Un client ajunge la oficiul de nchiriere i indic angajatului de la nchirieri un numr de nchiriere. Se verific fiierul de nchirieri pentru a gsi numrul de nchiriere al clientului. Dac se gsete nregistrarea corespunztoare, este extras acordul de nchiriere i discutat cu clientul. Dac clientul l accept atunci se imprim acordul de nchiriere. Clientul semneaz acordul i indic un numr de carte de credit. Angajatul de la nchirieri selecteaz una din opiunile de asigurare existente. Dup selecie se completeaz o poli de asigurare i se ataeaz la acordul semnat. Excepii 1. Un client nu are o rezervare. n acest caz se verific disponibilitatea unui vehicol. Dac vehicolul este disponibil, acesta este oferit clientului precizndu-se i preul. Dac clientul accept vehicolul i preul atunci este iniiat nchirierea. 2. Dac nu este disponibil un vehicol de tipul celui rezervat (din cauza ntrzierii unei returnri) atunci clientului i se face o alt propunere. PROCESARE RETURNARE VEHICOL Clientul nregistreaz kilometrajul i nivelul de combustibil i le indic angajatului de la nchirieri. Cantitatea de combustibil ce trebuie adugat la vehicol este adugat la contul nchirierii de pe acordul de nchiriere. Contul nchirierii este verificat de ctre client. Clientul pltete costurile nchirierii. Excepii 1. Vehicolul returnat este avariat, necesitnd plata unei garanii i completarea unei revendicri a asigurrii. 2. Clientul contest contul. CREARE RAPOARTE MANAGEMENT Fiierul cu statistica rezervrilor este actualizat la realizarea acestora. Fiierul este actiualizat i cnd se nchiriaz vehicole fr rezervare preliminar. Statisticile sunt actualizate la returnarea vehicolelor pentru a nregistra durata nchirierii i suma de bani ncasat. La cererea din partea managerului firmei se genereaz un raport al nchirierilor. O EXTENSIE ULTERIOAR Extindei proiectul prin adugarea de caracteristici suplimentare suport pentru nchirieri regulate de ctre firme client. n acest caz vor fi disponibile zilnic un numr precizat de vehicole pentru angajaii companiei client, la oficiile de nchiriere precizate. Firma client poate nominaliza i oferi o list cu angajaii autorizai ce pot ridica vehicolele. Firmei client i se va prezenta lunar un cont de plat. Pentru

Lab.2. Modelare funcional. Cazuri de utilizare 19 Inginerie software 2014 Conf.dr. Cristina Mndru aceasta va trebui ca mai nti s scriei un nou caz de utilizare i/sau s adaptai cazurile de utilizare existente. STUDIU INDIVIDUAL SUPLIMENTAR: La : http://www.cragsystems.co.uk/SFRWUC/ Specifying Functional Requirements With Use Cases

Part 1. Actors and Use Cases Part 2. Use Case Diagrams and Text

http://www.cragsystems.co.uk/SFRWUC/

lab2 (1)

Documents