Query, Views, and Transformations (QVT)

To deliver the two main features of model mappings, construction and synchronization, mappings must be executed automatically. This also shortens turnaround times, scales up to large models, and helps avoid manual work, which results in fewer errors and therefore improves overall quality.

Obviously, the rules that define a mapping have to be provided in a machine-readable manner to make them executable. This requires a formalism in which the rules can be expressed; the models must be formalized too, so that they can be consumed and produced by a machine.

Recognition of these facts has led to QVT, for Query, Views, and Transformations. There may be several types of QVT when all is said and done, depending on usage. For this reason, we lay out here several approaches to the problem.

The rules or algorithms that constitute a mapping function have to be specified with some formality in order to be subject to automatic execution with correct and reproducible results. Many formalisms are appropriate for this task. The most important approaches are imperative, archetype-based, and declarative.

Specifying a mapping function imperatively means implementing all rules and algorithms in a procedural programming language that defines how to query data in one metamodel, transform it, and then write it out. While this is a familiar approach we're talking an ordinary, boring programming language here the mapping isn't reversible, so one can't construct the source model from the target. While that may not appear important at first, non-reversible mappings make it more difficult to reverse-engineer models, which can make understanding the target model difficult.

An archetype-based^[1] approach defines a mapping function as a set of templates that mix code or rules into the text to be generated. This can be implemented as a data access language that selects the appropriate elements from the source metamodel, selects which archetype to use for what source model elements, and then selects how to transform this information into something else that one can then insert into the target model.

^[1] We chose "archetype" so as to distinguish between this concept and C++ templates, which is a related but slightly different concept.

The archetype-based approach is particularly well-suited for generating text from metamodels. The sequential and visible nature of a character stream highlights the importance of order, location, and formatting issues, which are nicely addressed by text-based archetypes.

A declarative approach to mapping specifies the algorithms as rules that specify what is to be produced, not how it's done. This approach lends itself much better to automated reversibility of the rules than the imperative approach or the archetype-based approach, though that doesn't guarantee reversibility the modelers still have to do some work.

Looking ahead, we can envision a model-driven approach to specifying a mapping function. The relationship of this approach to any of the approaches we've discussed to this point would basically be the same as the relationship between MDA-driven software development and handcrafting code. After all, surely all of the same reasons for modeling apply to mapping functions as for any other model we build.

Models make it possible to provide formal and rigorous definitions of parts or all of the mapping function, which could then be "filled out" using any one of the approaches outlined above. We view the model-driven approach to specifying mapping functions as the most general, into which the other approaches could be embedded. They could also hide the gory details of the metamodels at each end of the mapping function, as suggested in Weis et al. (2003).

Note that a model-driven approach to specifying mapping functions can be recursively applied to itself: One can model the mapping functions that generate mapping functions that eventually produce the system. In other words, this approach can be used to generate generators.