Embedded-Elements im Project Browser

Elemente mit Embedded-Elements

Im Diagramm werden Embedded-Elements immer am Container-Element angeheftet dargestellt. Sie können am Element verschoben werden, aber nicht vom Element entfernt, d.h., entfernt können sie schon werden, allerdings nur vom Diagramm.

Wird ein Embedded-Element mit [Entf] vom Diagramm gelöscht, verschwindet die grafische Repräsentation. Mit [Strg] + [Entf], nach Auswahl des Elements in der Grafik, wird das Embedded-Element gänzlich aus dem Modell gelöscht!

Soweit so gut, nun können Elemente aus dem Project Browser in beliebigen weiteren Diagrammen verwendet (verlinkt) werden. Dadurch wird eine neue grafische Repräsentation erstellt. Beim Einfügen von Elementen mit enthaltenen Embedded-Elements, kann ausgewählt werden, ob diese mit eingefügt werden sollen. Falls später noch weitere Embedded-Elements hinzu kommen, werden diese nicht automatisch in das Diagramm eingefügt! Ein Manueller Update kann, wie unten beschrieben durchgeführt werden. Ein automatischer Diagramm-Update kann mittels Scripts bzw. Add-in realisiert werden.

Einfüge Dialog für Elemente

Alle Embedded-Elements eines Elementes (auch geerbte) können nachträglich im Diagramm angezeigt werden. Diese können durch Auswahl des Container-Elements + rechte Maustaste + Auswahl des Menüeintrags Embedded Elements eingesehen und aktiviert werden. Alternativ können auch Embedded-Elements per drag and drop vom Project Browser in das Diagramm mit dem Container-Element eingefügt werden.

Dasselbe Vorgehen kann auch für UML/SysML Parts angewendet werden. Ein Part wird in UML Composition Structural Diagrams verwendet bzw. in SysML Internal Block Diagrams.
Dabei wird eine Komponente oder Block, etc. über einen Block oder Komponente gezogen. Dabei kann ausgewählt werden, ob das Element als Part oder Port eingefügt werden soll. Fügt man es als Part ein, erhält man ein neues Element, dessen Typ (dessen Classifier) der Block oder die Komponente ist.

Drag and Drop eines Elements über ein anderes Element

Hat nun zum Beispiel der Block oder die Komponente, welche als Typ (Classifier) verwendet wurden, Parts, werden diese nicht automatisch angezeigt. Durch Auswahl des neu angelegten Parts und durch Verwendung des Kontextmenüeintrags: Embedded Elements->Embedded Elements…, können, wie oben beschrieben, alle Embedded Elements angezeigt werden. Da das Embedded-Element nicht am Part, sondern an dessen Classifier definiert wurde, muss in diesem Fall Show Owned/inherited ausgewählt werden!

Embedded-Elements Menü

Ein automatisches Einfügen aller Embedded-Elements in ein Diagramm ist momentan nicht vorhanden, kann aber mittels Script/Add-in realisiert werden!

Durch ein Versioniertes Package erhalten Sie laufend Backups Ihrer Modelle (alternativ können auch Base-Lines verwendet werden).
Die Verwendung von versionierten Packages kann auch zur Realisierung von Team-Kollaboration verwendet werden, da ein unter Versionskontrolle stehendes Package nur von einem Client gleichzeitig ausgecheckte sein kann (pessimistisches Versionieren).

Die Kommunikation mit dem Versionskontrollsystem wird von EA übernommen.
Hin und wieder passiert es, dass EA und das Versionskontrollsystem out-of–synch gerät.
Das Resultat ist die Fehlermeldung, dass ein im EA als ausgecheckt markiertes Package eingecheckte werden soll, dies aber nicht geht, weil  es bereits eingecheckte ist.

Ab Version 7.5 gibt es den Menüpunkt Re-Synch Status With VC Provider… der EA und das Versionskontrollsystem wieder synchronisiert.

Aus den transformierten PSM Modellen kann Code generiert werden! Soweit der modellgetriebene  Top-Down Ansatz.
JUnit und NUnit Tests können nun ausgeführt werden, es wäre wünschnswert die Ergebnisse der Unit-Tests in das Modell zu integrieren.
Nun, wenn JUnit und NUnit Klassen als Modell im EA vorhanden sind (Top-Down generiert und fertig implementiert oder reverse engineered) kann dies auch realisiert werden !!!

Durch die Build-Umgebung im EA können Tests automatisch angetriggered werden und Ergebnisse automatisch in das EA Modell integriert werden.

Voraussetzung dafür ist, dass die Unit-Klassten im Modell vorhanden sind und dass das Anstoßen der Testumgebung über die Kommandozeile möglich ist. Folgende Grafik zeigt eine Beispielconfiguration für NUnit-Tests.

Aufruf der Tests geschieht über Project | Build and Run | Test

Ergebnisse des Tests werden im EA Output-Fenster angezeigt und in das Modell übernommen. Eventuelle Fehler im Test werden angezeigt, der Code wird per doppelklick im EA (bzw. der konfigurierten IDE angezeigt) angezeigt.

Aufgezeichnete Log im Modell:

Failed at 05-Jul-2006 1:02:08 PM
expected: <0>
but was:  <1>

Failed at 28-Jun-2006 8:45:36 AM
expected: <0>
but was:  <2>

Weiterführende Links: blog.lieberlieber, SD aus NUnit Tests aufzeichnen

Bei meiner Installation EA 8.0 Build 852 hatte ich das TOGAF Framework installiert, dies hat die Erstellung meiner Profile dahingehend beeinflusst, dass sie beim Export nicht richtig interpretiert wurden und somit meine Technologie nicht vollständig war.

Im konkreten handelt es sich um die Extend-Beziehung zwischen Meta-Elementen und Stereotype-Elementen. Bei aufgedrehtem TOGAF Framework wurde ein anderer Typ von Extend-Beziehung erstellt und beim Export fehlte das <AppliesTo> Tag. Damit war das Profil korrupt und wurde nach Erstellung der MDG Technology und nach dem Import nicht richtig angezeigt!

Vorübergehende Lösung ist, TOGAF während der Erstellung der Profile abzuschalten (Settings | MDG Technologies).
Dieser Fehler wurde bereits registriert und wird in folgenden EA Versionen behoben werden. 

Nach Export des Profils (in diesem Fall Diagram-Profile, identisch beim Toolbox-Profile) muss für jeden Stereotyp auch ein <AppliesTo> vorhanden sein!

Auch für Modelle welche in C gegossen werden sollen ist es möglich Code aus Verhaltensmodellen zu generieren. Allerdings muss unter ‘Tools | Options | Source Code  Engineering | C ‘ die Option Object Oriented Support auf true gesetzt werden!

Ist diese Option gesetzt werden unter ‘Settings | Code Generation Templates‘ für die Sprache C andere Templates angezeigt!
Dies ist leicht erkennbar, da nun auch die Templates State, Activity, etc. befüllt sind.
Der Unterschied beläuft sich allerdings nicht nur auf befüllte Templates für die Verhaltenscode Generierung, sondern auch alle anderen Templates unterscheiden sich und können angepasst werden.

Zusammenfassend, mit der Option ‘Tools | Options | Source Code  Engineering | C ‘ die Option Object Oriented Support’ auf true oder false gesetzt, werden zwei unterschiedliche Sets an Templates für die Generierung von C Code geladen.

Hinweis: Beim Export der editierten Templates, egal ob Object Oriented Support = true | false werden immer beide alle Änderungen in beiden Template Sets exportiert. D.h. in den exportierten Referenzdaten für C Templates befinden sich die Änderungen sowohl von Object Oriented Support = true also auch von Object Oriented Support =  false.

Export der Code Generierungstemplates für C

Wenn die GUIDs beibehalten werden (nicht möglich im selben Projekt, weil sie ja eindeutig sind!) können die zwei Kopien (in verschiedenen EA Projekten) zu einem späteren Zeitpunkt verglichen werden. Die Differenz der Packages kann eingesehen werden und ein differenzierter Merge ist möglich.

Mit der EA Version 8.0 ist dies natürlich immer noch möglich! Hinzugekommen ist allerdings, dass Packages nicht erst als XMI exportiert werden müssen um es anschließend wieder importieren zu können. Ab 8.0 gibt es die Option ein Package in das Clipboard zu kopieren und wieder einzufügen. Dies funktioniert nicht nur in einer EA Instanz und somit in einem Projekt, sonder auch zwischen EA Instanzen und somit zwischen EA Projekten!

Einziger “Nachteil” ist im momentan, dass beim einfügen vom Clipboard immer die GUID neu generiert wird. Falls die GUID beibehalten werden soll kann aber immer noch der XMI Export und Import verwendet werden.

Um nun Code-Refactorings in das Modell zu bekommen kann dies durch importieren des Source-Directories erreicht werden.  Dazu wird das namespace root Package ausgewählt, anschließend mittels Import Source Directory (siehe Bild)das Source-Verzeichnis des Codes ausgewählt und importiert.

Namespace Root im Project Browser

Beim Import des Soruce-Directories wird das ausgefühlte Source-Verzeichnis durchsucht und mit dem aktuellen Modell synchronisiert (synchronice muss selektiert sein!). Falls eine Klasse umbenannt oder verschoben wurde, wird diese neue angelegt. Die alten Klassen im Modell (alle Klassen die im Code nicht vorhanden waren), werden über ein Property-Fenster zum Löschen angeboten.

Hinweis: Import Source-Directory verhält sich so wie ein Reverse-Engineering! Änderungen im Modell werden verworfen da das Modell mit dem Code synchronisiert wird.