Business Rules - Geschäftsregeln: Konzepte, Modellierungsansätze, Softwaresysteme

Textprobe:

Kapitel 6.3, Integrierte Ansätze der Geschäftsregelmodellierung:

6.3.1, Geschäftsregeln in UML.
6.3.1.1,Allgemeines.
Als eigenständiges Paradigma der Entwicklung von Informationssystemen zielt Objektorientierung auf die Bereitstellung von Bezugsrahmen, die von der Analyse über die Modellierung bis hin zur Implementierung für alle Phasen des Entwicklungsprozesses Gültigkeit besitzen. Durch eine möglichst methodeneinheitliche Modellierung sowohl der fachlichen Anforderungen, als auch ihrer Umsetzung in Anwendungssystemen wird einerseits eine bessere Kommunikation zwischen Modellierern der Fachseite und Systementwicklern ermöglicht. Andererseits entfällt mit der Transformation einer Beschreibungssprache in eine andere auch eine potentielle Fehlerquelle.
In den 1990er Jahren von den Methodenentwicklern GRADY BOOCH, IVAR JACOBSON und JAMES RUMBAUGH entworfen und 1997 durch die OMG als Standard akzeptiert, entwickelte sich UML schnell zur dominierenden Sprache objektorientierter Modellierung von Softwaresystemen. Vor diesem Hintergrund wurden verschiedene Anstrengungen unternommen, UML um Methoden der Unternehmensmodellierung im Allgemeinen, und der Geschäftsregelmodellierung im Speziellen anzureichern. UML stellt grundsätzlich eine Reihe verschiedener Diagrammtypen mit einheitlicher Notation und Semantik zur Verfügung, ohne deren konkrete Verwendung methodisch festzulegen:
- Klassendiagramme werden zur Modellierung von Objektklassen, deren Attribute, Methoden (d. h. Operationen im Sinne des objektorientierten Ansatzes) und Beziehungen zueinander verwendet.
- Anwendungsfalldiagramme dienen zur Darstellung möglicher Interaktionen von Akteuren bzw. Anwendern mit dem Anwendungssystem, beschränkt sich dabei jedoch auf die für den Anwender sichtbaren Aktionen und Reaktionen innerhalb eines Geschäftsprozesses.
- Im Gegensatz hierzu stellen Aktivitätsdiagramme Kontrollflüsse innerhalb eines Systems, bestehend aus alternativen zeitlich-logischen Abfolgen systemseitiger Aktivitäten dar. Durch Unterteilung der Diagramme in sog. "swim lanes" lassen sich die Aktivitäten bestimmten Objektklassen zuordnen.
- Sequenz- und Kollaborationsdiagramme werden zur Darstellung zulässiger Interaktionen zwischen Objektklassen verwendet.
- In Zustandsdiagrammen werden schließlich die zulässigen Zustände von Objekten einer Objektklasse modelliert, die durch Attributswerte repräsentiert und durch Operationen verändert werden.
Grundsätzlich wird eine Vielzahl einfacher Geschäftsregeln durch diese Diagramme bereits in impliziter Form ausgedrückt, z. B. Berechtigungsregeln durch Anwendungsfalldiagramme oder Integritätsbeschränkungen durch Kardinalitäten in Klassendiagrammen.
ODELL wies jedoch bereits 1995 auf die Notwendigkeit hin, Geschäftsregeln auch in verbaler, deklarativer Form zu explizieren, und betrachtete insbesondere Ableitungsregeln sowie die von ihm identifizierten strukturellen Einschränkungen als Bestandteile von Objektklassen. REGEV/WEGMANN beschreiben einen Ansatz, bestimmte Geschäftsregeln in Form textueller Bemerkungen zusammen mit kollektiven und individuellen Zielen der Akteure in Anwendungsfalldiagrammen zu dokumentieren. GRAHAM stellt hierzu jedoch klar, dass eine frei formulierte Beschriftung von Modellelementen mit den Anforderungen des Business Rules-Ansatzes nicht zu vereinbaren ist.
Mit OCL wird nun eine sprachlich-semantische, mit Stereotypen eine grafische Notationsform vorgestellt, die zur Erweiterung der UML konzipiert wurden, und für die Geschäftsregelmodellierung in Betracht kommen.
6.3.1.2, OCL:

Um auch komplexere Einschränkungen modellintern in unzweideutiger und zugleich maschinell interpretierbarer Form explizieren zu können, wurde UML 1999 durch die formalisierte Spezifikationssprache OCL ergänzt.
Bsp.: Verbal: "Die Sozialversicherungsnummer einer Person muss einzigartig sein".
OCL: "Person
Person.allinstances -> forAll (p1, p2 ¦
P1 p2 implies p1.SozVersNR
P2.SozVersNR)".
OCL-Ausdrücke können zwar in allen o. g. Diagrammtypen zur Explizierung von Geschäftsregeln verwendet werden, müssen aber jeweils genau einem Modellelement zugeordnet werden. ENDL erachtet die Modellierung von Geschäftsregeln als OCL-Ausdrücke in UML-Diagrammen aus mehreren Gründen als problematisch:

-Die Entscheidung, welche Diagrammtypen neben dem obligatorischen Klassendiagramm überhaupt zu verwenden, und in welchem davon Geschäftsregeln zu modellieren sind, liegt, da UML diesbezüglich kaum Einschränkungen vornimmt, im Ermessen des Modellierers. Zulässige Zustandsübergänge von Objektattributen könnten etwa sowohl Klassen-, als auch Zustands- oder Aktivitätsdiagrammen zugeordnet werden. Ebenso ist innerhalb eines Diagrammtyps festzulegen, welchem Modellelement eine ggf. mehrere Elemente betreffende Geschäftsregeln zuzurechnen ist. Das Objektklassenmodell sollte nach ENDL grundsätzlich den Kristallisationspunkt bilden, in möglichst viele Regeln gemeinsam beschrieben werden.
-In OCL formulierte Regeln haben keine Eigenschaften, sondern sind vielmehr ihrerseits Eigenschaft der jeweiligen UML-Komponente. Es können somit keine zusätzlichen Informationen hinterlegt werden.
-Die Wiederverwendbarkeit von Geschäftsregeln ist in UML nicht vorgesehen - Geschäftsregeln, die von mehreren Modellelementen zu berücksichtigen sind, sind vielmehr redundant zu spezifizieren. GRAHAM identifiziert diesbezüglich ein generelles Spannungsverhältnis zwischen dem Prinzip der Kapselung des objektorientierten Paradigmas und dem Anspruch des Business Rules-Ansatzes, Geschäftsregeln als unabhängige Systemkomponente zu modellieren. Er empfiehlt daher, Geschäftsregeln in einem zentralen Repository abzulegen, und in den jeweils betroffenen Objektklassen nur einen Verweis auf die Fundstelle zu spezifizieren.
UML-Modelle sind, einschließlich der darin enthaltenen OCL-Spezifikationen, plattformunabhängige Modelle im Sinne des MDA-Ansatzes, unterstützen also grundsätzlich eine Abbildung auf plattformabhängige Modelle sowie die automatisierte Generierung ausführbaren Codes in einer objektorientierten Programmiersprache, z. B. in Java. DEMUTH/ HUSSMANN/LOECHER wiesen zwar bereits im Jahr 2001 die Transformierbarkeit in OCL spezifizierter Invarianten in Code der Structured Query Language (SQL) nach. Dennoch bezeichnete LINEHAN das Mapping zwischen den Meta-Modellen der Modellierungssprachen auf den verschiedenen Ebenen des MDA auch im Jahr 2008 noch immer als "offenen Punkt".
Mit Blick auf die technisch-formale Syntax der OCL-Ausdrücke wird diese jedoch übereinstimmend für ungeeignet erachtet, Geschäftsregeln auch für Angehörige der Fachseite in verständlicher Weise zu repräsentieren. Letztlich bleibt auch festzuhalten, dass sich UML als Modellierungssprache für Softwaresysteme naturgemäß stärker an Implementierungsaspekten orientiert. Geschäftsregeln werden darin nicht als eigenständiges Modellierungsobjekt aufgefasst, sondern entstehen "quasi als 'Abfallprodukt' bei der Analyse der Funktionen und der Datenstrukturen".
6.3.1.3, Stereotype und Tagged Values:

Ein weiterer Ansatz zur Erweiterung der UML um Aspekte der Unternehmensmodellierung, insbesondere der Geschäftsprozessmodellierung, setzt bei dem UML-eigenen Erweiterungsmechanismus der sog. Stereotypen an. Stereotype erweitern das aus den Ursprungselementen der UML bestehende Meta-Modell um grafische Modellbausteine, die zusätzliche oder speziell auf die Modellierungssituation angepasste Eigenschaften aufweisen.