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
- Déterminez qui utilisera directement le système. Ces personnes sont les acteurs.
- Choisissez l’un de ces acteurs.
- 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.
- 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. - Dessinez la version initiale du cas d’utilisation, ne compliquez pas trop les relations de cas d’utilisation à ce stade
- 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
- 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.
- Décrivez ce processus de base dans la description du cas d’utilisation.
- 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) : |
|
| Chemin de base : |
|
| Chemins alternatifs : |
|
| Règles commerciales : |
|
| Prérogatives non fonctionnelles: |
|
Liens connexes
- Qu’est-ce que le langage de modélisation unifié ?
- Diapositive de cas d’utilisation / notes de cours
- Le rôle des cas d’utilisation dans la modélisation des exigences et de l’analyse
- Une liste d’outils UML
- Essayez Visual Paradigm GRATUITEMENT
- Cas d’utilisation – Notes pour la formation
- Comment rédiger des cas d’utilisation efficaces ?
- Chapitre de livre – PDF – Modèle de cas d’utilisation : Rédaction d’exigences en contexte
Français
English
简体中文
繁體中文
Deutsch
Español
العربية
Italiano
Português
日本語
Nederlands
Русский
Heya i am for the first time here. I found this board and I find It really useful & it helped me out much. I hope to give something back and help others like you helped me.