Normierte Programmierung:

Man schlägt den Sack und meint den Esel

30.06.1978

Wie jeder Fachmann weiß, sind Vergleiche unsinnig, deren Ergebnis nahelegt, auf die Normierte Programmierung (NP) zugunsten von anderen Verfahren zu verzichten. (Siehe auch CW-Nr. 23 vom 2. Juni 1978: "Strukturiert: Normiert programmiert").

Die NP definiert den genauen Ablauf für Programme mit sequentieller Dateniverarbeitung - und das ist auch heute noch die Mehrzahl aller kommerziellen Programme. In diesem Rahmen können beliebige Techniken und Methoden verwendet werden. Strukturierte Programmierung (SP),Entscheidungstabellen-Technik, Modulare Programmierung können ohne weiteres mit der NP kombiniert werden.

Wie kommt es also, daß die Normierte Programmierung immer wieder angegriffen und in Konkurrenz zu anderen Programmier-Methoden und -Techniken gesehen wird? (CW-Nr. 20 vorn 12. 5. 78: "Für alle Phasen der Programmierung.")

Gipskorsett und Rollstuhl

Die Vorurteile und Widerstände gegen die NP werden dann verständlich, wenn man einige der Hilfsmittel betrachtet, die dem Programmierer zum praktischen Einsatz angeboten werden. Das sind Programmieraleitugen und/oder Generatoren, die einem Programmierer soviel (oder so wenig) nützen, wie Gipskorsett und Rollstuhl einem Fußballspieler Tore schießen helfen: Hilfsmittel dieser Art schaffen mehr Probleme, als sie lösen.

Wesentliche Probleme dabei sind:

- umfangreiche, aufgabenfremde Konventionen und Terminologie: Vorgabe komplexen Namensgebilde, Zeilennummernakrobatik etc.

-Formatzwang bei der Formulierung der Aufgabe

-Aufgabenanmaßung, die zu uneingelösten Versprechungen führt, verstärkt die Belastung durch Konventionen (was haben Dateibeschreibungen mit dem Programmablauf zu tun?); statt gewohnter und verständlicher Angaben (RECORDING MODE F) müssen zusätzlich zu lernende, undeutliche Verschlüsselungen gemacht werden ("3" in Spalte 27 der Kartenart XYZ)

-Generierungsläufe, häufig in mehreren Versuchen, müssen zusätzlich zu den Übersetzungsläufen durchgeführt werden

-Übertriebene Schematisierung verhindert die klare Gliederung der jeweiligen Aufgabe: Vor lauter Bäumen sieht man den Wald nicht mehr.

Erlernen und laufende Benutzung solcher "Werkzeuge" sind und bleiben ein Alptraum!

Ein Verzicht auf die NP wäre jedoch ein Rückschritt, da für jedes Programm mit sequentieller Dateiverarbeitung der Ablauf neu zu entwerfen, zu codieren und zu testen wäre (erfahrungsgemäß treten etwa 50 Prozent der Fehler in der Ablaufsteuerung auf!), ein Verzicht auf die Generatoren dagegen wäre ein Fortschritt.

Umständliche Anleitungen

Was kann der Anwender tun? Er möchte weder benutzerunfreundliche Generatoren einsetzen noch nach umständlichen Anleitungen die Programmsteuerung immer wieder neu selbst stricken.

Wir haben dieses Problem bereits vor vielen Jahren auf folgende Weise gelöst:

Eine generalisierte Steuerung mischt beliebig viele Dateien (Tabellen, Datenbariksegmente etc.) und kontrolliert den Ablauf beliebig vieler Gruppenstufen.

Die wenigen Konventionen finden auf einer DIN-A4-Seite Platz und sind in einer halben Stunde bequem erlernbar; für die Steuerung eines Programmablaufs sind nämlich nicht mehr Konventionen erforderlich!

Günstiges Pagingverhalten

Generierungsläufe gibt es nicht. Der Code der Steuerung wird je nach Programmiersprache durch Makroaufruf, COPY- oder INCLUDE-Anweisung Bestandteil des jeweiligen Quellenprogramms. "Ganz nebenbei" verwaltet die Steuerung auch noch eine Tabelle mit Zustandsvariablen, die für jede Datei auf jeder Gruppenstufe über An- bzw. Abwesenheit eines Satzes für die laufende Gruppe sowie die vorhergehende Gruppe Auskunft gibt.

Das erspart beim Programmieren viele komplexe Vergleiche.

Die Größe dieser Steuerung (ca. 0,6 KB in der Assembler-Version) hängt nicht von der Anzahl der Dateien oder Gruppenstufen ab.

Ein interessanter Nebeneffekt bei Verwendung dieser Steuerung ist ein besonders günstiges Pagingverhalten bei virtuellem Speicher.

Diese Steuerung übernimmt also den Teil des normierten Programmablaufs, der wirklich automatisierbar ist. Dadurch, daß sie den Program. mierer nicht belastet, stellt sie ein echtes Werkzeug dar, das wir so leicht und selbstverständlich zur Hand nehmen wie Bleistift und Codierblatt. Wohl auch aus diesem Grunde haben wir für unsere Steuerung Anwendungsgebiete gefunden, bei denen man zunächst nicht an die Verwendung der NP denken würde.

Im Rahmen solcher Möglichkeiten stellt sich die Frage nach Ablösung der NP durch andere Verfahren nicht mehr. Als überzeugte Anwender auch von Strukturierter Programmierung, Entscheidungstabellentechnik und Modularer Programmierung kombinieren wir diese Verfahren je nach Erfordernis mit der NP.

* Christoph Röttger und Wolf Osterberg sind Mitarbeiter der Arbeitsgemeinschaft Soffwaretechnik, Buttermeicherstraße 19, 8000 München 5