Business Process and Model Notation (BPMN) für die Modellierung von Datentransformationen

Um einen Überblick über die aktuellen Möglichkeiten der Modellierung zu bekommen, wurden durch eine gezielte Recherche geeignete grafische Methoden gesucht. Dafür wurden zunächst Anforderungen festgestellt, die wir als Unternehmen an solch eine Modellierung haben.

Anforderungen an eine Modellierungstechnik für Datentransformationen

Die Anforderungen ergaben sich aus wissenschaftlicher Literatur. Dazu zählen unteranderem:

• Ziel und Zweck einer Modellierungstechnik ist die grafische Darstellung von Datentransformationen mit entsprechenden Notationselementen
• Darstellung von Quell- und Zielsystemen
• Darstellung folgender Operationen: Aggregation, Konvertierung, Filter und Join
• Darstellung mehrerer unterschiedlicher Datentransformationen in einem Prozess

Es wurden nur Modellierungstechniken im weiteren Verlauf näher betrachtet, die alle genannten Anforderungen erfüllen konnten.
Im Zuge der Recherche haben sich dann sechs Modellierungstechniken herauskristallisiert:

• BPMN Erweiterung für ETL-Prozesse [1]
• UML-Klassendiagramm Erweiterung für ETL-Prozesse [2]
• UML-Aktivitätsdiagramm Erweiterung für ETL-Prozesse [3]
• KANTARA-Framework [4]
• Modell von Vassiliadis, Simitsis und Skiadopoulos [5]
• Modell von Dupor und Jovanovic [6]

Diese wurden innerhalb eines Vergleichs durch formale, unternehmensbezogene und anwenderbezogene Kriterien bewertet. Die zwei Methoden „BPMN Erweiterung für Extract-Transform-Load (ETL)-Prozesse“ und „UML Aktivitätsdiagramm Erweiterung für ETL-Prozesse“ wurden anschließend ausgewählt, da nur diese beiden fähig sind, in verschiedenen Detailierungsebenen zu abstrahieren und vielfältige Datentransformationen abzubilden.
Beide Modellierungstechniken wurden anschließend an einem Praxisbeispiel von doubleSlash verprobt, um herauszufinden welche Methode für doubleSlash am geeignetsten ist.

Zu modellierender Anwendungsfall mit BPMN und UML Aktivitätsdiagramm

Bei doubleSlash wird ein Data Hub eingesetzt, um aus verschiedenen internen Systemen Auswertungen zu generieren. Ein Beispiel ist die Berechnung des Auftragseingangs oder auch die Berechnung der Betriebsleistung. Über Schnittstellen zu den internen Systemen werden die Daten aus den Quellsystemen extrahiert und in eine gemeinsame Datenbasis übertragen. Anschließend werden die Daten aus dem jeweiligen System in einem so genannten „Import-Bereich“ separat transformiert, um sie anschließend in einem Anwendungsfall einzusetzen und mit weiteren Daten zusammenzuführen. Die verschiedenen Anwendungsfälle können untereinander Abhängigkeiten haben.
Aus dem Data Hub wurde ein Anwendungsfall modelliert, der das aktuelle Auftragsvolumen auswertet. Das folgende Schaubild zeigt die Zusammensetzung des Anwendungsfalls:

Es wurden zunächst Angebotsdaten aus dem Angebotsverwaltungssystem und Daten von Bestellungen sowie Bestellpositionen aus dem Abrechnungssystem transformiert.

Anwendung der Modellierungstechniken BPMN und UML Aktivitätsdiagramm

Bei der Verwendung der Modellierungstechniken wurde Wert daraufgelegt, die Abstraktionsmöglichkeiten darzustellen, indem an geeigneten Stellen Teilprozesse eingesetzt wurden. Die „BPMN Erweiterung“ und „UML Aktivitätsdiagramm Erweiterung“ für Datentransformationen erweisen sich als besonders flexibel, da jegliche Arten von Datentransformationen in Aktivitäten dargestellt werden können. Aus Komplexitätsgründen werden nur einige ausgewählte Teile dargestellt.

Anwendung mit BPMN

Der Anwendungsfall wird in einem Pool mit dem Titel „Anwendungsfall: Auswertung Auftragsvolumen“ dargestellt. Abbildung 2 zeigt die ersten Prozessschritte.

Zu Beginn wird der Prozess durch das parallele Gateway in drei Ausgangspfade unterteilt (siehe rote Markierung). Die drei auszulesenden Tabellen werden durch Datenobjekte visualisiert. Die Filter für die wichtigsten Spalten sind mit Datenannotationen verknüpft, die beschreiben, welche Spalten behalten werden.

Die beiden Tabellen Bestellungen und Bestellpositionen werden mit einem Full Outer Join zusammengeführt. Die Bedingung für den Join ist in einer Datenannotation dargestellt. Anschließend werden die Angebote mit der zuvor zusammengeführten Tabelle durch einen weiteren Full Outer Join verknüpft. Daraufhin erfolgt der Teilprozess „Überprüfung Auftragseingang des aktuellen Monats“. Alle weiteren Datentransformationen, die in diesem Anwendungsfall aufgetreten sind, wurden ebenfalls in dem Aktivitäts-Notationselement modelliert.

Verbesserungspotential BPMN

Aus der Anwendung ergaben sich einige wenige Verbesserungspotentiale. Mit der Notation kann nicht der Anfangs- oder Endzustand einer Tabelle dargestellt werden. Das wäre insbesondere bei dem Import aus verschiedenen Systemen hilfreich, um zu erkennen, wie die Attribute sich verändert haben und ob neue hinzugefügt wurden. An dieser Stelle bietet es sich an, den Anfangs- und Endzustand der Tabelle in einer zusätzlichen Tabelle zum Prozessdiagramm darzustellen. Weiterhin erfolgt die Darstellung von Tabellenattributen bisher nur als Kommentar in einer Datenannotation. Um den eigentlichen Nutzen eines Kommentars wiederherzustellen, bietet es sich an, die Datenannotation um eine weitere Variable zu erweitern, die mit „Tabellenattribute“ betitelt wird. Im Zuge dessen können dann auch die entsprechenden Datentypen bspw. wie folgt angegeben werden: Tabellenattribut1:Datentyp.

Anwendung mit UML Aktivitätsdiagramm

Zunächst werden für den Anwendungsfall die drei benötigten Tabellen aus der Zwischenablage geladen. Die folgende Abbildung zeigt den Prozessstart durch das Symbolisieren des Quellsystems, der Zwischenablage.

Das Laden der drei Tabellen Angebote, Bestellungen und Bestellpositionen werden durch drei Pfade aufgeteilt (siehe rote Markierung). Daraufhin werden die benötigten Spalten mit einem Filter über die „Selection“ eingeschlossen. Der Prozess „Zählen der Bestellpositionen“ wird als Teilprozess dargestellt. Die nächste Abbildung zeigt das Zusammenführen der Tabellen.

Die Tabellen Bestellungen und Bestellpositionen werden über einen Full Outer Join zusammengeführt. Dafür werden zunächst die relevanten Attribute (id und orderid) angegeben und überprüft. Anschließend wird die Aktivität mit dem anzuwendenden Join sowie der Bedingung dargestellt. Diese verbundene Tabelle wird anschließend auch mit einem Full Outer Join mit der Tabelle Angebote zusammengeführt.

Verbesserungspotential UML Aktivitätsdiagramm

Beim UML Aktivitätsdiagramm fallen vor allem Filter, Joins, Konvertierungen und Aggregationen sofort auf, da diese eine gesonderte Darstellung haben. In der Darstellung werden die benötigten Informationen zur Datentransformationsaufgabe abgebildet, wie bspw. die zu selektierenden Daten bei einem Filter. Das Konzept der Autoren Muñoz u.a. beruht auf einem Template, dass für die oben genannten Datentransformationen angewendet wurde. Es bietet sich an, einige weitere Transformationen ebenfalls in diesem Template darzustellen, wie bspw. Spaltenumbenennungen oder die Behandlung von fehlenden Werten. Somit können die entsprechenden Spalten, für die die Änderung umgesetzt werden soll, einfach mit angegeben werden. Allerdings unterscheidet das Template für den Filter nicht zwischen einem Zeilen- oder Spaltenfilter, was optimiert werden kann. Bspw. könnte dies im Aktivitätsnamen mit aufgegriffen werden. Grundsätzlich können zusätzlich auch Notizen bzw. Kommentare eingesetzt werden, um z.B. Tabellenattribute und Datentypen für Datentransformationsaufgaben abzubilden. Wie auch bei BPMN bietet es sich an, den Anfangs- und Endzustand einer Tabelle tabellarisch mit abzubilden.

Beide Modellierungstechniken BPMN und das UML Aktivitätsdiagramm sind geeignet, um die Datentransformationen aus dem Anwendungsfall darzustellen. Dennoch haben beide Verbesserungspotential. Die bedeutenden Unterschiede der Modelle mit BPMN und dem UML-Aktivitätsdiagramm liegen vor allem in der Visualisierung von Tabellen und Dateien sowie in der Darstellung von Aktivitäten.
Durch die bessere Umsetzung mit BPMN, die Nachvollziehbarkeit aller Notationselemente und dem geringen Aufwand zur Einarbeitung der vorgeschlagenen Verbesserungen, stellt sich die BPMN Erweiterung zur Darstellung von Datentransformationen gegenüber dem UML Aktivitätsdiagramm als bessere Variante für doubleSlash heraus. Ein weiterer großer Vorteil ist, dass die Implementierung bei doubleSlash vermutlich einen geringen Zeitaufwand ermöglicht, da die Notationselemente sowie die Anwendungsregeln kaum von der Basisnotation abweichen.

Forschungspotential für Modellierungstechniken von Datentransformationen

Aufgrund der zeitlichen Limitation wurden die Ergebnisse nur an einem Anwendungsfall überprüft. Demnach gilt es nun, die BPMN Erweiterung in Projekten weiter zu verproben und zu validieren. Ein weiterer Ansatz, den es zu erforschen gilt, ist ob sich die BPMN Erweiterung auch eignet, um einen Datentransformationsprozess von Beginn an zu konzipieren und ob die bestehenden Notationselemente dafür ausreichen. Weiterhin ist interessant, ob andere Unternehmen andere Modellierungstechniken einsetzen oder BPMN ebenfalls als geeignete Methode betrachten würden.

Zudem stellt sich die Frage, wie eine Modellierungstechnik aussieht, die speziell für Datentransformationen entworfen wird und die Kriterien im oben genannten Vergleich erfüllen würde.

Mehr über Data Driven Services erfahren

Quellen: