Knowledge-intensive processes require exibility and scalability in modelling, as well as profound integration of data and decisions into the process. Business Process Model and Notation (BPMN) is a pertinent modelling method for processes. Until lately decisions were regularly modelled as a part of the process model in intertwined paths and gateways, negatively a ecting the maintainability, comprehensibility and exibility of processes as well as decisions. The recent introduction of the Decision Model and Notation (DMN) standard provides an opportunity for shifting in favour of a Separation of Concerns between the decision and process model. Likewise, the Case Management Model and Notation (CMMN) standard provides a method for modelling loosely structured processes in the form of cases. These three Object Management Group (OMG) standards are developed to be mutually intelligible. Previous work discusses for which modelling endeavours the separate methods should be employed. However, a clear approach towards consistently integrating the process, case, and decision concerns has still not been proposed. In this paper, we shed a light on the importance of the separation of concerns and identify inconsistencies that might arise in terms of integrated process, case, and decision modelling. Additionally, we provide a rst attempt at guidelines aiming to remedy potential incompatibilities and inconsistencies.
An increased interest in modelling cases and decision is present in scienti c work in the eld of process management, as illustrated by the vast body of recent literature on Decision Model and Notation (DMN) [1{5], and Case Management Model and Notatin (CMMN) [6{12]. With these two recently introduced OMG standards it has become possible to externalise decisions and cases from the master process and to model them separately according to the Separation of Concerns paradigm, hence enhancing the understandability, scalability, and maintainability of processes, as well as the underlying decisions and case models. ? Corresponding author.
Decision Model and Notation is a standard for modelling decisions. DMN
consists of two levels. Firstly, the decision requirement level in the form of a
Decision Requirement Diagram (DRD) is used to portray the requirements of
decisions and the dependencies between the di erent constructs in the decision
model. Secondly, the decision logic level is used to specify the underlying
decision logic. The standard also provides an expression language S-FEEL (Simple
Friendly Enough Expression Language), as well as boxed expressions and
decision tables for the notation of the decision logic. Representing decision logic in
decision tables is a core concept in DMN. Decision tables have extensively been
adopted in previous works, as shown in [
Credit Eligibility
Risk Level Background Check
Financial Check ID/Passport
Police Records
Financial History
Income
CMMN is a standard for modelling loosely structured processes or parts of
processes, i.e. cases. Cases are usually resolved ad hoc, requiring exibility during
run-time in terms of planning, executing and ordering of tasks. Hence, cases
are more about unstructured, non-routine work done by knowledge workers, or
activities that are not prede ned, depending on the situation at hand. This is
in contrast with a structured and routine process such as those modelled with
BPMN. Instead of a procedural character, cases are more suitable for declarative
and loosely structured ows. Typical applications for case modelling revolve
around knowledge-intensive and non-predictive areas such as patient care in
health and hospital processes. Figure 2 gives an example of a CMMN model
for claims handling. The model exists of one case le, i.e Claims File, which
contains stages, events, milestones, (discretionary) tasks, entry and exit criteria,
and planning tables. For a full understanding of these constructs, we refer to the
Case Management Model and Notation standard speci cation [
This paper is structured as follows. In Section 2, a brief overview of relevant decision and case modelling approaches from literature is provided, followed by Section 3 where the separation and integration of modelling concerns is elucidated. Section 4 outlines challenges of integration by providing possible inconsistency concerns which should be remedied in future work. This section discusses the integration from a pairwise point of view, i.e. processes and decisions, processes and cases, and nally cases and decisions. Inconsistencies are enumerated and remedies for the inconsistencies are suggested. Finally, Section 5 provides conclusions and possibilities for future work.
DMN was meant mainly for business users and both the scienti c and business
communities have given quite some attention to the DMN standard. However,
most research in the eld revolves around automated discovery of decision
models [
The decision modelling approaches present in process management literature
often breach the separation of concerns between control and data ow, resulting
in cascading gateways and spaghetti-like processes, hence negatively in uencing
maintenance and reusability [
When it comes to case modelling, little research has been performed so far on the topic [6{12], especially when it comes to de ning how case models are related to processes and decisions. Other declarative process notations and their relation to data and decisions were discussed in literature, such as the Declare language and its extensions for data- and decision-awareness [16, 25{27]. 3
Literature has focused little on soundly integrating process and decision models.
The DMN standard was developed with the apparent aim to be used in
conjunction with BPMN [
Utilising case models with processes and decisions has been addressed in
literature as well [
When it comes to linking the models, the three OMG standards are designed to be compatible with each other: in BPMN, a case task can be used to call upon an underlying CMMN model. Similarly, both in BPMN and in CMMN, a business rule task, which we call a decision activity, can be used to invoke an underlying DMN model. Hence, processes can be lled with decisions and cases, while the cases themselves can boast decisions as well.
The Separation of Concerns (SoC) paradigm o ers rm motivation for
keeping multi-perspective modelling tasks, such as control ows, cases, and decision
making, isolated and founded on a basis which can be used to ensure consistency.
The integrated modelling and externalisation was already considered in terms
of business rules [
In this section, we address the pairwise integration of processes, cases, and decisions by illuminating possible inconsistencies when using two modelling methods simultaneously, each representing a modelling concern of its own. Additionally, we suggest rules and guidelines on how to remedy some of these inconsistencies. 4.1
In this subsection, possible incompatibilities that might arise between the process
model and the decision model are discussed, as the goal is to identify potential
incompatibilities and subsequently to alter the process to restore consistency.
This issue was discussed more in detail in [
For the sake of clari cation, we will illustrate one of the process-decision incompatibilities through an example. We opt for the Data Recency Incompatibility. Consider Figure 3 where the process of prospect acceptance is depicted with a Risk level decision requiring Financial statements and ID/Passport input objects created by activity Receive Documents. However these documents must be up to date in order to make a sound decision. A rule might be that if the time between the start of the process and the enactment of the Risk level decision is longer than six months, the documents have to be resubmitted in order to ensure that the decision is taken based on up to date documents.
Incorporating this constraint can easily be done using a timer event on the Receive documents activity, which will trigger the activity every six months. That way, the process will proceed with the correct data and the decision enactment will be sound. This remedies the Data Recency Incompatibility.
When using cases within the process, it is of paramount importance that the process knows the state of the case that has been executed. States and milestones that are part of the case model can be linked to paths in the process model. Hence, depending on the conclusion of the case, the process model will continue on a certain path after the enactment of the case. If there are more paths in the process than conclusions in the case model, incompatibilities between the two models can arise. We call this the Path Rei cation Incompatibility. Similarly, if the case contains conclusions that are not followed up by the control ow of the process, the process might not be able to continue after the case enactment. We call these inconsistencies Case Conclusion Incompatibilities.
CASE Inspection
Pass Error Fail
Proceed with procurement Procurheomldent on
Cancel procurement procured on hold calcelled
Consider the example process regarding food inspection in Figure 5. The process contains a Case with the name Inspection. Depending on the outcome of the underlying case, the process will will continue in three possible paths before reaching a conclusion. Figure 6 gives the underlying case model. However, only two possible milestones are present in the case model, while the process has three di erent paths leaving the gateway after the enactment of the case. Clearly, the Path Rei cation Incompatibility is at play here as discussed above.
To remedy this inconsistency, either the process or the case model must be adapted. One could remove one of the paths in the process model or add an additional terminating state in the case model in the form of a milestone. We opt for the latter and the remedied case model is presented in Figure 7. By adding the additional milestone of Inspection error the case and process model are rendered consistent again, and the process can continue to reach a sound conclusion. Note that a single path in the process can catch multiple terminating states from the case model through an or logical statement. Hence, a one-on-one mapping of terminating states and process pathways is not always necessary. Similar to the integration of processes and decisions in Section 4.1, the Input Data Incompatibility can also occur when employing cases and decisions. Hence, the case model must provide the relevant input data for the decision model it wishes to invoke. Depending on the outcome of the decision, the case will reach certain milestones. Inconsistencies occur when there are more decision outcomes in the decision model than possible milestones in the process model. Thus, when certain decision outcomes are reached, the case model is not capable of detecting them. We call this the Decision Conclusion Incompatibility.
Consider the case model in Figure 8, depicting a contract case model. In the case, a Check credit decision activity is present. In order to invoke this decision correctly, the case model must provide the necessary data input for the decision enactment, otherwise the Input Data Incompatibility occurs. In this model, we assume the data input is provided correctly through the data object modelled within the case model. However, assume that the Check credit decision has three possible outcomes: Credit OK, Credit Problem, and On Hold. The case model in
Again, there are two ways of remedying this incompatibility: either by introducing a milestone in the case model capturing the decision outcome of On Hold or by making the decision outcome of On Hold impossible to reach in the underlying decision model and thus deleting it from the decision model. We opt for the former approach and the remedied case model is presented in Figure 9. Clearly, the case model is now able to detect all outcomes of the underlying decision model and is thus capable of reaching a sound end state and conclusion.
Contract [update]
Check credit Contract [update] Check credit [complete] Credit Problem Fig. 9: Contract generation case model remedied.
This work discusses insights and challenges for an integrated modelling approach of processes, cases, and decisions. We discussed integration scenarios and elaborated upon inconsistencies that might arise during the endeavour of model integration. Consistent integration should rely on a profound data management between the separate modelling concerns, by correctly matching intermediate results of decisions, process data, and case data necessary for the enactment of the knowledge-intensive process in its entirety.
In future work, we will further investigate how data management needs to be organised in order to reach consistency in integration of processes, cases, and decisions. Besides, the modelling complexity of integrated models is an interesting question for research as well. Additionally, integrated modelling in cooperative information systems and in distributed processes is of particular interest for Internet of Things (IoT) applications.