Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

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 Blockdefinitions­diagramm, 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 System­entwicklungs­methoden 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 System­kontext 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 Anwendungs­fall­diagramm. 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 Verhaltens­diagramme. Im Aktivitäts­diagramm steht ein einfacher Pfeil für einen Kontrollfluss, im Zustands­diagramm für eine Transition und im Sequenz­diagramm 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 Anwendungs­fall­diagrammen werden die Assoziationen zum Beispiel meist auf direktem Weg geführt, während sie in Klassen­diagrammen im rechten Winkel besser aussehen.

Ein Diagramm oben tanzt aus der Reihe. Alle vier Diagramme bedeuten das Gleiche, nur verwendet das letzte Diagramm andere Ausdrucks­mittel dafür. Es ist ein Kompositions­struktur­diagramm (SysML::Internes Block­diagramm) 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 System­kontext 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 Zugriffs­mö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 Kompositions­struktur­diagramm (oder internes Blockdiagramm) verwenden. In einem Projekt, in dem die Schnittstellen­spezifikation so formal erfolgen soll, würde ich von Anfang an dieses Diagramm empfehlen.

Das Kompositions­struktur­diagramm und das interne Block­diagramm 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.