Aufgabe: Operationsanalyse
Diese Aufgabe legt fest, wie eine Verhaltensbeschreibung auf Systemebene in eine grobe Systemstruktur umgewandelt wird.
Disziplinen: Analyse und Design
Zweck
  • Den Text des Blackbox-Ereignisablaufs für jede Systemoperation in allen für die Architektur wichtigen Anwendungsfällen in Whitebox-Schritte umwandeln. Das bezieht sich auf Aktionen und Kollaborationen des Subsystems.
  • Diese Whitebox-Beschreibungen um Entscheidungen, die sich auf Lokalitäten, Prozesse und Mitarbeiter beziehen, sowie um Anforderungen des Whitebox-Budgets erweitern.
  • Basierend auf den Whitebox-Schritten Interaktionen zwischen Subsystemen in Ablauf- und Kollaborationsdiagrammen (im Analysemodell) erstellen.
Beziehungen
Hauptbeschreibung
In dieser Aufgabe beginnt der Designer, eine Verhaltensbeschreibung auf Systemebene in eine grobe Systemstruktur (und zugeordnete Interaktionen) und ein entsprechendes Verhalten auf Subsystemebene umzuwandeln.
Schritte
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). 

Erste Erweiterung des Whitebox-Schritts

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.

Weitere Informationen