Le diagramme de cas d'utilisation est une vue utilisée pour décrire les fonctions du système composées d'acteurs, de cas d'utilisation et de la relation entre eux. Il est observable par des utilisateurs externes appelés acteurs. Les diagrammes de cas d'utilisation sont souvent utilisés lors de la phase d'analyse des exigences.
Avant de développer un système, la tâche la plus importante est d'obtenir les besoins des utilisateurs, et les plus importants parmi les besoins des utilisateurs sont les exigences fonctionnelles du système proposées par les utilisateurs. Nous pouvons utiliser des diagrammes de cas d'utilisation pour exprimer visuellement les besoins des utilisateurs.
Diagramme de cas d'utilisation visuel
Les principaux éléments d'un diagramme de cas d'utilisation incluent les acteurs, les cas d'utilisation et les relations entre les éléments. En plus de cela, les diagrammes de cas d'utilisation peuvent également contenir des annotations et des contraintes.
1. Notion de participants
Les acteurs sont des entités externes qui interagissent avec le système principal. Les participants peuvent être des personnes, des sous-systèmes, d'autres systèmes, etc.
Chaque acteur est en fait un ensemble de rôles. En UML, un acteur est représenté graphiquement sous une forme humaine et reçoit un nom. Comme le montre l'image ci-dessous, le « lecteur » participe au système de prêt des bibliothèques.
acteurs du diagramme de cas d'utilisation
Les acteurs doivent être en dehors des limites du système et ne pas en faire partie.
2. Comment identifier les participants
Lors de la modélisation de cas d'utilisation, l'identification des acteurs est la première étape de la modélisation de diagramme de cas d'utilisation. Alors, comment déterminer les participants du système ? Nous pouvons y réfléchir à partir des idées suivantes :
(1) Les objets de service du système, tels que les lecteurs dans le système de prêt de bibliothèque ;
(2) Les personnes qui fournissent un soutien pour terminer le travail - comme le personnel de la bibliothèque du système de prêt de bibliothèque, qui doit utiliser le système pour aider les lecteurs à terminer leurs emprunts, à rendre les livres et à effectuer des rappels ;
(3) Mainteneur du système : la personne responsable de l'installation, de la maintenance et de la gestion du système. Dans ce cas, le système doit fournir des fonctions pertinentes pour aider ce personnel à effectuer les travaux d'installation, de maintenance et de gestion ;
(4) Appareils externes : nécessité de transmettre des informations ou de lire des informations à partir d'appareils externes, tels que des lecteurs de cartes ;
(5) Autres systèmes ou sous-systèmes : tels que le système financier dans le système de prêt. Le système financier n'est pas une fonction du système de prêt, mais le système de prêt doit lui transmettre des informations pour terminer le travail en retard ;
(6) Heure : à un moment programmé, un événement spécifique se produit automatiquement, tel qu'une sauvegarde automatique, un rappel régulier, etc. ;
(7) Événements spécifiques : par exemple, la réception automatique des commandes dans le système de plats à emporter est pilotée par des événements de génération de commandes.
Lors de l'identification des participants , gardez les éléments suivants à l'esprit :
(1) Les participants sont situés en dehors du système et ne font pas partie du système ;
(2) Les participants interagissent avec le système à travers les frontières du système ;
(3) Bien que les icônes des participants soient représentées par des icônes en forme humaine, les participants ne sont pas nécessairement des personnes et peuvent également être d'autres sous-systèmes, d'autres systèmes, le temps, la température et d'autres facteurs.
3. Relations entre les participants
La principale relation entre les participants est la généralisation. La généralisation est représentée par une flèche triangulaire ouverte et pleine qui pointe vers des participants plus généraux et se termine du côté des participants « spécifiques ». Une relation de généralisation est une relation entre le général et le particulier (le concret). Dans une relation de généralisation, une description abstraite d'un participant peut être partagée par un ou plusieurs participants concrets. La figure suivante illustre les relations généralisées entre les participants dans un système de prêt de bibliothèque :
Relation de généralisation entre les participants au système de prêt en bibliothèque
retraités , etc. en dessous du lecteur sont des participants « spécifiques ». La généralisation des participants peut être comprise comme : un participant « spécifique » est un participant « général », tel qu'un membre du corps professoral qui est une sorte de lecteur. Dans la généralisation des acteurs, les cas d'utilisation qui sont exécutables par un acteur « général » sont représentés comme exécutables par un acteur « concret » (« spécial »).
1. La notion de cas d'utilisation
Un cas d'utilisation est un service système ou une unité fonctionnelle qui peut être expérimenté par les participants. Il définit un objectif que le système doit atteindre. Un cas d'utilisation définit uniquement un comportement du système mais ne révèle pas la structure interne du système.
Le plus grand avantage des cas d'utilisation est qu'ils décrivent les fonctions du système du point de vue de l'utilisateur. Graphiquement, un cas d'utilisation est représenté par une ellipse pleine avec le nom du cas d'utilisation à l'intérieur ou en dessous de l'ellipse :
Cas d'utilisation de l'emprunt de livres
2. Identifier les cas d'utilisation
Les cas d'utilisation peuvent être identifiés à travers les points suivants :
(1) De quelles fonctions le participant a-t-il besoin du système pour soutenir son travail ?
(2) Les participants doivent-ils interroger certaines informations dans le système ?
(3) Les participants doivent-ils modifier certaines informations dans le système, telles que des opérations de création, de modification et de suppression ?
(4) Les participants doivent-ils être informés d'événements spécifiques ou de changements d'état du système ?
(5) Quels événements externes dans le système inciteront le système à exécuter les fonctions pertinentes en réponse ?
(6) Le système fournit-il des fonctions pertinentes pour aider le personnel de maintenance à entretenir le système ?
3. Points clés de l'identification des cas d'utilisation
(1) Les cas d'utilisation identifiés doivent refléter les objectifs du système, c'est-à-dire « que faire » plutôt que « comment le faire », ce qui signifie que les cas d'utilisation ne sont pas des détails de la mise en œuvre du système ;
(2) Définir les cas d'utilisation du point de vue des participants (utilisateurs) plutôt que du point de vue du système ;
(3) Les cas d'utilisation doivent fournir des résultats précieux aux participants, plutôt qu'un ensemble d'actions ;
(4) Évitez de tomber dans la décomposition fonctionnelle et la décomposition par étapes ;
(5) Chaque participant doit avoir un cas d'utilisation exécutable et chaque cas d'utilisation doit être associé à au moins un participant.
4. Nommer les cas d'utilisation
Après avoir déterminé les cas d'utilisation du système, vous devez nommer chaque cas d'utilisation. La dénomination des cas d'utilisation doit décrire les objectifs atteints par les participants du point de vue de l'utilisateur. Les méthodes de dénomination suivantes peuvent être utilisées :
verbe + objet
Autrement dit, le nom du cas d'utilisation doit être sous la forme d'une expression verbe-objet. Comme choisir des cours, emprunter des livres, commander des biens et payer par carte de crédit.
5. Granularité des cas d'utilisation
La granularité du cas d'utilisation fait référence au degré auquel un cas d'utilisation affine ou intègre les fonctions du système. On peut également dire qu'il s'agit du nombre de services système ou d'unités fonctionnelles inclus dans un cas d'utilisation. Si la granularité du cas d'utilisation est trop grossière ou trop grande, le cas d'utilisation contiendra plus de fonctions système, et vice versa. Si la granularité des cas d'utilisation est trop grossière, il sera difficile de comprendre le système. Si la granularité est trop fine, le modèle de cas d'utilisation sera trop grand, ce qui entraînera des difficultés de conception. Si le cas d’utilisation est trop fin, il peut tomber dans une décomposition fonctionnelle, telle que :
Granularité initiale du cas d’utilisation
En fait, de nombreuses entreprises du système incluent de telles opérations d'ajout, de suppression, de modification et de vérification. Cela ne peut fournir aucun objectif significatif aux utilisateurs, mais ignorera leur objectif réel.
Le "ajouter, supprimer, modifier et vérifier" ci-dessus n'est rien d'autre que la gestion des utilisateurs, qui est le véritable objectif des participants. Il serait peut-être préférable de gérer le cas d'utilisation ci-dessus de la manière suivante :
Réduction de la granularité des cas d'utilisation
Le cas d'utilisation Gérer les utilisateurs représente un objectif ou une tâche pour les administrateurs système. Si vous devez ajouter des ajouts, des suppressions, des modifications et des requêtes, il serait préférable de l'exprimer de la manière suivante.
Après optimisation de la granularité du cas d'utilisation
Une autre erreur souvent commise dans la modélisation de cas d’utilisation est de traiter les étapes comme des cas d’utilisation. Par exemple, celui-ci semble parfait, mais il est évident que les étapes de fonctionnement sont considérées comme des cas d’usage :
Étapes de fonctionnement comme exemples d'erreurs de cas d'utilisation
Les étapes ci-dessus ne sont rien d'autre que la réalisation de l'objectif de l'utilisateur en tant que participant : l'inscription. Il convient donc de le modifier comme suit :
Après optimisation du cas d'utilisation
Dans la modélisation de cas d’utilisation, la troisième erreur courante consiste à traiter les activités du système comme des cas d’utilisation. Dans le diagramme de cas d'utilisation ci-dessous, l'établissement d'objets de connexion, la création d'objets de commande et l'exécution d'instructions SQL sont des activités au sein du système qui ne peuvent pas être perçues par l'utilisateur. Elles ne constituent pas le but de l'utilisateur et celui-ci s'en fiche. Ce diagramme de cas d’utilisation est donc inexact :
Exemple d'erreur de cas d'utilisation d'activité système
La quatrième erreur courante dans la modélisation des cas d'utilisation consiste à nommer les cas d'utilisation en utilisant une perspective système.
Utiliser la perspective système pour nommer des exemples d'erreurs de cas d'utilisation
Parmi les deux diagrammes de cas d’utilisation ci-dessus, lequel est le meilleur ? Évidemment, celui de droite est meilleur que celui de gauche, car le cas d'utilisation de droite est nommé du point de vue de l'utilisateur, tandis que le cas d'utilisation de gauche est nommé du point de vue du système, et les utilisateurs se sentiront confus après le voir.
6. Spécification du cas d'utilisation
Le diagramme de cas d'utilisation décrit généralement les exigences fonctionnelles de l'utilisateur (fonctions ou services fournis par le système), mais chaque cas d'utilisation doit être décrit en détail afin que les utilisateurs sachent ce que le cas d'utilisation est spécifiquement censé faire. Il s'agit de la spécification du cas d'utilisation. En d’autres termes, le modèle de cas d’utilisation consiste essentiellement en un diagramme de cas d’utilisation et une description détaillée de chaque cas d’utilisation (spécification du cas d’utilisation).
Une spécification de cas d'utilisation doit contenir le contenu suivant :
(1) L'identification et le nom du cas d'utilisation ;
(2) Les participants impliqués dans le cas d'utilisation ;
(3) Une brève description du cas d'utilisation ;
(4) Autres cas d'utilisation connexes ;
(5) Conditions préalables à l'exécution du cas d'utilisation
(6) Flux d'événements de base ;
(7) Flux d'événements alternatif ;
(8) Post-conditions pour l'exécution du cas d'utilisation ;
(9) Autres informations, telles que les exigences non fonctionnelles, les contraintes de conception, l'état de l'examen du cas d'utilisation, le préparateur, les enregistrements de modification, etc.
Les relations entre les cas d'utilisation comprennent principalement trois types : la généralisation, l'inclusion et l'expansion.
Lorsque plusieurs cas d'utilisation ont des attributs ou des comportements similaires, nous pouvons résumer leurs points communs dans un cas d'utilisation parent et d'autres cas d'utilisation en tant que cas d'utilisation enfants d'une relation de généralisation. Les cas d'utilisation enfants héritent des attributs et des comportements du cas d'utilisation parent. La relation de généralisation des cas d'utilisation peut être comprise comme différentes voies de mise en œuvre pour le même objectif commercial.
La relation de généralisation est représentée graphiquement par une implémentation avec une flèche triangulaire creuse pointant du cas d'utilisation enfant vers le cas d'utilisation parent.
Relation de généralisation du diagramme de cas d'utilisation
Dans l'exemple ci-dessus, « Mode de paiement 1 » et « Mode de paiement 2 » sont des cas de sous-utilisation de « Paiement ». Le cas d'utilisation parent « Paiement » ne fournit pas de méthodes de paiement spécifiques, mais fournit uniquement les attributs et les interfaces nécessaires au paiement, et implémente des fonctions de paiement spécifiques dans ses cas d'utilisation enfants.
Au cours du processus de modélisation du système, certaines fonctions doivent être utilisées de manière répétée dans différents scénarios métier. Ces fonctions utilisées à plusieurs reprises peuvent être séparées pour former un cas d'utilisation distinct, et lors de l'exécution de fonctions associées, les fonctions publiques séparées peuvent être incluses dans le processus principal. La relation d'inclusion des cas d'utilisation peut décrire cette situation. De plus, si un cas d'utilisation de base a trop de fonctions, il peut également être décomposé en plusieurs petits cas d'utilisation. Les cas d'utilisation contenus sont appelés cas d'utilisation de fournisseur, et les cas d'utilisation qui contiennent d'autres cas d'utilisation sont appelés cas d'utilisation de client.
En UML, la relation d'inclusion est représentée par une flèche en pointillé avec le stéréotype « include » . La flèche pointe du cas d'utilisation de base (y compris le cas d'utilisation/cas d'utilisation client) vers le cas d'utilisation inclus (cas d'utilisation du fournisseur).
Le diagramme de cas d'utilisation contient des relations
Ce qui suit est un exemple spécifique. Dans cet exemple, le lecteur souhaite pré-emprunter des livres. Il doit exécuter le cas d'utilisation du livre de requête avant de pouvoir pré-emprunter le livre. Par conséquent, le cas d'utilisation du livre de requête sera inclus dans le cas. Cas d'utilisation du livre de pré-emprunt. Dans le même temps, le lecteur doit lors du pré-emprunt de livres, il doit s'être connecté au système et le système a enregistré son statut de connexion avant de pouvoir effectuer l'opération de pré-emprunt, donc le cas d’utilisation de la vérification d’identité sera également inclus dans le cas d’utilisation du livre avant l’emprunt. L'interrogation de livres n'est pas seulement une fonction de base requise par un lecteur, mais également un processus opérationnel nécessaire pour d'autres fonctions. La vérification d'identité n'est pas seulement utilisée lors du pré-emprunt de livres, mais également lors de l'exécution de fonctions telles que l'interrogation des dossiers d'emprunt et le paiement des amendes. Il est plus approprié de proposer la vérification d'identité séparément pour former un cas d'utilisation :
Relation d'inclusion du livre de prêt anticipé du lecteur
Les cas d'utilisation de base fournissent des points d'extension, dans lesquels de nouveaux comportements peuvent être ajoutés. Les cas d'utilisation d'extension fournissent un ensemble de fragments d'insertion qui peuvent être insérés dans les points d'extension du cas d'utilisation de base.
· Le cas d'utilisation de base fournit uniquement des points d'extension sans connaître les détails du cas d'utilisation de l'extension.
· Un cas d'utilisation de base est complet même sans cas d'utilisation étendu, contrairement à une relation d'inclusion.
· Un cas d'utilisation peut fournir plusieurs points d'extension, et chaque point d'extension peut apparaître plusieurs fois.
· Dans des circonstances normales, l'exécution du cas d'utilisation de base n'impliquera pas le cas d'utilisation étendu. Les fonctions du cas d'utilisation étendu ne seront exécutées que lorsque des conditions ou des événements spécifiques se produisent.
En UML, une relation d'extension est représentée par une flèche en pointillé avec le stéréotype « étendre >>. Les flèches pointent des cas d'utilisation étendus aux cas d'utilisation de base.
Relation d'extension du diagramme de cas d'utilisation
L'exemple suivant est un fragment de diagramme de cas d'utilisation dans un système de prêt de bibliothèque :
Les lecteurs paient des amendes pour développer leurs relations
Dans cet exemple, payer une amende est un cas d’utilisation de base pour le lecteur et un cas d’utilisation étendu pour retourner le livre. "Payer une amende", en tant que cas d'utilisation étendu de "Rendre les livres", ne sera exécuté que dans les conditions suivantes :
(1) Les livres du lecteur sont en retard ou ont de bons dossiers pour d'autres raisons et n'ont pas été entièrement payés ;
(2) Le lecteur choisit de payer l'amende en même temps après avoir rendu le livre.
Ce qui précède est le contenu pertinent sur les diagrammes de cas d'utilisation UML. Tous les cas de diagramme de cas d'utilisation ci-dessus sont dessinés à l'aide de ProcessOn.
Carte mentale collaborative en ligne gratuite et organigramme Utilisation gratuite 
![[Partage d'informations utiles] Maîtrisez 14 types de diagrammes UML en 10 minutes](https://cdn.processon.io/admin/knowledge/article_thumb_img/66d15af4990fed148692bdec.png)