Combining independent model transformations

Abstract

Model transformation is one of the key principles of Model Driven Engineering. Many approaches have been proposed to design and realize them. However, for all the approaches, model transformations are considered as single entities that can only be chained if their input and output metamodels are compatible. This approach has the major drawback to focus on the satisfaction of the compliance property when building a transformation chain.In this paper we propose a mechanism for combining independent model transformations which jointly work towards a common objective but do not initially handle compatible metamodels. Our proposal is independent of any model transformation approach. It has been validated using Gaspard, an environment dedicated to code generation for embedded systems.

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

“…This scenario will help demonstrate the issues related to the practice of testing model transformation assets. This experience reported by example is relevant for studies related to reuse techniques, applied in model transformations in following works [11] [14][32] [37] [2]. FOMDA (Features-Oriented Model-Driven Architecture) is a methodology to specify generative and dynamic model transformation chains [4].…”

“…private TransformationExecutor revEng; @Test()// This is a JUnit 4 annotation 10 public void testIntegration() throws Throwable{ //Reverse a simple class to a model element in a CIM view (MDA) 11 org.wct.uml.Class cimClass = (org.wct.uml.Class) revEng.execute(("clazz", "src/test/SomeEntity.java"); 12 assertNotNull(cimClass); //Use of a wizard that refines the CIM into a PIM view (MDA) 13 Object obj = ormWizard.execute("entity", cimClass); 14 org.wct.uml.Class pimClass = (org.wct.uml.Class) obj; 15 assertNotNull(pimClass); //Transform a PIM into a JPA or XDoclet dependent PSM 16 obj = ormExec.execute("entity", pimClass); 17 org.wct.uml.Class psmClass = (org.wct.uml.Class) obj; 18 assertNotNull(psmClass); //Generates Source-code using default source-code generator 19 defCodeGen.execute("entity", psmClass);…”

“…This is demonstrated in annotations supported inside the @FomdaTask into the property shown in line 3. a rule can be IS_SELECTED, IS_NOT_SELECTED, IS_XOR, //IS_OR, IS_OPTIONAL, IS_MANDATORY, IS_DEPENDENCY 5 rule=AssertFeatureKind.IS_SELECTED, 6 features={ 9 @FeatureReference(featureName="Remote Layer"), 10 @FeatureReference(featureName="JPA") } ), @AssertFeatures ( 11 rule=AssertFeatureKind.IS_XOR, features={ 12 @FeatureReference(featureName="JPA"), 13 @FeatureReference(featureName="XDoclet") } ) } ) 14 public class FeatureDependentTestCase extends FomdaTestCase{…”

“…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.…”

From subsets of model elements to submodels

“…Generally, the use of model parts is not assumed in main existing works and engines like QVT [21] or ATL [24] and a transformation only operates on the whole model. Few works such as [18,42] explicitly use model parts in model transformation but they generally rely on ad hoc definitions. Though, by enabling partial models, transformations could benefit of qualities like locality, for example to reduce the impact of model evolution on transformation maintenance or limit the responsibilities of specific transformation in case of erroneous results.…”