Konzept: Anwendungsfall-Flowdown
Anwendungsfall-Flowdown ist die Technik, mit der funktionale Anforderungen für die Analyseelemente (und anschließend die Designelemente) abgeleitet werden können.
Beziehungen
Hauptbeschreibung

Einführung

Anwendungsfall-Flowdown ist die Technik, mit der funktionale Anforderungen für die Analyseelemente (und anschließend die Designelemente) abgeleitet werden können. Die Ergebnisse dieser Aktivität sind:

  • Übersicht über die Subsystemoperationen
  • Übersicht über bereitgestellte Subsystemoperationen für Lokalitäten
  • Übersicht über ausgeführte Subsystemoperationen für Prozesse
  • Anwendungsfallübersicht für Subsysteme (optional)

Die Technik verwendet die Standard-RUP-Aktivität zur Auswahl architektonisch relevanter Anwendungsfälle. Für jeden ausgewählten Anwendungsfall wird der Ereignisablauf beschrieben. Dies ist die Beschreibung der Interaktionen zwischen den Systemakteuren und dem System. Die Systemantworten sind Blackbox-Antworten. Die Beschreibungen enthalten keinen Verweis auf die Architekturelemente. Anschließend wird ein Blackbox-Schritt (der von einer Systemoperation ausgeführt wird) in ein oder mehrere Whitebox-Schritte erweitert, die jeweils von einem benannten Subsystem ausgeführt werden. Die Whitebox-Schritte werden auch den Lokalitäten, auf denen sie bereitgestellt werden, und den Prozessen, die sie ausführen, zugeordnet. Jeder Whitebox-Schritt, der sich auf Lokalitäten oder Prozesse erstreckt (d. h. mehr als eine bzw. einen zur Ausführung benötigt), wird so oft aufgeteilt, bis er an einer einzelnen Lokalität von einem einzelnen Prozess ausgeführt werden kann. Ein Whitebox-Schritt kann an mehreren Lokalitäten repliziert werden, aber dies sind unabhängige Instanzen. Diese Whitebox-Schritte sind Kandidaten für Subsystemoperationen, die auf dieser unteren Ebene der logischen Komposition Systemoperationen entsprechen.

Die Kompositionen eindeutiger Sequenzen von Subsystemoperationen für ein einzelnes Subsystem, die an der Realisierung von Systemoperationen beteiligt sind, ergeben die Subsystemanwendungsfälle (optionaler Schritt).

Zuordnung der Subsystemlokalität

Zu Beginn des Anwendungsfall-Flowdown haben Sie es mit einem System zu tun, das sich normalweise auf mehrere Lokalitäten erstreckt (und diese möglicherweise kapselt). Der Grad der durchgeführten Dekomposition in Subsysteme (und Subsubsysteme) ist eine Architekturentscheidung und unter anderem vom Fachgebiet und der Komplexität des Systems abhängig. Für die Zwecke der Leistungsanalyse ist es jedoch wichtig, dass Sie die Rechenlast für die Lokalität kennen. Hierfür werden die Subsystemoperationen an der Lokalität herangezogen. Halten Sie sich deshalb an die folgenden Vorgaben für Dekomposition: Die Dekomposition muss eine Reihe von Subsystemoperationen ergeben, die klar auf die Lokalitäten verteilt sind, d. h. eine Subsystemoperation erstreckt sich nicht auf mehrere Lokalitäten. Wenn eine Subsystemoperation (von z. B. Subsystem A) aus Leistungsgründen die Verwendung von Ressourcen an einer anderen Lokalität erfordert, müssen diese Ressourcen selbst durch eine Subsystemoperation verfügbar gemacht werden, die von Subsystem A selbst an dieser Lokalität bereitgestellt wird (oder von einem anderen Subsystem).

Diese Bedingung gilt offensichtlich, wenn sich ein Subsystem nicht über Lokalitäten erstreckt. Ein Subsystem kann sich jedoch auf mehrere Lokalitäten erstrecken, wenn seine Operationen wie beschrieben verteilt werden können. Andernfalls muss das Subsystem weiter zerlegt werden. Die Diskussion hier bezieht sich auf einzelne Instanzen eines Subsystems, das mehrere Lokalitäten umspannt. Ein System kann an mehreren Lokalitäten repliziert werden, aber hierbei handelt es sich um separate Instanzen.