Model-Driven Engineering (MDE) [15] proposes an active use of models to conduct the different phases of software development. Provided the fact that everything is a model, every systematic manipulation thereof may be considered a model transformation [16,18]. Consequently, model transformations are vital for MDE. Given their prominent role and their use in increasingly complex scenarios, appropriate reuse mechanisms are indispensable to increase development productivity as well as quality, e.g., in terms of maintainability of model transformations. To address this need, a plethora of reuse mechanisms has been proposed by the research community, cf., e.g., [1,2,3,4,7,8,10,11,13,17,21,22,23,25,26], to mention just a few. In [9], we have surveyed and categorized several different reuse mechanisms for model transformations by using a conceptual comparison framework. However, it remains still unclear, if at all and how often reuse mechanisms are employed in practical settings.
To shed some light on this area and to estimate the application frequency of current reuse mechanisms for model transformations, we performed a case study based on a real-world transformation repository and its population. In particular, following the guidelines for conducting empirical explanatory case studies by Runeson and Höst [14], we analyzed the population of the Atlas Transformation Language (ATL) Transformation Zoo 4 (in the following denoted as "Zoo" for short) [6]. The Zoo has been chosen, because to the best of our knowledge, this repository is-at the time of writing-offering the most comprehensive collection of publicly available model transformations. Furthermore, the Zoo has been source for several previous studies concerning, e.g., the evaluation of model metrics [24], the validation of the results of metamodel matching tools [5], or the estimation of how end-users employ ATL in practice [19], to mention just a few. Thus, we consider the population of the Zoo as a representative set of model transformations. For analyzing the Zoo, we developed a semi-automated process for extracting transformation projects from the Zoo. The extracted transformation projects have then been classified and analyzed with respect to indicators for the application of reuse mechanisms. The results show that up to now reuse mechanisms are rarely used in practice. Thus, we conclude by discussing potential barriers that might harm the practical applicability, thereby pointing to further research topics.
Outline. Section 2 discusses the basic setup of the case study and gives an impression on the transformations that are available in the Zoo. The case study as well as the results thereof are presented in Section 3, whereby Section 4 critically reflects the results and discusses threats to validity, before Section 5 concludes the paper.
To estimate the application frequency of current reuse mechanisms for model transformations, we conducted an empirical explanatory case study in order to analyze the population of the Zoo. The study was performed to quantitatively assess the application frequency of reuse mechanisms in model transformations of the Zoo. More specifically, we aimed at answering the following research question:
With which frequency are reuse mechanisms currently applied in model transformation projects?
For performing the analysis of the Zoo's population, we extracted all transformation projects from the Zoo's website 5 . To reason about the Zoo's population, not only the transformation definitions are required, but also accompanying artifacts such as the input and output metamodels, launch configurations, and build scripts. For instance, the metamodels are of interest to relate their size and structure to the size and structure of model transformations. The launch configuration files and build scripts for running the transformations are an important source to reason about the execution processes of the transformations, e.g., how a set of transformations interact.
The Zoo provides a collection of 103 different transformation projects, mostly provided as .zip archives, containing 1689 files in total. Before starting the automated analysis of the transformation projects in a subsequent step, the relevant files (transformations, metamodels, launch configurations, and build scripts) have been extracted from the .zip archives on basis of their file extensions. Consequently, we selected 873 out of the 1689 files: 231 ATL transformations (.atl files), 525 metamodels (.ecore and .km3 files), 57 build scripts (.build or .xml files), and 95 launch scripts (.launch files). The remaining 781 files, being, e.g., readme files for documentation or test input/output models, have not been considered in this case study (cf. Fig. 1(a)). Furthermore, since transformations have been reused in different projects, duplicates may exist. In particular, we regarded two transformations as duplicate, if they have the same name and identical metric values for their intrinsic properties, i.e., the same number of rules and helpers. In this respect, 40 duplicates have been removed resulting in 191 transformations for further investigation. The remaining transformations may be further divided into three different kinds of ATL transformations. First, a transformation may either be (i) a model-to-model transformation (168), (ii) a library of reusable helpers (17), which are importable to other transformations, or (iii) queries (6), which derive information from models by using Object Constraint Language 6 (OCL) expressions, e.g., to select a set of model elements from an input model, as depicted in Fig. 1(b).
To give an impression on the complexity of the transformation tasks supported, we list in the following some meta-information about the transformations. First, the transformation size ranges from a minimum of 1 rule to a maximum of 84 rules. Concerning the numbers of input and output metamodels, the majority are 1-to-1 transformations, but there is also a small amount of 1-to-n (2 transformations), n-to-1 (12 transformations), and n-to-m transformations (2 transforma- 3 Analysis of the ATL Transformation Zoo After introducing the setup of the case study, it is described to which extent the reuse mechanisms available for ATL are practically applied by transformations in the Zoo, whereby we distinguish between a fully automatic detection and a semiautomatic detection. For each reuse mechanism, we (i) shortly characterize the according reuse mechanism, (ii) discuss, how it might be (semi-)automatically detected, (iii) analyze the results, and finally (iv) provide a critical discussion thereof. The results are summarized in Table 1. For calculating the relative application frequency, we refer to the ratio between applications detected and total amount of model transformations (168). However, for the application frequency of transformation chains, we employ the ratio between applications and total amount of transformation projects (103), because a chain is not tailored to one transformation, but to a complete transformation project.
Reuse mechanisms, whose applications might be detected automatically include functions, inheritance, superimposition, higher-order transformations (HOTs), and transformation orchestration, as described in the following.
Functions. As well-known from procedural programming languages, functions in transformation languages provide means to extract and to reuse recurring transformation logic. In ATL, functions are called helpers and are defined in OCL. The application frequency of functions in ATL transformations may be detected automatically by querying, if helpers are contained in a transformation as indicated by the following OCL query.
T r a n s f o r m a t i o n . a l l I n s t a n c e s ( ) −> s e l e c t ( t | t . h e l p e r s . notEmpty ( ) )
When analyzing the result, it may be seen that helpers are used in nearly 80% of the inspected transformations (cf. Table 1) and the higher the amount of rules within a transformation, the higher the amount of helpers is (cf. Fig. 2(a)). This might be due to the fact that helpers are included, since the very first version of ATL and also because functions are a well-known reuse mechanism from traditional software engineering. Furthermore, functions might be that popular, because they are expressed in OCL, and consequently, there is no further learning curve for the transformation designer, since she is typically familiar with OCL.
Rule Inheritance. Inheritance between meta-classes in metamodels necessitates the usage of inheritance between transformation rules to avoid code duplication, e.g., duplicate assignments. The application frequency of rule inheritance may be automatically detected by searching for rules that extend other rules, which is indicated by the reference Rule.superRule in the ATL metamodel and exploited in the following OCL query. Although, a tremendous amount of metamodels of the Zoo employs inheritance (around 75%), rule inheritance is rarely used in the Zoo (6 applications, only), 7 whereby there is a strong correlation (correlation coefficient about 0.90) between the amount of meta-classes and the amount of inheritance relationships (cf. Fig. 2(b)). Consequently, rule inheritance would be especially beneficial for large metamodels. However, most surprisingly, inheritance between rules has been used rather by middle-sized transformations. A reason for the poor adoption of inheritance in model transformations might be that the support for inheritance in ATL is still limited, e.g., the declarative part of ATL is considered in rule inheritance [27], only. Furthermore, there is only limited support for static semantic checks, aggravating the correct application of rule inheritance. Module Import. Module import allows to build the union of transformation rules from different model transformations. Thereby, rules or helpers may be 7 It has to be noted that inheritance has been introduced in the ATL 2006 compiler.
This induces that rule inheritance may have been theoretically employed in about 60% of all transformations. redefined, i.e., a rule or a function may be replaced by a new one, and additional rules and functions may be added. This concept is known in ATL as superimposition [25]. To automatically recognize superimposition, the launch scripts have been analyzed, since superimposition is introduced at load-time in ATL (cf. OCL query below). Thereby, superimposition is assumed to be used, if a launch script contains an entry with a key Superimpose and a non-empty value. Although superimposition has been introduced in 2007 already, currently no transformation in the Zoo applies this reuse mechanism. A reason for this might be that this mechanism is rather coarse-grained, i.e., rules that should be redefined must be redefined from scratch without the possibility of reusing parts of the refined rule. Consequently, it would be beneficial, if superimposition could be combined with inheritance. Unfortunately, superimposition is not compatible with inheritance, i.e., the rule inheritance hierarchy is broken, if a superrule is redefined with superimposition. Furthermore, ATL imports modules at load-time, whereas numerous other transformation languages import modules at compiletime [9], entailing the advantage that static checks may be applied.
Higher Order Transformation (HOT). HOTs are model transformations that either take a model transformation as input, produce a model transformation as output, or do both and may thus, be used for transformation synthesis, transformation analysis, transformation (de-)composition, or transformation modification [21]. For automatically detecting the usage of a HOT, one has to analyze, whether the input metamodel and/or the output metamodel of a transformation is of type ATL as done by the following OCL query.
When analyzing the transformations of the Zoo, one may find that the application frequency for HOTs is around 4%. HOTs are available in the Zoo, especially for (i) transformation synthesis, e.g., to produce from metamodels a copying transformation for their models and for (ii) transformation modification, e.g., to enrich ATL transformations by adding debugging functionality or tracing capabilities. The low application frequency of 4% may result from the challenging development of HOTs [20] and from the specialized application cases.
Transformation Orchestration. Transformation orchestration is used to reuse transformations in the large, i.e., whole transformations at once. For orchestrating model transformations, build files on basis of ANT8 may be used. Therefore, the automatic detection of transformation orchestrations relies on the recognition, if more than one task for executing a transformation is defined in the build script as formalized by the following OCL query. When investigating the Zoo, transformation orchestration is used in around 11% of the projects, especially in transformation projects that establish bridges between technical spaces. Some transformation chains are quite complex such as employing not only sequences, but also loops of transformation executions, i.e., a transformation is employed for an arbitrary sized collection of models. In the largest model transformation chain, nine transformations are involved. Finally, also HOTs are used in the chains to produce transformations on-the-fly that are applied directly in the later phases of the transformation process.
Besides those reuse mechanisms that might be detected fully automatically, some reuse mechanisms allow for a semi-automatic detection, only, including transformation product lines (TPLs), external domain specific languages (DSLs), and generic transformations (cf. [9] for details). In this context, TPLs allow to configure a transformation externally, i.e., to use, e.g., feature model to configure a transformation and by this to reuse the already predefined transformation rules. An example for this might be a Class2Relational transformation, which allows to follow different object-relational mapping strategies, which might be configurable by a feature model. External DSLs on top of ATL allow to simplify the specification of recurring transformation logic by dedicated language constructs, which finally get translated into ATL code. Finally, generic transformations allow to parameterize transformation logic with types, and thus, allow to decouple transformation logic from concrete metamodel types. Current best practice in ATL to implement a TPL is to use an additional input model to configure a transformation. Thus, we selected each transformation having more than one input model as a potential candidate that has to be inspected manually. External DSLs and generic transformations typically employ a HOT that either generates a new ATL transformation (external DSL) or that rewrites an existing one (generic transformations). Consequently, hints for the application of these reuse mechanisms may be detected by analyzing, if the ATL metamodel is used as the target metamodel of a transformation (cf. OCL query below). The resulting hints need to be verified by manual inspection of the transformations. → n a m e = ' A T L ' ) )
Although candidate transformations for these reuse mechanisms have been detected, the manual inspection thereof showed that none of these reuse mechanisms have been applied in the transformations of the Zoo, which might be due to the fact that those reuse mechanisms just emerged recently and are thus, not reflected in the Zoo. Finally, please note that we did not investigate internal DSLs defined for ATL (e.g., HNL [2], ATL4pros [12]), and reflection as provided by Mistral [8], because these approaches require for a modified ATL execution environment and the transformations contained in the Zoo are executable with the official distribution of ATL, only.
We now present (i) a critical discussion of the results and (ii) we elaborate on several factors that may jeopardize the validity of our results.
Well-known Reuse Mechanisms Made their Way into Practice. With respect to the posed research question, one may see that the frequency of the application of reuse mechanisms varies strongly between the different reuse mechanisms. Helpers are frequently used in transformations. This seems quite natural, because (i) factorization of recurring logic to functions is well-known from procedural programming languages, (ii) OCL, which is mainly used to define helpers, is a well-known language for transformation developers, and (iii) helpers have been provided from the early stages of ATL -thus, it is also well-documented in the ATL user guide and well-demonstrated by several examples. Furthermore, at least some transformations apply rule inheritance, which is comparable to inheritance in object-oriented programming languages. Finally, orchestration is also a common and well-understood reuse mechanism in software engineering and has achieved practical application.
Reuse Occurs in a Narrow Scope. By further investigating the applied reuse mechanisms, it may be seen that reuse occurs most often within a single transformation, only, i.e., reuse across transformation boundaries is performed rarely. Thus, it may be concluded that reuse mechanisms that have a direct and instant benefit for the transformation developer, when creating a single transformation are applied more frequently. Other reuse mechanisms such as TPLs, generic transformations, and external DSLs, which unfold their full potential over the time and require more complex abstraction and specialization mechanisms, still have to wait for their frequent application.
Challenging Abstraction/Specialization may Hamper Application. Any reusable artifact needs abstraction as well as specialization to be adapted to the current context. However, the abstraction of reusable artifacts is often challenging. This applies especially to HOTs as also stated by Tisi et al. [20], where the user must be familiar with the abstract syntax of the transformation language. In case of generic transformations, specialization requires that mappings between the metamodels of the transformation to reuse and the new transformation have to be defined by the transformation designer in order to overcome heterogeneities between the involved metamodels.
Threats to Validity. Internal Validity: Are There Factors, Which Might Affect the Results in the Context of ATL? Applications of superimposition may have not been found, because of missing launch scripts. Sometimes screenshots are provided, only that may not be processed automatically to detect applications of reuse mechanisms. The same holds for missing build scripts in case of transformation chains or chains that are executed manually or by Java programs.
The results may be biased, because only ATL transformations residing in the Zoo have been analyzed. Latest trends in transformation reuse may have not been reflected, since the latest transformations stem from October 2010.
External Validity: To What Extent is it Possible to Generalize the Findings? So far, we cannot claim any results outside the context of the Zoo. Nevertheless, the analysis methods may be applied to arbitrary transformation repositories to compute the frequency of the employed reuse mechanisms. Thus, replaying the presented case study for other transformation languages and repositories should enable the possibility of reasoning about the reuse mechanism applications for those languages/repositories as well.
In this paper, we reported on a case study for analyzing the Zoo's population with respect to the application frequency of reuse mechanisms. For this, we developed a framework for analyzing the population in a semi-automated way. This framework is publicly available and is customizable to investigate other language usage aspects in the future as well.
We see the following topics as possible next steps of this work. First, by having transformations in the Zoo identified that are not using rule inheritance, although the source and target metamodels are heavily using inheritance between meta-classes, would allow to experiment with automated refactorings [28] for improving the transformations' designs. Second, we plan to explore additional transformations that are publicly available but outside of the Zoo. Finally, we also want to expand our work to other transformation languages that offer reuse mechanisms such as QVT.
Acknowledgements. This work has been funded by bmvit under grants ffg bridge 832160 and ffg fit-it 825070 and 829598, ffg Basisprogramm 838181, and by öad under grant AR18/2013 and UA07/2013. We would like to thank Marcel F. van Amstel for providing us the ATL2Metrics transformations which has been the basis for computing several metrics for the Zoo's population.