Chapitre 216 minIntermédiaire
Diagramme de cas d'utilisation : acteurs, include et extend
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- identifier les acteurs principaux et secondaires d'un système ;
- nommer des cas d'utilisation au bon niveau de détail ;
- choisir entre include et extend, et orienter la flèche ;
- construire le diagramme à partir d'un cahier des charges.
4 exercices corrigés1 schéma
Le diagramme de cas d'utilisation (use case diagram) montre ce qu'une application fait pour ses utilisateurs : les acteurs qui l'utilisent, à l'extérieur, et les cas d'utilisation, les services qu'elle leur rend, à l'intérieur d'un cadre qui délimite le système. C'est le premier diagramme d'un projet, celui qu'on montre au client pour valider le besoin. Ce chapitre détaille ses éléments, les relations «include» et «extend» qui font trébucher tant d'étudiants, et la méthode pour le construire à partir d'un cahier des charges.
Les éléments du diagramme
L'acteur
Un acteur est un rôle joué par quelqu'un ou quelque chose d'extérieur au système et qui interagit avec lui. Trois points à retenir :
- c'est un rôle, pas une personne : Inès, comptable, est l'acteur « Comptable » ; si elle est aussi visiteuse le week-end (improbable, mais possible), elle joue deux acteurs ;
- il est extérieur au système : on le dessine hors du cadre ;
- il peut être humain (un bonhomme, le stick man) ou non : un autre logiciel, un appareil, un service externe. Un acteur non humain se dessine souvent par un rectangle portant le stéréotype
«actor»ou«système».
On distingue l'acteur principal, qui déclenche le cas d'utilisation pour en obtenir un résultat (le visiteur qui saisit ses frais), et l'acteur secondaire, que le système sollicite pendant le cas (le service de paie à qui l'on transmet les virements). Le temps peut être un acteur : une tâche planifiée qui se déclenche chaque mois se modélise par un acteur « Horloge » ou « Planificateur ».
Le cas d'utilisation
Un cas d'utilisation est un service que le système rend à un acteur et qui produit un résultat observable et utile pour lui. Il se dessine par une ellipse et se nomme par un verbe à l'infinitif suivi d'un complément, du point de vue de l'acteur : « Saisir un frais hors forfait », « Valider une fiche de frais ».
Le bon niveau de détail est celui d'un objectif de l'utilisateur, atteint en une séance de travail. « Cliquer sur Valider » est trop fin (c'est une étape) ; « Gérer la comptabilité » est trop large (c'est un domaine). Pose-toi la question : l'acteur peut-il partir satisfait après ce cas, sans rien faire d'autre ? Si oui, c'est le bon grain.
La frontière du système
Un rectangle entoure les cas d'utilisation et porte le nom du système (« AppliFrais »). Tout ce qui est dedans est à construire ; tout ce qui est dehors existe déjà ou ne dépend pas de toi. Tracer cette frontière, c'est délimiter le périmètre du projet : un excellent sujet de discussion avec le client.
L'association entre acteur et cas
Un trait plein relie un acteur à chaque cas d'utilisation auquel il participe. On ne met en général pas de flèche ; certains auteurs en mettent une pour indiquer qui initie l'échange (de l'acteur principal vers le cas, du cas vers l'acteur secondaire). Les sujets d'examen utilisent les deux conventions : lis les flèches si elles sont là, ne les exige pas.
Les relations entre cas d'utilisation
L'inclusion : «include»
Le cas A inclut le cas B quand B est une partie obligatoire de A : chaque fois que A s'exécute, B s'exécute aussi. On trace une flèche pointillée de A vers B, avec le stéréotype «include».
On s'en sert surtout pour factoriser une partie commune à plusieurs cas. Dans AppliFrais, le comptable ne peut ni valider ni refuser sans avoir affiché le détail de la fiche : « Valider une fiche de frais » inclut « Consulter le détail d'une fiche ».
L'extension : «extend»
Le cas B étend le cas A quand B est un comportement optionnel qui vient s'ajouter à A, seulement dans certaines conditions. On trace une flèche pointillée de B (l'extension) vers A (le cas de base), avec le stéréotype «extend». A fonctionne très bien sans B.
Dans AppliFrais, pendant la validation, le comptable refuse parfois un frais hors forfait non conforme : « Refuser un frais hors forfait » étend « Valider une fiche de frais ». On peut préciser la condition dans une note ({condition : frais non conforme}) et le point d'extension, l'endroit du cas de base où l'extension peut se greffer, dans un compartiment de l'ellipse (points d'extension : contrôle des hors forfait).
La généralisation
Une flèche à triangle creux relie un élément spécialisé à un élément général.
- Entre acteurs : le Visiteur et le Comptable sont des Utilisateurs. Tout ce que fait un Utilisateur (s'authentifier, changer son mot de passe), le Visiteur et le Comptable le font aussi : on ne relie ces cas qu'à l'acteur parent, et le diagramme s'allège.
- Entre cas : « Payer » se spécialise en « Payer par carte » et « Payer par virement ». C'est plus rare.
Include ou extend : la distinction qui tombe
«include» | «extend» | |
|---|---|---|
| Sens | Partie obligatoire | Ajout optionnel, sous condition |
| La flèche part de | Du cas de base | Du cas d'extension |
| La flèche arrive sur | Le cas inclus | Le cas de base |
| Le cas de base fonctionne seul ? | Non, il a besoin du cas inclus | Oui |
| Question à te poser | « Faut-il toujours faire B pour faire A ? » | « Fait-on parfois B en plus de A ? » |
| Exemple | « Valider une fiche » «include» → « Consulter le détail d'une fiche » | « Refuser un frais hors forfait » «extend» → « Valider une fiche » |
Pour retenir le sens des flèches : la flèche part toujours de celui qui « connaît » l'autre. Le cas de base connaît ce qu'il inclut (il en a besoin) ; une extension connaît le cas qu'elle étend (elle sait où se greffer), alors que le cas de base ignore ses extensions.
Et « S'authentifier » ?
Faut-il écrire « Saisir un frais » «include» « S'authentifier » ? Beaucoup de sujets et de corrigés le font, et ce n'est pas faux : on ne peut pas saisir un frais sans être connecté. Mais l'authentification n'est pas une partie du service « saisir un frais » : c'est une précondition, valable une fois pour toute la session. La façon la plus propre est de faire de « S'authentifier » un cas à part, relié à l'acteur Utilisateur, et d'écrire « l'utilisateur est authentifié » dans les préconditions des autres cas. À l'examen, si le sujet utilise l'inclusion, suis sa convention.
Le diagramme d'AppliFrais
Voici le diagramme de cas d'utilisation d'AppliFrais, construit à partir du cahier des charges du chapitre 1.
Lis-le comme une liste de phrases :
- un utilisateur (visiteur ou comptable) peut s'authentifier ;
- un visiteur saisit ses frais forfaitisés et ses frais hors forfait, clôture sa fiche quand il a terminé, et consulte ses fiches ; quand il saisit un frais hors forfait, il peut joindre un justificatif ;
- un comptable valide une fiche, ce qui passe toujours par la consultation de son détail ; pendant la validation, il peut refuser un frais hors forfait ;
- un comptable met en paiement les fiches validées, ce qui sollicite le service de paie ;
- le planificateur clôture les fiches du mois écoulé que les visiteurs ont laissées ouvertes.
Trois choix de conception méritent une explication. « Consulter le détail d'une fiche » est séparé de « Consulter ses fiches de frais » : le premier est le point de vue du comptable sur n'importe quelle fiche, le second celui du visiteur sur les siennes. « Clôturer les fiches du mois » a pour acteur le planificateur, pas le comptable : le planificateur ne clôture que les fiches que le visiteur a laissées ouvertes. Et il n'y a pas de cas « Gérer les visiteurs » : la création des comptes n'est pas dans le cahier des charges, elle reste hors du périmètre.
Construire le diagramme à partir d'un cahier des charges
La méthode tient en cinq étapes.
- Trouver les acteurs. Relève qui interagit avec l'application : les rôles humains (souvent des noms de métier), puis les systèmes externes (banque, service de paie, messagerie, API). Vérifie pour chacun qu'il est bien hors du système.
- Trouver les cas d'utilisation. Pour chaque acteur, relève les verbes qui décrivent ce qu'il veut obtenir. Reformule-les en « verbe + complément » et vérifie le grain : un objectif, pas une étape.
- Relier. Trace une association entre chaque acteur et les cas auxquels il participe. Un cas sans acteur, ou un acteur sans cas, signale un oubli.
- Factoriser. Cherche les parties communes obligatoires (
«include»), les comportements optionnels («extend») et les acteurs qui partagent des cas (généralisation). N'en ajoute que si le diagramme y gagne en clarté. - Relire avec le client. Lis le diagramme à voix haute, en phrases. Chaque phrase doit correspondre à un besoin du cahier des charges, et chaque besoin à une phrase.
Les erreurs classiques
| Erreur | Pourquoi c'est faux | Correction |
|---|---|---|
| La base de données comme acteur | Elle fait partie du système | La retirer, ou nommer le vrai système externe |
| Un acteur dans le cadre | Un acteur est extérieur par définition | Le sortir du cadre |
| « Cliquer sur Valider » | C'est une étape, pas un objectif | « Valider une fiche de frais » |
Des «include» en chaîne pour montrer un ordre | Le diagramme ne montre pas l'ordre | Décrire l'ordre dans la description textuelle |
La flèche «extend» du cas de base vers l'extension | Le sens est inversé | De l'extension vers le cas de base |
| Un trait entre deux acteurs | Les acteurs ne communiquent pas via le diagramme | Une généralisation (triangle) si l'un est un cas particulier de l'autre, sinon rien |
| Nommer l'acteur « Inès » | Un acteur est un rôle | « Comptable » |
Exercices
Exercice 1 sur 4 Include, extend ou rien ? Réussi À revoir
Pour chaque paire, indique la relation et le sens de la flèche.
- Sur un site de réservation, « Réserver une chambre » et « Payer la réservation » (le paiement est exigé à la réservation).
- Sur le même site, « Réserver une chambre » et « Ajouter un petit-déjeuner ».
- Dans une médiathèque, « Emprunter un document » et « Vérifier l'abonnement de l'adhérent » ; « Prolonger un emprunt » et « Vérifier l'abonnement de l'adhérent ».
- Dans AppliFrais, « Saisir un frais hors forfait » et « Saisir le montant du frais ».
- Sur un site marchand, « Passer une commande » et « Utiliser un code promo ».
Voir la réponseMasquer la réponse de l'exercice 1
«include», de « Réserver une chambre » vers « Payer la réservation » : le paiement fait toujours partie de la réservation.«extend», de « Ajouter un petit-déjeuner » vers « Réserver une chambre » : c'est une option.- Deux
«include», chacun vers « Vérifier l'abonnement de l'adhérent ». C'est l'usage typique de l'inclusion : factoriser une partie commune et obligatoire. - Rien : saisir le montant est une étape du cas, pas un service. Elle apparaît dans le scénario de la description textuelle.
«extend», de « Utiliser un code promo » vers « Passer une commande », avec la condition « le client possède un code ».
Tu avais trouvé ?
Exercice 2 sur 4 Repérer les acteurs Réussi À revoir
Une salle de sport veut une application : « Les adhérents réservent une place dans un cours collectif et peuvent l'annuler jusqu'à deux heures avant. Les coachs consultent la liste des inscrits à leurs cours. L'accueil enregistre les nouveaux adhérents et encaisse les abonnements par carte, via le terminal de paiement de la banque. Chaque nuit, l'application envoie un SMS de rappel aux adhérents inscrits à un cours le lendemain, par l'intermédiaire d'un fournisseur de SMS. »
Liste les acteurs, en précisant s'ils sont humains ou non, principaux ou secondaires.
Voir la réponseMasquer la réponse de l'exercice 2
- Adhérent : humain, principal (réserver, annuler).
- Coach : humain, principal (consulter les inscrits).
- Agent d'accueil : humain, principal (enregistrer un adhérent, encaisser un abonnement).
- Banque (ou « Système de paiement ») : non humain, secondaire, sollicité pendant l'encaissement.
- Planificateur (ou « Horloge ») : non humain, principal du cas « Envoyer les rappels de la veille », qu'il déclenche chaque nuit.
- Fournisseur de SMS : non humain, secondaire, sollicité pour envoyer les messages.
Les adhérents qui reçoivent un SMS ne sont pas acteurs de ce cas : ils ne déclenchent rien et n'interagissent pas avec l'application à ce moment-là. L'application elle-même et sa base de données ne sont pas des acteurs.
Tu avais trouvé ?
Exercice 3 sur 4 Corriger un diagramme Réussi À revoir
Un étudiant a dessiné, pour la salle de sport : un acteur « Base de données » relié à tous les cas ; un cas « Se connecter » relié à « Réserver un cours » par une flèche «include» partant de « Se connecter » ; un cas « Annuler une réservation » relié à « Réserver un cours » par une flèche «extend» partant de « Réserver un cours » ; un cas « Cliquer sur Réserver » inclus dans « Réserver un cours ». Corrige chaque point.
Voir la réponseMasquer la réponse de l'exercice 3
- L'acteur « Base de données » doit disparaître : la base fait partie du système.
- L'
«include»est à l'envers : s'il est gardé, il part de « Réserver un cours » vers « Se connecter ». Mieux : « S'authentifier » devient un cas à part, relié aux acteurs, et l'authentification devient une précondition des autres cas. - « Annuler une réservation » n'est pas une extension de « Réserver un cours » : c'est un autre objectif, réalisé plus tard, dans une autre séance. C'est un cas indépendant, relié à l'adhérent.
- « Cliquer sur Réserver » est une étape d'interface : à supprimer du diagramme, elle trouve sa place dans le scénario nominal de la description textuelle.
Tu avais trouvé ?
Exercice 4 sur 4 Dessiner un diagramme complet Réussi À revoir
Une ludothèque prête des jeux de société et veut une application : « Un adhérent crée son compte, puis réserve un jeu pour une date de retrait ; si sa cotisation annuelle n'est pas à jour, la réservation exige qu'il la paie, en ligne, par l'intermédiaire de la plateforme de paiement. Au moment de réserver, il peut demander la livraison du jeu à domicile. Il peut annuler une réservation. Au retour d'un jeu, un bénévole enregistre le retour ; s'il manque des pièces, il déclare le jeu incomplet, et la commande des pièces manquantes est transmise à l'éditeur du jeu. Le responsable de la ludothèque consulte les statistiques de prêt. Adhérents, bénévoles et responsable se connectent avec un identifiant. »
Donne les acteurs, les cas d'utilisation et les relations, sous forme de liste.
Voir la réponseMasquer la réponse de l'exercice 4
Acteurs : Utilisateur (parent), avec trois acteurs spécialisés qui en héritent : Adhérent, Bénévole, Responsable ; Plateforme de paiement (non humain, secondaire) ; Éditeur (non humain, secondaire).
Cas et associations :
- Utilisateur — « S'authentifier » ;
- Adhérent — « Créer son compte », « Réserver un jeu », « Annuler une réservation » ;
- Bénévole — « Enregistrer le retour d'un jeu » ;
- Responsable — « Consulter les statistiques de prêt » ;
- Plateforme de paiement — « Payer la cotisation » ;
- Éditeur — « Déclarer un jeu incomplet ».
Relations entre cas :
- « Payer la cotisation »
«extend»→ « Réserver un jeu », condition : cotisation pas à jour ; - « Demander la livraison à domicile »
«extend»→ « Réserver un jeu » (option) ; - « Déclarer un jeu incomplet »
«extend»→ « Enregistrer le retour d'un jeu », condition : pièces manquantes.
Le piège est le paiement : il n'a lieu que si la cotisation n'est pas à jour, donc ce n'est pas un «include» (qui voudrait dire « à chaque réservation »), mais une extension sous condition. Si le texte disait « chaque réservation se paie », ce serait une inclusion. « Créer son compte » est relié à l'Adhérent et non à l'Utilisateur : un bénévole ne crée pas son compte lui-même.
Tu avais trouvé ?