UML gilt als schwergewichtig, aber die meisten Engineers greifen trotzdem dazu, wenn sie präzise sein müssen: ein Klassendiagramm, um ein Modell festzuzurren, ein Sequenzdiagramm, um eine Interaktion genau zu fassen, ein Zustandsautomat, um die Übergänge explizit zu machen. Das Problem war nie UML. Es war das Zeichnen. Ein Dutzend Klassen mit Feldern und Beziehungen von Hand anzuordnen, ist genau die Art fummeliger, mechanischer Arbeit, die niemand zweimal machen will.
Damit passt es fast perfekt zu KI. Die Struktur ist klar definiert, die Notation ist Standard und das Layout folgt Regeln. Du bringst die Absicht mit; das Tool übernimmt die Platzierung.
Zwei Einstiege: beschreiben oder auf Code zeigen
Es gibt zwei ehrliche Ausgangspunkte für ein KI-generiertes UML-Diagramm, und sie passen zu unterschiedlichen Momenten.
- Aus einer Beschreibung, wenn das Design noch in deinem Kopf ist. „Ein User hat viele Orders; jede Order hat Line Items; ein Line Item verweist auf ein Product.“ Du skizzierst das Modell laut und willst es sehen.
- Aus vorhandenem Code oder Schema, wenn das Design schon existiert und du das Bild willst. Deine Klassen, deine SQL-Tabellen, deine Typen enthalten die Beziehungen bereits. Daraus zu generieren heißt, dass das Diagramm der Realität entspricht statt deiner Erinnerung daran.
Der zweite Weg ist die stille Superkraft. Ein aus den echten Typen abgeleitetes Klassendiagramm kann über die Felder nicht lügen, und ein ER-artiges Modell aus echter DDL kann keine Beziehung erfinden, die es nicht gibt.
Ein Klassendiagramm mit KI, aus einem einzigen Satz
Angenommen, du beschreibst ein kleines Bestellmodell. Das generierte Diagramm liefert dir echte Kästen: jede Klasse mit ihren Attributen und die Assoziationen mit korrekter Multiplizität, nicht nur einfache Linien.
Sequenzdiagramme: die Interaktion, nicht die Objekte
Klassendiagramme zeigen Struktur; Sequenzdiagramme zeigen Verhalten über die Zeit. Sie von Hand zu zeichnen ist noch mühsamer, weil jede Nachricht ein exakt platzierter Pfeil zwischen Lebenslinien ist. Beschreib stattdessen den Ablauf: „Der Client ruft die API auf, die den Cache prüft, einen Miss hat, die Datenbank abfragt, den Cache schreibt und antwortet.“ Du bekommst Lebenslinien und geordnete Nachrichten, die du dann kürzen und annotieren kannst.
Die Notation ist Standard und das Layout folgt Regeln. Genau deshalb kann eine Maschine es entwerfen, und du kannst dich darauf verlassen, es selbst zu korrigieren.
Bleib ehrlich: aus dem Echten generieren
Das langlebigste UML wird nicht aus der Fantasie gezeichnet; es wird aus dem abgeleitet, was schon existiert. Wenn deine Modelle sich verändern, veraltet ein handgezeichnetes Diagramm mit. Das Klassendiagramm aus deinen echten Typen oder ein Datenmodell aus deinem echten Schema zu generieren heißt, dass sich das Bild aktualisiert, wenn sich der Code ändert. Neu generieren statt neu zeichnen, und das Diagramm ist kein Museumsstück mehr.
Dann mach es lesbar, denn UML kann dicht werden
Vollständiges UML wird schnell zu einer Wand aus Kästen. Der Vorteil editierbarer Ausgabe ist, dass du es auf die Aussage zurechtstutzen kannst, um die es dir gerade geht. Blende die Attribute aus, die für dieses Diagramm keine Rolle spielen. Gruppiere die Klassen eines Aggregats. Hebe die Beziehung hervor, die den Lesenden auffallen muss. Ein Diagramm, das eine Sache klar sagt, schlägt ein vollständiges, das niemand liest.
Generiere die Struktur, korrigiere die Details, kürze auf die Botschaft und exportiere eine Version, die bleibt. UML ist dann keine lästige Pflicht mehr, sondern wieder das, wofür es gedacht war: ein präzises, gemeinsames Bild davon, wie das System zusammengesetzt ist.