Soundness of Decision-Aware Business Processes


Extended Camunda Modeler


Download one of the following archives, extract it, and run the camunda-modeler executable.


1. Download both the process model and the decision table displayed below.

2. In the Camunda Modeler, open the downloaded file decisionTable.dmn.

3. In the table editor window, click the import BPMN button and select the downloaded file processModel.bpmn.

4. Click the button check soundness. This will display the reasons why the decision-aware business process model is not sound.

5. You can change the table in the same window. If you want to change the process model, you need to open it in a separate tab. There you can edit and save it. Then, you can import it again in the table editor tab. An alternative process model that is sound is shown below.

Process Model (not sound)


Decision Table

  • Download
  • Output set of the decision table: {(out1,out2), out2, out3, (out3,out4)}

Process Model (sound)


User Guide

This short user guide explains how to use our extended Camunda Modeler for soundness checking of decision-aware business processes. The Camunda Modeler offers functionalities for both process and decision modeling in a single standalone application.

Hence, you can simply create both models using the same application and then check for soundness. To do so, open the decision table and import your process model by clicking the import BPMN button. The imported model will be displayed. (Note that in this view you cannot edit the process model. To edit the model, open it in a separate window, save it, and import it again in the decision table window.) Now you can click the check soundness button and a table summarizing the analysis results will appear.

The analysis results as well as guidelines for process and decision modeling will be discussed in the following.

Analysis Results

The soundness check of our extended modeler will produce various pieces of information displayed in a table. Note that only rows that are marked in red describe errors.
  • Decision table output set: This is the set of all possible outputs that the DMN decision table can produce. This set is determined by the set of rules of the table together with the hit policy.
  • Overlapping rules: The will list all rules that are overlapping, i.e. rules for which input value combinations exist such that these rules are triggered at the same time. (Reference)
  • Decision deadlock freedom violated: The decision deadlock freedom criterion is satisfied iff the decision table is complete and every possible output of the table is covered by a branch condition of the associated process model. If this criterion is violated, the reason for the violation is given.
  • Dead branch absence violated: The dead branch absence criterion is satisfied iff every branch condition of the process model evaluates to true for at least on possible output of the table. Otherwise the corresponding branch is said to be dead (or unreachable). If this criterion is violated, the reason for the violation is given.
  • Syntax error in branch condition: The branch conditions of the process model must be specified according to a defined grammar (see below). If the process model contains an incorrect condition, it will be displayed together with an error message. (This error message may or may not be helpful. The grammar was specified using ANTLR v4.)

Process Modeling

Our soundness checker verifies the consistency of a decision fragment with a decision model (or top-level decision table). A decision fragment is a fragment of a process model, containing the following elements:
  • business rule task, followed by a
  • split gateway of type {xor, ior, complex}, having
  • two or more outgoing branches, where each branch is annotated with a
  • condition that specifies a test that can be applied to the output of a decision table and that yields either true or false
Examples of decision fragments (with additional start/end events) are displayed above.

Branch Condition Grammar

The grammar used for specifying the condition C of a decision fragment was created using ANTLR v4. The corresponding .g4 file is shown below.


Decision Table Modeling

The Camunda Modeler supports the modeling of DMN decision tables. A nice tutorial is given here.

Of course, DMN decision models don't just consist of a single decision table. Rather, a decision model defines the decision requirements and the decision logic of a business decision. However, given that the decision model has a single top-level decision whose logic is implemented by a decision table, associating only a single decision table to your process model is sufficient to validate the consistency or soundness of the process model and the entire decision model.


Consider the decision table displayed below. This table has two output variables: output1 and output2. Since the table's hit policy is rule order, given the input input = 2, the output will be output1 = [out1, out2] and output2 = [out11, out22]. This output can be satisified by the following branch condition in the process model (displayed below): output(output1) contains out2 and output(output2) == [out11, out22].




Kimon Batoulis
Mathias Weske