Tutoriel d’analyse de cas d’utilisation

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

Les diagrammes de cas d’utilisation UML sont la principale forme d’exigences système/logiciel pour les nouveaux programmes logiciels en cours de développement. Le but d’un diagramme de cas d’utilisation est de visualiser ce que le système doit faire (quoi); à ce stade, il ne considère pas comment (comment) le faire.

Une fois qu’un cas d’utilisation est spécifié, il peut être représenté dans une représentation textuelle et visuelle (c’est-à-dire un diagramme de cas). Un concept clé de la modélisation des cas d’utilisation est qu’elle nous aide à concevoir le système du point de vue de l’utilisateur final. Il s’agit d’une technique efficace pour communiquer le comportement du système en termes d’utilisateur en spécifiant tous les comportements du système visibles de l’extérieur.

En d’autres termes, l’utilisation du système doit être vue de l’extérieur, c’est-à-dire que le système ne doit pas être vu de l’intérieur, mais d’un niveau supérieur pour déterminer la fonctionnalité que le système doit fournir aux acteurs externes.

Objectif des diagrammes de cas d’utilisation

Les diagrammes de cas d’utilisation sont généralement développés dans les premières étapes du développement, et les gens utilisent souvent la modélisation de cas d’utilisation aux fins suivantes.

• Spécifier le contexte d’un système
• Capturer les exigences d’un système
• Valider l’architecture d’un système
• Piloter la mise en œuvre et générer des cas de test
• Développé par des analystes, des experts du domaine et des utilisateurs finaux cibles ensemble

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

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

Éléments du diagramme de cas d’utilisation

Acteurs

Chaque cas d’utilisation aura au moins un acteur, qui peut être compris comme au moins un participant (rôle), qui n’est pas nécessairement une personne, mais peut être un autre système ou appareil. Un acteur peut interagir avec plus d’un cas d’utilisation, et un cas d’utilisation peut interagir avec plus d’un acteur.

Les acteurs ne sont pas nécessairement des personnes, c’est-à-dire des utilisateurs, mais ils peuvent en fait être des non-personnes, c’est-à-dire des systèmes ou du temps.

Le plus souvent, les utilisateurs sont des personnes impliquées dans le diagramme de cas d’utilisation, telles que des clients, des employés, des superviseurs, etc.

Acteurs humains vs acteurs non humains

De temps à autre, le système est affecté par divers événements pour exécuter certaines fonctions dans une situation donnée. Par exemple, lorsqu’un audit est réussi, le système envoie de manière proactive une lettre pour informer les personnes ; alors l’envoi de la lettre est-il effectué automatiquement par le système ? Ce cas d’utilisation est en fait déclenché par le temps, alors l’acteur est Timer ; par exemple, ce cas d’utilisation peut être vu comme « envoyer automatiquement une lettre à 5h00 tous les jours », alors l’acteur qui déclenche cet événement – l’envoi d’une lettre – n’est pas le système, mais en fait le Timer Actor

Acteurs primaires vs secondaires

Un acteur principal est un acteur qui utilise le système pour atteindre un objectif. Les cas d’utilisation documentent les interactions entre le système et les acteurs pour atteindre les objectifs de l’acteur principal. Les acteurs secondaires sont les acteurs que le système doit assister pour atteindre les objectifs de l’acteur principal.

• Les acteurs peuvent être primaires ou secondaires. Les acteurs primaires initient les interactions avec le système.
• Les acteurs secondaires sont généralement appelés par le système pour obtenir de l’aide et un acteur secondaire n’initie jamais le cas d’utilisation.

Notez que : Le symbole d’un acteur ne fait pas la différence entre un acteur principal et un acteur secondaire ; la différence doit être déduite des descriptions de cas d’utilisation (également appelées récits de cas d’utilisation).

Par exemple:

Un agent de crédit bancaire souhaite examiner la demande de prêt d’un client, et une partie du processus implique une vérification de la cote de crédit en temps réel.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

• Utiliser le nom du cas. Examiner une demande de prêt
• Acteur principal. Agent de crédit
• Acteur secondaire. Système de notation de crédit

Comment identifier les acteurs ?

Puisqu’un acteur n’est pas nécessairement une personne, mais peut être un système externe, un dispositif ou une minuterie, nous trouvons un acteur plus spécifique en posant les questions suivantes

• Qui utilisera le système une fois qu’il aura été développé ?
• De qui ou de quels autres systèmes le système aura-t-il besoin pour obtenir des données ?
• Pour qui ou pour quels autres systèmes le système fournira-t-il des données ?
• À quels autres systèmes le système sera-t-il associé ?
• Qui assurera la maintenance et l’administration du système ?

Ces questions nous aident à faire abstraction des acteurs du système. En prenant l’exemple des guichets automatiques, répondre à ces questions nous permet de trouver plus d’acteurs, c’est-à-dire

• L’ opérateur est responsable de la maintenance et de la gestion du système ATM
• Les guichets automatiques doivent également communiquer avec les serveurs principaux pour obtenir des informations sur les comptes d’utilisateurs.

Cas d’utilisation

Un cas d’utilisation représente une fonctionnalité (généralement une exigence) qui devrait être implémentée par le système. Les détails d’un cas d’utilisation, autres que son nom unique, ne sont pas représentés visuellement dans le diagramme ; ces détails sont donnés dans le récit (description textuelle) du cas d’utilisation.

Un cas d’utilisation est une liste d’actions ou d’étapes d’événements qui définissent généralement les interactions entre les rôles des acteurs et le système pour atteindre un objectif. Les cas d’utilisation sont une technique utile pour identifier, clarifier et organiser les exigences du système. Un cas d’utilisation consiste en un ensemble de séquences d’interactions possibles entre le système et l’utilisateur qui définissent la fonctionnalité à atteindre et les solutions aux éventuelles erreurs rencontrées.

Comment identifier les cas d’utilisation ?

Une fois que nous avons trouvé les acteurs, nous pouvons déterminer les cas d’utilisation du système en fonction des acteurs, en examinant principalement les services dont chaque acteur a besoin du système ou la manière dont les acteurs utilisent le système. L’identification des cas d’utilisation peut commencer par les questions suivantes (pour chaque participant).

• Pourquoi les acteurs utilisent-ils le système ?
• Le participant crée-t-il, modifie-t-il, supprime-t-il, accède-t-il et stocke-t-il des données dans le système ? Si oui, comment l’acteur effectue-t-il ces opérations ?
• L’acteur informe-t-il le système de certains événements extérieurs ?
• Le système informe-t-il l’acteur de certains événements internes ?

En rassemblant ce qui précède, le diagramme de cas d’utilisation du système ATM peut être représenté comme suit.

Le cas d’utilisation est présenté par des ellipses, de quelque chose de statique ou dynamique, ou d’une tâche ou d’un système.

Limite du système

Les limites du système décrivent le système en regroupant les cas d’utilisation dans des limites rectangulaires, et les limites du système dans Visual Paradigm fournissent le comportement de confinement des cas d’utilisation.

Les acteurs sont des rôles (acteurs humains ou acteurs non humains) qui interagissent avec le système en cours de développement. Par conséquent, les acteurs doivent être placés à l’extérieur des limites du système et interagir avec les cas d’utilisation qui sont placés à l’intérieur des limites du système.

Notez que: 

Un acteur est défini par les frontières du système. Si la limite du système que nous voulons définir est limitée au GAB lui-même, alors le serveur principal est un système externe et peut être abstrait en tant qu’acteur.

Si la limite du système que nous voulons définir s’étend à l’ensemble du système bancaire, où les guichets automatiques et les serveurs principaux font partie de l’ensemble du système bancaire, alors le serveur principal n’est plus abstrait en tant qu’acteur.

Relation amoureuse

Après avoir appris ces trois symboles clés, continuez avec la connaissance des relations et dessinez des diagrammes de cas d’utilisation. Une relation directe entre un participant et un cas d’utilisateur est dessinée, et la relation est utilisée comme une ligne sans flèches, indiquant une relation à double sens, appelée ligne de liaison.

Un cas d’utilisation peut être décomposé en plusieurs cas d’utilisation qui sont reliés par des relations <<include>>, <<extend>> ou <<generalization>> (décrites plus loin dans cet article).

Relation de lien de communication

Cela représente une communication bidirectionnelle entre un acteur et un cas d’utilisation et est donc une relation binaire.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

<<Inclure>> Relation

Une relation d’ inclusion signifie que le cas d’utilisation inclura d’autres cas d’utilisation. Inclure la relation a pour but d’utiliser Inclure la relation pour réduire la répétition de la description du même cas d’utilisation. Si de nombreux cas partagent la même fonction de portion, la fonction peut être séparée et d’autres cas d’utilisation peuvent être inclus dans le cas.

Par exemple, le bibliothécaire doit lire le code pour enregistrer le livre emprunté lorsque le livre est emprunté, et doit également lire le code pour enregistrer le livre rendu lorsque le livre est rendu, car la lecture du code est une partie répétitive de l’action. , il peut être transformé en un cas d’utilisation distinct, et laisser le livre emprunté et le livre rendu inclure ce cas.

MODIFIER CET EXEMPLE DE DIAGRAMME DE 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.

<<Prolonger>> Relation

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, A peut exiger B. Dans ce cas, B dépend de B. Cependant, selon les conditions décrites, A peut exiger B Dans ce cas, B dépend de A et ne peut exister seul. Pour cette raison, B ne peut pas être étendu à plus d’un cas d’utilisation. Le récit du cas d’utilisation de A inclura les étapes d’exécution qu’il requiert de B ; ce point est appelé le point d’extension.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

Regardons un autre exemple où le système commande automatiquement des marchandises lorsqu’il n’y a pas d’inventaire afin que le responsable n’ait pas à exécuter la commande directement. Voir le diagramme de cas d’utilisation ci-dessous :

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

Relation de généralisation

La relation généralisée est similaire à la relation généralisée du langage orienté objet dans les diagrammes de classes et peut être appliquée à la généralisation des rôles (acteurs) et des cas d’utilisation.

Par exemple, dans le système de réservation, il existe deux types de méthodes de réservation : « réserver un billet par téléphone » et « réserver un billet en ligne », et le cas d’utilisation de base « réserver un téléscripteur », vous pouvez donc utiliser la généralisation pour façonner le cas, et ajoutez <<essentiel>> au cas d’utilisation parent (réservation) pour indiquer la relation généralisée.

MODIFIER CET EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION

Discuter des relations dans le diagramme de cas d’utilisation

• Dans un diagramme de cas d’utilisation général, nous ne représentons que les relations entre acteurs et cas d’utilisation, c’est-à-dire les associations de communication entre eux.
• En outre, nous pouvons également décrire la généralisation entre les participants et les acteurs, ainsi que les relations d’inclusion, d’extension et de généralisation entre les cas d’utilisation.
• Nous utilisons ces relations pour adapter le modèle de cas d’utilisation existant et extraire des informations communes à réutiliser, ce qui facilite la maintenance du modèle de cas d’utilisation.
• Cependant, nous devons être prudents dans le choix de ces relations dans l’application. Généralement, ces relations augmentent le nombre de cas d’utilisation et de relations, augmentant ainsi la complexité du modèle de cas d’utilisation.
• De plus, le modèle de cas d’utilisation est généralement ajusté une fois qu’il est terminé, il n’est donc pas nécessaire de se précipiter pour résumer les relations entre les cas d’utilisation au début de la modélisation des cas d’utilisation.

Cas d’utilisation – le flux d’événements

Le diagramme de cas d’utilisation nous donne une vue globale de la fonctionnalité du système, nous pouvons savoir quels participants interagiront avec le système et quels services chaque acteur doit obtenir du système.

Le cas d’utilisation décrit la conversation entre les acteurs et le système, mais les détails de cette conversation ne sont pas représentés dans le diagramme de cas d’utilisation, donc pour chaque cas d’utilisation, nous pouvons décrire les détails de cette conversation en termes de flux d’événements.

Scénarios de cas d’utilisation et flux d’événements – retrait d’argent au guichet automatique

Par exemple, le cas « Retrait » dans un système ATM peut être représenté par un flux d’événements comme suit :

Scénario normal – Retrait de fonds – flux d’événements de base :

1. L’utilisateur insère une carte de crédit
2. Entrez le NIP
3. Entrez le montant du retrait
4. Retrait d’espèces
5. Quittez le système et récupérez la carte de crédit

Mais cela ne décrit que le scénario normal du cas d’utilisation du retrait. En tant que véritable système ATM, nous devons également considérer divers autres scénarios qui peuvent se produire, tels que :

• cartes de crédit invalides,
• mauvais mots de passe,
• solde de trésorerie insuffisant sur le compte de l’utilisateur, etc.

Toutes ces situations possibles (à la fois normales et anormales) sont appelées scénarios du cas d’utilisation et les scénarios sont également appelés instances du cas d’utilisation. Les scénarios sont également appelés instances de cas d’utilisation. Parmi les différents scénarios d’un cas d’utilisation, le scénario le plus courant est décrit par le processus de base, tandis que les autres scénarios sont décrits par des processus alternatifs.

Scénarios alternatifs

Pour le cas d’utilisation « Retrait » dans un système ATM, nous pouvons obtenir des processus alternatifs comme suit.

Retrait – processus événementiels alternatifs.

1. Scénario alternatif I : L’utilisateur peut se retirer à n’importe quelle étape du processus de base et passer à l’étape 5 du processus de base.
2. Processus alternatif II : à l’étape 1 du processus de base, l’utilisateur insère une carte de crédit non valide, le système affiche une erreur et quitte la carte de crédit, et le cas d’utilisation se termine.
3. Processus alternatif III : À l’étape 2 du processus de base, l’utilisateur entre un mot de passe incorrect, le système affiche une erreur et invite l’utilisateur à ressaisir le mot de passe et à revenir à l’étape 2 du processus de base ; après trois entrées de mot de passe incorrectes, la carte de crédit est confisquée par le système et le cas d’utilisation se termine.
4. …

En combinant le scénario de base et les scénarios alternatifs, toutes les différentes situations qui peuvent se produire dans un cas d’utilisation peuvent être clairement décrites. Lors de la description du flux d’événements d’un cas d’utilisation, nous voulons décrire autant que possible tous les scénarios possibles pour garantir l’exhaustivité des exigences.

Modèle de cas d’utilisation vs diagrammes de cas d’utilisation

Il est important d’éviter l’idée fausse qu’un diagramme de cas d’utilisation composé d’acteurs et de cas d’utilisation est un modèle de cas d’utilisation, car un diagramme de cas d’utilisation n’est qu’une représentation visuelle des services que le système peut fournir, nous donnant une idée générale de la fonctionnalité du système.

Le modèle de cas d’utilisation se compose d’un diagramme de cas d’utilisation et d’une description détaillée de chaque cas d’utilisation, la spécification de cas d’utilisation, qui est fournie sous forme de modèle dans le RUP.

Brève description Brève description
du rôle et de l’objectif du cas d’utilisation.

Flux d’événements 
Le flux d’événements doit représenter tous les scénarios, y compris les scénarios de base et alternatifs.

Scénarios de cas d’utilisation
Inclure des scénarios de réussite et des scénarios d’échec, et les scénarios sont principalement une combinaison de flux de base et alternatifs.

Exigences particulières
Décrivez les exigences non fonctionnelles (y compris les performances, la fiabilité, la disponibilité, l’évolutivité, etc.) et les contraintes de conception (système d’exploitation, outils de développement, etc.) associées au cas d’utilisation.

Condition préalable
L’état dans lequel le système doit se trouver avant que le cas d’utilisation puisse être exécuté.

Post-conditions
L’ensemble des états dans lesquels le système peut se trouver après l’exécution du cas d’utilisation.

Une spécification de cas d’utilisation est essentiellement une représentation textuelle, avec la possibilité d’utiliser des diagrammes d’état, des diagrammes d’activité ou des diagrammes de séquence pour aider à décrire plus clairement le flux d’événements. Toute représentation graphique des interfaces utilisateur et des processus, ou d’autres graphiques, c’est-à-dire des structures filaires, peut être jointe au cas d’utilisation tant qu’elles contribuent à améliorer la clarté de la représentation.

Par exemple:

• les diagrammes d’activités sont utiles pour décrire des processus décisionnels complexes,
• les diagrammes de transition d’état sont utiles pour décrire le comportement du système lié à l’état, et
• les diagrammes de séquence sont appropriés pour décrire la messagerie temporelle.

Outils de cas d’utilisation

Version en ligne

La version gratuite de l’outil de dessin gratuit Visual Paradigm Online (VP Online) prend en charge UML, ERD et les organigrammes. Vous pouvez rapidement dessiner des diagrammes de cas d’utilisation avec l’éditeur de dessin UML intuitif. Cet outil UML gratuit n’a pas de publicité, pas de période d’accès limitée et pas de restrictions telles que le nombre de diagrammes, le nombre de formes, etc. Dessinez UML librement. Dessinez UML librement. vous êtes propriétaire des diagrammes que vous créez à des fins personnelles et non commerciales.

Version de bureau

L’ édition communautaire de Visual Paradigm , disponible depuis 2004, fournit un logiciel UML gratuit à des fins non commerciales uniquement, prenant en charge les utilisateurs qui font leurs premiers pas dans la modélisation UML, ainsi que ceux qui ont besoin d’un logiciel de modélisation UML multiplateforme gratuit pour usage personnel, comme l’application d’UML sur des projets d’étudiants.

Les références

• Qu’est-ce qu’un diagramme de cas d’utilisation ?
• Types d’acteurs dans le modèle de cas d’utilisation
• Identifier les besoins des utilisateurs avec des diagrammes de cas d’utilisation
• Qu’est-ce qu’une spécification de cas d’utilisation ?
• User Story vs cas d’utilisation pour le développement logiciel agile
• Utiliser une approche basée sur des cas pour le développement agile

Ressources UML

• Qu’est-ce qu’UML ?
• Pourquoi la modélisation UML ?
• Présentation des 14 types de diagrammes UML