Guide de syntaxe des diagrammes d’objets PlantUML

Qu’est-ce qu’un diagramme d’objets ?

Un diagramme d’objets est un diagramme structurel diagramme UML qui agit comme une capture instantanée concrète et en temps réel de l’état de votre application. Alors qu’un diagramme de classes décrit les plans abstraits, les types de données et les règles structurelles d’un système, un diagramme d’objets visualise une instance d’exécution active à un moment donné. Il modélise l’instanciation d’objets réels, affiche les valeurs exactes attribuées à leurs champs et met en évidence les liens spécifiques existant entre ces instances pendant l’exécution.

Ce type particulier de type de diagramme UML est extrêmement utile pour le débogage des structures de données complexes, pour expliquer des états de relations hautement imbriqués (tels que des graphes arborescents parent-enfant), ou pour vérifier qu’un patron de conception ingénierie se comporte comme prévu dans des cas limites spécifiques. Avec VPasCode, vous pouvez définir proprement des relations d’objets en temps réel, en évitant complètement les outils manuels de dessin de boîtes.

Guide de syntaxe principale : éléments et constructions

Pour concevoir un diagramme d’objets UML précis et conforme aux normes dans PlantUML, vous devez comprendre les instanciations d’objets, les affectations de valeurs de champs et les mappages des liens entre instances.

1. Instanciation des objets (nom contre types de classes)

Les objets sont déclarés en utilisant le mot-clé objectmot-clé. Selon les conventions standard de modélisation UML, vous définissez un objet en fournissant son nom d’instance unique, suivi d’un deux-points, puis de son type de plan de classe parent :

object "currentUser : Account" as activeUser

Astuce pro : Utilisez toujours le mot-clé as pour mapper une déclaration de nom d’instance longue à un identifiant interne court et abrégé (comme activeUser) afin de dessiner rapidement et proprement les lignes de liaison.

2. Affectation des états de champs et des valeurs en temps d’exécution

Pour remplir vos objets avec des valeurs de données de test, ouvrez un bloc de corps en utilisant des accolades en fin de ligne et écrivez vos affectations clé-valeur sur des lignes distinctes. Contrairement aux définitions de classes, n’ajoutez pas ici les types de données — utilisez des valeurs opérationnelles réelles :

objet "adminCart : ShoppingCart" comme cart1 {
    cartId = "CART-9081"
    nombreArticles = 3
    estExemptTaxe = false
}

3. Mappage des liaisons d’instances

Les connexions entre des instances concrètes dans un diagramme d’objets représentent des pointeurs de mémoire du monde réel plutôt que des modèles structurels abstraits. Vous mappez ces liens en utilisant des traits doubles pleins (“--). Vous pouvez également ajouter des étiquettes de chaîne de caractères pour indiquer le contexte fonctionnel de la liaison :

activeUser -- cart1 : "possède et modifie"

Meilleures pratiques pour les cartes d’objets pratiques

• Concentrez-vous sur ce qui compte : Ne listez pas chaque champ d’une définition de classe. Incluez uniquement les valeurs de variables clés qui expliquent directement l’état d’exécution spécifique ou le bug que vous essayez de démontrer.
• Gardez les liens neutres : Évitez d’utiliser des triangles d’héritage ou des losanges de composition stricte dans un diagramme d’objets. Utilisez des lignes de relation simples et plates (--) ou des pointes de flèche basiques (-->) pour montrer les références.
• Alignez les itérations horizontalement : Si vous mappez une liste de tableaux ou une séquence d’objets historiques, utilisez des flèches de navigation horizontales telles que -droite-> pour forcer les instances à s’afficher proprement sur une seule ligne.

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

Exemple 1 : État de session du jeton d’identité (mappages de valeurs concrètes)

Ce squelette mappe un état d’autorisation de sécurité en cours, démontrant comment un utilisateur authentifié unique établit des liens vers plusieurs instances de session machine actives spécifiques, chacune ayant des variables de données distinctes.

@startuml
objet "targetUser : UserAccount" comme user {
    userId = 1042
    username = "dev_admin"
    status = "ACTIVE"
}

objet "sessionMobile : UserSession" comme session1 {
    sessionId = "SESS-AAA-99"
    deviceOS = "iOS 17"
    adresseIP = "192.168.1.54"
}

objet "sessionDesktop : UserSession" comme session2 {
    sessionId = "SESS-BBB-11"
    deviceOS = "macOS 14"
    adresseIP = "72.44.12.102"
}

' Établir les liens d'exécution
user -- session1 : "authentifié sur"
user -- session2 : "authentifié sur"
@enduml

Analyse syntaxique : Ce schéma capture un scénario définitif dans le code de production : un enregistrement utilisateur spécifique (ID 1042) qui active deux instances de session d’exécution complètement distinctes simultanément. Chaque conteneur de session suit ses propres paramètres de mise en page de métadonnées isolés.

Exemple 2 : État de livraison de facture e-commerce (Cartes multi-entités)

Ce plan système avancé cartographie un graphe de transaction financière terminée. Il indique précisément comment les enregistrements de commande, les journaux de transaction et les colis entreposés sont liés entre eux à un moment précis.

@startuml
objet "buyerProfile : Customer" comme customer {
    email = "[email protected]"
    niveau = "VIP"
}

objet "activeOrder : Order" comme order {
    orderNumber = "#99122"
    totalPartiel = 149.99
    devise = "USD"
}

objet "stripeTransaction : LedgerEntry" comme ledger {
    referenceId = "ch_3Mv8x"
    gatewayStatus = "SUCCESS"
    régléLe = "2026-05-26"
}

objet "packageA : Shipment" comme ship1 {
    trackingCode = "1Z999AA1"
    transporteur = "UPS"
    poidsKg = 1.4
}

objet "packageB : Shipment" comme ship2 {
    trackingCode = "1Z999AA2"
    transporteur = "UPS"
    poidsKg = 0.8
}

' Liens d'exécution structurels
customer -- order : "soumis"
order -- ledger : "financé par"
order -- ship1 : "exécuté via"
order -- ship2 : "exécuté via"
@enduml

Analyse syntaxique : Ce modèle fournit une vue hautement structurée d’un état système complexe. Il montre une seule commande liée à un journal de transaction de paiement réussie, divisée en deux fichiers d’expédition physiques distincts. Ce niveau de détail en fait un excellent plan directeur pour l’audit des structures de données et des processus système.