What is DMN?
Decision Model and Notation (DMN) is a common notation for decision models developed by Object Management Group, for user from both business and technical including:- business analysts designing decision models;
- technical developers automating the decisions in processes; and
- business people who manage and monitor those decisions.
Some Basic Concepts
Before we continue, let looks at some basic concepts in DMN.In the context of DMN, a decision is an act of determining an output value, based on a number of input values, using logic defining how the output is determined from the inputs. A decision model is a formal model of an area of decision-making, expressed as decision requirements and decision logic.
A decision model is defined in two levels, the Decision Requirements Level and the Decision Logic Level. The Decision Requirements Level is the more abstract level of modeling, made up of a Decision Requirements Graph (DRG) represented in one or more Decision Requirements Diagrams (DRD). It defines the decisions to be made, the interrelationships, and the required components for the decision logic. the Decision Logic Level is the detailed level of modeling, consisting of the value expressions associated with decisions and business knowledge models. In other words, the required decisions is captured in some form of logic expression at sufficient detail enabling validation and/or automation.
BPMN Process Model and DMN Decision Model
Part of a good practice in business process modelling using BPMN is to remove the decision logic or business rules logic from the business process model. Consequently, when when and where decision making is required on a process model, it is represented using a "business rules" task which is linked to a "decision model".
Figure 1: BPMN Process Model with DMN Decision Model
Source: DMN Specification
Source: DMN Specification
On an executable BPMN process model, a business rules task will invoke the respective decision model on the repository via a service call to a decision management engine. The decision management engine will then return the output to the executable process model (running on an BPMS). Decision model may also be used in a user task or in manual task where decision model is being utilised at in a user task or where there is no automation.
Decision Requirements Level
Constructs and Notation of a Decision Requirements Model
In its current version (1.0), there are seven types of construct being used in Decision Requirement modelling, i.e. four element types and three requirement types.
| Construct | DMN Notation | Description |
|---|---|---|
| ELEMENTS | ||
| Decision |  | The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models. |
| Business Knowledge Model |  | A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model. |
| Knowledge Source |  | The authority for a business knowledge model or decision. |
| Input Data |  | Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model. |
| REQUIREMENTS | ||
| Information Requirement |  | Information – input data or decision output – required for a decision. |
| Knowledge Requirement |  | The invocation of a business knowledge model. |
| Authority Requirement |  | Showing the knowledge source of an element or the dependency of a knowledge source on input data. |
Table 1: Constructs of DMN Decision Requirements Model
Here is a simple illustration of the elements and requirements (relationships between the elements) in a Decision Requirements Graph.
Figure 2: DMN Elements and Requirements in a Decision Requirements Graph
Source: DMN Specification
Source: DMN Specification
In Figure 2, the decision action requires the data input where the business knowledge is applied. The business knowledge contains the decision logic. The content of the decision is sourced from (has its authority based on) the knowledge source 1, e.g. corporate policies and the content of the business knowledge is sourced from the knowledge source 2, e.g. corporate compliance guidelines.
Knowledge Source and Authority Requirements
One of the key features of DMN is being able to specify the source or authority of business knowledge. As seen earlier, a decision applies business knowledge. Being able to show the link between the business knowledge and its source via an authority requirements provides not only tracebility but also a way for impact analysis. In the example below, the source or authority of the business knowledge (business rules) are the policy document, policy group (business artefacts) and the legislative (external artefact).
Figure 3: Business Knowledge with Authority Requirement from Business and Legislative Artefacts
The authority requirements can also be used to indicate business knowledge (business rules) that is derived from analytic model based on the decision itself and input data of the decision. (see Figure 4 below)
Figure 4: Business Knowledge sourced from Analytic Model based on Decision and Input Data
Decision Requirements Graph (DRG) versus Decision Requirements Diagram (DRD)
A Decision Requirements Graph (DRG) is a self contained decision model of a specific domain of decision making where all the modeled requirements for any Decision in the DRG (its immediate sources of information, knowledge and authority) are present in the same DRG.
On the other hand, a Decision Requirements Diagram (DRD) is a decision model that is only presenting a (possibly filtered) view of a DRG. The DMN specification does not specify the contents of a DRD, i.e. what should be included or can be excluded. However, where information is filtered (not shown), the DRD should provide a clear visual indication that this is the case.
Figure 5: DRDs views of a DRG
Figure 5 above shows two examples of DRD with different views of the given DRG. DRD 1 has a focused view on Decision 1 whereas DRD 2 focused on the information requirements of both Decision 1 and Decision 2.
Decision Logic Level
Decision logic is added to a decision model by including a value expression component to elements of the decision model. Each decision in a decision model has a value expression that describes how a decision outcome is derived from its required input, possibly invoking a business knowledge model. Similarly each business knowledge element has a value expression which is the defined function that is to be re-used across the multiple instances of the decision element. There is no value expression for a knowledge source, where in implementation could be linked to the artefact (document).Decision Logic Level Modelling
The notation for decision logic is boxed expressions which decompose the decision logic model into small pieces that are associated with elements of Decision Requirements Diagram. There are four types of Boxsed Expression:- Boxed Function - expression showing the kind, parameters and body of a function.
- Boxed Invocation - expression showing the parameter bindings that provide the context for the evaluation of the body of a business knowledge model.
- Boxed List - expression showing a list of n items.
- Boxed Literal Expression - expression showing a literal expression.
- Decision Table - a tabular representation of a set of related input and output expressions, organised into rules indicating which output entry applies to a specific set of input entries.
- Friendly Enough Expression Language (FEEL) - a literal expression language included in the DMN specification.
Figure 6: Boxed Expression using Boxed Invocation and Decision Table
In the above DRD (Figure 6), the decision logic of the Eligibility decision is represented using a Boxed Invocation and Eligibility business knowledge is represented using a Decision Table. Both the Boxed Invocation and the Decision Table can be represented using FEEL as shown in Figure 7 below.
Figure 7: Boxed Expression using FEEL
DMN Decision Table
As one of the boxed expression, Decision Table is a common expression to represent business knowledge in tabulated business rules, which also provide easy validation in most cases. Here is an example of how business knowledge 2 in a DRD is represented using a Decision Table. (see Figure 8).
Figure 8: Business Knowledge expressed using Decision Table
A DMN decision table consists of:
- name,
- set of inputs, each input optionally associated with a type and list of input values,
- set of outputs, each output optionally associated with a type and list of output values,
- list of rules in rows or columns of the table, where each rule is composed of the specific input entries and output entries of the table row (or column),
- hit policy,
- Completeness indicator (optional),
- Aggregation - only applicable in decision table with multiple hits policy.
Syntax of a DMN Decision Table
Figure 9 below is an illustration of the syntax for a DMN Decision Table.
Figure 9: Syntax of DMN Decision Table
Orientations of Rules in DMN Decision Table
A DMN Decision Table may be constructed where the rules are listed in rows, or as columns, or even as crosstab (rows and columns). See the examples below.
Table 2: DMN Decision Table with Rules as Rows
Table 3: DMN Decision Table with Rules as Columns
Table 4: DMN Decision Table with Rules as Crosstabs
DMN Decision Table Hit Policy
The hit policy in a DMN Decision Table specifies:- what the result of the decision table is where there are multiple matches for a given set of inputs.
- contains additional information that can be used to check correctness of decision table at design-time.
The hit policy indication is mandatory and is summarized using a single character in a particular decision table cell. The hit policy MUST default to Unique. Decision tables with the Unique hit policy do not contain rules with overlapping input entries.
Single Hit Policies
There are four types of single hit policies.| Hit Policy | Description |
|---|---|
| Unique | This is the default policy. All rules are exclusive and only a single rule is matched. |
| Any | Multiple matching rules, all matching rules with the same output. Any of these outputs can be used. |
| Priority | Multiple matching rules with different outputs. Returns the matching rule with the highest output priority which is specified in an ordered list of values, e.g. the list of expected output values. |
| First | Multiple matching rules with different outputs. First hit by rule order is returned. Once there is a hit, the evaluation stops (and ignore the rest of the rules). The matching has a dependency on the order of the rules. The last rule is often the catch-remainder rule. This type of policy is hard to validate manually and must be used with care. |
Table 5: Single Hit Policies
Examples of Decision Table with Single Hit Policy
Most Decision Tables have single hit policy which is easier and simpler than those with multiple hits policy. Here are some examples of Decision Table with single hit policy.
Table 6: Decision Table with Unique Hit Policy
Table 7: Decision Table with Priority Hit Policy
Table 8: Decision Table with Any Hit Policy
Table 9: Decision Table with First Hit Policy
Multiple Hits Policy for Single Output Decision Table
There are three types of multiple hits policies for a single output Decision Table.| Hit Policy | Description |
|---|---|
| No order | Returns all hits in a unique list in arbitrary order. |
| Output order | Returns all hits in decreasing priority order. Output priorities are specified in an ordered list of values. |
| Rule order | Returns all hits in rule order, i.e. dependency on the order of the rules. |
Table 10: Multiple Hits Policies for Single Output
When a multiple hits table returns output entries from multiple rules, the output entries have to be aggregated into a singe result. An Aggregation specifies the function to handle the multiple output entries.
| Aggregation | Description |
|---|---|
| Collect | The result of the decision table is the list of all the outputs, ordered or unordered per the hit policy. |
| Sum | The result of the decision table is the sum of all the outputs. |
| Min | The result of the decision table is the smallest value of all the outputs. |
| Max | The result of the decision table is the largest value of all the outputs. |
| Count | The result of the decision table is the number of outputs. |
| Average | The result of the decision table is the average value of all the outputs, defined as the sum divided by the count. |
Table 11: Aggregation for Multiple Hits Policy
Examples of Decision Table with Multiple Hit Policy
Here are three examples of Decision Table with multiple hits policy.
Table 12: Decision Table with No Order Hit Policy and Sum Aggregation
Given an applicant with the age of 50 and 25 years of service, the returned result is 30 which is the sum of three outputs (20, 5, 5) from Rule 1, Rule 4 and Rule 5.
Table 13: Decision Table with No Order Hit Policy and Collect Aggregation
Given the same applicant aged 50 and 25 years of service, the returned result is (20, 5, 5), which is a collection of the three outputs from Rule 1, Rule 4 and Rule 5.
Table 14: Decision Table with Output Order Hit Policy and Collect Aggregation
Given an applicant with a GPA of 3.6, an Activity Participating Score of 4, and a yes for the Honour Society Membership, the returned result is (20% scholarship, 50% loan), a collection of ordered outputs from Rule 1 and Rule 2.
Notes on Hit Policies
Decision tables with multiple output columns support only the following hit policies: Unique, Any, First, No order, and Rule order.
Cross-tab tables are unique and complete by definition and therefore do not need a hit policy indication.
In tables with First or Rule Order hit policy, the order of the rules influence the output, and therefore must be used with care.
No comments:
Post a Comment