Towards knowledge interoperability between the UML, DMN, BPMN and CMMN models

. Development of modern software systems consists of many different phases, the sequence of whom is referred to as the software life cycle. During these phases, business analysts gather requirements from clients and try to design a system in order to fulfil these requirements. Software design of complex systems exploits various notations for representing knowledge about system structure and behaviour, decisions, processes and different cases. These elements are modelled using such graphical notations, maintained by Object Management Group (OMG), such as UML (Unified Modelling Language), DMN (Decision Model and Notation), BPMN (Business Process Model and Notation), and CMMN (Case Management Model and Notation). In this paper, we present our work-in-progress analysis of the current state of the art in knowledge interchange for these notations. Moreover, we identify the integration or interchange approaches in terms of application areas. Our goal is to provide an input for an integrated method of designing systems with the use of these notations.


Introduction
Software development of modern systems consists of many different phases. The sequence of them is commonly referred to as the software life cycle. However, there is no single life cycle model. The traditional software life cycle [1], the so-called waterfall model, assumes a standard sequence of phases without feedbacks, except the ones leading directly to the previous phase. The more advanced model is the spiral model [2], in which phases repeat in a spiral. These two models are presented in Figure 1. Agile software development [3] can be seen as an extension of the spiral model.
In software design, Unified Modelling Language (UML) [5] is the standard for modelling software applications. On the one hand, UML is universal. Different UML diagrams provide the method for capturing requirements, collaboration between parts of the software that realise them, the realisation itself and models that show how everything fits together and is executed [6].
On the other hand, there are more dedicated notations, such as Decision Model and Notation (DMN) [7], which provides diagrams for modelling decisions. Processes and cases are also modelled using Business Process Model and Notation (BPMN) [8] or Case Management Model and Notation (CMMN) [9]. These are the standards supported and maintained by Object Management Group (OMG).
The remaining parts of this are organised as follows: Section 2 gives the background of Software Engineering for further considerations. Section 3 provides the summary of the existing solutions in knowledge interoperability with these notations, and the paper is summarised in Section 4.

Software Engineering Preliminaries
Model Driven Architecture (MDA) [10] is a system development approach that increases the power of models in this process. MDA defines an architectural framework that supports detailed specification based on models. Such specifications should allow producing interoperable, reusable, portable software components and data models. The goal of MDA is to separate the design specification from the specific platform technology. Model abstraction layers constitute the core of MDA [10,11]: − Computation Independent Business Models (CIM) shows a system from the computation-independent viewpoint. CIM should use a business language in which specialised computer knowledge is unnecessary. − Platform Independent Models (PIM) shows a system from the computation-dependent viewpoint, which hides the details necessary for a certain platform. PIM defines a model that is independent of any implementation technology and fucuses on the operation of a system. − Platform Specific Models (PSM) shows a system from the platform-specific viewpoint, which focuses on the usage of a particular platform by a system. PSM specifies a system regarding the certain implementation constructs. − Code model specifies the code, usually in a high-level language.
UML is a general-purpose modelling language that provides abstract syntax rules and semantics. The current version defines a variety of UML diagrams, which are divided into two main categories: structure diagramsrepresenting the structure of a modelled application (Class, Component, Object, Composite Structure, Deployment, Package, and Profile Diagrams) and behaviour diagrams -representing general types of behaviour (Activity, State Machine, Use Case and four Interaction Diagrams). Although models used with MDA are often expressed using UML, it is not restricted only to this notation [12]. DMN [7] is a standard for decision modelling where a decision selects some option or determines the result based on some input data. There are two DMN diagrams: Decision Requirements Graph (DRG) and Decision Requirements Diagram (DRD).
BPMN [8] is the most popular notation for business processes representation. It uses a set of models to depict a process and how it is performed. It distinguishes four different types of diagrams: 1) Process diagramsdescribing the ways in which activities are carried out to accomplish the intended goals, 2) Collaboration diagrams -representing the collaborative public B2B processes, 3) Conversation diagrams -specifying the logical relation of message exchanges, and 4) Choreography diagrams -defining the expected behaviour between the interacting participants.
In the case of knowledge-intensive processes where activities do not form a well-structured business process but are rather conducted in an ad-hoc way, CMMN [9] is a better choice. It provides a declarative way of modelling cases and visualising the events that may happen in the context of a case, the tasks involved, the milestones, etc. Such various activities may be performed in an unpredictable order in response to evolving situations.

Knowledge interoperability
Based on the analysis of the literature, we selected the most relevant papers describing knowledge integration or knowledge interchange approaches concerning any two of the UML, DMN, BPMN or CMMN notations.
In Tables 1 and 2, we present the overview of the identified integration or interchange solutions, which can be used for various purposes such as (the list is an extended version of the list proposed in [21]): − Model Verification -the provided solution can be used for formal verification of the model or is suitable for formal checking, − Model Validation -the solution can be used for validating the requirements or manual compliance checking, − Impact Analysis -the solution is suitable for analysis of impact, − Model Refinement -the solution can be used for refinement or refactoring of the used models, − Knowledge Translation -the solution is suitable for translation of knowledge between diagrams, − Model Understanding -the solution may improve understanding of the models, − Model Formalisation -the solution provides some way of formalisation, − Safety/Security Assurance -the solution can be used for assuring safety or security.
The goal of the provided analysis is to constitute an input for an integrated method of designing systems with the use of these notations. Taking into account how many solutions for knowledge interchange between two notations exist, the order of using these notations in a project can be determined. For example, if model verification is an essential issue in the project, one can count how many solutions used for model verification exists in translation from one notation to another. Then, building a graph like in Fig. 3, but concerning the specific application area, it is possible to calculate the maximal traceable path (Hamiltonian path) or maximal spanning tree. However, for practical usage, an in-depth analysis of each solution is needed. For each solution, specific diagram interchange should be determined. Subsequently, based on particular diagrams, determining a path between them can be beneficial.

Conclusion
In this paper, we presented an overview of knowledge interchange between UML, DMN, BPMN and CMMN models. Based on these results, we outlined a possible method of determining which diagrams should be used in which order. Our future research will be focused on providing guidelines for using these notations depending on the phase of the project, modelling needs and the list of models already specified. Thanks to such guidelines, it will be possible to provide a new method for software engineering taking into account the knowledge interchange between the diagrams.