Eine Sackgasse zeichnet sich für die gegenwärtige Entwicklung der Programmiersprachen ab. Gerade bei den Sprachen der vierten Generation wird beispielsweise ein krasser Generationenkonflikt deutlich: Für keines der heute verfügbaren Produkte in diesem Bereich gibt es einen Übersetzer oder Generator, der Anweisungen der dritten Generation erzeugt.
Ohne Zweifel befindet sich die Software-Branche mit ihrer Begriffsbildung in der Isolation: Denn wer außer den Insidern weiß schon, daß ein Entscheidungstabellengenerator keine Entscheidungstabellen generiert, daß Pseudocode kein Code ist, daß ein Projektsteuerungssystem kein Projekt steuert, daß ein Data Dictionary kein Datenverzeichnis ist, daß die Sprachen der sogenannten "vierten Generation" gar keine Sprachen sind und daß ein Softwarehaus kein Haus ist.
Ähnlich verwirrend erscheint Nicht-Eingeweihten die Generationenbestimmung im Bereich der Programmiersprachen. Die Sprache der ersten Generation ist der Assembler (früher Autocoder und SPS). Dabei wird eine Anweisung Quellcode (Assembler) 1:1 "assembliert" in eine Anweisung Objektcode (Maschinencode). Man bezeichnet diese Sprache auch als die Sprache der mnemonischen Abkürzungen.
Die Sprachen der zweiten Generation sind unter anderem Cobol und PL/1. Aus einer Anweisung Quellcode werden durch Compilierung mehrere Anweisungen Objektcode. Sie werden auch als Hochsprachen bezeichnet, weil sie bei der Anordnung auf den Abstraktionsebenen (Abbildung 1) von der Maschinensprache zum Menschenverständnis über dem Assembler angeordnet sind. Es handelt sich eben nicht um Abkürzungen, sondern um lesbare Texte.
Die Sprachen der dritten Generation sind die sogenannten Generatorsprachen. Dabei wird ein Quellcodegenerator veranlaßt, aus einer Anweisung Generatorcode mehrere Anweisungen der Hochsprachen (Quellcode der zweiten Generation) zu erzeugen (zu generieren. Diese Generatorsprachen haben die Eigenschaft, mehr oder weniger die Strukturbildung zu fördern, wobei bestimmte Anweisungen (GO TO) vermieden werden
sollen und dadurch die vermehrte Schachtelung bestimmter Strukturen auftritt. Über den Sinn und Unsinn der Strukturierung in dieser Form sind sich die Wissenschaftler bis heute noch nicht ganz einig geworden. Allerdings übernimmt Codasyl jetzt Anweisungen der Konstrukte für "Folgestruktur", "Auswahlstruktur" und "Wiederholungsstruktur" in die Sprache Cobol.
Ob durch die Maßnahmen der Codasyl nun die Sprachen der dritten Generation zur zweiten werden oder die Sprache Cobol in die dritte Generation aufrückt, kann der allgemeinen Meinungsbildung überlassen bleiben. Jedenfalls sind die verschiedenen Generationen auf der Sprachebene ausgeschöpft. Unter der Annahme, man würde mit einer Generatoranweisung zehn Anweisungen Cobol erzeugen und jede Cobol-Anweisung würde wiederum zehn Assembler-Anweisungen (oder Objektbefehle) erzeugen, ergäbe sich schon ein Verdichtungsverhältnis von 100:1. Nach diesem Prinzip käme es bei einer Sprache der vierten Generation schon zu einem Verdichtungsverhältnis von 1000:1, bei einer eventuellen fünften Generation zu einem Verdichtungsverhältnis von 10 000:1.
Wohin soll diese Entwicklung führen? Wer, außer dem Autor solchen Codierens, ist da noch in der Lage, die Vorzeichnung "Programm" zu verstehen, wenn der Quellcode für ein ganzes Programm so aussieht, wie in Abbildung 2 dargestellt? Niemand würde dieses Generationenprinzip ernsthaft mit Erfolg weiterführen können.
Es gibt heute keine Sprache der vierten Generation, denn es gibt keinen Übersetzer oder Generator, der Generator-Anweisungen der dritten Generation erzeugt. Diese Entwicklung ist ohnehin am Ende der Sackgasse der Sprachen angelangt. Warten wir nicht auf die vierte Generation, sie kommt auch nicht!
Im übrigen handelt es sich bei den Sprachen der ersten bis dritten Generation durchweg um Prozeßsprachen prozeduraler Konstruktion. Aber das gerade wollten die meisten Sprachen der sogenannten vierten Generation gar nicht sein, sondern sie wollen nonprozedural (nicht prozedurbezogen) sein. Sie sollen also nicht das "Wie", sondern das "Was" einer Programmfunktion beschreiben und gehören demzufolge in die Kategorie der Spezifikationssprachen.
Nun könnte man sich vielleicht noch darauf einigen, daß die Spezifikationssprachen eben die vierte Generation darstellen. Bei dieser Definition würden sich dem geschulten Softwareingenieur alle Widerstände regen. Denn Spezifikation ("Was") ist nicht Konstruktion ("Wie") und kann deshalb wegen der "Sprachkonstrukte" ganz und gar nicht in das gegebene Generationenprinzip eingeordnet werden.
Die Bezeichnung "Sprache der vierten Generation" ist ein Widerspruch in sich selbst. Am besten scheint es, diesen Begriff zu vergessen und ihn sogar aus dem Glossar zu streichen.
Wendet man sich also den sogenannten "Spezifikationssprachen" zu, so stellt sich die Frage, ob wenigstens der Begriff "Spezifikationssprache" stehen bleiben kann oder nicht. Die Antwort bringt vielleicht ein intensives Nachdenken darüber, was eigentlich spezifiziert werden soll.
Auf der obersten Ebene der Software-Produktion wird die Programmfunktion spezifiziert. "Was soll das Programm leisten?" Auf der darunter befindlichen Ebene läßt sich die Programmfunktion in ein System von Funktionen zerlegen, wobei jede so gebildete Funktion eine Programm-Komponente darstellt. Auf dieser Ebene ist die Komponentenfunktion zu spezifizieren.
Dieser Zerlegungsprozeß läßt sich weiter fortsetzen. Dabei entstehen nach unten immer mehr Ebenen, solange bis eine Systemhierarchie des Programms besteht. Bei einem Programm handelt es sich also um ein System mit verschiedenen Systemklassen. Und innerhalb jeder Systemklasse gibt es Systemeigenschaften.
In den Systemklassen sind unter anderem biologische Systeme von sozialen zu unterscheiden und diese wiederum beispielsweise von Informationssystemen. Jedes dieser Systeme hat die Eigenschaft, statisch oder dynamisch zu sein.
Ein Programm ist nach dieser Taxonomie ein dynamisches Informationssystem. Es besteht folglich im Gegensatz zur Zeitung, welche ein statisches Informationssystem ist
weil sie ihren zeitlichen Zustand nicht verändert.
Ein dynamisches Informationssystem in Form eines Computerprogramms verändert seinen Zustand ständig in der Weise, wie unterschiedliche Daten verarbeitet werden sollen. Eine brauchbare Spezifikationssprache muß also den Zustand klar definieren, welchen eine Programmfunktion nach ihrem Durchlauf annehmen kann. Diese Spezifikationssprache muß dann für jede Komponente auf jeder Ebene der Systemhierarchie gleichermaßen anwendbar sein.
Es geht also darum, Programmfunktionen zu spezifizieren. Nach der Funktionstheorie handelt es sich bei der Programmfunktion um eine Transformation einer Eingabe in eine Ausgabe. Eine auf allen Ebenen der Hierarchie gleichermaßen anwendbare Spezifikationssprache muß also darauf ausgerichtet sein, für jede Komponente des Systems die Eingabe, die Transformation in die Ausgabe, den Zustand der Funktion nach ihrem Durchlauf und die Ausgabe eindeutig und vollständig zu beschreiben.
Läßt sich nun diese Beschreibung durch Anwendung unserer natürlichen Sprache (Englisch, Deutsch oder andere) vornehmen? Die Antwort heißt eindeutig: Ja. Man sollte dies allerdings nicht in Prosa tun, sondern aus Transparenzgründen durch Anordnung der Beschreibungen in tabellarischer Darstellungsfom. Die bildhafte Darstellung der vier Spezifikationsmerkmale ist also das wesentliche Kommunikationskriterium.
Eine eigens für die Spezifikation zu schaffende Sprache wird nicht benötigt. Auch dieser Begriff sollte am besten aus dem Glossar verschwinden. So bleibt nichts, was sich unter der Überschrift "vierte Generation" sinnvollweise noch anordnen ließe. Was passiert nun mit solchen "Programmsprachen", welche bis dato als Sprachen der vierten Generation bezeichnet wurden! Man ordnet die Produkte am besten zwei von einander getrennten Klassen zu: Da gibt es auf der einen Seite die sogenannten Query-Sprachen (Abfragesysteme) und auf der anderen Seite die "Hochsprachen mit integriertem IOCS (lnput-Output-Control-System)". In Dialog-Anwendungen übernehmen letztere die Erzeugung der Bildschirmmasken und der Transaktionssteuerung, für Online und Batch-Anwendungen übernehmen sie die Ein-/ Ausgabe der Daten und stellen für den prozeduralen Teil Sprachkonstrukte ähnlich der Programmiersprachen Cobol bereit.
Die Anwender sind gut beraten, wenn sie die die Abfragesysteme von den Entwicklungssystemen streng trennen. Die Hersteller wiederum handeln klug, wenn sie neben der Namensgebung für ihre Produkte eine Zuordnung treffen würden, die es dem Interessenten ermöglicht, den jeweiligen Leistungsumfang für die unterschiedliche Zielsetzung in kurzer Zeit zu erkennen.
Wenn es darum geht, diese "Programmsprachen" den drei Sprachgenerationen zuzuordnen, so ließe sich eindeutig feststellen, daß die verfügbaren Sprachkonstrukte der Klasse der Hochsprachen zuzuordnen sind. Die Software-Ingenieure sind deshalb gut beraten, wenn sie oberhalb der Hochsprachen andere Klassen definieren würden, als dies mit dem Generationenprinzip bisher getan wurde.
Oberhalb der Hochsprachen müssen Werkzeugklassen definiert werden, die in zwei verschiedene Richtungen auseinanderlaufen. Die in der Abbildung 1 angefangene Generationensäule spaltet sich oberhalb der dritten Ebene in ein Y-Schema, wobei der linke Balken auf das Informations-Center "Fachabteilung) und der rechte Balken auf das Entwicklungs-Center (Programmierabteilung) weisen /Abbildung 4).
Jeder der drei Balken im Y-Schema definiert eine bestimmte Kategorie von Mitteln zur Software-Produktion. Bei der Gestaltung einer Software-Produktions-Umgebung (SPU) werden die einzelnen Mittel diesen Kategorien zugeordnet und sich ergänzende Komponenten sinnvoll miteinander konfiguriert um so Redundanzen und Widersprüche zu vermeiden.
Auf der Basis des Y-Schemas werden auch die organisatorischen Voraussetzungen für die optimale Nutzung einer Software-Produktions-Umgebung klar und die künftig zu erstellenden Software-Systeme lassen sich aufteilen in informative Systeme und operative Systeme.
Die Erstellung der informativen Systeme kann weitgehend der Fachabteilung (Informations-Center) überlassen werden, aber man muß aufpassen, daß alle operativen Systeme ausschließlich vom Entwicklungs-Center (Programmierabteilung) erstellt werden. Demzufolge ergeben sich die Kategorien der Software-Produktionsmittel wie folgt:
- die (Basis-)Kategorie der Sprachen,
- die Kategorie der Abfragesysteme,
- die Kategorie der Engineering-Werkzeuge.
*Jörg Richter ist geschäftsführender Gesellschafter der Advis Jörg E. Richter + Partner GmbH, Eschborn.