Ist man bei der Strukturierung von Software mit dem Methoden-Latein am Ende?

Entscheidungstabellen verknüpfen Menü-Listen

20.02.1981

Der "richtige Weg", Software zu strukturieren, ist eines der in Fachkreisen seit Jahren am meisten diskutierten Themen. Dabei kommt es vor allem darauf an, die Strukturen der Programme/Systeme so festzulegen, daß ein Höchstmaß an Transparenz, Änderungsfreundlichkeit, Erweiterbarkeit, Einfachheit und Robustheit erreicht wird. Gleichzeitig sollen die Kosten für Software-Entwicklung/Wartung gesenkt werden. Der folgende Beitrag will einen besseren Weg für die meisten Problemstellungen aufzeigen.

Die Meinungen sind offensichtlich verschieden, und daß die "richtige" Methode noch nicht gefunden wurde, geht schon daraus hervor, daß keine der bekannten Methoden sich bisher allgemein durchsetzen konnte. Im Gegenteil, die bekannten Methoden werden zunehmend kritisiert, und man sucht weiterhin nach besseren Wegen.

Alle bekannten Strukturierungs-Methoden arbeiten mit den drei Grundstrukturen Sequenz, Auswahl und Wiederholung. Durch beliebige Zusammensetzung dieser Grundstrukturen entstehen Programme mit beliebiger Gesamtstruktur. Daher kommt es, daß kein Programm-System den anderen gleich ist.

Die unendliche Vielzahl der Strukturen verhindert jeden Lern- und damit Rationalisierungseffekt und führt in der Regel zu einer völligen Inkompatibilität zwischen den Programm-Systemen (selbst bei gleicher Methode und Programmiersprache).

Die abwechselnde Verwendung von Sequenz, Auswahl und Wiederholung führt außerdem zu den bekannten verschachtelten Strukturen. Dies wiederum macht die Software kompliziert und führt dazu, daß jede Änderung/Ergänzung an einem Programm problematisch und teuer ist.

Bei Anwendung der Auswahl-Methode gibt es in jedem Programm/System nur zwei Komponenten: die "Steuerung" und die "Code-Segmente". Ein Code-Segment ist eine rein sequentielle Folge von Befehlen. Die Steuerung entscheidet, welches Code-Segment jeweils als nächstes auf gerufen wird.

Ein Code-Segment besteht aus einem bis n Befehlen. Es ist abfrage- und schleifenfrei (damit auch schachtelungsfrei). Ein Code-Segment ist naturgemäß kurz.

Aus dem bisher Gesagten geht bereits hervor, daß zumindest die Code-Segmente sehr einfach sind. Daraus könnte man schließen, daß die ganze

Problematik in der Steuerung steckt. Dazu kann gesagt werden, daß bei dem richtigen Verständnis der Methode auch die Steuerung sehr einfach ist, zumal bei einem entsprechenden Pre-Compiler die Steuerung nicht von Hand codiert werden muß. Die Steuerung bietet also in der Realisierung noch weniger Schwierigkeiten als die Code-Segmente.

Die Steuerung (also die Logik eines Programmes) wird beschrieben mit Entscheidungstabellen und gegebenenfalls mit Pseudo-Code (Design-Sprache). Der Input für die Entscheidungstabellen sind "Menü-Listen". Die Menü-Listen werden ermittelt unter Anwendung der bekannten "Menü-Technik".

- Die Funktionen werden mit Hilfe der Menü-Technik gegliedert. Diese Gliederung hört nicht - wie üblich - beim Programm auf, sondern wird bis zur letzten Unter-Funktion fortgesetzt.

- Daten, Programmzustände und alles, was sonst noch Einfluß auf den Ablauf eines Programmes hat, werden nach der gleichen Technik aufgelistet.

- Die Menü-Listen werden durch Entscheidungstabellen miteinander verknüpft. Dies ergibt Anzahl und Funktion der Code-Segmente (reine Auswahl-Struktur). "Sequenzen" treten als Element der Strukturierung nicht auf. "Wiederholung" von einzelnen Code-Segmenten wird gegebenenfalls zu einem späteren Zeitpunkt definiert und beeinflußt die Struktur ebenfalls nicht.

Die Auswahl-Methode bietet eine ungewöhnliche Transparenz der Systeme. Zudem ist sie open-ended, schachtelungsfrei und damit sehr änderungsfreundlich. Zeichnerische Hilfsmittel sind nicht erforderlich (etwa Struktogramme, Ablaufpläne, sonstige Diagramme), da es nur eine einheitliche, bekannte Struktur gibt.

Dargestellt wird die Logik des Programmes (also die Steuerung) durch Entscheidungstabellen und Pseudo-Code. Diese Darstellung ist wesentlich knapper, übersichtlicher und leichter änderbar als bei den sonst notwendigen Darstellungsweisen. Durch die konsequente Trennung von Steuerung und Problemcode kann die Steuerung generiert werden und braucht folglich nicht codiert werden.

Ist eine umfangreiche "Code-Segmente-Bibliothek" beziehungsweise eine leistungsfähige "Design-Sprache" vorhanden, entfällt im wesentlichen auch das Codieren der Code-Segmente und damit das Codieren überhaupt. Neben der Einsparung an Codierzeit führt dies vor allem zu praktisch codierfehlerfreien Programmen und einer entsprechenden Reduzierung an Maschinen-Test-Zeit.

Eine Programmiersprache (Design-Sprache), die sich an der Auswahl-Methode orientiert, braucht keinerlei Anweisungen zur Steuerung eines Programms, also keine IF-Anweisungen, keine DO-Anweisungen und keine Sprung-Anweisungen. Jegliche Blockstruktur (BEGIN . . . END) sowie Verschachtelungen im Programm entfallen.

Es existiert jedoch eine Einschränkung: IF und DO-Anweisungen sind zwar nicht notwendig, doch sollten sie zur Vereinfachung bestimmter

Aufgaben (vorerst?) zulässig bleiben (beziehungsweise durch äquivalente Anweisungen ersetzt werden).

Beispiele hierfür sind der Zeilenzähler bei einer Druckausgabe oder der Schleifenzähler beim Durchsuchen von Tabellen oder Dateien. Hier ist die Steuerung so eng mit dem Code-Segment verbunden, daß es durchaus sinnvoll ist, dieses auch im Code-Segment zu programmieren und damit die Steuerung zu entlasten.

Die Code-Segmente werden dadurch nicht nennenswert komplizierter, aber das Gesamtprogramm unter Umständen entschieden einfacher.

Es empfiehlt sich aber, sparsam damit umzugehen; sonst entstehen die alten, verschachtelten Programme.

Fortgeschrittene sparen mehr

Die Auswahl-Methode, kombiniert mit den richtigen Werkzeugen (Den-Sprache, Editor, Compiler, Macro-Processor, Test-Tools etc.) und dem richtigen Management, ermöglicht gegenüber den bekannten Methoden ohne weiteres eine Reduzierung der Software-Kosten (Entwicklung und Wartung zusammengenommen) um etwa den Faktor 2, bei fortgeschrittenem Verständnis auch mehr.

*Heinz Mann ist Abteilungsleiter in der DSE-Anwendungsentwicklung Banken, Versicherungen und öffentliche Verwaltungen bei der Honeywell

Bull AG in Eschborn