Richtlinie: Geschäftsregeln
Eine Geschäftsregel stellt eine Anforderung dar, die festlegt, wie das Geschäft, einschließlich der Geschäftstools funktionieren muss. Diese Richtlinie beschreibt, wie Geschäftsregeln identifiziert und modelliert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Erläuterung

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 erfassen

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).

Formalitätsstufen

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. 

Kategorien von Geschäftsregeln

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].

Abbildung von Geschäftsregeln in Modellen

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. 

Im Begleittext beschriebenes Diagramm

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 

Im Begleittext beschriebenes Diagramm

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. 

Im Begleittext beschriebenes Diagramm

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.  

Im Begleittext beschriebenes Diagramm

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.  

Im Begleittext beschriebenes Diagramm

Die Regel muss als Methode in der Operation "Nettopreis berechnen" abgebildet werden, impliziert aber auch den Bedarf an Beziehungen zwischen Klassen im Modell.