Realizing Model Transformation Chain interoperability

Abstract

A single Model Transformation Chain (MTC) takes a high-level input model rooted in the problem domain and through one or more transformation steps produces a low-level output model rooted in the solution domain. To build a single "almighty" MTC that is in charge of every design, implementation and specific platform concern is a complex task. Instead, we can use several smaller MTCs that are easier to develop and maintain, because each MTC is independently developed focusing on a specific concern. However, the MTCs must interoperate to produce complete applications; this inherently creates dependencies between them, because each MTC generates a part of the final lowlevel model. In this paper, we propose an external and explicit mechanism to track dependencies between the MTCs (i.e., the MTCs are oblivious to the mechanism), which is used to automatically derive correspondence relationships between the final models generated by each MTC. The contribution of our mechanism is the reduction of complexity of building interoperable MTCs because the derived correspondences are resolved after the transformations execution, in the solution domain where the semantics of every concept is welldefined. The resolution process consists of (1) checking the consistency between the models, (2) producing communication bridges or (3) guiding the composition of the models. This paper presents three case studies to illustrate the derivation and resolution of correspondence relationships through the MTCs.

Supporting large scale model transformation reuse

“…Considering consistency in transformation composition, Guy et al [27] and Yie et al [52] suggest that valid compositions must be ensured with parameter types. For example, IO parameters are checked during the design of a model transformation chain, validating rules such as metamodel data types (e.g., EMF-based metamodels compatibility), transformation languages (e.g., ATL and QVT transformations), etc.…”

“…Output: TCDM with high-level composition and composition rules (e.g., parameter matching [52] and semantic rules for chaining reuse tasks [9]). …”

Extending JUnit 4 with Java annotations and reflection to test variant model transformation assets

“…Considering that different model transformation frameworks are available and some do not support the same set of languages [39][34] [5], transformation rules programmed with heterogeneous languages impose threats to the validity of the exemplified transformation assets. This limitation in our work is suppressed by T-Core framework, which supports the execution and validation of heterogeneous model transformations in MTCs [34].…”

“…Moreover, their study is focused in reusing textual guidance for test cases, not in adapting automated test cases.Our work is complementary and presents a contribution in comparison to related works. In order to provide a specific solution to test variant model transformation assets, our contribution facilitates the specification of automated JUnit test cases.In this sense, our contribution is directly important to test model transformation assets specified and generated through some related works as follows: 1) Almeida et al proposed a solution to compose model transformations in MTCs[1]; 2) Boas proposed the design of a MTC using workflow to model a transformation process according MDA views[8]; 3) Basso et al[4] and Völter et al[37] applied SPL-based techniques to specify dynamic MTC; 4) Vanhooff et al proposed a MTC modeling language to generate specifications used by some transformation execution engines[36] and Wagelaar et al proposed a framework to chain black-box model transformations[38], similar as those exemplified in Section 3; 5) Etien et al complemented these works to include validation for metamodels interoperated among different transformation compositions[11], similarly as Yie et al that applied validation between transformation IO parameters considering an MTC specification[39]; 6) Rosenmüller et al applied techniques to control dynamic SPLs[32] and, despite not being related to model transformation reuse, can also be applied in this context; 7) Aranega et al[2] and Basso et al[6] applied SPLbased techniques to fragment and merge model transformation assets. Although these works present an important contribution as a means of reuse techniques, they have not tackled automated test cases to validate the generated assets.…”

Engineering model transformations with transML

“…Kleppe proposed the MCC environment [37], which offers a scripting language with composition operators enabling the design of transformation chains. In [66] the authors propose mechanisms to compose transformation chains by defining correspondence meta-models. In [2] the authors present a tool integration framework enabling the description and execution of MDE processes.…”