Guide des diagrammes de cas d’utilisation PlantUML

Introduction

Utilisation cas diagrammes offrent à définir manière claire pour décrire comment les utilisateurs, les systèmes externes, et les autres acteurs interagissent avec un système logiciel. Ils aident les équipes à définir la portée du système, identifier fonctionnel exigences, et communiquer attendu comportement avant mise en œuvre commence.

PlantUML rend l’utilisation cas de modélisation pratique grâce à une syntaxe basée sur du texte qui peut être stockée, examinée, versionnée, et régénérée aux côtés de documentation du projet ou source code. Avec quelques commandes, vous pouvez définir des acteurs, des cas d’utilisation, des limites du associations, des associations, des relations <<inclure>>, des relations

<<étendre>>, des généralisations, des notes, PlantUML utilisation cas notation présentée dans la feuille de référence et démontre comment à appliquer cela dans exemples réalistes Elle présente également dans un flux de travail plus large utilisant Visual Paradigm UML, assisté par l’IA modélisation, et VPasCode. Ensemble, ces outils prennent en charge un processus complet : processus : transformer les exigences en un modèle initial, modèle initial, valider les relations UML, les relations UML, affiner le diagramme, et maintenir le modèle final modèle final en tant que diagramme lisible diagramme lisible source.

Un diagramme de cas d’utilisation UML décrit comment les utilisateurs externes ou les systèmes interagissent avec un système. Il se concentre sur ce que fait le système, plutôt que sur la manière dont il est implémenté.

PlantUML vous permet de créer des diagrammes de cas d’utilisation en utilisant une notation textuelle simple.

1. Structure de base de PlantUML

Chaque diagramme PlantUML commence par @startuml et se termine par @enduml.

@startuml

' Le contenu du diagramme va ici

@enduml

Les commentaires commencent par une apostrophe :

' Ceci est un commentaire

Vous pouvez également utiliser des commentaires multilignes :

/'
Ceci est un
comentaire sur plusieurs lignes
'/

2. Définir des acteurs

Un acteur représente une personne, un rôle, une organisation, un appareil ou un système externe qui interagit avec votre système.

Acteur de base

actor User

Cela crée un acteur en forme de bâton nommé User.

Acteur avec un alias

Les alias sont utiles lorsque le nom affiché contient des espaces ou lorsque vous souhaitez un identifiant plus court pour les relations.

actor "Passerelle de paiement" as payment
actor "Administrateur système" as admin

Vous pouvez ensuite faire référence aux alias :

payment --> ProcessPayment
admin --> ManageUsers

Acteur utilisant un style visuel différent

PlantUML prend en charge plusieurs styles d’acteurs. Le style par défaut est généralement suffisant, mais vous pouvez utiliser un acteur de style icône :

skinparam actorStyle awesome

actor Client

Vous pouvez également utiliser un acteur de style rectangle simple :

skinparam actorStyle hollow

actor Client

L’apparence exacte dépend du moteur de rendu PlantUML et des paramètres de thème.

3. Définir les cas d’utilisation

Un cas d’utilisation représente un service, un objectif ou une fonction fournie par le système.

Cas d’utilisation de base

usecase "Connexion"

PlantUML affiche ceci comme une ellipse étiquetée Se connecter.

Cas d’utilisation avec un alias

usecase "Traiter le paiement par carte de crédit" as ProcessPayment

L’étiquette visible est Traiter le paiement par carte de crédit, tandis que ProcessPayment est utilisé dans les relations.

actor Client
Client --> ProcessPayment

Noms de cas d’utilisation sur plusieurs lignes

Vous pouvez insérer un saut de ligne en utilisant n:

usecase "Traiternle paiement parncarte de crédit" as ProcessPayment

Ceci est utile lorsqu’un diagramme contient des étiquettes longues.

4. Limites du système

Une limite de système regroupe les cas d’utilisation qui appartiennent à un système particulier.

rectangle "Système d'achat en ligne" {
    usecase "Parcourir les produits" as Browse
    usecase "Paiement" as Checkout
}

Le rectangle représente le système, et les cas d’utilisation à l’intérieur représentent les fonctionnalités fournies par ce système.

Vous pouvez également utiliser un alias nommé pour la limite :

rectangle "Système d'achat en ligne" as OnlineStore {
    usecase "Parcourir les produits" as Browse
    usecase "Paiement" as Checkout
}

Une limite de système est utile pour distinguer le comportement du système des acteurs et services externes.

5. Connecter les acteurs et les cas d’utilisation

Une association indique qu’un acteur participe à ou interagit avec un cas d’utilisation.

Association non dirigée

Client -- Parcourir

Cela crée une ligne pleine sans pointe de flèche.

Association dirigée

Client --> Parcourir

Cela crée une ligne pleine avec une pointe de flèche pointant vers le cas d’utilisation.

Les deux formes sont couramment utilisées. La direction de la flèche doit être choisie de manière cohérente selon la communication ou la responsabilité que vous souhaitez mettre en évidence.

Association avec une étiquette

Client --> Paiement : commence

L’étiquette décrit l’interaction.

Client --> VoirCommandes : affiche l'historique des commandes

Pour une mise en page plus lisible, vous pouvez utiliser une flèche plus longue :

Client ---> Commander : démarre

6. La <<inclure>> relation

Une inclure relation représente un comportement qui est toujours requis par un autre cas d’utilisation.

Par exemple, passer une commande peut toujours nécessiter une validation du paiement :

PasserCommande ..> ValiderPaiement : <<inclure>>

La direction est importante :

Cas d'utilisation de base ..> Cas d'utilisation inclus : <<inclure>>

La flèche pointe du cas d’utilisation qui a besoin du comportement vers le cas d’utilisation qui fournit le comportement réutilisable.

Exemple

usecase "Passer une commande" as PasserCommande
usecase "Valider les détails du client" as ValiderClient
usecase "Calculer le total de la commande" as CalculerTotal
usecase "Effectuer le paiement" as EffectuerPaiement

PasserCommande ..> ValiderClient : <<include>>
PasserCommande ..> CalculerTotal : <<include>>
PasserCommande ..> EffectuerPaiement : <<include>>

Cela signifie :

1. Passer une commande valide toujours les détails du client.

2. Passer une commande calcule toujours le total de la commande.

3. Passer une commande effectue toujours le paiement.

Utiliser <<inclure>> lorsque le comportement inclus est obligatoire ou réutilisable.

7. La <<étendre>> relation

Une extension relation représente un comportement optionnel, conditionnel ou exceptionnel ajouté à un cas d’utilisation de base.

Par exemple, l’application d’une réduction peut se produire uniquement lorsque le client dispose d’un bon valide :

AppliquerRemise ..> PasserCommande : <<étendre>>

La direction est :

Cas d'utilisation d'extension optionnel ..> Cas d'utilisation de base : <<extend>>

La flèche pointe depuis le comportement optionnel vers le cas d’utilisation de base.

Exemple correct

usecase "Checkout" as Checkout
usecase "Apply Discount Coupon" as ApplyDiscount

ApplyDiscount ..> Checkout : <<extend>>

Cela signifie que Appliquer un coupon de réduction étend optionnellement le processus de paiement.

Comparaison entre inclure et étendre

Exemple :

Checkout ..> ValidatePayment : <<include>>
ApplyDiscount ..> Checkout : <<extend>>

Évitez d’inverser ces relations car la direction en modifie le sens.

8. Généralisation des cas d’utilisation

La généralisation montre qu’un cas d’utilisation est une forme spécialisée d’un autre cas d’utilisation.

usecase "Rechercher des produits" as SearchProducts
usecase "Parcourir des produits" as BrowseProducts

SearchProducts -|> BrowseProducts

Le triangle creux pointe vers le cas d’utilisation le plus général.

Cela signifie que Rechercher des produits est une variante spécialisée de Parcourir des produits.

La généralisation est moins courante que include et extend, donc utilisez-le uniquement lorsqu’il existe une véritable relation parent-enfant entre les cas d’utilisation.

9. Généralisation des acteurs

Les acteurs peuvent également avoir des relations de généralisation.

acteur Client
acteur "Client Premium" as ClientPremium

ClientPremium -|> Client

Cela indique qu’un client premium est un type spécialisé de client et hérite des interactions de l’acteur général.

Par exemple :

ClientPremium --> AppliquerRemise

10. Notes et annotations

Les notes ajoutent des explications ou des contraintes à un diagramme.

Note attachée à un cas d’utilisation

note à droite de Paiement
  Le client doit fournir
  des informations de facturation
  valides.
end note

D’autres positions incluent :

note à gauche de Paiement
  Processus orienté client
end note

note au-dessus de Paiement
  Flux de travail commercial principal
end note

note en dessous de Paiement
  Inclut le traitement des paiements
end note

Syntaxe de note courte

note à droite de Login : Une authentification utilisateur est requise

Note autonome avec un alias

note "Le paiement doit être autorisénavant que la commande soit confirmée" comme PaymentNote

Reliez la note à un élément avec une ligne pointillée :

PaymentNote .. MakePayment

Notes pour les contraintes

Les notes sont utiles pour documenter les conditions :

note à droite de ApplyDiscount
  Comportement optionnel :
  utilisé uniquement lorsqu'un
  coupon valide est fourni.
fin note

11. Direction de la mise en page

Par défaut, PlantUML choisit automatiquement une mise en page. Vous pouvez influencer la direction.

Mise en page de gauche à droite

direction de gauche à droite

Cela est souvent utile pour les diagrammes de cas d’utilisation car les acteurs apparaissent à gauche et les systèmes externes à droite.

Mise en page de haut en bas

direction de haut en bas

Cela peut être utile pour des diagrammes compacts ou des flux de travail organisés verticalement.

Liens de mise en page invisibles

Un lien invisible peut influencer le positionnement sans afficher de relation visible :

Client -[caché]-> Paiement

Ceci est utile pour améliorer la mise en page du diagramme.

12. Mise en forme du diagramme

Supprimer les ombres

skinparam shadowing false

Utiliser des paquets et des limites rectangulaires

skinparam packageStyle rectangle

Définir les couleurs

skinparam usecase {
    BackgroundColor #FDFDFD
    BorderColor #333333
}

skinparam actor {
    BorderColor #333333
}

Définir les couleurs des flèches

skinparam ArrowColor #555555

Définir la taille de police par défaut

skinparam defaultFontSize 14

Une section de style complète peut ressembler à ceci :

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome
skinparam defaultFontSize 14

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #234
}

skinparam ArrowColor #555555

13. Paquets et regroupement

Les paquets peuvent regrouper des cas d’utilisation liés.

package "Fonctionnalités Client" {
    usecase "Créer un compte" as Register
    usecase "Se connecter" as Login
    usecase "Parcourir les produits" as Browse
}

package "Fonctionnalités d'Administration" {
    usecase "Gérer les produits" as ManageProducts
    usecase "Générer un rapport de ventes" as SalesReport
}

Les packages sont utiles lorsqu’un diagramme contient de nombreux cas d’utilisation.

Vous pouvez également utiliser un rectangle comme groupe :

rectangle "Gestion des commandes" {
    usecase "Passer une commande" as PlaceOrder
    usecase "Suivre une commande" as TrackOrder
    usecase "Annuler une commande" as CancelOrder
}

14. Systèmes externes

Les applications ou services externes peuvent être représentés comme des acteurs.

actor "Passerelle de paiement" as PaymentGateway
actor "Service d'envoi d'e-mails" as EmailService
actor "CRM externe" as CRM

Connectez-les aux cas d’utilisation du système :

PaymentGateway --> MakePayment
EmailService --> SendConfirmation
CRM --> SynchronizeCustomer

Cela sépare clairement les fonctionnalités du système des services situés en dehors des limites du système.

15. Exemple complet

L’exemple suivant combine les principales notations de la feuille de référence.

@startuml
title Système d'achat en ligne - Diagramme des cas d'utilisation

direction de gauche à droite

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #333333
}

skinparam ArrowColor #555555

' Acteurs
actor Client as client
actor "Client Premium" as premium
actor Administrateur as admin
actor "Passerelle de paiement" as payment
actor "Service d'envoi d'e-mails" as email

' Généralisation des acteurs
premium -|> client

' Limite du système
rectangle "Système d'achat en ligne" {

    ' Cas d'utilisation du client
    usecase "Créer un compte" as Register
    usecase "Se connecter" as Login
    usecase "Parcourir les produits" as Browse
    usecase "Rechercher des produits" as Search
    usecase "Voir les détails du produit" as ViewProduct
    usecase "Ajouter un produit au panier" as AddToCart
    usecase "Voir le panier" as ViewCart
    usecase "Passer à la caisse" as Checkout
    usecase "Passer une commande" as PlaceOrder
    usecase "Suivre une commande" as TrackOrder
    usecase "Annuler une commande" as CancelOrder

    ' Comportement partagé inclus
    usecase "Valider les informations du client" as ValidateCustomer
    usecase "Calculer le total de la commande" as CalculateTotal
    usecase "Effectuer un paiement" as MakePayment
    usecase "Envoyer une confirmation de commande" as SendConfirmation

    ' Comportement optionnel
    usecase "Appliquer un coupon de réduction" as ApplyDiscount
    usecase "Demander un remboursement" as RequestRefund

    ' Cas d'utilisation d'administration
    usecase "Gérer les produits" as ManageProducts
    usecase "Générer un rapport de ventes" as SalesReport
}

' Associations des acteurs
client --> Register
client --> Login
client --> Browse
client --> Search
client --> ViewProduct
client --> AddToCart
client --> ViewCart
client --> Checkout
client --> TrackOrder
client --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
admin --> SalesReport

payment --> MakePayment
email --> SendConfirmation

' Relations d'inclusion
Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> PlaceOrder : <<include>>

PlaceOrder ..> MakePayment : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

' Relations d'extension
ApplyDiscount ..> Checkout : <<extend>>
RequestRefund ..> CancelOrder : <<extend>>

' Généralisation des cas d'utilisation
Search -|> Browse

' Notes
note right of Checkout
    Processus principal d'achat du client
end note

note right of ApplyDiscount
    Comportement optionnel :
    utilisé uniquement lorsqu'un coupon
    valide est disponible
end note

note bottom of MakePayment
    Le paiement est géré par
    une passerelle de paiement externe
end note

@enduml

16. Lecture de l’exemple complet

Le diagramme communique ce qui suit :

• Client peut parcourir les produits, ajouter des produits au panier et passer à la caisse.

• Client Premium est une forme spécialisée de Client.

• Passer à la caisse inclut toujours la validation du client, le calcul du total et la passation de la commande.

• Passer une commande inclut toujours le paiement et la confirmation.

• Appliquer un coupon de réduction est optionnel et étend le processus de caisse.

• Demander un remboursement est une extension optionnelle de l’annulation.

• La passerelle de paiement gère le traitement des paiements.

• Le service d’envoi d’e-mails envoie les confirmations de commande.

• L’administrateur gère les produits et génère des rapports.

17. Erreurs courantes

Inverser inclure

Incorrect :

ValidateCustomer ..> Checkout : <<inclure>>

Correct :

Checkout ..> ValidateCustomer : <<inclure>>

Le cas d’utilisation de base pointe vers le comportement inclus requis.

Inversionétendre

Incorrect :

Checkout ..> ApplyDiscount : <<étendre>>

Correct :

ApplyDiscount ..> Checkout : <<extend>>

Le cas d’utilisation d’extension optionnel pointe vers le cas d’utilisation de base.

Utiliser include pour un comportement optionnel

Si un comportement ne se produit que dans certaines conditions, utilisez <<extend>>:

ApplyDiscount ..> Checkout : <<extend>>

S’il se produit toujours, utilisez <<include>>:

Checkout ..> ValidateCustomer : <<include>>

Placer des acteurs externes à l’intérieur de la limite du système

Les utilisateurs et services externes devraient normalement être à l’extérieur du rectangle :

actor Client

rectangle "Système d'achat" {
    usecase "Paiement" as Paiement
}

Client --> Paiement

Créer des cas d’utilisation trop détaillés

Un cas d’utilisation doit décrire un objectif utilisateur significatif, tel que :

usecase "Passer une commande"

Évitez de transformer chaque petite étape d’implémentation en un cas d’utilisation distinct, sauf si elle est réutilisée, optionnelle ou importante pour le modèle.

18. Modèle pratique minimal

Pour un diagramme plus petit, utilisez ce modèle :

@startuml

direction left to right

actor Utilisateur

rectangle "Mon Système" {
    usecase "Objectif principal de l'utilisateur" as ObjectifPrincipal
    usecase "Comportement partagé requis" as ComportementPartage
    usecase "Comportement optionnel" as ComportementOptionnel
}

Utilisateur --> ObjectifPrincipal

ObjectifPrincipal ..> ComportementPartage : <<include>>
ComportementOptionnel ..> ObjectifPrincipal : <<extend>>

note right de ObjectifPrincipal
    Fonction principale du système
end note

@enduml

Ce modèle contient la notation essentielle :

• Acteur

• Limite du système

• Cas d’utilisation

• Association

• Inclure

• Étendre

• Note

• Direction de la mise en page

Outils : Visual Paradigm UML, IA et VPasCode

PlantUML est idéal pour créer des diagrammes sous forme de texte, mais les outils de modélisation visuelle peuvent rendre le même flux de travail plus facile à examiner, à affiner et à partager. Visual Paradigm offre des capacités de modélisation UML, accompagnées d’une modélisation assistée par IA et d’un espace de travail VPasCode basé sur du texte. Sa plateforme prend en charge les diagrammes UML standard, notamment les diagrammes de cas d’utilisation, de classes, de séquence, d’activité, de composants, de déploiement, de machines à états, de paquets et d’objets.

Modélisation UML Visual Paradigm

Visual Paradigm peut être utilisé lorsque vous souhaitez construire un diagramme de cas d’utilisation de manière visuelle plutôt que d’écrire toute la syntaxe manuellement. Un flux de travail typique est le suivant :

1. Créez un projet UML.

2. Ajoutez un diagramme de cas d’utilisation.

3. Placez les acteurs et les cas d’utilisation sur la toile.

4. Dessinez la limite du système.

5. Connectez les acteurs aux cas d’utilisation.

6. Ajouter inclure, étendre, et des relations de généralisation.

7. Ajoutez des notes et des contraintes.

8. Organisez et exportez le diagramme terminé.

La modélisation visuelle est particulièrement utile lorsque les parties prenantes doivent examiner le diagramme de manière interactive. Les membres de l’équipe peuvent inspecter les symboles, discuter d’éléments spécifiques et annoter les diagrammes de manière collaborative.

Un diagramme de cas d’utilisation créé manuellement peut contenir :

• Des acteurs tels que Client, Administrateur, et Passerelle de paiement

• Une frontière de système telle que Système d'achat en ligne

• Cas d’utilisation tels que Paiement, Passer une commande, et Suivre une commande

• <<inclure>> relations pour un comportement réutilisable obligatoire

• <<étendre>> relations pour un comportement optionnel

• Relations de généralisation pour des acteurs ou des cas d’utilisation spécialisés

Le modèle visuel doit conserver les mêmes règles sémantiques utilisées dans PlantUML :

Paiement ..> ValiderPaiement : <<inclure>>
AppliquerRemise ..> Paiement : <<étendre>>
ClientPremium -|> Client

La distinction importante est que changer d’outil ne modifie pas le sens UML. Que le diagramme soit créé à la main, généré par une IA ou écrit en PlantUML, la direction de la relation doit rester correcte.

Modélisation assistée par IA

Les capacités d’IA de Visual Paradigm peuvent aider à transformer les exigences en langage naturel en éléments de modèle et en diagrammes. La plateforme décrit ses fonctionnalités d’IA comme capables de transformer les exigences en diagrammes et de générer des artefacts de développement logiciel à partir de descriptions textuelles.

Par exemple, vous pourriez fournir l’exigence suivante :

Créez un diagramme de cas d'utilisation pour un système d'achat en ligne.

Acteurs :
- Client
- Client Premium
- Administrateur
- Passerelle de paiement
- Service d'envoi d'e-mails

Le client peut s'inscrire, se connecter, parcourir les produits, ajouter des produits au panier,
procéder au paiement, suivre les commandes et annuler les commandes.

Le paiement doit inclure la validation du client, le calcul du total, le paiement
et la confirmation de la commande.

L'application d'un coupon de réduction est optionnelle et étend le paiement.
Le client Premium est un type spécialisé de Client.

Un outil assisté par IA peut utiliser cette description pour proposer :

• Définitions des acteurs

• Noms des cas d’utilisation

• Frontières du système

• Associations

• Cas d’utilisation inclus

• Cas d’utilisation étendus

• Généralisation des acteurs

• Notes décrivant les règles métier

L’IA est la plus utile lors du premier passage de modélisation. Elle peut rapidement produire un brouillon à partir des exigences, identifier les acteurs candidats et suggérer des comportements réutilisables. Le modèle résultant doit tout de même être examiné par un développeur, un analyste ou un expert du domaine.

Liste de vérification recommandée pour l’IA

Après avoir généré un diagramme, vérifiez :

• Chaque acteur est externe à la limite du système.

• Chaque cas d’utilisation décrit un objectif utilisateur significatif ou un service système.

• Le comportement réutilisable obligatoire utilise <<inclure>>.

• Le comportement optionnel ou conditionnel utilise <<étendre>>.

• La inclure flèche pointe du cas d’utilisation de base vers le cas d’utilisation inclus.

• La étendre flèche pointe du cas d’utilisation qui étend vers le cas d’utilisation de base.

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

• Les cas d’utilisation dupliqués ou trop détaillés ont été supprimés.

• Les noms sont exprimés de manière cohérente sous forme de phrases verbales.

• Le diagramme communique clairement la portée du système.

VPasCode : modélisation avec du texte

VPasCode propose un espace de travail de texte vers diagramme au sein de l’écosystème Visual Paradigm. La plateforme officielle le décrit comme un éditeur en ligne gratuit de texte vers diagramme et le présente également comme un moyen de transformer du code en diagrammes.

Cela rend VPasCode utile pour les utilisateurs qui préfèrent la précision et la répétabilité du diagramme en tant que code tout en travaillant toujours dans un environnement de modélisation visuelle.

Un diagramme de cas d’utilisation PlantUML peut être écrit comme suit :

@startuml
title Système d'achat en ligne

gauche à droite

acteur Client as client
acteur "Client Premium" as premium
acteur Administrateur as admin
acteur "Passerelle de paiement" as payment
acteur "Service d'envoi d'e-mails" as email

premium -|> client

rectangle "Système d'achat en ligne" {
    casdutilisation "Créer un compte" as Register
    casdutilisation "Se connecter" as Login
    casdutilisation "Parcourir les produits" as Browse
    casdutilisation "Passer la commande" as Checkout
    casdutilisation "Passer une commande" as PlaceOrder
    casdutilisation "Suivre une commande" as TrackOrder
    casdutilisation "Annuler une commande" as CancelOrder

    casdutilisation "Valider les détails du client" as ValidateCustomer
    casdutilisation "Calculer le total de la commande" as CalculateTotal
    casdutilisation "Effectuer un paiement" as MakePayment
    casdutilisation "Envoyer une confirmation de commande" as SendConfirmation

    casdutilisation "Appliquer un coupon de réduction" as ApplyDiscount
    casdutilisation "Demander un remboursement" as RequestRefund

    casdutilisation "Gérer les produits" as ManageProducts
}

client --> Register
client --> Login
client --> Browse
client --> Checkout
client --> TrackOrder
client --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
payment --> MakePayment
email --> SendConfirmation

Checkout ..> ValidateCustomer : <<inclure>>
Checkout ..> CalculateTotal : <<inclure>>
Checkout ..> PlaceOrder : <<inclure>>

PlaceOrder ..> MakePayment : <<inclure>>
PlaceOrder ..> SendConfirmation : <<inclure>>

ApplyDiscount ..> Checkout : <<étendre>>
RequestRefund ..> CancelOrder : <<étendre>>

@enduml

Le même modèle peut être affiné de plusieurs manières :

• Changer la direction de la mise en page avec direction de gauche à droite.

• Ajouter des notes pour expliquer les règles métier.

• Regrouper les cas d’utilisation en paquets.

• Ajouter du style avec skinparam.

• Renommer les alias sans modifier les libellés visibles.

• Garder la source du diagramme sous contrôle de version.

• Régénérer le diagramme chaque fois que le modèle change.

Modélisation visuelle versus diagramme en tant que code

Un flux de travail combiné pratique

Un flux de travail productif consiste à utiliser chaque outil pour la tâche qu’il gère le mieux :

1. Capturez les exigences en langage naturel.
   Décrivez les utilisateurs, les objectifs, la portée du système et les règles métier.

2. Utilisez l’IA pour créer un modèle initial.
   Demandez à l’IA d’identifier les acteurs et les cas d’utilisation, puis de générer une première ébauche.

3. Examinez l’ébauche dans Visual Paradigm UML.
   Vérifiez si le modèle reflète fidèlement le domaine et si le diagramme est facile à comprendre.

4. Exportez ou réécrivez le modèle en PlantUML.
   Utilisez des alias, des noms cohérents et une syntaxe explicite pour les relations.

5. Maintenez la source dans VPasCode ou dans un système de contrôle de version.
   Stockez le .puml fichier avec la documentation du projet ou le code source.

6. Validez la sémantique UML.
   Portez une attention particulière à include, extend, et à la direction de la généralisation.

7. Publiez le diagramme final.
   Exportez-le sous forme d’image ou de document pour les exigences, l’architecture, les revues de conception et la documentation du projet.

Invite pour générer un diagramme de cas d’utilisation PlantUML

L’invite suivante peut être utilisée avec un assistant de modélisation par IA :

Générez un diagramme de cas d'utilisation PlantUML pour un système de commerce en ligne.

Utilisez une disposition de gauche à droite et placez tous les cas d'utilisation du système à l'intérieur d'un
rectangle nommé « Système de commerce en ligne ».

Acteurs :
- Client
- Client Premium
- Administrateur
- Passerelle de paiement
- Service d'envoi d'e-mails

Cas d'utilisation du client :
- Créer un compte
- Se connecter
- Parcourir les produits
- Ajouter un produit au panier
- Passer à la caisse
- Suivre une commande
- Annuler une commande

Passer à la caisse doit inclure :
- Valider les informations du client
- Calculer le total de la commande
- Passer la commande

Passer la commande doit inclure :
- Effectuer le paiement
- Envoyer une confirmation de commande

Comportement optionnel :
- Appliquer un coupon de réduction étend Passer à la caisse
- Demander un remboursement étend Annuler une commande

Le Client Premium est une spécialisation du Client.

Utilisez la syntaxe standard PlantUML et incluez :
- Alias d'acteurs
- Alias de cas d'utilisation
- Limite du système
- Associations d'acteurs
- Relations <<include>>
- Relations <<extend>>
- Généralisation d'acteurs
- Au moins une note explicative

Assurez-vous que les flèches « include » pointent du cas d'utilisation de base vers le cas d'utilisation inclus,
et que les flèches « extend » pointent du cas d'utilisation optionnel vers le cas d'utilisation de base.

Leçon principale

Visual Paradigm UML est parfaitement adapté à la modélisation et à l’examen interactifs ; l’IA peut accélérer la transition des exigences vers un premier brouillon, et VPasCode avec PlantUML offre un flux de travail textuel répétable. Utilisés ensemble, ils prennent en charge l’intégralité du cycle de vie de la modélisation : décrire les exigences, générer un brouillon, valider le modèle UML, affiner la source et publier un diagramme maintenable.

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.