Grundlagen des Modellbasierten System-Engineering (MBSE)

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Linutronix GmbH

Willert Software Tools GmbH

Software und Systeme werden zunehmend schwieriger versteh- und beherrschbar. Infolgedessen wenden sich immer mehr Entwickler modellbasiertem System-Engineering (MBSE) zu. Was gibt es dabei zu beachten?

Seit einiger Zeit erlebt die modellgetriebene Entwicklung im Software und vor allem auch im Systems Engineering (MBSE) gesteigertes Interesse. Die häufig immer noch im Software Engineering verwendeten 3 GL (third generation language), z.B. ANSI C, aber auch rein textuelle Spezifikationen, scheinen dabei der steigenden Komplexität immer weniger gerecht zu werden. Software und Systeme sind zunehmend schwieriger versteh- und beherrschbar.

Die Hoffnung, dieser Entwicklung mit Hilfe von grafischen Repräsentanzen zu begegnen, scheint die Haupt-Triebfeder. Dementsprechend werden fleißig Bilder gemalt und Systemaspekte grafisch dargestellt. Und tatsächlich helfen die grafischen Sichten dabei die Systeme besser zu verstehen. Mittel- bis langfristig entsteht jedoch eine neue Problematik.

Bildergalerie

Bildergalerie mit 9 Bildern

Wie wird die kontinuierlich ansteigende Anzahl der grafischen Sichten, die nun redundant zum Code existieren, gepflegt und konsistent zum Code gehalten? Der dafür notwendige Arbeitsaufwand übersteigt häufig die Kapazitäten im Alltag.

Wenn modellgetriebene Entwicklung neben den Qualitätsattributen auch die Effizienz im Engineering erhöhen soll muss es weit über eine Ansammlung händisch erstellten von grafischen Sichten hinausgehen. Dann muss es Sichten automatisch generieren, durch Simulation die Zukunft vorweg nehmen, in dem Annahmen zu frühen Zeitpunkten verifiziert werden und auf Basis von automatischer Korrelation die Konsistenz des Modells absichern. Dieser Artikel gibt in zwei Teilen einen kleinen Einblick welche Voraussetzungen dafür notwendig sind. Der erste Teil behandelt die stetig wachsende Komplexität von Systemen und Anwendungen, wie sich das Potential für Hidden Links dadurch erhöht, und welche möglichen Auswege aus diesem Dilemma existieren. Der zweite Teil behandelt Modellierung jenseits von einfachen grafischen Abbildungen: Wie lässt sich ein System in all seinen Abhängigkeiten darstellen, welche Ableitungen können so vorzeitig getroffen werden, und wie ist eine Modellierung mit zukünftigen Entwicklungen automatisiert möglich?

Steigende Komplexität von Systementwicklungen

Wachsende Komplexität ist eine wesentliche Ursache dafür, dass mit einem Vorgehen nicht mehr die gewünschten Ergebnisse hinsichtlich Qualitätsattribute und Produktivität erzielt werden. Um zu verstehen, warum und wie neue Arbeitsweisen und Prinzipien dem begegnen und auf welche Weise sie wirken, ist es hilfreich zu verstehen, wie Komplexität entsteht und sich auswirkt.

Glaubt man den aktuellen Theorien zum Thema Komplexität, dann liegt das Hauptproblem in der Wirkkette: Hidden Links => Emergenz => Dysfunktion (näher besprochen im Omega Tau Podcast: Interview mit Henning Butz über Komplexe Systeme).

Verborgene oder nicht direkt offensichtliche Abhängigkeiten (Hidden Link), führen bei Änderungen eines Gesichtspunktes des Systems zu sogenannten ‚emergenten Zuständen‘ in Bezug zu anderen Gesichtspunkten des Systems. Emergente Zustände sind Zustände, die nicht erwartet werden und damit ist auch das Verhalten innerhalb dieser Zustände nicht definiert. Dieses kann wiederum zu Fehlverhalten (Dysfunktion) führen.

Erhöht wachsende Komplexität das Potential für Hidden Links?

Ein Basis-Mechanismus, der seit Jahrzehnten im Engineering eingesetzt wird, um steigender Kompliziertheit zu begegnen ist Teile & Herrsche (hierarchische Dekomposition). Bei jeder Teilung einer Einheit in zwei Elemente ergeben sich potentiell neue Schnittstellen. Wie in Bild 2 zu sehen ist, wächst bei zunehmender Teilung die Anzahl der neuen Schnittstellen polynom zur Anzahl der einzelnen Elemente.

Die Anwendung von ‚Teile & Herrsche‘ verringert also die Kompliziertheit eines einzelnen Elements, erhöht aber gleichzeitig die Kompliziertheit der Interfaces zwischen den Elementen. Damit erhöht sich also letztendlich auch das Potential für Hidden Links.

Bisher haben wir die Interfaces lediglich auf einer Ebene betrachtet und sprechen aus diesem Grund nur von Kompliziertheit. In der Realität haben wir dieses Beziehungsgeflecht jedoch nicht nur auf einer Ebene, sondern parallel auf mehreren Ebenen. Bezogen auf das reine Software Engineering prägen sich Schnittstellen auf folgenden Ebenen aus:

• Zeit

• Datenfluss

• Logisches Verhalten

• Prioritäten

• Varianten (teuer, preiswert, kundenspezifisch)

• Versionen (über den Zeitverlauf)

• Betriebsmodi (z.B. Standardnutzung, Konfiguration, Service)

• Übergelagerte Kontrollflüsse (Not-Aus, Diagnosemodus, etc.)

Haben wir unser System häufig genug in Komponenten zerteilt, und ziehen sich nun Abhängigkeiten über mehrere der obigen Ebenen kreuz und quer über Komponenten hinweg, dann sind wir bei komplexen Systemen angelangt. Auf jeder Ebene prägen sich Interfaces einzelner Gesichtspunkte aus und die wenigsten davon sind in heutigen Systemen dokumentiert. Das Wissen über diese Interfaces befindet sich überwiegend in den Köpfen der Entwickler.

Es stellt sich die Frage, wie sich die Änderung einer Zeile Code potentiell hinsichtlich Varianten, Versionen, Betriebsmodi, zeitlichen Gesichtspunkten etc. auf das Gesamtsystem auswirken kann. In diesem Bewusstsein explodieren Testaufwände und doch bleibt das Gefühl, nicht ausreichend getestet zu haben. So spüren wir heute die Komplexität in vollem Umfang.

MBSE: Ausweg aus dem Komplexität-Dilemma

Wie wir eingangs näher betrachtet haben, kann sich schon die Änderung einer Zeile Code potentiell hinsichtlich Varianten, Versionen, Betriebsmodi, zeitlichen Gesichtspunkten etc. enorm auf die Komplexität des Gesamtsystems auswirken. Dies macht es schwierig, die weitere Entwicklung des Systems weiterhin sinnvoll in einem Modell abzubilden.

Um steigender Komplexität effizient zu begegnen haben sich folgende Maßnahmen als grundlegend hilfreich herausgestellt:

Bildergalerie

Bildergalerie mit 9 Bildern

• 1. Strukturierung und Elimination der Auswirkungen zwischen Ebenen auf Basis von Architektur-Mustern

• 2. Einschränkung der Ausprägung von Schnittstellen auf Basis von Contract-Based-Design (auch DbC - Design by Contract bzw. Entwurf gemäß Vertrag)

• 3. Strukturierte Speicherung von Link-Beziehungen zwischen System-Artefakten und darauf basierenden Traceability-Analysen

• 4. Anwendung von Abstraktion auf Basis von Musterbildung (Abstraktion und Standardisierung von Lösungsansätzen, z.B: durch höhere Notationen, wie UML)

Alle obigen Maßnahmen haben ihre Berechtigung und werden durch Modellgetriebenes Engineering adressiert. Im Folgenden werde ich mich jedoch auf die Betrachtung der Abstraktion auf Basis von Musterbildung konzentrieren.

Abstraktion durch Bildung von Mustern

Bitte zählen Sie einmal die in Bild 3a dargestellten Streichhölzer. Wenn Ihnen das zu unübersichtlich ist, versuchen Sie es einmal mit Abbildung 3b. Erkennen Sie den Unterschied? Das ist das Ur-Prinzip, das sich hinter Abstraktion verbirgt.

Was aus dem Beispiel mit den Streichhölzern nicht sofort ersichtlich wird, Abstraktion ist auch eine Form von Teile und Herrsche. Es ist die Konzentration der Darstellung auf ausgewählte Gesichtspunkte. Auf Kosten der besseren Verstehbarkeit werden bewusst andere Gesichtspunkte vernachlässigt.

Beispiel: Ein U-Bahn-Netz wird erst dann für die Meisten übersichtlich, wenn es abstrakt dargestellt wird. Die Information der realen Positionen der U-Bahnstationen wird dabei vernachlässigt. Wir wenden Teile & Herrsche nun auf die Beziehungen an, aber es gibt keine Vorteile ohne damit einhergehende Nachteile.

Wollen wir Systeme auf diese Weise vollständig beschreiben, benötigen wir mehrfache Sichten. Diese Überlappen sich in Ihren Inhalten und erzeugen Redundanzen. In den Bildern 4a und 4b ist das gut zu sehen: Dort sind drei Sichten auf unterschiedliche Gesichtspunkte dargestellt (statisches Design, logisches Verhalten, zeitliches Verhalten). Innerhalb der Sichten tauchen einzelne Elemente redundant auf. Ändert sich ein Element, muss es nun in verschiedenen Sichten geändert werden. Abgesehen vom damit verbundenen Aufwand stellt sich die Frage wo überhaupt in einem Modell ein Elemente verwendet wird? Redundanz erhöht nicht nur den Aufwand sondern an sich auch das Potential für ‚Hidden Links’.

Grundsätzlich können wir also davon ausgehen, dass die Erhöhung der Abstraktion immer auch mit der Erhöhung der Redundanz und damit dem Aufwand der Pflege unserer Abstrakten Sichten verbunden ist. Das ist ein bekanntes Problem. Sicherlich haben auch Sie abstrakte Sichten auf Ihren Code, und sei es eine mit Word erstellte Dokumentation. Welche der folgenden Aussagen trifft am besten den Zustand Ihrer Dokumentation?

• 1. Wir haben eine hervorragende Dokumentation, die sehr hilfreich ist.

• 2. Unsere Dokumentation ist sehr schlecht bis nicht existent.

• 3. Unsere Dokumentation ist gar nicht so schlecht. Das Problem ist die Inkonsistenz zum Code.

Erfahrungsgemäß antworten 95% aller Entwickler, dass die 3. Aussage am zutreffendsten ist. Was schließen wir daraus? Nicht die Dokumentation / Abstrakte Sicht an sich ist das Problem, sondern der Aufwand für Wartung und Pflege, um sie konsistent z.B. zum Source-Code (zur Realität) zu halten.

Natürlich gilt obiges auch für modellgetriebenes System-Engineering im allgemeinen und den Einsatz der UML im speziellen. Das ist der Grund, warum ‚Bildchen Malen‘ zwar kurzfristig hilft komplexe Systeme besser zu verstehen, aber mittel- bis langfristig zu Inkonsistenz führt. Die Sichten repräsentieren nicht mehr die Realität, was sie unbrauchbar macht. (Wrong documentation is worse than no documentation) Aus diesem Grund sollte man also grafische Repräsentanzen an sich noch nicht als Modell sehen. So steht es auch im MBSE-Manifest.

Ein Modell sagt mehr, als 1000 Bilder

Ein Modell im Sinne von MDSE geht über Grafische Repräsentanzen hinaus. Es besteht eher aus Artefakten und deren Korrelation, die in Summe ein System mit seinen Zusammenhängen repräsentieren und u.a. auch graphisch dargestellt werden können. Wichtig ist, dass die Definition der Artefakte auf einer Metastrukturen basiert. Nur dadurch wird eine automatisierte Verarbeitung, Korrelation, Verifikation etc. der Artefakte und deren Zusammenhänge ermöglicht. Das macht erst ein Modell aus.

Wir wollen das einmal an einem Beispiel exemplarisch aufzeigen. Stellen wir uns vor, es gäbe ein Modellelement ‚Dreieck’. Dieses wird in Form einer Notation (Notationselemente im Sinn eines Muster auf Basis von Regeln und Gesetzmäßigkeiten und einer Metastruktur) abgebildet. Die Metastruktur der Notation würde nicht nur Seitenlängen und Winkel kennen, sondern auch Gesetzmäßigkeiten, wie ‚rechtwinkliges‘ oder ‚gleichschenkliges‘ Dreieck oder so etwas wie den ‚Satz des Pythagoras‘. Und natürlich gäbe es ein Werkzeug, das diese Metastruktur versteht und anwenden kann. Die grafische Repräsentanzen sind nun nur Sichten auf das Model. Diese visualisieren Artefakte und deren Zusammenhänge.

Bildergalerie

Bildergalerie mit 9 Bildern

Legen wir z.B. die zwei Seitenlängen ‚a’ ‚b’ und einen Winkel auf Basis eines Editors in einem Datensatz ab, kann ein Werkzeug auf Basis dieser Daten in Kombination mit den Metadaten das Modell um die zwei anderen Winkel und die Länge der 3. Seite automatisch erweitern. (Siehe Bilder 5a und 5b).

Ein gutes Werkzeug erlaubt die Eingabe der Daten in Form der grafischen Repräsentanz und ermittelt automatisch die technischen Artefakte. Bessere Modellierungs-Werkzeuge ermöglichen auch die Eingabe der technischen Artefakte und können daraus verschiedene grafische Sichten automatisch erzeugen. Diese automatisierte Transformation in grafische Sichten verringert den Aufwand für die händische Pflege der Sichten und ist eine elementare Voraussetzung für die konsistente Aussagekraft von Modellen über den gesamten Lebenszyklus des Systems.

Aber es geht noch einen wesentlichen Schritt weiter. Ändern wir nun den Winkel ‚A‘ wird aus dem rechtwinkligen Dreieck evtl. ein gleichseitiges Dreieck. Sollte definiert sein, dass es sich in dieser speziellen Instanz eines Dreiecks um ein rechtwinkliges Dreieck handelt, kann das Modell die Daten gegeneinander korrelieren und uns eine Warnung generieren, dass nun Daten (evtl. Spezifikation und Implementation) in Konflikt stehen. Hier streifen wir bereits einen Aspekt des CBD (Contract Based Design).

Wir sehen also, ein Modell geht weit über die grafische Repräsentanz hinaus und ermöglicht eine weitaus mächtigere automatisierte Korrelation von Artefakten und deren Gesetzmäßigkeiten. Aber um das zu ermöglichen gibt es zwei Grundvorraussetzungen.

• 1. Modelle basieren auf einer Metastruktur (die Notationen UML und SysML bilden in diesem Sinn eine Metastruktur)

• 2. Deren präzise Anwendung

Letzteres ist selten der Fall. Was dann passiert sehen Sie, wenn Sie noch einmal einen genaueren Blick auf die Abbildung 3b werfen. Haben Sie dort 28 Streichhölzer gezählt? Das rechte obere Muster wurde nicht präzise angewandt, es stellt 6 Streichhölzer dar. Sie sehen, sobald die Präzision fehlt, ist unser Modell nicht mehr wirklich hilfreich.

Anwendungsfälle gehen mit bestimmtem Vorgehen einher

Modellgetriebenes System-Engineering (MBSE) geht weit über die Erstellung grafischer Darstellungen von Systemsichten hinaus wenn es das Engineering auf eine neue Ebene bringen soll. Und nur dann kann sie der steigenden Komplexität erfolgreich begegnen.

Dieser Artikel konnte nur einige Aspekte des modellgetriebenen Engineerings oberflächlich beleuchten. Es gibt viele Experten, die sich mit Fragestellungen und Lösungen zur Modellierung von Embedded Systemen auseinandersetzen. Erfahrungen und Erkenntnisse sind zum Beispiel im ‚Manifest Modeling of Embedded Systems‘ dokumentiert und online auf http://www.mdsemanifest.org abrufbar.

Modellbasierte Risikoanalyse sicherheitskritischer Systeme

Softwaremodellierung

Die Zeit ist reif für modellbasierte Softwareentwicklung!

* Andreas Willert ist Gründer und CEO der Willert Software Tools GmbH.

(ID:45240217)