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 ConceptsBefore 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 ModelPart 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".
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.
|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.
|The authority for a business knowledge model or decision.
|Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
|Information – input data or decision output – required for a decision.
|The invocation of a business knowledge model.
|Showing the knowledge source of an element or the dependency of a knowledge source on input data.
Here is a simple illustration of the elements and requirements (relationships between the elements) in a Decision Requirements Graph.
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 RequirementsOne 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).
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)
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 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 LevelDecision 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 ModellingThe 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.
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.
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).
A DMN decision table consists of:
- 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 TableFigure 9 below is an illustration of the syntax for a DMN Decision Table.
Orientations of Rules in DMN Decision TableA 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.
DMN Decision Table Hit PolicyThe 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 PoliciesThere are four types of single hit policies.
|This is the default policy. All rules are exclusive and only a single rule is matched.
|Multiple matching rules, all matching rules with the same output. Any of these outputs can be used.
|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.
|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.
Examples of Decision Table with Single Hit PolicyMost 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.
Multiple Hits Policy for Single Output Decision TableThere are three types of multiple hits policies for a single output Decision Table.
|Returns all hits in a unique list in arbitrary order.
|Returns all hits in decreasing priority order. Output priorities are specified in an ordered list of values.
|Returns all hits in rule order, i.e. dependency on the order of the rules.
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.
|The result of the decision table is the list of all the outputs, ordered or unordered per the hit policy.
|The result of the decision table is the sum of all the outputs.
|The result of the decision table is the smallest value of all the outputs.
|The result of the decision table is the largest value of all the outputs.
|The result of the decision table is the number of outputs.
|The result of the decision table is the average value of all the outputs, defined as the sum divided by the count.
Examples of Decision Table with Multiple Hit PolicyHere are three examples of Decision Table with multiple hits policy.
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.
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.
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.