Model transformation: Difference between revisions
Rewrote, expanded, added refs |
|||
| Line 1: | Line 1: | ||
A '''model transformation''', in [[model-driven engineering]], is an automatable way of ensuring that a family of models is consistent, in a precise sense which the software engineer can define. The aim of using a model transformation is to save effort and reduce errors by automating the building and modification of models where possible. |
|||
{{Refimprove|date=April 2009}} |
|||
A '''model transformation''' in [[Model-driven engineering]] takes as input a model conforming to a given [[Metamodeling|metamodel]] and produces as output another model conforming to a given metamodel. |
|||
== Overview == |
== Overview == |
||
Model transformations can be thought of as programs that take models as input. There is a wide variety of kinds of model transformation and uses of them, which differ in their inputs and outputs and also in the way they are expressed. |
|||
If the source and target metamodels are identical, the transformation is called '''endogeneous'''. If they are different the transformation is called '''exogeneous'''. |
|||
If the level of abstraction does not change, the transformation is called '''horizontal'''. If the level of abstraction does change, the transformation is called '''vertical'''. |
|||
These two distinctions are [[orthogonal]]. |
|||
A model transformation |
A model transformation usually specifies which models are acceptable as input, and if appropriate what models it may produce as output, by specifying the [[metamodel]] to which a model must conform. |
||
One of the characteristics of a model transformation is that it is also a model, i.e. it conforms to a given metamodel. This facilitates the definition of '''Higher Order Transformation'''s (HOTs)<ref>(See [[Massimo Tisi et. al. On the Use of Higher-Order Model Transformations. Lecture Notes in Computer Science, 2009, Volume 5562/2009, 18-33, DOI: 10.1007/978-3-642-02674-4_3 ]]</ref>, i.e. transformations taking other transformations as input and/or transformations producing other transformations as output. |
|||
Several [[model transformation language]]s (in short MTL) are presently available <ref>(See [[Model Transformation Language#Available transformation languages|list of available transformation languages]]</ref> |
|||
== Classification of model transformations == |
|||
Model transformations and languages for them have been classified in many ways<ref name="CzarneckiHelsen"/><ref name="Stevens-landscape"/>. |
|||
Some of the more common distinctions drawn are: |
|||
=== Number and type of inputs and outputs === |
|||
In principle a model transformation may have many inputs and outputs of various types; the only absolute limitation is that a model transformation will take at least one model as input. However, a model transformation that did not produce any model as output would more commonly be called a model analysis or model query. For the remainder of this entry we assume the commonest case, in which the transformation takes one model as input and gives one model as output. |
|||
=== Endogenous versus exogenous === |
|||
An endogenous model transformation modifies a model which is given to it as input (in-place transformation). For example, a model refactoring could be implemented using an endogenous model transformation. An exogenous model transformation produces a new model as output. For example, in a process conforming to the [[OMG]] [[Model Driven Architecture]], a Platform Independent Model might be transformed into a Platform Specific Model by an exogenous model transformation. |
|||
=== Unidirectional versus bidirectional === |
|||
A unidirectional model transformation has only one mode of execution: that is, it always takes the same type of input and produces the same type of output. Unidirectional model transformations are useful in compilation-like situations, where the output model is read-only. The relevant notion of consistency is then very simple: the input model is consistent with the model that the transformation would produce as output, only. |
|||
For a bidirectional model transformation, the same type of model can sometimes be input and other times be output. Bidirectional transformations are necessary in situations where people are working on more than one model and the models must be kept consistent. Then a change to either model might necessitate a change to the other, in order to maintain consistency between the models. Because each model can incorporate information which is not reflected in the other models, there may be many models which are consistent with a given model. Important special cases are: |
|||
*bijective transformations, in which there is exactly one model which is consistent with any given model; that is, the consistency relation is bijective. A pair of models is consistent if and only if it is related by the consistency bijection. Both models contain the same information, but presented differently. |
|||
*view transformations, in which a concrete model determines a single consistent view model, but the same view model might be produced from many different concrete models. The view model is an abstraction of the concrete model. If the view may be updated, a bidirectional transformation is needed. This situation is known in the database field as view-update. Any concrete model is consistent with its view. |
|||
It is particularly important that a bidirectional model transformation has appropriate properties to make it behave sensibly, for example, not making changes unnecessarily, or discarding deliberately made changes<ref name="Stevens-properties"/>. |
|||
== Languages for model transformations == |
|||
Main article: [[Model transformation language]]. |
|||
A model transformation may be written in a general purpose programming language, but specialised model transformation languages are also available. Bidirectional transformations, in particular, are best written in a language that ensures the directions are appropriately related. The [[OMG]]-standardised model transformation languages are collectively known as [[QVT]]. |
|||
In some model transformation languages, for example the [[QVT]] languages, a model transformation is itself a model, that is, it conforms to a metamodel which is part of the model tranformation language's definition. This facilitates the definition of '''Higher Order Transformation'''s (HOTs)<ref name="Tisi"/>, i.e. transformations which have other transformations as input and/or output. |
|||
==See also== |
==See also== |
||
| Line 24: | Line 52: | ||
== References == |
== References == |
||
{{Reflist |
{{Reflist|refs= |
||
<ref name="CzarneckiHelsen"> |
|||
== Further reading == |
|||
{{Cite journal |
|||
*''Model Driven Architecture: Applying MDA to Enterprise Computing'', [[David S. Frankel]], John Wiley & Sons, ISBN 0-471-31920-1 |
|||
| doi=10.1147/sj.453.0621 |
|||
*''[http://drops.dagstuhl.de/opus/volltexte/2005/11 A Taxonomy of Model Transformations]'', Tom Mens, Krzysztof Czarnecki and Pieter Van Gorp, 2005 |
|||
| last1=Czarnecki |
|||
| last2=Helsen |
|||
| title=Feature-based survey of model transformation approaches |
|||
| year=2006 |
|||
| journal=IBM Systems Journal}} |
|||
</ref> |
|||
<ref name="Stevens-landscape"> |
|||
{{Cite journal |
|||
| doi=10.1007/978-3-540-88643-3_10 |
|||
| last=Stevens |
|||
| first=Perdita |
|||
| title=A landscape of bidirectional model transformations |
|||
| publisher=[[Springer]] |
|||
| location=Berlin / Heidelberg |
|||
| year=2008}} |
|||
</ref> |
|||
<ref name="Stevens-properties"> |
|||
{{Cite journal |
|||
| doi=10.1007/s10270-008-0109-9 |
|||
| last=Stevens |
|||
| first=Perdita |
|||
| title=Bidirectional model transformations in QVT: semantic issues and open questions |
|||
| publisher=[[Springer]] |
|||
| location=Berlin / Heidelberg |
|||
| year=2010 |
|||
| journal=Software and Systems Modeling}} |
|||
</ref> |
|||
<ref name="Tisi"> |
|||
{{Cite journal |
|||
| doi=10.1007/978-3-642-02674-4_3 |
|||
| last=Tisi |
|||
| first=Massimo |
|||
| title=On the Use of Higher-Order Model Transformations |
|||
| publisher=[[Springer]] |
|||
| location=Berlin / Heidelberg |
|||
| year=2009 |
|||
| series=LNCS |
|||
| volume=5562 |
|||
| journal=ECMDA-FA '09}} |
|||
</ref> |
|||
}} |
|||
=== External links === |
|||
*[http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf ''Model-Driven Architecture: Vision, Standards And Emerging Technologies''] at omg.org |
|||
*[http://www-128.ibm.com/developerworks/rational/library/3100.html ''An Introduction to Model Driven Architecture''] at ibm.com |
|||
*[http://www.methodsandtools.com/archive/archive.php?id=5 ''Understanding the Model Driven Architecture (MDA)''] from Methods & Tools |
|||
*Czarnecki, K, and Helsen, S : Classification of Model Transformation Approaches. In: Proceedings of the OOPSLA'03 Workshop on the Generative Techniques in the Context Of Model-Driven Architecture, Anaheim, California, USA. [http://www.swen.uwaterloo.ca/~kczarnec/ECE750T7/czarnecki_helsen.pdf ''Webpublished.''] |
|||
* Portal site ''MDA and Model Transformation'': [http://www.model-transformation.org/ site access] |
|||
{{DEFAULTSORT:Model Transformation}} |
{{DEFAULTSORT:Model Transformation}} |
||
Revision as of 12:09, 13 June 2011
A model transformation, in model-driven engineering, is an automatable way of ensuring that a family of models is consistent, in a precise sense which the software engineer can define. The aim of using a model transformation is to save effort and reduce errors by automating the building and modification of models where possible.
Overview
Model transformations can be thought of as programs that take models as input. There is a wide variety of kinds of model transformation and uses of them, which differ in their inputs and outputs and also in the way they are expressed.
A model transformation usually specifies which models are acceptable as input, and if appropriate what models it may produce as output, by specifying the metamodel to which a model must conform.
Classification of model transformations
Model transformations and languages for them have been classified in many ways[1][2]. Some of the more common distinctions drawn are:
Number and type of inputs and outputs
In principle a model transformation may have many inputs and outputs of various types; the only absolute limitation is that a model transformation will take at least one model as input. However, a model transformation that did not produce any model as output would more commonly be called a model analysis or model query. For the remainder of this entry we assume the commonest case, in which the transformation takes one model as input and gives one model as output.
Endogenous versus exogenous
An endogenous model transformation modifies a model which is given to it as input (in-place transformation). For example, a model refactoring could be implemented using an endogenous model transformation. An exogenous model transformation produces a new model as output. For example, in a process conforming to the OMG Model Driven Architecture, a Platform Independent Model might be transformed into a Platform Specific Model by an exogenous model transformation.
Unidirectional versus bidirectional
A unidirectional model transformation has only one mode of execution: that is, it always takes the same type of input and produces the same type of output. Unidirectional model transformations are useful in compilation-like situations, where the output model is read-only. The relevant notion of consistency is then very simple: the input model is consistent with the model that the transformation would produce as output, only.
For a bidirectional model transformation, the same type of model can sometimes be input and other times be output. Bidirectional transformations are necessary in situations where people are working on more than one model and the models must be kept consistent. Then a change to either model might necessitate a change to the other, in order to maintain consistency between the models. Because each model can incorporate information which is not reflected in the other models, there may be many models which are consistent with a given model. Important special cases are:
- bijective transformations, in which there is exactly one model which is consistent with any given model; that is, the consistency relation is bijective. A pair of models is consistent if and only if it is related by the consistency bijection. Both models contain the same information, but presented differently.
- view transformations, in which a concrete model determines a single consistent view model, but the same view model might be produced from many different concrete models. The view model is an abstraction of the concrete model. If the view may be updated, a bidirectional transformation is needed. This situation is known in the database field as view-update. Any concrete model is consistent with its view.
It is particularly important that a bidirectional model transformation has appropriate properties to make it behave sensibly, for example, not making changes unnecessarily, or discarding deliberately made changes[3].
Languages for model transformations
Main article: Model transformation language.
A model transformation may be written in a general purpose programming language, but specialised model transformation languages are also available. Bidirectional transformations, in particular, are best written in a language that ensures the directions are appropriately related. The OMG-standardised model transformation languages are collectively known as QVT.
In some model transformation languages, for example the QVT languages, a model transformation is itself a model, that is, it conforms to a metamodel which is part of the model tranformation language's definition. This facilitates the definition of Higher Order Transformations (HOTs)[4], i.e. transformations which have other transformations as input and/or output.
See also
- Model-driven engineering (MDE)
- Model-driven architecture (MDA)
- Domain-specific language (DSL)
- Model transformation language
- Refinement
- Transformation (disambiguation)
- Program transformation
- Data transformation
- Graph transformation
References
- ^ Czarnecki; Helsen (2006). "Feature-based survey of model transformation approaches". IBM Systems Journal. doi:10.1147/sj.453.0621.
- ^
Stevens, Perdita (2008). "A landscape of bidirectional model transformations". Berlin / Heidelberg: Springer. doi:10.1007/978-3-540-88643-3_10.
{{cite journal}}: Cite journal requires|journal=(help) - ^ Stevens, Perdita (2010). "Bidirectional model transformations in QVT: semantic issues and open questions". Software and Systems Modeling. Berlin / Heidelberg: Springer. doi:10.1007/s10270-008-0109-9.
- ^ Tisi, Massimo (2009). "On the Use of Higher-Order Model Transformations". ECMDA-FA '09. LNCS. 5562. Berlin / Heidelberg: Springer. doi:10.1007/978-3-642-02674-4_3.