Diagrammes de classes UML pour la modélisation de données avec PlantUML

Un diagramme de classes UMLdécrit la structured’un système : les éléments qu’il modélise, leurs propriétés et leurs relations. Pour la modélisation de données, il peut capturer les concepts du domaine et les contraintes avant de vous engager dans des tables ou du code d’application.

PlantUMLrend le diagramme reproductible : vous écrivez du texte, le générez, examinez les modifications dans le contrôle de version et le mettez à jour au fur et à mesure que le modèle évolue. Il complète — et ne remplace pas — les schémas de base de données, les migrations et les règles métier détaillées.

1. Choisissez le niveau de modélisation

Un diagramme de modélisation de données utile se concentre généralement sur un seul niveau à la fois :

• Conceptuel :concepts métier et relations, avec un minimum de détails techniques. Exemple :Clientpasse un Commande.

• Logique :attributs, identifiants, multiplicités et règles, sans lier le modèle à une base de données spécifique.

• Physique :détails d’implémentation tels que les types de colonnes SQL, les index et les contraintes spécifiques à la base de données.

L’exemple ci-dessous est un modèle de domaine logique. Des types comme UUID, Money, et DateTimesont illustratifs ; décidez de leurs représentations concrètes lors du choix d’une technologie.

2. Fondamentaux de PlantUML

Une classe possède un nom et peut énumérer des attributs et des opérations :

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Les marqueurs de visibilité sont des indications de modélisation facultatives :

• + public

• - private

• # protected

• ~ visibilité du paquet

Pour un diagramme de domaine ou de données, les attributs sont les plus importants. Incluez des opérations uniquement lorsqu’elles clarifient un comportement important ; évitez de transformer le diagramme en une liste complète de code.

3. Relations et multiplicité

Les notations de relation les plus utiles pour la modélisation de données sont :

Les étiquettes de multiplicité se situent près des extrémités de l’association :

• 1 — exactement un

• 0..1 — optionnel, au plus un

• * ou 0..* — zéro ou plus

• 1..* — un ou plus

• 2..5 — une plage bornée

Par exemple :

Client "1" -- "0..*" Commande : passe

Lisez attentivement les libellés à chaque extrémité : un client peut passer zéro ou plusieurs commandes ; chaque commande est associée à exactement un client. Les libellés décrivent la relation, et non nécessairement une implémentation de clé étrangère spécifique à une base de données.

4. Exemple détaillé : boutique en ligne

Ce modèle inclut les clients, les commandes, les lignes de commande, les produits et les enregistrements de paiement. Il illustre les identifiants, les types de valeur, une énumération, la composition et les multiplicités.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Client {
  +idClient: UUID
  +email: AdresseEmail
  +nomAffiché: String
}

class Commande {
  +idCommande: UUID
  +dateCommande: DateTime
  +statut: StatutCommande
  +total: Argent
}

class LigneCommande {
  +numéroLigne: Integer
  +quantité: PositiveInteger
  +prixUnitaire: Argent
}

class Produit {
  +idProduit: UUID
  +sku: SKU
  +nom: String
  +prixActuel: Argent
}

class Paiement {
  +idPaiement: UUID
  +montant: Argent
  +statut: StatutPaiement
  +datePaiement: DateTime [0..1]
}

class Argent <<objet de valeur>> {
  +montant: Decimal
  +devise: CodeDevise
}

enum StatutCommande {
  BROUILLON
  PASSÉE
  PAYÉE
  LIVRÉE
  ANNULÉE
}

enum StatutPaiement {
  EN ATTENTE
  AUTORISÉ
  CAPTURÉ
  ÉCHOUÉ
  REMBOURSÉ
}

Client "1" -- "0..*" Commande : passe
Commande "1" *-- "1..*" LigneCommande : contient
LigneCommande "0..*" --> "1" Produit : fait référence à
Commande "1" -- "0..*" Paiement : tentatives de paiement
Commande --> StatutCommande
Paiement --> StatutPaiement
LigneCommande --> Argent : prix unitaire
Paiement --> Argent : montant

note right of LigneCommande
  la quantité doit être supérieure à zéro
  le prixUnitaire est le prix capturé
  au moment de la commande
end note

note right of Produit
  le prixActuel du Produit peut changer.
  Il ne remplace pas le prixUnitaire de la LigneCommande.
end note
@enduml

Pourquoi modéliser LigneCommande explicitement ? La relation entre une commande et un produit possède ses propres données — la quantité et le prix au moment de l’achat. Cela en fait un concept du domaine, et non simplement un lien simple.

Pourquoi une composition de Commande vers LigneCommande? L’exemple suppose qu’une ligne de commande appartient à une seule commande et n’a pas de sens indépendant. Utilisez la composition uniquement lorsque cette règle de propriété et de cycle de vie est vraie dans votre domaine ; la notation UML ne l’impose pas dans la base de données.

Pourquoi distinguer les prix actuels et historiques ? Le prix d’un produit peut changer après qu’une commande a été passée. Conserver le prix au moment de l’achat sur la ligne de commande préserve le montant historique.

5. Décisions de modélisation qui comptent

Identifiants : Marquez les identifiants de manière cohérente, comme idClient ou idCommande. UML ne définit pas une seule notation universelle pour les clés primaires, choisissez donc une convention et documentez-la. Un stéréotype ou une note peut le rendre explicite :

class Client {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Valeurs optionnelles : Utilisez [0..1] pour un attribut optionnel lorsque cela est clair pour vos lecteurs, ou notez la règle. Par exemple, un paiement peut ne pas avoir de paidAt d’horodatage jusqu’à ce qu’il réussisse.

Objets de valeur : Un type tel que Money ou EmailAddress peut représenter un concept avec sa propre validation ou sémantique. Décidez s’il doit apparaître comme une classe séparée, un type d’attribut ou une structure de base de données en fonction du public et du niveau de détail.

Énumérations et valeurs contrôlées : Utilisez une énumération lorsque l’ensemble autorisé est petit et relativement stable. Si les valeurs nécessitent des descriptions indépendantes, un cycle de vie ou une administration, modélisez-les plutôt comme une classe.

Normalisation et implémentation : Un diagramme de classes communique des concepts et des règles ; il ne règle pas tous les détails relationnels. Par exemple, si Money devient deux colonnes, une table séparée ou un type spécifique à la base de données est une décision d’implémentation.

Gardez les diagrammes lisibles : Divisez un grand domaine en diagrammes ciblés — tels que la commande, l’inventaire et l’identité — et utilisez des paquets pour regrouper les classes liées. Affichez uniquement les attributs pertinents par rapport à la question que le diagramme est censé répondre.

6. Construisez un modèle à partir des exigences

1. Extrayez les concepts candidats du langage du domaine : les noms suggèrent souvent des classes ; les verbes suggèrent souvent des relations ou des comportements.

2. Préciser les règles avec des questions concrètes : une commande peut-elle exister sans client ? Peut-elle avoir zéro ligne ? Un paiement peut-il être réessayé ?

3. Choisir un niveau de modélisation et exclure les décisions techniques relatives à la base de données d’un diagramme conceptuel.

4. Ajouter des attributs et des identifiants uniquement lorsqu’ils aident à expliquer le modèle.

5. Définir les multiplicités à partir des règles métier, en vérifiant les deux extrémités de chaque relation.

6. Examiner les cas limites: suppression, enregistrements historiques, champs optionnels, tentatives répétées et valeurs changeantes.

7. Générer et examiner le diagramme avec des experts du domaine et des implémenteurs. Traitez-le comme un modèle à valider, et non simplement comme une image à approuver.

7. Utiliser VPasCode et Visual Paradigm

VPasCode est un éditeur de texte vers diagramme basé sur le navigateur, prenant en charge PlantUML et un aperçu en direct. Sa description des fonctionnalités mentionne également la génération et la modification de code de diagramme par IA, ainsi qu’une assistance syntaxique. Un flux de travail pratique est le suivant :

1. Ouvrez VPasCode et sélectionnez ou saisissez PlantUML.

2. Collez l’exemple ci-dessus et inspectez le diagramme généré.

3. Itérez sur la source PlantUML ; conservez le texte comme artefact versionnable.

4. Utilisez l’assistant IA, s’il est disponible dans votre espace de travail, pour rédiger ou réviser une première version.

5. Vérifiez vous-même chaque classe, relation, multiplicité et règle métier générées.

Les outils de diagrammes assistés par IA de Visual Paradigm peuvent générer des diagrammes modifiables à partir de descriptions en langage naturel. Son flux de travail publié décrit la génération d’un diagramme de classes à partir d’une consigne, puis l’affinement de ses éléments et relations. Traitez la sortie de l’IA comme unbrouillon: il peut inférer une propriété incorrecte, des contraintes manquantes ou des classes injustifiées. La correction du modèle dépend toujours de sa validation par rapport aux exigences.

Par exemple, donnez une consigne à un assistant IA :

Créez un diagramme de classes UML logique pour une boutique en ligne. Les clients passent des commandes. Chaque commande contient une ou plusieurs lignes de commande. Chaque ligne de commande fait référence à un produit et stocke la quantité et le prix unitaire au moment de l’achat. Les commandes peuvent avoir plusieurs tentatives de paiement. Incluez les identifiants, les multiplicités et les énumérations d’état de commande et de paiement. Sortez uniquement du code PlantUML.

Ensuite, examinez la sortie par rapport aux exigences avant de l’accepter. Pour de meilleurs résultats, spécifiez explicitement les hypothèses — par exemple, si les commandes peuvent être des brouillons sans lignes, et si les paiements peuvent être remboursés.

Visual Paradigm décritVPasCode en tant que éditeur compatible PlantUML avec rendu en direct et génération ou modification assistée par IA. Les outils et la disponibilité peuvent varier selon la version du produit ou l’espace de travail.

8. Une liste de vérification de révision compacte

Avant de partager ou d’implémenter un diagramme de classes, vérifiez :

• Chaque classe représente-t-elle un concept de domaine significatif ?

• Les identifiants et les attributs importants sont-ils clairs ?

• Les libellés de relation et les multiplicités sont-ils corrects aux deux extrémités ?

• La composition reflète-t-elle une dépendance réelle du cycle de vie ?

• Les faits historiques sont-ils préservés là où les valeurs actuelles peuvent changer ?

• Les valeurs optionnelles et les contraintes métier sont-elles visibles ?

• Le diagramme est-il suffisamment ciblé pour son public ?

• Le contenu généré a-t-il été vérifié par rapport aux exigences réelles ?

Le meilleur flux de travail diagramme-as-code est l’IA pour un brouillon initial, PlantUML pour des modifications précises et l’historique des versions, et une revue humaine pour la correction du domaine.

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.