Mit DMN rechnen - ercas.software · Mit DMN rechnen - Der Nutzen von DMN für Berechnungsmodelle Seite 2 von 12 Decision Modell and Notation (DMN) 1 ist das Schwesternschiff von Business

Mit DMN rechnen

Der Nutzen von DMN für Berechnungsmodelle

Dr. Siegward Richthammer

mit freundlicher Unterstützung von

Mit DMN rechnen - Der Nutzen von DMN für Berechnungsmodelle Seite 1 von 12

Inhaltsverzeichnis

1. Das Praxisbeispiel ………………………………………………………………….. 2

2. Erforderliche Elemente aus DMN …………………………………………… …… 3

3. Decision Requirement Diagram (DRD) für die Preis berechnung …………... 3

4. Mehrfachinstanzen wirken sich auf das Modell aus ………………………….. 5

Lösungsansatz 1: Die Multi-Instance-Decision mit Si gnavio ……….. 6

Lösungsansatz 2: Nutzung des BPMN-Funktionsumfangs ………….. 7

5. Mit oder ohne Fehlerhinweise ………………………………………………… ….. 9

6. Test des Modells ………………………………………………………………….... 1 0

Fazit ………………………………………………………………………………………. 12


Decision Modell and Notation (DMN)1 ist das Schwesternschiff von Business Process Modell and Notation (BPMN)2. Beide standardisiert durch die Object Management Group (OMG) und beide für die Prozessmodellierung und -automatisierung unterwegs. Die volle Innovationskraft kann BPMN entfalten, wenn auch DMN eingesetzt wird. In diesem Sinne ist mit DMN auch zukünftig zu rechnen. Aber - mit DMN kann auch tatsächlich gerechnet werden. Das eröffnet uns Ansätze für weitere betriebliche Einsatzgebiete, die im Sinne eines Business-IT-Alignments wirken und schlanke Entwicklungsprozesse ermöglichen. Berechnungsmodelle kommen im betrieblichen Bereich vielfältig vor. Der Charme dabei ist, dass dies mit einem überschaubaren Umfang an Notationen und dazu mit dem gleichen Standard und dem gleichen Tool wie bei Entscheidungen geschieht. 1. Das Praxisbeispiel Wir wählen eine Preisberechnung für einen DSL-Anschluss, der verschiedene Bausteine mit jeweils eigenen Preisermittlungen zum Inhalt haben soll. Auch wenn es sich um ein Anschauungsbeispiel handelt, so wollen wir doch gerade im Hinblick auf die tägliche Praxis eine gewisse Komplexität behandeln. Das Modell ist jedoch leicht auf andere Branchen übertragbar. Wir gehen von drei Grundtarifen aus, die mit unterschiedlichen Bausteinen kombiniert werden können. Die Preisermittlung setzt sich aus insgesamt sechs Bestandteilen zusammen. Diese sind: 1 Grundtarif DSL 16 Mbit/s Grundtarif DSL 50 Mbit/s Grundtarif DSL 100 Mbit/s

2 - Zusatzbaustein Fernsehen wählbar

Zusatzbaustein Fernsehen wählbar

3 Virenschutz wählbar Virenschutz wählbar Virenschutz wählbar

4 - Mobiltarif 1 GB zusätzlich wählbar

Mobiltarif 3 GB zusätzlich wählbar

5 Gewährung von individuellen Zu- oder Abschlägen (z.B. nach Kundenwert, bei Schwerbehinderung). Es wird angenommen, dass diese als Liste mit 0 – n Listeinträgen vorliegt, die der Preisermittlung vorgegeben wird.

6 Versandkosten zum Festpreis

Abbildung 1: Produktbeschreibung für das Praxisbeispiel „Preisberechnung DSL Tarif mit Zusatzleistungen, bzw. Zusatzbausteinen“ Die Anforderung an uns ist, den Endpreis für den Kunden zu ermitteln, die Preise der einzelnen Bausteine auszuweisen und für die Buchhaltung den Betrag der Mehrwertsteuer 1 Einen guten Überblick zu DMN bietet Johannes Stöhr, Von der Identifikation bis zur ausführbaren Logik von operativen Entscheidungen, White-Paper von Signavio, 2015. 2 Vgl. Jakob Freund / Bernd Rücker, Praxishandbuch BPMN 2.0 (Hanser Verlag).


sowie den Nettobetrag zu errechnen. Unser Rechenbeispiel wird alle genannten Werte ermitteln und dem Aufrufer als Ergebnisse zurückgeben. 2. Erforderliche Elemente aus DMN Für die Berechnung müssen wir zuerst die Eingabedaten (Input Data) identifizieren. Diese sind diejenigen Parameter, die unser Berechnungsschema von außerhalb bekommt und die Einfluss auf das Ergebnis der Berechnung haben. Als zweites benötigen wir das Element „Decision“. Darin werden die Ergebnisse mittels Entscheidungstabellen oder Literal Expressions ermittelt. Die Regelwerke werden mittels der fachbereichstauglichen Friendly Enough Expression Language (FEEL) spezifiziert. Der Berechnungsweg setzt sich aus hierarchisch angeordneten Decisions zusammen, d.h. das Ergebnis / der Output einer Decision wird als Input für eine folgende Decision verwendet. Man spricht in diesem Sinne von „Subdecisions“. Die Kenntnis um den Aufbau einer Decision (Input Columns – Output Columns – Hit Policy – Completeness Indicator) und von FEEL setzen wir an dieser Stelle voraus. Drittens müssen wir die Input Data der Decision zuordnen, die diese Information benötigt. Der Konnektor wird als „Information Requirement“ bezeichnet. 3. Decision Requirement Diagram (DRD) für die Preisberechnung Das DRD für die Preisberechnung wird im Modellierungstool von Signavio in vier Schritten entwickelt (Abbildung 3). Dieses formale Muster kann auf Berechnungsschemata übertragen werden, die ohne Mehrfachinstanzen (siehe dazu Punkt 4) auskommen. Das DRD bildet ab, welche Informationen benötigt werden und wie diese transformiert werden müssen, damit ein regelkonformes Ergebnis (Entscheidung, Berechnung, etc.) erarbeitet werden kann. Gemäß dem Motto „Ein Bild sagt mehr als tausend Worte“ kann das DRD durchaus bereits in der Analysephase benutzt werden, in der die Fachlichkeit für die Umsetzung definiert wird. Wie baut sich das DRD für die Preisberechnung fachlich auf? Zuerst werden in Ebene 1 die Eingabedaten, die auf das Ergebnis unserer Berechnung einwirken können, dargestellt und beschrieben: Datentyp, Wertebereiche, Listeneigenschaft (Beispiel siehe Abbildung 2).

Abbildung 2: Beschreibung der Input-Daten am Beispiel der Bandbreite. Links die Input Data, rechts die Attribute.


Abbildung 3: DRD für das Praxisbeispiel „Preisberechnung DSL Tarif mit Zusatzleistungen, -bausteinen“ In Ebene 2 werden die Preise für die einzelnen Leistungen errechnet. Diese brauchen wir, um die Anforderung zu erfüllen, die Leistungen jeweils betragsmäßig zu dokumentieren. Die Berechnungen erfolgen über Entscheidungstabellen, in denen die Eingabedaten ausgewertet werden (siehe Abbildung 4).

Abbildung 4: Preisermittlung für die Decision „Kosten Grundtarif“ (siehe Abbildung 3) gemäß der Bandbreite Es kann auch eine Literal Expression zum Einsatz kommen, wie im Falle der Decision für die Versandkostenpauschale (siehe Abbildung 5).

Abbildung 5: Beispiel einer Literal Expression für die Decision „Versandkostenpauschale“ (siehe Abbildung 3) Sie basiert auf keinem Eingabewert und wird vom Berechnungsschema selbst erzeugt. Sie ist in unserem Fall vollständig dort gekapselt abgelegt (sie könnte auch als wiederverwendbare Decision spezifiziert werden) und ist Eingabewert für die abschließende Decision „Ergebnis“.


Die Ebene 3 fasst die Kosten für die einzelnen Leistungen zusammen und berechnet Positionen auf dieser Aggregationsstufe. In unserem Falle zuerst die individuellen Vereinbarungen, die als Zu- oder Abschläge in die Berechnung einfließen. Natürlich könnte die Berechnung auch an anderer Stelle erfolgen, aber das ist Fachlichkeit, die uns an dieser Stelle nicht weiter beschäftigen soll. Abschließend wird noch die Mehrwertsteuer berechnet. Mit den bisherigen Verarbeitungen sind alle erforderlichen Werte berechnet. In Ebene 4 werden die Werte aller Ebenen aggregiert und an die rufende Stelle zurückgegeben. Wir können die Aggregation als Liste in vertikaler (siehe Abbildung 5) oder horizontaler (siehe Abbildung 6) Form ausgeben. Beachten müssen wir jedoch, dass je nach der gewählten Form die Hit Policy der Entscheidungstabelle eine andere ist. Denn die Ausgabeform „Liste“ muss über die Hit Policy definiert werden.

Abbildung 5: Beispiel für die Listenausgabe der Ergebniswerte in vertikaler Form mit der Hit Policy „C“ (=“collect“). Die Ausgabe wird bei dieser Variante in einer Liste gesammelt.

Abbildung 6: Beispiel für die Ausgabe der Ergebniswerte in horizontaler Form (Einzelspalten) mit der Hit Policy „U“ (= „unique“). Aufgrund der Ausgabebreite ist der Output in der Darstellung abgeschnitten. Ganz gleich sind – abgesehen vom Ausgabeformat - die beiden Varianten aber nicht. Bei einer horizontalen Ausgabe können unterschiedliche Datentypen ausgegeben werden. Bei der vertikalen Form der Ausgabedaten in einer Spalte dagegen nur ein Datentyp. 4. Mehrfachinstanzen wirken sich auf das Modell aus Rechenmodelle können beinhalten, dass bestimmte Rechenschritte mehrfach erforderlich sind, weil die Vertragskomponenten mehrfach eingeschlossen werden können. In unserem Praxisbeispiel kann ein Mobiltarif mehrfach gewollt sein, da ein Kunde mehrere mobile Endgeräte hat, für die er jeweils eine SIM-Karte benötigt. Diese könnten zudem inhaltlich voneinander abweichen (z.B. eine SIM-Karte mit 1 GB Volumen, die andere mit 3 GB Volumen). Die Produktkonstruktion mit Mehrfachinstanzen lässt es zu, dass jeweils unter-schiedliche monatliche Volumen je SIM-Karte mit unterschiedlichen Preisen gewählt werden können. Die Mehrfachinstanz könnte auch bei Gruppenverträgen zur Anwendung kommen.


Die Unterscheidung der einzelnen Instanzen mittels einer Produktvariante ist folglich die Voraussetzung für eine Mehrfachinstanz. Wäre sie nicht gegeben, dann läge eine einfache Wiederholgruppe von inhaltlich gleichen Elementen vor. Es würde dann die Anzahl der gleichartigen Komponenten als zusätzlicher Input-Parameter genügen, mit der das Ergebnis aus der Decision „Kosten Mobiltarif“ multipliziert wird. Diesen Fall deckt das DMN-Modell unter Punkt 3 (siehe Abbildung 3) ab. Interessant ist diese Konstellation deshalb, weil DMN dafür (noch) keine standardisierte Lösung anbietet. Es gibt jedoch Lösungsmöglichkeiten. Lösungsansatz 1: Die Multi-Instance-Decision mit Si gnavio

Abbildung 7: DRD für das Berechnungsschema mit Mehrfachinstanz mit der Multi Instance Decision (Signavio) Toolhersteller können den Standard der OMG erweitern und im Modellierungstool einen


Funktionsumfang anbieten, mit dem sich die Mehrfachinstanz darstellen lässt. Das Tool von Signavio enthält hierzu das Element „Multi Instance Decision“. Dieses Element hat als Input eine Liste. Diese Liste - einfach oder komplex - kann als Input Data vorgegeben werden oder als Output aus einer vorherigen Subdecision stammen. Die Multi Instance Decision arbeitet im Sinne einer Scheifenfunktion, die für jedes Element der Liste durchlaufen wird. Dabei wird für jedes Element der Liste die Decision ausgeführt. Die einzelnen Ergebnisse können nach verschiedenen Wünschen aggregiert werden (z.B. als Ausgabeliste, als Summe, Abfrage auf boolsche Werte). Damit bildet dieses Element genau die Konstruktion ab, die wir für unsere Mehrfachinstanz gesucht haben. Die Änderungen gegenüber dem DRD unter Punkt 3 (siehe Abbildung 3) sind mit Rot gekennzeichnet (siehe Abbildung 7). Dies ist eine elegante Lösung, da sie uns ermöglicht, mit „DMN“ in „gewohnter Weise“ zu modellieren und einen Beitrag zum „Business-IT-Alignment“ zu leisten. Jedoch ist der Preis, dass wir uns vom Tooling abhängig machen und über den Standard der OMG in der Modellierung hinausgehen. Das Modell selbst kann aus Signavio heraus im Format für Drools (siehe http://www.drools.org) exportiert werden. Lösungsansatz 2: Nutzung des BPMN-Funktionsumfangs Aufgrund der engen Verbindung von BPMN und DMN können wir auf die BPMN-Funktionalität zurückgreifen. Für denjenigen, dem das Verbleiben im Standard wichtig ist, bietet sich hier eine flexible Alternative. Der „Business-Rules-Task“ erlaubt, das BPMN-Modell direkt mit dem DMN-Modell zu verlinken (siehe Abbildung 8). BPMN bringt die Mehrfachinstanz im Standard bereits mit. Zur Ausführung wird dann eine Process-Engine benötigt, die im Optimalfall die beiden Standards BPMN und DMN unterstützt.

Abbildung 8: BPMN-Modell für die Steuerung der Preisberechnung. Zur zusätzlichen Verdeutlichung wurden die BPMN-Datenobjekte verwendet. Die Task „Mobiltarif berechnen“ ist als parallele Mehrfachinstanz modelliert und ruft für jede gewünschte SIM-Karte (= Mobiltarif) das DMN-Modell zur Berechnung der Kosten auf. Das Modell gibt jeweils den Preis für einen Mobiltarif zurück.

Abbildung 9: DMN-Modell für die Berechnung des Einzelpreises eines Mobiltarifs. Der Aufruf erfolgt aus der Task „Mobiltarif berechnen“ aus Abbildung 8.


Die einzelnen Ergebnisse werden im Prozess gesammelt und gemeinsam mit den weiteren Input-Data in der Task „Preis berechnen“ an das DMN-Berechnungsschema gegeben. Das Berechnungsschema selbst entspricht weitgehend in diesem Fall der Abbildung 7. Ausnahme ist eben die Berechnung des Mobiltarifs, die in der Business-Rules-Task „Mobiltarif berechnen“ (BPMN) bereits ausgeführt (DMN) wurde. Statt der Liste der gewählten Datenvolumen (wie in Abbildung 7) wird folglich die Task „Mobiltarif berechnen“ erzeugte Liste mit Einzelnettopreisen übergeben und im DMN-Modell die Summe aus den Einzelpreisen gebildet. Änderungen gegenüber Abbildung 7 sind rot gekennzeichnet.

Abbildung 10: DRD für das Berechnungsschema mit Einbettung in einem BPMN-Workflow. Für die Summierung der Einzelnettopreise genügt eine Literal Expression (siehe Abbildung 11).

Abbildung 11: Summierung der Einzelpreise der verschiedenen Mobiltarife mittels einer Literal Expression in der Decision „Summe Kosten Mobiltarif“.


Mit oder ohne Fehlerhinweise Die bisher dargestellten Modelle der Preisberechnung haben die Funktion „Rechnen“ abgebildet. Die fachliche Richtigkeit der Input-Daten wurde dabei vorausgesetzt. Wir können die Anforderung an das Modell erhöhen, indem wir zusätzlich fordern, dass bei fehlerhaften Input-Daten das Modell dies erkennen und im Output zusätzlich protokollieren soll. Dies hat den Vorteil, dass eine Fehlersuche bei unerwarteten Ergebnissen durch den Hinweis aus dem Modell selbst erleichtert wird. Natürlich könnte der Hinweistext von der rufenden Anwendung verwendet werden, um beispielsweise den Anwender auf eine Fehleingabe hinzuweisen. Ob dies im Einzelfall erforderlich ist, hängt von der Anwendungsarchitektur ab. Liegt eine Schicht für die Plausibilitäten und Prüfung von Eingabewerten architektonisch vor der Berechnung, dann muss dies im Berechnungsmodell nicht wiederholt werden. Das Berechnungsmodell würde nur ausgeführt werden, wenn die vorherigen Schichten erfolgreich durchlaufen wurden. Natürlich wäre die vorgelagerte Prüfungsschicht eine hervorragende Einsatzmöglichkeit für DMN. Wollen wir die Plausibilität dennoch prüfen und erkannte Fehler dokumentieren, dann müssen wir bedenken, dass wir das DRD während seiner Ausführung nicht abbrechen können, wenn wir Fehler erkannt haben. Das wäre nur mit einer BPMN-Steuerung analog der Mehrfachinstanz möglich (durch angeheftete Abbruchereignisse oder Gateways). Damit hätten wir uns aber auch für die Prüfung in einer vorgelagerten Schicht entschieden. Bei einer Integration der Plausibilitätsprüfungen können wir das Modell selbst (siehe Abbildung 3, 7 oder 10) unverändert als Grundlage nehmen. Anpassungen sind erforderlich in den Decisions der Ebene 2 „Berechnung der Einzelpositionen“ sowie der Ebene 4 „Aufbereitung und Zusammenfassung der einzelnen Ergebniswerte“. In Ebene 2 müssen wir dafür sorgen, dass Hinweise erzeugt werden und in Ebene 4 werden diese Hinweise in den Output unseres Berechnungsmodells eingebunden. Die Decision „Kosten Fernsehen“ der Ebene 2 wird exemplarisch dargestellt. Hier haben wir eine echte Plausibilität zu berücksichtigen. Die Leistung „Fernsehen“ kann nur gewählt werden, wenn sich der Kunde gleichzeitig für DSL 50 oder DSL 100 entscheidet. Benötigt wird eine neue Ergebnisspalte für die Ausgabe eines Hinweistextes.

Abbildung 12: Entscheidungstabelle für die Decision „Kosten Grundbeitrag“. In der Spalte „Hinweis“ (siehe rosa markierte Spalte) werden mögliche Regelverstöße ausgegeben, die in folgenden Decisions verwendet werden können. In der Spalte „Kosten netto“ setzen wir den Wert auf 0, damit nachfolgende Decisions korrekt ablaufen. Danach folgt die Aufnahme dieses Hinweistextes in diejenige Decision, die abschließend den


gesamten Output sammelt. Dies ist die Decision „Ergebnisse“ in der Ebene 4. Dort fügen wir ebenfalls eine neue Ergebnisspalte für den Hinweistext ein und referenzieren auf die Ausgabespalte „Hinweis“ der Decision „Kosten Fernsehen“ (siehe Abbildung 13).

Abbildung 13: Entscheidungstabelle für die Decision „Ergebnisse“. In der Spalte „Hinweis“ (siehe rosa markierte Spalte) werden die jeweiligen Hinweise aus den einzelnen Decisions zur Berechnung der Einzelpositionen gesammelt ausgegeben. Test des Modells Bislang haben wir DMN-Definitionen erstellt ohne zu wissen, ob die hinterlegten Strukturen logisch korrekt sind oder die Berechnungsmethode korrekt abbilden. Es fehlt also ein Testverfahren, mit dem möglichst frühzeitig in der Fachentwicklung das erreichte Ergebnis geprüft werden kann. Mit guten Modellierungstools lässt sich die Funktionsweise ohne weitere Transformation interaktiv testen. Der Fachentwickler kann die einzelnen Rechenschritte grafisch und mit dem jeweiligen Ergebnis nachvollziehen. Abbildung 14 zeigt den entsprechenden Ausschnitt aus dem Tool von Signavio (Simulation DMN-Modelle). Auf der linken Seite stehen die Input-Daten (grün umrandet), mit denen der Tester seine Testfälle eingeben kann. Auf der rechten Seite finden sich die Ergebnisse unseres Berechnungsmodells (blau umrandet). Die Hinweistexte aufgrund der fehlerhaften Eingabe der Bandbreite (s. Abbildung 13) werden vom Berechnungsmodell ausgegeben (rot umrandet). Im vorliegenden Testfall wurde DSL 16 Mbit/s gewählt und gleichzeitig die Leistung „Fernsehen“ angefordert. Da dies gemäß der festgelegten Produktdefinition (siehe Abbildung 1) nicht möglich ist, wird ein entsprechender Hinweistext ausgegeben, auf den der Aufrufende reagieren kann. Die Simulation erlaubt ein gezieltes Testen jeder einzelnen Decision. Der Fachmodellierer hat somit jederzeit die Möglichkeit, jede Decision auf deren fachliche Richtigkeit zu testen. Neben der Anzeige der Ergebnisse erlauben gute Tools auch den Blick in die jeweiligen Decision selbst, um nachvollziehen zu können, welche Zeile(n) ausgewählt wurden (siehe Abbildung 15).


Abbildung 14: Ausschnitt aus dem Simulationstool von Signavio. Die Simulation zeigt Input (grün umrandet) und Output (blau umrandet) aus der Decison „Ergebnisse“ von Abbildung 13 (siehe Ebene 4 in den DMN-Modellen). Rot umrandet werden die Kosten für Fernsehen dargestellt. Der Fehler wird in der Spalte „Hinweis“ dokumentiert.

Abbildung 15: Protokollierung der einzelnen Decisions und ihrer Ergebnisse. Die im Testfall ausgewählte Zeile wird grün markiert. Die bisher dargestellte Simulation bezieht sich auf Einzelfälle, die manuell eingegeben werden. Es gibt auch die Möglichkeit der Verarbeitung von Testfällen im Stapel, des Exportierens und Importierens von ganzen Testfallchargen (siehe dazu das Testlabor im Tool von Signavio).


Fazit Der Begriff „Business-IT-Alignment“ steht für das Maß der Ausrichtung der IT an den Geschäftszielen, Strukturen und Prozessen. Eine besondere Nähe zwischen IT und Geschäftsprozessen ist dann erreicht, wenn die fachlichen Beschreibungen selbst automatisiert ausgeführt werden. Die Modelle können in einer von Fachbereich und IT gemeinsam „gesprochenen“ Spezifizierungssprache von Nicht-Technikern erstellt und schon während der Erstellung getestet werden. Das Ergebnis ist – vereinfacht ausgedrückt - wie Quellcode automatisiert ausführbar. Das ist mit BPMN und DMN gegeben. Damit unterstützen diese Standards schlanke und wertschöpfende Prozesse in Fachbereich und IT während des gesamten Entwicklungsprozesses. Für die Umsetzung von Berechnungsschemata verschiedener Ausgestaltung haben wir es in diesem Beitrag aufgezeigt. Ein weiterer interessanter Ansatz wurde gestreift: BPMN kann zur Steuerung beliebiger Workflows genutzt werden (siehe die BPMN-Steuerungsschicht in Abbildung 9). BPMN kann also mehr orchestrieren als die Prozessbeteiligten an Geschäftsprozessen in Form von IT-Systemen und Menschen. Es können – allgemein gesprochen - Workflows innerhalb von Anwendungssystemen konzipiert werden. BPMN und DMN samt zugehöriger Engine bringen viel mit, wovon sich in der Softwareentwicklung profitieren ließe. Dieser Beitrag möchte anregen, weitere Einsatzfelder für die Standards BPMN und DMN zu erschließen und so das Business-IT-Alignment fördern.

Documents

Mit DMN rechnen - ercas.software · Mit DMN rechnen - Der Nutzen von DMN für Berechnungsmodelle Seite 2 von 12 Decision Modell and Notation (DMN) 1 ist das Schwesternschiff von Business