Challenges and Opportunities of Modularizing Textual

Domain-Speciﬁc Languages

Christoph Rieger, Martin Westerkamp and Herbert Kuchen

ERCIS, University of M

unster, M

unster, Germany

Keywords:

Domain-Speciﬁc Language, Modularization, Xtext, Language Composition.

Abstract:

Over time, domain-speciﬁc languages (DSL) tend to grow beyond the initial scope in order to provide new

features. In addition, many fundamental language concepts are reimplemented over and over again. This

raises questions regarding opportunities of DSL modularization for improving software quality and fostering

language reuse – similar to challenges traditional programming languages face but further complicated by

the surrounding editing infrastructure and model transformations. Mature frameworks for developing textual

DSLs such as Xtext provide a wealth of features but have only recently considered support for language com-

position. We therefore perform a case study on a large-scale DSL for model-driven development of mobile

applications called MD

, and review the current state of DSL composition techniques. Subsequently, chal-

lenges and advantages of modularizing MD

are discussed and generalized recommendations are provided.

1 INTRODUCTION

Domain-speciﬁc languages (DSL) have emerged for

various purposes (Mernik et al., 2005). Despite their

unique capabilities, shared fundamental concepts are

rarely reused but are re-implemented for every new

language. In the context of Model-Driven Software

Development (MDSD) which tries to automate the

process of software creation, this causes a frequent

re-implementation of similar functionality. In recent

years, modularization of DSLs has become a topic of

increasing interest in academia due to the expected

improvements on software quality (Pescador et al.,

2015; Cazzola and Vacchi, 2016). Tightly coupled to

the concepts of language evolution, the composition

of languages introduces a variety of opportunities re-

garding maintainability, reusability, and extensibility

(Cazzola and Poletti, 2010). For example, changes to

language features can be performed in isolation, re-

quiring one to update and rebuild only parts of the

language (Vacchi et al., 2014).

Whereas a variety of DSL development frame-

works have evolved in the past, support for lan-

guage composition varies in practice (Erdweg et al.,

2015). On the one hand, development frameworks

speciﬁcally tailored to language modularization of-

ten emerged from niche projects and lack features

such as sophisticated Integrated Development Envi-

ronment (IDE) support (Vacchi et al., 2014; Ekman

and Hedin, 2007). On the other hand, language work-

benches used in practice often provide a broad set

of features for developers and modellers but consider

DSL composition as a negligible feature.

For example, the mature Xtext framework is

widely used for developing textual DSLs and provides

seamless IDE integration. However, modularization

capabilities such as grammar inheritance are still lim-

ited. One objective of this work is to analyse capabili-

ties concerning language modularization in Xtext and

the resulting implications for DSL developers.

The analysis is based on a prototypical imple-

mentation of a modularized DSL. With Model-Driven

Mobile Development (MD

), Heitk

otter and Ma-

jchrzak (2013) presented a cross-platform develop-

ment approach to create data-driven business apps for

smartphones and tablets. MD

generates native apps

for multiple platforms, providing a native look and

feel, access to device sensors, and a high level of ab-

straction for modellers. Whereas the textual DSL fa-

cilitates modularization by utilizing the Model-View-

Controller (MVC) pattern (Ernsting et al., 2016) for

its models, the framework itself is not aligned with

this structure but implemented in a monolithic project.

In order to improve maintainability and extensibility,

an enhanced framework architecture is proposed for

with respect to its DSL design and tooling.

The contributions of this work are threefold.

Firstly, the paper reviews language modularization

Rieger, C., Westerkamp, M. and Kuchen, H.

Challenges and Opportunities of Modularizing Textual Domain-Speciﬁc Languages.

DOI: 10.5220/0006601903870395

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 387-395

ISBN: 978-989-758-283-7

387

approaches in the ﬁeld of external domain-speciﬁc

languages. Secondly, modularization capabilities and

limitations of the Xtext framework are further inves-

tigated, using a case study of the large-scale MD

DSL. Thirdly, we generalize the observed beneﬁts and

drawbacks and propose recommendations for modu-

larizing existing DSLs. The structure of this paper

follows these contributions. Based on related work

presented in Section 2 and general modularization

concepts in Section 3, Section 4 provides the case

study. The ﬁndings are then generalized and dis-

cussed in Section 5 before concluding in Section 6.

2 RELATED WORK

Introducing formal models as a higher level of ab-

straction permits domain experts to express their

requirements using semantics close to the notation

known within the domain, usually using either a tex-

tual or graphical syntax (V

olter, 2013).

External DSLs are independently developed lan-

guages and separate to any host-language, therefore

often providing a custom syntax speciﬁcally crafted

according to domain experts’ requirements (Fowler,

2005). Since they are independent, appropriate tools

such as linkers, parsers, compilers, or interpreters

need to be provided (V

olter, 2013). Internal DSLs are

encapsulated into a General Purpose Language (GPL)

and consequently use the same syntax. However, they

utilize only a subset of its features to create domain

abstractions (Fowler, 2005). Language Workbenches

offer a custom IDE, speciﬁcally designed to the de-

velopment and usage of DSLs. The IDE becomes an

integral part of model-processing, blurring the lines

between programming and modelling (Fowler, 2005).

In contrast to GPLs, DSLs are designed in line

with a (potentially changing) domain scope and soft-

ware systems need to cope with changes in their en-

vironment (Cazzola and Poletti, 2010). Moreover,

DSLs are often iteratively developed, e.g., when de-

ﬁciencies in the language design are exposed or a

DSL is intentionally designed to cover only the most

important domain concepts in the beginning, with

further components to be developed in the future

olter, 2013). Additional complexities arise when

downward compatibility to previous versions should

be provided through techniques such as deprecation

markers (V

olter, 2013).

Consequently, the attempt to enhance maintain-

ability during the ongoing evolution of a language is a

major driver for DSL modularization. Internal DSLs

use the extensibility of a host language, e.g., macros

in Lisp or metaprogramming in C++ . They, however,

lack DSL-speciﬁc tooling support as well as a cus-

tomizable syntax (Fowler, 2005). Therefore, we focus

on external DSLs as well as Language Workbenches

in the following.

In recent years, the implementation of modular ex-

ternal DSLs has become a subject of increasing re-

search interest (Ekman and Hedin, 2007; Krahn et al.,

2010; Cazzola and Vacchi, 2016). Subsequently, a

variety of development frameworks have been pre-

sented that support the creation of necessary tooling

such as parser generation, implementing generators,

and supplying IDE integration (Erdweg et al., 2015).

With Neverlang, Cazzola and Poletti have introduced

a language development framework that speciﬁcally

focuses on creating reusable DSLs (Cazzola and Po-

letti, 2010). In Neverlang, modularization is organ-

ised along two dimensions. Language features are

deﬁned individually in modules, containing the syn-

tax deﬁnition in Backus-Naur-Form (BNF) notation

and an arbitrary amount of so-called roles describing

the semantics (Vacchi et al., 2014). Whereas Nev-

erlang provides sophisticated modularization tech-

niques such as traits (Cazzola and Vacchi, 2016), it

does not provide IDE integration for generated DSLs,

hampering its adoption by domain experts.

A DSL development framework that supports the

entire MDSD process including language deﬁnition,

generator implementation, and IDE integration, is

MontiCore. The framework generates Eclipse plug-

ins for DSLs which support syntax highlighting, fold-

able code regions, and error messages. Flexible lan-

guage composition is enabled through interfaces and

multiple inheritance. MontiCore includes external

fragments at runtime so that modellers are capable of

utilizing arbitrary DSLs when modelling. While a va-

riety of template-engines are available for MontiCore,

the framework provides a native engine that facili-

tates agile development by introducing tags within the

source code which are implementable in later itera-

tions (Krahn et al., 2010). Although the framework is

under active development, no supporting community

has established yet, leaving its future maintenance un-

certain.

Being part of the Eclipse Modeling Project, the

Xtext

framework’s evolution and support is backed

by a comparably large community. It provides so-

phisticated tooling support such as IDE integration

but is not speciﬁcally tailored towards language com-

position (cf. Section 4). For code generation, Xtext

advocates Xtend

, a Java-like programming language

that additionally supplies developers with template

expressions to ease the implementation of generators.

Xtext – http://www.eclipse.org/Xtext/documentation/

Xtend – https://www.eclipse.org/xtend/

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

388

3 DSL MODULARIZATION

CONCEPTS

A large amount of design patterns for domain-speciﬁc

languages have been presented in literature (Spinellis,

2001; Krahn et al., 2010). As this work focuses on

modularizing external DSLs, six applicable modular-

ization techniques are visualized in Figure 1.

Language extension allows new features to be

added to an existing language (Spinellis, 2001). The

novel DSL inherits from the base language, includ-

ing its semantics and syntax. Being closely related to

object-oriented forms of inheritance, language exten-

sion is generally not limited to single inheritance, but

also allows obtaining features from multiple DSLs.

However, due to the threat of possible conﬂicts,

mainly single inheritance is used in practice (Ducasse

et al., 2006).

Mixins represent a special form of language ex-

tension. Unlike multiple inheritance, mixins are not

tied to a particular super class in the type hierar-

chy. Instead, a mixin provides a self-contained incre-

ment of functionality and speciﬁes its dependencies

(to classes or other mixins). Concepts deﬁned in a

mixin can therefore be used by multiple classes, thus

enabling a more ﬂexible class composition. During

language compilation, the type hierarchy is linearised

such that all language dependencies are resolved us-

ing single inheritance (Bracha and Cook, 1990).

Language specialization represents the counter-

part to language extension. Rather than extending a

DSL, unnecessary parts of a language are removed,

creating a novel DSL. It thereby comprises a subset

of the former language elements (Spinellis, 2001).

Pipeline Pattern. In contrast to language extension

and specialization, the language modules in this pat-

tern are on the same hierarchical level. Each language

handles a set of language elements and passes the rest

to the next one, so that a language’s output is the input

for the next language in the pipeline. Pipelining thus

encourages the separation of tasks and discourages

the use of too feature-rich languages (Mernik et al.,

2005).

Trait. Only recently, the use of traits has been pro-

posed for DSL composition (Cazzola and Vacchi,

2016). Similar to an interface with method imple-

mentations, a trait is a collection of methods and at-

tributes. Nonetheless, a trait is stateless by deﬁnition

and does not enforce an order of composition, en-

abling a more ﬂexible reuse across classes compared

to inheritance. In language composition, traits pro-

vide or extend language constructs, and conﬂicts are

explicitly disambiguated by the target language. In

contrast to mixins, a trait only provides reusable func-

Figure 1: Language modularization concepts.

tionality without affecting the type hierarchy and re-

spective semantic implications (Ducasse et al., 2006).

Aspect. Similar to traits, aspects provide compos-

able units of functionality which are independent of

their order and enable a ﬂexible architecture design.

However, in contrast to traits, aspects are not invoked

within the target class, but an aspect itself declares

pointcuts, i.e., the set of events during program ex-

ecution for which the aspect’s action should be exe-

cuted (Wand et al., 2004). This composition mecha-

nism requires a language processor, the so-called as-

pect weaver, which is used to resolve the composition

of components and aspects. With respect to language

composition, there are two general approaches to im-

plement aspects. Firstly, aspects can be deﬁned in cor-

respondence with generated GPL code as long as an

aspect weaver for the target language exists. More-

over, the developer needs detailed knowledge about

the generator to deﬁne pointcuts. Secondly, deﬁning

aspects on a grammar-level provides the possibility to

declare pointcuts according to a DSL’s structure (Wu

et al., 2005). Yet, such an approach requires a trans-

formation engine which operates as aspect weaver.

Challenges and Opportunities of Modularizing Textual Domain-Speciﬁc Languages

389

4 MODULARIZATION IN Xtext

In this section, we present a case study on a large

DSL called MD

in order to demonstrate the practical

implications of current modularization capabilities of

DSLs created using the language workbench Xtext.

4.1 Modularization Concepts in Xtext

Whereas a large variety of modularization concepts

exists for DSLs in general (cf. Section 3), Xtext’s sup-

port for language extension is limited. As depicted in

Listing 1, grammars can extend other grammars using

the with keyword (line 1). The inheriting grammar

may extend existing language concepts, replace rule

deﬁnitions, or introduce new ones. However, Xtext

only supports single inheritance.

1 gra m m a r de . m d2 . V iew with d e . md2 . Md 2B a s i c s

2 im p o r t " h t tp :/ / md2 . d e / M o d el " as mo d el

4 Opt i o n I n p u t : ' O p t i on' n a me = ID

5 widge t I n f o

6 ' opt i o n s ' values = [ mo d e l :: E n um ]

7 fragment w i d g e t I n f o :

8 ' l a b e l ' la b el T e x t = S TRING

9 ' too l t i p ' t o o l t i pT e x t = S T R I N G

Listing 1: Language inheritance and grammar mixins.

In addition, Xtext provides a feature called gram-

mar mixins. In contrast to the modularization con-

cept with the same name presented in the previous

section, any metamodel can be used as Xtext mixin

using the import keyword (line 2). When importing

a metamodel, elements may then be referenced across

models. However, Xtext does not actually employ the

referenced grammar, but its metamodel. Therefore,

it is not possible to directly access rules from these

referenced grammars. Consequently, its syntax is not

available within the importing DSL to deﬁne new ele-

ments of the imported class in the including language.

For example, a modeller adding an OptionInput el-

ement can reference a list of values provided in a dis-

tinct model ﬁle (according to line 6) but cannot create

an Enum object directly in the View model.

Finally, the concept of fragments is another instru-

ment for enhanced reusability which has been added

recently

. Instead of repetitively declaring a similar

syntax in multiple parser rules, common parts can be

extracted into a fragment and integrated by multiple

rules. For example, the fragment widgetInfo (line 7)

speciﬁes the syntax of two attributes and is included

in the OptionInput rule (line 5). Although this con-

cept introduces multiple inheritance on the level of

http://zarnekow.blogspot.de/2015/10/the-xtext-

grammar-learned-new-tricks.html

model elements, it is only available within a single

grammar and cannot be used across languages.

4.2 Case Study on MD

Cross-platform development frameworks aim to mit-

igate the redundancy of developing applications for

multiple platforms. However, hybrid apps based on

web technologies lack a native look & feel and do

not provide an additional level of abstraction beyond

a common Application Programming Interface (API),

e.g., regarding platform-dependent design guidelines

(Heitk

otter et al., 2013). The Model-Driven Mo-

bile Development (MD

) framework abstracts from

the low-level implementation of business apps – i.e.

form-based, data-driven apps interacting with back-

end systems (Majchrzak et al., 2015) – and allows

for modelling the desired result in a platform-agnostic

fashion (Heitk

otter et al., 2013). From this model, the

framework currently generates native source code for

the Android and iOS platform as well as a Java-based

back-end application.

Models designed using the MD

DSL follow the

Model-View-Controller (MVC) pattern, extended by

an additional workﬂow layer (Ernsting et al., 2016).

Workﬂows can trigger workﬂow elements deﬁned in

the controller, while conversely the controller can ﬁre

a workﬂow’s events as illustrated in Figure 2.

Figure 2: Architecture of MD

models.

In contrast to the subdivided design of MD

models, the DSL itself is deﬁned in a single Xtext

grammar, roughly grouped into Model, View, Con-

troller, and Workﬂow components which reference

each other. However, some cases exist in which this

hierarchy is bypassed. For example, the AutoGener-

ator feature is used to automatically derive a generic

view representation from a given data structure. This

feedback between view layer and content provider

(located in the controller component) causes a circu-

lar dependency which needs to be considered while

restructuring the language.

The purpose of MD

’s modularization is there-

fore twofold. First and foremost, it should result in

a framework that provides enhanced maintainability

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

390

Figure 3: Proposed module structure for MD

models.

and increased software quality. Resulting from a se-

ries of modiﬁcations and extensions, the DSL was not

well structured and interrelations were hard to grasp

for developers due to the sheer size of the language.

Before modularizing, the Xtext ﬁle comprised 924

lines of code organized in 188 grammar rule deﬁni-

tions. This makes MD

one of the ﬁve largest Xtext-

based DSLs (in lines of code and ﬁle size) published

on Github. However, the initial structure contradicted

the MVC approach enforced in MD

models, and

DSL evolution was seriously hampered by this com-

plexity. For example, evaluations of the framework

have unveiled a lack of abstraction in the DSL’s View

layer (Vaupel et al., 2014) which could be tackled

more efﬁciently when dependencies to other compo-

nents of MD

are clear.

Second, MD

is tailored to the domain of data-

driven business apps (Heitk

otter et al., 2013). Future

users may wish to create DSLs tailored to their sub-

domains or even organisations. This can be achieved

by extending or specializing reusable modules. In ad-

dition, the creation of multiple (technical) sub-DSLs

can remedy current deﬁciencies and foster a more ag-

ile and targeted evolution of language features.

To achieve these aims, a clear separation of con-

cerns is mandated on DSL level and further compo-

nents dealing with code generation to trace concepts

along the processing chain, indicate dependencies,

and clarify interrelations. In order to focus this work

on the modularization of the DSL itself, the existing

generators were adapted to the new project structure

without formally subdividing them into submodules.

4.3 Modularizing MD

Complying with the structure of the MD

-DSL and

corresponding reference architecture (Ernsting et al.,

2016), the MVC+Workﬂow pattern is adopted to de-

compose the monolithic MD

grammar into four sub-

DSLs. In addition, a ﬁfth Basics DSL is introduced as

common infrastructure.

4.3.1 Inheritance-based Modularization

Each module is a domain-speciﬁc language on its own

but does not exist in isolation as visualized in Fig-

ure 3. The Model module only relies on Basics and

provides the MD

type system, rules for modelling

custom entity structures, and typed parameter deﬁni-

tions to be used by other modules. While the View

module depends on Model in order to reference data

types, the Controller relies on both Model and View

such that the modeller can deﬁne custom actions link-

ing data objects with the desired representation. The

Workﬂow module only depends on Controller, since it

builds workﬂow paths from low-level process steps.

Sophisticated modularization techniques such as

multiple inheritance are not available in Xtext. How-

ever, it permits reusing grammars to a certain extent

through single inheritance (see Section 4.1). In the-

ory, unidirectional dependencies between sub-DSLs

could be recompiled into a chain of DSLs only us-

ing single inheritance, similar to the concept of mix-

ins (see Section 3). Nevertheless, automation would

be required to build a (temporary) inheritance struc-

ture from the dependency graph each time any of the

modules changes, and adapt the IDE and generator

code accordingly. We therefore decided to avoid this

approach and interrelate multiple DSLs differently.

4.3.2 Interface-based Modularization

In contrast to single inheritance, more than one DSL

can be imported in Xtext. As explained in Section 4.1,

the ﬂexibility of importing multiple sub-DSLs comes

at the cost of modelling components in multiple ﬁles

according to the module in which the rules are lo-

cated, and reference the respective objects.

To achieve a coherent structure across multiple

DSLs, Voelter and Solomatov (2010) suggest the uti-

lization of interfaces. The modularized MD

DSL

creatively combines standard Xtext features to cre-

ate such extensible interfaces as depicted in Listings

Challenges and Opportunities of Modularizing Textual Domain-Speciﬁc Languages

391

1 gra m m a r de . m d2 . B a s i c s

3 MD2Model :

4 pac k a g e = P ac k a ge D e fi n it i o n &

5 mo d e l = L a n g u a ge E l em e n t ?;

6 La n g u a ge E l em e n t :

7 { L a n g ua g e El e m en t } ;

8 P a c k a ge D e fi n i ti o n :

9 ' pack a g e ' p k g N a m e = QU A L I F IE D _ N AM E ;

Listing 2: Basics grammar deﬁning interfaces.

1 gra m m a r de . m d2 . M o d el wi t h de . md 2 . Ba sics

2 im p o r t " h t tp :/ / md2 . d e / B a s i c s " as basi c s

4 MD2Model returns basi c s :: M D 2 M o d e l :

5 su p e r

6 mo d e l = Mo d e l ;

7 M o d e l r e t u r ns basics : : L a n gu a g eE l e me n t :

8 {Mod e l } mo d e l El e m en t s += M o d e l E le m e n t +;

Listing 3: Model grammar implementing interfaces.

2 and 3. Firstly, the concept of unassigned rule calls

(line 7 in Listing 2) forces the instantiation of rules.

As no further attributes are speciﬁed, the rule is effec-

tively transformed into an empty interface. Secondly,

the returns keyword inﬂuences the meta model by

explicitly merging the inferred class with the given

type. A common use case for this feature is the def-

inition of expressions such that the actual subtype is

transparent to referencing elements.

For example, the Model rule (line 7 in List-

ing 3) creates valid Basics::LanguageElement ob-

jects, effectively implementing the imported inter-

face. Thirdly, the super keyword (line 5 in Listing 3)

provides all contents of the inherited rule to the im-

plementing rule. Therefore, Basic::MD2Model’s at-

tributes are available in the corresponding rule of the

Model grammar and can be overwritten. Together, the

concept of interfaces is emulated in Xtext not only

within a single language but also across DSLs.

4.3.3 Modularizing Bidirectional Dependencies

Beyond the presented linear dependency structure, in-

tertwined components can also be extracted into sep-

arate sub-DSLs. As mentioned before, the AutoGen-

erator feature is such an example that provides a view

element but relies both on the Model and Controller

module. During the language generation process,

Xtext is not able to resolve bidirectional language ref-

erences. Extracting the problematic feature is possi-

ble by introducing a separate module that implements

a new LanguageElement subtype complying with the

aforementioned interface principles. The new struc-

ture as visualized in Figure 4 inevitably creates circu-

lar dependencies between those DSLs. However, the

metamodel of each DSL can be built independently

Figure 4: Resolving bidirectional dependencies.

by avoiding bidirectional dependencies. Using cross-

language references via imports, other grammars can

access the respective target normally and the resulting

cycle is resolved soundly by Xtext.

4.3.4 Domain Extension

Domain extension is a second type of extension to the

presented modular structure. The modularization of

, as described to this point, mainly provides ben-

eﬁts from a DSL developer’s perspective. The sepa-

rated modules retain clear responsibilities and depen-

dencies, easing future development of the framework.

Nevertheless, it could be extended to specialized do-

mains or applied to speciﬁc organizations which bring

along new requirements by adapting MD

to the tar-

get domain, thus achieving a variable scope of the lan-

guage (V

olter and Solomatov, 2010). Instead of cre-

ating new modules that inherit from the Basics gram-

mar, existing modules can be reused through inheri-

tance. For example, a newly introduced ViewAddon

module inherits from the View grammar to add a new

type of view element as depicted in Figure 5.

The add-on’s grammar needs to implement the

common root of MD

, i.e. MD2Model. Note that in

this case, the super call (line 6 in Listing 4) does not

refer to the rule in Basics but to the inherited deﬁ-

nition within the View module. In order to extend a

speciﬁc rule, e.g., adding a speciﬁc view element, a

Figure 5: Domain extension.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

392

1 gra m m a r de . m d2 . V i ew A d d o n w ith d e . md2 . View

2 im p o r t " h t tp :/ / md2 . d e / V iew " a s view

3 im p o r t " h t tp :/ / md2 . d e / B a s i c s " as basi c s

5 MD2Model returns basi c s :: M D 2 M o d e l :

6 su p e r ;

7 Co n t e n t El e m en t r e t u r n s v iew :: C o n t en t E le m e nt :

8 su p e r | Ad d e d B u t t on ;

9 Add e d B u t t o n : ...

Listing 4: ViewAddon grammar.

new rule alternative can be provided for the deﬁni-

tion of a ContentElement (lines 7-8). Nevertheless,

the original implementation is maintained by delegat-

ing other model inputs to the super language imple-

mentation. Conversely, rules may limit which super

language rules can be referenced, or place inherited

elements arbitrarily in the derived language’s struc-

ture without affecting the inherited grammar.

4.4 Advantages and Disadvantages of

Modularization

In this section, the results of the modularization are

discussed with regard to the implications for MD

modellers and DSL developers.

Modelling Experience. DSL modularization should

minimize changes to the language’s scope and its us-

age for modellers. It can be observed that the scope

of the modularized MD

DSL has not changed and

all language concepts could be transferred. Because

the language syntax was not modiﬁed, three structural

metrics were chosen from a plethora of grammar-

related metrics in order to asses the overhead of the

modularization (

Crepin

sek et al., 2010). Table 1 com-

pares the different DSL sizes using the number of

grammar rules, non-comment and non-blank lines of

code (NCLOC), and the amount of (non-comment)

characters in each DSL grammar. As can be seen,

the modularization process incurs a slight overhead

of about 5% lines of code due to the declaration of

imports and the speciﬁcation of interfaces. However,

complexity is greatly reduced compared to the origi-

nal DSL speciﬁcation with 2087 lines (including com-

ments). Admittedly, the resulting six DSLs represent

only a ﬁrst high-level separation of concerns. How-

ever, the effects of the modularization will amplify

when complex constructs of the large Controller and

View modules are further broken down.

However, as drawback of the extension approach,

new model ﬁles (and ﬁle types) are required for each

type of extension such as AutoGenerator model ele-

ments. This restriction is acceptable for large modules

(such as enforcing MVC separation on ﬁle level) but

gets inconvenient in case of multiple small additions.

Table 1: DSL comparison metrics.

(Sub-)DSL Rules NCLOC Characters

Original MD

188 924 30.208

Basics 26 93 1.893

Model 20 97 3.498

Controller 85 421 16.198

Workﬂow 8 31 1.050

AutoGenerator 5 27 955

Modular MD

206 970 31.913

Difference +9.6 % +5.0 % +5.6 %

Language Development. With regard to DSL devel-

opment, several advantages can be observed. Firstly,

splitting the large-scale DSL makes the framework

more maintainable. Both MD

and Xtext evolve over

time, therefore some parts of the implementation be-

came outdated but could not be replaced because of

the unknown implications of such actions. Also, the

underlying functionalities for validation, preprocess-

ing, and source code generation are untangled. There-

fore, deprecated and irrelevant code can be better

spotted and safely deleted without fearing side-effects

on other parts of the framework.

Secondly, the separation of concerns will likely

improve development speed and quality of sub-DSLs.

Instead of managing the whole language scope, par-

ticular sub-DSLs can evolve separately. This does

not only apply to language features but also includes

tool support for validation, formatting, code comple-

tion, etc. Also, developing generators does not re-

quire comprehensive knowledge about MD

anymore

but can focus on the transformation of speciﬁc domain

concepts to the respective target platform.

Finally, the modularization prepares the language

for future developments. New sub-DSLs can intro-

duce new or extend existing language concepts. Also,

language reuse in different DSLs is possible. How-

ever, the complete replacement of a language with an

existing DSL in the same domain is currently not eas-

ily possible because of the interface-based language

structure. Yet, considering the complex interrelations

within generated code it is questionable whether a re-

placement is actually desired.

Modularizing MD

also introduces some draw-

backs for language developers: The grammar of each

sub-DSL is simpliﬁed at the cost of fragmentation in

the overall framework structure. In particular, each

new DSL in Xtext is based on ﬁve Eclipse projects for

grammar deﬁnition, editor integration, and unit tests.

The current module structure of six DSLs already re-

sults in a set of 30 projects and will quickly rise if

Challenges and Opportunities of Modularizing Textual Domain-Speciﬁc Languages

393

new extensions and add-ons are introduced. Manag-

ing the conﬁguration – including dependencies, DSL

versions, and overall language bundling – needs to be

automated using build tools such as Gradle

From a conceptual perspective, a balance between

core language features and extensions needs to be

found. Language specializations may be tailored to

the speciﬁc environment but such adjustments ide-

ally do not require any change to the core language

to avoid compromising on the reusability of the host

language. Furthermore, the composition of domain

extensions is based on grammar inheritance and there-

fore prone to the same problems of manually main-

taining inheritance chains. As a consequence, intro-

ducing a multitude of minor DSL extensions is cur-

rently not advisable.

5 DISCUSSION

Beyond MD

-related advantages and disadvantages

derived from the case study, the generalized reﬂec-

tions on the results are presented as recommendations

for the modularization of DSLs in a broader context.

Recommendation 1. Inheritance-based modulariza-

tion should be limited to closely related language ex-

tensions and language specialization.

Language workbenches often do not support pow-

erful language composition techniques. For exam-

ple in Xtext, the limitation to single-inheritance and

language imports as main approaches to modulariza-

tion is not ﬂexible enough to cope with the extensive

(de-)composition of real-world DSLs. Because in-

heritance introduces tight coupling between two lan-

guages, this should be used sparingly. Common base

languages and language specialization, for instance

regarding sub-domains or company-/project-speciﬁc

adaptations, are well-suited use cases for grammar

inheritance. On the other hand, inheritance only al-

lows for the addition or modiﬁcation of grammar rules

but cannot remove existing language concepts. Also,

long inheritance chains of otherwise unrelated sub-

languages provide maintainability beneﬁts compared

to one large-scale deﬁnition.

Recommendation 2. Interface-based modulariza-

tion should be used for a ﬂexible combination of inde-

pendent languages as large-scale layers of the DSL.

A multi-layer structure of the resulting DSL can

be achieved by emulating interfaces between differ-

ent languages as described in Section 4.3.2. With the

concept of language imports, references between ele-

ments from different DSLs cannot only be performed

Gradle Build Tool – https://gradle.org/

for hierarchical relationships but can also be used in

settings with bidirectional or circular dependencies.

Although it was shown how issues can be overcome

using existing features, the workarounds are based on

implicit conventions that need to be shared by all in-

volved DSL developers.

Recommendation 3. Language reuse works best if a

common root language and infrastructure exists.

Unfortunately, there is no simple way to

“mix & match” arbitrary DSL speciﬁcations in Xtext.

Reusing a distinct set of rules in different languages

is complicated for reasons detailed in Section 4.1. In

general, a common infrastructure is required to ef-

fectively integrate language concepts across multiple

languages. A set of fundamental interfaces shared by

all related sub-DSLs eases the integration process also

in development frameworks which are not targeted to

language modularization. However, the dependency

on such a base language limits wide-spread language

reuse as no standard set of primitives exists that can

be applied generically to a broad set of languages.

Recommendation 4. The granularity of modules

should match the designed DSL’s structure.

Due to the limited ﬂexibility of referencing con-

structs by importing the target metamodel, the module

structure ideally matches the structure of the result-

ing DSL. For example, the effect of requiring separate

model ﬁles for language add-ons is potentially accept-

able for larger chunks of functionality that form in-

trinsic sub-units of the designed DSL. Otherwise, nu-

merous small language extensions require content to

be modelled in many different ﬁles, potentially caus-

ing confusion for the modeller.

Obviously, these pieces of advice are based on the

current features of the Xtext framework. If better con-

cepts for modularization are introduced, these recom-

mendations might change over time. Possible options

include native interfaces that can be implemented by

any grammar rule (Krahn et al., 2010) or techniques

such as aspects and traits (general multi-inheritance

has its own shortcomings) for embedding individual

language concepts in different DSLs such that the re-

sulting integration is transparent to the user. However,

currently no development efforts beyond the fragment

concept for non-extensible and DSL-internal inter-

faces are known.

6 CONCLUSION AND OUTLOOK

Until now, basic language constructs in DSLs need to

be implemented from scratch again and again, thus

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

394

limiting the degree of true domain-speciﬁcity. Conse-

quently, interoperability, maintainability, and reuse of

DSLs do not reach their full potential. In this work,

modularization techniques for language (de-) com-

position using a state-of-the-art framework for DSL

development called Xtext were investigated. A case

study on the large Xtext-based DSL MD

for mod-

elling business apps is presented in order to achieve

a high degree of modularity using available modular-

ization techniques.

Several challenges limit the ﬂexible applicability

of language modules. Most importantly, the con-

straints of single-inheritance and Xtext’s inability to

embed external grammars negatively affect the possi-

bilities of modular languages and the resulting mod-

elling experience for users. Beyond the particular use

case, general opportunities of DSL modularization in

Xtext include the reduction of legacy code and im-

proved maintainability of the current code base. The

applied practices are distilled into four recommenda-

tions for exploiting the current features.

This work reveals future research need concerning

suitable modularization techniques for textual DSLs

which necessitate more ﬂexibility regarding the reuse

of small-scale languages and the extraction of – of-

ten technical and not domain-speciﬁc – concepts into

sub-DSLs. Also, fully modularizing the model-driven

process including editing component, model proces-

sor, and code generators constitutes future work.

REFERENCES

Bracha, G. and Cook, W. (1990). Mixin-based inheritance.

ACM SIGPLAN Notices, 25(10):303–311.

Cazzola, W. and Poletti, D. (2010). DSL Evolution through

Composition. In 7th Workshop on Reﬂection, AOP

and Meta-Data for Software Evolution, pages 1–6.

Cazzola, W. and Vacchi, E. (2016). Language components

for modular DSLs using traits. Computer Languages,

Systems & Structures, 45:16–34.

Crepin

sek, M., Kosar, T., Mernik, M., Cervelle, J., Forax,

R., and Roussel, G. (2010). On automata and lan-

guage based grammar metrics. Computer Science and

Information Systems, 7(2):309–330.

Ducasse, S., Nierstrasz, O., Sch

arli, N., Wuyts, R., and

Black, A. P. (2006). Traits: A Mechanism for Fine-

Grained Reuse. ACM Transactions on Programming

Languages and Systems, 28(2):331–388.

Ekman, T. and Hedin, G. (2007). The JastAdd system —

modular extensible compiler construction. Science of

Computer Programming, 69(1–3):14–26.

Erdweg, S., van der Storm, T., V

olter, M., Tratt, L.,

Bosman, R., Cook, W. R., Gerritsen, A., Hulshout,

A., Kelly, S., Loh, A., Konat, G., Molina, P. J., Palat-

nik, M., Pohjonen, R., Schindler, E., Schindler, K.,

Solmi, R., Vergu, V., Visser, E., van der Vlist, K.,

Wachsmuth, G., and van der Woning, J. (2015). Eval-

uating and comparing language workbenches: Exist-

ing results and benchmarks for the future. Computer

Languages, Systems & Structures, 44, Part A:24–47.

Ernsting, J., Rieger, C., Wrede, F., and Majchrzak, T. A.

(2016). Reﬁning a Reference Architecture for Model-

Driven Business Apps. In Intl. Conference on Web In-

formation Systems and Technologies, pages 307–316.

Fowler, M. (2005). Language workbenches: The killer-app

for domain speciﬁc languages? http://martinfowler.

com/articles/languageWorkbench.html.

Heitk

otter, H., Majchrzak, T. A., and Kuchen, H. (2013).

Cross-platform model-driven development of mobile

applications with MD2. In 28th Annual ACM Sympo-

sium on Applied Computing, pages 526–533.

Krahn, H., Rumpe, B., and V

olkel, S. (2010). MontiCore: a

framework for compositional development of domain

speciﬁc languages. International Journal on Software

Tools for Technology Transfer, 12(5):353–372.

Majchrzak, T. A., Ernsting, J., and Kuchen, H. (2015).

Achieving business practicability of model-driven

cross-platform apps. OJIS, 2(2):3–14.

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and How to Develop Domain-speciﬁc Languages.

ACM Computing Surveys, 37(4):316–344.

Pescador, A., Garmendia, A., Guerra, E., Sanchez

Cuadrado, J., and de Lara, J. (2015). Pattern-based de-

velopment of Domain-Speciﬁc Modelling Languages.

In International Conference on Model Driven Engi-

neering Languages and Systems, pages 166–175.

Spinellis, D. (2001). Notable design patterns for domain-

speciﬁc languages. Journal of Systems and Software,

56(1):91–99.

Vacchi, E., Olivares, D. M., Shaqiri, A., and Cazzola, W.

(2014). Neverlang 2: A Framework for Modular Lan-

guage Implementation. In 13th International Confer-

ence on Modularity, pages 29–32. ACM.

Vaupel, S., Taentzer, G., Harries, J. P., Guckert, M., Stroh,

R., Gerlach, R., and Guckert, M. (2014). Model-

Driven Development of Mobile Applications Allow-

ing Role-Driven Variants. MODELS, 45(355):1–17.

olter, M. (2013). DSL Engineering. CreateSpace Inde-

pendent Publishing Platform.

olter, M. and Solomatov, K. (2010). Language modu-

larization and composition with projectional language

workbenches illustrated with MPS. 3rd Intl. Confer-

ence on Software Language Engineering, LNCS.

Wand, M., Kiczales, G., and Dutchyn, C. (2004). A se-

mantics for advice and dynamic join points in aspect-

oriented programming. TOPLAS, 26(5):890–910.

Wu, H., Gray, J., Roychoudhury, S., and Mernik, M. (2005).

Weaving a debugging aspect into domain-speciﬁc lan-

guage grammars. In Proceedings of the 2005 ACM

Symposium on Applied computing, pages 1370–1374.

Challenges and Opportunities of Modularizing Textual Domain-Speciﬁc Languages

395