Ein Angebot von

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

| Autor / Redakteur: Andreas Willert / Sebastian Gerstl

Bild 3a: Modelldarstellung ohne Abstraktion.
Bild 3a: Modelldarstellung ohne Abstraktion. (Bild: Andreas Willert)

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?

Wie wir im ersten Teil der Beitragsreihe zu Modellbasiertem System-Enineering (MDSE) 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:

  • 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 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 MDSE-Manifest.

Wenn aber grafische Repräsentanzen noch kein Modell sind - worauf kommt es bei einem Modell dann an? Darauf gehen wir

im dritten Teil dieses Beitrags näher ein.

Modellbasiertes System-Engineering, Teil 1: Evolution der Abstraktion

Modellbasiertes System-Engineering, Teil 1: Evolution der Abstraktion

17.04.18 - 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. lesen

Modellbasiertes System-Engineering, Teil 3: Ein Modell sagt mehr, als 1000 Bilder

Modellbasiertes System-Engineering, Teil 3: Ein Modell sagt mehr, als 1000 Bilder

30.04.18 - Grafische Repräsentanzen alleine machen noch kein Modell aus. Effizient angewandtes MDSE ist in der Lage, künftige Entwicklungen im Model vorauszuahnen und vorausschauend abzubilden. Wie geht das? 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: 45252287 / Software Engineering)