Language Architecture: An Architecture Language for

Model-Driven Engineering

Niels Brouwers, Marc Hamilton, Ivan Kurtev and Yaping Luo

Altran Netherlands B.V., Eindhoven, The Netherlands

Keywords:

Architecture, Model-Driven Engineering, Domain-Speciﬁc Languages.

Abstract:

The increasing number of languages used to engineer complex systems causes challenges to the development

and maintenance processes of these languages. In this paper, we reﬂect on our experience in developing real

life complex cyber-physical systems by using MDE techniques and DSLs. Firstly, we discuss a number of

industrial challenges in the modeling software engineering domain. To address these challenges, we propose

the concept of language architecture as an organizational principle for designing, reusing and maintaining DSLs

and their infrastructure. Based on this, a metamodel for a DSL is designed and a tool support (LanArchi) is

developed. Finally the possible future directions are given.

1 INTRODUCTION

Today’s software systems are often implemented with

multiple languages. Familiar examples are web-based

systems that use XML and HTML for content, CSS for

layout, and data manipulation languages for storing

and querying data. While general-purpose languages

are still the main implementation choice, a recent state-

ment (Nierstrasz, 2016) clearly indicates that software

engineers need specialized languages for requirements

speciﬁcation and problem domain modeling among

others. The advances in the Model-Driven Engineer-

ing (MDE) make the development of Domain-Speciﬁc

Languages (DSLs) easier. As the number of languages

used to engineer complex systems increases, it be-

comes challenging to develop and maintain a set of

inter-related languages and their dependence on exist-

ing hardware and software development infrastructure.

In this paper we reﬂect on our experience in de-

veloping real life complex cyber-physical systems by

using MDE techniques and DSLs. After the develop-

ment of dozens of DSLs and continuous requests for

new ones, it is clear that the process of DSL develop-

ment and maintenance needs a disciplined approach

supported by tools at a level beyond the usual language

ingredients. Languages are not ‘isolated islands’ any-

more, they answer business and technical needs at a

higher abstraction level, they are key players in the

automation of the engineering process.

In our practice, an engineer (usually an expert in

mechatronics or electronics but rarely in software de-

velopment) speciﬁes a solution in a DSL that reﬂects

a certain problem domain. It is known that such a

DSL requires a signiﬁcant amount of additional func-

tionality to allow the engineers to get conﬁdent in the

quality of their solutions and to produce an executable

solution. This functionality comes in the form of simu-

lators, test generators, translators to formal veriﬁcation

tools, and ﬁnally code generators.

Some of the tasks to obtain these functions are cur-

rently well supported. Language workbenches focus

on deﬁning language abstract and concrete syntax, gen-

eration of editors and possibly speciﬁcation of genera-

tors. Languages for specifying transformation chains,

such as MTC Flow (Alvarez and Casallas, 2013), aim

at automating the generation process. However, we

clearly identify the need of considering language devel-

opment at a higher abstraction level and in a broader

scope. Software architects need to know how code

generated from domain models ﬁts in the global soft-

ware architecture. System architects are interested in

how company problem domain is covered by a set of

related DSLs. Project managers make staff allocation

and training decisions based on the DSLs that will be

used as a development instrument. Finally, evolution

of languages may impact the existing software infras-

tructure. In order to address these needs an explicit

representation of languages and the relations to their

environment are needed.

We propose the concept of Language Architecture

as an organizational principle for designing, reusing

and maintaining DSLs and their infrastructure. Lan-

Brouwers N., Hamilton M., Kurtev I. and Luo Y.

Language Architecture: An Architecture Language for Model-Driven Engineering.

DOI: 10.5220/0006206001470156

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 147-156

ISBN: 978-989-758-210-3

147

guage architecture is a kind of megamodel (Bézivin

et al., 2005). Megamodels are models whose elements

denote other models. The initial idea of megamodeling

is to represent the relations among models, metamod-

els, and transformations between models. The pro-

posed concept of language architecture, as the name

suggests, is closely related to the idea of Linguistic

Architecture presented in (Favre et al., 2012). The goal

of the Linguistic Architecture is to make explicit the

linguistic structure of software systems: the involved

languages, software artefacts expressed in them and

their relations. The purpose of a language architecture

is to support the design of new languages and their

evolution at a more global level: to make explicit the

role of the languages in the engineering process and

the required tools. A language architecture is therefore

an additional view with language-centric focus that

is needed along with the well-known views used in

system architecture speciﬁcation. We do not limit the

applicability of this concept only to the software en-

gineering process but we apply it for any engineering

process in which DSLs are relevant.

In order to support the practical application of lan-

guage architectures, we developed a DSL based on

a metamodel for expressing such architectures. This

approach allows tool supported creation and analysis

of language architectures.

This paper ﬁrst describes the industrial challenges

we have experienced and that motivate our proposal

(Section 2). The main concepts in Language Archi-

tecture are explained and further structured in a meta-

model (Section 3 and Section 4). The metamodel

serves as a base for an initial tool support for the ap-

proach (Section 5). The paper concludes with position-

ing our work in the existing body of knowledge and

pointing to future research directions (Section 6 and

Section 7).

2 INDUSTRIAL CHALLENGES

Within a large industrial context multiple DSLs may

be developed, each capturing a particular subset of

the company’s domain of interest, a single concern of

the system being developed or a distinct activity in

the systems engineering process. Each of these lan-

guages provide a viewpoint, likely at different levels

of abstraction, to serve different stakeholders’ needs.

Consequently, with the increased application of

model-based engineering approaches and correspond-

ing automation of the engineering process, there is a

rapid growth of languages being developed in large

industrial software companies. This leads to a number

of challenges.

Lack of Language Centric View in the Engineering

Process.

DSLs and the associated generators are the

key instruments for automating engineering processes.

In an automated process the focus on artifacts that

used to be manually created is shifted more towards

the tools that perform the automation and artifact gen-

eration. DSLs and their infrastructures enter the area

of interest of new stakeholders. Once a critical mass

of languages is established, the evolution and main-

tenance becomes challenging tasks. Unfortunately,

awareness of the role DSLs fulﬁll in the engineering

processes is often not present or neglected. Further-

more, there is little support for establishing a language-

centric view over architectures and processes. These

factors ultimately hinder the stakeholders to access the

vital information they need. We discuss reﬁnements of

this challenge in the next paragraphs.

Capturing a Domain in Multiple Languages.

indicated above, multiple DSLs play a signiﬁcant role

in the engineering process or to capture the domain of

interest, each of them targeting a different set of stake-

holders. How to capture a large and complex domain

in smaller domains of interest by a set of stakeholders,

while ensuring the domain is completely captured?

How to ensure each of the stakeholders capture their

domain of interest consistently with related domains?

To address these questions, an overview on the level

across individual languages is helpful.

Impact Analysis Upon Language Evolution.

all software artifacts, languages evolve over time. The

evolution of languages is a complex subject in the

ﬁeld of model-driven engineering and is known as the

model/meta-model co-evolution problem (Mengerink

et al., 2016). With the current state-of-the-art of model-

ing tools, the evolution of languages, especially when

taking into account the impact on dependent compo-

nents such as generators, editors and existing models,

is a costly and error-prone process. As a result, it must

be carefully planned, executed, and validated. This

requires explicit representation of dependencies to the

evolving language thus allowing proper impact analy-

sis. Unfortunately, in many cases the inter-language de-

pendencies are not explicitly described, which makes

the impact analysis very hard.

Identiﬁcation of Modeling Software Platforms.

Automation of non-trivial steps in the engineering pro-

cess requires the development of advanced multi-step

transformations. A typical code generator to trans-

form a problem-oriented DSL into a working software

consists of several intermediate model levels in which

the last model level is transformed into executable

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

148

programs. When developing multiple transformations

within a given industrial context, reuse of interme-

diate model levels becomes feasible to achieve cost

reduction, higher quality and standardization. Such

intermediate model levels with corresponding code

generators become a standardized software modeling

platform that will play a signiﬁcant role to automate

software construction. Identifying such opportunities

for reuse is difﬁcult when transformation architectures

are considered internal and not publicly matched to

the engineering process.

Tool Integration in the Engineering Process.

the past, software was engineered with only a very

limited set of languages and tools. All aspects of a

software system, ranging from data management to

control behavior, from concurrency aspects to user in-

terface design, were often implemented using a single

programming language. Software engineering increas-

ingly becomes a discipline where tools provided by

different vendors need to be integrated into the engi-

neering process, each addressing only a subset of the

required aspects. Selecting the wrong tool results in

sub-optimal designs and implementations. Increas-

ing the amount of tools an engineer needs to interact

with increases accidental complexity. Finally, once

integrated in the engineering process, tools can hardly

be replaced with a competitor tool without having to

make large development costs. These three drawbacks

of integrating different tools need to be addressed by

an architectural level view on the engineering process.

What are the requirements imposed on tools to be in-

tegrated and what are the goals they need to fulﬁll?

How to integrate them in a ﬂexible manner to prevent

vendor lock-in? How to prevent accidental complex-

ity? These are some of the standing questions related

to this challenge.

3 MAIN CONCEPTS IN

LANGUAGE ARCHITECTURE

With the language architecture, we address the design

of automated engineering processes. We perceive an

engineering process as a collaboration of design pro-

cesses with the goal of constructing a system. Design

processes aim at specifying or changing (for example,

a refactoring of a software system) aspects of engi-

neering units. Engineering units are systems or parts

of systems. Generally, a design process uses a com-

bination of decomposition and reﬁnement activities.

Reﬁnement adds details to the speciﬁcation of an engi-

neering unit while retaining the original intention of

this (more abstract) unit.

In this paper, the term ‘process contribution’ de-

notes the architectural concepts needed to describe

such engineering processes. More concretely, these

can be languages, artifacts, human or automated trans-

formations, (sub)systems being constructed, tool envi-

ronments, and engineers. In the light of the language-

centric view on the engineering process, we are inter-

ested in the language aspects of any involved engineer-

ing process contribution.

Languages and their relations are the primary con-

cepts in the language architecture. Any process contri-

bution has to expose its relevant language aspects as an

interface. For example, a model checking tool should

explicitly state the formal language it supports, that is,

its interface states that the tool ‘consumes’ speciﬁca-

tions expressed in this language.

Figure 1 shows some of the main concepts in lan-

guage architectures depicted as a simple mind map. In

the following, we elaborate on these concepts.

Language: Deﬁnition and Application.

In an engi-

neering process humans often use natural languages to

communicate with each other. Such languages are very

complex and intuitive and are acceptable communica-

tion means at an abstract level. However, to automate

parts of the engineering process, we need to restrict the

used languages to formally deﬁned processable lan-

guages. In addition to that, the construction relations

between languages (such as composition (Clark et al.,

2015) and extension (Voelter, 2014)) and aspects of

realization technology also need to be expressed.

In order to deal with any language at an abstract

level, we pose no assumption on how languages are

deﬁned. Furthermore, a Language can potentially be

a group of languages. For instance, UML can be per-

ceived as an integrated collection of languages. Engi-

neers can express an interest in a subset, such as use

case and class diagrams.

Our approach to representing languages largely

follows the one taken by (Clark et al., 2015), though

there are some signiﬁcant differences due to our global

interest in specifying languages:

Concrete syntax

is not considered to be a deﬁning part

of the language. Concrete syntaxes can be attached

as an optional aspect.

Abstract syntax

needs a ﬂexible interpretation: for our

architecture we need a speciﬁcation of the most

signiﬁcant language concepts. Optionally, more de-

tailed language descriptions can be attached (OMG

standards, metamodels, etc.).

Static semantics

will be delegated to the referenced

language descriptions.

Language Architecture: An Architecture Language for Model-Driven Engineering

149

Figure 1: Main concepts in language architecture.

Meaning

is dynamic semantics of languages which

is enriched by a context. More details of this are

explained in the following paragraphs.

When working with languages, the context where

they are applied becomes relevant to the interpretation

of these languages. In fact, many languages have a

very limited priori semantics, which is enriched by

the context. A sentence like “the component is opti-

mized” could apply to software, but equally well to

economics, electronics and other domains. In a spe-

ciﬁc context, this sentence may even be sufﬁcient to

derive optimized behaviors. Likewise, although a Up-

paal speciﬁcation (Larsen et al., 1997) has a formal

semantics and can even be used to generate code, the

result becomes useful and gets a meaning only in a

given context. Even if some formal properties can be

proven, without a relation to context, we don’t know

whether the speciﬁcation refers to a washing machine

or a missile launcher.

The application of a language in a context thus spe-

cializes the language by implicitly adding a mapping

of language concepts to engineering concepts in this

context. This is a subtle reﬁnement of the language

that is usually never explicitly given in a formal way.

To capture the role of the context we introduce the con-

cept of Language Application along with Language

Deﬁnition. Language application refers to a language

deﬁnition but is always present for a given context.

A language can have properties that can help in

classifying its application. We select two key language

properties: role and abstraction level. Example lan-

guage abstraction levels are conceptual, logical, and

physical. Languages play different roles in an engi-

neering process. Example roles are:

’front-end’

: languages optimized for the engineers’

goals of developing systems;

intermediate

: languages used throughout (automated)

reﬁnement to represent aspects of the development.

Some intermediate languages are never used di-

rectly by engineers and may have no concrete syn-

tax;

decoration

: languages that can be used to drive the

realization process, for example, to customize code

generation;

formal languages : support formal analysis;

Reﬁnement of Language Architecture Speciﬁca-

tions.

An engineering process can be speciﬁed at

different levels of abstraction. Abstract speciﬁcations

are expected to be reﬁned by adding details to process

contributions while respecting their original intention.

We need to be able to express for every process con-

tribution the goal(s) of its presence. As a ﬁrst attempt

we choose to deﬁne the goals in natural language.

Language Architecture must be capable of captur-

ing the Reﬁnement process of the involved languages.

Imagine a process description in which we state that a

speciﬁcation is given in a state machine language with-

out further restrictions. A reﬁnement of the process

can state that UML state machines are used. Another

reﬁnement dimension concerns language implementa-

tion technologies. At some abstract level, a language

can be deﬁned by the concepts available in a domain

(a domain ontology). A technological reﬁnement is

to give a concrete language implementation using a

grammar or a metamodel.

Artifacts.

There are engineering contributions that

are not languages but just Artifacts used in the engi-

neering process. A typical example is a speciﬁcation

document. It may be a combination of models in dif-

ferent languages and natural text. When the artifact

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

150

is directly deﬁned by a language, we call it Language

Artifact. Other more complex artifacts (e.g. speciﬁca-

tion document, contributing libraries, reference data,

projects) can be deﬁned as compositions of artifacts,

some of them possibly being language artifacts. Fol-

lowing our goal to explicate every language aspect

of engineering contributions, it should be possible to

specify which languages are used in a composite ar-

tifact. It should be noted that in many cases there is

no need to make the existence of artifacts explicit. For

example, in a transformation chain where outputs re-

late to inputs it is not necessary to give concrete input

artifacts.

Transformations.

In design processes we observe

decomposition and reﬁnement. Both can be seen as

a Transformation. The input and output of transfor-

mations are speciﬁed by languages. A transformation

can be composed of other transformations arranged

in a ﬂow via intermediate languages. Again, we need

to reason transparently about a transformation being

potentially a group of transformations.

When we detail the properties of a transformation,

a language mapping concept can be used. The goal

here is not to exhaustively specify a transformation,

but to use an elementary way of describing what the

transformation should do, as an addition to the goals

we can deﬁne on any engineering process contribution.

Concepts in the Engineering Environment.

To re-

late the previously discussed process contributions to

actual deliverables of the engineering process or to any

other supporting tool we need to consider the context

or the environment of the process.

The main outcome of a process is a system or a sys-

tem component. As a motivating example for treating

systems as process contributions, consider data ob-

tained as a result of system calibration. The data can

be fed back in the engineering process and therefore it

is important to denote the system as a source.

Another important kind of engineering contribu-

tions consists of development tools. A model checker

that consumes formal speciﬁcations in a given lan-

guage is a tool that supports the engineering process

and is a part of the process environment. Again, the in-

terest is in the language aspects of the tools. We glob-

ally categorize process contributions into language

processing contributions and non-processing contri-

butions. They all expose languages as the relevant

interfaces, but the ﬁrst category can in addition expose

language interfaces with a direction. A Transforma-

tion is a kind of language processing contribution. An

Artifact is a kind of non-processing contribution.

Language processing contributions can be part of

the result of the engineering process itself. A system

that uses conﬁguration language to customize its oper-

ations is an example of the result of a process that is a

language processing contribution itself.

There are also language processing contributions

that support the engineering process, such as build

environments, test environments, etc. A kind of non-

processing contribution other than Artifact is a storage

environment like an archive.

General Organization of Language Architecture.

Until now we identiﬁed speciﬁc process contributions

and relations that we consider to be elements of lan-

guage architectures. We also apply several well-known

organizational principles when describing language ar-

chitectures. All process contributions require a group-

ing or encapsulation concept with the option to se-

lectively expose languages as interfaces. We propose

a construct inspired by components in UML and in

some architectural description languages. A compo-

nent may encapsulate a potentially complex internal

structure and if needed, can expose languages by using

a port-like construct. This Language Port can be used

to specify a language as an interface to the process

contribution. A directed variant of a port can be used

on processing components.

To connect elements, we need relations that have

references to the languages at their ends. There can be,

for example, a Flow relation from a language artifact

to a transformation via a language that is speciﬁed as

an input.

The issue of language compatibility arises when

using ﬂows that point to languages at their ends. Syn-

tactic compatibility may be derived from construction

relations, for instance, in case of a generalization, spe-

cialized languages will be compatible with their gen-

eral language. Syntactic compatibility is, however, not

always sufﬁcient. Semantic compatibility has to be

considered for the application context of the involved

languages. The concept of model typing (Steel and

Jézéquel, 2007) is also useful when resolving compati-

bility questions. Non-compatible connections imply a

need for a transformation.

4 APPLYING LANGUAGE

ARCHITECTURE IN PRACTICE

In this section we discuss aspects of applying the con-

cept of language architecture in practice. First, the

most important use cases are described based on our

experience (Section 4.1). They serve as drivers for

Language Architecture: An Architecture Language for Model-Driven Engineering

151

developing the tool support for language architectures.

Currently available tool is an editor for specifying lan-

guage architecture models. It is based on a metamodel

explained in Section 4.2.

4.1 Use Cases of Language Architecture

We identify a number of uses cases for language ar-

chitecture on the basis of the industrial challenges in

Section 2.

Deﬁne Engineering Process. The architect can de-

ﬁne the engineering process in terms of input/output

language(s), transformations, and engineering com-

ponents. Language architecture enables architects to

reﬁne or abstract parts of the architecture. Multiple

reﬁnements of an abstract entity can co-exist. A re-

ﬁnement tree can be derived for all components in the

architecture. Reﬁnement links support traceability of

language architecture elements, which in turn is the

enabling instrument for performing impact analysis

and assessments.

Analyze Language Architecture. As the language

architectures are captured in a processable form, they

can be analyzed to ﬁnd incompleteness, incompati-

bilities, redundancy, potential re-use, etc. Moreover

impact analysis on the architectures can be carried out

in case of the evolution of languages.

Validate language architecture The validity of lan-

guage relations and reﬁnements in a language architec-

ture can be checked. If needed, transformations could

be added or language choices may be reconsidered.

Extend Language Architecture. Depending on tech-

nology constraints and organizational choices, reﬁne-

ments can be created up to the level of physical lan-

guage or transformation deﬁnition units (such as ecore,

qvto, xml). In this case, the language architecture con-

cepts can be re-used or extended, for example in the

reference architecture deﬁnition (see Section 4.3). The

rules/considerations/guidelines can be deﬁned and as-

sociated with engineering process automation aspects.

4.2 Metamodel Design of Language

Architecture

Based on the concepts deﬁned in the language archi-

tecture description and the use cases, a metamodel of

language architecture is created.

Figure

ﬁg:lanarchiMM shows a snippet of the

metamodel, where a number of main concepts are

described. There are three types of components in

a language architecture: Artifact, ProcessingCompo-

nent, and LanguageDeﬁnition. As mentioned before,

Transformation, System, and Enviroment are all types

of processing components. A Language can be a Lan-

guageDeﬁnition or LanguageApplication. Moreover,

languages can be exposed via ports: LanguagePort

and DirectedPort. Finally, relations between languages

(LanguageRelation) can be expressed having language

references (ports, language deﬁnitions, language appli-

cations etc.) as relation ends.

4.3 Reference Architecture

Within a certain environment (e.g. a company), a num-

ber of choices are made concerning languages to be

used, technological aspects and processes that are fol-

lowed. These choices are often formulated as rules

that guide the engineering process. Examples of rules

relevant to language aspects are the deﬁnitions of ab-

straction levels, roles and choices of languages. Addi-

tionally, rules need to be deﬁned concerning technolo-

gies to apply, guidelines for tools, interfaces between

disciplines, connections to existing processes and oth-

ers.

We call a set of such rules a Reference Architecture.

The reference architecture provides the framework of

choices and guidelines to reﬁne language architectures

in a speciﬁc context. From a practical perspective, we

envisage that a reference architecture can be realized

as a library of engineering contributions that are reused

and reﬁned in language architectures.

Figure 3 shows the relation between language archi-

tecture and reference architecture. Multiple language

acrhitectures can exist in the framework of a single

reference architecture. They can be extended with

practical details such as the used build environments,

deployment strategies and other. In this paper, we only

focus on language architecture.

5 TOOL SUPPORT

In this section, the current implementation of an ed-

itor for language architectures (LanArchi Editor) is

described with a small example.

5.1 An Example of Language

Architecture for Model-based

Testing

The complexity of languages and relations can grow

rapidly even in a simple constellation, for example, a

Model-based Testing (MBT) product, which allows

generation of a test harness and a partial test suite

based on the speciﬁcation of a system. The goal of

this example is to transform an ASD (G.H. Broadfoot,

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

152

Figure 2: An extract of the metamodel of language architecture: only a number of main concepts are shown here.

Figure 3: Language Architecture and Reference Architec-

ture.

2005) model to a SpecExplorer (Veanes et al., 2008)

test harness. ASD provides a language for specify-

ing component interfaces and designs, and a tool that

checks the models for presence of deadlocks and live-

locks. SpecExplorer is a tool for model-based testing

based on .Net.

In order to design a small engineering process that

fulﬁlls the example task, we take the ASD “language”

with some additional test-related speciﬁcations as an

input and the SpecExplorer “language” as an output

from which the harness can be generated. In the previ-

ous statements the term language is in quotes because,

as we will see shortly, ASD and SpecExplorer are

technologies that expose more than one language. Fig-

ure 4 shows the main elements in this simple language

architecture.

To be more speciﬁc (Figure 5), we can further re-

ﬁne the elements in this language architecture. Both

input and output “languages” are sets of languages.

We make a distinction between the languages that pro-

vide the concepts used by engineers to build models

and the languages for serializing these models (re-

ferred to as Concepts and Storage respectively). To

ﬁll the gap between ASD models and SpecExplorer

tests, a transformation needs to be built. ASD models

are state machines that specify how an event is han-

dled for every state. We call this style state-centric.

SpecExplorer takes events as a leading concept speci-

fying reactions for every event. We refer to this style

as transition-centric. Therefore, in our example the

required transformation obtains a transition-centric

speciﬁcation from a state-centric one. This task is

generic and can be used for languages that adhere to

the mentioned speciﬁcation styles. We decided to built

a generic reusable transformation from technology neu-

tral state machine-like language (named System SM)

to transition-centric speciﬁcations for specifying test

suites. In this way we can deal with other pairs of

input and output languages apart from ASD and Spec-

Explorer. Instead of ASD, we can use UML state

machines or Excel state tables as inputs. Likewise, we

can vary the test harness by transforming to concep-

tually similar but technologically different tool-sets.

For instance, instead of SpecExplorer, Eclipse MBT

can be used as output. Moreover, the additional test

speciﬁcations are translated in parallel to SpecExplorer

‘cord’ scripts.

Figure 4: The abstract overview of our example: in this

diagram the high-level architecture is shown. There is a

transformation deﬁnition called ASD2Spec. This deﬁnition

has two input ports (System Speciﬁcation and Test Contribu-

tion) and one output port (TestSuite).

Language Architecture: An Architecture Language for Model-Driven Engineering

153

Figure 5: A screen-shot of the LanArchi editor: the left area is the drawing area where users can build their diagrams, the right

area is the palette area where a number of notations are given.

5.2 The Language Architecture Models

of the Example

With LanArchi tool, the architecture of our example

can be constructed in different abstraction levels. Fig-

ure 4 shows an abstract architecture of the example. It

provides a high-level view for users to understand the

overall architecture.

To show the detailed information of the architec-

ture model, a reﬁned version can be created. Figure 5

shows a screen-shot of the model in the LanArchi edi-

tor. There are two deﬁnitions of artifacts: ASD Speciﬁ-

cation and SpecExplorer TestSuite. Each one has a tool

set and concepts of the corresponding language. By us-

ing several chained transformations (shown as arrows

or as boxes for a reiﬁed view), ASD Storage can even-

tually be transformed to SpecExplorer Storage. The

ﬁgure also shows the intermediate languages (System

SM and Test Suite) and the possibility to use differ-

ent inputs (UML StateMachine) and outputs (Eclipse

MBT).

6 FUTURE DIRECTION

The presented work on language architectures is ongo-

ing and can be extended in several directions concern-

ing the underlying concepts and the toolset.

Language Architecture Assessments.

When an en-

gineering process is expressed in a language architec-

ture, it can be assessed if it satisﬁes certain criteria.

Examples of criteria on engineering contributions are:

•

Maturity level to identify the degree of automation

or weak spots in the engineering process. Stake-

holders might use this information for planning

further process automation or to estimate project

risks.

•

Inventory of knowledge and expertise levels to plan

personnel trainings.

•

KPIs such as generated line of code (LOC) and

number of clients as a means to evaluate business

cases.

Language Architecture Patterns.

In order to sup-

port language reuse and variability modeling, language

architecture patterns can be developed to address qual-

ity attributes such as interoperability (prevent vendor

lock-in), development costs, extensibility, scalability,

maintainability.

7 RELATED WORK

As already mentioned, the concept of Language Archi-

tecture is a form of megamodel, i.e. a model where

some model elements refer to other models. There

exist several applications of megamodeling for differ-

ent purposes. (Iovino et al., 2012) use megamodels

to depict dependencies among models that need to be

considered during model co-evolution. (Diskin et al.,

2013) propose a graph-oriented view on megamodels

and analyze the meaning of edges and vertices. The

goal is to make explicit the meaning of relations among

the models instead of treating them just as a graph edge.

Linguistic architecture approach (Favre et al., 2012)

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

154

aims at making the relations between software arte-

facts and their languages explicit. This approach also

puts forward the idea that a linguistic architecture is

a speciﬁc view that should be considered along with

other views used in architecture descriptions.

Our approach shares commonalities with some of

these works: language architectures should support in

dealing with coupled evolution of models and indeed,

we perceive them as views over existing software ar-

chitecture, engineering process descriptions, and even

enterprise architecture. Our driving concern for deﬁn-

ing language architectures is to make an explicit repre-

sentation of the role of languages in automating engi-

neering processes. One consequence is that languages

should be adequately described to serve the need of

different stakeholders.

The need of considering a signiﬁcant amount of

inter-related languages, the support for language reuse,

and presenting a language to different stakeholders are

among the challenges identiﬁed in a process called

Globalization of DSLs (Cheng et al., 2015) (Clark

et al., 2015). (Clark et al., 2015) deﬁne globaliza-

tion of DSLs as “purposeful construction, adaptation,

coordination and integration of explicitly deﬁned lan-

guages, to be amenable to mechanical and cognitive

processing, with the goal of improving quality and

reducing the cost of system development”. In our prac-

tice we face these challenges in the scope of large

companies and therefore our proposal contributes to

solving some of them. Furthermore, several concepts

found in the conceptual models in (Clark et al., 2015)

are also present in our metamodel.

8 CONCLUSION

The growing application of DSLs in non-trivial indus-

trial settings has a signiﬁcant impact on engineering

processes. Languages are the key enablers for engi-

neering process automation. Management needs to

understand the role of DSLs in relation to business

goals and to take them into account when resources

are allocated and people need to be trained. This calls

for a language-centric view on system and process ar-

chitecture descriptions. In this paper we proposed the

concept of Language Architecture and a metamodel

for a DSL in order to enable building such language

centric views.

With the support of language architectures, lan-

guage designers are aware of the main concerns that

need to be addressed during the design process: the

role of the language, the relations to its environment,

the purpose of the language tool support. Promoting

reuse of language components and fragments of trans-

formation chains is also a very important aspect of our

work. Furthermore, language architectures can assist

in the strategic planning of process automation based

on maturity assessment of process contributions.

Next steps for further development include profes-

sionalization of the tool and experimenting how it can

support the reported industrial challenges. From theo-

retical perspective we plan to align with the work on

DSL globalization in order to achieve better concep-

tual foundation for language architectures.

ACKNOWLEDGMENTS

We thank Mark van den Brand for his valuable com-

ments on the paper.

REFERENCES

Alvarez, C. and Casallas, R. (2013). MTC Flow: A Tool to

Design, Develop and Deploy Model Transformation

Chains. In Proceedings of the Workshop on ACadeMics

Tooling with Eclipse, ACME ’13, pages 7:1–7:9, New

York, NY, USA. ACM.

Bézivin, J., Jouault, F., Rosenthal, P., and Valduriez, P.

(2005). Modeling in the large and modeling in the

small. In Model Driven Architecture, pages 33–46.

Springer.

Cheng, B. H. C., Degueule, T., Atkinson, C., Clarke, S.,

Frank, U., Mosterman, P. J., and Sztipanovits, J. (2015).

Motivating Use Cases for the Globalization of DSLs,

pages 21–42. Springer International Publishing, Cham.

Clark, T., Van Den Brand, M., Combemale, B., and Rumpe,

B. (2015). Conceptual Model of the Globalization

for Domain-Speciﬁc Languages. In Combemale, B.,

Cheng, B. H., France, R. B., Jézéquel, J.-M., and

Rumpe, B., editors, Globalizing Domain-Speciﬁc Lan-

guages, volume 9400 of Lecture Notes in Computer

Science, pages 7–20. Springer International Publishing.

Diskin, Z., Kokaly, S., and Maibaum, T. (2013). Mapping-

Aware Megamodeling: Design Patterns and Laws. In

Software Language Engineering - 6th International

Conference, SLE 2013, Indianapolis, IN, USA, October

26-28, 2013. Proceedings, pages 322–343.

Favre, J.-M., Lämmel, R., and Varanovich, A. (2012). Mod-

eling the linguistic architecture of software products. In

International Conference on Model Driven Engineer-

ing Languages and Systems, pages 151–167. Springer.

Iovino, L., Pierantonio, A., and Malavolta, I. (2012). On the

impact signiﬁcance of metamodel evolution in MDE.

Journal of Object Technology, 11(3):3: 1–33.

Larsen, K. G., Pettersson, P., and Yi, W. (1997). UPPAAL

in a nutshell. International Journal on Software Tools

for Technology Transfer (STTT), 1(1):134–152.

Mengerink, J., Schiffelers, R., Serebrenik, A., and van den

Brand, M. (2016). DSL/Model Co-Evolution in Indus-

Language Architecture: An Architecture Language for Model-Driven Engineering

155

trial EMF-Based MDSE Ecosystems. In Workshop on

Model Evolution at MoDELS 2016.

Nierstrasz, O. (2016). The Death of Object-Oriented Pro-

gramming. In International Conference on Fundamen-

tal Approaches to Software Engineering, pages 3–10.

Springer.

G.H. Broadfoot (2005). ASD case notes: Costs and bene-

ﬁts of applying formal methods to industrial control

software. In Fitzgerald, J., Hayes, I., and Tarlecki, A.,

editors, FM 2005: Formal Methods, LNCS, vol. 3582,

pages 548–551. Springer, Heidelberg.

Steel, J. and Jézéquel, J.-M. (2007). On model typing. Soft-

ware & Systems Modeling, 6(4):401–413.

Veanes, M., Campbell, C., Grieskamp, W., Schulte, W.,

Tillmann, N., and Nachmanson, L. (2008). Model-

based testing of object-oriented reactive systems with

Spec Explorer. In Formal methods and testing, pages

39–76. Springer.

Voelter, M. (2014). Generic tools, speciﬁc languages. PhD

thesis, TU Delft, Delft University of Technology.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

156