Richtlinie: Geschäftsereignis
Geschäftsereignisse stellen wichtige Vorkommen in den täglichen Aufgaben des Geschäfts dar. Diese Richtlinie beschreibt, wie diese modelliert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Erläuterung

Geschäftsereignisse stellen wichtige Vorkommen in den täglichen Aufgaben des Geschäfts dar. Natürlich passieren in jedem und in Zusammenhang mit jedem Geschäft jeden Tag Tausende von Dingen. Mit Hilfe von Geschäftsereignissen können wir die Komplexität verwalten, indem wir uns auf das Wesentliche konzentrieren, und in diesem Sinn sind sie architektonisch relevant. Geschäftsereignisse haben die folgenden Merkmale:

  • Sie stellen ein Vorkommen von Bedeutung dar, d. h. sie sind nicht trivial.
  • Sie scheinen zufällig oder zumindest unvorhersehbar aufzutreten.
  • Sie treten unabhängig voneinander auf.
  • Sie führen zu einer unmittelbaren Aktion im Geschäft.

Ein Geschäftsereignis, das diese Merkmale nicht aufweist, ist verdächtig.

Geschäftsereignisse werden von Geschäftsakteuren, Mitarbeitern und Geschäftsentitäten bei der Interaktion für die Realisierung der Geschäftsanwendungsfälle ausgelöst und empfangen. Geschäftsereignisse können in den Fällen ausgelöst werden:

  • Von Geschäftsakteuren, um den Beginn oder das Ende eines Geschäftsanwendungsfalls anzuzeigen. Wenn beispielsweise ein Lieferant Waren liefert, könnte ein Geschäftsereignis "Lieferung" den Beginn des Geschäftsanwendungsfalls "Waren liefern" anzeigen.
  • Von Geschäftsentitäten, um eine Änderung des Zustands anzuzeigen. Im Rahmen des Geschäftsanwendungsfalls "Mitarbeiter einstellen" könnte beispielsweise ein Geschäftsereignis "KandidatQualifiziert" anzeigen, dass die Referenzen eines potenziellen Mitarbeiters geprüft wurden.
  • Von Mitarbeitern, um einen speziellen Punkt in einer Geschäftsanwendungsfallrealisierung anzuzeigen. Nachdem beispielsweise eine Rakete gestartet wurde, könnte ein Geschäftsereignis "Start" anzeigen, dass mit der Überwachung der Laufbahn der Rakete begonnen werden kann.
  • Durch das Vergehen von Zeit. Beispielsweise könnte sechs Stunden, nachdem ein Patient aus dem Operationssaal geschoben wurde, ein Geschäftsereignis PatientAufgewacht eine Schwester dazu veranlassen, nach dem Patienten zu sehen.

Geschäftsereignisse modellieren

Geschäftsereignisse können Informationen enthalten, die mehr Kontext zu dem Vorkommen, das von dem Ereignis dargestellt wird, enthalten. Diese Informationen werden, wie in der Abbildung gezeigt, als Attribute der Geschäftsereignisklasse modelliert. Die Attribute eines Geschäftsereignisses können bestimmt werden, indem geprüft wird, welche Informationen die Empfänger des Ereignisses benötigen, um Aktionen einzuleiten.  

UML-Beispiel für Begleittext

Geschäftsereignisse, die Änderungen im Zustand der Geschäftsentitäten darstellen, sollten, wie in der folgenden Abbildung gezeigt, eine Assoziation zu der Geschäftsentität haben, auf die sie sich beziehen. Damit haben die Empfänger des Geschäftsereignisses die Möglichkeit, auf die fragliche Geschäftsentität zuzugreifen und die erforderlichen Informationen abzurufen.

UML-Beispiel für Begleittext

Geschäftsakteure, Mitarbeiter und Geschäftsentitäten können Geschäftsereignisse auslösen und empfangen. Die Klasse, die ein Geschäftsereignis auslöst, ist eine Veröffentlichungskomponente (oder Publisher), und die Klasse, die ein Geschäftsereignis empfängt, ist ein Subskribent.

Eine Veröffentlichungskomponente setzt eine Abhängigkeit mit dem Stereotyp <<senden>> zu den Geschäftsereignissen voraus, die sie auslöst. Schauen Sie sich dazu die folgende Abbildung an.

UML-Beispiel für Begleittext

Ein Subskribent setzt, wie in der Abbildung gezeigt, eine Operation mit dem Stereotyp <<Geschäftsereignis>> mit demselben Namen wie das Geschäftsereignis und Parametern voraus, die den Attributen des Geschäftsereignisses entsprechen. Beachten Sie, dass die Operationssignatur mit dem Namen des Geschäftsereignisses und den Attributen konsistent sein muss.

UML-Beispiel für Begleittext

Alternativ können Sie eine Abhängigkeit mit dem Stereotyp <<empfangen>> (receive) vom Subskribenten zum Geschäftsereignis erstellen, obwohl dies nicht dem UML-Standard entspricht. Die Operationssignaturen können von allen Abhängigkeiten mit dem Stereotyp <<empfangen>> abgeleitet werden. Ein Beispiel dieses vom Standard abweichenden Ansatzes wird in der Abbildung gezeigt.

UML-Beispiel für Begleittext

Das eigentliche Auslösen von Geschäftsereignissen wird in Interaktions- oder Aktivitätsdiagrammen gezeigt. In Interaktionsdiagrammen sendet die Veröffentlichungskomponente eine asynchrone Nachricht mit dem Namen des Geschäftsereignisses an den Empfänger. Ein diesbezügliches Beispiel wird in der Abbildung gezeigt. Beachten Sie bitte, dass es sich um eine asynchrone Nachricht handelt. Dies weist darauf hin, dass die Veröffentlichungskomponente die Verarbeitung des Geschäftsereignisses durch den Subskribenten nicht abwartet. Stattdessen löst die Veröffentlichungskomponente das Geschäftsereignis aus und fährt direkt mit ihrer Arbeit fort. Der Subskribent beginnt mit der Verarbeitung des Geschäftsereignisses, sobald er es empfängt. Dies bildet das echte Leben exakter ab als synchrone Nachrichten.

UML-Beispiel für Begleittext

In Aktivitätsdiagrammen wird gezeigt, dass die Veröffentlichungskomponente das Geschäftsereignis auslöst. Dass der Empfänger das Geschäftsereignis empfängt, wird in demselben oder in einem anderen Diagramm gezeigt. Ein diesbezügliches Beispiel wird in der Abbildung gezeigt.

UML-Beispiel für Begleittext

Geschäftsereignisse finden

Wenn eine Assoziation zwischen einem Geschäftsakteur und einem Geschäftsanwendungsfall benannt ist, kann ein entsprechendes Geschäftsereignis verwendet werden, um die Einleitung des Geschäftsanwendungsfalls anzuzeigen, die für das Geschäft ein wichtiges Vorkommen ist.

Analysieren Sie die Interaktionen zwischen Mitarbeitern in Ablaufdiagrammen. Berücksichtigen Sie Folgendes für jede Nachricht, die zwischen Mitarbeitern ausgetauscht wird.

  • Standortnachrichten, die zwischen zwei Mitarbeitern an unterschiedlichen Standorten übergeben werden, sind geeignete Geschäftsereignisse (oder Kandidaten).
  • Zeitnachrichten, bei denen die Zeitdifferenz zwischen Auslösen und Empfang erheblich ist, sind geeignete Geschäftsereignisse (oder Kandidaten).
  • Zwecknachrichten, die aus Aktionen resultieren, die in Bezug auf die Aktionen, die im Geschäftsereignis ausgelöst werden, einen anderen Zweck aufweisen, sind geeignete Geschäftsereignisse (oder Kandidaten).
  • Verantwortlichkeitsnachrichten, die von einem Mitarbeiter mit anderen Zuständigkeiten abgesetzt werden, sind geeignete Geschäftsereignisse (oder Kandidaten).

Die Analyse der Grenzen von Geschäftssystemen hilft Ihnen, Unterschiede in Zweck oder Zuständigkeit zu ermitteln.

In Aktivitätsdiagrammen müssen Sie überlegen, ob eine Aktion direkt vor oder nach einer Aufgabe erforderlich ist oder ob eine Partei über das Resultat eines Entscheidungspunkts informiert werden muss.

Geschäftsentitäten geben außerdem Hinweise auf Geschäftsereignisse. Alle bedeutenden Operationen einer Geschäftsentität sind geeignete Geschäftsereignisse (oder Kandidaten). Zustandsdiagramme für Geschäftsentitäten sind sehr hilfreich. Zustandsübergänge weisen auf potenzielle Geschäftsereignisse hin, weil sie eine Änderung im Zustand des Geschäfts darstellen.

Bei der Ermittlung von Geschäftsereignissen ist es hilfreich, sich ein dokumentorientiertes Büro vorzustellen, in dem die Geschäftsentitäten Dossiers sind und die Büroangestellten die Dossiers lesen, ändern und in Posteingangs- und Postausgangskörbe legen. Sobald ein Teil eines Dossiers vollständig dupliziert werden muss, damit es an verschiedene Empfänger weitergeleitet werden kann, haben Sie wahrscheinlich ein Geschäftsereignis gefunden. Es gibt mehrere Empfänger. Wenn ein Mitarbeiter nach der Ausführung einer Aufgabe eine Notiz schreiben muss, um jemand anderen zu informieren, könnte sich auch diese Aufgabe als Geschäftsereignis qualifizieren. Natürlich liegen die Dossiers nicht den ganzen Tag auf dem Schreibtisch herum. Sie werden abgelegt. Wenn ein Dossier aus dem Aktenschrank entfernt oder ein Dossier in den Aktenschrank zurückgelegt werden muss, müssen Sie überlegen, was dazu geführt hat, dass das Dossier aus dem Aktenschrank entfernt bzw. dorthin zurückgelegt werden muss. Das Vorkommen, das diesen Vorgang auslöst, also das Entfernen oder Zurücklegen eines Dossiers, kann ein Geschäftsereignis sein.

Generalisierung von Geschäftsereignissen

Geschäftsereignisse können in "Familien" von Ereignissen kategorisiert oder gruppiert werden, indem Generalisierungsbeziehungen zwischen eher generellen und eher speziellen Geschäftsereignissen definiert werden. Damit können mehrere Typen von Geschäftsereignissen von Parteien, die nicht an den verschiedenen Einzeltypen von Geschäftsereignissen interessiert sind, auf dieselbe Weise behandelt werden.

UML-Beispiel für Begleittext

Das obige Diagramm zeigt, dass Krankheit, Fehlen und Tod eines Mitarbeiters alle spezialisierte Versionen für die Abwesenheit eines Mitarbeiters sind. Durch die Definition des Supertyps "Abwesenheit" können alle drei untergeordneten Typen als Abwesenheit behandelt werden. In einem Beratungsunternehmen muss der Kundenbetreuer möglicherweise den Kunden über die Abwesenheit eines Mitarbeiters informieren und unabhängig vom Grund der Abwesenheit für Ersatz sorgen. Der Kundenbetreuer ist deshalb nur an dem Geschäftsereignis "Abwesenheit" interessiert. Der Empfangsmitarbeiter hingegen muss unter Umständen bestimmte Maßnahmen einleiten, wenn ein Mitarbeiter krank wird, z. B. einen Arzt rufen oder Blumen verschicken. Falls ein Mitarbeiter stirbt, müssen der Leiter der Personalabteilung und der Vorgesetzte des Mitarbeiters informiert werden.

In diesem Beispiel sehen wir, dass die spezialisierten Versionen von Geschäftsereignissen hilfreich sind, wenn unterschiedliche Parteien unterschiedliche Aktionen als Reaktion auf unterschiedliche (bestimmte) Ereignisse ausführen müssen. Generalisierungen von Geschäftsereignissen sind hilfreich, wenn bestimmte Parteien auf dieselbe Weise auf bestimmte Geschäftsereignisse reagieren müssen, unabhängig von den speziellen Umständen.

Natürlich wird in der Praxis die Partei wahrscheinlich über das eigentliche (spezielle) Ereignis informiert. Wenn ein Mitarbeiter stirbt, können Sie davon ausgehen, dass auch der Kundenberater darüber informiert wird, aber die Aktion ist dieselbe. Geschäftsereignishierarchien helfen Ihnen, ein einfacheres, verständlicheres Geschäftsanalysemodell zu erstellen.

Automatisierung von Geschäftsereignissen

Es macht Sinn, die Definition, das Auslösen und die Weitergabe von Geschäftsereignissen zu automatisieren, aber dies ist nicht immer praktikabel. Manchmal ist es teurer, ein solches automatisiertes System zu erstellen, als eine E-Mail an einen Kollegen zu senden. Beim Nachdenken über die Automatisierung von Geschäftsereignissen müssen bestimmte Aspekte berücksichtigt werden:

  • die Kosten für den Kauf oder die Implementierung eines Systems, das Teile des Ereignismanagements automatisiert,
  • die technische Durchführbarkeit einer automatisierten Lösung,
  • die Kosten für nicht automatisierte Alternativen,
  • die Auswirkungen, wenn bestimmte Ereignisse nicht ausgelöst oder nicht empfangen werden,
  • die Möglichkeit, dass bestimmte Ereignisse künftig Geschäftsgrenzen überschreiten,
  • die derzeit verfügbaren Benachrichtigungskanäle.

In einer serviceorientierten Architektur werden Nachrichten verwendet, um Softwaresysteme voneinander und von physischen Standorten zu entkoppeln. Zum zeitlichen Entkoppeln von Softwaresystemen können auch asynchrone Nachrichten verwendet werden. Geschäftsereignisse werden als Nachrichten in diesen Arten von Softwaresystemen implementiert, obwohl sicherlich nicht alle Nachrichten ein zugehöriges Geschäftsereignis haben. In der Enterprise Application Integration (EAI) ist die Anwendung von Geschäftsereignissen sehr hilfreich. Hier definiert jede Anwendung eine Anzahl von Geschäftsereignissen, die von anderen Anwendungen subskribiert werden können. Auf diese Weise können Anwendungen ohne direkte Interaktion miteinander interagieren.

Stellen Sie sich beispielsweise eine Versicherungsgesellschaft vor, die ein Front-Office-System für die Verwaltung von Kundeninteraktionen, Angeboten und Verträgen hat. Für die Verwaltung von Produkten und Policen wird ein Back-Office-System verwendet. Wenn ein Kunde ein Angebot einholt, erfasst das Front-Office-System die erforderlichen Informationen über den Kunden und das versicherte Objekt. Anschließend berechnet das Produktverwaltungssystem auf der Basis dieser Informationen die Prämien und erstellt eine vorläufige Versicherungspolice, die an ein Angebot gebunden ist. Sobald der Kunde das Angebot akzeptiert, muss das Policenverwaltungssystem die Police fertig stellen. In diesem Beispiel gibt es zwei Nachrichten, die in Bezug auf die Zeit, den Standort und die Zuständigkeit voneinander entkoppelt sind - PrämienBerechnen und PoliceFertigstellen. Als Geschäftsereignis würde jedoch nur die Nachricht PoliceFertigstellen modelliert, weil sie über den aktuellen Kontext hinaus von Bedeutung ist.