Teilnehmer unserer Kurse fragen manchmal, welche UML oder SysML Diagrammart für einen Systemkontext verwendet werden muss. Tatsächlich ist die Auswahl ja groß: Neben den links abgebildeten Diagrammen könnte man auch noch das Paketdiagramm oder in der SysML das Blockdefinitionsdiagramm, das interne Blockdiagramm oder das Anforderungsdiagramm verwenden. Tatsächlich erlauben all diese Diagramme einen Systemkontext darzustellen (das Beispiel ist übrigens aus dem bekannten Comic über verschiedene Sichtweisen auf ein Softwareprojekt: projectCartoon.com).
Erst mal muss man festhalten, dass man die Antwort nicht in der UML oder SysML Spezifikation finden wird. Ein Systemkontext ist ein Diagramm, das bei bestimmten Systementwicklungsmethoden vorgesehen ist, um das System von seiner Umgebung abzugrenzen. Und zu methodischen Fragen schweigen beide Spezifikationen.
Ist die Modelliererin also frei in der Wahl der Diagrammart? Nur Scheinbar. Denn in Wahrheit steht in der Spezifikation:
> the primary graphical symbols define the type of the diagram
Ok, mal schauen: Die primären grafischen Symbole in einem Systemkontext sind die Akteure. Die UML (und auch die SysML) kennt nur ein Diagramm, in dem Akteure auftreten. Mit anderen Worten: Egal was drüber steht, es ist per definitionem ein Anwendungsfalldiagramm. Und das, obwohl nicht ein einziger Anwendungsfall weit und breit zu sehen ist.
Und wozu steht dann die Diagrammart überhaupt darüber? Überraschenderweise sieht die UML gar nicht vor, die Diagrammart anzugeben. Die abgebildeten Diagramme sind nicht konform zur Spezifikation.
Bei der Mehrzahl der Diagrammarten (7 in der UML, 4 in der SysML) ist die Art auch ziemlich nebensächlich. Die Semantik eines Symbols ist für alle diese Arten gleich. Ein einfacher Pfeil zwischen zwei benannten Rechtecken bedeutet dort immer eine navigierbare Assoziation. Ausnahmen sind natürlich unter anderem die Verhaltensdiagramme. Im Aktivitätsdiagramm steht ein einfacher Pfeil für einen Kontrollfluss, im Zustandsdiagramm für eine Transition und im Sequenzdiagramm für eine Nachricht.
Trotz der Austauschbarkeit vieler Diagrammarten, ist es sinnvoll, dass die Tools einen Unterschied dazwischen machen. So können sie dem Modellierer zum jeweiligen Diagramm passende Vorschläge machen, etwa in Form einer Toolbox, die für Anwendungsfalldiagramme eben Anwendungsfälle und Akteure enthält. Außerdem werden Layout-Optionen an die Diagrammart angepasst. In Anwendungsfalldiagrammen werden die Assoziationen zum Beispiel meist auf direktem Weg geführt, während sie in Klassendiagrammen im rechten Winkel besser aussehen.
Ein Diagramm oben tanzt aus der Reihe. Alle vier Diagramme bedeuten das Gleiche, nur verwendet das letzte Diagramm andere Ausdrucksmittel dafür. Es ist ein Kompositionsstrukturdiagramm (SysML::Internes Blockdiagramm) und zeigt von Konnektoren verbundene interne Teile eines Elements. Die Aussage ist trotzdem gleich. Der Aufwand ist ein bisschen höher, da ein zusätzliches Element explizit modelliert werden muss: Der Systemkontext selbst (siehe rechts). Damit können dann die Bestandteile des Kontextes – die Akteure – mittels Konnektoren, die ebenfalls dem Kontext gehören, mit dem System verbunden werden.
Der Aufwand ist gerechtfertigt, wenn die Schnittstellen zu den Akteuren mit Hilfe von Ports genau spezifiziert werden sollen. 
Ports definieren eine Zugriffsmöglichkeit auf Teile eines Elements, stehen also stellvertretend für diese Teile. Sie sind folglich spezielle Teile. Wie alle Teile können sie nur mittels Konnektoren mit anderen Teilen verbunden werden. Braucht man das muss man ein Kompositionsstrukturdiagramm (oder internes Blockdiagramm) verwenden. In einem Projekt, in dem die Schnittstellenspezifikation so formal erfolgen soll, würde ich von Anfang an dieses Diagramm empfehlen.
Das Kompositionsstrukturdiagramm und das interne Blockdiagramm gehören übrigens zu den Ausnahmen, bei denen ein Pfeil nicht eine navigierbare Assoziation bedeutet. In diesen beiden Diagrammen wird mit einem Pfeil ein Konnektor dargestellt, dessen Typ eine navigierbare Assoziation ist.
Fazit
Für einen Systemkontext nimmt man ein Anwendungsfalldiagramm oder ein Kompositionsstrukturdiagramm (SysML::Internes Blockdiagramm). Letzteres wird für komplizierte Systeme empfohlen.
Bildnachweis:
projectcartoon.com Lizenziert unter CC BY 3.0.