Tout ce que vous devez savoir sur la modélisation des cas d’utilisation

Avantages du diagramme de cas d’utilisation

1. Les cas d’utilisation sont une technique puissante pour l’élicitation et la documentation des exigences fonctionnelles de la boîte noire.
2. Parce que les cas d’utilisation sont faciles à comprendre et constituent un excellent moyen de communiquer avec les clients et les utilisateurs car ils sont écrits en langage naturel.
3. Les cas d’utilisation peuvent aider à gérer la complexité des grands projets en divisant le problème en principales fonctionnalités utilisateur (c’est-à-dire les cas d’utilisation) et en spécifiant les applications du point de vue des utilisateurs.
4. Un scénario de cas d’utilisation, souvent représenté par un diagramme de séquence, implique la collaboration de plusieurs objets et classes, les cas d’utilisation aident à identifier les messages (opérations et informations ou données requises – paramètres) qui collent les objets et les classes ensemble.
5. Les cas d’utilisation fournissent une bonne base pour faire le lien entre la vérification des modèles de niveau supérieur (c’est-à-dire l’interaction entre les acteurs et un ensemble d’objets collaboratifs), et par la suite, pour la validation des exigences fonctionnelles (c’est-à-dire le plan de test de la boîte blanche).
6. L’approche axée sur les cas d’utilisation fournit des liens traçables pour le suivi du projet dans lequel les activités de développement clés telles que les cas d’utilisation mis en œuvre, testés et livrés remplissent les buts et objectifs du point de vue de l’utilisateur.

Comment dessiner un diagramme de cas d’utilisation ?

Un modèle de cas d’utilisation peut être développé en suivant les étapes ci-dessous.

1. Identifier les acteurs (rôle des utilisateurs) du système.
2. Pour chaque catégorie d’utilisateurs, identifiez tous les rôles joués par les utilisateurs pertinents pour le système.
3. Identifiez quels sont les utilisateurs qui ont besoin que le système soit exécuté pour atteindre ces objectifs.
4. Créez des cas d’utilisation pour chaque objectif.
5. Structurer les cas d’utilisation.
6. Prioriser, revoir, estimer et valider les utilisateurs.

Notez que : pour rendre l’approche des cas d’utilisation plus « Agile », ne détaillez pas tous les cas d’utilisation, mais hiérarchisez-les dans votre backlog de produit, vous devez affiner le cas d’utilisation à différents niveaux de détails en fonction de la phase de développement avec juste-à-temps et juste assez.

Vous pouvez également:

1. Dessinez des packages pour la catégorisation logique des cas d’utilisation dans des sous-systèmes associés.

Structuration des cas d’utilisation

UML définit trois stéréotypes d’association entre Use Cases :

<<inclure>> Cas d’utilisation

Le moment d’utiliser la relation <<include>> est une fois que vous avez terminé la première description de tous vos cas d’utilisation principaux. Vous pouvez maintenant consulter les cas d’utilisation et identifier les séquences courantes d’interaction utilisateur-système.

<<étendre>> Cas d’utilisation

Un cas d’utilisation étendu est, en fait, un cours alternatif du cas d’utilisation de base. Le cas d’utilisation <<extend>> accomplit cela en insérant conceptuellement des séquences d’action supplémentaires dans la séquence de cas d’utilisation de base.

Cas d’utilisation abstrait et généralisé

Le cas d’utilisation général est abstrait. Il ne peut pas être instancié, car il contient des informations incomplètes. Le titre d’un cas d’utilisation abstrait est affiché en italique.

Exemple

Cet exemple décrit un modèle de plusieurs cas d’utilisation métier (objectifs) qui représente les interactions entre un restaurant (le système métier) et ses principaux acteurs.

Une fois que les cas d’utilisation de base ont été identifiés lors de la première coupe, nous pourrions peut-être structurer davantage ces cas d’utilisation avec des cas d’utilisation <<extend>> et <<include>> lors de la deuxième retouche, comme illustré dans la figure ci-dessous :

Cas d’utilisation métier

Un cas d’utilisation métier est décrit dans  une terminologie sans technologie  qui traite le processus métier comme une boîte noire et décrit le processus métier utilisé par ses acteurs métier, tandis qu’un cas d’utilisation ordinaire est normalement décrit au  niveau de la fonctionnalité du système  et spécifie la fonction. ou le service que le système fournit à l’utilisateur. En d’autres termes, le cas d’utilisation métier représente la façon dont le travail doit être effectué manuellement dans la situation actuelle et il n’est pas nécessairement effectué par le système ou destiné à être automatisé dans le cadre du système cible.

Comment identifier les acteurs

Souvent, les gens trouvent qu’il est plus facile de commencer le processus d’élicitation des exigences en identifiant les acteurs. Les questions suivantes peuvent vous aider à identifier les acteurs de votre système (Schneider et Winters — 1998) :

• Qui utilise le système ?
• Qui installe le système ?
• Qui démarre le système ?
• Qui maintient le système ?
• Qui arrête le système ?
• Quels autres systèmes utilisent ce système ?
• Qui obtient des informations de ce système ?
• Qui fournit les informations au système ?
• Est-ce que quelque chose se passe automatiquement à un instant présent ?

Comment identifier les cas d’utilisation ?

L’identification des cas d’utilisation, puis le processus d’élicitation basé sur des scénarios se poursuivent en demandant quelle valeur visible et observable de l’extérieur que chaque acteur souhaite. Les questions suivantes peuvent être posées pour identifier les cas d’usage, une fois vos acteurs identifiés (Schneider et Winters — 1998) :

• Quelles fonctions l’acteur voudra-t-il du système ?
• Le système stocke-t-il des informations ? Quels acteurs vont créer, lire, mettre à jour ou supprimer ces informations ?
• Le système doit-il informer un acteur des chances dans l’état interne ?
• Y a-t-il des événements externes dont le système doit être informé ? Quel acteur informe le système de ces événements ?

Conseils d’utilisation du diagramme de cas

Maintenant, consultez les conseils ci-dessous pour voir comment appliquer efficacement les cas d’utilisation dans votre projet logiciel.

• Structurez et organisez toujours le diagramme de cas d’utilisation du point de vue des acteurs.
• Les cas d’utilisation doivent commencer simplement et avec la vue la plus élevée possible. Ce n’est qu’alors qu’ils pourront être affinés et détaillés davantage.
• Les diagrammes de cas d’utilisation sont basés sur la fonctionnalité et doivent donc se concentrer sur le « quoi » et non sur le « comment ».

Utiliser les niveaux de détails des cas

La granularité des cas d’utilisation fait référence à la manière dont les informations sont organisées dans les spécifications des cas d’utilisation et, dans une certaine mesure, au niveau de détail auquel elles sont écrites. Atteindre le bon niveau de granularité des cas d’utilisation facilite la communication entre les parties prenantes et les développeurs et améliore la planification des projets.

Alastair Cockburn dans  Writing Effective Use Cases  nous donne un moyen simple de visualiser différents niveaux d’objectifs en pensant en termes de mer :

Notez que:

• Alors qu’un cas d’utilisation lui-même peut approfondir de nombreux détails sur chaque possibilité, un diagramme de cas d’utilisation est souvent utilisé pour une vue de niveau supérieur du système sous forme de plans.
• Il est avantageux d’écrire des cas d’utilisation à un niveau de granularité plus grossier avec moins de détails lorsque cela n’est pas nécessaire.

J’espère que vous pourrez répondre à « qu’est-ce qu’un diagramme de cas d’utilisation » maintenant et que vous pourrez appliquer un cas d’utilisation dans votre projet. Si vous souhaitez en savoir plus sur les autres types de diagrammes UML, veuillez consulter le guide UML :  Overview of the 14 UML Diagram Types .

Il ne suffit pas de montrer le diagramme de cas d’utilisation en   notation UML . Chaque cas d’utilisation est accompagné d’un texte expliquant le but du cas d’utilisation ainsi que la fonctionnalité accomplie lorsqu’un cas d’utilisation est exécuté.

La spécification de cas d’utilisation est généralement créée lors de la phase d’analyse et de conception de manière itérative.

• Dans un premier temps, seule une brève description des étapes nécessaires pour exécuter le flux normal du cas d’utilisation (c’est-à-dire, quelle fonctionnalité est fournie par le cas d’utilisation) est écrite.
• Au fur et à mesure que l’analyse progresse, les étapes sont étoffées pour ajouter plus de détails.
• Enfin, les flux exceptionnels sont ajoutés au cas d’utilisation
• Chaque projet peut adopter un modèle de cas d’utilisation standard pour la création de la spécification de cas d’utilisation.

Cas d’utilisation vs spécification de cas d’utilisation

Un cas d’utilisation décrit une tâche effectuée par un acteur produisant un résultat de valeur commerciale pour une entreprise. Un cas d’utilisation peut être visualisé sous la forme d’un diagramme de cas d’utilisation ou/et dans un format de spécification textuelle structurée :

Le cas d’utilisation (tâche — qu’un client souhaite exécuter) peut être :

• Interactif – Un cas d’utilisation du système décrit l’interaction d’un acteur avec un système dans la poursuite de l’objectif commercial défini
• Manuel — Une séquence d’actions exécutées par un acteur
• Automatisé — Une séquence d’étapes exécutées par un programme ou un script

Caractéristiques des cas d’utilisation

Un cas d’utilisation a :

• Un seul but
• Un point de départ unique
• Un point final unique
• Plusieurs chemins pour aller du début à la fin
• c’est-à-dire spécifier le comportement pour une variété de conditions possibles
• Chaque condition peut nécessiter une ou des actions spécifiques

Par exemple — Le client paie la facture :

Il existe plusieurs chemins pour atteindre l’objectif :

• Paiement par téléphone
• Par mail
• En personne
• par chèque
• en liquide, etc…

Un chemin qui ne mène pas au but :

• La carte de crédit est refusée

Approche de cas d’utilisation agile

Le modèle de cas d’utilisation et ses cas d’utilisation individuels évoluent niveau par niveau au fil du temps. Tous les cas d’utilisation d’un modèle n’auront pas nécessairement besoin d’être spécifiés au même niveau de détail.

Juste à temps et juste assez

Les cas d’utilisation peuvent être écrits à différents niveaux de données et de portée, chacun ayant un objectif :

• Résumé : descriptions générales et aperçus généraux des fonctionnalités du système ou des processus métier.
• Niveau utilisateur : descriptions des utilisateurs liées aux tâches et comment ils interagissent avec le système ; descriptions d’un processus métier spécifique. Les cas d’utilisation au niveau de l’utilisateur sont généralement considérés comme se situant au niveau de la tâche qui constitue le travail principal de l’utilisateur.
• Sous-fonction : descriptions des activités de niveau inférieur utilisées pour compléter les sous-parties d’un cas d’utilisation principal.

Remarque : Certains cas d’utilisation peuvent être suffisamment spécifiés jusqu’au niveau II. Vous vous arrêtez lorsque suffisamment de détails sont obtenus en utilisant juste à temps et juste assez.

Une spécification détaillée des cas d’utilisation

Le cas d’utilisation détaillé est une représentation textuelle illustrant une séquence d’événements ainsi que d’autres informations de cas d’utilisation connexes dans un certain format. Les gens adoptent généralement un modèle de cas d’utilisation standard pour enregistrer les informations détaillées des cas d’utilisation