Generování UML pomocí AI

Ve dvou věcech, a jsou to právě ty, které stojí nejvíc času. První je prázdná stránka: pojmenovat osm podstatných jmen v doméně a dostat je na plátno je půl hodiny práce, která nevyprodukuje nic, o čem by se někdo hádal, a model to udělá za vteřiny. Druhou je dohledávání notace - která hlava šipky znamená realizaci, na který konec jde kosočtverec, jak vypadá násobnost 0..* vedle 1. Ta znalost je ve specifikaci, specifikace je v trénovacích datech a pamatovat si ji nikdy nebyla ta zajímavá část práce.

Diagram v hlavičce tohohle článku přišel z dvouvětého popisu. Třídy jsou správné, atributy věrohodné a člověk, který doménu zná, si ho přečte a začne se hádat o ty části, na kterých záleží - a přesně na to první návrh je.

Opakují se napříč modely i napříč prompty, protože pod povrchem jsou všechna týmž selháním: generátor vybírá nejběžnější odpověď a váš systém není nejběžnějším systémem.

1. Kompozice nakreslená jako agregace nebo jako obyčejná asociace. Dutý kosočtverec je bezpečně vypadající volba, takže je to ta, která se vrátí. Je to zároveň ta, která říká, že části přežijí celek, což je tvrzení o mazání a o vlastnictví, které nikdo neověřil.
2. Násobnosti výchozí na jeden k mnoha. Bez zeptání se téměř každá asociace vrátí jako 1 k 0..*. Někdy je to správně. Když ne, je to ten druh nesprávnosti, který přežije až do schématu.
3. Rozhraní vymyšlená pro jedinou implementaci. Modely přečetly velké množství podnikové Javy. Pokud má vaše doména jednoho poskytovatele plateb, je «interface» IPaymentProvider v návrhu ozdobou.
4. Úplně nesprávný druh diagramu.Zeptejte se na chování v čase a vrátí se diagram tříd, protože diagramy tříd dominují trénovacím datům. Pokud byla otázka „co se stane, když platba selže“, chtěli jste sekvenční diagram.

Ani jedno z nich se neopravuje těžko. Všechna se těžko všimnou, protože nesprávný druh vztahu vypadá přesně tak sebevědomě jako správný a diagram je tak jako tak uklizený.

Tři složky, a ta třetí je ta, kterou lidé vynechávají.

1. Pojmenujte druh diagramu.„Diagram tříd“, ne „UML diagram“. Pokud si nejste jistí, který druh chcete, je to modelovací otázka a těch čtrnáct druhů je tady.
2. Dejte mu svá podstatná jména. Slova, která váš tým už používá, napsaná tak, jak je píše váš kód. Model, který si vymyslí BorrowRecord, když vy říkáte Loan, vyprodukuje diagram, který si nikdo neumí na nic namapovat.
3. Vyslovte otázku, na kterou musí diagram odpovědět.„...který ukazuje, co se stane s výpůjčkami, když se výtisk vyřadí.“ Právě to mění věrohodný obrázek na ověřitelné tvrzení a je to jediná věta s nejvyšší hodnotou v jakémkoli promptu.

Projděte si to dřív, než diagram opustí vaši obrazovku. Mapuje se jedna ku jedné na ta čtyři selhání výše a je to celý rozdíl mezi vygenerovaným diagramem, který pomůže, a takovým, který rok potichu dezinformuje tým.

Dvě minuty nejsou nadsázka: na diagramu o osmi boxech jsou to čtyři pohledy. Funguje to díky tomu, že víte, co hledáte, a proto je seznam krátký a konkrétní místo „důkladně zkontrolujte“.

Archyno generuje do modelu, ne do obrázku, a právě ten rozdíl je důvodem, proč může tenhle článek skončit tam, kde končí. AI dostane tentýž metamodel, který vynucuje editor, takže se vrátí to, co notace opravdu připouští - realizace může přistát jen na rozhraní, ArchiMate vztah sloužení může spojit jen ty vrstvy, které specifikace dovoluje. Kategorie chyb výše se smrsknou na ty, které nezachytí žádný nástroj: na ty o vašem systému.

Protože je to model a ne obrázek, oprava je úprava, ne nový prompt. Změňte kosočtverec, změňte násobnost, přejmenujte třídu - a to přejmenování dorazí do každého pohledu, ve kterém se prvek objevuje. Výsledek se exportuje jako PNG, SVG, Mermaid, XMI nebo soubor .qea pro Sparx, a právě to dělá z vygenerovaného diagramu něco, co umíte předat týmu, který nepoužívá tentýž nástroj jako vy.

ArchiMate polovina tohohle - kde pravidla vrstev dělají generování zároveň těžším i užitečnějším - je v článku generování ArchiMate diagramů pomocí AI. Co nástroj dělá a co nedělá, je přímo vyloženo v proč Archyno.