Guideline 1: “Identify language uses early.” The language defined will be used for at least one task. Most common uses are: documentation of knowledge (only) and code ge- neration. However, there are a lot more forms of usage: definition or generation of tests, formal verification, auto- matic analysis of various kinds, configuration of the system at deployment- or run-time, and last but increasingly im- portant, simulation.

An early identification of the language uses have strong in- fluence on the concepts the language will allow to offer. Code generation for example is not generally feasible when the language embeds concepts of underspecification (e.g., non- deterministic Statecharts). Even if everything is designed to be executable, there are big differences regarding the over- head necessary to run certain kinds of models. If efficient execution on a small target machine is necessary (e.g., mo- bile or car control device) then high-level concepts must be designed for optimized code generations. For simulation and validation of requirements however, efficiency plays a minor role.

Guideline 2: “Ask questions.” Once the uses of a language have been identified it is helpful to embed these forms of language uses into the overall software development process. People/roles have to be identified that develop, review, and deploy the involved programs and models. The following questions are helpful for determining the necessary decisions: Who is going to model in the DSL? Who is going to review the models? When? Who is using the models for which purpose?

Based thereon, the question after whether the language is too complex or captures all the necessary domain elements can be revisited. In particular, appropriate tutorials for the DSL users in their respective development process should now be prepared.

Guideline 3: “Make your language consistent.” DSLs are typically designed for a specific purpose. Therefore, each feature of a language should contribute to this purpose, oth- erwise it should be omitted. As an illustrative example we consider a platform independent modeling language. In this language, all features should be platform independent as well. This design principle was already discussed in [14].

2.2 Language Realization When starting to define a new language, there are several options on how to realize it. One can implement the DSL from scratch or reuse and extend or reduce an existing lan- guage, one can use a graphical or a textual representation,

and so on. We have identified general hints which have to be taken into account for these decisions.

Guideline 4: “Decide carefully whether to use graphical or textual realization.” Nowadays, it is common to use tools supporting the design of graphical DSLs such as the Eclipse Modeling Framework (EMF) or MetaEdit+. On the other hand, there exist sophisticated tools and frameworks like MontiCore or xText for text-based modeling. As described in [6], there are a number of advantages and disadvantages for both approaches. Textual representations for example usually have the advantage of faster development and are platform and tool independent whereas graphical models provide a better overview and ease the understanding of models. Therefore, advantages and disadvantages have to be weighted and matched against end users’ preferences in order to make a substantiated decision for one of the real- izations. From this point on, a more informed decision can be made for a concrete tool to realize the language based on their particular features and the intended use of the lan- guage. Comparisons can be found in [21] or [3].