Wie schon der vorige Teil a), so beschäftigt sich auch dieser b)- Teil des dritten Hauptabschnittes mit der Erstellung von Batch-Programmen nach Programmvorgaben unter Anwendung des Delta**-NP-Generators mit besonderer Berücksichtigung der Jackson-Methodik. Bild 3 des Beitrags in der vorigen CW-Ausgabe zeigte als Ergebnis der Datenstruktur-Umwandlung das "Schachtelhalm"-Diagramm. An diese Darstellung knüpft der weitere Text an.

Die Schachtelhalm-Struktur wird dem Delta-NP-Generator mitgeteilt und zwar beispielsweise durch folgende Befehle:

.GRU-DAT(EI)

.GRU-KU(NDE)

.GRU-FIL(IALE)

.GRU-OBJ(EKT)

.GRU-SATZ

Der Generator legt aufgrund dieser Befehle entsprechend viele sogenannte Programmebenen an. Die Bilder 4 bis 6 zeigen das Programmskelett mit seinen Bausteinen, die durch diese Befehle angelegt werden. An dieser Stelle kommt die Mächtigkeit des Delta-Systems voll zum Tragen: Mit diesen wenigen.GRU-Befehlen erstellt der Generator einerseits ein Baukastengerüst, ein Schubladensystem (die einzelnen Bausteine werden "Locationen" genannt), in das andererseits Makros (etwa der File- oder der Report-Generator) und vorwiegend der Programmierer Anwendungscode hineinstellen. (Der Code für die Ablaufsteuerung, mithin für die Ansteuerung der einzelnen Bausteine, wird gleichfalls maschinell generiert.)

Durch die einheitlichen wenigen Präfixe, die für die Baustein-Namensvergabe in jeder Programmebene verwendet werden, ist das System schnell erlernbar:

I- = Initialisierung

S- = Statusprüfung (Prüfung, ob neuer Gruppenbegriff gültig)

C- = Close (nicht im Sinne von "Schließen Dateien", sondern im Sinne von Abschluß der jeweiligen Ebene)

Jede Programmebene ist selbst wiederum in zwei Unterebenen gegliedert:

- die eine ist die Ebene mit den I-, S-, C-Bausteinen

- die zweite Ebene wird nach der Statusprüfung angesteuert, und zwar:

Bearbeitung einer falschen Gruppe (Kennzeichen 0):

O-0-: Open falsche Gruppe

P-0-: Process falsche Gruppe und Nachlesen bis "neue Gruppe"

C-0-: Close falsche Gruppe

Bearbeitung der richtigen Gruppe (Kennzeichen 1):

O-1-: Open richtige Gruppe (Gruppenanfangsverarbeitung); diesem Baustein schließen sich die "DO-WHILE"-Befehle an (vom Generator bereitgestellt)- sie steuern iterativ so lange die nächste Ebene an, bis ein neuer Gruppenbegriff vorliegt.

P-1-: Process richtige Gruppe (Gruppenwechselverarbeitung)

C-1-: Close richtige Gruppe (Abschluß Gruppenwechselverarbeitung)

Jedem dieser Präfixe folgt in den Bausteinamen die in den.GRU-Befehlen genannte Bezeichnung der jeweiligen Programmebene.

In den Bildern 4 bis 6 sind diese Bausteinnamen umrandet. In diese Bausteine stellt der Anwendungsprogrammierer seinen Cobol-/PL/1-Code mit dem Zuweisungsbefehl "Store to Location" (etwa:.SL = P-1-OBJ) ein. Alle anderen Teile generiert der NP-Generator automatisch, auch die "PERFORM GETI"-Befehle und die GETI-Routine selbst (in der die sequentiellen Input-Datei(en) gelesen werden, in der auch bei mehreren physischen Eingabedateien im Rahmen des Mischprozesses der nächste Satz ausgewählt wird).

Auch die notwendigen Befehle für das Lesen und Rückschreiben von Update-/Referenz-Dateien werden durch den File-Generator automatisch in die richtigen Bausteine eingestellt.

Ein Problem der bisherigen Normierten Programmierung löst dieser Generator automatisch:

* Bei sequentiellen Stammdateien, die im "Vater-Sohn"-Prinzip fortgeschrieben werden, mußte bisher der Programmierer die Einleseprioritäten selbst wählen und den Abgleichprozeß selbst programmieren.

* Dies geschieht jetzt vollständig automatisch: Die sequentielle Stammdatei ist im logischen Sinne keine steuernde sequentielle Eingabedatei (dies ist nur die Änderungs-/Bewegungsdatei). Die Stammdatei wird dem File-Generator als Update-Datei mit dem Parameter "replace" mitgeteilt; der Generator stellt damit in die richtigen Bausteine die Befehle für das Lesen der Vater-Datei und das Schreiben der Sohn-Datei: Der Anwendungsprogrammierer hat "den Eindruck", es handele sich um eine normale übliche, bisherige Update-Datei.

* Handelt es sich tatsächlich um diese "übliche" Update-Datei (also nicht um eine sequentiell, sondern um eine wahlfrei organisierte Datei, in der die veränderten Sätze direkt zurückgeschrieben werden), so teilt der Programmierer dies dem File-Generator mit "update-onplace" mit.

* In beiden Fällen werden die Lese-Nachlese-, Schreibbefehle sowie die Befehle für das Setzen der Kennzeichen "found" oder "not found" den richtigen Bausteinen automatisch zugeordnet.

Das Problem, auf höheren Ebenen unterschiedliche Gruppenverarbeitungsbausteine für "richtige" und "falsche" Gruppenbegriffe abhängig von Prüfungen anzusteuern, die erst auf unteren Ebenen geschehen ("Backtracking"), löst der Generator vollautomatisch (eine Hauptgruppe ist ja erst dann gültig, wenn mindestens ein Satz mit auch gültigen Untergruppen vorliegt).

Kommen wir zum Ausgangspunkt des zweiten Abschnittes der Programmvorgabe zurück: Aus der komplexen Datenstruktur haben wir einen Schachtelhalm gewonnen; dieser Schachtelhalm ist Basis für das Schreiben der ".GRU"-Befehle. Damit ist die Anzahl der Programmebenen festgelegt. Die schwierigste Hürde beim Programmdesign ist nun genommen; alles andere ist (fast) nur noch Fleißarbeit.

Den Registern 3 bis 6 der Programmvorgabe werden die Dateien-, Satz-, Feldbeschreibungen (in der Regel in der Form von Hardcopy-Ausdrucken) aus den Datenbeschreibungsbausteinen des File-Generators oder aus einem Data-Dictionary zugeordnet.

Abschnitt 7 der Programmvorgabe: Sofern der Organisationsprogrammierer dieses bei einem komplexen Programm für notwendig hält, kann er unter Abschnitt 7.1 einen Gesamtüberblick ablegen, der so strukturiert ist, wie dies durch die Bilder 4 bis 6 gezeigt wird.

Unter Register 7.1 wird die verbale Beschreibung der Dateiebene, unter 7.2 bis 7.8 die Beschreibung der Gruppenebenen, unter 7.9 die der Satzebene abgelegt. Innerhalb jeder Ebene wird der verbaIe Text nach den I-, S-, C- und O-, P-, C- (0-, -1-)Bausteinen gegliedert, wobei bei komplexen Abhängigkeiten innerhalb dieser Bausteine Entscheidungstabellen angewendet werden (und zwar so, daß diese unmittelbar als Eingabecode für den -Generator dienen können).

Um im Register 8 genau die Texte aus dem Funktionsdesign (Systemplanung) und Systemdesign abzulegen die das jeweilige Programm betreffen müssen lediglich die ".ADD"-Befehle geschrieben werden, die auf die jeweiligen Textbausteine verweisen.

Begleitender Werkzeugkasten

Gleichgültig, wie weit eine jeweilige Programmvorgabe vorangeschritten ist, Delta generiert aufgrund dieser vorhandenen Anweisungen die entsprechenden Texte, Handbücher Programmskelette etc., die in die Register abgelegt werden können. Mit diesen Vorabandrucken kann die Arbeit in der Vorgabe fortgesetzt werden, bis sie komplett ist. Ein letzter Generierungslauf stellt dann die Unterlage für den Programmierer dar, er aufgrund der verbalen Beschreibungen in Abschnitt 7 den entsprechenden Code den hier genannten Bausteinen zuordnet.

Der Leser wird festgestellt haben daß der Erstellungsprozeß eines Programms durch den "Werkzeugkasten" Delta voll begleitet wird. Die Methode komplexe Datenstrukturen in Schachtelhalmstrukturen umzuwandeln und hieraus die Programmebenen abzuleiten wird durch den Delta-NP-Generator unterstützt und führt zu klar strukturierten transparenten und pflegefreundlichen Batch-programmen. Die sich gleichzeitig ergebende einheitliche Sprache zwischen allen EDV-Mitarbeitern liegt auf der Hand.

Aber: Bildschirm-/Dialogprogramme können mit dem NP-Generator nicht realisiert werden. Gibt es eine ähnlich elegante Methode für solche Programme ? Die Antwort auf diese Frage gibt der nächste Teil dieser Reihe.

Von Klaus D. Ahrens*