UML - Diagramme de cas d’utilisation (Use

case diagram)

Ilhem Boussaïd
iboussaid@[Link]

Université des Sciences et de la Technologie Houari Boumediene

Licence 3 Académique
[Link]

27 octobre 2013

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 1 / 49

 Diagramme de cas d’utilisation

Plan

1 Diagramme de cas d’utilisation

Les acteurs
Les use cases
Relations
Les scénarios
Documentation d’un CU
Étude d’un guichet automatique de banque
Références

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 2 / 49

 Diagramme de cas d’utilisation

Diagramme de cas d’utilisation

Le diagramme Use Case ou Cas d’utilisation est utilisé dans l’activité

de spécification des besoins
Il est utilisé pour :
Recueillir, analyser et organiser les besoins
Recenser les fonctionnalités d’un système
Ce qu’il devra faire (et pas "comment")
Description du comportement sous forme d’actions/réactions
Représentation des fonctions du système du point de vue des
utilisateurs.

Le diagramme Use Case doit permettre de répondre à la question Qui fait

quoi ?

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 3 / 49

 Diagramme de cas d’utilisation

Les éléments du diagramme de cas

d’utilisation

Les entités qui interagissent avec le système (acteurs) : Personne,

chose, logiciel, extérieur au système décrit
Les fonctionnalité visible de l’extérieur (Cas d’utilisation) : Action
déclenchée par un acteur
Le système observé (subject), modélisé dans le diagramme de cas
d’utilisation sous forme de grand rectangle comprenant tous les cas
d’utilisation.
Une ligne entre un acteur et un cas d’utilisation signifie qu’une
communication est établie. Elle est modélisée sous forme
d’association en UML.
Décription textuellement des interactions (scénarios)

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 4 / 49

 Diagramme de cas d’utilisation

Les éléments du diagramme de cas

d’utilisation
CasUtilisation3
Le diagramme est constitué de
système
acteurs
cas d’utilisation

Système

CasUtilisation1

Acteur1

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 5 / 49

 Diagramme de cas d’utilisation

Les éléments du diagramme de cas

d’utilisation
Exemple :

Système

Acteur

Cas d’utilisation
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 6 / 49
 Diagramme de cas d’utilisation Les acteurs

Acteur

Un acteur (actor ) est un rôle joué par l’utilisateur du système logiciel.

En plus des personnes physiques, les acteurs peuvent être :
Des périphériques manipulés par le système (imprimantes, robots, . . . ) ;
Des logiciels déjà disponibles à intégrer dans le projet ;
Des systèmes informatiques externes au système mais qui interagissent
avec lui (SGBD, horloge, etc.)
Les acteurs se trouvent obligatoirement à l’extérieur du système.

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 7 / 49

 Diagramme de cas d’utilisation Les acteurs
CasUtilisation1

Acteur CasUtilisation2

Les acteurs sont souvent spécifiés sous CasUtilisation3

forme de personnages
stylisés.

Acteur1

Ils peuvent également être représentés par un rectangle doté du

stéréotype "actor" ou par un pictogramme (par exemple un
symbole d’ordinateur).

« actor »
Acteur 3

Acteur 2

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 8 / 49

 Diagramme de cas d’utilisation Les acteurs

Acteur
Attention !
Un acteur correspond à un rôle, pas à une personne physique.
Une même personne physique peut être représentée par plusieurs
acteurs si elle a plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles
seront représentées par un seul acteur.
un acteur n’est pas forcément "humain"
Figure 2.1 – Exemple de diagramme de cas d’utilisation

Figure 2.2 – Exemple de diagramme de cas d’utilisation

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 9 / 49
 Diagramme de cas d’utilisation Les acteurs

Acteur principal ou secondaire

Un acteur principal est celui pour qui le cas d’utilisation produit un
résultat observable.
l’acteur principal est à l’initiative des échanges nécessaires pour réaliser
le cas d’utilisation (C’est lui qui déclenche le cas d’utilisation).
Les acteurs secondaires sont souvent sollicités pour des informations
complémentaires ; ils peuvent uniquement consulter ou informer le
système lors de l’exécution du cas d’utilisation.

Paiement CB
« secondary »

Client Banque

Dans la mesure du possible, disposez les acteurs principaux à gauche des

cas d’utilisation et les acteurs secondaires à droite.
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 10 / 49
 Diagramme de cas d’utilisation Les use cases

Cas d’utilisation (CU)

Un cas d’utilisation (use case) est une manière spécifique d’utiliser
le système.
Il permet de décrire ce que le futur système devra faire, sans spécifier
comment il le fera.
Généralement modélisés sous forme d’ellipse
Le nom peut figurer à l’intérieur de l’ellipse ou au-dessous
Peuvent éventuellement être représentés par un rectangle doté d’un
pictogramme d’ellipse

CasUtilisation1

CasUtilisation2

CasUtilisation3

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 11 / 49

 Diagramme de cas d’utilisation Les use cases

Recenser les cas d’utilisation

Il n’y a pas une manière mécanique et totalement objective de repérer

les cas d’utilisation
Il faut se placer du point de vue de chaque acteur et déterminer :
comment il se sert du système,
dans quels cas il l’utilise,
à quelles fonctionnalités il doit avoir accès.
Pour chaque acteur, il convient de :
Rechercher les différentes intentions avec lesquelles il utilise le système
Déterminer dans le cahier des charges les services fonctionnels attendus
du système

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 12 / 49

 Diagramme de cas d’utilisation Les use cases

Recenser les cas d’utilisation

Il faut éviter les redondances et limiter le nombre de cas en se

situant au bon niveau d’abstraction (par exemple, ne pas réduire un
cas à une action).
Il ne faut pas faire apparaître les détails des cas d’utilisation, mais il
faut rester au niveau des grandes fonctions du système.
Il ne doit pas y avoir de notion temporelle dans un diagramme de
cas d’utilisation (sera pris en compte dans le diagramme de séquence
par exemple).

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 13 / 49

 Diagramme de cas d’utilisation Les use cases

Relations entre cas d’utilisation et acteurs

(association)

Les acteurs impliqués dans un cas d’utilisation lui sont liés par une
association.

Un acteur peut utiliser plusieurs fois le même cas d’utilisation.

Multiplicité : Nombre de fois où l’acteur peut déclencher le cas
∗ : une infinité de fois (pas représenté en général)
[n..m] : entre n et m fois
n : exactement n fois

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 14 / 49

 Diagramme de cas d’utilisation Relations

Relation acteur-acteur
Une seule relation possible : la généralisation/spécialisation

Annuler commande

Commercial

Editer statistiques

Directeur

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 15 / 49

 Diagramme de cas d’utilisation Relations

Relation cas d’utilisation-cas d’utilisation

l’inclusion («include») : le cas A inclut le cas B (B est une partie
obligatoire de A).

A <<include>> B

l’extension («extend») : le cas B étend le cas A (B est une partie

optionnelle de A).

A B
<<extend>>

généralisation/spécialisation : le cas A est une généralisation du cas

du cas B (B est une sorte de A).

A B

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 16 / 49

 Diagramme de cas d’utilisation Relations

Relation d’inclusion

La relation include (include relationship) permet à la fonctionnalité

commune de plusieurs cas d’utilisation d’être décrite par un cas
d’utilisation (Ex. s’authentifier).
Rôle de la relation d’inclusion :
Décomposer un cas complexe en sous-cas plus simples
Factoriser une partie d’un cas d’utilisation commune à d’autres cas
d’utilisation

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 17 / 49

 Diagramme de cas d’utilisation Relations

Relation d’inclusion

Quand un cas est trop complexe (faisant intervenir un trop grand

nombre d’actions), on peut procéder à sa décomposition en cas plus
simples.

<<include>>
Valider panier

Passer commande <<include>>

Client S'authentifier

<<include>>

Payer

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 18 / 49

 Diagramme de cas d’utilisation Relations

Relation d’inclusion

La relation include factoriser une partie d’un cas d’utilisation

commune à d’autres cas d’utilisation (évite la description multiple du
même comportement).

Passer commande <<include>>

S'authentifier
Client <<include>>

Suivre commande

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 19 / 49

 Diagramme de cas d’utilisation Relations

Relation d’extension

On utilise principalement cette relation pour séparer le comportement

optionnel (les variantes) du comportement obligatoire.
Le cas d’utilisation A est complété par le cas d’utilisation B.
Le cas d’utilisation A décrit la fonctionnalité de base, le cas
d’utilisation B spécifie les extensions.
Le cas d’utilisation A peut être exécuté seul ou avec les extensions.
A : Cas principal

Commander article

B : Cas d’extension
Condition:
<<extend>>
Article indisponible

Se procurer l'article auprès du fournisseur

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 20 / 49

 Diagramme de cas d’utilisation Relations

Relation de généralisation

Payer par CB

Payer

Client
Virement

Un virement est un cas particulier de paiement.

Un virement est une sorte de paiement.

La flèche pointe vers l’élément général.

Cette relation de généralisation/spécialisation est présente dans la
plupart des diagrammes UML et se traduit par le concept d’héritage
dans les langages orientés objet.
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 21 / 49
 Diagramme de cas d’utilisation Relations

Relation cas d’utilisation-cas d’utilisation -

Exemple

System

<<include>>

Acheter CD Identification

<<include>>
Client
Payer par CB

Payer

Payer par chèque

<<extend>>
Si promotion

Réduction

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 22 / 49

 Diagramme de cas d’utilisation Relations
# Une des forces de la notation UML est de proposer de nombreux types de
diagramme qui mettent en avant des aspects différents d’une description. Ainsi, le
Relation entre éléments de base (acteur, CU)
modélisateur peut utiliser le type de diagramme qui lui paraît le plus adapté pour
représenter son problème (et sa solution), tout en restant dans la norme.

3. Relation entre éléments de base (acteur, CU)

#UML
Attention ! se concentre sur la description du système et de ses interactions avec
l'extérieur. C’est un formalisme bien trop pauvre pour décrire l'intérieur du système.
Par contre, les autres modèles UML peuvent être servir pour décrire ces types de
Les communications internes (entre cas d’utilisations) ne sont pas
communications.
modélisées
0 Les communications internes (entre cas d’utilisations) ne sont pas modélisées.
0 Les communications externes (entre acteurs) ne sont pas modélisées.
Les communications externes (entre acteurs) ne sont pas modélisées.

GAB

ConsulterSonCompte
Retirer de
Client
l’argent
Porteur de carte RetirerDeLArgent
AuDistributeur

RetirerDeLArgent
Déposer ParChèque
Client banque de Guichetier
l’argent Système
Bancaire

[Link] Page 2

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 23 / 49

 Diagramme de cas d’utilisation Relations

Exemple

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 24 / 49

 Diagramme de cas d’utilisation Les scénarios

Scénario
Méthode de
ConceptionUn scénario représente une séquence d’interactions entre le système et
Orientée Objet
Diagramme de cas d’utilisation
ses acteurs
A. Lewandowski
Les scénarios
Il décrit une exécution particulière d’un cas d’utilisation du début à la
Scénarios
fin • séquence particulière de messages dans le CU
Introduction
Un cas d’utilisation
• « chemincontient en général :
» particulier
• peut être vu comme une instance du CU
Concepts de base un scénario nominal et
Diagrammes UML • tous scénarios
plusieurs les scénarios d’un CU sont
alternatifs (qui issus du mêmede
se terminent acteur
façonet normale) ou
Introduction à UML
Diagramme de cas ont le
d’erreur (quimême objectif en échec).
se terminent
d’utilisation
Diagramme de classes
Diagramme de
• scénarios servent de base aux jeux d’essais
packages
Diagramme d’objets
Diagramme de
début
communication fin normale
Diagramme de
séquence
Diagramme d’activité
Diagramme d’états
Autres diagrammes

Démarche de
conception OO

erreur

63 I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 25 / 49

 Diagramme de cas d’utilisation Documentation d’un CU

Documentation d’un cas d’utilisation

Fiche de description textuelle d’un CU

pas normalisé par UML, mais fortement recommandé
champs de description (nom, acteur principal, préconditions, etc.)
lisible et informel

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 26 / 49

 Diagramme de cas d’utilisation Documentation d’un CU

Documentation d’un cas d’utilisation

Structuration de la fiche
1 Sommaire d’identification
obligatoire
titre, résumé, version, responsable, auteur, etc.
2 Description des scénarios
obligatoire
scénario nominal (déroulement « classique » du CU), scénarios
alternatifs, scénarios d’erreur, préconditions, postconditions
3 Exigences non-fonctionnelles
optionnel (si pertinent)
fréquence, disponibilité, confidentialité, performances, concurrence,
contraintes d’interface, etc.

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 27 / 49

 Diagramme de cas d’utilisation Documentation d’un CU

Documentation d’un cas d’utilisation -

Exemple

Paiement CB
« secondary »

Client Banque

Identification :
Nom du cas : Payer CB
Objectif : Détailler les étapes permettant à client de payer par carte
bancaire
Acteurs : Client, Banque (secondaire)
Date : 21/11/2010
Responsables : Toto
Version : 1.0

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 28 / 49

 Diagramme de cas d’utilisation Documentation d’un CU

Documentation d’un cas d’utilisation -

Exemple
Séquencements :
Le cas d’utilisation commence lorsqu’un client demande le paiement
par carte bancaire
Pré-conditions :
Le client a validé sa commande
Enchaînement nominal :
1 Le client saisit les informations de sa carte bancaire
2 Le système vérifie que le numéro de CB est correct
3 Le système vérifie la carte auprès du système bancaire
4 Le système demande au système bancaire de débiter le client
5 Le système notifie le client du bon déroulement de la transaction
Enchaînements alternatifs :
1 En (2) : si le numéro est incorrect, le client est averti de l’erreur, et
invité à recommencer
2 En (3) : si les informations sont erronées, elles sont re-demandées au
client
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 29 / 49
 Diagramme de cas d’utilisation Documentation d’un CU

Documentation d’un cas d’utilisation -

Exemple

Post-conditions :
La commande est validée
Le compte de l’entreprise est crédité
Rubriques optionnelles :
Contraintes non fonctionnelles :
Fiabilité : les accès doivent être sécurisés
Confidentialité : les informations concernant le client ne doivent pas
être divulgués
Contraintes liées à l’interface homme-machine : :
Toujours demander la validation des opérations bancaires

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 30 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Étude d’un guichet automatique de banque

(GAB)
On considère le système suivant de gestion d’un Guichet Automatique
de Banque (GAB) :
le distributeur délivre de l’argent à tout porteur d’une carte de la
banque (autorisation d’un certain montant par le Système
d’Information de la banque) ou d’une carte de crédit (autorisation à
distance par le Système d’Autorisation),
Pour les clients de la banque, il permet en plus :
la consultation du solde du compte
le dépôt d’argent (chèque ou numéraire)
Toute transaction est sécurisée et nécessite par conséquent une
authentification (code personnel vérifié avec le code enregistré sur la
puce de la carte - la carte est avalée après trois échecs).
Dans le cas où une carte est avalée par le distributeur, un opérateur de
maintenance se charge de la récupérer. C’est la même personne qui
collecte également les dépôts d’argent et qui recharge le distributeur.
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 31 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Étape 1 - Identification des acteurs du GAB

Quelles sont les entités externes qui interagissent directement avec
le GAB ?
tout Porteur de carte . . .
Les clients de la banque porteurs d’une carte de crédit de cette
dernière.
le Système d’autorisation global Carte Bancaire, pour les
transactions de retrait ;
le Système d’information de la banque, pour autoriser toutes les
transactions effectuées par un client avec sa carte de la banque, mais
également pour accéder au solde des comptes.
Opérateur de maintenance pour le rechargement en billets du
distributeur, la récupération des cartes avalées, etc.
Attention !
le lecteur de carte et le distributeur de billets font partie du GAB ⇒ ce ne
sont pas des acteurs !
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 32 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Étape 2 - Identification des cas d’utilisation

Préparez une liste préliminaire des cas d’utilisation du GAB, par

acteur.
Porteur de carte :
Retirer de l’argent.
Client banque :
Retirer de l’argent.
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.).

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 33 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Étape 3 - Réalisation de diagrammes de cas

d’utilisation

System

Retirer de l'argent

Porteur de carte
Consulter son solde

Déposer l'argent

Client de la banque

Recharger la caisse

Collecter dépôt d'argent

Opérateur de maintenance

Maintenir l'état opérationnel

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 34 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Acteurs secondaires
Complétez le diagramme de cas d’utilisation préliminaire en
ajoutant les acteurs secondaires.
System

Retirer de l'argent

Sys. Auto.
Porteur de carte
Consulter son solde

Déposer l'argent

S.I. Banque
Client de la banque

Un problème se pose pour le cas d’utilisation partagé Retirer de

l’argent.
Pour le Porteur de carte non client, il faudra faire appel au Sys.
Auto. (qui se chargera de contacter le SI de la banque du porteur),
Pour un client de la banque, le GAB contactera directement le SI
banque.
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 35 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Acteurs secondaires

Solution : distinguer deux cas d’utilisation pour le retrait d’argent :

Retirer de l’argent
Retirer de l’argent avec une carte de la banque.

System

Retirer de l'argent

Sys. Auto.
Porteur de carte

Retirer de l'argent avec une carte de la banque

S.I. Banque
Client de la banque

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 36 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Étape 4 – Description textuelle des cas d’utilisation

Étape 4 - Description textuelle des cas
d’utilisation
EXERCICE 1-6.
Partie obligatoire du cas d’utilisation
Décrivez la partie obligatoire du cas d’utilisation RETIRER DE L’ARGENT (pour
Description du cas d’utilisation RETIRER DE L’ARGENT (pour l’acteur
l’acteur non client de la banque).
non client de la banque).
ion
Solut

Sommaire d’identification
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
. Il s’agit ici d’un choix de modélisation arbitraire ! Nous ne disons pas que toute autre solution serait mauvaise, mais
nous expliquons avec des arguments concrets pourquoi nous préférons la nôtre.

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 37 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque
29 Vendredi, 18. ao t 2006 11:31 11

Pré-Conditions

Modélisation fonctionnelle : étude de cas

CHAPITRE 1

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 carte5 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(USTHB)
I. BOUSSAID GAB demande une autorisation
GL - Use Case au Système d’autorisation.
27 octobre 2013 38 / 49
 Préconditions
Diagramme de cas d’utilisation Étude d’un guichet automatique de banque
• La caisse du GAB est alimentée (il reste au moins un billet !).
• Aucune nominal
Scénario 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 carte5 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.
I. BOUSSAID (USTHB) GL 6- Use Case 27 octobre 2013 39 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque
Point de vue fonctionnel
32
PREMIÈRE PARTIE
Scénarios alternatifs ou d’erreur
propose d’indiquer les différentes alternatives par des lettres collées au chif-
fre du numéro de l’étape du scénario nominal concernée. Une version alterna-
tive de la solution précédente pourrait être alors :
2a. Carte illisible ou non valable :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
2b. Carte périmée :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation
se termine en échec.
4a. Délai de saisie du code expiré :
Le GAB avertit le porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
4-12a.9 Le Porteur annule la transaction :
Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.
5a. Code d’identification erroné pour la première ou deuxième fois :
5a1. Le GAB enregistre l’échec sur la carte.
5a2. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 3.
5b. Code d’identification erroné pour la troisième fois :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation
se termine en échec.
7a. Transaction refusée par le Système d’autorisation :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
7b. Délai de réponse du Système d’autorisation expiré :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
I. BOUSSAID (USTHB)
termine en échec. GL - Use Case 27 octobre 2013 40 / 49
 5a. Diagramme de cas d’utilisation
Code d’identification Étude
erroné pour d’un guichet
la première automatique
ou deuxième fois : de banque
5a1. Le GAB enregistre l’échec sur la carte.
5a2. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 3.
Scénarios alternatifs ou d’erreur
5b. Code d’identification erroné pour la troisième fois :
Le GAB avertit le Porteur et confisque la carte ; le cas d’utilisation
se termine en échec.
7a. Transaction refusée par le Système d’autorisation :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
7b. Délai de réponse du Système d’autorisation expiré :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
9a. Délai de saisie du montant expiré :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
10a. Montant demandé supérieur au solde hebdomadaire :
10a1. Le GAB avertit le Porteur et le scénario nominal reprend à l’étape 8.
10b. Solde hebdomadaire insuffisant :
Le GAB avertit le Porteur et éjecte la carte ; le cas d’utilisation se
termine en échec.
12a. Le Porteur ne demande pas de ticket :
Le cas d’utilisation continue à l’identique, sauf l’impression du ticket.
9. La notation 4-12 signifie : « de l’étape 4 à l’étape 12 ».

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 41 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Scénarios alternatifs ou d’erreur

5- 050 [Link] Page 33 Vendredi, 18. ao t 2006 11:31 11

Modélisation fonctionnelle : étude de cas

33
CHAPITRE 1

14a. Délai de retrait de la carte expiré :

14a1. Le GAB confisque la carte et annule la transaction ;
14a2. Le GAB avertit le Système d’autorisation et le cas d’utilisation se
termine en échec.
16a. Délai de retrait des billets expiré :
Le GAB confisque les billets et annule la transaction ; le cas d’utili-
sation se termine en échec.
1-7a. Coupure réseau avec le Système d’autorisation :
Le GAB avertit le Porteur et é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 infor-
mations 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.

EXERCICE 1-7.
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 42 / 49
 Diagramme de cas d’utilisation CHAPITRE 1 de banque
Étude d’un guichet automatique

14a. Délai de retrait de la carte expiré :

Post conditions
14a1. Le GAB confisque la carte et annule la transaction ;
14a2. Le GAB avertit le Système d’autorisation et le cas d’utilisation se
termine en échec.
16a. Délai de retrait des billets expiré :
Le GAB confisque les billets et annule la transaction ; le cas d’utili-
sation se termine en échec.
1-7a. Coupure réseau avec le Système d’autorisation :
Le GAB avertit le Porteur et é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 infor-
mations 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.

EXERCICE 1-7.
Paragraphes optionnels du cas d’utilisation

Complétez la description du cas d’utilisation RETIRER DE L’ARGENT avec les para-

graphes optionnels. Détaillez les besoins en interface homme-machine.

ion
Exigences non fonctionnelles10
Solut

Contraintes
I. BOUSSAID (USTHB) GL - Use Descriptif
Case 27 octobre 2013 43 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Exigences non fonctionnelles

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.
Concurrence : Non applicable (mono-utilisateur).
Disponibilité ; Le GAB est accessible 7 jours sur 7, 24 h sur 24.
L’absence de papier pour imprimer les tickets ne doit pas empêcher les
retraits.
Intégrité : Les interfaces du GAB doivent être très robustes pour
prévenir le vandalisme.
Confidentialité : La comparaison du code d’identification saisi sur le
clavier du GAB avec celui de la carte doit être fiable à 10−6 .

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 44 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Besoins d’interface Homme/Machine (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.

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 45 / 49

 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

À retenir !
Cas d’utilisation - Pourquoi faire ?
Permettre au client de décrire ses besoins
Parvenir à un accord (contrat) entre clients et développeurs Point
d’entrée pour les étapes suivantes du développement

Qu’est ce qu’un cas d’utilisation ?

Usage que des acteurs font du système
Acteur : Entité extérieure qui interagit avec le système
Une même personne peut jouer le rôle de différents acteurs
Un acteur peut être un autre système (SGBD, Horloge, ...)
Usage : Séquence d’interactions entre le système et les acteurs
Généralement composé de plusieurs scénarios (instances)
Scénario de base et ses variantes (cas particuliers)
Description des scénarios à l’aide de diagrammes de séquence
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 46 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

À retenir !
Comment découvrir les cas d’utilisation ?
Délimiter le périmètre du système
Identifier les acteurs interagissant avec le système :
Ceux qui utilisent le système
Ceux qui fournissent un service au système
Identifier les acteurs principaux
→ Ceux qui utilisent le système pour atteindre un but
Définir les cas d’utilisation correspondant à ces buts
→ Nom = Verbe à l’infinitif + Groupe nominal

Comment décrire les cas d’utilisation ?

Diagramme de cas d’utilisations
Récapitulatif graphique des interactions entre acteurs et cas
Diagramme de séquence
I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 47 / 49
 Diagramme de cas d’utilisation Étude d’un guichet automatique de banque

Diagramme de cas d’utilisation

Pour construire le diagramme de cas d’utilisation il faut :

Identifier les entités qui interagissent avec le système (acteurs)
Personne, chose, logiciel, extérieur au système décrit
Représente un rôle (plusieurs rôles possibles pour une même entité)
Identifié par le nom du rôle
Déterminer les fonctionnalité visible de l’extérieur (Use cases)
Action déclenchée par un acteur
Identifié par une action (verbe à l’infinitif)
Décrire textuellement les interactions (scénarios)
Ne pas confondre utilisateur et acteur

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 48 / 49

 Diagramme de cas d’utilisation Références

A. Lewandowski Cours : Méthode de Conception Orientée Objet

Université du Littoral Côte d’Opale
Pierre Gérard Cours : Introduction à UML 2 Université de Paris 13 -
IUT Villetaneuse
Pascal Roques UML2 par la pratique Edition Eyrolles

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 49 / 49

 Diagramme de cas d’utilisation Références

Questions

I. BOUSSAID (USTHB) GL - Use Case 27 octobre 2013 49 / 49