=Paper=
{{Paper
|id=Vol-1805/Struber2016HuFaMo
|storemode=property
|title=Comparing Reuse Mechanisms for Model Transformation Languages: Design for an Empirical Study
|pdfUrl=https://ceur-ws.org/Vol-1805/Struber2016HuFaMo.pdf
|volume=Vol-1805
|authors=Daniel Strüber,Anthony Anjorin
|dblpUrl=https://dblp.org/rec/conf/models/StruberA16
}}
==Comparing Reuse Mechanisms for Model Transformation Languages: Design for an Empirical Study==
https://ceur-ws.org/Vol-1805/Struber2016HuFaMo.pdf
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,