Systemkontext im Entwurf

Dokumentationsmittel für Software-Architekturen.

Synonyme: Kontextabgrenzung, Kontextdiagramm

Zweck, Ziele, Inhalte:

Ein Systemkontext stellt alle beteiligten Benutzer und Fremdsysteme, mit denen das zu beschreibende System interagiert, vollständig dar und visualisiert somit das Umfeld des Systems. Dies kann sowohl aus einer fachlichen als auch einer technischen Sicht erfolgen.

Mit Hilfe des Systemkontextes werden Verantwortlichkeiten geklärt: Was leistet das System, was leistet es nicht? Wo verläuft die Systemgrenze? Welche Fremdsysteme müssen integriert werden?

In der Mitte der Darstellung wird das zu beschreibende System platziert, um dieses herum die beteiligten Benutzer und Fremdsysteme, die mit dem System durch eine direkte Linie verbunden sind; ggf. enthalten die Linien noch weitere Informationen.

Für jeden dargestellten Benutzer bzw. jedes dargestellte Fremdsystem ist eine kurze Beschreibung zu verfassen.

Tipps für die Erstellung

  • Stellen Sie das zu beschreibende System mit demselben Modellelement dar welches Sie auch zur Repräsentation des Systems in Ihrem Architektur-Modell verwenden – z.B. UML Component mit einem Stereotype «System» (oder «SuC» für System-under-Construction).
  • Modellieren Sie die Verbindungen als UML Association, und zwar immer von den beteiligten Benutzern und Fremdsystemen ausgehend zum System, dann fällt es Ihnen leichter, an diesen Verbindungen Informationsflüsse nach Motto “Wer liefert welche Daten?” darzustellen.
  • Fachliche Kontext-Sicht:
    • Da die mit dem System interagierenden Benutzer und Fremdsysteme allgemein als Akteure bezeichnet werden sollten dafür dieselben Modellelemente verwendet werden wie in Ihrem Anwendungsfall-Modell – also UML Actors:
      • Benutzer des Systems in der Standard-Darstellung als Strichmännchen mit dem Stereotype «SystemUser»
      • Fremdsysteme in der alternativen Rechtecks-Darstellung mit dem Stereotype «ForeignSystem».
    • Gehen Sie sparsam mit den weiteren Informationen an den Verbindungen um – die Zielgruppe ist selten an technischen Details wie Kommunikationsarten oder Protokollen interessiert.
  • Technische Kontext-Sicht:
    • Zumeist stellt diese Sicht auch die oberste Ebene – “Wie bettet sich das System in die Umgebung ein?” – dar. Daher stehen für die mit dem System interagierenden Benutzer und Fremdsysteme die folgenden Modellelemente zur Auswahl:
      • Zur Repräsentation von Fremdsystemen können entweder UML Components (Modellierung auf Schnittstellen-Ebene) oder UML Nodes (Modellierung ohne Interaktionspunkte – also weder Ports noch Schnittstellen) – jeweils mit einem Stereotype «ForeignSystem» versehen – zum Einsatz kommen.
      • Die Benutzer des Systems sollten nicht als Akteure dargestellt werden, sondern es sollten jene Systeme dargestellt werden, mit Hilfe derer die Benutzer mit dem System interagieren – und zwar wiederum (wie zuvor) als Fremdsysteme.
  • Erstellen Sie immer beide Sichten: eine fachliche, die den Systementwurf (Design) grundsätzlich abgrenzt und eine technische, die als Einstieg in die Beschreibung des Architekturentwurfs (Logical Architecture) dient.

Checkliste:

  • Wer ist die Zielgruppe? Ist eine fachliche oder technische Kontext-Sicht nötig?
  • Sind alle Benutzer und Fremdsysteme ausschließlich und direkt mit dem zu beschreibenden System verbunden – nicht jedoch untereinander oder indirekt über andere Benutzer/Fremdsysteme?
  • Erklärt eine Legende, was die einzelnen Symbole bedeuten?
  • Sollte die Anzahl der dargestellten Benutzer und Fremdsysteme größer als 10 sein, so sollte geprüft werden, ob sich diese durch Zusammenführung abstrahieren lassen.
  • Sind für alle Benutzer und Fremdsysteme Kurbeschreibungen vorhanden? Und geht daraus klar hervor, welche Rollen sie für das System spielen bzw. wozu sie überhaupt mit dem System interagieren?

Weiterführende Informationen: