Was ist DMN?

Die Decision Model and Notation (DMN) ist eine Notation zur Entscheidungsmodellierung und eine XML-Definition. Die DMN-Spezifikationen können unter http://www.omg.org/spec/DMN/1.0/ eingesehen werden.

Mit DMN können Sie Entscheidungsprozesse strukturiert dokumentieren, sodass diese für alle Beteiligten einfach nachzuvollziehen sind.

Obwohl DMN eine eigenständige Notation ist, können Sie DMN-Diagramme einfach in BPMN-Diagrammen integrieren. Dies trägt zur Transparenz und Übersichtlichkeit in BPMN-Diagrammen, die Entscheidungsprozesse darstellen, bei. Wie das folgende Beispiel zeigt, kann das Modellieren von Entscheidungsprozessen in BPMN schnell zu sehr komplexen Diagrammen führen:

Beispiel: Entscheidungsprozess in BPMN.

Beispiel: Entscheidungsprozess in BPMN.

DMN besteht aus Decision Requirements Graphs (DRG), die Decision Requirements Diagrams (DRD) bilden.

In diesem Artikel werden die verschiedenen Element eines Decision Requirement Graphs erklärt.

Elemente

In DMN gibt es vier verschiedene Kernelemente:

  • Decisions,
  • Input Data,
  • Business Knowledge Models,
  • Knowledge Sources.

Diese werden im Folgenden erläutert.

Decision/Entscheidung

'Decision'-Element.

‘Decision’-Element.

Decisons stellen einen Punkt dar, an dem Inputs durch eine Zuordnung Outputs generieren. Decisions können ein oder mehrere Business Knowledge Models abrufen.

Input Data

'Input Data'-Element.

‘Input Data’-Element.

Input Data-Elemente bezeichnen Informationen, die bei einer oder mehreren Entscheidungen und/oder Business Knowledge Models berücksichtigt werden müssen.

Business Knowledge Model

'Business Knowledge Model'-Element.

‘Business Knowledge Model’-Element.

Business Knowledge Models sind Funktionen, die Geschäftslogik für ein oder mehrere Entscheidungen bereitstellen.

Knowledge Source

'Knowledge Source'-Element.

‘Knowledge Source’-Element.

Eine Knowledge Source stellt eine Autorität dar, die während einer Entscheidung miteinbezogen werden muss.

Requirements (Konnektoren)

DMN-Konnektoren im Signavio Editor.

DMN-Konnektoren im Signavio Editor.

In DMN gibt es drei verschiedene Konnektorentypen. Alle Konnektoren etablieren eine Requirement(Anforderungs-)Relation, d.h. das Element, von dem der Konnektor ausgeht, wird vom Element auf das der Konnektor zeigt zur Entscheidungsfindung benötigt.

Konnektoren werden hier, anders als bei der BPMN-Modellierung, von dem Informationen aufnehmenden zu dem Information sendenden Element gezeichnet. Sie verwenden daher das Kontextmenü des Elements, auf das der Konnektor zeigt, um einen Konnektor zu dem Element zu ziehen, von dem der Konnektor ausgeht. Weiteres zur DMN-Modellierung können Sie im Kapitel DMN-Diagramme im Editor modelieren lernen.

Requirements (Konnektoren)
Information Requirement Ein Information Requirement-Konnektor beginnt bei einem Data Input oder Decision-Element und zeigt auf eine Decision oder ein Business Knowledge Model, das die Informationen des Ursprungselements benötigt.
Knowledge Requirement Ein Knowledge Requirement-Konnektor beginnt bei einem Business Knowledge Model und zeigt auf eine Decision oder ein Business Knowledge Model, von dem das Business Knowledge Model aufgerufen wird.
Authority Requirement Ein Authority Requirement-Konnektor beginnt bei einem Knowledge Source oder Input Data Element und zeigt auf ein abhängiges Decision Requirements Graph Element.

Entscheidungstabelle

Eine Entscheidungstabelle beinhaltet immer eine Sammlung von Regeln. Sie transformiert Inputs gemäß den vorgegebenen Rules zu Outputs und kann wie folgt dargestellt werden:

Beispiel: Entscheidungstabelle im Editor.

Beispiel: Entscheidungstabelle im Editor

Hit Policies

Hit Policies bestimmen die Semantik einer Entscheidungstabelle und schreiben vor, wie Regeln strukturiert werden müssen. Zum Beispiel können in manchen Fällen mehrere Regeln auf einen Sachverhalt zutreffen, die möglicherweise auch zu unterschiedlichen Ergebnissen führen. Daher muss für jede Entscheidungstabelle eine Hit Policy vorgegeben werden.

Hierbei gibt es folgende zwei Varianten:

  • Single Hit Policies
    Bei einer Single Hit Policy wird genau eine Regel berücksichtigt. Diese kann jedoch mehrere Outputs produzieren.
  • Multi Hit Policy
    Bei einer Multi Hit Policy werden mehrere Outputs produziert, welche dann in Listen aggregiert werden.

Die gewünschte Hit Policy für die Entscheidungstabelle wird in der linken oberen Ecke mit dem jeweiligen Anfangsbuchstaben angegeben (Beispiel: “P” steht für Priority).

Zudem hat jede Entscheidungstabelle eine konfigurierbare Vollständigkeitseinstellung.

  • Eine vollständige Entscheidungstabelle ist nur dann valide, wenn alle möglichen Eingaben abgedeckt werden. Wir empfehlen die Verwendung von vollständigen Entscheidungstabellen. Hierdurch können Sie verhindern, dass Probleme bei der Entscheidungsausführung auftreten, falls der Modellierer der Entscheidung nicht alle auftretenden Eingaben berücksichtigt hat.
  • Eine unvollständige Entscheidungstabelle ist selbst dann valide, wenn nicht alle möglichen Eingaben abgedeckt werden.

Im Folgenden werden die einzelnen Hit Policies vorgestellt und anhand eines Beispiels jeweils veranschaulicht.

Single Hit Policies

Der folgende Abschnitt erklärt alle Single Hit Policies anhand praktischer Beispiele.

Unique Hit Policy

Bei der Unique Hit Policy wird eine Inputkombination von genau einer Regel abgedeckt. Unique (Single) ist die Standardeinstellung in Signavios DMN-Editor.

Beispiel

Je nach der aktuellen Jahreszeit entscheidet ein Einzelhändler, welche Warengruppe er reduziert anbieten möchte. Nur eine Warengruppe kann reduziert angeboten werden, da nur eine Jahreszeit gleichzeitig vorherrschen kann.

Input Output
Jahreszeit Warengruppe
Frühling Gartenbedarf
Sommer Getränke
Herbst Bekleidung
Winter Lebensmittel

Any Hit Policy

Bei einer Any Hit Policy umfassen mehrere Regeln die gleiche Kombination von Eingabewerten. Diese Überlappung ist jedoch nur zulässig, wenn die betreffenden Regeln auch zum gleichen Output führen.

Beispiel

Wenn ein Antragsteller für einen Kredit unter 18 Jahre alt ist und bereits Schulden hat, wird der Antrag abgelehnt. Anderenfalls erhält er einen Kredit.

Input Output
Alter Schulden Ergebnis
< 18 ja abgelehnt
- nein genehmigt
>= 18 - genehmigt

Priority Hit Policy

Bei einer Priority Hit Policy können sich Regeln mit unterschiedlichen Outputs überlappen. Um das Output-Ergebnis zu bestimmen, werden die Outputs priorisiert. Dabei müssen die Outputs immer in Listenform sein. Der Wert mit dem geringeren Listenindex wird priorisiert.

Beispiel

In der Entscheidungstabelle wird die Logik festgelegt, mit welchem Alter Kunden bestimmte Rabattmarken erhalten. Für alle über 18 Jahre werden Rabattscheine für Sportgeräte und für alle über 3 Jahre für Spielzeuge ausgehändigt. Auf einen 30-jährigen Kunden treffen beide Regeln zu, da aber der Output “Sportgeräte” höher priorisiert ist, erhält der Kunde dafür eine Rabattmarke. Die Outputliste muss demnach [Sportgeräte, Spielzeug, Kleidung] sein.

Input Output
Alter Rabattmarke
> 18 Sportgeräte
> 3 Spielzeug
- Kleidung

First Hit Policy

Bei der First Hit Policy können sich Regeln überlappen. Aber nur eine Regel trifft zu: Die First Hit Policy geht von einer festen Reihenfolge der Regeln aus - diese werden von oben nach unten evaluiert. Sobald eine Regel zutrifft, werden keine weiteren Regeln mehr gecheckt und der Output der zuerst zutreffenden Regel wird für das Ergebnis angewandt.

Beispiel:

In der Entscheidungstabelle wird die Logik festgelegt, mit welchem Alter Kunden bestimmte Rabattmarken erhalten. Für alle über 18 Jahre werden Rabattscheine für Sportgeräte und für alle über 3 Jahre für Spielzeuge ausgehändigt. Auf einen 30-jährigen Kunden treffen beide Regeln zu, da aber die Regel mit den 18-jährigen ganz oben steht, wird sie als Entscheidungsgrundlage genommen. Der Kunde erhält demnach einen Gutschein für Kleidung.

Input Output
Alter Rabattmarke
> 18 Kleidung
> 3 Sportgeräte
- Spielzeug

Multi Hit Policies

Bei der Verwendung von Multi Hit Policies können mehrere Regeln für eine Kombination von Eingabewerten aktiviert werden. Dementsprechend geben Multi Hit Policies entweder eine Liste oder ein Aggregat der entsprechenden Ausgabewerte zurück. Der folgende Abschnitt erklärt alle Multi Hit Policies anhand praktischer Beispiele.

Collect Hit Policy (C)

Standardmäßig sammelt die Collect Hit Policy die Ausgabewerte von zutreffenden Regeln, kann aber konfiguriert werden, um die Werte als Summe, Minimum, Maximum oder Anzahl zu aggregieren.

Beispiel

Ein Online-Shop fügt bestimmten Bestellungen Rabatt-Coupons bei. Der Rabatt hängt hierbei von der Einkaufssumme ab. In der unten stehenden Entscheidungstabelle hängt das Ergebnis von der Variante der Collect Hit Policy ab. Im Falle einer Einkaufssumme von 250€, gibt

  • die Standard-Collect Hit Policy zwei Coupons (mit 5%, beziehungsweise 25% Rabatt) in nicht bestimmter Reihenfolge zurück,
  • die Summe-Collect Hit Policy einen Coupon mit 30% Rabatt zurück,
  • die Maximum-Collect Hit Policy einen Coupon mit 25% Rabatt zurück.
  • die Minimum-Collect Hit Policy einen Coupon mit 0% Rabatt zurück und enttäuscht damit unseren Kunden,
  • die Anzahl-Collect Hit Policy mit 2 ein in diesem Szenario nicht sinnvolles Ergebnis zurück.
Input Output
Gesammtsumme Rabatt-Coupon
<= 50€ 0%
> 50€ 5%
> 200€ 25%

Output Order Hit Policy (O)

Die Ergebnisse sind nach Priorität der Output-Werte sortiert.

Beispiel

Ein Online-Shop fügt Bestellungen kleine Geschenke bei. Die Geschenke, die ein Kunde erhält, hängen von der Höhe der Bestellsumme ab. Falls die Bestellsumme 50€ oder geringer ist, erhält der Kunde einen Rabatt-Coupon. Falls die Bestellsumme höher als 50€ ist, erhält der Kunde zusätzlich ein Paket Qualitätskaffee. Unter Verwendung einer Output Order Hit Policy gibt die unten stehende Tabelle für die Einkaufssumme von 250€ das Ergebnis [Kaffee, Rabatt-Coupon] zurück, das entsprechend der festgelegten Ausgabeliste sortiert ist.

Input Output
Gesammtsumme Geschenk = [Kaffee, Rabatt-Coupon]
- Rabatt-Coupon
> 50€ Kaffee

Rule Order Hit policy (R)

Die Ergebnisse sind nach der Reihenfolge der zutreffenden Regeln sortiert.

Beispiel

Wenn die Rule Order Hit Policy auf die oben stehende Tabelle angewandt wird, führt eine Gesammtsumme von 250€ zum Ergebnis [Rabatt-Coupon, Kaffee], das entsprechend der Reihenfolge der zutreffenden Regeln sortiert ist.

Decision Requirements Diagram (DRD)

Ein vollständiger Decision Requirements Graph kann zum Beispiel wie folgt aussehen:

Beispiel: Decision Requirements Diagram.

Beispiel: Decision Requirements Diagram.