Systemkontext und Anwendungsfälle mit Claude & Syside (Teil 2)

SysML v2 und AI passen erstaunlich gut zusammen. Es ist Zufall, dass eine Modellierungssprache mit einer formalen textuellen Notation fast zeitgleich mit LLMs erscheint, einer AI-Technologie, die extrem gut mit Text umgehen kann. Doch diesen glücklichen Umstand nutzen aktuell viele Systems Engineers und experimentieren mit beiden Technologien.

Die textuelle Notation ist zwar formal, aber dennoch „nur“ eine weitere Sicht auf das Modell. Die grafische Sicht hat nach wie vor ihre Existenzberechtigung und das eigentliche Modell enthält auch Informationen, die per default nicht in der textuellen Notation erscheinen.

In diesem Teil modellieren wir den Kontext unseres Systems und definieren die wichtigsten Aktoren und Anwendungsfälle. Dabei setzen wir auf der SYSMOD-Bibliothek auf und untersuchen, wie Syside das Modell textuell und grafisch abbildet.

Schritt 2 im Entwicklungsprozess: Idee konkretisieren

Im ersten Schritt ging es um das Stakeholderproblem, welches wir fast übertrieben lösungsneutral festgehalten haben. Hier sind drei Umsetzungsstrategien, die alle das Stakeholderproblem lösen, sich aber drastisch voneinander unterscheiden:

• Klimaanlage für das Gebäude
• Persönlicher Tischventilator
• Wassereimer für die Füße

Bevor wir weitermachen können, müssen wir uns für eine konkrete Idee entscheiden, die wir weiterverfolgen werden. Wie wir das machen, ist im Schritt „System Idea“ festgehalten:

Auch wenn es schon klar ist, wo die Reise hingeht (Tischventilator), so soll hier gezeigt werden wie wir diese Entscheidung systematisch fällen. Zunächst halten wir unsere Idee fest. Die Idee ist als doc-Element Teil von DeskCoolingSystem, was wiederum im Kontext liegt:

Systemidee: model/DeskCoolingSystemIdea.sysml

#systemContext part def DeskCoolingSystemIdeaContext {
    part def DeskCoolingSystem {
        doc
        /* System idea: a tabletop fan for a single workplace.
         *
         * The device stands on the desk next to the person it serves and cools
         * them by directing a stream of the surrounding room air at them, rather
         * than by lowering the temperature of the room. It draws its power from
         * a USB port of the equipment already on the desk, so that it needs no
         * installation, no mains outlet of its own, and no servicing.
         *
         * This is a commitment to a kind of solution, not a design. How the
         * airflow is produced, directed, and controlled is decided in
         * activity 5. */
        port powerPort {
            doc
            /* Port through which the system receives electrical power. */
        }
    }
}

Aktoren, Entscheidungen, Annahmen

Hier greifen wir schon etwas vor, denn die Definition des Systemkontexts kommt eigentlich erst in Schritt 3. Deswegen ist der hier abgebildete Kontext auch noch unvollständig. Um nun unsere Idee zu konkretisieren, müssen wir folgendes erfassen:

• Aktoren: Wer interagiert mit dem System? Dies sind nicht (unbedingt) die Stakeholder und können auch Dinge sein, wie die Energieversorgung
• Entscheidungen: Für welche Alternativen, die den Lösungsraum einschränken, haben wir uns bewusst entschlossen?
• Annahmen: Worauf verlässt sich unser System? Im Prinzip sind das Rahmenbedingungen, sowohl für das Funktionieren des Systems als auch für dessen Entwicklung.

Um dies in SysML abzubilden, brauchen wir entsprechende Datenstrukturen. Dazu benutzen wir SysML v2 Metadata, über das wir auch die Attributierung vorgeben können. Die folgende Datei enthält sowohl die Metadaten als auch die Entscheidungen und Annahmen:

Beispielhaft zwei Elemente:

• Decision D-03: The system is powered from a USB port of the equipment already on the desk. This keeps the device usable at an ordinary workplace with no preparation: no free mains outlet, no installation, and no charging routine.
• Assumption A-02: Moving unconditioned room air over a person relieves the sensation of being too warm at the temperatures that occur at an ordinary workplace.

Eine Visualisierung als SysML-Diagramm ist hier wenig hilfreich. Die Situation ist ähnlich wie bei den User Needs im ersten Teil. Wir könnten eine tabellarische Ansicht erzeugen, worauf ich hier aber verzichte, da der SysML v2-Code gut lesbar ist.

Traceability

Damit unsere Entscheidungen und Annahmen nicht im luftleeren Raum hängen, können wir hier explizit eine Traceability erstellen. Hier beispielhaft für D-03.

Systemidee: model/DeskCoolingDecisions.sysml

dependency d03MotivatedBy from d03 to FitsOrdinaryWorkplaces, ComfortWithoutAttention {
    doc
    /* D-03 serves use at an ordinary workplace without preparation, and
       without a charging routine for the desk worker to maintain. */
}

Schritt 3: Systemkontext

Auch wenn wir uns bei der Ideenfindung schon Gedanken über die Aktoren gemacht haben, so gehören diese in den Systemkontext. Hier sollten wir pragmatisch sein und nur das Modellieren, was wirklich relevant ist. Zum Beispiel hatten wir den OfficeNeighbor identifiziert, den wir weglasssen, da dieser eine untergeordnete Rolle spielt.

Abgesehen davon ist nicht jeder Stakeholder auch ein Actor und nicht jeder Actor ist ein Stakeholder.

Für unser Beispielprojekt haben wir nun drei Aktoren, wie im folgenden Kontextdiagramm zu sehen.

Leider stößt hier die grafische Visualisierung mit Syside, basierend auf TomSawyer, schon an ihre Grenzen. Das Defaultlayout war ziemlich breit, zu breit für das Einbinden in einen Blogartikel. Daher habe ich das Model händisch angepasst. wodurch einer der Konnektoren schief ist (eine Funktion zum Geradeziehen habe ich nicht gefunden).

Dies ist ein einfaches Diagramm mit einem System und drei Aktoren. Zumindest in der jetzigen Form ist das nicht skalierbar und auch vielen Stakeholdern nicht zumutbar. Daher wäre hier klar meine Empfehlung, den Kontext am Whiteboard mit den relevanten Stakeholdern zu erheben. Wichtig ist dann nur, Änderungen sauber nachzupflegen und veraltete Beschreibungen zu löschen.

Anwendungsfälle

Ein weiteres Ergebnis aus Schritt 3 sind die Anwendungsfälle. Für dieses Einfache Modell arbeiten wir zunächst mit dreien:

• PutIntoService: Das System wird in Betrieb genommen.
• ProvideRelief: Das System arbeitet normal.
• AdjustRelief: Das System wird vom Nutzer an sich ändernde Bedingungen angepasst.

Hier fängt das Modell an, etwas unübersichtlich und (unnötig?) komplex zu werden. Dazu gleich mehr. Hier zunächst für den dritten Use Case sowohl das textuelle als auch das grafische Modell:

AdjustRelief: model/DeskCoolingSystemContext.sysml

#systemUseCase use case def AdjustRelief {
    doc
    /* The desk worker changes how much relief the system gives. */
    subject deskCoolingSystem : DeskCoolingSystem;
    actor deskWorker;
    objective {
        doc
        /* The desk worker brings the amount of relief to what they
           currently want, including none at all, without leaving their
           work to do it. */
        frame concern simpleUseAndControl : SimpleUseAndControl;
    }
    attribute ucMotivation :>> ucMotivation = "What the desk worker wants changes during the day, with the room, their clothing, and what they are doing. Relief that cannot be changed is either too little or too much most of the time.";
    attribute ucTrigger :>> ucTrigger = "The desk worker asks the system for a different amount of relief.";
    attribute ucResult :>> ucResult = "The relief the system gives corresponds to what the desk worker asked for.";
    constraint precondition :>> precondition {
        doc
        /* The system is in service at the workplace. */
    }
    constraint postcondition :>> postcondition {
        doc
        /* The system gives relief at the level the desk worker asked
           for, and the desk worker did not have to interrupt their work
           to achieve it. Stopping the system is the case where that
           level is none. */
    }
    action acceptReliefSetting :> deskCoolingSystem.acceptReliefSetting;
    action deliverRelief :> deskCoolingSystem.deliverRelief;
    action indicateService :> deskCoolingSystem.indicateService;
    first start then acceptReliefSetting;
    first acceptReliefSetting then deliverRelief;
    first deliverRelief then indicateService;
    first indicateService then done;
}

Die grafische Darstellung ist nicht wirklich zu gebrauchen. Dafür ist die textuelle Version extrem lesbar und nützlich.

Parts, Part Defs und Vererbungsbeziehungen

Spätestens an dieser Stelle zeigt sich eine Eigenschaft von SysML v2, die eine steile Lernkurve erzeugt: Das Modell besteht nicht nur aus den sichtbaren Elementen, sondern aus relativ vielen Verweisen auf Definitionen, allgemeinere Elemente und geerbte Elemente. Das ermöglicht Wiederverwendung und eine sehr präzise Semantik. Beim Lesen muss man aber häufig mehreren Ebenen folgen.

Ein wichtiger Ausgangspunkt ist der Unterschied zwischen part def und part. Eine Definition beschreibt eine Klasse von Dingen. Eine Usage beschreibt, wie so ein Ding in einem konkreten Kontext vorkommt. Die Analogie zu Typ und Variable hilft als erste Näherung, auch wenn die SysML-v2-Semantik darüber hinausgeht. Die SysML-v2-Spezifikation beschreibt eine Usage explizit als Verwendung einer Definition in einem bestimmten Kontext.

Unser System taucht deshalb zunächst als Definition auf:

part def DeskCoolingSystem {
    port deskWorkerPort;
    port powerPort;
    port environmentPort;
}

Im Systemkontext gibt es dann ein konkretes Part, das durch diese Definition typisiert wird:

#System part deskCoolingSystem : DeskCoolingSystem :>> soi;

DeskCoolingSystem sagt also, was für ein System wir modellieren. deskCoolingSystem sagt, welche Rolle dieses System in diesem Kontext spielt.

Damit ist die Kette aber noch nicht zu Ende. In Schritt 3 verfeinern wir die Definition aus der Systemidee:

part def DeskCoolingSystem :> DCD_IDEA::DeskCoolingSystem {
    port :>> deskWorkerPort {
        out item coolingEffect : CoolingEffect;
        out item serviceIndication : ServiceIndication;
        in item reliefSetting : ReliefSetting;
    }
    // ...
}

Es gibt damit zwei Definitionen mit demselben einfachen Namen in unterschiedlichen Packages. DCD_CONTEXT::DeskCoolingSystem spezialisiert DCD_IDEA::DeskCoolingSystem. Die erste Definition sagt im Wesentlichen: Wir entwickeln einen USB-betriebenen Tischventilator mit diesen Schnittstellen. Die zweite Definition behält diese Aussage bei und konkretisiert, was über die Schnittstellen ausgetauscht wird und welches Black-Box-Verhalten das System anbietet.

Dasselbe Prinzip wird auf den Kontext angewendet:

#systemContext part def DeskCoolingSystemContext
    :> DCD_IDEA::DeskCoolingSystemIdeaContext {
    #System part deskCoolingSystem
        :>> DCD_IDEA::DeskCoolingSystemIdeaContext::deskCoolingSystem
        : DeskCoolingSystem;
    // Use Cases ...
}

Der DeskCoolingSystemContext aus Schritt 3 spezialisiert also den DeskCoolingSystemIdeaContext aus Schritt 2. Gleichzeitig wird das darin geerbte deskCoolingSystem neu definiert und mit der detaillierteren DeskCoolingSystem-Definition typisiert.

Damit entsteht eine Verfeinerungskette:

System Idea
    DeskCoolingSystemIdeaContext
        deskCoolingSystem : DCD_IDEA::DeskCoolingSystem
                ↓
Specification Context
    DeskCoolingSystemContext
        deskCoolingSystem : DCD_CONTEXT::DeskCoolingSystem

Das vermeidet Duplikation. Der Spezifikationskontext muss die drei Aktoren und die grundsätzlichen Schnittstellen nicht noch einmal definieren. Er erbt sie aus dem System-Idee-Kontext und ergänzt nur die Information, die in diesem Entwicklungsschritt hinzukommt.

SYSMOD bringt eine weitere Ebene ins Spiel

Hinzu kommt die SYSMOD-Bibliothek. Sie liefert unter anderem generische Konzepte wie Project, SystemContext, actors, soi, useCases, systemIdeaContext und specificationContext. Auch die Schlüsselwörter #project, #systemContext und #systemUseCase stammen aus dieser Bibliothek.

Dadurch können wir zum Beispiel schreiben:

#User part deskWorker :> actors;
#ExternalSystem part usbPowerSource :> actors;

actors muss nicht in unserem Modell definiert werden. Es ist bereits Bestandteil des generischen SYSMOD-Systemkontexts. Ebenso kommt soi, das System of Interest, aus dieser Bibliothek. SYSMOD definiert außerdem bereits eine Sammlung useCases für die Use Cases eines Systemkontexts. (GitHub)

Auf Projektebene wird die Wiederverwendung noch deutlicher:

part deskCoolingIdeaContext
    :>> systemIdeaContext
    : DCD_IDEA::DeskCoolingSystemIdeaContext;
part deskCoolingContext
    :>> specificationContext
    : DCD_CONTEXT::DeskCoolingSystemContext
    :> deskCoolingIdeaContext;

Hier wird das generische SYSMOD-Projekt auf unser Produkt zugeschnitten. deskCoolingIdeaContext ersetzt bzw. verfeinert den von SYSMOD vorgesehenen systemIdeaContext. deskCoolingContext macht dasselbe mit specificationContext und steht zusätzlich in Beziehung zum vorhergehenden deskCoolingIdeaContext.

Das ist der große Vorteil einer Bibliothek wie SYSMOD: Projektstruktur, methodische Rollen und viele wiederkehrende Modellierungsmuster müssen nicht für jedes Produkt neu erfunden werden. SYSMOD selbst modelliert eine Kette vom Brownfield-Kontext über System Idea und Specification Context bis zu späteren Architekturen. Unser zugeschnittener Prozess überspringt den Brownfield-Kontext, nutzt aber die restliche Struktur weiter.

Der Preis dafür ist Indirektion. Wer beispielsweise deskCoolingContext verstehen will, muss unter Umständen dessen Definition, den System-Idee-Kontext, die geerbten Elemente sowie die entsprechenden SYSMOD-Elemente ansehen. Schon bei einem kleinen Beispiel verteilt sich die Bedeutung eines Elements damit über mehrere Dateien und Ebenen.

:, :>, :>> und #

Einen großen Teil dieser Beziehungen drückt SysML v2 mit drei sehr ähnlichen Operatoren aus:

Das ist gerade für Einsteiger verwirrend, aber wichtig. Derselbe Operator :> hat je nach Elementart einen anderen präzisen Namen. Bei einer Definition ist es Spezialisierung:

part def DeskCoolingSystem
    :> DCD_IDEA::DeskCoolingSystem;

Das darf man bei SysML v2 auch ausschreiben:

part def DeskCoolingSystem
    specializes DCD_IDEA::DeskCoolingSystem;

Bei einer Usage bedeutet :> dagegen subsets. Ein gutes Beispiel sind unsere Aktoren:

#User part deskWorker :> actors;

deskWorker ersetzt actors nicht. Es ist ein konkreterer Bestandteil der allgemein definierten Menge der Aktoren. Dasselbe Prinzip verwenden wir in den Use Cases:

action deliverRelief :> deskCoolingSystem.deliverRelief;

Die Aktion im Use Case ist eine konkrete Verwendung des bereits am System definierten Black-Box-Verhaltens.

:>> ist stärker. Es wird verwendet, wenn eine geerbte Usage im neuen Kontext neu definiert wird. Das passiert zum Beispiel hier:

port :>> deskWorkerPort {
    out item coolingEffect : CoolingEffect;
    out item serviceIndication : ServiceIndication;
    in item reliefSetting : ReliefSetting;
}

Der Port ist bereits in der Systemidee vorhanden. Im nächsten Entwicklungsschritt soll kein zweiter Port daneben entstehen. Stattdessen wird genau dieser geerbte Port verfeinert. Deshalb :>>.

Eine praktische Leseregel ist daher:

• : beantwortet die Frage „Durch welche Definition ist dieses Element typisiert?“.
• :> beantwortet „Welche allgemeinere Definition oder Usage spezialisiere beziehungsweise subsette ich?“.
• :>> beantwortet „Welche geerbte Usage verfeinere ich an genau dieser Stelle?“.

Die SysML-v2-Spezifikation verwendet dafür ausdrücklich die Begriffe defined by, specializes beziehungsweise subsets und redefines; Redefinition ist dabei selbst eine besondere Form des Subsettings.

Die ausgeschriebenen Schlüsselwörter sind übrigens gültige SysML-v2-Syntax. Aus

part deskCoolingSystem : DeskCoolingSystem :>> soi;

kann man gedanklich (und auch schriftlich) also

part deskCoolingSystem
    defined by DeskCoolingSystem
    redefines soi;

machen. Gerade beim Einstieg ist diese Langform wesentlich leichter zu lesen.

Zuletzt haben wir noch #, was eine Metadaten-Annotation kennzeichnet:

#User part deskWorker :> actors;

#User klassifiziert das nachfolgende Modellelement zusätzlich als User. User ist in unserem Fall eine von SYSMOD bereitgestellte Metadatendefinition.

Dabei bedeutet:

• #User: semantische Kennzeichnung als Benutzer/Aktor
• part deskWorker: die eigentliche Part Usage
• :> actors: deskWorker ist ein Subset der allgemeineren actors-Usage

Das # ist also weder Teil des Namens noch ein Kommentar oder Präprozessorzeichen. Es hängt zusätzliche, maschinenlesbare Bedeutung an das Element.

Eine metadata def kann auch eigene Attribute enthalten. Beim Anwenden der Annotation können wir diese Attribute mit Werten belegen.

Die starke Wiederverwendung von Definitionen, Subsettings und Redefinitionen ist eine Stärke von SysML v2. Sie verhindert, dass dieselbe Information an mehreren Stellen kopiert wird. Gleichzeitig entsteht eine hohe Navigationslast. Auch ein kleines Modell verlangt deshalb ein Verständnis von Definitionen und Usages, Namespaces, Spezialisierung, Subsetting, Redefinition und den verwendeten Bibliotheken. Die Syntax ist kompakt, die dahinterliegende Semantik nicht.

Was habe ich davon?

Das Beispiel ist fachlich sehr klein. Trotzdem entsteht bereits eine überraschend tiefe Modellstruktur. Das liegt zum Teil gerade daran, dass wir die Mechanismen von SysML v2 und SYSMOD konsequent verwenden: Definition und Usage, Spezialisierung, Subsetting, Redefinition sowie die schrittweise Verfeinerung der SYSMOD-Kontexte. Diese Mechanismen vermeiden Duplikation und schaffen eine präzise Semantik. Der Preis ist eine erhebliche Navigations- und Lernlast.

Für dieses Projekt würde ich daher nichts Wesentliches flatten. Gerade weil das Repo SysML v2 mit Methode demonstrieren soll, ist die entstehende Komplexität selbst ein relevantes Ergebnis. Würde ich dagegen einen möglichst einfachen „Learn SysML v2 in 30 Minutes“-Demonstrator bauen, würde ich mehrere dieser Ebenen weglassen.

Was bekommen wir für diesen Aufwand?

• Fehler werden früher sichtbar. Syside validiert das Modell während des Tippens und prüft neben der Syntax auch zahlreiche semantische Regeln. Ein ungültiger Typ, eine fehlerhafte Referenz oder eine unzulässige Modellbeziehung wird dadurch direkt im Editor sichtbar. Das geht zwar über einen einfachen Syntaxcheck hinaus, allerdings werden nur Inkonsistenzen erkannt, für die eine formale Regel existiert. Dass beispielsweise eine Entscheidung zu keinem Stakeholder Need zurückverfolgt werden kann, ist nicht automatisch ein SysML-Fehler. Dafür brauchen wir eine eigene Modellierungsregel. Syside Automator unterstützt solche projektspezifischen Prüfungen über Python.
• Wiederverwendung ohne Kopieren. Genau dafür gibt es das Zusammenspiel von Definitions und Usages. Eine Definition wie DeskCoolingSystem oder ein SYSMOD-Konzept wird einmal modelliert und kann in verschiedenen Kontexten verwendet und gezielt verfeinert werden. Änderungen müssen damit nicht in mehreren Kopien synchron gehalten werden. Die SysML-v2-Spezifikation nennt Wiederverwendung in unterschiedlichen Kontexten ausdrücklich als Zweck des Definition/Usage-Konzepts.
• Änderungsfolgen werden analysierbar. Explizite Beziehungen machen aus einer Änderung einen Ausgangspunkt für Impact Analysis. Wenn sich beispielsweise ein Stakeholder Need ändert, kann ich von dort zu Entscheidungen, Anforderungen, Architektur und später Verifikation navigieren, sofern wir diese Beziehungen modelliert haben. In Gegenrichtung lässt sich fragen: Warum existiert dieses Element? Syside unterstützt bereits auf Basisebene „Find References“ über das gesamte Modell und kann beim Umbenennen alle semantisch verbundenen Referenzen aktualisieren. Die eigentliche fachliche Impact Analysis geht darüber hinaus, basiert aber auf genau diesem Beziehungsnetz.

• Lücken lassen sich systematisch suchen. Sobald Beziehungen nicht nur in Texten beschrieben, sondern Teil des Modells sind, wird Gap Analysis möglich. Wir können beispielsweise prüfen: Gibt es eine Entscheidung ohne zugrunde liegenden Need? Einen #User ohne Stakeholder? Eine Anforderung ohne Ursprung? Später eine Anforderung ohne Verifikation? Solche Fragen lassen sich über das Modell automatisieren und als projektspezifische Validierungsregeln formulieren. Syside Automator unterstützt dafür programmatischen Modellzugriff und eigene Validierungsregeln.
• Traceability bekommt Semantik. Ein Link in SysML unterscheidet Typisierung, Spezialisierung, Subsetting, Redefinition, Satisfaction, Verification und weitere Beziehungen. Damit lässt sich nicht nur feststellen, dass zwei Elemente zusammenhängen, sondern wie. SysML v2 wurde ausdrücklich darauf ausgelegt, Konsistenz und Traceability zwischen Anforderungen, Verhalten, Struktur, Analyse und Verifikation zu erhalten.
• Änderungen werden versionierbar und überprüfbar. In diesem Fall liegt das Modell textuell vor und wir können normale Versionsverwaltung einsetzen. Ein Git-Diff zeigt, welche Modellzeilen geändert wurden, Änderungen können über Branches und Pull Requests geprüft werden und die Historie bleibt erhalten. Sensmetry nennt die Nachvollziehbarkeit von Änderungen über Git ausdrücklich als Vorteil des „System as Code“-Ansatzes. Die SysML v2 API unterstützt ebenfalls Versionierung und ist eine Alternative zum textbasierten Ansatz, den wir demnächst ebenfalls genauer beleuchten werden.
• Das Modell wird maschinell auswertbar. Aus derselben Modellstruktur lassen sich Diagramme, Tabellen, Dokumentation, Qualitätsprüfungen oder eigene Analysen erzeugen. Syside trennt das inzwischen klar auf: Der Editor unterstützt Modellierung und Validierung, der Modeler erzeugt Ansichten und Diagramme und Automator erlaubt Python-basierte Analysen und Reports. Gerade die präzisen Beziehungen, die das Modell beim Lesen komplizierter machen, liefern dafür die notwendige Struktur.

Damit verschiebt sich auch die Bewertung der Komplexität. Eine lange Kette aus Definition, Usage, Spezialisierung und Redefinition ist zunächst schwieriger zu lesen als eine Tabelle oder ein Diagramm mit ein paar Kästen. Dafür ist die Bedeutung dieser Kette für ein Werkzeug eindeutig.

Ob sich dieser Aufwand lohnt, hängt stark davon ab, wie viel Nutzen unsere Stakeholder aus dem Modell ziehen. Und wie schnell der Nutzen bei diesen ankommt.

Im nächsten Teil schauen wir uns dann Anforderungen und Architektur mit SYSMOD und SysML v2 an.