UML mit KI erzeugen
Ein Sprachmodell erzeugt aus zwei Sätzen Beschreibung ein UML-Diagramm, und das meiste daran stimmt. Hier geht es um den Rest: die vier Fehler, die beim Erzeugen jedes Mal auftreten, und die Zwei-Minuten-Prüfung, die sie findet, bevor das Diagramm ein Team erreicht.
9 Min. LesezeitUML 2.5.119 von 23
01What generation is actually good at
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.
02The four failures, in order
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.
- 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.
- Multiplicities defaulted to one-to-many. Unasked, almost every association comes back
1to0..*. Sometimes that is right. When it is not, it is the kind of wrong that survives into a schema. - Interfaces invented for single implementations. Models have read a great deal of enterprise Java. If your domain has one payment provider, an
«interface» IPaymentProviderin the draft is decoration. - 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.
03Prompting for something checkable
Three ingredients, and the third is the one people leave out.
- 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.
- Give it your nouns. The words your team already uses, spelled the way your code spells them. A model that invents
BorrowRecordwhen you sayLoanproduces a diagram nobody can map onto anything. - 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.
04The two-minute review
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.
Reach for it when
- Every diamond: does the part really die with the whole? Filled if yes, hollow if not
- Every multiplicity: read it aloud as a sentence and check it against a real case
- Every interface: is there a second implementation, or could there plausibly be one?
- The diagram kind: does this shape answer the question you asked, or a different one?
Reach for something else when
- Accepting attribute types - they are guesses, and cheap to correct later
- Arguing about layout before the relationships are right
- Asking for a redraw when a single edge is wrong - fix it in the editor
- Circulating it before somebody who knows the domain has read it once
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".
05How this works in Archyno
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.
In one line each
- 01Generation is excellent at the blank page and at notation, which is most of the friction.
- 02It is unreliable about ownership, multiplicity, invented interfaces and diagram kind.
- 03Name the diagram kind, supply your own nouns, and state the question it must answer.
- 04Review four things: diamonds, multiplicities, interfaces, and whether the kind fits.
- 05Generate into a model rather than an image, or every correction is another prompt.
- 06Nothing about generation replaces somebody who knows the domain reading it once.
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.
06Häufige Fragen
Kann KI ein UML-Diagramm aus einer Beschreibung erzeugen?
Ja, und der erste Entwurf ist meist strukturell in Ordnung: passende Klassen, vernünftige Namen, Beziehungen, die überwiegend richtig zeigen. Was das Modell nicht wissen kann, ist welcher von mehreren vertretbaren Entwürfen zu Ihrem System passt - behandeln Sie die Ausgabe als Entwurf von jemandem, der die Spezifikation kennt, aber Ihren Code nicht.
Welche Fehler machen KI-erzeugte UML-Diagramme am häufigsten?
Vier, in dieser Reihenfolge: Komposition wird als Aggregation oder blosse Assoziation gezeichnet, Multiplizitäten stehen ungefragt auf eins-zu-viele, Schnittstellen werden für Klassen mit genau einer Implementierung erfunden, und es kommt ein Klassendiagramm zurück, wo die Frage ein Sequenz- oder Komponentendiagramm verlangte. Alle vier sieht man in unter zwei Minuten.
Wie sollte ein Prompt für ein UML-Diagramm aussehen?
Nennen Sie die Diagrammart, listen Sie die Substantive, die Sie ohnehin verwenden, und sagen Sie, welche Frage das Diagramm beantworten soll. „Ein Klassendiagramm der Ausleihe - Mitglieder, Ausleihen, Exemplare, Titel - das zeigt, was mit Ausleihen passiert, wenn ein Exemplar ausgesondert wird“ liefert Prüfbares; „zeichne UML für eine Bibliothek“ liefert eine Bibliothek, die niemand betreibt.
Taugt ein erzeugtes Diagramm für ein Team?
Nach einer Durchsicht ja, und das ist die ehrliche Antwort. Das Erzeugen nimmt das leere Blatt und das Nachschlagen der Notation ab, also den grössten Teil der Reibung; ob das Modell zu Ihrem System passt, ist Urteilsvermögen, das niemand für Sie erzeugt. Schaden richten die Diagramme an, die vor dem Verteilen niemand gelesen hat.
Passend dazu