UML a la réputation d'être lourd, mais la plupart des ingénieurs y reviennent dès qu'ils doivent être précis : un diagramme de classes pour fixer un modèle, un diagramme de séquence pour cerner une interaction, une machine à états pour rendre les transitions explicites. Le problème n'a jamais été UML. C'était le dessin. Disposer à la main une douzaine de classes avec leurs champs et leurs relations est exactement le genre de travail minutieux et mécanique que personne ne veut faire deux fois.
C'est donc un terrain presque idéal pour l'IA. La structure est bien définie, la notation est standard et la disposition obéit à des règles. Vous apportez l'intention ; l'outil s'occupe du placement.
Deux points d'entrée : le décrire ou pointer vers le code
Il existe deux points de départ honnêtes pour un diagramme UML généré par IA, et ils conviennent à des moments différents.
- À partir d'une description, quand la conception est encore dans votre tête. « Un User a plusieurs Orders ; chaque Order a des Line Items ; un Line Item référence un Product. » Vous esquissez le modèle à voix haute et voulez le voir.
- À partir du code ou du schéma existant, quand la conception existe déjà et que vous voulez l'image. Vos classes, vos tables SQL, vos types encodent déjà les relations. Générer à partir d'eux signifie que le diagramme correspond à la réalité plutôt qu'à votre souvenir de celle-ci.
Le second est le super-pouvoir discret. Un diagramme de classes dérivé des types réels ne peut pas mentir sur les champs, et un modèle de type ER généré à partir d'un vrai DDL ne peut pas inventer une relation qui n'existe pas.
Un diagramme de classes, à partir d'une phrase
Supposons que vous décriviez un petit modèle de commandes. Le diagramme généré vous donne de vraies boîtes : chaque classe avec ses attributs, et les associations tracées avec la bonne multiplicité, pas de simples lignes.
Diagrammes de séquence : l'interaction, pas les objets
Les diagrammes de classes montrent la structure ; les diagrammes de séquence montrent le comportement dans le temps. Ils sont encore plus fastidieux à dessiner à la main, car chaque message est une flèche placée précisément entre des lignes de vie. Décrivez plutôt le flux : « Le client appelle l'API, qui vérifie le cache, ne trouve rien, interroge la base de données, écrit dans le cache et renvoie la réponse. » Vous obtenez des lignes de vie et des messages ordonnés que vous pouvez ensuite élaguer et annoter.
La notation est standard et la disposition obéit à des règles. C'est précisément pour cela qu'une machine peut en faire l'ébauche et que vous pouvez vous fier à vous-même pour la corriger.
Restez fidèle : générez à partir du réel
L'UML le plus durable n'est pas dessiné de mémoire ; il est dérivé de ce qui existe déjà. Si vos modèles dérivent, un diagramme dessiné à la main dérive aussi. Générer le diagramme de classes à partir de vos types réels, ou un modèle de données à partir de votre vrai schéma, signifie que l'image se met à jour quand le code change. Régénérez au lieu de redessiner, et le diagramme cesse d'être une pièce de musée.
Puis rendez-le lisible, car l'UML peut devenir dense
Un UML complet peut vite devenir un mur de boîtes. L'avantage d'un résultat modifiable, c'est que vous pouvez l'élaguer jusqu'au propos que vous voulez réellement tenir. Masquez les attributs qui n'importent pas pour ce diagramme. Regroupez les classes d'un même agrégat. Mettez en évidence la relation que le lecteur doit remarquer. Un diagramme qui dit une chose clairement vaut mieux qu'un diagramme complet que personne ne lit.
Générez la structure, corrigez les détails, réduisez au message et exportez une version qui dure. L'UML cesse d'être une corvée et redevient ce pour quoi il a été conçu : une image précise et partagée de la façon dont le système est construit.