Guideline 23: “Align abstract and concrete syntax.” Given the concrete syntax, the abstract syntax and especially its structure should follow closely to the concrete syntax to ease automated processing, internal transformations and also pre- sentation (pretty printing) of the model.

In order to align abstract and concrete syntax three main principles apply: First, elements that differ in the concrete syntax need to have different abstract notations. Second, elements that have a similar meaning can be internally rep- resented by reusing concepts of the abstract syntax (usually through subclassing). This is more a semantics-based deci- sion than a structurally based decision. Third, the abstract notation should not depend on the context an element is used in but only on the element itself. A pretty bad exam- ple for context-dependent notations is the use of “=” as as- signment in OCL-statements (let-construct) and as equality in OCL-expressions. Here, the semantics obviously differs whilst the syntax is equal.

Furthermore, the use of a transformation engine usually also requires an understanding of the internal structure of a language, which is related to the abstract syntax. Therefore,

the user to some extent is exposed to the internal structure of the language and hence needs an alignment between his concrete representations and the abstract syntax, where the transformations operate on.

Alignment of both versions of syntax and the seamlessness principle discussed in [14] assures that it is possible to map abstractions from a problem space to concrete realizations in the solution space. For a domain specific language the domain is then reflected as directly as possible without much bias, e.g., of implementation or executability considerations.

Guideline 24: “Prefer layout which does not affect trans- lation from concrete to abstract syntax.” A good layout of a model can be used to simplify the understanding for a hu- man reader and is often used to structure the model. Nev- ertheless, a layout should be preferred which does not have any impact on the meaning of the model, and thus, does not affect the translation of the concrete to the abstract syntax and the semantics. As an example, this is the case for com- puter languages where the program structure is achieved by indentation. From a practical point of view, line separators, tabs, and spaces are often treated differently depending on editors and platforms and are usually difficult to distinguish by a human reader. If these elements gain a meaning, de- velopers have to be much more cautious and a collaborative development requires more effort. For graphical languages a well-known bad example is the twelve o’clock semantics in Stateflow [7] where the order of the placement of transitions can change the behavior of the Statechart. To simplify the usage of DSLs, we recommend that the layout of programs doesn’t affect their semantics.

Guideline 25: “Enable modularity.” Nowadays, systems are very complex and thus, hard to understand in their en- tirety. One main technique to tackle complexity is modu- larization [15] which leads to a managerial, flexible, compre- hensible, and understandable infrastructure. Furthermore, modularization is a prerequisite for incremental code gener- ation which in turn can lead to a significant improvement of productivity. Therefore, the language should provide a means to decompose systems into small pieces that can be separately defined by the language users, e.g., by providing language elements which can be used in order to reference artifacts in other files.

Guideline 26: “Introduce interfaces.” Interfaces in pro- gramming languages provide means for a modular develop- ment of parts of the system. This is especially important for complex systems as developers may define interfaces be- tween their parts to be able to exchange one implementa- tion of an interface with another which significantly increases flexibility. Furthermore, the introduction of interfaces is a common technique for information hiding: developers are able to change parts of their models and can be sure that these changes do not affect other parts of the system when the interface does not change. Therefore, we recommend that a DSL should provide an interface concept similar to the interfaces of known programming languages.