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

Two things, and they are the two that cost the most time. The first is the blank page: naming the eight nouns in a domain and putting them on a canvas is half an hour of work that produces nothing anyone will argue about, and a model does it in seconds. The second is notation lookup - which arrowhead means realization, which end the diamond goes on, what a multiplicity of 0..* looks like next to 1. That knowledge is in the spec, the spec is in the training data, and remembering it was never the interesting part of the job.

The diagram at the top of this article came from a description two sentences long. The classes are right, the attributes are plausible, and a person who knows the domain can read it and start arguing about the parts that matter - which is exactly what a first draft is for.

These repeat across models and across prompts, because they are all the same failure underneath: the generator is picking the most common answer, and your system is not the most common system.

1. Composition drawn as aggregation, or as a plain association. The hollow diamond is the safe-looking choice, so it is the one that comes back. It is also the one that says the parts survive the whole, which is a claim about deletion and about ownership that nobody checked.
2. Multiplicities defaulted to one-to-many. Unasked, almost every association comes back 1 to 0..*. Sometimes that is right. When it is not, it is the kind of wrong that survives into a schema.
3. Interfaces invented for single implementations. Models have read a great deal of enterprise Java. If your domain has one payment provider, an «interface» IPaymentProvider in the draft is decoration.
4. The wrong diagram kind entirely.Ask about behaviour over time and a class diagram comes back, because class diagrams dominate the training data. If the question was "what happens when the payment fails", you wanted a sequence diagram.

None of these are hard to fix. All of them are hard to notice, because a wrong relationship kind looks exactly as confident as a right one, and the diagram is tidy either way.

Three ingredients, and the third is the one people leave out.

1. Name the diagram kind."A class diagram", not "a UML diagram". If you are not sure which kind you want, that is a modelling question and the fourteen kinds are here.
2. Give it your nouns. The words your team already uses, spelled the way your code spells them. A model that invents BorrowRecord when you say Loan produces a diagram nobody can map onto anything.
3. State the question the diagram must answer."...that shows what happens to loans when a copy is withdrawn." This is what turns a plausible picture into a checkable claim, and it is the single highest-value sentence in any prompt.

Run this before the diagram leaves your screen. It maps one-to-one onto the four failures above, and it is the whole difference between a generated diagram that helps and one that quietly misinforms a team for a year.

Two minutes is not an exaggeration: on a diagram of eight boxes it is four glances. What makes it work is knowing what you are looking for, which is why the list is short and specific rather than "review carefully".

Archyno generates into a model rather than into a picture, and that difference is the reason this article can end where it does. The AI is handed the same metamodel the editor enforces, so what comes back is elements and relationships the notation actually permits - a realization can only land on an interface, an ArchiMate serving relationship can only connect the layers the spec allows. The categories of error above shrink to the ones no tool can catch: the ones about your system.

Because it is a model and not an image, the correction is an edit rather than a re-prompt. Change the diamond, change the multiplicity, rename the class - and the rename reaches every view the element appears on. The result exports as PNG, SVG, Mermaid, XMI or a Sparx .qea file, which is what makes a generated diagram something you can hand to a team that does not use the same tool as you.

The ArchiMate half of this - where the layer rules make generation both harder and more useful - is in generating ArchiMate diagrams with AI. What the tool does and does not do is set out plainly in why Archyno.