Wechsel in der Art der Darstellung oder Formulierung sind Quellen für Mißverständnisse und Fehler:

Programmcode als Abbild eines Struktogramms

12.03.1982

An dieser Stelle präsentiert der Verfasser ein Prozessorsystem, das er an der Universität-Gesamthochschule Siegen auf verschiedenen Systemen aIs Testversion implementiert hat. Am Beispiel einer Offenen-Posten-Mahnung, deren sachlicher Inhalt von dem einen oder anderen Leser ein gewisses Maß an Großzügigkeit verlangen mag, wird dargelegt. wie der Anweisungsteil eines Cobol-Programms aus einem Struktogramm hergeleitet wird.

Das Struktogramm rückt hier an den Platz des Programmtextes, wobei die im Beispiel benutzte Zielsprache Cobol mit Rücksicht auf den Leser gewählt ist, grundsätzlich aber auch andere Zielsprachen wie Fortran, Pascal oder Algol in der genannten Implementation Verwendung finden. Die Tendenz geht deshalb auch dahin, direkt in Assemblercode zu übersetzen und so das Kompilieren abzukürzen.

Das bei dem vorgestellten System verfolgte Ziel besteht darin, die Programmentwurfsunterlagen zu Programmtext und Programmdokument (vor allem in unveränderter Gestalt) werden zu lassen, und nicht aus einem skizzenhaften Entwurf - etwa nach Constantine - eine Darstellung in grafischen Symbolen á la DIN 66001, daraus einen Programmtext (beispielsweise ein Cobol-Programm) und schließlich daraus ein Dokument (etwa ein Struktogramm) abzuleiten. Wechsel in der Art der Darstellung oder Formulierung sind Quellen für Mißverständnisse und damit für Fehler, die schwer aufzudecken sind, da sie nicht syntaktischer Natur sind.

Das Beispiel besteht aus drei Abbildungen. Abbildung 1 zeigt das Kartenbild, das aus der Übertragung einer Struktogrammskizze entsteht.

Die erste Karte enthält Zeichen die zur Darstellung und Deutung des Struktogramms notwendig sind. Der Reihe nach bedeuten diese: Beginn einer Senkrechten (;), Ende einer Senkrechten (?), Senkrechte (Ü), Füllzeichen ( ), Waagerechte (_), Kommentar () und ein in der Übersetzung verwendetes Zeichen (&). Es ist kein Auszählen der Felder erforderlich, um ein lesbares Struktogramm zu erzeugen. Dieses geschieht im System, und das Ergebnis zeigt Abbildung 2. Jedes Struktogramm setzt sich bekanntlich aus konsequent geschachtelten Blöcken zusammen. Die Darstellung eines Blocks selbst hat syntaktische Bedeutung. Leider scheint es nicht möglich, allein mit grafischen Symbolen die Sprache zu gestalten. So sind neben den Blöcken andere Anweisungen wie LESEN, END OF FILE, EXIT etc. notwendig.

Die Anzahl der zu definierenden Blöcke hängt von den Anforderungen an die Sprache ab. Im Beispiel verwendet wurden:

Wie man leicht sieht, ist der Code nicht optimal, weder in der Zahl der Anweisungen noch in der Ausführungszeit. Jedoch ist der Code ein genaues Abbild des Struktogramms. Eine Optimierung kann angeschlossen werden; der erzeugte Code ist dann aber auch nicht mehr blockstrukturiert.

Das vorgelegte Beispiel entstammt einer Testversion. Es zeigt Möglichkeiten und Grenzen der Struktogramme auf. Wird das Struktogramm als Programmtext verwendet, so sind Änderungen in diesem Text mit einem Aufwand zu vergleichen, der dem in anderen Sprachen entspricht.

Es sei auch der Hinweis erlaubt, daß die vorliegende Kartenversion so verändert werden kann, daß der Entwurf der Struktogramme über Sichtgeräte durchgeführt wird, womit die Möglichkeit eröffnet würde, den gesamten Top-Down-Entwurf interaktiv durchzuführen.

* Dipl.-Math. Professor Dr. Hans-Joachim Ortolf ist Fachhochschullehrer für Statistik und Datenverarbeitung im Fachbereich 6/Mathematik der Universiäts-Gesamthochschule Siegen.