MÜNCHEN (hö) - In CW-Nr. 30 vom 21. Juli 1978 ("Wer ist der Esel"?) nahm Dr. Reinhold Thurner, Sodecon AG, Dübendorf, Programmgeneratoren gegen die Kritik des Autorenteams Röttger & Osterberg in Schutz (CW-Nr. 27 vom 30.6.78, "Man schlägt den Sack und meint den Esel"). Die Herren Röttger und Osterberg meinen dazu, daß Herr Dr. Thurner ihren "Artikel verzerrt und verdreht hat, Polemik schlechten Stils betreibt, und - statt einen konstruktiven Beitrag zu leisten - nur mit allgemeinen Schlagworten am Problem vorbeiargumentiert". Hier ihre Slellungnahme:

Herr Dr. Thurner schließt seinen Artikel mit der Feststellung: "Richtige Wahl der Methoden und ihre Unterstützung durch eine klare Syntax... ermöglichen eine bessere und rationellere Systementwicklung". Dem muß man beipflichten, und die Beherzigung dieser Ratschläge empfiehlt sich auch für die Abfassung eines Zeitungsartikels. Das Verfahren jedoch, dem Gegner zu unterstellen, was nie gesagt oder angedeutet wurde, und auf dieses Phantom dann genüßlich einzuschlagen, ist eine Methode eigenen Art, deren Beurteilung wir uns ersparen wollen. Wenigstens fand Herr Thurner die "überraschende neue Variante" nachahmenswert, den fremden Esel zu schlagen und den eigenen zu loben. Und so wird wohl auch sein methodischer "Exklusivesel" in angestammten Compiler-Weidegründen weiter friedlich vor sich hin generieren.

"Jackson-Welle"

"Name-dropping" und zahlreiche Schlagworte alleine bringen die Diskussion nicht weiter. Man kann es sich natürlich leicht machen und auf der allgemeinen "Jackson-Welle" mitschwimmen. Auch wir kennen Jackson; zum Problem der NP hat er nicht viel beizutragen. Was er zum Beispie] über das Mischen von Dateien sagt (Abschnitt 4.2 Collating, Seite 70 ff.), stellt uns nicht zufrieden, ihn selbst offensichtlich auch nicht. Der letzte Absatz dieses Kapitels endet immerhin mit der resignierenden Feststellung: "This structure is, of course, vulnerable to changes in the specification just as the preceding structure is. Such vulnerability is the inevitable price for optimization." Und dabei mischt Herr Jackson nur zwei Dateien!

Werkzeuge

Zur Sache. Die "Methodenkonfrontation" hatten wir in unserem Artikel bereits deutlich verurteilt. Was wir gegenübergestellt haben, sind Werkzeuge, und da gibt es eben Unterschiede.

Wir stellten ein Werkzeug für die Normierte Programmierung vor, das man so leicht und selbstverständlich zur Hand nimmt wie Bleistift und Codierblatt Warum ist dieses Werkzeug so unbequem?

Es nimmt dem Programmierer nicht nur Entwurf. Codierung und Test der Ablaufsteuerung ab, sondern unterstützt ihn auch methodisch, indem es ihn von der Aufgabenstellung zur Problemlösung hinführt. Das Wesentliche dieser Methode ist ein weiterentwickeltes Blockrezept.

Die Anzahl der zu mischenden Dateien beziehungsweise der Gruppenstufen hat dabei weder einen Einfluß auf die Größe der Steuerung noch auf den Grad der Komplexität der Verarbeitungsblöcke im Programm. An das - so Dr. Thurner - "schwierige Problem der Plausibilitätsprüfung (auch der Gruppenebenen)" haben wir uns nicht nur "gewagt" - wir haben damit keine Probleme mehr: Die Eingabesituation für alle Gruppenstufen wird von der Steuerung automatisch und laufend in einer Tabelle von Zustandsvariablen festgehalten. Mit einer einzigen Abfrage kann so eine beliebige Dateienkonstellation auf einer beliebigen Gruppenstufe ermittelt werden. Durch gezielte Veränderung dieser Variab]en hat der Benutzer außerdem die Möglichkeit. Sätze im Programm logisch zu schaffen oder zu eliminieren, so daß Sonderfälle auf der Eingabeseite zu Normalfällen auf der Verarbeitungsseite werden. Damit entfällt das sonst übliche Gestrüpp von Abfrageketten. Keine noch so komplexe Struktur ist mehr "vulnerable to changes".

Auch die jeweiligen Schlüssel aller Gruppenstufen stehen direkt zur Verfügung. Werden sie für Listentitel, Summenzeilen und ähnliches benötigt, so muß nicht erst mühsam ermittelt werden, in welchem Datensatz (welcher Datei) sie enthalten sind.

Die Konventionen für die Gestaltung eines NP-Programms sind auf der Basis einer solchen Verallgemeinerung tatsächlich auf einem DIN-A4-Blatt darstellbar und von einem NP-Kenner in einer halben Stunde erlernbar. Und diese wenigen Konventionen gelten für Programme beliebig komplexer Struktur. Dadurch wird die Ablaufsteuerung endlich zu einem Trivialproblem, und der Programmierer kann sich der eigentlichen Aufgabe zuwenden. Auch wenn es Dr. Thurner zu überraschen schien: Wir verwenden dieses NP-Werkzeug seit 1970.

Neuartige Lösungsansätze

Mit Werkzeugen solcher Art erscheint die Frage des methodischen Ansatzes zur Lösung von Problemen in einem anderen Licht. Sie eröffnen neue Möglichkeiten zur "besseren und rationelleren Systementwicklung". Und zwar dadurch, daß sie den wirklich mechanischen und automatisierbaren Teil eines Aufgabentyps vollständig übernehmen, während der Teil der Aufgabe, der nur mit "Verständnis" zu lösen ist, beim Programmierer bleibt. Bei ihm ist er auch besser aufgehoben als bei einem Super-Apparat, der zu seiner Bedienung zusätzliches Verständnis voraussetzt.

Nach unserem ersten Artikel haben uns frustrierte Anwender von NP-Generatoren geschrieben. Erfahrungsberichte solcher Anwender wären für die CW-Leser sicher eine interessante Fortsetzung dieser Kontroverse.

Christoph Röttger & Wolf-Heinrich Osterberg, Software-Technik München 5, Buttermelcherstraße 19, Tel.: 29 61 01