Eclipse-basierte Codegenerierung für Enterprise-Architect-Modelle

Hin und wieder fragen uns unsere Kunden, ob es möglich ist, Code für UML-Modelle zu generieren, die mit dem Enterprise Architect (EA) entworfen wurden. Eclipse ist 2026 keine junge Technologie mehr, aber in der Automobil- und Embedded-Industrie nach wie vor weit verbreitet. Für Teams, die bereits auf dem Eclipse-Ökosystem aufbauen, bleibt der hier beschriebene Ansatz der sauberste Weg. Im Allgemeinen ermutigen wir unsere Kunden, dem Paradigma des modellgetriebenen Engineerings (MDE) zu folgen, um Quellcode automatisch aus Softwaremodellen abzuleiten.

Wann EA-Modelle als Codequelle sinnvoll sind

Je nach Anwendungsfall des Kunden kann es sinnvoller sein, eine dedizierte domänenspezifische Sprache (z. B. mit Xtext) mit einem kundenspezifischen Code-Generator zu verwenden, der die Bedürfnisse des Kunden perfekt erfüllt. In manchen Fällen ist UML jedoch ebenfalls gut geeignet, z. B. bei der Arbeit mit AUTOSAR-Modellen. In solchen Szenarien scheint es sinnvoll zu sein, mit den von EA bereitgestellten allgemeinen Codegenerierungsfunktionen zu beginnen und diese an spezifische Bedürfnisse anzupassen. Wir zeigen ein Beispiel für einen solchen Versuch und begründen, warum ein Drittanbieter-Code-Generator die bessere Wahl sein kann.

Der eingebaute Template-Editor: Möglichkeiten und Grenzen

Ausgehend von einem einfachen UML-Modell, das eine Bibliothek mit Medien beschreibt, erzeugen die Standard-Codegenerierungstemplates rudimentären Java-Code. Leider berücksichtigen die Templates keine Multiplizitäten: Eine Bibliothek sollte eine beliebige Anzahl von Medien enthalten, nicht nur eines! Also überprüften wir die Templates und waren überrascht von ihrer eigenwilligen Syntax und dem Generierungsmechanismus. Es ist schön, dass die Templates modular aufgebaut sind und einzelne Templates wiederverwendet werden können (z. B. zur Generierung eines Attributs), sogar vordefinierte Makros können verwendet werden, z. B. um sprachabhängige Sichtbarkeiten zu generieren. Aber wir dachten, es wäre einfach, die Templates so zu modifizieren, dass ein List<Media> für unsere Bibliothek generiert wird…

(Code-Template-Editor in EA: keine Syntaxvalidierung, schlechte Dokumentation – der vorgeschlagene Weg zur Generierung eines mehrwertigen Feldes für die ‘media’-Aggregation funktioniert nicht.)

Wo die integrierten Mittel nicht ausreichen

Aber das ist nicht so einfach, wie es klingt, selbst für erfahrene Java-Entwickler. Wir versuchten, das Template ‘Attribute Declaration’ (das von ‘Class Body’ referenziert wird) zu modifizieren, bis uns auffiel, dass stattdessen ‘Linked Attribute Declaration’ verwendet wird. Nachdem wir die richtige Stelle gefunden hatten, konnten wir nicht bestimmen, wie ein Typ wie List generiert werden soll, weil die vordefinierte Variable linkAttCollectionClass nie gesetzt wird. Der Tooltip sagt „The collection appropriate for the linked attribute in scope.", das User Guide ist etwas konkreter, aber wir konnten nicht herausfinden, wie man sie setzt. Am Ende ignorierten wir diese Variable und behielten nur die hässliche Überprüfung der Aggregationskardinalität (die z. B. bei der Kardinalität ‘1..1’ versagt). Unser Fazit:

• Die proprietäre Template-Sprache in EA hat eine unvollständige und schlechte Dokumentation.
• Die Beziehung zwischen Sub-Templates (z. B. die Einbindung von ‘Link Attribute’ in einer Klasse) ist undurchsichtig.
• Code-Completion ist unpraktisch, da sie je nach aktuellem Kontext nicht richtig scoped.
• Es gibt keine Syntaxvalidierung.
• Der tatsächlich generierte Code ist in den Templates schwer zu erkennen; ungültige Anweisungen werden direkt generiert.
• Makros können nicht modifiziert oder hinzugefügt werden.

Eclipse und die EA-Bridge: ein bewährter Ansatz

Aufgrund der oben genannten Nachteile der integrierten Codegenerierungsfunktionen von EA empfehlen wir unseren Kunden, die Codegenerierung für UML-Modelle benötigen, Eclipse und seine Tools für die Codegenerierung zu verwenden. Dies bietet auch genügend Flexibilität, um den generierten Code gemäß spezifischen Coding-Styles und Guidelines zu formatieren, was mit EA-Code-Templates eine schwierige Aufgabe wäre.

Wir verwenden die EA-Bridge, um auf EA-Modelle innerhalb von Eclipse zuzugreifen. Sie lädt diese als Eclipse-UML-Modelle und führt dabei als Nebeneffekt eine syntaktische Modellvalidierung durch. Damit lassen sich alle Eclipse-basierten Modellierungstools zur Verarbeitung von EA-Modellen nutzen, z. B. für Modellvalidierung, Codegenerierung (z. B. Xtend oder reines Java) oder automatisierte Testausführung in Continuous-Integration-Builds.

Unsere Wahl für die Codegenerierung ist typischerweise Xtend mit seinen Template Expressions, da es nahtlos mit Java integriert und Code-Completion, Syntaxvalidierung sowie vollständige Debugging-Unterstützung bietet. Das folgende Snippet zeigt ein einfaches Beispiel, wie Code für die Library-Klasse wie gewünscht generiert werden kann.

(Ein erstes Codegenerierungs-Template in Xtend zum Generieren von Java-Klassen für alle UML-Klassen eines EA-Modells; dieses Template kann bei Bedarf leicht erweitert werden.)

Xtend als Template-Sprache: Vorteile in der Praxis

Im Gegensatz zu den EA-Codegenerierungsfunktionen werden Xtend-Code-Templates validiert, die IDE bietet richtig gescopte Code-Completion, und Änderungen werden sofort im generierten Code reflektiert (wenn der Xtend-Code-Generator als Eclipse-Builder konfiguriert ist), was die Code-Template-Entwicklung zu einer komfortablen Aufgabe macht. Sie können sogar am EA-Modell arbeiten, und sobald es sich ändert, aktualisiert der Code-Generator den generierten Code automatisch. Wenn Sie benutzerdefinierten Code zu Ihren generierten Quellen hinzufügen möchten, empfehlen wir dringend, das Generation-Gap-Pattern anzuwenden, um generierten und manuellen Code klar zu trennen. Das Mischen von generiertem und manuellem Code ist ebenfalls möglich (wir haben das für einige unserer Kunden getan), erfordert aber einen wesentlich komplizierteren Code-Generator.

Die Eclipse-basierte EA-Bridge steht im Eclipse Marketplace zur Verfügung und enthält auch die in diesem Artikel besprochenen Beispiel-Codegenerierungs-Templates.

Bitte beachten Sie, dass das Projekt „EA-Bridge Live Codegen Example" nur ein Beispiel mit rudimentärer Fehlerbehandlung ist. Es ist nützlich, um schnell mit einem code-generierenden Prototypen zu beginnen, ohne eine Runtime-Instanz zu starten. Wenn Sie ernsthaft einen Code-Generator erstellen möchten, sollten Sie das innerhalb eines separaten Eclipse-Plugins tun, einen Builder oder eine Kontextmenü-Aktion registrieren und das innerhalb einer Eclipse-Runtime-Instanz starten.

Praxisbeispiel: AUTOSAR-Spezifikation aus dem EA-Modell

Dass sich dieser Ansatz auch für produktive, vollständig headless betriebene Pipelines ohne grafische IDE eignet, zeigt das AUTOSAR-Konsortium. Das Konsortium nutzt die EA-Bridge, um ein umfangreiches EA-Modell auszulesen, aus dem ein Java-basierter Code-Generator die AUTOSAR-Spezifikation erzeugt. 2020 ersetzten sie ihren eigenen Glue-Code zur EA-API durch die EA-Bridge — das Ergebnis war ein Performance-Gewinn von rund Faktor 10 beim Laden des Modells. Der gesamte Prozess läuft in CI-Pipelines, ohne dass eine Eclipse-IDE gestartet werden muss.

Dieses Beispiel zeigt, was „maßgeschneidertes Tooling auf EA-Modellen" in der Praxis bedeutet: ein Werkzeug, das genau auf das Ausgabeformat zugeschnitten ist (in diesem Fall eine Spezifikation) und zuverlässig und reproduzierbar läuft.

Die neue Generation: CLI-Werkzeug und VS Code Extension

Seit 2024 gibt es eine neue Generation der EA-Bridge: ein Rust-basierter Kern als CLI-Werkzeug, ergänzt um eine VS Code Extension als Oberfläche. Kein Eclipse notwendig — das CLI-Werkzeug lässt sich direkt in CI-Pipelines einbinden und lädt EA-Modelle rund zehnmal schneller als der EA-eigene XMI-Export. Wer heute neu mit EA-basierter Codegenerierung beginnt, greift besser zu diesem Ansatz. Der hier beschriebene Eclipse-Ansatz bleibt für Teams valide, die bereits auf einer Eclipse-Toolchain aufbauen.

EA Bridge →

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