Bemerkungen zur QVTo -Implementierung

Explizite Model - Type Deklaration

modeltype UML2 uses "http://www.eclipse.org/uml2/4.0.0/UML";

Alternativ kann nach [RDEC2008] auch ein Metamodell implizit bestimmt werden, aber dann kann natürlich der Editor nicht bei der Auswahl der Strukturen helfen - damit nimmt man das wesentlichen Vorteil der Eclipse-Syntaxsteuerung.

. und -> - Notation

ist die OCL-Teilsprache

disjunct verfeinert polymorphe Beziehungen oder disjunkte Bedingungen

vergl. PJB

mapping Type::toType() : EClassifier
disjuncts Class::toClass,Enumeration::toEnum
{}

mapping Class::toClass() : EClass
{
//...
}

mapping Enumeration::toEnum() : EEnum
{
 //...
}

Mapping funktioniert nur 1:1

... sonst braucht man einen extra Parameter.
Beim Beispiel Zustandsautomat zu Klassen sieht man, dass die Transitionen einmal in die Oberklasse eingehen, und ein zweites Mal bedarfsweise in die konkrete Zustandsklasse. Die Lösung ist ein zusätzlicher Parameter, damit die QVTo-Maschine das mitbekommt.
siehe Diskussion "second mapping steals first one"

Eigene Beispiele:

• Zustandsautomat zu Klassendiagramm
• Komponentendiagram/Ports zu Monitoring Administration
  Hier die Grundidee, dass man Designregeln in OVTo formuliert, und diese dann auf ein Model schrittweise anwendet.

Weitere Beispiele:

ECore2UML

David T: "Betrachtung der Transformationssprache QVT operational innerhalb der Eclipse-Plattform" Seminarabeit RWTH Aachen 2011

beschreibt UML zu ECore-Transformation als Beispiel