Le diagramme de cas d’utilisation

Un diagramme de cas d’utilisation sert à recueillir, analyser et organiser les besoins, en listant les grandes fonctionnalités vues par un utilisateur externe. C’est souvent la première étape d’analyse UML pour cadrer le système.

Il capture le comportement d’un système (ou sous-système) tel que perçu de l’extérieur et scinde la fonctionnalité en cas d’utilisation cohérents ayant du sens pour les acteurs.

Éléments du diagramme

Acteur

Un acteur est un rôle (personne, processus, dispositif) qui interagit avec le système.

Il se représente par un petit bonhomme (stickman) avec son nom (figure 1).

Figure 1 — Exemple de représentation d’un acteur

Figure 1 — Exemple de représentation d’un acteur

Il est également possible de représenter un acteur sous la forme d’un classeur stéréotypé «actor» (figure 2).
Figure 2 — Exemple de représentation d’un acteur sous la forme d’un classeur

Figure 2 — Exemple de représentation d’un acteur sous la forme d’un classeur

Cas d’utilisation

Un use case est une fonctionnalité observable de bout en bout (déclenchement → déroulement → fin) qui rend un service à l’acteur initiateur. Il se représente par une ellipse contenant le nom du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype (figure 3).

Figure 3 — Exemple de représentation d’un cas d’utilisation (ellipse)

Figure 3 — Exemple de représentation d’un cas d’utilisation (ellipse)

Il est également possible de le représenter sous la forme d’un classeur stéréotypé «use case» (figure 4), dans le cas où l’on désire présenter les attributs ou les opérations du cas d’utilisation.

Nous reviendrons sur les notions d’attributs ou d’opération lorsque nous aborderons les diagrammes de classes et d’objets.

Figure 4 — Exemple de représentation d’un cas d’utilisation sous la forme d’un classeur

Figure 4 — Exemple de représentation d’un cas d’utilisation sous la forme d’un classeur

Frontière du système

Le cadre du diagramme porte le nom du système ; acteurs à l’extérieur, cas d’utilisation à l’intérieur.

Figure 5 — Exemple simplifié de diagramme de cas d’utilisation modélisant une borne d’accès à une banque

Figure 5 — Exemple simplifié de diagramme de cas d’utilisation modélisant une borne d’accès à une banque

Les relations

Association (acteur ↔ cas)

Le chemin de communication entre un acteur et un cas : trait continu.

Acteur principal / secondaire

Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à cet acteur; il reçoit un résultat observable. Un cas d’utilisation a au plus un acteur principal. L’acteur secondaire quant à lui, est sollicité pour des informations complémentaires.

  • Le stéréotype «primary» représente l’association reliant un cas d’utilisation à son acteur principal,
  • Le stéréotype «secondary» est utilisé pour les acteurs secondaires (figure 6).
Figure 6 — Exemple de diagramme de cas d’utilisation représentant un logiciel de partage de fichiers

Figure 6 — Exemple de diagramme de cas d’utilisation représentant un logiciel de partage de fichiers

Les cas d’utilisation interne

Il s’agit des cas non relié directement à un acteur.

  • include : A inclut B si le comportement de A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. (figure.7). Utile pour factoriser un sous-comportement commun (figure.7), ou décomposer un cas complexe en sous-cas plus simples (figure 8).
  • extend : A étend B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B (figure 7). Exécuter B peut éventuellement entraîner l’exécution de A, contrairement à l’inclusion, l’extension est optionnellement.

Un diagramme de cas d’utilisation n’a pas de temporalité : on n’enchaîne pas des cas, on exprime des capacités.

Figure 7 — Exemple de diagramme de cas d’utilisation avec les différentes relations interne

Figure 7 — Exemple de diagramme de cas d’utilisation avec les différentes relations interne

Figure 8 — Exemple de diagramme de cas d’utilisation avec décomposition d’un cas complexe

Figure 8 — Exemple de diagramme de cas d’utilisation avec décomposition d’un cas complexe

Identifier les acteurs

  • Lister les rôles des utilisateurs (ex. responsable, admin…) et les systèmes externes / périphériques qui interagissent directement avec le système.
  • Se représenter la frontière : dehors = acteurs, dedans = fonctionnalités.
  • Éviter les faux acteurs (pas d’interaction directe).

Ne pas confondre acteur et utilisateur : un acteur peut être un humain, un système ou un dispositif ; une même personne peut jouer plusieurs rôles.

Recenser les cas d’utilisation

L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences fonctionnelles du système.

  • Chaque cas = fonction métier du point de vue d’un acteur ; se demander pourquoi l’acteur utilise le système.
  • Nommer avec un verbe à l’infinitif + complément en vous plaçant du point de vue de l’acteur et non pas de celui du système(Ex.: “retirer de l’argent”, pas “distribuer de l’argent”).
  • Limiter le nombre, éviter la décomposition fonctionnelle trop fine en se situant à un bon niveau d’abstraction.

La description textuelle d’un cas

Le diagramme ne suffit pas : rédiger une fiche (souple, testable). Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation. Gabarit recommandé :

ChampContenu
Id / VersionUC-XX / v0.1
Nom<verbe à l’infinitif> (Ex.: se connecter au système)
ObjectifIntention principale du cas (résumé en 1–2 phrases).
Acteur principalRôle qui initie le cas et reçoit un résultat observable.
Acteurs secondairesRôles informés/assistants (optionnel).
PréconditionsÉtat requis du système avant le déclenchement.
Scénario nominal1) … 2) … 3) … (échanges acteur ↔ système, 5–9 étapes max).
Scénarios alternatifsA1) … ; A2) … (variantes métier)
Scénarios d’exceptionE1) … ; E2) … (erreurs / validations)
PostconditionsÉtat du système après exécution (effets observables à l’issue des différents scénarios).