Der eigentliche Unterschied zwischen SysML und UML

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.

Kürzlich fragte jemand in einem Forum, warum die SysML eine Erweiterung der UML und nicht einfach eine unabhängige neue Sprache ist. Meine Antwort war, dass die UML eine sehr durchdachte und bewährte Sprache zur Modellierung von Struktur und Verhalten von Systemen ist und sich daher auch zur Modellierung von physischen Systemen anbietet. Das bringt natürlich sofort die Frage auf, warum dann überhaupt eine Erweiterung der UML nötig ist?

Ich will hier mal eine Antwort versuchen: Wenn man davon ausgeht, dass die UML für alle Systeme geeignet ist und die SysML für physische Systeme, dann läuft die Frage darauf hinaus, welche Eigenschaften ein physisches System hat, die ein Software-System nicht hat? Nun – erst mal dass es physisch ist, was nichts anderes heißt, als dass es physikalischen, chemischen und biologischen Gesetzen gehorcht. Wie zum Beispiel dem Gravitationsgesetz, dem Gesetz der konstanten Proportionen der Reagenzien in einer chemischen Reaktion oder der Uniformitätsregel bei der biologischen Vererbung. Auch Software-Systeme gehorchen Gesetzen, allerdings sehr einfachen: Ein Element des Systems verbraucht Speicherplatz. Die Ausführung von Verhalten dauert Zeit. Beide Tatsachen ignoriert man in UML-Modellen in der Regel [1].

Gesetze

Diese Gesetze braucht man, um anhand eines Systemmodells Vorhersagen über das modellierte System machen zu können.  Daher ist die Erweiterung der UML, die sich direkt aus der physischen Natur der beschriebenen Systeme herleitet, das Zusicherungsdiagramm. Damit kann man dann zum Beispiel beschreiben, dass auf Elemente des modellierten Systems die Gravitationskraft wirkt und vorhersagen, dass sie zu Boden fallen werden, wenn sie nicht befestigt sind.

Fehlender Instanziierungsprozess

Der zweite wichtige Unterschied ist, dass Materie nicht einfach erzeugt oder gelöscht werden kann (von Antimaterie und relativistischen Effekten sehe ich hier ab). In Softwaresystemen kann der Prozess der Instanziierung und Zerstörung von Elementen vollständig in Form von Klassendiagrammen, Konstruktoren und Destruktoren mit der UML beschrieben werden. Die Klasse wird ja auch als Bauplan bezeichnet, nach deren Anweisungen ein Objekt erzeugt wird. Man spricht davon, dass die Klasse instanziiert wird. Dafür ist die Laufzeitumgebung zuständig, die aus einem Substrat ein Objekt formt. Im Falle von Software ist das Substrat der Speicherplatz.

Was wäre bei physischen Systemen das Substrat und die Laufzeitumgebung? Nichts anderes als die wirkliche Welt und die darin enthaltenen Materialien. Ein SysML-Modell der gesamten Welt? Viel zu konkret für unsere Zwecke! Daher lässt man den Instanziierungsprozess im SysML-Modell komplett weg [2] (mit anderen Worten: es gibt keine Konstruktoren). Da man nun den Prozess selbst nicht beschreibt, braucht man erweiterte Möglichkeiten, das Ergebnis des Prozesses zu beschreiben. Das geschieht mit Hilfe des internen Blockdiagramms und seinen Parts, Ports und Konnektoren, die gegenüber der UML enorm erweitert wurden (z.B. Parts mit kontextspezifischen Typen, verschachtelte Ports, Konnektoren getypt durch Assoziationsklassen) .

Kontinua

Der dritte Unterschied ist, dass in physischen Systemen auch Kontinua existieren (oder Quasi-Kontinua wie zum Beispiel Materialflüsse). Dafür braucht man ein paar Erweiterungen des Aktivitätsdiagramms.

Die anderen Unterschiede sind nicht so elementar: Anforderungsdiagramme und Views würden auch der UML gut stehen. Blockdefinitionsdiagramme sind eigentlich Klassendiagramme und die Umbenennung ist wohl dem Sprachgebrauch von anderen Ingenieursdisziplinen geschuldet. Das Weglassen von einzelnen Diagrammen der UML würde ich eher als Empfehlung sehen, die ich ignoriere wenn ich die Diagramme für nützlich halte.

Fazit

Mit UML kann man den informationstechnischen Aspekt beliebiger Systeme und ihrer Erstellungsprozesse beschreiben. Sobald es um physische Eigenschaften geht oder der Erstellungsprozess nicht beschrieben werden kann, braucht man die SysML.

Sehen Sie noch weitere prinzipielle Unterschiede? Die OMG-SysML-Arbeitsgruppe teilt meine Ansicht übrigens nicht, dass es in der SysML keine Konstruktoren gibt. Wie sehen Sie das?