Exemple de diagramme de cas d'utilisation : acteurs, cas d'utilisation, include et extend

Un diagramme de cas d'utilisation répond à une question sur une seule page : qui utilise ce système, et pour quoi faire ? Les product managers s'en servent pour s'accorder sur le périmètre, les ingénieurs pour voir chaque point d'entrée d'un système, et les testeurs pour vérifier que chaque objectif a un chemin. C'est aussi l'un des diagrammes UML les plus souvent mal dessinés : on en fait un logigramme, on dessine chaque bouton comme un cas d'utilisation, ou on utilise include et extend à l'envers.

Cet article explique la notation telle que la définit la spécification UML 2.5.1, tranche entre include et extend avec un test simple, déroule un exemple complet pour une application de commande de repas, montre le texte qui doit se trouver derrière chaque ovale et liste les erreurs qui rendent les diagrammes de cas d'utilisation inutiles.

La notation

Le sens des flèches vient directement de la spécification UML 2.5.1, publiée par l'OMG en décembre 2017 : include va du cas de base vers le cas inclus ; extend va du cas qui étend vers le cas qu'il étend. La spécification autorise aussi des points d'extension, des emplacements nommés dans le cas de base où une extension peut se brancher, listés dans l'ovale.

Include ou extend : un seul test

Demandez-vous si le cas de base est complet sans l'autre.

• Incomplet sans lui : include. Passer une commande implique toujours un paiement. « Place order » inclut « Pay for order ». La flèche pointe vers ce qui est inclus, et le cas de base ne peut pas s'exécuter sans lui.
• Complet sans lui : extend. Appliquer un code promo est facultatif ; une commande est parfaitement valide sans code. « Apply promo code » étend « Place order », à un point d'extension comme « avant le paiement », quand le client a un code. La flèche pointe vers le cas de base, qui ne sait même pas que l'extension existe.

Deux autres règles évitent la plupart des abus :

• Utilisez include pour partager un comportement dont plusieurs cas d'utilisation ont besoin, comme l'authentification ou le paiement. Ne l'utilisez pas pour découper un cas d'utilisation en étapes ; c'est un logigramme.
• Utilisez extend avec parcimonie. Si vous avez plus d'extends que de cas de base, vous documentez des options d'interface, pas des objectifs.

Les acteurs sont des rôles

Un acteur est un rôle, pas une personne ni un intitulé de poste. La même personne peut être cliente le matin et gérante de restaurant l'après-midi. Les acteurs peuvent aussi être des systèmes : un prestataire de paiement que l'application appelle pour autoriser une carte est un acteur de soutien. Certaines équipes modélisent les tâches planifiées avec un acteur « Time », une convention courante pour les cas d'utilisation que personne ne lance à la main.

Par convention, les acteurs principaux, qui lancent des cas d'utilisation pour atteindre leurs objectifs, se placent à gauche, et les acteurs de soutien, que le système sollicite, à droite.

Nommer les cas d'utilisation au bon niveau

Nommez les cas d'utilisation par un verbe et un complément, du point de vue de l'acteur : « Passer commande », et non « Commande », « Écran de commande » ou « Bouton Valider ». Chacun doit être un objectif que l'acteur peut atteindre en une seule séance et qu'il serait content d'avoir atteint, ce qu'Alistair Cockburn appelle le niveau de la mer des objectifs utilisateur. Les niveaux plus hauts (« Gérer le restaurant ») sont trop larges pour un ovale ; les niveaux plus bas (« Saisir le numéro de carte ») sont des étapes à l'intérieur d'un cas d'utilisation.

Un exemple complet : la commande de repas

Le diagramme ci-dessous montre une application de commande de repas avec quatre acteurs :

• Customer parcourt le menu, passe des commandes et suit les livraisons.
• Restaurant staff accepte les commandes.
• Courier livre les commandes.
• Payment provider, un système externe, soutient le paiement.

Et sept cas d'utilisation dans la frontière :

1. Browse menu
2. Place order, qui inclut Pay for order
3. Pay for order, que soutient le prestataire de paiement
4. Apply promo code, qui étend Place order avant le paiement
5. Track delivery
6. Accept order
7. Deliver order

Remarquez ce qui ne figure pas sur le diagramme : pas d'ordre des étapes, pas d'écrans, pas d'ovale « Log in » pour chaque acteur. L'authentification est une précondition, pas un objectif ; elle a sa place dans les descriptions, ou dans un unique cas d'utilisation inclus si elle porte un vrai comportement.

La description derrière chaque ovale

Le diagramme est un index. La valeur se trouve dans une courte description par cas d'utilisation, par exemple :

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

Les extensions de la description, ces branches « et si » numérotées, sont la source des exigences et des cas de test. Elles sont bien plus détaillées que les relations extend du diagramme, qui ne doit montrer que les objectifs optionnels méritant une image.

Erreurs courantes

• Un logigramme déguisé. Des flèches entre cas d'utilisation qui signifient « ensuite » transforment le diagramme en modèle de processus. Pour l'ordre du travail, utilisez un diagramme BPMN ou un diagramme d'activité.
• Un cas d'utilisation par opération CRUD. « Créer un plat », « Modifier un plat » et « Supprimer un plat » forment en général un seul objectif : « Gérer le menu ».
• Des écrans et des boutons comme cas d'utilisation. « Cliquer sur Payer » est une étape, pas un objectif.
• Include pour décomposer. Si chaque cas d'utilisation en inclut trois autres, le diagramme décrit la structure du code, pas les objectifs des utilisateurs.
• Des composants internes comme acteurs. La base de données n'est pas un acteur ; elle est dans le système. Les systèmes externes que vous appelez, si.
• Pas de frontière. Sans le rectangle du sujet, les lecteurs ne peuvent pas distinguer ce que vous construisez de ce dont vous dépendez.

Diagrammes de cas d'utilisation, user stories et diagrammes de séquence

Ils fonctionnent ensemble : le diagramme de cas d'utilisation cartographie le territoire, les stories le découpent en morceaux livrables, et un diagramme de séquence montre comment un scénario se déroule réellement.

Le diagramme de cas d'utilisation

Comment le lire :

• Le rectangle est la frontière du système : tout ce qui est à l'intérieur est l'application de commande de repas.
• Les acteurs de gauche lancent les cas d'utilisation : le client a trois objectifs, le personnel du restaurant et les livreurs un chacun.
• Le prestataire de paiement à droite est un système de soutien que l'application appelle pendant le paiement.
• La flèche «include» de Place order vers Pay for order signifie que le paiement a toujours lieu. La flèche «extend» d'Apply promo code vers Place order signifie que le code promo est facultatif.
• Le bloc Markdown est une légende de notation pour les lecteurs qui découvrent UML.

Dessiner des diagrammes de cas d'utilisation que l'on lit vraiment

• Restez sous environ 15 cas d'utilisation par diagramme. Si un système en a davantage, découpez par acteur ou par sous-système.
• Placez les acteurs principaux à gauche et les acteurs de soutien à droite, pour que le sens de lecture corresponde à qui lance quoi.
• Étiquetez explicitement include et extend, avec les guillemets, et gardez les flèches en pointillé.
• Laissez les détails aux descriptions. Le diagramme doit tenir sur une diapositive ; le texte peut être aussi long que nécessaire.

Les diagrammes de cas d'utilisation se combinent bien avec les autres vues UML : l'exemple de diagramme de classes UML pour le modèle du domaine et l'exemple de diagramme d'états pour le cycle de vie d'une commande.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un Cadre du pack Base nommé Food ordering app comme frontière du système.
3. Ajoutez dans le cadre sept nœuds Cas d'utilisation du pack UML, nommés comme ci-dessus.
4. Ajoutez quatre nœuds Acteur du pack UML : Customer, Restaurant staff et Courier à gauche, Payment provider à droite.
5. Reliez les acteurs à leurs cas d'utilisation par des traits simples. Ajoutez des arêtes pointillées étiquetées «include» de Place order vers Pay for order et «extend» d'Apply promo code vers Place order.
6. Ajoutez un bloc Markdown du pack Base avec une courte légende de notation.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre include et extend dans un diagramme de cas d'utilisation ? Include signifie que le cas de base exécute toujours le comportement inclus, et la flèche pointe vers le cas inclus. Extend désigne un comportement optionnel ajouté sous condition, et la flèche va de l'extension vers le cas de base.

Un acteur peut-il être un système ? Oui. Tout rôle externe qui interagit avec le système peut être un acteur, y compris un autre logiciel comme un prestataire de paiement. Les composants internes à votre système ne sont pas des acteurs.

Faut-il des flèches entre les acteurs et les cas d'utilisation ? UML utilise de simples traits d'association entre acteurs et cas d'utilisation. Certaines équipes ajoutent des pointes de flèche pour montrer qui initie, mais la notation standard ne l'exige pas.

Combien de cas d'utilisation un diagramme doit-il contenir ? À titre indicatif, pas plus de 15 environ. Les systèmes plus grands se lisent mieux en plusieurs diagrammes, découpés par acteur ou par sous-système.

Les diagrammes de cas d'utilisation montrent-ils l'ordre des étapes ? Non. Ils montrent des objectifs, pas des séquences. L'ordre des étapes relève des descriptions de cas d'utilisation, des diagrammes d'activité ou des diagrammes de séquence.

Commencez gratuitement — un siège, sans carte bancaire.