Die Modellierungssprache SysML

Die SysML 1.x basiert auf der UML Sprachfamilie mit ihren 14 Diagramm-Arten, wobei das 14te Diagramm der UML-Profilmechanismus ist, mit dem UML erweitert werden kann. Die SysML 1.x ist so eine Erweiterung. SysML ist allerdings nicht nur ein UML-Profil, sondern auch ein OMG Standard, welcher eine Sub-Menge der UML für SysML (UML4SysML) definiert und über SysML spezifische Stereotypen (zusätzliche Bezeichnungen auf UML Sprach-Elementen) die Sprache UML erweitert.

Der Grund für eine Systems Modelling Language war, dass einige Diagramme der UML sehr auf die Beschreibung von Software-Systemen ausgelegt sind und von der Begrifflichkeit stark an Objektorientierte Software Entwicklung erinnern. Daher wurden einige Modell-Elemente mittels Stereotypen umbenannt und mit TaggedValues, um einige Eigenschaften erweitert. Von den 14 bzw. 13 Diagrammen (wenn das UML-Profil nicht gerechnet wird) wurden 7 übernommen und zwei neue Diagramme hinzugefügt. Die SysML hat also 9 Diagramme im Gegensatz zu UML mit 13 (14 mit UML Profil) Diagrammen.

In der SysML finden wir also einige Diagramme, welche 1:1 von der UML übernommen wurden. Diese sind: das Paket-Diagramm (Package Diagram), Anwendungsfall-Diagramm (UseCase Diagram), das Zustandsautomaten-Diagramm (State Machine Diagram) und das Sequenzdiagramm (Sequence Diagram).

Das UML Klassendiagramm, das UML Kompositionsstrukturdiagramm und das UML Aktivitätsdiagramm wurden mittels UML-Profile erweitert und durch in der SysML Spezifikation definierten Constraints eingeschränkt.

Neben diesen UML Diagrammen gibt es in der SysML auch zwei gänzlich neue Diagramme, das Anforderungsdiagramm (Requirements Diagram) und das Parametrische Diagramm (Parametric Diagram).

UML Diagramme mit Erweiterungen

Block-Definitions-Diagramm (BDD)

Das UML Klassen-Diagramm heißt nun Block-Definitions-Diagramm. Die wesentliche Erweiterung ist die Einführung des Stereotypes «block» für die UML Klasse. Wir sprechen also nicht mehr von Klassen, sondern von Blöcken. Der Block entspricht dabei mehr dem Verständnis eines System-Ingenieures oder -Ingenieurin.

Eine Erweiterung in der SysML ist, dass Schnittstellen mittels UML Ports (Interaktionspunkte) genauer spezifiziert werden können und damit der stoffliche Austausch zwischen Systemen und Systembestandteilen genauer und formaler beschrieben werden kann.

Wir können z. B. definieren, dass ein bestimmter Stoff (Luft, Flüssigkeit, spezielle Kraftstoffe, Elektrizität, etc.) hinein oder hinaus fließen.

Die Flussrichtung wird dabei mit sogenannten FlowProperties definiert. Ein Property ist dabei eine Eigenschaft, welche in einem Block enthalten sein kann. Der Typ des Properties definiert, um was es sich dabei handelt. Dabei kann der Typ ein anderer Block sein oder ein DataType Element, welcher wiederum genauer spezifiziert sein kann.

Mit dem BDD beschreiben wir z. B. den strukturellen Aufbau eines Systems, dabei gibt das SysML BDD nicht vor welche Sicht eingenommen werden soll, diese wird durch die eine spezielle Methode definiert, z. B. ob ein BDD eine logische Sicht auf das System, eine physische Sicht oder eine Software-Sicht bzw. eine Kombination davon beschreibt. Ja, mit SysML können auch (Software)-Systeme beschrieben werden, genauso wie die UML auch für die allgemeine Beschreibung von Systemen verwendet werde kann, mit den Einschränkungen die durch die SysML ergänzt wurden.

Der PowerControlUnit Block mit angezeigten Ports, manche sind durch Blöcke mit FlowProperties typisiert, daher zeigen sie Pfeile für dir Fließrichtung. Diese Ports können im IBD ebenfalls an Properites vom Typ PowerControlUnit angezeigt und mit anderen Ports oder Properties verknüpft werden.

Internes-Block-Definitions-Diagramm (IBD)

Das Interne Bock-Definitions-Diagramm ist eine Erweiterung des UML Kompositionsstruktur Diagramms. In der Regel werden BDD und IBD in der SysML als zwei Seiten einer Medaille betrachtet (Black-Box und White-Box Sicht des Systems) und kommen in der Regel immer beide vor.

Mit dem BDD definieren wir die Bauteile (Typen) in unserem System. Mit unterschiedlichen Beziehungen (Generalisierung (= Vererbung), Komposition & Aggregation (= Teil-Ganzes-Beziehung) beschreiben wir wie ein System aus anderen Systemen besteht.

Hat ein Block Ports (kleine Rechtecke am Rahmen), können diese auch an den Properties angezeigt werden, um damit auf die Interaktionspunkte der Blöcke zuzugreifen, wenn diese in einem anderen Block verwendet werden (als Property typisiert mit einem Block mit Port). Z. B. hat die PowerControlUnit einige Ports, welche im IBD ebenfalls angezeigt werden können.

Wurde der Port mit einem Block typisiert, der wiederum FlowProperties enthält, zeigt der Port eine Richtung [<] [>] oder [<>]. Letzteres bedeutet, dass die durch das FlowProperty definierte „Gut“ hinein und hinaus fließt oder das unterschiedliche Dinge hinein oder hinaus fließen.

Aktivitäts-Diagramm

Das SysML Aktivitätsdiagramm ist im Kern nicht angepasst und funktioniert genauso wie das UML Aktivitätsdiagramm. Es gibt lediglich einige Erweiterungen durch einigen Stereotypen, um eine bessere Kontrolle von Flüssen im Aktivitätsdiagramm zu errechen. Wir können in SysML Aktivitätsdiagrammen z. B. Wahrscheinlichkeiten bei den Flüssen (ObjectFlow) angeben, optionale Flüsse definieren und Kontinuierliche Flüsse genauer beschreiben.

Neue Diagramme in der SysML 1.x

Anforderungs-Diagramm

In der UML gibt es kein eigenes Modell für Anforderungen (Requirements). Das einzige Modell, welches dafür herangezogen werden kann, ist das Anwendungsfalldiagramm (Use Case Diagram).

Mit Use Cases beschreiben wir funktionale Anforderungen für unterschiedliche Stakeholder, welche durch UML Akteure beschrieben werden. Der Use Case, abhängig vom System-Kontext, beschreibt dabei den Sinn und Zweck des Systems.

Möchten wir allerdings nicht funktionale Anforderungen oder funktionale Anforderungen beschreiben, welche nicht unbedingt den primären System-Zweck beschreiben, fehlt in der UML ein Modell.

Im Enterprise Architect (EA) gab es immer schon ein Anforderungs-Modell. In der SysML ist dieses nun auch standardisiert und ebenfalls im EA verfügbar.

Mit dem Anforderungsmodell können wir vor allem textuelle Anforderungsbausteine definieren und diese mit den in der SysML verfügbaren Beziehungen verknüpfen, um damit Aussagen und somit strukturiert Informationen in unser Modell einzupflegen, um diese später automatisch verarbeiten zu können. Damit kann uns das Modell interessante Fragestellungen beantworten.

Die SysML bietet einige spezielle Beziehungen, die zwischen Requirements-Elementen verwendet werden.  Dabei müssen nicht alle verwendet werden. Die wichtigsten Beziehungen zwischen Anforderungen ist die «derivReqt» Beziehung, die aussagt, dass eine Anforderung aufgrund einer anderen Anforderung vorhanden ist. Wird das Ziel der «derivReqt» Beziehung geändert, hat dies eine Auswirkung auf alle davon abgeleiteten Anforderungen.

SysML Anforderungen können auch mit dem restlichen Modell verknüpft werden, und erlauben dadurch eine vollständige Traceability von der Stakeholder-Anforderung bis zu dem gewünschten System-Level, welches im Modell abgebildet werden soll.

Weitere wichtige Beziehungen sind dabei die «refine» Beziehung, mit der wir eine Anforderung durch ein anderes Modell-Element genauer beschreiben können. Damit können wir eine Brücke zwischen Textbaustein und Model Based Requirements schlagen.

Die «verify» Beziehung erlaubt es Test-Fälle («testCase») Element mit Anforderungen zu verbinden. Der Test-Fall beschreibt wie die Anforderung mit der er verknüpft ist getestet werden soll.

Die «satisfy» Beziehung beschreibt die Umsetzung einer Anforderung durch ein anderes Modell-Element. So kann z. B. eine Anforderung durch einen oder mehrere Blöcke umgesetzt werden.

Parametrisches-Diagramm

 Das Parametrische (Parametric) Diagramm ist ein gänzlich neues Modell und eine Spezialisierung von SysML Blöcken. Der SysML Block heißt hier ConstraintBlock (Block mit Stereotyp «constraint») und definiert eine Art Gleichung- der auch als Funktion gesehen werden – mit Eingabe und Ausgabe Variablen (Values). Die Variablen werden in einer Gleichung verwendet.

«constraint» Blöcke können nun im Parametirc Diagramm instanziiert werden und werden Constraint Properties genannt. Mehrere Constraint Properties können nun zu einem Funktionsgraphen zusammengebaut werden.

Durch Simulationsmöglichkeiten können Parametric Diagramme ausgewertet werden. Dabei können unterschiedliche Sets an Variablen Konfigurationen (der Eingabedaten) definiert werden. Die Simulation berechnet anschließend die Ausgabedaten.

Zum Berechnen können auch mathematische Solver wie Matlab-Simulink oder Modellica verwendet werden.

Einfaches Parametic Diagramm mit einem Constraint Property

Durch die Kombination mehrere Constraint Properties in einem Parametric Diagramm, können wir komplexere Systeme beschreiben. Die einzelnen Constraint Blöcke dienen hierbei als Bibliothek und die Verwendung als Constraint Property in einem Parametric Diagramm als einfache Beschreibung eines komplexen Systemverhaltens.