Étude d’un Guichet Automatique de Banque

Page 1 sur 14Lecteur de document UniversityLib

Étude d’un Guichet Automatique de Banque

Software Engineering / System Modeling · notes

Voir tous les documents en électronique et automatique

**ÉTUDE D’UN 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 l’argent, *via* un lecteur de carte et un distributeur de billets. 2. Consultation de solde de compte, dépôt d’argent qu’il soit dépôt en numéraire ou dépôt de chèques pour les clients porteurs d’une carte de la banque adossée au GAB. Le client pourra éventuellement consulter son solde lors de l’opération de retrait d’argent. 3. Toutes les transactions sont sécurisées. S’il s’agit d’un 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 d’autorisation (qui se chargera ensuite de contacter le SI de la banque du porteur). 4. Un opérateur de maintenance s’occupera 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 d’utilisation ; 4. Construire un diagramme de cas d’utilisation ; 5. Décrire textuellement les cas d’utilisation ; 6. Compléter les descriptions par des diagrammes dynamiques ; 7. Organiser et structurer les cas d’utilisation.

**** **Identification des acteurs**

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

**Phrase 1** : Tout Porteur de carte pourra retirer de l’argent, *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 qu’acteur, car l’acteur est celui qui bénéficie de l’utilisation du système. C’est bien le Porteur de carte qui retire de l’argent 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 d’une carte de crédit de la banque adossée au GAB.

* Cette phrase identifie des services supplémentaires qui ne sont proposés qu’aux clients de la banque porteurs d’une carte de cette dernière. Il s’agit donc d’un profil différent du précédent : acteur : **Client de la banque**

**Phrase 3** :

* Cette phrase nous permet d’identifier les deux acteurs suivants : le SI **de la banque** pour autoriser les transactions des clients de la banque et le **Système d’autorisation** 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 s’occupera de recharger le distributeur et de maintenir le système opérationnel.

* Cette phrase nous soumet un autre acteur : L’opérateur de maintenance.

**Diagramme de contexte statique**

Son objectif est simple. Il doit présenter le système à modéliser sous la forme d’une « 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 n’y a qu’une 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 d’exclusion serait d’utiliser le concept d’héritage.

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

**Diagramme de contexte statique du GAB**

**Identification des cas d’utilisation**

| | | | --- | --- | | Acteurs | Cas d’utilisation | | Porteur de carte | • Retirer de l’argent. | | Client banque | • Retirer de l’argent (à ne pas oublier !). • Consulter le solde de son compte courant. • Déposer de l’argent (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 d’autorisation (Sys. Auto.) | Néant | | Système d’information (SI) banque | Néant |

**Diagramme de cas d’utilisation**

| | | --- | | **![](data:image/png;base64...)** | | *Figure : Diagramme de cas d’utilisation préliminaire du GAB* |

Le cas d’utilisation *Retirer de l*’*argent* a deux acteurs principaux possibles (mais exclusifs du point de vue de la simultanéité). Une autre façon de l’exprimer consiste à considérer l’acteur *Client de la banque* comme une spécialisation (au sens de la relation d’héritage) de l’acteur 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 d’autres qui lui sont propres en tant que client.

| | | --- | | ![](data:image/png;base64...) | | *Version plus sophistiquée du diagramme de cas d’utilisation préliminaire* |

* Il nous reste maintenant à ajouter les acteurs secondaires pour compléter le diagramme de cas d’utilisation. * Pour tous les cas d’utilisation 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 d’utilisation partagé *Retirer de l’argent.* En effet, si l’acteur 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, s’il s’agit d’un **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 d’hé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.

Publicité

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 d’utilisation Retirer de l’argent sélectivement deux par deux et non pas tous ensemble. * Une autre solution consiste à distinguer deux cas d’utilisation pour le retrait d’argent : Retirer de l’argent et Retirer de l’argent avec une carte de la banque.

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

* Pour faire en sorte que l’accès au DAB soit mutuellement exclusif pour les acteurs Porteur de carte non client et client de la banque, nous auront recours au concept d’hé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 d’inclusion, d’extension et de généralisation.

**Relation d’inclusion**

* D’après la phrase 4 toutes les opérations sont sécurisées. C’est-à-dire qu’il est impératif de s’authentifier avant de pouvoir accéder aux différentes fonctionnalités du GAB. Ce qui implique une relation **d’inclusion** entre les différents CU précédemment énoncés et le CU « s’authentifier ».

| | | --- | | ![](data:image/png;base64...) | | *Figure : Relation d’inclusion entre CU* |

**Relation d’extension**

* Nous remarquons que pour un client de la banque, il est possible lors de l’opération de retrait de consulter son solde afin de s’assurer 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 d’extension entre le CU « Retirait de l’argent 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 l’argent est une généralisation des CU « déposer des chèques » et déposer des numéraires » d’où la représentation suivante :

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

Le résultat final nous donne le diagramme de cas d’utilisation suivant :

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

**Description textuelle des cas d’utilisation**

**Titre** : Retirer de l’argent

**Résumé** : ce cas d’utilisation permet à un Porteur de carte, qui n’est pas client de la banque, de retirer de l’argent, si son crédit hebdomadaire le permet.

**Acteurs** : Porteur de carte (principal), *Système d’autorisation (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 d’autorisation 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 d’identification.

4. Le Porteur de carte saisit son code d’identification.

Publicité

5. Le GAB compare le code d’identification avec celui qui est codé sur la puce de la carte.

6. Le GAB demande une autorisation au Système d’autorisation.

7. Le Système d’autorisation 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 s’il 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.

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 d’identification. | | 4. Le Porteur de carte saisit son code d’identification. | 5. Le GAB compare le code d’identification avec celui qui est codé sur la puce de la carte. 6. Le GAB demande une autorisation au Système d’autorisation. | | 7. Le Système d’autorisation 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 s’il 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 d*’*identification provisoirement erroné*

L’enchaî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*

L’enchaî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é*

L’enchaî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 d’erreur**

Publicité

*E1 : carte non-valide*

L’enchaînement E1 démarre au point 2 du scénario nominal.

3. Le GAB indique au Porteur que la carte n’est pas valide (illisible, périmée, etc.), la confisque ; le cas d’utilisation se termine en échec.

*E2 : code d*’*identification définitivement erroné*

L’enchaî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 d’autorisation est informé ; le cas d’utilisation se termine en échec.

*E3 : retrait non autorisé*

L’enchaînement E3 démarre au point 6 du scénario nominal.

7. Le Système d’autorisation interdit tout retrait.

8. Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.

*E4 : carte non reprise*

L’enchaî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 d’autorisation est informé ; le cas d’utilisation se termine en échec.

*E5 : billets non pris*

L’enchaî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 d’utilisation se termine en échec.

*E6 : annulation de la transaction*

L’enchaînement E6 peut démarrer entre les points 4 et 12 du scénario nominal.

4 à 12. Le Porteur de carte demande l’annulation de la transaction en cours.

Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.

**Postconditions**

* La caisse du GAB contient moins de billets qu’au début du cas d’utilisation (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 d’utilisation**

**Exigences non fonctionnelles10**

* Temps de réponse : L’interface du GAB doit réagir en l’espace 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). L’absence de papier pour imprimer les tickets ne doit pas empêcher les retraits.

**Besoins d’IHM**

* Les dispositifs d’entré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 l’affichage 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.