Diagrammes de cas d'utilisation UML

Un diagramme de cas d'utilisation est une carte du périmètre. Il nomme les personnes et les systèmes qui interagissent avec ce que vous construisez, les objectifs avec lesquels ils viennent, et la ligne entre le dedans et le dehors. C'est tout ce qu'il fait, et sa retenue est précisément l'intérêt.

Il ne dit rien de l'ordre. Rien des écrans, des champs ou des algorithmes. Rien de la façon dont quoi que ce soit fonctionne. Chacun de ces sujets est un autre diagramme, et la tentation de les faire passer en fraude sur celui-ci produit ces diagrammes de cas d'utilisation tentaculaires et inutiles qui ont donné mauvaise réputation à la notation.

Personne ne vous tend la liste. Le diagramme ci-dessus paraît évident une fois tracé et ne l'était pas du tout avant ; l'écart entre la page blanche et cette image, ce sont quatre questions posables dans une salle en vingt minutes.

1. Qui déclenche quelque chose ici ? Chacun est un acteur principal candidat. Demandez le rôle plutôt que le nom - la personne qui a dit « c'est moi qui fais ça » est un titulaire d'un rôle qui lui survivra.
2. Qui ou quoi reçoit quelque chose sans le demander ? Rapports, fichiers, notifications, traitements de règlement. Ce sont les acteurs secondaires à droite de la frontière, et c'est la moitié du diagramme que la plupart des premiers jets oublient.
3. Qu'est-ce qui doit être là pour que cela fonctionne ? Prestataires de paiement, services d'identité, le mainframe, un moteur antifraude. Tout ce pour quoi vous ouvririez un ticket à une autre équipe est hors frontière et a sa place sur le diagramme - le dessiner est souvent le moment où quelqu'un réalise que la dépendance n'a jamais été convenue.
4. Qu'est-ce qui arrive parce que le temps a passé ? Un rapprochement nocturne, une expiration à quatorze jours, une facturation mensuelle. Le temps est un acteur, dessiné en bonhomme bâton étiqueté Clock ou Scheduler, et les processus qui l'omettent finissent avec des cas d'utilisation que personne ne semble déclencher.

Nommez ensuite chaque objectif du côté du comptoir où se tient l'acteur, verbe d'abord, dans son vocabulaire : Submit payment, pas Payment submission handling et surtout pas PaymentController. Si le nom n'a de sens que pour qui a vu le code, c'est une étape dans un cas d'utilisation plutôt qu'un cas d'utilisation.

Ces deux-là sont la raison pour laquelle les diagrammes de cas d'utilisation sont mal tracés. Les deux sont des flèches pointillées avec un mot-clé, et elles pointent dans des directions opposées.

«include» pointe du cas de base vers ce qu'il fait toujours. Lisez « appelle ». Dans le diagramme ci-dessus, Submit payment inclut Authorize payment : on ne peut pas soumettre sans autoriser. Cela sert à factoriser un comportement partagé par plusieurs cas - et c'est exactement pourquoi Refund payment l'inclut aussi.

«extend» pointe de l'ajout optionnel vers le cas de base. Lisez « peut interrompre ». Log audit trail étend Refund payment : les remboursements fonctionnent sans, et cela arrive sous une certaine condition. Le cas de base ignore l'existence de ses extensions.

Le diagramme est la table des matières. Ce à partir de quoi on construit vraiment, c'est la description de cas d'utilisation derrière chaque ellipse - et un projet qui trace le diagramme sans jamais écrire les descriptions a produit une image du travail plutôt qu'une spécification. C'est la partie dont la notation ne dit rien, d'où le nombre d'équipes qui s'arrêtent à l'image.

Il y a trois profondeurs utiles, et le choix relève du projet et non de la modélisation. Une description brève, ce sont deux phrases dans le backlog. Une informelle, un paragraphe par scénario. Une entièrement rédigée comporte les champs ci-dessous et vaut l'effort pour la poignée de cas qui portent de l'argent ou du risque réels.

• Nom. L'étiquette de l'ellipse, verbe d'abord : Authorize payment.
• Acteur principal. Celui qui veut le résultat. Merchant.
• Parties prenantes et intérêts. Qui d'autre est concerné et ce qu'il en attend. L'acquéreur veut un code d'autorisation valide ; l'équipe antifraude veut la tentative enregistrée, qu'elle réussisse ou non. C'est dans ce champ qu'apparaissent la plupart des exigences oubliées.
• Préconditions. Ce qui est déjà vrai avant le début - le marchand est authentifié, la commande existe. Pas une liste d'étapes, une liste de garanties.
• Scénario nominal. Le chemin heureux numéroté, étape acteur puis étape système, dans la langue du métier. Entre cinq et douze étapes ; au-delà, le cas d'utilisation en est deux.
• Extensions. Numérotées d'après l'étape dont elles dérivent - 4a, 4b, 7a - chacune avec sa condition et ce qui se passe. C'est ce champ qui justifie le format, car c'est une invite systématique à envisager chaque façon d'échouer.
• Postconditions. Ce qui est vrai ensuite, en succès et pour chaque échec. « Une autorisation est enregistrée et les fonds sont bloqués » se teste ; « le paiement est traité » non.

En petit, pour Authorize payment : le scénario nominal est (1) le marchand soumet le paiement, (2) le système valide le total de la commande, (3) le système demande l'autorisation à l'acquéreur, (4) l'acquéreur renvoie une approbation, (5) le système enregistre le blocage et confirme. Le travail est dans les extensions - 3a l'acquéreur ne répond pas, 4a l'acquéreur refuse, 4b l'acquéreur demande une authentification renforcée - et chacune est une conversation qu'on aurait sinon eue six semaines plus tard en triage de défauts.

Un diagramme de cas d'utilisation utile tient sur une page et compte entre trois et dix ellipses. C'est une table des matières, pas le livre. Le détail appartient aux descriptions - le flux principal numéroté et ses alternatives - ou, si le flux est assez ramifié pour mériter un dessin, à un diagramme d'activité par cas.

1. Décomposition fonctionnelle. Vingt ellipses nommées d'après des boutons. Les cas d'utilisation sont des objectifs ; si ce n'est pas quelque chose qu'un acteur veut, cela n'a rien à faire là.
2. Des acteurs nommés d'après des personnes ou des intitulés de poste. Modélisez le rôle. Une personne peut être plusieurs acteurs, et un acteur peut être un traitement par lots.
3. Flèches «include» et «extend» inversées. Elles pointent en sens opposés. Appliquez le test du retrait ci-dessus.
4. Des acteurs à l'intérieur de la frontière. La frontière est ce que vous construisez. Un acteur est par définition à l'extérieur.
5. Un ordre suggéré par la position verticale. Un diagramme de cas d'utilisation n'a pas d'axe temporel. Rien dans la mise en page ne dit ce qui vient d'abord.