Strukturierte Programmierung - a revolution in programming? (Dijkstra [1])

"Der Generator ist nicht so wichtig"

27.03.1975

Exclusiv für CW, von Dr. Ch. Floyd

MÜNCHEN - Als der Wiener Mediziner Prof. Semmelweis den Zusammenhang zwischen mangelnder Hygiene und der damals üblichen hohen Sterblichkeit von Müttern im Kindbettfieber feststellte, erregte er mit seiner Behauptung zunächst Befremden und Entsetzen unter seinen Kollegen und den Zuständigen in der Krankenhausverwaltung.

Zwar stützten sich die von ihm formulierten Forderungen der Hygiene auf fundierte wissenschaftliche Erkenntnisse. Sie stellten aber die gesamte Krankenhauspraxis in Frage. Offenbar mußte das Pflegepersonal neu geschult werden. Die Organisation des Krankenhausbetriebs mußte geändert werden. Der tägliche Ablauf wurde unweigerlich verlangsamt. Althergebrachte Gewohnheiten und Geräte erschienen plötzlich fragwürdig.

Und war es für damals praktizierende Ärzte wirklich glaubhaft, daß durch so einfache

Maßnahmen wie konsequentes Händwaschen und Gerätereinigen eine drastische Reduzierung der Sterblichkeitsrate erreicht werden konnte? Sicherlich schien es vielen, als hätte man es "sowieso immer schon so gemacht", als brächten die neuen Forderungen nur Mühsal, aber nichts wesentlich Neues.

Trotz dieses anfänglichen Widerstandes konnten sich die neuen Methoden zum Vorteil aller Betroffenen in der Medizin durchsetzen.

Die Analogie zur gegenwärtigen Situation in der EDV läßt, sich erstaunlich weit führen.

Auch hier besteht die Notwendigkeit einer drastischen Verbesserung. Auch hier wurde von einer Gruppe von Wissenschaftlern, geführt von Prof. E. W. Dijkstra, eine neue Methodik vorgeschlagen, die überall in der Praxis der Datenverarbeitung angewendet werden kann und sollte: die strukturierte Programmierung und auf sie abgestimmte Verfahren der Systementwicklung und Projektorganisation.

Und auch hier kann die Wirkung der neuen Methodik nicht durch Verwendung eines bestimmten technischen Hilfsmittels automatisch gewährleistet werden; sie beruht auf einer konsequenten Verbesserung der Arbeitsmethode. Sie erfordert Umdenken und Umschulung für die meisten Programmierer bzw. konsequentes Anwenden der Prinzipien für diejenigen, die es "immer schon so gemacht haben". Sie erfordert in vielen Betrieben eine Neuorganisation von Programmiergruppen und DV-Management. Sie impliziert sogar langfristig ein neues Rollenverständnis für den Programmierer.

Die gemeinsame Grundlage für sämtliche Empfehlungen der neuen Methodik bilden Erkenntnisse über die Arbeitsweise des menschlichen Verstandes ("It is a return to common sense in programming" - [2]). Das Ziel ist die Erhöhung der Qualität von Programmsystemen (Zuverlässigkeit, Flexibilität, Benutzerfreundlichkeit, Effizienz) sowie eine erhebliche Reduzierung der Herstellungs- und Wartungskosten.

Es wird dadurch erreicht, daß bei der Planung und Implementierung von Systemen darauf geachtet wird, daß das entwickelte System "intellectually manageable" bleibt, überblickbar, verstehbar. Daraus ergeben sich eine Reihe von konkreten Forderungen, die konsequent und gemeinsam angewendet werden müssen, um die gewünschte Wirkung zu erzielen:

- Ausarbeitung der Anforderungen und externen Charakteristika eines Systems vor Beginn der Planung. Dies gilt für das gesamte System und für jeden Systemteil: die exakte verbale funktionale Beschreibung des Systems bildet die Grundlage für seine Entwicklung.

- Modularisierung des Systems in einer hierarchischen Struktur. Dabei dienen einzelne Ebenen zur schrittweisen Abstraktion bzw. Konkretisierung der Aufgabenstellung [4].

- Vereinfachung der Schnittstellen zwischen einzelnen Moduln. Schnittstellen dienen nur zur Weitergabe von einfachen Werten, sie enthalten keine komplizierten Datenstrukturen [3].

- Entwicklung jedes Programms durch schrittweise Verfeinerung seiner funktionalen Beschreibung. Dabei werden verwendete Datenstrukturen und Verarbeitungsalgorithmen gemeinsam verfeinert ([4], [5])

- Beschränkung auf wenige einfache sprachliche Mittel zur Beschreibung des Steuerflusses. Zur Formulierung jedes Programmes reichen drei Grundkonstruktionstypen (Strukturblöcke) aus: die sequentielle Aneinanderreihung, die Fallunterscheidung und die bedingte Wiederholung [6]. Diese Strukturblöcke können in jeder höheren Sprache ausgedruckt werden (u. a. [7], [8]). "Wilde Sprünge" im Programm sind gefährlich [9], die Verwendung von Sprungbefehlen wird daher verboten oder zumindest drastisch eingeschränkt [10].

- Problemnahe Datenbehandlung. Daten werden unterteilt in "manifeste" Konstanten, in Verarbeitungsdaten und steuernde (logische) Daten. Datenwerte werden konsequent überwacht. Daten werden logisch strukturiert, ihr Gültigkeitsbereich vom Programmierer angegeben. Leider unterstützen nur wenige Sprachen (Pascal [11]) diese Prinzipien. Die meisten Programmierer sind hier auf Selbstdisziplin und Kommentare angewiesen.

Praxis der Strukturierten Programmierung

Für die praktische Arbeit nach den Forderungen der Strukturierten Programmierung müssen vor allem die allgemeinen Prinzipien auf die Erfordernisse einzelner Programmiersprachen und einzelner Projekte adaptiert werden. Sie sind dann Richtlinien für die Erstellung von Programmierstandards Schnittstellenkonventionen u. a. (siehe z. B. [12]).

Altgewohnte Hilfsmittel wie etwa das Flußdiagramm erscheinen fragwürdig. Struktogramme ([13] [14]) sind für die graphische Darstellung eines strukturierten Programmes besser geeignet. Eine übersichtliche graphische Darstellung der funktionalen Zusammenhänge eines Systems ermöglichen die von IBM entwickelten HlPOs (Hierarchy of Input-Processing-Output) [15].

Computerunterstützung

Der auch in dieser Zeitschrift schon verwendete Ausdruck "Generator für Strukturierte Programmierung" ist unglücklich gewählt; ein Großteil der Forderungen der Strukturierten Programmierung kann nämlich nicht mechanisch erzwungen werden ([1] Seite 863).

Systeme, die die Strukturierte Programmierung unterstützen [16] können folgende Ziele haben:

- Mechanisches Erzwingen einiger Forderungen der Strukturierten Programmierung, insbesondere bei der Steuerflußbeschreibung

- Erzeugung von Dokumentation z. B. von Struktogrammen

- Erleichterung der Routinearbeit des Programmierers

- Interaktive Führung des Programmierers bei der Programmentwicklung.

Diese Ziele müssen erreicht werden, ohne dem Programmierer unzumutbare Mehrarbeit aufzulasten. So erfordert etwa das in [16] erwähnte PAD (Programmieren durch Auswählen im Dialog) System von der TH Darmstadt zu viele Dialogschritte; Struktor (ADV-Orga) verlangt ein zweidimensionales Eingabeformat, das die mit diesem System entwickelten Programme wenig änderungsfreundlich macht. Die Eingabeschnittstelle von Columbus (Softlab) ist wesentlich günstiger gewählt.

Eine wohldurchdachte Computerunterstützung für die Strukturierte Programmierung ist sicher wünschenswert. Das Wesentliche bleibt aber die Anwendung der Methode. Und das kann auch ohne mechanische Hilfsmittel realisiert werden. Daß die Strukturierte Programmierung die von ihr erhobenen Ansprüche erfüllt, bewies inzwischen die Erfahrung [17].

Um eine "Revolution" zu bringen [1], muß sie sich allgemein durchsetzen. Allerdings: Der Zwang zur Verbesserung der Arbeitsmethoden ist in der DV nicht ganz so groß wie in der Medizin.

Bei uns geht es zum Glück nicht um Leben und Tod der Benutzer.

Dr. Christiane Floyd

wurde 1944 in Wien geboren. 1966 promovierte sie in Mathematik an der Universität Wien.

Von 1970 bis 1973 hielt sie Gastvorlesungen an der Stanford University in Californien - über Strukturierte Programmierung. Vorher hatte sie dort als wissenschaftliche Mitarbeiterin zwei Jahre im Computer Science Department verbracht und - unter anderem - an der Entwicklung eines Compiler-Compilers gearbeitet.

Heute ist Dr. Floyd Mitarbeiterin der Firma Softwarelabor, München.