Model transformation: Difference between revisions

Revision as of 09:57, 6 December 2016

Latest revision as of 06:16, 14 September 2024

(14 intermediate revisions by 10 users not shown)

Line 1:

{{Data transformation}}

A '''model transformation''', in [[model-driven engineering]], is an automatable way of ensuring that a family of [[Computer model|model]]s 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.

A '''model transformation''', in [[model-driven engineering]], is an automatableautomated way of modifying and creating [[platform-specific model]] from platform-independent ones. An example use of model transformation is ensuring that a family of [[Computer model|model]]s 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 ==

Line 17 ⟶ 19:

=== Endogenous versus exogenous ===

Endogenous transformations are transformations between models expressed in the same language. Exogenous transformations are transformations between models expressed using different languages.<ref>Tom Mens, Pieter Van Gorp: A Taxonomy of Model Transformation. Electr. Notes Theor. Comput. Sci. 152: 125-142 (2006)</ref> For example, in a process conforming to the [[Object Management Group|OMG]] [[Model Driven Architecture]], a [[platform-independent model]] might be transformed into a [[platform-specific model]] by an exogenous model transformation.

=== Unidirectional versus bidirectional ===

Line 23 ⟶ 25:

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 any 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 transformationstransformation]]s 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, 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.

Line 58 ⟶ 60:

| title=Feature-based survey of model transformation approaches

| year=2006

| journal=IBM Systems Journal}}| volume=45

| issue=3

| pages=621–645

| citeseerx=10.1.1.124.9674

}}

</ref>

<ref name="Stevens-landscape">

{{Cite journalbook

| doi=10.1007/978-3-540-88643-3_10

| last=Stevens

| first=Perdita | title=Generative and Transformational Techniques in Software Engineering II

| first=Perdita

| titlechapter=OnA the UseLandscape of Higher-OrderBidirectional Model Transformations

| title=A landscape of bidirectional model transformations

|author-link=Perdita Stevens

| volume=5235

| pages=408–424

| publisher=[[Springer Publishing|Springer]]

| year=2008| series=Lecture Notes in Computer Science

| ___location=Berlin / Heidelberg

| isbn=978-3-540-88642-6

| year=2008}}

| chapter-url=https://www.research.ed.ac.uk/en/publications/f1706efc-3370-472c-b506-bd65680a04b6

}}

</ref>

Line 76 ⟶ 87:

| doi=10.1007/s10270-008-0109-9

| last=Stevens

| first=Perdita |author-link=Perdita Stevens

| title=Bidirectional model transformations in QVT: semantic issues and open questions

| publisher=[[Springer Publishing|Springer]]

| ___location=Berlin / Heidelberg

| year=2010

| journal=Software and Systems Modeling}}| volume=9

| pages=7–20

| s2cid=371579

| url=https://www.pure.ed.ac.uk/ws/files/12628301/bidirectional.pdf

}}

</ref>

<ref name="Tisi">

{{Cite journalbook

| doi=10.1007/978-3-642-02674-4_3

| last=Tisi

| first=Massimo

| title=Model Driven Architecture - Foundations and Applications

| title=On the Use of Higher-Order Model Transformations

| chapter=On the Use of Higher-Order Model Transformations

| publisher=[[Springer Publishing|Springer]]

| ___location=Berlin / Heidelberg

| year=2009

| series=LNCS

| volume=5562

| pages=18–33

| journal=ECMDA-FA '09}}

| journal=Ecmda-Fa '09| isbn=978-3-642-02673-7

}}

</ref>

Line 116 ⟶ 131:

| last14=Mazanek

| title=A survey and comparison of transformation tools based on the transformation tool contest

| publisher=[[Elsevier]]

| year=2014

| journal=Science of Computer Programming}}| volume=85

| pages=41–99

| doi-access=free

}}

</ref>

}}

==Further reading==

* ''Model Driven Software Engineering in Practice'', Marco Brambilla, Jordi Cabot, Manuel Wimmer, foreword by [[Richard Soley]] ([[Object Management Group|OMG]] Chairman), Morgan & Claypool, USA, 2012, Synthesis Lectures on Software Engineering #1. 182 pages. {{ISBN |9781608458820}} (paperback), {{ISBN |9781608458837}} (ebook) http://www.mdse-book.com

[[Category:Systems engineering]]