Diagramme de Use Case

A quoi ça sert ?

La définition du périmètre d’un système informatique est toujours une tâche compliquée. Les différents acteurs d’un projet ont souvent une vision différentes des fonctionnalités attendues.

Le diagramme de use case est là pour répondre de façon schématique et concise aux interactions attendues entre le système et les acteurs de ce système. Ce diagramme donne une vision générale des fonctionnalités sans bien entendu entrer trop dans le détails sous peine de perdre en lisibilité. Ce type de diagramme est très utile pour dialoguer plus facilement entre les équipes techniques, les équipes commerciales, la MOA et la MOE.

Comment ça marche ?

Dans un diagramme de use case on trouve principalement les éléments suivants :

  • Acteurs
  • Use case (cas d’utilisation)
  • Relations

Les acteurs sont des éléments extérieurs à votre système qui interagissent avec lui. Ce peut-être soit des éléments humains (prospect, administrateur, client…) ou des machines. Le plus souvent ces acteurs sont représentés par un petit bonhomme.

Les Use case sont les fonctionnalités que le système représenté doit réaliser. Le plus compliqué est de savoir rester lisible et apprendre à décomposer ses use case.

Les relations sont les liens existants entre les différents éléments de nos diagrammes. Il peut y avoir des relations entres :

  • Acteurs -> Acteurs
  • Acteurs -> Use Case
  • Use Case -> Use Case

Un exemple

Prenons l’exemple très classique du distributeur de billet. On peut identifier les acteurs suivants :

  • Prospect (possède une CB mais n’est pas client de la banque)
  • Client
  • Transporteur de fond

Posons maintenant les use case suivants, ce n’est certes pas exhaustif mais c’est un début :

  • Retirer argent
  • Consulter solde
  • Recharger distributeur

En étudiant le système on se rend compte que le Client peut faire toutes les actions que le Prospect peut réaliser. Cela introduit une relation d’héritage entre Client et Prospect.

La question maintenant est qui peut faire quoi ?

  • Le prospect peut retirer de l’argent avec sa CB.
  • Le client peut retirer de l’argent avec sa CB mais comme il hérite des actions que peut faire le prospect on ne va pas représenter cette relation.
  • Le client peut consulter son solde.
  • Le transporteur de fond peut recharger la machine.

Au final on obtient ceci :

Diagramme use case d'un distributeur de billet

Et les relations entre use case dans tout ça ? et bien effectivement il n’y en a pas dans notre premier exemple. On pourrait rajouter un Use case “Vérifier code” qui serait exécuté lorsqu’un acteur souhaite retirer de l’argent ou consulter son solde. Dans ce cas ce nouveau Use case posséderait une relation de type “include”, ce qui signifie que pour compléter le Use case “Retirer argent” il faut exécuter le Use case “Vérifier code”.

Diagramme de use case avec relation include

Un exemple moins bon

Reprenons l’exemple précédent. J’ajoute les use case suivants :

  • Demander code
  • Vérifier Code
  • Demander montant
  • Vérifier solde
  • Délivrer billet

Ce sont en gros les étapes lors d’un retrait d’argent. A première vue elles pourraient tout à fait entrer dans notre diagramme de use case. Pourtant ce serait une erreur de les représenter car elles représentent le fonctionnement interne du système et non la vision qu’a l’acteur de l’interaction souhaitée. Afin de détailler le cheminement à effectuer pour compléter le use case “Retirer argent” un diagramme de séquence serait plus indiqué et surtout plus compréhensible.

L’importance du nommage des use case

Vous allez me dire que dans mon premier exemple j’ai ajouté un use case “Vérifier code”, or c’est un élément interne au système et non une interactions avec l’acteur externe. C’est tout à fait vrai j’ai très mal nommé ce use case, il aurait dû prendre l’action plus globale qui est de s’authentifier et au final se nommer : “Authentifier”

Leave a Reply