Conversion between models is a subject of contention, either because they are not well understood or because their merits in practical model-driven development situations are not very clear. Of course, this is akin to a "chicken and egg" problem, in that a lack of understanding of the underlying problems and the mechanisms for solving them is at the root of a lack of understanding of where and how these type conversions are applied.
Use OMG's query (Query) / view (View) / conversion (Transformation) standard for conversion between models, this standard is also called QVT.
1. History
As defined by the OMG, MDA guidelines generally discuss conversions between different models at different levels of abstraction. The conversion between the platform-independent model (PIM) and the platform-specific model (PSM) is performed before generating code through the platform-specific model (PSM). At this time, QVT will be used.
2. M2M Language Requirements
Before delving into the details of QVT itself, it is helpful to discuss the following: Some of the more important and perhaps less obvious requirements regarding the inter-model transformation language and its implementation:
- Most real-world inter-model conversion situations require conversion rules to be able to find what other conversion rules have already computed, since each rule usually only accounts for a small part of the overall conversion.
- Except during the first run of M2M Scratch, users rarely generate completely new models.
- A transformation defines the relationship between the source and target models, either implicitly or explicitly.
- In general, converted source models can be very large.
- In many use cases, often platform-specific target models may need to be changed manually by the model author.
- Transformation between models is usually a substantial structural change in mapping the source model to the target model.
- Whether to support bidirectional conversion is a requirement, which is often debated.
3. The overall system structure
The QVT specification consists of 3 different inter-model translation languages: Relations language and Core language are declarative, while Operational. Mappings language is mandatory. The hybrid nature of QVT is introduced to accommodate different types of users with different wants, needs and habits. This strategy is not surprising if one considers the large number of initial submissions to the RFP, each with different expectations regarding the use and functionality of the QVT.
QV T Language Architecture
Semantically define the Relations language in terms of the Relations language. In particular, this is mimicked by an inter-model transformation from the MOF source model in the Relations language to the MOF metamodel in the Core language. This semantic transformation itself is specified by the Relations language.
4. Conversion example
Example of an ALMA metamodel, a source model that can be used to model astronomical observation data. It provides platform-independent abstractions over all possible artifacts that are required by the ALMA software infrastructure. One possible platform-independent incarnation of ALMA data is a relational database. In this case, the transformation of the ALMA metamodel to a simple relational database metamodel is discussed.
The target DB metamodel is a simple reproduction of a relational database table.
The QVT Relations language is a declarative member of QVT's 3 languages. Users of QVT Relations must describe the transformation of a source metamodel to a target source model as a set of relations. Transformation execution means validating these relationships and then enforcing them by manipulating the target model if necessary.
The Operational Mappings language (OM) is a mandatory member of the QVT language specification. It can be used in combination with QVT Relations in a hybrid fashion, or it can be used independently. For example reasons, only methods used independently are considered.
The OPerational Mappings transformation begins with a transformation header, which specifies the input and output models for the transformation. OM transformations can only be performed in statically indicated directions, as it generally does not account for transformations in multiple directions.
5. OMG standardization process and tool availability
The QVT specification currently adopted by OMG has not yet been finalized. This means that the current specification is open to the public through the publication of reports, allowing actors inside and outside the OMG to support potential issues and bugs, or to suggest minor improvements.
Tool developers are also free to use the adopted specification and provide it to the MDA team for prototype implementation. Unfortunately, at the time of writing, there are few publicly available prototypes of the QVT language.
6. Evaluation
Whether the current QVT standard can survive the turbulent environment and rapid development of new technologies and methodologies in MDSD, only time will tell. The fact that the standard specifies 3 languages indicates that translation between models remains an elusive domain. Perhaps multiple non-QVT inter-model translation languages and tools, some proprietary, some open source, but all of them handle the problem in their own way.
It is obvious that the purpose of the QVT standard is to avoid the uncontrolled growth of such systems, but the problem is that no one currently knows what is really needed to make M2M work in real-time practice. This is partly because few projects are using M2M extensively in industrial project settings, and partly because model-driven development is an "early" market.
Depending on language usage, both QVT Relations and QVT Core already incur significant costs in supporting the need for bidirectional mapping, which we believe is of no practical value.
Finally, we should mention that the QVT specification is a complex document with numerous revisions. It is difficult, if not impossible, to demonstrate that language standards are consistent and reasonable. OMG has very little experience with language definitions with behavioral biases. It is also the case that too many people have studied its specification over a long period of time. Then, a reasonable language standard must be widely accepted and easy to implement. We expect revisions and subsequent versions of QVT to appear in the near future, assuming this standard is not bypassed by actual model conversion standards that may emerge.