Exploiting Meta-Model Structures in the Generation of Xtext Editors

org Holtmann

1 a

, Jan-Philipp Stegh

ofer

2 b

and Weixing Zhang

1 c

Department of Computer Science & Engineering, Chalmers | University of Gothenburg, Gothenburg, Sweden

Xitaso IT & Software Solutions GmbH, Augsburg, Germany

Keywords:

Xtext, Textual Modelling, Modelling Language Engineering, Modelling Environments.

Abstract:

When generating textual editors for large and highly structured meta-models, it is possible to extend Xtext’s

generator capabilities and the default implementations it provides. These extensions provide additional fea-

tures such as formatters and more precise scoping for cross-references. However, for large metamodels in

particular, the realization of such extensions typically is a time-consuming, awkward, and repetitive task. For

some of these tasks, we motivate, present, and discuss in this position paper automatic solutions that exploit

the structure of the underlying metamodel. Furthermore, we demonstrate how we used them in the devel-

opment of a textual editor for EATXT, a textual concrete syntax for the automotive architecture description

language EAST-ADL. This work in progress contributes to our larger goal of building a language workbench

for blended modelling.

1 INTRODUCTION

Xtext (Eysholdt and Behrens, 2010) is a framework

for the development of domain-speciﬁc languages

(DSLs). It can either take an existing meta-model

and derive a grammar from it or allows a language

engineer to create a grammar directly which is then

translated into a meta-model. Once a grammar exists,

Xtext can generate editors that integrate seamlessly

into the Eclipse IDE and offer many convenient fea-

tures such as an outline view of the ﬁle which is cur-

rently edited. On the other hand, it offers extension

mechanisms for more advanced editor features.

In practice, using these extensions mechanisms

can pose signiﬁcant technical challenges. For ex-

ample, auto-formatting or the use of template pro-

posals — both common features in modern editors —

are not supported for DSLs based on Xtext out-

of-the-box. Despite comprehensive documentation

of the corresponding extension mechanisms, these

challenges re-occur and have to be solved manually.

In particular, implementing these features for sufﬁ-

ciently large languages can be cumbersome and in-

volves a lot of repetitive code.

In other cases where Xtext provides support out-

of-the-box, the default implementations provided by

https://orcid.org/0000-0001-6141-4571

https://orcid.org/0000-0003-1694-0972

https://orcid.org/0000-0003-2890-6034

Xtext are not always suitable for large DSLs since the

performance they provide (e.g., for cross-reference

auto-completion) is insufﬁcient for practical purposes

or for certain use cases.

In the context of a prototype for a textual variant

of the automotive systems modeling language EAST-

ADL (Debruyne et al., 2004; Cuenot et al., 2007), we

implemented several automated solutions for these re-

occurring challenges by using custom Xtext generator

fragments that exploit the structure of the language’s

meta-model. These fragments are used when Xtext

generates the editors for a DSL. We created fragments

for formatting, content-assist, and template proposals.

In addition, we created a solution for providing the

scope of cross-references automatically suggested by

the editor which addresses several short-comings of

the default solution. In all cases, the structure of the

meta-model provides the necessary support to enable

the automation.

In this position paper, we discuss these automated

solutions and describe how other DSL engineers can

adapt them for their needs. Our solutions are partic-

ularly suitable for very large, but highly structured

DSLs that are available as a metamodel, but should

also translate to other situations in which Xtext is

used. Furthermore, we discuss the limitations of the

automatic solutions where present. Whereas these au-

tomations are not generic enough to add them to Xtext

properly, they are interesting for other language engi-

218

Holtmann, J., Steghöfer, J. and Zhang, W.

Exploiting Meta-Model Structures in the Generation of Xtext Editors.

DOI: 10.5220/0011745900003402

In Proceedings of the 11th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2023), pages 218-225

ISBN: 978-989-758-633-0; ISSN: 2184-4348

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

neers and can be applied to other languages as well.

Our work in progress contributes to a larger vi-

sion of a language workbench for blended modelling

in which editors for different concrete syntaxes for the

same abstract syntax co-exist and enable engineers to

seamlessly switch between the representations (Cic-

cozzi et al., 2019). Especially when used in conjunc-

tion with evolving languages where the meta-model

structure changes regularly, it is necessary to be able

to quickly regenerate the editors with as little manual

effort as possible.

2 RELATED WORK

Neubauer et al. proposed an approach (Neubauer

et al., 2015) to automatically create modern edi-

tors for XML-based DSLs by bridging the “technical

spaces” XMLware, grammarware, and modelware.

Their automation mainly focuses on providing auto-

matic customization of textual concrete syntaxes for

the target DSL, such as which symbols to use. In con-

trast, our automation mainly focuses on the enhance-

ment of the editors, such as automatically providing

default names for new elements, improved sugges-

tions for cross-references, etc.

Latifaj et al. focused on enabling different stake-

holders to perform blended modeling (David et al.,

2022) in an automated manner, i.e., using different

modeling notations to seamlessly handle overlapping

parts of the model (Latifaj et al., 2021). They discuss

four challenges to achieving this automation goal in

the commercial tool RTist. However, they do not ad-

dress the challenges of content assistance, template

proposals, etc., which are the core challenges dis-

cussed in this paper.

Cooper and Kolovos acknowledge some of the

challenges we address in this work in their paper

on requirements and challenges of blended mod-

elling (Cooper and Kolovos, 2019). For instance,

they consider scoping across concrete syntaxes to be

a challenge. We address this with our custom Scope-

Provider as discussed in Section 4.4.

3 BACKGROUND

In the following, we provide relevant information on

Xtext as well as EATXT, the textual variant of EAST-

ADL which we used as an exemplar and a case study

for our work.

3.1 Xtext

Xtext is a framework for the development of tex-

tual domain-speciﬁc languages (DSL) (Eysholdt and

Behrens, 2010). At its core is a grammar language

that allows deﬁning the syntax of a DSL. Xtext can

either generate a grammar out of an existing meta-

model or the user can specify the grammar directly

and the meta-model is generated by Xtext. A gram-

mar can be used as the input to generate editors for

the Eclipse IDE or for browsers. In addition, Xtext

can generate a language server that allows integrating

the DSL into VS.Code or Eclipse Theia.

The generation process is controlled by a work-

ﬂow for the Modeling Workﬂow Engine (MWE2)

(Eclipse Foundation, 2023b). Xtext provides a lan-

guage generator which can be customized and ex-

tended with custom fragments. A fragment gener-

ates code based on the generator’s conﬁguration, the

grammar and the corresponding meta-model. Xtext

out-of-the-box provides a number of such fragments,

which can be extended or replaced. These fragments

add a number of features to the generated editors. For

instance, Xtext automatically generates a syntax val-

idator which highlights incorrect syntax directly in

the editor and in Eclipse’s “Problems” view. For ed-

itors in the Eclipse IDE, support for the outline view

is also generated. We use Xtext’s ability to change

the standard conﬁguration to add custom fragments

that provide better formatting, content-assist and tem-

plate proposals as described below. These custom

fragments are written in Xtend (Eclipse Foundation,

2023a).

Xtext splits the generated code into different bun-

dles, distinguishing between the infrastructure for the

language itself, the user interface of the editors (bun-

dle name ends with “.ui”) and the integration into the

Eclipse IDE (bundle name ends with “.ide”).

3.2 EAST-ADL and EATXT

EAST-ADL is an automotive systems modeling lan-

guage (Cuenot et al., 2007) and is based on a large

metamodel with more than 200 metaclasses and a hi-

erarchy of nested elements describing different as-

pects of electronic vehicle systems. It can be edited

in EATOP, an Eclipse-based editing environment that

provides a hierarchical view of an EAST-ADL model

along with form- and table-based editing capabili-

ties. EATXT provides a textual syntax for EAST-ADL

with the goal to enable blended modeling (Ciccozzi

et al., 2019), that is, the ability to switch between the

hierarchy-based and the textual representation seam-

lessly depending on the editing task.

Exploiting Meta-Model Structures in the Generation of Xtext Editors

219

shortName: String [1..1]

Referrable

shortName: String [1..1]

Referrable

EAPackageEAPackage

EAPackagable-

Element

EAPackagable-

Element

EADatatypeEADatatype

EANumericalEANumerical

element

direction:

EADirectionKind [1..1]

FunctionFlowPort

direction:

EADirectionKind [1..1]

FunctionFlowPort

1..1

type

1..1

type

...

inout

out

«enumeration»

EADirectionKind

inout

out

«enumeration»

EADirectionKind

FunctionTypeFunctionType FunctionPortFunctionPort

port

Design-

FunctionType

Design-

FunctionType

...

Figure 1: EAST-ADL Metamodel Excerpt.

Figure 1 depicts an EAST-ADL metamodel ex-

cerpt, which we use in this paper as a running exam-

ple for illustrative purposes. The excerpt contains a

set of metaclasses (partially containing attributes) and

relationships (i.e., generalizations, compositions, and

cross-references), which we explain in the following.

An example of an EATXT ﬁle is shown in Fig-

ure 2. The textual concrete syntax follows the hi-

erarchy and structure of the EAST-ADL metamodel.

Metaclasses in EAST-ADL are represented as blocks

delimited by curly braces (e.g., the FunctionFlowPort

WipingCmd in lines 7–10 as part of the DesignFunc-

tionType WiperCtrl). Attributes are represented as

lists with the attribute name and the values (e.g.,

the attribute direction in line 8 as part the Function-

FlowPort WipingCmd). Cross-references are repre-

sented as the reference name followed by the ac-

tual path to the reference (e.g., the cross-reference

type points to “DataTypes.Integer uint8”). In the

case of EATXT, the Xtext grammar is speciﬁed in

such a way that the textual keywords representing

the metamodel concepts like metaclasses, attributes,

and cross-references are named as in the metamodel

(e.g., both the keyword and its corresponding meta-

class have the same name FunctionFlowPort).

4 CHALLENGES AND

SOLUTIONS

In this section, we explain our solutions to re-

occurring challenges in the development of Xtext-

based language workbenches by referring to Figure 3,

Figure 2: Excerpt from an EATXT File Specifying a Wind-

shield Wiper Control System.

which depicts the coarse-grained architecture of our

Xtext-based editor for EATXT.

As described in Section 3.2, EAST-ADL is a sta-

ble language based on an Ecore metamodel (cf. east-

adl22.ecore in the plugin o.e.eatop.eastadl22 in the

top-left corner of Figure 3). We conceived its textual

syntax by automatically deriving an initial grammar

from that metamodel with Xtext and subsequently

adapting the grammar to the stakeholders’ needs. Fig-

ure 3 indicates the resulting grammar as the artifact

Eatxt.xtext as part of the plugin org.bumble.eatxt. In

this grammar, we named the production rules and

keywords equally as the language concepts in the

metamodel (i.e., metaclasses, attributes, and ERefer-

ences). This enables the exploitation of the meta-

model structure and thereby the development of our

automatic solutions.

The green Xtend and Java classes that are part of

the plugin org.bumble.eatxt represent our solutions to

the re-occurring challenges described below, exploit-

ing the structure of the metamodel eastadl22.ecore.

Three of the solutions are custom fragments that are

executed by the Xtext language generator (cf. Sec-

tion 3.1) and generate further artifacts (depicted in

lilac) that are used in the EATXT runtime. Another

solution generates an artifact during the activation of

the plugin which can then be exploited at runtime. We

provide the implementation in our EATXT develop-

ment repository (Holtmann et al., 2023). In the fol-

lowing four subsections, we explain and discuss these

automatic solutions, the challenges they solve, and the

artifacts they generate.

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

220

o.e.eatop.eastadl22o.e.eatop.eastadl22

org.bumble.eatxtorg.bumble.eatxt

org.bumble.eatxt.ideorg.bumble.eatxt.ide

org.bumble.eatxt.uiorg.bumble.eatxt.ui

contentassist/

EatxtContentAssist

Fragment.xtend

contentassist/

EatxtContentAssist

Fragment.xtend

formatting2/

EatxtFormatter2

Fragment.xtend

formatting2/

EatxtFormatter2

Fragment.xtend

scoping/

EatxtScopeProvider.java

scoping/

EatxtScopeProvider.java

«import»«import»

Legend

Generated artifact

exploited at runtime

Automatic solution

executed at infrastructure

generation or plugin startup

formatting2/

EatxtFormatter.xtend

(transformed to .java)

formatting2/

EatxtFormatter.xtend

(transformed to .java)

templates/

templates.xml

templates/

templates.xml

eastadl22.ecore

Activator.javaActivator.java

Eatxt.xtext

Cross-references

lookup map

templates/

EatxtTemplate

Fragment.xtend

templates/

EatxtTemplate

Fragment.xtend

src-gen/contentassist/

EatxtProposalProvider.java

src-gen/contentassist/

EatxtProposalProvider.java

Figure 3: EATXT Architecture and Automatic Solutions for Re-occurring Challenges.

4.1 Template Proposals

The Eclipse IDE provides the possibility of using

code templates to enter complex code constructs that

contain a signiﬁcant amount of text and are more

complicated than simple keywords. For instance, in

the case of the Java programming language, the pro-

posal of complete constructors or different kinds of

loops is handled by code templates. Eclipse ships

with a set of pre-deﬁned code templates and allows

adding user-deﬁned templates or customize existing

ones. Likewise, Xtext editors also provide the pos-

sibility to use and deﬁne code templates by support-

ing template proposals, which consist of the actual

code template and a context type (Eclipse Foundation,

2023g). During the editor generation, Xtext automati-

cally registers such a context type for each production

rule and keyword (e.g., the production rule for textual

instances of the EAST-ADL metaclass FunctionFlow-

Port), and it provides the context for the code template

proposal.

However, the development of template propos-

als is cumbersome, because the DSL engineer has to

deﬁne each template manually in an XML ﬁle tem-

plates/templates.xml as part of the UI plugin (cf. top

of the plugin org.bumble.eatxt.ui on the right-hand

side of Figure 3) (Eclipse Foundation, 2023g). More-

over, it is recommended practice to deﬁne them in

the runtime workspace of the Xtext editor through

a corresponding dialog and to export the resulting

templates.xml to the development workspace (Eclipse

Foundation, 2023g), which impedes rapid prototyp-

ing of the template proposals. Particularly, this man-

ual practice is awkward for large metamodels.

As an automatic solution to this challenge in

EATXT, we implemented the generator fragment tem-

plates/EatxtTemplateFragment.xtend as part of the

plugin org.bumble.eatxt (cf. fragment of the plugin

in Figure 3). This fragment is executed by the

MWE2 workﬂow and automatically generates the

XML ﬁle templates/templates.xml as part of the

plugin org.bumble.eatxt.ui. The fragment iterates

over the metamodel and generates a template pro-

posal for all metaclasses and all of their manda-

tory sub-elements (i.e., attributes, containments and

their nested structures, as well as cross-references).

We restrict the code templates to contain only sub-

elements that are mandatory in the metamodel instead

of proposing all potential sub-elements, because it

might be much effort for the user to delete all pro-

posed optional, but potentially not required, elements.

Figure 4 depicts the generation scheme of the frag-

ment using the example of the metaclass Function-

FlowPort and its mandatory attribute and mandatory

cross-reference. We specify the context type as the

name of the production rule, which in the EATXT case

is always named the same as the corresponding meta-

class (e.g., org.bumble.eatxt.Eatxt.FunctionFlowPort

Exploiting Meta-Model Structures in the Generation of Xtext Editors

221

shortName: String [1..1]

Referrable

shortName: String [1..1]

Referrable

EADatatypeEADatatype

direction:

EADirectionKind [1..1]

FunctionFlowPort

direction:

EADirectionKind [1..1]

FunctionFlowPort

1..1 type1..1 type

...

inout

out

«enumeration»

EADirectionKind

inout

out

«enumeration»

EADirectionKind

templates/

templates.xml

templates/

templates.xml

Figure 4: Exemplary Generation of a Template Proposal.

for the XML template attribute context). The ac-

tual code template is then generated as the name of

the production rule and metaclass (e.g., FunctionFlow-

Port) followed by a set of further texts as well as open-

ing and closing curly braces.

Beyond proposing simple static texts that would

typically not ﬁt to the remainder of the text ﬁle and

hence would lead to error messages in the editor, the

template proposal approach also supports template

variable resolvers (Eclipse Foundation, 2023g). For

simple attributes, we distinguish the different plain

data types of attributes (e.g., String, Integer, Float)

and corresponding template variable resolvers. For

example in Figure 4, we translate the String attribute

shortName of the metaclass Referrable to a corre-

sponding template variable resolver ${shortName}.

For enumeration attributes, we generate enumeration

template variable resolvers. For example, the value of

the attribute direction is automatically set to the ﬁrst

literal in of the enumeration EADirectionKind. Fur-

thermore, we also support cross-reference template

variable resolvers that propose an existing element

that ﬁts to the type of the cross-reference. For exam-

ple, the cross-reference type is translated to the corre-

sponding resolver.

Figure 5 depicts a screenshot for the proposal of a

code template for the context type FunctionFlowPort

with its mandatory two attributes, where the default

enumeration value of the direction attribute as well as

a target candidate for the cross-reference type is di-

rectly proposed. In the case of EATXT, the generated

template ﬁle contains 194 code templates with a total

of more than 1,000 XML lines and covers all meta-

classes of the metamodel and their mandatory sub-

elements.

As we exploit the concept names of the underly-

ing metamodel for this solution, such a generation of

template proposals is restricted to grammars that have

the same concept names as the corresponding meta-

model (i.e., metaclass names, attribute names, asso-

ciation role names). Thus, the DSL engineer is not

allowed to rename the resulting keywords.

4.2 Content-Assist for New Model

Elements with Unique Names

Beyond the usual keyword-based content-assist

known from IDEs, Xtext provides a customizable

approach to provide content-assist for the speciﬁca-

tion of new model elements by means of proposal

providers (Eclipse Foundation, 2023c). In this ap-

proach, Xtext generates an abstract proposal provider

class with default functionality with content-assist

methods for all metaclasses as well as an empty con-

crete subclass that can be customized. To customize

the content-assist for a speciﬁc model element type

(e.g., for the metaclass FunctionFlowPort with exem-

plary instances in lines 7–10 and 14–17 in Figure 2),

the DSL engineer has to override the corresponding

method in a concrete subclass.

In the case of EATXT, we had the requirement to

provide content-assist proposals with unique names

in the model namespace for all metaclasses with a

mandatory shortName attribute. Since almost all of

the more than 200 metaclasses in the EAST-ADL

metamodel have this mandatory attribute due to sub-

classing (cf. Figure 1), the implementation of the cor-

responding particular methods in the concrete pro-

posal provider would have been very repetitive.

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

222

Figure 5: Proposed Code Template.

In order to provide an automatic solution

for this challenge, we implemented a fragment

contentassist/EatxtContentAssistFragment.xtend

(cf. plugin org.bumble.eatxt in Figure 3). Again,

this fragment is executed by the MWE2 work-

ﬂow and exploits the metamodel structure by

iterating over all metaclasses with the mandatory

attribute and generating the concrete subclass

src-gen/contentassist/EatextProposalProvider.java

(cf. plugin org.bumble.eatxt.ui on the right-hand side

of Figure 3).

Figure 6 depicts the scheme for the generation of

the proposal provider methods using the example for

the metaclass FunctionFlowPort. For each metaclass

with the mandatory attribute, this generated proposal

provider includes a corresponding overriding content-

assist method that proposes a unique name consist-

ing of the corresponding preﬁx <metaclassName >

followed by a randomized number for a new in-

stance of the metaclass. For example, we generate for

the metaclass FunctionFlowPort a corresponding pro-

posal provider method that proposes the preﬁx “Func-

tionFlowPort ” followed by the randomized number.

Overall, the generated EatxtProposalProvider encom-

passes 188 such methods.

Figure 7 depicts a screenshot of the content-assist

proposal for a new FunctionFlowPort instance.

4.3 Formatters

Formatting text documents (e.g., Java source code)

in the Eclipse IDE is the process of rearranging the

documents’ texts without semantically changing their

contents. Xtext in principle supports this process

as well, but does not provide out-of-the-box format-

ters (Eclipse Foundation, 2023e).

Instead, it requires that the language engineer ex-

tends an abstract formatter class and implements a

corresponding dispatcher method for any metaclass to

be formatted in its text representation. These meth-

ods are called when the formatting process is trig-

gered and apply a series of text replacements for the

corresponding model objects. As formatting should

treat the text document and its particular contents in a

uniform way, the implementation of these methods is

highly repetitive.

In order to automate this tedious task and to pro-

vide a way of formatting the particular model ele-

ments uniformly, we implemented the generator frag-

ment formatting2/EatxtFormatter2Fragment.xtend as

part of the plugin org.bumble.eatxt (cf. fragment of

the plugin in Figure 3). This fragment is executed

by the MWE2 workﬂow and automatically generates

the formatter class formatting2/EatxtFormatter.xtend

as part of the same plugin. The fragment iterates over

the metaclasses of the metamodel and generates the

corresponding dispatcher method for each container

metaclass. Furthermore, the fragment generates the

individual formatting methods for all nested contain-

ments or sub-elements of these container classes calls.

The generated formatter class in the EATXT case en-

compasses 51 dispatch methods and 141 calls of the

formatting methods for the nested sub-elements.

4.4 Scoping for Cross-References

Programming languages, DSLs, and metamodels typ-

ically provide means to establish links between the

semantic concepts deﬁned in the corresponding mod-

els (e.g., for specifying the type of a language con-

cept through referencing a different type concept).

In the Xtext language development framework, such

links are called cross-references (Eclipse Foundation,

2023d). The scoping API of Xtext provides the means

for ﬁnding the target of a cross-reference based on its

source context (Eclipse Foundation, 2023f). For ex-

ample, the FunctionFlowPort instances in the lines 7–

9 and 14–17 in Figure 2 are source contexts, and their

elements type are cross-references pointing to target

objects typed by the metaclass EADatatype (cf. Fig-

ure 1). If the target concept is nested in a container

hierarchy (e.g., hierarchies of packages like the EA-

Package instance DataTypes in lines 1–3 in Figure 2),

this procedure for ﬁnding a cross-reference target par-

ticularly includes the computation of the scope within

the nested container hierarchy.

Xtext provides a default out-of-the-box approach

for the cross-reference scoping within container hi-

erarchies by means of a scope provider (Eclipse

Foundation, 2023f), where the scope provider also

enables content-assist for the cross-reference tar-

gets. In this default approach, the fully quali-

Exploiting Meta-Model Structures in the Generation of Xtext Editors

223

shortName: String [1..1]

Referrable

shortName: String [1..1]

Referrable

FunctionFlowPortFunctionFlowPort

...

src-gen/contentassist/

EatxtProposalProvider.java

src-gen/contentassist/

EatxtProposalProvider.java

Figure 6: Exemplary Generation of a Content-assist Method for Unique Names of new FunctionFlowPort Model Elements.

Figure 7: Content-assist for a new Model Element.

ﬁed name of the cross-reference target in the con-

tainer hierarchy is only proposed by the content-

assist if the target is part of a different con-

tainer. For example in Figure 2, the type cross-

reference in line 9 as part of the container hierar-

chy FcnDesignTypes.WiperCtrl.WipingCmd points to

the model element Integer uint8 as part of the con-

tainer DataTypes). In contrast, if the target is part of

the same container as the source context, then only the

plain name of the target is proposed but not its fully

qualiﬁed name.

In the case of EATXT, a requirement is to provide

content-assist that always proposes the fully qualiﬁed

name. This requires a custom implementation of the

scope provider (see also (Latifaj et al., 2021) for a dif-

ferent use case requiring such a custom implementa-

tion). In such a custom implementation, the DSL en-

gineers have to compute for any source context meta-

class the corresponding cross-reference target candi-

date metaclasses. For example, for the source context

metaclass FunctionFlowPort and its cross-reference

type, they have to realize that the target candidates

are instances of the metaclass EADatatype (cf. Fig-

ure 1). In this context, multiple cross-reference target

metaclasses are possible if the source context meta-

class has multiple cross-references.

Basically, this computation is straightforward, but

needs to consider all cross-references of the underly-

ing metamodel, resulting in a large switch-case state-

ment (i.e., if the source context of a cross-reference

is an instance of a certain metaclass, return all can-

didates that are instances of the metaclasses of all

target references). Particularly for large grammars

and metamodels, this straightforward custom imple-

mentation is very awkward. Beyond that, both the

Xtext default approach and custom implementation

suffer from performance issues for large grammars

and metamodels with many cross-references. In the

runtime editor, the target candidate types are al-

ways computed on any content-assist keystroke for

the given source context type. In the worst case,

the lookup needs to traverse the entire switch-case-

statement, which consists of all n possible cases for a

complexity of O(n).

As an automatic solution for this challenge in

EATXT, we generate a cross-references lookup map

in the activator of the plugin (cf. Activator.java in

the plugin org.bumble.eatxt in Figure 3). This gen-

eration traverses the metamodel exactly once with a

complexity of O(n). This lookup map contains the

corresponding type of the cross-reference target for

any source context type, and we compute it by iterat-

ing over all cross-references in the metamodel. We

generate the lookup map during the ﬁrst activation

of the plugin. After that, the scoping/EatxtScope-

Provider.java accesses it via an interface but does not

need to perform the same computation on every cross-

reference content-assist keystroke. The lookup map is

implemented as a Java HashMap whose get() method

has a complexity of O(1) in most cases. In the EATXT

case, the map encompasses the source context meta-

classes and corresponding target metaclasses for 261

cross-references of the EAST-ADL metamodel. Fig-

ure 8 depicts a screenshot of the content-assist for

cross-referencing an existing model element in a dif-

ferent container hierarchy.

Figure 8: Cross-referencing an Existing Model Element.

The solution has two advantages, in particular for

large grammars and metamodels. First, we auto-

mate the awkward custom implementation of a scope

provider with a generic solution that exploits the un-

derlying metamodel cross-references structure. Sec-

ond, it signiﬁcantly improves the performance of the

Xtext scope provider approach by computing a cross-

reference lookup table once at plugin activation, in-

stead of computing the target types on every content-

assist keystroke for a source context. Thus, the ex-

pensive operation takes place only once rather than

repeatedly at runtime.

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

224

5 CONCLUSION AND OUTLOOK

Our solutions to the four challenges of template

proposals, formatters, content-assist, and scoping

have been developed and evaluated in the context of

EATXT, but are not only useful there. Instead, we ar-

gue that similar approaches are helpful for any highly

structured abstract syntax for which Xtext is used

to generate editors for a textual concrete syntax. A

speciﬁc language will beneﬁt from adaptations, espe-

cially in the area of scoping. As such, our solutions

are not generic enough to contribute to Xtext directly,

but will hopefully serve as a blueprint that is useful to

other engineers with similar challenges.

We view our contributions in the light of a future

language workbench that supports the blended mod-

eling for large DSLs that evolve. As described in our

previous work (Holtmann et al., 2022), EAST-ADL is

such a language and support for its evolution within

Eclipse is a relatively new capability. Our work fur-

ther supports this approach by providing a stream-

lined way to generate the editors whenever the lan-

guage changes. When coupled with the generation

of a graphical editor (see, e.g., (Cooper and Kolovos,

2019)), this brings us closer to the ideal of a blended

modeling language workbench.

ACKNOWLEDGEMENTS

Parts of this research were sponsored by Vinnova un-

der grant agreement nr. 2019-02382 as part of the

ITEA4 project BUMBLE.

REFERENCES

Ciccozzi, F., Tichy, M., Vangheluwe, H., and Weyns, D.

(2019). Blended Modelling – What, Why and How.

In 22nd ACM/IEEE Intl. Conf. on Model Driven Engi-

neering Languages and Systems (MODELS) Compan-

ion Proceedings, pages 425–430. IEEE.

Cooper, J. and Kolovos, D. (2019). Engineering hy-

brid graphical-textual languages with sirius and xtext:

Requirements and challenges. In 2019 ACM/IEEE

22nd Intl. Conf. on Model Driven Engineering Lan-

guages and Systems (MODELS) Companion Proceed-

ings, pages 322–325. IEEE.

Cuenot, P., Chen, D., Gerard, S., L

onn, H., Reiser, M.-O.,

Servat, D., Sjostedt, C.-J., Kolagari, R. T., Torngren,

M., and Weber, M. (2007). Managing complexity of

automotive electronics using the East-ADL. In 12th

IEEE Intl. Conf. on Engineering Complex Computer

Systems (ICECCS 2007), pages 353–358. IEEE.

David, I., Latifaj, M., Pietron, J., Zhang, W., Ciccozzi,

F., Malavolta, I., Raschke, A., Stegh

ofer, J.-P., and

Hebig, R. (2022). Blended modeling in commercial

and open-source model-driven software engineering

tools: A systematic study. Software & Systems Mod-

eling.

Debruyne, V., Simonot-Lion, F., and Trinquet, Y. (2004).

EAST-ADL—an architecture description language. In

IFIP World Computer Congress, TC 2, pages 181–

195. Springer.

Eclipse Foundation (2023a). Xtend. https://www.eclipse.

org/xtend/. Last accessed Jan 2023.

Eclipse Foundation (2023b). Xtext reference documenta-

tion: Conﬁguration. https://www.eclipse.org/Xtext/

documentation/302 conﬁguration.html. Last accessed

Jan 2023.

Eclipse Foundation (2023c). Xtext reference documen-

tation: Content assist. https://www.eclipse.org/

Xtext/documentation/310 eclipse support.html#

content-assist. Last accessed Jan 2023.

Eclipse Foundation (2023d). Xtext reference documen-

tation: Cross-references. https://www.eclipse.org/

Xtext/documentation/301 grammarlanguage.html#

cross-references. Last accessed Jan 2023.

Eclipse Foundation (2023e). Xtext reference docu-

mentation: Formatting. https://www.eclipse.org/

Xtext/documentation/303 runtime concepts.html#

formatting. Last accessed Jan 2023.

Eclipse Foundation (2023f). Xtext reference documen-

tation: Scoping. https://www.eclipse.org/Xtext/

documentation/303 runtime concepts.html#scoping.

Last accessed Jan 2023.

Eclipse Foundation (2023g). Xtext reference documen-

tation: Template proposals. https://www.eclipse.

org/Xtext/documentation/310 eclipse support.html#

templates. Last accessed Jan 2023.

Eysholdt, M. and Behrens, H. (2010). Xtext: implement

your language faster than the quick and dirty way. In

ACM Intl. Conf. on Object oriented programming sys-

tems languages and applications companion, pages

307–309.

Holtmann, J., Stegh

ofer, J., and L

onn, H. (2022). Mi-

grating from proprietary tools to open-source software

for EAST-ADL metamodel generation and evolution.

In K

uhn, T. and Sousa, V., editors, 25th Intl. Conf.

on Model Driven Engineering Languages and Sys-

tems (MODELS) Companion Proceedings, pages 7–

11. ACM.

Holtmann, J., Stegh

ofer, J.-P., and Zhang, W. (2023).

EATXT implementation excerpt. https://github.com/

joerg-holtmann/EATXT4MODELSWARD23. Last

accessed Jan 2023.

Latifaj, M., Ciccozzi, F., Mohlin, M., and Posse, E. (2021).

Towards Automated Support for Blended Modelling

of UML-RT Embedded Software Architectures. In

ECSA (Companion).

Neubauer, P., Bergmayr, A., Mayerhofer, T., Troya, J., and

Wimmer, M. (2015). XMLText: From XML schema

to xtext. In 2015 ACM SIGPLAN Intl. Conf. on Soft-

ware Language Engineering, pages 71–76.

Exploiting Meta-Model Structures in the Generation of Xtext Editors

225