Un guide rapide pour la modélisation de cas d’utilisation

La modélisation des cas d’utilisation est un outil utile pour capturer les exigences. Il fournit une représentation graphique des exigences d’un système logiciel.

Avec la publication du livre d’ Ivar Jacobson (1991) Object-Oriented Software Engineering, A Use-Case-Driven Approach , la modélisation des cas d’utilisation est effectivement devenue une technique d’analyse pratique ». Aujourd’hui, Jacobson continue de promouvoir cette approche de l’analyse des systèmes et l’a mise à niveau vers Use Case 2.0, qui est officiellement l’un des 14 types de diagrammes UML .

Étant donné que le modèle de cas d’utilisation est simple dans son concept et son apparence, il est relativement facile de discuter de son exactitude avec du personnel non technique (tel que des clients).

Un cas d’utilisation n’est pas une procédure, un processus ou une fonction.

Les éléments du diagramme de cas d’utilisation

Les éléments d’un diagramme de cas d’utilisation sont les acteurs (entités externes) et le cas d’utilisation lui-même. D’une manière générale, un cas d’utilisation est une unité fonctionnelle (exigence) ou un service dans un système.

Acteur

Un acteur est toute entité extérieure au système de conception, qu’il s’agisse d’une personne ou d’une autre entité non humaine. Un utilisateur d’un système est un exemple typique d’acteur. D’autres types d’acteurs comprennent des systèmes logiciels qui sont intégrés au système actuel (par exemple, un système de base de données), du matériel externe tel qu’un capteur, etc.

Il existe deux notations dans la spécification UML :

L’utilisation de stickman pour les acteurs est plus expressive, mais peut prêter à confusion si l’acteur n’est pas réellement une personne, mais une machine ou un appareil externe. Le symbole rectangle est la notation UML standard pour une classe .

Un acteur est un rôle plutôt qu’une personne réelle 

Un acteur représente le rôle de l’entité qui interagit avec le système actuel, pas une instance. La notation d’acteur indique que l’entité est une classe au lieu d’une instance de lecture (c’est-à-dire un utilisateur réel John ou Mary). La raison pour laquelle un acteur est un type d’une classe est que ce n’est pas l’acteur lui-même, mais le rôle qu’il joue.

Par exemple, un acteur peut représenter les clients d’une banque, plutôt que de spécifier un acteur distinct pour chaque client. De même, il peut y avoir un autre acteur représentant le directeur de banque. Fait intéressant, dans le monde réel, le directeur d’une banque peut également être client de la même banque. En d’autres termes, la même personne joue à la fois le rôle de client et de gestionnaire.

Acteurs primaires vs secondaires

L’acteur principal d’un cas d’utilisation est la partie prenante qui demande au système de fournir ses services. Il a un objectif associé au système – un objectif qui peut être satisfait par le fonctionnement du système. L’acteur principal est généralement, mais pas toujours, l’acteur qui déclenche le cas d’utilisation.

L’acteur secondaire est utilisé par le système, mais il n’interagit pas seul avec le système. En d’autres termes, les acteurs secondaires n’initient aucun cas d’utilisation.

Les cas d’utilisation sont généralement initiés par les acteurs principaux. Le système utilise un acteur secondaire tel qu’une base de données à travers un ensemble de cas d’utilisation. L’association entre les cas d’utilisation et les participants représente une communication bidirectionnelle.

Ainsi, pour chaque cas d’utilisation initié par un acteur principal, il faut répondre au cas d’utilisation connexe. De même, pour chaque association entre un acteur secondaire et un cas d’utilisation, la communication commence par le cas d’utilisation et l’acteur secondaire doit répondre à l’initiation.

Cas d’utilisation

Les cas d’utilisation représentent les fonctions (généralement des exigences) censées être implémentées par le système. Les détails du cas d’utilisation, à l’exception de son nom unique, ne sont pas exprimés intuitivement dans le diagramme ; Ces détails sont donnés dans la description du cas d’utilisation.

Les cas d’utilisation sont généralement initiés par des acteurs clés. Le système utilise une base de données et d’autres participants auxiliaires à travers un ensemble de cas d’utilisation.

L’association entre les cas d’utilisation et les acteurs représente une communication à double sens. Ainsi, pour chaque cas d’utilisation initié par l’acteur principal, il faut répondre à ce dernier. De même, pour chaque association entre l’acteur secondaire et le cas d’utilisation, la communication commence par le cas d’utilisation, et l’acteur secondaire doit répondre à l’initiation.

Limite du système

La limite du système définit le système d’intérêt par rapport au monde qui l’entoure.

Exemple de diagramme de cas d’utilisation : système de réservation d’une compagnie aérienne

Les cas d’utilisation définissent les interactions entre les acteurs externes et le système pour atteindre des objectifs particuliers. Un diagramme de cas d’utilisation contient quatre composants principaux

Dans le diagramme de cas d’utilisation d’un système de réservation de billets, le système est représenté par des boîtes contenant de nombreux cas d’utilisation différents. L’acteur principal est le client et l’acteur secondaire est l’administrateur. Le client initie les cas d’utilisation, tels que la réservation, la navigation et l’annulation des vols, tandis que l’administrateur initie les cas d’utilisation, tels que la mise à jour des enregistrements de vol, mais est considéré comme un acteur secondaire dans le cas d’utilisation de l’annulation du vol, car il ne fait qu’aider à terminer les cas d’utilisation initiés par le client.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION UML

Structuration des cas d’utilisation

Selon le domaine d’application et le choix du concepteur, un cas d’utilisation peut être décomposé en plusieurs cas d’utilisation, qui sont reliés par des relations < < include > > ou < < extend > >.

Le lien d’association représente une communication bidirectionnelle entre un acteur et un cas d’utilisation, et est donc une relation binaire. Puisqu’il s’agit d’une communication bidirectionnelle, pour chaque cas d’utilisation initié par un acteur principal, cet acteur doit obtenir une réponse du cas d’utilisation.

De même, pour chaque communication entre un cas d’utilisation et un acteur secondaire (initié par le cas d’utilisation), l’acteur secondaire doit renvoyer une réponse au cas d’utilisation.

Généralisation

La généralisation représente la relation entre

• rôles ou
• cas d’utilisation.

MODIFIER CE MODÈLE DE DIAGRAMME DE CAS D’UTILISATION UML

Si deux acteurs sont connectés par cette relation, alors l’acteur (ou cas d’utilisation) à l’extrémité de la flèche (relié au bas du triangle) est une version spécialisée de l’acteur (ou cas d’utilisation) à l’autre extrémité.

En règle générale, l’acteur (ou cas d’utilisation) à l’extrémité inférieure (connecté au bas du triangle) est appelé la version spécialisée de l’acteur (ou cas d’utilisation) à l’autre extrémité.

La généralisation signifie que la version spécialisée a toutes les fonctionnalités de la version générale, et peut-être plus.

Inclure   est un type spécial de relation entre deux cas d’utilisation. Si un cas d’utilisation A inclut un autre cas d’utilisation B, alors l’implémentation de A nécessite l’implémentation de B pour accomplir sa tâche. Cependant, B est indépendant de lui-même. Autrement dit, B n’a pas besoin de savoir quoi que ce soit sur A. B peut également être inclus dans tout autre cas d’utilisation.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

L’extension est un autre type particulier de relation entre deux cas d’utilisation. Si un cas d’utilisation B étend un autre cas d’utilisation A, alors l’implémentation de A peut inclure conditionnellement l’implémentation de B pour terminer sa tâche. Autrement dit, dans certains cas, A peut terminer sa tâche sans B. Cependant, selon les conditions décrites.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

Utiliser les notations des diagrammes de cas

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION EN LIGNE

9 étapes simples pour effectuer une analyse de cas d’utilisation

1. Déterminez qui utilisera directement le système. Ces personnes sont les acteurs.
2. Choisissez l’un de ces acteurs.
3. Définissez ce que cet acteur veut faire avec le système. Chaque chose que l’acteur veut faire avec le système devient un cas d’utilisation.
4. Répétez les étapes 2 et 3 pour tous les autres cas d’utilisation
   Identifiez les rôles secondaires et la prise en charge des rôles non humains pour les cas d’utilisation que vous avez identifiés.
5. Dessinez la version initiale du cas d’utilisation, ne compliquez pas trop les relations de cas d’utilisation à ce stade
6. Discutez et passez en revue avec les utilisateurs pour valider les objectifs de chaque cas d’utilisation (bénéfices de la fonctionnalité proposée) Après modifications, vous pouvez continuer à détailler les cas d’utilisation dans les étapes 8 à 10
7. Pour chaque cas d’utilisation, décidez du processus le plus courant que l’acteur suivra lors de l’utilisation du système. Ce qui se passerait normalement.
8. Décrivez ce processus de base dans la description du cas d’utilisation.
9. Une fois que vous êtes satisfait du processus de base, envisagez maintenant des scénarios alternatifs et ajoutez-les en tant que cas d’utilisation étendus.

Modèle de cas d’utilisation et spécification

Il ne suffit pas de montrer le diagramme de cas d’utilisation en notation UML. Chaque cas d’utilisation est accompagné d’un texte qui explique l’objectif du cas d’utilisation et la fonctionnalité qui est accomplie lorsque le cas d’utilisation est exécuté.

Un cas d’utilisation décrit une tâche effectuée par un acteur qui produit un résultat de valeur commerciale pour l’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 de texte structuré .

Scénarios de cas d’utilisation

Un cas d’utilisation se compose d’un certain nombre de scénarios, chacun représentant une instance spécifique du cas d’utilisation, correspondant à des entrées spécifiques de l’acteur ou à des conditions spécifiques dans l’environnement. Chaque scénario décrit une autre façon pour le système de se comporter, ou il peut décrire des échecs ou des exceptions.

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

Regroupement de cas d’utilisation avec des packages

Vous pouvez également : Dessiner des packages pour la catégorisation logique des cas d’utilisation dans des sous-systèmes associés.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

Spécification détaillée des cas d’utilisation

Un cas d’utilisation détaillé est une représentation textuelle qui décrit un flux d’événements et d’autres informations de cas d’utilisation connexes dans un format spécifique. Un modèle de cas d’utilisation standard est souvent utilisé pour documenter les détails d’un cas d’utilisation

Qu’est-ce qu’une description de cas d’utilisation

Une description de cas d’utilisation est une description écrite de la séquence d’étapes qu’un analyste effectue pour effectuer une transaction système complète. Elle est initiée par un acteur, apporte de la valeur à cet acteur et est le but des acteurs travaillant dans le système.

Acteur – Toute personne ou système externe au système qui utilise ou interagit avec le système pour atteindre un objectif. Chaque acteur se voit attribuer un rôle pour représenter son interaction avec la solution. Les acteurs de personnes doivent être nommés sous la forme de rôles et ne doivent pas se voir attribuer de noms réels. Les acteurs sont généralement classés comme principaux, secondaires ou parties prenantes

Acteur principal – L’acteur qui initie le cas d’utilisation.
Acteur secondaire – L’acteur qui réagit ou répond aux actions effectuées par l’acteur principal.
Parties prenantes – acteurs hors scène qui n’interagissent pas directement avec le cas d’utilisation, mais qui ont un intérêt dans le résultat du cas d’utilisation.

Flux de flux d’événements (chemin) – la séquence d’étapes que les acteurs et les solutions doivent suivre pour exécuter un cas d’utilisation. En général, un cas d’utilisation se compose d’un chemin de réussite principal (également appelé de base ou principal), d’un chemin alternatif et d’un chemin d’exception.

Le chemin normal – l’entrée de l’acteur et la réponse du système – représente le chemin de réussite le plus courant pour atteindre les objectifs de l’acteur.

Chemins alternatifs – entrées de l’acteur et réponses du système, représentant les autres chemins moins courants pour atteindre l’objectif de l’acteur

Chemins exceptionnels – entrées de l’acteur et réponse du système, représentant des chemins infructueux lorsque l’objectif de l’acteur ne peut pas être atteint.

Description du cas d’utilisation
Nom du cas d’utilisation :	Retirer de l’argent
Acteurs):	Client (primaire), Système bancaire (secondaire)
Description sommaire:	Permet à tout client de la banque de retirer de l’argent de son compte bancaire.
Priorité:	Doit avoir
Statut:	Niveau de détails moyen
Condition préalable:	Le client de la banque a une carte à insérer dans le GAB Le GAB est correctement en ligne
Condition(s) postérieure(s) :	Le client de la banque a reçu son argent (et éventuellement un reçu) La banque a débité le compte bancaire du client et enregistré les détails de la transaction
Chemin de base :	Le client introduit sa carte dans le guichet automatique Le distributeur vérifie que la carte est une carte bancaire valide Le guichet automatique demande un code PIN Le client saisit son code PIN Le GAB valide la carte bancaire par rapport au code PIN Le guichet automatique présente des options de service, notamment « Retirer » Le client choisit « Retirer » Le guichet automatique présente des options pour les montants Le client sélectionne un montant ou saisit un montant Le guichet automatique vérifie qu’il a suffisamment d’argent liquide dans sa trémie Le guichet automatique vérifie que le client est en dessous des limites de retrait Le guichet automatique vérifie les fonds suffisants sur le compte bancaire du client Le guichet automatique débite le compte bancaire du client Le GAB restitue la carte bancaire du client Le client prend sa carte bancaire Le guichet automatique émet l’argent du client Le client prend son argent
Chemins alternatifs :	2a. Carte invalide 2b. Carte à l’envers 5a. Carte volée 5b. NIP invalide 10a. Insuffisance d’espèces dans la trémie 10b. Mauvaise dénomination de l’argent dans la trémie 11a. Retrait au-dessus des limites de retrait 12a. Fonds insuffisants sur le compte bancaire du client 14a. Carte bancaire coincée dans la machine 15a. Le client ne prend pas sa carte bancaire 16a. Argent bloqué dans la machine 17a. Le client ne prend pas son argent un guichet automatique ne peut pas communiquer avec le système bancaire b Le client ne répond pas à l’invite du guichet automatique
Règles commerciales :	B1 : Format du NIP B2 : Nombre de tentatives de code PIN B3 : Possibilités d’entretien B4 : Options de montant B5 : Limite de retrait B6 : la carte doit être retirée avant la distribution d’espèces
Prérogatives non fonctionnelles:	NF1 : Délai de transaction complète NF2 : Sécurité pour la saisie du code PIN NF3 : Délai pour autoriser le retrait de la carte et de l’argent liquide NF4 : Prise en charge de la langue NF5 : Support aveugle et partiellement aveugle

Liens connexes

1. Qu’est-ce que le langage de modélisation unifié ?
2. Diapositive de cas d’utilisation / notes de cours
3. Le rôle des cas d’utilisation dans la modélisation des exigences et de l’analyse
4. Une liste d’outils UML
5. Essayez Visual Paradigm GRATUITEMENT
6. Cas d’utilisation – Notes pour la formation
7. Comment rédiger des cas d’utilisation efficaces ?
8. Chapitre de livre – PDF – Modèle de cas d’utilisation : Rédaction d’exigences en contexte