Quand on imagine un logiciel, on pense tout de suite au code. Pourtant, avant d'ouvrir leur éditeur, les
développeurs passent souvent par une étape de modélisation. Il s'agit de représenter, sur un schéma, quelles
données le logiciel manipulera et comment ses différentes parties interagiront.
C'est le plan de l'architecte avant la première pierre. Personne ne coule des fondations en espérant que la
cuisine tombera au bon endroit.
Le MCD, modèle conceptuel de données
Le MCD représente les données importantes du système et les liens entre elles, sans le moindre détail technique.
On y trouve des entités, leurs attributs, et les relations qui les unissent.
Il vient de la méthode Merise, née en France dans les années 1970, encore largement enseignée ici alors qu'elle
est quasiment inconnue ailleurs. Ne sois pas surpris si un collègue étranger ne voit pas de quoi tu parles.
Exemple :
Pour une bibliothèque, on identifie trois entités, Livre, Auteur et Lecteur. Un auteur écrit plusieurs livres, un lecteur peut en emprunter plusieurs. Chaque entité porte ses attributs, un livre a un titre, une année de publication et un ISBN. À partir de ce schéma, la structure de la base de données se déduit presque mécaniquement.
L'intérêt du MCD est moins technique qu'humain. Il oblige à trancher des questions qu'on aurait sinon découvertes trop tard. Un exemplaire abîmé, c'est le même livre ou un autre ? Un livre écrit à quatre mains, on le range comment ? Ce sont exactement les questions de vocabulaire commun dont parle le chapitre sur le Domain Driven Design.
Le diagramme de classes (UML)
UML (Unified Modeling Language) est une notation standardisée dans les années 1990 pour décrire un logiciel
orienté objet. Elle regroupe une quinzaine de types de diagrammes, dont trois seulement servent vraiment au
quotidien.
Le diagramme de classes est le plus connu. Là où le MCD décrit les données, lui décrit le code, avec ses
classes, leurs attributs et leurs méthodes.
Livre
-------------------
+ titre : string
+ annee : int
+ auteur : Auteur
-------------------
+ emprunter()
+ rendre()
Le + signale ce qui est visible de l'extérieur, un - ce qui reste privé à la classe.
Les traits entre les boîtes disent qui contient quoi, qui hérite de qui, et combien d'exemplaires sont en jeu.
Le diagramme de séquence
Celui-ci raconte le déroulement d'un scénario dans le temps. Qui parle à qui, dans quel ordre, avec quelles
informations. Chaque participant a sa colonne, et les flèches horizontales sont les messages échangés, de haut
en bas.
C'est de loin le diagramme le plus utile en réunion mixte, parce qu'il se lit sans aucune connaissance
technique. Quand un lecteur emprunte un livre, on voit défiler l'interface, le serveur, la base de données, et
on repère immédiatement l'étape que personne n'avait prévue.
Lecteur Interface Serveur Base
│ │ │ │
│ "emprunter" │ │ │
│──────────────▶│ emprunter(42) │ │
│ │──────────────▶│ 42 dispo ? │
│ │ │─────────────▶│
│ │ │◀─────────────│
│ │ │ oui │
│ │ │ enregistrer │
│ │ │─────────────▶│
│ │◀──────────────│ │
│◀──────────────│ "à rendre │ │
│ │ le 12 mars" │ │En le dessinant, quelqu'un finit toujours par demander ce qui se passe si le livre n'est pas disponible, ou si le lecteur a déjà trois emprunts en cours. C'est exactement l'étape que personne n'avait prévue.
Le diagramme de cas d'usage
Ici, on se place du point de vue de l'utilisateur. Chaque bulle est une chose qu'il peut faire, s'inscrire,
chercher un livre, consulter son historique, et chaque bulle est reliée à un acteur, le lecteur, le
bibliothécaire, l'administrateur.
C'est un outil de cadrage plus que de conception. Il sert à s'assurer qu'on n'a oublié ni une fonctionnalité, ni
un type d'utilisateur, avant que le développement ne commence.
Le schéma que tu verras le plus
Aucun des diagrammes ci-dessus n'est celui qu'on projette en comité. Celui-là, ce sont des boîtes et des
flèches, le site, l'application mobile, la base, le prestataire de paiement, l'outil d'emailing, et ce qui
circule entre eux. Il ne suit aucune norme, et c'est pourtant le seul dessin technique que la plupart des
dirigeants regardent jamais.
Un bon schéma s'adresse à un public précis. Le même système se dessine en cinq boîtes pour une direction et en
quarante pour l'équipe qui le construit, et le diagramme qui essaie de servir aux deux ne sert à personne.
Quand on t'en montre un, demande à quel niveau de zoom il se place, ça évite de chercher un détail qui n'y est
pas.
Les outils ont changé. Beaucoup d'équipes décrivent aujourd'hui leurs schémas en quelques lignes de texte, rangées à côté du code et transformées en dessin automatiquement. Un schéma qui se modifie comme du code reste à jour, là où l'image collée dans un document se périme à la première évolution. Pour les ateliers, les tableaux blancs en ligne ont remplacé les post-it, sans changer la méthode.
À quoi ça sert vraiment
- Aligner l'équipe : un schéma au tableau règle en dix minutes un malentendu qui aurait coûté deux semaines de développement.
- Faire apparaître les trous : les incohérences d'un modèle sautent aux yeux bien plus vite que celles d'un cahier des charges de quarante pages.
- Documenter : un an plus tard, le schéma explique la structure du système plus vite que la lecture du code.
- Discuter avec les non-techniques : c'est souvent le seul support commun entre le métier et les développeurs.
La modélisation a aussi ses excès. Dans les années 2000, certains projets produisaient des centaines de diagrammes UML exhaustifs qui devenaient faux dès la première semaine de développement. Les équipes agiles ont largement réagi contre cette dérive. Aujourd'hui, l'usage courant, c'est quelques schémas ciblés, souvent dessinés au tableau et photographiés, pas une documentation complète que personne ne maintiendra.
Retiens surtout une chose, les développeurs ne codent pas à l'aveugle. Quand on te propose une réunion de modélisation, ce n'est pas du temps volé au développement, c'est du temps qui évite d'avoir à tout refaire. Et tu n'y es pas spectateur. Tu es la source du savoir métier, celui qui corrige un mot, signale le cas particulier que personne n'a prévu, et tranche entre deux modèles également plausibles. Le chapitre sur le Domain Driven Design décrit l'atelier où ça se joue.