=Paper=
{{Paper
|id=Vol-1760/paper7
|storemode=property
|title=On Leveraging Executable Language Engineering for Domain-Specific Transformation Languages
|pdfUrl=https://ceur-ws.org/Vol-1760/paper7.pdf
|volume=Vol-1760
|authors=Erwan Bousse,Manuel Wimmer,Wieland Schwinger,Elisabeth Kapsammer
|dblpUrl=https://dblp.org/rec/conf/models/BousseWSK16
}}
==On Leveraging Executable Language Engineering for Domain-Specific Transformation Languages==
https://ceur-ws.org/Vol-1760/paper7.pdf
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