Modélisation UML

Sept chapitres ont construit un vocabulaire : classe, attribut, visibilité, héritage, interface, composition. Il manque un moyen de montrer tout cela sans faire lire le code.

C'est ce que fait un diagramme de classes. Un programme de dix classes se lit en une minute sur un schéma, contre une heure dans les fichiers — et surtout, il se discute : c'est l'artefact qu'on met au tableau quand trois personnes doivent se mettre d'accord avant d'écrire.

UML compte quatorze types de diagrammes. Ce chapitre n'en traite qu'un, celui de classes, parce qu'il est le seul qu'on emploie vraiment en L2 — et parce qu'il est en correspondance directe avec le code.

La classe

1┌─────────────────────────────┐2│          Livre              │   ← nom (en italique si abstraite)3├─────────────────────────────┤4│ - titre : String            │   ← attributs5│ - disponible : boolean      │6│ + NB_MAX : int              │   ← souligné si static7├─────────────────────────────┤8│ + emprunter(qui : String)   │   ← méthodes9│   : boolean                 │10│ + estDisponible() : boolean │11│ - verifier() : void         │12└─────────────────────────────┘

Trois compartiments : le nom, les attributs, les méthodes. Les deux derniers peuvent être omis quand ils n'apportent rien au propos — un diagramme n'est pas une transcription.

Les symboles de visibilité reprennent exactement le chapitre 3 :

Deux conventions typographiques valent d'être connues, car elles se lisent d'un coup d'œil : souligné signifie static, italique signifie abstrait — pour une classe comme pour une méthode.

Les relations

C'est le cœur du chapitre, et chaque trait a un sens précis.

1Livre ──────────▷ Document          héritage       (triangle creux, trait plein)2Livre ┄┄┄┄┄┄┄┄┄▷ Empruntable        réalisation    (triangle creux, pointillés)3Commande ◇────── Article            agrégation     (losange creux)4Maison  ◆────── Piece               composition    (losange plein)5Etudiant ─────── Cours              association    (trait simple)6Facture ┄┄┄┄┄┄> Calculatrice        dépendance     (flèche pointillée)

L'héritage — triangle creux, trait plein, pointé vers le parent — traduit extends. C'est le « est-un » du chapitre 5, avec le même critère de substituabilité.

La réalisation — même triangle, mais en pointillés — traduit implements. La distinction visuelle est délibérée : hériter et implémenter ne sont pas la même chose.

L'association est un simple trait : deux classes se connaissent. En pratique, cela devient un attribut d'un côté ou des deux.

L'agrégation et la composition sont deux associations particulières, et leur différence est la seule subtilité du chapitre. Toutes deux expriment « a-un » ; ce qui les sépare est la durée de vie.

Dans une agrégation (losange creux), la partie survit au tout. Une Commande agrège des Article : supprimer la commande ne supprime pas les articles, qui existaient avant et continueront après.

Dans une composition (losange plein), la partie meurt avec le tout, et n'appartient qu'à lui. Une Maison compose ses Piece : détruire la maison détruit les pièces, et une pièce n'appartient pas à deux maisons.

Le test pratique : « si je supprime le tout, la partie a-t-elle encore un sens ? » Oui, agrégation ; non, composition.

Enfin la dépendance — flèche pointillée — signale un usage passager : une classe reçoit l'autre en paramètre ou l'emploie localement, sans la stocker.

Multiplicités

Un chiffre à chaque extrémité dit combien d'objets participent.

1Bibliotheque  1 ◆────── 0..*  Livre2Livre         *  ─────── 0..1  Lecteur

Les multiplicités sont la partie la plus utile du diagramme, et la plus souvent oubliée. Elles répondent à des questions que le code ne pose pas explicitement : un livre peut-il être emprunté par deux lecteurs à la fois ? un lecteur sans emprunt est-il légal ? Un 0..1 du côté Lecteur répond « non » et « oui », et impose une décision qu'on aurait sinon prise par accident.

Voici ces relations réunies dans un diagramme interactif. Chaque trait porte son symbole UML — triangle d'héritage, losange de composition ou d'agrégation — et ses multiplicités ; déplacez les classes pour démêler les liens, et retrouvez la composition Bibliotheque ◆ Livre, l'héritage Livre ▷ Document et la réalisation de l'interface Empruntable.

Du diagramme au code

La traduction est presque mécanique, et c'est ce qui rend le diagramme utile plutôt que décoratif.

Les deux dernières lignes méritent qu'on s'y arrête, car elles transforment une nuance sémantique en différence de code visible :

1class Maison {                          /* COMPOSITION */2    private final List<Piece> pieces = new ArrayList<>();3    public Maison(int nb) {4        for (int i = 0; i < nb; i++) pieces.add(new Piece());   /* elle les crée */5    }6}7 8class Commande {                        /* AGRÉGATION */9    private final List<Article> articles;10    public Commande(List<Article> articles) {11        this.articles = articles;       /* elle les reçoit */12    }13}

Le chemin inverse compte autant : savoir lire du code existant et en tirer un diagramme est ce qu'on fait le premier jour sur un projet qu'on n'a pas écrit. C'est aussi ce que font les outils de rétro-ingénierie des ateliers de développement.

Ce qu'un diagramme ne dit pas, et ce qu'il ne faut pas en faire

Trois limites, pour ne pas prendre le dessin pour le programme.

Il ne dit rien du comportement. L'ordre des appels, les conditions, les boucles n'y figurent pas — c'est le rôle d'autres diagrammes UML, hors programme, comme celui de séquence.

Il vieillit. Un diagramme qui n'est pas maintenu devient un mensonge, plus nuisible qu'une absence de documentation. D'où deux usages viables : le dessin jetable au tableau avant de coder, et le diagramme régénéré depuis le code.

Il ne doit pas tout montrer. Un diagramme de quarante classes avec tous les getters est illisible et n'aide personne. On dessine ce qui répond à la question du moment : les relations principales, sans les accesseurs, sans les classes utilitaires.

Le modéliser-avant-tout des années 1990 a d'ailleurs largement été abandonné. Ce qui reste, et qui est ce qu'on enseigne ici : un croquis de cinq à dix classes, fait avant d'écrire, pour se mettre d'accord.

À vous

L'exercice fait les deux trajets, et c'est le second qui est formateur.

Du diagramme au code : on vous donne un diagramme décrit sous forme de données — classes, attributs, relations, multiplicités — et vous écrivez le générateur qui en produit les squelettes Java. Il devra traduire correctement 1, 0..1 et *, et distinguer agrégation et composition par la façon dont les parties arrivent.

Du code au diagramme : on vous donne des classes, et vous en extrayez les relations. Un cas est ambigu — un attribut de type List peut être une agrégation ou une composition — et c'est en regardant qui crée les objets que vous trancherez.

Un dernier contrôle vérifie les multiplicités sur des données : un livre à deux emprunteurs simultanés doit être signalé comme violant le diagramme.

// ── Un diagramme, décrit sous forme de données ────────────────────────────
const DIAGRAMME = {
  classes: [
    { nom: "Document", abstraite: true,
      attributs: [{ v: "-", nom: "titre", type: "String" }],
      methodes:  [{ v: "+", nom: "decrire", type: "String", abstraite: true }] },
    { nom: "Livre", herite: "Document", implemente: ["Empruntable"],
      attributs: [{ v: "-", nom: "isbn", type: "long" },
                  { v: "+", nom: "NB_MAX", type: "int", statique: true }],
      methodes:  [{ v: "+", nom: "decrire", type: "String" }] },
    { nom: "Bibliotheque",
      attributs: [{ v: "-", nom: "nom", type: "String" }],
      methodes:  [] },
    { nom: "Lecteur", attributs: [{ v: "-", nom: "nom", type: "String" }], methodes: [] },
  ],
  relations: [
    { de: "Bibliotheque", vers: "Livre", type: "composition", multiplicite: "*" },
    { de: "Lecteur", vers: "Livre", type: "agregation", multiplicite: "*" },
    { de: "Livre", vers: "Lecteur", type: "association", multiplicite: "0..1" },
  ],
};

// ── 1. Du diagramme au code ───────────────────────────────────────────────
function versJava(d) {
  const lignes = [];
  for (const c of d.classes) {
    let entete = (c.abstraite ? "abstract " : "") + "class " + c.nom;
    if (c.herite) entete += " extends " + c.herite;
    if (c.implemente) entete += " implements " + c.implemente.join(", ");
    lignes.push("public " + entete + " {");

    const VISIBILITE = { "-": "private", "+": "public", "#": "protected", "~": "" };
    for (const a of c.attributs) {
      lignes.push("    " + [VISIBILITE[a.v], a.statique ? "static final" : "", a.type, a.nom]
        .filter(Boolean).join(" ") + ";");
    }
    // ← à écrire : traduire les relations dont cette classe est l'origine.
    //   « 1 » et « 0..1 » donnent un attribut simple, « * » donne une List.
    lignes.push("}");
    lignes.push("");
  }
  return lignes.join("\n");
}

// ── 2. Du code au diagramme ───────────────────────────────────────────────
const SOURCES = {
  Panier: [
    "class Panier {",
    "  private List<Article> articles;",
    "  Panier(List<Article> articles) { this.articles = articles; }",   // reçus
    "}",
  ],
  Maison: [
    "class Maison {",
    "  private List<Piece> pieces = new ArrayList<>();",
    "  Maison(int n) { for (int i=0;i<n;i++) pieces.add(new Piece()); }", // créées
    "}",
  ],
};

function versDiagramme(nom, source) {
  const texte = source.join("\n");
  const champ = /private List<(\w+)>/.exec(texte);
  if (!champ) return { de: nom, type: "aucune relation détectée" };
  // ← à écrire : agrégation ou composition ? Regardez QUI CRÉE les objets.
  return { de: nom, vers: champ[1], type: "à déterminer", multiplicite: "*" };
}

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Complétez versJava pour les trois multiplicités.
// 2. Complétez versDiagramme : le critère est « qui crée les objets ».
// 3. Écrivez un contrôle de multiplicité : un livre emprunté par deux
//    lecteurs simultanément viole le 0..1 du diagramme.

console.log(versJava(DIAGRAMME));

En travaux pratiques

Ce que la suite en fait

Le bloc V met tout en œuvre. Le chapitre 9 donne les collections qui matérialisent les multiplicités * — List, Map, Set — et l'on verra que le choix entre elles est lui-même une décision de modélisation : un Set interdit les doublons, une Map impose une clé unique.

Le chapitre 10 partira d'un énoncé en français pour arriver à un diagramme, puis au code. La notation de ce chapitre y sera l'outil de travail, et non plus le sujet.

À retenir