Enterprise Architect in der Toolchain: EA-Modelle automatisiert verarbeiten

Moderne Produktentwicklung ist Teamarbeit, und jede Disziplin hat ihr bevorzugtes Werkzeug. Systemarchitekten arbeiten im Enterprise Architect, Entwickler in ihrer IDE und CI-Pipeline, andere in spezialisierten Werkzeugen. Das Problem ist selten das einzelne Tool, sondern die Lücke dazwischen: Solange das Architekturmodell nur im Enterprise Architect lebt, einer GUI-Anwendung, die zudem auf Windows beschränkt ist, bleibt es eine Insel. Wer es automatisiert weiterverarbeiten will, braucht es als portable, skriptbare Daten.

Die itemis EA Bridge ist genau dieser Baustein: ein eigenständiges Kommandozeilenwerkzeug, das EA-Modelle ausliest und als stabiles JSON bereitstellt, plattformunabhängig und schnell genug für jeden automatisierten Schritt.

Wie schnell, zeigt ein realer Vergleich. Ein Kundenmodell mit über 70 MB, 77.164 Modellelementen und 140 umfangreichen Zustandsautomaten verarbeiten die drei Werkzeuge sehr unterschiedlich:

Die drei Zeilen messen nicht exakt dieselbe Operation, zeigen aber dieselbe Aufgabe auf demselben Modell. Der eigentliche Gewinn liegt in der Turnaround-Zeit: Sekunden statt Minuten machen aus einem schwerfälligen Sonderlauf einen Schritt, den man beliebig oft wiederholen kann. Dieselbe Geschwindigkeit qualifiziert die Verarbeitung zugleich als automatisierten Schritt in einer Pipeline.

Was sich automatisieren lässt

Sobald das Modell als strukturierte, maschinenlesbare Daten vorliegt, wird aus manueller Weiterverarbeitung eine automatisierte. Vier Anwendungsfälle stehen dabei im Vordergrund:

• Validierung: Konsistenzregeln, Namenskonventionen und Vollständigkeitsprüfungen laufen reproduzierbar gegen jedes Modell, statt per Sichtprüfung.
• Code-Generierung: Aus dem Modell entstehen Quelldateien, etwa für eine AUTOSAR-Methodik auf UML-Basis.
• Report-Generierung: Aus denselben Daten lassen sich Dokumente und Übersichten ableiten, von der Schnittstellenliste bis zum Architektur-Steckbrief.
• KI-Reasoning: Die strukturierten Daten eignen sich als Grundlage, damit KI-Assistenten Fragen über das Modell präzise beantworten.

Jeder dieser Schritte braucht das Modell als verlässliche Daten, und jeder profitiert davon, dass die Verarbeitung performant und plattformunabhängig läuft, lokal beim Entwickler wie in einer CI-Pipeline. Die Felder Code-Generierung und KI-gestützte Nutzung vertiefen eigene Artikel zu Custom Tooling und KI-gestützter Entwicklung.

Die ursprüngliche, Java-basierte EA-Bridge entwickeln wir seit 2013; sieben Kunden haben wir bei der Einführung direkt begleitet. Die neue Generation ist in Rust geschrieben, als CLI-Werkzeug direkt von einer KI nutzbar. Eine VS-Code-Extension setzt als Oberfläche darauf auf, der entscheidende Baustein für die Toolchain ist aber die CLI darunter.

Das Modell in VS Code: Modellbaum, Properties View, gerendertes Diagramm, Suchfeld und KI Skill.

Die CLI als Integrationsbaustein

Das Produkt ist ein einzelnes Rust-Binary mit zwei Modi: Als CLI läuft es auf der Kommandozeile, als Sidecar dient es als Hintergrundprozess der VS-Code-Extension. Für die Toolchain Integration zählt der CLI-Modus.

Das Werkzeug stellt einige wenige, klar umrissene Kommandos bereit:

• export liest ein EA-Modell und gibt es als JSON aus, wahlweise in eine Datei oder nach stdout.
• query wertet ein jq-Programm gegen das Modell aus und gibt nur das Ergebnis zurück, ohne das gesamte Modell exportieren zu müssen.
• schema gibt das JSON-Schema des Exports aus, sodass nachgelagerte Werkzeuge gegen einen dokumentierten Vertrag programmieren können.
• errors listet den Katalog der Fehlercodes mit ihrer Bedeutung auf.

Die verfügbaren Kommandozeilenargumente, hier unter Windows über ea-bridge.exe aufgerufen.

Für die Pipeline-Tauglichkeit zählen zwei Eigenschaften: was die Kommandos tun und wie sie sich verhalten. Die Nutzdaten gehen nach stdout, Diagnostik und Warnungen nach stderr. Der Rückgabewert ist standardisiert: 0 für Erfolg, 1 für Teilerfolg mit Datenwarnungen, 2 für Abbruch. Jede Warnung trägt einen Fehlercode, der über errors nachschlagbar ist.

# In eine Datei exportieren, um sie nachgelagert weiterzuverarbeiten
ea-bridge export Modell.qea --output modell.json

# Oder direkt in das nächste Werkzeug pipen
ea-bridge export Modell.qea | python generate.py

Über das query-Kommando wird die CLI darüber hinaus zum Qualitätsgate. Eine gezielte Abfrage beantwortet eine konkrete Frage und liefert nur das Ergebnis zurück, etwa die Zahl der Interfaces oder ‘die Namen und Typen aller Elements, denen ein Stereotyp aus dem Profil “BMM” appliziert wurden’:

ea-bridge query Modell.qea '[.elements[] | select(.elementType=="Interface")] | length'
ea-bridge query model.qea '[.elements[] | select((.stereotypes // []) | any(startswith("BMM::"))) | {name: .name, type: .elementType}] | .[] | (.name + " (" + .type + ")")'

Dieselbe Abfrage auf einem Raspberry Pi: Das ARM-Linux-Binary zählt und listet die Interfaces im Modell und gibt nur das Ergebnis aus.

Eine Abfrage formuliert eine Modellregel; der Exit-Code entscheidet, ob der Build weiterläuft. So fällt ein Modell, das eine Konvention verletzt, früh auf.

Ein typisches Szenario: Ein nächtlicher oder commit-gesteuerter Job exportiert das aktuelle Modell als JSON, lässt Konsistenzabfragen darüberlaufen und übergibt das Ergebnis an die Codegenerierung. Der Enterprise Architect bleibt die maßgebliche Modellquelle, muss aber nirgends in der Pipeline installiert sein. Die Entkopplung von Modellierungs- und Automatisierungswerkzeug ist der Kern einer funktionierenden Toolchain Integration.

Plattformunabhängig, überall lauffähig

Der Enterprise Architect läuft nur unter Windows. Die EA Bridge nicht. Weil Rust plattformnativen Code erzeugt, liefern wir vorgebaute Binärdateien für Windows (x64), macOS (x64 und ARM) und Linux (x64 und ARM). Eine EA-Modelldatei lässt sich damit auf einem Linux-CI-Runner verarbeiten, ohne Windows-Agent und ohne EA-Lizenz auf dem Buildserver. Für die reine CLI-Nutzung genügt die jeweilige Binärdatei ohne weitere Laufzeitabhängigkeiten.

Wo das Modell liegt: die Datenbank-Abstraktion

EA-Modelle werden in der Praxis unterschiedlich persistiert. Die EA Bridge trennt die Kernlogik über eine Datenbank-Abstraktion von den konkreten Persistenzformaten; alle Formate werden über dieselbe Schnittstelle geladen. Unterstützt sind heute:

• die modernen SQLite-basierten Dateien (.qea und .qeax),
• die klassischen Access/JET-Dateien (.eap und .eapx),
• serverbasierte EA-Repositories auf MySQL/MariaDB und Microsoft SQL Server.

Damit erreicht die EA Bridge auch die zentralen Team-Repositories, in denen größere Organisationen ihre Modelle gemeinsam verwalten. Eine Server-Verbindung wird über die EA-eigenen Shortcut-Dateien angesprochen; die Bridge erkennt das dahinterliegende Backend und löst die Verbindung entsprechend auf. Oracle, PostgreSQL und Cloud-Anbindungen werden derzeit nicht unterstützt; Funktionswünsche nehmen wir über den Issue-Tracker entgegen.

Stabiles JSON-Schema

Der gemeinsame Nenner zwischen dem Enterprise Architect und dem Rest der Werkzeuglandschaft ist das JSON-Format. Es ist eigenständig versioniert (aktuell Version 1.6) und in seinen Kernfeldern bewusst stabil gehalten: Ein nachgelagertes Werkzeug bricht nicht, wenn die Bridge ein neues, optionales Feld ergänzt. Über das schema-Kommando lässt sich der Vertrag jederzeit maschinell abrufen.

Einordnung: Automatisierung, nicht Traceability

Toolchain Integration umfasst mehr als einen Pfad. Die EA Bridge ist der Automatisierungs-Pfad: Sie holt das EA-Modell als Daten heraus, damit Artefakte automatisch entstehen statt manuell übertragen zu werden, sei es Validierung, generierter Code, ein Report oder eine KI-gestützte Abfrage. Ein typisches Beispiel ist, das Architekturmodell an eine Codegenerierungs-Pipeline anzubinden, etwa um AUTOSAR-Methodik auf UML-Basis umzusetzen. Dieser Anwendungsfall ist im Abschnitt Automatisierung: Codegenerierung aus der Architektur beschrieben.

Davon zu unterscheiden ist die werkzeugübergreifende Traceability, also die durchgängige Nachverfolgbarkeit von Anforderungen über die Architektur bis zum Code. Dafür gibt es bei itemis mit itemis ANALYZE eine eigene Plattform. Die EA Bridge adressiert den Automatisierungsfall; welche technischen Integrationsebenen darüber hinaus existieren, ordnet der Abschnitt technische Integrationsebenen ein.

Fazit

Die EA Bridge macht den Enterprise Architect anschlussfähig. Eine plattformunabhängige CLI mit sauberem stdout/stderr-Verhalten, dokumentierten Exit-Codes und einem stabilen, versionierten JSON-Format macht EA-Modelle automatisiert weiterverarbeitbar: für Validierung, Code- und Report-Generierung, KI-Reasoning und die Einbindung in CI/CD-Pipelines, ohne Windows-Agent oder EA-Lizenz auf dem Server. Über die Datenbank-Abstraktion erreicht sie lokale Dateien ebenso wie die serverbasierten Team-Repositories.

Wenn Ihre Engineering-Werkzeuge nicht miteinander reden und der Enterprise Architect eine Insel ist, ist das genau unser Feld. Wie itemis Werkzeugketten zusammenführt, lesen Sie auf der Seite Toolchain Integration. Das Werkzeug selbst finden Sie im VS Code Marketplace.