Modellbasiertes System-Engineering, Teil 1: Evolution der Abstraktion

| Autor / Redakteur: Andreas Willert / Sebastian Gerstl

Bild 1: Die vier Evolutionsstufen des Modellbasierten System-Engineering.
Bild 1: Die vier Evolutionsstufen des Modellbasierten System-Engineering. (Bild: Andreas Willert)

Software und Systeme werden zunehmend schwieriger versteh- und beherrschbar. Infolgedessen wenden sich immer mehr Entwickler modellgetriebenem Engineering zu. Was gibt es dabei zu beachten? Teil 1 einer dreiteiligen Reihe zu MDSE.

Seit einiger Zeit erlebt die modellgetriebene Entwicklung im Software und vor allem auch im Systems Engineering (MDSE) 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.

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?

Bild 2: Anzahl der Interfaces wachsen polynom zur Anzahl der Elemente.
Bild 2: Anzahl der Interfaces wachsen polynom zur Anzahl der Elemente. (Bild: Andreas Willert)

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.

Im zweiten Teil dieses Beitrags werden wir näher darauf eingehen, wie wir mittels Modellbasiertem System-Engineering einen Ausweg aus diesem Komplexitäts-Dilemma finden.

Modellbasiertes System-Engineering, Teil 2: Ausweg aus dem Komplexitäts-Dilemma

Modellbasiertes System-Engineering, Teil 2: Ausweg aus dem Komplexitäts-Dilemma

23.04.18 - Im Laufe der Entwicklung nimmt die Komplexität eines Systems – und damit die Zahl interner Verlinkungen – quasi exponentiell zu. Wie kann mittels Modellierung sinnvoll ein Überblick behalten werden? lesen

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

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45240217 / Tools & Softwarekomponenten)