Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.07.1978

Normierte Programmierung:Wer ist der Esel?

DÜBENDORF/SCHWEIZ (hö) - In CW-Nr. 27 vom 30. Juni 78, Seite 8, verurteilte das Autorenteam Christoph Röttger und Wolf Osterberg, Mitarbeiter der Arbeitsgemeinschaft Softwaretechnik, den Einsatz von Programm-Generatoren: "Man schlägt den Sack und meint den Esel." Anderer Meinung ist Dr. Reinhold Thurner, Sodecon AG, Dübendorf, der durch die Entwicklung und Anwendung der Generatoren Detab und Delta (die selbst mit Hilfe von Generatoren geschrieben wurden) genau die gegenteilige Erfahrung gemacht hat. Thurner findet, daß "die Situation - insbesondere was den Wert von Hilfsmitteln anbelangt - völlig falsch dargestellt ist". Hier sein Statement:

In der Diskussion um normierte und strukturierte Programmierung wurde in der Tat gelegentlich der Sack geschlagen, um den Esel zu bewegen. Die Autoren des letzten Artikels haben eine überraschende neue Variante gebracht, indem sie zwar die fremden Esel schlugen, aber die eigenen lobten.

Diese schlimmen Programmgeneratoren sollten ausgerottet werden - so hieß es da - , sie seien syntaktisch schlecht, schematisieren übertrieben, vermischen die Aufgaben. Da lobe ich mir die vorgeschlagene Lösung mit einem syntaktisch klaren COPY oder einem Macro-Aufruf (mein Freund Witt dazu "The poor man's compiler"). Und das besonders dann, wenn die ganze Sache 0,6 KB, eine A 4-Seite, eine halbe Stunde Lernaufwand kostet und schon seit vielen, vielen Jahren gelöst ist.

Methodenkompatibilität

Die normierte Programmierung definiert den Programm-Ablauf und die Baustein-Struktur für eine Datenstruktur, die Jackson folgendermaßen darstellt (siehe Grafik).

Die Ergänzung der Jackson-Methode durch das Bausteinkonzept der normierten Programmierung (Bausteine für Anfangs-/Endverarbeitung pro Gruppe) beschert uns einen einfachen und zuverlässigen Ablauf. Ja, wir können uns sogar an das schwierige Problem der Plausibilitätsprüfung (auch der Gruppenebenen) wagen, das Jackson mit seinem "Backtracking-Konzept" methodisch einleuchtend beschrieben hat. Lassen wir diese Überlegungen mit dem Baustein-Gedanken der normierten Programmierung und dem syntaktischen Gefühl der SP-Leute zusammenfließen, dann kann jeder der 3 Beteiligten dadurch nur gewinnen. Alte und neue Heilslehren können so zu einem vernünftigen Methodensatz für die Praxis umgeschmolzen werden. Methodenkompatibilität müssen wir anstreben; der Esel heißt Methodenkonfrontation und den gilt es zu schlagen. Er gehört zur Klasse der Exklusivesel, für die die Welt am Rande ihres Weidegrundes endet.

Wir können nicht bei allgemeinen Strukturierungskonzepten stehenbleiben, auch die Entwicklung von Methoden ist noch nicht ausreichend. Um die Produktivität und Qualität der Systementwicklung entscheidend zu verbessern, müssen wir zu einer Technik gelangen, die eine Beschreibung von Systemen mit einer guten (und standardisierten) Syntax und deren Umwandlung durch Compiler und Generatoren gestattet. Wir müssen aber entsprechende Qualität der Syntax und der Werkzeuge verlangen, damit sie zu einer echten Hilfe werden.

Die erwähnten "Alptraum-Werkzeuge" verdanken wir Leuten, deren syntaktisches Niveau sich in der "3" in Spalte 27 niedergeschlagen hat und deren Compiler-Technik sich auf Macros, Copy und Trivialexpansion beschränkt.

Der Programmierer ist der Esel, der als Handwerkszeug nur Papier und Bleistift kennt und den Computer nur für die Arbeit anderer einsetzen will. Er weiß eben, daß niemand so wie er Entscheidungstabellen umwandeln, NP-Strukturen programmieren und Pseudocode auscodieren kann.

Generatortechnik

Sie würden ein COBOL-Programm sicher nicht von Hand umwandeln. Sie würden aber auch nicht eine Programmkette einsetzen, deren erstes Programm die FILE-Section und Ein/ Ausgabe, deren zweites Programm die WORKING STORAGE sowie die MOVE und COMPUTE-Anweisungen bearbeitet, während das dritte die Ablaufbefehle umwandelt und das vierte schlußendlich die Verbindungen zwischen den Ausgaben der 3 Vorgänger (teilweise) herstellt.

Ja, Sie würden so etwas nicht einmal als Compiler, sondern als Alptraum bezeichnen. Seien Sie aber fair und bezeichnen Sie es nicht als Generatorsystem, wenn Ihr Code zuerst durch ein NP-Programm, dann durch einen ET-Umwandler, anschließend durch ein "System" für Datei und Satzbeschreibung und -Dokumentation muß, um unmittelbar darauf noch von einem Macroprozessor, einem Listengenerator und einem Umwandler für strukturierte Programmierung seziert zu werden.

Oder gehen Sie einen Schritt weiter und schlagen Sie dieses Ding, denn das ist der Esel und nicht die Generatortechnik an sich.

Richtige Wahl der Methoden und ihre Unterstützung durch eine klare Syntax und ein umfassendes Werkzeugsystem ermöglichen eine bessere und rationellere Systementwicklung. Unsere Anstrengungen sollten wir auf dieses Ziel ausrichten und jeder kann seinen Beitrag zu diesem Ziel beitragen.