Dipl.-Phys. Wolfgang Zinke
Consultant für Software-Technologie, München
Da zwischen denen, die Software machen, und denen, die für die Kosten aufkommen, in den meisten Fällen eine Kommunikationslücke besteht, blieb das Wartungsproblem lange verborgen, vor allem deshalb, weil der EDV-Laie zunächst meint, ein Programm bedürfe als geistig Produkt, das keinem Verschleiß unterworfen ist, keinerlei Wartung.
Wie horrend tatsächlich die Wartungskosten von Software sein können, zeigt eine Untersuchung der U.S. Air Force, die festgestellt hat, daß in ihren Programmen pro Anweisung 75 Dollar Entwicklungskosten, aber 4000 Dollar Wartungskosten stecken. Die Einstellung änderte sich, als man zu rechnen begann. Die Softwarekrise wurde offenbar.
So wurde nach Wegen gesucht, die Wartungskosten niedrig zu halten - was zu der Erkenntnis führte, daß die Wartungsfreundlichkeit eines Programms stark von seiner originalen Beschaffenheit abhängt. Das wartungsfreundliche Programm hat demnach vor allem folgende Eigenschaften:
- Es sollte ein abgeschlossenes Problem behandeln, das eine funktionale Einheit bildet, so daß man mit einem Satz in der Lage ist, zu umreißen, was das Programm macht.
- Es sollte verständlich sein, ein Programmierer, der mit dem durch das Programm behandelten Problem vertraut ist, sollte in der Lage sein, den Programmablauf anhand des Quelltextes zu verstehen.
- Es sollte klar definierte Schnittstellen zu seiner äußeren Umgebung - nämlich den bearbeiteten Daten - haben, die selbst wiederum logische Einheiten bieten; es sollte ferner nach außen hin nur die Daten bearbeiten, die an diesen Schnittstellen erscheinen. "Verborgene" Schnittstellen, die der Anwender des Programms nicht kennt, darf es nicht geben.
- Es sollte unabhängig von bestimmten Betriebssystemen oder gar Versionen eines Betriebssystems sein,
- Es sollte schließlich Daten, die es von außen bekommt, vor der Bearbeitung auf Verträglichkeit mit den von ihm gestellten Voraussetzungen prüfen.
Das sind einleuchtende Forderungen - es ist jedoch noch ein langer Weg zu einer allgemein anerkannten Systematik, mit deren Hilfe man gezwungenermaßen Programme schreibt, die diese Forderungen erfüllen.
Eine wesentliche Entdeckung auf diesem Weg war, daß es möglich ist, Steuerflüsse in einem Programm zu strukturieren. Die "strukturierte Programmierung", die leider heute noch von keiner gängigen Programmiersprache erzwungen wird, fußt auf der Erkenntnis daß es möglich ist, jedes beliebige Programm aus vier Arten von Strukturblöcken zusammenzutragen:
- die einfache Anweisungsfolge,
- die Verzweigung,
- die Schleife,
- die Prozedur.
Die nächste Entdeckung, die gemacht wurde, war die, daß es zweckmäßig ist, eine Prozedur so zu konzipieren, daß sie eine funktionale Einheit bildet und so als unabhängiger Programmteil erstellt werden kann. Dies wird als "Modulartechnik" bezeichnet.
Verbunden mit dem Prozedurkonzept ist auch das Konzept der "Fernwirkungsfreiheit" eines Programms, das , leider ebenfalls von den meisten gängigen Programmiersprachen nicht erzwungen wird - eine Ausnahme bildet PL/1.
Ein weiterer Gesichtspunkt zur Erzielung wartungsfreundlicher Programme ist schließlich der der "Datenstrukturierung".
Mit all diesen Konzepten kann man nun an die funktionale Planung eines Projektes gehen. Dabei gibt es zwei Möglichkeiten:
- den Top-Down-Approach,
- den Aufbau mit Hilfe einer oder mehrerer virtueller Maschinen.
Beim Top-Down-Approach werden ständig neue Prozeduren geboren, und es bleibt der Kunst eines Entwicklungsteams überlassen, Redundanzen zu vermeiden. Dies wird um so leichter, je kleiner das Team ist. Meist ist die Größe eines Teams in etwa proportional zur geschätzten Komplexität eines Problems, was zu der Aussage berechtigt, daß die strikte Top-Down-Methode dort von Vorteil ist, wo es um überschaubare Probleme geht.
Anders bei großen Projekten: Dort ist es sinnvoll, virtuelle Maschinen oder Softwaremaschinen zu konstruieren. Eine virtuelle Maschine steht in jedem Fall zur Verfügung: Sie ist entweder der Vorrat der Maschinenbefehle nebst dem Betriebssystem in seiner Makroschnittstelle oder die verwendete Programmiersprache mit ihrem Laufzeitsystem. Sieht man diese Maschine als den rechnerspezifischen Nukleus an, so können um sie herum schalenförmig weitere virtuelle Maschinen gebaut werden. Das Entwicklungsteam wird in mehrere Teams zur Entwicklung je einer dieser virtuellen Maschinen aufgeteilt. Dabei werden sinnvollerweise die Abhängigkeiten von bestimmte Bedingungen so lokalisiert, daß sie nur in bestimmten Maschinen auftreten. Ein Schalenmodell für die Realisierung eines größeren Projektes kann folgende Maschinen enthalten:
- die betriebssystemabhängige Maschine: In ihr werden alle Funktionen angeboten, die auf das verwendete Betriebssystem Bezug nehmen; ihre Anwenderschnittstelle ist betriebssystemunabhängig,
- die betriebssystemnahe Maschine: Sie bietet alle Funktionen an, die in irgendeiner Weise Aufrufe an das Betriebssystem zur Folge haben, beispielsweise Datenzugriffsmethoden, spezielle Sicherungsfunktionen, Wiederanlauffunktionen. Ihre Anwenderschnittstelle ist unabhängig vom Betriebssystem sowie von Versionen und internen Konzepten des Projektes,
- die anwendernahe Maschine: Sie bietet neben den Funktionen der betriebssystemnahen Maschine auch Funktionen an, die vom Betriebssystem unabhängig sind und beispielsweise problemspezifische Algorithmen, Syntaxprüfroutinen, Sprachprozessoren und ähnliches enthalten.
Jede dieser virtuellen Maschinen benutzt ausschließlich die im Schalenmodell unter ihr liegende, deren Funktion sie als Prozedur aufruft. Auf der oberen, der anwendernahen Maschine, bauen die Programme auf, die das eigentliche Anwenderproblem EDV-technisch lösen.
Es sollte nicht verschwiegen werden, daß die dargestellten Konzepte bis zum heutigen Tage nur Ansatzpunkte zu besserer Software sind und daß es auch keine Möglichkeit gibt, den Designer und Programmierer zu ihrer Einhaltung zu zwingen. Am Schluß deshalb ein Rat an den Entwicklungsleiter: Das beste Mittel, einen Mitarbeiter zur Einhaltung von Strukturierungsregeln zu bringen, ist, ihn von der Schönheit und Klarheit strukturierter Software zu überzeugen.