Exemples de diagrammes de cas d'utilisation

La bibliothèque est le premier exemple standard pour une bonne raison : tout le monde connaît déjà le domaine, il ne reste donc que la notation à regarder. Deux acteurs, cinq cas d'utilisation, et une frontière qui dit desquels le logiciel est responsable.

Remarquez ce que sont les ellipses. Emprunter un livre est un objectif - un adhérent veut repartir avec un livre - et cela reste un objectif que le comptoir soit une personne, une borne en libre-service ou une application. Cette indépendance vis-à-vis du mécanisme est le test du cas d'utilisation : si remplacer l'interface changeait l'étiquette, l'étiquette est une étape.

Deux relations font un vrai travail. Vérifier l'adhésion est incluse par Emprunter un livre, c'est-à-dire qu'elle a toujours lieu dans le cadre de celui-ci, et la flèche va de l'emprunt vers le comportement inclus. Elle n'a pas d'acteur propre, et c'est correct : personne n'arrive à la bibliothèque en voulant qu'on vérifie son adhésion. Payer une amende de retard étend Rendre un livre : cela n'arrive que parfois, et la flèche va dans l'autre sens, du comportement optionnel vers la base.

Le second exemple ajoute la pièce que la plupart des premiers diagrammes oublient : un système dont vous dépendez et que vous ne contrôlez pas.

La Payment gateway est un acteur secondaire. Elle n'initie rien - sur ce diagramme, tout part du client - mais le système l'appelle, donc elle a sa place hors de la frontière, avec un trait vers le cas d'utilisation qui en a besoin. La dessiner est ce qui fait gagner sa place à un diagramme de cas d'utilisation dans une conversation de périmètre : la frontière montre désormais exactement quel comportement vous assumez et lequel vous achetez.

Appliquer un code de réduction étend Passer commande parce que la plupart des commandes n'en ont pas. Si presque toutes en avaient un, ce serait un include à la place. La question n'est pas de savoir si le comportement est important, mais s'il a toujours lieu.

Quatre ellipses est une taille raisonnable. Une vraie boutique a des centaines de comportements, et le diagramme ne grossit pas d'autant : vous en dessinez un par conversation, cadré sur la question posée, et c'est la discipline dont parle cadrer un modèle.

La plupart des mauvais diagrammes de cas d'utilisation le sont d'exactement une façon, et cela vaut la peine de la voir une fois.

Quatre ellipses, un acteur, une frontière, aucune erreur de notation - et le diagramme ne vaut rien. Chaque étiquette est une étape d'interface plutôt qu'un objectif qu'une personne poursuit. Personne ne veut saisir un identifiant ; on veut se connecter, et même cela n'est en général qu'au service d'autre chose.

Tout le diagramme se réduit à un seul cas d'utilisation, et les quatre étapes ont leur place dans sa description textuelle ou, si le branchement compte vraiment, dans un diagramme d'activité. C'est la réparation standard : la séquence part vers l'activité, les objectifs restent ici.

Les deux bons diagrammes ci-dessus sont le même diagramme avec d'autres noms, et c'est ce qu'il y a d'utile dans cette notation : une fois la forme en main, le suivant prend dix minutes.