Präsentiert von: in Kooperation mit: iSAQB®

Veranstalter:

Trainings für Softwarearchitekten mit iSAQB-Zertifizierung

iSAQB®Jetzt Teilnahme sichern!

www.software-architecture-camp.de

Das Camp bietet Ihnen eine fundierte und pragmatische Einführung in Software- architektur mit hohem Übungsanteil. Mit Zertifizierung zum „Certified Professional for Software Architecture – Foundation Level (CPSA-F)“.

Stefan Zörner

Till Schulte-Coerne

Stefan Toth

Phillip Ghadir

Dr. Jörg Preußig

Dr. Gernot Starke

Stefan Tilkov

Die verschiedenen Module des Advanced Levels vertiefen Ihre Kenntnisse und Fähigkeiten in den Bereichen Technik, Methodik und Kommunikation. Mit Zertifizierung zum „Certified Professional for Software Architecture – Advanced Level (CPSA-A)“.

Stefan Tilkov

Oliver Wolf

Matthias Bohlen

Kim Nena Duggen

www.bt-magazin.de 2.2015 Heft 21 € 4,90

heuteGeschäftsprozesse

Decision Modeling:

Strukturiert entscheiden

Transformation Triangle:

IT und Business digitalisieren

BPM und Microservices:

Kleine Ordnung im Großen

©S

&S M

edia

©

iSto

ckph

oto.

com

/Pho

to-D

ave

www.bt-magazin.de48 bt | 2.2015

Decision Model and Notation

Entscheidungen mit der DMN analysieren und modellieren

Was gibt es da zu entscheiden? In unserem Arbeitsleben spielt das Treffen von Entscheidungen eine wichtige Rol-

le, doch vielen fällt genau das schwer. Hierbei kann der neue Standard der Object

Management Group (OMG) zum Thema Entscheidung, die Decision Model and

Notation (DMN), weiterhelfen. Denn die DMN ermöglicht es uns, Entscheidungen

strukturiert zu beschreiben und dadurch besser zu verstehen. Und auch bei der Au-

tomatisierung kann sie hilfreich sein.

AUTOR: DR. MARcUS WINTEROll

Um es gleich vorwegzunehmen: Die DMN ist kein Werkzeug, um etwas zu entscheiden. Es geht viel-mehr darum, Entscheidungen besser zu verstehen, die wiederholt anfallen. Die Gründe dafür, über Ent-scheidungen zu sprechen, sind die Gleichen, die uns

dazu bewegen, beispielsweise Geschäftsprozesse zu beschreiben. Das heißt, wir wollen Entscheidungen verstehen, analysieren und verbessern, um eine gleich-bleibende Qualität der einzelnen Entscheidungen zu gewährleisten.

Was bietet die DMN hierfür an? Welche Strukturen gibt sie für Entscheidungen vor? Aus der Sicht des neuen

49bt | 2.2015www.bt-magazin.de

OMG-Standards sind Beschreibungen von Entscheidun-gen folgendermaßen strukturiert:

•Der Kontext: Wie bettet sie sich in den Geschäftspro-zess ein?

•Die Anforderungen: Welche Informationen werden benötigt? Welche Entscheidungen müssen zuvor ge-troffen werden? Welche Vorgaben sind dabei einzu-halten?

•Die Entscheidungslogik: Welches Verfahren soll an-gewendet werden, um zu einer Entscheidung zu kom-men? Etwa die Anwendung von Regeln [1, S. 19]?

Die DMN selbst bietet nur Notationen für die letzten beiden Aspekte an. Bezüglich der Einbettung in die Ge-schäftsprozesse wird auf die BPMN verwiesen, wobei Business-Rule-Tasks als Brückenkopf zwischen der BPMN-Ablaufbeschreibung und dem DMN-Entschei-dungsmodell auserkoren wurden (Abb. 1).

DEcisioN REquiREMENtsBetrachten wir also, was der neue Standard für die Be-schreibung der Anforderungsperspektive bereithält. Zählen wir die Grundelemente für diese Perspektive zusammen, ergibt sich ein überschaubares Bild: Es gibt lediglich vier Grundelemente und drei Arten von Bezie-hungen zwischen ihnen.

Werfen wir zunächst einen Blick auf die vier Grund-elemente (Abb.  2). Das zentrale Element ist die Ent-scheidung selbst. Mit Entscheidung ist hier der Akt der Entscheidung gemeint, nicht das Ergebnis. Natürlich hält

die Spezifikation auch eine Reihe von Attributen bereit, um eine Entscheidung genauer zu charakterisieren. Im Folgenden die wichtigsten:

•Die Frage: Was soll durch die Entscheidung beantwor-tet werden?

•Erlaubte Antworten: Wie sehen mögliche Antworten aus? Hier sind die möglichen Antworten aufzuzählen bzw. eine repräsentative Auswahl.

•Die Entscheidungslogik: Wie sieht der Weg zur Ent-scheidung aus? Das kann beispielsweise eine Entschei-dungstabelle sein, der Aufruf einer Funktion oder andere, wie auch immer geartete Beschreibungen des Entscheidungsverfahrens.

Hiermit ist der Akt der Entscheidung schon ganz gut cha-rakterisiert, der nun an einem Beispiel illustriert werden soll: Dem Auswahlprozess für Bewerber, wie er in Ab-bildung 3 beschrieben ist. Der Ablauf wurde für unsere Zwecke vereinfacht; Varianten und fachliche Fehler brau-chen wir zur Illustration der Entscheidungen nicht. Auch die Herausforderungen im Ablauf, die beispielsweise dadurch entstehen, dass noch interessante Bewerbungen eintrudeln, während schon die ersten Gespräche geführt werden, müssen uns hier nicht interessieren.

Hinter jeder Business-Rule-Task des betrachteten Prozesses steht eine Entscheidung. Diese sehen wir in Abbildung 4 als Decision Requirement Diagram (DRD) dargestellt. Dort sehen wir neben den Entscheidungen noch weitere Elemente, die für die Entscheidung eine Rolle spielen. Schauen wir uns zunächst die Entschei-

©iS

tock

phot

o.co

m/P

hoto

-Dav

e

www.bt-magazin.de50 bt | 2.2015

dung „Über Angebot entscheiden“ genauer an. Im Prozess wird die Entscheidung durch die gleichnamige Business-Rule-Task repräsentiert.

Die Entscheidung kann durch die Frage „Soll ein An-gebot an den Bewerber gehen und mit welchem Gehalt?“ charakterisiert werden; mögliche Antworten könnten die Form „Ja mit folgendem Gehalt …“ haben oder schlicht „Nein“ lauten. Auf die zugehörige Entscheidungslogik werden wir später eingehen.

Weitere wichtige Informationen über die Entschei-dung lassen sich dem Diagramm entnehmen: die Bewer-bung, die Gehaltsklassen und der persönliche Eindruck stellen direkte oder indirekte Eingabedaten für die Ent-

scheidung dar. Sie werden mit dem DMN-Element Ein-gabedaten (Input Data) dargestellt und mittels der so genannten Informationsanforderung (Information Re-quirement) mit der Entscheidung verbunden.

Mit Informationsanforderungen können Entschei-dungen nicht nur Eingabedaten zugeordnet werden, sondern auch andere Entscheidungen, deren Ergebnisse in gewisser Weise auch als Eingabedaten dienen. So setzt „Über Angebot entscheiden“ voraus, dass zuvor die fach-liche Eignung des Bewerbers und der Gesamteindruck beurteilt wurde.

Weitere Elemente, die mit der Angebotsentschei-dung zusammenhängen, sind zum einen das so genannte Geschäftswissensmodell (Business Knowledge Model), zum anderen die Wissensquelle (Knowledge Source). Das Geschäftswissensmodell „Entscheidung über An-gebot“ repräsentiert die Entscheidungslogik, die später noch genauer betrachtet wird. Der gestrichelte Pfeil, mit dem das Element an die Entscheidung geheftet wird, steht für eine Wissensanforderung (Knowledge Re quire-ment).

Mit Wissensquellen können im DRD Vorgaben ins Modell aufgenommen werden; in unserem Beispiel

Abb. 1: Die verschiedenen Aspekte einer Entscheidung und deren Zusammenhang

Abb. 2: Die Elemente des Decision Requirements Diagram (DRD)

51bt | 2.2015www.bt-magazin.de

über die Form des Angebots und die Zeit, die für die Entscheidung zur Verfügung steht. Solche Vorgaben können beispielsweise firmenintern sein, etwa gesetzli-che Vorschriften oder allgemeine Standards, die es ein-zuhalten gilt. Die Zuordnung einer Wissensquelle zu einer Entscheidung oder einem Geschäftswissensmo-dell wird mit einer Vorgabe (Authority Requirement) modelliert.

In einem DRD haben Vorgaben eher informativen Charakter  – während die Eingabedaten und die Ent-scheidungslogik bei jeder einzelnen Entscheidung benö-tigt werden, beschreiben die Vorgaben, welche Regeln in der Entscheidung oder der zugehörigen Entscheidungs-logik einzuhalten sind. Würde diese Angabe fehlen, könnten wir aus dem Diagramm immer noch heraus-lesen, was für die Entscheidungen benötigt wird. Uns

würde allerdings die Information fehlen, warum der Akt der Entscheidung so aussieht, wie er aussieht.

Das DRD ist ein Instrument, mit dem sich die Anfor-derungen an Entscheidungen analysieren lassen. Es hilft, zu verstehen, welche Eingabedaten eine Entscheidung braucht, welche weiteren Entscheidungen benötigt wer-den und welche Vorgaben zu beachten sind.

DER ZusaMMENhaNg ZwischEN DMN uND BPMNEine solche Analyse kann beispielsweise hilfreich sein, um die Geschäftsprozesse besser zu verstehen, in die die Entscheidungen eingebettet sind. Wenn wir das DRD aus Abbildung  4 mit der zugehörigen Geschäftsprozessbe-schreibung in Abbildung 3 vergleichen, finden wir nicht nur die Entscheidungen als Business-Rule-Task in der Pro-

Abb. 3: Ein einfaches Einstellungsverfahren als Beispielprozess

Abb. 4: Entscheidung samt zugehöriger Anforderungen im Decision Requirements Diagram

www.bt-magazin.de52 bt | 2.2015

zessbeschreibung wieder, sondern auch die Eingabedaten „Bewerbung“, „Bedarf“, „Persönlicher Eindruck“ und „Gehaltsklassen“ als Datenobjekte. Wenn wir also die Eingabedaten der Entscheidungen bestimmen, bestimmen wir damit auch Datenobjekte des Geschäftsprozesses. Und anders herum: In der BPMN-Beschreibung können wir er-kennen, woher die benötigten Daten kommen.

Ein weiterer wichtiger Aspekt des Zusammenspiels zwischen der Entscheidungs- und Ablaufmodellierung: Eine saubere Trennung der beiden Modellierungen macht das Geschäftsprozessmodell verständlicher und einfacher zu pflegen. Häufig wird beides vermischt, was zu einer Kaskade von Verzweigungen in der Prozessmodellierung führt. Bei einer sauberen Trennung zwischen Ablauf und Entscheidung modellieren wir die Entscheidung  – wie schon gezeigt  – mit einer Business-Rule-Task, häufig gefolgt von einem Gateway, sodass abhängig von der Entscheidung der weitere Ablauf bestimmt wird. Die ei-gentliche Entscheidung lässt sich dann mithilfe der DMN beschreiben. Und zwar nicht nur die Anforderung an eine Entscheidung, sondern auch die Entscheidungslogik selbst, z. B. in Form von Geschäftsregeln. Bei Änderun-

gen in der Entscheidungslogik müssen wir auch nur diese ändern, während die BPMN-Prozessbeschreibung davon unberührt bleibt.

BEschREiBuNg DER ENtschEiDuNgslogikWir haben gesehen, wie mittels eines DRD die Anforde-rungen an eine Entscheidung analysiert werden können. Wir haben auch gesehen, dass zu jeder Entscheidung eine Frage und mögliche Antworten gehören. Was aber noch unklar ist: Wie kommen wir von der Frage zu den Ant-worten? Diesen Weg weist uns die Entscheidungslogik, die sich in der DMN unterhalb des DRD abspielt (Abb. 1). Grundsätzlich sieht die DMN drei Varianten zur Beschrei-bung der Entscheidungslogik vor:

•per Entscheidungstabelle•durch den Aufruf eines Geschäftswissensmodells•durch einen geeigneten Ausdruck in einer beliebigen

Sprache

Die letztgenannte Variante eröffnet alle Möglichkeiten, die Entscheidungslogik zu beschreiben; angefangen bei natürlicher Sprache, über Ausdrücke eines logischen Kal-küls bis hin zu direkt ausführbaren Programmiersprachen wie Java. Allerdings bewegt man sich dann außerhalb der DMN. Mit den Entscheidungs tabellen bringt sie aber ein mächtiges Instrument mit, das viele Fälle abdeckt.

In unserem Beispiel könnte eine Entscheidungstabel-le für die Entscheidung über das Angebot aussehen wie Tabelle 1. Die Spalten „Gehaltsforderung“, „Fachliche Eignung“ und „Gesamteindruck“ stehen für mögliche

uc gehaltsforderung Fachliche Eignung gesamteindruck angebot

sehr gut, gut, mittel, schlecht sehr gut, gut, mittel, schlecht Boolean

1 > Gehaltsklassen.obere Gehaltsklasse - - false

2 > Gehaltsklassen.mittlere Gehaltsklasse sehr gut, gut sehr gut, gut true

3 > Gehaltsklassen.mittlere Gehaltsklasse mittel sehr gut true

4 > Gehaltsklassen.mittlere Gehaltsklasse mittel gut false

5 > Gehaltsklassen.mittlere Gehaltsklasse - mittel, schlecht false

6 > Gehaltsklassen.mittlere Gehaltsklasse schlecht - false

7 > Gehaltsklassen.untere Gehaltsklasse sehr gut, gut, mittel sehr gut, gut true

8 > Gehaltsklassen.untere Gehaltsklasse sehr gut, gut mittel true

9 > Gehaltsklassen.untere Gehaltsklasse mittel mittel false

10 > Gehaltsklassen.untere Gehaltsklasse schlecht - false

11 > Gehaltsklassen.untere Gehaltsklasse - schlecht false

12 < Gehaltsklassen.mittlere Gehaltsklasse sehr gut, gut, mittel sehr gut, gut, mittel true

13 < Gehaltsklassen.mittlere Gehaltsklasse schlecht - false

14 < Gehaltsklassen.mittlere Gehaltsklasse - schlecht false

Tabelle 1: Entscheidung über Angebot

Abb. 5: Entscheidungslogik als Boxed Expression

www.bt-magazin.de

Eingabedaten, die Spalte „Angebot“ steht für den zugehörigen Ausgabewert. Die entsprechenden Überschriften sind also die Namen der Ein- bzw. Aus-gabeparameter. In den Zeilen unter den Überschriften können die mögli-chen Ein- bzw. Ausgabewerte oder der Datentyp angegeben werden. Jede der nummerierten Zeilen bildet eine Regel. Die Entscheidungstabelle verbindet also alle Regeln, die zu einer Entscheidung gehören.

Zu der Entscheidung über das Angebot muss aber nicht allein die Frage beantwortet werden, ob überhaupt ein Angebot an den Bewerber geht, son-dern es – das geht aus den genannten möglichen Antworten hervor – muss auch die Höhe des angebotenen Gehalts ermittelt werden. Für diese beiden Teilfragen werden zwei unterschiedliche Entscheidungslogiken verwendet. Im DRD wird dies durch die beiden Geschäftswissensmodelle sichtbar, die der Entscheidung mittels Wissensanforderung zugeordnet sind.

Das heißt, die Entscheidungstabelle (Tabelle 1) ist der Entscheidung nur mittelbar über das entsprechende Geschäftswissensmodell zugeordnet. Für die Gehaltsbestimmung verwendet die Entscheidung das „Gehaltsmodell“. Damit haben wir ein Beispiel für den Aufruf von Geschäftslogik.

Jetzt müssen wir das alles noch zusammenfügen. Hierfür dienen in der DMN so genannte Boxed Expressions. Das heißt, dass sämtliche Ausdrücke in Kästchen erscheinen. Ein Beispiel hierfür haben wir bereits kennengelernt, denn auch die Entscheidungstabellen sind eine Form von Boxed Expressions. Um nun die verschiedenen Geschäftswissensmodelle in der Entscheidung zu verwenden, formulieren wir eine Boxed Expression wie in Abbildung 5. In der ersten Zeile steht dort der Name der beschriebenen Entscheidung. Darunter fin-den wir links die Ausdrücke „Angebot“ sowie „Gehalt“ und rechts davon die Berechnung dieser Ausdrücke durch den Aufruf der Geschäftswissensmodelle „Entscheidung über Angebot“ bzw. „Gehaltsmodell“.

Die Aufrufe selbst sind auch eine Form von Boxed Expressions und daher nochmals geschachtelt. Der Aufruf der Entscheidungstabelle „Entscheidung über Angebot“ geschieht mittels der Parameter „Gehaltsforderung“, „Fachli-che Eignung“ und „Gesamteindruck“, rechts davon steht jeweils die Bindung der Parameter für den Aufruf, die hier zum einen durch das Eingabedatum „Be-werbung“ erfolgt, zum anderen durch weitere Entscheidungen sowie auch aus dem DRD hervorgeht. Schließlich wird in der untersten Zeile der Rückgabe-wert aus „Angebot“ und „Gehalt“ bestimmt.

Für die Ausdrücke in den Boxed Expressions definiert die DMN eine eigene Sprache, die Friendly Enough Expression Language (FEEL). Damit können ein-fache und komplexe Ausdrücke formal und damit maschinenlesbar formuliert werden.

Grundsätzlich können in den Boxed Expressions aber auch Ausdrücke in beliebiger Sprache stehen. Ein einfaches Beispiel sehen wir in Abbildung 6. Dort wird in natürliche Sprache (und mit etwas Interpretationsspielraum) beschrieben, wie das Gehalt zu berechnen ist. Die dafür notwendigen Größen „Gehaltsforderung“ und „Berufserfahrung“ werden in der zweiten Zeile als Parameter definiert. Zudem wird die finanzielle Lage eingeschätzt, hierfür wird das entsprechende Geschäftswissensmodell genutzt. Die letzte Zeile be-sagt, dass „Gehalt“ schließlich als Ergebnis zurückgegeben wird.

Die Verwendung von Geschäftswissensmodellen ist nicht zwingend, denn die Entscheidungslogik kann auch direkt mit der Entscheidung verknüpft wer-den. Durch die Verwendung der Geschäftswissensmodelle wird in unserem Bei-spiel allerdings schon im DRD deutlich, dass die Entscheidung über das Angebot auch das Gehaltsmodell benötigt, weil dieses als Element im DRD auftaucht.

Anzeige

www.bt-magazin.de54 bt | 2.2015

Dies wäre bei der direkten Verknüpfung nicht der Fall. Ein anderer Grund für die Verwendung von Geschäftswis-sensmodellen ist die Wiederverwendung: Greifen mehrere Entscheidungen auf dieselbe Entscheidungslogik zurück, muss diese nur einmal definiert werden. Im Beispiel in Abbildung 4 gilt das für „Einschätzung der finanziellen Lage“.

Die Beispiele zeigen nur einige der Möglichkeiten, die Entscheidungslogik mit den Mitteln der DMN zu beschrei-ben. Es handelt sich hierbei um ein mächtiges Werkzeug. Vor allem die Boxed Expressions ermöglichen es, die Ent-scheidungslogik beliebig in immer kleinere Bestandteile zu zerlegen. Dafür zahlt man aber auch einen Preis: Anders als die DRD sind die Boxed Expressions sehr viel schwerer zu erlernen. Und der Anspruch der DMN, nicht nur für Analytiker und Entwickler verständlich zu sein, sondern auch für Fachleute [1, S. 13] wird dadurch unterhöhlt. Letztlich verhält es sich hier wie mit anderen formalen Sprachen wie z. B. der UML oder auch der BPMN: Ver-wendet man nur wenige unterschiedliche Elemente, kann man einfache Beschreibungen entwickeln, die zumindest von gutwilligen Fachleuten verstanden werden können. Das gilt mit Sicherheit für die DRD und zumindest auch für einfache Entscheidungstabellen. Doch je mehr Regis-ter wir ziehen, um an Ausdrucksmächtigkeit zu gewinnen, desto eher bleibt die Verständlichkeit auf der Strecke.

VERwENDuNgsMöglichkEitENAbschließend wollen wir noch einen kurzen Blick auf die Einsatzmöglichkeiten der DMN werfen. Drei Möglichkei-ten liegen auf der Hand: Analyse, Automatisierung und Compliance.

Wer beginnt, Entscheidungen mithilfe von DRD zu analysieren, wird schnell merken, dass sich dieses Werk-zeug als hilfreich dabei erweisen kann, zu verstehen, was eigentlich zu entscheiden ist, welche Informationen dazu benötigt werden und wie das mit anderen Entscheidun-gen zusammenhängt. Die so gewonnenen Erkenntnisse kommen einem beispielsweise bei der Gestaltung der Ge-schäftsprozesse zugute.

Zuweilen lohnt es sich auch, in der Analyse noch eine Ebene tiefer zu gehen und die Entscheidungslogik mithil-fe von Entscheidungstabellen genauer zu analysieren, um

wirklich zu verstehen, welche Informationen tatsächlich für eine Entscheidung benötigt werden; denn bekanntlich steckt der Teufel im Detail.

Das Zusammenspiel von DRD und Entscheidungsta-bellen kann auch hilfreich sein, um bei einer sehr großen Anzahl von Geschäftsregeln Struktur und Ordnung in den Regelzoo zu bringen.

Eine weitere Verwendungsmöglichkeit wäre die Au-tomatisierung der Entscheidungslogik. Die Verwendung von Boxed Expressions zusammen mit FEEL oder an-deren maschinenlesbaren Sprachen bietet prinzipiell die Möglichkeiten, die Entscheidungslogik zu automatisieren. Doch was das anbetrifft, müssen wir erst einmal abwar-ten, inwieweit die Toolhersteller die DMN unterstützen werden. Es gibt zwar bereits erste Modellierungstools, aber noch keine Tools, die etwa die Entscheidungstabellen der DMN interpretieren und ausführen.

Die dritte Anwendungsmöglichkeit ist das Thema Compliance. Dabei geht es vor allem darum, Regeln ein-zuhalten, z. B. im Umgang mit Risiken. Hier unterstützt die DMN insbesondere mit dem DRD: Einzuhaltende Regelwerke können einfach als Wissensquellen dargestellt werden. Über Vorgaben kann außerdem die Verbindung zu den betroffenen Entscheidungen modelliert werden, bei denen die Regelwerke einzuhalten sind. Die anzuwenden-den Regeln, die in den Entscheidungstabellen formuliert werden, stellen dann die konkrete, direkt anwendbare Ausgestaltung der allgemeinen Regelwerke dar, die durch die Wissensquellen repräsentiert werden.

links & literatur[1] „Decision Model and Notation“, Beta1, OMG Document

Number: dtc/2014-02-01: http://www.omg.org/spec/DMN/1.0

[2] Debevoise, T.; Taylor, J.: „The Microguide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling“, createSpace Independent Publishing Platform, 2014

Dr. Marcus winteroll ist Mitglied der oose Innovative Infor-matik eG und beschäftigt sich als Trai-ner und Berater mit der Analyse sowie Verbesserung von Geschäfts- und Ent-wicklungsprozessen. Dazu setzt er auf agile Methoden, aber auch die klassi-schen Vorgehensweisen sind ihm aus seiner langjährigen Erfahrung als Pro-jektleiter, Prozessmanager, Analyti-ker, Qualitätssicherer und Entwickler

vertraut. Seine Erfahrungen berichtet er als Sprecher auf Konferenzen und Autor von Fachartikeln. Außerdem ist er Fragenschreiber für das BPM-Zertifikat der OMG (OcEB2).

Abb. 6: Boxed Expression mit natürlichsprachlichen Ausdrü-cken