On Leveraging Executable Language Engineering for Domain-Specific Transformation Languages (Position Paper) Erwan Bousse Manuel Wimmer Wieland Schwinger Elisabeth Kapsammer TU Wien TU Wien JKU Linz JKU Linz Vienna, Austria Vienna, Austria Linz, Austria Linz, Austria bousse@big.tuwien.ac.at wimmer@big.tuwien.ac.at wieland.schwinger@cis.jku.at elisabeth@cis.jku.at Abstract—An increasing number of domain-specific transforma- work focused on the generation of dedicated execution trace tion languages (DSTLs) are used to define model transformations management facilities of an xDSML [4], and on the usage of in specific contexts. This shift led to many approaches to define such facilities for model omniscient debugging [2]. new DSTLs and associated tools, either through frameworks or complete generative approachs. In parallel, the fields of language In this context, we make the following observation: if we engineering and model execution have seen the development of consider a model transformation as a model [1], [12], we can many approaches to efficiently define new executable domain- consider a DSTL as a specific sort of xDSML. Therefore, all specific modeling languages (xDSMLs), and to provide tools research results in the field of xDSML engineering can be (e.g., editor, debugger) for any newly defined xDSML. In this applied to DSTLs, in order to improve or supplement exist- position paper, we propose to study how the engineering of DSTLs could benefit from state-of-the-art xDSML engineering ing DSTL engineering approaches. For instance, a language approaches. We first demonstrate why a DSTL is an xDSML workbench such as the GEMOC Studio [3] can be used to with specific characteristics. We then give a selection of research implement a DSTL and to automatically provide it with a directions to apply xDSML engineering approaches on DSTLs. debugger. Furthermore, such research results can presumably Index Terms—model transformation, domain-specific transfor- be adapted or extended for the specific case of DSTLs, given mation languages, language engineering, model execution a study of what characterizes DSTLs as specific xDSMLs. For instance, in the case of DSTLs, the parameters given to I. I NTRODUCTION the executed model (i.e., the model transformation) commonly Model transformations are at the core of all model driven always comprise an input model and input/output metamodels. engineering activities [15]. They are defined using model In this position paper, we propose to study how the engi- transformation languages, which provide concepts to express neering of DSTLs could benefit from state-of-the-art xDSML model modifications or code generation. Because model engineering approaches. In Section II, we present why a DSTL transformations are complex artifacts, an increasing number of is a specific sort of xDSML. In Section III, we present some domain-specific transformation languages (DSTLs) [12] are specific characteristics of DSTLs, and we identify a selection used to define them. A DSTL can be specific to a technical of research directions to apply xDSML engineering approaches concern of model transformation (e.g., Epsilon task-specific on DSTLs. Finally, we conclude in Section IV. DSTLs [11]), or to a specific context (e.g., mapping of abstract and concrete syntaxes [9]), or even to a specific set of input II. F ROM X DSML TO DSTL ENGINEERING and output metamodels (especially in generative approaches, In this section, we first briefly explain what is an xDSML, e.g., [10]). The growing usage of DSTLs led to many methods we then demonstrate how a DSTL is as a specific sort of to efficiently define new DSTLs and associated tools, such as xDSML, and finally we present a category of DSTLs that are frameworks [5], [16] or generative approaches [7], [10]. A good defined with fixed input and output metamodels. illustration of this trend is the Tool Transformation Contest 2016 (TTC’16), which confronted transformation tools on the A. Executable Domain-Specific Modeling Language (xDSML) implementation of an engine for a dataflow-based DSTL1 . An xDSML is a domain-specific modeling language sup- In parallel, the fields of language engineering and model ported by execution semantics [6]. There are two main ap- execution have seen the development of many approaches to proaches to define execution semantics: translational (i.e., com- efficiently define new executable domain-specific modeling lan- pilation or code generation) and operational (i.e., interpretation). guages (xDSMLs) [3], [6], [13], which are DSMLs supported In this paper we focus on operational semantics, only. by execution semantics. Such approaches can automatically Figure 1 shows an xDSML and its usage to execute a model. provide static (e.g., editor) or dynamic (e.g., debugger) tools The central part of an xDSML is the abstract syntax, also called for any newly defined xDSML. For example, our recent the domain model. It is completed by the parameter metamodel that defines the possible parameters for an execution. The 1 https://github.com/bluezio/ttc2016-live executable model and the parameter model conform to these 41 xDSML DSTL specific to M1 and M2 Execution state metamodel Parameter Execution State Input Transformation Engine state Output Model metamodel transformation metamodel transformation metamodel M1 engine metamodel metamodel M2 Model Abstract Abstract syntax syntax data flow State and output depends on / uses Input Model Engine Output Parameter Executable Execution conforms to model transformation state model model model state Figure 1. Representation of an xDSML and its usage. Figure 3. Representation of a DSTL with fixed input and output metamodels M1 and M2, and its usage for a model-to-model transformation. DSTL Metamodeling language Transformation Engine state engine so that any input model may be taken as a parameter, metamodel Types and for the state metamodel, so that the output model can Abstract Output be constructed. The executable model not only consists of Instances syntax and state Engine the model transformation, but also of its input and output State metamodels. The execution transformation is commonly called Input Output model Model transformation model a transformation engine, which is responsible for applying the rules of the executed model transformation. More precisely, Transformation and Input metamodel metamodels Output metamodel such engine is a transformation that generically reads both the input transformation and the input model (e.g., using eGet in EMF) and produces the output model (e.g., using eSet Figure 2. Representation of a DSTL as an xDSML, and its usage for a model-to-model transformation. Some arrows are not shown for readability and factories in EMF). The engine is arbitrarily complex and (e.g., the input and output metamodels conform to Types). completely dependent on the paradigms and features provided by the implemented DSTL (e.g., pattern matching). Finally, at runtime, the execution state comprises both the engine state metamodels. Next, the operational semantics of the xDSML (e.g., current rule being executed), and the output model being comprise two parts. First, the state metamodel defines what is produced. Note that if the input and output models are distinct, the dynamic execution state of an executable model. Second, we have an out-place model transformation, and if they are the the execution transformation is a model transformation (often same single model, we have an in-place model transformation. in-place) that defines how the state changes during execution. The latter case is possible since the input and output models conform to the same Instances metamodel. B. Domain-Specific Transformation Language (DSTL) A DSTL is domain-specific language that can be used C. DSTL with fixed input and output metamodels to express model transformations. If we consider a model While a DSTL can commonly consider any input and output transformation as a model [1], [12], we can consider a DSTL metamodels, it is also possible to define a DSTL for fixed as a specific sort of xDSML, and a model transformation as an input and output metamodels. This is especially the case executable model. In the following, we present the common for generative approaches that produce the DSTL specific to case of DSTLs that can process models conforming to any a given DSML [10], in order to facilitate the definition of given input/output metamodels (e.g., Epsilon DSTLs [11]). transformations for this DSML. While such choice implies Figure 2 shows a refinement of Figure 1 to represent a a loss of genericity, it makes possible to provide syntactic DSTL in the case of model-to-model transformations. While constructs very similar to the input and output metamodels it was implicit in Figure 1, we explicitly must show here the (e.g., by deriving a pattern language from the input metamodel), considered metamodeling language (e.g., EMF Ecore) that is and ease the definition of the engine, among other advantages. required by a DSTL to generically handle any input or output Figure 3 shows a refinement of Figure 1 when considering metamodels and models. It is shown at the top left, and is a DSTL that is specific to an input metamodel M1 and to an composed of two parts: Types (e.g., EClass, EReference) output metamodel M2. In this scenario, the DSTL does not and Instances2 (e.g., EObject). The Types part is used by have to explicitly rely on a metamodeling language, since M1 the abstract syntax, since a model transformation references is directly used as a parameter metamodel and M2 is part of the classes of the considered input and output metamodels. The execution state metamodel. Consequently, the only parameter Instances part is used both as the parameter metamodel, given to the engine is an input model conforming to M1. 2 Relationships are presented from the perspective of the DSTL, meaning III. O BSERVATIONS AND RESEARCH DIRECTIONS that the input/output models are considered as generic models conforming to While being xDSMLs, DSTLs have a number of specific the Instances metamodel, i.e., we present the linguistic relationships. Yet, if we consider ontological relationships, the input/output models do conform to characteristics. For example, when a DSTL supports any input the input/output metamodels, which is only shown here as dependency links. or output metamodels (see Section II-B), the executed model 42 is heterogeneous and complex since it is composed of both As a starting point for exploring these directions, we have input/output metamodels in addition to the transformation. In implemented an open-source toy DSTL called MiniTL3 using other words, the abstract syntax of such DSTL has to import the GEMOC Studio language workbench. all the complexity of a complete metamodeling language. In IV. C ONCLUSION addition, the parameter metamodel is a subset of the same metamodeling language, meaning that the parameter can be We showed that DSTLs are a specific sort of xDSMLs, any kind of arbitrarily complex model. The execution state is and we proposed research directions to study how xDSML likewise rather complex, since it includes the complete output engineering can be leveraged to improve or supplement DSTL model under construction. Lastly, the transformation engine of engineering. We plan to explore these directions as part of the a DSTL can also be elaborated to manage diverse concerns TETRA Box research project to improve the testing of model (e.g., pattern matching, order of execution of rules) [8], [16]. transformations, and to study whether DSTLs are the “killer” While there is already a wide range of efficient approaches case studies for xDSMLs workbenches. to engineer DSTLs [7], [10], the aforementioned complexity ACKNOWLEDGMENT is a strong motivation to further improve these approaches. This work has been funded by the Austrian Science Fund Research in language engineering and model execution include (FWF): P 28519-N31, by the Christian Doppler Forschungsge- many approaches to tackle the complexity of engineering an sellschaft CDL-Flex and the BMWFW (Austria). xDSML. To potentially benefit from such results in the context of DSTLs, we propose a selection of research directions: R EFERENCES a) xDSML design pattern: Understanding a DSTL, es- [1] J. Bézivin, F. Büttner, M. Gogolla, F. Jouault, I. Kurtev, and A. Lindow. Model Transformations? Transformation Models! In Int. Conference on pecially its transformation engine [14], helps verifying that Model Driven Engineering Languages and Systems (MODELS), 2006. both a DSTL and conforming transformations are correct. The [2] E. Bousse, J. Corley, B. Combemale, J. Gray, and B. Baudry. Supporting xDSML design pattern [6] was proposed to capitalize good Efficient and Advanced Omniscient Debugging for xDSMLs. In Int. Conference on Software Language Engineering (SLE), 2015. engineering practices for xDSMLs with a strong focus on the [3] E. Bousse, T. Degueule, D. Vojtisek, T. Mayerhofer, J. Deantoni, and separation of concerns, which helps understandability. Such B. Combemale. Execution Framework of the GEMOC Studio (Tool design pattern could be used or adapted for engineering DSTLs. Demo). In Software Language Engineering (SLE), 2016. [4] E. Bousse, T. Mayerhofer, B. Combemale, and B. Baudry. A Generative Furthermore, defining xDSMLs in a systematic manner gives Approach to Define Rich Domain-Specific Trace Metamodels. In Euro- the possibility to analyze them with automatic procedures. pean Conference on Modeling Foundations and Applications (ECMFA), 2015. b) xDSML generic and generative approaches: Generic [5] M. Bravenboer, K. T. Kalleberg, R. Vermaas, and E. Visser. Stratego/XT and generative approaches have been proposed to support any 0.17. A language and toolset for program transformation. Science of xDSML defined in a systematic manner (see previous point). Computer Programming, 72:52–70, 2008. For instance, we proposed an approach to generate the domain- [6] B. Combemale, X. Crégut, and M. Pantel. A Design Pattern to Build Executable DSMLs and associated V&V tools. Asia-Pacific Software specific trace metamodel of an xDSML [4], and a generic Engineering Conference (APSEC), 2012. omniscient debugging approach for model execution [2]. Such [7] J. S. Cuadrado, E. Guerra, and J. De Lara. Towards the Systematic Construction of Domain-Specific Transformation Languages. In European approaches could be applied or adapted for DSTLs. Conference on Modelling Foundations and Applications (ECFMA), 2014. c) Extend xDSML workbenches for DSTLs: Some existing [8] K. Czarnecki and S. Helsen. Feature-based survey of model transforma- work aim at capitalizing knowledge and practices for the tion approaches. IBM Systems Journal, 45(3), 2006. [9] A. S.-B. Herrera, E. D. Willink, and R. F. Paige. A Domain Specific engineering of transformation languages. For instance, the Transformation Language to Bridge Concrete and Abstract Syntax. In T-Core framework [16] provides a wide range of primitives to Int. Conference on Model Transformation (ICMT), 2016. greatly facilitate the definition of transformation engines. Such [10] K. Hölldobler, B. Rumpe, and I. Weisemöller. Systematically deriving domain-specific transformation languages. In Model Driven Engineering frameworks or libraries could be used in xDSML language Languages and Systems (MODELS), 2015. workbenches to help defining operational semantics of DSTLs. [11] D. S. Kolovos, R. F. Paige, and F. A. C. Polack. The Epsilon Transformation Language. In Int. Conference on Model Transformation d) Use DSTLs as case studies for model execution: Due (ICMT), 2008. to their peculiarities, DSTLs represent interesting cases of [12] T. Kühne, G. Mezei, E. Syriani, H. Vangheluwe, and M. Wimmer. Explicit xDSMLs. Following the trend of the TTC’16, DSTLs could Transformation Modeling. In Int. Workshop on Multi-Paradigm Modeling (MPM), 2010. be used as case studies for model execution approaches. [13] T. Mayerhofer, P. Langer, M. Wimmer, and G. Kappel. xMOF: Executable e) Efficiency of transformation engines: Because the DSMLs based on fUML. In Int. Conference on Software Language semantics of DSTLs tend to be complex, implementing Engineering (SLE), 2013. [14] J. T. Saxon, B. Bordbar, and D. H. Akehurst. Opening the Black- efficient transformation engines is a difficult task. For example, Box of Model Transformation. In European Conference on Modeling providing a query mechanism requires efficient ways to explore Foundations and Applications (ECMFA), 2015. the input model, and to store or cache intermediate results. [15] S. Sendall and W. Kozaczynski. Model Transformation: The Heart and Soul of Model-Driven Software Development. IEEE Software, 20(5), While there are already common ways to improve efficiency, 2003. such as using traceability maps in operational semantics or [16] E. Syriani, H. Vangheluwe, and B. LaShomb. T-Core: a framework choosing an efficient target language in translational semantics, for custom-built model transformation engines. Software and Systems Modeling (SoSyM), 14(3), 2013. specific techniques could be developed or studied. 3 https://github.com/tetrabox/minitl 43