The Decision Model and Notation (DMN) is a standard notation to specify decision logic in business applications. A central construct in DMN is a decision table. The rising use of DMN decision tables to capture and to automate everyday business decisions fuels the need to support analysis tasks on decision tables. This paper presents an opensource DMN editor to tackle three analysis tasks: detection of overlapping rules, detection of missing rules and simpli cation of decision tables via rule merging. The tool has been tested on large decision tables derived from a credit lending data-set.
Copyright c 2016 for this paper by its authors. Copying permitted for private and academic purposes. vide a common notation that is readily understandable for all business users including business managers, analysts, and developers. DMN consists of two levels: a \decision requirements level" and a \decision logic level". The decision requirements level de nes input data needed to make a decision. The decision logic level describes how each decision is made. Decisions are usually expressed as decision tables. In decision tables, columns represent inputs and outputs of a decision, and rows represent rules. Columns typically are typed so that they have an associated domain. A rule is a conjunction of basic expressions (one basic expression per cell). Basic expressions are captured using a language known as S-Feel (Simpli ed Friendly Enough Expression Language).
In Figure 1, we see an example of a decision table. The rules in the decision table should be interpreted as follows: 1. If the customer asks for a loan duration of 36 and her annual income is less than or equal to 56943, then she gets grade \C." 2. If the customer asks for a loan duration of 36 and her annual income is greater than 56943, then she gets grade \A." 3. If the customer asks for a loan duration of 60, then she gets grade \B."
Using DMN decision tables for making critical business decisions raises the
question of ensuring their correctness and simplicity to prevent costly defects.
The tool presented in this paper implements scalable algorithms for two basic
correctness checking tasks over DMN tables and one algorithm for simpli cation
task [
We implemented our tool starting from dmn-js, the open-source rendering and editing toolkit of Camunda DMN.2 We extended dmn-js to support correctness veri cation and simpli cation. Our tool can be found at https://github.com/ ulaurson/dmn-js and a deployed version for testing is available at http:// dmn.cs.ut.ee/. A screencast of the tool demo can be found at https://www. dropbox.com/s/nc0vibw2jlv0p3l/DMN_Screencast.mp4?dl=0.
The tool provides a syntactic check that veri es whether each cell of a decision table has the right content. The implemented algorithm checks if the content of each cell matches its column type.3 If not, the cell becomes red and a tooltip is added. In Figure 2, we see two syntactic errors. In the third rule rst column we have a syntactic error because this cell should contain a double but it contains a string. Another syntactic error is in the rst rule second column. This cell should contain a string, but it contains an integer.
3 Our tool supports types integer, string, Boolean, and double.
When clicking verify table (see Figure 2), the tool nds all the overlaps in the decision table. The tool can nd two types of overlaps: overlaps where inputs and outputs are the same and overlaps where inputs are the same and at least one output is di erent. In Figure 3, we see that the tool has found two overlaps. Rules 2 and 5, and rules 4 and 6 have overlaps. The overlapping rules are summarized in the \Missing and overlapping rules" table. This table contains maximal sets of overlapping rules with a non-empty intersection. If \(outputs are the same)" is explicitly mentioned in a set of overlapping rules, then these rules have the same inputs and outputs, otherwise they have di erent outputs. The overlapping rules are highlighted in light red.
When clicking verify table, the tool also nds the missing rules in the decision table. In Figure 4, the decision table has three missing rules. The rst value inside the brackets shows what is missing in the rst input column, the second value shows, what is missing in the second input column and so on. In Figure 4, we can see that there are three types of missing rules. In the rst case, a categorical value is missing. Corresponding to interval [21, 65) there is no rule with \Customer Status" = \gold". In the second case, an interval is missing. In the decision table, there is no rule where \Age" = [65, 80). The third case has a missing Boolean value. With \Age" >= 80 and \Customer Status" = \gold" or \silver" there is no rule with \Lives in Estonia" = true. The missing rules are summarized in the \Missing and overlapping rules" table. The rst column of this table contains information about the missing rules. The second column contains a button for adding the missing rules into the table.
When clicking simplify table (see Figure 2), the tool simpli es the decision table via rule merging. In Figure 5, the rst decision table is a regular decision table that has no overlapping rules and no missing rules. The second decision table represents the simpli ed version of the rst table. Rules 1, 2, and 6 can be merged because these rules only di er in one input (the outputs are the same). Rules 3, 4, and 7 can also be merged. Rules 1 and 3 in the second table cannot be merged because their outputs are di erent. 3
Based on the tool implementation, we have conducted empirical evaluations to compare the proposed algorithms with respect to existing approaches (in particular the one implemented in Signavio4) in terms of scalability, conciseness of the feedback provided to users (in case of overlapping and missing rules) and compactness of the simpli ed tables. The tests have been conducted on large decision tables derived from a credit lending data-set.
Execution times for missing rules detection are under 2 seconds. The
detection of overlapping rules leads to higher execution times, due to the need to
detect sets of overlapping rules and ensure maximality. In Signavio, if multiple
rules have a joint intersection (e.g., rules fr1, r2, r3g) the output contains an
overlap entry for the triplet fr1, r2, r3g but also for the pairs fr1, r2g, fr2, r3g
and fr1, r3g (i.e., subsets of the overlapping set). Furthermore, in some cases,
the overlap of pair fr1, r2g may be reported multiple times (and same for fr2,
r3g and fr1, r3g). Meanwhile, our approach produces only maximal sets of
overlapping rules with a non-empty intersection. Therefore, the number of sets of
overlapping rules and the number of missing rules identi ed by our approach
is drastically lower than the number of overlapping and missing rules identi ed
by Signavio. For more information about our experimentation of the tool, the
reader is referred to [