Designing and applying a domain specific modelling language appears to be quite simple: invent appropriate modelling elements and connectors, define their semantics in a legend and use them. The talk will show, that there are more aspects to consider and more steps to perform, and that it is necessary to deeply immerse into the domain in question. But the result is worth the effort. The work summarized in this extended abstract has been published in the ICTer 2015 proceedings by IEEE [MM2015]. There is an on-going discussion about the pros and cons of domain specific Modelling languages in comparison to the traditional generic languages like, for example, the Unified Modelling Language UML or the Business Process Model Notation BPMN. Certainly, generic languages have high merits due to their versatility in arbitrary domains as well as a broad body of experience and knowledge that has emerged from intensive use and research. On the other hand, such languages tend to follow the “law of logistic growth” by being continuously extended up to the point where complexity and lack of concept orthogonality corrupts transparency and makes the language hardly manageable for practical use. As an example, today's 17 (standard) and 8 additional UML 2.0 diagrams may lead to misunderstandings and user demotivation. In contrast to that a Domain Specific Modelling Language (DSML) is designed for exclusive use in a certain domain and there-in for specific purposes. Consequently it comes (a) with a lean set of modelling concepts and explicit constraints that are tailored for the particular domain and purposes and (b) with lexical/graphical notations that are familiar and/or easy to understand by the users in that domain. To use a DSML in practice requires, however, to embed it into a Domain Specific Modelling Method (DSMM), which features the procedure of how to apply the language as well as appropriate mechanisms to be used in such procedure. We present a guideline for how to create such a DSMM following [MM15], where we illustrated the process steps
by using the Human Cognitive Modelling Language (HCM-L)2 as a running example3. But the approach is generic enough to be transferred to other domains, in particular when (1) intuitive and thus easy understandability by model consumers is required, like by a country doctor about the processes in his practice, or a lawyer about his clients’ processes, or (2) individual human preferences in business processes, organizational or topological (e.g. buildings and rooms) structures have to be modeled. The talk will therefore focus on the DSMM process in general and touch some ideas for enterprise modelling. This summary only lists references that are not cited in the original paper; for all other sources, for an in-depth description, and for a comparison of our approach with that of Ulrich Frank, from which we started our considerations, please see [MM15]. 2
We propose to divide the DSMM creation process in five main phases (see Fig.1) which usually will have to be gone through iteratively: Preparation, Modelling Language, Modelling Process, Modelling Tool and Evaluation. a) Clarification of Scope and Purpose of the Language: the scope determines what should be a part of DSML’s meta-model or not, who are the future users, and for whom the textual/graphical notation should be readable. 2 HCM-L was developed for Modelling purposes in the domain of Ambient Assistance, and in particular within the framework of the Human Behavior Monitoring and Support (HBMS) project, where it serves to represent and reproduce episodic knowledge of a certain person without any loss. 3 This work was funded by the Klaus Tschira Stiftung gGmbH, Heidelberg
Creating a Domain Specific Modelling Method 17 b) Requirements Analysis: to reveal in detail all focal aspects to be potentially modeled. Domain specific standards, relevant literature and stakeholder know-how are important sources for this analysis; the results could be summarized in, e.g., usage scenarios or exemplary diagrams as part of the specification. c) Context Analysis: the domain specific context of the afore-mentioned focal aspects is usually relevant for a comprehensive capture of a domain. Therefore, all relevant contextual information should be collected and reflected regarding their possible usage in the model and typical use cases. As an example, it might be desirable in enterprise modelling to add business goals and requirements to enterprise architecture models [En11].
This phase concentrates on the language design and definition: a) Selection of a Base Modelling Language: there are many powerful (generic) modelling languages “on the market”; selecting one of these as a basis for deriving the modeling concepts of the intended DSML may reduce the overall effort. b) Language Specification: developing a meta-model by defining the syntax and semantics of the intended DSML. Relevant parts of the base modelling language could be included, irrelevant parts removed. c) Design of the Notation: based on the meta-model, an appropriate notation has to be defined. Mostly, this will be a graphical one for which Moody’s nine principles of designing cognitively effective visual notations should be observed. Experiments with stakeholders help to improve the notation’s readability. For enterprise modelling, e.g., [MRR10] recommend on the styles of labels, [KFS15] present an overview of the visual design of process model element labels.
Defines the process of using the DSML systematically for creating models by providing a stepwise procedure of how to act for modelers, e.g., what aspects should be modeled first, if there is more than one diagram type, with which one should be started.
A modelling language without tool is useless in practice. No matter if such a tool will be created from scratch or by adopting a meta-modelling framework, several steps have to be performed in order to end up with an appropriate solution: a) Tool Requirements Definition: regarding categories like methodology support, general software characteristics or documentation. b) Framework and Meta-Modelling Language Selection: the implementation of a modelling tool from scratch for an incrementally changing modelling language leads to challenges in the development process. Thus, adopting a meta-modelling 3
[En11] [KFS15] [MM15] framework is a more efficient choice which, however, inevitably includes the selection of the meta-modelling language to be used. c) View Definition: complex domains lead to complex models. For enabling users to manage such complexity, appropriate measures have to be provided. Usually this challenge is solved by providing various views on the complex content. d) Tool Implementation: the meta-model of the DSML is formulated using the metamodelling language of the selected framework. The implementation is based on the tool requirements specified in step a). e) Framework Dependent Add-Ons: additional functionalities of a given framework should be checked with regard to the requirements, e.g., coupling to external frameworks, simulation or analysis functions.
The evaluation of the created DSML and DSMM has to be carried out against the goals and requirements revealed in phase 1 in cooperation with the relevant stakeholders. Additionally, the quality issues (both, instances and meta-model) have to be evaluated. In the case of a DSML for enterprise modelling, Business Process Compliance (BPC) [RTD08] should also be evaluated in this step and, if needed, changes implemented. The presented approach to systematically developing a DSML/DSMM is based on our experiences made in the course of the HBMS project. We would like to discuss it with the EMISA community in order to further sharpen and improve the particular steps.
Engelsman, W. et al.: Extending enterprise architecture Modelling with business goals and requirements. In Enterprise Information Systems, 5; pp. 9-36, 2011.
Koschmider, A. et al.: A Comprehensive Overview of Visual Design of Process Model Element Labels: 4th Int. Workshop on the Theory and Application of Visualizations and Human‐ centric Aspects in Processes at BPM; LNBIB, 2015.