- 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 Model Driven Architecture (MDA) benötigt wird.
Bei der Diskussion ist zwischen Sprachen zu unterscheiden, die von Dritten als Antwort auf den "Request for Proposals" (RFP)[1] entworfen wurden und der Sprache QVT, wie sie in den Spezifikationen[2] [3] 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.
Inhaltsverzeichnis
Aufbau
Die QVT Spezifikation[3] 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, undself.stereotypes->includes('persistent')
, der prüft ob die Klasse (self) vom Stereotyp'persistent'
ist. Die Methodemain()
bildet den Anfangspunkt des Programms. Sie wendet auf alle Klassen des UML-Modells das Mappingclass2table
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 Model Driven Architecture. 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[1] und der Spezifikation[3] 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[4] Borland X kommerziell basiert auf Vorversion der Spezifikation SmartQVT[5] France Telecom R&D X Open Source (EPL) Java-basierte Umsetzung, Eclipse-Plugin medini QVT[6] ikv++ technologies ag X* Open Source (EPL) * unterstützt noch keine Collection-Patterns ModelMorf[7] TRDDC X* kommerziell * nicht vollständig Tefkat[8] 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 M2M Projekt[9] Eclipse Foundation geplant Open Source (EPL) Operationaler Teil befindet sich im Eclipse Incubator, Testversionen (des operationalen Teils) sind verfügbar. Literatur
- ↑ a b OMG: MOF 2.0 Query / Views / Transformations RFP. ad/2002-04-10. Needham, MA: Object Management Group, April 2002. omg.org
- ↑ OMG: Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Final Adopted Specification ptc/07-07-07. Needham, MA: Object Management Group, July 2007. omg.org
- ↑ a b c OMG: Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Version 1.0 formal/08-04-03. Needham, MA: Object Management Group, April 2008. omg.org
- ↑ borland.com
- ↑ smartqvt.elibel.tm.fr
- ↑ ikv.de
- ↑ tcs-trddc.com
- ↑ tefkat bei SourceForge
- ↑ eclipse.org
Wikimedia Foundation.