Der Gattungsbegriff "Sprachen der vierten Generation" umfaßt eine Vielzahl unterschiedlicher Werkzeuge und Sprachen: So schaffen Auswertungssprachen dort wirtschaftliche Lösungen, wo die klassische Programmentwicklung zu aufwendig und zu teuer war, oder lösen bisherige Programmiersprachen bei der Entwicklung operativer Applikationen ab. Die Auswirkungen auf diesen traditionellen Bereich der Anwendungsentwicklung unstersucht Michael Bauer*.
Sprachen der vierten Generation haben durch die Reduzierung trivialer Programmierarbeit auf das Wesentliche eine eindeutige Verbesserung der Programmierproduktivität zur Folge. Zwar ist die vielzitierte 1:10-Steigerung nur bei Vorführbeispielen zu erzielen, aber auch eine geringere Erfolgsrate stellt bereits einen beachtlichen Produktivitätsschub dar.
Allerdings ist nicht zu verhehlen, daß diese Tools auch Probleme mit sich bringen. So kämpfen viele Anwender im deutschsprachigen Raum mit Akzeptanzschwierigkeiten - zumindest in der Anfangsphase. Dazu werden funktionale Schwächen der Werkzeuge und "Umstellung im Denken" als die beiden wesentlichen Ursachen genannt.
Programmierroutine ist eine ungünstige Voraussetzung. Für routinierte Programmierer, die beispielsweise in Cobol und CICS oder IMS zu Hause sind, ergeben sich einige Änderungen gegenüber dem eingefahrenen Denkschema. Dies kann in der Anfangsphase recht störend sein, wenn es in der Ausbildung nicht richtig vermittelt wird. Hierzu einige Beispiele:
- Die Programme in einer Sprache der vierten Generation werden im CICS-Sinne "conversational" geschrieben; das heißt im Verlaufe eines Programmes gibt es Terminalausgaben mit anschließender Eingabe, die zu einer Mehrschritt-Transaktion führen. Der Programmierer, dem jahrelang eingetrichtert wurde, in Einschritt-Transaktionen - also "pseudo-conversational" - zu denken, ist zunächst verwirrt. Daß die Sprache der vierten Generation daraus intern wieder "conversational" Transaktionen macht, sieht er ja nicht. Allerdings werden so die Programmabläufe linear programmiert, was die Lesbarkeit erhöht.
- Wenn dem 4GL-System eine relationale Datenbank zugrunde liegt, führt dies zu Datenmengenverarbeitung. Dies wird in den Sprachen durch implizite Schleifen gelöst, die der Programmierer nicht selbst steuert. Hinzu kommen noch Befehle mit impliziten Sprüngen.
- Durch den Wegfall von GOTO ist man zu strukturierter Programmierung gezwungen. Wenn dann in einer 4GL nicht alle Kontrollstrukturen der strukturierten Programmierung verfügbar sind, entstehen tief verschachtelte IF/ELSE-Konstrukte. Da geht leicht die Übersicht verloren, so daß man sich wieder nach dem guten alten GOTO sehnt.
Die Anwender berichten übereinstimmend, daß Anfängern und Studienabsolventen das Denken in den neuen Sprachen wesentlich leichter fällt als den alten Hasen. Doch ist das Umdenken bei der - Programmierung noch lange nicht so gravierend, wie bei Analyse- und Entwurf.
Der Organisationsaufwand ist deutlich reduziert. Obwohl es sich bei Sprachen der vierten Generation um Programmierwerkzeuge handelt, beeinflussen sie auch deutlich die vorgelagerten Phasen der Anwendungsentwicklung.
Organisatorischer Aufwand wesentlich reduziert
Viele Anwender haben festgestellt, daß sich durch den Einsatz eines 4GL-Produkts der Aufwand für die Organisation neuer Anwendungen drastisch reduziert hat.
Dies läßt sich darauf zurückführen, daß Sprachen der vierten Generation zwar keine direkte, aber doch eine indirekte Auswirkung auf den Analyse- und Entwurfsprozeß haben.
Früher war es üblich, daß sich aus dem Entwurf der Anwendungen die Daten ableiten ließen, die benötigt wurden. Dieses prozeßorientierte Design war so lange richtig, wie es ein Nebeneinander einzelner isolierte - Anwendungen gab. Mit Zunahme der Integration der Anwendungen aber mußte eine gemeinsame Datenbasis geschaffen werden. Dies erfordert ein anwendungsneutrales Design der Daten im Rahmen eines übergreifenden Datenmodells. Zwar ist diese Erkenntnis nicht neu, doch braucht; sie lange, um sich in der Praxis durchzusetzen.
Sprachen der vierten Generation fördern diesen Prozeß dadurch, daß Datensichten separat und vor der Entwicklung von Programmen erstellt werden müssen. Funktionen, wie zum Beispiel Prüfregeln, werden an die Datendefinition gekoppelt und so aus Programmen herausgezogen, 4GLs basieren meist auf Datenbanksystemen, die ein gesamthaftes Datendesign erfordern.
Als grundlegende Designarbeit ist somit ein Datenmodell zu schaffen, auf das sich alle Formen von DV-Anwendungen abstützen können:
- klassischer Entwicklungsprozeß mit Analyse- und Entwurfsarbeiten auf dem Papier;
- Entwicklung unter Verwendung von Prototyping;
- direkter Zugriff auf die Daten mittels nichtprozeduraler Sprachen.
Man kann sich das Ganze als ein Schichtenmodell vorstellen (siehe Abbildung).
Auch die schrittweise Erarbeitung einer DV-Lösung mittels Prototyping ist keine neue Erfindung; aber sie ist mit Sprachen der vierten Generation erst zu vertretbaren Kosten möglich geworden. Beim Prototyping handelt es sich nicht nur darum, Bildschirmmasken vorzuführen und zu erproben, sondern die fachliche Spezifikation zu verfeinern. Dieses Vorgehen, gemeinsam mit den Fachmitarbeitern die Details der fachlichen Lösung zu erarbeiten und gleichzeitig dabei einen großen Teil der Programmierarbeit zu erledigen, wird in Amerika als "Joint Application Development" bezeichnet.
Hierfür bietet eine Sprache der vierten Generation die notwendigen Voraussetzungen dadurch, daß ein Großteil der trivialen Codierung durch automatische Funktionen abgedeckt wird. Hierdurch ist es möglich, bereits mit drei Zeilen ein ablauffähiges Dialogprogramm zu schreiben. Außerdem werden im Data Dictionary viele Dinge einmalig definiert, die automatisch für alle Programme wirken. Dies kann von Datendefinitionen über Editiermasken, gültige Werte, Prüfregeln bis zu Hilfstexten und Fehlernachrichten reichen. Auch kann die Übersetzung einer Problembeschreibung, die der Fachmitarbeiter versteht, in einen Programmcode recht einfach sein, wenn man eine strukturierte Beschreibung verwendet.
Sprachen der vierten Generation erfordern also nicht nur ein Umdenken bei den Programmierern. Der gesamte Entwicklungsprozeß von DV-Anwendungen muß überdacht werden, um die neuen Konzepte realisieren zu können. Notwendig ist es, die Schaffung der konzeptionellen Grundlage in Form eines durchgängigen Datenmodells zu erreichen. Erforderlich ist ferner die Konzentration des Wissens um Daten in ein Data Dictionary, das möglichst aktiv mit der Sprache der vierten Generation in Verbindung steht. Hinzu kommen die aktive Einbeziehung in den Entwicklungsprozeß und das Prototyping zur Straffung und qualitativen Verbesserung der Analyse- und Designphase.