Aufgabe: Geschäftsoperationsanalyse
Diese Aufgabe legt fest, wie eine Verhaltensbeschreibung auf Geschäftssystemebene in eine grobe Systemstruktur umgewandelt wird.
Zweck
  • Den Text des Blackbox-Ereignisablaufs für jede Geschäftsoperation in allen für die Architektur wichtigen Geschäftsanwendungsfällen in Whitebox-Schritte umwandeln. Das bezieht sich auf Aktionen und Kollaborationen des Subsystems.
  • Diese Whitebox-Beschreibungen mit Entscheidungen, die sich auf die relevanten Architektursichten beziehen, und geplanten Whitebox-Anforderungen erweitern.
  • Basierend auf den Whitebox-Schritten Interaktionen zwischen Subsystemen in Ablauf- und Kollaborationsdiagrammen (im Geschäftsanalysemodell) erstellen.
Beziehungen
Hauptbeschreibung
In dieser Aufgabe beginnt der Geschäftsdesigner, eine Verhaltensbeschreibung auf Geschäftssystemebene in eine grobe Systemstruktur (und zugeordnete Interaktionen) und ein entsprechendes Verhalten auf Geschäftssubsystemebene umzuwandeln.
Schritte
Blackbox-Test zu Whitebox-Schritten für das Subsystem ausarbeiten

In diesem Schritt nehmen Sie das Geschäftsanwendungsfallmodell und arbeiten den Text des Blackbox-Ereignisablaufs (der Eigentum der einzelnen Geschäftsanwendungsfälle ist) zu Whitebox-Schrittsequenzen aus (in Form von Aktionen und Interaktionen von Subsystemen, wobei die Subsysteme und skizzierten Kollaborationen der Geschäftsarchitekturanalyse entnommen werden). Wenn diese Aufgabe für ein Subsystem ausgeführt wird, für das die Operationen bereits angegeben wurden, dann sind die Operationen der Ausgangspunkt, und Sie können direkt mit dem Schritt Erste Erweiterung des Whitebox-Schritts fortfahren.

Dann wird eine Geschäftssystemoperation (Blackbox-Schritt) zu einem oder mehreren Whitebox-Schritten erweitert, die jeweils von einem benannten Subsystem ausgeführt werden. Dabei wird der Designer geleitet von der Arbeit, die der Architekt (während der Architekturanalyse) bei der Auswahl von Subsystemen und Interaktionen, die zur Beschreibung der Whitebox-Schritte verwendet werden, geleistet hat. Beachten Sie, dass die Analyse, wenn sie jetzt fortgesetzt wird, von der Geschäftssystemoperation gesteuert wird, d. h., behandeln Sie den nächsten Realisierungsschritt als Realisierung aller Geschäftssystemoperationen (im Gegensatz zum abstrakteren Begriff des Blackbox-Schritts des Geschäftsanwendungsfalls). 

Erste Erweiterung des Whitebox-Schritts

Die Whitebox-Schritte für die einzelnen Geschäftssystemoperationen (grauer Hintergrund in der folgenden Tabelle) werden anfänglich im Geschäftsanalysemodell erfasst und der entsprechenden Geschäftssystemoperation als ihrer Realisierung zugeordnet. Sie werden nicht mit dem Geschäftsanwendungsfall gespeichert (hier nur zur Veranschaulichung so dargestellt), können jedoch vom Geschäftsanwendungsfall über die Geschäftssystemoperation zurückverfolgt werden.

Whitebox-Schritte um Entscheidungen, die sich auf Lokalitäten, Prozesse und Mitarbeiter beziehen, erweitern

Diese Beschreibung wird dann um Entscheidungen, die sich auf Lokalitäten, Prozesse und Mitarbeiter beziehen, erweitert. Die Entscheidung hinsichtlich der Lokalität bestimmt mit einem gewissen Spielraum (je nach Abstraktionsebene der Lokalität), wo der Whitebox-Schritt für das Subsystem ausgeführt wird. Die Prozessentscheidung ist nur notwendig, wenn entschieden wird, dass (zumindest für diesen Schritt) das Subsystem "passiv" ist, d. h., dass seine Operationen von subsystemexternen Prozessen aufgerufen werden. Ein "aktives" Subsystem kann autonom antworten und dabei subsysteminterne Prozesse verwenden. Der Geschäftsdesigner wird erneut durch die Arbeit des Geschäftsarchitekten geleitet (beim Erstellen des Lokalitäts- und des Prozessmodells). Bei Entscheidungen, die sich auf Mitarbeiter beziehen, d. h. wenn Sie Personal zuordnen möchten, beginnen Sie, die organisatorischen Entitäten und dann die Ressourcen der Systemarbeiter, die für eine Geschäftssystemoperation benötigt werden, zu identifizieren.

Wenn die Analyse zeigt, dass ein Whitebox-Schritt mehr als eine Lokalität (oder einen Prozess) erfordert, dann müssen Sie ihn in kleinere Schritte unterteilen, die alle einer einzigen Lokalität (und einem Prozess, falls zutreffend) zugeordnet werden können. Diese Unterteilung kann wichtige Auswirkungen auf die Architektur haben (möglicherweise muss das Subsystem ausgelagert werden), daher muss die Meinung des Teams bzw. des Geschäftsarchitekten berücksichtigt werden.

Geplante Anforderungen des Whitebox-Schritts zuordnen
Als Nächstes müssen Sie geplante Anforderungen des Blackbox-Schritts zu Whitebox-Schritten zuordnen. Diese Zuordnung hilft, die Leistungsanforderungen für das Subsystem und die zugeordnete Lokalität zu bestimmen. Im Falle eines passiven Subsystems gilt das als Eingabe für die Latenzanalyse des aufrufenden Prozesses (der möglicherweise andere Zuständigkeiten hat).
Whitebox-Schritte nach Subsystem ordnen

In diesem Schritt erfassen Sie alle Whitebox-Schritte für die einzelnen Subsysteme (d. h. die Whitebox-Schritte, die zu diesem Subsystem gehören). Dies geschieht, um die Identifikation von Subsystemoperationen (die für das Geschäftssubsystem denselben Stellenwert haben wie Geschäftssystemoperationen für das System) vorzubereiten, und zwar durch die Untersuchung der Beschreibungen der Whitebox-Schritte für das Subsystem. Wie bei der Identifikation von Geschäftssystemoperationen besteht die Möglichkeit, dass nicht für jeden Whitebox-Schritt eine eindeutige Subsystemoperation vorhanden ist. Beachten Sie ebenfalls, dass die Whitebox-Schritte nach Geschäftssystemoperation gruppiert werden. Das kann z. B. auch in tabellarischer Form geschehen, mit einer Gruppierung nach Subsystem:

Entworfene Kollaborationen für einzelne Systemoperationen verfeinern

Basierend auf Whitebox-Schritten werden Interaktionen zwischen Subsystemen in Ablauf- und Kollaborationsdiagrammen (im Geschäftsanalysemodell) erstellt. Damit wird die Arbeit, die zuvor durch den Geschäftsarchitekten geleistet wurde, verfeinert. An diesem Punkt können die Kollaborationen noch abstrakt sein, möglicherweise werden nur Links oder Nachrichten auf einer abstrakten Ebene identifiziert. Diese Arbeit bietet jedoch einen Einblick in die Kopplung und Kohäsion der Subsysteme. Damit wird die zuvor durchgeführte Erweiterung der Whitebox-Schritte verfeinert (siehe Erste Erweiterung des Whitebox-Schritts).

Analyse auswerten
Der Geschäftsdesigner muss beim Abschluss dieser Aufgabe eine informelle Überprüfung veranlassen und somit sicherstellen, dass alle auftretenden Probleme aufgezeichnet und für die Lösung eingeplant werden.
Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen