Model Driven SW Engineering

Abstraktion ist der mächtigste Mechanismus Komplexität zu begegnen. Abstraktion greift im Wesentlichen auf Muster und grafische Darstellung zurück. Auf Basis von Mustern kann unser Gehirn einmal gelernte komplizierte Konstrukte schnell assoziieren. Die grafische Darstellung abstrahiert deren Zusammenwirken auf Basis von verschiedenen Diagrammen hinsichtlich Zeit, Datenfluss, logischem Verhalten und statischem Design.
Die UML folgt diesem Ansatz. Sie fasst unter einem Notationselement (Objekt, Klasse, Port) ein in sich kompliziertes Muster zu einem Symbol zusammen. Das komplexe Zusammenwirken verschiedener Muster wird wiederum in verschiedenen Diagrammen dargestellt und liefert damit die Voraussetzung zum Verständnis komplexer Systeme.

Grph - Streichoelzer als Muster.png

Model Driven SW Engineering

Die UML setzt den Hebel gleichzeitig an mehreren Stellen an. Die beiden wichtigsten sind 'Musterbildung' und 'Verringerung der Informationsdichte'. Beide Mechanismen erhöhen die Verstehbarkeit. MDSE (Model Driven Software/Systems Engineering) nutzt die UML und fügt ihr weitere wichtige Elemente hinzu, wie frühzeitige Simulation, kongruente Darstellung verschiedener Sichtweisen, automatische Generierung von Code und Dokumentation.

Modelle schaffen die Möglichkeit den Blick auf einen bestimmten Ausschnitt zu richten und andere Facetten des Systems wegzublenden. Diese werden dann wiederum in anderen Sichtweisen dargestellt. Der Blick auf das jeweils wesentliche einer Sichtweise erhöht die Verstehbarkeit. Dieses Vorgehen folgt dem seit Jahrtausenden bewährten Muster "Teile und Herrsche".

Hochsprachen (3GL Notationen) kennen nur eine Sichtweise, dies zeigt immer alles. Das hat Vor- und Nachteile. Diese eine Sichtweise hat eine hohe Informationsdichte, und damit auch wenig Redundanz. Der Nachteil ist die schlechte Verstehbarkeit. 4GL Notationen wie z.B. die UML erweitern die Ansichten und reduzieren damit die Informationsdichte. Dadurch  erhöht sich die Verstehbarkeit, aber erkauft wird es mit erhöhter Redundanz und diesem Sachverhalt gehört große Aufmerksamkeit bei der Einführung von MDSE.

Die Pflege von redundanten Anteilen (z.B. Word Dokumentationen zum Source Code) ist schon immer eine Schwachstelle im SW Engineering gewesen. Die besten verstehbarsten UML Diagramme helfen nichts, wenn sie nicht kongruent zum real existierenden System und/oder Code sind. Wird dem keine Rechnung getragen bleibt unser ureigenes Problem existent und wir haben nichts gewonnen. Die redundanten Anteile werden über die Zeit inkongruent. Über Jahre gesehen tendiert der Nutzen, der zwar verstehbaren Diagramme, gegen Null. Sie liefern tendenziell inkongruenten Sachverhalt. (Kommt Ihnen diese Situation bekannt vor? Wir haben, anstelle von Word Dokumenten, UML Diagramme die nicht wirklich hilfreich sind.)

Hier setzt ein wichtiger Gesichtspunkt von MDSE an. Auf Basis von so genannten Repositories (Tool-proprietäre Datenbanken) und Modellierungs-Werkzeugen (die Codegenerierung, Reverse Engineering, Simulation etc. unterstützen) verschmelzen die redundanten Anteile und Darstellungen in ein homogenes Modell. Änderungen, in welcher Sichtweise oder Ebene auch immer durchgeführt, werden automatisch durch das Werkzeug in alle Redundanzen ausgeprägt.

  • Im Idealfall stellt das Modell ein monolithisches, zu jedem Zeitpunkt in sich kongruentes System dar,
  • das simuliert werden kann, um bereits in frühen Phasen Feedback zu bekommen
  • aus dem heraus Production-Code generiert wird, der genau das tut, was in den Diagrammen dargestellt ist
  • was verschiedene Sichtweisen liefert, um komplexe Sachverhalte schnell und fehlerfrei zu begreifen
  • aus dem, zu jedem Zeitpunkt, eine aktuelle Dokumentation generiert werden kann

Wenn Sie also Ihr ureigenes Problem, die Inkongruenz von redundanten Anteilen Ihrer Systembeschreibungen, nicht verschlimmbessern möchten wird Ihnen das Lesen eines UML-Buches und dem anschließenden zeichnen von UML Diagrammen mit MS Visio, nicht viel weiter helfen.

Sprechen Sie mit uns, wir führen MDSE seit den 90er Jahren erfolgreich bei unseren Kunden ein und wissen wie es geht.

 

Managements Interest

Immer mehr Studien zum Thema MDSE zeigen in ihren Ergebnissen, wenn alle Komponenten stimmig sind (Notation, Werkzeug, Ausbildung und Kenntnisstand der Mitarbeiter, Methode und Prozess), können bereits wenige Monate nach der Einführung von MDSE Effiziennzsteigerungen von 20% - 30% erreicht werden. Langfristig über mehrere Jahre gesehen (wenn in Folge auch Wiederverwendbarkeit, Änderbarkeit, Robustheit, vereinfachte Test-Automatisierung anfangen zu wirken) sind Effizienzsteigerungen um Faktor 2 bis 3 realistisch.

Damit amortisiert Sich die Einführung von MDSE bereits innerhalb eines Jahres und hat enormes Potential die Entwicklungskosten über Jahre hinaus zu senken, bei gleichzeitiger Verkürzung von ,Time To Market‘ und Sicherung der Qualität trotz steigender Komplexität.

Aber die Einführung von MDSE ist, gegenüber der Herkömmlichen Programmierung in Hochsprachen, ein Paradigmen Wechsel. Die Investitionen sind erheblich und werden auf der Ebene von Entwicklung oder Projektleitung in der Regel nur halbherzig getroffen. Dabei bleiben wichtige Gesichtspunkte auf der Strecke und Amortisation der Investitionen treten dann nur in seltenen Fällen ein.

Die Entscheidungsverantwortung zur Einführung von MDSE liegt in der Geschäftsebene des Unternehmens, die sich z.B. auch für die Entscheidung der Einführung von SAP verantwortlich fühlen würde. Wahrscheinlich das gehobene Management.