Modélisation de cas d’utilisation

Un diagramme de cas d’utilisation  UML   est la principale forme d’exigences système/logiciel pour un nouveau programme logiciel en cours de développement. Les cas d’utilisation spécifient le comportement attendu (quoi) d’un système, et non la méthode exacte pour y parvenir (comment). Un ensemble complet de cas d’utilisation spécifie toutes les différentes manières d’utiliser le système et définit donc tous les comportements requis du système délimitant la portée du système.

Un concept clé de la modélisation des cas d’utilisation est qu’elle nous aide à concevoir un système du point de vue de l’utilisateur final. Il s’agit d’une technique efficace pour communiquer le comportement du système dans les termes de l’utilisateur en spécifiant tous les comportements du système visibles de l’extérieur.

Diagramme de cas d’utilisation en un coup d’œil

Une forme standard de diagramme de cas d’utilisation est définie dans le langage de modélisation unifié, comme indiqué dans l’exemple de diagramme de cas d’utilisation ci-dessous :

Qu’est-ce qu’un cas d’utilisation ?

• Un cas d’utilisation est un ensemble de séquences possibles d’interactions entre le système en cours de discussion et ses acteurs externes liés à un objectif particulier.
• Chaque cas d’utilisation est un cours complet d’événements dans le système du point de vue de l’utilisateur.
• Les cas d’utilisation une fois spécifiés peuvent être désignés à la fois par une représentation textuelle et visuelle (c’est-à-dire un diagramme de cas d’utilisation).
• Les cas d’utilisation sont la méthode privilégiée par la communauté des composants et des objets pour spécifier les exigences et, en fait, pour piloter l’ensemble du processus de développement logiciel.
• Les cas d’utilisation s’en tiennent généralement à des tâches assez importantes ; ils n’ont pas besoin d’être écrits pour chaque action que l’utilisateur peut effectuer.

Avantages de l’approche par cas d’utilisation

Les cas d’utilisation offrent de nombreux avantages au-delà de la définition des besoins des utilisateurs. Les cas d’utilisation peuvent être utilisés pour :

• Utilisez l’aide de cas pour capturer les exigences fonctionnelles d’un système.
• Les cas d’utilisation sont traçables.
• Les cas d’utilisation peuvent servir de base à l’effort d’estimation, de planification et de validation.
• Le cas d’utilisation peut évoluer à chaque itération d’une méthode de capture des exigences, à des directives de développement pour les programmeurs, à un cas de test et enfin à une documentation utilisateur.
• Les chemins alternatifs de cas d’utilisation capturent un comportement supplémentaire qui peut améliorer la robustesse du système.
• Les cas d’utilisation se sont avérés facilement compréhensibles par les utilisateurs professionnels et se sont donc avérés un excellent pont entre les développeurs de logiciels et les utilisateurs finaux.
• Identifier les classes de domaine métier et leurs associés

Acteur

• Quelqu’un interagit avec le cas d’utilisation (fonction système).
• Nommé par le nom.
• L’acteur joue un rôle dans l’entreprise
• Semblable au concept d’utilisateur, mais un utilisateur peut jouer différents rôles
• Par exemple:
• Un prof. peut être instructeur et aussi chercheur
• joue 2 rôles avec deux systèmes
• L’acteur déclenche des cas d’utilisation.
• L’acteur a une responsabilité envers le système (entrées) et l’acteur a des attentes vis-à-vis du système (sorties).

Cas d’utilisation

• Fonction du système (processus — automatisé ou manuel)
• Nommé par verbe + nom (ou syntagme nominal).
• c’est-à-dire faire quelque chose
• Chaque acteur doit être lié à un cas d’utilisation, tandis que certains cas d’utilisation peuvent ne pas être liés à des acteurs.

Lien de communication

• La participation d’un acteur à un cas d’utilisation est matérialisée en reliant un acteur à un cas d’utilisation par un lien solide.
• Les acteurs peuvent être connectés à des cas d’utilisation par des associations, indiquant que l’acteur et le cas d’utilisation communiquent entre eux à l’aide de messages.

Limite du système

• La limite du système est potentiellement l’ensemble du système tel que défini dans le document des exigences.
• Pour les grands systèmes complexes, chaque module peut constituer la limite du système.
• Par exemple, pour un système ERP pour une organisation, chacun des modules tels que personnel, paie, comptabilité, etc.
• peut former une frontière système pour les cas d’utilisation spécifiques à chacune de ces fonctions métier.
• L’ensemble du système peut couvrir tous ces modules représentant la limite globale du système

Analyse de cas d’utilisation en 6 étapes

Lors du développement de cas d’utilisation, vous devez commencer par une partition fonctionnelle – une liste des principales catégories fonctionnelles du système ciblé. Cela aidera à identifier les domaines sur lesquels il faut se concentrer.

Étape 1 — identifier les acteurs : Identifiez qui va utiliser directement le système. Ce sont les Acteurs.

• Les acteurs sont l’un des principaux composants du développement de cas d’utilisation.
• Un acteur est un rôle spécifique joué par un utilisateur du système et représente une catégorie d’utilisateurs qui présentent des comportements similaires lors de l’utilisation du système.
• Les acteurs peuvent être des personnes ou des systèmes informatiques.
• Un acteur principal est un acteur ayant un objectif nécessitant l’assistance du système.
• Un acteur secondaire est un acteur dont le système a besoin d’aide pour atteindre son objectif.
• L’un des acteurs est désigné comme le système en discussion.
• Une personne peut jouer plusieurs rôles et représenter ainsi plusieurs acteurs, tels que l’opérateur du système informatique ou l’utilisateur final.

Étape 2 : Choisissez l’un de ces acteurs.

• Pour identifier le cas d’utilisation d’un système cible, nous identifions les acteurs du système.
• Un bon point de départ consiste à vérifier la conception du système et à identifier qui il est censé aider.

Étape 3 — Identifier les cas d’utilisation : Définissez ce que cet acteur veut faire avec le système. Chacune de ces choses que l’acteur veut faire avec le système devient un cas d’utilisation.

• Les choses que les acteurs veulent faire avec le système deviennent des buts.
• Le but est le résultat final des actions de l’utilisateur. Il existe deux types d’objectifs. Le premier type est un objectif rigide.
• Cet objectif doit être entièrement satisfait et décrit les exigences minimales d’un système cible.
• Pour identifier les cas d’utilisation, nous pouvons lire la spécification des exigences du point de vue d’un acteur et poursuivre les discussions avec les utilisateurs qui fonctionneront en tant qu’acteurs.
• En définissant tout ce que chaque acteur pourra faire en interaction avec le système, la fonctionnalité complète du système est définie.

Étape 4 – Identifiez le scénario de cas d’utilisation normal : pour chacun de ces cas d’utilisation, décidez du cours le plus courant lorsque cet acteur utilise le système. Ce qui se passe normalement.

• Un cas d’utilisation comporte un cours de base et plusieurs cours alternatifs.
• Le cours de base est le cours le plus simple, celui dans lequel une demande est délivrée sans aucune difficulté.
• Il peut y avoir des cours alternatifs qui décrivent des variantes du cours de base et les erreurs qui peuvent survenir.
• Celles-ci sont documentées en tant qu’extensions du cas d’utilisation.

Étape 5 – Développer la description du cas d’utilisation : décrivez ce cours de base dans la description du cas d’utilisation.

• Le scénario d’utilisation est rédigé du point de vue de l’utilisateur dans un langage facile à comprendre.
• Les étapes nécessaires pour atteindre l’objectif identifié sont écrites, connues sous le nom de flux d’événements.

Étape 6 – Développer des chemins alternatifs de cas d’utilisation : Une fois que vous êtes satisfait du cours de base, considérez maintenant les alternatives et ajoutez-les en tant que cas d’utilisation étendus.

Scénarios alternatifs d’un cas d’utilisation

Un cas d’utilisation décrit également comment le système doit réagir lorsque les choses  ne  vont pas bien ou  vont  bien, mais  pas  de la manière décrite dans le scénario de réussite principal. Nous appelons ces situations  des extensions .

• Il existe deux variétés :  les exceptions  et  les alternatives .
• Les exceptions sont les conditions d’échec (quelque chose s’est mal passé).
• Les alternatives sont simplement une manière différente pour que les choses se passent bien.

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 .

Les références

• Comment dessiner un diagramme de cas d’utilisation
• Tutoriel de diagramme de cas d’utilisation
• Description du cas d’utilisation