Comparing Reuse Mechanisms for Model Transformation Languages: Design for an Empirical Study Daniel Strüber Anthony Anjorin Universität Koblenz-Landau, Germany∗ and University of Paderborn, Germany Philipps-Universität Marburg, Germany anthony.anjorin@upb.de strueber@uni-koblenz.de ABSTRACT (cf., e.g., [14]), there exist no empirical studies of various Reuse mechanisms for model transformation languages help transformation reuse mechanisms and their actual useful- avoid duplication, thereby increasing maintainability and ness for transformation developers. enabling a more systematic overall development process. As In this work, therefore, we present our design for a contro- the introduction of such reuse mechanisms to model trans- lled experiment that aims to explore the benefits and dra- formation languages is still in its preliminary stages, howe- wbacks of the proposed reuse mechanisms for model trans- ver, language designers are currently faced with the chal- formation languages. Specifically, we intend to compare two lenge of choosing from amongst diverse proposed approa- recently emerging reuse mechanisms: rule refinement [4] and ches. Although there are a few surveys comparing syntactic variability-based rules [24]. This choice is motivated by the and semantic differences, there is still a need for empirical fact that both mechanisms address the same technical scope studies on the actual effectiveness of different reuse mecha- - the reuse of graph-based model transformations [7] - while nisms for transformation developers. In this paper, there- contrasting in the employed reuse paradigm: rule refinement fore, we present a study design for a controlled experiment reuses transformation rules by breaking them into smaller to investigate the benefits and drawbacks of two specific re- fragments that can be assembled using a composition me- use mechanisms for model transformation languages: rule chanism, while a variability-based rule represents a family of refinement and variability-based rules. Both mechanisms multiple, similar rules in an integrated form, using variabi- are tailored to graph-based model transformation languages, lity annotations to denote individual parts. This distinction yet represent two contrasting reuse paradigms: modularizing between composition- and annotation-based approaches is rules by composing them from smaller, shared fragments, well-known from the domain of software product lines [11]. versus maintaining a single, integrated representation via We are interested in the influence of these reuse mecha- variability annotations. We propose to compare these two nisms on maintainability, a main quality aspect of software approaches using comprehension and bug-finding tasks to artifacts [1] that is particularly important in the face of con- investigate understandability, and bug-fixing and modifica- tinuous development and evolution. More specifically, our tion tasks to study changeability. study targets the maintainability aspects of understanda- bility and changeability of model transformations [18, 26]. Given a group of participants, understandability can be qu- 1. INTRODUCTION antified in terms of correctness, completion time, and percei- Model transformations play a fundamental role in Model- ved effort during bug-finding and multiple-choice style com- Driven Engineering (MDE), where software systems are pro- prehension tasks. To measure changeability, we plan to use duced by the continuous refinement, translation, and syn- bug-fixing and modification tasks, again using correctness, chronization of models [19]. completion time, and perceived effort for quantification. As the field matures and MDE approaches are faced with The rest of the paper is structured as follows: Section 2 increasingly complex development tasks, the size and com- discusses related work. Section 3 introduces a motivating plexity of required model transformations also increases. De- running example that is used to explain the two reuse me- veloping and especially maintaining such large transforma- chanisms for the comparison. Section 4 presents our study tions is challenging without dedicated support for reusing design with an outline of the experimental variables of the parts of existing transformations [22]. As such reuse mecha- set-up, while Section 5 concludes. nisms for model transformation languages are just starting to emerge [14], however, transformation developers are often forced to resort to code or pattern duplication, well-known 2. RELATED WORK for its manifold maintainability-related drawbacks. The planned study is the first empirical investigation of But how can language designers decide which reuse me- transformation reuse mechanisms. Empirical studies in the chanisms to integrate in their model transformation langu- area of model transformation have so far been confined to ages? While some surveys exist comparing syntactic and the evaluation of transformation languages and approaches. semantic differences of various proposed reuse mechanisms Acreţoaie et. al [2] have compared their usability-oriented ∗ This research was partially supported by the research pro- Visual Model Transformation Language to traditional visual ject Visual Privacy Management in User Centric Open and textual languages. They found that their approach es- Environments (supported by the EU’s Horizon 2020 pro- tablishes a compromise between effort and correctness. In gramme, Proposal number: 653642). an evaluation of their transformation-by-example approach, Avazpour et al. [6] found that developers perceive the provi- applications where possibly hundreds of rules are required, ded interaction-based tool support as useful during the deve- such pattern duplication can quickly lead to a maintenance lopment of transformations. Guana and Stroulia [9] propose nightmare as changes, e.g., bug fixes, have to be consistently a study design to understand developer performance during applied to multiple, independent rules without tool support. the development of model-to-code transformations and mea- sure the effect of traceability visualizations. Conversely, only 3.1 Rule refinement reuse mechanisms for code have been investigated so far, The basic idea of rule refinement [4] is to enable a flexible mostly from a product line perspective [8, 15]. sharing and composition of common rule fragments. Pat- tern duplication can be avoided in this way by including the 3. MOTIVATING SCENARIO same fragment as a part of multiple rules. Rule refinement Our motivating scenario (adapted from [23]) is a simpli- can be applied to our running example to result in a network fied move method refactoring, implemented via three trans- of rule fragments as depicted in Fig. 2. Rule A remains un- formation rules depicted in Fig. 1: The first rule A transfers changed and is regarded as “resolved” as it does not refine a method m from its current containing class s to another any other rule fragment (it has no outgoing “inheritance” Method(src,trg,m) moveMethodAddWrapper(src,trg,m) arrows). Rule B is reduced to a refinement of A, i.e., it is class t. This rule is a graph transformation rule that preser- «preserve» «preserve» «preserve» «preserve» «preserve» ves all elements marked with preserve, deletes all elementstype «preserve»produced by merging rule A with the specified refinement. fields :Fieldmarked with type fields :Field This merge operator is relatively straightforward: The dis- delete, and «preserve» creates all elements marked with «preserve» erve» create. Such «preserve» rules are only applicable if all preserved and :Class joint union of both patterns (in general of multiple patterns) :Class :Class is formed, and then all elements with the same identifier are deleted elements can be matched name=src in a host model. «delete» name=trg me=src name=trg glued together. Similarly, rule C is specified as a refinement Rules B and C represent variants «create»of A:methods B creates a wra- «delete» pper method «create» methods w for simple delegation to the method m thatmethodsof B, resulting in the same pattern as in Fig 1 by first re- «create» methods «preserve» methods :Method «create» «preserve» solving rule B and then repeating the same merging process is to be moved. This can be used to limit the :Method effects of the :Method name=m refactoring and avoid having to change all existing clients with the specified refinement for rule C. Note that the merge name=m name=m operator requires the manual specification of identical ele- of the class s. Rule C additionally creates an annotation that marks w as deprecated to discourage future usage of ments, which is done by assigning names (e.g., s, me) to moveMethodAddDeprecatedWrapper(src,trg,m) the wrapper method, which can be eventually deleted. pattern variables, a concept that is not to be confused with parameters (e.g., src, trg, m), which are used to propagate «preserve» «preserve» «preserve» A: move(src,fields «preserve» trg, m) type «preserve» values across name attributes in this example. :Field :Class :Class «preserve» 2 «preserve» «preserve» «preserve» «preserve» «preserve» :Class name=src :Class fields :Field name=trg type :Class A: moveMethod(src,trg,m) name=trg «create» name=src «delete» «create» name=trg methods «create» methods methods «preserve» «preserve» «preserve» annotation «delete» fields :Field type «create» «create» methods «create» «create» methods«preserve» methods «preserve» «preserve» :Method :Annotation :Method s:Class :Class 3 name=m value="Dep" «preserve» name=m :Method name=src name=trg name=m «delete» «create» methods «preserve» methods :Method B: moveAndCreateDelegate(src, trg, m) name=m «preserve» 5 «preserve» «preserve» «preserve» «preserve» «preserve» :Class :Class fields :Field type :Class name=trg moveMethod(src,trg,m) name=src deprecate -> wrappername=trg B: addWrapper(src,m) C: markDeprecate(m) «create» «preserve» «create» «preserve» «preserve» «delete» «preserve» «create» methods methods methods «preserve»methods «preserve»s :Class fields :Field type :Class «create» s:Class me:Method name=src «preserve» name=trg 6 «create» :Method name=src name=m :Method «delete» «create» «create» name=m «create» «create» name=m methods methods annotation methods methods «create» «create» rg, m) C: moveAndCreateDeprecatedDelegate(src, «create» trg, m) me:Method :Annotation «create» annotation «create» «preserve» :Method :Annotation «preserve» :Method «preserve» name=m value="Dep" «preserve» 8 «preserve» «preserve» «preserve» :Class name=m :Class fields value="Dep" :Field type name=m :Class name=trg name=src name=trg Figure 2: Refinement rules. «create» «delete» «create» «create» methods methods methods methods «preserve» 9 «create» «create» «preserve» annotations «create» 3.2 Variability-based rules :Method :Method :Annotation :Method name=m name=m value="Dep" name=m In stark contrast to rule refinement, variability-based rules [21, 23, 24] enable an integrated representation of multiple rules in a single diagram. The variability-based rule for our Figure 1: Three model transformation rules. running example is depicted in Fig. 3. The rule comprises two configuration options that are denoted via variability an- This simple example illustrates how multiple transforma- notations, e.g., the annotation [wrapper] is used to indicate tion rules can “share” a common part that must be repeated which edges and nodes in the diagram are only present when in each variant if no reuse mechanism is provided. In realistic configuration option wrapper is set to true. Note that depen- dencies between configuration options can be specified, e.g., the influence of confounding factors (e.g., participant ex- the dependency deprecate -> wrapper (upper-left corner) pertise) is reduced as each participant serves as their own is used to indicate that the configuration option deprecate control. A main threat to this kind of study design are lear- requires wrapper, i.e., all elements annotated with wrapper ning effects: over the course of the experiments, participants are also present in the deprecate variant of the rule. become more experienced and might carry over gained expe- rience among tasks. A viable mitigation to this threat is to moveMethod(src,trg,m) deprecate -> wrapper vary the order of treatments among participants. We discuss additional threats and mitigation strategies in Sec. 4.3. «preserve» «preserve» «preserve» «preserve» «preserve» :Class fields :Field type :Class To discuss the different dimensions that influence our ex- name=src name=trg periment, we first outline its variables in the following. We then specify our research plan as one possible path through «create» «delete» «create» methods the design space spanned by these variables. Finally, we methods methods describe potential threats to validity in our set-up, and our «create» «create» «preserve» means of mitigating these threats. annotation «create» :Method :Annotation :Method name=m value="Dep" name=m 4.1 Experimental variables Figure 3: Variability-based rule. 4.1.1 Independent variables As the single independent variable in the planned experi- moveMethod(src,trg,m) addWrapper(src,m) This scenario illustrates a set of maintainability ment, deprecate(m) trade-offs we measure the effects of the employed reuse mecha- extends extends addWrapper(src,m) nism. For RQ1 and RQ3, only the data points of the two that we aim to explore «preserve» «preserve» «preserve» in our study. Both considered moveMethod(src,trg,m) me- fieldschanisms type proposed reuse mechanisms are considered, whereas RQ2 in- :Field help avoid pattern duplication, which may simplify the consistent editing of multiple «preserve» variants at «preserve» once. In ad-«create» corporates the data points for the no-reuse case as well. «preserve» :Class :Class can lead to com- :Class rule refinement dition, if applied skillfully, :Method name=src name=trg modular prehensible and maintainable name=src rule fragments, «create» re- name=m4.1.2 Dependent variables «preserve» «create» The variables we want to observe as a result of the expe- «delete»flecting an independent «create»handling and separation of concerns methods annotation methodsin the:Method methods riment are the following: transformation. Variability-based rules improve nota- «create» «create» name=m :Method :AnnotationCorrectness score. We plan to measure correctness ba- tional compactness drastically, thereby potentially reducing reading effort: it is well-known that humansname=m struggle with value="Dep" sed on how well participants are able to solve certain tasks. processing more than 7±2 units of information at once [17]. As these tasks might not be directly comparable, counting On the downside, as they require developers to derive the the number of correctly solved tasks only provides ordinal included rule variants in their minds, both approaches may values. increase cognitive overhead. In particular, variability-based Perceived effort. Participants will be asked to rate the rules may suffer from their increased amount of informa- perceived effort it took to solve all tasks using a suitable tion in each individual diagram, comparable to the case of ordinal scale ranging from, e.g., 0 to 10 to quantify effort. variability-annotated code, where a decrease in developer Completion time. For all tasks, completion times will performance was found [15]. be measured for all participants. This qualitative value can be contrasted with correctness scores and perceived effort to 4. STUDY DESIGN yield further insights. User preference. Finally, regardless of correctness, per- To investigate the identified trade-offs further, we propose ceived effort, and completion time, we shall ask users which the following research questions: reuse mechanism they prefer and enjoyed using the most. • RQ1: Which reuse mechanism is most beneficial for For statistical analysis, we intend to apply the Wilcoxon developers in terms of understandability and changea- signed-rank test [28], which is a robust non-parametric test bility? to identify significant differences between two treatments. It assumes data measured at least on an ordinal scale, which • RQ2: How do the studied reuse mechanisms compare applies to all of our dependent variables. to offering no reuse at all? A remaining issue concerns the fact that we are interested in two different quality goals that should ideally be studied • RQ3: Can the understandability and changeability of as separate entities. Yet, as changeability clearly depends the selected reuse mechanisms be further improved via on understandability, it is not obvious how these two diffe- the available tool support? rent goals can be studied in isolation. To this end, a viable To address these research questions, we plan to administer method is to collect performance data for both goals, and a set of comprehension and implementation tasks to parti- to subtract the understandability from the changeability re- cipants who are familiar with graph-based model transfor- sults. For instance, the time required to actually change mations. Such participants will be recruited from research the affected rules can be obtained from subtracting the time groups, as well as master-level model-driven engineering co- required to understand the rules from the full completion urses. time. A prerequisite for this method is that subtraction We plan to apply a crossover trial, a variant of the within- is supported by the underlying scale, which is the case for subject design [10]: in this design, all subjects are sequen- completion times. tially exposed to each treatment. This choice is motivated by the statistical efficiency of the design: it allows the nu- 4.1.3 Controlled variables mber of required participants to be minimized. Moreover, The design space of our controlled variables comprises the Name Possible values Independent variable Reuse mechanism { Rule refinement, variability-based rules, no reuse } Controlled variables Transformation language { Henshin, ATL, EOL, ... } Example type { queries, endogenous, exogenous } Task type { bug-finding, quiz, bug-fixing, modification task } Environment { pen-and-paper, tool } Dependent variables Correctness score Ordinal Perceived effort Ordinal Completion time Interval User preference Ordinal Table 1: Experimental variables following dimensions: history effects. Other goals of the pilot study are to deter- Transformation language. The variety of available mo- mine if we can extract any meaningful results (e.g. maybe del transformation languages is usually classified along a nu- all task are too difficult and we do not gather sufficient use- mber of main paradigms, most prominently imperative, hy- ful data), and to see if our assumptions about participant’s brid, and graph-based model transformations [7, 16]. In the abilities hold true. planned study, we aim to investigate reuse in the context Task types. To study understandability and changeabi- of Henshin [5], a graph-based language. The reason for this lity, we plan to administer tasks allowing us to quantify these choice is twofold: first, examples and tool support for one properties. The understandability of a software artifact can of the supported reused mechanisms are readily available in be investigated using bug-finding tasks or quiz-style com- Henshin (convenience sampling). Second, the graphical syn- prehension questions. In the example, a bug-finding task tax of Henshin closely resembles that of a group of languages would be to swap the delete and create edges and have the including eMoflon [3], EMorF [12], and QVTs [29], rende- user find and mark this error on a printout. A comprehen- ring it a promising choice to obtain results which might also sion question could be “How many individual rules can be generalize to these languages. In addition, Henshin is under derived from this representation?”. Changeability refers to active development and in widespread use.1 Our study will the ease of modifying or extending the functionality of a be based on bug-finding and bug-fixing tasks, since these ta- system. Two possible kinds of tasks to study changeability sks can avoid lengthy textual task descriptions that might be are the fixing of a preconceived bug, such as the one des- hard to match to the presented visual representations [27]. cribed above, and the implementation of a feature request Our example rules will mostly be endogenous, such as those such as “I need a set of transformation rules with the same shown in the running example, allowing us to establish a behavior as the given ones, but with one modification: the compromise between external and internal validity. target class must have a field whose type is the source class”. Example types. In the choice of example transforma- A challenge for the study design lies in choosing a feasible tions, we need to account for the inherent trade-off between subset of all tasks so as to avoid exhausting the participants. external and internal validity [20]: by using simple and easy- To this end, we plan to use bug-finding and bug-fixing tasks, to-understand examples, we can mitigate the effect of parti- since these tasks can avoid lengthy textual task descriptions cipant heterogeneity, but risk ending up with an experiment that might be hard to match against the presented visual that is not realistic enough. The simplest transformation representations [27]. that can be expressed using rules is a query – a rule perfor- Environment. Another balancing act between control ming no modifications of the input model. Queries are ge- and remaining adequately realistic concerns the experimen- nerally easy to understand; yet in realistic settings they are tal environment. By setting up the participants in a contro- likely to be expressed using dedicated query languages. En- lled pencil-and-paper environment, we can eliminate confo- dogenous transformations – transformations that update the unding factors related to the tool implementations, for in- input model or translate it to a model of the same language stance, differences in visual appearance. Such a controlled – are a typical use-case for graph-based model transforma- environment is, however, not really comparable to the real- tion, but require an understanding of its underlying repla- world environment that actual users of the reuse mechanisms cement mechanism. Exogenous transformations, creating an find themselves in, especially in the case of changeability ta- output model of a different language, are most complicated sks. Moreover, RQ3 can only be studied by comparing the as they require the understanding of two meta-models and reuse mechanisms with and without the actual tool support their relations; yet they are particularly important for the provided. As of now, tool support for rule refinement [13] typical forward-engineering process in model-driven engine- and VB rules [25] exists, but is implemented within different ering. Two other sub-dimensions of this dimension are the model transformation languages and corresponding tool en- number of examples and the size of the individual examples. vironments – eMoflon and Henshin. To ensure optimal con- We intend to conduct a pilot study to find a suitable co- trol during the experimental comparison, both mechanisms llection of examples that avoids participant fatigue, using a should be implemented for the same language and tool en- different set of participants than in the actual study to avoid vironment. 1 For a selection of publications describing Henshin’s use in numerous research projects, see https://www.eclipse.org/ 4.2 Quantitative data henshin/publications.php To gain additional insight about the perceived benefits and pitfalls of both reuse approaches, we also plan to col- [3] A. Anjorin, M. Lauder, S. Patzina, and A. Schürr. lect quantitative data, using text fields in the task sheet to eMoflon: Leveraging EMF and Professional CASE collect participants’ opinions after their completion of the Tools. Informatik, 192:281, 2011. experiment. [4] A. Anjorin, K. Saller, M. Lochau, and A. Schürr. Modularizing Triple Graph Grammars Using Rule 4.3 Potential threats to validity Refinement. In International Conference on In addition to the threats already described in the previ- Fundamental Approaches to Software Engineering, ous discussion, we plan to mitigate researcher bias by stri- pages 340–354. Springer, 2014. ving to ensure that participants are unable to directly map [5] T. Arendt, E. Biermann, S. Jurack, C. Krause, and reuse mechanisms to researchers, e.g., by anonymising tool G. Taentzer. Henshin: Advanced Concepts and Tools names. for In-Place EMF Model Transformations. In To avoid selection bias in favor of volunteers, whose level International Conference on Model Driven of motivation does not reflect that of the whole population, Engineering Languages and Systems, pages 121–135. we will offer a small prize among participants. Springer, 2010. Finally, the participants’ performance can be confounded [6] I. Avazpour, J. Grundy, and L. Grunske. Specifying by relevant prior knowledge, e.g., from exercise in the area model transformations by direct manipulation using of software product lines and other annotation-based model concrete visual notations and interactive families. To study the effect of prior knowledge, we plan to recommendations. Journal of Visual Languages and ask participants to rate their own prior knowledge of relevant Computing, 28:195 – 211, 2015. topics. [7] K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal, 45(3):621–645, 2006. 5. CONCLUSION [8] J. Feigenspan, C. Kästner, S. Apel, J. Liebig, In this paper, we present our study design for an empi- M. Schulze, R. Dachselt, M. Papendieck, T. Leich, and rical comparison of two reuse mechanisms for graph-based G. Saake. Do background colors improve program model transformation languages. The selected reuse mecha- comprehension in the #ifdef hell? Empirical Software nisms exemplify the contrasting reuse paradigms of modula- Engineering, 18(4):699–745, 2013. rizing a set of rules and merging similar rules in a variability- [9] V. Guana and E. Stroulia. How Do Developers Solve annotated representation. Software-engineering Tasks on Model-based Code Our prior expectations are as follows: we expect refine- Generators? An Empirical Study Design. In First ments to be (perhaps only slightly) more understandable International Workshop on Human Factors in but less changeable than variability rules (RQ 1), both re- Modeling, pages 33–38. CEUR-WS.org, 2015. use mechanisms to substantially improve changeability but [10] B. Jones and M. G. Kenward. Design and analysis of (at least without substantial training) reduce understanda- cross-over trials. CRC Press, 2014. bility (RQ 2), and that appropriate tool support plays a crucial role in both cases (RQ 3). It remains to be seen if [11] C. Kästner, S. Apel, and M. Kuhlemann. Granularity our experiment results will support or refute these initial hy- in software product lines. In International Conference potheses. Addressing the trade-off between different forms on Software Engineering, pages 311–320. ACM, 2008. of experimental validity [20], our set-up aims to establish a [12] L. Klassen and R. Wagner. EMorF-A tool for model compromise between internal and external validity. A series transformations. Electronic Communications of the of follow-up studies moving the spotlight in either direction EASST, 54, 2012. can lead to a more comprehensive picture. [13] G. Kulcsár, E. Leblebici, and A. Anjorin. A Solution The results of our study will provide evidence to desig- to the FIXML Case Study Using Triple Graph ners of model transformation languages who are planning Grammars and eMoflon. In Transformation Tool to include a reuse mechanism within their language. In a Contest, pages 71–75. CEUR-WS.org, 2014. broader context, we hope to shed a new light on the discus- [14] A. Kusel, J. Schönböck, M. Wimmer, G. Kappel, sion of when and how software reuse can be established in a W. Retschitzegger, and W. Schwinger. Reuse in manner that is most beneficial to all involved stakeholders. model-to-model transformation languages: are we there yet? Software & Systems Modeling, Acknowledgements: The authors wish to thank Vlad 14(2):537–572, 2015. Acret, oaie and the anonymous reviewers for their careful rea- [15] J. Melo, C. Brabrand, and A. Wasowski. , How Does ding of this paper and their detailed comments and sugges- the Degree of Variability Affect Bug Finding? In tions. International Conference on Software Engineering, ICSE ’16, pages 679–690, New York, NY, USA, 2016. ACM. 6. REFERENCES [16] T. Mens and P. V. Gorp. A taxonomy of model [1] ISO/IEC 25010:2011. Systems and software transformation. Electr. Notes Theor. Comput. Sci., engineering – Systems and software Quality 152:125–142, 2006. Requirements and Evaluation (SQuaRE) – System [17] G. A. Miller. The magical number seven, plus or and software quality models, 2011. minus two: Some limits on our capacity for processing [2] V. Acreţoaie, H. Störrle, and D. Strüber. VMTL: a information. Psychological review, 63(2):81, 1956. language for end-user model transformation. Software [18] S. Nalchigar, R. Salay, and M. Chechik. Towards a & Systems Modeling, pages 1–29, 2016. catalog of non-functional requirements in model transformation languages. In Workshop on the pages 122–140. Springer, 2016. Analysis of Model Transformations. CEUR-WS.org, [24] D. Strüber, J. Rubin, M. Chechik, and G. Taentzer. A 2013. Variability-Based Approach to Reusable and Efficient [19] S. Sendall and W. Kozaczynski. Model Model Transformations. In International Conference Transformation: The Heart and Soul of Model-Driven on Fundamental Approaches to Software Engineering, Software Development. IEEE Software, 20(5):42–45, pages 283–298. Springer, 2015. 2003. [25] D. Strüber and S. Schulz. A Tool Environment for [20] J. Siegmund, N. Siegmund, and S. Apel. Views on Managing Families of Model Transformation Rules. In internal and external validity in empirical software International Conference on Graph Transformation, engineering. In International Conference on Software pages 89–101. Springer, 2016. Engineering, volume 1, pages 9–19. IEEE, 2015. [26] E. Syriani and J. Gray. Challenges for addressing [21] D. Strüber. Model-Driven Engineering in the Large: quality factors in model transformation. In Refactoring Techniques for Models and Model International Conference on Software Testing, Transformation Systems. PhD thesis, University of Verification and Validation, pages 929–937, 2012. Marburg, 2016. [27] I. Vessey and D. Galletta. Cognitive fit: An empirical [22] D. Strüber, T. Kehrer, T. Arendt, C. Pietsch, and study of information acquisition. Information systems D. Reuling. Scalability of Model Transformations: research, 2(1):63–84, 1991. Position Paper and Benchmark Set. In Workshop on [28] F. Wilcoxon. Individual Comparisons by Ranking Scalable Model Driven Engineering, pages 21–30. Methods. Biometrics Bulletin, 1(6):80–83, Dec. 1945. CEUR-WS.org, 2016. [29] E. D. Willink. Optimized Declarative Transformation: [23] D. Strüber, J. Rubin, T. Arendt, M. Chechik, First Eclipse QVTc Results. In Workshop on Scalable G. Taentzer, and J. Plöger. RuleMerger: Automatic Model Driven Engineering, pages 47–56. Construction of Variability-Based Model CEUR-WS.org, 2016. Transformation Rules. In International Conference on Fundamental Approaches to Software Engineering,