Higher-order Rewriting of Model-to-Text Templates

for Integrating Domain-speciﬁc Modeling Languages

Bernhard Hoisl

1,2

, Stefan Sobernig

, and Mark Strembeck

1,2

Institute for Information Systems and New Media, WU Vienna, Vienna, Austria

Secure Business Austria Research (SBA Research), Vienna, Austria

Keywords:

Domain-speciﬁc Modeling Language, M2T, Code Generation, Higher-order Transformation, Eclipse Model-

ing Framework, Epsilon.

Abstract:

Domain-speciﬁc modeling languages (DSMLs) are commonly used in model-driven development projects. In

this context, model-to-text (M2T) transformation templates generate source code from DSML models. When

integrating two (or more) DSMLs, the reuse of such templates for the composed DSML would yield a number

of beneﬁts, such as, a reduced testing and maintenance effort. However, in order to reuse the original templates

for an integrated DSML, potential syntactical mismatches between the templates and the integrated metamodel

must be solved. This paper proposes a technology-independent approach to template rewriting based on

higher-order model transformations to address such mismatches in an automated manner. By considering

M2T generator templates as ﬁrst-class models and by reusing transformation traces, our approach enables

syntactical template rewriting. To demonstrate the feasibility of this rewriting technique, we built a prototype

for Eclipse EMF and Epsilon.

1 INTRODUCTION

A domain-speciﬁc modeling language (DSML) pro-

vides modeling abstractions and notations to describe

the concepts and activities in a business domain (e.g.,

health care or banking) or a technical domain (e.g.,

access control or workﬂow speciﬁcation). DSMLs

commonly focus on narrow domain fragments and

system concerns only, such as schedule management

for power suppliers or security properties of business

process data (Spinellis, 2001).

The beneﬁts of DSMLs include reduced develop-

ment times for DSML-based software products, an

improved time-to-market, as well as reductions in de-

velopment and delivery costs; e.g., for developer or

customer trainings (Bettin, 2002). However, the de-

velopment of a DSML and correspondingtool support

most often requires substantial efforts that add to the

overall costs of the underlying software development

project (White et al., 2009; Krueger, 1992). Thus,

beneﬁts of a domain-speciﬁc development approach

only realize over time.

As a result, the costs of DSML development are

strong drivers for reusing DSMLs as design artifacts,

both during the life cycle of a single software prod-

uct and for multiple software products (White et al.,

2009; Krueger, 1992). For a single software product,

the development of a tailored DSML can be justiﬁed if

the underlying software product is subject to frequent

modiﬁcations or if the respective project demands for

multiple and rapidly available prototypes. While a

DSML would generate signiﬁcantly more beneﬁts if

it was used in the development of different software

products, this reuse is often barred by the narrow do-

mains covered by DSMLs. In this situation, one op-

tion is to start from a joint metamodel and to reﬁne

this metamodel, the corresponding structural and be-

havioral semantics, as well as the DSML notation to

cover an extended domain.

To develop a software product using two or more

pre-existing DSMLs, with each DSML deﬁning a

subsystem of the product, integrating the correspond-

ing DSMLs into a new consolidated DSML is an im-

portant design option (Vallecillo, 2010). Consider,

for example, modeling the billing domain in a power

supply company which covers company-speciﬁc ac-

counting and branch-speciﬁc schedule management.

Provided that compatible DSMLs for both tasks (i.e.,

accounting and schedule management) are available

(e.g., based on the same metamodeling infrastruc-

ture), their integration is a viable strategy; e.g., via

product line techniques (White et al., 2009). Simi-

Hoisl B., Sobernig S. and Strembeck M..

Higher-order Rewriting of Model-to-Text Templates for Integrating Domain-speciﬁc Modeling Languages.

DOI: 10.5220/0004321100490061

In Proceedings of the 1st International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2013), pages 49-61

ISBN: 978-989-8565-42-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

larly, in security-critical domains integrating security-

related DSMLs can support the systematic composi-

tion of different security concerns (Hoisl et al., 2012).

In addition to reusing the domain-speciﬁc lan-

guage models through metamodel composition

(Kalnina et al., 2010; Object Management Group,

2008), the model-to-text (M2T) transformations

available for the source DSMLs could be applied to

models of the new DSML. This way, generator ar-

tifacts (such as platform code, conﬁguration speciﬁ-

cations, and deployment descriptors) could be reused

for the new DSML.

From a DSML integration perspective, however,

there are major barriers to reusing model transforma-

tions (Wimmer et al., 2012). One barrier for M2T

generator templates, in particular, is the conformance

relation between M2T transformations and a given

metamodel. Consider the template sketch in Figure

1. The transformation template which accompanies

class

contains a variable assignment expression,

with the right-hand side calling on

propertyB

of an

instance of

(assuming that

stores an instance of

). This way, the template is conﬁned to a metamodel

containing a corresponding class

Class A

-propertyA

Class C

-propertyA

-propertyB

(a)

«transform»

(c)

Class B

-propertyB

(b)

Class A

-propertyA

Class C

-propertyC

«transform»

Class B

-propertyB

Class A

-propertyA

Class B

-propertyB

Class C'

-propertyA

-propertyB

Class C''

-propertyB

var x = y.propertyB;

Figure 1: Syntactical metamodel conformance.

This conformance relation is affected by the meta-

model composition applied for DSML integration. In

the model composition scenarios (

) and (

) in Fig-

ure 1, class

is composed into new classes, using

different composition operations. In scenario (

) the

conformance relation is preserved by the composition

operation; e.g., a full-property-preserving composi-

tion (Herrmann et al., 2007). Hence, the template still

applies and can be reused over instances of class

. In

scenario (

), however, the naming difference between

propertyB

and

propertyC

, while structurally equiv-

alent, breaks the conformance relation. The template

cannot be applied to instances of class

. Refactoring

a template clone would be required, for example.

Existing reuse techniques for M2T generator tem-

plates fall short on addressing such syntactical mis-

matches. For example, language-level reuse tech-

niques for M2T transformation languages only pro-

vide reuse capabilities at the block level (e.g. for

entire template or function blocks) rather than at

the expression level. Furthermore, most M2T trans-

formation languages lack the ability to use generic

transformations to abstract from different, but struc-

turally compatible metamodels. Generic transfor-

mation techniques, as available for some model-

to-model (M2M) transformation languages, require

an upfront deﬁnition in terms of parametric tem-

plates and explicit bindings (Cuadrado et al., 2011).

However, the demand for such an upfront deﬁnition

also adds to the development overhead of a DSML.

Adapter models mimic the metamodels of the source

DSMLs. This, however, impedes the deﬁnition of ad-

ditional M2T transformations that are speciﬁc to the

integrated DSML. Yet, additional transformations are

required to glue the different artifacts that are gener-

ated for the integrated DSML.

In this paper, we suggest an approach to over-

come the above limitations of M2T transformation

templates for DSML integration. Our transformation

rewriting technique allows for the automated modi-

ﬁcation of transformation templates to ﬁx important

syntactical mismatches between templates and the

composed DSML (Wimmer et al., 2010). In scenario

(

) from Figure 1, for example, the naming difference

would be tackled by rewriting the template expression

based on tracing data of the class composition, using

the new property name

propertyC

Our current prototype supports three higher-order

rewriting operations (retyping, association retarget-

ing, and property renaming). Note, however, that

our approach allows for arbitrary rewriting opera-

tions. Semantic heterogeneity in metamodel-model

relations (Wimmer et al., 2010) and types of syntac-

tical heterogeneity between source and target meta-

models which cannot be resolved in an automated

manner are currently not addressed by our approach.

This is, for instance, the case for m:n source/tar-

get cardinality in scenario (

) in Figure 1. Our

rewriting technique is applicable to M2T transfor-

mation languages which support a subset of the

meta object facility (MOF) M2T transformation lan-

guage (OMG MOFM2T), higher-order transforma-

tions (HOTs), and basic model transformation trac-

ing (Object Management Group, 2008; Tisi et al.,

2009). All implementation artifacts are available from

http://nm.wu.ac.at/modsec.

In Section 2, we give an overview on DSML in-

tegration, M2T transformations, and generator tem-

plates. Subsequently, we introduce our generic tem-

plate rewriting approach in Section 3. In Section 4,

we describe how our approach is then mapped to the

EMF and Epsilon infrastructures. A proof-of-concept

implementation for the Epsilon Generation Language

(EGL) is introduced. Section 5 gives an example of

how our prototype environment can be applied. We

discuss limitations as well as the pros and cons of our

approach when compared to alternative techniques in

Section 6. Section 7 provides an overview of related

work and Section 8 concludes the paper.

2 TRANSFORMATIONS AND

TRACES FOR DSML

INTEGRATION

In general, the process of integrating two or more

source DSMLs involves four major activities which

may be repeated a number of times to derive an

integrated target DSML (Hoisl et al., 2012). The

language model composition activity uses the lan-

guage models (e.g., the MOF or Ecore metamod-

els including corresponding metamodel-level con-

straints) of the source DSMLs as input for the def-

inition of a target metamodel. An important out-

put of this activity is a composition speciﬁcation that

includes, for instance, correspondence rules and/or

M2M transformations. In the behavior composi-

tion activity the behavioral semantics attached to the

source metamodels are composed to match the tar-

get metamodel. Depending on the behavior deﬁ-

nition corresponding composition operations are ap-

plied (such as M2M transformations or code-to-code

transformations). The concrete syntax composition

activity integrates the concrete syntaxes (e.g., textual,

tree-based, tabular, or diagrammatic) of the source

DSMLs. Finally, the platform integration composi-

tion activity integrates the software platforms of the

source DSMLs. In particular, this activity integrates

artifacts such as M2M and M2T transformations or

model interpreters of the source DSMLs. The output

of this activity is a set of platform integration spec-

iﬁcations which conform to the target metamodel.

Sometimes this composition step requires the gener-

ation of glue artifacts to realize a system-level com-

position; e.g., via pipelining, language extension, or

front-end integration (Spinellis, 2001).

The artifacts deﬁned in the language model com-

position activity serve as the input for platform in-

tegration. In the remainder of this paper, we focus

on M2T generator templates, M2M transformations,

and transformation traces. Below, we discuss each of

these artifact types in more detail.

M2T Generator Templates as Models. Platform

integration as described above (Hoisl et al., 2012)

includes the generation of platform-speciﬁc artifacts

(such as, platform-speciﬁc source code or platform

conﬁguration and deployment documents; see Figure

2). The generation of these artifacts can be supported

via M2T generators which receive a transformation

deﬁnition and a set of source models as the input to

produce a transformed representation of these mod-

els. For the remainder of this paper, we especially fo-

cus on template-based M2T generators and the corre-

sponding generator templates (Czarnecki and Helsen,

2006). In principle, a generator template consists of

two kinds of code. On the one hand, there is tem-

plate code to access and to select source model data

by quantifying over the model structure that is speci-

ﬁed in a metamodel (see also Figure 2). On the other

hand, a template contains code to expand and to wrap

the selected model data into string fragments.

...

Metamodel

(M2, language model)

Meta-metamodel

(M3)

instance-of

deﬁne

platform integration

refers to

M2T metamodel

(M2, template model)

instance-of

M2T model instance

(M1, template)

Model

(M1, speciﬁcation)

Platform artifacts

(code, conﬁg, ...)

deﬁne

DSML

engineer

Domain

modeler

deﬁne

DSML

engineer

applies to

generates

Figure 2: M2T template models.

Template-based M2T transformations are a

widely supported platform integration technique in

contemporary MDD tool chains, and a variety of

template language implementations exist, such as,

Eclipse Xpand, Xtend2, EGL, JET, or Acceleo (Rose

et al., 2012; Czarnecki and Helsen, 2006). For each

of these languages, M2T generators and generator

templates can be implemented in different ways. For

example, one option is to use speciﬁcation documents

with a textual abstract syntax and a tree-based

intermediate representation which is interpreted by

the generator. In an alternative approach, we can use

a DSL for M2T transformations that is embedded in a

general-purpose scripting engine to realize generator

templates via scripts. Such “generator template

scripts” are then evaluated by the language interpreter

(Zdun, 2010).

To abstract from such implementation details and

to beneﬁt from generator templates as ﬁrst-class mod-

eling elements, our approach focuses on the model

representations of generator templates. In other

words, we consider generator templates as instances

of a conceptual M2T template metamodel (see Figure

2). Rather than including all features that are avail-

able in different template languages, our approach re-

quires only a generic subset of the features deﬁned

through the MOFM2T speciﬁcation (Object Manage-

ment Group, 2008). In this way, the approach is

portable to contemporary M2T template languages.

M2M Transformations. In our approach we con-

sider M2M transformations at the M1 and M2 mod-

eling levels (see Figure 3). First, we compose the

core language models of two (or more) source meta-

models into a target metamodel. This composition is

achieved via transformations that refer to the corre-

sponding metamodel structures (M3). Second, M1

models of respective generator templates (see also

Figure 2) are transformed into new M1 template mod-

els to adapt them to metamodel changes that result

from the DSML integration. These M2M transforma-

tions are higher-order model transformations (HOTs):

Transformations receiving input/output models which

are themselves model representations of transforma-

tions; probably even expressed in the same transfor-

mation language (Tisi et al., 2010).

Note that the programmingmodel that is used by a

certain M2M transformation language (e.g. relational,

operational mappings, hybrid) is transparent to our

approach (Czarnecki and Helsen, 2006). Neverthe-

less, to demonstrate our approachwe use hybrid trans-

formation rules as supported by, for instance, the At-

las Transformation Language (ATL) and the Epsilon

Transformation Language (ETL) in our examples.

...

Meta-metamodel

(M3)

instance-of

Source model

(M1, specification)

...

instance-of

Target model

(M1, specification)

Source metamodel

(M2, language model)

Target metamodel

(M2, language model)

instance-of

...

M2 transformation

definition

M1 transformation

definition

refers to

applied to

generates

refers to refers to

Trace model instance

(M1, trace)

Trace metamodel

(M2, trace model)

instance-of

refers to refers to

refers torefers to

instance-of

Figure 3: M2M transformations and traces.

Transformation Traces. Even though our approach

is generic and does not require a speciﬁc variant of

M2M transformations, we assume that a transforma-

tion history is available. This history includes trans-

formation traces that document the M2M transforma-

tions between language models (the M2 level in Fig-

ure 3). In particular, each transformation trace estab-

lishes a persistent link between a source and a tar-

get model element which are connected via a model

transformation operation (merging, extension, renam-

ing). Moreover, each transformation trace refers to a

corresponding transformation rule. In order to intro-

spect on these traces (for example, to identify the kind

of transformation operation performed), transforma-

tion traces must be represented as ﬁrst-class mod-

els. In other words, each trace must be an instance

of a dedicated trace metamodel that complies with

the transformed models at the M3 level (see Figure

3). Note, however, that we neither deﬁne restrictions

on the time the traces are recorded (allowing, for ex-

ample, partial evaluation of transformation rules, and

runtime tracing) nor do we require a speciﬁc tracing

engine: Built-in tracing, traces generated by trans-

formation rules, as well as internal or external trace

stores are supported.

3 TEMPLATE SYNTAX

REWRITING

Before introducing our template rewriting approach,

we must ﬁrst review the types of potential mismatch

between different DSML metamodels in more detail.

We consider MOF-compliant metamodels. Regarding

M2T template language concepts, we use the corre-

sponding MOFM2T terminology for explanatory pur-

poses (Object Management Group, 2008).

Figure 4 provides a sketch of DSML

and DSML

being composed into DSML

using an M2M trans-

formation deﬁnition. The mismatch problem can then

be restated as question: How can we make the gen-

erator templates A and B apply to instances of the

composed metamodel C rather than to instances of

metamodels A and B, respectively? To answer this

question, we must establish some background: First,

it is important to identify the types of structural dif-

ferences encountered during metamodel composition.

More speciﬁcally, we must collect the details about

the structural differences and make them accessible to

the template transformation. Then, the elements of a

generator template which are affected by these struc-

tural differences must be highlighted. Finally, corre-

sponding transformations of the generator templates

must be deﬁned. The objective of template rewriting

is the transformation of the source templates (

)

into derivatives (

A’

B’

) which refer to metamodel

directly (see Figure 4).

Model

(M1, spec)

Code

artifact C

Metamodel C

(M2, DSML C)

Metamodel A

(M2, DSML A)

Metamodel B

(M2, DSML B)

instance of

Template C

Template A

(M1)

Template B

(M1)

refers to refers to

Code

artifact A'

Code

artifact B'

gluesglues

Template A'

(M1)

Template B'

(M1)

executesexecutes

generates

Code

artifact A

Code

artifact B

generates

applies to

Transformation

definition

applies

generates

Transformation

definition

applies

Trace

generates

refer to

variant of variant of

generates

uses

Figure 4: M2T template rewriting for DSML integration.

Metamodel Composition. When composing the

source metamodels (

and

in Figure 4), the DSML

engineer can choose from a variety of model com-

position operations when deﬁning the transformation,

only limited by the M2M transformation language’s

capacity (Vallecillo, 2010). These include model

mergers using merge operators with different prece-

dence and conﬂict resolution schemes, operating at

different granularity levels (package, metaclass). In

a model extension, subsets of either language model

enter the new metamodel as disjoint sets to comple-

ment each other. Model reﬁnements realize is-kind-

of dependencies between all or selected elements of

the source metamodels. Model interfacing involves

introducing model elements speciﬁc to the new meta-

model as a structural glue between elements merged

from the source metamodels. A hybrid composition

can involve any combination of the above operations.

In our approach, we restrict the composition oper-

ations so that structural semantics of the source meta-

models are preserved. Thus, it is assured that the code

artifacts generated based on the composed metamodel

are semantically equivalent to the code artifacts gen-

erated with M2T templates of the individual source

metamodels. The source-target cardinality can be ei-

ther 1:1 or n:1: Either the element (class, attribute

etc.) is preserved in the target model or a set of ele-

ments is merged into one new element.

Our template rewriting approach considers the ef-

fects of metamodel composition as changes between

two model states across predeﬁned model correspon-

dences, rather than as a sequence of transformation

operations. State-based differentiation refers to com-

puting the changes between the source and target

models after the completed composition, by contrast-

ing the source and target metamodels at the M2 level.

Listing 1 presents two examples of state-based differ-

entiation to identify element name changes, deﬁned

as OCL expressions over two couples of source and

target elements of two MOF-compliant metamodels.

The two introspection deﬁnitions

isRenamedClass

and

isRenamedProperty

reﬂect important cases for

M2T template rewriting, to be reconsidered later in

this section.

Listing 1: State-based differentiation.

def

: isRenamedClass (source : NamedElement ,

2 target : NamedElement ) :

Boolean

3 = source.oclIsKindOf (Class)

and

4 target.oclIsKindOf (Class)

and

5 target.name != source.name

def

: isRenamedProperty (source : NamedElement ,

8 target : NamedElement ) :

Boolean

9 = source.oclIsKindOf (Property )

and

10 target.oclIsKindOf (Property )

and

11 target.name != source.name

A state-based technique has a number of advan-

tages. To begin with, it is minimalistic and imple-

mentable for several M2M transformation engines. In

addition, it turns our template rewriting approach ag-

nostic about the actual composition operations used.

Trace Models. To make state differences between

source and target metamodels computable, the corre-

spondences between metamodel elements established

during the metamodel composition must be preserved

at metamodel composition time (Paige et al., 2011).

Alternative tracing techniques, such as, implicit trac-

ing or model annotation (Drivalos et al., 2008), are not

suitable for state-based differentiation. The tracing

scheme can be achieved by storing the transformed el-

ement couples as instances of a simplistic trace model

(see Figure 5). Instances of

Trace

refer to a

source

metamodelelement and a

target

metamodelelement

which is paired during metamodel composition. In

addition, a reference to the

Transformation

is stored

along with the element couple. The

Trace

concept

provides the context for the introspection expressions

in Listing 1. This tracing scheme is suitable for de-

tecting unsupported heterogeneity situations in the

context of model composition (i.e., composition op-

erations violating deﬁned structural semantic preser-

vation conditions, such as, m:n cardinality of source/-

target element mappings). Traces can be used to inter-

rupt the rewriting process and to aid the debugging of

allowed composition operations (Amar et al., 2008).

Assocation

(from MOF)

Template

TypedModel

(from QVT)

Block

Parameter

(from MOF)

1..*

Template-

Expression

Template-

Invocation

1..*

0..*

overrides

Module

ModuleElement

1..*

0..* 0..*

0..*

extends

body

0..*

depends

Package

(from MOF)

Type

(from MOF)

1..*

0..*

0..1

0..*

nested

Package

NamedElement

(from MOF)

Class

(from MOF)

Property

(from MOF)

0..* 0..1

2..*

1..*

/endType

...

Template model (MOFM2T)

Language model

Trace

(from QVT)

Transformation

(from QVT)

target

source

1 1

0..1

Trace model

Ocl-

Expression

(from OCL)

Variable-

Declaration

(from OCL)

ModelProperty-

CallExp

(from OCL)

...

OperationCall-

Exp

(from OCL)

Operation

(from MOF)

0..*

0..1

Figure 5: Excerpts from MOF and MOFM2T.

Template Models. Based on the transformation data

gained from introspecting the transformation traces,

the templates are to be adapted (e.g., a template

A’

to be derived from template

in Figure 4). To rep-

resent M2T generator templates as ﬁrst-class mod-

els, we consider them instances of a subset of the

MOFM2T reference language (see Figure 5).

In MOFM2T, transformations are structured in

Modules

(e.g., for namespace or public/private part

deﬁnitions) which can contain a number of

Tem-

plates

(see Figure 5). A

Template

as a special-

ized

Block

contains string production expressions

(

TemplateExpressions

) with placeholders for data

to be extracted from models.

Templates

can be in-

voked with

Parameters

and can return

Parameters

They realize function-style language elements (Wim-

mer et al., 2012). A

Template

can override other

templates, with the overriding template being invoked

in place of the shadowed template. A

TemplateEx-

pression

, among others, represents expressions for

calls to model elements, for declaring and managing

variables, for declaring control statements, and for ex-

panding to strings. A

TemplateInvocation

speciﬁes

an invocation of a

Template

. As

TemplateInvoca-

tion

is a specializing classiﬁer of

TemplateExpres-

sion

Templates

can be invoked from within other

Templates

. A

TypedModel

speciﬁes an input model

Package

) to be referenced and accessed throughout

the

TemplateExpressions

. The

Types

contained by

the

Package

represent the domain of model element

types available to the

Templates

. These type refer-

ences are primary rewriting targets.

Template Model Transformations. Metamodel

changes as identiﬁed by state-based differentiation

(

isRenamedClass

and

isRenamedProperty

in List-

ing 1) affect the M2T generator templates syntacti-

cally in two ways. First, block expressions (variants

OclExpressions

) maintain references to

Types

(as can be learned from Figure 5). This is the case

for

Parameters

Templates

and for type-aware

template expressions, in particular type annotations

VariableDeclarations

and type annotations for

parameters of operation calls (

OperationCallExp

Second, navigating

OclExpressions

, such as,

Mod-

elPropertyCallExp

may refer to renamed meta-

model elements (e.g.,

Property

). From these syntac-

tical dependencies, three rewriting requirements fol-

low for pairs of source and target metamodel ele-

ments, which are represented by a set of

Trace

in-

stances (see Figure 5):

Retyping: References to a

Type

named after a re-

named source

Class

must be replaced by the target

Class

name.

Association Retargeting: When an

Association

be-

tween two

Classes

is redirected and receives another

target (i.e., a

Property

owned by another

Class

), the

corresponding

endTypes

must be modiﬁed. Thus, the

return

Type

of the expression must be adapted and set

to the new

endType

. Note that the name of a corre-

sponding navigation reference (e.g., a property call to

retrieve an element) in navigating

OclExpressions

is not affected.

Property Renaming: A renamed

Property

(

isRenamedProperty

) affects navigating

OclEx-

pressions

as the navigation path in these expres-

sions changes. To rewrite these navigation paths

according to the renaming, the

property

attributes

of these

OclExpressions

are adjusted.

All three rewriting operations may occur repeat-

edly for identical pairs of transformed source and tar-

get metamodel element types, depending on the num-

ber of state-based differences computed from the set

Traces

. Corresponding transformations must be

deﬁned in an M2M transformation deﬁnition which

operates on the source templates (

) based on a set

Traces

to produce syntactically adapted template

model instances (

A’

B’

; see Figure 4).

4 EPSILON/EMF PROTOTYPE

Based on our notion of template rewriting (see Sec-

tion 3), we introduce a prototypical realization of this

rewriting technique for the EMF and the Epsilon fam-

ily of model transformation languages. In this tech-

nology projection, MOF-compliant DSML models

are approximated by Ecore metamodels. To perform

language model composition, as described in Sec-

tion 3, we use transformation deﬁnitions expressed

in Epsilon task languages. M2T generator templates

are represented by EGL transformations. To obtain

model representations of EGL templates, we map the

respective MOFM2T concepts to their correspond-

ing language concepts in the Epsilon language fam-

ily. The Epsilon language runtime provides a built-

in tracing facility for capturing transformation cor-

respondences between Ecore metamodels as required

for our rewriting approach (Kolovos et al., 2012).

Ecore Metamodel Composition. In the EMF/Ep-

silon toolkit, metamodel composition is divided into

three tasks: (1) matching, (2) copying, and (3) merg-

ing metamodels. The ﬁrst task (matching) is per-

formed via the Epsilon Comparison Language (ECL)

and has the source metamodels, as well as compari-

son rules provided by the DSML engineer as inputs.

During copying, the unmodiﬁed metamodel elements

(i.e., which do not match any comparison rule) are

copied into the target metamodel of the composed

DSML. This can be achievedusing the ETL. The third

step in an Epsilon-speciﬁc DSML composition ap-

plies merge rules deﬁned by the DSML engineer on

element triples of the source metamodels and the tar-

get metamodel. The output of this 3-pass transforma-

tion is a composed DSML metamodel and transfor-

mation traces, to be used for state-based differentia-

tion (see Section 3).

The introspection operations

isRenamedClass

and

isRenamedProperty

translate into the Epsilon

Object Language (EOL) equivalents for Ecore meta-

models in Listing 2, to compute the state-based differ-

ences between the source and the target metamodels.

Listing 2: State-based differentiation for Ecore metamod-

els.

operation

isRenamedClass (source : Ecore!EObject ,

2 target : Ecore!EObject) :

Boolean

{

return

source.isKindOf (Ecore!EClass)

and

4 target.isKindOf (Ecore!EClass)

and

5 target.name <> source.name;

6 }

operation

isRenamedProperty (source : Ecore!EObject ,

9 target : Ecore!EObject ) :

Boolean

{

return

source.isKindOf (Ecore!EReference )

and

11 target.isKindOf (Ecore!EReference )

and

12 target.name <> source.name;

13 }

Minimal Ecore Trace Model. To provide a model

representation of transformation traces (as sketched

in Figure 5 in Section 3), we realized a custom trace

metamodel for our prototype. Listing 3 gives the

metamodel deﬁnition.

CompositionLink

is the cor-

responding concept of

Trace

in Figure 5.

Listing 3: Trace metamodel in EMFatic textual syntax.

@namespace

(uri="CompositionTrace ", prefix ="

CompositionTrace ")

package

CompositionTrace ;

class

CompositionLink {

ref

EObject source;

ref

EObject target;

7 }

During the metamodel composition step (see above),

transformation correspondences obtained from the

Epsilon tracing machinery are stored as

Composi-

tionLink

instances. Each

CompositionLink

stores

a pair of source and target

EObjects

extracted from

the Epsilon tracing sources (ECL match, ETL trans-

formation, and EML merge traces). In this custom

metamodel, references to the respective merge and

transformation rules are omitted for brevity.

Ecore Metamodel for EGL Templates. EGL tem-

plates are natively processed by an ANTLR-based

parser and transformed into an abstract syntax tree

(AST) structure. Currently, Epsilon neither provides

EMF metamodel representations of its language fam-

ily, nor the tooling to perform round-tripping between

ASTs and any model representation. Therefore, we

extended an early prototype for EOL model represen-

tations (Wei, 2012) to cover EGL language concepts.

We extracted the language abstractions from (Kolovos

et al., 2012) and by screening the Epsilon code base

for missing details.

Figure 6 presents an excerpt of the extended

Ecore metamodel. In this technology projection, the

M2T template model concepts introduced in Figure

OperationDeclaration

(from EOL)

Formal-

Parameter

(from EOL)

Type

(from EOL)

Orchestration-

Workflow

(from Workflow)

Module

(from EOL)

Model

(from EMC)

1..*

0..*

0..1

Block

(from EOL)

nested

Statement

(from EOL)

Expression

(from EOL)

FeatureCallExpression

(from EOL)

0..*

0..1

0..*

0..1

0..*

0..1

0..*

0..1

0..*

0..*0..*

0..*

ModelElementType

(from EOL)

type: String

PropertyCallExpression

(from EOL)

MethodCallExpression

(from EOL)

OperationDefinition

(from EOL)

VariableDeclaration-

Expression

(from EOL)

EReference

(from Ecore)

EClass

(from Ecore)

EStructuralFeature

(from Ecore)

EAttribute

(from Ecore)

EDataType

(from Ecore)

ENamedElement

(from Ecore)

0..* 0..1

2..*

property

eAttributeType

Template model (Epsilon)Language model

Figure 6: Excerpt from the Ecore metamodel for the Epsilon

language family.

5 must be mapped to their Epsilon correspondences

in Figure 6. Some Epsilon concepts such as

Mod-

ule

and

Block

are directly compliant with MOFM2T.

Nevertheless, some EGL concepts deviate from the

MOFM2T metamodel structure: For example, Ep-

silon distinguishes between

Statements

and

Ex-

pressions

. In contrast, the MOFM2T speciﬁcation

(Object Management Group, 2008) summarizes text

production rules of

Templates

as specialized expres-

sions (

TemplateExpression

). Generally speaking,

the complete EOL/EGL metamodel exceeds the do-

main coverage of the MOFM2T metamodel because

Epsilon provides an integrated collection of several

task-speciﬁc languages. For our prototype, however,

only a subset of the Epsilon metamodel was relevant

(see Figure 6). The resulting concept mapping used

for our prototype is shown in Table 1.

Table 1: Mappings between MOFM2T and Epsilon.

MOFM2T Epsilon

Association EReference

Block Block

Class EClass

ModelPropertyCallExpr PropertyCallExpression

Module Module

NamedElement ENamedElement

OperationCallExpr MethodCallExpression

Parameter FormalParameter

Property EAttribute

Template OperationDefinition

TemplateExpression Statement

Expression

TemplateInvocation FeatureCallExpression

Type Type

EDataType

TypedModel Model

ModelElementType

VariableDeclaration VariableDeclaration-

Expression

ETL Transformations on EGL Template Models.

Finally, assuming the availability of model repre-

sentations of source EGL templates and of transfor-

mation traces (

CompositionLink

instances), equiv-

alents to the template-to-template transformations as

deﬁned in Section 3 must be deﬁned based on the

mappings shown in Table 1. Note that these transfor-

mations apply to any occurrence of EGL templates to

be adapted. The deﬁnitions below are generic in this

sense and must be bound to the concrete templates un-

der transformation. These M2M transformations are

expressed in ETL.

Retyping, Association Retargeting. In Epsilon, the

type of a model element acting as an input to a trans-

formation is represented by the

ModelElementType

metaclass. To change the type reference owned by

a template element (e.g., an expression) or to retar-

get an association (i.e., an

EReference

in Ecore), the

respective

type

attribute of the corresponding

Mod-

elElementType

element must be changed to match

the name of the target metamodel metaclass (see Fig-

ure 6). The corresponding ETL rule is depicted in

lines 10–20 of Listing 4.

Property Renaming. An

EReference

in Ecore repre-

sents a navigation axis from one

EClass

to another

by pairing the opposite metaclasses. Therefore, to re-

ﬂect a renamed

EReference

in the template model,

the

property

attribute of a

PropertyCallExpres-

sion

element must be adapted (see Figure 6). The

ETL rule for this transformation is deﬁned in lines

22–32 of Listing 4.

Listing 4: EGL snippet creating ETL rewrite rules.

for

links) {

var

src : Ecore!EObject;

var

trgt : Ecore!EObject;

3 src = l.source;

4 trgt = l.target;

(src.name <> trgt.name) {

6 etl = etl + TemplateFactory .prepare(renameElement (

src , trgt)).process ();

7 }

8 }

@template

operation

renameElement (src : Ecore!EClass , trgt : Ecore

!EClass) { %]

rule

retype[%=src.name%]2[%=trgt.name%]

transform

s : egl_in!ModelElementType

t : egl_out!ModelElementType

extends

Type

16 {

17 guard : s.type == "[%=src.name%]"

18 t.type = "[%=trgt.name %]";

19 }

20 [% }

@template

operation

renameElement (src : Ecore!EReference , trgt :

Ecore!EReference ) { %]

rule

rename[%=src.name%]2[%=trgt.name%]

transform

s : egl_in!PropertyCallExpression

t : egl_out!PropertyCallExpression

extends

FeatureCallExpression

28 {

29 guard : s.property == "[%=src.name%]"

30 t.property = "[%=trgt.name%]";

31 }

32 [% }

As mentioned above, the two M2M transforma-

tion rules must be instantiated for a concrete set of

EGL template models (e.g., to reﬂect the concrete el-

ement names). As shown in Listing 4, the ETL rules

are themselves generated by instantiating an M2T

EGL template for a given set of transformation traces.

For demonstration purposes, the top-level EGL script

processes the available traces retrieved from the pre-

ceeding metamodel composition in lines 1–8, to dis-

patch to the expanded ETL transformation rules for

each pair of source and target elements with name

mismatches (see line 5 in Listing 4).

Epsilon Composition and Rewriting Procedure. A

process ﬂow view of the overall composition and

transformation steps is presented in Figure 7. This

Eclipse-speciﬁc process ﬂow realizes the abstracted

scheme shown in Figure 4. Two activities must

be performed as the prerequisites for applying the

actual rewriting to the M2T EGL templates: 1)

The DSML metamodel composition in three Epsilon-

speciﬁc steps (matching, copying, merging) and 2)

the transformation of M2T EGL templates into their

model representations—that is, the instances of the

metamodel depicted in Figure 6. The trace model

generated during the metamodel composition and

the instantiated ETL rewrite rules enter the actual

template-to-template transformation along with the

EGL template models. The rewritten EGL template

models are ﬁnally serialized into EGL script repre-

sentations to be applied to the composed metamodel

at the end of this process (this last step is not shown

in Figure 7).

This process ﬂow can be automated in Epsilon

by providing a speciﬁc build script which turns the

ﬂow into a sequence of Epsilon-speciﬁc Apache Ant

tasks (Kolovos et al., 2008). Such an

Orchestra-

tionWorkflow

deﬁnes the sequence of tasks, such as,

Model

loading or

Module

invocation (see Figure 6).

Alternatively, such a process ﬂow can be realized by

instrumenting the Epsilon and EMF APIs in a piece

of Java glue code.

5 AN INTEGRATION SCENARIO

In this section, we describe a composition scenario of

two DSMLs to exemplify the integration process. We

run through the whole process of applying one higher-

order rewrite rule

. The ﬁrst DSML models system

audits (referred to as DSML

, hereafter) by provid-

ing abstractions for audit events and audit rules. The

second DSML (DSML

, hereafter) allows for mod-

eling generic state machines. The scenario integrates

the two DSMLs into a composed DSML

capable of

All software artifacts as well as the complete example

can be obtained from http://nm.wu.ac.at/modsec.

Metamodel

DSML 1

Metamodel

DSML 2

Trace

metamodel

Match elements

(ECL)

Comparison

rules

Match trace

Copy elements

(ETL)

Merge elements

(EML)

Transformation

rules

Transformation trace

Merge trace

Merge

rules

Composed metamodel

Generate trace

model

Match trace

Generate higher-order

M2M rewrite rules

(EGL)

Trace model

Rewrite M2T

transformation models

(ETL)

Higher-order

rewrite rules

M2T transformation

metamodel (EOL, EGL)

Metamodel

DSML 1

Metamodel

DSML 2

Metamodel DSML 1

Metamodel DSML 2

Rewritten M2T transformation

model DSML 1

Rewritten M2T transformation

model DSML 2

M2T transformation

model DSML 1

{stream}

M2T transformation

model DSML 2

{stream}

Higher-order rewriting of M2T templates

Figure 7: Process of higher-order rewriting of M2T templates.

modeling a reactive distributed system with auditing

support. Both DSMLs provide M2T generator tem-

plates written in EGL to generate Java code. The ob-

jective is to reuse these EGL templates for models of

DSML

through syntax rewriting. For this scenario,

we explain the application of a particular higher-order

rewriting rule to a template speciﬁc to DSML

In DSML

for system audits, an

AuditRule

sub-

scribes to a

Signal

type and, when an

AuditEvent

is triggered, checks the corresponding

Conditions

against the published

Signal

occurrence (see Figure

8). If all

Conditions

evaluate to true, a notiﬁcation

action will be executed to perform audit-related tasks,

such as generating an entry in an audit trail or notify-

ing the system administrator—not displayed in Figure

8; for details see (Hoisl and Strembeck, 2012).

AuditEvent

Signal

data : String

AuditRule

Condition

EventSystem

NamedElement

name : String

publish

0..*

conditions

0..*

auditEvents

0..*

auditRules

0..*

Figure 8: DSML

—auditing in event-based systems.

For DSML

, we have chosen a state/transition

pattern (see Figure 9) for its communicability in an

example. In a state machine,

Transitions

model the

change from one

State

to another. A

Transition

triggered by an

Event

StateMachine

State

Transition

Event

NamedElement

name : String

states

0..*

transition

0..1

events

0..*

target

Figure 9: DSML

—a state/transition behavioral system.

DSML Metamodel Composition. In this step, we

merge the

AuditEvent

element from DSML

and

the

Event

element from DSML

into a uniﬁed

Au-

ditElement’

element of the composed DSML

(see Figure 10). Thereby, we connect both DSMLs

structurally by merging these two core concepts into

one concept of DSML

. Otherwise, the metamodel

composition preserves all structural semantics present

in the source DSMLs (inheritance, attributes, refer-

ences).

AuditEvent'

DSML C

AuditEvent

DSML A

Event

DSML B

«merge» «merge»

:CompositionLink

target target

source

Figure 10: DSML composition via element merge.

This concept merge is deﬁned by the ECL com-

parison rule shown in Listing 5. Therein, a match is

deﬁned iff the corresponding metamodel elements of

the two DSMLs are named AuditEvent and Event, re-

spectively (line 5)

Listing 5: ECL comparison rule for

AuditEvent’

rule

AuditEventandEvent2AuditEvent ’

match

l : EventSystem !EClass

with

r : StateMachine !EClass {

compare

5 l.name = ’AuditEvent ’

and

r.name = ’Event ’

6 }

For all elements missed by the rule in Listing 5,

a direct copy operation into the target metamodel is

deﬁned via an ETL transformation (not shown). All

elements matching the above ECL rule are processed

Please note that we show only relevant code parts in the

example listings (excerpts).

by the merge operation in Listing 6. Therein, a new

element name is constructed (line 5) and all proper-

ties, references, and inheritance relations (lines 6–7)

from both the DSML

and the DSML

metamodels

are transferred into the newly created element in the

target metamodel. This preserves the n:1 source/tar-

get cardinality (see Section 3).

Listing 6: EML merge rule for

AuditEvent’

rule

MergeAuditEvent

merge

l : EventSystem !EClass

with

r : StateMachine !EClass

into

t : EventSystemStateMachine !EClass {

5 t.name = l.name + "’";

6 t.eStructuralFeatures ::= l.eStructuralFeatures +

r.eStructuralFeatures ;

7 t.eSuperTypes ::= l.eSuperTypes + r.eSuperTypes ;

8 }

Ecore-based Trace Model. The merge and the trans-

formation yield an instance of the trace metamodel

(see Listing 3, Section 4). In Figure 10, the two re-

sulting instances of

CompositionLink

are illustrated,

recording pairs of transformation sources and trans-

formation targets: (

AuditEvent

AuditEvent’

) and

(

Event

AuditEvent’

Ecore-based Template Model. Listing 7 shows an

example code snippet of an EGL template. For now,

only line 1 is of interest: A loop is deﬁned iterating

overall

AuditEvents

in an

EventSystem

. The return

type of the reference

EventSystem.auditEvents

deﬁned as

AuditEvent

. In the composed DSML

the corresponding concept is

AuditEvent’

. To reuse

this snippet for DSML

, the type annotation of the it-

erator variable

must be modiﬁed to

AuditEvent’

Listing 7: EGL code snippet with typed iterator.

1 [%

for

(ae : AuditEvent

EventSystem .auditEvents ) {

for

(signal

ae.publish ) {

out

println

(’private Signal ’ + signal.name + ’;’);

4 }

5 } %]

For applying syntactical rewrite rules, the EGL

template (Listing 7) needs to be transformed into its

model representation. Listing 8 shows the corre-

sponding instance model representation of line 1 of

Listing 7 (simpliﬁed).

Listing 8: EGL model representation.

1 <statements xsi:type="dom :ForStatement ">

2 <iterator name="ae">

3 <type xsi:type="dom:ModelElementType " type=" AuditEvent

"/>

4 </iterator >

5 <iterated xsi :type="dom:PropertyCallExpression "

property ="auditEvents ">

6 <target xsi:type="dom:NameExpression " name="

EventSystem "/>

7 </iterated >

EGL Template Model Transformation. The ab-

stracted higher-order rewrite rules documented in

Listing 4, Section 4, must be instantiated using the

trace model shown in Figure 10. The ETL rewrite

rule generated by this template instantiation for the

DSML

element

AuditEvent

is reproduced in List-

ing 9. All other rewrite rules are omitted due to space

limitations. The rule in Listing 9 resets the

type

prop-

erties of

ModeElementType

instances, which equal to

AuditEvent

, to the value

AuditEvent’

Listing 9: ETL higher-order rewrite rule.

rule

renameAuditEvent2AuditEvent ’

transform

s : egl_in!ModelElementType

t : egl_out!ModelElementType

extends

Type {

5 guard : s.type == "AuditEvent "

6 t.type = "AuditEvent ’";

7 }

Applying this rule to the EGL model as shown in

Listing 8 results in an EGL model which is corrected

for the changed type name. Line 3 of Listing 10 shows

that the type of the iterator variable named

was

effectively changed to

AuditEvent’

Listing 10: Rewritten EGL model representation.

1 <statements xsi:type="dom:ForStatement ">

2 <iterator name="ae">

3 <type xsi :type="dom :ModelElementType " type="AuditEvent

’"/>

4 </iterator >

5 <iterated xsi :type="dom:PropertyCallExpression "

property ="auditEvents ">

6 <target xsi:type="dom:NameExpression " name="

EventSystem "/>

7 </iterated >

To be able to execute the rewritten EGL template,

in a last step, the EGL model representation in List-

ing 10 is serialized back into EGL template code (see

Listing 11). Line 1 shows the changed type of the

loop iterator named

. This type conforms to the

composed DSML metamodel

(see Figure 10). The

rewritten EGL code template can be executed over

models of DSML

Listing 11: EGL snippet with changed iterator type.

1 [%

for

(ae : AuditEvent ’

EventSystem .auditEvents ) {

for

(signal

ae.publish ) {

out

println

(’private Signal ’ + signal.name + ’;’);

4 }

5 } %]

6 DISCUSSION

Our approach to rewriting M2T generator templates

syntactically is motivated by examining barriers to

reusing DSMLs, in general, and to reusing DSML-

based M2T transformations for platform integration,

in particular. An important barrier results from M2T

transformation languages lacking the capacity of ab-

stracting from certain structural conditions of a con-

crete metamodel (Wimmer et al., 2012).

While variants of template genericity (Cuadrado

et al., 2011; Varr´o and Pataricza, 2004) help decouple

from early bound references to concrete model ele-

ment types, naming differences affecting navigational

axes are not addressed, for example. Therefore, our

approach can complement M2T template genericity.

Given that generic transformations can also be imple-

mented using HOTs on M2T templates, there is even

a shared implementation vehicle.

In addition, our approach contributes to capturing

M2T transformation logic independently from a par-

ticular transformation language or engine. This plat-

form abstraction (Wimmer et al., 2012) contributes to

the reusability of M2T transformations, as they can be

migrated to another language environment. By pro-

viding a precise deﬁnition of our approach in terms of

the MOFM2T speciﬁcation (see Sections 3 and 4), we

establish such an M2T platform abstraction.

Another barrier to M2T transformation reuse is

the lack of contextual information about the con-

ditions and requirements of reuse (Wimmer et al.,

2012). While not fully elaborated in this paper, we

enumerate working assumptions on the structural se-

mantics of metamodel transformations (e.g., cardinal-

ity classes supported) in Section 3. These working

assumptions can be formalized into executable pre-

and post-conditions (e.g., OCL expressions) stored at

the model-level. The conditions can then be evalu-

ated based on the transformation traces generated dur-

ing metamodel composition to establish whether the

rewriting transformations are applicable.

One critique of using HOTs (Tisi et al., 2009)

is that they expose the engineer to the internals of

the transformation language (Tisi et al., 2010) and

thus hinder reuse. In the case of M2T transformation

models, this model complexity bears the risk of de-

railing the widely opaque text production expressions

so that the platform artifacts are emitted malformed.

In our approach, the M2T generator templates are

represented by comparatively small metamodel do-

mains (i.e., subsets of MOFM2T and the correspond-

ing EGL mapping). On top, the HOTs remain com-

pletely hidden from the DSML engineer because they

are themselves generated by template instantiation on

the tracing data (see Section 3). This is a compromise

balancing between automation and a limited support

for metamodel heterogeneity.

The degree of DSML and M2T transformation

reuse is directly related to the relative effort caused

by the generative environment(transformation adjust-

ments, manual conﬁguration, automation of the gen-

eration tasks). To improve the reuse degree, this ex-

tra effort must be minimal. In our approach, most of

the artifacts are only speciﬁed or generated once upon

composing a DSML (e.g., the rewrite rules). Only

when the source DSMLs are modiﬁed, the compos-

ing transformation deﬁnition must be updated. M2T

transformations speciﬁc to the integrated DSML can

vary independently from the generated M2T transfor-

mations. This allows for generating different kinds

of patch code; e.g., pipelining or language extension

(Spinellis, 2001).

7 RELATED WORK

The approach presented in this paper relates to exist-

ing work in two areas. First, we distinguish between

three relevant language- and model-level reuse tech-

niques for generator templates.

Higher-Order Transformation (HOT). Our syntax

rewriting approach takes two M2T transformation

models (EGL templates) as input and produces two

modiﬁed M2T transformations (EGL templates) by

applying an M2M transformation (via ETL) over

these two transformation models. Hence, we apply

HOTs for transformation modiﬁcations (Tisi et al.,

2009). In recent years, a variety of alternative HOT

application scenarios have attracted attention, includ-

ing transformation analysis, transformation gener-

ation, and transformation composition (Tisi et al.,

2009). In addition, language-level support for HOTs

has been improved (Oldevik and Haugen, 2007; Tisi

et al., 2010). However, related work has concen-

trated on speciﬁc transformation platforms, for in-

stance, ATL (Tisi et al., 2010), rather than on HOTs

in a technology-independent manner.

Generic Templates. Generic templates abstract from

the underlying metamodel and contain transformation

rules which refer to abstracted metamodel types in

terms of type variables (Cuadrado et al., 2011; Varr´o

and Pataricza, 2004). The type variables are then late-

bound to speciﬁc model element types at transforma-

tion runtime. This form of type parametrization must

be employed by the DSML engineer right from the

beginning to construct the generator templates in a

reusable manner. Some approaches also require the

explicit deﬁnition of bindings for type variables and

structural adapters against a concrete metamodel to

cope with types of structural heterogeneity in meta-

models. This certainly adds to the initial effort of con-

structing the supporting transformations for a DSML.

Our approach differs as we do not base the rewrit-

ing of templates on placeholder variables or adapters,

but we rather extract the changes from a trace model.

This offers the beneﬁt of automation and of unantici-

pated reuse of generator templates. At the same time,

our approach is limited in its expressiveness to handle

metamodel heterogeneity (see Section 3). Because

both approaches use HOTs as implementation vehi-

cle, they can complement each other. Transformation

genericity has not been documented for M2T genera-

tor templates so far.

Adapter Models. To establish metamodel confor-

mance for generator templates, another strategy is the

use of intermediate models which adapt model ac-

cesses by the generator template to match the origi-

nal metamodel structure. To mimic the original meta-

model, an adapter model consists of relational expres-

sions which bind to the transformed metamodel and

return model values according to the declared corre-

spondences (Morin et al., 2009). Adapter models pro-

vide for unanticipated template reuse, however, as for

M2T transformations the generated platform artifacts

would not reﬂect the derived or newly introduced do-

main concepts. This increases the cognitive distance

for the integrating DSML engineer. The generation

of glue code using M2T transformations is restricted

because concept correspondences between the inte-

grated DSML and the source DSMLs can not be lever-

aged in code generation.

The second related area is the encoding of tracing

data to be used in model transformations.

Modeled Traces. Traces captured along the trans-

formation process can be stored in a separate trace

model or can be attached to the source/target model,

e.g., via model annotations (Paige et al., 2011; Amar

et al., 2008). The complexity of traces depends on

their scope (e.g., only selected or all rules) and the

tracing data needed. For our approach, it is sufﬁ-

cient to store trace links between source and target el-

ements. Besides, the trace metamodel can be deﬁned

for more general or very speciﬁc purposes, such as our

template rewriting scenario (Drivalos et al., 2008).

Delta Models. Delta models are generated by com-

paring the input and output models of an M2M trans-

formation (ex-post). The creation of delta models (or

difference models) is comparable to diff tools for text

artifacts. In contrast to model traces, delta models

are an indirect method. Traces are not directly cap-

tured at transformation time, the actual transforma-

tion correspondences at the element level cannot be

reconstructed. This black-box encoding of tracing

data (Diskin et al., 2011) is not suitable for a rewriting

approach which requires exact knowledge of source

and target correspondences.

8 CONCLUSIONS

In this paper, we present an approach to rewriting

M2T generator templates syntactically for reusing

them in DSML integration. By considering M2T

generator templates as ﬁrst-class models and reusing

M2M transformation traces, we developed a rewrit-

ing approach based on higher-order model transfor-

mations (HOTs). This approachis independent from a

concrete transformation platform and the documenta-

tion in terms of the MOFM2T speciﬁcation facilitates

uptake in MOFM2T-compliant transformation lan-

guages. To demonstrate the feasibility of this rewrit-

ing technique, we provide a prototype implementa-

tion and a DSML integration example based on the

Eclipse EMF project and the Epsilon language family.

As a side product, we so contributed to constructing a

metamodel for the M2T-speciﬁc parts of the Epsilon

language infrastructure.

In our future work, we will extend our prototype

to support a wider range of metamodel-level compo-

sition operations (e.g., extends, alternatives). More-

over, we will evaluate the applicability of our ideas

to other transformation languages with HOT support

(e.g., ATL).

ACKNOWLEDGEMENTS

This work has partly been funded by the Austrian Re-

search Promotion Agency (FFG) of the Austrian Fed-

eral Ministry for Transport, Innovation and Technol-

ogy (BMVIT) through the Competence Centers for

Excellent Technologies (COMET K1) initiative and

the FIT-IT program.

The authors would like to thank William Wei and

Dimitris Kolovos for their valuable advice on various

Epsilon issues.

REFERENCES

Amar, B., Leblanc, H., and Coulette, B. (2008). A

Traceability Engine Dedicated to Model Transforma-

tion for Software Engineering. In Proc. of the 4th

ECMDA Traceability Workshop, volume WP09-09 of

CTIT Workshop Proceedings, pages 7–16. Centre for

Telematics and Information Technology (CTIT), Uni-

versity of Twente.

Bettin, J. (2002). Measuring the Potential of Domain-

Speciﬁc Modelling Techniques. In Proc. of the

2nd Domain-Speciﬁc Modelling Languages Work-

shop, pages 39–44. Helsinki School of Economics.

Cuadrado, J. S., Guerra, E., and de Lara, J. (2011). Generic

Model Transformations: ”Write Once, Reuse Every-

where”. In Theory and Practice of Model Transforma-

tions, volume 6707 of LNCS, pages 62–77. Springer.

Czarnecki, K. and Helsen, S. (2006). Feature-based sur-

vey of model transformation approaches. IBM Sys-

tems Journal, 45(3):621–646.

Diskin, Z., Xiong, Y., and Czarnecki, K. (2011). From

State- to Delta-Based Bidirectional Model Transfor-

mations: the Asymmetric Case. Journal of Object

Technology, 10:6:1–25.

Drivalos, N., Paige, R. F., Fernandes, K. J., and Kolovos,

D. S. (2008). Towards Rigorously Deﬁned Model-to-

Model Traceability. In Proc.of the 4th ECMDA Trace-

ability Workshop, volume WP09-09 of CTIT Work-

shop Proceedings, pages 17–26. Centre for Telemat-

ics and Information Technology (CTIT), University of

Twente.

Herrmann, C., Krahn, H., Rumpe, B., Schindler, M., and

V¨olkel, S. (2007). An Algebraic View on the Seman-

tics of Model Composition. In Proc. of the 3rd Eu-

ropean Conference on Model Driven Architecture—

Foundations and Applications, volume 4530 of LNCS,

pages 99–113. Springer.

Hoisl, B. and Strembeck, M. (2012). A UML Extension

for the Model-driven Speciﬁcation of Audit Rules.

In Proc. of the 2nd International Workshop on Infor-

mation Systems Security Engineering, volume 112 of

LNBIP, pages 16–30. Springer.

Hoisl, B., Strembeck, M., and Sobernig, S. (2012). To-

wards a Systematic Integration of MOF/UML-based

Domain-speciﬁc Modeling Languages. In Proc. of the

16th IASTED International Conference on Software

Engineering and Applications, pages 337–344. ACTA

Press.

Kalnina, E., Kalnins, A., Celms, E., and Sostaks, A.

(2010). Graphical Template Language for Transfor-

mation Synthesis. In Software Language Engineering,

volume 5969 of LNCS, pages 244–253. Springer.

Kolovos, D., Rose, L., Paige, R., and Garc´ıa-Dom´ınguez,

A. (2012). The Epsilon Book. Available

at: http://www.eclipse.org/epsilon/doc/book/. Last ac-

cessed: 30.11.2012.

Kolovos, D. S., Paige, R. F., and Polack, F. A. C. (2008).

A Framework for Composing Modular and Interoper-

able Model Management Tasks. In Proc. of the 1st

ECMFA Workshop on Model Driven Tool and Process

Integration, pages 79–90. Frauenhofer IRB.

Krueger, C. W. (1992). Software Reuse. ACM Computing

Surveys, 24(2):131–183.

Morin, B., Perrouin, G., Lahire, P., Barais, O., Van-

wormhoudt, G., and J´ez´equel, J.-M. (2009). Weav-

ing Variability into Domain Metamodels. In Proc. of

the 12th International Conference on Model Driven

Engineering Languages and Systems, pages 690–705.

Springer.

Object Management Group (2008). MOF Model To

Text Transformation Language. Available at:

http://www.omg.org/spec/MOFM2T. Version 1.0,

formal/2008-01-16. Last accessed: 30.11.2012.

Oldevik, J. and Haugen, Ø. (2007). Higher-Order Trans-

formations for Product Lines. In Proc. of the 11th In-

ternational Software Product Line Conference, pages

243–254. IEEE Computer Society.

Paige, R., Drivalos, N., Kolovos, D., Fernandes, K., Power,

C., Olsen, G., and Zschaler, S. (2011). Rigorous

Identiﬁcation and Encoding of Trace-Links in Model-

Driven Engineering. Software and Systems Modeling,

10:469–487.

Rose, L. M., Matragkas, N., Kolovos, D. S., and Paige, R. F.

(2012). A Feature Model for Model-to-Text Transfor-

mation Languages. In Proc. of the 2012 ICSE Work-

shop on Modeling in Software Engineering, pages 57–

63. IEEE Computer Society.

Spinellis, D. (2001). Notable Design Patterns for Domain-

Speciﬁc Languages. Journal of Systems and Software,

56(1):91–99.

Tisi, M., Cabot, J., and Jouault, F. (2010). Improving

Higher-Order Transformations Support in ATL. In

Proc. of the 3rd International Conference on Theory

and Practice of Model Transformations, volume 6142

of LNCS, pages 215–229. Springer.

Tisi, M., Jouault, F., Fraternali, P., Ceri, S., and B´ezivin, J.

(2009). On the Use of Higher-Order Model Trans-

formations. In Proc. of the 5th European Confer-

ence on Model Driven Architecture—Foundations and

Applications, volume 5562 of LNCS, pages 18–33.

Springer.

Vallecillo, A. (2010). On the Combination of Domain Spe-

ciﬁc Modeling Languages. In Proc. of the 6th Euro-

pean Conference on Modelling Foundations and Ap-

plications, volume 6138 of LNCS, pages 305–320.

Springer.

Varr´o, D. and Pataricza, A. (2004). Generic and Meta-

transformations for Model Transformation Engineer-

ing. In Proc. of the 7th International UML Conference

Modelling Languages and Applications, volume 3273

of LNCS, pages 290–304. Springer.

Wei, W. (2012). EpsilonLabs: Epsilon Static Analysis.

Available at: http://code.google.com/p/epsilonlabs/

wiki/EpsilonStaticAnalysis. Last accessed:

30.11.2012.

White, J., Hill, J. H., Gray, J., Tambe, S., Gokhale, A. S.,

and Schmidt, D. C. (2009). Improving Domain-

Speciﬁc Language Reuse with Software Product Line

Techniques. IEEE Software, 26(4):47–53.

Wimmer, M., Kappel, G., Kusel, A., Retschitzegger, W.,

Sch¨onb¨ock, J., and Schwinger, W. (2010). Towards

an Expressivity Benchmark for Mappings based on a

Systematic Classiﬁcation of Heterogeneities. In Proc.

of the 1st International Workshop on Model-Driven

Interoperability, pages 32–41. ACM.

Wimmer, M., Kappel, G., Kusel, A., Retschitzegger, W.,

Sch¨onb¨ock, J., and Schwinger, W. (2012). Fact

or Fiction—Reuse in Rule-Based Model-to-Model

Transformation Languages. In Proc. of the 2nd Inter-

national Conference on Model Transformations, vol-

ume 7307 of LNCS, pages 280–295. Springer.

Zdun, U. (2010). A DSL Toolkit for Deferring Architec-

tural Decisions in DSL-based Software Design. Infor-

mation & Software Technology, 52(7):733–748.