DMN-Tutorial
Inhaltsverzeichnis
Was ist DMN?
DMN steht für Decision Model and Notation. Es handelt sich um einen Standard, der von der Object Management Group (OMG) verwaltet wird und sich in verschiedenen Branchen durchgesetzt hat. Unternehmen nutzen DMN, um Entscheidungsmodelle zu entwerfen, die zur Automatisierung von Entscheidungsprozessen verwendet werden. DMN dient als gemeinsame Sprache, um zwischen Fachabteilungen und der IT bezüglich wiederholbarer Geschäftsregeln und Entscheidungsmanagement Alignment zu erreichen. Der Standard steigert die geschäftliche Effizienz, verringert das Risiko von Fehlern durch Menschen und stellt sicher, dass die Entscheidungsmodelle innerhalb des Unternehmens austauschbar sind.
Kernelemente von DMN:
- Entscheidungstabellen — Einfache und intuitive Darstellung von Entscheidungen, bestehend aus Eingabe, Bedingung und Ausgabe.
- FEEL (Friendly Enough Expression Language) — Wird verwendet, um Bedingungen in Entscheidungstabellen auszudrücken, damit sie ausgeführt werden können.
Entscheidungsdiagramme (Decision Requirements Diagrams, DRD) — Werden erstellt, wenn eine Entscheidung nicht in einer einfachen Tabelle beschrieben werden kann. Zum Beispiel, wenn es Abhängigkeiten zwischen Zwischenentscheidungen gibt, deren Ergebnisse als Input für die zu treffende endgültige Entscheidung dienen.
Vorteile von DMN
Standard
DMN gehört nicht einem bestimmten Unternehmen, sondern einer Institution (OMG), die bereits durch andere weltweit genutzte Standards etabliert ist, z. B. BPMN und UML (Unified Modeling Language). Der DMN-Standard wird von zahlreichen Softwareprodukten unterstützt, sodass Sie weniger abhängig von den Produkten eines bestimmten Herstellers sind.
Direkte Ausführung
In DMN können Entscheidungen in derselben Sprache modelliert und ausgeführt werden. Business-Analysten können die Regeln, die zu einer Entscheidung führen, in leicht lesbaren Tabellen modellieren, und diese Tabellen können direkt von einer Decision Engine (wie Camunda) ausgeführt werden. Dadurch wird das Risiko von Missverständnissen zwischen Business-Analysten und Entwicklern minimiert, und es ist sogar möglich, in der Produktion schnell Änderungen durchzuführen.
Erfahrung
DMN als Standard ist noch jung, aber er wurde von Fachkräften entwickelt, die jahrzehntelange Erfahrung mit dem Management von Geschäftsregeln haben. Allerdings schreibt der Standard keine speziellen Implementierungsmuster vor, sodass modernere und schlankere Implementierungen möglich sind als bei herkömmlichen Business-Rule-Engines.
Dieses Tutorial bietet eine schnelle Einführung in DMN, wie in Version 1.1 definiert.
Eine einfache Entscheidungstabelle
Unser DMN-Tutorial beginnt mit einer recht einfachen Entscheidungstabelle:
Nehmen wir an, Sie haben Gäste zum Abendessen eingeladen. Sie fragen sich, was Sie kochen sollen. In diesem Beispiel folgen wir einer sehr einfachen Entscheidungslogik: Je nach Jahreszeit entscheiden Sie sich für ein Gericht. Im Herbst nehmen Sie Rippchen, im Winter Roastbeef und so weiter.
Schauen wir uns die Elemente in diesem Beispiel an:
- In der oberen linken Ecke sehen wir den Namen der Entscheidungstabelle: „Gericht“
- Darunter befindet sich ein „U“, das für „Unique“ (eindeutig) steht und die definierte Hit Policy für diese Entscheidungstabelle darstellt. Dies bedeutet, dass bei einer zu treffenden Entscheidung nur eine der folgenden Zeilen zutreffen kann. In diesem Fall kann die aktuelle Jahreszeit nur Herbst, Winter, Frühling oder Sommer sein. Sie können nicht zwei Jahreszeiten gleichzeitig auswählen, auch wenn der Sommer dieses Jahr verdammt kalt ist.
- Die hellgrünen Spalten beziehen sich auf mögliche Eingabedaten. In diesem Beispiel gibt es nur eine Eingabespalte, da wir nur an der aktuellen Jahreszeit interessiert sind. Die Zelle mit dem Text „Jahreszeit“ definiert dies. In DMN ist dies die Bezeichnung für einen Input-Ausdruck. Der Ausdruck selbst ist in diesem Beispiel der Einfachheit halber ausgeblendet, wird aber später gezeigt. Die Zellen darunter (die so genannten Input-Einträge) beziehen sich auf die möglichen Bedingungen für die Eingabe. Diese Bedingungen stehen in Anführungszeichen (z. B. „Sommer“), weil wir technisch gesehen String-Werte vergleichen.
- Für jede mögliche Eingabe (d. h. die aktuelle Jahreszeit) wird in der Zelle daneben der entsprechende Output-Eintrag definiert. So bringen wir zum Ausdruck, dass wir je nach Jahreszeit ein bestimmtes Gericht wählen. Auch hier müssen wir Anführungszeichen (wie „Steak“) verwenden, da wir String-Werte zuweisen.
- Die Definition, dass für einen Input-Eintrag, der wahr (true) ist (oder eine Kombination von wahren Input-Einträgen), ein bestimmter Output-Eintrag gelten soll, ist eine Regel. Jede Regel wird in einer Tabellenzeile unterhalb der Tabellenüberschrift definiert und hat eine Nummer, die Sie in den Zellen links daneben finden können.
- Zu guter Letzt können Sie Ihre Regeln in der rechten Spalte mit Anmerkungen versehen. Diese Anmerkungen geben nur zusätzliche Informationen und werden von einer Decision Engine ignoriert.
Alles ganz einfach, oder? Natürlich ist DMN vielschichtiger, aber die Grundprinzipien sind in der Tat sehr einfach.
Kombinierung von Bedingungen
Meistens besteht eine Regel nicht nur aus einer Bedingung, sondern aus mehreren Bedingungen, die kombiniert werden. Wir können dies ausdrücken, indem wir der Entscheidungstabelle Input-Spalten hinzufügen:
Wir können zum Beispiel auch Gäste berücksichtigen, die Vegetarier sind. Es ist also egal, in welcher Jahreszeit wir uns befinden, wir können diesen Gästen kein Fleisch servieren. Zum Glück haben wir immer etwas Pasta zur Verfügung. Durch die Kombinierung der beiden Input-Spalten „Jahreszeit“ und „Vegetarier“ haben wir dafür gesorgt, dass die ersten vier Regeln nur dann als wahr gewertet werden können, wenn die Gäste keine Vegetarier sind. Regel Nummer 5 hat ein „-“ in der Eingabe, die die Jahreszeit überprüft. Das bedeutet, dass Gäste unabhängig von der Jahreszeit Pasta erhalten, wenn sie Vegetarier sind.
Wie Sie sehen können, folgt die Kombinierung von Input-Einträgen in einer Regel (d. h. einer Tabellenzeile) immer einer UND-Logik: „Wenn es Herbst ist und meine Gäste keine Vegetarier sind, serviere ich Spareribs.“
Einführung in FEEL
Nachdem Sie nun ein Grundverständnis zur Struktur einer Entscheidungstabelle haben, wollen wir uns die möglichen Eingaben genauer ansehen. Einfach gesagt werden bestimmte Daten mit bestimmten Strings verglichen (z. B. dass die Jahreszeit Sommer sein soll). DMN bietet jedoch fortgeschrittenere Konzepte zur Überprüfung von Eingaben. Teil des DMN-Standards ist die Friendly Enough Expression Language (FEEL).
FEEL definiert eine Syntax zur Formulierung von Bedingungen, anhand derer Eingabedaten ausgewertet werden sollen. Sie können zum Beispiel in FEEL beschreiben, dass bestimmte Eingabedaten wie folgt aussehen sollen:
- Eine konkrete Zeichenfolge (String), Beispiel wäre die Jahreszeit, die „Sommer“ lauten soll
- Wahr oder falsch (beispielsweise, ob unsere Gäste Vegetarier sind oder eben nicht)
- Eine Zahl, die unter, über oder genau gleich einer anderen gegebenen Zahl ist
- Eine Zahl, die zwischen einer bestimmten Mindest- und einer bestimmten Höchstzahl liegt
- Ein Datum, das vor oder nach einem anderen bestimmten Datum liegt oder genau dieses Datum ist
- … und vieles mehr
Sehen wir uns dazu das folgende Beispiel an:
Das erste, was Ihnen auffallen wird, sind zwei zusätzliche Zeilen mit grauen Zellen. Diese Zeilen beschreiben technische Details, die die Decision Engine benötigt, um die Entscheidung auszuführen. Die erste enthält Ausdrücke, die sich — in diesem Fall — einfach auf Variablennamen beziehen, nämlich „season“, „guestCount“ und „desiredDish“. Die zweite Zeile teilt der Engine den Typ des jeweiligen Ergebnisses des Ausdrucks mit, in diesem Fall „string“ und „integer“.
In den ersten Beispielen wurden diese Zeilen ausgeblendet, um es anfangs möglichst einfach zu halten. Tatsächlich sind sie aber wichtig, denn sie bestimmen, welche FEEL-Ausdrücke für die Input-Eingaben zur Verfügung stehen.
Sehen wir uns jede einzelne Regel an, d. h. jede Zeile:
- Wenn es Herbst ist und Sie bis zu 8 Gäste erwarten, bereiten Sie Spareribs zu.
- Wenn es Winter ist und Sie bis zu 8 Gäste erwarten, servieren Sie Roastbeef.
- Ist es Frühling und Sie erwarten bis zu 4 Gäste, tischen Sie sehr feines, Dry-Aged-Gourmet-Steak auf.
- Ist es aber Frühling und Sie erwarten 5 bis 8 Gäste, servieren Sie ein gewöhnliches Steak.
- Wenn es Herbst, Winter oder Frühling ist und Sie mehr als 8 Gäste erwarten, entscheiden Sie sich für Eintopf.
- Im Sommer gibt es auf jeden Fall einen leichten Salat und natürlich ein schönes Steak. Juhu!
Wie Sie wahrscheinlich schon vermuten, ist dies nur die Spitze des Eisbergs. Es gibt noch viel mehr, was Sie in DMN-Entscheidungstabellen ausdrücken können, wie wir im DMN Reference Guide beschreiben.
Für Entwickler: Sie können eine implementierte Version dieses Beispiels auf GitHub finden.
DMN- und BPMN-Prozesse
Vielleicht denken Sie jetzt:
Warum sollte ich überhaupt DMN benutzen, ich kann diese Regeln auch mit BPMN Gateways ausdrücken!
Wenn wir das obige Beispiel in BPMN ausdrücken, sieht es wie folgt aus:
Die Probleme hierbei sind jedoch offensichtlich: Regeln lassen sich in BPMN viel ausführlicher ausdrücken, insbesondere wenn mehrere Bedingungen zu berücksichtigen sind. Das Diagramm wird komplex und schwer zu verwalten.
Deshalb enthält BPMN eine so genannte Geschäftsregelaufgabe, die in einer späteren Version des BPMN-Standards als Entscheidungsaufgabe bezeichnet werden sollte: Diese Aufgabe bezieht sich auf eine Entscheidung, die getroffen werden muss, und das Ergebnis der Entscheidung ermöglicht dem nachfolgenden exklusiven Gateway, den Ablauf zu leiten, wie Sie im folgenden Beispiel sehen können.
Sowohl bei der Modellierung als auch bei der Ausführung können wir die Aufgabe „Gericht festlegen“ mit der DMN-Entscheidungstabelle verknüpfen, die ausgeführt wird, wenn die Entscheidung getroffen werden soll, und das Ergebnis bestimmt dann den weiteren Ablauf in BPMN.
In diesem speziellen Beispiel könnte man die Verwendung des Fluss-Routing ohnehin in Frage stellen. Es gibt sechs Aufgaben, bei denen es um die Zubereitung einer Mahlzeit geht, der einzige Unterschied ist die Art der Mahlzeit. Es besteht kein offensichtlicher Vorteil darin, diese sechs unterschiedliche Aufgaben zu haben. Ein alternatives Muster wäre das folgende:
Das ist zu einfach, oder? Aber in diesem Fall ist es in der Tat ein geeignetes Muster.
BPMN und DMN zu kombinieren, ist äußerst sinnvoll. Leider ist dieser Ansatz von der OMG noch nicht standardisiert. Dies bedeutet, dass eine Verknüpfung einer BPMN-Geschäftsregelaufgabe mit einer DMN-Entscheidung immer herstellerspezifisch ist.
Entscheidungsdiagramme
Wenn Sie komplexe Entscheidungen diskutieren und analysieren möchten, die anhand anderer Entscheidungen getroffen wurden, können Entscheidungsdiagramme (Decision Requirements Diagrams, DRD) hilfreich sein. Dies ist eine recht einfache Notation, die in der DMN-Norm definiert ist und im Wesentlichen aus den folgenden Elementen besteht:
- Entscheidungen: Die Bestimmung eines Ausgabewerts (Output-Wert) aus einer Reihe von Eingabewerten (Input-Werte) unter Verwendung einer logischen Definition. Diese Entscheidungslogik können Sie in Entscheidungstabellen ausdrücken.
- Eingabedaten: Die Eingabedaten, die Sie in Ihre Entscheidungslogik „einspeisen“, um den Output-Wert zu bestimmen.
- Zusammenhang zwischen Entscheidungen: Sie können Entscheidungen mit Pfeilen verbinden und so angeben, welcher Entscheidungs-Output als Input für eine andere Entscheidung betrachtet wird.
Es gibt noch weitere Symbole in der DRD-Notation, die wichtigsten sind jedoch diese drei. Sehen wir uns ein Beispiel an:
Nehmen wir an, dass wir für unser Abendessen auch die Getränke auswählen müssen, die wir servieren wollen. Diese Entscheidung sollte sich an dem Gericht orientieren, das wir zubereiten, und auch Kinder berücksichtigen. Die Entscheidungstabelle könnte wie folgt aussehen:
Sie werden feststellen, dass diese Tabelle ein „C“ in der oberen linken Ecke hat, anstelle des „U“, das Sie in den vorherigen Beispielen gesehen haben. Das C steht für „Collect“ (Sammeln), was eine andere Hit Policy ist und bedeutet, dass mehr als eine Regel wahr sein könnte, was zu einer Liste von Output-Werten führt.
Wenn es zum Beispiel Spareribs gibt und unsere Gäste mit Kindern kommen, servieren wir Wasser, Apfelsaft und das berühmte Aecht Schlenkerla Rauchbier.
Natürlich müssen wir zuerst das Gericht bestimmen, das wir zubereiten wollen, bevor wir uns für die Getränke entscheiden können. Und diese Anhängigkeit können Sie in einem DRD beschreiben, wie wir es in diesem Beispiel getan haben:
Bereit, loszulegen?
Lernen Sie die Plattform kennen oder erhalten Sie eine Demo
