search
menu Navigation
NextGenSysML Teil 3 – Anforderungen an die Architektur der SysML v2

Systems Engineering

NextGenSysML Teil 3 – Anforderungen an die Architektur der SysML v2

9. Januar 2019

In diesem Blogbeitrag werden die Anforderungen an die Architektur und den Formalismus der SysML v2 erläutert. Der vorherige Blogbeitrag dieser Blogpost-Serie gab einen Überblick über die allgemeinen Anforderungen des OMG Request for Proposals (RFP). Die folgenden Blogbeiträge zeigen Details zu bestimmten Abschnitten der RFP‘s. Am Ende dieses Blogposts finden Sie eine Übersicht über alle Beiträge der Serie.

Ein grundlegendes Konzept einer Modellierungssprachenarchitektur ist das Metamodell. Es definiert die Elemente der Sprache. Die folgende Abbildung zeigt beispielsweise einen vereinfachten Ausschnitt des UML-Metamodells.

UML Metamodell Actor Class Usecase BehavioredClassifier

Die Abbildung zeigt die Definition der UML-Modellelemente Actor, Class und UseCase. Alle sind Spezialisierungen des abstrakten Konzepts BehavioredClassifier. Sie erben neben anderen die Fähigkeit, ein Verhaltenselement zu besitzen. Ein typisches Beispiel ist ein Anwendungsfall, der eine Aktivität besitzt, die die Abläufe des Anwendungsfalls spezifiziert.

Eine weitere Eigenschaft, die vom BehavioredClassifier geerbt wird, ist die Notation als Rechteck. Sie wissen wahrscheinlich, dass Rechtecke in einem Diagramm Klassen bzw. Blöcke darstellen. Aber auch Akteure und Anwendungsfälle können durch Rechtecke anstelle von Strichfiguren oder Ellipsen dargestellt werden. In der UML-Spezifikation finden Sie natürlich viel detailliertere und eine vollständige Spezifikation des Metamodells.

SysML v1 verwendet den Erweiterungsmechanismus Profil/Stereotyp, um die SysML-Modellelemente als eine Erweiterung der UML zu definieren. Die nächste Abbildung zeigt beispielsweise die Definition des SysML-Elements Block. Es ist ein Stereotyp, das das UML-Element Class erweitert. Natürlich enthält die SysML-Spezifikation eine detailliertere Definition des Blockelements mit Constraints und der Spezifikation der Semantik und Notation.

SysML Block Definition

Die folgende Abbildung zeigt die Beziehung zwischen SysML v1 und UML. SysML v1 ist ein Profil der UML. Das StandardProfile ist Teil der UML-Spezifikation und definiert einige gängige Stereotypen. SysML verwendet es auch.

SysML Architektur

Tatsächlich importiert SysML v1 nur eine Teilmenge der UML namens UML4SysML und nicht das vollständige UML-Metamodell.

Eine wesentliche Neuerung von SysML v2 im Vergleich zu SysML v1 besteht darin, dass es nicht mehr erforderlich ist, ein UML-Profil zu sein. Wörtlich heißt es in den Anforderungen:

Proposals for SysML v2 shall be specified using a metamodel that includes abstract syntax, concrete syntax, semantics, and the relationships between them.

und

Proposals for the SysML v2 metamodel shall be specified in MOF or SMOF.

Die Anforderungen öffnen den Lösungsraum für SysML v2. Es kann immer noch ein UML-Profil sein, aber auch eine Modellierungssprache mit einem vollständig neuen UML-unabhängigen Metamodell. In jedem Fall muss es auf der Meta Object Facility (MOF) bzw. MOF Support for Semantic Structures (SMOF) basieren. MOF ist die Basis aller OMG-Modellierungssprachen.

Das SysML Submission Team (SST), d.h., das Team, das die neue SysML v2-Spezifikation entwickelt, arbeitet an einem neuen UML-unabhängigen Metamodell. Dies ermöglicht die Implementierung von Systemkonzepten in SysML ohne Einschränkungen durch das UML-Metamodell. Beispielsweise haben die SysML v1-Modellelemente Allocate und ElementGroup aufgrund des zugrunde liegenden UML-Metamodells einige Probleme.

Eine nicht zwingende Anforderung für SysML v2 besagt, dass Modellbibliotheken die SysML v2-Semantik definieren müssen. Sie erweitern die deklarative Basissemantik. Diese Spracharchitektur vereinfacht auch die benutzerspezifische Erweiterung der Sprache. Anstelle von Profilen mit Stereotypen können Sie die Sprache erweitern, indem Elemente in einer Modellbibliothek definiert werden.

Eine andere nicht zwingende Anforderung erfordert, das die Semantik von SysML v2 mithilfe mathematischer Logik definiert wird. Die Korrektheit eines Modells kann damit durch mathematische Nachweise belegt werden, anstatt das Modell auszuführen. Eine nicht zwingende Anforderung gibt außerdem an, dass eine Teilmenge der SysML v2-Semantik vollständig und entscheidbar sein muss.

Zusätzlich zum SysML v2-Metamodell fordert das RFP auch ein SysML v2-UML-Profil:

Proposals for SysML v2 shall be specified as a SysML v2 profile of UML that includes, as a minimum, the functional capabilities of the SysML v1.x profile, and a mapping to the SysML v2 metamodel.

Das SysML-v2-Profil kann nur eine Teilmenge der SysML-v2-Funktionen bereitstellen, da die zugrunde liegende UML die Möglichkeiten einschränkt .Das SysML-v2-Profil soll eine breitere Palette von Herstellerimplementierungen ermöglichen und einen Migrationspfad von SysML-v1-Modellen über SysML-v2-Profilmodelle zu SysML-v2-Metamodellmodellen bieten.

In Bezug auf Migration soll SysML v2 auch eine die Abbildung der Konzepte definieren, die gemeinsam von SysML v2 und UML bzw. SysML genutzt werden.

Die Definition einer Modellierungssprache besteht aus drei Hauptsäulen: abstrakte Syntax, konkrete Syntax und Semantik. Die Semantik definiert die Bedeutung eines Modellelements und die konkrete Syntax definiert die Notation. Die abstrakte Syntax definiert die Struktur des Modellelements. Wenn Sie ein Informatiker sind, wissen Sie, dass die Darstellung von den dargestellten Daten abhängt, die Daten jedoch nicht von der Ansicht abhängen dürfen.

Das Gleiche ist auch für die SysML v2 gefordert, d.h., die abstrakte Syntax darf nicht von der Notation (konkrete Syntax) abhängen. Somit können zusätzlich zu den standardisierten SysML-Diagrammen weitere benutzerspezifische Ansichten definiert werden.

Die von SysML v2 standardisierten Notationen müssen eine eindeutige Abbildung auf die abstrakte Syntax sowie Beispiele in der Spezifikation bereitstellen.

Obwohl die Diagramme, d.h., grafische Ansichten, eine wesentliche Rolle bei der Modellierung spielen, ist es manchmal nützlich, Modelldaten textuell zu bearbeiten oder anzuzeigen. Eine nicht zwingende Anforderung für SysML v2 fordert eine textuelle SysML-Notation. Die Kombination aus grafischen und textuellen SysML-Editoren und Darstellungen macht es zu einer leistungsfähigen Entwicklungsumgebung. Die Action Language for Foundational UML (Alf) ist ein potenzieller Kandidat für die textuelle SysML-Notation. Natürlich muss Alf für SysML v2 erweitert und modifiziert werden.

SysML ist eine allgemeine Modellierungssprache für Systems Engineering und deckt keine Spezialgebiete einer Domäne wie Raumfahrt oder Luftfahrt oder Methodiken wie SYSMOD, OOSEM oder Harmony ab. In der Praxis müssen Sie SysML an Ihre speziellen Anforderungen anpassen, um es effektiv in einer MBSE-Umgebung einzusetzen. SysML v1 stellt die Profil- und Stereotypmodellelemente zur Erweiterung der Sprache bereit. SysML v2 muss auch einen Mechanismus enthalten, um die Syntax und Semantik erweitern zu können. Anstelle eines Profil-/Stereotypmechanismus können SysML-v2-Modelle voraussichtlich durch Modellbibliotheken erweitert werden (siehe oben).

Der Austausch von Modellen zwischen verschiedenen Modellierungswerkzeugen war von Beginn an eine Herausforderung für SysML (und UML). Es ist Zeit, dieses Problem zu lösen. SysML v2 soll ein Format zum Austausch der abstrakten und konkreten Syntax (Notation, Diagramme) eines Modells bereitstellen. Dies ist zwar nur eine nicht-verpflichtende Anforderung an die SysML v2, aber das SST-Team, das an der Spezifikation der SysML v2 arbeitet, hat einen besonderen Fokus auf dieses Thema und wird eine Lösung erarbeiten.

Der Austausch von Modellen erfordert häufig eine Abbildung von Modellelementen von einem Format auf ein anderes, z. B. den Import oder Export der Modelldaten aus oder nach Excel. Eine weitere  nicht zwingende Anforderung gibt an, dass SysML v2 die Möglichkeit bieten soll, Modellabbildungen und -umwandlungen zu definieren.

Der nächste Blogbeitrag behandelt die Querschnittsanforderungen, die für alle Modellelemente gelten, beispielsweise einen eindeutigen Identifikator, Gruppierungen oder allgemeine Beziehungen zwischen Modellelementen.

Frühere Blogbeiträge dieser Reihe:

Geplante zukünftige Blogbeiträge:

(Übersetzung des Original-Blogposts: https://model-based-systems-engineering.com/2019/01/01/nextgensysml-part-3-language-architecture-and-formalism-requirements/)


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich erkläre mich mit der Datenschutzerklärung und der Datenschutzinformation.