Effizienter mit OOP, Modellierung, Req. Engineering und Co?

Artikel zum Downloaden 

Nicht immer führt die Einführung einer neuen Methode oder eines Werkzeuges zur erwarteten Steigerung der Effizienz. Daraus zu schließen, Werkzeug oder Methode funktionieren nicht, wäre voreilig. Ursachen dafür gibt es viele, unter anderem falsche Erwartungen. Zum Beispiel, wenn mit der Einführung der Notation C++ in Kombination mit einem 
C++ Compiler die Erwartung verbunden ist, dass die Methode OOP damit automatisch folgt. Die Enttäuschung ist dann vorpro-grammiert. In diesem Artikel wird exemplarisch am Beispiel der Modellierung gezeigt, was schief laufen kann, wenn falsche Ziele angesteuert werden.

Zum Beispiel die Anwendung der UML!

Eines ist gewiss: Die stetige und mit steigender Geschwindigkeit wachsende Komplexität heutiger Systeme. Um dem gerecht zu werden müssen wir mit neuen Vorgehen im Engineering reagieren. Aber nicht immer bringen diese den gewünschten Erfolg. Das bedeutet jedoch nicht, dass die Werkzeuge, Methoden oder Notationen deswegen nicht leistungsfähig sind. Oft werden mit neuen Engineering Vorgehen lediglich die Symptome bekämpft und nicht die Ursachen der Problematik. Exemplarisch für die Modellierung mit UML soll an dieser Stelle gezeigt werden woran es liegen kann, wenn erwartete Erfolge ausbleiben.
Der häufigste Grund warum die UML eingesetzt wird den ich derzeit höre ist die Verbesserung der Verstehbarkeit und Dokumentation von Software.
Seit einigen Jahren befrage ich Software-Entwickler, z.B. im Rahmen von Vorträgen auf Kongressen, wie sie die Situation bezüglich ihrer Software-Dokumentation beurteilen würden. Sie sollen sich einer der 3 folgenden Kategorien zuordnen.
1. Unsere Dokumentation ist gut
2. Unsere Dokumentation ist schlecht
3. Die Dokumentation an sich nicht so schlecht, das eigentliche Problem liegt darin, dass sie nicht konsistent zum Code ist.
98% dieser Entwickler stufen den Zustand ihrer Dokumentation bei 3. ein. Das eigentliche Problem ist also nicht schlechte Dokumentation, sondern Inkonsistenz zum Code. Und die Ursache dahinter ist Redundanz, verbunden mit Zeitdruck, so dass die redundanten Anteile nicht systematisch konsistent gehalten werden können.
Unabhängig davon fangen ein Großteil der Entwickler an die UML einzusetzen, um die Dokumentation (und damit die Verstehbarkeit) ihrer Software zu verbessern.
Dabei muss man wissen, dass 3GL Notationen (3GL = Third Generation Languages wie C, C++, Pascal ...) in ihrem Charakter eine hohe Informationsdichte haben, verbunden mit vergleichsweise schlechter Verstehbarkeit und geringer Redundanz.
4GL Notationen (z.B. UML, SDL ...) hingegen besitzen eine geringe Informationsdichte, verbunden mit wesentlich besserer Verstehbarkeit, aber erkauft durch hohe Redundanz.
Ja, Sie lesen richtig: Hohe Redundanz. 4GL Notationen stellen verschiedene Gesichtspunkte der Systeme dar. Zeitliche Abläufe, Kommunikation, statische Aufteilung... Das erhöht die Verstehbarkeit, aber gleichzeitig auch die Redundanz. Ein Ereignis zum Beispiel kann dann in verschiedenen Ansichten mehrfach auftauchen.
Wenn nun nicht gleichzeitig eine Lösung zum managen der Redundanzen eingeführt wird, vergrößert sich das eigentliche Problem. Nach einem Jahr erstellen von UML-Diagrammen gefolgt von händischer Programmierung haben wir nur noch mehr inkonsistente Dokumentation, die niemand nutzt, da sie nicht das repräsentiert, was im Zielsystem an Software läuft.
Grundsätzlich gibt es zwei Maßnahmen, die notwendig sind, um die redundanten Anteile zu verringern
1. Einsatz eines Repository auf dessen Basis die Diagramme dynamisch entstehen
2. Einsatz von Codegenerierung, so dass zwischen den nun besser verstehbaren 4GL Modellen und dem eigentlichen Source Code keine Inkonsistenzen mehr entstehen
Wird beides nicht benutzt ist es nur eine Frage der Zeit, wann die Modelle inkonsistent zum Code und dann nicht mehr genutzt werden. Inzwischen treffe ich auf immer mehr Entwickler, die mir das aus eigener Erfahrung bestätigen.

Von Mustern, Normen, Halbzeugen und Werkzeugen?

Vor einiger Zeit habe ich einen ,Bauernkasten‘ (so werden die alten Schränke in der Steiermark genannt) 1807 gebaut, von meinen Großeltern geerbt. Er besteht aus zwei Teilen, die mit 4 Holzschrauben und Muttern verbunden sind. Für den Transport nach Deutschland habe ich ihn auseinander geschraubt. Als ich ihn dann zuhause angekommen wieder zusammen bauen wollte, stellte ich mit Erstaunen fest, dass jeweils nur eine Muttter auf genau eine Schraube passte. Die Gewinde waren noch von Hand erstellt.
Ein Grundprinzip lässt sich aber schon an der 200 Jahre alten Schraube erkennen, das Muster (Pattern) des Gewindes, als ein Konzept, um leicht lösbare Verbindungen herzustellen.
Heute sehen Schrauben anders aus. Das Konzept des Gewindes ist gleichgeblieben, was ist dazu gekommen? Die Norm für metrische Gewinde.
Der Einsatz von so genannten Mustern erhöht die Effizienz im Engineering enorm. Verbunden mit Normen wird diese noch einmal potenziert. Muster in Kombination mit Normen ermöglichen hoch effizientes Outsourcing.
Heute ist es egal wo auf der Welt Sie eine Schraube kaufen, und wo diese Schraube hergestellt wurde. Wenn sie ein metrisches Gewinde und eine metrisches Schlüsselmaß hat, passt sie und das Werkzeug mit dem Schraube und Mutter genutzt werden passt auch.
Ohne Muster in Verbindung mit Normen wäre der Maschinenbau nicht dort wo er heute ist.
Produktion, und Wartung heutiger Produkte in allen Industrien (Automitiv, Aerospace, Medical ...) wären nicht denkbar.
Das Software Engineering steckt in dieser Beziehung noch in den Kinderschuhen. Oder etwa nicht?

Muster, Halbzeuge, Normen und Werkzeuge im Software Engineering

Muster (Pattern) werden im Software Engineering bereits seit Jahrzehnten eingesetzt, z.B. in Form von Scheduling Pattern. Eines der meist eingesetzten Muster in Embedded Software ist sicher die ,main() Loop‘. Leistungsfähigere Scheduling Pattern können in Form von Halbzeugen als RTOS eingekauft werden.
Jedoch sind diese proprietär. In Abbildung Nr. 4 ist das Erzeugen eines Tasks exemplarich für einige RTOS dargestellt. Abgesehen davon, dass die Notation nicht einheitlich ist, ist auch die Implementation des Pattern unterschiedlich.
Der Wechsel eines Halbzeuges zu einem anderen Lieferanten ist in diesem Fall mit erheblichem Aufwand verbunden.
Aber auch im Software Engineering gibt es Normen. OSEK-OS, RIF (ReqIF), XMI, SDL, UML ...
Werfen wir einen Blick auf die Norm UML. Diese besitzt im Vergleich zu 3GL Notationen Notationselemente, die auch heute häufig eingesetzte Pattern adressieren, zum Beispiel die Nutzung von Timern, Scheduling Pattern, Kommunikations Pattern, OO Pattern wie Instanziierung oder Vererbung.
All diese Pattern sind im Grund nichts neues, sie werden seit Jahren häufig sogar Jahrzehnten eingesetzt. Neu ist die Norm. Unabhängig vom Lieferanten des Werkzeugs (UML-Modellierungs Tool, Codegenerator ...) oder des Halbzeugs (RTOS, Framework ...) lassen sich die Modelle mit wesentlich geringerem Aufwand weiter verwenden.
Das ist der eigentliche Grund warum die Modellierung mit 4GL Notationen die Effizienz wesentlich erhöhen kann. Aber nur, wenn aus dem Modell Code generiert wird.
Der Codegenerator adaptiert den Standard auf die Hersteller proprietären Halbzeuge. Im Codegenerator ist es ein Schalter, der bewirkt, dass ein anderes System unterstützt wird. In wenigen Sekunden ist die Software dadurch auf einem anderen System lauffähig. Mit händischer Codierung ein Aufwand von mehreren Tagen.
Änderungen und Erweiterungen werden im Modell durchgeführt. Dort ist die Verstehbarkeit um ein vielfaches höher, als auf Code-Ebene. Auf Basis des Repository und der Codgegenerierung wird aus dem Modell vollständiger Code generiert. Redundanzen müssen nicht gepflegt werden.
Das ist Stand der Technik im Software Enginee-ring. Leider nicht immer Stand der Praxis.

Resümee

Neue Paradigmen helfen komplexer werdende Systeme weiterhin effizient zu entwickeln und zu warten. Häufig werden Methoden oder Werkzeuge jedoch nicht orientiert am grundlegenden Problem eingesetzt.
Die Effizienz kann dann nicht wie erwartet gesteigert werden und das neue Vorgehen wird als nicht praktikabel dargestellt. Häufig werden Methode, Notation und Werkzeug nicht homogen zueinander angewandt. Alte oder zugekaufte Sourcen verwendet und mit Pattern kombiniert (z.B. synchrone Kommunikation mit preemptivem Scheduling), die nicht dafür geeignet sind.
Würde ein schwedischer Möbelhersteller die Regale mit einer wilden Kombination an Pattern liefern, dann würde die Parodie auf deren Werbung ,Wohnst du schon, oder schraubst du noch‘ eine ganz andere Bedeutung bekommen, abgesehen von den Kosten für unzählige Werkzeuge, die für den Zusammenbau mitgeliefert werden müssten.
Übertragen gilt für alle Paradigmenwechsel. Bei der Einführung eines neuen Vorgehen kann viel falsch gemacht werden. Wenn sich dann der Erfolg nicht einstellt liegt es nicht immer am Werkzeug oder an der Methode.
Eines steht fest, die Anwendung von Mustern in Verbindung mit Normen und Werkzeugen hat den Maschinenbau revolutioniert. Dasselbe wird in den kommenden Jahren im Software Engineering geschehen.
Heute liegt vor allem im Architektur Design ein grundlegendes Potential für den effizienten Einsatz von Mustern und damit auch ein Grundstein zur Anwendung von Notationen wie UML und effizienter Codegenerierung.
Die Frage ist häufig nicht ,Programmieren Sie noch oder modellieren Sie schon‘ sondern ,Malen Sie noch oder modellieren Sie schon‘. In diesem Sinn wünsche ich Ihnen viel Erfolg beim Programmieren, Malen oder Modellieren.

Autor: Andreas Willert