"An die Stelle der Anwendungsprogrammierung mit Hilfe traditioneller Programmiersprachen wie Cobol. Fortran, PL/1 und Pascal muß eine höhere Stufe der Automatisierung treten. Die Arbeit des Programmierers muß automatisiert werden ..." So schreibt James Martin in seinem Buch "Manifest der Informationstechnologie".
Niemand zweifelt daran, daß die Tage der traditionellen Programmierer - der Assembler-, PL/ 1- oder Cobol-Codierer - gezählt sind. Diese Sprachen sind für die Mehrzahl der kommerziellen Anwendungen einfach ungeeignet. Die semantische Ebene ist zu tief, der Test- und Pflegeaufwand zu hoch. Es ist aber nicht gesagt, daß diese Sprachen aussterben müssen. Sie werden nach wie vor weiterverwendet, um spezielle Aufgaben zu erledigen und die Werkzeuge selbst zu entwickeln. Außerdem werden normierte Sprachen wie Fortran, Cobol und Pascal als Zielsprachen von Generatoren dienen.
Auch wenn man einräumt, daß es sich nicht mehr rechtfertigen läßt, kommerzielle Anwendungen in einer Sprache der 3. Generation zu konstruieren, ist es noch lange nicht gesagt, daß die einzige Alternative eine Sprache der 4. Generation sein muß. Diese Sprachen haben ihre Einschränkungen, vor allem dort, wo es um die Portabilität der Systeme geht. Eine weitere Einschränkung ist die Tatsache, daß sie nur für einzelne Programmtypen geeignet sind, insbesondere für Mensch-Maschine-Dialoge und das Berichtswesen. Für komplexe, automatisierte Prozesse sind sie wegen ihrer mangelnden Modularität und Strukturierung ungeeignet. Es gibt daher vier Gründe, warum Sprachen der 4. Generation kein Allheilmittel sind:
- Sie sind nicht allgemeingültig.
- Sie sind nicht normiert.
- Sie sind nicht modularisiert.
- Sie sind unzulänglich strukturiert.
Was bleibt aber dem Anwender in Anbetracht dieser Einschränkungen der 4. Generation und der bekannten Mängel der 3. Generation übrig?
Die Antwort heißt, DV-Anwendungen in zwei Klassen zu trennen. Zur einen Gruppe gehören die dispositiven Aufgaben, die zum Teil von den Endbenutzern selbst programmiert werden -Aufgaben wie Abfragen, einfache Änderungen und Berichtsgenerierung. Hier kommen die Sprachen der 4. Generation zur Geltung. Es sollte auch das Ziel eines jeden Unternehmens sein, diese Aufgaben an die Fachabteilungen zu delegieren und sie über ein "Informationscenter" zu koordinieren.
Zu der anderen Klasse gehören die operativen Aufgaben, die von professionellen Software-Ingenieuren entwickelt werden -Aufgaben wie Lohn und Gehalt, Lagerhaltung, Auftragsverwaltung und Fertigungssteuerung. Hier hat der Anwender drei Alternativen:
- Er kann ein Standard-Softwaresystem kaufen.
- Er kann das System selbst entwickeln.
- Er kann Standardsoftware kaufen und anpassen.
Normierte Sprache als Output
Im Falle einer eigenen Entwicklung wird er die Anwendung in einer Spezifikationssprache entwerfen und die Programme daraus generieren lassen. Im Falle einer Anpassung wird der User die Standardsoftware nachdokumentieren, respezifizieren und die neuen Module generieren.
Das Hauptwerkzeug der operativen Systeme ist also die Spezifikationssprache. Die konventionellen Programmiersprachen bilden lediglich eine normierte Schnittstelle zur Maschine. Die Vorteile der Spezifikationssprachen sind die Nachteile der Sprachen der 4. Generation. Sie sind allgemeingültig, modular und strukturiert. Lediglich die Anforderung Normierung bleibt unbefriedigt. Deshalb empfiehlt es sich, aus den Spezifikationssprachen eine normierte Sprache der 3. Generation zu generieren.
Die daraus resultierenden Programme können denn auch durch entsprechende Testwerkzeuge verifiziert und validiert werden. Für einfache, kurzlebige Anwendungen ist eine formale Spezifikation und Verifikation zu aufwendig. Hier gilt es, leicht handhabbare Werkzeuge, die von Amateuren bedient werden können, einzusetzen, also Sprachen der 4. Generation.
Für komplexe, langlebige Anwendungen sind Sprachen der 4. Generation inadäquat. Hier gilt es, formale Spezifikationssprachen, Code-Generatoren und Test-Werkzeuge, die von Profis bedient werden, zu nutzen.
Daraus folgt, daß es für die Datenverarbeitung keine Allheilmittel gibt. Vielmehr liegt die Lösung in einer Kombination von
- Dialogsprachen mit Berichtsgeneratoren,
- Spezifikationssprachen mit Code-Generatoren und Testwerkzeugen sowie
- Standardsoftware.
Auf keinen Fall darf weiter wie bisher entwickelt werden. Diese Art des Programmierens ist nicht nur teuer, sie ergibt auch Programme, die weder testbar noch wartbar sind. Heute bietet die Softwaretechnologie genügend Alternativen an. Es obliegt dem Anwender, für das jeweilige Problem die geeignete Alternative auszuwählen. Leider wird einem niemand dies abnehmen können.