Générer de l'UML avec l'IA

Deux choses, et ce sont les deux qui coûtent le plus de temps. La première est la page blanche : nommer les huit noms d'un domaine et les poser sur une toile représente une demi-heure de travail qui ne produit rien dont quiconque discutera, et un modèle le fait en quelques secondes. La seconde est la recherche de notation : quelle pointe de flèche signifie réalisation, de quel côté va le losange, à quoi ressemble une multiplicité 0..* à côté d'un 1. Ce savoir est dans la spécification, la spécification est dans les données d'entraînement, et le retenir n'a jamais été la partie intéressante du métier.

Le diagramme en tête de cet article vient d'une description de deux phrases. Les classes sont justes, les attributs plausibles, et quelqu'un qui connaît le domaine peut le lire et commencer à discuter des parties qui comptent - ce à quoi sert exactement un premier jet.

Ils se répètent d'un modèle à l'autre et d'un prompt à l'autre, parce qu'en dessous ce sont tous le même échec : le générateur choisit la réponse la plus courante, et votre système n'est pas le système le plus courant.

1. Une composition dessinée en agrégation, ou en association simple. Le losange creux est le choix qui a l'air prudent, donc c'est celui qui revient. C'est aussi celui qui dit que les parties survivent au tout, une affirmation sur la suppression et sur la propriété que personne n'a vérifiée.
2. Des multiplicités par défaut à un-à-plusieurs. Sans qu'on le demande, presque toute association revient en 1 vers 0..*. Parfois c'est juste. Quand ça ne l'est pas, c'est le genre de faux qui survit jusque dans un schéma.
3. Des interfaces inventées pour une seule implémentation. Les modèles ont lu énormément de Java d'entreprise. Si votre domaine a un seul prestataire de paiement, une «interface» IPaymentProvider dans le brouillon est de la décoration.
4. Carrément le mauvais type de diagramme.Posez une question sur le comportement dans le temps et un diagramme de classes revient, parce que les diagrammes de classes dominent les données d'entraînement. Si la question était « que se passe-t-il quand le paiement échoue », vous vouliez un diagramme de séquence.

Aucun n'est difficile à corriger. Tous sont difficiles à remarquer, parce qu'un type de relation faux a exactement l'air aussi assuré qu'un juste, et le diagramme est soigné dans les deux cas.

Trois ingrédients, et c'est le troisième que l'on oublie.

1. Nommez le type de diagramme.« Un diagramme de classes », pas « un diagramme UML ». Si vous ne savez pas lequel vous voulez, c'est une question de modélisation et les quatorze types sont ici.
2. Donnez-lui vos noms. Les mots que votre équipe emploie déjà, écrits comme votre code les écrit. Un modèle qui invente BorrowRecord quand vous dites Loan produit un diagramme que personne ne peut faire correspondre à quoi que ce soit.
3. Énoncez la question à laquelle le diagramme doit répondre.« ...qui montre ce qui arrive aux prêts quand un exemplaire est retiré. » C'est ce qui transforme une image plausible en affirmation vérifiable, et c'est la phrase la plus rentable de n'importe quel prompt.

Faites-la avant que le diagramme ne quitte votre écran. Elle correspond point par point aux quatre échecs ci-dessus, et c'est toute la différence entre un diagramme généré qui aide et un qui désinforme discrètement une équipe pendant un an.

Deux minutes n'est pas une exagération : sur un diagramme de huit boîtes, ce sont quatre coups d'oeil. Ce qui le rend efficace, c'est de savoir ce que l'on cherche, d'où une liste courte et précise plutôt qu'un « relisez attentivement ».

Archyno génère dans un modèle plutôt que dans une image, et c'est cette différence qui permet à cet article de se terminer là où il se termine. On donne à l'IA le même métamodèle que celui qu'applique l'éditeur, donc ce qui revient, ce sont des éléments et des relations que la notation autorise réellement : une réalisation ne peut atterrir que sur une interface, une relation de service ArchiMate ne peut relier que les couches que la spécification permet. Les catégories d'erreur ci-dessus se réduisent à celles qu'aucun outil ne peut attraper : celles qui concernent votre système.

Parce que c'est un modèle et non une image, la correction est une modification et non un nouveau prompt. Changez le losange, changez la multiplicité, renommez la classe - et le renommage atteint toutes les vues où l'élément apparaît. Le résultat s'exporte en PNG, SVG, Mermaid, XMI ou en fichier .qea Sparx, ce qui fait d'un diagramme généré quelque chose que vous pouvez remettre à une équipe qui n'utilise pas le même outil que vous.

La moitié ArchiMate de tout ceci - où les règles de couches rendent la génération à la fois plus difficile et plus utile - est dans générer des diagrammes ArchiMate avec l'IA. Ce que l'outil fait et ne fait pas est exposé sans détour dans pourquoi Archyno.