Development Softwarearchitektur

Fachlogik mit DMN modellieren

Die Spezifikation von funktionalen Anforderungen in natürlicher Sprache oder mit Modellen der UML ist häufig unzulänglich. Neben dem Business-Analysten muss sich auch ein Entwickler in die Spezifikation einarbeiten und mögliche Ungereimtheiten vor der Codierung beseitigen. Mit dem OMG-Standard DMN (Decision Model and Notation) können Business-Analysten funktionale Anforderungen spezifizieren, prüfen und simulieren. Die mit DMN erstellte Logik ist durch eine DMN-Engine ausführbar und ermöglicht ein modellgetriebenes Vorgehen.

Wilfried Kurth

Author

16.12.2022
Lesezeit: 19 Minuten
117 Views

Funktionale Anforderungen natürlichsprachlich so zu spezifizieren, dass sie widerspruchsfrei, vollständig, eindeutig und auch noch korrekt sind, ist sehr aufwendig und fast unmöglich. Schon eine einfache und kleine funktionale Anforderung, wie beispielsweise die Generierung einer Ansprache für eine Person, erfordert viel Prosa. In Abbildung 1 ist eine funktionale Anforderung für die Bildung der Ansprache einer Person beschrieben. Der erste Satz orientiert sich an der Satzschablone für Anforderungen, wie sie in [Rup20] empfohlen wird. Obwohl die Spezifikation dieser Anforderung schon recht umfangreich ist, ist sie nicht vollständig – so fehlt zum Beispiel eine Aussage darüber, was passieren soll, wenn nicht alle notwendigen Daten vorliegen. In Abbildung 2 ist der Prozess von der Anforderung bis zur Codierung beschrieben. Im besten Fall erstellt der Business-Analyst seine Anforderung, der Entwickler analysiert diese, setzt sie anschließend um und der Business-Analyst testet sie zum Schluss noch erfolgreich. In den meisten Fällen läuft es nicht so gut. Es wird eher so laufen, dass der Entwickler schon beim Analysieren der Anforderung Fragen hat oder Widersprüche entdeckt. Spätestens bei der Codierung wird er Lücken erkennen und im ungünstigsten Fall entdeckt der Business-Analyst erst beim Test, dass noch etwas nicht stimmt. Nach jedem entdeckten Mangel müsste der Business-Analyst die Anforderungsspezifikation wieder nachführen. Aber auch das passiert häufig nicht, sodass Anforderungsspezifikation und Codierung auseinanderlaufen. Am Ende hat das Anforderungsdokument keine Bedeutung mehr, da die Wahrheit nur noch im Programm-Code zu finden ist. Damit hat der Business-Analyst die Hoheit über die Fachlichkeit verloren.

Abb. 1: Natürlich-sprachliche Anforderungsspezifikation

Abb. 2: Anforderungs- und Entwicklungsprozess

Decision Model and Notation

Decision Model and Notation (DMN) ist ein Standard der Object Management Group [OMG], der 2016 erstmalig publiziert wurde. DMN ist, wie auch schon die Business Process Model and Notation (BPMN), eine Notation für Business-Analysten. Das Wort Decision (Entscheidung) in Decision Model and Notation ist etwas irreführend. So wurde von [Hal10] mit „The Decision Model“ eine Methode für Business-Analysten vorgestellt, welche nur auf Entscheidungstabellen beruht. Daher wird auch DMN auf den ersten Blick mit Entscheidungstabellen gleichgesetzt und ein paar Tool-Anbieter, wie zum Beispiel [Camu] oder [Flow], haben aus der DMN-Spezifikation tatsächlich nur den Teil der Entscheidungstabellen umgesetzt. DMN ist aber viel mehr. DMN ist eine Notation für die Spezifikation von Geschäftslogik – diese kann auch regelbasierte Entscheidungen mittels Entscheidungstabellen enthalten. Neben Entscheidungstabellen bietet DMN die Möglichkeit, Geschäftslogik mit literalen Ausdrücken gemäß der Friendly Enough Expression Language (FEEL) zu beschreiben. DMN enthält ca. 100 vordefinierte Funktionen für Logik, Zeichenfolgen, Datum/Uhrzeit, Listen und Numerik. Zusätzlich können eigene Funktionen, sogenannte Business Knowledge Models (BKM), für Wiederverwendung, Iteration oder Rekursion definiert werden. Das Decision Model besteht aus einem Decision Requirements Graph (DRG). Der DRG besteht aus Decisions und BKMs. Mit diesen Elementen beschreibt man die Geschäftslogik. Weiterhin enthält ein DRG Input Data. Dieses Element steht für die von außerhalb des DRG gelieferten Informationen. Ein DRG kann durch ein oder mehreren Decision Requirements Diagrams (DRD) visualisiert werden.

Anforderungsspezifikation mit DMN

Die Anforderungen aus Abbildung 1 lassen sich als Decision Model mit sechs Decisions darstellen:

Stunde der aktuellen Uhrzeit (vordefinierte Funktion),
Alter der Person (vordefinierte Funktion),
Begrüßung (Entscheidungstabelle),
Anrede (Entscheidungstabelle),
Name (Entscheidungstabelle),
Ansprache (Kontext).

Das DRD in Abbildung 3 zeigt den Überblick über alle zusammengehörenden Decisions und gibt durch die Pfeile (vom Typ Informationsanforderung) an, wo der Input für jede Decision herkommt. Jede Decision benötigt im Allgemeinen Eingabedaten, auf die Geschäftslogik angewendet wird. Wenn die Eingabedaten außerhalb des Decision Model existieren und von außen mitgegeben werden müssen, werden diese als Input Data bezeichnet. Das Ergebnis einer Decision sind wieder Daten. Ausgabedaten einer Decision können wiederum Eingabedaten anderer Decisions sein. Input Data brauchen Datentypen. Der Datentyp kann ein einfacher FEEL-Datentyp (z. B. date oder string) sein oder auch ein selbstdefinierter Datentyp.
Abbildung 4 zeigt den selbstdefinierten Datentyp tPartner¹ für Input Data PartDat. Die Zuweisung von Datentypen zu Input Data ist in jedem Fall zwingend. Darüber hinaus empfiehlt [Meth-a], allen Variablen in einem Decision Model Datentypen zuzuweisen.
Für die Darstellung der Geschäftslogik in einer Decision gibt es verschiedene vorgegebene „Boxed Expression“-Typen. Die Decision aktuelleStunde besteht aus dem „Boxed Expression“-Typ Literaler Ausdruck und verwendet für die Ermittlung der Stunde der aktuellen Uhrzeit die eingebaute Funktion now(). Die Ergänzung. hour gibt die Stunde zurück. Die Decision alter verwendet für die Ermittlung des Alters eine weitere vordefinierte Funktion years and months duration(from, to) mit der Ergänzung. years, welche die Anzahl ganzer Jahre aus der Zeitdauer zurückgibt. Diese Decision benötigt vom Input Data PartDat das Geburtsdatum PartDat.gebDat für den ersten Funktionsparameter. Der zweite Funktionsparameter ist eine weitere vordefinierte Funktion today(), welche das aktuelle Datum zurückgibt. Die Decision begrüssung, verwendet den „Boxed Expression“-Typ Entscheidungs tabelle, die aus den zuvor ermittelten Daten alter und aktuelleStunde eine passende Begrüßung ableitet. Die Decision anrede verwendet ebenfalls eine Entscheidungstabelle, die aus alter und Partner. geschlecht eine passende Anrede ableitet. Die Decision name verwendet auch eine Entscheidungstabelle, die aus alter und Partner.geschlecht einen Namen ableitet. Die oberste Decision Ansprache verwendet den „boxed expression“-Typ Kontext mit drei Kontexteinträgen, welche die drei Zwischenergebnisse begrüssung, anrede und name zu einem Ergebnis Ansprache zusammenfassen.

¹⁾ Die Modellierung der Datentypen ist durch die OMG-Spezifikation nicht vorgegeben. Im hier verwendeten Modellierungswerkzeug Innovator werden die Datentypen durch Strukturdefinitionen im Strukturdiagramm modelliert.

Abb. 3: Decision Model für Ansprache

Abb. 4: Benutzer-definierter Datentyp tPartner und Input Data PartDat

Simulation

Den großen Mehrwert in der Nutzung von DMN hat der Business-Analyst erst, wenn er auch ein Modellierungswerkzeug verwendet, welches die Möglichkeit bietet, Decisions zu simulieren. Hierzu lässt sich der Business-Analyst zuerst eine Vorlage für DMN-Testdaten je Input Data erstellen und gibt anschließend die Daten für die Testfälle an. In der anschließenden Simulation wird für jede Decision ein Ergebnis ermittelt. Damit kann der Business-Analyst sicherstellen, dass seine Anforderungsspezifikation sowohl syntaktisch korrekt als auch fachlich richtig ist. Für den besseren Vergleich mit dem Decision Model sind in Abbildung 5 die Testdaten der Input Data und die Teilergebnisse der simulierten Decisions ähnlich wie das DRD in Abbildung 3 angeordnet und miteinander verbunden. Das hier verwendete Modellierungswerkzeug Innovator der Firma [MID] ermöglicht seit Version 14.2 die Simulation von Decisions mit Testdaten und verwendet dazu die Drools DMN-Engine. Die DMN-Engine ist nicht mit einer Business Rule Engine gleichzusetzen. Die Software Drools (vgl. [Droo]) beinhaltet auch eine inferenzbasierte Rule Engine für die proprietäre Regelsprache Drools Rule Language (DRL).

Abb. 5: Testdaten und Simulationsergebnisse

Behavioral Rules und DMN

Der DRG berücksichtigt noch nicht, was bei fehlerhaften Daten oder beim Fehlen zwingend erforderlicher Daten, wie Name oder Geburtsdatum, geschehen soll. Die Ermittlung einer adäquaten Ansprache erfordert, dass mindestens Vor- und Nachname sowie das Geburtsdatum einer Person bekannt sind. Wenn Geburtsdatum, Voroder Nachname fehlen, liefert die Decision nur „null“ zurück, also kein Ergebnis. Doch nicht nur fehlende Daten, sondern auch Daten in ungenügender Qualität stellen ein Problem dar. Läge das Geburtsdatum in der Zukunft oder bestünden Vor- oder Nachname nur aus einem leeren String, lieferte die Decision auch kein brauchbares Ergebnis. [Ros09] bezeichnet solche Geschäftsregeln, die die Existenz von Daten oder das Vorhandensein bestimmter Dateninhalte erfordern und somit verletzt werden können, als Behavioral Rules. Die Validierung von Input Data mit DMN-Mitteln ist in [Meth-b] ausführlich beschrieben. Hier im Beispiel (siehe Abbildung 6) sind nur zwei Arten von Datenvalidierung umgesetzt. Die eine Decision hinweisAufFehlendeDaten prüft, ob alle Daten vorhanden sind, und enthält den ‘Boxed Expression’-Typ Kontext mit zwei Kontexteinträgen und einem Kontextergebnis:

Der erste Kontexteintrag notwendi- geDaten legt die Attribute fest, die Daten enthalten müssen.
Der zweite Kontexteintrag fehlen- deDaten ermittelt die Attribute, bei denen Daten fehlen.
Das Kontextergebnis liefert einen Hinweis, wenn Daten fehlen.

Hier sieht man die Mächtigkeit der Notation mit ihren ca. 100 vordefinierten Funktionen, die es ermöglicht, fast jede Art von Geschäftslogik zu beschreiben. get entries() ist eine vordefinierte Funktion, mit der die Struktur (item.key) und der Inhalt (item.value) einer Variablen abgefragt werden. Die eckigen Klammern sind ein Filterausdruck auf eine Datenrelation in einer Variablen. Die andere Decision hinweisAufFalsche-Daten prüft die Richtigkeit der Daten und verwendet hierzu eine Entscheidungstabelle. Mit der Auswertungsstrategie „Sammeln: Liste“ ist angegeben, dass mehr als eine Regelzeile der Entscheidungstabelle zutreffen kann. Die Decision HinweiseFürDaten fasst die hinweise in einer Liste zusammen und gibt mit DatenSindValide ein true oder false an, wenn es Hinweise gibt, bzw. nicht gibt. Die anschließende Simulation zeigt das Ergebnis, wenn Vorname und Geburtsdatum im Input Data null enthalten (siehe Abbildung 7).

Abb. 6: Decision Model HinweiseFürDaten

Abb. 7: Simulationsergebnis

Datenaufbereitung mit DMN

Eine weitere Herausforderung bei Spezifikation von Anforderungen mit DMN ist der Umgang mit abgeschlossenen Wertebereichen, wie zum Beispiel bei „Partner. geschlecht“. Häufig werden Zahlen (1, 2, 3) statt Texten (männlich, weiblich, divers) gespeichert und die Zuordnung von Zahlen zu Texten ist in einer gesonderten Wertebereichstabelle persistiert. Dort können noch zusätzlich fremdsprachliche Übersetzungen (male, female, diverse) oder neben einer Langform auch noch eine Kurzform (m, w, d) hinterlegt sein. Solche Wertebereichstabellen existieren häufig zentral, aber für die dezentrale Nutzung werden auch Kopien der Daten dezentral vorgehalten. Zahlen statt Texten in Decisions erschweren ihre Erstellung und machen sie schlechter lesbar. Mit DMN ist eine Umwandlung der Daten von Zahl nach Text (und wieder von Text nach Zahl) möglich. Dafür kommt der „boxed expression“-Typ Relation zum Einsatz. Das Decision Model in Abbildung 8 zeigt, wie eine Zuordnung von Zahlen und Texten für das Input Data Partner.geschlecht als Relation in einem BKM dargestellt wird und diese mit der Decision Partner abgefragt werden kann. Die Zuordnung von Zahlen zu Texten ist als Relation abgebildet, damit der Inhalt flexibel abgefragt werden kann:

Zu einer Zahl möchte man den dazugehörigen Text ermitteln,
Zu einem Text möchte man die dazugehörige Zahl ermitteln.

Der DRG erhält eine neue Decision Partner, welche die Logik für die Datenumwandlung enthält. Diese Decision hat dieselbe Struktur wie Input Data PartDat und verwendet den „Boxed Expression“-Typ Kontext. Die Kontexteinträge vorname, nachname und gebDat erhalten die Daten unverändert aus den Input Data. Nur im Kontexteintrag geschlecht wird mit einem weiteren Kontext und dem Kontexteintrag „Wertetabelle“ das BKM „WerteTabelleGeschlecht“ aufgerufen und im Kontexttextergebnis mit einem Filterausdruck der passende Text zur Zahl für geschlecht ermittelt. In Abbildung 9 ist eine weitere Umwandlung von Daten, diesmal von Text nach Zahl, für die Werte aus den Kontexteinträgen begrüssung und anrede der Decision Ansprache dargestellt.

Abb. 8: Decision Model zur Umwandlung von Zahlwerten in Textwerte

Abb. 9: Decision Model zur Umwandlung von Textwerte in Zahlwerte

Decisions und Prozess

Der gesamte DRG (siehe Abbildung 10) für die Anforderungsspezifikation ist mittlerweile recht umfangreich und umfasst Geschäftslogik aus verschiedenen Bereichen:

Kasten 1: Die Prüfung, ob die Daten vorhanden sind und die richtigen Werte enthalten, damit eine sinnvolle Ansprache gebildet werden kann
Kasten 2: Die Umwandlung von Zahlen zu Texten, um die Decisions lesbar zu halten
Kasten 3: Die eigentliche fachliche Geschäftslogik, zur Bestimmung der Ansprache einer Person
Kasten 4: Die Umwandlung von Texten zu Zahlen für eine mögliche Persistierung der Daten

Abb. 10: Gesamtes Decision Requirements Diagram

„Business Decision as a whole“ mit Decision Services unterteilen

Wie kann die Erkenntnis darüber, ob die Daten für die Bildung einer Ansprache vorhanden sind und auch die richtigen Werte enthalten, berücksichtigt werden? Wenn die Daten in Ordnung sind, kann die Ansprache gebildet werden. Aber was geschieht, wenn die Daten nicht in Ordnung sind? Das Ergebnis des Decision Model ist eine Ansprache und keine Fehlermeldung. Die Lösung besteht darin, die Gesamt-Decision in kleinere Decisions zu unterteilen und durch einen Prozess zu orchestrieren. In [Bru16] beschreibt B. Silver den Mehrwert eines Decision Model, welches zusammengehörende Geschäftslogik von Anfang bis Ende zeigt, unabhängig davon, ob sie als Ganzes oder in Teilen ausgeführt wird, und verwendet hierfür den Begriff „Business Decision as a whole“. Die „Business Decision as a whole“ kann man mit Decision Services in kleinere Teile unterteilen, ohne die Geschäftslogik zu verändern. Das „Decision Service“-Element (siehe Abbildung 11) definiert eine ausführbare Einheit von Geschäftslogik. In den einzelnen Abschnitten gibt man an, welche Elemente des Gesamtmodells in dem Decision Service Information (Input Data) oder Eingabeentscheidung sind, welche die Ausgabeentscheidung ist und welche gekapselten Entscheidungen enthalten sind. In Abbildung 12 ist visualisiert, wie die Gesamt-Decision mittels Decision Services in kleinere ausführbare Einheiten unterteilt ist:

Der erste Decision Service umfasst die Decisions zur Prüfung der Datenvalidität.
Der zweite Decision Service umfasst die Decision zur Umwandlung von Zahlen in Texte.
Der dritte Decision Service umfasst die Decisions mit der eigentlichen Geschäftslogik für die Anrede.
Und der letzte Decision Service umfasst die Decisions zur Umwandlung von Texten in Zahlen.

Abb. 11: Decision Service

Abb. 12: Teil-DRDs mit Decision Services

DMN vervollständigt BPMN

In der BPMN ist der Task ein atomares Element und kann mit Mitteln der BPMN nicht weiter strukturiert beschrieben werden. Auf der Ebene des atomaren Task geht es fast immer um die Verarbeitung von Information: In einem Benutzer-Task gibt der Nutzer Eingabe- oder Ausgabe-Daten vor. In einem Service-Task wird die Funktionalität eines IT-Service einer Applikation aufgerufen. Damit aus modellierten Prozessen ausführbare Prozesse werden, ist IT-Unterstützung erforderlich. GUIs designen oder neue IT-Services entwickeln, ist die Domäne der IT und nicht des Business. DMN ermöglicht Business-Analysten, die Informationsverarbeitung in einem Task als ausführbare Decision zu modellieren. Das ermöglicht ein Stück weit Unabhängigkeit von der IT, da nicht mehr jede funktionale Anforderung zuvor als Activity Service programmiert und bereitgestellt werden muss.
Abbildung 13 zeigt einen Prozess, der die Decision Services mittels Decision Tasks orchestriert:

Der Task „Partnerdaten validieren“ ruft die Decision HinweiseFürDaten auf. Im anschließenden Gateway wird aufgrund des Ergebnisses in der Variable DatenSindValide verzweigt.
Der Task „Texte für Zahlwerte ermitteln“ ruft die Decision Partner auf.
Der Task „Ansprache ermitteln“ ruft die Decision Ansprache auf.
Der Task „Zahlwerte für Texte ermitteln“ ruft die Decision AnsprDat auf.

Abb. 13: Prozess mit Decision Tasks und Decision Services

Datenfluss in Prozessen

In einem BPMN-Prozessmodell sind Tasks über Sequenzflüsse miteinander verbunden. Über diese Sequenzflüsse fließen jedoch keine Daten zwischen den Tasks. Stattdessen fließen die Daten zwischen den Prozessvariablen und Tasks. In Abbildung 13 gibt es die Dateneingabe-Prozessvariable PartDat für die Daten, die der Prozess von außen erhält, und die Datenausgabe-Variablen HinweiseFür-Daten und AnsprDat für die Daten, die vom Prozess nach außen gegeben werden, sowie die Datenobjekt-Prozessvariablen Partner und Ansprache für die Daten, die zwischen den Tasks fließen. Leider setzt jeder Anbieter für BPMN die Definition der Datentypen und das Mapping zwischen Prozess- und Task-Daten anders um, und es erfordert häufig IT-Unterstützung, um es anzuwenden. Trisotech hat hier einen Ansatz aufbauend auf den DMN-Konstrukten FEEL und Boxed Expressions gewählt, der in [Tris] beschrieben ist.

Ausführungsvarianten für Prozesse mit Decision Tasks

Das Mapping der Daten zwischen Prozess und Tasks ist Voraussetzung, um einen ausführbaren Prozess zu erhalten. Ein Prozess, der keine Benutzer- oder manuellen Tasks enthält, ist damit vollständig automatisierbar. Prozess und Decisions benötigen eine entsprechende Process- beziehungsweise Decision-Engine, welche die Prozess- oder Decision-Instanzen auf Basis der Modelle ausführen. Hier kann man grob drei Varianten von Ausführung unterscheiden:

zentrales Process/Decision Management System,
dezentrale Process/Decision Execution Services
Embedded Process/Decision Engines.

Ein Prozess ohne Interaktion ist durch alle drei Varianten ausführbar. Ein Prozess, der außerdem nicht auf Ereignisse von außen warten muss (eintreffende Dokumente oder ablaufende Termine), muss nicht durch ein zentrales Process Management System gesteuert werden. Ist außerdem eine hohe Anzahl an Prozessinstanzen zu erwarten, sind dezentrale Process Execution Services wahrscheinlich die bessere Lösung. Mit der Verwendung einer embedded Engine besteht zusätzlich die Möglichkeit, ein Stück selbstständig laufende Software bereitzustellen.
Voraussetzung dafür ist, dass sowohl die Modellierungswerkzeuge als auch die Process/Decision Engines die OMG-Standards BPMN und DMN spezifikationsgetreu umsetzen. Im Rahmen eines Innovation Day in der AXA (CH und D) waren wir in der Lage, aus einem Prozess mit Decision Tasks (Prozess modelliert mit Camunda, Decisions modelliert mit Innovator) einen lauffähigen Microservice (Process Engine von Camunda, Decision Engine von Drools) zu erstellen.

Fazit

DMN ist mehr als nur eine Notation für Geschäftsregeln. Es ist eine Notation für Geschäftslogik.
DMN ist ausführbar und bietet Business-Analysten die Möglichkeit, funktionale Anforderungen zu spezifizieren, zu prüfen und zu simulieren.
DMN ergänzt BPMN und ermöglicht es dem Business-Analysten so, deklarative Logik und Ablauflogik zu kombinieren.
BPMN um Variablen-Mapping und Expression Language erweitert, ermöglicht die Modellierung ausführbarer Prozesse.

Die Modellierung automatisiert ausführbarer Prozesse mit Decision Tasks

verringert den Aufwand zwischen Business und IT (siehe Abbildung 14),
gibt dem Business die Hoheit über die Geschäftslogik zurück und
entlastet die IT von der Verantwortung für codierte Geschäftslogik und -abläufe.