Das statische Business Objekt Modell als Analyse-Werkzeug

Wir lösen eine Problemstellung aus dem Requirements Engineering mit Hilfe eines dafür unkonventionellen Werkzeugs: Dem statischen Business Objekt Modell.
Damit untersuchen wir die Unterschiede zwischen zwei ähnlichen Regelwerken auf visuelle Weise.

Einleitung

Wir lösen eine Problemstellung aus dem Requirements Engineering mit Hilfe eines dafür unkonventionellen Werkzeugs: Dem statischen Business Objekt Modell.
In einem Kundenprojekt sollen verschiedene dezentrale Implementierungen für Online-Bestellprozesse durch einen neu entwickelten, zentralen Dienst ersetzt werden. Um sicherzustellen, dass sich dabei das Verhalten gegen aussen nicht ändert, müssen vor der Ablösung die alte und die neue Implementierung nochmals auf Unterschiede überprüft werden. Wir untersuchen also die Unterschiede zwischen zwei ähnlichen Regelwerken auf visuelle Weise.

Ausgangslage

Ein Unternehmen bietet verschiedene Internetdienstleistungs-Produkte über einen Online-Shop an. Die entsprechenden Geschäftsprozesse rund um die Bestellung, Änderung und Kündigung von Internet-Dienstleistungen decken die gesamte Lieferkette vom Ordermanagement bis zur Logistik ab. Dabei gibt es innerhalb der Geschäftsprozesse komplexe zeitliche Abhängigkeiten zwischen nicht weniger als 18 verschiedenen Ereignissen.

Zum Beispiel darf das gewünschte Aufschaltdatum eines Services nicht in der Vergangenheit liegen. Etwas weniger trivial: Ein Service darf erst dann aktiviert und auch verrechnet werden, wenn die letzte verschickte Hardware-Komponente beim Kunden angekommen ist, die für den Service nötig ist. Dabei ist relevant, ob ein Kunde die Komponente selbst abholt, ein Techniker sie vorbeibringt, oder sie per Post verschickt wird.

Die angebotenen Produkte lassen sich in zwei Technologien kategorisieren: Virtuelle und dedizierte Services.

Problemstellung

Im Rahmen einer Konsolidierung der SOA wurde das gesamte Regelwerk rund um Ereignisse in einem zentralen Workflow neu umgesetzt, der von den einzelnen Order-Management-Applikationen aufgerufen werden kann. Nun sollen die alten lokalen Implementierungen abgelöst werden.

Unsere Aufgabe war es, bei dieser Ablösung allfällige Unterschiede zwischen der alten lokalen und der Logik in dem neuen Workflow zu finden, so dass Konflikte kontrolliert bereinigt werden können. Es ging also nicht darum, die Logik bis ins Detail zu verstehen, sondern insbesondere die Differenzen zu erkennen. Dabei kam aber erschwerend dazu, dass Abhängigkeiten zwischen Ereignissen pro Anwendungsfall und Technologie unterschiedlich ausgeprägt sind. Eine bestimmte Regel gilt also vielleicht für die Aktivierung, aber nicht für die Verlängerung. Oder sie gilt zwar für beide Anwendungsfälle, aber nur für die dedizierten Services und nicht für die virtuellen.

„Aufgabe: Finde die Unterschiede zwischen zwei sehr ähnlichen, komplexen Regelwerken.“

Wir haben uns entschieden, die Analyse mit Hilfe eines statischen Business Objekt Modells durchzuführen. Diesen Ansatz möchten wir hier erläutern.

Aufbau des Business Objekt Modells

Jedes Datum ist als stereotypisiertes Business Objekt modelliert. Der Stereotyp definiert dabei, um welche Art von Business Objekt es sich handelt:

• Einen Benutzer-Input
• Ein System-Input (z.B. geliefert durch einen externen Webservice)
• Ein berechneter Wert (Output)

Eine Regel oder Abhängigkeit zwischen zwei Ereignissen wird durch eine Relation zwischen zwei Business Objekten modelliert. Hier ein ganz einfaches Beispiel: „Das vom Kunden gewünschte Aktivierungsdatum darf nicht in der Vergangenheit liegen“. Ausgedrückt durch die Relation „NotBefore“.

Umsetzung des Modells

In einem ersten Schritt wurden nun alle bekannten Regeln mit Hilfe solcher Relationen modelliert. Das entstandene Konstrukt sieht nicht nur kompliziert aus, es enthält auch Beziehungen, die in der statischen Sicht widersprüchlich scheinen. Zum Beispiel kann es zwischen zwei Objekten eine „NotBefore“-Beziehung wie auch eine „NotAfter“ Beziehung geben. Welche der beiden wann gilt hängt von dynamischen Regeln ab. Sprich: Kann erst zur Laufzeit entschieden werden.

In einem zweiten Schritt werden nun Ansichten des Modells für bestimmte Konstellationen der dynamischen Parameter erstellt. In diesem Fall haben wir zwei solche Parameter: Den Use Case und die Service-Technologie.

Use Cases:

• Aktivierung
• Verlängerung
• Deaktivierung

Service-Technologien:

• Dediziert
• Virtuell

Anwendung

Das Resultat sieht folgendermassen aus. Durch Klicken auf die Schaltflächen unten am Diagramm können Sie zwischen den einzelnen Ansichten hin und her wechseln. So werden auf einfache Weise Unterschiede visuell ersichtlich.

Um die Technologie-abhängigen Regel-Unterschiede im Use Case „Aktivierung“ zu untersuchen, wählen Sie unten den Use Case „Aktivierung“ aus und wechseln Sie dann zwischen den Technologien „Dediziert“ und „Virtuell“ hin und her. Anmerkung: Der Use Case „Deaktivierung“ ist für beide Technologien trivial und identisch. Sie finden daher keine Unterschiede.

Analog: Um die Unterschiede zwischen den einzelnen Use Cases für eine bestimmte Technologie zu sehen, wählen Sie z.B. „Dediziert aus“ und wechseln Sie dann zwischen den einzelnen Use Cases hin und her.

Und last but not least können natürlich die Unterschiede zwischen der alten lokalen und der neuen zentralisierten Logik visuell untersucht werden. Dazu wechseln Sie zwischen den Schaltflächen „Komplett“ und „Differenzen“.

	Activation	Retention	Deactivation	Alle
Dedicated	AD	RD	DD	Komplett
Virtual	AV	RV	DV	Differenzen

Ergebnisse und Fazit

Mit Hilfe des statischen Business Objekt Modells konnte der Auftrag erfüllt werden: Unterschiede in der Logik wurden visuell einfach erkennbar. Die gefundenen Konflikte konnten bereinigt werden. Unten stehendes Bild zeigt Beispiele gefundener Abweichungen:

Als zusätzlicher Benefit sind die Unterschiede pro Use Case und Technologie visuell schnell erfassbar.
Der hier vorgestellte Ansatz ist aber nur einer von vielen möglichen. Seine Stärken zeigen sich unter folgenden Umständen:

• Die Abhängigkeiten zwischen den Business Objekten enthält eine gewisse Komplexität, die ohne visuelle Hilfe schwer fassbar wäre.
• Es gibt wenige Dimensionen dynamischer Parameter (hier: Use Case und Technologie). Die Anzahl notwendiger Diagramme explodiert mit der Anzahl Dimensionen.
• Es interessieren die Unterschiede zwischen den einzelnen Ausprägungen. Es ist weniger relevant, wie genau die Regeln für einen spezifischen Fall aussehen.
• Der Betrachtungsraum ist geschlossen. Hier wurden nur die verschiedenen Datums-Felder betrachtet. Abhängigkeiten zu anderen Business Objekten oder Services waren nicht relevant.

Natürlich gibt es noch viele weitere legitime Darstellungsvarianten. Letztendlich ist der Empfänger ausschlaggebend: Welche Aufbereitung der Informationen unterstützt den Leser am besten in seiner Problemstellung?