Enterprise Architect mit Add-ins anpassen

Problem: Modellierungsaufgaben werden unzureichend unterstützt

Ein UML-Profil stellt sicher, dass alle benötigten Konzepte im Modell instanziiert werden können. Die Instanziierung kann jedoch kompliziert und zeitintensiv sein. Die MDG Technology for EMF zum Beispiel verwendet UML-Konzepte wieder, sofern sie geeignet sind, und führt Tagged Values nur für zusätzliche Eigenschaften ein. Folglich muss ein Benutzer die wenigen relevanten Eingabefelder in den Tiefen der Properties-Dialoge von Enterprise Architect finden. Die Benutzerfreundlichkeit, insbesondere für neue Benutzer, könnte durch ein Eingabeformular verbessert werden, das nur die relevanten Eigenschaften enthält.

Lösung: Model Assistants

Add-ins ermöglichen es, Enterprise Architect um zusätzliche Funktionalität zu erweitern, beispielsweise

• Eingabeformulare zum Erstellen oder Bearbeiten von Elementen und Connectoren,
• Synchronisation von Änderungen zwischen zwei Ansichten eines Elements auf verschiedenen Abstraktionsebenen oder
• Refactorings, die eine Änderung konsistent auf das gesamte Modell anwenden.

Diese Beispiele haben gemeinsam, dass sie sich auf eine Aufgabe konzentrieren und dem Benutzer helfen, sie effizient durchzuführen. Daher nennen wir sie Model Assistants. Model Assistants können manuell vom Benutzer über einen Menüeintrag oder automatisch nach bestimmten Änderungen im Modell aufgerufen werden.

Der Screenshot unten zeigt Enterprise Architect mit einem Add-in für EMF. Das Add-in bietet einen Model Assistant zum Bearbeiten von Elementen/Connectoren mit einem angewendeten Stereotype der MDG Technology for EMF. Dieser Assistant bietet zwei Varianten: Erstens ermöglicht das Kontextmenü eines ausgewählten Elements dem Benutzer, einen Dialog zu öffnen, in dem EMF-spezifische Eigenschaften bearbeitet werden können. Zweitens öffnet ein Hauptmenüeintrag ein benutzerdefiniertes Fenster, das dieselben relevanten EMF-Eigenschaften des ausgewählten Elements anzeigt. Wenn auf dem ausgewählten Element kein EMF-Stereotype angewendet ist, wird stattdessen eine Informationsmeldung angezeigt.

(Model Assistant zum Bearbeiten der Eigenschaften eines EMF-stereotypisierten Elements/Connectors)

Problem: Modellvalidität

Model Assistants helfen dem Benutzer, eine Aufgabe effizient durchzuführen, hindern ihn jedoch nicht daran, etwas zu tun, das das Modell verletzt. Zum Beispiel:

• Ein obligatorischer Tagged Value könnte versehentlich ohne Warnung in EA gelöscht werden und damit das UML-Profil verletzen. Ein Tool, das das Modell verarbeitet, könnte sich weigern, es zu laden, oder einen Standardwert für den fehlenden Tagged Value verwenden. Da der Standardwert nicht Teil des Modells ist, sind die daraus resultierenden Defekte schwer zu finden.
• Konzepte könnten falsch verwendet werden und ihre Semantik verletzen, z. B. durch Einführung einer zyklischen Vererbungsbeziehung. Ein Tool, das das Modell verarbeitet, sollte solche Defekte melden. Falls nicht, werden ungültige Artefakte generiert, die untersucht werden müssen, um einen im ursprünglichen Modell eingeführten Defekt zu finden. Dies ist eine nicht-triviale Aufgabe, insbesondere wenn das Modell und die Artefakte von verschiedenen Personen entwickelt werden.
• Modellierungskonventionen der Organisation oder des aktuellen Projekts könnten verletzt werden, z. B. durch die Verwendung von Namen mit Zeichen, die in Tools, die das Modell verarbeiten, verboten sind. Ein solches Tool erkennt die Verletzung möglicherweise nicht und schlägt entweder fehl oder generiert Artefakte, die den Defekt wiederholen. Wird die Verletzung später entdeckt, z. B. in einem Review, erfordert die Behebung auch die Anpassung von Artefakten, die auf den generierten basieren.

Folglich sollte die Modellvalidität häufig geprüft werden, um Defekte so früh wie möglich zu finden und die Kosten für deren Behebung zu reduzieren. Es stellt auch sicher, dass das Modell von anderen Tools weiterverarbeitet werden kann.

Lösung: Integrity Checks

Wir verwenden sogenannte Integrity Checks, um die Konsistenz und Gültigkeit des Modells zu prüfen. Sie stellen sicher,

• dass die Datenbank, die das EA-Modell enthält, konsistent ist.
  • EA’s Project Data Integrity Check stellt eine obligatorische Konsistenz sicher, einschließlich beispielsweise einer gültigen Containment-Hierarchie.
  • Zusätzliche Checks sind für Aspekte erwünscht, die von EA’s Integrity Check nicht abgedeckt werden, wie die Konformität zur verwendeten MDG Technology, z. B. werden fehlende obligatorische Tagged Values nicht automatisch hinzugefügt.
• dass das Modell konform zum UML-Standard und den verwendeten UML-Profilen ist.
  • Einen solchen Check bieten EA und die EA-Bridge. Ersterer basiert auf der Enterprise Architect API, während letzterer auf der Eclipse UML2 Implementierung basiert.
• dass das Modell konform zum Zielstandard und den Modellierungskonventionen ist.
  • Dies umfasst sowohl eine syntaktische als auch eine semantische Prüfung. Syntaktische Gültigkeit bedeutet, dass jedes Element und jeder Connector den Constraints der verwendeten Modellierungssprache entspricht. Semantische Gültigkeit ist strenger und erlaubt nur Elemente und Connectoren gemäß der Zieldomäne. Z. B. kann ein Connector zwischen einem bereitgestellten und einem erforderlichen Port derselben Komponente anwendbar, aber in der Domäne nicht erwünscht sein.

Integrity Checks können automatisch ausgeführt werden, z. B. wenn ein EA-Modell geöffnet wird, oder auf Anfrage des Benutzers. Oft ist es möglich, gefundene Probleme automatisch oder halbautomatisch zu lösen. Unsere Add-ins zeigen dem Benutzer typischerweise alle gefundenen Probleme an, sodass er sie überprüfen und entscheiden kann, wie jedes einzelne gelöst werden soll. Dies ist im Screenshot unten zu sehen, wo der Integrity Check meldet, dass ein obligatorischer Tagged Value fehlt, und vorschlägt, ihn als Lösung wieder hinzuzufügen.

Wie das in einer produktiven Toolchain aussieht, zeigt das Projekt mit KOSTAL: Der Automobilzulieferer prüft alle Constraints seiner UML-basierten AUTOSAR-Methodik direkt in Enterprise Architect und erhält sofortiges Feedback bei Verstößen. Zusätzlich lässt sich die Validierung im Standalone-Modus vor der Codegenerierung ausführen, was Konsistenz im gesamten Entwicklungsprozess sicherstellt. Referenz KOSTAL →

Problem: Rollout von MDG Technology und Add-ins

Sowohl MDG Technologies als auch Add-ins müssen für alle Benutzer, die mit dem Modell arbeiten, verfügbar sein. Während eine MDG Technology in das Enterprise Architect Modell eingebettet werden kann, ist dies mit Add-ins nicht möglich. Daher ist ein Rollout des Add-ins einschließlich aller erforderlichen Ressourcen wie einer MDG Technology erforderlich.

Lösung: Einen Installer anbieten

Anstatt MDG Technologies in EA-Modellen einzubetten, bevorzugen wir die Verteilung als Teil von Add-ins. Dies stellt sicher, dass Add-ins und MDG Technology immer kompatibel zueinander sind. Es kann jedoch vorkommen, dass ein Modell mit einer neueren Version des Add-ins bearbeitet werden soll. Wenn die neuere MDG Technology mit der alten inkompatibel ist, kann ein Integrity Check implementiert werden, um das Modell zu migrieren.

Ein Installer ist ideal für den Rollout des Add-ins, da er für Benutzer und Administratoren komfortabel ist. Ein weiterer Vorteil ist, dass Installer typischerweise eine vorherige Installation aktualisieren können. Installer sind beispielsweise mit dem WiX Toolset einfach zu implementieren, da es sich gut in die .NET IDE integriert, die typischerweise für die Add-in-Entwicklung verwendet wird.

Zusammenfassung

In diesem Artikel haben wir mehrere Probleme besprochen, die häufig bei der Verwendung von Enterprise Architect out-of-the-box auftreten und die mit einem Add-in gelöst werden können:

• Modellierungsaufgaben werden durch die Standard-UI von EA unzureichend unterstützt. Dazu gehört, dass der Benutzer zu viel Zeit mit der Navigation durch die EA-UI verbringt, das Fehlen benutzerdefinierter Eingabeformulare oder Refactorings. Wir lösen dies mit sogenannten Model Assistants, die dem Benutzer helfen, spezifische Aufgaben effizient durchzuführen.
• Enterprise Architect stellt nur eine grundlegende Konsistenz und Gültigkeit des Modells sicher. Wir empfehlen dringend zusätzliche Integrity Checks, um konsistente und gültige Modelle sicherzustellen, die weiterverarbeitet werden können.
• Add-in und MDG Technology müssen kompatibel und in allen EA-Instanzen verfügbar sein. Wir lösen dies durch die Verteilung der MDG Technology als Teil eines Add-ins und mit einem Installer für den Rollout des Add-ins.

Add-ins und externe Werkzeuge: zwei komplementäre Ansätze

Add-ins erweitern Enterprise Architect von innen: Sie nutzen die COM-Schnittstelle von EA, laufen im selben Prozess und können die EA-UI direkt steuern. Genau deshalb setzen wir sie für Model Assistants und Integrity Checks ein, die direkt im laufenden EA ablaufen.

Für die Verarbeitung von EA-Modellen außerhalb von EA — Codegenerierung, Validierung in CI-Pipelines, Dokumentationsgenerierung — sind externe Werkzeuge besser geeignet. Die Eclipse-basierte EA-Bridge lädt EA-Modelle als Eclipse-UML-Modelle und ermöglicht so die Nutzung des gesamten Eclipse-Modellierungsökosystems. Seit 2026 gibt es zusätzlich eine neue Generation der EA-Bridge als Rust-basiertes CLI-Werkzeug, das EA-Modelle direkt ohne Eclipse oder laufendes EA verarbeitet, geeignet für headless CI-Pipelines.

EA Bridge →

Wie EA-Modelle mit der EA-Bridge zur Codegenerierung und UML-Validierung verarbeitet werden, beschreiben die folgenden Artikel:

• Eclipse-basierte UML-Validierung von Enterprise-Architect-Modellen
• Eclipse-basierte Codegenerierung für Enterprise-Architect-Modelle
• UML-Profile in Enterprise-Architect-Modellen – Beispiel Codegenerierung

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