Query View Transformation ( QVT MOF ) is a specification of the Object Management Group, which describes a (programming ) language for model-to -model transformations. QVT is part of the Meta Object Facilities (MOF), a collection of documents of the OMG for the formal definition of models and their application, as required for example in the context of Model Driven Architecture ( MDA).

The discussion is to distinguish between languages ​​that have been designed by third parties in response to the " Request for Proposals " (RFP ) and the QVT language, as described in the specifications.

May be generated from a class model as a simple example of an ER transformation model. This requires, in the simplest case, the class and the ER model and their respective meta-model, as well as a provision, such as the ER model to be generated from the class model. This provision can be described in one of the QVT languages. As a very typical example, a ( purely professional ) analysis model is transformed into a (technical ) design model, ie, the transformation adds the technology, in which the model is to be implemented, the analysis model added.

The acronym stands QVT (views) and " transformations " ( transformations ) for " queries" ( queries ), " views". Subqueries MOF understands formal expressions with which individual elements of a model can be selected; Views are complex questions with which all sections are selected from a model; with transformations relations between models are presented. Despite the name, QVT time although the MOF QVT usually only one standard for the description of the MOF model transformations, as these are considered as the main field of application of QVT and queries and views can already be interpreted as parts of a transformation.


The QVT specification defines two kinds of languages ​​: declarative and imperative. The declarative part consists of the languages ​​of QVT Relations and QVT - Core and an image of the relations to the core language RelationsToCoreTransformation. QVT Core is related to QVT Relations, such as Java bytecode to Java source code and is for end users, therefore, is of secondary importance. The imperative part contains the language Operational Mappings Language and specifications for Black Box Implementations, ie an interface for outside implemented by QVT transformation languages ​​.

Declarative and imperative languages ​​may be used together in the following manner: It is possible to implement individual relations in a relational transformation into one of the most imperative languages ​​and this hook into the relational transformation as a plug-in quasi. This can be useful to implement more complex algorithms or reuse existing program libraries.

The following is a simple example of a transformation in the language of Operational mapping, which maps each persistent class of a UML model to a table in an Entity -Relationship Model.

- Transformation of a ' UML ' model to a ' ERM ' model     transformation uml2erm ( in uml: UML, erm out: ERM)       - Entry point     main () {     uml.objects () [# Class ] -> map class2table ();   }       - Mapping of class on Table     mapping Class :: class2table (): Table     When { self.stereotypes -> includes ( 'persistent ')}     {       name: = self.name;     } The example contains two OCL expressions uml.objects () [# Class ], which selects all the classes of the UML model, and self.stereotypes -> includes ( ' persistent' ), which checks whether the class (self) from the stereotype ' persistent' is. The main () method is the beginning point of the program. It applies to all classes of the UML model to the mapping class2table that generates from the passed class a table in the ER model.

The QVT metamodel (which is defined QVT ) is based on the metamodels of EMOF and Essential OCL. The latter is imperative to extended functions ( imperative OCL).


Requirements: QVT transformations are based on the metamodels of the respective input and output models. These must therefore be present to perform the transformation. By using the meta-models pictures can be defined on the basis of element types. In this way, a transformation can define a mapping such that, for example, all elements of type EntityType of an ER model will be transformed to each an element of type class in the class model. The meta-models must be described by means of QVT for the MOF.

The importance of QVT is the model-to- model transformation in the context of Model Driven Architecture. In contrast to the previously widely applied model-to- code transformation, a Platform Specific Model ( PSM) can be created not only as source code but as a model. From this it can then be generated later in a second step, the source code. Thus, one has by the PSM as a real model at the level of the technical architecture of the advantages of modeling over a purely source - code - based software development (see also Unified Modeling Language or Software Engineering ).

Typical application scenarios for QVT languages ​​are:

  • Verification of models
  • Unidirectional and bidirectional model transformations (N -directional are also possible but of little relevance )

Under transformations elements of models can be created, replaced, or deleted. To this end, traces can be maintained between models. These are mappings between elements of different models, which say which element was mapped to that. This is necessary to create, replace, or delete elements consistent.


Here's to distinguish between implementations based on the RFP and the specification has been implemented with the latter still, what part (operational, relational, core) and which version of the specification as a reference. Is it responses to the RFP, as were "only" implemented the requirements of (partially) described in the RFP, scope and syntax of languages ​​so can differ greatly.