Menu

Seite450

Anonymous Joerg Reichert

4.5. Neuerung in openArchitectureWare 4.2

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.

Verknüpfen von Modellen

Grundlage: Video 06 von AMPLE

  • Referenzen vom Modellelement aus Modell M1 (m1.ecore) auf ein Modellelement aus Modell M2 (m2.ecore) im Workflow setzen.
  • [TODO] Screenshot des Workflows und Erklärung

Modell-Transformationen

Grundlage: Video 07 von AMPLE

1. Modell-Verschmelzung

  • zu verschmelzende Modelle folgen gleichem Metamodell
  • es liegt nur eine Modularisierung vor (ein großes Modell wurde in viele Teile zerlegt, die für den Einsatz wieder zusammengeführt werden (M = M1 + M2 + ... Mn)
  • Transformation ist in wirklich keine

2. Modell-Erweiterung zur Generierungszeit

  • das Modell wird um neue Elemente während der Generierungszeit ergänzt (als Java-Code vorliegendes Modell wird durch weiteren Java-Code (der dazu nur die bestehenden Klassen = Metamodellelemente verwendet, erweitert)
  • durch die Ergänzung ändert sich das Metamodell nicht, d.h. die Erweiterung ist Metamodell-konform

3. eigentliche Modelltransformation

  • Ausgangsmodell wird nicht verändert
  • Ausgangsmodell und Zielmodell folgen getrennten Metamodellen
  • Veränderungen an einem Modell verlangt keine Änderung am anderen Modell, nur die Transformationsbeschreibung muss geändert werden
  • identische Modellelemente existieren als Kopien (auch Kopien im Metamodell) (Transformation in dem Fall reine Kopierfunktion)

4. Mixin-Modelle

  • Modell der Transformationsbeschreibung von Modellen
  • Modell ist Parametrisierung der Transformation

Modelle erweitern

Grundlage: Video 08 von AMPLE

1. Spezialisierung

  • das neue Metamodell erweitert die Elemente eines anderen Metamodells
  • eine bereits vollständige Sprache wird so für den eigenen Anwendungsfall spezialisiert
  • nicht benötigte Elemente aus dem Ausgangsmodell können allerdings so nicht entfernt werden (vor allem Problem wenn man das komplexe Metamodell von UML erweitert)

2. Erweiterungsfunktionen

  • aus den Informationen im Ausgangsmodell werden über Funktionen weitere Informationen abgeleitet (z.B. Ausgangsmodell definiert Attribute Länge und Breite und mit der Erweiterungsfunktion wird Fläche berechnet)
  • Ausgangsmodell muss nicht geändert werden (es wird kein eigenes Attribut Fläche eingeführt)
  • abgeleitete Informationen müssen außerhalb des Modells bezogen werden (Funktion für die Berechnung der Fläche wird mit Modell nicht mitgeliefert)

3. Modellverwebung

  • eigenes Modell beschreibt eigene Elemente sowie Regeln wie diese in ein anderen Modell einzufügen sind (z.B. welche Eigenschaften ein Modellelement haben muss, damit es die Erweiterung bekommt, z.B. alle Elemente, die keine Beziehung zu anderen Elementen hat, bekommt ein zusätzliches String-Attribut abc), es können auch zusätzliche Metaklassen eingeführt werden
  • das Ausgangsmodell wird durch die Anwendung des Aspekt-Modells geupdatet
  • der Unterschied zwischen Ausgangs- und verwobenen Modell ist kaum oder gar nicht aufzulösen

4. Modelle verbinden

  • Metamodelle werden durch die Einführung von Relationen zwischen Elementen aus beiden Metamodellen verbunden (Element A aus M1 hat Referenz auf Element B aus Modell M2, auch mehrere Verknüpfungen denkbar)
  • die beteiligten Modelle müssen je nach Art der Relation nicht unbedingt von der Referenzierung wissen, z.B. unidirektionale Beziehung von A aus M1 auf B aus M2, bedeutet, dass M2 nichts von der Referenz weiß, in M1 wird M2 importiert und die Relation gesetzt)
  • setzt voraus, dass Metamodell-Referenzen von der Sprache des Metamodells unterstützt werden
  • setzt voraus, dass Transformationen und Generator mit mehreren Metamodellen arbeiten kann
  • in oAW mit XJoin-Funktionalität gelöst

5. Dynamische Eigenschaften

  • an Modellelementen könnte zusätzliche Eigenschaften in Form von Name-Wert-Paaren gespeichert werden (wie properties-Datei)
  • als Werte können auch Modellelemente verwendet werden
  • in oAW durch Libraries-Funktionalität unterstützt

6. Annotationen

  • externe Modelle enthalten zusätzliche Informationen über Elemente des Ausgangsmodells, indem deren Elemente eine Relationsship zur betreffenden Metaklasse des Ausgangsmodell aufbauen oder diese über deren id referenzieren
  • in EMF über Inter-Resource-Referenzen unterstützt

Libraries

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

  • Aspekt hat keine Entsprechung im Modell
  • der Aspekt, der von Produktlinie verlangt wird, wird vom Generator nicht unterstützt bzw. muss nicht unterstützt werden
    • z.B. verlangt die Auswahl von EJB 3.0, dass die für EJB 3.0 erforderlichen jars im Generat verfügbar sind, die jars lassen sich nicht generieren, sie sind feste Bausteine
    • durch die Konfiguration wird z.B. nur entschieden, ob eine Java-Klasse eingebunden werden soll oder nicht, die Klasse selbst muss nicht parametrisiert werden - sie könnte zwar als Template angelegt werden, wegen der fehlenden Parametrisierung ist dies aber nicht erforderlich
    • der feste Baustein ist unveränderlich und muss nur ins Generat kopiert werden

2. Nur als Modell

  • Aspekt hat Entsprechung im Modell
  • die Implementierung kann vollständig aus dem Modellelement / Teilmodell generiert werden und bedarf keiner weiteren Anpassung
  • ändert sich der Generator, ändert sich zwar auch der generierte Code, da aber keine manuelle Anpassung erforderlich ist, hat dies keine Auswirkung die Lauffähigkeit des generierten Produkts
  • Beispiel: Workflow-Beschreibung

3. Kombination von Modell und Code

  • Aspekt hat Entsprechung im Modell
  • aus dem Modellaspekt kann keine oder nur teilweise eine Implementierung generiert werden, es ist eine manuelle Anpassung bzw. Erweiterung der Implementierung erforderlich um ein lauffähiges Produkt zu erhalten
  • Beispiel: Geschäftslogik

Arten von Quellcode

1. ein Teil generiert, der andere Teil manuell geschrieben

  • Unabhängigkeit von der Plattform-Technologie
  • Ausgangscode wird generiert, der nach wohl definierter Vorgehensweise händisch erweitert werden muss
  • Beispiel: Geschäftslogik

2. Quellcode wird vollständig generiert

  • ist von spezifischen Plattform-Technologie abhängig
  • generierter Code ummantelt den Plattform-unspezifischen Code derart, dass ein lauffähiges Produkt entsteht
  • Beispiel: OSGI

Tracing

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.

Orthogonale Variabilität

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.

AOP auf Transformatiosebene

Grundlage: Video d von AMPLE

  • Interceptors in Libraries
  • AOP nun auch in den Extensions (oaw.xtend.XTendAdvice muss bei class bei der Workflow-Komponente dazu angegeben werden)
  • 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

  • alles andere wie in 4.1.2 bereits (AOP-Template, Around-Statement, mit ctx.process() wird der Inhalt der ummantelten Define-Methode ausgeführt

AOP auf Modellebene

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).

AOP auf Code-Ebene

Grundlage: Video f von AMPLE

AspectJ im Code verwenden

1. Abstrakter Aspekt-Klasse

  • abstrakte Klasse definiert Pointcut(s) und auch den Code, der an den Pointcut(s) geschrieben werden soll
  • Anwendung
    • wenn Aspekt angewendet werden soll, wird eine konkrete Klasse generiert, die die abstrakte Klasse erweitert
    • wenn Aspekt nicht angewendet werden soll, existiert nur die abstrakte Klasse, die selbst keine Funktionalität entfalten kann, weil sie ja abstrakt ist
  • Aspekte werden mit allen benötigten Dinge in der Library repräsentiert, durch Namenskonventionen in Kombination mit Recipe kann Richtigkeit des zusätzlichen manuellen Codes geprüft werden

2. Unvollständige Aspekte

  • generierte Aspektklasse ist nur Rumpf und muss durch manuell zu schreibenden Code ergänzt werden (Base-Klasse wird generiert und muss durch händisch geschriebene Klasse erweitert werden)
  • die selbst geschriebene Klasse muss nach AspectJ-Spezifikation abstrakt sein, in ihr werden die before- und after-Method Codeteile abgelegt

Negative Variabilität

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.

Testen

Grundlage: Video h von AMPLE

  • Domänenarchitektur testen
  • Produkt testen
    • spezfisches Produkt testen (Produkt, dass einer konkreten Konfiguration entspricht, Test ist Integrationstest)
    • Features(-kombinationen) testen (wenn Feature ausgewählt ist, werden automatisch entsprechende Testklassen generiert)
  • das Metamodell wird um das Konzept Testkomponente erweitert
  • die Tests müssen manuell geschrieben werden, es werden nur Stubs generiert, die eine Interface implementieren, dass die Implementierung der Methode runTest vorschreibt, damit sie vom TestRunner gefunden werden

Weiterentwicklung

Grundlage: Video j von AMPLE

  • Umsetzung neuer Anforderungen erfolgt nicht durch Hardcodierung sondern durch Abänderung des Feature Modells (und entsprechend des Konfigurationsmodells)
  • die Änderung im Konfigruationsmodell zieht eine Änderung der Transformationsbeschreibungen nach sich
  • meist reicht eine Verzweigung von der bestehenden Konfigurationsbehandlung in den Transformationen

[TODO]

  • Erkenntnisse aus den oAW-Videos noch mit einpflegen
  • Screenshots aus den Videos mit einpflegen

zurück zu 4.4 Erweiterungs- und Verbesserungsmöglichkeiten
weiter zu 5 Testen
zurück zu 4 Implementierung
zurück zu [FrontPage]


Related

Documentation: FrontPage
Documentation: Seite000
Documentation: Seite400
Documentation: Seite440
Documentation: Seite500