10 astuces pour créer un diagramme de cas d’utilisation professionnel

Qu’est-ce que la modélisation des cas d’utilisation ?

La modélisation des cas d’utilisation est une réponse simple à la question « Qu’est-ce que l’utilisateur (client) veut ? ». Elle vous permet de représenter visuellement ce que l’utilisateur souhaite accomplir en utilisant le produit final, qui peut être un système, un logiciel, un programme, etc. La modélisation des cas d’utilisation est une technique utile qui fournit aux développeurs logiciels une base solide pour concevoir des systèmes logiciels qui répondent aux besoins des clients.

Bien que la notation utilisée dans les diagrammes de cas d’utilisation puisse sembler simple et ne transmettre que peu de détails, la manière dont les cas d’utilisation sont recueillis, organisés et développés influence grandement la direction du cycle de vie du développement logiciel, et donc la qualité du produit logiciel final.

10 astuces pratiques pour la modélisation des cas d’utilisation

Dans cet article, nous passerons en revue dix astuces pour maximiser l’efficacité de la création de diagrammes de cas d’utilisation. Nous ne détaillerons pas ce qu’est un cas d’utilisation, mais couvrirons certains concepts clés sur la modélisation UML, les diagrammes de cas d’utilisation et la capture des exigences.

1. Pensez depuis la perspective de l’utilisateur final

Il est clair que vous devez connaître les attentes des utilisateurs afin de construire un système logiciel fonctionnel, et ce principe est particulièrement important dans la modélisation des cas d’utilisation. Beaucoup de personnes considèrent à tort la modélisation des cas d’utilisation comme un processus de modélisation des fonctions du système, ce qui peut être erroné. Pour être précis, la modélisation des cas d’utilisation est une manière de modéliser ce que les utilisateurs veulent. Chaque cas d’utilisation dans un diagramme de cas d’utilisation doit aboutir à un objectif observable grâce à l’interaction de l’utilisateur avec le logiciel ou le système final. Parfois, un objectif utilisateur est identique à une fonction du système, mais ce n’est pas toujours le cas. Par exemple, « Connexion » est une fonction du système, mais ce n’est certainement pas un objectif utilisateur – Personne ne lance un programme, se connecte et s’en va ! Ainsi, plus vous dessinez de fonctions du système dans un diagramme de cas d’utilisation, moins le modèle de cas d’utilisation sera efficace pour exprimer les véritables attentes des utilisateurs tout au long du processus de développement logiciel. Par conséquent, lorsque vous développez un modèle de cas d’utilisation, essayez de tout exprimer en commençant par penser depuis la perspective de l’utilisateur final.

2. Évitez les noms de cas d’utilisation trop longs

Si vous lisez un diagramme de cas d’utilisation préparé pour un système de guichet automatique, quel cas d’utilisation souhaitez-vous voir dans le diagramme ? « Retirer de l’argent » ou « Retirer de l’argent et mettre à jour le solde du compte ». Le deuxième cas d’utilisation semble plus descriptif, n’est-ce pas ? Et si vous aviez 50 cas d’utilisation ou plus avec un nom aussi long ? Vous ne voudrez probablement plus lire le diagramme, et peut-être que vos yeux seront fatigués.

L’une des raisons pour lesquelles nous avons besoin de modélisation est que nous voulons comprendre un système logiciel complexe de manière simple et facile. C’est pourquoi UML nous a fourni de nombreuses notations différentes, chacune représentant une perspective spécifique dans la description d’un système logiciel complet. Ce « esprit » s’applique également à la nomination des cas d’utilisation. Si nous essayons de nommer les cas d’utilisation avec une description détaillée, pourquoi ne pas simplement utiliser un fichier texte ? Pour rendre un diagramme de cas d’utilisation facile à comprendre, il est important de garder les noms des cas d’utilisation courts, tout en restant descriptifs. Gardez les noms courts et laissez la description détaillée dans la partie description des cas d’utilisation.

3. Un acteur est un rôle, pas une personne réelle

Certaines personnes tentent de représenter les employés au sein d’une organisation comme des acteurs dans un diagramme de cas d’utilisation, ce qui aboutit à un diagramme comportant Peter, Mary, Daisy, etc. Souvenez-vous, un acteur représente un rôle unique composé de personnes, de sous-systèmes ou d’autres entités ayant des caractéristiques uniques et partageant les mêmes objectifs et attentes.

4. Modéliser un cas d’utilisation commun avec une relation

Un cas d’utilisation représente un objectif utilisateur, qui peut être atteint en passant par une série d’étapes. Lorsque les mêmes étapes apparaissent dans plusieurs cas d’utilisation, vous pouvez éventuellement créer un nouveau cas d’utilisation pour les étapes communes et le relier aux cas d’utilisation qui déclenchent ces étapes. En utilisant un cas d’utilisation inclus, cela rend clair que les cas d’utilisation qui l’incluent partagent effectivement le même ensemble d’étapes que celles représentées par le cas d’utilisation inclus, sans aucune ambiguïté.

5. Modéliser un comportement exceptionnel

La relation d’extension peut être utilisée pour préciser quand et comment le comportement d’un cas d’utilisation peut être déclenché par un autre cas d’utilisation. L’extension a lieu aux points d’extension définis dans le cas d’utilisation étendu. Le cas d’utilisation étendant définit les étapes qui peuvent être exécutées par le cas d’utilisation étendu sous des conditions spécifiques.

6. Modéliser un scénario avec un flux d’événements

Un cas d’utilisation représente un objectif utilisateur, qui peut être atteint en passant par une séquence d’étapes. Certaines personnes tentent de modéliser directement les étapes sur un diagramme de cas d’utilisation en reliant l’acteur au cas d’utilisation par de nombreuses associations, prétendant que ce sont les étapes, ce qui est certainement incorrect. À la place, les étapes du cas d’utilisation peuvent être correctement décrites dans l’éditeur de flux d’événementséditeur de flux d’événements.

L’éditeur de flux d’événements est présenté sous forme de tableau, chaque ligne représentant une étape du cas d’utilisation. Vous pouvez y écrire les étapes, avec ou sans flux conditionnel. Vous pouvez également appliquer des formats au texte pour mettre en évidence les idées clés.

7. Utiliser judicieusement les stéréotypes pour la catégorisation

Un stéréotype est un mécanisme qui vous permet d’introduire une notation spécifique au domaine en plus des notations standard. Un stéréotype est indiqué entre deux guillemets, au-dessus du nom de la forme lorsqu’il est appliqué. Une utilisation appropriée des stéréotypes aide les lecteurs à mieux percevoir les différences entre les cas d’utilisation.

8. Modéliser le flux détaillé du système avec un diagramme de séquence

Diagramme de séquencevous permet de modéliser le comportement du système en représentant la communication et l’échange de messages entre objets au fil du temps. Mais par où commencer ? Au lieu de deviner quel interaction modéliser, vous pouvez commencer par vous référer aux besoins de l’utilisateur, ce que le modèle de cas d’utilisation vise précisément à présenter.

Nous savons que chaque cas d’utilisation représente un objectif utilisateur unique. Dessiner un diagramme de séquence à partir d’un cas d’utilisation signifie que vous allez modéliser ce que le système informatique doit faire pour satisfaire l’utilisateur. Idéalement, il n’y aura pas de conception redondante, car tous les diagrammes de séquence sont créés à partir de cas d’utilisation, qui représentent ce que l’utilisateur souhaite.

9. Appliquer la même largeur aux cas d’utilisation lorsque cela est approprié

Étant donné que les noms des cas d’utilisation ont des longueurs différentes, il est normal d’avoir des cas d’utilisation de largeurs différentes. Pour rendre le diagramme plus esthétique et plus facile à lire, il serait judicieux de les redimensionner pour qu’ils aient tous la même largeur.

10. Positionner les acteurs et les cas d’utilisation de manière significative

Un diagramme de cas d’utilisation avec des acteurs et des cas d’utilisation placés au hasard est certainement un cauchemar pour les lecteurs. Il faut examiner attentivement le diagramme pour trouver l’information souhaitée parmi les acteurs et les cas d’utilisation dispersés. Il serait préférable de placer les formes de manière ordonnée. Vous pouvez également regrouper les cas d’utilisation à l’aide de formes de paquetage si nécessaire.