Aufgabe: Operationsdesign
Diese Aufgabe verfeinert die Ergebnisse der Operationsanalyse zu detaillierten Operationsrealisierungen.
Zweck
  • Die vorläufigen Interaktionen zwischen Subsystemen zu Operationsrealisierungen im Designmodell verfeinern.
  • Die Subsystemoperationen verfeinern und angeben.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional:
  • Ohne
Extern:
  • Ohne
Ausgaben
Schritte
Operationsrealisierungen erstellen

Mit der Aufgabe Operationsanalyse hat der Designer Interaktionen zwischen Subsystemen (ohne viele Details) im Analysemodell erstellt. Denken Sie daran, dass Sie diese Interaktionen nach Systemoperationen gruppiert haben, d. h., Sie haben die Interaktionen erfasst, die die einzelnen Systemoperationen realisieren. Jetzt, da Sie mit den erweiterten Beschreibungen der Systemanwendungsfälle (Whitebox) arbeiten, werden die Nachrichtendetails, die ausgetauschten Entitäten, die Reihenfolgeplanung, der Steuerfluss und die zugeordneten Daten im Designmodell hinzugefügt und die Operationsrealisierungen erfasst, die Organisation erfolgt erneut über die Systemoperationen. Wenn dieses Detail hinzugefügt wird, bewertet der Designer die Qualität der entstehenden Kollaborationen und sucht nach Gelegenheiten, ein Refactoring für das Design auszuführen. Versehen Sie die Operationsrealisierungen während der Verarbeitung einer Nachricht mit Beschreibungen der Aktivitäten des Subsystems (entnehmen Sie sie der Beschreibung des Whitebox-Schritts und verfeinern Sie sie, falls erforderlich). Diese Beschreibungen helfen beim nächsten Schritt, Spezifikationen für die einzelnen Subsystemoperationen zu entwickeln.

Ähnliche Whitebox-Schritte des Subsystems zusammenfassen und Subsystemoperationen angeben

Der Designer hat den anfänglichen Platzhalter für Übersicht über die Subsystemoperationen während er Aufgabe "Operationsanalyse" erstellt. Die Übersichtstabelle zeigt auch (mit grauem Hintergrund) die Rückverfolgbarkeit zu den Blackbox-Schritten des Systemanwendungsfalls. Dabei wird in der Tabelle angezeigt, dass die Blackbox-Schritte <ID 1> und <ID 2> für den Systemanwendungsfall beide durch Aufrufe von <Name der Systemoperation 1> ausgeführt wurden.

<Name> des Subsystems
Systemoperation ID des Blackbox-Schritts für Systemanwendungsfall Lokalität Prozess Mitarbeiter Beschreibung des Whitebox-Schritts für das Subsystem Subsystemoperation

<Name der Systemoperation 1>

<ID 1> Lokalitäts-ID Prozess-ID ID der Organisation oder des Systemmitarbeiters (ID des Whitebox-Schritts): Beschreibung einer von einem Subsystem ausgeführten Aktion (Teil des Blackbox-Schritts wird ausgeführt) in Form von Eingabe, Verarbeitung, Ausgabe (ID der Subsystemoperation): Name der Subsystemoperation, die für diesen Schritt aufgerufen wird, z. B. «Subsystemoperation» "Verkaufsliste erstellen" (für Auftragsbearbeitung des Subsystems)
... ...   (ID des Whitebox-Schritts): ...  
... ...   ...  
<ID 2> ... ...   ...  
<Name der Systemoperation 2> <ID 3> ... ...   ...  
<ID 4> ... ...   ...  
... ... ... ...   ...  

Beispiel für eine Operationsübersicht des Subsystems

Als Nächstes werden die Subsystemoperationen über die Whitebox-Schritte und Operationsrealisierungen identifiziert und ihr Verhalten wird angegeben. Wie bei der Identifikation der Systemoperationen ist möglicherweise nicht jedem Whitebox-Schritt eine eindeutige Subsystemoperation zugeordnet. Das bedeutet, wenn Sie die Gruppe der Whitebox-Schritte und deren zugeordneten Nachrichtenaustausch, die Ein-/Ausgabeentitäten usw. untersuchen, werden Sie vielleicht feststellen, dass Sie die Möglichkeit haben, kleinere Gruppen von Subsystemoperationen zu definieren, um deren Anforderungen zu erfüllen.

Beachten Sie, dass die Übersichtstabelle auch nach Lokalitäten oder Prozessen geordnet werden kann. Sie zeigt dann an, wie die Gruppe der Subsystemoperationen den einzelnen Lokalitäten oder Prozessen zugeordnet ist. Der Sortierung nach Lokalitäten zeigt die Verarbeitungslast an einer Lokalität an. Das ist nützlich, wenn die Kapazität der physischen Komponenten, die die Lokalität unterstützen, geprüft wird. In dieser Form wird die nach Lokalitäten sortierte Übersicht zu einem Merkmal des Deployment-Modells.

Wenn eine Subsystemoperation an mehreren Lokalitäten ausgeführt wird, ist das ein Hinweis darauf, dass zumindest ein Teil des Subsystems repliziert wird. Diese replizierten Abschnitte müssen nicht notwendigerweise Daten gemeinsam nutzen oder synchron gehalten werden. Diese Designoptionen sind von der Anwendung und vom Grund für die Replikation abhängig. Beispielsweise kann die erforderliche Verarbeitung identisch sein, sich jedoch auf ein anderes Geschäftssegment beziehen. Im Extremfall können alle Subsystemoperationen an mehreren Lokalitäten ausgeführt werden, d. h. effektiv, dass das Subsystem selbst repliziert wird. Die Notwendigkeit, replizierte Instanzen eindeutig zu identifizieren, ist auch vom Grund für die Replikation abhängig.

Die Sortierung nach Prozessen erlaubt dem Designer, Überlegungen zu Fragen hinsichtlich des gemeinsamen Zugriffs anzustellen: Wenn Sie eine Subsystemoperation als diskretes, für Akteure verfügbares Funktionselement anzeigen möchten, dann können Operationen, die demselben Prozess zugeordnet sind, nicht parallel ausgeführt werden. Das kann den Designer veranlassen, die Prozesszuordnung zu überdenken, die Prozessreplikation in Erwägung zu ziehen oder das erkannte Latenzproblem auf einer niedrigeren Detaillierungsebene zu untersuchen, z. B., indem er Zeitscheibenverfahren einsetzt oder gemeinsam genutzte Prozesse verwendet, wenn eine Operation blockiert wird (z. B. bei Eingabe und Ausgabe). Diese Techniken bieten möglicherweise eine akzeptable Flexibilität, wohingegen die Verzögerung eines Operationsbeginns (mit strikter Serialisierung der Operationen) inakzeptabel sein kann. In dieser Form wird die nach Prozessen sortierte Übersicht zu einem Merkmal des Designmodells.

Ergebnisse kurz festhalten

Sie haben für alle Subsysteme folgende Aktionen ausgeführt:

  • Operationen des Subsystems definieren
  • die vom Subsystem zu unterstützenden Schnittstellen definieren
  • beschreiben, wie das Subsystem mit anderen Subsystemen kollaborieren soll, um die Systemanwendungsfälle zu realisieren
  • den Kontext des Subsystems definieren: die Akteure, Schnittstellen und E/A-Entitäten

Sie sind daher absolut in der Lage, diese Gruppe von Arbeitsergebnissen an ein unabhängiges Entwicklungsteam abzugeben, wenn Sie dies wünschen, oder die RUP-Aufgaben in der Disziplin "Anforderungen" erneut aufzurufen, um eine weitere, rekursive Dekomposition vorzunehmen.

Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen