Étude d’un Guichet Automatique de Banque

1/14
100%

TUDE DUN GUICHET AUTOMATIQUE DE BANQUE

(UML 2 par la pratique, Pascal Roque)

Cette tude de cas concerne un syst me simplifi de Guichet Automatique de Banque (GAB). Le GAB offre les services suivants :

1. Tout Porteur de carte pourra retirer de largent, via un lecteur de carte et un distributeur de billets.

2. Consultation de solde de compte, d p t dargent quil soit d p t en num raire ou d p t de ch ques pour les clients porteurs dune carte de la banque adoss e au GAB. Le client pourra ventuellement consulter son solde lors de lop ration de retrait dargent.

3. Toutes les transactions sont s curis es. Sil sagit dun client de la banque, le GAB contactera directement le SI banque alors que pour un porteur de carte non client de la banque, il faudra faire appel au Syst me dautorisation (qui se chargera ensuite de contacter le SI de la banque du porteur).

4. Un op rateur de maintenance soccupera de recharger le distributeur et de maintenir le syst me op rationnel (r cup rer les cartes aval es, r cup rer les ch ques d pos s, remplacer le ruban de papier, etc.).

Question :

1. Identifier les acteurs ;

2. R aliser le diagramme de contexte

3. Identifier les cas dutilisation ;

4. Construire un diagramme de cas dutilisation ;

5. D crire textuellement les cas dutilisation ;

6. Compl ter les descriptions par des diagrammes dynamiques ;

7. Organiser et structurer les cas dutilisation.

j Identification des acteurs

| |

| --- |

| Quelles sont les entit s externes qui interagissent directement avec le GAB ? |

Phrase 1 : Tout Porteur de carte pourra retirer de largent, via un lecteur de carte et un distributeur de billets.

  • Un premier acteur vident : tout Porteur de carte .
  • Le lecteur de carte et le distributeur de billets font partie du GAB. Ils ne peuvent donc pas tre consid r s comme des acteurs !
  • la carte bancaire elle-m me est-elle un acteur ?

La carte est bien externe au GAB, et elle interagit avec lui& Pourtant, nous ne recommandons pas de la r pertorier en tant quacteur, car lacteur est celui qui b n ficie de lutilisation du syst me. Cest bien le Porteur de carte qui retire de largent pour le d penser ensuite, pas la carte !

Phrase 2 : Consultation de solde de compte, d p t en num raire et d p t de ch ques pour les clients porteurs dune carte de cr dit de la banque adoss e au GAB.

  • Cette phrase identifie des services suppl mentaires qui ne sont propos s quaux clients de la banque porteurs dune carte de cette derni re. Il sagit donc dun profil diff rent du pr c dent : acteur : Client de la banque

Phrase 3 :

  • Cette phrase nous permet didentifier les deux acteurs suivants : le SI de la banque pour autoriser les transactions des clients de la banque et le Syst me dautorisation pour les retraits effectu par les porteurs de cartes qui ne sont pas client de l a banque.

Phrase 4 : Un op rateur de maintenance soccupera de recharger le distributeur et de maintenir le syst me op rationnel.

  • Cette phrase nous soumet un autre acteur : Lop rateur de maintenance.

Diagramme de contexte statique

Son objectif est simple. Il doit pr senter le syst me mod liser sous la forme dune bo te noire et les diff rents acteurs qui interagissent avec ce syst me. Bien que ce diagramme ne fasse pas partie des diagrammes UML officiels , son int r t reste ind niable.

  • Le GAB est un syst me fondamentalement mono-utilisateur : tout instant, il ny a quune instance de chaque acteur (au maximum) connect e au syst me.
  • Client banque et Porteur de carte sont mutuellement exclusifs,

![](data:image/png;base64...)

Une solution plus labor pour r soudre le probl me dexclusion serait dutiliser le concept dh ritage.

Publicité

![](data:image/x-emf;base64...)

Diagramme de contexte statique du GAB

Identification des cas dutilisation

| | |

| --- | --- |

| Acteurs | Cas dutilisation |

| Porteur de carte | " Retirer de largent. |

| Client banque | " Retirer de largent ( ne pas oublier !). " Consulter le solde de son compte courant. " D poser de largent (du num raire ou des ch ques) |

| Op rateur de maintenance | "Recharger le distributeur. " Maintenir l tat op rationnel (r cup rer les cartes aval es, r cup rer les ch ques d pos s, remplacer le ruban de papier, etc.). |

| Syst me dautorisation (Sys. Auto.) | N ant |

| Syst me dinformation (SI) banque | N ant |

Diagramme de cas dutilisation

| |

| --- |

| ![](data:image/png;base64...) |

| Figure : Diagramme de cas dutilisation pr liminaire du GAB |

Le cas dutilisation Retirer de largent a deux acteurs principaux possibles (mais exclusifs du point de vue de la simultan it ). Une autre fa on de lexprimer consiste consid rer lacteur Client de la banque comme une sp cialisation (au sens de la relation dh ritage) de lacteur plus g n ral Porteur de carte.

Un client de la banque est en effet un Porteur de carte particulier qui a toutes les pr rogatives de ce dernier, ainsi que dautres qui lui sont propres en tant que client.

| |

| --- |

| ![](data:image/png;base64...) |

| Version plus sophistiqu e du diagramme de cas dutilisation pr liminaire |

  • Il nous reste maintenant ajouter les acteurs secondaires pour compl ter le diagramme de cas dutilisation.
  • Pour tous les cas dutilisation propres au client de la banque, il faut clairement faire intervenir comme acteur secondaire SI banque.
  • Mais un probl me se pose pour le cas dutilisation partag Retirer de largent. En effet, si lacteur principal est un Porteur de carte non client, il faudra faire appel au Sys. Auto. (qui se chargera ensuite de contacter le SI de la banque du porteur), alors que, sil sagit dun client de la banque, le GAB contactera directement le SI banque.
  • Nous remarquons alors que les acteurs secondaires sollicit s ne sont pas les m mes dans le cas du Porteur de carte non client et dans celui du client de la banque.
  • Nous ne retiendrons donc pas la solution pr c dente : il ne peut pas y avoir dh ritage entre client de la banque et porteur de carte car il ne font pas intervenir les m me acteur secondaire.
  • Nous consid rerons dans la suite que les d nominations Porteur de carte non client et Porteur de carte sont synonymes.

Une premi re solution consiste ajouter une association avec chacun des deux acteurs non humains.

![](data:image/png;base64...)

  • Cette mod lisation simpliste ne permet pas au lecteur du diagramme de comprendre que les acteurs participent au cas dutilisation Retirer de largent s lectivement deux par deux et non pas tous ensemble.
  • Une autre solution consiste distinguer deux cas dutilisation pour le retrait

dargent : Retirer de largent et Retirer de largent avec une carte de la banque.

![](data:image/png;base64...)

  • Pour faire en sorte que lacc s au DAB soit mutuellement exclusif pour les acteurs Porteur de carte non client et client de la banque, nous auront recours au concept dh ritage travers un nouvel acteur que nous appellerons Porteur qui repr sente une g n ralisation des deux acteurs pr c dents.
  • Nous compl terons notre diagramme par le raffinement des CU gr ce aux concepts dinclusion, dextension et de g n ralisation.

Relation dinclusion

  • Dapr s la phrase 4 toutes les op rations sont s curis es. Cest- -dire quil est imp ratif de sauthentifier avant de pouvoir acc der aux diff rentes fonctionnalit s du GAB. Ce qui implique une relation dinclusion entre les diff rents CU pr c demment nonc s et le CU sauthentifier .

| |

| --- |

Publicité

| ![](data:image/png;base64...) |

| Figure : Relation dinclusion entre CU |

Relation dextension

  • Nous remarquons que pour un client de la banque, il est possible lors de lop ration de retrait de consulter son solde afin de sassurer que le montant du retrait ne d passe pas celui de son solde. Cela se repr sente au niveau de notre repr sentation par une relation dextension entre le CU Retirait de largent avec une carte de la banque et le CU consulter solde .

![](data:image/png;base64...)

Relation de g n ralisation

Le CU d poser de largent est une g n ralisation des CU d poser des ch ques et d poser des num raires do la repr sentation suivante :

![](data:image/png;base64...)

Le r sultat final nous donne le diagramme de cas dutilisation suivant :

![](data:image/x-emf;base64...)

Description textuelle des cas dutilisation

Titre : Retirer de largent

R sum : ce cas dutilisation permet un Porteur de carte, qui nest pas client de la banque, de retirer de largent, si son cr dit hebdomadaire le permet.

Acteurs : Porteur de carte (principal), Syst me dautorisation (secondaire).

Date de cr ation : 02/03/02 Date de mise jour : 05/05/06

Version : 5.0 Responsable : Pascal Roques

Description des sc narios

Pr conditions

" La caisse du GAB est aliment e (il reste au moins un billet !).

" Aucune carte ne se trouve d j coinc e dans le lecteur.

" La connexion avec le Syst me dautorisation est op rationnelle.

Sc nario nominal

1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.

2. Le GAB v rifie que la carte introduite est bien une carte bancaire.

3. Le GAB demande au Porteur de carte de saisir son code didentification.

4. Le Porteur de carte saisit son code didentification.

5. Le GAB compare le code didentification avec celui qui est cod sur la puce de la carte.

6. Le GAB demande une autorisation au Syst me dautorisation.

7. Le Syst me dautorisation donne son accord et indique le solde hebdomadaire.

8. Le GAB demande au Porteur de carte de saisir le montant d sir du retrait.

9. Le Porteur de carte saisit le montant d sir du retrait.

10. Le GAB contr le le montant demand par rapport au solde hebdomadaire.

11. Le GAB demande au Porteur de carte sil veut un ticket.

Publicité

12. Le Porteur de carte demande un ticket.

13. Le GAB rend sa carte au Porteur de carte.

14. Le Porteur de carte reprend sa carte.

15. Le GAB d livre les billets et un ticket.

16. Le Porteur de carte prend les billets et le ticket.

Une autre pr sentation int ressante6 consiste s parer les actions des acteurs et du syst me en deux colonnes comme suit :

| | |

| --- | --- |

| 1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB. | 2. Le GAB v rifie que la carte introduite est bien une carte bancaire. 3. Le GAB demande au Porteur de carte de saisir son code didentification. |

| 4. Le Porteur de carte saisit son code didentification. | 5. Le GAB compare le code didentification avec celui qui est cod sur la puce de la carte. 6. Le GAB demande une autorisation au Syst me dautorisation. |

| 7. Le Syst me dautorisation donne son accord et indique le solde hebdomadaire. | 8. Le GAB demande au Porteur de carte de saisir le montant d sir du retrait. |

| 9. Le Porteur de carte saisit le montant d sir du retrait. | 10. Le GAB contr le le montant demand par rapport au solde hebdomadaire. 11. Le GAB demande au Porteur de carte sil veut un ticket. |

| 12. Le Porteur de carte demande un ticket. | 13. Le GAB rend sa carte au Porteur de carte. |

| 14. Le Porteur de carte reprend sa carte. | 15. Le GAB d livre les billets et un ticket. |

| 16. Le Porteur de carte prend les billets et le ticket. | |

Encha nements alternatifs

A1 : code didentification provisoirement erron

Lencha nement A1 d marre au point 5 du sc nario nominal.

6. Le GAB indique au Porteur de carte que le code est erron , pour la premi re ou deuxi me fois.

7. Le GAB enregistre l chec sur la carte.

Le sc nario nominal reprend au point 3.

A2 : montant demand sup rieur au solde hebdomadaire

Lencha nement A2 d marre au point 10 du sc nario nominal.

11. Le GAB indique au Porteur de carte que le montant demand est sup rieur au solde hebdomadaire.

Le sc nario nominal reprend au point 8.

A3 : ticket refus

Lencha nement A3 d marre au point 11 du sc nario nominal.

12. Le Porteur de carte refuse le ticket.

13. Le GAB rend sa carte au Porteur de carte.

14. Le Porteur de carte reprend sa carte.

15. Le GAB d livre les billets.

16. Le Porteur de carte prend les billets.

Encha nements derreur

Publicité

E1 : carte non-valide

Lencha nement E1 d marre au point 2 du sc nario nominal.

3. Le GAB indique au Porteur que la carte nest pas valide (illisible, p rim e, etc.), la confisque ; le cas dutilisation se termine en chec.

E2 : code didentification d finitivement erron

Lencha nement E2 d marre au point 5 du sc nario nominal.

6. Le GAB indique au Porteur de carte que le code est erron , pour la troisi me fois.

7. Le GAB confisque la carte.

8. Le Syst me dautorisation est inform ; le cas dutilisation se termine en chec.

E3 : retrait non autoris

Lencha nement E3 d marre au point 6 du sc nario nominal.

7. Le Syst me dautorisation interdit tout retrait.

8. Le GAB jecte la carte ; le cas dutilisation se termine en chec.

E4 : carte non reprise

Lencha nement E4 d marre au point 13 du sc nario nominal.

14. Au bout de 10 secondes, le GAB confisque la carte.

15. Le Syst me dautorisation est inform ; le cas dutilisation se termine en chec.

E5 : billets non pris

Lencha nement E5 d marre au point 15 du sc nario nominal.

16. Au bout de 10 secondes, le GAB reprend les billets.

17. Le cas dutilisation se termine en chec.

E6 : annulation de la transaction

Lencha nement E6 peut d marrer entre les points 4 et 12 du sc nario nominal.

4 12. Le Porteur de carte demande lannulation de la transaction en cours.

Le GAB jecte la carte ; le cas dutilisation se termine en chec.

Postconditions

  • La caisse du GAB contient moins de billets quau d but du cas dutilisation (le nombre de billets manquants est fonction du montant du retrait).
  • Une transaction de retrait a t enregistr e par le GAB avec toutes les informations pertinentes (montant, num ro de carte, date, etc.).
  • Les d tails de la transaction doivent tre enregistr s aussi bien en cas de succ s que d chec.

Paragraphes optionnels du cas dutilisation

Exigences non fonctionnelles10

  • Temps de r ponse : Linterface du GAB doit r agir en lespace de 2 secondes au maximum. Une transaction nominale de retrait doit durer moins de 2 minutes.
  • Disponibilit : Le GAB est accessible 7 jours sur 7, 24 h sur 24 (global10). Labsence de papier pour imprimer les tickets ne doit pas emp cher les retraits.

Besoins dIHM

  • Les dispositifs dentr e/sortie la disposition du Porteur de carte doivent tre :
  • " Un lecteur de carte bancaire.
  • " Un clavier num rique (pour saisir son code), avec des touches validation , correction et annulation .
  • " Un cran pour laffichage des messages du GAB.
  • " Des touches autour de l cran pour s lectionner un montant de retrait parmi ceux qui sont propos s.
  • Un distributeur de billets.
  • Un distributeur de tickets.

Étude d’un Guichet Automatique de Banque

Software Engineering / System Modeling · notes

Browse all électronique et automatique documents

TUDE DUN GUICHET AUTOMATIQUE DE BANQUE

(UML 2 par la pratique, Pascal Roque)

Cette tude de cas concerne un syst me simplifi de Guichet Automatique de Banque (GAB). Le GAB offre les services suivants :

1. Tout Porteur de carte pourra retirer de largent, via un lecteur de carte et un distributeur de billets.

2. Consultation de solde de compte, d p t dargent quil soit d p t en num raire ou d p t de ch ques pour les clients porteurs dune carte de la banque adoss e au GAB. Le client pourra ventuellement consulter son solde lors de lop ration de retrait dargent.

3. Toutes les transactions sont s curis es. Sil sagit dun client de la banque, le GAB contactera directement le SI banque alors que pour un porteur de carte non client de la banque, il faudra faire appel au Syst me dautorisation (qui se chargera ensuite de contacter le SI de la banque du porteur).

4. Un op rateur de maintenance soccupera de recharger le distributeur et de maintenir le syst me op rationnel (r cup rer les cartes aval es, r cup rer les ch ques d pos s, remplacer le ruban de papier, etc.).

Question :

1. Identifier les acteurs ;

2. R aliser le diagramme de contexte

3. Identifier les cas dutilisation ;

4. Construire un diagramme de cas dutilisation ;

5. D crire textuellement les cas dutilisation ;

6. Compl ter les descriptions par des diagrammes dynamiques ;

7. Organiser et structurer les cas dutilisation.

j Identification des acteurs

| |

| --- |

| Quelles sont les entit s externes qui interagissent directement avec le GAB ? |

Phrase 1 : Tout Porteur de carte pourra retirer de largent, via un lecteur de carte et un distributeur de billets.

  • Un premier acteur vident : tout Porteur de carte .
  • Le lecteur de carte et le distributeur de billets font partie du GAB. Ils ne peuvent donc pas tre consid r s comme des acteurs !
  • la carte bancaire elle-m me est-elle un acteur ?

La carte est bien externe au GAB, et elle interagit avec lui& Pourtant, nous ne recommandons pas de la r pertorier en tant quacteur, car lacteur est celui qui b n ficie de lutilisation du syst me. Cest bien le Porteur de carte qui retire de largent pour le d penser ensuite, pas la carte !

Phrase 2 : Consultation de solde de compte, d p t en num raire et d p t de ch ques pour les clients porteurs dune carte de cr dit de la banque adoss e au GAB.

  • Cette phrase identifie des services suppl mentaires qui ne sont propos s quaux clients de la banque porteurs dune carte de cette derni re. Il sagit donc dun profil diff rent du pr c dent : acteur : Client de la banque

Phrase 3 :

  • Cette phrase nous permet didentifier les deux acteurs suivants : le SI de la banque pour autoriser les transactions des clients de la banque et le Syst me dautorisation pour les retraits effectu par les porteurs de cartes qui ne sont pas client de l a banque.

Phrase 4 : Un op rateur de maintenance soccupera de recharger le distributeur et de maintenir le syst me op rationnel.

  • Cette phrase nous soumet un autre acteur : Lop rateur de maintenance.

Diagramme de contexte statique

Son objectif est simple. Il doit pr senter le syst me mod liser sous la forme dune bo te noire et les diff rents acteurs qui interagissent avec ce syst me. Bien que ce diagramme ne fasse pas partie des diagrammes UML officiels , son int r t reste ind niable.

  • Le GAB est un syst me fondamentalement mono-utilisateur : tout instant, il ny a quune instance de chaque acteur (au maximum) connect e au syst me.
  • Client banque et Porteur de carte sont mutuellement exclusifs,

![](data:image/png;base64...)

Une solution plus labor pour r soudre le probl me dexclusion serait dutiliser le concept dh ritage.

Advertisement

![](data:image/x-emf;base64...)

Diagramme de contexte statique du GAB

Identification des cas dutilisation

| | |

| --- | --- |

| Acteurs | Cas dutilisation |

| Porteur de carte | " Retirer de largent. |

| Client banque | " Retirer de largent ( ne pas oublier !). " Consulter le solde de son compte courant. " D poser de largent (du num raire ou des ch ques) |

| Op rateur de maintenance | "Recharger le distributeur. " Maintenir l tat op rationnel (r cup rer les cartes aval es, r cup rer les ch ques d pos s, remplacer le ruban de papier, etc.). |

| Syst me dautorisation (Sys. Auto.) | N ant |

| Syst me dinformation (SI) banque | N ant |

Diagramme de cas dutilisation

| |

| --- |

| ![](data:image/png;base64...) |

| Figure : Diagramme de cas dutilisation pr liminaire du GAB |

Le cas dutilisation Retirer de largent a deux acteurs principaux possibles (mais exclusifs du point de vue de la simultan it ). Une autre fa on de lexprimer consiste consid rer lacteur Client de la banque comme une sp cialisation (au sens de la relation dh ritage) de lacteur plus g n ral Porteur de carte.

Un client de la banque est en effet un Porteur de carte particulier qui a toutes les pr rogatives de ce dernier, ainsi que dautres qui lui sont propres en tant que client.

| |

| --- |

| ![](data:image/png;base64...) |

| Version plus sophistiqu e du diagramme de cas dutilisation pr liminaire |

  • Il nous reste maintenant ajouter les acteurs secondaires pour compl ter le diagramme de cas dutilisation.
  • Pour tous les cas dutilisation propres au client de la banque, il faut clairement faire intervenir comme acteur secondaire SI banque.
  • Mais un probl me se pose pour le cas dutilisation partag Retirer de largent. En effet, si lacteur principal est un Porteur de carte non client, il faudra faire appel au Sys. Auto. (qui se chargera ensuite de contacter le SI de la banque du porteur), alors que, sil sagit dun client de la banque, le GAB contactera directement le SI banque.
  • Nous remarquons alors que les acteurs secondaires sollicit s ne sont pas les m mes dans le cas du Porteur de carte non client et dans celui du client de la banque.
  • Nous ne retiendrons donc pas la solution pr c dente : il ne peut pas y avoir dh ritage entre client de la banque et porteur de carte car il ne font pas intervenir les m me acteur secondaire.
  • Nous consid rerons dans la suite que les d nominations Porteur de carte non client et Porteur de carte sont synonymes.

Une premi re solution consiste ajouter une association avec chacun des deux acteurs non humains.

![](data:image/png;base64...)

  • Cette mod lisation simpliste ne permet pas au lecteur du diagramme de comprendre que les acteurs participent au cas dutilisation Retirer de largent s lectivement deux par deux et non pas tous ensemble.
  • Une autre solution consiste distinguer deux cas dutilisation pour le retrait

dargent : Retirer de largent et Retirer de largent avec une carte de la banque.

![](data:image/png;base64...)

  • Pour faire en sorte que lacc s au DAB soit mutuellement exclusif pour les acteurs Porteur de carte non client et client de la banque, nous auront recours au concept dh ritage travers un nouvel acteur que nous appellerons Porteur qui repr sente une g n ralisation des deux acteurs pr c dents.
  • Nous compl terons notre diagramme par le raffinement des CU gr ce aux concepts dinclusion, dextension et de g n ralisation.

Relation dinclusion

  • Dapr s la phrase 4 toutes les op rations sont s curis es. Cest- -dire quil est imp ratif de sauthentifier avant de pouvoir acc der aux diff rentes fonctionnalit s du GAB. Ce qui implique une relation dinclusion entre les diff rents CU pr c demment nonc s et le CU sauthentifier .

| |

| --- |

Advertisement

| ![](data:image/png;base64...) |

| Figure : Relation dinclusion entre CU |

Relation dextension

  • Nous remarquons que pour un client de la banque, il est possible lors de lop ration de retrait de consulter son solde afin de sassurer que le montant du retrait ne d passe pas celui de son solde. Cela se repr sente au niveau de notre repr sentation par une relation dextension entre le CU Retirait de largent avec une carte de la banque et le CU consulter solde .

![](data:image/png;base64...)

Relation de g n ralisation

Le CU d poser de largent est une g n ralisation des CU d poser des ch ques et d poser des num raires do la repr sentation suivante :

![](data:image/png;base64...)

Le r sultat final nous donne le diagramme de cas dutilisation suivant :

![](data:image/x-emf;base64...)

Description textuelle des cas dutilisation

Titre : Retirer de largent

R sum : ce cas dutilisation permet un Porteur de carte, qui nest pas client de la banque, de retirer de largent, si son cr dit hebdomadaire le permet.

Acteurs : Porteur de carte (principal), Syst me dautorisation (secondaire).

Date de cr ation : 02/03/02 Date de mise jour : 05/05/06

Version : 5.0 Responsable : Pascal Roques

Description des sc narios

Pr conditions

" La caisse du GAB est aliment e (il reste au moins un billet !).

" Aucune carte ne se trouve d j coinc e dans le lecteur.

" La connexion avec le Syst me dautorisation est op rationnelle.

Sc nario nominal

1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.

2. Le GAB v rifie que la carte introduite est bien une carte bancaire.

3. Le GAB demande au Porteur de carte de saisir son code didentification.

4. Le Porteur de carte saisit son code didentification.

5. Le GAB compare le code didentification avec celui qui est cod sur la puce de la carte.

6. Le GAB demande une autorisation au Syst me dautorisation.

7. Le Syst me dautorisation donne son accord et indique le solde hebdomadaire.

8. Le GAB demande au Porteur de carte de saisir le montant d sir du retrait.

9. Le Porteur de carte saisit le montant d sir du retrait.

10. Le GAB contr le le montant demand par rapport au solde hebdomadaire.

11. Le GAB demande au Porteur de carte sil veut un ticket.

Advertisement

12. Le Porteur de carte demande un ticket.

13. Le GAB rend sa carte au Porteur de carte.

14. Le Porteur de carte reprend sa carte.

15. Le GAB d livre les billets et un ticket.

16. Le Porteur de carte prend les billets et le ticket.

Une autre pr sentation int ressante6 consiste s parer les actions des acteurs et du syst me en deux colonnes comme suit :

| | |

| --- | --- |

| 1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB. | 2. Le GAB v rifie que la carte introduite est bien une carte bancaire. 3. Le GAB demande au Porteur de carte de saisir son code didentification. |

| 4. Le Porteur de carte saisit son code didentification. | 5. Le GAB compare le code didentification avec celui qui est cod sur la puce de la carte. 6. Le GAB demande une autorisation au Syst me dautorisation. |

| 7. Le Syst me dautorisation donne son accord et indique le solde hebdomadaire. | 8. Le GAB demande au Porteur de carte de saisir le montant d sir du retrait. |

| 9. Le Porteur de carte saisit le montant d sir du retrait. | 10. Le GAB contr le le montant demand par rapport au solde hebdomadaire. 11. Le GAB demande au Porteur de carte sil veut un ticket. |

| 12. Le Porteur de carte demande un ticket. | 13. Le GAB rend sa carte au Porteur de carte. |

| 14. Le Porteur de carte reprend sa carte. | 15. Le GAB d livre les billets et un ticket. |

| 16. Le Porteur de carte prend les billets et le ticket. | |

Encha nements alternatifs

A1 : code didentification provisoirement erron

Lencha nement A1 d marre au point 5 du sc nario nominal.

6. Le GAB indique au Porteur de carte que le code est erron , pour la premi re ou deuxi me fois.

7. Le GAB enregistre l chec sur la carte.

Le sc nario nominal reprend au point 3.

A2 : montant demand sup rieur au solde hebdomadaire

Lencha nement A2 d marre au point 10 du sc nario nominal.

11. Le GAB indique au Porteur de carte que le montant demand est sup rieur au solde hebdomadaire.

Le sc nario nominal reprend au point 8.

A3 : ticket refus

Lencha nement A3 d marre au point 11 du sc nario nominal.

12. Le Porteur de carte refuse le ticket.

13. Le GAB rend sa carte au Porteur de carte.

14. Le Porteur de carte reprend sa carte.

15. Le GAB d livre les billets.

16. Le Porteur de carte prend les billets.

Encha nements derreur

Advertisement

E1 : carte non-valide

Lencha nement E1 d marre au point 2 du sc nario nominal.

3. Le GAB indique au Porteur que la carte nest pas valide (illisible, p rim e, etc.), la confisque ; le cas dutilisation se termine en chec.

E2 : code didentification d finitivement erron

Lencha nement E2 d marre au point 5 du sc nario nominal.

6. Le GAB indique au Porteur de carte que le code est erron , pour la troisi me fois.

7. Le GAB confisque la carte.

8. Le Syst me dautorisation est inform ; le cas dutilisation se termine en chec.

E3 : retrait non autoris

Lencha nement E3 d marre au point 6 du sc nario nominal.

7. Le Syst me dautorisation interdit tout retrait.

8. Le GAB jecte la carte ; le cas dutilisation se termine en chec.

E4 : carte non reprise

Lencha nement E4 d marre au point 13 du sc nario nominal.

14. Au bout de 10 secondes, le GAB confisque la carte.

15. Le Syst me dautorisation est inform ; le cas dutilisation se termine en chec.

E5 : billets non pris

Lencha nement E5 d marre au point 15 du sc nario nominal.

16. Au bout de 10 secondes, le GAB reprend les billets.

17. Le cas dutilisation se termine en chec.

E6 : annulation de la transaction

Lencha nement E6 peut d marrer entre les points 4 et 12 du sc nario nominal.

4 12. Le Porteur de carte demande lannulation de la transaction en cours.

Le GAB jecte la carte ; le cas dutilisation se termine en chec.

Postconditions

  • La caisse du GAB contient moins de billets quau d but du cas dutilisation (le nombre de billets manquants est fonction du montant du retrait).
  • Une transaction de retrait a t enregistr e par le GAB avec toutes les informations pertinentes (montant, num ro de carte, date, etc.).
  • Les d tails de la transaction doivent tre enregistr s aussi bien en cas de succ s que d chec.

Paragraphes optionnels du cas dutilisation

Exigences non fonctionnelles10

  • Temps de r ponse : Linterface du GAB doit r agir en lespace de 2 secondes au maximum. Une transaction nominale de retrait doit durer moins de 2 minutes.
  • Disponibilit : Le GAB est accessible 7 jours sur 7, 24 h sur 24 (global10). Labsence de papier pour imprimer les tickets ne doit pas emp cher les retraits.

Besoins dIHM

  • Les dispositifs dentr e/sortie la disposition du Porteur de carte doivent tre :
  • " Un lecteur de carte bancaire.
  • " Un clavier num rique (pour saisir son code), avec des touches validation , correction et annulation .
  • " Un cran pour laffichage des messages du GAB.
  • " Des touches autour de l cran pour s lectionner un montant de retrait parmi ceux qui sont propos s.
  • Un distributeur de billets.
  • Un distributeur de tickets.