NextGenSysML Teil 8 - Verhaltensanforderungen

Blog offline

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.

In diesem Blogbeitrag werden die Anforderungen für die Verhaltensmodellierung mit der SysMLv2 vorgestellt. Er ist Teil einer Blogpostserie über den kommenden neuen Standard SysML v2 und SysML API & Services. Die Blogbeiträge stellen die Anforderungen an den Standard vor, die in der von der OMG veröffentlichten Ausschreibung (Request for Proposal, RFP) spezifiziert sind. Am Ende dieses Beitrags finden Sie eine Liste aller Beiträge dieser Serie, einschließlich eines Links zum ersten Beitrag der Serie, der eine allgemeine Einführung bietet.

Ein Verhalten ist eine Interaktion zwischen Strukturelementen, die eine Änderung der Zustände der Elemente bewirken kann. In SysML v1 wird ein Verhalten mit Aktivitäten, Zustandsautomaten, Interaktionen (Sequenzdiagrammen) oder opakem Verhalten, das Verhalten in einer anderen Textsprache als SysML definiert, beispielsweise eine Programmiersprache, beschrieben.
SysML v2 soll ähnliche Möglichkeiten anbieten, um…

…funktionsorientiertes Verhalten (Aktivität, Interaktion) einschließlich der Umwandlung von Eingaben in Ausgaben, Vor- und Nachbedingungen und der Reihenfolge der Ausführung modellieren zu können. Das umfasst diskretes und kontinuierliches Zeitverhalten. Eine optionale Anforderung für SysML v2 fordert zusammengesetzte Ein- und Ausgaben mit separaten Verknüpfungen für die einzelnen Bestandteile.

…zustandsbezogenes Verhalten von Strukturelementen modellieren zu können. Einschränkungen und funktionsorientiertes Verhalten können beispielsweise als Verhalten bei Übergängen in Zustandsautomaten integriert werden. Eine nicht obligatorische Anforderung fordert die Fähigkeit, die Zustandshistorie darzustellen.

...opakes Verhalten zum Einbetten anderer Spezifikationssprachen, z. B. Programmiersprachen modellieren zu können.

Ebenso wie es entscheidend ist, Strukturen zu zerlegen, ist es auch wesentlich, Verhalten zu zerlegen. SysML v2 soll die Dekomposition von Verhalten auf jeder Detaillierungs-Ebene unterstützen.
Verhalten kann nicht nur Eigenschaftswerte ändern, sondern auch ganze Strukturen von Elementen, d.h., Verbindungen und Kompositionen. Beispielsweise beim Schalten (=Verhalten) in einem Getriebe (=Struktur). SysML v1 unterstützt das nicht gut und das RFP fordert es jetzt für die SysML v2 ein.

SysML v2 soll die Fähigkeit bieten, Verhalten ausführen zu können. Mit SysML v1 ist das bereits möglich, es fehlt jedoch der SysML an formaler Präzision und es sind Interpretationen durch die Laufzeitumgebungen erforderlich. Gegenwärtig arbeitet die SysML v1.7 Revision Task Force an einem nicht-normativen Anhang der Spezifikation über die präzise Semantik der SysML, um die „Präzisionslücke“ zu schließen. Es werden jedoch nicht normative und notwendige (bedeutendere) Änderungen, um eine normativ genaue Semantik von SysML zu erreichen, nicht realisiert.

Ereignisse können Verhalten in Zustandsautomaten auslösen, aber auch in funktionsorientierten Verhalten, z. B. in SysML v1, die AcceptEventAction in der Aktivität. Ein Ereignis kann der Empfang eines Signals, ein Zeitereignis oder die Änderung von Eigenschaftswerten sein.

Der Kontrollfluss, d.h., die Ausführungsreihenfolge, kann durch Kontrollknoten wie z.B. eine Entscheidung oder ein Splitting festgelegt werden.

Zeitliche Aspekte können mit Elementen wie der Zusicherung über eine Dauer modelliert werden.

Typischerweise betrachten Systemingenieure Verhalten und Struktur sowohl getrennt als auch integriert. SysML v2 unterstützt die Modellierung von Verhalten und die Integration von Verhalten mit Strukturelementen. Zum Beispiel Zustandsautomaten, die die Zustände von Strukturelementen darstellen, oder die Zuordnung von strukturellen Eingaben und Ausgaben zu Verhaltensein- und -ausgaben (z. B., Eigenschaften von Ports zu Aktivitätsparametern).

Eine optionale Anforderung für SysML v2 fordert eine Verhaltensbibliothek für allgemeine Funktionen, z. B. Funktionen für Daten oder Energie.

Sie kennen wahrscheinlich Anwendungsfälle. SysML v2 unterstützt ein allgemeineres Konzept: den Fall. Ein Fall ist eine Reihe von Schritten, die einem Ziel zugeordnet sind. Spezifische Fälle sind die bekannten Anwendungsfälle, aber auch Analyse-, Sicherheits- oder Assurance-Fälle.

Der nächste Blog-Beitrag behandelt die Anforderungen an die Fähigkeit von SysML v2, Anforderungen zu modellieren.

Frühere Blogbeiträge dieser Reihe:

Geplante zukünftige Blogbeiträge:

NextGenSysML Teil 9 – Anforderungen an Anforderungen
NextGenSysML Teil 10 - Verifikationsanforderungen
NextGenSysML Teil 11 - Analyseanforderungen
NextGenSysML Teil 12 - Beispielmodell und Konformitätsanforderungen
NextGenSysML Teil 13 - SysML API & Services Übersicht
NextGenSysML Teil 14 - API & Services: Architekturanforderungen
NextGenSysML Teil 15 - API & Services: Konformitätsanforderungen
NextGenSysML Teil 16 - API & Services: Serviceanforderungen

(Übersetzung des Original-Blogposts: https://mbse4u.com/2019/05/20/nextgensysml-part-8-behavior-requirements/)