Guide de syntaxe des diagrammes de classes PlantUML

Qu’est-ce qu’un diagramme de classes ?

Un UML Diagramme de classes est le plan structurel fondamental de la modélisation orientée objet. Il représente un système logiciel en visualisant ses classes, leurs attributs internes (champs de données), leurs méthodes (fonctions) et les relations structurelles entre elles. Alors que les bases de code peuvent devenir étendues et difficiles à analyser, un diagramme de classes clair fournit aux ingénieurs une référence visuelle immédiate sur la manière dont les objets de code interagissent, héritent des comportements et gèrent les frontières des données.

En utilisant VPasCode, vous pouvez concevoir des mises en page de classes détaillées entièrement en texte brut, laissant la conception du layout, la taille des boîtes et l’espacement des lignes entièrement à nos moteurs cloud intégrés.

Guide de syntaxe fondamentale : éléments et constructions

Pour écrire des diagrammes de classes de haute qualité, vous devez comprendre trois repères structurels fondamentaux : définir le corps de la classe, attribuer des modificateurs de visibilité aux membres, et cartographier les relations entre objets.

1. Déclaration des classes et des membres

Vous déclarez un modèle d’objet standard en utilisant le mot-clé classmot-clé. À l’intérieur des accolades de fin, vous listez vos champs et méthodes sur des lignes séparées :

class CustomerAccount {
    String accountId
    String emailAddress
    Boolean isActive()
}

2. Modificateurs de visibilité (contrôle d’accès)

PlantUML mappe les règles standard d’encapsulation orientée objet (public, privé, protégé et package privé) en utilisant des préfixes de texte simples juste avant le nom du champ ou de la méthode :

• + Accès public clair (accessible par toute autre classe)
• - Accès strictement privé (accessible uniquement au sein de cette classe spécifique)
• # Accès protégé (accessible au sein de cette classe et de ses sous-classes)
• ~ Accès package/interne (accessible uniquement au sein du module de code local)

3. Définition des relations entre objets

Connecter des classes nécessite des notations spécifiques de flèches pour indiquer la dépendance structurelle ou la composition du code de votre application :

• Héritage / Généralisation (Est-Un) : Utilise une flèche en triangle ouvert pointant vers la classe parente : SubClass --|> ClasseParent
• Implémentation / Réalisation : Utilise une ligne pointillée avec un triangle ouvert pour montrer l’exécution d’une interface : ClasseConcrète ..|> IInterface
• Composition (Possession stricte) : Utilise un losange plein pour montrer qu’un objet enfant ne peut exister sans son conteneur parent : Parent *-- Enfant
• Agrégation (Collection partagée) : Utilise un losange ouvert pour montrer une relation de collection temporaire : Département o-- Employé

Meilleures pratiques pour les cartes de classes pratiques

• Séparez les mises en page avec des classes abstraites : Utilisez le mot-clé classe abstraite ou interface pour différencier visuellement les limites structurelles de vos modèles de base de données concrets.
• Marquez les multiplicités dès le départ : Ajoutez toujours des multiplicités numériques (comme "1" ou "0..*") aux deux extrémités de vos flèches de relation pour rendre les contraintes de données explicites pour les développeurs.
• Contrôlez l’espacement vertical : Les diagrammes de classes peuvent devenir extrêmement longs. Si votre mise en page s’étend trop verticalement, remplacez un double trait (--) par un trait simple (-) à l’intérieur de vos flèches de relation pour forcer un alignement horizontal côte à côte.

Exemples de diagrammes de classes PlantUML du monde réel

Exemple 1 : Modèle de domaine E-Commerce (Visibilité et Encapsulation)

Ce plan montre les modificateurs d’accès standards, les objets de données de base et les mappages de multiplicité de données de base entre les entités principales du commerce en ligne.

@startuml
class Utilisateur {
    - String userId
    - String hachageSecret
    + Boolean verifierConnexion(String input)
}

class Commande {
    + String commandeId
    + Date timestamp
    - Double calculerTotal()
}

Utilisateur "1" --> "0..*" Commande : "place et possède"
@enduml

Analyse de la syntaxe : Le - préfixe maintient les champs sensibles comme les identifiants strictement privés à l’intérieur du Utilisateur bloc de classe, tandis que les fonctions d’accès public utilisent le + marqueur. La chaîne de connexion met explicitement en évidence qu’un utilisateur peut rechercher zéro ou plusieurs commandes de manière transparente.

Exemple 2 : Passerelle de paiement avancée (Héritage et Interfaces)

Cette carte complète du génie logiciel montre comment organiser les interfaces, les boucles d’héritage de classes et les compositions complexes dans un cadre unifié.

@startuml
interface IPaymentProcessor {
    + Boolean autoriserMontant(Double montant)
    + void capturerFonds()
}

classe abstraite BaseGateway {
    # String clefApiMarchand
    # String urlPointDeFin
    + void journaliserTransaction(String charge)
}

class StripeGateway {
    - String jetonStripe
    + Boolean autoriserMontant(Double montant)
    + void capturerFonds()
}

class PayPalGateway {
    - String courrielPayPal
    + Boolean autoriserMontant(Double montant)
    + void capturerFonds()
}

class PanierAchats {
    - Liste elements
    + void passerCommande(IPaymentProcessor moteur)
}

' Déclarations de relations structurelles
BaseGateway ..|> IPaymentProcessor
StripeGateway --|> BaseGateway
PayPalGateway --|> BaseGateway
PanierAchats *-- IPaymentProcessor
@enduml

Analyse de la syntaxe : Le ..|> notation établit que la classe abstraite implémente notre interface racine principale. Les lignes triangulaires pleines (--|>) dirigent proprement les passerelles enfants vers leur classe parente de base, tandis que le losange plein (*--) déclare qu’une Panier d'achat possède fondamentalement son processeur de moteur de paiement pendant le cycle de vie d’une session.