Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Ein Modell sagt mehr als 1000 Bilder!

Autor: Andreas Willert, Willert Software Tools

Beitrag - Embedded Software Engineering Kongress 2017

 

Die Evolution der Abstraktion

Seit einiger Zeit erlebt die modellgetriebene Entwicklung ein gesteigertes Interesse. Die häufig immer noch im Software Engineering verwendeten 3 GL (third generation language, auch high-level programming language), wie ANSI C, scheinen der steigenden Komplexität zunehmend weniger gerecht zu werden.

Die Hoffnung, die Verstehbarkeit auf Basis von grafischen Repräsentanzen zu erhöhen, ist die Haupt-Triebfeder. Dementsprechend werden fleißig Bilder gemalt und Systemanteile grafisch dargestellt. Und tatsächlich helfen die grafischen Repräsentanzen dabei, die Systeme besser zu verstehen. Wird das einige Zeit betrieben, kommt eine andere Problematik wie ein Bumerang zurück.

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

Dieser Artikel soll aufzeigen, dass modellgetriebenes Engineering weit mehr ist als eine grafische Repräsentanz. Er soll auch aufzeigen, dass die reine Erstellung einer grafischen Repräsentanz in einer Sackgasse mündet. Sie erhöht die Verstehbarkeit auf Kosten von erhöhter Redundanz und damit erhöhtem Pflegeaufwand.  Damit verbunden sinkt die Arbeitseffizienz.

Nur wenn redundante Anteile durch Werkzeuge automatisiert angepasst, Änderungen einer Komponente gegenüber dem Gesamtsystem automatisch korreliert, Tests automatisiert und Code generiert … also wo immer möglich Abläufe und Arbeitsschritte automatisiert werden, kann sich modellgetriebene Entwicklung langfristig erfolgreich durchsetzen.

Komplexität

Wachsende Komplexität ist die wesentliche Ursache, warum wir mit einem Vorgehen nicht mehr die gewünschten Ergebnisse erzielen. 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. Aus diesem Grund möchte ich zum Einstieg die Komplexität etwas näher betrachten.

Glaubt man den aktuellen Theorien zum Thema Komplexität, dann liegt das Hauptproblem in der Wirkkette: Hidden Links -> Emergenz -> Dysfunktion.

Das bedeutet, verborgene Abhängigkeiten führen bei Änderungen eines Gesichtspunktes des Systems zu sogenannten emergenten Zuständen in Bezug zu anderen Gesichtspunkten des Systems. Ein Zusammenhang beider Gesichtspunkte ist nicht offensichtlich und bildet einen Hidden Link. Dies kann wiederum zu Fehlverhalten (Dysfunktion) führen.

Gehen wir noch einen Schritt zurück, wie entstehen Hidden Links?

Ein Basis-Mechanismus, der seit Jahrzehnten im Engineering eingesetzt wird, um steigender Kompliziertheit zu begegnen, ist "Teile & Herrsche"; im Engineering unter anderem auch in Form von "hierarchischer Dekomposition" angewandt. Bei jeder Teilung einer Einheit in zwei Teileinheiten ergeben sich potentiell neue Schnittstellen. Wie in der folgenden Abbildung 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 Komplexität eines einzelnen Teils, erhöht aber gleichzeitig die Kompliziertheit der Interfaces zwischen den Teilen. 

Bisher haben wir die Interfaces lediglich auf einer Ebene betrachtet und sprechen aus diesem Grund nur von Kompliziertheit. In der Realität heutiger Embedded Applikationen haben wir dieses Beziehungsgeflecht jedoch nicht nur auf einer Ebene, sondern parallel auf mehreren Ebenen. Erschwerend kommt hinzu, dass die Grenzen zwischen zwei Komponenten, bezogen auf verschiedene Ebenen und/oder Sichtweisen, nicht unbedingt gleich verlaufen. Zum Beispiel entsprechen logische Komponenten nicht exakt den physikalischen Komponenten - analog sehr gut zu sehen bei der Darstellung von U-Bahnnetzen. Die grafische Darstellung des Fahrplans entspricht nur sehr bedingt dem realen Verlauf der U-Bahn, dient aber dem besseren Verständnis (siehe dazugehörige Abbildung, PDF).

Betrachten wir exemplarisch das Software Engineering, dann haben wir es in der Regel mit mindestens folgenden Ebenen zu tun:

  • Zeit
  • Datenfluss
  • Logisches Verhalten
  • Prioritäten
  • Varianten
  • Versionen
  • Betriebsmodi

 

Aus Applikationssicht kommen in der Regel noch weitere Ebenen hinzu, z.B. in Form von überlagerten Kontrollflüssen, wie beispielsweise Not-Aus, Software-Update oder Service & Diagnose Modus. Auf jeder Ebene ergeben sich Interfaces einzelner Gesichtspunkte zueinander, und die wenigsten davon sind in heutigen Systemen dokumentiert. Das Wissen über diese Interfaces befindet sich in der Regel in den Köpfen der Entwickler. 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. Dann stellt sich die Frage, wie sich die Änderung einer Zeile Code potentiell hinsichtlich Varianten, Versionen, Betriebsmodi, zeitlichen Gesichtspunkten … auf das Gesamtsystem auswirkt. Eine der vielen Auswirkungen in diesem Kontext: Testaufwände scheinen zu explodieren - und doch bleibt das Gefühl, nicht ausreichend getestet zu haben. So spüren wir heute die Komplexität in vollem Umfang in verschiedensten Gesichtspunkten. 

Häufig wird vergessen, dass nach jeder hierarchischen Dekomposition der Schritt der Aggregation (Zusammensetzen einzelner Komponenten zu einem Gesamtsystem) folgen muss. Spätestens an dieser Stelle müssen alle Schnittstellen und vor allem deren Auswirkungen im Gesamtsystem wieder homogen zueinander passen. Wird ein Zusammenhang übersehen, ist das der Einstieg in die Wirkkette Hidden Links -> Emergenz -> Dysfunktion.

Um einem Gedankengang grundsätzlich vorzubeugen: "Teile & Herrsche" ist immer noch unverzichtbare Grundlage zum Managen von Kompliziertheit und Komplexität. Aber für letzteres benötigen wir darüber hinaus Mechanismen, um die angestiegene Komplexität der Interfaces wieder zu beherrschen.

Unser Gehirn als Engpass

Die Neurobiologie besagt, dass unser Gehirn auf der bewussten Ebene ca. 7 +/- 2 Artefakte und/oder Beziehungen in einem Augenblick überblicken (begreifen) kann. Verglichen mit der Anzahl an potentiellen Artefakten und Schnittstellen komplexer Systeme ist das nicht sehr viel. Stellen Sie sich vor, Sie haben gerade 7 Artefakte parat und deren Zusammenhänge logisch durchdacht, dann fällt Ihnen ein 8. Artefakt ein. Im selben Moment fällt eines der vorherigen Artefakte, wie bei einem Schieberegister, aus Ihrem Fokus heraus. Und das geschieht, ohne dass unser Bewusstsein uns darauf aufmerksam macht. Wir merken für gewöhnlich nicht, dass wir in diesem Moment gerade etwas vergessen. Stattdessen befinden wir uns in dem Irrglauben, alles berücksichtigt zu haben. Gibt es nun zufällig einen logischen Zusammenhang zwischen dem 8. neuen Artefakt und dem gerade herausgefallenen, haben wir eine potentielle Situation für die Entstehung eines Hidden Link.

Wenn wir nun bedenken, dass heutige komplexe Systeme tausende an Artefakten haben, die über deutlich mehr als 7 Ebenen potentiell in Beziehung stehen können, ist es naheliegend, dass es ein Trugschluss ist zu glauben, unser Gehirn sei in der Lage, die möglichen Auswirkungen von Änderungen rein gedanklich vollständig zu durchdringen.

Abgesehen davon versagt unser Gedächtnis bereits, wenn es die möglichen Zusammenhänge einer begrenzten Auswahl an Artefakten aus dem Stegreif auflisten sollte. Und jetzt stellen Sie sich noch die Entwicklung eines komplexen Systems auf Basis von vielen Gehirnen vor, in denen keines der Gehirne das Gesamtsystem mit all seinen potentiellen Zusammenhängen kennt, sondern immer nur Anteile des Systems.

Wenn also ein einzelnes Gehirn nicht mehr alle Zusammenhänge kennt, bleibt die spannende Frage: Welche anderen Gehirne des Teams soll es zu Rate ziehen, um mit Sicherheit alle Abhängigkeiten herauszufinden?

Noch eines zeigt die Neurobiologie. Wahrscheinlich wäre unser Unterbewusstsein in der Lage, uns aus dem Dilemma zu helfen, denn unser Unterbewusstsein scheint einem optimalen Gedächtnis sehr nahe zu kommen. Nur ist die Menschheit noch nicht in der Lage, deterministisch mit dem Unterbewusstsein zu arbeiten, und so lange müssen wir andere Wege gehen, wenn wir komplexe Systeme entwickeln möchten, die sich am Ende deterministisch verhalten sollen. (In einem 5 Min. Video auf YouTube erklärt Prof. Kruse sehr eindrücklich, wie der Komplexität in Zukunft begegnet werden kann.)

Ausweg aus dem Dilemma

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

  1. Strukturierung und Elimination von Ebenen und Beziehungen auf Basis von Architektur-Design
  2. Einschränkung der Ausprägung von Schnittstellen auf Basis von Contract-Based-Design (auch DbC Design by Contract - 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)

Die 1. Maßnahme beruht darauf, über geeignete Ausprägung der Schnittstellen das Beziehungsgeflecht einfach und verstehbar zu halten. Diesen Aspekt werden wir an dieser Stelle nicht weiter verfolgen.

Die 2. Maßnahme Contract-Based-Design ist eine hervorragende Möglichkeit, Ausprägungen von Schnittstellen einzuschränken, und/oder die Basis, diese automatisiert zu prüfen. Obwohl erste Ansätze bereits 1985 in der Programmiersprache "Eiffel" durch Bertrand Meyer eingeführt wurden, konnte sich CBD noch nicht breitflächig durchsetzen. Notationen, wie UML in Verbindung mit Stereotypen, bieten sehr gute Voraussetzungen zur Anwendung von Contract-Based-Design und damit die Basis für eine weitere Verbreitung. Auch diesen Ansatz werden wir an dieser Stelle nicht direkt verfolgen, aber an der einen oder anderen Stelle tangieren.

Auch für die 3. Maßnahme, Analysen auf Basis von Traceability, liefert die modellgetriebene Entwicklung auf Basis von 4 GL Notationen gute Grundlagen. Z.B. kennt die Notation UML / SysML Linkbeziehungen zwischen Notationselementen. Mit Linkbeziehungen können Zusammenhänge deklariert und auf dieser Basis in Folge aussagekräftige Traceability-Analysen erzeugt werden. Um Linkbeziehungen speichern zu können, benötigen die zu verlinkenden Elemente eineindeutige Identifier (UUIDs). 3 GL Notationen, wie C oder C++, haben keinerlei Metastrukturelemente, mit denen diese abgebildet werden können. Auch die Editoren, auf deren Basis diese Notationen angewandt werden, liefern hier keine Lösung.

Wie also kann z.B. eine Anforderung explizit zu einer C-Anweisung verlinkt werden? (Achtung: Die häufig anzutreffende Praxis des Verlinkens zu Commit-Statements eines Config-Management-Systems oder anderen dynamischen Artefakten ist an dieser Stelle keine wirkliche Lösung - aber das ist ein ganz anderes Thema, welches an dieser Stelle den Rahmen sprengen würde).

Auch diese mögliche Maßnahme wird nicht Bestandteil der folgenden Betrachtungen sein (siehe dazugehörige Abbildung, PDF).

Nachfolgend werden wir uns im Wesentlichen mit der 4. Maßnahme beschäftigen: Abstraktion durch Musterbildung und Metastruktur durch Notationen wir der UML.

 

Leider sind an dieser Stelle die 10.000 Zeichen erreicht. Wie immer in diesem Tagungsband reicht der Platz nicht, um den vollen Inhalt meiner Präsentation als Paper niederzuschreiben. Möchten Sie weiterlesen, dann können Sie das ganze Paper unter diesem Link laden.

Beitrag als PDF downloaden


Modellierung - MicroConsult Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung /Embedded- und Echtzeit-Softwareentwicklung.

 

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.


Modellierung - Fachwissen

Wertvolles Fachwissen zum Thema Modellierung /Embedded- und Echtzeit-Softwareentwicklung steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.