Blackbox-Test zu Whitebox-Schritten für das Subsystem ausarbeiten
In diesem Schritt nehmen Sie das Anwendungsfallmodell und arbeiten den Text des Blackbox-Ereignisablaufs (der Eigentum
der einzelnen Anwendungsfälle ist) zu Whitebox-Schrittsequenzen aus (in Form von Aktionen und Interaktionen von
Subsystemen, wobei die Subsysteme und skizzierten Kollaborationen der Systemarchitekturanalyse 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.
Wenn z. B. eine tabellarische Beschreibung in der Tabelle "Beispiel für Blackbox-Ereignisablauf" verwendet wird, stellt
sich die Situation wie folgt dar:
Systemanwendungsfall <Name>
|
Schritt
|
Akteuraktion
|
Beschreibung des Blackbox-Schritts
|
Geplante Blackbox-Anforderungen
|
Systemoperation
|
1
|
(ID
der Akteuraktion): Beschreibung der Aktion, die der Akteur ausführt, z. B. "AA1: Dieser
Anwendungsfall beginnt, wenn der Sachbearbeiter die Schaltfläche für neuen Verkauf
betätigt"
|
(ID
des Blackbox-Schritts): Beschreibung der Systemantwort (ohne Offenlegung der internen
Systemstruktur), z. B. "BBS1: Das System ruft für Sachbearbeiter und Kunden bestimmte Anzeigen für
neuen Verkauf auf und aktiviert den Scanner"
|
(Anforderungs-ID
für Blackbox-Schritt): Beschreibt, wie gut das System diesen Schritt ausführen muss, etwa
hinsichtlich Reaktionszeit bzw. -geschwindigkeit, z. B. "SUP36.2: Gesamte Antwortzeit beträgt 0,5
Sekunden"
|
(ID
der Systemoperation): Name der Systemoperation, die für diesen Schritt aufgerufen wird, z. B.
"<<Operation>> Neuen Verkauf beginnen" (im Kontextdiagramm laut Definition in Aufgabe: Systemkontext definieren)
|
2
|
|
|
|
|
3
|
|
|
|
|
Beispiel für Blackbox-Ereignisablauf
Wird die Aufgabe für ein Subsystem ausgeführt, für das nur die Operationen definiert wurden, stellt sich die Situation
wie folgt dar:
Dann wird eine Systemoperation (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 Systemoperation gesteuert wird, d. h., behandeln Sie den nächsten Realisierungsschritt als Realisierung aller
Systemoperationen (im Gegensatz zum abstrakteren Begriff des Blackbox-Schritts des Systemanwendungsfalls).
Die Whitebox-Schritte für die einzelnen Systemoperationen (grauer Hintergrund in der folgenden Tabelle) werden
anfänglich im Analysemodell erfasst und der entsprechenden Systemoperation als ihrer Realisierung zugeordnet. Sie
werden nicht mit dem Systemanwendungsfall gespeichert (hier nur zur Veranschaulichung so dargestellt), können jedoch
vom Systemanwendungsfall über die Systemoperation zurückverfolgt werden.
Systemanwendungsfall <Name>
|
Systemoperation
|
Schritt
|
Akteuraktion
|
Beschreibung des Blackbox-Schritts
|
Geplante Anforderungen des Blackbox-Schritts
|
Beschreibung des Whitebox-Schritts für das Subsystem
|
Geplante Anforderungen des Whitebox-Schritts
|
Lokalität
|
Prozess
|
Mitarbeiter
|
(ID der Systemoperation): Name der Systemoperation, die die für
diesen Schritt aufgerufen wird, z. B. "<<Systemoperation>> Neuen Verkauf beginnen" (im
Kontextdiagramm)
|
1
|
(ID der Akteuraktion): Beschreibung der Aktion, die der Akteur
ausführt, z. B. "AA1: Dieser Anwendungsfall beginnt, wenn der Sachbearbeiter die Schaltfläche
für neuen Verkauf betätigt"
|
(ID des Blackbox-Schritts): Beschreibung der Systemantwort (ohne
Offenlegung der internen Systemstruktur), z. B. "BBS1: Das System ruft für Sachbearbeiter und Kunden
bestimmte Anzeigen für neuen Verkauf auf und aktiviert den Scanner"
|
(Anforderungs-ID für Blackbox-Schritt): Beschreibt, wie gut das
System diesen Schritt ausführen muss, etwa hinsichtlich Reaktionszeit bzw. -geschwindigkeit, z. B.
"SUP36.2: Gesamte Antwortzeit beträgt 0,5 Sekunden"
|
(ID des Whitebox-Schritts): Beschreibung einer von einem Subsystem
ausgeführten Aktion (Blackbox-Schritt wird teilweise ausgeführt) in Form von Eingabe, Verarbeitung,
Ausgabe, z. B. "WBS1: Die Point-of-Sale-Schnittstelle löscht die Transaktion, ruft Anzeigen für
neuen Verkauf auf und fordert die Erstellung einer Verkaufsliste durch die Auftragsbearbeitung
an"
|
|
|
|
|
(ID des Whitebox-Schritts): ...
|
|
|
|
|
|
|
|
|
|
|
2
|
|
|
|
|
|
|
|
|
|
3
|
|
|
|
|
|
|
|
|
Beispiel für Whitebox-Ereignisablauf
|
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 Systemdesigner wird erneut durch die Arbeit des Systemarchitekten 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 Systemoperation 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 Systemarchitekten berücksichtigt werden.
Systemanwendungsfall <Name>
|
Systemoperation
|
Schritt
|
Akteuraktion
|
Beschreibung des Blackbox-Schritts
|
Geplante Anforderungen des Blackbox-Schritts
|
Beschreibung des Whitebox-Schritts für das Subsystem
|
Geplante Anforderungen des Whitebox-Schritts
|
Lokalität
|
Prozess
|
Mitarbeiter
|
(ID der Systemoperation): Name der Systemoperation, die die für
diesen Schritt aufgerufen wird, z. B. "<<Systemoperation>> Neuen Verkauf beginnen" (im
Kontextdiagramm)
|
1
|
(ID der Akteuraktion): Beschreibung der Aktion, die der Akteur
ausführt, z. B. "AA1: Dieser Anwendungsfall beginnt, wenn der Sachbearbeiter die Schaltfläche
für neuen Verkauf betätigt"
|
(ID des Blackbox-Schritts): Beschreibung der Systemantwort (ohne
Offenlegung der internen Systemstruktur), z. B. "BBS1: Das System ruft für Sachbearbeiter und Kunden
bestimmte Anzeigen für neuen Verkauf auf und aktiviert den Scanner"
|
(Anforderungs-ID für Blackbox-Schritt): Beschreibt, wie gut das
System diesen Schritt ausführen muss, etwa hinsichtlich Reaktionszeit bzw. -geschwindigkeit, z. B.
"SUP36.2: Gesamte Antwortzeit beträgt 0,5 Sekunden"
|
(ID des Whitebox-Schritts): Beschreibung einer von einem Subsystem
ausgeführten Aktion (Teils des Blackbox-Schritts wird ausgeführt) in Form von Eingabe, Verarbeitung,
Ausgabe, z. B. "WBS1: Die Point-of-Sale-Schnittstelle löscht die Transaktion, ruft Anzeigen für
neuen Verkauf auf und fordert die Erstellung einer Verkaufsliste durch die Auftragsbearbeitung
an"
|
|
Lokalitäts-ID
|
Prozess-ID
|
ID der Organisation oder des Systemmitarbeiters
|
(ID des Whitebox-Schritts): ...
|
|
|
|
|
|
|
|
|
|
|
2
|
|
|
|
|
|
|
|
|
|
3
|
|
|
|
|
|
|
|
|
Beispiel für erweiterten Whitebox-Ereignisablauf
|
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).
Systemanwendungsfall <Name>
|
Systemoperation
|
Schritt
|
Akteuraktion
|
Beschreibung des Blackbox-Schritts
|
Geplante Anforderungen des Blackbox-Schritts
|
Beschreibung des Whitebox-Schritts für das Subsystem
|
Geplante Anforderungen des Whitebox-Schritts
|
Lokalität
|
Prozess
|
Mitarbeiter
|
(ID der Systemoperation): Name der Systemoperation, die die für
diesen Schritt aufgerufen wird, z. B. "<<Systemoperation>> Neuen Verkauf beginnen" (im
Kontextdiagramm)
|
1
|
(ID der Akteuraktion): Beschreibung der Aktion, die der Akteur
ausführt, z. B. "AA1: Dieser Anwendungsfall beginnt, wenn der Sachbearbeiter die Schaltfläche
für neuen Verkauf betätigt"
|
(ID des Blackbox-Schritts): Beschreibung der Systemantwort (ohne
Offenlegung der internen Systemstruktur), z. B. "BBS1: Das System ruft für Sachbearbeiter und Kunden
bestimmte Anzeigen für neuen Verkauf auf und aktiviert den Scanner"
|
(Anforderungs-ID für Blackbox-Schritt): Beschreibt, wie gut das
System diesen Schritt ausführen muss, etwa hinsichtlich Reaktionszeit bzw. -geschwindigkeit, z. B.
"SUP36.2: Gesamte Antwortzeit beträgt 0,5 Sekunden"
|
(ID des Whitebox-Schritts): Beschreibung einer von einem Subsystem
ausgeführten Aktion (Teils des Blackbox-Schritts wird ausgeführt) in Form von Eingabe, Verarbeitung,
Ausgabe, z. B. "WBS1: Die Point-of-Sale-Schnittstelle löscht die Transaktion, ruft Anzeigen für
neuen Verkauf auf und fordert die Erstellung einer Verkaufsliste durch die Auftragsbearbeitung
an"
|
(Anforderungs-ID für Whitebox-Schritt): Beschreibt, wie gut das
System diesen Schritt ausführen muss, etwa hinsichtlich Reaktionszeit bzw. -geschwindigkeit, z. B.
"SUP36.2.1: Abgelaufene Zeit beträgt 0,16 Sekunden"
|
Lokalitäts-ID (in Lokalitätsmodell)
|
Prozess-ID (in Prozessmodell)
|
ID der Organisation oder des Systemmitarbeiters
|
(ID des Whitebox-Schritts): ...
|
(Anforderungs-ID des Whitebox-Schritts): ...
|
Lokalitäts-ID
|
Prozess-ID
|
ID der Organisation oder des Systemmitarbeiters
|
|
|
|
|
|
|
2
|
|
|
|
|
|
|
|
|
|
3
|
|
|
|
|
|
|
|
|
Beispiel für geplante Anforderungen des zugeordneten Whitebox-Ereignisablaufs
|
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
Subsystem denselben Stellenwert haben wie Systemoperationen für das System) vorzubereiten, und zwar durch die
Untersuchung der Beschreibungen der Whitebox-Schritte für das Subsystem. Wie bei der Identifikation von
Systemoperationen besteht die Möglichkeit, dass nicht für jeden Whitebox-Schritt eine eindeutige
Subsystemoperation vorhanden ist. Beachten Sie ebenfalls, dass die Whitebox-Schritte nach Systemoperation gruppiert
werden. Das kann z. B. auch in tabellarischer Form geschehen, mit einer Gruppierung nach Subsystem:
Beispiel für eine Anwendungsfallübersicht des Subsystems
Subsystem <Name>
|
Systemoperation
|
Lokalität
|
Prozess
|
Mitarbeiter
|
Beschreibung des Whitebox-Schritts für das Subsystem
|
Subsystemoperation
|
<Name>
|
Lokalitäts-ID
|
Prozess-ID
|
ID der Organisation oder des Systemmitarbeiters
|
(ID des Whitebox-Schritts): Beschreibung einer von einem
Subsystem ausgeführten Aktion (Blackbox-Schritt wird teilweise ausgeführt) in Form von
Eingabe, Verarbeitung, Ausgabe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Beispiel für Anwendungsfallübersicht für Operation
Im Falle eines "Systems von Systemen", bei dem für jedes System/Subsystem ein Anwendungsfallmodell verwaltet wird, ist
diese Gruppierung eine strikter Leitfaden für die Identifikation von Anwendungsfällen für Subsysteme: Sie können für
jede System- bzw. Subsystemoperation, an der das Subsystem beteiligt ist, einen Anwendungsfall identifizieren.
Vielleicht stellen Sie fest, dass die Whitebox-Schrittsequenzen für einige dieser Anwendungsfälle identisch sind und
zusammengefasst werden können. In diesem Fall kann ein einziger Anwendungsfall für das Subsystem erstellt werden, um
die Anforderungen der verschiedenen Systemoperationen zu erfüllen.
|
Entworfene Kollaborationen für einzelne Systemoperationen verfeinern
Basierend auf den Whitebox-Schritten werden Interaktionen zwischen Subsystemen in Ablauf- und Kollaborationsdiagrammen
(im Analysemodell) erstellt. Damit wird die Arbeit, die zuvor durch den Systemarchitekten 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 Systemdesigner 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.
|
|