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