Custom Tooling auf EA-Modellen: vom Modell zum generierten Code

Ein Enterprise-Architect-Modell ist für viele unserer Kunden die maßgebliche Beschreibung ihrer System- oder Softwarearchitektur: Klassen, Schnittstellen, Zustandsautomaten, profilierte Modelle mit Stereotypen. Der Wert dieses Modells entsteht erst, wenn man es weiterverarbeiten kann: Code daraus generiert, es gegen eigene Regeln validiert oder Dokumentation daraus ableitet. Genau dort tut sich der Enterprise Architect mit seinen Bordmitteln schwer. Wir haben deshalb mit der itemis EA Bridge eine Werkzeugbasis gebaut, die das Modell als stabile, maschinenlesbare Daten bereitstellt, auf denen sich eigenes Tooling aufsetzen lässt.

Custom Tooling bedeutet nicht zwangsläufig eine neue domänenspezifische Sprache auf der grünen Wiese. Ein bestehendes Werkzeug wie den Enterprise Architect zu erweitern und seine Modelle nutzbar zu machen, ist genauso Custom Tooling: zugeschnitten auf den Prozess, der beim Kunden tatsächlich gelebt wird. Dieser Artikel beschreibt, wie die EA Bridge diese Basis schafft und was sich konkret darauf bauen lässt.

Ein Datenpunkt vorab, weil er die Tragfähigkeit der Basis zeigt: Ein reales Kundenmodell mit über 70 MB, 77.164 Modellelementen und 140 umfangreichen Zustandsautomaten lädt die EA Bridge in 1,1 Sekunden vollständig und stellt es als JSON bereit. Der Enterprise Architect selbst braucht für den XMI-Export desselben Modells etwa fünf Minuten. Diese Geschwindigkeit ist die Voraussetzung dafür, Codegenerierung bei jedem Commit laufen lassen zu können, statt sie als gelegentlichen Sonderlauf zu behandeln.

Woher das Domänenwissen kommt

Wir starten hier nicht bei null. Die ursprüngliche, Java-basierte EA-Bridge entwickeln wir seit 2013 und haben die Einführung bei sieben Kunden direkt begleitet; darüber hinaus sind zahlreiche Lizenzen im Einsatz. Aus über einem Jahrzehnt Arbeit mit dem EA-Datenmodell stammt ein detailliertes Verständnis seiner Datenbankstrukturen, der verschiedenen Dateiformate und der Anforderungen, die Kunden an die Codegenerierung aus Modellen stellen. Dieses Wissen ist in die neue Werkzeugbasis eingeflossen, die wir KI-gestützt in nur vier Wochen neu gebaut haben: ein Rust-Kern als CLI-Werkzeug, ergänzt um eine VS-Code-Extension als Oberfläche. Einblicke in die damalige Arbeit geben zwei ältere Artikel: Eclipse-basierte UML-Validierung von Enterprise-Architect-Modellen und Eclipse-basierte Codegenerierung für Enterprise-Architect-Modelle.

Technisch liest der Rust-Kern das Modell in zwei Durchgängen: erst werden die Rohdaten aus der Datenbank gesammelt, dann die Querverweise aufgelöst und der fertige Modellgraph im Speicher gebaut.

Die Basis: ein stabiles, versioniertes JSON-Format

Der eigentliche Hebel für Custom Tooling liegt nicht in einer einzelnen Funktion, sondern im Datenformat. Die EA Bridge leitet das Modell in ein dokumentiertes JSON-Format aus, das den Modellgraphen vollständig abbildet: Pakete, Elemente, Konnektoren und Diagramme. Diese Objekte liegen als GUID-indizierte Maps vor, sodass ein Element direkt über seine GUID nachgeschlagen werden kann, statt eine Liste zu durchsuchen oder die Datenbank erneut abfragen zu müssen.

Ein Element trägt im Export deutlich mehr als nur Name und Typ: Sichtbarkeit, Attribute und Operationen mit allen Details, die zugeordneten Stereotypen und Tagged Values sowie die ein- und ausgehenden Konnektoren. Attribute führen Typname, Klassifizierer, Standardwert, Multiplizität und Sichtbarkeit; Kardinalitäten stehen als Zeichenketten im Export (etwa 1, 0..* oder *). Wer ein Custom Tool baut, muss die Eigenheiten des Enterprise Architect kennen, und genau dafür dokumentieren wir die Abbildung jedes UML-Konzepts auf seinen JSON-Pfad.

Das Format ist stabil und eigenständig versioniert (aktuell Version 1.6). Die Kernfelder sind bewusst stabil gehalten, sodass nachgelagerte Werkzeuge auf einer verlässlichen Struktur aufsetzen können; neue, optionale Felder kommen additiv hinzu, ohne bestehende Generatoren zu brechen. Wer die Struktur maschinell prüfen will, lässt sich das JSON-Schema direkt vom Werkzeug ausgeben.

Das JSON Schema der EA Bridge in einem Terminal in Ubuntu.

Dieses stabile Format entkoppelt die Modellquelle von der Weiterverarbeitung. Ein kundenspezifischer Generator, eine Validierung oder ein Dokumentationswerkzeug arbeitet gegen eine klar dokumentierte Datenstruktur, anstatt an die Grenzen der EA-eigenen Bordmittel gebunden zu sein. Damit wird es ein wartbarer Baustein in der eigenen Werkzeugkette.

Codegenerierung: anpassbar statt starr

Auf dieser Basis liefern wir drei Template-Sätze für Java, Python und C++ mit, als anpassbaren Ausgangspunkt. Jeder Satz besteht aus einem Einstiegsskript, einem Generator, der das JSON in ein für die Templates aufbereitetes Modell überführt, und einem Satz von Jinja2-Templates. Geteilte Formatierungslogik, etwa das Rendern von Doc-Kommentaren, das Zusammensetzen von Modifikatoren oder die Bildung von Methodensignaturen, liegt in zentralen Makros, sodass sie nicht in jedem Template wiederholt werden muss.

Die Generatoren bilden die gängigen UML-Konzepte auf Code ab:

• Klassen, Interfaces, Enumerationen, Datentypen werden zu den entsprechenden Konstrukten der Zielsprache, etwa einer Java-Klasse, einem Interface mit abstrakten Methoden, einem Enum oder einem Record.
• Attribute werden zu Feldern mit Typ, Sichtbarkeit und Multiplizität, Operationen zu Methoden mit Parametern, Rückgabetyp und Modifikatoren wie abstract oder static.
• Vererbung (Generalization) wird zur extends-Beziehung, Realisierung zur implements-Beziehung.
• Assoziationen und Aggregationen werden zu Feldern, deren Mehrwertigkeit aus der Multiplizität abgeleitet wird.

Was zählt, ist die Anpassbarkeit: Die Zuordnung von UML-Typen zu Zielsprachen-Typen liegt als sichtbare Tabelle im Generator, die Namenskonventionen sind als Funktionen herausgezogen, und jedes typspezifische Template lässt sich eigenständig editieren.

Ein konkretes Beispiel: Angenommen, jede generierte Java-Klasse soll einen @since-Eintrag im Doc-Kommentar bekommen, der aus dem Versionsfeld des Modellelements stammt. Das Versionsfeld steht im JSON-Export bereits zur Verfügung; nötig ist nur eine kleine Ergänzung im Klassen-Template und im Doc-Kommentar-Makro. Was früher manuelle Übertragung oder ein starrer, nur durch den Hersteller änderbarer Generator war, wird so zu einem konfigurierbaren Schritt in der eigenen Build-Kette: andere Zielsprache, anderer Coding-Standard, anderes Framework, andere Metadaten im generierten Code.

Zur praktischen Absicherung ergänzen wir Kompilier-Tests, sodass bei jedem Push die generierten Java-, Python- und C++-Dateien aus einem Referenzmodell tatsächlich übersetzen.

Codegenerierung auf einem Raspberry Pi: Aus dem exportierten Modell entstehen über die mitgelieferten Templates die Quelldateien der Zielsprache.

Soll eine Zielsprache unterstützt werden, für die noch kein Template-Satz existiert, nimmt man einen der drei vorhandenen Sätze als Vorlage. Die Trennung zwischen Generator, der das JSON aufbereitet, und Templates, die die konkrete Syntax erzeugen, hält das überschaubar: Die Modellaufbereitung bleibt weitgehend gleich, angepasst werden vor allem die typspezifischen Templates und die Typzuordnung. So wächst aus dem Showcase Schritt für Schritt ein produktiver Generator für genau die Sprache und die Konventionen eines Kunden.

Weil das JSON deterministisch ausgegeben wird und der generierte Code damit reproduzierbar ist, lässt sich die Generierung sauber in die Versionskontrolle einbinden: Eine Modelländerung erzeugt einen nachvollziehbaren Diff im generierten Code, der sich wie jeder andere Code reviewen lässt.

Mehr als Codegenerierung: Validierung und Dokumentation

Weil das Modell als strukturierte Daten vorliegt, lassen sich darauf ebenso Modellvalidierung und Dokumentationsgeneratoren aufsetzen. Das CLI-Werkzeug bringt ein query-Kommando mit, das ein jq-Programm gegen das JSON auswertet und nur das Ergebnis zurückgibt. So lässt sich etwa die Zahl der Interfaces bestimmen:

ea-bridge query Modell.qea '[.elements[] | select(.elementType=="Interface")] | length'

Konsistenzregeln, Namenskonventionen oder Vollständigkeitsprüfungen lassen sich als Abfragen formulieren und reproduzierbar gegen jedes Modell laufen lassen. Beispiele, die sich direkt umsetzen lassen: „existiert zu jeder als persistent markierten Klasse ein Identifikator-Attribut", „tragen alle Schnittstellen im API-Paket den vorgeschriebenen Stereotyp" oder „gibt es Elemente ohne Beschreibung". In einer CI-Pipeline wird daraus ein Qualitätsgate, das fehlerhafte Modelle früh meldet, statt sie in den generierten Code durchzureichen.

Die EA Bridge liefert bewusst keinen fertigen Validator oder Dokumentationsgenerator, sondern die verlässliche Datenbasis und das Abfragekommando, auf denen sich kundenspezifisches Tooling aufsetzen lässt.

Erweiterbar mit KI

Beide Wege, Codegenerierung und Validierung, setzen bislang voraus, dass jemand Jinja2-Templates oder jq-Abfragen schreiben kann. Genau diese Hürde senkt der KI-Skill, den die EA Bridge mitliefert. Er kennt die Semantik des Modells, also welches UML-Konzept an welcher Stelle im JSON steht, und die Struktur der mitgelieferten Codegen-Templates.

Eine gewünschte Änderung lässt sich in natürlicher Sprache beschreiben, etwa „ergänze jeder Klasse einen Kopfkommentar mit Autor und Version", und der Skill weiß, welches Template und welches Makro er dafür anpassen muss. Für die Validierung gilt dasselbe: Weil der Skill die Query-Sprache und die JSON-Pfade kennt, lassen sich kundenspezifische Regeln aus einer Beschreibung in Worten als fertige Abfragen generieren. Das Ergebnis bleibt in beiden Fällen prüfbarer Code: Ein erfahrener Entwickler liest das generierte Template oder die Query gegen, bevor sie in die Werkzeugkette wandert.

Was die Basis (noch) nicht leistet

Die EA Bridge ist noch sehr jung und lädt noch nicht alle Modellinformationen; insbesondere Verhaltensdiagramme wie Interactions sind noch unvollständig. Die mitgelieferten Codegen-Templates sind ein Showcase: Sie zeigen das Vorgehen und decken gängige Konstrukte ab, erzeugen aber bewusst keinen produktionsfertigen Rahmen mit Gettern, Settern oder automatisch generierten Hilfsmethoden.

Diese Grenzen sind Ausdruck der Produktstrategie: Zuerst entsteht die tragfähige Basis, der Rest wächst entlang des tatsächlichen Bedarfs. Funktionswünsche nehmen wir über den Issue-Tracker entgegen.

EA Bridge als Integrationsbaustein

Dieselbe CLI-Basis dient auch zur Toolchain Integration (EA-Modelle in CI/CD-Pipelines) und als Datengrundlage für KI-gestützte Entwicklung; beides behandeln eigene Artikel. Hier bleibt der Fokus auf dem selbst entwickelten Werkzeug.

Die EA Bridge selbst ist ein Beleg für KI-gestütztes Custom Tooling: Wir haben sie in vier Wochen mit KI-Agenten nach einer spezifikationsorientierten Methode gebaut, inklusive eines domänenspezifischen KI-Skills, der das zugrunde liegende Modell versteht. Dieser Punkt, dass KI die Kosten für eigene Werkzeuge drastisch senkt und die Make-or-Buy-Entscheidung verschiebt, ist auf der Seite warum KI die Ökonomie der Werkzeugentwicklung verändert ausgeführt.

KI dient hier als Werkzeug; Architektur und Domänenmodellierung bleiben in menschlicher Hand. Bei der EA Bridge betraf das zum Beispiel die Abbildung der EA-Tabellen auf die UML-Konzepte. Die Agenten strebten eine möglichst kanonische Übertragung der Tabellendaten an, das Mapping auf die UML-Konzepte gelang ihnen aber nicht; hier war Domänenwissen erforderlich, das die Agenten nicht mitbrachten. Dasselbe Muster sehen wir in Kundenprojekten regelmäßig: Ein Assistent in einem generischen Werkzeug gibt generische Vorschläge, ein Werkzeug, das die Domäne strukturell kennt, liefert präzise Ergebnisse. Wie sich bestehende Standardwerkzeuge gezielt erweitern lassen, beschreibt der Abschnitt domänenspezifische Sprachen und Werkzeugerweiterungen auf der Custom-Tools-Seite.

Fazit

Eine schnelle, skriptbare CLI mit einem stabilen, versionierten JSON-Format ist die Integrationsbasis, auf der eigenes Tooling entsteht: Codegenerierung, die sich an Zielsprache, Coding-Standards und Frameworks anpassen lässt, ebenso wie Modellvalidierung und Dokumentation. Die mitgelieferten Templates für Java, Python und C++ sind der offene Ausgangspunkt dafür, und ein mitgelieferter KI-Skill senkt die Hürde, sie auch ohne tiefe Programmierkenntnisse anzupassen.

Wenn Sie aus Ihren Enterprise-Architect-Modellen mehr herausholen wollen, als die Bordmittel hergeben, ist das genau unser Feld. Wie itemis individuelle Werkzeuge entwickelt, von der Domänenanalyse bis zur langfristigen Wartung, lesen Sie auf der Seite Custom Tool Development. Das Werkzeug selbst finden Sie im VS Code Marketplace.

Custom Tools bei itemis — Individuelle Werkzeuge für Ihre modellbasierte Entwicklung: Custom Tool Development →