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