Die ersten Softwar-Tools für Strukturierte Programmierung (SP) von Siemens (COLUMBUS) und ADV/ORGA (STRUKTOR) sind weltweit eine Novität und verdienen einige Aufmerksamkeit. Die fast gleichzeitige Ankündigung der Systeme erhielt einen pikanten Anstrich durch den Verdacht, STRUKTOR könne ein Plagiat des COLUMBUS sein. (Siehe S. 1 "Strelt um Erstgeburt").
COLUMBUS-Erfinder Witt geht in Kleist'scher Manier auf die vermeintlich Elster-Tat ein. Dr. Schnupp (Softlab) zieht einen historischen Vergleich mit Datenbanksystemen und lehnt den Begriff Generator für SP ab. H. Neunert (ADV/ORGA) mißt Definitionen und Bezeichnungen nur akademische Bedeutung bei. Für Ihn stehen praxisorientierte Gesichtspunkte im Vordergrund. Er hält Struktor für eine Besinnung auf das Wesentilche: Routine-Arbeit der Maschine überlassen. Jörg Richter (ADVIS) schließlich sieht in Ankündigung und Gerede um Struktor mehr Show-Effekt als Nutzen für den Anwender. Er fürchtet sich vor einem Universal-Generator UNIGEN, der seiner Ansicht nach nur "NONSENS" generiert.
Dr. Peter Schnupp, Geschäftsführender Gesellschafter des Softwarelabors, München.
Was ist COLUMBUS? Dazu eine Parallele aus der Geschichte der EDV. Vor 15 Jahren etwa stellte man fest, daß das Datenmanagement eine extrem schwierige und fehleranfällige Aufgabe ist.
- Man schuf eine "Untersprache" mit Anweisungen für Datenmanipulation auf logischer Ebene, die das
Datenmanagement wesentlich erleichtern.
- Man fugt die gleiche Untersprache in alle verwendeten Programmiersprachen ein, wo ihre Anweisungen die alten, unhandlichen READs und WRITEs ersetzen.
Vor etwa 5 Jahren merkte man, daß die Handhabung der üblichen Programmfluß-Steueranweisungen, wie GOTO, Branch u. ä., bei komplex strukturierten Programmen mindestens ebenso schwierig wie das Datenmanagement ist. Idee des COLUMBUS ist es, das Übel ebenso zu kurieren.
- Die Untersprache, welche die steuernden Anweisungen, vor allem die GOTOs, in leder Programmiersprache ersetzen kann, mußte gar nicht mehr erfunden werden. Die strukturierte Programmierung stellt sie als IF-THEN-ELSE, DO WHILE, CASE und vielleicht noch einige Nebenformen dieser Grundanweisungen zur Verfügung.
- Dr. Witt schuf ein System, das diese Untersprache in jede Programmiersprache einfügt und damit dem Programmierer nicht nur Komfort sondern auch noch eine Vielzahl weiterer nützlicher Dienstleistungen bieten kann.
- Und er nannte es - Gott sei Dank - auch nicht "Generator für strukturierte Programmierung". Denn es generiert ja keine strukturierten Programme, sondern es verlangt sie als Eingabe und erzeugt daraus Quellsprachencode.
Deshalb einige Bitten an alle, die COLUMBUS nachimplementieren. Nennen Sie das System "Prozessor" oder "Werkzeug" oder "Übersetzer" oder -am besten - gleich COLUMBUS.
Fügen Sie in Ihren Subset bitte mehr Dienstleistungen ein, als nur den Struktogramm-Generator. Und wenn Ihr Struktogramm-Generator kein Struktogramm erzeugt, sondern eine sbstrakte Grafik, wie sie auf der ersten Seite der Nr. 5 der CW als Ausgabe des STRUKTOR abgebildet ist: lassen sie ihn einfach weg.
Struktogramme sind etwas Nützliches, aber COLUMBUS ist weit mehr als ein Zeichlengerät. Er liefert sprachliche Mittel, die dem Anwender helfen, durch strukturierte Programmierung seine Problemlösung klar zu formulieren und konsequent zu testen.
Horst Neunert, Stv. Leiter des Geschäftsbereiches Technische Systeme der ADV/ORGA F. A. Meyer KG München
ADV/ORGA denkt praxisorientiert und mißt der Frage, ob ein ORGWARE-Tool den Titel Generator verdient, nur akademische Bedeutung bei. Vielmehr erscheint uns die Besinnung auf das Wesentliche beim Einsatz solcher Werkzeuge entscheidend Tunlichst das Denken dem überlassen, der es kann die Routinearbeit aber der Maschine, die es besser kann. Alle sinnvoll arbeitenden Hilfsmittel wie z. B. Assembler, Compiler und Generatoren für Normierte Programmierung oder Entscheidungstabellen entsprechen diesem Prinzip.
Trotzdem ist die Routinearbeit für Analytiker und Programmierer heutiger Prägung noch lange nicht tot. Wo beginnt sie? An der Stelle an der die Formulierung einer Problemlösung beendet, das Programm aber noch nicht geschrieben ist? Wir meinen sie beginnt beim Formulieren in der Planungsarbeit. Ein Integraler Ansatz sollte also auch dort beginnen. David Gries: "One doesn't program in a programming language but into it".
Wer die Strukturierte Programmierung heute noch verteidigt, trägt Eulen nach Athen. Wer gleichzeitig den Einsatz von Tools für diese Methode ablehnt, ist zumindest inkonsequent. Nach dem Aufsatz von Nassi und Sneiderman, der die so bestechende Struktogrammtechnik vorstellte, war das Erscheinen zugehöriger Werkzeuge nur eine Frage der Zeit. Struktogramme können sowohl Produkt im Entwurtprozeß als auch an dessen Ende Ausgangsbasis für die (maschinelle) Erzeugung ablauffähiger Programme sein. Wir mußten nur den Rechner lehren, diese Diagramme zu verstehen d. h. eine abstrakte Maschine bauen, die die Obersetzung einer zweidimensionalen Darstellung in die rechnerspezifische eindirnensionale Form durchführt. Genau dies besorgt STRUKTOR: darin liegt seine Besonderheit und seine Universalität.
Jörg-E Richter, Geschäftsführender Gesellschafter der ADVIS Software-Partner, Hannover.
Als uns die Information über die kurzfristig im Münchner Arabella-Haus angesetzte Pressekonferenz der ADV/ORGA erreichte, wurde uns klar, daß nunmehr die bereits erwartete Image-Aktion anlaufen werde, die das schleichende Gespenst des Eindrucks der Kreativ-Schwäche vertreiben sollte.
Im Lichte der Tatsache, daß die Pressekonferenz unmittelbar vor der Tagung des German Chapter of ACM über "Moderne Methoden der Softwaretechnologie" strategisch placiert wurde, konnte man "Strukturiertes" erwarten. Was gerade Jetzt hoch in Mode steht, verspricht den hochsten Aufmerksamkeitswert, und im übrigen war hier ja das Feld bestens von namhaften Softwarehäusern bestellt und damit nur geringste eigene Mühe nötig.
So nimmt es nicht Wunder, wenn sich das Premieren-Produkt bei näherer Betrachtung als "Potemkinsches Dorf" erwies: Struktor ist frühestens im Sommer 1975 marktfähig!
Wir sind an die Igel-Hase-Strategie früherer Hardware-Ankündigungen erinnert. Dort nämlich war mit Hardware erst einmal das Gehause gemeint, und mit der angekündigten Maschine hatte die Jahre spätere Erstinstallation nur noch das Typenschild gemeinsam.
Allerdings liegt die Vermutung nahe, daß sich der versuchte Präventivschlag als ein Schlag ins Wasser erweist. Das Marktlenkungs-Manöver hätte gelingen können, wenn da nicht die Methode und die Struktogramme wären, auf die sich ADV/ORGA nun zu unserer Schadenfreude festgelegt hat. Diese sind aufgrund der Ergebnisse intensiver Forschungsarbeiten nicht gerade "das Gelbe vom Ei des Columbus". Mit einem wirklich brauchbaren, soliden Software-Werkzeug sollte eine exakte Prüfung der Wohlstrukturiertheit vorgenommen werden können - da liegt nämlich das Anwenderinteresse! Stattdessen präsentiert sich das NP-historische Konzept des "Generator".
Es ist zu befürchten, daß derartige Konzeptmonotonie zu einem Universal-Generator_UNIGEN führt Dieser vorübersetzt dann "Nach Optimaler-Norm-Schematisierte ENtscheidungstabellen-Struktogramme: "NONSENS"
Dr. Jan Witt, Siemens AG, Unternehmensbereich Datenverarbeitung, Abt. Systemprogrammierung, München
Als Entwickler ist man natürlich geschmeichelt, wenn auf dem Arbeitsgebiet, das man sich selbst ausgesucht hat, Produkte auftauchen, die dem eigenen Produkt verwandt sind, weil man sich dadurch in der Richtigkeit des Ansatzes bestätigt sieht. Man ist natürlich auch froh, wenn jene anderen Produkte erst zögernd Gehversuche machen, man selbst aber ein praktisch erprobtes Produkt mit mehr als einem Jahr Entwicklungsvorsprung in der Hand hat.
Als Angestellter einer angesehenen, großen Firma, deren urheberrechtlichen und wirtschaftlichen Interessen man sich verpflichtet fühlt, ist man nicht ganz so enthusiastisch, vor allem, wenn man erfährt, daß die Anbieter des anderen Produkts von eben dieser großen Firma einschlägige systembezogene Informationen bekommen haben, und wenn man hört, daß das Konkurrenzprodukt eben dieser großen Firma zum Kauf angeboten werden soll. Zu leicht könnte man geneigt sein, sich an die fatale Scherzdefinition zu erinnern, ein Consulant sei einer, der sich von einem die Uhr leiht, um einem zu sagen, wie spät es ist, und dann vergißt, die Uhr zurückzugeben.
Ein bißchen traurig wird man schließlich als Wissenschaftler und Didakt in Hinblick auf die Brauchbarkeit der STRUKTOR-Lösung für den Benutzer. Im Vordergrund beider Lösungen STRUKTOR (ADV ORGA) und COLUMBUS (Siemens) steht das Nassi/Shneiderman-Diagramm als Programmvorlage und als mechanisch erzeugte Programm-Dokumentation. Die COLUMBUS-Lösung geht davon aus, daß beliebige Programmiersprachen durch eine für alle Programmiersprachen einheitliche, universelle Steuerflußsprache "überschichtet" werden, und daß aus dieser Sprache automatisch Nassi/Shneiderman-Diagramme oder Programme in der "reinen" Primärsprache erzeugt werden. Ferner können aus dem überschichteten Text Querverweismatrizen, eingerückte Listendarstellungen sowie "kanonisch geordnete" Programme erzeugt werden. Großer Wert wurde dabei darauf gelegt, außerhalb der Steuerfluß-Konstruktion die verwendete Programmiersprache nicht zu verfremden und die Nassi/Shneiderman-Diagramme an beliebige Formatvorgaben (Bildschirm, Datei, Schnelidrucker) anzupassen.
STRUKTOR dagegen scheint einige Nachteile zu haben: Es wird eine unnötig verfremdete Primärsprache als Eingabe verwendet. Dabei müssen z. B. die beiden Zweige einer IF-Anweisung parallel spaltengerecht abgelocht werden.
Die Umwandlungsroutine in die reine Primärsprache erzeugt zu viele GOTOs. COLUMBUS dagegen verwendet die Original-COBOL-IF-Konstruktionen, wo immer möglich. Technisch gesehen scheint es sich bei STRUKTOR um eine Insellösung zu handeln, die sich wohl kaum zu einem zusammenhängenden System der Art des COLUMBUS erweitern läßt. STRUKTOR beschränkt sich auf die Stapelverarbeitung. COLUMBUS dagegen ist auch dialogfähig.