HAL Id: hal-01197038https://hal.inria.fr/hal-01197038

Submitted on 11 Sep 2015

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Melange: A Meta-language for Modular and ReusableDevelopment of DSLs

Thomas Degueule, Benoit Combemale, Arnaud Blouin, Olivier Barais,Jean-Marc Jézéquel

To cite this version:Thomas Degueule, Benoit Combemale, Arnaud Blouin, Olivier Barais, Jean-Marc Jézéquel. Melange:A Meta-language for Modular and Reusable Development of DSLs. 8th International Conference onSoftware Language Engineering (SLE), Oct 2015, Pittsburgh, United States. �hal-01197038�

Melange: A Meta-language for Modularand Reusable Development of DSLs

Thomas DegueuleINRIA, France

thomas.degueule@inria.fr

Benoit CombemaleINRIA, France

benoit.combemale@inria.fr

Arnaud BlouinINSA Rennes, Francearnaud.blouin@irisa.fr

Olivier BaraisUniversity of Rennes 1, France

olivier.barais@irisa.fr

Jean-Marc JézéquelUniversity of Rennes 1, France

jezequel@irisa.fr

AbstractDomain-Specific Languages (DSLs) are now developed fora wide variety of domains to address specific concerns inthe development of complex systems. When engineering newDSLs, it is likely that previous efforts spent on the develop-ment of other languages could be leveraged, especially whentheir domains overlap. However, legacy DSLs may not fitexactly the end user requirements and thus require furtherextension, restriction, or specialization. While current lan-guage workbenches provide import mechanisms, they usuallylack an explicit support for such customizations of importedartifacts. In this paper, we propose an approach for buildingDSLs by safely assembling and customizing legacy DSLsartifacts. This approach is based on typing relations that pro-vide a reasoning layer for manipulating DSLs while ensuringtype safety. On top of this reasoning layer, we provide an al-gebra of operators for extending, restricting, and assemblingseparate DSL artifacts. We implemented the typing relationsand algebra into the Melange meta-language. We illustrateMelange through the modular definition of an executablemodeling language for the Internet Of Things domain. Weshow how it eases the definition of new DSLs by maximizingthe reuse of legacy artifacts without introducing issues interms of performance, technical ecosystem compatibility, orgenerated code volume.

Categories and Subject Descriptors D.3.2 [LanguageClassifications]: Specialized application languages

Keywords Domain-specific languages, language reuse, lan-guage composition, model typing, melange

1. IntroductionExtending the time-honored practice of separation of con-cerns, Domain-Specific Languages (DSLs) are increasinglyused to handle different, complex concerns in software-intensive system development. However, the definition ofa DSL and the associated tools (i.e. checkers, simulators,generators) require significant development efforts for, bydefinition, a limited audience and a DSL that is doomed toevolve as the concepts in the domain and the expert under-standing of the domain evolve.

Despite the wide range of domains in which DSLs are usedand their constant evolution, many of them are close and sharecommonalities such as a particular action language or a com-mon paradigm (e.g. the family of DSLs for statecharts [6]).Recent work in the community of Software Language Engi-neering focused on language workbenches that support themodular design of DSLs, and the possible reuse of such mod-ules (usually using a scattered clause import linking separateartifacts) [26, 43]. Besides, particular composition operatorshave been proposed for unifying or extending existing lan-guages [33]. However, while most of the approaches proposeeither a diffuse way to reuse language modules, or to reuseas is complete languages, there is still little support for easilyassembling language modules with customization facilities(e.g. restriction) in order to finely tune the resulting DSLaccording to the language designer’s requirements.

In this paper, we present Melange, a tool-supported meta-language in which legacy DSLs are assembled and cus-tomized to produce new ones. Melange provides specificconstructs to assemble various abstract syntax and operationalsemantics artifacts into a DSL. DSLs can then be used as first-class entities to be reused, extended, restricted or adaptedinto other DSLs. Melange relies on typing relations that stati-cally ensure the structural correctness of the produced DSLs,and subtyping relations between DSLs to reason about theirsubstitutability. Newly produced DSLs are correct by con-struction, ready for production (i.e. the result can be deployedand used as is), and reusable in a new assembly.

We illustrate the benefits of the proposed language opera-tors and type system by designing a new executable modelinglanguage for the Internet Of Things domain. We show howthe proposed approach eases the definition of new DSLs bymaximizing the reuse of legacy artifacts without introducingissues in terms of performance, technical ecosystem compati-bility, or generated code volume.

The remainder of this paper is organized as follows. Sec-tion 2 gives an overview of the approach, further detailed withthe algebra for DSL assembly and customization (Section 3)and its support in the dedicated meta-language Melange (Sec-tion 4). Then we illustrate our approach with a significant casestudy in Section 5. Finally, Section 6 discusses related work,and Section 7 concludes and discusses several perspectivesof our work.

2. Approach OverviewDomain-specific languages are typically defined throughthree main concerns: abstract syntax, concrete syntax(es) andsemantics. Various approaches may be employed to specifyeach of them, usually using dedicated meta-languages [44].The abstract syntax specifies the domain concepts and theirrelations and is defined by a metamodel or a grammar. Thischoice often depends on the language designer’s backgroundand culture. Examples of meta-languages for specifying theabstract syntax of a DSL include EMOF [1] and SDF [19].The semantics of a DSL can be defined using various ap-proaches including axiomatic semantics, denotational seman-tics, operational semantics, and their variants [36]. Concretesyntaxes are usually specified as a mapping from the abstractsyntax to textual or graphical representations, e.g. throughthe definition of a parser or a projectional editor [46]. Inthis paper, we focus on DSLs whose abstract syntaxes aredefined with metamodels and whose semantics are definedin an operational way through the definition of computa-tional steps designed following the interpreter pattern [17].Computational steps may be defined in different ways, e.g.using aspect-oriented modeling [23] or endogenous transfor-mations [5]. In this paper, however, we only focus on theweaving of computational steps in an object-oriented (OO)fashion with the interpreter pattern. In such a case, speci-fying the operational semantics of a DSL involves the useof an action language to define methods that are staticallyintroduced directly in the concepts of its abstract syntax [24].It is worth noting that the proposed approach can easily beadapted to other kinds of operational semantics specificationmechanisms, such as endogenous transformations in a func-tional way. We do not address in this paper the problem ofconcrete syntax composition and customization.

Figure 1 gives a high-level overview of our approach.On the right side are legacy language artifacts that mustbe reused and assembled to build new DSLs. Importedartifacts include abstract syntax and semantics, possiblywith their corresponding tools and services (e.g. checkers,

MM1

MM2

Sem1

Sem2

L2

L4

L1

L3

«inherit»

«mergeL»

«weave»

«slice»

Metamodel

Semantics

Language

Tooling

Model Type

Binding

«mergeS»

«mergeS»

«weave»

Legacy ArtifactsAssembled DSLs

MT1 MT2

MTi

«impl» «impl»

Figure 1: DSLs Assembly and Customization

or transformations). These tools consist in manipulatingmodels conforming to a particular metamodel. Similarly,semantic definitions directly access and manipulate modelelements for execution or compilation purposes. Hence,abstract syntax and semantics are related one another throughbinding relations: semantics artifacts require a particularshape of abstract syntax, which is provided by a givenmetamodel. On the left side of Figure 1 are the newly builtlanguages. Assembly operators (mergeS , weave) realize thetransition from legacy artifacts to new DSLs. They importand connect disparate language artifacts, e.g. by mergingdifferent abstract syntaxes or by binding a given semanticsto a new syntax. Naturally, the same artifacts can be reusedin different assemblies. The output of assembly operators isencapsulated in a language definition. Once new assembliesare created, customization operators (slice, mergeL, inherits)offer the possibility to refine the newly built DSLs so as tomeet additional requirements or to fit a specialized context.Both assembly and customization operators are captured inan algebra (cf. Section 3).

Assembling and customizing DSLs is a complex task thatrequires checking the composability of heterogeneous partsand the validity of the result. For example, based on Figure 1,it is clear that Sem1 can be woven on L4 only if it can bebound to its syntax MM2. Similarly, the intuitive meaningof inheritance, as found in most OO languages, implies thecompatibility between the super- and sub- elements. It followsthat the compatibility between L1 and L3 in Figure 1 mustbe ensured to guarantee that L1’s tooling can be reusedfor L3. What is missing here to guarantee these propertiesis an abstraction layer that would support reasoning aboutthe compatibility between different languages artifacts. Inour approach, we rely on the notion of model typing asintroduced by Steel et al. [42] and further refined by Guy etal. [18]. Model types are structural interfaces over the abstractsyntax of a language, defined by a metamodel. As such,they also take the form of a metamodel. They are linkedone another by subtyping relations that specify if a model

Model Type Language

SemanticsMetamodel

«impl»

«composedOf»

«subtypeOf»«inherit»

«slice»«merge»

«depends»

Figure 2: Model Typing Relations

conforming to a given metamodel can be manipulated throughanother metamodel. Several metamodels may implement thesame model type, meaning that transformations and toolsdefined over a model type can be reused for all matchingmetamodels. Moreover, model typing allows to reason aboutthe compatibility between different metamodels.

We further extend the concept of model typing by explic-itly separating implementations of languages (i.e. abstractsyntax, semantics, and tools) from their structural interfaces(i.e. model types exposing part of their features) as canonicalrepresentation of languages. As depicted in Figure 2, each lan-guage has at least one model type that captures its structuralinterface. Then, the associated type system enables reasoningabout compatibility between different artifacts, e.g. to checkwhether a given semantics can be applied on a given abstractsyntax, or to ensure that within an inheritance relation thesub-language remains compatible with the super-language.

3. An Algebra for DSL Assembly andCustomization

In this section, we introduce an abstract algebraic specifi-cation of operators for language assembly and customiza-tion. This specification is mainly intended to serve as a refer-ence for the implementation of a concrete meta-language thatwould support the aforementioned approach. We first providethe definitions and concepts required to define the algebra(Section 3.1). Then, we introduce the operators for languageassembly (Section 3.2) and customization (Section 3.3).

3.1 Language DefinitionBased on the informal conceptual model of Section 2, wedefine a language L as a 3-tuple of its abstract syntax,semantics, and exact model type:

L , 〈AS, Sem,MT 〉

Including the exact model type of a language into thetuple allows to directly specify the impact of each of theoperators of the algebra on the typing layer. As explained inSection 3.1.3, model types also indirectly support the reuseof languages tooling. In the following, for any language L,we denote AS(L) its abstract syntax, Sem(L) its semantics,and MT (L) its exact model type. On non-ambiguous cases,we simply refer to them as AS, Sem, and MT . The nextsub-sections detail each of them.

Aa1 : Int

B C

F G

D

E

g

0..1

d

1

e0..1

e1

a0..1

MM1

op(Int)

(a) Receiving Metamodel

Aa1 : Double

Dd

*

MM2

H

i1

I

op(String)

(b) Merged Metamodel

Aa1 : Double

B C

F G

D

E

g

0..1

d

*

e0..1

e1

a0..1

MM1

H

i1

I

op(Int)op(String)

(c) Resulting Metamodel

Figure 3: Syntax Merging Operator

3.1.1 Syntax and Syntax MergingIn our algebra, the abstract syntax AS of a language L isspecified using a metamodel, i.e. a multigraph of classes andtheir relations. When assembling several abstract syntaxes,their concepts must be merged together so that the resultingabstract syntax is no less capable than its ancestors. Infor-mally, this means that the abstract syntax resulting from themerge must incorporate concepts from all languages andmerge the definitions of shared elements. In our specific case,merging several abstract syntaxes boils down to the prob-lem of metamodel composition [10]. Figure 3 illustrates thesyntax merging operator on a simple example. We use theterms receiving metamodel, merged metamodel, and resultingmetamodel to refer to the three metamodels involved in themerging operation. Similarly, the terms receiving languageand resulting language will be used throughout this section.

Depending on the meta-language used for defining meta-models, different merging operators may be employed withdifferent policies for matching and merging rules, conflictsmanagement, etc.. The choice of the concrete semantics ofthe syntax merging operator is left to the implementer ofthe algebra, and a concrete implementation is described inSection 4.3. In the remainder of this section, we denote ◦ theabstract syntax merging operator.

3.1.2 Semantics and Semantics MergingThe semantics Sem of a language L is defined by a sequenceof aspect definitionsAt

i, whereA is a class, t is a pointcut andi is the index of A in the sequence. In this case, the pointcutt specifies the concept of the language’s abstract syntax (ameta-class) on which the aspect must be ultimately woven.

The advice is the class A itself, consisting of attributes andmethods. When a joinpoint is found, i.e. when a matchingconcept is found in the language, elements of the advice areinserted in the target meta-class. Since aspects are definedusing classes in an OO manner, they may inherit from eachother. To cope with possible specialization and redefinitionof methods, aspects are ordered by hierarchy in a sequence:

Sem(L) , (Ati ∈ Aspects) where

∀Ati ∈ Sem(L),∃c ∈ AS(L) : c match t

∀Ati, A

tj ∈ Sem(L) : At

i CAtj =⇒ i > j

where match denotes the joinpoint matching relation andC denotes the class inheritance operator. For a language tobe well-formed, each of its aspects must have a matchingmeta-class in its abstract syntax; this is what the first propertyensures. Ordering the aspects that compose a semantics in asequence lets the choice of linearization and/or disambigua-tion opened to the implementer when several aspects are inconflicts (e.g. insert the same method on the same target t).The merging of two semantics, denoted Sem • Sem′, con-sists in producing a new semantics structure. As the definitionshows, merging two semantics is equivalent to concatenatingtheir sequences of aspects. As a result, this operator is notcommutative and any redefinition of an aspect or method inSem′ overrides the previous definition in Sem:

Sem • Sem′ ≡ Sem _ Sem′

where _ denotes the sequence concatenation operator. Wealso denote sig the signature of an aspect A. The signatureof an aspect is a metamodel that exposes all the features(i.e. properties and methods) defined in an aspect and itsdependencies, omitting the concrete method bodies. Thesignature of a semantic specification Sem is thus definedas the structural merge (through ◦) of the signature of theaspects that compose it:

sig(Sem) ,◦⋃

Ati∈Sem

sig(Ati)

3.1.3 Model TypingEach languageL has one exact model typeMT . Like abstractsyntaxes, model types are described with a metamodel. Theexact model type of a language is its most precise structuralinterface, i.e. the model type that exposes all its features. Thus,the exact model type of a language exposes both its conceptsand their relations (i.e. its metamodel) and the signature of itssemantics (newly inserted features and methods). Hence, theexact type MT of a language L is defined as the structuralmerge of its abstract syntax and the signature of its semantics:

MT (L) , AS(L) ◦ sig(Sem(L))

Any change in either the abstract syntax or the signature ofthe semantics of a language will result in a different type. The

issue of tooling is indirectly addressed through the reasoningcapabilities provided by the model typing layer: if the resultof the application of operators leads to a language L whosemodel type MT is a subtype of the model type MT ′ ofanother language L′, then tools defined for L′ can be reusedas is for L. In the following, we denote <: the subtypingrelation between model types.

3.2 Operators for Language Assembly3.2.1 Syntax MergingWhen building new languages, it is likely that previouslydefined language abstract syntax fragments may be reusedas is. For instance, the syntactic constructs of a simpleaction language (e.g. with expressions, object manipulation,basic I/O) may be shared by any language encompassingthe expression of queries or actions. This first scenario oflanguage assembly thus consists in importing a fragment ofabstract syntax from another language to reuse its definition.In such a case, the language resulting from the merge ofthe receiving language and the merged abstract syntax mustincorporate all the concepts of both, while preserving thesemantics of the receiving language. Also, its model typemust be updated accordingly to incorporate the new syntacticconstructs. Hence, we specify the merging of an abstractsyntax into a language, denoted m←−, as follows:

L m←− AS′ = 〈AS ◦AS′, Sem,MT ◦AS′〉

In most cases, the resulting model type MT ′ = MT ◦AS′is a subtype of both AS′ and MT since it incorporatesthe features of both. It is however worth noting that newelements introduced in a model type with the ◦ operator maybreak the compatibility with the super model type in somecases (e.g. the introduction of a new mandatory feature [18]).In the former case, when the compatibility can be ensuredthrough subtyping, tooling defined over AS′ and/or L (e.g.transformations, checkers) can be reused as is on the resultinglanguage.

3.2.2 Semantics WeavingAnother scenario of language assembly consists in importingpredefined semantics elements in a language. When differentlanguages share some close abstract syntax, such as differentflavors of an action language, their semantics are likely to besimilar, at least for the common subparts (e.g. the semanticsof integer addition is likely to remain unchanged). Whenthe case arises, one would like to import the semanticsdefinition of addition from one action language to another. Wedenote w←− the semantics weaving operator, which consistsin weaving a semantics Sem′ on a language L. In such acase, the two semantics are merged and the exact type of Lis updated to incorporate the syntactic signature of the newsemantics:

L w←− Sem′ = 〈AS, Sem • Sem′,MT ◦ sig(Sem′)〉

Following the previous definitions, this operator can be suc-cessfully applied only if there is a matching meta-class inAS for each aspect in Sem′. Since the two semantics areconcatenated, Sem′ may override any previous definition ofSem, meaning that the semantics merge operator may be em-ployed either to augment or to override part of the semanticsof the receiving language L. The semantics weaving operatoris thus particularly relevant for incrementally implementingsemantic variation points [4].

3.3 Operators for Language CustomizationIn the previous subsection, we specified how the syntax merg-ing and semantics weaving operators help to build new lan-guages by assembling predefined fragments of abstract syn-tax and semantics. However, although the reuse of languageartifacts significantly decreases the development costs, the re-sulting languages may not fit exactly the language designer’sexpectations. Thus, we introduce in this section an algebrafor language customization. Customization may include spe-cialization of the abstract syntax or semantics of a languagefor a given context, restriction to a subset of its scope orcomposition with (possibly part of) other language defini-tions. In a recent paper, Erdweg et al. propose a taxonomyof different composition operators between languages, in-cluding language extension, restriction, and unification [11].The operators of our algebra closely match their taxonomy:the inheritance operator is similar to language extension, theslicing operator is similar to language restriction, and themerging operator is similar to language unification.

3.3.1 Language MergingSituations arise where two independent languages must becomposed to form a more powerful one. For instance, afinite-state machine language may be defined as a basiclanguage of states and labeled transitions combined to anaction language for expressing complex guards and actions.The resulting language may in turn be merged with a languagefor expressing classifiers where the state machines woulddescribe their behavior. To support this kind of scenario, weintroduce the language merging operator, denoted ]. Theoutput of this operator is a new language that incorporatesboth the syntactic and semantic definitions of its two operands.In this case, the receiving language is augmented with themerged language to produce the resulting language. Since themerged language can override part of the semantics of thereceiving language, order matters and commutativity can notbe ensured.

L ] L′ = 〈AS ◦AS′, Sem • Sem′,MT ◦MT ′〉

3.3.2 Language InheritanceIn essence, the language inheritance operator is similar to thelanguage merging operator, as both aims to combine the defi-nitions of two languages. The language inheritance operator,denoted ⊕, differs from the language merging operator in

that it does not consider the two languages on equal terms: asub-language inherits from a super-language. Moreover, thelanguage inheritance operator ensures that the sub-languageremains compatible with its super-language. Whatever thesubsequent operators applied to the sub-language, it mustremain compatible with the super-language, otherwise anerror is reported. Concretely, it means that the exact modeltype of the sub-language must remain a subtype of the exactmodel type of the super-language: the MT<:MT ′ propertyis conservative, meaning that any operators apply on L mustnot violate it. In a sense, the language inheritance operatorsupports a form of language design-by-contract, as the lan-guage designer is assured that tools defined over L′ will bereused untouched on L.

L ⊕ L′ = 〈AS ◦AS′, Sem′ • Sem,MT ′′〉 where

MT ′′ = MT ◦MT ′ and

MT ′′<:MT ′

Note that in this case, the semantics Sem and Sem′ areconcatenated in reverse order Sem′•Sem. The sub-languagefirst inherits the abstract syntax and semantics of its super-language, and may then override part of the inherited artifactsto refine its definition further.

3.3.3 Language SlicingModel slicing [3, 41] is a model comprehension techniqueinspired by program slicing [48]. The process of modelslicing involves extracting from an input model a subset ofmodel elements that represent a model slice. Slicing criteriaare model elements from the input model that provide entrypoints for producing a model slice. The slicing process startsby slicing the input model from model elements given asinput (the slicing criteria). Then, each model element linked(e.g. by inheritance or reference) to a slicing criterion issliced, and so on until no more model elements can be sliced.For instance, model slicing can be used to extract the staticmetamodel footprint MM ′ of a model operation definedover a metamodel MM , i.e. extracting the elements of MMused by the operation [22]. Model slicing can be positive ornegative. Positive model slicing consists of slicing modelsaccording to structural criteria. These criteria are the requiredmodel elements from which the slice is built. For instance,based on the simple metamodels of Figure 3, one may wantto slice the MM1 metamodel using as slicing criterion thereference a of the class A. This slicing consists of staticallyextracting all the elements of MM1 in relation with a (aincluded). The result of this slicing is depicted by Figure 4a:the class A that contains a is sliced; the super class of A(F ) is sliced; the A’s references with a lower cardinalitygreater than 0 are sliced (only the mandatory references andattributes are sliced); the target classes of these references(e.g. D) are sliced. This slicing process continues recursivelyuntil no more elements can be sliced. We extended the modelslicing principles proposed by Blouin et al. [3] to support

Aa1 : Int

F

D

E

d

1

e1

a0..1

MM1

op(Int)

(a) Positive slicing on MM1

with A.a as input

F G

E

g

0..1

MM1

(b) Negative slicing on MM1

with D as input

Figure 4: Slice Examples

negative slicing. Negative slicing consists of considering theslicing criteria as model elements not to have in the slice.For instance, a negative slicing of MM1 with the class Das slicing criterion produces the slice depicted by Figure 4b:a clone, that will be the output slice, of MM1 is created;The class D is removed from this clone; all the classes thathave a mandatory reference to D are removed (class A);subclasses of the removed classes are also removed (classesB and C). This slicing process continues recursively until nomore elements can be removed.

Model slicing can be used to perform language restriction.For instance, a language designer may want to shrink a legacymetamodel to its sub-set used by a set of model operations ofinterest [22]. This consists of a positive slicing from a set ofoperations. A language designer may also want to restrict thefeatures of a language (e.g. removing specific features of aprogramming language) for education purposes or to reduceits expressiveness [11]. This consists of a negative slicingfrom unwanted elements.

In the context of language engineering, we leverage theslicing operation to permit language designer to slice a lan-guage according to some slicing criteria, as formalized asfollows. Given a language L1 , (AS1, Sem1,MT1). Slic-ing L1 using slicing criteria c consists of slicing positively ornegatively (resp. denoted Λ+ and Λ−, or Λ+

− when consider-ing both operators) its abstract syntaxAS1 using c to producea new abstract syntax AS2, such that AS2 ⊆ AS1. Then, theaspects At

i, that compose Sem1, that only refer to elementsdefined in AS2 are extracted to form Sem2, as formalized asfollows:

Λ+−(L1, c) = 〈AS2, Sem2,MT2〉, where:

AS2 , λ+−(AS1, c), AS2 ⊆ AS1,

Sem2 ,{At

i ∈ Sem1, fp(Ati, AS1) ⊆ AS2

},

MT1<:MT2,

The footprint operation (denoted fp) extracts the meta-model elements of AS1 used in the aspects a. The choice ofapplying a positive (Λ+) or negative (Λ−) slicing is made by

the language designer during the language design accordingto her requirements. The abstract syntax slicing operation [3](denoted λ+, λ−, or λ+−) slices a given abstract syntax AS1

according to slicing criteria c to produce an output abstractsyntax AS2. Because of the strict slicing that extracts meta-model elements by assuring the conformance, the model typeMT1 is a sub-type of the output MT2.

4. Melange: A Meta-Language for DSLAssembly and Customization

Melange1 is an open-source meta-language and frameworkfor DSL engineering. Instead of providing its own dedicatedmeta-languages for the specification of each part of a DSL(abstract syntax, type system, semantics, etc.), Melange relieson other independently-developed components to providesuch features. The abstract syntax of DSLs is specified usingthe Ecore implementation of the EMOF standard providedby the Eclipse Modeling Framework (EMF)2. The choiceof Ecore is motivated by the success of EMF both in theindustry and academic areas. This allows Melange to possi-bly integrate a wide range of existing DSLs: over 300 Ecoremetamodels exists in the “metamodel zoo” [35], over 9000on Github. For semantics specification, Melange relies on theXtend programming language3 to express operational seman-tics with the definition of aspects. The algebra introduced inSection 3 has been implemented within Melange, providingfeatures for assembly and customization of legacy DSLs ar-tifacts. Overall, Melange is tightly integrated with the EMFecosystem. Newly built DSLs can thus benefit from otherEMF-based components such as Xtext [14] for defining theirtextual syntax or Sirius4 for their graphical representation.Melange is bundled as a set of Eclipse plug-ins.

In this section, we present the Melange meta-languagethrough its abstract syntax (Section 4.1), concrete syntax(Section 4.2), implementation choices (Section 4.3) andintegration with the EMF ecosystem (Section 4.4).

4.1 Abstract SyntaxThe abstract syntax of Melange (the metamodel depicted inFigure 5) includes the concepts and relations discussed inSection 2. This abstract syntax is supplemented with staticsemantics rules expressed as OCL constraints not presentedhere for the sake of conciseness. LanguagesSpec, the rootof Melange’s abstract syntax, defines a meta-program that(i) specifies an assembly of DSLs (ii) delimits the scope forthe inference and checking of model typing relations.

A Language is defined by its Metamodel and its associatedSemantics. A Metamodel is composed of a set of Classes.A Semantics consists of a set of Aspects used to weavebehavior into its meta-classes. This mechanism relies on1 http://melange-lang.org2 https://www.eclipse.org/modeling/emf/3 http://www.eclipse.org/xtend/4 https://eclipse.org/sirius/

Element

name : EString

Language

Transformation

Subtyping

elements

0..*

exactType1

implements

0..*

0..*

extracted0..1

input0..*

output0..1

subMT

1

superMT 10..*

implements0..*

ObjectType Class

ModelType

mmsotssubs

1Semantics Aspect

0..*

0..* Metamodel0..*classes

1

1

sem

tgt

src

Weaving

tgt1..*0..*ops

MergeSyn

LanguagesSpec

Operator

LgeOperator

Inheritance Slicing MergeLge

Figure 5: Excerpt of the Abstract Syntax of Melange

static introduction and is inspired by the concept of openclasses [24]. As specified in Section 3, both assembly andcustomization operators can be applied on languages. TheMergeSyn operator is used to import and merge a metamodelinto a given language, whereas the Weaving operator isused to weave a given aspect on the abstract syntax ofa language. For the customization part, a language caninherit (Inheritance operator) from a “super” language. TheMergeLge operator allows language designers to merge onelanguage into another one. Finally, the Slicing operatorpermits to slice a language given a specific slicing criterion.

A ModelType defines an interface to manipulate models. Itconsists of a set of ObjectTypes, thereby defining a group ofinterrelated types. Model types can be created from scratch,or automatically inferred from a concrete language. In thelatter case, the language explicitly references this new modeltype as its exactType. Model types are linked one another bysubtyping relations: if MT ′ is a subtype of MT , then thereis one and only one Subtyping instance that references MT ′

as its subType and MT as its superType.A Transformation defines a model transformation that

takes Elements as input and may produce an Element asoutput. This means that transformations can operate onMetamodels, ModelTypes, or Transformations themselves.

4.2 Concrete SyntaxMelange provides a textual editor that allows designersto import, manipulate, and reason about DSLs. For thesake of conciseness, we do not detail the whole grammarof the concrete syntax of Melange. Instead, we illustrateits typical use through the mere examples introduced inSection 3 to illustrate the proposed language operators. In asingle Melange file, multiple languages can be designed. Forinstance, the L1 and L2 languages are designed by importingrespectively the MM1.ecore and MM2.ecore metamodels(Lines 1 to 6). The L3 language (Lines 7 to 9) is equivalent tothe merging result depicted by Figure 3c. L3 inherits from L1,i.e. L3 reuses the abstract syntax MM1.ecore. This abstractsyntax is then merged with the L2 language to form L3(Line 8). The L4 language (Lines 10 to 12) is designed byperforming a positive slicing on the L1 using as input the

reference a of the class A. Similarly, L5 is designed (Lines 13to 15) by performing a negative slicing on L1 using as inputthe class D. Finally, L6 (Lines 16 to 18) inherits from L5. Theaspect ExecuteAspect is then woven into L6.

1 language L1 {2 syntax "MM1. e c o r e "3 }4 language L2 {5 syntax "MM2. e c o r e "6 }7 language L3 i n h e r i t s L1 {8 merge L29 }

10 language L4 {11 s l i c e + L1 us ing [MM1.A. a ]12 }13 language L5 {14 s l i c e − L1 us ing [MM1.D]15 }16 language L6 i n h e r i t s L5 {17 with E x e c u t a b l e A s p e c t18 }

Listing 1: Concrete Syntax of Melange

4.3 Implementation ChoicesThe algebra introduced in Section 3 can be implemented invarious ways. We report here on additional choices we madein its concrete implementation within Melange. The alge-bra does not require a particular formalism for expressingmetamodels. In our implementation, we rely on the Ecoreimplementation of the EMOF standard provided by EMFto specify the abstract syntax of DSLs. Different operatorsfor metamodel merging have been proposed in the literature(e.g. [10, 28]). Interestingly, the UML2.0 specification intro-duces the notion of PackageMerge that specifies “how thecontents of one package are extended by the contents of an-other package” [37]. Informally, the UML specification statesthat “a resulting element will not be any less capable thanit was prior to the merge”. Matching of elements of bothsides mostly occurs based on name equality. When a match isfound between two elements, the resulting package incorpo-rates both sides of its definition. We choose to use a slightlyimproved version of the PackageMerge operator as definedin the UML specification and refined by Dingel et al. [9]. Tomeet our requirements, we adapt the PackageMerge operatorby trading its UML specificities with EMOF specificities,while preserving its general spirit. For example, we do notconsider the concept of Profile and adapt the concept of UMLAssociation to the concept of EMOF Reference. The Pack-ageMerge operator specifies a set of constraints that must beensured for the merge to succeed. If one of the constraintsis violated, the merge is ill-formed and an error is reported.It follows that operators of the algebra that relies on the ab-stract syntax merging operator share the same property: ifthe constraints are violated the operation is invalid and anerror is reported to the user, otherwise the result is guaranteedto be well-formed. On the semantics part, we choose to use

the Xtend programming language supplemented with anno-tations we developed to specify the operational semanticsof DSLs through the definition of aspects. Xtend compilesdirectly to Java code, providing a seamless integration withother artifacts generated using the EMF framework. A simpleexample of aspect used to weave executability in the Statemeta-class of a FSM language is given in Listing 2. The_self variable refers to the element on which the aspect isultimately woven (a State object in this case) and allows theaspect to access all its features (outgoingTransitions in thiscase). Here, the ExecutableState aspect inserts a step methodin the State meta-class to fire the appropriate transition givenan input character c. Note that aspects may also declare newattributes that are introduced in the target meta-classes.

1 @Aspect ( c lassName = fsm . S t a t e )2 c l a s s E x e c u t a b l e S t a t e {3 def void s t e p ( char c ) {4 v a l t = _ s e l f . o u t g o i n g T r a n s i t i o n s5 . f i n d F i r s t [ i n p u t == c ]6 i f ( t == n u l l ) throw new E x c e p t i o n7 e l s e t . f i r e8 }9 }

Listing 2: Weaving Executability with Aspects

The @Aspect annotation specifies the pointcut of theaspect, while the rest of the class definition defines its advice(new methods and attributes to be inserted). Since pointcutsand advices are not clearly separated, the process of re-binding a set of aspects to a new abstract syntax consistsin copying the aspects while updating their pointcuts to targetthe appropriate concepts of the new abstract syntax.

We also made the following choices in the priorities givento each operator. The inheritance operator has the highestpriority, followed by the merge and slice operator (in order ofappearance), ending with the aspect weaving operator. First,languages may inherit part of their definition from a super-language. As a consequence, the type system ensures thatthe sub-typing relation between the two languages is kept,otherwise an error is reported. Then, other artifacts may beassembled, merged or sliced on top of the inherited defini-tion. Finally, aspect weaving comes last to support both theredefinition of imported parts and the addition of “glue code”to make the different parts fit together. As an example, whentwo merged languages exhibit no common subparts, a newaspect can be woven to connect them in a meaningful way byadding structural references between their abstract syntax, orby inserting some additional code to make their respective in-terpreters cooperate, e.g. through context translation. Finally,for each language declaration, Melange infers its correspond-ing exact model type. The embedded model-oriented typesystem automatically infers the subtyping hierarchy throughstructural typing. This hierarchy is used to ensure the subtyp-ing relation when inheritance is involved and is displayed tothe user in a dedicated Eclipse view.

4.4 Compilation Scheme and Integration with EMFFrom a Melange program, such as the one depicted in List-ing 1, the Melange compiler first reads and imports the exter-nal definitions and assembles them according to the rules ofthe algebra. Once the new DSLs are assembled, customiza-tion operators are applied. Then, the compiler completes theresulting model by inferring the subtyping hierarchy amongthe model types inferred for each language. The implemen-tation relations between metamodels and model types arealso inferred in this phase, leading to a complete Melangemodel conforming to the metamodel of Figure 5. Then, itgenerates a set of artifacts for each declared language: (i) anEcore file describing its abstract syntax (ii) a set of aspects de-scribing its semantics attached to the concepts of its abstractsyntax (iii) an Ecore file describing its exact model type and(iv) an Eclipse plug-in that can be deployed as is in a newEclipse instance to support the creation and manipulation ofmodels conforming to it. To generate the runtime code forthe new artifacts, Melange relies on the EMF compiler (agenmodel generating Java code from an Ecore file), and theXtend compiler (generating Java code from the aspects file).For each language definition, the Java code generated by bothcompilers is associated to a plug-in. Since Melange reusethe formalism for language definition of EMF, along withits compilation chain, it is fully interoperable with the EMFecosystem. Newly created DSLs may thus benefit from othertools of the EMF ecosystem such as Xtext for the definitionof a textual editor or Sirius for a graphical representation.

5. Case StudyIn this section, we illustrate how the proposed algebra imple-mented within Melange can be used by language designersto assemble legacy DSLs. We then discuss the results, theintegration of the proposed operators in an existing languageworkbench, and the development overhead. All the materialsof the case study are available on the companion webpage5.

5.1 Language RequirementsTo illustrate Melange, we design an executable modelinglanguage for the Internet of Things (IoT) domain, i.e. forembedded and distributed systems. This language is inspiredby general-purpose executable modeling languages (e.g. Ex-ecutable UML [32] or fUML [40]) and IoT modeling lan-guages (e.g. ThingML [15]). This language enables the mod-eling of the behavior of communicating sensors built on top ofresource-constrained embedded systems, such as low-powersensor and micro-controller devices (Arduino6, RaspberryPi7, etc.). Such a language aims at providing appropriate ab-stractions and dedicated simulators, interpreters, or compilersdepending on the targeted platforms. To illustrate the ben-

5 http://melange-lang.org/sle156 http://www.arduino.cc/7 https://www.raspberrypi.org/

efits of Melange, the resulting language will be built as anassembly of other popular languages. We consider the threefollowing requirements while designing this language:

i) The language has to provide an IDL (Interface Defini-tion Language) to model the sensor interfaces in terms ofprovided services. Examples of popular languages that pro-vide the appropriate abstractions include the class diagram of(f)UML, the SysML block definition diagram [16], or MOF,as they all provide an OO interface definition language.

ii) The language must support the modeling of concurrentsensor activities. Various languages may be employed tomodel this concern. For instance, process modeling languagessuch as the (f)UML/SysML activity diagram or BPEL/BPMNare good candidates.

iii) The primitive actions that can be invoked within theactivities must be expressed with a popular language IoTdevelopers are familiar with. Such a language can be sharedby the community and embedded on a set of devices used inthe IoT domain. Even though the C language is the commonbase language of most embedded platforms, its lack ofabstraction hinders its exploitation in a modeling environment.Instead, we choose the Lua language8. Lua is a dynamically-typed language commonly used as an extension or scriptinglanguage. Lua is notably popular in the IoT domain since itis compact enough to fit on a variety of host platforms.

5.2 Language Design using MelangeWith the aim of validating Melange, the experimental proto-col consists in selecting three publicly-available implementa-tions of existing EMF-based languages to support these threerequirements. For the structural part, we use the Ecore lan-guage itself as an implementation of EMOF. EMOF providesstructural modeling capabilities similar to the UML class dia-gram. For the activity modeling part, we reuse materials fromthe Model Execution Case of the TTC’15 tool contest9. Thecase foresees the specification of the operational semanticsof a subset of the UML activity diagram language with trans-formation languages. For the action language part, we reusean existing implementation of the Lua language developedusing Xtext. We provide an operational semantics of the Lualanguage using Xtend and a set of active annotations.

The new language has to provide three perspectives: i)Capturing the services offered by IoT devices, ii) Definingthe behavior of these services through a model of an internalprocess describing the workflow of activities, and iii) Mod-eling activity implementations. Each activity can execute anaction defined using the Lua language. This action languageis extended to integrate a new primitive to send messagescontaining data. These messages are used to invoke serviceson other devices. The resulting language is built using theMelange assembly definition depicted in Listing 3. The def-inition is decomposed in multiple languages to ease the de-

8 http://www.lua.org/9 http://www.transformation-tool-contest.eu/

1 language A c t i v i t y L a n g {2 syntax " p l a t f o r m : / r e s o u r c e / A c t i v i t y . e c o r e "3 with O p e r a t i o n a l S e m a n t i c s A c t i v i t y A s p e c t4 }56 language LuaLang {7 syntax " p l a t f o r m : / r e s o u r c e / x t e x t / Lua . e c o r e "8 with org . k3 . l u a . O p e r a t i o n a l S e m a n t i c s A s p e c t9 }

1011 language EcoreLang {12 syntax " p l a t f o r m : / r e s o u r c e / Ecore . e c o r e "13 }1415 language A c t i v i t y S l i c e {16 s l i c e + A c t i v i t y L a n g us ing [ ’ OpaqueAct ion ’ ,17 ’ MergeNode ’ , ’ Dec is ionNode ’ , ’ I n i t i a l N o d e ’ ,18 ’ JoinNode ’ , ’ ForkNode ’ , ’ A c t i v i t y F i n a l N o d e ’ ]19 }2021 language A c t i v i t y E c o r e L a n g {22 merge A c t i v i t y S l i c e23 merge EcoreLang24 with f r . i n r i a . d i v e r s e . g l u e . E O p e r a t i o n A s p e c t25 }2627 language Act iv i t yELuaLang {28 merge A c t i v i t y E c o r e L a n g29 merge LuaLang30 with f r . i n r i a . d i v e r s e . g l u e . E x p r e s s i o n A s p e c t31 }3233 language LuaExtens ionLang {34 syntax " p l a t f o r m : / r e s o u r c e / LuaExt . e c o r e "35 with org . l u a e x t . O p e r a t i o n a l S e m a n t i c s A s p e c t36 }3738 language F i n a l L a n g i n h e r i t s Act iv i t yELuaLang {39 merge LuaExtens ionLang40 with f r . i n r i a . d i v e r s e . l u a . E x p r e s s i o n A s p e c t41 }

Listing 3: Assembling the IoT Language with Melange

scription of the process. In a real situation, this definition canbe shortened.

1. The abstract syntax of the three languages (the activitydiagram from TTC15, Lua, and Ecore) are imported intoMelange to form languages respectively called Activity-Lang, LuaLang, and EcoreLang (Lines 1 to 13).

2. To design the ActivitySlice language, ActivityLang issliced to preserve only the activity diagram part withoutthe action language concepts (Lines 15 to 19). To do so,we manually identified the classes of interest (Lines 16to 18).

3. ActivitySlice and EcoreLang are merged (Lines 21 to 25).The EOperationAspect then binds EOperation and Activ-ity (Line 24). This step creates a language ActivityEcore-Lang that enables the modeling of objects. Such objectscan be for example a temperature sensor in a specific room

instance with an operation getTemperature. The imple-mentations of the operations are defined through activitydiagram definitions.

4. ActivityEcoreLang and LuaLang are then merged to forma new language ActivityELuaLang (Lines 27 to 31). TheExpression classes from both languages are linked oneanother by a new aspect (Line 30).

5. The new language LuaExtensionLang is designed tosupplement Lua with message sending capabilities tosupport synchronization between several complex objects(Lines 33 to 36).

6. A new language FinalLang, which inherits from Activi-tyELuaLang, is then created (Lines 38 to 41). ActivityELu-aLang is merged with the LuaExtensionLang and providesa specific glue linking the ActivityELuaLang semanticswith the LuaExtension semantics.

Besides, each language is implicitly associated with itsautomatically-inferred exact model type. The type checkingalgorithm of Melange can thus infer the subtyping hierarchyamong the different languages. For instance, in this case,the resulting FinalLang language subtypes all the otherlanguages because it incorporates all their features [18].Consequently, tools and transformation defined on e.g. theEcore language can be reused to manipulate models createdwith the FinalLang language. In the end, we obtain a newexecutable modeling language for IoT resulting from thecomposition of three legacy languages for which reuse wasunforeseen. Additionally, most of the previously defined toolscan be reused as is.

5.2.1 DiscussionA critical point concerns the ability of Melange to be in-tegrated into an existing ecosystem. The integration usingMelange of three existing EMF languages allows a languagedesigner to obtain a new EMF language. If we do not considerthe imposed methodology for defining the language seman-tics (the use of the interpreter pattern [17]), no modificationof these languages was required to support that composition.This illustrates how Melange can be integrated into an exist-ing language workbench without any change in the legacyabstract syntaxes. All the Melange operators are used forthis case study. Although this does not guarantee that theseoperators are sufficient, it highlights that all of them are re-quired when a language designer needs to compose existinglanguages.

Another major point is the possible overhead in termof performance and lines of code that stem from the useof Melange. Compared to a top-down approach where theIoT language is built from scratch by an expert in languagedesign, we observe no additional concepts integrated into theabstract syntax definition. At the semantics level, glue code isinjected for the implicit conversion of the interpreter patterncontext resulting from the composition of the various contexts

stemming from various operational semantics. At runtime, noadditional cost in terms of performance were observed to theuse of the language resulting from the composition. Table 1sums up the results.

Table 1: Comparison of Melange and a Top-down Approachfor the IoT Language

Melange Top-downMetaclasses (#) 104 104LoC for the glue (#) 27 0Efficiency (sec) 30,0 25,9

Performance comparison is obtained by loading and exe-cuting a model with 10 objects that contains one operationwith a workflow with 1000 basic actions that do mainly 10numeric operations. The comparison was done on the samelaptop designed with an Intel i7 with 16Gb of memory, aLinux 64bit operating system and an Oracle Java 8 virtualmachine.

Nevertheless, these results may be moderated by the fol-lowing threats to validity. First, all the languages must bedesigned in the same technical ecosystem. Melange does notprovide any support for integrating heterogeneous languagesin terms of technical ecosystem. Second, Melange can notcompose any language semantics. The composition can bedone if and only if the semantics is operational and definedfollowing the interpreter pattern (e.g. through static introduc-tion or a visitor). Third, concepts with different names indifferent languages may represent the same concept. In sucha case, adaptation mechanisms are required to align thembefore composition. Melange provides a simple renamingmechanism that allows to rename concepts, but lacks a pow-erful mechanism for realizing complex adaptations. Finally,the same person implemented the language using Melangeand using a traditional top-down approach. This person isan expert in language design and modeling technologies. Be-sides, the top-down language design has been reviewed bythree experts in language design and is publicly available onthe companion webpage.

6. Related WorkA DSL allows developing software for a particular applicationdomain quickly and effectively, yielding programs that areeasy to understand, reason about, and maintain [21]. Theremay be, however, a significant overhead in creating the infras-tructure needed to support a DSL. Numerous works proposedto create reusable and composable language units to tacklethis issue. Methodologies have been proposed for buildingDSLs embedded within an existing, higher-order, and typedprogramming language [20]. Techniques have been then de-signed for building modular interpreters and tools for suchembedded DSLs. Different techniques have been studied foraddressing the challenge of language extension and compo-sition, such as projectional editing [45]. Spoofax, however,

relies on meta-languages for defining syntaxes and seman-tics, which are inherently modular and composable [47]. Al-though basic import mechanisms are supported, they usuallylack a powerful support for customization. More recently, anoverview of the support provided by language workbencheshas been provided [12]. In the grammar world, several tech-niques demonstrated the possibility to create language unitsusing attribute grammars [25, 34, 39]. MontiCore appliedmodularity concepts for designing new DSLs by extendingan existing one, or by composing other DSLs [29]. MontiCorereifies as a first-class object the concept of language inheri-tance to allow language feature reuse. Other works proposeto leverage concepts from the component-based softwareengineering community to modularly develop DSLs [43, 50].

In the MDE domain, several meta-tooling platforms pro-pose mechanisms for improving language design modularity.Ledeczi et al. propose to compose domain-specific designenvironments using MDE technologies [31]. Melusine [13],Xtext [14], or MPS [2] are frameworks supplemented withIDEs for building textual DSLs. In both the MDE and gram-mar domains, the increasing trend to create new DSLs, fromscratch or by adapting existing ones, causes the emergenceof families of DSLs. A family of DSLs is a set of DSLs shar-ing common aspects but specialized for a particular purpose.The emergence of a family of DSLs raises the need to reusecommon tools among a given family [27, 30] and the need tocreate language composable units. To ease the language unitcomposition, Steel et al. [42] and De Lara et al. [8] proposeto define a clear contract and a typing system that can be usedfor composing language units. De Lara et al. present the con-cept mechanism, along with model templates and mixin layersleveraged from generic programming to MDE [7]. Conceptsare close to model types [42] as they define the requirementsa metamodel must fulfill for its models to be processed by atransformation, under the form of a set of classes. Sánchez,Wimmer et al. go further than strict structural mapping by re-naming, mapping, and filtering metamodel elements [38, 49].Erdweg et al. proposed a taxonomy to ease the positioning ofapproach related to language composition [11]. According tothis classification, our algebra supports the language exten-sion, restriction, and unification operators. Additionally, wedo not consider that restriction is only a matter of additionalvalidation rules. Instead, we prune the language from theunwanted parts so that only the necessary concepts are kept.

7. Conclusion and Future WorkWhile current language workbenches provide import mecha-nisms, they usually lack an explicit support for customizationand safe composition of imported artifacts. This paper pro-poses an approach for building DSLs by safely assemblingand customizing legacy DSLs artifacts. We propose differentoperators for assembling (mergeS /weave), restricting (slice),extending (inherits), and merging (mergel) DSLs. The use oftyping and subtyping relations that provides a reasoning layer

for DSLs manipulation is also promoted. The approach isimplemented in Melange, an EMF-based meta-language. Weillustrate and discuss this work by designing a new executablemodeling language for IoT showing that: all the proposedoperators are relevant for designing a new language based onthe composition and the specialization of three legacy DSLs;the use of Melange does not introduce specific technical issuecompared to a traditional top-down approach.

In our future work, we will investigate to what extentMelange can be used to provide agile modeling for DSL users,i.e. the safe reuse of model transformations that can workacross several DSLs, and the specification of viewpoints.

AcknowledgmentsThis work is partially supported by the ANR INS ProjectGEMOC (ANR-12-INSE-0011), the ITEA2 Project MERgE,and the French LEOC Project Clarity.

References[1] MOF, 2.0 core final adopted specification, 2004.

[2] Language and IDE modularization and composition with MPS.In R. Lämmel, J. Saraiva, and J. Visser, editors, Proc. ofGTTSE’13, pages 383–430, 2013.

[3] A. Blouin, B. Combemale, B. Baudry, and O. Beaudoux.Kompren: Modeling and generating model slicers. Softwareand Systems Modeling (SoSyM), pages 1–17, 2012.

[4] F. Chauvel and J.-M. Jézéquel. Code generation from UMLmodels with semantic variation points. In Model DrivenEngineering Languages and Systems, pages 54–68. 2005.

[5] B. Combemale, X. Crégut, P.-L. Garoche, and X. Thirioux. Es-say on semantics definition in MDE-an instrumented approachfor model verification. J. of Sw, 4(9):943–958, 2009.

[6] M. L. Crane and J. Dingel. UML vs. classical vs. Rhapsodystatecharts: Not all models are created equal. In Model DrivenEngineering Languages and Systems, pages 97–112. 2005.

[7] J. De Lara and E. Guerra. Generic meta-modelling withconcepts, templates and mixin layers. In Proc. of MODELS’10,pages 16–30, 2010.

[8] J. de Lara, E. Guerra, and J. Sánchez-Cuadrado. Abstractingmodelling languages: A reutilization approach. In AdvancedInformation Systems Engineering, pages 127–143. 2012.

[9] J. Dingel, Z. Diskin, and A. Zito. Understanding and improvingUML package merge. SoSym, 7(4):443–467, 2008.

[10] M. Emerson and J. Sztipanovits. Techniques for metamodelcomposition. In OOPSLA Workshop on Domain SpecificModeling, pages 123–139, 2006.

[11] S. Erdweg, P. G. Giarrusso, and T. Rendel. Language com-position untangled. In Proc. of the Workshop on LanguageDescriptions, Tools, and Applications, page 7, 2012.

[12] S. Erdweg, T. van der Storm, M. Völter, M. Boersma,R. Bosman, W. R. Cook, A. Gerritsen, A. Hulshout, S. Kelly,A. Loh, et al. The state of the art in language workbenches. InSoftware language engineering, pages 197–217. 2013.

[13] J. Estublier, G. Vega, and A. Ionita. Composing domain-specific languages for wide-scope software engineering ap-plications. In Proc. of MODELS’05, pages 69–83, 2005.

[14] M. Eysholdt and H. Behrens. Xtext: Implement your languagefaster than the quick and dirty way. In Proc. of OOPSLA ’10Companion, pages 307–309, 2010.

[15] F. Fleurey, B. Morin, A. Solberg, and O. Barais. MDE to man-age communications with and between resource-constrainedsystems. In Proc. of MODELS’11, pages 349–363, 2011.

[16] S. Friedenthal, A. Moore, and R. Steiner. A practical guide toSysML: the systems modeling language. 2014.

[17] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. DesignPatterns: Elements of Reusable Object-Oriented Software.Addison-Wesley Professional, 1994.

[18] C. Guy, B. Combemale, S. Derrien, J. R. Steel, and J.-M.Jézéquel. On model subtyping. In Modelling Foundationsand Applications, pages 400–415. Springer, 2012.

[19] J. Heering, P. R. H. Hendriks, P. Klint, and J. Rekers. Thesyntax definition formalism sdf—reference manual—. ACMSigplan Notices, 24(11):43–75, 1989.

[20] P. Hudak. Modular domain specific languages and tools. InProceedings of Fifth International Conference on SoftwareReuse, pages 134–142. IEEE Computer Society, June 1998.

[21] J. Hutchinson, J. Whittle, M. Rouncefield, and S. Kristoffersen.Empirical assessment of MDE in industry. In Proc. of ICSE’11,pages 471–480. ACM, 2011.

[22] C. Jeanneret, M. Glinz, and B. Baudry. Estimating footprintsof model operations. In Proc. of ICSE’11, 2011.

[23] J.-M. Jézéquel. Model driven design and aspect weaving.Software & Systems Modeling, 7(2):209–218, 2008.

[24] J.-M. Jézéquel, B. Combemale, O. Barais, M. Monperrus, andF. Fouquet. Mashup of metalanguages and its implementationin the kermeta language workbench. Software & SystemsModeling, pages 1–16, 2013.

[25] U. Kastens and W. Waite. Modularity and reusability inattribute grammars. Acta Informatica, 31(7):601–627, 1994.

[26] L. C. Kats and E. Visser. The spoofax language workbench:rules for declarative specification of languages and IDEs. InACM sigplan notices, volume 45, pages 444–463, 2010.

[27] D. Kolovos, L. Rose, and N. Matragkas. A research roadmaptowards achieving scalability in model driven engineering. InBigMDE’13, 2013.

[28] D. S. Kolovos, R. F. Paige, and F. A. Polack. Merging modelswith the epsilon merging language (EML). In Model drivenengineering languages and systems, pages 215–229. 2006.

[29] H. Krahn, B. Rumpe, and S. Völkel. Monticore: a frameworkfor compositional development of domain specific languages.JSTT, 12(5):353–372, 2010.

[30] A. Kusel, J. Schönböck, M. Wimmer, G. Kappel, W. Rets-chitzegger, and W. Schwinger. Reuse in model-to-model trans-formation languages: are we there yet? SoSyM, pages 1–36,2013.

[31] A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nordstrom,J. Sprinkle, and G. Karsai. Composing domain-specific designenvironments. Computer, 34(11):44–51, Nov 2001.

[32] S. J. Mellor and M. Balcer. Executable UML: A Foundationfor Model-Driven Architectures. 2002.

[33] M. Mernik. An object-oriented approach to language composi-tions for software language engineering. Journal of Systemsand Software, 86(9):2451 – 2464, 2013.

[34] M. Mernik and V. Zumer. Reusability of formal specificationsin programming language description. In 8th Annual Workshopon Software Reuse, WISR8, pages 1–4, 1997.

[35] Metamodel Zoos. http://www.emn.fr/z-info/atlanmod/index.php/Zoos, last access: april 2015.

[36] P. D. Mosses. The varieties of programming language seman-tics and their uses. In Perspectives of System Informatics, pages165–190. Springer, 2001.

[37] Unified Modeling Language 2.0, Infrastructure. OMG, 2005.

[38] J. Sánchez Cuadrado, E. Guerra, and J. de Lara. Generic modeltransformations: Write once, reuse everywhere. In Proc. ofICMT’11, pages 62–77, 2011.

[39] J. a. Saraiva. Component-based programming for higher-orderattribute grammars. In Proc. of GPCE, pages 268–282, 2002.

[40] E. Seidewitz. UML with meaning: Executable modeling infoundational UML and the Alf action language. Ada Lett., 34(3):61–68, Oct. 2014.

[41] S. Sen, N. Moha, B. Baudry, and J.-M. Jézéquel. Meta-modelPruning. In Proc. of MODELS’09, 2009.

[42] J. Steel and J. M. Jézéquel. On model typing. SoSyM, 6(4):401–413, 2007.

[43] E. Vacchi and W. Cazzola. Neverlang: A framework for feature-oriented language development. Computer Languages, Systems& Structures, 2015.

[44] E. Visser, G. Wachsmuth, A. Tolmach, P. Neron, V. Vergu,A. Passalaqua, and G. Konat. A language designer’s work-bench: A one-stop-shop for implementation and verification oflanguage designs. In Proc. SPLASH, pages 95–111, 2014.

[45] M. Voelter. Language and IDE modularization, extension andcomposition with MPS. Generative and TransformationalTechniques in Software Engineering, 2011.

[46] M. Voelter, B. Kolb, and J. Warmer. Projecting a modularfuture. 2014.

[47] M. Völter and E. Visser. Language extension and composi-tion with language workbenches. In Proc. of the OOPSLAcompanion, pages 301–304. ACM, 2010.

[48] M. Weiser. Program slicing. In Proceedings of the 5thinternational conference on Software engineering, pages 439–449. IEEE Press, 1981.

[49] M. Wimmer, A. Kusel, W. Retschitzegger, J. Schönböck,W. Schwinger, J. Cuadrado, E. Guerra, and J. de Lara. Reusingmodel transformations across heterogeneous metamodels. InProc. of MPM’11, 2011.

[50] S. Živkovic and D. Karagiannis. Towards metamodelling-in-the-large: Interface-based composition for modular metamodeldevelopment. In Enterprise, Business-Process and InformationSystems Modeling, pages 413–428. Springer, 2015.