Software Tools

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.