Modellgetriebene Softwareentwicklung
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 Modellierungssprache 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.
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 25 Jahren erfolgreich bei unseren Kunden ein und wissen, wie es geht.
Single Source of Truth als Voraussetzung für effizientes Modellgetriebenes Software Engineering
Komplexität beherrschen, Ressourcen managen, Ziele erreichen: Erfolgreiche Projekte des Embedded Systems / Software Engineerings brauchen leistungsstarke, aufeinander abgestimmte Vorgehen, Werkzeuge und Kompetenzen. Das Prinzip Single Source of Truth ist ein wichtiges Element im Kontext von Modellgetriebenem Engineering.
In unserem Video erfahren Sie mehr.
Modellgetriebenes Software Engineering für effizientere und testbare Softwarearchitektur und Designs
Softwareentwickler stehen immer mehr unter Druck: Immer schneller müssen sie neue Codes entwickeln und anpassen, um mit den heutigen Innovationen mithalten zu können. Knapp gesteckte Deadlines und kurzfristige Änderungen stehen dabei an der Tagesordnung. Modelle helfen den nötigen visuellen Überblick zu behalten. Damit diese Modelle jederzeit konsistent zum jeweiligen Code sind, müssen sie kontinuierlich gepflegt und bei Änderungen angepasst werden.
Welche Lösung Ihnen Willert dazu bietet, sehen Sie in diesem Video.