Bei dem Artikel in CW Nr. 34 "Die Krone gebührt dem modularen Programmieren" sowie dessen Auslöser in CW Nr. 30 "Wie ich lernte, Struktogramme zu lieben" fiel mir auf, daß in den gezeigten Struktogrammen für eine im Programm gewünschte Wiederholung kein zwingender Grund abgeleitet Vielmehr wird bei oberflächlicher Betrachtung des Verarbeitungsteils jeder Unbefangene zu dem Schluß kommen, daß hier in jedem Fall "Schluß" ist.
In der von mir entworfenen Version wird der Blick des Betrachters unwillkürlich nach oben zu "Lesen Erfassungsdaten" gelenkt. Die Transparenz der Darstellung wird dadurch erheblich verbessert.
Bezüglich der Äußerungen von Herrn Ewald gegen Struktogramme kann ich nur sagen, daß Sourcecode und Ablaufdiagramm in den aufgeführten Beispielen noch durchaus mithalten können, da es sich um ein kleines, abgegrenztes Problem handelt. In keinem Fall kann dies aber für Programmentwicklungen mit mehreren Mannmonaten oder gar Mannjahren gelten.
Die Strukturierung eines großen Programmpaketes ist mit den althergebrachten Methoden einfach nicht mehr praktizierbar.
1. Struktogramme sind in einer wesentlich kürzeren Zeit zu erstellen als andere Darstellungen (Drei bis vier Struktogramme pro Stunde sind keine besondere Leistung.)
2. Die Übersicht geht auch bei großen Mengen von Einzelaktivitäten nicht verloren.
3. Ein Struktogramm. zwingt zum STRUKTURIEREN, banal gesagt: "Wenn eine DlN-A4-Seite nicht mehr ausreicht, sollte man anfangen zu denken. "
4. Struktogramme bewähren sich in der Praxis nicht erst seit der Ausgabe 30/1980 der CW.
Im übrigen ist der Vergleich in der CW 30/l980 zwischen einem Struktogramm und einem Ablaufdiagramm, wie er hier gemacht wurde, trotz aller Begeisterung für Struktogramme natürlich nicht zulässig. Hier werden zwei Darstellungen unterschiedlichen Feinheitsgrades miteinander verglichen.
Ein Struktogramm kann und darf nur ein Mittel zur Erfassung der Programmablauflogik sein und als Instrument der Programmiervorgabe dienen. Einzelne Statements daraus zu machen, sollte dem Ersteller des Sourcecodes überlassen bleiben.
Zur Dokumentation eines Programmes reicht der sprechende Sourcecode, versehen mit einigen Kommentaren, dann vollkommen aus. Es ist in der Praxis sogar sinnvoll, bei der Betreuung laufender EDV-Verfahren tunlichst nicht mehr auf die ursprünglichen Struktogramme zurückzugreifen, da diese erfahrungsgemäß nach kürzester Zeit mit den tatsächlichen Programmen nicht mehr übereinstimmen.
*Jürgen Junger ist freier Unternehmensberater in Böblingen