CAP.
2
MODELAREA FUNCTIONALA.
DIAGRAMELE CAZURILOR DE
UTILIZARE
2.1 Modelarea functionala in UML
Presupune structurarea functionalitatii sistemului, adica
descrierea cerintelor functionale
In UML se pot folosi, in principal, 2 tipuri de diagrame:
Diagrama cazurilor de utilizare – descrie functiunile
principale ale sistemului informational
Diagrama de activitati – descrie logica proceselor
economice ale sistemului
2.2. Diagrama cazurilor de
utilizare
Descrie cerinţele funcţionale ale sistemului -
comportamentul sistemului din perspectiva utilizatorilor
Accentul este pus pe CE, nu CUM!
There is nothing object-oriented about use cases!!!
Conţin:
actori
cazuri de utilizare
relaţii:
între actori şi cazuri de utilizare
între cazurile de utilizare
între actori
Diferente semantice fata de DFD
Contine relatii OO (inclusiv între actori)
Creata din punctul de vedere al utilizatorilor
Poate fi creata impreuna cu utilizatorii
Datele nu sunt separate de functionalitati
Cazurile de utilizare nu se detaliaza cu alte diagrame ale
cazurilor de utilizare
NU REDA FLUXURILE informationale!!!
Actori. Definire
UML – “specifică un rol jucat de utilizator sau orice alt sistem care
interacţionează cu sistemul în cauză”
nu sunt parte a sistemului, reprezintă orice element care
interacţionează cu sistemul
sunt doar generatori de evenimente
reprezintă o clasă şi nu o instanţă – categorie de utilizatori
nu este o persoană – ea poate avea mai multe roluri
actorii pot fi human sau non-human
Exemplu: Aplicatie de gestiune a relatiilor cu clienţii
Client, Agent comercial, Personal desfacere, Contabil, Manager,
Gestionar, Sistem gestiunea stocurilor, Sistem gestiunea
trezoreriei, Sistem gestiunea producţiei
Actori. Identificare
întrebări ce ar putea ajuta la identificarea actorilor:
Ce intrări/ieşiri sunt necesare în sistem? De unde vin
acestea şi unde merg?
Cine este interesat de o anumită cerinţă?
Unde ar trebui folosit sistemul?
Cine va beneficia de pe urma sistemului?
Cine va furniza sistemului date, cine le va folosi şi cine le va
şterge?
Cine va administra şi întreţine sistemul?
Cu ce alte sisteme externe va interacţiona?
Cazuri de utilizare. Definire
UML: “un set de acţiuni pe care sistemul le realizează pentru a
furniza un rezultat care are o valoare pentru unul sau mai mulţi
actori sau beneficiari ai sistemului”
O unitate distinctă de interacţiune între utilizator (uman sau nu) şi
sistem
surprinde o anumită funcţionalitate a sistemului din perspectiva
utilizatorului
este o clasă nu o instanţă
Pot fi 2 tipuri de cazuri de utilizare:
concrete - o funcţionalitate identificată ca cerinţă a utilizatorilor
abstracte – rezultă în urma rafinării DCU; nefolosite direct de
actori; apar în relaţii de incluziune sau extensie cu cazurile de
utilizare concrete
Cazuri de utilizare. Definire
Exemple de cazuri de utilizare:
Adauga client
Inregistrare factura
Calcul amortizare lunara
Evaluare bonitate client
Contraexemple de cazuri de utilizare:
Evidenta facturi client – este prea general (amplu)
Calcul valoare factura – este doar o parte de functionalitate
nu poate fi executat singur, ci doar in contextul unui alt caz de utilizare
Utilizatorul doreste sa integistreze o factura, nu doar sa calculeze valoarea
Nici caz de utilizare abstract nu (prea) poate fi considerat
Cazuri de utilizare. Definire
reprezintă o colecţie de scenarii în legătură cu utilizarea sistemului
fiecare scenariu descrie o secvenţă de acţiuni executate în vederea
realizării unei sarcini de lucru date
trei categorii de scenarii:
principal (“happy day scenario”) – reprezintă scenariul principal
de lucru care finalizează cazul de utilizare cu succes
descrie secvenţa de paşi cea mai comună de realizare a cazului
de utilizare
relevă esenţa lucrurilor
este util în înţelegerea uşoară a scopului cazului de utilizare
alternative – descrie o secvenţă de paşi, alta decât în scenariul
principal, dar care are ca rezultat finalizarea cu succes a cazului de
utilizare
de excepţie – descrie o secvenţă de paşi care nu duce la
finalizarea cu succes a CU
reprezintă o cale nedorită de utilizator
Cazuri de utilizare. Exemple
Exemplu CU: Înregistrare comandă client
Scenariul principal:
Înregistrare comandă client existent fără depăşirea
limitei de creditare
Scenarii alternative:
Înregistrare comandă client existent cu mărirea limitei
de creditare,
Înregistrare comandă client nou
Scenarii excepţie:
Înregistrare comandă cu stoc insuficient
Înregistrare comandă client existent fara aprobarea
măririi limitei de creditare
Cazuri de utilizare. Identificare
Ce funcţionalităţi ale sistemului va trebui să acceseze actorul?
Actorul trebuie să citească şi/sau să actualizeze anumite date din
sistem?
Sunt evenimente din sistem ce trebuie aduse la cunoştinţă actorului?
Poate actorul să-şi uşureze munca sau să lucreze mai eficient folosind
noi funcţionalităţi?
Se poate începe cu modelarea proceselor afacerii şi apoi se continuă cu
extragerea cazurilor de utilizare din aceste modele
modelul procesului poate fi construit cu ajutorul diagramelor de
activităţi
Cazuri de utilizare. Identificare
identificarea CU este un proces iterativ – utilizatorul/clientul se
poate razgandi!
definirea CU la un nivel uniform de granularitate
dimensiunea unui CU este un subiect controversat - opinii
CU sa contina 10 – 15 pasi!
CU sa poata fi descris pe 1 pagina Word!
dacă un CU are un singur scenariu, atunci ar putea fi prea
„fin”!
criterii pentru determinarea dimensiunii potrivite a CU
o funcţionalitate realizată de o singură persoană, într-un
singur loc, la un moment dat (one person/role, one place,
one time)
la final, datele vor fi într-o stare de consistenţă
furnizează o anumită “valoare” (business value)
dimensiunea CU este alegerea analistului
Cazuri de utilizare. Identificare
Cockburn propune mai multe niveluri pentru identificarea CU:
([Link])
Cazuri de utilizare. Descrierea
folosind diagramele de activităţi pentru fiecare CU sau scenariu
folosind diagramele de secvenţă
narativ, folosind un şablon (template)
numele CU
obiectivele urmărite
evenimentul declansator
actorul(ii) care iniţiază interacţiunea
condiţiile anterioare realizării (pre-condiţii)
trebuie sa fie adevarate înainte de începerea scenariului
aceste conditii nu sunt testate pe parcursul scenariului
rezumatul
lista scenariilor posibile
paşii pentru fiecare scenariu - se urmăreasc doar
interacţiunile cu utilizatorul (nu algoritmi de prelucrare!!!)
conditiile de garantare a succesului (post-condiţii)
actorul care beneficiază de rezultatele CU
cerinte nefunctionale
pasii pot fi descrisi folosind propozitii SVDPI (Subiect +
Verb + complement/obiect Direct + Prepozitie +
Cazuri de utilizare. Descrierea
Exemplu de pas in scenariu formulat conform
structurii SVDPI:
The patient contacts the office regarding an
appointment.
Secretara inregistreaza cererea de cazare a
studentului.
Seful de birou inregistreaza pontajul pentru un
angajat.
Cazuri
Nume:
de utilizare. Descrierea
Inregistrare comandă client
Obiective: Înregistrarea comenzilor lansate de clienţi, verificarea
condiţiilor de livrare şi rezervarea cantităţilor necesare
Descriere sintetică: Acest CU este iniţiat atunci când o comandă este
înaintată direct de către client sau prin intermediul
unui agent comercial. El se finalizează când cel care a iniţiat
comanda completează toate datele şi efectuează
înregistrarea.
Actorii: Client, Agent comercial
Pre-condiţii: Clientul sau agentul sunt înregistraţi în sistem
Post-condiţii: Comanda este înregistrată în baza de date
Cantităţile necesare sunt rezervate
Scenariul principal: Înregistrare comandă client existent fără depăşirea
limitei de creditare
Scenarii alternative: Înregistrare comandă client existent cu mărirea
limitei de creditare,
Înregistrare comandă client nou
Scenarii excepţie: Înregistrare comandă neacceptata deoarece nu s-a
aprobat mărirea limitei de creditare
Paşii scenariului principal: (vezi descrierea scenariilor interfeţelor
Relaţiile
Relaţiile dintre actori şi cazurile de utilizare
relaţii de asociere - arata ca actorul interactioneaza
cu sistemul pentru realizarea cazului de utilizare
Relaţiile între actori
relaţii de generalizare.
Relaţiile între cazurile de utilizare
generalizare,
extensie
incluziune.
Relaţiile
Relaţii între cazurile de utilizare
1. Extensia
este o relaţie de generalizare care arată că un CU adaugă
anumiţi paşi (activităţi) la un alt CU
are loc într-un anumit punct din CU extins - punct de
extensie – poate fi evidenţiat în DCU
arată că un CU continuă secvenţa de activităţi a CU de
bază atunci când:
se ajunge la punctul de extensie în CU de bază şi
este îndeplinită condiţia de extensie
se reprezintă printr-o linie de dependenţă căreia i se
ataşează stereotipul Extend
<<extend>>
Relaţiile
Relaţii între cazurile de utilizare
1. Extensia - exemple
“ Recuperare parola “ <<extend>> “Autentificare”
“Adauga la favorite” <<extend>> “Vizualizare produse”
“Calcul discount” <<extend>> “Inregistrare comanda”
“Calcul penalitati intarziere” << extend>> “Returnare
carte”
Relaţiile
Relaţii între cazurile de utilizare
1. Extensia
se foloseşte pentru scoaterea în evidenţă a scenariilor
alternative sau de excepţie
se recomandă utilizarea atunci când logica alternativei la
scenariul principal este de o complexitate mare
se poate folosi pentru gestionarea evenimentelor
asincrone (ex. În orice moment al executarii cazului de
utilizare poate fi initiata operatiunea de căutare)
evidenţiere în descrierea cazului de utilizare
....
Verificare stare client. [Punct de extensie: CU22
Adăugare client (Client inexistent)]
....
Relaţiile
Relaţii între cazurile de utilizare
2. Incluziunea
este o relaţie de generalizare care denotă că un CU include
comportamentul descris de un alt CU
presupune identificarea şi gruparea unor paşi comuni mai
multor CU într-un CU separat
astfel de CU sunt identificate prin analiza detaliilor (paşilor)
CU de bază
se are în vedere reutilizarea
este ca şi apelarea unei funcţii sau invocarea unei operaţii -
un CU invocă un altul
se reprezintă printr-o linie de dependenţă căreia i se
<<include>>
ataşează stereotipul Include
Relaţiile
Relaţii între cazurile de utilizare
2. Incluziunea
exemple: - “Adaugare comandă” si “Modificare comandă”
<<include>> “Verificare limită credit”
- “Punere in functiune”, “Reevaluare imobilizare”
si “Reparatie capitala” <<include>> “Calcul amortizare lunra”
- “Plaseaza comanda” <<include>> “Autentificare”
3. Generalizarea
arată că un CU moşteneşte comportamentul unui alt CU,
adaugând propriul comportament
se poate folosi extensia sau incluziunea!!!!
nu prea se foloseşte în practică!!!!
Relaţiile
Atentie la diferenta dintre relatiile de extensie si
incluziune
pasii cazului de utilizare care extinde se adauga la pasii
celui extins numai daca este indeplinita conditia specificata
pasii cazului de utilizare inclus se adauga intotdeauna la
pasii celui care include, altfel scenariul nu poate fi finalizat
Exemplu de DCU cu relatii de extensie si
incluziune
Relaţiile
Relaţiile de incluziune şi extensie pot fi identificate numai
după descrierea cazurilor de utilizare concrete
Când se utilizează incluziunea?
se identifică o secvenţă de paşi comună mai multor cazuri de
utilizare
se dorește descompunerea unui CU prea complex pentru a fi
înțeles
Când se utilizează extensia?
un caz de utilizare, cu toate scenariile alternative şi excepţie,
este prea complex
nu se doreşte modificarea unui caz de utilizare concret – ele
este în sistemul existent şi se doreşte adăugarea unei noi
funcţionalităţi
se doreşte implementarea parţială a unui caz de utilizare într-
Întrebări care caută un
1. Sunt cazurile de utilizare abstracte de sine-
răspuns!!!!!
stătătoare?!
2. Pot fi asociate cazurile de utilizare abstracte cu
actorii?!
3. Câte diagrame ale cazurilor de utilizare ar trebui
construite pentru un sistem?!
Exemplu de DCU
(1) functiunile principale ale sistemului (un restaurant) si
Descrie
interactiunile acestuia cu actorii principali (preluat [Link])
Exercitiu
Intr-o biblioteca, cititorii imprumuta carti iar functionarii dau carti cu imprumut.
Ambele operatii necesita furnizarea unui nume si parole valide pentru accesul in
sistem.
Care dintre cele 3 variante este cea corecta?
Exercitiu
Ar putea fi conceputa altfel DCU din figura de mai jos?
Reutilizare în modelul
cazurilor de utilizare
Potenţialul de reutilizare poate fi modelat prin
intermediul a 4 relaţii de generalizare
dependenţe de extensie între cazurile de utilizare
dependenţe de incluziune între cazurile de utilizare
moştenire între cazurile de utilizare
moştenire între actori
Avantajele dezvoltării orientate
pe
Cazurile de utilizare stau la baza proiectarii si implementarii
cazurile
sistemului (conform de utilizare
Unified Process):
permit definirea ariei de întindere a sistemului
sunt utile în planificarea proiectului – numărul CU indică
dimensiunea proiectului şi permite măsurarea progreselor
proiectului
instrument bun de comunicare – utilizatorii, analiştii,
proiectanţii, testerii
pot sta la baza încheierii contractului
facilitează proiectarea interfeţelor utilizator
stau la baza definirii cazurilor de test
sunt utile la elaborarea documentaţiei utilizatorului
celelalte tipuri de diagrame UML sunt construite in jurul
cazurilor de utilizare – ele prezinta functionalitatile sistemului
Webografie
[Link]
m
[Link]
[Link]
UseCases_IncludesAndExtends.pdf