Geschäftsregeln sind Arten von Anforderungen, die festlegen, wie das Geschäft, einschließlich der Geschäftstools
funktionieren muss. Sie können Gesetze und Verordnungen sein, denen das Geschäft unterliegt, aber auch die gewählte
Geschäftsarchitektur und den gewählten Stil dokumentieren. Es gibt zwei Methoden für die Erfassung von Geschäftsregeln:
-
Modellbasiert - Geschäftsregeln werden als stereotype Einschränkungen in UML-Modellen erfasst. Die Regel
kann mit natürlicher Sprache oder einer formaleren Notation wie Object Constraint Language (OCL) deklariert werden.
Der Vorteil dieser Technik besteht darin, dass die Geschäftsregeln für die Quelle erfasst und angezeigt werden, für
die sie gelten. Der Hauptnachteil ist der, dass Geschäftsregeln über das gesamte Modell verteilt sind und es daher
schwierig ist, zugehörige Geschäftsregeln anzuzeigen. Der Bericht Übersicht über Geschäftsregeln gibt einen Überblick über alle Geschäftsregeln im
Modell.
-
Dokumentbasiert - Geschäftsregeln werden in einem gesonderten Dokument erfasst. Das Dokument enthält
Geschäftsregeln, aber dies sind nicht die Geschäftsregeln, die im modellbasierten Ansatz verwendet werden. Ein
dokumentbasierter Ansatz ist hilfreich, wenn sehr viele Geschäftsregeln zu beachten sind (z. B. für
Finanzprodukte). Ein Nachteil ist, dass Geschäftsregeln in einem anderen Artefakt erfasst werden als die Quelle,
für die sie gelten.
Geschäftsregeln können in Dokument- und Modellform erfasst werden. Wenn Sie sich einen Überblick über die
Geschäftsregeln in Modellen verschaffen möchten, können Sie einen Bericht Übersicht
über Geschäftsregeln generieren.
Ein Dokument für Geschäftsregeln ist besonders hilfreich für Geschäftsregeln, die ausführliche Beschreibungen haben, z.
B. gesetzliche Vorschriften. Dokumentbasierte Geschäftsregeln haben den Nachteil, dass es trotzdem erforderlich sein
kann, die Rückverfolgbarkeit der Geschäftsregeln zu allen entsprechendenden Teilen des Modells zu gewährleisten. Diese
Schwierigkeit kann mit modellbasierten Geschäftsregeln überwunden werden, die direkt an den entsprechenden Stellen im
Modell erfasst werden können. Dies hat jedoch den Nachteil, dass die Geschäftsregeln "im Modell verschwinden" und es
schwieriger ist, sich einen Überblick über alle Geschäftsregeln zu verschaffen, die gemeinsame Merkmale haben (z. b. zu
einer bestimmten Kategorie gehören).
Geschäftsregeln müssen strikt und formal ausgedrückt werden, damit sie eine Basis für die Automatisierung bilden
können. Eine Alternative ist die Verwendung der Object Constraint Language (OCL) gemäß Spezifikation in Unified
Modeling Language (UML) [RUM98].
Berücksichtigen Sie immer, wer die Geschäftsregeln liest. Wenn Sie den Fokus auf den Leser setzen, stellen Sie sicher,
dass die Art und Weise, in der Sie die Geschäftsregeln (Dokumente oder Modelle) erfassen, der gewählte Stil und die
gewählte Formalitätsstufe für die Zielgruppe angemessen ist. Geschäftsregeln, die von denen, die sie lesen müssen,
nicht verstanden werden, sind in jedem Projekt Zeitverschwendung.
Beispiel:
Sie möchten die Größe eines Teams auf weniger als zehn Mitglieder beschränken. Mit der OCL können Sie diese
Geschäftsregel als Invariante ausdrücken:
context Team inv:
self.numberOfMembers <= 10
Sie müssen jedoch daran denken, dass dieser formale Sprachtyp für viele Ihrer Stakeholder schwierig zu interpretieren
ist und deshalb vielleicht eine eher natürliche Sprache zu bevorzugen ist. Sie können eine Gruppe von reservierten
Ausdrücken definieren, die Sie für die Definition der Regeln verwenden. Diese Ausdrücke sollten dieselben sein, die in
[ODL98] definiert sind:
-
IF (WENN)
-
ONLY IF (NUR WENN)
-
WHEN (WENN)
-
THEN (DANN)
-
ELSE (SONST)
-
IT MUST ALWAYS HOLD THAT (ES MUSS IMMER GELTEN, DASS)
-
IS CORRECTLY COMPLETED (IST ORDNUNGSGEMÄSS DURCHGEFÜHRT)
Beispiel:
In dieser weniger formalen Sprache, liest sich das Beispiel wie folgt:
ES MUSS IMMER GELTEN, dass die Anzahl der Teammitglieder kleiner-gleich 10 ist.
Regeln können auf viele Arten klassifiziert werden, obwohl es üblich ist, sie in Bedingungsregeln und Ableitungsregel
zu unterteilen. [ODL98] Beide Kategorien können wie folgt weiter unterteilt werden:
-
Bedingungsregeln geben Richtlinien oder Bedingungen an, die Objektstruktur und -verhalten einschränken.
Bedingungsregeln können immer oder nur unter bestimmten Bedingungen gelten. Bedingungen, die immer
gelten, werden als Invarianten bezeichnet.
-
Stimulus- und Antwortregeln schränken Verhalten ein, indem sie festlegen, wann und ob Bedingungen
zutreffen müssen, damit ein bestimmtes Verhalten ausgelöst wird.
-
Bedingungsregeln für Operationen definieren Bedingungen, die vor oder nach einer Operation gelten (wahr
sein müssen) müssen, damit sichergestellt ist, dass die Operation ordnungsgemäß ausgeführt wird.
-
Bedingungsregeln für Struktur definieren Richtlinien oder Bedingungen für Klassen, Objekte und ihre
Beziehungen, gegen die nicht verstoßen werden darf.
-
Ableitungsregeln definieren Richtlinien oder Bedingungen, um Fakten aus anderen Fakten abzuleiten oder zu
berechnen.
-
Inferenzregeln definieren, dass Rückschlüsse gezogen werden können, wenn bestimmte Fakten zutreffen
(wahr sind).
-
Berechnungsregeln leiten ihre Ergebnisse mit Hilfe von Verarbeitungsalgorithmen ab und sind eine
komplexere Variante von Interferenzregeln.
Diese Klassifizierung von Geschäftsregeln ist praktisch, wenn erläutert werden muss, was Geschäftsregeln sind, wie man
sie findet und wie man mit ihnen arbeitet. Sie müssen sie jedoch nicht als feste Gruppierungen betrachten, auf die Sie
sich immer beziehen müssen. Deshalb zeigt unsere Vorlage für das Artefakt Geschäftsregeln diese Klassifizierung nicht.
In Ihrem Projekt wird es sehr wahrscheinlich andere Gruppierungen geben (nach Domäne, nach Benutzer oder nach
Produktgruppe), die aussagefähiger sind. Weitere Informationen zum Klassifizieren und Anwenden von Geschäftsregeln
finden Sie in [ROS97].
Eine Geschäftsregel wirkt sich auf die Darstellung Ihrer Modelle aus. Sie kann auch Einfluss darauf nehmen, wie Sie die
Aufgaben in Ihrem Aktivitätsdiagramm anordnen und welche Assoziationen zwischen Geschäftsentitäten verwendet werden.
Einige Regeln sind nicht direkt in die Darstellung des Diagramms umsetzbar und müssen unter Umständen in den
Beschreibungen des Modells untergebracht werden.
Geschäftsregeln in einem UML-Diagramm sollten mit dem Modellelement verbunden werden, auf das sie sich auswirken.
Außerdem ist es hilfreich, Geschäftsregeln für Rückverfolgbarkeits- und Berichtszwecke in Anforderungsattributen zu verfolgen.
Stimulus- und Antwortregeln
Diese Art von Geschäftsregel wirkt sich auf den Workflow eines Geschäftsanwendungsfalls aus und kann zu dem
Geschäftsanwendungsfall zurückverfolgt werden, auf den sie sich bezieht. Sie können einen Bedingungspfad oder einen
alternativen Pfad durch den Workflow zeigen. Wenn die beteiligten Aktionen von geringerer Bedeutung sind, kann es
ausreichen, die Auswertung der Geschäftsregel in einen Aktivitätszustand einzuschließen.
Im Geschäftsanalysemodell könnte sich eine Regel dieser Art beispielsweise darauf auswirken, wie Sie den Lebenszyklus
einer Geschäftsentität beschreiben. Eine solche Regel könnte auch in die Beschreibung einer Operation eines
Mitarbeiters aufgenommen werden. Die Untersuchung der identifizierten Geschäftsereignisse ist eine sehr hilfreiche
Quelle für die Definition solcher Arten von Geschäftsregeln. Normalerweise wird ein Geschäftsereignis identifiziert,
weil irgendjemand oder irgendetwas an dem Eintreten des Ereignisses interessiert ist. Stellen Sie sich die Frage
"Welches Verhalten oder welche Bedingungen gelten, wenn das Ereignis eintritt?"
Beispiel:
In einer Organisation für Auftragsbearbeitung könnten Sie die folgende Regel finden:
WENN eine Bestellung storniert wird
WENN die Bestellung nicht geliefert wird
DANN die Bestellung schließen
Diese Geschäftsregel wird mit zwei alternativen Pfaden in einem Workflow und im Einzelnen mit einer Entscheidung und
einer Wächterbedingung an abgehenden Übergängen abgebildet.
Die Geschäftsregel wird in diesem Fall in einen alternativen Pfad durch den Workflow übersetzt.
Bedingungsregeln für Operationen
Diese Art von Geschäftsregel wird häufig in Vorbedingungen und Nachbedingungen eines Workflow oder in einen bedingten
oder alternativen Pfad in einem Workflow umgesetzt. Es kann sich auch um ein Leistungsziel oder eine andere nicht
verhaltensbezogene Regel handeln, die auf die betroffenen Geschäftsanwendungsfälle zurückverfolgt werden sollten.
Beispiel:
In einer Organisation für Auftragsbearbeitung könnten Sie die folgende Regel finden:
Bestellung an Kunden ausliefern
NUR WENN der Kunde eine Lieferadresse hat
Die Geschäftsregel wird in einen alternativen Pfad im Workflow übersetzt.
Beispiel:
Eine weitere Bedingungsregel für Operationen ist folgende:
ES MUSS IMMER GELTEN, DASS
alle Kundenanfragen innerhalb von 24 Stunden des Erhalts beantwortet werden.
Diese Geschäftsregel wird in ein Leistungsziel eines Geschäftsanwendungsfalls übersetzt. Weitere Informationen hierzu
finden Sie im Abschnitt über Leistungsziele auf der Seite Richtlinie: Geschäftsanwendungsfall.
Bedingungsregeln für Struktur
Diese Art von Geschäftsregel wirkt sich auf die Beziehungen zwischen Instanzen von Geschäftsentitäten aus. Sie wird
durch die Existenz einer Assoziation zwischen zwei Geschäftsentitäten, manchmal als Multiplizität der Assoziation
ausgedrückt.
Beispiel:
In einer Organisation für Auftragsbearbeitung könnten Sie die folgende Regel finden:
ES MUSS IMMER GELTEN, DASS
eine Bestellung sich mindestens auf 1 Produkt bezieht.
Diese Geschäftsregel wird in eine Assoziation mit der Multiplizität 1..* übersetzt.
Inferenzregeln
Inferenzregeln sind Stimulus- Antwortregeln sowie Bedingungsregeln für Operationen und Bedingungsregeln für Struktur
häufig sehr ähnlich. Der Unterschied besteht darin, dass ein paar Schritte durchdacht werden müssen, um zu einem
Schluss zu gelangen. Die Regel impliziert eine Methode, die in einem Aktivitätszustand des Workflows und letztendlich
in einer Operation eines Mitarbeiters oder einer Geschäftsentität abgebildet werden muss.
Beispiel:
Sie können die folgende Regel definieren, um den Status eines Kunden zu bestimmen:
Ein Kunde ist ein guter Kunde, WENN und NUR WENN
die unbezahlten Rechnungen, die an diesen Kunden gesendet wurden, weniger als 30 Tage alt sind.
Diese Geschäftsregel entspricht einem alternativen Pfad durch den Workflow, und die Methode wird in der Aufgabe "Kunden
bewerten" abgebildet.
Berechnungsregeln
Berechnungsregeln sind Inferenzregeln sehr ähnlich. Der Unterschied besteht darin, dass die Methode formaler ist und
wie ein Algorithmus aussieht. Wie bei Inferenzregeln muss diese Methode zu einer Aufgabe im Workflow und letztendlich
zu einer Operation eines Mitarbeiters oder einer Geschäftsentität zurückverfolgt werden können.
Beispiel:
Eine Berechnungsregel kann die Berechnung eines Wertes spezifizieren:
Der Nettopreis eines Produkts WIRD WIE FOLGT BERECHNET
Produktpreis * (1+Steuersatz/100).
Die Auswertung des Nettopreises könnte Teil der Aufgabe "Bestellung ausliefern" sein, da Sie dort die Rechnung
erstellen, die mit der Bestellung versendet wird. Im Geschäftsanalysemodell wird diese Regel in Assoziationen und
Operationen übersetzt.
Die Regel muss als Methode in der Operation "Nettopreis berechnen" abgebildet werden, impliziert aber auch den Bedarf
an Beziehungen zwischen Klassen im Modell.
|