Studiu de caz

-ATM (Automatic teller machine)-

 Enunţarea problemei
Se presupune că un ATM oferă următoarele servicii:
1) Distribuirea banilor către orice posesor de card (smartcard), prin intermediul
unui cititor de card
2) Consultarea soldului contului, facilităţi de plată şi de depozitare a cecurilor
pentru clienţii băncii (bank customers) care deţin un card (smardcard)
Trebuie avut în vedere că:
3) Toate tranzacţiile trebuie făcute în siguranţă
4) E necesar uneori ca bancomatul să se reumple etc.

De aceea, trebuie îndeplinite sarcinile: Obs. Enunţul problemei

• Să se identifice actorii poate fi incomplet (aşa
cum se întâmplă în
• Să se identifice cazurile de utilizare realitate)
• Să se construiască o diagramă use-case
• Să se descrie textual cazurile de utilizare
• Să se completeze descrierile cu diagrame dinamice
• Să se organizeze şi să se structureze cazurile de utilizare
 Pasul 1. Identificarea actorilor
1.1 Care sunt entităţile externe care interacţionează direct cu ATM-ul?
Prima propoziţie indică şi primul actor :
1) Distribuirea banilor către orice posesor de card (smardcard), prin
intermediul unui cititor de card
Atenţie! Cititorul de card face parte din ATM, deci nu poate fi actor!

Întrebare. Este cardul un actor (deoarece este extern ATM şi

interacţionează cu el)?
Răspuns. Poate fi, dar se aplică următorul principiu: eliminaţi actorii “fizici”
în dauna actorilor “logici”!, deoarece actorii reprezintă cineva sau ceva ce
beneficiază în urma utilizării sistemului.

Cardul nu beneficiază prin folosirea ATM, ci cel care deţine cardul, aşadar
cardul nu va fi considerat actor.
Aşadar, primul actor va fi posesorul de card (CardHolder)
 Pasul 1. Identificarea actorilor (continuare)

A doua propoziţie specifică :

2) Consultarea soldului contului, facilităţi de plată şi de depozitare a cecurilor
pentru clienţii băncii (bank customers) care deţin un card (smardcard)

Aşadar, se conturează şi alt actor: clientul băncii (bank customer)

A treia propoziţie specifică :

3) Toate tranzacţiile trebuie făcute în siguranţă
Cine oferă siguranţă?
În exemplul considerat (preluat după sistemul bancar din Franţa) se
identifică alţi doi actori:
• Visa authorisation system (VISA AS) pentru tranzacţii de retragere prin
intermediul unui smatcard Visa
• Sistemul informaţional al băncii (Bank IS) care să autorizeze toate
tranzacţiile făcute de un client prin intermediul smartcard-ului său, dar şi
accesarea soldului
 Pasul 1. Identificarea actorilor (continuare)

A patra propoziţie specifică :

4) E necesar uneori ca bancomatul să se reumple etc.

Aceasta sugerează că e nevoie activitate de mentenanţă: umplerea

bancomatului, recuperarea smartcard-urilor care au fost “înghiţite” etc.

Aceste sarcini identifică un alt actor: Operatorul (Maintenance Operator)

CardHolder
Bank Customer
Concluzie. Actorii sunt: Visa AS
Bank IS
Maintenance Operator
 Pasul 1 bis. Reprezentarea unei diagrame
Pentru o mai bună înţelegere a celor deduse la pasul 1, e mai utilă
desenarea unei diagrame, pe care o s-o numim diagramă statică de
context (static context diagram)
 Pasul 1 bis. Reprezentarea unei diagrame (continuare)
O altă soluţie, mai elaborată, ar fi să considerăm Bank customer ca
specializarea a lui CardHolder. Se rezolvă astfel problema excluderii
mutuale dintre cei doi actori.
 Pasul 2. Identificarea cazurilor de utilizare

Un caz de utilizare reprezintă specificarea unei secvenţe de acţiuni,

incluzând variante, pe care sistemul le poate efectua, interacţionând cu
actorii din sistem.
Vom lua actorii, unul câte unul, şi vom lista modurile în care aceştia
interacţionează cu sistemul:

1) CardHolder:
• retrage bani
2) Bank customer:
• retrage bani
• consultarea soldului
• depozitarea banilor (cash)
• depozitarea cecurilor
3) Maintenance operator:
• reumple cu bani bancomatul
• recuperarea cardurilor care au fost “înghiţite”
• recuperarea cecurilor care au fost depozitate

4) Visa AS:
• niciuna

5) Bank IS:
• niciuna

Actor primar sau secundar?

Numim actor primar pe acela pentru care cazul de utilizare produce un
rezultat observabil. Ceilalţi participanţi la cazul de utilizare se numesc
actori secundari.
Exemplu: Visa AS şi Bank IS sunt actori secundari. Nu pot ei înşişi să
folosească ATM.
 Pasul 3. Crearea diagramelor use case
O diagrama use case arată relaţiile dintre actori şi sistem, precum şi
cazurile de utilizare (use cases).

ATM

Retragere bani

Umple bancomatul
Consultare sold

Recuperează carduri
Depozitează bani

Frontiera Depozitează cecuri Recuperează cecuri

sistemului
 Pasul 3. Crearea diagramelor use case (continuare)
O variantă se obţine considerând Bank customer ca specializare a CardHolder.

ATM

Retragere bani

Umple bancomatul
Consultare sold

Recuperează carduri
Depozitează bani

Depozitează cecuri Recuperează cecuri

Obs. Vom redenumi actorul CardHolder în Visa CardHolder

 Pasul 3. Crearea diagramelor use case (continuare)
Adăugarea actorilor secundari
Recomandări:
• Implicit, rolul unui actor e “principal” (“primary”); dacă nu e aşa, indicaţi că
rolul e “secundar” (“secondary”) pe asociere, de partea actorului
• Pe cât e posibil, plasaţi actorii principali în stânga diagramei, iar pe cei
secundari în dreapta

Obs. Dacă actorul principal e Visa CardHolder, atunci Visa AS trebuie

solicitat; pe de altă parte, ATM va solicita Bank IS direct, dacă e vorba de
un client al băncii (bank customer).

O soluţie ar consta în adăugarea unei asocieri cu fiecare dintre aceşti actori

secundari.
Adăugarea unei asocieri cu fiecare dintre aceşti actori secundari.
O altă soluţie ar fi să se facă disticţie între cele două cazuri de utilizare
referitoare la retragerea banilor:
• Retragere bani cu Visa card
• Retragere bani cu un card bancar
 Pasul 4. Descrierea textuală a cazurilor de utilizare
Cazul de utilizare trebuie să aibă un început şi un sfârşit identificabile clar.
Trebuie specificate, de asemenea, variante posibile, cum ar fi scenariu de
succes, secvenţe alternative, în timp ce, simultan, se încearcă să se aranjeze
descrierile într-o ordine secvenţială, pentru a îmbunătăţi înţelegerea lor.

Scenarii
Numim fiecare unitate de descriere a secvenţelor de acţiune secvenţă.
Un scenariu reprezintă o succesiune particulară a secvenţelor, care e rulat de
la începutul la sfârşitul unui caz de utilizare.
Un scenariu poate fi folosit pentru a ilustra o interacţiune sau o execuţie a
unei instanţe a unui caz de utilizare.
 Pasul 4. Descrierea textuală a cazurilor de utilizare
(continuare)
Înregistrarea descrierii textuale nu e standardizată în UML. Se recomandă:

a) Rezumatul de identificare (Identification summary) (obligatoriu): include

titlu, rezumat, datele de creare şi modificare, versiunea, persoana
responsabilă, actorii...
b) Fluxul de evenimente (Flow of events) (obligatoriu): descrie principalul
scenariu de succes (main success scenario sau basic flow of events sau
normal path), secvenţele alternative şi secveţele de erori, precum şi
precondiţiile şi postcondiţiile.
c) Cerinţe UI (UI requirements) (opţional): adăugarea constrângerilor pentru
GUI.

d) Cerinţe nefuncţionale (Non-functional constraints) (opţional): se pot

adăuga informaţiile: frecvenţă, disponibilitate, acurateţe, integritate,
confidenţialitate, performanţă etc.
a) Rezumatul de identificare (Identification summary)

Titlu: Retragere bani folosind Visa card

Rezumat: Acest caz de utilizare permite unui posesor de card Visa (Visa
CardHolder), care nu e client al băncii, să retragă bani în limita zilnică.

Actori: Visa CardHolder (primary), Visa AS (secondary).

Creation date: xx/11/09

Date of update: zz/11/09

Version: 2.2

Person in charge: Nume Prenume

b) Fluxul evenimentelor (Flow of events)
Precondiţii:
• ATM e aprovizionat cu bani
• Nu e niciun card în cititorul de card
Main success scenario:
1. Visa CardHolder introduce cardul în cititor.
2. ATM verifică dacă este valabil cardul.
3. ATM cere Visa CardHolder pin-ul.
4. Visa CardHolder introduce pin-ul.
5. ATM verifică dacă datele sunt corecte.
6. ATM cere autorizaţie de la VISA authorisation system.
7. VISA authorisation system confirmă şi indică limita zilnică de retragere.
8. ATM cere Visa CardHolder să introducă suma dorită.
9. Visa CardHolder introduce suma dorită.
10. ATM verifică dacă suma e sub limita zilnică.
11. ATM întreabă Visa CardHolder dacă doreşte chitanţă.
12. Visa CardHolder cere chitanţa.
13. ATM returnează cardul către Visa CardHolder.
14. Visa CardHolder ia cardul.
15. ATM oferă banii şi chitanţa.
16. Visa CardHolder ia banii şi chitanţa.
O altă prezentare posibilă constă în separarea acţiunii actorilor şi sistemului:
1. Visa CardHolder introduce cardul 2. ATM verifică dacă este valabil cardul.
în cititor. 3. ATM cere Visa CardHolder pin-ul.

4. Visa CardHolder introduce pin-ul. 5. ATM verifică dacă datele sunt corecte.
6. ATM cere autorizaţie de la VISA
authorisation system.
7. VISA authorisation system 8. ATM cere Visa CardHolder să introducă
confirmă şi indică limita zilnică de suma dorită.
retragere.
9. Visa CardHolder introduce suma 10. ATM verifică dacă suma e sub limita
dorită. zilnică.
11. ATM întreabă Visa CardHolder dacă
doreşte chitanţă.
12. Visa CardHolder cere chitanţa. 13. ATM returnează cardul către Visa
CardHolder.

14. Visa CardHolder ia cardul. 15. ATM oferă banii şi chitanţa.

16. Visa CardHolder ia banii şi

chitanţa.
b) Fluxul evenimentelor (Flow of events) (continuare)
Secvenţe alternative:

A1) Număr de pin incorect: intervine la pasul 5

6. ATM informează CardHolder că pin-ul e incorect pentru prima şi a doua oară.
7. ATM înregistrează eşecul pentru card.
Scenariul se reîntoarce la pasul 3.

A2) Suma cerută e mai mare decât limita zilnică: intervine la pasul 10
11. ATM informează CardHolder că suma cerută e mai mare decât limita zilnică.
Scenariul se reîntoarce la pasul 8.

A3) Visa CardHolder nu vrea chitanţă: intervine la pasul 11

12. Visa CardHolder declină oferta de a primi o chitanţă.
13. ATM returnează cardul cătreVisa CardHolder.
14. Visa CardHolder ia cardul.
15. ATM oferă banii.
16. Visa CardHolder ia banii.
Secvenţe de erori:
E1) Card invalid: intervine la pasul 2
3. ATM informează Visa CardHolder că nu e valid cardul (nu se poate citi, expirat
etc.) şi îl confiscă, cazul de utilizare eşuează (fails).
E2) Număr de pin invalid după încercări repetate: intervine la pasul 5
6. ATM informează Visa CardHolder că pin-ul e incorect pentru a treia oară.
7. ATM confiscă (smart)cardul.
8. E notificat VISA AS; cazul de utilizare eşuează (fails).
E3) Retragere neautorizată: intervine la pasul 6
7. VISA AS interzice orice retragere.
8. ATM scoate cardul; cazul de utilizare eşuează (fails).
E4) Cardul nu e luat înapoi de Visa CardHolder: intervine la pasul 13
14. După 15 secunde, ATM confiscă (smart)cardul.
15. VISA AS e notificat; cazul de utilizare eşuează (fails).
E5) Banii nu sunt ridicaţi de Visa CardHolder: intervine la pasul 15
14. După 30 secunde, ATM ia banii înapoi.
15. VISA AS e notificat; cazul de utilizare eşuează (fails).

Postcondiţii:
• nu sunt prea evidente
c) Cerinţe UI (UI Requirements)
Mecanismul de intrare/ieşire disponibil pentru Visa CardHolder trebuie să fie:
• Un cititor de (smart)card.
• O tastatură numerică (pentru a introduce pin-ul) cu tastele “enter”, “corect” şi
“cancel”.
• Un ecran pe care să se afişeze mesajele ATM-ului.
• Taste în jurul ecranului, a.î. posesorul de card să selecteze suma dorită.
• Un distribuitor de chitanţe.
• Un distribuitor de bani.
d) Restricţii nefuncţionale (Non-functional constraints)
Timpul de răspuns:
• Interfaţa ATM trebuie să răspundă în limita maximă de 2 secunde.
• O tranzacţie nominală trebuie să se termine în cel mult 2 minute.
Disponibilitatea
• ATM trebuie să fie accesibil 24/7
• Lipsa hârtiei pentru tipărirea chitanţelor nu trebuie să fie un obstacol pentru un
posesor de card ră retragă bani.
Integritatea
• Interfaţa ATM trebuie să fie destul de robustă pentru a evita vandalizarea.
Confidenţialitatea
• Rata de eroare a procedurii de comparare a numărului de pin introdus cu acela de
pe card să fie sub 10-6.
 Pasul 5. Descrierea grafică a cazurilor de utilizare

Deşi descrierea textuală a cazurilor de utilizare e esenţială, are totuşi

dezavantajul că nu specifică în ce ordine vor fi secvenţele sau în ce
moment intervin actorii secundari.

E recomandat să completăm descrierea textuală cu una sau mai multe

diagrame UML mai dinamice.
Obs. Pentru cazurile de utilizare se recomandă diagramele de activitate (Activity
diagram), dar pot fi utile diagramele de secvenţe (Sequence diagram).

Obs. Pentru anumite scenarii se recomandă Sequence diagram, care se va numi

System sequence diagram, în care se reprezintă sistemul ca o cutie neagră,
actorul principal la stânga, iar actorii secundari în dreapta sistemului.
Crearea unei System
sequence diagram care
să descrie un main
success scenario pentru
cazul Retragere bani
folosind un Visa card.
 Activity state; Action state

O activity state modelează realizarea unei activităţi care:

• e complexă şi poate fi divizată în mai multe activităţi;
• poate fi întreruptă de un eveniment.

O action state modelează realizarea unei activităţi care:

• e simplă şi nu poate fi divizată;
• nu poate fi întreruptă de un eveniment.
Completarea diagramei de
secvenţe

Se introduc:
-activităţile principale ale
sistemului (prin mesajele
trimise către sistem);
-referinţe la secvenţele
alternative şi de eroare (prin
note).
 Organizarea cazurilor de utilizare
Identificarea părţii comune pe care cazurile de utilizare le au în comun şi
adăugarea relaţiei include.
Relaţia extend e opţională, spre deosebire de include, care e obligatorie.

Cazul de utilizare “Consultare sold” poate fi inserat în cazul de utilizare

“Retragere bani cu card bancar”, la punctul de extensie: verifica suma
Punctul de extensie trebuie declarat în descrierea textuală:
...
8. ATM cere Bank customer să introducă suma dorită.
Punct de extensie: Verifica suma.

9. Bank customer introduce suma.

 Identificarea unei relaţii de generalizare ce implică cazuri de utilizare

Considerăm cazurile de utilizare: Depunere cash şi Depunere cecuri. Ambele

implică aceiaşi actori: Bank customer ca actor principal şi Bank IS ca actor
secundar.
 Structurarea cazurilor de utilizare folosind pachete
Strategii posibile: gruparea după actor, după domeniu funcţional etc.
În acest exemplu, folosim gruparea după actorii principali
Crearea cazurilor de utilizare pentru pachetul Visa Withdrawal.
Crearea cazurilor de utilizare pentru pachetul Customer Transactions.
Crearea cazurilor de utilizare pentru pachetul Maintenance.