Warum läuft das Programm eigentlich?

Rainer Lucas, Senior Entwickler bei der SAPHIR GmbH, München

Was braucht der Software-Entwickler zum Arbeiten? Ein stilles Kämmerlein und einen guten Pizzaservice! Das Klischee vom abgeschieden tüftelnden Genie in verwaschenen Jeans und Hang zu schlechten Essgewohnheiten hält sich hartnäckig. Und das obwohl die Software-Entwicklung in puncto Methodik schon lange einen großen Schritt nach vorne gemacht hat. Dennoch aber ist es noch immer nicht gelungen, alle Graubereiche in Fragen à la wann wurde welche Anforderung wie umgesetzt, durchgängig und für jedermann nachvollziehbar zu enträtseln.

Zweifellos hat man seit den Zeiten des systemlosen Programmierens eine lange Wegstrecke zurückgelegt. Damals war es durchaus erlaubt, mit „Go-to-Ansätzen“ und „Spaghettiprogrammen“ einfach mal drauf los zu entwickeln. Der Haken war jedoch schnell ausgemacht: Nur der Entwickler – wenn überhaupt der – verstand in der Retrospektive, was da lief und warum. Das erschwerte aber nicht nur die Weiterentwicklung erheblich, sondern auch den Support und die Wartung.

Der Forderung nach einer strukturierten Arbeitsweise trug man mit Nassi-Scheiderman Diagrammen oder der Specification and Description Language (SDL) in der Folge Rechnung. Diese Verfahren brachten beim Beschreiben von sequentiellen Systemen und Software-Abläufen auch einen klaren Fortschritt, allein es fehlte an Systemdaten. Deshalb begann man, Daten und Funktionen in Klassen- und Methodenaufrufen zu kapseln und zusammenzufassen. Mit dem objektorientierten Programmieren (OO) kam es damit gleichzeitig zu einem Paradigmenwechsel in Richtung Ereignissteuerung.

Zwar waren die Fortschritte in Sachen Knowhow-Transferaufwand, Änderbarkeit oder Planungssicherheit somit unverkennbar, noch immer aber formulierte man keine Use-Cases und verfügte über keine Ansätze zur „kalten“ Funktionskontrolle. Um dies zu gewährleisten, musste man eine höhere Abstraktionsebene betreten: Die Unified Modelling Language (UML)! Sie ermöglichte durch komplexe Beschreibungsverfahren und Diagramme mit verschiedensten Sichtwinkeln eben dies.

Ein Manko ließ sich auch damit jedoch nicht vollkommen eliminieren: Die Software-Entwicklung blieb und bleibt schwerfällig, denn der Aufwand bei Änderungen ist nach wie vor erheblich. Die meisten UML-Tools sind ein isolierter Zusatz zur Entwicklung. Eine integrierte Lösung für Planung, Source-Entwicklung, Test- und Dokumentation gibt es (noch) nicht.

Die in Hülle und Fülle vorhandenen konzeptionellen Ansätze sorgten also ohne Zweifel für frischen Wind. Die erhoffte durchgängige Transparenz sollte sich dagegen nicht im selben Maße einstellen. So kann man mit dem (statischen) Objektmodell auf der Basis von Vererbung und Polymorphismus ganze Taxonomien von Softwarestrukturen bilden, wobei sich auf jeder Ebene der Code der höheren Ebenen benutzen lässt. Und die gängigen UML-Tools unterstützen diese Methodik auch. Doch bestehen bei den Code- oder Testgeneratoren andererseits oft erhebliche Lücken im Gesamtablauf. Es hapert insbesondere an der Schnittstelle zwischen Systementwurf und Codierung.

Das liegt beispielsweise an den verwendeten Programmier-Sprachen, die der Abstraktionsebene des Systementwurfs nicht gewachsen sind. So lässt sich in vielen Fällen aus erzeugtem Code kein Bild über das dynamisches Verhalten von Objekten im Gesamtkontext des Systems erstellen. Am unerquicklichsten ist allerdings die ausufernde Komplexität der Gebilde durch die Entwicklungsverfahren.

Inzwischen lassen sich weite Teile des Programmierens schon über Tool-Oberflächen abwickeln, aber, und das ist der Pferdefuß dabei, durch zahllose uneinheitliche Eingabeverfahren. So erkauft man die grafische Erfassung und Bewertung durch das Tool quasi um den Preis einer neuen Übersprache.

Das Tool erzeugt aus den Eingaben Code. Hier allerdings beginnt ein heikles Minenfeld, denn die Einstellungen der Codegeneratoren sind mannigfaltig und zählen zu einer Grauzone zwischen Compilerschaltern und Sprachelementen. Umgekehrt verursacht das Re-Engineering bei einigen Tools größere Probleme, weil die Programmiersprache in der Entwicklungsumgebung oft Winkelzüge zulässt, die das Werkzeug nicht mehr erkennen kann. Eine Rückkehr zu schlüssigen Grafiken ist damit zweifelhaft und unzuverlässig.

Das Problem liegt hauptsächlich in der Granularität der aktuellen Hochsprachen. Dies macht die Verbindung zur hohen Abstraktionsebene der Entwicklungstools unsicher und führt dazu, dass man in vielen Entwicklungsprojekten die Verbindung zwischen Systementwurf und Codierung kappt. Die Entwurfsarbeit im Werkzeug nutzt man dann zu Dokumentationszwecken.

Einen Lösungsansatz bietet das dynamische Modell. Was aber ist darunter zu verstehen? Im statischen Objektmodell wird die Struktur der Objekte eines Systems mit ihren Beziehungen zu einem einzigen festen Zeitpunkt beschrieben. Im dynamischen Modell betrachtet man die Änderungen der Objekte und ihrer Beziehungen untereinander über die Zeit. Wesentliche Konzepte sind dabei der Kontrollfluss, die Interaktionen von Objekten sowie die Steuerung von Abläufen der gleichzeitig aktiven Objekte eines Systems.

Die einzelnen Objekte reagieren auf Ereignisse, führen entsprechende Aktionen aus und verändern ihren Zustand. Mithilfe der Begriffe 'Zustand – Ereignis – Bedingung – Aktion – Folgezustand' lässt sich ein dynamisch arbeitendes Objekt komplett beschreiben. Das gesamte dynamische Modell des Software-Systems besteht aus beliebig vielen solchen Objekten, wobei mindestens eines für jede Klasse dynamisches Verhalten aufweisen muss. Das Modell zeigt dabei die Summe der Aktivitäten für ein ganzes System. Alle dynamischen Objekte arbeiten parallel und können unabhängig voneinander ihre Zustände ändern.

Dynamische Modellierung hebt die Abstraktionsebene schon im Entwurf auf diese Methodik und zwar unabhängig von der Implementierung auf den Zielsystemen. Man kann somit also die Teile des Codes erstellen, die dieses Verhalten abbilden, und zwar mit getesteten und bewährten Verfahren.

Diesen Ansatz macht sich das Tool Event (von SAPHIR GmbH und datelec GmbH entwickelt) zu Nutze. Es deckt die Gebiete Entwurf, Codierung, Test und Dokumentation so weit als möglich ab und strafft diese gleichzeitig. Denn es walzt sie nicht in viele Einzelschritte und Dokumente aus, sondern zieht sie zu kompakten Gebilden zusammen. Durch Single-Source Methodik wird eine möglichst integrierte Dokumentation der einzelnen Prozessschritte unterstützt.

Event stellt die dynamischen Objekte als Zustandsmaschinen dar und verwendet die Matrixdarstellung der Zustandsmaschinen als „Supersprache“ zum Ebenenwechsel von der Codierung zur Objektebene. Hier entwirft und editiert man Zustände, Ereignisse und Aktionen - mit freiem Inhalt, aber auch einigen Schlüsselwörtern wie „SetState“ und „SendMessage“, die der Codegenerator und der integrierte Simulator auswerten.

Die entstandenen Objekte lassen sich immer aktuell aus der „Single Source“ in verschiedenen Darstellungen (zum Beispiel Zustandsdiagramme) dokumentieren. Mit Hilfe des integrierten Simulators kann man bereits im Entwurfsstadium Sequence-Diagramme vom dynamischen Verhalten erzeugen, so dass bereits hier verifizierte Funktionalität dokumentiert ist. Der augenscheinlichste Vorteil besteht dabei darin, dass man immer mit einer „Single Source“ arbeitet, aus der sich alle anderen Dokumente ableiten: Grafiken, Diagramme und Code. Änderungen am Code ändern zwangsläufig die Dokumentation, weil man immer nur ein Objekt editiert.

Natürlich unterstützt dieser dynamische Ansatz auch das statische Modell. Durch den eigenen Codegenerator kann das Tool nicht nur Vererbung von einzelnen Eigenschaften eines Objektes, sondern die Vererbung von ganzen Verhaltensweisen unterstützen. Komplexe Vorgänge lassen sich damit durch weniger statt mehr Information handhaben, was das gefährliche „Anti-Pattern“-Verfahren der Codeduplizierung vermeidet.

In der Matrix-Darstellung der Objekte ist das geerbte Verhalten farbig markiert, so dass man immer das Verhalten der gesamten Klasse sehen – also auch dokumentieren, Grafiken erstellen und simulieren kann. Danben lassen sich einzelne Aktionen überlagern, so dass man gegenüber der Basismaschine feinste Veränderungen vornehmen kann. Dies erlaubt eine umfangreiche Variantenbildung bei minimaler Code-Differenz zu den Basismaschinen.

Zusätzlich gibt es vererbbare Default- und Fehler-Methoden, so dass auch bei nicht definierten Einflüssen eine reguläre Verhaltensweise gewährleistet ist.

Die Modularisierung einer komplexen Aufgabe in geeignete Objekte zum Bewältigen einzelner Aufgaben ist unabhängig von all dem unerlässlich. Eine geeignete Basisklasse ermöglicht es, viele einzelne dynamische Objekte zu einem großen Verarbeitungsgebilde zu vereinen. Der Aufwand für Integration und Test lässt sich mit diesem Verfahren deutlich verringern. Dazu muss man im laufenden System das Senden und Empfangen der Ereignisse sowie der Zustände von beteiligten Maschinen sichtbar machen. Der frühzeitige Einbau einer Anzeige visualisiert das Verhalten des gesamten Systems und lässt einen sofortigen Rückschluss auf die betroffene Aktion zu.

Mit dem hier beschriebenen Ansatz lässt sich die Softwareentwicklung also zweifelsohne nachvollziehbarer gestalten. Somit kann man wichtiges Wissen über die entwickelten Systeme wesentlich einfacher als bisher abrufen. Ein Aspekt, der im Ernstfall nicht nur Zeit und Nerven, sondern auch bares Geld sparen kann.

Das dynamische Modell bietet einen Ausweg, der allerdings nur dann praktikabel ist, wenn man das Prinzip der Beschränkung walten lässt. In Verbindung mit der Verhaltensvererbung bietet dieser Ansatz einen gangbaren Weg, der komplexe Vorgänge durch überschaubare Informationen kontrollierbar macht. Die Zusammenarbeit mit den gängigen Entwicklertools (Reenginering) ist dabei durchaus möglich.

Die Praxis zeigt, dass die dynamische Modellierung als Programmierverfahren auf fast alle Gebiete anzuwenden ist. Dabei kann man auf jeden Fall über Anwendungen wie Kommunikationsprotokolle hinausgehen.

Doch auch die dynamische Modellierung wird sich weiterentwickeln. Komplexe Vorgänge durch einen höheren Sichtwinkel des Entwicklers weiter zu vereinfachen, beschleunigen und durch automatisierte Codeerzeugung sicher zu machen, muss dabei das Ziel sein.

Daneben muss man sicher auch anvisieren, den Schwerpunkt weiter in Richtung Design zu verlagern, um noch abstrakter zu arbeiten.

Mit der dynamischen Modellierung bietet sich nichts desto weniger schon jetzt ein Ansatz, der erheblich dazu beitragen kann, die Softwareentwicklung besser zu strukturieren, ohne sie gleich komplett aus den Fugen zu werfen.