Folgender noch zu schreibender Inhalt wird auf Grundlage von den Video-Tutorials des AMPLE-Projekts und die direkt auf der openArchitectureWare-Seite selbst erstellt worden sein.
Grundlage: Video 06 von AMPLE
Grundlage: Video 07 von AMPLE
1. Modell-Verschmelzung
2. Modell-Erweiterung zur Generierungszeit
3. eigentliche Modelltransformation
4. Mixin-Modelle
Grundlage: Video 08 von AMPLE
1. Spezialisierung
2. Erweiterungsfunktionen
3. Modellverwebung
4. Modelle verbinden
5. Dynamische Eigenschaften
6. Annotationen
Grundlage: Video 09 von AMPLE
Library-Komponenten sind vordefinierte Bausteine, die je nach Konfiguration des zu generierenden Produkts an bestimmten Stellen eingebunden werden müssen oder nicht.
Arten von Libraries
1. Reiner Code
2. Nur als Modell
3. Kombination von Modell und Code
Arten von Quellcode
1. ein Teil generiert, der andere Teil manuell geschrieben
2. Quellcode wird vollständig generiert
Grundlage: Video b von AMPLE
Nachspüren von Modell-zu-Modell- und Modell-zu-Code-Transformationen: wie werden die Anforderungen in der Software-Konfiguration umgesetzt
Mappings zwischen den Abstraktionsebenen werden durch formale Transformationen beschrieben, die Anwendung der Transformationen kann geloggt werden, indem an den ensprechenden Stellen die Funktion
createTrace(Modellelement, "Transformationsbeschreibung")
im Transformationscode in den oAW Extensions bei M2M aufgerufen wird oder
<VTRACE(Modellelement, "Transformationsbeschreibung")>
in den Templates bei M2C aufgerufen wird (im generierten Code wird dadurch ein Kommentar eingefügt, der angibt, was die Quelle der Transformation war).
Bisherige Nachverfolgungsmethodiken zogen nur die Beziehung zwischen Anforderung und generierten Artefakten, mit dieser Technik, wird die Spur zwischen einzelnen Modellelementen offenbart.
Das Mapping derr Elemente aus dem CIM über das PIM und PSM bis in den Code kann nun nachvollzogen werden. (von den Modellen des Problemraums zu Anwendungsmodellen und Implementierungs-Modellen des Lösungsraum)
Über die Trace-Funktion wird ein Trace-Modell im Hintergrund erzeugt. Das Modell wird als EMF-Modell angelegt und als xmi exportiert. Man kann zusätzlich neben xmi das Modell nach HTML exportieren.
Bei M2M speichert jeder Eintrag From (Ausgangsmodellelement), To (Zielmodellelement) und Kind (Transformationsbeschreibung). Bei M2C wird als Ziel die Java-Datei gespeichert. In der HTML-Ansicht sind Quelle und Ziel als Link angelegt, so dass man zum betreffenden Modellelement oder zur betreffenden Java-Datei browsen kann.
Grundlage: Video c von AMPLE
Orthogonale Variabilität bedeutet, dass die Variablitäten außerhalb der Modelle in einen eigenen Feature-Modellen beschrieben werden.
Konfigurationsmodelle werden auf Basis der Feature-Modelle erstellt, indem die Variablitäten aus dem Feature-Modell vollständig aufgelöst werden (also eine bestimmte Auswahl = Konfiguration getroffen wird).
Die Konfigurationsmodelle werden vom Generator konsumiert.
In oAW besteht die Möglichkeit eine Reihe von Feature-Modeling-Werkzeugen anzubinden (FMP?, XFeature (xfm)?, pure::Variants (vdm)). Ein Textdatei, in der alle anzuwendenden Features aufgelistet sind tut es aber auch. Das so am Anfang des oAW-Workflows eingelesene Konfigurationsmodell ist dann im gesamten Workflow-Prozess global verfügbar.
Grundlage: Video d von AMPLE
im Workflow kann mit
<feature exists="feature.name">
<component adviceTarget="" ...="">
...
</component>
</feature>
jetzt geprüft werden, ob ein Feature ausgewählt wurde(wird aus dem global verfügbaren Konfigurationsmodell ausgelesen), wenn ja, wird die Advice-Komponente angewendet
Grundlage: Video e von AMPLE
Über Modell Weaving können bestehende Modelle um Aspekte erweitert werden. Die Aspekt-Modelle werden auf Basis des gleichen Metamodells definiert, wie das eigentliche Modell. Die Modellelemente bekommen Namen wie %name, um sie so als Pointcut zu definieren. An diesen Elementen werden dann die Erweiterungen vorgenommen. In den Pointcut-Expressions wird dann definiert, in welchen Fällen die Erweiterungen unter dem Element %name anzuwenden sind. Die Pointcut-Expressions werden in einer Xtend-Datei gespeichert, die bei
Anwendung des Model-Advices mit einbezogen wird.
<cartridge file="org/openarchitectureware/util/xweave/wf-weave-expr" baseModelSlot="Ausgangsmodell" aspectFile="pfad/zu/Aspektmodell.xmi" expressionFile="paket:pointcut_regeln" />
Erweiterungen im Modell verlangen in der Regel auch Anpassungen in den Transformationsbeschreibungen (es sei denn, diese sind so generisch, dass sie auch das veränderte Modell korrekt und vollständig interpretieren und umwandeln können). Für die Templates und Erweiterungen müssen in der Regel entsprechend auch Advices mit eingebunden werden.
Advices drücken positive Variablität aus (es wird erweitert). Für negatitive Variablität muss in den Transformationen geprüft werden, ob bestimmte Features selektiert wurden sind und dann bei Nicht-Selektierung die Anwendung entsprechenden Transformationen unterbunden werden (if-else-Verzweigung).
In den Extensions wird dies mit der Funktion hasFeature("feature.name") oder isFeatureSelected("feature.name") bewerkstelligt. Die Funktionen liefern einen Boolean-Wert zurück an Hand dessen entschieden werden kann, ob bestimmte Transformationen angewendet werden sollen oder nicht.
Mit der Funktion getFeatureAttributeValue("Attribut1", "Attribut2") können eventuell vorhandenen Attribute eines Features geholt werden (soweit so was überhaupt mit dem eingesetzten Feature-Modeling-Werkzeug modellierbar war).
Grundlage: Video f von AMPLE
AspectJ im Code verwenden
1. Abstrakter Aspekt-Klasse
2. Unvollständige Aspekte
Grundlage: Video g von AMPLE
Werden im Konfigurationsmodell bestimmte Features nicht ausgewählt, müssen die dem Feature zugehörigen Modellelemente aus dem Modell entfernt werden.
Die Abhängigkeiten von Modellelementen und Features aus dem Konfigurationsmodell werden in einem eigenem Modell, dem Dependency-Model, modelliert, damit das Modell selbst nicht vom Konfigurationsmodell abhängt (das Metamodell des strukturellen Models muss so nicht abgeändert werden, um konfigurierbar zu sein.)
In openArchitectureWare 4.2 existiert dafür das neue Konstrukt XVar.
Beispiel: Aspekt-Element im Modell und Feature (wenn Feature selektiert, wird Aspekt angewendet, wenn Feature nicht selektiert ist, braucht es das Aspekt-Element im Modell nicht mehr)
XVar löscht alle betroffenen Elemente und auch die Referenzen auf die Elemente von nicht betroffenen Elementen aus dem Modell, wenn das Feature nicht selektiert ist.
Aufpassen muss man mit manuell geschriebenen Code: durch das Löschen der Elemente werden nun bestimmte Codeteile (Methoden, Klassen) nicht mehr generiert oder anders generiert. Manuell geschriebener Code muss entsprechend angepasst werden. Gleiches gilt für mit den gelöschten Modellelement verbundenen statischen Elemente, die möglicherweise noch im Generat rumschwirren.
Variable Code-Sektionen können durch eine spezielle Syntax markiert werden:
//# featureName ... //~# featureName
Dieses Codestück wird gelöscht, wenn das Feature nicht selektiert wurde. Eine Klasse, die solche variablen Code-Teil enthält wird als javav-Datei angelegt.
Im Workflow wird mit
<cartridge file="org/openarchitectureware/util/xvar/file/fw-xvarfile.oaw" sourcePath="project/src" sourceExt="javav" genPah="project/src-gen" genExt="java" useComments="false" />
dann das Löschen (useComments="false") bzw. auskommentieren (useComments="true") der betreffenden Codeteile gesteuert, indem die .javav-Datei unter src als Grundlage genommen wird und entsprechend modifiziert als eine .java-Datei in src-gen abgelegt wird.
Grundlage: Video h von AMPLE
Grundlage: Video j von AMPLE
zurück zu 4.4 Erweiterungs- und Verbesserungsmöglichkeiten
weiter zu 5 Testen
zurück zu 4 Implementierung
zurück zu [FrontPage]
Documentation: FrontPage
Documentation: Seite000
Documentation: Seite400
Documentation: Seite440
Documentation: Seite500