Aufgabe: Systemkontext definieren |
|
 |
Diese Aufgabe beschreibt, wie ein Systemkontextdiagramm erstellt wird, das die Kollaboration zwischen dem System und seinen Akteuren auf hoher Ebene zeigt. |
Disziplinen: Analyse und Design |
|
Zweck
-
Basierend auf dem Anwendungsfallmodell eine Kollaboration auf höchster Ebene aufbauen, die das System (modelliert
als Ausgangssubsystem auf höchster Ebene), seine Schnittstellen sowie seine Beziehungen zu seinen Akteuren
einschließlich der externen E/A-Entitäten, die zwischen Akteur und System fließen, zeigen.
|
Beziehungen
Rollen | Primärer Ausführender:
| Zusätzliche Ausführende:
|
Eingaben | Verbindlich:
| Optional:
|
Ausgaben |
|
Prozessverwendung |
|
Schritte
Einführung
Während das Anwendungsfallmodell den Verhaltenskontext für das System zeigt, erstellen Sie in dieser Aufgabe ein
logisches Modell des Systems in seiner Umgebung, und zwar mit den Arbeitsergebnissen Anwendungsfallmodell und Ergänzende Spezifikationen, um folgende Elemente in einem
Kontextdiagramm darzustellen:
-
Die Schnittstellen, die vom System realisiert werden sollen (hinsichtlich der vom System bereitgestellten
Operationen, der unterstützten Protokolle und der Statusvariablen und Speicher, die das System
realisiert, sowie der Attribute, die als TPMs (Technical Performance Measures) gekennzeichnet sind).
-
Die E/A-Entitäten, die zwischen dem System und seinen Akteuren fließen.
-
Die Schnittstellen, die für das System erforderlich sind (müssen von den Akteuren, die mit dem System
interagieren, realisiert werden), damit eine ausreichende Leistung geboten werden kann. Oft, wenn der Akteur ein
vorhandenes System repräsentiert, mit dem das System kommunizieren muss, geben diese erforderlichen Schnittstellen
einfach Einschränkungen wieder, die von diesem anderen System vorgegeben werden.
Ein Kontextdiagramm zeigt die Kollaboration zwischen dem System und seinen Akteuren auf höchster Ebene. Was die
Struktur angeht, ist es analog zum Anwendungsfallmodell für das System zu sehen. Diese Kollaboration wird im
Analysemodell erstellt.
E/A-Entitäten (für die Modellierung als stereotype E/A-Klassen mit Attributen, jedoch ohne Operationen dargestellt)
beschreiben Elemente, die in das System hinein- und aus ihm herausfließen. Im Falle des allgemeinen Systems sind das
Daten, Masse, Energie oder physische Komponenten. E/A-Entitäten werden bei der Modellierung Paaren aus Akteuren und
Systemen zugeordnet und zeigen an, dass diese besonderen E/A-Entitäten zwischen Akteur und System fließen. Sie können
in den Diagrammen dargestellt und dem Akteur zugeordnet werden. Die Flussrichtung wird vom Stereotyp "Senden" (Send)
oder "Empfangen" (Receive) bei der Zuordnung angezeigt und gibt somit die Richtung im Verhältnis zum Akteur an.
Eine Systemoperation ist ein Service, 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. Die Operationen werden zusammen mit den Hauptzuständigkeiten des betreffenden Systems bzw. Subsystems um
Schnittstellen herum gruppiert. Ein Systemaufruf ist eine Interaktion mit dem System, die feiner unterteilt ist als
eine Anwendungsfallinstanz, und eine Anwendungsfallinstanz ist eine Zusammenstellung von Operationsaufrufen und
Antworten.
Zustandsvariablen und Speicher sind Attribute, die für die vom System realisierten Schnittstellen definiert wurden.
Diese sind abstrakt und erfordern, dass das System Informationen je nach Typ und Vielfalt des Attributs verwaltet und
das Speichern, Abrufen und Modifizieren dieser Informationen erlaubt. Kein Attribut im System entspricht dem in der
Schnittstelle definierten Attribut direkt. Der Unterschied zwischen Zustandsvariablen und Speichern ist nicht
wesentlich, er spiegelt lediglich die Art und Weise wider, in der die Attribute verwendet werden, um die Ausführung der
(abstrakten) Zustandsmaschine des Systems zu steuern. Ein Zustand bleibt über einen bestimmten Zeitraum bestehen, im
Gegensatz zu einem Ereignis (z. B. Eingang eines Signals), das zu einem bestimmten Zeitpunkt eintritt. Die
Zustandsmaschinen, die hier erwähnt werden, sind finite Zustandsmaschinen, und die Darstellung des Zustands wird
normalerweise durch relativ wenige Variablen bestimmt. Der aktuelle Zustand kann z. B. durch den Wert eines einzelnen
Attributs eines Aufzählungstyps angegeben werden. Die Reaktion des Systems auf ein Ereignis ist jedoch möglicherweise
nicht nur von der Art des Ereignisses (und der Information, die es beinhaltet, z. B. in den Ausführungsparametern) und
dem aktuellen Zustand, sondern auch von den Werten anderer (eventuell vieler) Attribute abhängig.
Ein TPM (Technical Performance Measure) ist ein wichtiges technisches Attribut, das aus den ergänzenden Spezifikationen
oder aus dem Anwendungsfallmodell als kritischer Indikator der Systemeffektivität ausgewählt wird. Kann das
entsprechende Niveau nicht erreicht werden, wird die Systementwicklung dem Risiko ausgesetzt, dass die Kosten aus dem
Ruder laufen oder Plan- oder Leistungseinschränkungen entstehen. Die entwickelten Werte solcher Attribute werden
während der gesamten Projektlebensdauer überwacht. Beispielsweise kann es wichtig sein, dass das Gewicht des
gelieferten Systems unter einem bestimmten Grenzwert bleibt. Das Erreichen dieses Ziels muss überwacht werden, während
gleichzeitig die Design- und Konstruktionsarbeit fortgesetzt wird. Das Gewicht des Systems bei Lieferung ist
offensichtlich ein Attribut einer Systeminstanz (das auf verschiedene Weise wahrgenommen werden kann) und nicht
notwendigerweise mit dem Zielgewicht während der Entwicklung identisch. Sie können einen UML-Eigenschaftswert
verwenden, um das Leistungsziel mit einem TPM-Attribut anzugeben. Beispiel:
Gewicht lt. TPM {maximum_weight = 1000kg}
TPMs können auch auf andere nicht strukturelle Merkmale wie die Antwortzeit einer Operation angewendet werden.
Eigenschaftswerte können zwecks Aufzeichnung auf Systemoperationen oder das System selbst angewendet werden.
|
Erstes Kontextdiagramm erstellen
Die folgenden Schritte zeigen entstehende Detaillierungsebenen des Systems im Kontext. Im folgenden Beispiel wird ein
Sicherheitssystem dargestellt, das Eigentum vor unbefugtem Zugriff schützt und nicht nur einen Audioalarm auslösen,
sondern auch Einbrüche an ein Interventionssystem melden kann.
Während Sie das Anwendungsfallmodell entwickeln und mit weiteren Details versehen (Akteure ermitteln oder - wenn die
Geschäftsmodellierung durchgeführt und Akteure und ggf. Operationen bereits identifiziert wurden - die Interaktion der
Akteure erarbeiten), können Sie die anfängliche Kollaboration erstellen und mit einem Kontextdiagramm veranschaulichen.
Das Kontextdiagramm kann wie gezeigt erstellt werden, anfänglich ohne die Systemschnittstellen. Das System wird als
Subsystem auf höchster Ebene dargestellt (mit dem Stereotyp "System"), das schließlich verschiedene Schnittstellen
realisiert. Akteure und deren Zuordnungen werden, zunächst wieder ohne Details, gezeigt.
Kontextdiagramm (Anfang)
|
Zuordnungen und Schnittstellen verfeinern
Als Nächstes verfeinern Sie die Zuordnungen zwischen Akteuren, System und Systemschnittstelle. Sie können jetzt
beginnen, sich über die Systemoperationen und die Systemattribute Gedanken zu machen, die sich aus der Aufgabe Akteure und Anwendungsfälle finden (später: Anwendungsfall ausführlich beschreiben) ergeben. Beachten Sie, dass
das System jetzt über die Schnittstelle für die Akteure sichtbar wird. Sie können die Realisierung dieser Schnittstelle
anzeigen (durch den gestrichelten Kreis im Diagramm), Sie können sie jedoch auch ohne viel Informationsverlust
übergehen.
Identifizieren Sie die E/A-Entitäten in diesem Stadium nur vorläufig. Verlassen Sie sich dabei auf Ihr Fachwissen und
verwenden Sie die zuvor bei der Anwendungsfallrealisierung auf Unternehmensebene geleistete Arbeit als Grundlage. Die
E/A-Einheiten müssen zwar nicht unbedingt im Diagramm erscheinen, sind allerdings hilfreich, wenn es darum geht, die
Interaktionen zwischen Akteur und System zu untersuchen.
So können Sie beginnen, die Verbindungen zwischen Akteur und System zu charakterisieren (z. B. Erfassung des
erforderlichen Protokolls) und die Entitäten, die zwischen ihnen fließen, zu erfassen.
Kontextdiagramm (vorläufig)
|
Systemoperationen und andere Systemmerkmale detailliert angeben
In diesem Schritt beginnen Sie, Anwendungsfallszenarios (Instanzen von Anwendungsfällen) zu erstellen, über die Sie
Systemoperationen (bereitgestellte und erforderliche) beschreiben können. Die Szenarios können durch Interaktionen oder
Aktivitätsdiagramme veranschaulicht werden. Jeder Blackbox-Schritt in einem Anwendungsfall stellt eine feiner
unterteilte Interaktion mit dem System dar und entspricht einem Operationsaufruf (jedoch nicht unbedingt einer
eindeutigen Operation; andere Blackbox-Schritte verwenden möglicherweise dieselbe Operation). So wie die
Systemoperationen im Kontextdiagramm (und daher im Analysemodell) definiert werden, werden die Anwendungsfälle zwecks
Rückverfolgbarkeit ebenfalls in den aufgerufenen Operationen definiert. Die Operationen übernehmen auch alle
Leistungsanforderungen oder andere nicht funktionale Anforderungen, die den Blackbox-Schritten zugeordnet wurden. Wenn
Sie die einzelnen Blackbox-Schritte, die im Szenario ausgeführt werden, untersuchen, entdecken Sie Namen, die
möglicherweise Zustandsvariablen und Speicher suggerieren, die vom System zur Ausführung des Anwendungsfallszenarios
verwaltet werden müssen. Sie können auch die E/A-Entitäten verfeinern, die erforderlich sind und diese
Operationsaufrufen zuordnen, um die zwischen Akteur und System gesendeten Signale zu bilden.
Möglicherweise ist es gut für das Verständnis, die Systemschnittstelle in mehrere spezifische Schnittstellen zu
unterteilen. Tatsächlich können die ergänzenden Spezifikationen Schnittstellenanforderungen enthalten, die eine
entsprechende Vorgabe machen. Die folgende Darstellung veranschaulicht für jeden Akteurtyp die Entwicklung der
Systemschnittstelle zu einer "bereitgestellten Systemschnittstelle", obwohl das nicht obligatorisch ist. Akteure können
eine Schnittstelle gemeinsam nutzen oder es können mehrere Schnittstellen für einen Akteur vorhanden sein.
Diese Analyse kann auch Schnittstellen angeben, die für das System erforderlich sind, d. h., Schnittstellen, die
von den Akteuren unterstützt werden müssen (um Nachrichten vom System zu verarbeiten). Diese Nachrichten können
symmetrisch zum Diagramm hinzugefügt werden (siehe z. B. die vom Akteur Emergency Services realisierte, erforderliche
Systemschnittstelle IE-services/ESS im folgenden Diagramm). Beachten Sie, dass ein Akteur mehrere Schnittstellen
unterstützen bzw. realisieren kann (wird hier nicht gezeigt).
Die Operationen, Speicher usw. müssen den Schnittstellen wie dargestellt in erweiterter Form hinzugefügt werden (in den
Abschnitten für Attribute und Operationen). Das Diagramm ist nur teilweise ausgearbeitet (Schonung der
Speicherressourcen). Die physische Umgebungsschnittstelle, Akteure usw. wurden nicht erweitert. Es sei noch einmal
darauf hingewiesen, dass die Realisierung der bereitgestellten Systemschnittstellen ohne viel Informationsverlust
übersprungen werden kann.
Kontextdiagramm (Abschluss)
Diese Kollaboration auf höchster Ebene, die im Kontextdiagramm erfasst wird, ermöglicht die genaue Angabe der
Schnittstellen, Verbindungen und aller Elemente, die in das System hinein- und aus ihm herausfließen, sowie der
zugeordneten Leistungsmerkmale. Dadurch wird es möglich, die Systementwicklung unabhängig von anderen Elementen im
Systemkontext fortzusetzen.
|
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|