Es dürfte notwendig und sinnvoll sein, ein weiteres Mal Stellung zu nehmen, um den Kompromiß, der bis jetzt durch die Diskussion auf Leserbriefbasis bereits erzielt wurde, zu festigen. Ich wollte mit meiner ersten Stellungnahme (CW-Nr. 34 vom 22. August) keineswegs den Sinn der Struktogramme in Frage, sondern in erster Linie zwei Kritikpunkte herausstellen.
Es ging dabei
1.) um den Widerspruch zwischen den Aussagen am Anfang und Ende des Artikels (CW-Nr. 30 vom 25. Juli) "Der Programmablaufplan kann einem Struktogramm das Wasser nicht reichen, von ganz wenigen Ausnahmen abgesehen." Und "In manchen Fällen sind Ablaufpläne sogar übersichtlicher als Struktogramme und diesen vorzuziehen", wobei die Anfangsaussage durch einen Vergleich der zwei Methoden mit unfairerweise unterschiedlichen Vorgaben belegt werden sollte.
2.) ging es um die Herausstellung der Ergebnisse des modularen strukturierten Programmierens als Vorteile der Struktogramme.
Man muß doch die historische Entwicklung berücksichtigen (Wann erschien was erstmals in der Literatur?). In diesem Fall ist es so einfach, wie es sonst nicht immer der Fall ist. In der August-Ausgabe der ACM-SIGPLAN Notices des Jahres 1973 erschien der Artikel "FLOWCHART TECHNIQUES FOR STRUCTURED PROGRAMMING" der Autoren Nassi und Shneiderman vom Department of Computer Science der State University of New York.
Dort heißt es in der Kurzfassung (sinngemäß übersetzt) "Mit dem Erscheinen der strukturierten und GOTO-freien Programmierung wird eine Methode zur Modellierung von Berechnungen in einfach geordneten Strukturen notwendig. Jede dieser Strukturen soll einen kompletten Gedanken repräsentieren, der möglicher weise in Form von anderen, bis dahin nicht definierten Gedanken definiert wird. Ein Modell ist notwendig, des einen uneingeschränkten Kontrollfluß verhindert und eine Kontrollstruktur aufweist, die den zur strukturierten Programmierung zugerechneten Programmiersprachen nahekommt."
Im Text werden dann unter anderem folgende im Literaturverzeichnis des Artikels genannten Veröffentlichungen referiert:
1) H. Mills: Top-Down Programming in Large Systems in Debugging Techniques in Large Systems (Courant Institut)
2) E. W. Dijkstra: Structured Programming in Nato Science Committee - Software Engineering Techniques (April 1970)
3) E. W. Dijkstra: GO TO Statement Considered Harmful in CAM V 11
No. 3
4) C. Bohm and G. Jacopini: Flow Diagrams, Tuning Machines and Languages With Only Two Formation Rules in CAM V9 No. 5
Um meinen ersten Satz wieder aufzugreifen, in dem ich von einem Kompromiß sprach, möchte ich, der ich an unserer Universität für die Wartung eines Struktogrammgenerators für Programme in der Programmiersprache Pascal verantwortlich bin, den letzten Absatz in der Erwiderung von Herrn Elstermann (CW-Nr. 38 vom 19. September): "Varianten der Struktogramme sind modulare Ablaufpläne und Pseudocode. Sie gehen von der gleichen Strukturierungsidee aus sind in der Darstellung jedoch unterschiedlich und gefallen mal dem einen, mal dem anderen mehr," unterstreichen - mit der einzigen Einschränkung, daß ich in meiner Erwiderung keinen Pseudocode, sondern ein Programm in der höheren Programmiersprache Pascal, das von einem Compiler direkt in Maschinenbefehle übersetzt werden kann, gegenüberstellte.
Ich halte Struktogramme als "Zwangsjacke", um Programmierer zum strukturierten Programmieren mit der Absicht zu zwingen, wartungsfreundliche Programme zu erhalten, für äußerst sinnvoll. Andererseits haben wir in unserem CAP-Projekt "Implementierung einer Beschreibungssprache für parallele Systeme mit Verifikations- und Parallelisierungsalgorithmen" am Lehrstuhl Informatik 1 der Universität Dortmund (sechs Wissenschaftler und zwölf Studenten) mit den folgenden Programmierrichtlinien gute Erfahrungen gemacht:
1) Einheitliche Programmiersprache Pascal
2) Kein Unterprogramm größer als eine Seite
3) Keine Sprünge (GOTO), deshalb notwendigerweise Fehlerausgänge über den Prozedurausgang leiten und durch Fehlerkennzeichen im Fehlerausgabeparameter anzeigen.
4) Notwendige Daten- und Kontrollflußdokumentationen grundsätzlich im Quellprogramm.