Domain-Specific Languages

artifact which can either be a model again (model-to-model transformation) or an arbitrary textual artifact (model-to-text transformation).

Note thatMDSE, unlike round-trip engineering, is a strict forward en- gineering approach (though it can also be used for reverse engineering purposes). There is no need for synchronizing models and other imple- mentation artifacts because the models already are implementation artifacts. This implies that the modeling languages used in the context ofMDSEhave to be executable either by means of interpretation or through generation of source code from the model. If source code is generated from a model, changes are only applied to the model and the generated code is modified solely by means of re-generating it.

Some authors, like Brambilla et al. (2012), differentiate between two classes of modeling languages, namely domain-specific and general-purpose modeling languages. While the former are designed particularly for a cer- tain application domain or context, the latter can be applied to modeling purposes in any domain. Others, like Stahl and Völter (2006), view the concept ofMDSE as always being linked with the use of domain-specific modeling languages. They adopt this stance because they attribute the gains in productivity promised byMDSE to the domain-specificity of the applied modeling languages. Since for them, there is no need to contrast such languages with general-purpose modeling languages, they just speak of Domain-Specific Languages (DSLs). In this thesis, we adopt the perspective of Stahl and Völter (2006) and, accordingly, refer to such languages asDSLs.

2.2

Domain-Specific Languages

Like General-Purpose Languages (GPLs), such as C or Java, Domain-Specific Languages (DSLs) are programming languages. However, unlikeGPLs, which are designed to be able to implement any program that can be computed with a Turing machine,DSLslimit their expressiveness to a particular ap- plication domain. By featuring high-level domain concepts that enable to model phenomena at the abstraction level of the domain and by providing a notation close to the target domain,DSLscan be very concise. A popular example of a DSL are regular expressions that target the domain of text pattern matching and allow to model search patterns independently of any concrete matching engine implementation.

DSLscan be textual, graphical, or use a syntax that combines both tex- tual and graphical elements (which we call semi-graphical). In accordance with Völter (2013), we refer toDSLartifacts as models, code, and programs interchangeably, regardless of the concrete syntax of the language.

Another distinction amongDSLsis the one between external and internal languages. Internal or embeddedDSLsare implemented as libraries of exist- ingGPLsthat convey the impression of being independent languages by using programming techniques such as operator overloading (Czarnecki et al. 2004). An internalDSLcan be discerned from a mere Application Pro- gramming Interface (API) by the fact that a language does not only provide “vocabulary” (i. e., functions, data types, etc.), as anAPItypically does, but also provides a grammar (i. e., it prescribes how to combine the language elements to form larger expressions). In contrast to internalDSLs, external ones are completely independent languages with their own syntax designed from scratch.

The increased abstraction level ofDSLsand the reduced complexity of their source code is supposed to enhance productivity and quality during the implementation and maintenance of software in comparison toGPLs. While there are not many systematic studies of this claim, the few existing ones support this hypothesis (Kieburtz et al. 1996; Kosar et al. 2012).

2.2.1

Meta-Modeling

As with any other formal language, a DSLis defined by its concrete and abstract syntax as well as its static and execution semantics. While the concrete syntax defines the textual or graphical notation elements with which users of theDSL can express models, the abstract syntax of a DSL determines the entities of which concrete models can be comprised. These abstract model entities (abstract syntax) together with the constraints regarding their relationships (static semantics) can again be expressed as a model of all possible models of theDSL, which is therefore called the meta-model of the DSL. Since theDSLmeta-model embodies the structure of the target domain, it plays a critical role in the field of language engineering (Kleppe 2008). Gaševi´c et al. (2009) point out that meta-modeling bears great resemblance to the construction of ontologies and shares some of its inherent difficulties.

The meta-model of aDSLand its entities and relationships can, of course, again be described by a model, which is the meta-meta-model of the language

2.2. Domain-Specific Languages

Figure 2.1.The four levels of meta-modeling. Figure adapted from Stahl and Völter (2006).

(see Figure 2.1). Beginning with the “real world” information at the zeroth meta-level M0, each formal abstraction introduces another meta-level. We say that the model on level Mi describes or represents the model or the information on level Mi´1 and conforms to the model on level Mi+1. It is clear that such an abstraction process results in an infinite regress. For practical purposes, this infinite regress is typically handled by choosing a modeling language for level M3that is able to describe itself. Examples of such self-describing meta-languages areEBNF(ISO 14977 1996),EMFEcore (Steinberg et al. 2008), andMOF(Object Management Group 2015a).

The execution semantics of aDSLare defined by the model transforma- tions that are applied to it. A transformation can be described as a mapping from the meta-model of the source DSL to a target. If the DSLis directly executed by means of an interpreter, this target is the set of available ma- chine instructions, which directly constitutes the semantics. If source code is generated from theDSL, the target of the mapping is the meta-model of the target programming language (be it aDSLor aGPL). In this case, the semantics of the source DSLare defined in terms of the semantics of the target language.

2.2.2

Generation and Domain-Specific Platforms

In the context of this thesis, we only consider generation and not interpre- tation for makingDSLsexecutable. This means that for each target platform on which aDSLis supposed to run, a code generator must be provided to transformDSLmodels into source code either in anotherDSLor aGPL(for internalDSLs, the generation step is implicit). This approach of generating code in existing languages is efficient because it allows to reuse the low-level optimizations of existingGPLcompilers while introducing additional high- level Domain-Specific Optimizations (DSOs) that are independent of the target platform. For example, the generator of aDSLfor matrix-vector expressions could optimize computations based on recurring block structures of sparse matrices. Such optimizations are only possible at the level of theDSLgener- ator and not at the level of aGPLcompiler because the latter (necessarily) lacks any domain-specific concepts such as “block structure.” Following this approach, generators can be much simpler thanGPLcompilers but still create even more runtime-efficient applications.

To further reduce generator complexity, Stahl and Völter (2006) propose to not only provide a technical but also a domain-specific platform as the target for code generation (Figure 2.2). Since such a domain-specific platform already incorporates reusable “semantically-rich” domain components, transformations that target this platform are simplified.