Aufgabe: Systemkontext definieren
Diese Aufgabe beschreibt, wie ein Systemkontextdiagramm erstellt wird, das die Kollaboration zwischen dem System und seinen Akteuren auf hoher Ebene zeigt.
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
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional:
  • Ohne
Extern:
  • Ohne
Ausgaben
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)

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)

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)

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.

Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar