Richtlinie: Geschäftsentität
Geschäftsentitäten stellen "Dinge" dar, die von den Mitarbeitern während der Ausführung eines Geschäftsanwendungsfalls bearbeitet oder verwendet werden. Diese Richtlinie zeigt, wie Geschäftsentitäten modelliert werden.
Beziehungen
Hauptbeschreibung

Erläuterung

Geschäftsentitäten stellen "Dinge" dar, die von den Mitarbeitern während der Ausführung eines Geschäftsanwendungsfalls bearbeitet oder verwendet werden. Eine Geschäftsentität stellt häufig etwas dar, das für mehrere Geschäftsanwendungsfälle oder Anwendungsfallinstanzen einen Wert darstellt. Deshalb ist das Geschäftsentitätsobjekt eher langlebig. Im Allgemeinen empfiehlt es sich, wenn die Geschäftsentität keine Informationen darüber enthält, wie und von wem sie verwendet wird.

Gewöhnlich stellt eine Geschäftsentität ein Dokument oder einen wichtigen Teil eines Produkts dar, manchmal aber auch etwas weniger Konkretes, wie z. B. wichtige Kenntnisse über einen Markt oder einen Kunden. Beispiele für Geschäftsentitäten in einem Restaurant sind Menü und Getränke. Am Flughafen sind Ticket und Bordkarte wichtige Geschäftsentitäten.

In der Geschäftsmodellierung stufen wir Geschäftsentitäten als bedeutende (und persistente) Informationen ein und stellen Sie deshalb in der Artefaktbeschreibung dar. Im Allgemeinen können die "Dinge", die von Mitarbeitern bearbeitet oder verwendet werden, jedoch physische Objekte sein. Wenn ein Mitarbeiter durch ein komplexes physisches System mit Materialflüssen realisiert wird, die die Grenzen dieses Systems überschreiten, kann es hilfreich sein, die Informationsgegenstücke zu diesen Gegenständen durch Geschäftsentitäten darzustellen, über die die Mitarbeiter ihre Aktionen an den Rest des Geschäfts kommunizieren. Wenn Sie den Mitarbeiter als eigenständigen System betrachten, können Sie die physischen Aspekte für den Mitarbeiter dann getrennt vom Geschäftsmodellierungskontext behandeln.

Sie müssen nur die Phänomene als Geschäftsentitäten modellieren, auf die andere Klassen im Geschäftsbereichsmodell verweisen. Andere "Dinge" können als Attribute der relevanten Klassen modelliert oder lediglich in Textform in diesen Klassen beschrieben werden.

Attribute

Ein Attribut einer Klasse stellt eine Einzelinformation über ein Objekt dieser Klasse dar, die mit dem Objekt abgelegt wird. Ein Attribut hat einen Attributtyp. Jedes Attribut und jeder Attributtyp hat einen Namen.

Ein Objekt enthält normalerweise unterschiedliche Einzelinformationen, die einige seiner Merkmale beschreiben. Solche Einzelinformationen können implizit in der Beschreibung der Objektklasse beschrieben oder explizit als Attribut der Klasse modelliert werden.

Ein Attribut hat einen bestimmten Typ. Ein Attribut hat einen Namen, vorzugsweise ein Substantiv, das die Rolle des Attributs in Bezug auf die Klasse beschreibt. Ein Attributtyp kann mehr oder weniger primitiv sein, z. B. eine einfache Zahl oder eine Zeichenfolge. Unterschiedliche Klassen können Attribute mit identischen Strukturen haben. Diese Attribute sollten eine gemeinsame Beschreibung haben, d. h. denselben Attributtyp.

Anmerkung: Sie sollten Attribute nur modellieren, um eine Klasse verständlicher zu machen!

Attribute oder Entitäten verwenden

Gelegentlich ist es schwierig zu entscheiden, ob ein Konzept besser als Attribut einer Klasse oder als separate Geschäftsentitätsklasse beschrieben werden sollte. Es gilt folgende Regel: Modellieren Sie ein Phänomen als Attribut, wenn nur ein Objekt direkten Zugriff darauf haben muss oder der Zugriff über das Objekt der einzige natürliche Weg ist. Andernfalls modellieren Sie das Konzept separat in einer eigenen Klasse.

Im Begleittext beschriebenes Diagramm

Im Check-in-Anwendungsfall für den Flughafen sind Tickets wichtig. Auf jedem Ticket stehen ein Passagiername und ein Flug. Hier werden die Attribute Name und Flug identifiziert. Das Attribut Flug ist komplexer, weil es sich aus der Fluggesellschaft, dem Zielort, der Abflugzeit und der Ankunftszeit zusammensetzt.

Im Begleittext beschriebenes Diagramm

Alle Passagiere, in demselben Flugzeug reisen, haben denselben Flug. Die Fluggesellschaft ist für mehrere Flüge dieselbe. Eine bessere Alternative ist deshalb, Flug und Fluggesellschaft als Klassen zu modellieren.

Nachdem Sie entschieden haben, ob ein Konzept so wichtig für den Anwendungsfall ist, dass es modelliert werden muss, bestimmt nicht seine Bedeutung im echten Leben, ob es als separate Klasse oder lediglich als Klassenattribut modelliert werden sollte. Der entscheidende Faktor ist hier die Bedarfssituation für den Zugriff, d. h. einige Konzepte werden für unterschiedliche Geschäfte unterschiedlich modelliert.

Stellen Sie sich das folgende Beispiel vor: Für die Angestellten in einem Anwendungsfall Verkehrsplanung an einem Flughafen sind Flüge von zentraler Bedeutung. Für jeden Flug müssen Abflugzeit, Fluggesellschaft und Zielort definiert werden. In diesem Fall müssen Sie eine Klasse Flug verwenden und dieser die Attribut Abflugzeit, Fluggesellschaft und Zielort zuweisen.

Im Begleittext beschriebenes Diagramm

Flüge sind für wesentlich für die Angestellten, in in einem Geschäftsanwendungsfall Verkehrsplanung an einem Flughafen arbeiten.

Für die Angestellten eines Reisebüros stellt sich die Situation anders dar. Auch sie benötigen Abflugzeit, Fluggesellschaft und Zielort, aber sie haben darüber hinaus weitere Anforderungen. Was für ein Reisebüro am wichtigsten ist, ist, einen Flug mit einem bestimmten Zielort zu finden. In diesem Fall bietet es sich an, eine separate Klasse für Zielort zu erstellen. Die Klassen Flug und Zielort müssen einander natürlich kennen. Dies ist durch eine bidirektionale Assoziation möglich.

Im Begleittext beschriebenes Diagramm

Abflugzeiten und Zielorte von Flügen sind für Angestellte in einem Anwendungsfall Reisebüro gleichmaßen von Bedeutung.

Theoretisch kann alles als Klasse modelliert werden. Eine durchdachte Verwendung von Attributen reduziert jedoch die Anzahl der Klassen, die verwaltet werden müssen, und erleichtert das Verständnis des Objektmodells.

Operationen

Zur Erfüllung der Zuständigkeiten eines Mitarbeiters muss die Person, die als Mitarbeiter auftritt, Tools zur Bearbeitung der Geschäftsentitäten verwenden. Sie können diese Tools mit Operationen und Nachrichten, die die verwendeten Tools und die vorgenommenen Zugriffe darstellen, generell oder explizit definieren. Eine Operation definiert das Tool, mit dem eine Geschäftsentität bearbeitet wird. Der Zugriff wird durch eine Nachricht eingeleitet. Ein Tool, das zur Bearbeitung eines Geschäftsentitätsobjekts verwendet werden kann, wird als Operation der Geschäftsentitätsklasse mit einem Namen und optional mit Parametern dargestellt. Der Zugriff einer Geschäftsentitätseinheit wird als Nachricht dargestellt, die an das Geschäftsentitätsobjekt gesendet wird.

Eine Operation "Gepäck zuordnen" der Geschäftsentität "Ticket" umfasst beispielsweise das Anheften von Gepäckaufklebern an das Ticket. Die Parameter sind die Paketaufkleber.

Jede Operation wird mit einem Namen, der Aufschluss über den Zweck der Operation geben sollte, und optional einer Anzahl von Parametern definiert. Die Parameter geben an, was ein Objekt der Klasse von einem Objekt erwarten sollte, das Unterstützung anfordert oder einen Zugriff vornimmt, und was das Objekt bereitstellt, wenn die Operation ausgeführt wurde. Sie können beispielsweise Parameter angeben, die angeben, wann ein Mitarbeiter einen Schritt in der Mitarbeiteroperation ausführen sollte oder wann dieser Mitarbeiter durch Einleiten einer der Operationen einer Geschäftsentität auf eine bestimmte Geschäftsentität zugreifen sollte. Parameter können auch mehr oder wenige konkrete Dinge darstellen, die übergeben werden.

Operationen können je nach Bedeutung oder erforderlichem Detaillierungsgrad in einem Anwendungsfall informell oder detailliert definiert werden. Eine "detailliertere" Beschreibung könnte eine Verhaltensfolge beschreiben, die angibt, welche Attribute und Beziehungen während der Ausführung des Anwendungsfalls betroffen sind, wie eine Verbindung zu anderen Objekten anderer Klassen aufgenommen wird und wie ein Anwendungsfall beendet wird.

Merkmale einer tauglichen Geschäftsentität

  • Name und Beschreibung sind klar und verständlich.
  • Beziehungen der Geschäftsentität sind nicht voneinander abhängig.
  • Jede Beziehung wird im Workflow mindestens eines Geschäftsanwendungsfalls verwendet.
  • Alle "Dinge" im Geschäft, z. B. Produkte, Dokumente, Verträge usw. werden als Geschäftsentitäten modelliert.
  • Sie ist an mindestens einem Geschäftsanwendungsfall beteiligt.
  • Sie hat einen Eigner, d. h. einen Mitarbeiter oder Geschäftsakteur, der für die Geschäftsentität verantwortlich ist.

Geschäftsereignisse

Geschäftsereignisse können verwendet werden, um interessierte Parteien (einschließlich anderer Geschäftsentitäten) über eine Änderungen im Zustand der Geschäftsentität zu benachrichtigen. Das Erstellen und Löschen einer Geschäftsentität können von Bedeutung sein. Wenn Sie eine Zustandsmaschine definiert haben, untersuchen Sie die Zustände der Geschäftsentität. Jeder Übergang ist ein potenzielles Geschäftsereignis. Überprüfen Sie auch die Attribute und Operationen der Geschäftsentität. Bedeutenden Operationen, die nur gelegentlich verwendet werden, kann ein Geschäftsereignis zugeordnet werden. Änderungen an wichtigen Attributen können ein Ereignis auslösen. Geschäftsprozessmuster und Geschäftsentitätsmuster können ebenfalls einen Einblick in hilfreiche Geschäftsereignisse geben. Wenn eine Geschäftsentität beispielsweise genehmigt werden muss, bevor sie weiter verwendet wird, kann ein Geschäftsereignis <etwas> Genehmigt hilfreich sein, um andere Parteien darüber zu informieren, dass das Geschäftsereignis verwendet werden kann. Weitere Informationen zum Finden von Geschäftsereignissen finden Sie auf der Seite Richtlinie: Geschäftsereignis.