Guide de syntaxe des diagrammes d’état PlantUML

Qu’est-ce qu’un diagramme d’état ?

Un diagramme d’état (souvent appelé machine à états ou diagramme d’état) est un diagramme comportemental diagramme UML qui modélise le cycle de vie d’un objet système unique, d’une entité métier ou d’un processus en cours d’exécution. En tant que composant fondamental de la spécification du langage de modélisation unifié (UML), ce type spécifique type de diagramme UML illustre les différents états qu’un objet peut occuper, depuis son instanciation initiale jusqu’à sa destruction finale, ainsi que les événements ou conditions spécifiques qui déclenchent un changement d’un état à un autre.

Que vous soyez en train de documenter les drapeaux de connexion complexes d’une connexion WebSocket, les étapes de traitement des commandes d’un modèle de paiement e-commerce, ou le comportement d’un système matériel autonome, une machine à états UML fournit aux développeurs logiciels et aux architectes logiciels une maquette claire et sans ambiguïté de la logique réactive complexe. Avec VPasCode, vous pouvez instantanément écrire des transitions d’état complexes sans vous battre contre l’alignement des grilles ou les flèches de bordure superposées.

Guide de syntaxe fondamentale : éléments et constructions

Pour écrire des mises en page de diagrammes d’état de haute qualité conformes aux normes, vous devez comprendre les points de départ et d’arrivée, les définitions d’états, les transitions d’événements, les états composites imbriqués et les points de choix conditionnels.

1. États initial et final

Chaque machine à états doit avoir un point d’entrée et, de manière optionnelle, un point terminal. Dans la syntaxe PlantUML, ces éléments limites sont représentés par un symbole d’astérisque propre entourant un élément :

• [*] --> NomÉtat (Définit l’état de départ initial)
• NomÉtat --> [*] (Définit l’état final terminal)

2. Définition des états et des transitions d’événements

Les états sont déclarés automatiquement chaque fois qu’ils sont reliés par une flèche directionnelle (-->). Pour ajouter du contexte à une transition, ajoutez deux points (:) suivis par l’événement spécifique, le déclencheur d’API ou l’appel de méthode qui provoque le changement d’état :

[*] --> Déconnecté
Déconnecté --> Connexion : "connect()"
Connexion --> Connecté : "auth_success"

3. États composites / imbriqués

Les applications complexes présentent souvent des états individuels qui contiennent leurs propres sous-états imbriqués. Vous pouvez implémenter ces structures composites en utilisant le mot-clé étatsuivi d’une accolade ouvrante :

état ActiveWorkspace {
    [*] --> Idle
    Idle --> Saisie : "touche appuyée"
    Saisie --> Idle : "délai dépassé"
}

4. Points de choix (branchement conditionnel)

Lorsqu’un événement se produit, le système doit souvent évaluer des indicateurs de données internes avant de déterminer la destination de l’état suivant. Pour dessiner un losange de choix standard UML, utilisez le jeton de stéréotype <<choix>> de stéréotype :

état vérifier_paiement <<choix>>
CommandePassée --> vérifier_paiement : "process()"
vérifier_paiement --> Payé : [solde >= total]
vérifier_paiement --> Échec : [solde < total]

Meilleures pratiques pour des états clairs

• Utilisez les descriptions d’états : Vous pouvez ajouter des détails opérationnels clairs, des fonctions d’entrée ou des fonctions de sortie directement dans un nœud d’état en utilisant un wrapper deux-points en ligne (par exemple, NomÉtat : entrée / logTimestamp()).
• Gardez les noms d’état courts : Utilisez CamelCase ou snake_case pour vos codes de variables d’état internes (par exemple, TraitementPaiement), et utilisez des guillemets si vous devez attacher une étiquette longue et lisible à ces noms.
• Gérez les directions de routage vectoriel : Si vos cartes de cycle de vie multi-niveaux deviennent encombrées verticalement, insérez des règles spatiales en ligne dans les flèches de connexion (par exemple, -droite-> ou -bas->) pour équilibrer la densité du layout.

Exemples de diagrammes d’état PlantUML du monde réel

Exemple 1 : Cycle de vie du réseau d’un périphérique IoT (états composites et choix)

Ce squelette suit les boucles d’état comportementales de connexion d’un module capteur IoT, illustrant des blocs imbriqués complexes et des broches de choix d’évaluation conditionnelle.

@startuml
[*] --> Hors ligne

Hors ligne --> Connexion : "alimentation_on"

état Connexion {
    [*] --> Initialisation
    Initialisation --> RésolutionDNS : "matériel_prêt"
    RésolutionDNS --> EnvoiSéquence : "ip_acquise"
}

état verification_authentification <<choice>>
Connexion --> verification_authentification : "reception_defi_serveur"

verification_authentification --> En ligne : [jeton_valide]
verification_authentification --> Hors ligne : [jeton_expiré] : "clignotement_led_rouge"

état En ligne {
    [*] --> Inactif
    Inactif --> TransmissionDonnées : "déclenchement_timer"
    TransmissionDonnées --> Inactif : "ack_reçu"
    Inactif --> ÉconomieÉnergie : "batterie_faible_détectée"
}

En ligne --> Hors ligne : "perte_connexion"
@enduml

Analyse syntaxique : Cette carte sépare clairement les boucles opérationnelles individuelles. Lorsque le matériel passe à l’état composite Connexion enveloppe, il suit les sous-états localisés comme la résolution DNS avant d’atteindre le verification_authentification diamant de choix. Les crochets ([jeton_valide]) représentent des conditions de garde standard UML.

Exemple 2 : Machine à états de traitement des commandes e-commerce (sous-états concurrents)

Ce plan d’entreprise avancé modélise un système de commandes multithreadé montrant des comportements orthogonaux concurrents (traitement simultané des colis d’expédition et des enregistrements de facturation) en utilisant des lignes de séparation (--).

@startuml
[*] --> Panier

Panier --> CommandeSoumise : "clic_paiement"
CommandeSoumise --> TraitementPaiement : "autorisation_fonds"

état TraitementPaiement {
    [*] --> ContactBanque
    ContactBanque --> PaiementEffectué : "capture_reussie"
}

TraitementPaiement --> CommandeConfirmée : "paiement_validé"

état CommandeConfirmée {
    [*] --> GestionLogistique
    état GestionLogistique {
        [*] --> PrélèvementArticles
        PrélèvementArticles --> EmballageBoîte : "inventaire_sécurisé"
        EmballageBoîte --> EnLivraison : "étiquette_imprimée"
    }
    --
    [*] --> EnregistrementsFacturation
    état EnregistrementsFacturation {
        [*] --> GénérationFacture
        GénérationFacture --> FactureEnvoyée : "pdf_généré"
    }
}

CommandeConfirmée --> CommandeArchivée : "livraison_confirmée"
CommandeArchivée --> [*]
@enduml

Analyse syntaxique : À l’intérieur de la structure composite CommandeConfirmée composite, le délimiteur de double tiret (--) agit comme un séparateur orthogonal. Cela indique à PlantUML de diviser le diagramme en deux états concurrents qui s’exécutent en parallèle : la chaîne logistique physique à gauche, et les mises à jour de facturation d’entreprise à droite.