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