Effizientes Software Engineering Über den richtigen Umgang mit Werkzeugen, Methoden, Notationen …

Effizientes
Software Engineering
Über den richtigen Umgang mit Werkzeugen,
Methoden, Notationen …

Häufig werden neue Notationen, Werkzeuge oder Methoden eingeführt in der Hoffnung, die Effizienz im Software Engineering zu verbessern. Doch nicht immer stellt sich das gewünschte Ergebnis ein. Nicht immer führt der Wechsel der Notation von ANSI-C zu C++ gleichzeitig zu Objektorientierter Programmierung. Nicht immer verbessert der Einsatz von UML-Diagrammen die Qualität der Software-Dokumentation … Warum die Einführung eines neuen Werkzeuges, einer neuen Methode oder Notation eventuell sogar kontraproduktiv ist und was zu beachten ist, damit eine Investition zu der erwarteten Effizienz-Steigerung führt; darüber handelt dieser Artikel.
Grundlagen der Prozessoptimierung

Eine der grundlegenden Prinzipien in der Kybernetik (Wissenschaft der Steuerung und Regelung von Prozessen und Systemen) ist das Phänomen des Engpasses. Bereits Justus von Liebig hat den Kunstdünger auf Basis der Engpass Analyse erfunden. Seine Überlegungen gingen davon aus, dass eine Pflanze für optimales Wachstum (an dieser Stelle vereinfacht dargestellt) die vier Grundfaktoren Wasser, Nährstoffe, Wärme und Licht benötigt. Steht einer dieser Faktoren in nicht ausreichendem Masse zur Verfügung (bildet er also einen Engpass), dann hilft es nicht die anderen Faktoren zu erhöhen. Ganz im Gegenteil: betrachtet man dass Gesammtsystem, dann wird es bei weiteren Investitionen in die Bereiche, die nicht den Engpass bilden ineffizienter. Kosten steigen, der Output nicht. Betrachten wir noch einmal die Pflanze, z.B. im Sommer, wenn sie in einer sehr warmen Periode viel Licht und Wärme bekommt. Ihr Engpass ist dann evtl. Wasser. Würden wir ihr jetzt statt Wasser noch mehr Licht und Wärme zuführen würde sie wahrscheinlich eingehen. Die Kybernetik beweist, dass dieses grundlegende Zusammenhänge sind, die für Systeme und Organismen jeglicher Art gelten, also auch für Prozesse und Vorgehen im Software Engineering.

Engpasskonzentriertes Vorgehen im Software Engineering

Nur zu häufig wird jedoch nicht danach gehandelt. Begeben wir uns erst einmal auf die Suche nach den derzeitigen Engpässen im Software Engineering. Dort gibt es zwei Anforderungen, die sich in den letzten Jahren zu zentralen Engpässen entwickelt haben.
1.
Redundante Informationen
2.
Steigende Komplexität
Betrachten wir diese beiden Anforderungen einmal genauer.

1. Engpass
Redundante Informationen

In der Abbildung 1 ist zu sehen, wie die Kommunikation üblicherweise in einem typischen Projekt verläuft. Dort spricht der Anwender von HiFi-Qualität. Der Projektleiter überlegt sich wie er HiFi- Qualität so definieren kann, dass sie im Rahmen eines Abnahmetests überprüfbar ist und greift zu einer technischen Norm. Der Programmierer setzt dann die Anforderung durch die Programmierung seiner Software im Rahmen der Syntax einer Notation um. In diesem vereinfachten Beispiel haben wir lediglich drei in einem Prozess Beteiligte, so genannte Stakeholder. Es geht um die selbe Anforderung, die je nach Fachdomäne in einer anderen Syntax dargestellt ist. Hierzu dienen heute verschiedene Arten von Dokumenten, wie Lastenheft, Pflichtenheft, Architekturbeschreibung, Testspezifikation … All diese Dokumente werden in der Regel textbasiert mit den Editoren oder Textverarbeitungen dieser Welt erstellt. Dieses Vorgehen ist also dokumentenzentrisch. Jede Fachdomäne hat sein eigenes Dokument, in der die domänenspezifische Syntax genutzt wird. Werfen wir einen Blick in die Dokumente ergeben sich multifache Beziehungen der Aussagen zueinander, dargestellt in Abbildung Nr. 2. Aber damit noch nicht genug, betrachten wir diese Dokumente im V-Modell, dann erkennen wir noch einmal verschiedene Arten (Ebenen) von Abhängigkeiten, wie in Abbildung Nr. 3 dargestellt. All dieses führt zu sehr viel redundanten Informationen in den Dokumenten, die in der Praxis schwierig konsistent gehalten werden können. Das führt dann nicht selten zu Situationen wie der Folgenden. Dort schildert mir ein Mitarbeiter, der für den Test eines Systems zuständig ist, dass er im Idealfall zu dem zu testenden System ein Pflichtenheft, eine Software-Dokumentation und den Quellcode bekommt. Nun fängt er an, das System gegen die Anforderungen zu testen und stellt ein abweichendes Verhalten fest. Bezogen auf die Software und deren Dokumentation ist das Verhalten jedoch richtig, und nun kommt die spannende Frage: Handelt es sich hier um ein Fehlverhalten der Software oder um ein im Pflichtenheft nicht nachdokumentiertes Change Request des Kunden? Diese Frage nachträglich zu klären ist häufig mit erheblichem Aufwand verbunden, da sich weder Entwickler noch Kunden erinnern können. Würde anstelle von Dokumenten eine Datenbank genutzt, in der nicht nur die Syntax, sondern auch die Abhängigkeiten abgelegt werden können, dann wären die redundanten Informationen sehr viel einfacher zu pflegen und die Informationen würden zueinander konsistent bleiben.

Steigende Komplexität

Viele Produkte haben sich in den letzten Jahren von einfachen Geräten mit einer gewissen Grundfunktionalität in komplexe Systeme mit diversen Zusatzfunktionen entwickelt. Und damit nicht genug, gibt es Sonderausstattungen, muss die Firmware eines Gerätes zu alten Ausstattungskomponenten kompatibel bleiben … In der Praxis müssen im Software Engineering heutige Systeme mindestens folgende 7 Ebenen berücksichtigt werden.


Timing

Datenfluss

Logisches Verhalten

Prioritäten

Versionen

Varianten

Betriebsmodi
Betrachten wir die heute immer noch meist eingesetzte Notation zur Programmierung von technischen Systemen, die Sprache ANSI-C, dann kann das etwa so aussehen, wie in Abbildung Nr. 4 zu sehen ist. Ändern wir eine Zeile im C-Code, dann gilt es, die potentiellen Auswirkungen, bezogen auf alle 7 Ebenen, zu berücksichtigen. Das macht Wartung, Pflege, Weiterentwicklung … im Softwareengineering heute so anfällig.

Lösung

ANSI-C ist eine Notation mit extrem hoher Informationsdichte. Der Nachteil: einzelne Aspekte lassen sich nur sehr schlecht darstellen, z.B. der zeitliche Ablauf der Software oder der Datenfluss. Hier kann die UML Abhilfe schaffen. Sie ist eine Notation, die in ihren einzelnen Darstellungsmöglichkeiten eine sehr viel geringere Informationsdichte hat, dafür aber einen bestimmten Fokus sehr verstehbar darstellt. Mit ihr kann auf Basis von Timing-Diagrammen die Ebene Zeit sehr viel verstehbarer dargestellt werden. Das gleiche gilt für alle anderen Diagrammformen in Bezug auf andere Ebenen. Mit Klassendiagrammen zum Beispiel die statische Architektur, mit Zustandsautomaten das logische Verhalten, mit Sequenz-Diagrammen den Datenfluss, mit Komponenten-Diagrammen die Varianten … Also ein probates Mittel den heutigen Problemen der schlechten Verstehbarkeit von C-Programmen entgegen zu wirken. Und so werden UML-Diagramme erstellt, um die C-Programme zu dokumentieren und damit verstehbarer zu gestalten. Sehr häufig wird dazu erst einmal ein preiswertes Werkzeug genutzt, z.B. MS-Visio, da es in vielen Firmen als ein Standard-Programm zur Verfügung steht.

Wirkung auf den 1. Engpass ‚Redundante Informationen‘

Wurde jedoch nicht zuerst der Engpass der Redundanten Informationen beseitig, dann entstehen nun noch weitere Redundante Informationen, die gepflegt werden müssen. Die UML erhöht die Verstehbarkeit auf Basis von spezifischen Darstellungen, erhöht dabei aber die Redundanz. Eingesetzt ohne Datenbank (Repository) treibt sie den Aufwand zur Pflege der Redundanzen ins Unermessliche. Die Software wird verstehbarer, jedoch die Konsistenz der Informationen ist nicht mehr gewährleistet, es ist nur noch eine Frage der Zeit, wann die UML-Darstellungen nicht mehr genutzt werden und alle Arbeiten wieder auf C-Code Ebene stattfinden. Alle Investitionen in die UML waren nutzlos. Wird hingegen erst der Engpass der Redundanten Informationen beseitig, z.B. in dem vom dokumentenzentrischen Vorgehen auf ein Datenbank (Repository) zentrisches Vorgehen gewechselt wird, dann führt auch der Einsatz der UML zum gewünschten Ergebnis. Dafür sind natürlich Werkzeuge notwendig, die ein Repository beinhalten. Mit ihnen werden redundante Informationen in allen Darstellungen konsistent gepflegt. Wenn in einer Darstellung geändert wird, ändern sich alle anderen Darstellungen automatisch. Aber es ist auch ein Mindestmaß an Kenntnissen der UML erforderlich. Nur wenn in den verschiedenen Diagrammen auch die UML-Elemente konsistent genutzt werden können diese auf Basis des Repository bei Änderungen automatisch konsistent gehalten werden. Und es geht noch weiter: Nur wenn ein System in der richtigen Reihenfolge der Anwendung von Diagrammen modelliert wird, ist es einfach, die UML-Elemente konsistent weiter zu verwenden. Also auch der Prozess muss dementsprechend gestaltet sein. Weitere Beispiele, u.a. was die Software-Architektur mit der Modellierung von Zustandsautomaten zu tun hat, können Sie in der Newsletter Nr. 25 ‚Richtiges richtig tun‘ lesen. Die NL finden Sie unter: www.willert.de/newsletter

Kasten: Kybernetik

Der Begriff Kybernetik bezeichnet nach ihrem Begründer Norbert Wiener die Wissenschaft der Steuerung und Regelung von Maschinen und lebenden Organismen; er wird auch mit der Formel die Kunst des Steuerns übersetzt.

Autor: Dipl. Ing. (FH) Andreas Willert, Geschäftsführer und
Gesellschafter der Firma WillertSoftware Tools GmbH

Willert Software Tools GmbH
www.willert.de

Das könnte Sie auch Interessieren