Model transformations play a major role in model-driven engineering. For increasing development productivity as well as quality of model transformations, di erent kinds of reuse mechanisms have been proposed. However, it remains unclear to which extent reuse mechanisms have made their way into practical application. Thus, this paper presents an empirical study on the ATL Transformation Zoo to analyze the application frequency of reuse mechanisms. For this, we developed a semi-automated process for extracting transformation projects from the ATL Transformation Zoo, which are classi ed and analyzed with respect to the application frequency of reuse mechanisms. Finally, limitations of current reuse mechanisms, which potentially hinder their practical applicability, are critically re ected, pointing out further research directions.
Model-Driven Engineering (MDE) [
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 Host [
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 re ects the results and discusses threats to validity, before Section 5 concludes the paper. 2
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 speci cally, we aimed at answering the following research question: With which frequency are reuse mechanisms currently applied in model transformation projects? 2.1
Case Study Design For performing the analysis of the Zoo's population, we extracted all transformation projects from the Zoo's website5. To reason about the Zoo's population, not only the transformation de nitions are required, but also accompanying artifacts such as the input and output metamodels, launch con gurations, and build scripts. For instance, the metamodels are of interest to relate their size 4 http://www.eclipse.org/m2m/atl/atlTransformations 5 The complete data of this snapshot is available on our project website http://www.
modeltransformation.net and structure to the size and structure of model transformations. The launch con guration les 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 di erent transformation projects, mostly provided as .zip archives, containing 1689 les in total. Before starting the automated analysis of the transformation projects in a subsequent step, the relevant les (transformations, metamodels, launch con gurations, and build scripts) have been extracted from the .zip archives on basis of their le extensions. Consequently, we selected 873 out of the 1689 les: 231 ATL transformations (.atl les), 525 metamodels (.ecore and .km3 les), 57 build scripts (.build or .xml les), and 95 launch scripts (.launch les). The remaining 781 les, being, e.g., readme les 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 di erent 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 di erent 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 Language6 (OCL) expressions, e.g., to select a set of model elements from an input model, as depicted in Fig. 1(b). 2.2
Characteristics of the Zoo 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 transforma6 http://www.omg.org/spec/OCL 781
231 95 57 525
Transformations Metamodels Build Scripts Launch Scripts Unclassified Files 6 17 168
Transformation Queries Libraries (a) Distribution of le types
(b) Distribution of transformation types
Fig. 1. Overview on the ATL Transformation Zoo. tions) in the Zoo available. The metamodels used in the transformations range from small metamodels (below 10 meta-classes) to large metamodels (about 280 meta-classes). The languages represented by the metamodels range from modeling languages such as UML, QVT, and OCL over markup languages such as HTML and SVG to general-purpose programming languages such as Java or domain-speci c languages such as BibTeX. Finally, since support for di erent reuse mechanisms has been successively added over the last years, e.g., functions have been introduced with the rst version of ATL (2005), whereas inheritance (2006) and superimposition (2007) have been introduced in subsequent versions, the submission date to the Zoo is of interest. 3
After introducing the setup of Table 1. Reuse mechanisms' applications the case study, it is described and frequency. taoniwsmhsichavexaitleanbtlethfeorreuAsTeLmeachre- MeRcehuasneism ANpupTmliocbtaeatlrio onfs AFprRepeqlliauctaeitvnieco yn practically applied by transfortrcadmmoehuiseaumattctsorihiaeanmotacgnimnatcusetieisrisiccmdinhzhee,attdbenh(teceiiehtsttieemiw)Zocent,oadeicooiwnsc,naceon.wurad(dshiFsife)n,uoargrelshlhbyosroyeweeramuatwcusliihyeet-- itc iittttcceeooanuADm RSTuOuraplreFnce uhrIsHninTfemohcOPsrtetpLTmirrsooasintastaiisttoniiooncnne 110607314 71040491%%%%%% might be (semi-)automatically toaum itceon External DSL 0 0% sduelttesc,teadn,d (iinia)llyan(ailvy)zeprtohveiderea- i‐SeAm teD TranGsfeonrmeraict ions 0 0% 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. 3.1
Automatically Detected Reuse Mechanisms 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 de ned 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 j 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 rst 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.
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 j t . r u l e s > e x i s t s ( r j r .
,! s u p e r R u l e <> O c l U n d e f i n e d ) )
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 coe cient 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 bene cial 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 [
Module Import. Module import allows to build the union of transformation rules from di erent 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. 120 100 80 rs lep 60 eH 40 20
Fig. 2. Overview on relationships between di erent element types.
rede ned, 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 [
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
modi cation [
T r a n s f o r m a t i o n . allInstances ( ) > s e l e c t ( t j t . models > exists ( m j m . name =
,! ' ATL ' ) )
When analyzing the transformations of the Zoo, one may nd 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 modi cation, 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 [
Transformation Orchestration. Transformation orchestration is used to reuse transformations in the large, i.e., whole transformations at once. For orchestrating model transformations, build les 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 de ned in the build script as formalized by the following OCL query.
B u i l d S c r i p t . allInstances ( ) > s e l e c t ( bs j bs . tasks > s e l e c t ( t j t . name = ' ,!atl . launch ' or t . name = ' am3 . atl ' ) > s i z e ( ) > 1) 8 http://wiki.eclipse.org/ATL/User_Guide_-_The_ATL_Tools#ATL_ant_tasks 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- y that are applied directly in the later phases of the transformation process. 3.2
Semi-Automatically Detected Reuse Mechanisms
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 speci c languages (DSLs), and
generic transformations (cf. [
Current best practice in ATL to implement a TPL is to use an additional input model to con gure a transformation. Thus, we selected each transformation having more than one input model as a potential candidate that has to be inspected manually.
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 j t . i n M o d e l s > s i z e ( ) > 1) 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 veri ed by manual inspection of the transformations. 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 j t . o u t M o d e l s > e x i s t s ( m j m .
,! n a m e = ' ATL ' ) )
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
re ected in the Zoo. Finally, please note that we did not investigate internal
DSLs de ned for ATL (e.g., HNL [
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 di erent 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 de ne 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 bene t 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. [
Threats to Validity. Internal Validity: Are There Factors, Which Might A ect 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 re ected, 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. 5
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 identi ed 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 [
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 oad 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.