Arbeitsergebnis: Operation |
|
 |
Dieses Artefakt stellt einen Service dar, der von einem Objekt angefordert werden kann, um das Verhalten zu beeinflussen. Eine Operation definiert den Namen, den Typ, die Parameter und die Bedingungen für den Aufruf eines zugeordneten Verhaltens. |
|
Zweck
Das Artefakt "Operationen" erfasst die bereitgestellten und erforderlichen Services, die ein Element unterstützt oder
benötigt.
|
Beziehungen
Rollen | Verantwortlich:
| Geändert von:
|
Eingabe für | Verbindlich:
| Optional:
| Extern:
|
Hauptbeschreibung
Eine Operationsspezifikation lässt sich wie folgt skizzieren:
-
Beschreibung
-
Ein-/Ausgabeparameter
-
Nicht funktionale Anforderungen:
-
Diese leiten sich aus den nicht funktionalen Anforderungen ab, die den Schritten in den verschiedenen
Anwendungsfällen zugeordnet sind, die von dieser Operation unterstützt werden.
-
Der Kontext, in dem die Operation verwendet wird (d. h. ein bestimmter Anwendungsfall), wird möglicherweise
nicht erfasst (dieser kann z. B. durch Unterstützung der Mindestleistungsanforderung angegeben werden, wenn
alle Anwendungsfälle berücksichtigt sind).
-
Vorbedingungen
-
Nachbedingungen
-
Rückverfolgbarkeit des übergeordneten Systems
-
Optional: Rückverfolgbarkeit von Anwendungsfällen (bzw. Anwendungsfallschritten)
In den meisten Fällen werden Operationen für das entwickelte System und die wichtigsten Subsysteme rekursiv bis zum
gewünschten Dekompositionsgrad definiert. Die Operationen werden um Schnittstellen herum zusammen mit den
Hauptzuständigkeiten des betreffenden Subsystems gruppiert.
Je nach Granularität und Verwendungskontext spezifizieren, definieren, präzisieren oder verwenden unterschiedliche
Rollen Operationen als Haupteingaben für die ihnen zugeordneten Aufgaben:
-
Architekten beschreiben die Hauptservices, die von den architektonisch relevanten Elementen unterstützt
werden.
-
Analytiker arbeiten mit den Architekten zusammen, um die Anwendungsfallschritte den Systemoperationen
zuzuordnen.
-
Designer verwenden sie als Eingabe während der Präzisierung und Umstrukturierung als Bausteine für die
Schnittstellendesignspezifikationen.
-
Tester leiten ihre Testfälle von den angegebenen Operationen ab.
-
Manager verwenden sie als Basis für die Phasen- und Iterationsplanung.
|
Eigenschaften
Optional |  |
Geplant |  |
Wichtige Hinweise
Der Designer ist für die Integrität der Operationsgruppe verantwortlich und stellt Folgendes sicher:
-
Die Operationen sind eindeutig, und es gibt keine Überlappungen.
-
Die zusammengehörigen Operationen sind logisch um Schnittstellen herum gruppiert.
-
Jede Operation ist ordnungsgemäß dokumentiert.
-
Die Rückverfolgbarkeitsbeziehungen zu anderen Operationen und/oder Anwendungsfallschritten wurden eingerichtet.
-
Die Anwendungsfälle oder Systemoperationen sind für den Umfang der aktuellen Iteration ausreichend abgedeckt.
|
Anpassung
Darstellungsoptionen |
Der operationsbasierte Ansatz ist eine formalere und strengere Methode für die Definition der Services, die vom System
und seinen Hauptsubsystemen unterstützt werden. Der Ausgangspunkt sind in der Regel die Systemanwendungsfälle. Deshalb
wird davon ausgegangen, dass Operationen zusammen mit Anwendungsfällen verwendet werden.
Die Hauptanpassungsentscheidungen sind:
-
Sollen nur architektonisch relevante Operationen (solche, die sich auf die wichtigsten Anwendungsfälle beziehen)
beschrieben werden?
-
Wie "tief" soll die logische Dekomposition der Subsysteme gehen?
-
Sollen Vor- und Nachbedingungen vollständig beschrieben werden?
-
Muss die Rückverfolgbarkeit zwischen Operationen und Systemoperationen und/oder Anwendungsfällen verwaltet werden?
Wenn Schnittstellendesignspezifikationen produziert werden müssen, nimmt der Detaillierungs- und Formalitätsgrad für
die Operationen, die in diese Spezifikationen aufgenommen werden, so weit zu, dass die erzeugten Artefakte für
Implementierung und Tests verwendet werden könnten.
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|