Strukturiertes Programmieren, - was ist das eigentlich?

Vom Ende der Spaghetti-Technik

04.07.1975

Von John Wojak Exklusiv für CW

MÜNCHEN - Wer heute in der Programmierung "in" ist, der programmiert "strukturiert" in Cobol, Algol, PL/1 oder einer anderen gebräuchlichen Sprache. Zwar reden einige der Missionare der neuen Programmierkunst - hinter vorgehaltener Hand natürlich - von einer Verschwörung der IBM, die auf diese Art PL/1 verbreiten will und das Verhältnis von virtuellen zu realen Speichern zu erhöhen trachtet, die meisten der "Strukturierungsfanatiker" jedoch sprechen begeistert von "Problemlösungsmethodik" und "Programmiereffizienz".

Tabu für Go To

Der Begriff "Strukturierte Programmierung" stammt von Dr. E. W. Dijkstra, Professor für Mathematik an der Technischen Hochschule Eindhoven und wurde in mehreren Publikationen - deren berühmteste den Titel "Go To Considered Harmfull" trägt - zwischen 1968 und 1971 veröffentlicht. Das Konzept, zuerst wenig beachtet, wurde dann in den Vereinigten Staaten aufgegriffen und als "Revolution in der Programmierung" herausgestellt.

Dijkstra geht von der grundsätzlichen Feststellung aus, daß die Hauptschuld an schwer lesbaren Programmen, an hohen Fehlerquoten beim Programmieren, an der Erschwerung beim Testen und bei der späteren Programmpflege auf häufige Verwendung von "Go-To"-Anweisungen (beziehungsweise deren Equivalente) zurückzuführen sei. Dijkstra sagt, daß komplexe Problemstrukturen durchaus nicht zu komplizierten Programmstrukturen führen müssen. Dies bewirkt erst das Vor-, Zurück- und Überspringen in der Programmlogik mittels unbedingter Verzweigungen. Dies, so der holländische Professor, läßt sich weitgehend oder sogar vollständig vermeiden, wenn mit "Programmstrukturen" gearbeitet wird, die einmal von "oben nach unten" (Top Down) laufen, zum anderen auf Module zurückgreifen, die bestimmten Programmierebenen zugeordnet sind.

Hierarchie von Ebenen

Dabei ist die Konzipierung eines Programmes etwa wie folgt zu verstehen: zuerst werden die Bedingungen der Ablaufsteuerung, dann die Verarbeitungsphasen und endlich die einzelnen Befehlsroutinen festgelegt und programmiert. Dabei kann man überschaubare: Kontrollabschnitte schaffen, die den sogenannten "Seiten" bei virtuellen Speichern gleichen, und die zunächst noch nicht vorhandene Module simulieren.

Unter "strukturierter Programmierung" ist also eine Hierarchie von Ebenen zu verstehen, die jede in sich vollständig ist, nur je einen Eingang und Ausgang hat und jeweils selbständige Systemelemente erzeugt, die von der nächstniedrigen Programmierebene unterstützt werden.

Kein Programmgestrüpp

Ein selbständiges Systemelement kann zum Beispiel eine beliebige Input/Output-Operation, eine Rechenoperation oder die Auflösung einer Entscheidungstabelle sein.

So betrachtet, handelt es sich bei "Strukturierten Programmen" eigentlich um nichts anderes als um Programme mit hierarchisch sauber gegliederter Unterprogrammtechnik, bei der in einer Ebene jeweils Ablaufsteuerungsfunktion verschiedener Art auf Unterprogramme einer niedrigeren Stufe zugreifen. Beachtet man diese Voraussetzungen, dann wird klar, daß mit jedem Verzweigungsbefehl die Gefahr besteht, die "Struktur" zu unterlaufen oder sogar mit einer besonderen Klasse von Sprungbefehlen, den Schaltern, jede beliebige Programmstruktur in ein unübersehbares Gestrüpp von Ablauf- und Programmanweisungen verwandeln kann.

Saubere Unterprogramme

Dijkstra schlägt vor, statt der "Go-To"-Anweisung Bedingungssätze wie "If Then Do - Else Do" oder Anweisungen vom Typ "Perform" oder "Do" zu verwenden. Bei konsequenter Beachtung der Regeln müßten also Unterprogramme entstehen, die

- weitgehend merkmalfreie Anweisungssätze in einer höheren Programmiersprache enthalten.

- einen logischen Befehlsfluß in stets nur einer Richtung haben (Top-Down-Approach).

- Klare Trennung zwischen Befehlswegen und der Verarbeitung von Daten in mehreren Ebenen haben.

Zweifellos ist die Theorie des Professor Dijkstra richtig und interessant. Ein IBM-Team hat übrigens diese Grundlagen im praktischen Einsatz bei einer großen amerikanischen Zeitung erprobt.

Nur Euphorie?

Das klingt alles sehr gut und interessant, kann aber nicht darüber hinwegtäuschen, daß mindestens zwei Sachverhalte zu nennen sind, die geeignet erscheinen, zu große Euphorie über "Strukturierte Programmierung" einzuschränken:

1. Der größte Rationalisierungseffekt beim Programmieren ergibt sich nicht bei der Programmierung selbst, sondern durch "formale" (gute) Problemlösungsbeschreibung bei der Programmiervorgabe.

2. Die Mehrzahl der "Normalprogrammierer" hat - obwohl wir bereits sei Jahren von Modularen Programmen, von Normierter Programmierung und von Entscheidungstabellen sprechen - vorhandene Hilfsmittel zur Formalisierung von Programmen bisher kaum eingesetzt.

Sollte sich darum die Masse der Durchschnittsprogrammierer plötzlich mit "Strukturierter Programmierung" befreunden, dann dürfte sich ein Wunder am EDV-Horizont ereignet haben.