Domain-specific Modelling

Domain-specific Languages(DSLs) have to deal with a reduced number of concerns when compared toGeneral Purpose Languages(GPLs) [69]. Examples for GPLs areGeneral Pur- pose Programming LanguageslikeJavaandCandGeneral Purpose Modelling Languages

like UML [114,165]. DSLs are applied in many different domains, such as grid comput- ing [217], finance [91], or business processes [161, 168, 207]. More extensive DSLs like

Modelica[170] orMEMO[67] offer development support for a multiple different domains. In [117] the benefits of using DSLs have been quantitatively evaluated with the result that a higher degree of efficiency, e.g. in terms of productivity, can be achieved. In par- ticular, DSLs are beneficial if a family of programs, e.g. the family of business processes, is addressed due to a possible reuse of artefacts. Additionally, languages for a specific do- main are typically of a higher abstraction level and thus shorter than their pendant con- struct in GPLs [114]. As a result, developers using a DSL can concentrate on creative tasks rather than repetitive tasks. The usage of models and DSLs have notably the same two advantages, i.e. reusability and higher abstraction level, as they are essentially two sides of the same coin. In the context of MDE DSLs are also calledDomain-specific Modelling Languages(DMSLs) and define a consistent set of rules which a domain-specific model has to conform to. With the adoption of DMSLs in the MDE concept the responsibilities can be split up into three different roles (see Figure2.25) [69]:

• The DSML Engineer defines the DSML, e.g. BPMN, and provides tools to create instances of this DSML, e.g. BPMN Modelling Tools.

• The Domain Expert uses the provided tools to define and manage her instances of the DSML, i.e. the domain-specific models. Examples of domain experts are

Business Process AnalystsorBusiness Impact Analysts.

• TheSoftware Expertis the one who actually implements and configures the devel- opment artefacts for a specific system. In some cases this step can be automated.

In this setup the domain-specific models are essentially used as means of communica- tion between domain expert and software expert. With the proposed sharing of respon- sibilities, domain experts can now be more closely involved in the development process without having to be skilled programmer themselves. The identification and attribute mapping process from the original object to the model is in general calledmodelling or

Domain-specific Modelling(DMS) in the context of MDE [159]. This is carried out by the domain expert.

The traditional understanding of modelling and models is based on"...an abstraction of reality in the sense that it cannot represent all aspects of reality" [196], i.e. modelling is a simplification process. Different to the traditional understanding of modelling, in Model-Driven Engineering models are not only simplifications of reality but formal input and output for computer-based tools and represent implementations of precise opera- tions [14]. To enable a consistent interpretation of models of the same domain they have to conform to the same DSML. Following the "everything is a model" paradigm of MDE, DSMLs are in fact models themselves describing the abstract syntax of domain-specific models and are in MDE literature usually calledmeta-models. To distinguish between relations in MDE, two basic types of abstractions exist [14]:

1. therepresented-by abstraction is used to define the relation between the original information (or system) and the model, and

2. theconforms-toabstraction is to define the relation between a model and its meta- model. Although, in a general sense a model is an instance of a meta-model, the instance-of term is not widely supported in MDE in order to avoid confusion with object-oriented principles.

Since a meta-model is also a model it needs to conform to a meta-meta-model which defines the abstract syntax of the meta-model. For this purpose, the Object Management Group (OMG) has defined a standard calledMeta Object Facility (MOF)[162]. It proposes a four-level architecture, shown in Figure2.26:

At the bottom level, the layer M0 is the original information, i.e. the real system. An example of such a system in terms of BPM is a enacted implementation of the business process in Figure2.2 on page14. Information on level M0 isrepresented by a model at the M1 level. With regards to the former M0 example, the actually executed online order process is represented by the online order BP model shown in Figure2.2. A model from the level M1conforms toa model in the meta-model layer at level M2. This layer permits modelling tools to operate with M1 models, e.g. editors for DSLs, such as the Process Composerof theSAP Netweaver BPM[287]. These tools require a formal specification of the abstract syntax of the M1 models they are handling. This specification is defined by the meta-model. Since the Online Order BP conforms to the BPMN language, BPMN is the BP’s meta-model and an example for a model in the meta-model layer M2. The abstract syntax of meta-models is defined by a meta-meta-model at the M3 level. Additionally, a

conforms-to represented-by Meta-Model Model Information Meta-Meta-Model conforms-to M3 conforms-to M2 M1 M0

Fig. 2.26 MOF layers - Meta-data Architecture proposed by OMG [162]

meta-meta-model has to conform to itself. The MOF standard defines a meta-modelling language called MOF2.0 [162], to which for instance the BPMN meta-model conforms to. Another more or less aligned variant of a meta-meta-model is theEcoremodel, used and defined in the Eclipse Modeling Framework (EMF) [225]. Throughout this thesis, MDE principles are implemented using the EMF toolkit/framework.