23 September 2014

Introduction to Decision Model & Notation (DMN)

Early this year, OMG released the beta version of its Decision Model & Notation (DMN), a complimentary notation to work alongside BPMN for modelling of operational decision and business rules. Similar to BPMN, it aims to support designing of decision models, providing guided operational decision and potentially automation of operational decision. This article provides an introduction to the basic concepts of DMN, its constructs, illustration of decision model and decision logic expression particularly the DMN Decision Table.

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.
Its purpose is to provide the constructs that are needed to model decisions in diagrams, accurately defined by business analysts, and optionally automated. In addition, it is also designed to be usable alongside BPMN process model.

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

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
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.
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

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.
The combination of input values for the rules must be exclusive, i.e. set of input values do not overlap between rules. A decision table is considered as complete when the list of rules contain all possible combinations of input values. It is possible to have an incomplete table which has a default output specified (under a catch-reminder rule).

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.

Friendly Enough Expression Language (FEEL)

FEEL is a special expression language included as part of the DMN specification. If you are interested in FEEL, see Section 10 of the specification.

Trying Out DMN Decision Modelling

For a 30 days trial of Signavio which has a Decision modelling module based on OMG' DMN, [click here].

Decision Model And Notation (DMN), OMG. [link]

No comments:

Post a Comment