MOF QVT

Query View Transformation (MOF QVT) ist eine Spezifikation der Object Management Group, die eine (Programmier-)Sprache für Modell-zu-Modell-Transformationen beschreibt. QVT ist Teil der Meta Object Facilities (MOF), einer Sammlung von Dokumenten der OMG zur formalen Definition von Modellen sowie deren Anwendung, wie sie etwa im Rahmen der modellgetriebenen Architektur (MDA) benötigt wird.

Bei der Diskussion ist zwischen Sprachen zu unterscheiden, die von Dritten als Antwort auf den „Request for Proposals“ (RFP) entworfen wurden und der Sprache QVT, wie sie in den Spezifikationen beschrieben ist.

So kann als einfaches Beispiel ein ER-Modell aus einem Klassenmodell durch Transformation erzeugt werden. Hierzu benötigt man im einfachsten Fall das Klassen- und ER-Modell und deren jeweiliges Metamodell sowie eine Vorschrift, wie das ER-Modell aus dem Klassenmodell zu erzeugen ist. Diese Vorschrift kann in einer der QVT-Sprachen beschrieben werden. Als besonders typisches Beispiel kann ein (rein fachliches) Analysemodell in ein (technisches) Designmodell transformiert werden, das heißt die Transformation fügt die Technik, in der das Modell realisiert werden soll, zum Analysemodell hinzu.

Das Akronym QVT steht für queries (Anfragen), views (Sichten) und transformations (Transformationen). Unter Anfragen versteht MOF formale Ausdrücke, mit denen einzelne Elemente eines Modells ausgewählt werden können; Sichten sind komplexe Anfragen, mit denen ganze Abschnitte aus einem Modell ausgewählt werden; mit Transformationen werden Beziehungen zwischen Modellen dargestellt. Trotz des Namens QVT versteht man unter MOF QVT jedoch meist nur einen Standard zur Beschreibung von MOF-Modelltransformationen, da diese als das Hauptanwendungsgebiet von QVT betrachtet werden und Queries und Views sich ohnehin als Teile einer Transformation interpretieren lassen.

Aufbau

QVT Spracharchitektur

Die QVT Spezifikation definiert zwei Arten von Sprachen: deklarative und imperative. Der deklarative Teil besteht aus den Sprachen QVT-Relations und QVT-Core sowie einer Abbildung der Relations auf die Core Sprache RelationsToCoreTransformation. QVT-Core verhält sich zu QVT-Relations wie Java-Bytecode zu Java-Quellcode und ist für Endanwender daher von untergeordneter Bedeutung. Der imperative Teil enthält die Sprache Operational Mappings Language sowie Vorgaben für Black Box Implementations, also eine Schnittstelle für außerhalb von QVT implementierte Transformationssprachen.

Deklarative und imperative Sprachen können auf folgende Weise gemeinsam verwendet werden: Es ist möglich, einzelne Relationen in einer relationalen Transformation in einer der imperativen Sprachen zu implementieren und diese in die relationale Transformation als plug-in quasi einzuklinken. Dies kann sinnvoll sein, um besonders komplexe Algorithmen zu implementieren oder vorhandene Programmbibliotheken wiederzuverwenden.

Nachfolgend ein simples Beispiel einer Transformation in der Sprache Operational Mappings, welche jede persistente Klasse eines UML-Modells auf eine Tabelle in einem Entity-Relationship-Modell abbildet.

   -- Transformation von einem 'UML' Modell auf ein 'ERM' Modell

 transformation uml2erm( in uml : UML, out erm : ERM )

   -- Einstiegspunkt

 main() {
   uml.objects()[#Class]->map class2table();
 }

   -- Abbildung von Class auf Table

 mapping Class::class2table() : Table
   when { self.stereotypes->includes('persistent') }
   {
     name := self.name;
   }

Das Beispiel enthält die beiden OCL-Ausdrücke uml.objects()[#Class], welcher alle Klassen des UML-Modells selektiert, und self.stereotypes->includes('persistent'), der prüft ob die Klasse (self) vom Stereotyp 'persistent' ist. Die Methode main() bildet den Anfangspunkt des Programms. Sie wendet auf alle Klassen des UML-Modells das Mapping class2table an, das aus der übergebenen Klasse eine Tabelle im ER-Modell erzeugt.

Das QVT-Metamodell (welches QVT definiert) baut auf den Metamodellen von EMOF und Essential OCL auf. Letzteres wird um imperative Funktionen erweitert (imperative OCL).

Anwendung

Voraussetzungen: QVT-Transformationen basieren auf den Metamodellen der jeweiligen In- und Output-Modelle. Diese müssen daher zur Ausführung der Transformation vorliegen. Durch die Verwendung der Metamodelle können Abbildungen auf Basis der Elementtypen definiert werden. Auf diese Weise kann eine Transformation eine Abbildung so definieren, dass beispielsweise alle Elemente vom Typ EntityType aus einem ER-Modell auf je ein Element vom Typ Klasse im Klassenmodell transformiert werden. Die Metamodelle müssen für QVT mittels der MOF beschrieben sein.

Die Bedeutung von QVT liegt in der Modell-zu-Modell-Transformation im Rahmen von modellgetriebener Architektur. Im Gegensatz zur bisher weitgehend üblichen Modell-zu-Code-Transformation, kann so ein Platform Specific Model (PSM) nicht nur als Source-Code, sondern als Modell erstellt werden. Aus diesem kann dann später in einem zweiten Schritt der Source-Code generiert werden. Somit verfügt man durch das PSM als echtes Modell auch auf der Ebene der technischen Architektur über die Vorteile der Modellierung gegenüber einer rein Source-Code-basierten Softwareentwicklung (siehe hierzu auch Unified Modeling Language oder Software Engineering).

Typische Einsatzszenarien für QVT-Sprachen sind:

• Verifikation von Modellen
• Uni- und Bidirektionale Modell-Transformationen (N-direktionale sind ebenfalls möglich aber von geringer Relevanz)

Im Rahmen von Transformationen können Elemente von Modellen erzeugt, ersetzt, oder gelöscht werden. Hierzu können Traces zwischen Modellen gepflegt werden. Dies sind Zuordnungen zwischen Elementen der verschiedenen Modelle, die besagen welches Element auf welches abgebildet wurde. Dies ist notwendig, um Elemente konsistent erzeugen, ersetzen oder löschen zu können.

Implementierungen

Hier ist zwischen Implementierungen auf Basis des RFP und der Spezifikation zu unterscheiden, bei letzterer noch, welcher Teil (operational, relational, Core) umgesetzt wurde und welche Version der Spezifikation als Referenz dient. Handelt es sich um Antworten auf den RFP, so wurden „nur“ die im RFP beschriebenen Anforderungen (teilweise) umgesetzt, Umfang und Syntax der Sprachen können sich also stark voneinander unterscheiden.

Name	Hersteller (Distributor)	QVT Operational	QVT Relational	QVT Core	Lizenz	Anmerkung
Borland Together Architect	Borland	X			kommerziell	basiert auf Vorversion der Spezifikation
SmartQVT	France Telecom R&D	X			Open Source (EPL)	Java-basierte Umsetzung, Eclipse-Plugin
medini QVT	ikv++ technologies ag		X*		Open Source (EPL)	* unterstützt noch keine Collection-Patterns
ModelMorf	TRDDC		X*		kommerziell	* nicht vollständig
Tefkat	University of Queensland (SourceForge)				Open Source (LGPL)	Eclipse-Plugin, verwendet EMF
Atlas Transformation Language	ATLAS INRIA & LINA (Eclipse Foundation)				Open Source	Hybride Sprache (kombiniert relationale und operationale Konzepte)
Eclipse MMT Projekt	Eclipse Foundation	geplant			Open Source (EPL)	Operationaler Teil befindet sich im Eclipse Incubator, Testversionen (des operationalen Teils) sind verfügbar.