Introduction to DMN

© 2014 Max Tay, MaxConsilium Pty Ltd

Decision Model & Notation

(DMN)

An Introduction

Max Tay, OCEB® Business Advanced, CBPP®


Decision Model & Notation

(DMN) 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.

It is designed to be useable alongside BPMN.


Basic Concepts

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.

Decision model is defined in two levels:

Decision requirements level

◦ define the decisions to be made, the interrelationships, and the required components for the decision logic.

Decision logic level

◦ define the required decisions in some form of logic representation at sufficient detail enabling validation and/or automation.



Decision Requirements Levels –

Constructs Elements

DecisionThe act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.

Business Knowledge ModelA function encapsulating business knowledge, in the form of business rules, decision table or analytic model.

Knowledge SourceThe authority for a business knowledge model or decision.

Input DataInformation used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.

Requirements (relationships)

Information RequirementInformation – input data or decision output – required for a decision.

Knowledge RequirementThe invocation of a business knowledge model.

Authority RequirementShowing the knowledge source of an element or the dependency of a knowledge source on input data.


Decision Requirements Level –

NotationElements

Decision

Business Knowledge

Model

Knowledge Source

Input Data

Requirements (relationships)

Information Requirement

Knowledge Requirement

Authority Requirement


Example of Decision

Requirements Model


Knowledge Source and Authority

Requirement Business knowledge derived from (authority

requirements) business artefacts and legislative artefact

(knowledge sources).

Business knowledge derived from predictive analytic

model based on the input data and decision.


Decision Requirements Models –

DRG and DRDDecision Requirements Graph (DRG)

A DRG is composed of elements connected

by requirements and is self-contained.

◦ All the modelled requirements for any

Decision in the DRG – its immediate sources

of information, knowledge and authority – are

present in the same DRG.

Decision Requirements Diagram (DRD)

A DRD only presents a particular view of a

DRG, which may be a partial or filtered

display.


Examples of DRG and DRDs


Decision Logic Level

Decision logic is added to a decision model by including a value expression component in some of the decision model elements in the DRG.

Each decision element in a decision model may include a value expression that describes how a decision outcome is derived from its required input, possibly invoking a business knowledge model.

Each business knowledge model element may include a value expression, which is the defined function that is to be re-used in multiple decisions.

Knowledge source is not represented at the decision logic level.


Decision Logic Level

Modelling The notation for decision logic is “boxed expressions”

which is associated with Elements of Decision Requirements Diagram.

Represented in any of the following forms:

◦ Invocation (for Decision element),

◦ decision tables,

◦ calculations,

◦ if/then/else logic,

◦ simple data structures, and

◦ externally defined logic from Java and PMML into executable expressions with formally defined semantics

◦ A literal expression language provided by DMN –Friendly Enough Expression Language (FEEL).


Boxed Expression of Decision

and Business Knowledge Model


Boxed Expression and FEEL

Expression for Decision Logic


Representing Business Knowledge

Model using DMN Decision Table


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

Input values for the rules must be exclusive, i.e. input values do not overlap.

A decision table is complete when the list of rules contain all possible combinations of input values.

◦ An incomplete table may specify a default output.


Syntax of DMN Decision

Table

Input expression 1 Input expression 2 Output name

value 1a, value 1b value 2a, value 2b value 3a, value 3b

1 value 1a value 2a value 3a

2 value 1b value 2b value 3b

Decision name

HC

Name of Decision Table

Rule number

Set of Inputs

Output(s)Multiple output columns allowed

Double line between inputs section and outputs section, and between inputs/outputs headers and the rule entry cells.

Lists of expected values (optional)

Hit policy

Completeness indicator


Orientations of Rules

Rules as rows

Rules as columns

Rules as crosstab


DMN Decision Table Hit

Policy The hit policy 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.


Types of Single Hit Policy Unique

◦ Default policy. All rules are exclusive. Only a single rule is matched.

Any

◦ Multiple matching rules with same output, any output 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 (and evaluation stops), i.e. dependency on the order of the rules.

◦ The last rule is often the catch-remainder.

◦ Hard to validate manually and must be used with care.


Examples of Decision Table with

Single Hit Policies


Types of Multiple Hit Policy for

Single Output Decision Table 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.


Output Aggregation for Multiple

Results A multiple hit table may return output entries from multiple

rules, where the result is aggregated into a singe result.

Aggregation indicator:

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



Multiple Hit Policies

Age = 50, Service = 25, Returned result = sum(20, 5, 5) = 30

Age = 50, Service = 25, Returned result = (20, 10, 5)



Multiple Hit Policies (cont’)

GPA = 3.6, Score = 4, Membership = Yes,

Returned result = (20% scholarship, 50% loan)


More on Hit Policies

Decision tables with multiple output columns support only the following hit policies: Unique, Any, First, No order, and Rule order.

Crosstab tables are unique and completeby 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.


FEEL

If you are interested in FEEL, see

Section 10 of the specification.

Official specification is available at:

http://www.omg.org/spec/DMN/Current

View article on my blog:

http://blog.maxconsilium.com/2014/09/intro

duction-to-decision-model-notation.html

http://www.omg.org/spec/DMN/Current

http://blog.maxconsilium.com/2014/09/introduction-to-decision-model-notation.html


Technology

Introduction to DMN