Diagrame Use-Case ATM [PDF]

Zitiervorschau

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: • Să se identifice actorii • Să se identifice cazurile de utilizare

Obs. Enunţul problemei poate fi incomplet (aşa cum se întâmplă în 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

Consultare sold

Depozitează bani

Frontiera sistemului

Depozitează cecuri

Umple bancomatul

Recuperează carduri

Recuperează cecuri

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

Consultare sold

Depozitează bani

Depozitează cecuri

Umple bancomatul

Recuperează carduri

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.