Journal of Software & Systems Modelling manuscript No. (will be inserted by the editor)
Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations
Georg Hinkel · Thomas Goldschmidt · Erik Burger · Ralf Reussner
Received: March 14, 2016 / Revision: January 5, 2017/ Accepted: not yet
Abstract Model-driven engineering (MDE) has pro- .NET platform. The results confirm the value of inher- ven to be a useful approach to cope with todays ever ited modularity and tool support while conciseness and growing complexity in the development of software sys- understandability are still competitive. tems; nevertheless, it is not widely applied in industry. Keywords Model-driven Engineering · Model Trans- As suggested by multiple studies, tool support is a ma- formation · Domain-Specific Language · Tool Support · jor factor for this lack of adoption. Especially the devel- Extensibility opment of model transformations lacks good tool sup- port. Additionally, modularization techniques are in- evitable for the development of larger model transfor- 1 Introduction mations to keep them maintainable. Existing tools for MDE, in particular model transformation approaches, The increasing complexity of software systems has been are often developed by small teams and cannot keep tackled in the past by increasing the abstraction of pro- up with advanced tool support for mainstream gen- gramming languages. Today, it seems as if the abstrac- eral purpose programming languages, such as IntelliJ tion level of modern programming languages can hardly or Visual Studio. Internal DSLs are a promising solu- be raised without losing general purpose applicability. tion to these problems. In this paper, we investigate In recent years, many domain-specific languages (DSLs) the impact of design decisions of an internal DSL to the [10] have been proposed, which can be used to describe reuse of tool support and modularization concepts from systems at a higher abstraction level in terms of domain the host language. We validate our findings in terms of concepts. understandability, applicability, tool support and ex- The merit of a DSL is based on how well it can tensibility using three case studies from academia, a be used to document, generate, or reason on a system model-driven engineering platform, and the industrial or its parts. For these tasks, several artifacts need to automation domain where we apply an implementation be created. They are typically deduced by reusing ex- of an internal model transformation language on the isting documentation systems, programming languages, or analyses through transformation. In this process, in- G. Hinkel stances of the DSL are transformed into documenta- FZI Forschungszentrum Informatik, Haid-und-Neu-Straße 10-14, tion, code, or input (models) for analysis. Therefore, 76131 Karlsruhe, Germany model transformations are sometimes called the “heart E-mail: [email protected] and soul” of model-driven approaches, which should be Thomas Goldschmidt supported by dedicated languages [49]. ABB Corporate Research, Wallstadter Straße 59, 68526 Laden- A variety of model transformation approaches [7] burg E-mail: [email protected] exists. They incorporate high-level abstractions, such as the composition of model transformations, into rules Erik Burger · Ralf Reussner Karlsruhe Institute of Technology, Am Fasanengarten 5, 76131 that describe the transformation for a particular model Karlsruhe, Germany element. Developers can use these languages to pro- E-mail: {burger,reussner}@kit.edu duce transformations that are more concise, more un- 2 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner derstandable and sometimes even more performant (cf. a mainstream general-purpose language, such as Java [14]) than transformations written in general purpose or C]1. Given the popularity of these languages, there programming languages. Nevertheless, model transfor- are also rich component frameworks available that can mation languages are still not widely adopted in indus- be reused as a technological foundation for a modular- try. Multiple studies [37, 38, 50, 58] suggest that tool ization concept. Examples for such component frame- support is a major factor in the adoption of model- works include OSGi on the Java platform or the .NET driven engineering. This applies especially to model trans- component model in .NET. formations, given their importance in model-driven ap- Although multiple transformation languages follow proaches. this approach of an internal language, there is no sys- Since model-driven approaches are not widely adopted, tematic analysis yet that would show how the design of often relatively few resources are spent to improve tools. such a language affects the quality of the derived tool This becomes evident when compared to integrated de- or modularization support. Neither has there been an velopment environments (IDEs) for mainstream lan- investigation on what types of tool support can be in- guages, such as IntelliJ or Visual Studio, which have a herited at all. The goal of this paper is therefore to close massive user base. Thus, much more resources are spent this gap by answering the following research questions: for the improvement of these tools. Many model trans- – What types of tool support can be reused from model formation tools are maintained by researchers rather transformation languages implemented as internal than commercial tool vendors, resulting in proof of con- DSLs? cept implementations rather than fully-featured, easy – How does the embedding of model transformation to use tools. concepts into object-oriented concepts affect the qual- An increased application of model-driven techniques ity of derived tool support? in industry would typically go along with the creation of – How can modularization concepts from general-pur- more complex models. Therefore, also the model trans- pose object-oriented host languages be reused for formations would become more complex. To reuse parts model transformation languages? of the transformations in new scenarios as often as pos- sible, the transformations would have to be modular- To answer these research questions, we analyze the ized. In contrast to this, Wimmer, Kusel et al. indicate different design alternatives of how model transforma- that reuse functionality of current model transforma- tion concepts can be embedded into object-oriented con- tions is hardly established in practice [33, 62]. cepts. We sketch how the resulting language would look Furthermore, as Meyerovich suggests [36], many de- like and discuss the implications on several kinds of tool velopers do not appreciate switching their primary pro- support. This discussion is guided by existing studies on gramming languages. They do so only if there is a signif- what kinds of tool support are most important to de- icant amount of code they can reuse, or if management velopers using Java with Eclipse [39]. We have analyzed requires them to do so. This is reasonable since such the model transformation language NTL in three case a change often makes valuable knowledge of particu- studies in order to validate and evaluate the results of lar technologies superfluous. Also, similar concepts are our discussion. sometimes implemented in slightly different ways, caus- This paper extends prior work on reusing compo- ing subtle bugs. As an example in the world of model nent models for model transformation [24] and on in- transformations, the difference in OCL between is-type- vestigating editing and navigation support for inter- of (= is of the exact type of) and is-kind-of (= is of nal model transformation languages [22]. The exten- the exact type or of a subtype of) often causes confu- sion consists of a more holistic view on the subject, sion for developers who are not confronted with it on and an evaluation of open questions from the discus- an everyday-basis. sion through case studies. Thus, two sides of the problem can be identified: The remainder of this paper is structured as fol- On the one side, general purpose languages lack model lows: Section 2 explores what tool support we suspect transformation concepts, and on the other side, dedi- to inherit from the usage of internal DSLs. Section 3 cated model transformation languages lack tool or mod- 1 The choice of a textual languages such as Java or C] as host ularization support. A promising approach to the solu- languages for a model transformation language inevitably leads tion of these problems is the combination of both worlds to a textual model transformation language. Even from the early in an internal DSL [10] for model transformation: The days on, there has always been a demand for graphical model transformation language is embedded in another lan- transformation languages [49]. However, as the success of textual model transformation languages [29, 31], but also the experience guage, called host language. To gain best tool support, with graphical languages [64] imply, textual model transforma- the model transformation language should be hosted in tions may be better suited for certain kinds of problems. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 3 describes the abstract syntax of the transformation lan- or support deployment. The features of the compo- guage extracted from other model transformation ap- nent model determine the tools that can be used. De- proaches. Section 4 discusses adaptation points how tecting version conflicts requires a version concept. In- transformation rules can be embedded in general-pur- tegrity checks usually require digital signatures. Almost pose object-oriented programming concepts aiming for all tools require that components have explicit refer- optimal tool support reuse. Section 5 explains our im- ences. Some component models are tightly coupled to plementation in the internal model transformation lan- the underlying runtime model, such as in the case of guage NTL. Section 6 presents our three case studies .NET, which is why many tools that are based on the to validate our findings and answer questions from the component model are already implemented in the vir- discussion in Section 4. Section 7 discusses limitations, tual machine, such as detecting version conflicts or check- before Section 8 discusses related work. Finally, we con- ing integrity. clude the paper in Section 9. From a developers’ perspective, the tools that are based on the programming model, most notably the programming languages, are probably the most impor- 2 Reuse Potential for Model Transformation tant. The programming model is what the application is Languages as Internal DSLs specified against, and therefore, these tools support the developer directly. Therefore, we divide this category In this section, we investigate the types of tool sup- further into the development activities, i.e., editing, in- port that internal DSLs for model transformation can specting, and validation. Here, editing means to alter inherit. the specification of the application, e.g., through writ- For this reason, we differentiate between three im- ing code. However, this may also include other parts portant development artifacts that make up a develop- of the programming model, such as changing configu- ment platform: the runtime model, the component mo- ration. If OSGi is used, for example, this could be the del and the programming model. The runtime model plugin description. Inspecting refers to the activity to refers to the set of commands that can be executed by analyze existing code to see how it works or identify the machine, which may be a virtual machine such as problems. Validation includes attempts to demonstrate the Java Virtual Machine (JVM)2 or the Common Lan- the correctness of the application. If feasible, this can guage Runtime (CLR)3. By component model, we mean be done through formal verification. For larger applica- the inner structure that defines when and how code can tions, it is likely that correctness is shown only for pre- be reused in different settings. Typical examples include defined examples through tests. Usually, the tools based the OSGi component model4 or the .NET component on the programming model are implemented and bun- model5. Lastly, the programming model specifies how dled in Integrated Development Environments (IDEs). the application is specified, including the programming Model transformation languages implemented in ex- language(s) used, but also possibly additional rules for ternal languages create their own programming model, how it is used. Such additional rules may be implied specifically created for writing model transformations6. by the component framework that is used. For exam- While most approaches use a programming model con- ple, OSGi requires a plugin XML file that describes the sisting of a single model transformation language, some component under development. These artifacts form approaches such as Epsilon [31] use a family of lan- layers, as the component model depends on the ma- guages. This concept is sometimes also adopted for in- chine model, and the programming model depends on ternal languages, for example in Sigma [32]. the component model. The programming models of external languages are The reason for this differentiation is that in our ex- often not compatible with common component models perience, most tools operate on just one or two of these on the respective platform, thus also require a new com- artifacts. For the runtime model, the most common ponent model. A popular exception here is GrGen.NET tools are the machines that ultimately execute the code. [11, 12] that integrates into the .NET component model This includes assemblers, but also virtual machines such as a new .NET language. Often, a new component model as the JVM or the CLR. is not specified explicitly, but rather implicitly through On the level of the component model, tools exist file boundaries, i.e., each transformation file implicitly for example to detect version conflicts, check integrity represents a component. However, there are some no- 2 http://docs.oracle.com/javase/specs/jvms/se7/html/index. table exceptions where an explicit component model for html 3 http://msdn.microsoft.com/en-us/library/8bs2ecf4 6 Many external transformation languages also allow the in- 4 http://www.osgi.org tegration of code written in other languages, such as Java, and 5 http://msdn.microsoft.com/en-us/library/hk5f40ct therefore may include parts of an existing programming model. 4 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner model transformations is introduced [5], though rather that have free control to optimize for these quality at- for the purpose of automated interface adaptation. tributes. However, before we investigate how model trans- In some transformation languages, multiple types formation concepts can be mapped to object-oriented of components exist. For example, ATL distinguishes concepts, we will describe the model transformation between libraries and transformations, where libraries concepts considered in the next section. are not allowed to contain transformation rules. The changed component model usually does not alter the runtime model used, as most transformation languages 3 Abstractions for Model Transformation are implemented in other programming languages such In this section, we extract abstract concepts of existing as Java. Common exceptions are ATL, SimpleGT and model transformation languages. The goal of this sec- EMFMigrate [55], which are now using their own tion is to explain the features that, in our opinion, a Transformation Virtual Machine (EMFTVM, [56]), which model transformation language should support. These however, translates to Java-bytecode and internally uses features are a basis for the later discussion of design the JVM. As a consequence, tool support on the run- alternatives. time model level is reused in any case, independently of Transformation rules are a very useful concept in how transformation languages are implemented. model transformation. They are used in many of the When using internal DSLs for model transforma- most popular model transformation languages, such as tion, the main idea is to reuse large parts of the pro- ATL [29], ETL [31], and QVT Operational [41]. Trans- gramming model. This is done by putting usage rules on formation rules describe how a particular model ele- top of an existing programming language rather than ment is transformed [7]. These explicit transformation creating an entirely new one [10]. The reused program- rules imply mappings from a given source model ele- ming language is also referred to as host language. The ment to elements of the target model, referred to as intended benefit of this construction is that tools oper- the trace. This trace function is built up incrementally ating on the host language can be reused. Furthermore, as the transformation proceeds. Usually, the trace can besides the programming model, also the component also be persisted (as a trace model) when the model model and runtime model are reused, and thus also transformation is completed. the tools operating on them. However, an important The trace can be accessible within the transforma- question here is how model transformation concepts are tion either implicitly or explicitly7. In any case, it is of- mapped to the component model, i.e., whether model ten serialized to a trace model. An implicit trace means transformations in an internal DSL can inherit the mod- that the trace access is transparent to the transforma- ularization concept of its host language at all. tion developer. For example, if a reference of a target A similar argument is also valid for any tools based element is bound to a source element in ATL, the trans- on the programming model: The value of the inherited formation engine automatically looks up the element in tool support is inevitably connected with the goodness the trace, whereas no trace access is necessary if the of fit of the domain concepts to the concepts of the in case of an attribute. ATL, for example, allows both host language. As model transformations describe an implicit and explicit accesses to the trace. If the trace is executable semantic in way similar to general purpose explicit, transformation languages often offer queries on programming language, the reused tool support is likely this trace for entries that are not available yet at query to be valuable for model transformations as well. time. In this case, the transformation engine has to de- Concluding, implementing a model transformation lay the execution of this rule and wait for the trace language as an internal DSL does not yield advantages entry to be available. This implies a dependency be- for reusing runtime model tool support, since this tool tween the transformation rule that accesses the trace support is reused also in case of external languages. and the transformation rule that is traced. The reso- Whether or not component model tool support can be lution of this dependency is usually a responsibility of reused depends on how the transformation concepts can the transformation engine. From our perspective, this be embedded in the object-oriented concepts of the host responsibility taken by the transformation engine is one language. The highest potential for tool support reuse of the major features that make existing model trans- is at the programming model level. formation languages better suited for model transfor- On the other hand, the inherited tool support must mations than general-purpose languages. also be weighted up against other quality attributes, 7 such as understandability and conciseness. As internal We see it as one of the base functionalities of a model trans- formation language that the trace is built up implicitly. The only DSLs are tied to the syntax to their host language, the question is whether the transformation developer sees the trace conciseness is usually worse than for external languages or not. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 5
Transformation rules are based on one or multiple cause the semantics of these members is the same for all input model elements, and produce either one, mul- inheriting classes (behavioral subtyping). To avoid code tiple or no target element (the latter to be used for duplication, one usually wants to specify this shared be- refinement transformations). Some transformation lan- havior just once and reuse it in transformation rules for guages, however, support only single input or output inheriting classes. The semantics of inheritance between model elements. Both the input model elements and transformation rules, however, is different between mul- the output model elements are usually typed. We will tiple transformation languages. While the base rule is refer to the list of input and output types as the sig- still executed in ETL, ATL entirely replaces the base nature of a transformation rule, similar to a methods transformation rule. signature. Transformation rules are often divided into multi- ple sections8. This gives the transformation developer 4 Adaptation Points for Implementing a chance to execute some code before the engine cre- Transformation Rules with respect to Tool ates the trace entry for a given model element. This Support and Modularization offers a flexible selection of the corresponding element, In this section, we discuss the implications of differ- for example when multiple input model elements cor- ent ways to represent transformation rules in object- respond to the same element of the target model. The oriented design. We aim specifically at gaining optimal population of elements in the target model is only per- tool support and modularity concepts for model trans- formed after inserting the trace entry. This avoids end- formations. less recursion if the target element (possibly indirectly) We divide our analysis of tool support into the fol- depends on itself. lowing four categories, based on the discussion from Triple Graph Grammars [48] are a family of trans- Section 2: formation languages where transformation rules do not have a signature in the first place. In TGGs, transfor- – Editing support: Support when creating a new mation rules are triggered by patterns. Here, we regard model transformation or modifying an existing model the entire pattern as input model elements, while the transformation, discussed in Section 4.1. model elements created by the rule constitute the out- – Inspection support: Support when inspecting an put elements. The transformation rule itself then only existing model transformation, discussed in Section 4.2. contains the specification of what the transformation – Test Infrastructure support: Support for auto- engine should do when the triggering pattern is found. mated testing of model transformations, discussed There are situations when the division in sections in Section 4.3. does not suffice to resolve all dependencies, since ele- – Modularization support: Support for checking ments needed for the transformation are not referenced the integrity of a model transformation at runtime, from a transformation rule’s source elements. A popular discussed in Section 4.4. example for this is when the source model uses naming The section is concluded with a short summary in conventions and these names must be resolved. These Section 4.5. cases demand for a stratification of the model trans- Our discussion is based on strongly-typed multi- formation, because some transformation rules require paradigm programming languages such as Java or C] that other transformation rules have been executed for as host languages where there is rich tool support avail- all elements of the source model. Such a stratification able. Furthermore, we concentrate on rule-based, uni- can be implemented in a level model, i.e., by assigning directional, non-incremental model transformation lan- each transformation explicitly a level. Examples such as guages in this section. Incremental or bidirectional model QVT-Operational, where stratification is implemented transformation languages can also be implemented as with the late resolve keyword, show that two levels internal model transformation DSLs [20, 52], but re- already suffice for most cases. quire access to abstract syntax trees as compiled code Another problem that must be tackled in model cannot easily be inverted or incrementalized. Such an transformations is the handling of inheritance hierar- access to the abstract syntax tree is only supported by chies, particularly in the source domain. A common few programming languages, among them C], Python, base class contains members shared among its inher- and Xtend. The code examples we present in this sec- ited classes. In many cases, the transformation of these tion are sketches where we have omitted any modifiers, members is the same for all inherited classes, e.g., be- though they may be obligatory in some host languages. 8 For example, mappings in QVT-operational are divided into Throughout this section, we sketch the design al- init, population and end sections. ternatives through a synthetic example of transforming 6 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner state machines to Petri nets with the same behavior. an importance that entire model transformation lan- This is achieved by creating a place for each state in guages have been built that are dedicated to reuse the the state machine, and likewise creating a transition type-safety of the host language [13]. Thus, the signa- for each transition of the state machine. In addition, a ture of a transformation rule must be known to the transition is created for each initial state that has no compiler. This can be achieved either when the trans- origin place, and a further transition for each final state formation rule is represented by a method, a generic that has no target place. method call, or by turning the transformation rule sig- An example of this transformation is illustrated in nature into generic type parameters, if the host lan- Figure 1, where the state machine is depicted that rep- guage supports it. Given the importance of type-safety resents the lifecycle of a simulation. The advantage of to tool support, especially including editing support, a Petri net here is that, with tokens, Petri nets can be we limit our discussion on those implementation alter- used to represent the state of multiple simulations in natives that maintain type-safety. the same diagram. In particular, we use the transformation rule from 4.1.1 Implementation of Model Transformation Rules states into places as example. This mapping creates a as Methods strict 1:1-relation between the states of a state machine and the places of a Petri net, such as for example to In the implementation as a method, both input and create a place created for the state created in the state outputs of a transformation rule are usually passed in machine. We will not go into detail of this transforma- as input parameters. The reason is that only a sin- tion rule, but remain on a sketching level. gle operational phase of the transformation rule can be provided and the transformation engine otherwise does not have a chance to insert trace entries before a 4.1 Editing Support transformation rule completes. Rule-based transforma- tion engines, such as ATL, ETL, and QVT-O, solve According to a study on the usage of the Eclipse IDE this problem by dividing the transformation rule exe- with 41 Java developers, the basic editing operations cution into phases. An internal DSL can, however, not such as delete, copy, cut, and paste are upon the most influence the host language, so this approach is not vi- commonly used editing commands [39]. These commands able here. Instead, the target elements are created and are supported by any editor. The study showed, how- inserted into the trace before the transformation rule ever, that more sophisticated tools were also often used, is called. The trace can afterwards be accessed through indicating that they raise productivity. The tool sup- inherited methods. port most often used beyond the basic commands was 1 [TransformationRule] code completion. It was used by every developer, mak- 2 void State2Place(State input, [Target] Place output) { ing up in the average of all executed commands. 3 ... 6.7 % 4 } This study was conducted in 2006, and code comple- tion has been improved since by learning from exam- Listing 1 Representing transformation rules as methods ples, frequency, or mined associations [3, 47]. Thus, we expect that the share of advanced tool support, such as This implementation strategy is sketched in List- code completion, has increased since then9. While many ing 1, where we have used an annotation to mark the model transformation tools support basic code comple- method as a transformation rule, and another annota- tion that lists all available members in alphabetic order, tion to mark a parameter as transformation rule output. more advanced code completion is often limited to large However, these annotations are not strictly required. mainstream IDEs10. Sigma [32] is a set of internal DSLs for Scala, where Code completion requires strongly typed environ- the transformation language applies this strategy. The ments, since in this case, the tool knows what methods first parameter is the only allowed input model element are available for a given object. Type safety is of such and the others are assumed to be outputs of the trans- formation rule. 9 The usage of the IDE when writing model transformations Another problem is that most languages make it dif- may differ from the usage in regular programming tasks. Thus, ficult to directly reference methods in other ways than the share of code completion commands could be lower. Neverthe- through their names. One reason for this is that many of less, we think that code completion in particular is also important for model transformation developers. them support method overloading, i.e., a class may sup- 10 Technologies such as Xtext may help by making it easier to port multiple methods with the same name. For the im- implement code completion for an external DSL. plementation of model transformation rules, this means Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 7
created stopped
Created stop
initialize stop stop initialize stop Transformation
reset Paused start Started reset start paused started pause pause
Figure 1 Illustration of the considered example transformation from finite state machines to Petri nets exemplified for a simulation lifecycle.
that it is hard to support explicit tracing or specify de- for transformation of models with a composite pattern. pendencies forming cycles. In Sigma, to the best of our Here, the cyclic dependency can be resolved, since the knowledge, explicit tracing is not supported, and de- transformation rule has to be called with different ob- pendencies between transformation rules are implicit. jects as inputs. This does not mean a transformation Dynamic languages make it easy to reference meth- rule execution depends on itself. ods, but these are not type-safe. Therefore, we exclude them from our consideration. 4.1.3 Implementation of Model Transformation Rules as Classes 4.1.2 Implementation of Model Transformation Rules as Method Calls The representation of model transformation rules as classes means that there is a generic transformation rule If transformation rules are represented as generic method class that each rule inherits from, passing the rule signa- calls, each transformation rule is an object created by ture as generic type parameters. Here, different phases calling a generic transformation rule method, accepting of a transformation rule can easily be represented by a configuration, such as different phases of the transfor- different methods of the class which the transformation mation. rule may (or has to) override. 1 var state2place = TransformationRule
4.2 Inspection Support
A large proportion of development activities is devoted on the analysis of existing code and navigation through it [39]. However, the navigation support of the mostly used search commands (searching for references to a selected element or its definition) can be derived inde- pendently of the transformation rule representation, if there is a representation as a code element at all (as opposed, e.g., to pure naming conventions). For external languages based on DSL frameworks, such as Xtext11, a simple form of visualization can be Figure 3 A visualization of a model transformation from finite state machines to Petri Nets using the Code Map tool obtained with few effort through the Outline view, which many model transformation tools use. However, this view only shows the document structure, not how the As an example, we have depicted the visualization elements of the transformation language are intercon- of an example model transformation from finite state nected, e.g., through (explicit or implicit) dependencies. machines to Petri Nets in Figure 3. This visualization Rentschler et al. have shown that a visualization of a can be obtained by simply reusing the Code Map fea- model transformations structure including the relation- ture built into Visual Studio. Even the layout is done ships between transformation rules aids the navigation by Visual Studio. The transformation rule in which the and helps to understand relations between transforma- caret currently resides is marked with a green arrow. In tion rules, at least in QVT Operational [44]. Thus, it this example, transformation rules where implemented is helpful for the maintainability of model transforma- as classes, but one could obtain similar results when tions. choosing an implementation as methods. A drawback is that this visualization is only avail- able on the syntactical level. For example, the model transformation from Figure 3 specified reversed depen- dencies, such as the rule StateToPlace specifies that Figure 2 Visualization of dependencies by Rentschler et al. [44] it should be called whenever the rule AutomataToNet is called. The same dependency (from a perspective of the A brief example of the visualization of this support engine) could also be specified in the rule AutomataToNet, is depicted in Figure 2. The tool implementation au- but the visualization would draw an arrow in the oppo- tomatically keeps track of which model transformation site direction, then. rule is currently worked on in the editor, and informs For internal languages, inherited visualization is of the developer on where this transformation rule is used, particular importance. Unlike external languages, in- and what other transformation rules it uses. Alterna- ternal languages are merely guidelines on how to use a tively, the developer may get an overview of all model framework. These guidelines are, however, not enforced 12 transformation rules including their dependencies. by the host language compiler . As a consequence, A similar visualization is getting common for gen- static analysis, such as visualization tailored for the in- eral-purpose object-oriented code. It visualizes the us- ternal language, is of limited applicability. For analyses age of members within a class or the usage of classes that look at the big picture, such as visualizations of within a package, as for example with Code Maps in the entire transformation, this means that it is hard to Visual Studio. This analysis is based on metadata, i.e., create something above the inherited visualization sup- classes, methods, and their interrelations based on the port. Alternatively, dynamic visualization that operate methods’ bodies. Objects as results of method calls 12 Technologies such as the modular compiler Roslyn are not part of this metadata, since they are runtime (https://roslyn.codeplex.com) give internal languages the chance artifacts and cannot be predicted at compile-time in to enrich the host language compiler. In the contrary direction, technologies such as Xbase [8] make it possible to use general- 11 https://eclipse.org/Xtext/ purpose language compilers in external DSLs. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 9 on the runtime semantic model [10] used in the DSL variable, just like in regular general-purpose code. We implementation is a viable approach, as supported by expect that this is about as useful as in general-purpose SDMLib [64]. They are, however, hard to integrate in code, since the transformation rule then is at the level the development environment and laborious to develop. of regular general-purpose code. This is different when For the implementation of transformation rules as the transformation rule body is specified in a declar- methods or types, as outlined in Section 4.1, the us- ative way. For example, in NMF Synchronizations age of a transformation rule is the same as the usage of [20], the transformation rule bodies are specified as ex- this method or type. Therefore, advanced visualization pressions. They are then runtime-compiled or incremen- techniques that show dependencies in object-oriented talized by the transformation engine. In this case, even programming can be used to visualize the structure of setting a breakpoint is impossible. Therefore, the de- model transformations. An implementation of transfor- bugging support in terms of variable inspection is inde- mation rules as method calls cancels the possibility of pendent of the representation of model transformation inherited visualizations, as objects are only available at rules in object-oriented design. It rather depends on runtime (unlike metadata). how the transformation rule bodies are implemented. In summary, even though the most often used com- Lastly, model transformation languages may stati- mands for inspecting model transformations can be reused cally analyze model transformations for desirable prop- from general-purpose tools, regardless of the embed- erties, such as property preservation [61], termination ding of transformation rules into object-oriented con- [9], or similarity between source and target models [28]. cepts, we see a major potential for reusing tool support Since these analyses are based on concepts specific to for visualization offered by an implementation either as model transformation, no such static analysis can be classes or methods. inherited. However, as internal DSLs should create a Debugging is a further important aspect of inspec- semantic model of the model transformation anyhow, tion support. According to Murphy [39], the step-over such static analysis can be implemented regardless of command in the average makes up 3.2 % of all executed the representation of transformation rules in code. commands in Eclipse during general-purpose program- ming. While debugging, the programmer has a program 4.3 Test Infrastructure Support slice (usually as a call stack) at hand, and may observe the status of variables defined in the program. Such in- The verification of arbitrary programs in general suf- teractive execution and slicing is also available in multi- fers from the Halting problem: The question whether ple model transformation languages [11, 27, 44], where a program terminates cannot be decided in general. the slices are often visualized graphically. Since model transformation languages should be Tur- Model transformation languages implemented in an ing-complete [49], verification is infeasible in the general internal DSL get the host language debugger for free, case. Thus, tests are necessary to increase the probabil- but it is questionable whether the generated program ity of bug detection, similar to regular general-purpose slices, i.e., call stacks, are meaningful for the transfor- code. Tests can be categorized according to their scope, mation developer. When a breakpoint is hit, the call ranging from unit tests, module tests, up to integration stack likely contains internal calls of the transforma- tests, and further. While tests on higher levels of ab- tion engine, where it may not be clear to the transfor- straction usually target a system’s external interface, mation developer which transformation rule is affected. unit tests aim to cover the entire code and test func- In-depth knowledge would be necessary to know if the tionality in isolation. underlying engine or the debugger simply hides these el- For most general-purpose languages, frameworks ex- ements because it is treated as external code. However, ist that support developers in writing unit tests. Tools the problem of inappropriate program slices can be cir- then provide support to automatically execute the tests, cumvented if the transformation language also supports and summarize the results and measure the test code program slices of its own, such as implemented for in- coverage in terms of covered lines or covered blocks. stance by SDMLib [64]. This is mandatory in many software development pro- The inspection of variables can in some cases be cesses, since they demand test code coverages by unit used in the context of an internal model transforma- tests of close to 100 %. tion language. This depends on how the transforma- The usage of internal DSLs has the advantage that tion rule bodies are specified: If they are specified as any complex functionality can be extracted into a method executable code, as in most languages, the transforma- outside of the model transformation framework, and tion developer may break anywhere in the body of the tested in isolation. However, it is furthermore desir- transformation rule and then inspect the state of any able to test artifacts that are smaller than the entire 10 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner model transformation in isolation, e.g., to detect bugs possible through dependency injection, so targets of ex- in transformation rules rather than in transformations. ternal calls can be replaced by means of configuration. This requires the transformation rules to be accessible However, transformation rule bodies are not always from outside the model transformation. Furthermore, directly represented as methods. As a consequence, it is it requires that model transformation engines can re- hard for a model transformation engine to analyze com- semble the environments of every transformation rule piled code. Therefore, additional benefits are easier to execution separately. Since dependencies of transfor- support in other ways. This may include incremental- mation rules usually imply the transformation of an ization, or paradigms that are cannot be easily reflected entire (sub-)model, this poses the requirement of a sep- in the host language expression grammar, such as graph arate execution strategy, although it is not a conse- patterns. NMF Synchronizations [20] and SDM- quence of the implementation of transformation rules. Lib [64] are two examples of internal model transfor- Therefore, there is no difference between the three im- mation languages, where the transformation rule body plementations of transformation rules considered from does not consist of a method call. In NMF Synchro- Section 4.1 regarding test infrastructure support. nizations, transformation rules are described by syn- chronization jobs. These jobs pass the abstract syntax tree instead of compiled code, to enable implicit incre- 4.4 Modularization Tool Support mentality and bidirectionality. Here, calls to external components are allowed, provided the called method Besides the potential of inheriting tool support on the implements the bidirectionality and incrementality in- programming model level, as discovered in the last three terface. Otherwise, the resulting model transformation sections, this section explores the support for modu- is not correct. In SDMLib, the body of a transforma- larization and extensibility that can be gained from tion rule is described as a triple of graph patterns. It is a reused component model. For this, we first discuss thus not easy to extend by third-party components. how the underlying component model of object-oriented The very basic modularization concept to break trans- platforms can be reused for model transformation, and formation rules into smaller helper functions is sup- afterwards discuss the consequences in terms of inher- ported by many existing model transformation languages ited tool support. and straight-forward to achieve. The exception to this As Belaunde has pointed out [2], there are two types rule is the implementation of transformation rules as of model transformation composition, which generally methods where the engine additionally needs to sepa- referred to as external and internal composition. While rate helper methods from transformation rules, but this external composition reuses model transformations as a can be accomplished by extracting helper methods into whole, internal model transformation reuses parts of the a different class. It gets much more interesting when model transformation. Therefore, external model trans- combined with a transformation rule superimposition formation composition approaches are rather centered concept [57, 63], similar to ATL. Such superimposed on the organization of model transformations for an ap- rules are able to change the body of a transformation propriate reuse, independently of model transformation rule in order to slightly adjust the behavior of the model languages. Thus, they are out of scope in the discussion transformation to specific needs and reuse other rules of design alternatives for implementing model transfor- unchanged. mation languages. Therefore, we concentrate on inter- Superimposition requires that transformation rules nal model transformation composition techniques in the can be overridden in some form. From the implemen- remainder of this section. tation strategies for transformation rules presented so One of the advantages of using an internal language far, this works for an implementation as method or as is the easy integration of arbitrary host language code. a class as these two artifacts support polymorphism. This immediately yields a parametrization as proposed With such a concept, it is possible to implement super- by Olsen et al. [42]. Furthermore, if the body of a trans- imposition by creating new transformation rules that formation rule is represented by a method body, then inherit from existing ones, overriding their body. this embedding yields a possible modularization of a 1 override void State2Place(State input, [Target] Place output) { transformation rule body: A method in object-oriented 2 ... 3 } programming languages can be divided into multiple helper methods. It can access objects and methods de- Listing 4 Superimposition when transformation rules are fined in other components, possibly made by third par- implemented as methods ties. This basic refactoring operation is even support by most modern IDEs. Such external calls are of course 1 class NewState2Place : State2Place { Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 11
2 override void Transform(State state, Place place, Context context) Listing 6 Using abstract classes for transformation rule {...} templates 3 }
Listing 5 Superimposition when transformation rules are implemented as classes An example is depicted in Listing 6: We have ex- tracted a shared functionality of ensuring unique names (by appending for example a number in case of con- Sketches of such an implementation are depicted in flicts) into a separate transformation rule template13. Listings 4 and 5 where we superimposed the transfor- In this case, the transformation rule EnsureUniqueName mation rule State2Place and exchange the main trans- is independent from both source and target metamodel, formation rule body. The problem here is that superim- but it could be bound to either of them. For example, position of model transformation rules translates to in- such generic transformation foster the reuse of transfor- heritance of object-oriented design in both cases, lead- mation rules across metamodel boundaries, as proposed ing to a name clash. Therefore, the terminology of in- by Wimmer et al. [62]. heritance is a bit dangerous. In , transformation NTL Component models, such as .NET or OSGI, describe rule inheritance is therefore called instantiation. the interface of components by the set of publicly ex- For implementations of transformation rules as meth- ported types. Thus, a transformation rule template like ods, the transformation can only be overridden as is, EnsureUniqueNames can go into its own component, and because it is not allowed to only override parts of a be reused across multiple model transformations of mul- method. This is different in the implementation of trans- tiple domains. Such an internal composition has advan- formation rules as classes, where multiple phases of tages over external composition: The application of the the transformation rule can be overridden separately. derived transformation rule may adjust the semantics Therefore, in the remainder of this section, we will con- of the inherited transformation rule template in a much centrate on the implementation of transformation rules more fine-grained way. For example, it can invoke the as classes. inherited transformation rule body only conditionally. If the helper methods for a given transformation rule As soon as model transformations may be split into are virtual, they make up a new, more fine grained in- multiple components, a range of problems arises. The terface of the transformation rule to the transformation various components used in a model transformation engine. At the same time, they may seal the original may not fit together as a consequence of some evolution interface in many languages. Thus, derived transforma- step, or components may require incompatible versions tion rules may override only parts of the transformation of a shared component. rules body, while the implementation of other aspects is Nowadays, object-oriented component models, such hidden, even to the deriving transformation rules. For as OSGI or .NET, are able to solve these kind of prob- example, a transformation rule may allow to adjust its lems elegantly. They assign version numbers to compo- body, while the creation of dependencies is closed to nents, apply digital signatures, and have references to deriving transformation rules. other components that explicitly contain version num- An interesting concept can be gained if it is allowed bers and public keys to validate the digital signatures. that transformation rule classes are abstract. Since helper With a semantics attached to version numbers, the com- methods may then be abstract as well, such an abstract ponent model may decide whether a newer version of transformation rule class is turned into a transforma- a given component is a bugfix or a major and thus tion rule template. Users then have to fill in some gaps breaking change. For example, in .NET, version num- by implementing the corresponding abstract method. bers consist of four parts: major, minor, build, and re- This can be combined with generic type parameters in vision. By default, changes of build and revision num- order to decouple a transformation rule from a concrete ber are interpreted as bug fixes. The runtime will then input or output metamodel. load assemblies with higher build or revision numbers instead of the specified referenced assembly. Higher ma- 1 abstract class EnsureUniqueName
and visualization support, but achieves a very concise specification. The question of which of these approaches is the Implementation best cannot be answered in general. It depends on the of Transformation
As Methods As Method- calls As Classes purpose of the transformation language. For very com- rules plex transformations, we suspect that a mapping of Schematic example List. 1 List. 2 List. 3 transformation rules to classes would be the best. A Concise syntax • • ◦ transformation language for rather small transforma- Type-safety • • • tion tasks would be better handled by an implementa- Multi-phase ◦ • • tion as methods, hoping that a single transformation Explicit Tracing ◦ • • phase suffices. The implementation as method calls of- Explicit Dependen- ◦ • • fers a compromise, if visualization is not an important cies aspect. Cyclic Dependencies • ◦ • Navigation • • • Nevertheless, to get a better understanding of these Visualization • ◦ • differences, a several open questions remain: Test infrastructure • • • Integration of host • • • language – How much does the degraded conciseness of Superimposition • ◦ • an implementation of model transformation Transformation rule ◦ ◦ • rules as classes affect other quality attributes, templates such as understandability or maintainability? Degraded conciseness is the only point where the •= supported ◦= not supported implementation of model transformation rules as Table 1 Comparison of different implementations of transfor- classes loses against other embeddings, but it is a mation rules in object-oriented design very important aspect that must not be neglected. Therefore, the impact of this degraded conciseness to quality attributes such as understandability or nent is found, the runtime raises an exception, detecting maintainability must be characterized more clearly. possible versioning issues. – What is the added value of transformation rule templates that are only supported by an implementation of transformation rules as 4.5 Summary classes? Transformation rule templates are a con- cept that has been well known for more than a This section summarizes the findings from the previous decade [54]. Nevertheless, it has hardly been adopted sections in a tabular form. The table concentrates on in model transformations yet. Thus, the worth of the main two alternative strategies that we see as viable this feature is questionable. options to implement transformation rules in object- – Is the approach of internal model transfor- oriented design, implementing transformation rules as mation languages applicable in the industry? classes or as methods. Internal model transformation languages have a de- The summary is depicted in Table 1. It compares graded conciseness compared to external languages. the implementation strategies that implement transfor- There is a threat that the tool support is impaired mation rules either as methods, method calls or classes. compared to their host languages. Thus, they do For most of the characteristics considered, all three im- not only combine the advantages of both external plementations are valid solutions. However, there are model transformation languages and their general- some trade-offs: The implementation as classes is the purpose host languages, but, to some degree, also most flexible and powerful in terms of modularization their disadvantages. concepts, but lacks conciseness, which is an important quality attribute of model transformations. An imple- mentation as method is assumed to have the best con- Based on these open questions, we have conducted ciseness, but lacks support for multiple transformation three case studies using NTL, a model transformation phases or explicit tracing. Furthermore, it offers less language representing model transformation rules as modularization functionality. Lastly, the implementa- classes. We present the language in the next section tion as method calls lacks modularization techniques before we describe the case studies in Section 6. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 13
5 The NMF Transformations Language (NTL) Both of these parts can be assigned individual strati- fication levels (DelayLevel). Transformation rules can The implementation of transformation rules as classes have dependencies. These depencies specify the follow- yields the most potential for reusing tool support, based ing four properties: on Table 1. At the same time, it has the disadvantage of – the dependent elements for a given source model a less concise syntax. This in turn has implications for element understandability and maintainability, and therefore is – filters that define whether the dependency is appli- very important. To get a better understanding of the cable advantages and disadvantages, we developed a model – whether the dependent transformation rule must be transformation language that follows this approach: the executed before the current one and NMF Transformations Language (NTL) [19]. – how to register the created target element at the Thus, this section describes NTL, the concrete syn- target element of the current transformation rule tax of the model transformation framework of NMF [21]. The language uses C] as host language. It is able In constrast to many other transformation languages, to describe model transformations from and to arbi- guards are not specified at the transformation rules, but trary runtime objects. The implementation is part of on the dependencies. NMF and thus available as open-source14.
5.2 Specification of model transformations 5.1 Abstract Syntax As we are aiming for a comprehensive transformation We begin our description of NTL by explaining its language, we represent transformation rules as classes abstract syntax. We have implemented the abstracted that inherit from a common generic transformation rule syntax in the model transformation framework NMF class. We pass in their signature as generic type param- Transformations, for which NTL provides a con- eters (cf. Section 4). The different phases of the trans- crete syntax. However, the abstract syntax is also used formation rule (cf. Section 3) are specified by overriding in other languages, such as the synchronization lan- methods from the base class. Thus, transformation rules guage NMF Synchronizations [20]. in NTL exactly look like the rule sketched in Listing 3, ] In general, a model transformation in NMF Trans- except for some syntactic boilerplate: In C , overriding formations consists of transformation rules. These rules methods must repeat the entire signature of the base are aware of their signature and may have dependen- method, accompanied by the keyword override. The cies. resulting syntax can be seen in Listing 7. We have decided to make these dependencies be- 1 public class FSM2PN : ReflectiveTransformation { 2 public class State2Place : TransformationRule
Transformation
+ Initialize() SingleDependency MultipleDependency
transformation 1
rules 0..* Dependency TransformationRule dependentRule + ExecuteBefore : Boolean + InputType : Type[] 1 + Filter : Function + OutputType: Type + Selector : Function parentRule dependencies + CreateOutput : Function + Persistor : Function + Transform : Function 1 0..* # HandleDependency()
Figure 4 Simplified Abstract Syntax of NMF Transformations
Listing 8 Specifying dependencies in NTL mation. It may override the transformation rules con- tained in this transformation, or add new transforma- The specification of dependencies for a transforma- tion rules. tion rule is sketched in Listing 8. Dependencies are cre- 1 public class NewFSM2PN : FSM2PN { ated in a dedicated method RegisterDependencies (see 2 [OverrideRule] line 2), which is run by the transformation engine at 3 public class NewState2Place : State2Place { ... } 4 } initialization of the transformation. Unlike transformation rules, dependencies are rather Listing 10 Superimposition in NTL uninteresting in code visualization. Furthermore, de- pendencies need not to be cross-referenced. Therefore, An example is depicted in Listing 10. Here, the we represent them as method calls in a dedicated func- model transformation NewFSM2PN superimposes the pre- tion of transformation rules. The attributes of depen- viously defined FSM2PN transformation and changes the dency elements of the abstract syntax are simply passed State2Place rule. Thus, any other transformation rule as method call arguments. In line 3, such a call is made referencing State2Place will now reference the new New- creating a dependency of the rule State2Place to Tran- State2Place rule. sition2Transition for each outgoing transition of a state The entire finite state machine to Petri nets trans- in the state machine (line 4). The resulting transitions formation can be found in [19]. We have abbreviated it are then added to the From reference of the Petri net here. place, which is the transformation result of the current state (line 5). Alternatively, the target elements of the transfor- 5.3 Executing a model transformation in NTL mation rule can be populated in the Transform method In , the transformation engine is encapsulated be- of the transformation rule. This method contains a ref- NTL hind an interface. Therefore, it is replaceable. This in- erence to the transformation engine, which includes an terface mainly consists of a method that executes a access to the trace, similar to the context parameter in given transformation rule for a given input model el- Listing 3. ement and an access to the generated trace. This sepa- 1 public overrides Transform(State state, Place place, ration makes the transformation engine independent of ITransformationContext context) { 2 var transitions = context.Trace.ResolveManyIn(Rule< the syntax of NTL and therefore reusable. For example, Transition2Transition>(), state.Outgoing); it has also been used in for 3 place.From.AddRange(transitions); NMF Synchronizations 4 } incremental model synchronization[20]. Listing 9 Alternative registrations of transitions through an In the default implementation for the transforma- access to the trace tion engine, the execution of a transformation rule im- plies the (sequential) execution of its dependencies, which With this transformation context, the persistor from usually cause the entire model to be transformed. How- Listing 8 can be specified in the main population method ever, a second execution strategy exists that only queries Transform, as shown in Listing 9. The advantage over predefined transformation records and does not exe- the more concise version in Listing 8 is its higher flexi- cute dependencies. This allows the execution of a sin- bility. gle transformation rule in isolation. A third execution NTL also supports superimposition. A transforma- strategy is planned that will execute dependencies of a tion rule may extend exactly one other model transfor- transformation rule in parallel. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 15
A consequence of this design is that transformation modularity properties. Therefore, we have added a sec- rules can easily be tested. In such a unit test, developers ond case study to investigate the modularity gained can inject trace entries into the transformation engine by the proposed embedding into object-oriented de- such that any calls from a transformation rule to the sign. Specifically, we want to validate that the pro- transformation engine can be mocked. posed mechanism of transformation rule templates may have advantages over other modularization concepts in a larger scenario. The case study is a code generator of 6 Evaluation and Validation model-driven engineering. It generates model represen- tation classes for metamodels that support refinements In this section, we validate our findings through three of attributes and references. Here, the functionality to case studies employing NTL as a representative of the map multiple inheritance to interfaces and appropri- implementation of transformation rules as generic classes. ate implementation classes is to be extracted into a In particular, we want to validate the claimed bene- reusable component. We compare different strategies fits for transformation rules in terms of modularization, for how such a reusable component could be realized, test infrastructure and industry applicability. Addition- and discuss advantages as well as disadvantages. This ally, we evaluate how the design alternative affects the discussion is contained in Section 6.2. conciseness of the language. As conciseness always af- By construction, internal languages cannot be more fects understandability, we also discuss these implica- understandable than external languages. Furthermor, tions. tool support is optimized for the host language and We do not validate the editing support, as we see it may not be as suitable for the internal DSL. Thus, as an immediate consequence of type-safety. The degree there is a risk that gained abstraction in comparison of tool support that can be inherited is dependent on to general-purpose code may not outweigh the poten- the host language. As indicated by the aforementioned tially degraded tool support. In a third case study, we Eclipse user study [39], editing support such as code have investigated the applicability of NTL in industrial completion is used very often, so it is reasonable to scenarios compared to a (hypothetical) general-purpose assume an added value. An equivalent argument holds solution. In particular, we have created a code gener- for navigating to a declaration, which is why this is ator that generates code for address space models of also omitted. Also, we do not validate the features of the OPC Unified Architecture standard (OPC-UA)15, the language in terms of explicit tracing and multiple a widely used communication standard in the Indus- phases, as these rather depend on the implemented API trie 4.0 initiative that aims to improve production pro- than on the general embedding of model transformation cesses using information from multiple sensors. Besides concepts into object-oriented design. applicability in industrial applications, we want to val- In the first case study, the Flowgraphs case from idate the testing infrastructure that can be inherited the Transformation Tool Contest (TTC) 2013, we com- by model transformations representing rules as classes. pare the understandability and conciseness of NTL with Therefore, we evaluate the test code coverage that can other model transformation languages. As solutions for be achieved using NTL and how the unit tests look the Flowgraphs case have been created mainly from like. As we introduced internal model transformation developers of the respective model transformation lan- languages as a way to mitigate the industry adoption guage, we can assume that the submitted solutions are problem of MDE, we also aim at evaluating the po- just as good as possible with the given tool. This al- tential for industry adoption of model transformation lows to compare the model transformation languages concepts. Therefore, we analyze results of a small ques- through the solutions. At the same time, the solutions tionnaire that asked to estimate advantages and disad- have been reviewed by the participants of the TTC vantages of the proposed solution in comparison to a workshop. We use these reviews and the solutions to hypothetical general-purpose code solution16. The case discuss the quality attributes of NTL. For this, we will study is presented in Section 6.3. compare NTL with other solutions: FunnyQT as solu- tion using an internal language as well as several exter- nal languages. However, the reviews only covered few quality attributes, such as understandability and con- ciseness. The analysis of the Flowgraphs case is depicted 15 https://www.opcfoundation.org/UA/ 16 in Section 6.1. The reason to compare the solution with a general-purpose code solution instead of for example an external model trans- Though the Flowgraphs case did include a very small formation solution is that this would have been the most likely extension scenario, we think it is too simple to validate alternative in that particular case. 16 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner
6.1 Case Study: The Flowgraphs Case from the Listing 11 Transforming while loops with NTL Transformation Tool Contest
1 (while-loop2loop [wl] In this section, we summarize the results of the Flow- 2 :from ’statements.WhileLoop 3 :to [fgl ’flowgraph.Loop] graphs case at the TTC 2013 [26]. In this contest, teams 4 (eset! fgl :txt (stmt2str wl)) were requested to solve a range of model transforma- 5 (eset! fgl :expr (expression2expr (eget wl :condition))) 6 (eset! fgl :body (stmt2item (eget wl :statement)))) tion tasks with their favorite transformation tools, pro- viding a unique opportunity to compare the underly- Listing 12 Transforming while loops with FunnyQT ing transformation languages and tools with respect to some quality attributes. 1 rule WhileLoop2Loop { 2 from The task of this case study is to create both con- 3 s : Java!WhileLoop trol flow graph and data flow graph for source code 4 to 5 t : GRP!Loop ( written in Java. For this purpose, Java source code 6 expr <- s.condition, 7 body <- s.statement, is turned into a model-based representation using the 8 txt <- s.getText JaMoPP parser [15]. To simplify the transformation, 9 ) 10 } only a subset of this metamodel was considered. This JaMoPP model is then transformed into a control flow, Listing 13 Transforming while loops with ATL from which a further in-place transformation extracts the data flow. 1 from src : in!WhileLoop 2 to tgt : out!Loop The solutions for this contest employed the transfor- 3 tgt.expr < src.condition mation languages NTL, ATL, Eclectic, e-Moflon 4 tgt.body < src.statement 5 tgt.txt = task1_attribution!text[src] and FunnyQT. From these, the languages NTL and 6 end FunnyQT are internal DSLs, whereas ATL and Eclec- Listing 14 Transforming while loops with Eclectic tic are external textual DSLs. e-Moflon is not con- sidered in the comparison, since the solution was at the Though the transformation rules are only very small stage of a proof-of-concept, which impairs the validity parts of the respective model transformation solutions, of manual assessments collected during the TTC. some conclusions can already seen in Listings 11-14. For As external languages can be optimized in syntax for example, as one may guess from Listing 11 in compar- conciseness and understandability, it is hard for an in- ison to the other listings, NTL was the least concise ternal DSL to beat such languages, since it is still bound solution, as expected. This is due to the fact that NTL to the syntax of its host language. The conciseness that requires explicit dependencies and therefore needs three can be achieved depends on the flexibility of the host lines of code for a task that can be expressed in a single language’s syntax. Since internal DSLs can never be as line in most other transformation languages. Further- concise and understandable as external model transfor- more, in NTL, access modifier keywords such as public, mation languages, the validation seeks to answer how the keyword override, and the complete method signa- close internal languages can get. tures must be included in a transformation rule defini- To give an impression of the difference between the tion, making the syntax much less concise than that of solutions, we have depicted the transformation rules for opponent solutions. the transformation of a JaMoPP while loop into a Loop On the other hand, the FunnyQT solution notably element of the Flowgraphs metamodel in Listings 11-14. proves that internal languages need not necessarily be less concise than external languages if the host language 1 public class WhileLoop2Loop : TransformationRule
Overall Evaluation
Understandability and Presentation Conciseness ATL Eclectic eMOFLON 2,5 3 3,5 4 4,5 Epsilon FunnyQT NMF Simplicity to use the Familiarity with the language Technology
Usefulness of the language Figure 5 Averaged survey results from the Transformation Tool Contest on a scale between 1 and 5
Solution Task 1/3.1 Task 2 Task 3.2 Total The results seem to imply a language adoption prob- NTL 600 295 45 940 lem for internal DSLs. We think, however, that this is FunnyQT 223 57 19 299 due to the audience that consisted of researchers in the Epsilon 320 90 29 439 model transformation community. (The TTC 2013 was ATL 397 268 66 731 co-located with the International Conference on Model Eclectic 290 97 29 416 Transformation 2013). This also seems to have an ef- Table 2 Implementation size of the Flowgraphs case fect on the quality of the presentation, and in turn may have had an influence on the overall evaluation of the approaches. The results also indicate that conciseness does not is first and foremost an indicator of the conciseness of necessarily correlate with understandability if compared internal languages that can be achieved in Lisp using across multiple languages. In particular, FunnyQT as its macro functionality, as FunnyQT was able to beat the most concise solution also received the worst evalu- even external languages that can optimize for concise- ation in terms of a combined assessment of conciseness ness and understandability. and understandability. As indicated in some responses, After the solutions had been presented to the au- this may be due to the fact that many people in the au- dience at the TTC, the attendees were given question- dience might not be confident with Lisp and had prob- naires about the solutions. The results from this ques- lems in understanding its syntax. tionnaire are depicted in Figure 5. NTL, though the least concise solution in terms of From the shape of the diagram in Figure 5, one can lines of code, was assessed to have an about equal con- see that both solutions using internal DSLs peaked in ciseness and understandability to ATL, even though the the overall evaluation and in the usefulness of the lan- responses indicated an overall lower familiarity with the guage. The shape of the curves is long and narrow. NTL technology. NTL also had a worse conciseness in In the contrary, the shapes for solutions in ATL or terms of lines of code. This may be due to a flaw in eMoflon are rather wide: The attendees were rather the design of ATL refinement transformations: For each familiar with the technologies and the presentation was model element that should survive the refinement, a perceived as better, but the overall evaluation is not separate rule had to be created in ATL to prevent this as good. The curves for the solutions in Eclectic and model element from being deleted. The external lan- Epsilon are rather round, which means they scored guages Epsilon and Eclectic received a better scoring of highest in all aspects, including both a familiarity with conciseness and understandability than NTL. the technologies, a good presentation, but also a good The assessments of understandability and concise- (even the best) overall evaluations. ness of NTL are better than for ATL. This indicates 18 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner that the much more verbose syntax of NTL does not common base class. Because the implementation DImpl degrade its understandability dramatically. Conciseness for the metaclass D may only use one base class, the in terms of lines of code does not seem to be a reliable property PropC has to be replicated in the implementa- indicator of understandability. The achievable concise- tion class DImpl as well. ness depends much on the syntax flexibility of the host This situation changes if the property PropB is a language and can range from a very good conciseness refinement of property PropA, as depicted in Figure 8. (e.g. FunnyQT) to rather verbose (e.g. NTL). Now, the implementation class DImpl must not use the implementation classes AImpl or CImpl, because they contain a direct implementation of PropA. However, it 6.2 Case Study: Generating Model Representation may use the implementation class BImpl. Code for NMeta Metamodels The selection of what base classes to select for an implementation class is a complex problem with some In this section, we present our second case study, the logic in it. Therefore, one would usually want to extract code generation for metamodels that support attribute it into a component and reuse in multiple specific code or reference refinements. generators that define the exact mapping of how an As an example meta-metamodel that supports re- attribute or reference is realized in code. finements, we have chosen NMeta. An excerpt of NMeta As an example, our implementation of this code gen- is depicted in Figure 6. NMeta is similar to Ecore, or, erator has to support multiple requirements: more generally, EMOF, in the sense that a metamodel consists of classes that have attributes and references, – for each property, it must also add a notification on and may have inheritance relations where multiple in- when this property changesi heritance is allowed. However, unlike Ecore metamod- – it must support bidirectional references els, references and attributes are allowed to refine other – each model element must contain absolute or rela- references and attributes. For example, the Type refer- tive URIs ence of a Reference is refined by its ReferenceType (see – classes have to contain annotations needed for seri- Figure 6). This has the consequence that the type sys- alization. tem can make sure that the type of a reference cannot While the details of the generated code are very specific be simple value types such as integers or strings. to the NMF framework, the general idea of transform- For each metaclass, the code generator creates an ing a metamodel including reference refinement may be interface as well as an implementation class. The inter- reused. face contains a property for each attribute or reference With external composition techniques, model trans- of the metaclass, and inherits from the interfaces cre- formations can only be used in their entirety. Thus, one ated for each of the metaclass’s base types. The imple- would first transform the metamodel to a code model mentation class may realize each of these attribute or with multiple inheritance. Then, a separate flattening reference properties either by inheriting it from a base transformation can be chained to it, which removes class or by defining a property as a member. However, if the multiple inheritance by introducing interfaces and a reference is refined in the scope of the given metaclass, merge implementations, as depicted in Figure 9. This the corresponding property should simply return the re- means that the transformation selects a base class and fining property, whereas non-refined references should then copies all of the members that are not inherited be implemented using a backing field (for attributes re- into the generated class. Ideally, the flattening transfor- spectively). This means that an implementation class mation can be reused. We think that this is the most must not inherit a property with an implementation promising approach if one wants to reuse large parts of using a backing field. For example, it must not inherit the logic, when modularity techniques such as superim- the implementation class where the refined reference position are not available. was originally defined. At the same time, it is desirable However, this approach is problematic. If we re- to inherit as many properties from other implementa- strict ourselves to external composition, we have to tion classes as possible, in order to keep the generated add information to the input model, such as annota- code small. tions of created interfaces, and adjust the flattening Furthermore, since the target platform does not sup- transformation appropriately. Furthermore, there may port multiple inheritance, the implementation class can be additional merging strategies required for commonly only choose exactly one base class to inherit implemen- used methods. This means that all systems that use tations for attributes or references. the flattening model transformation must be reconsid- For example, consider the situation in the left side ered. A possible solution would be to append a sec- of Figure 7. There, multiple inheritance is used with a ond application-specific transformation that performs a Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 19
<
<
Reference ReferenceType <
References 0..* DeclaringType 1 Opposite Refines 0..1 0..1
Class Identifier + IsAbstract : Boolean instance-of 0..1
InstanceOf BaseTypes 0..1 0..*
Figure 6 The meta-metamodel NMeta (simplified)
A AImpl Code generator Includes applica�on Fla�ening transforma�on + PropA + PropA specific content
B C BImpl CImpl + PropB + PropC + PropB + PropC
D DImpl + PropC Metamodel Code model incl. Code model mul�ple inheritance Figure 7 Example resolving multiple inheritance Figure 9 Resolving multiple inheritance using external compo- sition A AImpl + PropA + PropA
Includes application- Specific flattening transformation B C BImpl CImpl specific content + PropB + PropC + PropA’ + PropC <
D DImpl Generic flattening + PropC transformation
Figure 8 Example resolving multiple inheritance when property PropB refines PropB
Code model incl. Metamodel Code model multiple inheritance post-processing to the flattened composition, thus sur- Figure 10 Resolving multiple inheritance using superimposition rounding the reused flattening transformation by two transformations that implement the application-specific code generation. While this keeps the base class selec- However, this again yields further problems: The tion logic separated, it also means that pre- and post- superimposed flattening transformation and the main processing depend on each other and have to trace back code generator appear as isolated transformations, al- correspondences through two subsequent trace accesses. though they have dependencies to each other. This re- An apparently better solution is to combine the sults in similar implicit dependencies between multi- external composition approach with superimposition. ple transformation rules, which in turn yields a main- Here, the interface creation is superimposed by an ap- tenance problem. plication-specific rule that knows what the annotations The transformation rule interfaces introduced in Sec- that have to be applied, as depicted in Figure 10. tion 4.4 allow us to create extension points for poten- 20 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner
tially changing behavior. This does not require us to transformation, whereas the principal logic to resolve foresee the changes, as the appropriate methods can multiple inheritance is reused from the transformation just be marked virtual, giving the deriving class a high rule template. flexibility of how the changed behavior should be im- There is also an alternative strategy to create ex- plemented. tension points: One can create one abstract method per For example, the mapping of multiple inheritance to model reference that is accessed, possibly typed with a interfaces with implementation classes is implemented generic type parameter. This way, the approach is very in the transformation rule template ClassGenerator de- similar to the model concept transformation approach picted in Listing 15 (we have omitted parameter types from de Lara and Guerra [34]. for brevity).
1 public class ClassGenerator
Figure 12 A motor type in the OPC UA Address Space Model [35] conciseness is worse than for external languages. Ad- stance nodes. It can be considered as a loosely coupled ditionally, the case study shows test support and visu- type system. However, most type systems built into pro- alization support. The case study is mainly driven by gramming languages exactly define the layout of objects the Industrie 4.0 initiative. The goal of this initiative is in memory. In constrast, objects in OPC UA are repre- to improve production processes through the analysis sented in nodes with references, although these nodes of sensory inputs and combine them with control de- eventually have a memory representation. Instead of vices appropriately. To avoid dependencies to vendors, specifying the exact layout of these nodes, object types the communication must be based on standards, even in OPC UA only specify constraints to these nodes, though the data that each device may offer or consume such as that they must have certain references to other may have different formats for different device types. nodes. OPC UA is a standard to solve this problem and there- An example of such types is depicted in Figure 12. fore will most probably be one of the key technologies The ObjectType MotorType defines the structure of its for Industrie 4.0. Hence, tool support that allows for the instances. Although the only instance Motor1 in this integration of different information models from various example has exactly the same structure, its structure sub domains as well as different target platforms while could be slightly different. In contrast to fields of an at the same time lowering the hurdle for developers to object, which explicitly belong to this object, nodes in learn and maintain model transformations can have a OPC UA may be referenced by arbitrarily many refer- big impact on developer efficiency in this area. ences. These references are typed with ReferenceTypes. In the automation domain, it is of great impor- It is also possible to create custom reference types. tance to exchange data with the devices that analyze or Due to its flexibility, the Address Space Model of handle an industrial process. This may include reading OPC UA is useful for specifyng the data that can be temperature or pressure values, positioning valves, or obtained from a server. However, if developers want to starting motors. For this purpose, the Open Platform use this interface for their applications, the flexible ob- Communication (OPC) Foundation17 has released the ject layout is not desirable. Instead, developers usually OPC Unified Architecture standard (OPC UA)18. An want to fix the object layout by defining classes in an introduction can be found in [35]. One of the biggest object-oriented design with a fixed object layout. Code improvements to its predecessor Classic OPC, besides generators for this task already exist. However, there platform independence, is the introduction of what OPC are a couple of different SDKs for OPC UA and all UA calls the Address Space Model. these different SDKs have their own code generators This Address Space Model is a way to describe a that generate code in one language that is specific to system and its metadata. For this purpose, device data this particular SDK19. is represented in a fully meshed network of nodes with The code generator is currently agnostic of the used different types. The model is structured by object type SDK. In the intended scenario, it is extended by an- nodes that define the minimum structure for other in- other code generator that is specific to the used SDK.
17 https://www.opcfoundation.org/ 19 An overview of certified SDKs from different vendors is avail- 18 https://www.opcfoundation.org/UA/ able at https://opcfoundation.org/products 22 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner
This generator adds the SDK-specific functionality to graph can be clicked on, making the editor jump di- the original generator.. The code generator creates a rectly to the declaration of the transformation rule (or System.CodeDOM model, from which code is generated helper method, respectively). Thus, this tool support by the code providers for the intended language. This resembles the one presented by Rentschler [44] in large procedure is illustrated in Figure 13. parts, although no development effort was needed. Evaluating the test infrastructure, the model trans- formation has been tested by 155 unit tests, using the SDK-specific Code Generator widely adopted MSTest testing framework with a test code coverage of 100 % covered blocks. The full test <
– Our discussion explicitly excluded incrementality and In this paper, we discuss how an internal model bidirectionality, as these properties are not easy to transformation language can be constructed specifically obtain in an internal DSL, though it is possible [20]. for the inheritance of tool support, but DSLs have been As a consequence, their implementation is not as used in a number of approaches for a multitude of differ- clear as for non-incremental, uni-directional trans- ent rationales, including the ease of development [1, 6] formation languages. Few implementations are avail- , type safety [13], or language adoption [23]. able that implement these properties. Therefore, we In the remainder of this section, we first concentrate think that an analysis of design decisions would be on other approaches with internal model transforma- very speculative. tion DSLs (Section 8.1), and afterwards look at mod- – Tool support has many faces, and even though we ularity concepts for model transformation languages in have tried to find a systematic answer, basing our general. discussion on a user study of the Eclipse IDE, there may be many forms of tool support that we have missed. Furthermore, the study was conducted in 8.1 Internal DSLs 2006, and IDEs have improved a lot since then. Thus, many other tools might be used very fre- The idea of using internal DSLs [10] for model trans- quently that we have missed. We have tried to over- formation has already been applied several times, but come this limitation considering code visualization for different reasons. These reasons include a low im- techniques that were unavailable in 2006, but we do plementation effort [1], type safety [13] or extensibil- not have systematic data to make a reliable state- ity [6, 13, 19, 24, 25]. However, their implications on ment what other tool support might be missing. reusing tools or underlying component models have not – The validation of the Flowgraphs case is primar- been analyzed systematically. ily based on the responses from evaluation forms A language that has been used as host language for filled out by participants of the TTC 2013. While model transformation several times is Scala [13, 32, 60]. the number of responses was relatively high, the re- Scala has not as many users as Java or C] but still ad- sponses may be biased by the presentations of the vanced tool support is available. However, the language solutions. Further cause for bias is the familiarity adoption problem remains, i.e. fewer developers know with the technologies, as many participants did not Scala than Java or C]. Furthermore, these approaches take a closer look into the solution code, or knew C]. have different focus. Many approaches optimize the lan- However, as the NMF solution received the worst guage for conciseness whereas others such as NTL aim ratings in terms of solution presentation and tech- for comprehensiveness. The differences are discussed in nology familarity, we think that the bias is rather Section 4. to the disadvantage of NMF. Another language that provides a surprisingly flex- – The conclusions that we have drawn on modular- ible syntax, resulting in a concise syntax for internal ity in Section 6.2 suffer from the problem that the DSLs is Xtend20, for example used by EMF-IncQuery reusable transformation templates are only used in [52]. However, regarding tool support, Xtend is much the code generator of Section 6.2. Though the im- less used than Java or C] and thus fewer tool support plementation of resolving multiple inheritance is ex- can be inherited. tracted into its own component, we hav not proven Surprisingly, the most often used mainstream lan- that the templates for that functionality can really guages to the best of our knowledge have hardly been be reused in a different context. used as a host language for model transformation yet. Next to NTL and its close relative NMF Synchro- nizations [20], we are only aware of two approaches using Java. Paisley [59] is rather focused on pattern 8 Related Work matching and SDMLib [64] is an internal DSL for the Fujaba tool [40] using a method chaining syntax. So far, few model transformation languages exist that are implemented as an internal DSL. For each approach the authors have individually discussed the advantage 8.2 Modularity of Model Transformation Languages of their design choices. To the best of our knowledge, our approach is the first one that systematically ana- As pointed out by Belaunde [2], there are two princi- lyzes how to design an internal model transformation ple approaches to model transformation composition: DSL to optimize for reuse of component models and tools. 20 http://www.eclipse.org/xtend/ 24 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner
Internal and external composition. The difference be- sion conflicts are not automatically detected. This is tween these two is mainly the level of granularity in different for our approach where components of model which artifacts are reused. While in external compo- transformations are represented by assemblies that spec- sition, the entire model transformation as an artifact ify references enriched with both version information is reused, internal composition focuses on the reuse of and digital signatures in assemblies. This rather tech- its parts. We have discussed internal composition for nical information has to be specified separately from internal DSLs in Section 4.4 where we compared our the transformation specification and does not pollute approach with the superimposition from ATL [57], but the latter. Essentially, our work reuses the specification there are also other approaches using either internal of component dependencies from existing component composition for external languages or external compo- models as these dependency specifications are not spe- sition. cific to the domain of model transformation. These external composition include for example chain- A similar approach is the approach of model con- ing model transformations of multiple languages (see cept transformations by de Lara and Guerra [34] or e.g. [33, 62] for a survey). With our embedding, trig- the generic model transformation concept by Cuadrado gering a model transformation in the end boils down et al. [4]. There, the entire transformation is param- to a method call to which the loaded models have to eterized with the types and features it operates on, be passed. Therefore, chaining model transformations formulated as a concept. When applied to a particu- is exactly as easy as chaining method calls. However, lar context, the developer has to provide a mapping of this only holds within the limits of the technology, if these concepts to metamodel classes and features, very we were to chain a model transformation written in e.g. similar to our approach where types must be provided ATL, we would have to interoperate on a process level. for type parameters and abstract members of trans- Since many frameworks for external composition such formation rule templates must be overridden. There- as the one by Sanchez et al. [5] operate on this level fore, model concept transformation can also easily be anyhow, we do not see this as a drawback. achieved with our approach where one also introduces We are also not the first to base modularization sup- type parameters and abstract members at the transfor- port on existing component models. For external model mation class. The transformation language NTL is not transformation DSLs, experiences of reusing existing built for this scenario and therefore, the syntax would component models already exist. Xtend21 is reusing the be quite laborious. Hence, we see our approach as a whole technology stack of Java, including the organiza- generalization of model concept transformations. Our tion in Jar archives as the technical component model. approach is not restricted to abstract members, but However, unlike NTL, Xtend is a general-purpose lan- developers can also provide default implementations. guage with support for model-to-text transformations Moreover, abstract functions are not restricted to the through Xpand templates, though there are attempts selection of features but may include rather sophisti- to include model transformation concepts into Xtend cated logic which can then be exchanged by instantia- as well. Tailored model-to-model transformation lan- tions of the transformation rule template. This flexibil- guages implemented as external DSLs, like most com- ity of course comes at a price: It is much more concise to monly known QVT-O [41] or ATL [29], usually spec- specify how concepts map to metaclasses and features ify module reuse concepts. These concepts have been than it is to provide implementations for transforma- reviewed by Wimmer, Kusel et al. [33, 62, 63] with tion rule templates, a problem that is no longer specific the result that reuse was still rather a fiction, espe- to model transformations and easily solvable through a cially reuse across different metamodels such as we pro- different DSL. pose with transformation rule templates. Modulariza- tion concepts of general-purpose languages have been ported to QVT-O by Rentschler et al. [45], but cannot reuse a component infrastructure that provides support 8.3 Model Workflow Engines regarding more sophisticated component model tools such as detecting versioning conflicts or checking the There are several approaches that offer the composi- 22 integrity of model transformation components. tion of transformations in a workflow. This way of Rather, these languages are mainly organized in files re-using transformations is also called black-box compo- that do not specify version information. References to sition, since the internals of the transformations need other files are specified as import links. These links also not been known, and since it is not necessary that the do not specify a version information and possible ver- 22 The approaches described here have been compiled in the 21 http://www.eclipse.org/xtend/ related work section of [43] and have been adapted from there. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 25 transformations are modified to work with these ap- 9 Conclusion proaches. The Universal Transformation Infrastructure (Uni- Despite the improvements in terms of productivity, MDE TI) is a composition framework that has been inte- still lacks industry adoption, mainly due to missing tool grated into the AMMA Megamodel (AM3) as the project support. In this paper, we have proposed an approach Global Model Management for Composite Transforma- to solve this tool support problem by internal model tions (GMM4CT) [53]. The project uses the megamodel transformation languages. We have explored the de- registry of AM3. It shares many similarities with the sign alternatives of how model transformation rules can ModelBus approach [17]. be represented in object-oriented design. Furthermore, Wires* is a composition framework for the Atlas such a mapping also enables developers to reuse ex- Transformation Language (ATL) [46]. It offers a da- isting technology from component-based software engi- taflow-based, graphical description language for trans- neering. They can define the interface of transformation formations, and contains support for higher-order and rules and reuse model transformation components. generic transformations. The approach provides mech- There is no unique way of implementing transfor- anisms for a modular and compositional specification mation rules in an object-oriented language. The imple- and execution of model transformation chains. mentation choices are trade-off decisions. An implemen- tation of transformation rules as methods or method The TraCo approach [16] is a transformation com- calls leads to a more concise syntax with less syntactic position frmaework which offers safe composition of trans- boilerplate, but yields restrictions. Implementations as formations by contractual interfaces. The approach con- methods restrict the transformation language to a sin- tains a composition system for transformations and a gle operational phase: Transformation rules and method classification of consistency checks. calls make explicit tracing hard and cancel inherited 23 MWE is an orchestration language for model-re- visualizations based on metadata. Furthermore, impor- lated tasks. It is part of the Eclipse project Xtext. The tant modularization techniques, such as superimposi- components of a workflow are realized as Java beans, tion, are not applicable. The implementation as classes whose interfaces consist of untyped parameters and dy- that inherit from a common transformation rule class namically typed model slots. is an implementation alternative without these short- The GECO approach [30] can be used to combine comings at the price of a less concise language. code and model generators in aspect-oriented and multi- We have validated and evaluated our findings by view modeling approaches. GECO partitions generator implementing the latter approach into the transforma- fragments along the types of views and aspects of the tion language NTL, using C] as a host language. We application domain, modularizes the fragments along have discussed the implications of the design on qual- language features, and combines the outpout of these ity attributes of the transformation language at the fragements into a generator. Megamodel patterns are example of three case studies. In the first case study, used to guide the combination of fragments. we have evaluated the conciseness and understandabil- ity of NTL compared to classical model transformation languages. Here, the main result is that NTL is in- deed less concise than other transformation languages, as we had be expected, but in a combined assessment 8.4 Surveys of model transformation languages of understandability and conciseness, it is not much be- hind and was even able to score as good as the widely Of course, our work is not the first one to survey model used model transformation language ATL. In the sec- transformation languages, though for the best of our ond case study, code generation in the .NET Modeling knowledge, we are the first to report on implications of Framework, we have validated the impact of language internal model transformation language design to tool design to modularity and extensibility concepts. Here, support and modularity. A much more general survey the usage of transformation rule templates, supported of model transformation languages was provided for ex- through the reused component model of .NET, showed ample by Czarnecki and Helsen [7]. Other surveys have benefits. We have extracted the common functionality a different focus, such as bidirectional model transfor- of flattening a code model with multiple inheritance mation languages [18, 51] or reuse [33, 62, 63]. into a reusable component. The last case study from the automation domain shows the applicability of the
23 https://eclipse.org/Xtext/documentation/306_mwe2.html, language in an industrial scenario. Furthermore, it vali- retrieved 1 August 2016 dates testability and visualization support. In partic- 26 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner ular, we were able to achieve a full coverage of the 12. Gelhausen, T., Derre, B., Geiß, R.: Customizing model transformation through systematic unit tests. GrGen. net for Model Transformation. In: Proceed- We could automatically generate a visualization of the ings of the third international workshop on Graph model transformation through reusing out-of-the-box and model transformations, pp. 17–24. ACM (2008) tools for NTLs host language C]. 13. George, L., Wider, A., Scheidgen, M.: Type-safe model transformation languages as internal dsls in scala. In: Theory and Practice of Model Transfor- References mations, pp. 160–175. Springer (2012) 14. Gorp, P.V., Rose, L.: The petri-nets to statecharts 1. Barringer, H., Havelund, K.: TraceContract: A transformation case. In: Sixth Transformation Tool Scala DSL for trace analysis. Springer (2011) Contest (TTC 2013), EPTCS (2013) 2. Belaunde, M.: Transformation composition in qvt. 15. Heidenreich, F., Johannes, J., Seifert, M., Wende, In: Proc. of the First European Workshop on Com- C.: JaMoPP: The Java Model Parser and Printer. position of Model Transformations (CMT 2006), Technical Report TUD-FI09-10, Technische Uni- Bilbao, Spain, pp. 39–46 (2006) versität Dresden, Fakultät Informatik (2009). 3. Bruch, M., Monperrus, M., Mezini, M.: Learning from examples to improve code completion systems. ftp://ftp.inf.tu-dresden.de/pub/berichte/ In: Proceedings of the the 7th joint meeting of the tud09-10.pdf 16. Heidenreich, F., Kopcsek, J., Aßmann, U.: Safe European software engineering conference and the Composition of Transformations. Journal of Ob- ACM SIGSOFT symposium on The foundations of ject Technology 10, 1–20 (2011) software engineering, pp. 213–222. ACM (2009) 17. Hein, C., Ritter, T., Wagner, M.: Model-driven tool 4. Cuadrado, J.S., Guerra, E., De Lara, J.: Generic integration with modelbus. In: Workshop Future model transformations: write once, reuse every- Trends of Model-Driven Development (2009) where. In: International Conference on Theory 18. Hidaka, S., Tisi, M., Cabot, J., Hu, Z.: Feature- and Practice of Model Transformations, pp. 62–77. based classification of bidirectional transformation Springer (2011) approaches. Software & Systems Modeling pp. 1– 5. Cuadrado, J.S., Guerra, E., de Lara, J.: A com- 22 (2015). DOI 10.1007/s10270-014-0450-0. URL ponent model for model transformations. IEEE Transactions on Software Engineering 40(11), http://dx.doi.org/10.1007/s10270-014-0450-0 19. Hinkel, G.: An approach to maintainable model 1042–1060 (2014). DOI 10.1109/TSE.2014.2339852 transformations using internal DSLs. Master thesis, 6. Cuadrado, J.S., Molina, J.G., Tortosa, M.M.: Karlsruhe Institute of Technology (2013) Rubytl: A practical, extensible transformation lan- 20. Hinkel, G.: Change propagation in an internal guage. In: Model Driven Architecture–Foundations model transformation language. In: Theory and and Applications, pp. 158–172. Springer (2006) Practice of Model Transformations, pp. 3–17. 7. Czarnecki, K., Helsen, S.: Feature-based survey of Springer (2015) model transformation approaches. IBM Systems 21. Hinkel, G.: NMF: A Modeling Framework for Journal 45(3), 621–645 (2006) the .NET Platform. Tech. rep., Karlsruhe 8. Efftinge, S., Eysholdt, M., Köhnlein, J., Zarnekow, (2016). URL http://nbn-resolving.org/urn:nbn: S., von Massow, R., Hasselbring, W., Hanus, M.: Xbase: Implementing domain-specific languages for de:swb:90-537082 22. Hinkel, G., Goldschmidt, T., Happe, L.: Tool Sup- java. SIGPLAN Not. 48(3), 112–121 (2012). DOI port for Model Transformations: On Solutions us- 10.1145/2480361.2371419. URL http://doi.acm. ing Internal Languages. In: Modellierung 2016, org/10.1145/2480361.2371419 Karlsruhe, Germany, 2–4 March 2016 (2016) 9. Ehrig, H., Ehrig, K., De Lara, J., Taentzer, G., 23. Hinkel, G., Groenda, H., Vannucci, L., Denninger, Varró, D., Varró-Gyapay, S.: Termination criteria O., Cauli, N., Ulbrich, S.: A Domain-Specific Lan- for model transformation. In: International Confer- guage (DSL) for Integrating Neuronal Networks in ence on Fundamental Approaches to Software En- Robot Control. In: 2015 Joint MORSE/VAO Work- gineering, pp. 49–63. Springer (2005) shop on Model-Driven Robot Software Engineering 10. Fowler, M.: Domain-specific languages. Addison- and View-based Software-Engineering (2015) Wesley Professional (2010) 24. Hinkel, G., Happe, L.: Using component frame- 11. Geiß, R., Kroll, M.: Grgen. net: A fast, expressive, works for model transformations by an inter- and general purpose graph rewrite tool. In: Appli- nal DSL. In: Proceedings of the 1st Inter- cations of Graph Transformations with Industrial national Workshop on Model-Driven Engineering Relevance, pp. 568–569. Springer (2008) Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 27
for Component-Based Software Systems co-located 36. Meyerovich, L.A., Rabkin, A.S.: Empirical analysis with ACM/IEEE 17th International Conference of programming language adoption. In: Proceed- on Model Driven Engineering Languages & Sys- ings of the 2013 ACM SIGPLAN international con- tems (MoDELS 2014), CEUR Workshop Proceed- ference on Object oriented programming systems ings, vol. 1281, pp. 6–15. CEUR-WS.org (2014) languages & applications, pp. 1–18. ACM (2013) 25. Horn, T.: Model querying with funnyqt. In: Theory 37. Mohagheghi, P., Fernandez, M.A., Martell, J.A., and Practice of Model Transformations, pp. 56–57. Fritzsche, M., Gilani, W.: Mde adoption in indus- Springer (2013) try: challenges and success criteria. In: Models in 26. Horn, T.: The TTC 2013 flowgraphs case. In: Sixth Software Engineering, pp. 54–59. Springer (2009) Transformation Tool Contest (TTC 2013), EPTCS 38. Mohagheghi, P., Gilani, W., Stefanescu, A., Fer- (2013) nandez, M.A.: An empirical study of the state of 27. Horv, A., et al.: Dynamic backward slicing of model the practice and acceptance of model-driven engi- transformations. In: 2012 IEEE Fifth International neering in four industrial cases. Empirical Software Conference on Software Testing, Verification and Engineering 18(1), 89–116 (2013) Validation, pp. 1–10. IEEE (2012) 39. Murphy, G.C., Kersten, M., Findlater, L.: How are 28. Hülsbusch, M., König, B., Rensink, A., Semenyak, Java software developers using the Elipse IDE? M., Soltenborn, C., Wehrheim, H.: Showing full Software, IEEE 23(4), 76–83 (2006) semantics preservation in model transformation-a 40. Nickel, U., Niere, J., Zündorf, A.: The fujaba envi- comparison of techniques. In: International Confer- ronment. In: Proceedings of the 22nd international ence on Integrated Formal Methods, pp. 183–198. conference on Software engineering, pp. 742–745. Springer (2010) ACM (2000) 29. Jouault, F., Kurtev, I.: Transforming models with 41. Object Management Group: Meta Object Facil- atl. In: Satellite Events at the MoDELS 2005 Con- ity (MOF) 2.0 Query/View/ Transformation Spec- ference, pp. 128–138. Springer (2006) ification. http://www.omg.org/spec/QVT/1.1/PDF/ 30. Jung, R., Heinrich, R., Hasselbring, W.: GECO: (2011) A Generator Composition Approach for Aspect- 42. Olsen, G.K., Aagedal, J., Oldevik, J.: Aspects Oriented DSLs. In: P. Van Gorp, G. Engels (eds.) of Reusable Model Transformations. In: Proc. Theory and Practice of Model Transformations: of the First European Workshop on Composition 9th International Conference, ICMT 2016, Held as of Model Transformations (CMT 2006), Bilbao, Part of STAF 2016, Lecture Notes in Computer Spain, pp. 21–26 (2006) Science, vol. 9765, pp. 141–156. Springer Interna- 43. Rentschler, A.: Model Transformation Languages tional Publishing, Cham (2016). DOI 10.1007/ with Modular Information Hiding. Ph.D. thesis, 978-3-319-42064-6_10 Karlsruhe Institute of Technology, Karlsruhe, Ger- 31. Kolovos, D.S., Paige, R.F., Polack, F.A.: The ep- many (2015). DOI 10.5445/KSP/1000045910. URL silon transformation language. In: Theory and http://www.ksp.kit.edu/9783731503460 Practice of Model Transformations, pp. 46–60. 44. Rentschler, A., Noorshams, Q., Happe, L., Reuss- Springer (2008) ner, R.: Interactive visual analytics for efficient 32. Křikava, F., Collet, P., France, R.B.: Sigma: Scala maintenance of model transformations. In: Theory internal domain-specific languages for model ma- and Practice of Model Transformations, pp. 141– nipulations. In: Model-Driven Engineering Lan- 157. Springer (2013) guages and Systems, pp. 569–585. Springer (2014) 45. Rentschler, A., Werle, D., Noorshams, Q., Happe, 33. Kusel, A., Schönböck, J., Wimmer, M., Kappel, L., Reussner, R.: Designing information hiding G., Retschitzegger, W., Schwinger, W.: Reuse in modularity for model transformation languages. In: model-to-model transformation languages: are we Proceedings of the of the 13th international confer- there yet? Software & Systems Modeling pp. 1–36 ence on Modularity, pp. 217–228. ACM (2014) (2013) 46. Rivera, J.E., Ruiz-González, D., López-Romero, F., 34. de Lara, J., Guerra, E.: From types to type re- Bautista, J.M.: Wires* : A Tool for Orchestrating quirements: genericity for model-driven engineer- Model Transformations. In: A. Vallecillo, G. Sagar- ing. Software & Systems Modeling 12(3), 453–474 dui (eds.) XIV Jornadas de Ingeniería del Software (2013) y Bases de Datos (JISBD 2009), San Sebastián, 35. Mahnke, W., Leitner, S.H., Damm, M.: OPC uni- Spain, September 8-11, 2009, pp. 158–161 (2009) fied architecture. Springer (2009) 47. Robbes, R., Lanza, M.: How program history can improve code completion. In: Automated Software 28 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner
Engineering, 2008. ASE 2008. 23rd IEEE/ACM Engineering Languages and Systems, pp. 623–637. International Conference on, pp. 317–326. IEEE Springer (2011) (2008) 57. Wagelaar, D., Van Der Straeten, R., Deridder, 48. Schürr, A.: Specification of graph translators with D.: Module superimposition: a composition tech- triple graph grammars. In: Graph-Theoretic Con- nique for rule-based model transformation lan- cepts in Computer Science, pp. 151–163. Springer guages. Software & Systems Modeling 9(3), 285– (1994) 309 (2010) 49. Sendall, S., Kozaczynski, W.: Model transforma- 58. Whittle, J., Hutchinson, J., Rouncefield, M., tion: The heart and soul of model-driven software Burden, H., Heldal, R.: Industrial adoption of development. Software, IEEE 20(5), 42–45 (2003) model-driven engineering: Are the tools really 50. Staron, M.: Adopting model driven software devel- the problem? In: A. Moreira, B. Schätz, opment in industry–a case study at two companies. J. Gray, A. Vallecillo, P. Clarke (eds.) Model- In: Model Driven Engineering Languages and Sys- Driven Engineering Languages and Systems, Lec- tems, pp. 57–72. Springer (2006) ture Notes in Computer Science, vol. 8107, pp. 51. Stevens, P.: A landscape of bidirectional model 1–17. Springer Berlin Heidelberg (2013). DOI transformations. In: R. Lämmel, J. Visser, J.a. 10.1007/978-3-642-41533-3_1. URL http://dx. Saraiva (eds.) Generative and Transformational doi.org/10.1007/978-3-642-41533-3_1 Techniques in Software Engineering II, Lecture 59. Trancón y Widemann, B., Lepper, M.: Paisley: pat- Notes in Computer Science, vol. 5235, pp. 408– tern matching à la carte. In: Theory and Practice 424. Springer Berlin Heidelberg (2008). DOI of Model Transformations, pp. 240–247. Springer 10.1007/978-3-540-88643-3_10. URL http://dx. (2012) doi.org/10.1007/978-3-540-88643-3_10 60. Wider, A.: Implementing a bidirectional model 52. Ujhelyi, Z., Bergmann, G., Hegedüs, Á., Horváth, transformation language as an internal dsl in scala. Á., Izsó, B., Ráth, I., Szatmári, Z., Varró, D.: EMF- In: EDBT/ICDT Workshops, pp. 63–70 (2014) IncQuery: An integrated development environment 61. Wijs, A., Engelen, L.: Efficient property preserva- for live model queries. Science of Computer Pro- tion checking of model refinements. In: Interna- gramming 98, 80–99 (2015) tional Conference on Tools and Algorithms for the 53. Vanhooff, B.: Loosely Coupled Transformation Construction and Analysis of Systems, pp. 565–579. Chains. How to Enable Transformation Reuse Springer (2013) with Traceability Information. Ph.D. the- 62. Wimmer, M., Kappel, G., Kusel, A., Retschitzeg- sis, Informatics Section, Department of Com- ger, W., Schönböck, J., Schwinger, W.: Fact or puter Science, Faculty of Engineering Science fiction–reuse in rule-based model-to-model trans- (2010). URL https://lirias.kuleuven.be/handle/ formation languages. In: Theory and Practice 123456789/262244. Berbers, Yolande (supervisor) of Model Transformations, pp. 280–295. Springer 54. Varró, D., Pataricza, A.: Generic and meta- (2012) transformations for model transformation engineer- 63. Wimmer, M., Kappel, G., Kusel, A., Retschitzeg- ing. In: «UML» 2004—The Unified Modeling Lan- ger, W., Schönböck, J., Schwinger, W., Kolovos, guage. Modeling Languages and Applications, pp. D.S., Paige, R.F., Lauder, M., Schürr, A., et al.: 290–304. Springer (2004) Surveying rule inheritance in model-to-model 55. Wagelaar, D., Iovino, L., Di Ruscio, D., Pieranto- transformation languages. Journal of Object Tech- nio, A.: Translational semantics of a co-evolution nology 11(2), 3–1 (2012) specific language with the emf transformation vir- 64. Zündorf, A., George, T., Lindel, S., Norbisrath, tual machine. In: International Conference on The- U.: Story driven modeling libary (sdmlib): an in- ory and Practice of Model Transformations, pp. line dsl for modeling and model transformations, 192–207. Springer (2012) the petrinet-statechart case. Sixth Transformation 56. Wagelaar, D., Tisi, M., Cabot, J., Jouault, F.: To- Tool Contest (TTC 2013), ser. EPTCS (2013) wards a general composition semantics for rule- based model transformation. In: Model Driven