Modélisation UML

Les besoins recueillis au chapitre 4 sont écrits en français — clairs, mais difficiles à structurer et à partager. UML (Unified Modeling Language) offre un langage graphique normalisé pour représenter un logiciel : des diagrammes qui se dessinent au tableau, se montrent au client, et font le pont vers le code.

UML compte treize types de diagrammes. Ce chapitre en présente trois, et pas un de plus — c'est un parti pris assumé. En L1, trois diagrammes maîtrisés valent mieux que neuf survolés : vous n'avez pas encore assez de code derrière vous pour que le reste ait du sens. Le principe directeur : UML sert à clarifier ; dès qu'un diagramme complique au lieu d'aider, on l'abandonne.

Le diagramme de cas d'utilisation

C'est le diagramme le plus utile en amont, et le plus proche des besoins. Il répond à une seule question : qui fait quoi avec le système ?

Deux ingrédients :

• les acteurs : les rôles qui interagissent avec le système, dessinés en bonshommes-bâtons autour de la boîte du système. Un acteur est un rôle, pas une personne — « l'abonné », « le bibliothécaire ». Et il n'est pas forcément humain : une horloge qui déclenche un traitement nocturne, un autre logiciel qui appelle le vôtre, sont des acteurs à part entière.
• les cas d'utilisation : les services que le système rend, dessinés en bulles à l'intérieur de la boîte — un verbe et son objet : « emprunter un livre », « ajouter un ouvrage ». Chaque bulle est reliée aux acteurs qui l'emploient.

1        ┌─────────── Bibliothèque ───────────┐2        │   ( rechercher un livre )           │3  Abonné│   ( emprunter un livre )            │4  ──────┤   ( réserver un livre )             │5        │   ( enregistrer un retour )─────────┤ Bibliothécaire6        │   ( envoyer un rappel )─────────────┤ Horloge7        └─────────────────────────────────────┘

Voici ce même diagramme, interactif : déplacez les acteurs et les cas d'utilisation pour le réorganiser, servez-vous des commandes de zoom, et repérez l'acteur non humain — l'horloge — relié au rappel nocturne.

Ce diagramme se tire directement des besoins fonctionnels et des acteurs du chapitre 4. Sa force : il tient sur une page, se montre au client pour valider le périmètre (« ai-je oublié un service ? »), et découpe le travail de l'équipe — un cas d'utilisation correspond grosso modo à une fonctionnalité à développer et à tester. L'exercice vous fait en construire un à partir d'une description.

Le diagramme de classes, en première approche

Le diagramme de classes décrit les objets du domaine que le logiciel manipule, et fait le pont vers le code (surtout en programmation orientée objet). Chaque classe est une boîte à trois compartiments :

1┌─────────────────┐2│      Livre      │   ← nom3├─────────────────┤4│ titre           │   ← attributs (les données)5│ auteur          │6│ disponible      │7├─────────────────┤8│ emprunter()     │   ← méthodes (les opérations)9│ rendre()        │10└─────────────────┘

Les classes sont reliées par des associations qui traduisent les liens du domaine : un Abonné « emprunte » des Livre. On annote ces liens de multiplicités — « un abonné peut emprunter 0 à 5 livres », « un livre est emprunté par 0 ou 1 abonné » — qui capturent des règles métier directement dans le modèle.

En première approche, on s'en tient là : identifier les bonnes classes (les noms importants du domaine : Livre, Abonné, Emprunt), leurs attributs essentiels, et les associations principales. Le passage vers le code est alors presque mécanique — chaque classe du diagramme devient une classe du programme.

Le diagramme de séquence, simple

Le diagramme de séquence montre, pour un scénario précis, l'ordre des échanges entre les participants au fil du temps. Chaque participant a une ligne de vie verticale ; les messages sont des flèches horizontales, lues de haut en bas.

1 Abonné        Système        Catalogue2   │  emprunter()  │              │3   │──────────────▶│ disponible ? │4   │               │─────────────▶│5   │               │◀──── oui ────│6   │◀── confirmé ──│              │

Il répond à « comment ça se passe, étape par étape » pour un cas d'utilisation donné — par exemple l'emprunt d'un livre disponible. Il est précieux pour comprendre une interaction avant de la coder, et pour repérer les cas où ça se passe mal (le livre n'est pas disponible : que renvoie le système ?). On en fait un par scénario important, pas pour tout.

Du modèle vers le code

Ces trois diagrammes ne sont pas une fin : ce sont des outils de réflexion et de communication qui mènent au code.

• le cas d'utilisation fixe le périmètre — ce qu'il faut développer, et donc tester ;
• le diagramme de classes donne la structure — les classes à écrire, leurs attributs et méthodes ;
• le diagramme de séquence clarifie le comportement — l'enchaînement des appels dans un scénario.

Le danger, en L1, est de tomber amoureux du dessin et de passer plus de temps à modéliser qu'à construire. La règle de bon sens : un diagramme qu'on ne regardera plus après l'avoir dessiné ne valait pas la peine d'être dessiné. On modélise ce qui aide à décider ou à communiquer, et on code le reste. Pour votre projet, un diagramme de cas d'utilisation, un diagramme de classes et un ou deux diagrammes de séquence suffisent amplement.

À vous

L'exercice construit le diagramme le plus utile en amont : le diagramme de cas d'utilisation. À partir d'une description du logiciel de bibliothèque, vous identifiez les acteurs (qui) et les cas d'utilisation (quoi) — sans oublier l'acteur non humain, l'horloge qui déclenche le rappel nocturne.

C'est exactement le diagramme que vous dessinerez pour votre projet, juste après le cahier des charges : il en validera le périmètre et découpera le travail de l'équipe.

// Une description du logiciel de bibliothèque, telle que le client la donne.
// Un ACTEUR est un rôle qui interagit avec le système (souvent un SUJET :
// « l'abonné », « le bibliothécaire »). Un CAS D'UTILISATION est un service
// rendu à un acteur (souvent un VERBE + objet : « emprunter un livre »).
const description =
  "L'abonné peut rechercher un livre et l'emprunter. Il peut aussi réserver " +
  "un livre déjà emprunté. Le bibliothécaire enregistre les retours et ajoute " +
  "de nouveaux ouvrages au catalogue. Chaque nuit, le système envoie " +
  "automatiquement un rappel aux abonnés en retard.";

// ── À VOUS : identifier acteurs et cas d'utilisation ────────────────────────
// (1) Lister les acteurs (les rôles/sujets qui agissent).
const acteurs = [
  // "abonné", ...
];
// (2) Lister les cas d'utilisation (les services, verbe + objet).
const casUtilisation = [
  // "rechercher un livre", ...
];

// ── Vérification ────────────────────────────────────────────────────────────
console.log("Acteurs identifiés :", acteurs.join(", "));
console.log("Cas d'utilisation :");
casUtilisation.forEach((c) => console.log("   - " + c));
console.log("");
console.log("Attendu ~ 3 acteurs (abonné, bibliothécaire, système/horloge)");
console.log("et ~ 6 cas d'utilisation.");

Ce que la suite en fait

Le bloc III est complet : vous savez recueillir des besoins, les écrire sans ambiguïté, et les structurer en trois diagrammes utiles. Le quoi est fixé. Le bloc IV attaque le comment : la qualité du code lui-même.

Le chapitre 6 apprend à écrire un code lisible — car un logiciel se lit dix fois plus qu'il ne s'écrit — et le chapitre 7, à le concevoir pour qu'il résiste au changement. Le diagramme de classes que vous venez de voir y trouvera un prolongement naturel : bien découper en classes, c'est déjà de la conception.

À retenir