UML - Diagramme de cas

d’utilisation (Use
case diagram)
 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.
• déterminer les limites du système
• Le diagramme Use Case doit permettre de répondre à
la question Qui fait quoi ?
 Diagramme de cas d’utilisation
• Pour construire le diagramme de cas
d’utilisation il faut :
– identifier les rôles qui interagissent avec (acteurs)
– déterminer les grandes catégories d’utilisation
(Use cases)
– décrire textuellement les interactions (scénarios)
 Les éléments du diagramme de cas
d’utilisation
• Le diagramme est constitué de
– système
– acteurs
– cas d’utilisation
• Exemple :
 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, etc.
• Les acteurs se trouvent obligatoirement à l’extérieur du
système.
 Acteur
• Les acteurs sont souvent spécifiés sous forme de personnages
stylisés.

• 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).
 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"
 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.
• dans la mesure du possible, disposez les acteurs principaux à gauche des
cas d’utilisation et les acteurs secondaires à droite.
 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
 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
 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).
 Scénario
• Un scénario représente une séquence d’interactions entre le
système et ses acteurs
• Il décrit une exécution particulière d’un cas d’utilisation du
début à la fin
• Un cas d’utilisation contient en général :
– un scénario nominal et
– plusieurs scénarios alternatifs (qui se terminent de façon normale) ou
d’erreur (qui se terminent en échec).
 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
Documentation d’un cas d’utilisation
Documentation d’un cas d’utilisation -
Exemple
Documentation d’un cas d’utilisation -
Exemple
Documentation d’un cas d’utilisation -
Exemple
 Relation acteur-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.
• Le système observé (subject) est modélisé dans le diagramme
de cas d’utilisation sous forme de grand rectangle comprenant
tous les cas d’utilisation.
 Relation acteur-acteur
• Une seule relation possible : la
généralisation/spécialisation
 Relation cas d’utilisation-cas
d’utilisation
• généralisation/spécialisation : principe
d’héritage entre CU
• l’inclusion («include») : la réalisation d’un CU
nécessite la réalisation d’un autre CU
• l’extension («extend») : le comportement d’un
CU peut être complété par un autre CU (avec
condition éventuelle)
 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).
• La relation include évite la description multiple du même
comportement.
 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.
 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.
Relation de généralisation
Relation cas d’utilisation-cas
d’utilisation - Exemple
 Relation entre éléments de base
(acteur, CU)
• Attention !
– Les communications internes (entre cas
d’utilisations) ne sont pas modélisées
– Les communications externes (entre acteurs) ne
sont pas modélisées.
Étude d’un guichet automatique de
banque (GAB)
Étape 1 - Identification des acteurs du
GAB
Étape 2 - Identification des cas
d’utilisation
Étape 3 - Réalisation de diagrammes
de cas d’utilisation
Acteurs secondaires
 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.
Étape 4 - Description textuelle des cas
d’utilisation
 Pré-Conditions
• 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
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.
• 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.
Scénarios alternatifs ou d’erreur
Scénarios alternatifs ou d’erreur
Scénarios alternatifs ou d’erreur
 Post conditions
• 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.
 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.
 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.
Références