-An increasing number of domain-specific transformation languages (DSTLs) are used to define model transformations in specific contexts. This shift led to many approaches to define new DSTLs and associated tools, either through frameworks or complete generative approachs. In parallel, the fields of language engineering and model execution have seen the development of many approaches to efficiently define new executable domainspecific modeling languages (xDSMLs), and to provide tools (e.g., editor, debugger) for any newly defined xDSML. In this position paper, we propose to study how the engineering of DSTLs could benefit from state-of-the-art xDSML engineering approaches. We first demonstrate why a DSTL is an xDSML with specific characteristics. We then give a selection of research directions to apply xDSML engineering approaches on DSTLs. Index Terms-model transformation, domain-specific transformation languages, language engineering, model execution
Model transformations are at the core of all model driven engineering activities [15]. They are defined using model transformation languages, which provide concepts to express model modifications or code generation. Because model transformations are complex artifacts, an increasing number of domain-specific transformation languages (DSTLs) [12] are used to define them. A DSTL can be specific to a technical concern of model transformation (e.g., Epsilon task-specific DSTLs [11]), or to a specific context (e.g., mapping of abstract and concrete syntaxes [9]), or even to a specific set of input and output metamodels (especially in generative approaches, e.g., [10]). The growing usage of DSTLs led to many methods to efficiently define new DSTLs and associated tools, such as frameworks [5], [16] or generative approaches [7], [10]. A good illustration of this trend is the Tool Transformation Contest 2016 (TTC’16), which confronted transformation tools on the implementation of an engine for a dataflow-based DSTL1.
In parallel, the fields of language engineering and model execution have seen the development of many approaches to efficiently define new executable domain-specific modeling languages (xDSMLs) [3], [6], [13], which are DSMLs supported by execution semantics. Such approaches can automatically provide static (e.g., editor) or dynamic (e.g., debugger) tools for any newly defined xDSML. For example, our recent
work focused on the generation of dedicated execution trace management facilities of an xDSML [4], and on the usage of such facilities for model omniscient debugging [2].
In this context, we make the following observation: if we consider a model transformation as a model [1], [12], we can consider a DSTL as a specific sort of xDSML. Therefore, all research results in the field of xDSML engineering can be applied to DSTLs, in order to improve or supplement existing DSTL engineering approaches. For instance, a language workbench such as the GEMOC Studio [3] can be used to implement a DSTL and to automatically provide it with a debugger. Furthermore, such research results can presumably be adapted or extended for the specific case of DSTLs, given a study of what characterizes DSTLs as specific xDSMLs. For instance, in the case of DSTLs, the parameters given to the executed model (i.e., the model transformation) commonly always comprise an input model and input/output metamodels.
In this position paper, we propose to study how the engineering of DSTLs could benefit from state-of-the-art xDSML engineering approaches. In Section II, we present why a DSTL is a specific sort of xDSML. In Section III, we present some specific characteristics of DSTLs, and we identify a selection of research directions to apply xDSML engineering approaches on DSTLs. Finally, we conclude in Section IV.
In this section, we first briefly explain what is an xDSML, we then demonstrate how a DSTL is as a specific sort of xDSML, and finally we present a category of DSTLs that are defined with fixed input and output metamodels.
A. Executable Domain-Specific Modeling Language (xDSML)
An xDSML is a domain-specific modeling language supported by execution semantics [6]. There are two main approaches to define execution semantics: translational (i.e., compilation or code generation) and operational (i.e., interpretation). In this paper we focus on operational semantics, only.
Figure 1 shows an xDSML and its usage to execute a model. The central part of an xDSML is the abstract syntax, also called the domain model. It is completed by the parameter metamodel that defines the possible parameters for an execution. The executable model and the parameter model conform to these Parameter metamodel Input model
Input metamodel
Model transformation Transformation and metamodels
Engine state metamodel Output and state Engine
State Output model
Output metamodel metamodels. Next, the operational semantics of the xDSML comprise two parts. First, the state metamodel defines what is the dynamic execution state of an executable model. Second, the execution transformation is a model transformation (often in-place) that defines how the state changes during execution. B. Domain-Specific Transformation Language (DSTL)
A DSTL is domain-specific language that can be used to express model transformations. If we consider a model transformation as a model [1], [12], we can consider a DSTL as a specific sort of xDSML, and a model transformation as an executable model. In the following, we present the common case of DSTLs that can process models conforming to any given input/output metamodels (e.g., Epsilon DSTLs [11]).
Figure 2 shows a refinement of Figure 1 to represent a DSTL in the case of model-to-model transformations. While it was implicit in Figure 1, we explicitly must show here the considered metamodeling language (e.g., EMF Ecore) that is required by a DSTL to generically handle any input or output metamodels and models. It is shown at the top left, and is composed of two parts: Types (e.g., EClass, EReference) and Instances2 (e.g., EObject). The Types part is used by the abstract syntax, since a model transformation references classes of the considered input and output metamodels. The Instances part is used both as the parameter metamodel, 2Relationships are presented from the perspective of the DSTL, meaning that the input/output models are considered as generic models conforming to the Instances metamodel, i.e., we present the linguistic relationships. Yet, if we consider ontological relationships, the input/output models do conform to the input/output metamodels, which is only shown here as dependency links.
DSTL specific to M1 and M2
Input metamodel M1
Input model
Transformation engine
Model transformation
State and output Engine Output state model so that any input model may be taken as a parameter, and for the state metamodel, so that the output model can be constructed. The executable model not only consists of the model transformation, but also of its input and output metamodels. The execution transformation is commonly called a transformation engine, which is responsible for applying the rules of the executed model transformation. More precisely, 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 and factories in EMF). The engine is arbitrarily complex and 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 (e.g., current rule being executed), and the output model being produced. Note that if the input and output models are distinct, we have an out-place model transformation, and if they are the same single model, we have an in-place model transformation. The latter case is possible since the input and output models conform to the same Instances metamodel.
C. DSTL with fixed input and output metamodels
While a DSTL can commonly consider any input and output metamodels, it is also possible to define a DSTL for fixed input and output metamodels. This is especially the case for generative approaches that produce the DSTL specific to a given DSML [10], in order to facilitate the definition of transformations for this DSML. While such choice implies a loss of genericity, it makes possible to provide syntactic constructs very similar to the input and output metamodels (e.g., by deriving a pattern language from the input metamodel), and ease the definition of the engine, among other advantages.
Figure 3 shows a refinement of Figure 1 when considering a DSTL that is specific to an input metamodel M1 and to an output metamodel M2. In this scenario, the DSTL does not have to explicitly rely on a metamodeling language, since M1 is directly used as a parameter metamodel and M2 is part of the execution state metamodel. Consequently, the only parameter given to the engine is an input model conforming to M1.
III. OBSERVATIONS AND RESEARCH DIRECTIONS While being xDSMLs, DSTLs have a number of specific characteristics. For example, when a DSTL supports any input or output metamodels (see Section II-B), the executed model