MOF QVT

QVT Spracharchitektur

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

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.

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.

1. OMG: MOF 2.0 Query / Views / Transformations RFP. ad/2002-04-10. Needham, MA: Object Management Group, April 2002. omg.org
2. 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
3. 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
4. borland.com (Memento des Originals vom 14. Dezember 2006 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.borland.com
5. smartqvt.elibel.tm.fr (Memento des Originals vom 9. Dezember 2006 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/smartqvt.elibel.tm.fr
6. ikv.de
7. tcs-trddc.com (Memento des Originals vom 19. November 2006 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.tcs-trddc.com
8. tefkat bei SourceForge
9. Model to Model Transformation - MMT - Eclipsepedia