Diagrammes de cas d’utilisation UML en code avec PlantUML et VPasCode

Un diagramme de cas d’utilisation UML montre ce qu’un système offre et qui — ou quoi — interagit avec lui. Avec un flux de travail diagramme-en-code, la source du diagramme est du texte brut : modifiez le texte, générez le diagramme, et conservez la source à côté de la documentation du projet.

PlantUML prend en charge les diagrammes de cas d’utilisation. L’éditeur VPasCode de Visual Paradigm propose un éditeur et un aperçu PlantUML, ainsi que des fonctionnalités de génération et d’édition de diagrammes assistées par IA.

1. Ce qu’un diagramme de cas d’utilisation communique

Les diagrammes de cas d’utilisation se concentrent sur la portée du système et les objectifs des utilisateurs, et non les mécanismes étape par étape d’un flux de travail. Un diagramme contient généralement :

• Limite du système :Un rectangle nommant le système modélisé.

• Acteur :Un rôle extérieur au système qui interagit avec lui. Les acteurs peuvent être des personnes, des organisations, des appareils ou des systèmes externes.

• Cas d’utilisation :Une capacité ou un objectif fourni par le système, généralement représenté par un ovale et nommé avec une phrase verbale, comme « Passer une commande ».

• Association :Une ligne indiquant qu’un acteur participe à un cas d’utilisation.

• Relations entre cas d’utilisation :Inclure, étendre et généralisation.

Les acteurs représentent des rôles, pas des individus spécifiques. Un service de paiement externe peut être un acteur s’il interagit avec le système modélisé.

Les diagrammes de cas d’utilisation sont utiles pour clarifier la portée du système, discuter des exigences avec les parties prenantes, identifier les dépendances externes et fournir une vue d’ensemble partagée pour le développement et les tests. Associez-les à des descriptions écrites de cas d’utilisation lorsque vous avez besoin de détails tels que les préconditions, les étapes principales, les flux alternatifs et les résultats.

2. Relations en un coup d’œil

• Association acteur–cas d’utilisation :Une ligne simple indiquant une interaction.

• <<inclure>>:Le cas d’inclusion utilise toujours le comportement inclus. La flèche pointillée pointe du cas d’inclusion vers le cas inclus. Par exemple, passer une commande peut toujours inclure l’autorisation de paiement.

• <<étendre>>:Un cas d’extension ajoute un comportement à un cas d’utilisation de base sous une condition. La flèche pointillée pointe du cas d’utilisation d’extension vers le cas d’utilisation de base. Par exemple, l’application d’une promotion peut étendre la passation d’une commande.

• Généralisation : Un acteur ou un cas d’utilisation spécialisé hérite d’un plus général. La ligne pleine avec un triangle creux pointe vers l’élément général.

Une distinction utile : « include » signifie un comportement requis ; « extend » signifie un comportement conditionnel ajouté.

3. Essentiels de PlantUML

Un diagramme PlantUML commence par @startuml et se termine par @enduml. Déclarez les acteurs avec actor, les cas d’utilisation avec usecase et les limites du système avec rectangle. Les alias facilitent la référence aux éléments dans les relations.

@startuml
direction left to right

actor Client

rectangle "Boutique en ligne" {
  usecase "Parcourir les produits" as Parcourir
  usecase "Passer une commande" as Commander
}

Client --> Parcourir
Client --> Commander
@enduml

direction de gauche à droite demande à PlantUML de disposer le diagramme horizontalement. PlantUML peut ajuster la disposition précise au fur et à mesure que le diagramme évolue.

4. Exemple : boutique en ligne de base

@startuml
direction left to right

acteur Client
acteur Administrateur comme Admin

rectangle "Boutique en ligne" {
  cas d'utilisation "Parcourir les produits" comme Parcourir
  cas d'utilisation "Passer une commande" comme Commander
  cas d'utilisation "Suivre l'expédition" comme Suivre
  cas d'utilisation "Gérer le catalogue" comme Gérer
}

Client --> Parcourir
Client --> Commander
Client --> Suivre
Admin --> Gérer
@enduml

Les clients parcourent, commandent et suivent les expéditions. L’administrateur gère le catalogue. Le diagramme omet délibérément les étapes internes du traitement des commandes.

5. Exemple : include et extend

Supposons que passer une commande nécessite toujours une autorisation de paiement, tandis que l’application d’une promotion est facultative et conditionnelle.

@startuml
direction left to right

acteur Client

rectangle "Boutique en ligne" {
  cas d'utilisation "Passer une commande" comme Commander
  cas d'utilisation "Autoriser le paiement" comme Paiement
  cas d'utilisation "Appliquer une promotion" comme Promotion
}

Client --> Commander

Commander ..> Paiement : <<include>>
Promotion ..> Commander : <<extend>>
@enduml

La Commander ..> Paiement flèche signifie que « Passer une commande » inclut le comportement de paiement requis. La Promotion ..> Commander flèche signifie que « Appliquer une promotion » étend « Passer une commande » lorsque sa condition est remplie.

Documentez la condition — par exemple, « le client saisit un code promotionnel valide » — dans la description du cas d’utilisation ou dans une note.

6. Exemple : généralisation d’acteur et systèmes externes

Un acteur spécialisé hérite des interactions d’un acteur plus général. Les services externes peuvent également être des acteurs lorsqu’ils interagissent avec le système.

@startuml
direction left to right

acteur "Utilisateur" comme User
acteur "Client enregistré" comme Customer
acteur "Passerelle de paiement" comme Gateway

Customer --|> User

rectangle "Boutique en ligne" {
  cas d'utilisation "Parcourir les produits" comme Browse
  cas d'utilisation "Passer une commande" comme Place
  cas d'utilisation "Traiter le paiement" comme Pay
}

User --> Browse
Customer --> Place
Place ..> Pay : <<include>>
Gateway --> Pay
@enduml

Le « client enregistré » spécialise « Utilisateur » et hérite de l’interaction utilisateur générale. La passerelle de paiement est située à l’extérieur de la limite de la boutique en ligne, mais participe au cas d’utilisation de paiement.

7. Exemple : généralisation de cas d’utilisation

La généralisation peut représenter des versions spécialisées d’un cas d’utilisation plus large. Le triangle creux pointe vers le cas d’utilisation général.

@startuml
left to right direction

actor Client

rectangle "Système de paiement" {
  usecase "Effectuer un paiement" as Paiement
  usecase "Payer par carte" as Carte
  usecase "Payer par virement bancaire" as Virement
}

Client --> Carte
Client --> Virement

Carte --|> Paiement
Virement --|> Paiement
@enduml

Utilisez ceci lorsque les cas d’utilisation spécialisés partagent un objectif général mais présentent des différences significatives. Si les variations ne sont que des étapes conditionnelles, une <<étendre>> relation ou une description écrite du cas d’utilisation peut être plus claire.

8. Travailler dans VPasCode

Un flux de travail pratique :

1. Définir le périmètre.Identifier la limite du système, les rôles des acteurs et les objectifs que chaque rôle souhaite atteindre.

2. Créer une ébauche.Écrire PlantUML directement ou demander à l’assistant IA de générer un diagramme de cas d’utilisation.

3. Revoir le code et prévisualiser.Confirmer que les acteurs sont à l’extérieur de la limite du système, que les cas d’utilisation sont à l’intérieur, et que les flèches pointent dans la bonne direction.

4. Affiner le modèle.Remplacer les noms vagues, supprimer les détails d’implémentation et ajouter des relations uniquement lorsqu’elles reflètent des exigences réelles.

5. Demander des modifications ciblées par l’IA.Par exemple : « Ajouter un acteur de passerelle de paiement externe et montrer l’interaction de paiement requise en utilisant une relation « inclure ». Garder le reste inchangé. »

6. Valider avec les parties prenantes.Vérifier que le diagramme reflète le périmètre réel du système et les objectifs des utilisateurs.

7. Enregistrer la source. Conservez le .puml texte avec la documentation du projet ou dans le système de contrôle de version. Exportez une image si nécessaire pour les documents ou les présentations.

Exemple de demande d’assistance à l’IA

Créez un diagramme de cas d’utilisation UML en PlantUML pour une boutique en ligne. Incluez une frontière du système, des acteurs Client et Administrateur, et les objectifs Parcourir les produits, Passer une commande, Suivre l’expédition et Gérer le catalogue. Montrez l’autorisation de paiement comme un comportement requis inclus par Passer une commande. Montrez l’application d’une promotion comme une extension conditionnelle de Passer une commande. Retournez uniquement le code source PlantUML valide.

Traitez le code généré par l’IA comme une première ébauche. Examinez les acteurs, les frontières, les relations et les hypothèses métier avant de l’utiliser.

9. Pièges courants

• Modéliser des composants internes comme des acteurs : Les acteurs doivent être des rôles externes ou des systèmes qui interagissent avec le sujet.

• Nommer les cas d’utilisation comme des tâches d’implémentation : Préférez « Suivre l’expédition » à « Appeler l’API de suivi ».

• Utiliser <<include>> pour un comportement optionnel : « Include » représente un comportement que le cas d’utilisation de base requiert.

• Inverser les flèches de relation : « Include » pointe vers le cas d’utilisation inclus ; « extend » pointe vers le cas d’utilisation de base.

• Surcharger un diagramme de détails : Utilisez un diagramme de haut niveau pour le périmètre, puis des diagrammes séparés ou du texte pour les scénarios détaillés.

• Supposer qu’un rendu réussi signifie que le modèle est correct : PlantUML peut rendre un diagramme qui représente encore incorrectement les exigences.

10. Liste de vérification

Avant de partager le diagramme, confirmez que :

• La frontière du système est claire.

• Chaque acteur est externe et représente un rôle.

• Les noms des cas d’utilisation décrivent des objectifs significatifs.

• Les associations d’acteurs reflètent les interactions réelles.

• Les relations « include » sont requises ; les relations « extend » sont conditionnelles ou autrement justifiées.

• Les flèches de généralisation pointent vers l’acteur ou le cas d’utilisation général.

• Le diagramme reste lisible à sa taille prévue.

• Les hypothèses générées par l’IA ont été examinées avec des personnes familiarisées avec les exigences.

Cette publication est également disponible en Deutsch, English, Español, فارسی, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam : liste des langues séparées par une virgule, 繁體中文 : dernière langue.