MCD et diagramme de classes UML : les différences

Le MCD de Merise et le diagramme de classes d'UML décrivent tous deux des objets métier et les liens entre eux, mais ils n'ont pas le même but : le MCD modélise les données à stocker dans une base relationnelle, le diagramme de classes modélise les classes d'un programme orienté objet, avec leurs méthodes. Les deux notations se traduisent l'une dans l'autre presque terme à terme, avec un piège : les multiplicités UML se lisent du côté opposé aux cardinalités Merise. Ce chapitre donne les correspondances et la méthode pour passer de l'un à l'autre.

Deux modèles, deux objectifs

Le diagramme de classes est présenté en détail dans le chapitre Diagramme de classes du cours UML. Ce chapitre se concentre sur ce qui le relie au MCD.

Le tableau des correspondances

Cardinalités et multiplicités : l'inversion

C'est la différence à connaître. Reprends la règle « un client passe zéro ou plusieurs commandes ; une commande est passée par un seul client ».

• En Merise, la cardinalité se place du côté de l'entité qu'elle décrit : 0,n près de CLIENT (un client passe 0 à n commandes), 1,1 près de COMMANDE.
• En UML, la multiplicité se place du côté de la classe qu'on compte : * près de Commande (un client a 0 à plusieurs commandes), 1 près de Client (une commande a un client).

Pour traduire sans te tromper, ne déplace pas les nombres : relis la phrase. « Un client passe combien de commandes ? Zéro ou plusieurs » : en Merise, 0,n près de CLIENT ; en UML, * près de Commande. Le minimum et le maximum ne changent pas, seul l'endroit change.

Association porteuse et classe-association

La propriété quantite, portée par l'association CONTENIR dans le MCD, devient en UML une classe-association : une classe LigneCommande reliée par un trait pointillé à l'association entre Commande et Produit. Dans le code, on la transforme souvent en vraie classe, avec deux associations : une commande a plusieurs lignes, chaque ligne concerne un produit.

C'est la même chose qu'au passage au MLD : l'association porteuse plusieurs à plusieurs devient une table ligne_commande en relationnel, une classe LigneCommande en objet.

Héritage et généralisation

L'héritage de Merise/2 et la généralisation d'UML sont la même idée. En UML, la classe mère peut être abstraite (en italique, ou avec {abstract}) : on ne crée jamais d'objet Document, seulement des Livre, des Film ou des Jeu. C'est la traduction objet d'une contrainte de totalité. Côté code, l'héritage entre classes est présenté dans le cours Programmation orientée objet. Les contraintes se notent entre accolades sur l'ensemble de généralisation : {complete, disjoint} pour une partition.

En code, l'héritage est direct (class Livre : Document en C#, class Livre extends Document en PHP). En base, il faut choisir l'une des trois traductions, et les ORM proposent les mêmes : une table par classe, une seule table avec une colonne discriminante, ou une table par classe concrète.

Ce qui n'existe que d'un côté

Seulement en UML : les opérations (+ estEnRetard() : bool), la visibilité (+ public, - privé, # protégé), la navigabilité (une flèche au bout d'une association dit quel objet connaît l'autre), les classes abstraites et les interfaces. Rien de tout cela n'a de sens pour une base de données.

Seulement en Merise : l'identifiant, et toute la rigueur qui va avec (identifiants relatifs, dépendances fonctionnelles, normalisation). En objet, deux objets distincts peuvent avoir les mêmes valeurs ; en base, la clé primaire l'interdit.

Du MCD au code

Voici la classe Exemplaire et la classe Site écrites en C# à partir du MCD de Rivelire. L'association un à plusieurs devient une référence d'un côté (un exemplaire connaît son site) et une collection de l'autre (un site connaît ses exemplaires).

public class Site
{
    public string CodeSite { get; set; } = "";
    public string NomSite { get; set; } = "";
    public List<Exemplaire> Exemplaires { get; } = new();   // 0,n côté SITE
}

public class Exemplaire
{
    public string CodeBarre { get; set; } = "";
    public DateOnly DateAcquisition { get; set; }
    public string Etat { get; set; } = "neuf";
    public Site Site { get; set; } = null!;                 // 1,1 côté EXEMPLAIRE
}

Dans la table, le lien est une seule colonne, la clé étrangère code_site d'exemplaire ; dans le code, il est à double sens. Faire correspondre les deux, c'est le travail d'une couche d'accès aux données (DAO) ou d'un ORM : chapitre Repository, DAO et injection de dépendances du cours Architecture MVC, et cours POO.

Lequel choisir ?

Les deux, chacun à sa place. Pour concevoir une base de données relationnelle, le MCD reste l'outil le plus précis, et celui qu'attendent la plupart des correcteurs français. Pour concevoir le code d'une application, le diagramme de classes s'impose. Dans un projet d'E6 en C# ou en PHP objet, il est courant de présenter un MCD (ou un MLD) pour la base et un diagramme de classes pour le code : la commission vérifie surtout que les deux sont cohérents.

À l'écrit d'E7, le sujet fournit plutôt un schéma relationnel pour les questions de base de données et un diagramme de classes pour les questions de code. Sache lire les deux, et passer de l'un à l'autre sans inverser les cardinalités.

Exercices