Flexibly deployable control devices are often hard to configure, since their inter-faces are very complex. System contexts are not known, and parameterization iserror-prone. The Fraunhofer Institute for Experimental Software Engineering (IESE) shows how domain-specific languages offer a solution. By formally combining the rules for parameterization and encapsulating them together with the semantics from the application domain, configurations can be specified easily and generated consistently.

MASTERING COMPLEX CONFIGURATIONSWITH DOMAIN-SPECIFIC LANGUAGES

DR. THOMAS KUHN is Senior Engineer Work-

ing on Issues of Model-driven Software De-

velopment in Embedded Systems at the Fraun-

hofer Institute for Experi-mental Software Engi-

neering (IESE) in Kaisers-lautern (Germany).

DIPL.-INF. RALF KALMARis Business Area Manager

for Automotive andTransportation Systems

at Fraunhofer IESE inKaiserslautern (Germany).

DIPL.-INF. CHRISTIAN SCHÄFER

is Scientist in theEmbedded Systems De-partment at Fraunhofer

IESE in Kaiserslautern(Germany).

THORS

RESEARCH SOFTWARE

40

1 GAIN IN EFFICIENCY

Model-driven software and systems development is often associ-

ated with powerful and complex modeling languages such as UML

or Simulink. The range of use of these languages is very broad –

developers must be trained before they can effectively and produc-

tively use these systems with all their possibilities. In addition,

there will always be concepts that cannot be optimally described

using these generic modeling languages.

These are the reasons why a new trend towards domain-specif-

ic languages (DSLs) has emerged in recent years. DSLs are spe-

cifically developed to meet the requirements of the users and

therefore provide optimal support for the necessary forms of

description and levels of abstraction. Furthermore, their use is

intuitive for the respective experts, since they map concepts that

are already known and well mastered in the domain – extensive

training is thus not required. Our experiences show that increases

in productivity by a factor of 5 to 10 can often be achieved.

2 DOMAIN-SPECIFIC LANGUAGES: OPTIMIZATIONS DURING THE LAST YEARS

Domain-specific languages form a bridge between application ex-

perts and development tools; users do not need programming skills,

but can rather directly and exclusively use the concepts of their

domains when describing the solution to a problem. Examples of

domain-specific languages that have been successful for many years

include SQL for database queries, LaTeX for text layout, or com-

pany-specific languages such as KRL for robotic programming. In

contrast to general modeling languages, domain-specific languages

have a much closer focus and are customized precisely to one prod-

uct as well as to the way of thinking and the knowledge of the

domain experts, who therefore easily find their way around the

concepts of these languages. Hence, domain-specific languages

offer specially adapted and usable solutions for specific tasks.

Generic modeling languages, on the other hand, address a multi-

tude of task types, but rarely fit a concrete problem exactly.

A domain-specific language must support its users with clear

and intuitive concepts. Inconsistencies and too many alternative

and mixed concepts within one language are counterproductive.

In addition, such a language must be usable – the best language

concept is worthless unless it is supported by tools in such a way

that developers will like to work with it. For a long time, this

constituted a problem for the development of domain-specific

languages – making adapted development tools available was so

expensive that the development of a DSL for a specific problem

was not economically feasible.

However, unlike a few years ago, it is now possible to develop

one’s own domain-specific language including the necessary

modeling tools with relatively little effort. This DSL can then be

used to increase the productivity of one’s development, to encap-

sulate professional knowledge in a reusable manner, or to offer

support staff and customers a comfortable way for configuring or

programming one’s own products. To create a language, a series

of freely available and commercial tools can be used. Generators

are used to automatically implement the models created via a DSL

into error-free configuration files or program code. The advantag-

es are obvious: Development costs and times are reduced and qual-

ity is increased significantly. Domain-specific languages can be

used in a large variety of areas: They are excellently suited for

configuring complex systems such as control devices, machine

controls, or monitoring systems. Wherever similar systems must be

developed or configured frequently, the use of domain-specific

languages pays off.

In the following, the concepts of domain-specific languages as

well as the process of language development will be presented

using a DSL, which is kept very simple, for modeling normative

requirements on vehicle lighting as an example. The goal of this

DSL is to be able to model the configuration of a concrete case of

vehicle lighting during the requirements definition, taking into

account country-specific legal constraints regarding daytime run-

ning lights.

3 HOW TO DEVELOP A DOMAIN-SPECIFIC LANGUAGE

In order to make the development of DSLs more uniform, a DSL

development method was developed at Fraunhofer IESE that pro-

vides for artifacts and activities specifically adapted to language

development. The development of a DSL happens in four steps,

which are illustrated in . In the following, the individual steps of

this development method will be described in greater detail.

An implementation for exterior vehicle lights with due consider-

ation of different national variants shall serve as an example. To

facilitate maintainability, we will consider normative requirements

and functional (customer) requirements separately and later dem-

onstrate how such an integration of multiple languages works. To

keep matters simple, we limit ourselves to the aspect of daytime

running lights.

3.1 DEFINING THE REQUIREMENTS

When a domain-specific language is to be developed, its purpose

must first be determined. Here, it is important to take into account

1 GAIN IN EFFICIENCY

2 DOMAIN-SPECIFIC LANGUAGES:

OPTIMIZATIONS DURING THE LAST YEARS

3 HOW TO DEVELOP A DOMAIN-SPECIFIC LANGUAGE

4 WHEN IS A DSL WORTH THE EFFORT?

5 SUMMARY

Development steps for adomain-specific language

4103I2010 Volume 5

that a language is used to solve a precisely focused problem. DSLs

that are designed too broadly and cover too many different prob-

lems quickly become very complex and are then no longer easy to

use. There is also a risk that too many compromises must be made

during the development of the language and that the language de-

veloped in this way will no longer be an exact fit for the problems

to be solved. In this case it makes more sense to develop several

DSLs in a modular fashion.

The development method we have defined encapsulates the

central requirements on a DSL by means of use cases. When

developing a language, one of the first activities is therefore to

conduct interviews with the envisioned users of the language. They

define which activities the language shall support. Use cases can

be refined hierarchically – for example, both country-specific regu-

lations and international standards define regulations regarding the

color of the light. The “include” directive of use cases defines that

one activity includes another one. For example, the definition of one

regulation includes, among other things, the definition of which light

color is permissible. shows an example of activities that a devel-

opment engineer would perform using a DSL in order to define

regulations and standards regarding daytime running lights.

The knowledge regarding which roles will use a DSL is essential

and differentiates DSLs from general modeling languages ( right

side). Roles determine workflows to be supported, the language

elements, and their presentation.

Furthermore, the use cases frequently already define important

language elements. Use cases defining a standard or a country, for

example, imply a need for the language elements “standard“ and

“country“.

3.2 DEFINING THE LANGUAGE

This activity constitutes the core of the DSL development. It

comprises the definition of the meta-model of the language and

the definition of the (role-specific) presentation of the language

elements.

During the development of a domain-specific language, three

aspects must be defined, namely meta-model, presentation, and

generator (see box).

3.2.1 META-MODEL

The meta-model of a DSL, which is often also called an abstract

syntax, determines the structure of the language, i.e., it defines

the permitted language elements, their attributes, and the possi-

ble relationships among them. It thus provides the grammar rules

for the DSL. In addition, it defines how the information described

by means of a DSL is stored in a data structure. Meta-models

describe the abstract syntax of a language.

3.2.2 PRESENTATION

The presentation determines how elements of the meta-model are

actually presented to the user. Here, a graphical representation is

possible, as is a textual or tabular representation. Since the presen-

tation is the interface of the DSL with the user, it is essential that

it is customized to his or her needs. In the case of complex languag-

es with many language elements or languages used by many differ-

ent people, it is therefore quite common to define several presenta-

tions for the same meta-model, which satisfy the different workflows

and needs of the respective users. Thus, different views of the same

model are created. The presentation of a DSL is a concrete syntax

of the language – one DSL can have several presentations.

3.2.3 GENERATOR

Generators are used for generating additional artifacts from a

domain-specific model. They are based on the meta-model of a

language and are hence independent of the requirements of any

particular user. They rather realize technical requirements exist-

ing in the interface between a DSL and other tools. The form of

the output created may vary. Often, generators are used, for exam-

ple, to generate source code in another programming language,

such as C, C++ or Java, which can then be further processed by

Use cases in thedefinition of require-ments on daytime run-ning lights (simplified)

RESEARCH SOFTWARE

42

existing compilers. Transformations into proprietary XML formats,

for instance for configuration files or file formats of other mode-

ling languages such as Simulink, are conceivable.

The meta-model of the language is developed on the basis of

the language elements identified by the use cases. It may contain

further elements that do not show up in the use cases. Meta-

models structure the elements of a domain-specific language and

describe which language elements may be used when and which

elements can be put in relation to others. Furthermore, meta-

models define additional attributes of language elements that de-

scribe these in greater detail. illustrates the meta-model of a

DSL for the specification of daytime running lights.

A meta-model defines all language elements of a DSL. Differ-

ent types of language elements can be distinguished – here, ge-

neric elements, enumerations, and relations are shown. Attributes

describe language elements – in the example, the name of the

country is shown as an attribute. Relations are used to define de-

pendencies. Examples include specializations and aggregations.

Based on the meta-model and the requirements, one or several

presentations of the language are defined. Several basic forms of

presentation exist for a DSL: graphical, textual, or tabular. It is al-

so possible to offer several different forms of presentations. There

are no universally valid regulations regarding the design of pres-

entations, but some rules have proven useful in practice:

Graphical presentations are very well suited for quickly grasping

contexts. This form of presentation is especially suitable for lan-

guages with low complexity, for describing contexts, and/or for

enabling developers, support staff, and users to gain fast access

to the language.

Textual forms of presentation enable trained experts to work very

productively. However, users require more time to completely

grasp the presented information. The presentation is less intui-

tive than a graphical presentation.

Tabular representations are suitable for DSLs that operate with

many similar elements. Requirements specifications, for exam-

ple, can be presented very efficiently in this manner.

3.2.4 IMPLEMENTING THE GENERATOR

In our DSL development approach, the implementation of the gen-

erator is based on generator components. For this purpose, integra-

tion rules and templates exist for common output formats, which

makes it possible to reuse mappings that have been defined once –

for example to XML, to C, or to Simulink. This significantly reduc-

es the error-proneness of the generator and thus also the develop-

ment effort needed for developing a DSL. The implementation of

the generator generally uses common 3GL languages as well as

available generator frameworks and interfaces of proven develop-

ment environments, such as Ascet SD, Simulink, et cetera.

3.2.5 VALIDATING THE DSL

A DSL must be validated on the basis of the requirements for-

mulated by the domain experts. This validation is performed in

analogy to the validation of software systems, e.g., based on

scenarios developed during the requirements definition.

3.3 TOOL LANDSCAPE

The success of a domain-specific language strongly depends on

its acceptance by the users, which again strongly depends on the

:

:

:

quality of the used tools. When using domain-specific languages,

one does not need to do without the convenience offered by estab-

lished development environments. The following list provides an

overview of some existing tools and their areas of application:

MetaEdit+” is a commercial environment for the development

of DSLs that supports meta-modeling and a multitude of pres-

entation forms.

The Eclipse Graphical Modeling Framework (GMF) is an open-

source environment that, in combination with the Eclipse

Modeling Framework (EMF), also enables the definition of graphi-

cal domain-specific languages. By using additional Eclipse

plugins, support for text-based DSLs can be added.

UML development tools can often be adapted to new task areas

by using profiles, and can thus also be used to implement DSLs.

Some UML tools already offer integrated DSL development

environments allowing further adaptation. MagicDraw is one

example of such a tool.

The Microsoft DSL tools allow the definition of graphical and

text-based DSLs based on the Visual Studio tools.

Overall, we can conclude that there is sufficient support for pro-

fessional usage.

3.4 MULTI-LANGUAGE INTEGRATION

Domain-specific languages have a narrow focus. Complex systems

can therefore not be described using just one single DSL. Multi-

language integration is a technology that enables the combination

of different DSLs with each other. In the example shown here, the

information that was modeled regarding the legal requirements on

daytime running lights is used to model the behavior of a vehicle’s

general lighting system. The structure of the lighting system is al-

so defined via a DSL – a simplified meta-model of such a DSL is

shown in . It is not absolutely mandatory that a vehicle have spe-

cific daytime running lights. If a certain model is missing these,

then the low-beam lights can be used for this purpose, for example,

provided that country-specific regulations are still adhered to.

The defined behavior of the lighting system – here abstracted

by the block “Behavior” – defines the different states that the

driver can select. By means of mapping rules, the information

modeled via the requirements on daytime running lights is now

:

:

:

:

Example meta-model for the definition of the requirements on daytime running lights

4303I2010 Volume 5

combined with the model of the lighting system. For example, day-

time running lights can be realized by using dimmed headlights,

provided that modern LED lights are used.

The integration of different modeling languages is generally

achieved by means of integration rules. In our example, these in-

sert a suitable behavior into the state machine describing the be-

havior of the lighting element, . Here, it is necessary to take in-

to account that these integration rules must know the meta-class-

es of both languages. The use of standardized meta-models makes

it possible for language integrations to be reused.

4 WHEN IS A DSL WORTH THE EFFORT?

Whether or not to invest into the development of DSLs of one’s own

must be carefully studied in advance. However, depending on the

usage conditions, the higher initial investment for the development

of a DSL may already pay off after a short time. Therefore, the

development of a DSL may even make sense for smaller projects.

Our experiences show that different criteria are instrumental for

a DSL to be used successfully. These criteria are summarized in

the checklist below:

The usage environment (domain) can be clearly delimited.

The usage purpose of the DSL is focused.

Experiences exist in the application domain.

Commitment in the domain is long-term.

Several products/product variants with common functionalities

are being developed.

As soon as four out of five criteria apply, it becomes highly prob-

able that the use of DSLs will be profitable, since the costs saved

by using the DSL will most probably exceed the initial costs for

developing the DSL.

:::::

5 SUMMARY

Domain-specific languages are a means for counteracting the

increasing complexity in system development and the growing

development effort. Modern tool environments make it feasible

to develop one’s own domain-specific languages. Model-based

development with DSLs allows generating specifications for dif-

ferent targets all the way to hardware-specific object code. The

DSLs developed to date by our customers have shown productiv-

ity increases by a factor of 5-10. With the help of methods for

multi-language integration, the use of DSLs can also be benefi-

cial in heterogeneous system environments, so that the technol-

ogy also has multiple uses in automotive technology.

Multi-language integration calls for integration rules that are

adapted to the meta-models. One current challenge is the standard-

ization of meta-models for general concepts in application domains

describing, for example, lighting systems, chassis systems, or en-

gine control systems on an abstract level. This would enable much

better reuse of language integration rules than today. Since it is dif-

ficult to find a generally valid abstraction level for the meta-mod-

els, DSLs will have to prove their potential within individual compa-

nies first, before we can arrive at an integration platform – similar

to Autosar – that can be used across companies. This is an area

where more research and pre-development work is needed.

REFERENCES[1] Höwing, F.: Effiziente Entwicklung von Autosar-Komponenten mit Domän-enspezifischen Programmiersprachen. GI Jahrestagung (2) 2007: S. 551-556[2] Krahn, H.; Rumpe, B.; Völkel, S.: Mit Sprachbaukästen zur schnellerenSoftwareentwicklung: Domänenspezifische Sprachen modular entwickeln.In: OBJEKTspektrum Heft 4, 2008[3] Kelly, S.; Tolvanen, J.-P.: Domain-Specific Modeling – Enabling Full CodeGeneration, John Wiley & Sons, Inc. 2008

Simplified meta-model for defining the structure of a lighting system

Simplified behaviorof a lighting system

RESEARCH SOFTWARE

44