What is DMN?
The Decision Model and Notation (DMN) enables you to document decision processes in a structured and formalized manner. You find the DMN specification document at http://www.omg.org/spec/DMN/1.1/. With DMN, you can document structured decision-making processes, which can be traced and understood by business users, as well as by IT specialists.
Although DMN is an independent notation, it is designed to enable linking DMN to BPMN diagrams. This can be of great value, as DMN complements BPMN perfectly when it comes to modeling complex design processes. DMN modeling helps you to prevent messy BPMN decision process structures like the one sketched out below:
DMN element structures are called Decision Requirements Graphs (DRG). They form Decision Requirements Diagrams (DRD).
This article explains the different elements of a decision requirement graph.
There are four different core elements in DMN:
- Input data,
- Business knowledge models,
- Knowledge sources.
These elements are described below.
Decisions depict a point where an output is determined from one or several inputs, making use of decision logic. Decisions may require one or multiple business knowledge model elements.
Input Data elements contain information which is used by one or several decision and/or business knowledge model elements.
Business knowledge model
Business knowledge models are functions providing logic for one or multiple decision elements.
A Knowledge Source depicts an authority, which has to be considered during a decision or business model function.
There a three types of connectors in DMN. All of these connectors establish a requirement relationship: The element the connector is pointing to requires the input of the connector's source. Thus, in DMN connectors are drawn from the receiving (or requiring) element to the starting point, contrary to connectors in BPMN diagrams, which are drawn from the source to the target element.
|Information requirement||An information requirement connector starts at a data input or decision element and points to the decision element that requires the information.|
|Knowledge requirement||A knowledge requirement connector starts at a business knowledge model and points to a decision or a business knowledge model.|
|Authority requirement||An authority requirement points from an input data element to a dependent knowledge source or from a knowledge source to any dependent decision requirement graph element.|
A decision table always contains a collection of rules. It transform inputs according to the rules into outputs and can be depicted like this:
Hit policies determine the semantics of a decision table and prescribe how rules must be structured. For example, multiple rules that lead to different results may apply to one specific set of input values. This is why you need to specify a hit policy for each decision table.
There are two variants:
- Single hit policies
- Single hit policies considers exactly one rule. However, this rule can produce multiple outputs.
- Multi hit policy
- Multi hit policies aggregate outputs as sums/ lists.
The desired hit policy for the decision table is specified in the upper left corner with the respective initial letter (sample: P stands for priority).
Furthermore, you can configure different completeness requirements:
- A complete decision table is only valid if it considers all possible inputs. We recommend using complete decision tables in most scenarios, because they prevent problems that occur while executing the decision, if the decision modeler didn't consider an input that is then occurring in practice.
- An incomplete decision table is valid even if it doesn't consider all possible inputs.
Single hit policies
The following subsections explain all single hit policies with the help of practical examples.
Unique Hit Policy (U)
One input combination is covered by exactly one rule. Unique (single) is the default hit policy in Signavio's DMN editor.
Depending on the current season, a retailer decides which product group he offers at a reduced price. Only one product group can be offered, since only one season exists at the same time.
Any hit policy (A)
Multiple rules cover the same combination of input values. However, this overlap is only allowed if the overlapping rules have the same output.
If a credit applicant is under 18 years and is already in debt, the application is rejected. Otherwise he gets a credit.
Priority hit policy (P)
Rules can overlap with different outputs. To determine the resulting output, outputs are ordered according to priority. Outputs are always in list form. The value with the lower list index is prioritized.
In a decision table, the logic determines at what age customers get certain discount vouchers. For customers over 18 years sports equipment vouchers and for all over 3 years toys vouchers are issued. Both rules apply to a 30-year-old customer. Because the output 'sports equipment' has a higher priority, the customer will get a voucher for this. Consequently, the output list has to be [sports equipment, toys, clothing].
|> 18||Sports equipment|
First hit policy (F)
Rules might overlap. But only one rule fires: The first hit policy simply assumes an ordering of the rules - they are evaluated from top to bottom. As soon as one rule fires, the output of that rule is used as result of the decision. Once rule hits, no other rule is checked.
In a decision table, the logic determines at what age customers get certain discount vouchers. For customers over 18 years clothing vouchers and for all over 3 years sports equipment vouchers are issued. Both rules apply to a 30-year-old customer. Because the rule for 18-year-old customers is at the top of the decision table, this rule serves as the basis for the decision. The customer receives a voucher for clothing.
|> 3||Sports equipment|
Multi hit policies
When using multi hit policies, multiple rules can fire for one set of data inputs. Multi hit tables either return a set or aggregate as the final result of the decisions. The following subsections explain all multi hit policies with the help of practical examples.
Collect hit policy (C)
By default, the collect hit policy collects the outputs of matching rules, but can be configured to determine the sum, minimum, maximum or count of matching outputs instead.
An online shops adds a discount coupon to specific orders. The discount depends on the total sum of an order. In the decision table below, the outcome differs depending on the variant of the applied collect hit policy. Given a 250$ purchase order,
- the default collect hit policy returns two coupons (5%, respectively 25% discount) in no particular order,
- the sum collect hit policy returns one coupon with 30% discount,
- the maximum collect hit policy returns one coupon with 25% discount,
- the minimum collect hit policy returns one coupon with 0% discount and disappoints the customer in our scenario,
- the count collect hit policies returns 2, which doesn't provide relevant information in our scenario.
|Total order sum||Discount coupon|
Output order hit policy (O)
Results are ordered by the priority of the output values.
An online shop adds small gifts to orders. The gifts a customer receives depend on the total order sum. If the order sum is 50$ or lower, the customer receives a discount coupon. If the order sum exceeds 50$, the customer receives a small pack of high-quality coffee in addition to the coupon. With an output order hit policy, for the total order sum of 250$ the table below will return the result [Coffee, Discount coupon], sorted according to the order of the specified output list.
|Total order sum||Gift = [Coffee, Discount coupon]|
Rule order hit policy (R)
Results are ordered by the order of matching rules.
When applying a rule order hit policy to the table above, an input of 250$ will return the result [Discount coupon, Coffee], sorted according to the order of the applying rules.
Decision Requirements Diagram (DRD)
A complete decision requirements graph could for example look like this:
Is this page helpful?