Generování UML pomocí AI
Jazykový model vyrobí UML diagram ze dvou vět popisu a většina bude správně. Tohle je o té části, která ne: čtyři chyby, které generování dělá pokaždé, a dvouminutová kontrola, která je zachytí dřív, než se diagram dostane k týmu.
9 min čteníUML 2.5.119 z 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.
06Časté dotazy
Dokáže AI vygenerovat UML diagram z textového popisu?
Ano a první návrh bývá strukturálně v pořádku: správné třídy, rozumné názvy a vztahy, které většinou míří správně. Model ale nemůže vědět, který z několika obhajitelných návrhů odpovídá vašemu systému, takže s výstupem zacházejte jako s návrhem od člověka, který četl specifikaci, ale ne váš kód.
Co AI na UML diagramech pokazí nejčastěji?
Čtyři věci v tomto pořadí: kompozici nakreslí jako agregaci nebo obyčejnou asociaci, násobnosti nastaví na jedna k mnoha, aniž by se zeptala, vymyslí rozhraní pro třídy s jedinou implementací a vrátí diagram tříd tam, kde otázka potřebovala sekvenční diagram nebo diagram komponent. Všechny čtyři jsou vidět do dvou minut, když víte, co hledat.
Jak má vypadat prompt na UML diagram?
Pojmenujte druh diagramu, vypište podstatná jména, která už používáte, a řekněte otázku, na kterou má diagram odpovědět. „Diagram tříd půjčování v knihovně - členové, výpůjčky, exempláře, tituly - který ukáže, co se stane s výpůjčkami po vyřazení exempláře“ vyrobí něco ověřitelného, kdežto „nakresli UML pro knihovnu“ vyrobí věrohodný diagram knihovny, kterou nikdo neprovozuje.
Lze vygenerovaný diagram předat týmu?
Po kontrole ano a to je poctivá odpověď. Generování odstraní prázdný papír a listování v notaci, což je většina tření; rozhodnout, jestli model sedí na váš systém, je úsudek, který za vás nikdo nevygeneruje. Škodu nadělají ty diagramy, které si před rozesláním nikdo nepřečetl.
Související články