Qu’est-ce qu’un diagramme de cas d’utilisation ?
Un Diagramme de cas d’utilisation est un plan comportemental utilisé pour visualiser les relations entre les utilisateurs d’un système (appelés acteurs) et les actions ou objectifs spécifiques qu’ils souhaitent accomplir (appelés cas d’utilisation). Plutôt que de montrer des boucles logiques étape par étape, un diagramme de cas d’utilisation fournit un aperçu de haut niveau de la portée fonctionnelle d’un système, ce qui en fait un outil excellent pour définir les exigences du projet, les limites du système et les flux de travail des parties prenantes.
Avec VPasCode, vous pouvez instantanément créer des diagrammes de cas d’utilisation clairs et professionnels sans vous battre contre l’alignement visuel du canevas. Ce guide évite les notations obscures et obsolètes et se concentre uniquement sur les éléments syntaxiques pratiques dont vous avez besoin pour la documentation logicielle au quotidien.
Guide de syntaxe fondamentale : éléments et constructions
La création d’un diagramme de cas d’utilisation dans PlantUML repose sur quelques éléments structurels simples, placés entre les balises standards @startuml et @enduml .
1. Déclaration des acteurs
Un acteur représente une entité externe qui interagit avec votre application (tel qu’un utilisateur humain, un service en arrière-plan ou une API matérielle externe). Vous déclarez un acteur en utilisant le mot-clé actorsuivi d’un identifiant interne abrégé :
actor customer
actor admin comme "Administrateur système"
Astuce pro : Utilisez le mot-clé comme pour attribuer une chaîne d’affichage claire et lisible par l’humain aux identifiants d’acteurs complexes.
2. Définition des cas d’utilisation
Un cas d’utilisation représente un objectif fonctionnel ou un processus métier. Vous pouvez définir un cas d’utilisation de deux manières : en encadrant le texte entre des parenthèses (Votre cas d'utilisation), ou en utilisant explicitement le mot-clé cas d'utilisationmot-clé pour le formatage complexe :
(Connexion au tableau de bord)
cas d'utilisation checkout comme "Traiter le paiement par carte de crédit"
3. Cartographie des interactions de base
Pour connecter vos acteurs à leurs cas d’utilisation correspondants, utilisez des lignes de relation simples orientées ou non orientées. Vous pouvez également ajouter des étiquettes textuelles pour ajouter un contexte critique à une interaction :
client --> (Connexion au tableau de bord)
administrateur --> checkout : "Approuve les remboursements"
4. Relations avancées : Inclure et étendre
Lors de la modélisation de comportements système complexes, vous devez souvent montrer des dépendances entre différents cas d’utilisation en utilisant des stéréotypes UML standards :
- Inclure (dépendance obligatoire) :Indique qu’un cas d’utilisation de base dépend d’un autre cas d’utilisation d’aide pour réussir son exécution. Utilisez une ligne de connexion pointillée (
..>) accompagnée d’une étiquette textuelle :Plantuml Edit Plantuml in VPasCode(Traiter le paiement) ..> (Vérifier le solde) : <<inclure>>
- Étendre (comportement facultatif/conditionnel) :Indique qu’un flux de travail facultatif peut s’écarter d’un cas d’utilisation de base sous des conditions spécifiques. Notez que la flèche pointe du cas d’utilisation d’*extension* vers le cas d’utilisation de *base* :
Plantuml Edit Plantuml in VPasCode
(Appliquer le code promo) ..> (Traiter le paiement) : <<étendre>>
5. Imposer les limites du système
Pour distinguer clairement ce qui se passe à l’intérieur de votre application logicielle par rapport à ce qui se passe à l’extérieur, utilisez le “rectanglemot-clé pour encapsuler vos cas d’utilisation internes. De façon cruciale, les acteurs doivent rester à l’extérieur de ce bloc conteneur afin de refléter leur statut de participants externes :
acteur client
rectangle "Plateforme E-Commerce" {
(Parcourir le catalogue)
(Ajouter au panier)
}
client --> (Parcourir le catalogue)
client --> (Ajouter au panier)
Meilleures pratiques pour des mises en page propres
- Rester concis :Les cas d’utilisation doivent toujours commencer par un verbe clair et actif (par exemple, « Générer un rapport », « Mettre à jour le profil ») plutôt qu’une longue phrase.
- Utiliser des repères directionnels : Si vos acteurs et cas d’utilisation s’entassent de manière désordonnée, utilisez des flèches directionnelles spatiales telles que
-droite->ou-bas->pour guider doucement le moteur de mise en page vers une structure claire et lisible. - Isoler les limites du système : Utilisez toujours un rectangle de limite lorsque vous documentez des applications interagissant avec plusieurs microservices tiers. Cela rend immédiatement clair qui possède quel processus.
Exemples réels de diagrammes de cas d’utilisation PlantUML
Copiez-collez les maquettes pratiques suivantes directement dans votre panneau d’édition en direct de VPasCode pour voir comment elles sont rendues dynamiquement.
Exemple 1 : Authentification utilisateur principale et gestion des comptes
Ce modèle représente un écosystème d’application standard comprenant un utilisateur principal, un opérateur administratif et une boîte de limite contenant les mécanismes de sécurité fondamentaux.
@startuml
' Définir l'orientation du layout de gauche à droite
direction de gauche à droite
acteur "Utilisateur final" comme utilisateur
acteur "Administrateur Sécurité" comme admin
rectangle "Service de fournisseur d'identité" {
(Se connecter)
(Réinitialiser le mot de passe)
(Mettre à jour les données du profil)
(Consulter les journaux de sécurité)
(Désactiver les comptes)
}
utilisateur --> (Se connecter)
utilisateur --> (Réinitialiser le mot de passe)
utilisateur --> (Mettre à jour les données du profil)
(Consulter les journaux de sécurité) <-- admin
(Désactiver les comptes) <-- admin
@enduml
Analyse de la syntaxe : La directive direction de gauche à droite force le moteur de mise en page à positionner les acteurs sur les ailes extérieures et à faire croître les cas d’utilisation horizontalement plutôt que verticalement. Remarquez comment placer les déclarations d’acteurs proprement à l’extérieur du rectangleenveloppe les maintient organisés, tout en inversant la direction des crochets de flèche pour l’utilisateur administrateur (<-- admin) les fixe proprement sur le côté droit de la matrice du diagramme.
Exemple 2 : Checkout avancé pour e-commerce avec dépendances externes
Ce schéma de système du monde réel représente un flux de travail de paiement complexe qui dépend d’API bancaires externes, d’inclusions structurelles et de drapeaux d’extension optionnels.
@startuml
direction de gauche à droite
acteur "Client" comme client
acteur "Personnel du magasin" comme personnel
acteur "Passerelle Stripe" comme stripe
rectangle "Système de livraison de magasin en ligne" {
(Passer commande)
(Appliquer le coupon)
(Générer la facture)
(Préparer et emballer les articles)
(Mettre à jour l'état d'expédition)
}
' Interactions externes avec les limites du système
client --> (Passer commande)
(Passer commande) --> stripe : "Autoriser les fonds"
' Structures d'inclusion et d'extension
(Passer commande) ..> (Générer la facture) : <<inclure>>
(Appliquer le coupon) ..> (Passer commande) : <<étendre>>
' Chemins de traitement
(Préparer et emballer les articles) <-- personnel
(Mettre à jour l'état d'expédition) <-- personnel
(Générer la facture) --> personnel : "Envoyer une copie par e-mail"
@enduml
Analyse syntaxique : Ce modèle met en évidence comment un seul cas d’utilisation (Passer commande) impose un appel à (Générer la facture) en utilisant la <<inclure>> étiquette sur une ligne pointillée. En parallèle, l’application d’un code de coupon est correctement modélisée comme une branche optionnelle via <<étendre>> pointant vers l’arrière vers l’exécution de base. Tous les acteurs externes restent clairement isolés à l’extérieur de l’enveloppe du système.