Sprachen der vierten Generation (4GLs) werden immer wieder als einfache und effiziente Lösung der vordringlichsten Anwenderprobleme gepriesen - mit einiger Berechtigung. Fragt sich allerdings, ob der Nutzen dieser Werkzeuge es rechtfertigt, schwerwiegende Nachteile in Kauf zu nehmen. So machen sich die 4GL-Anwender in hohem Maße von ihrem Hersteller abhängig.
Programmiersprachen der dritten Generation (3GLs) galten als problemorientierte Programmiersprachen. Inwieweit dieses Attribut auch auf Sprachen der vierten Generation zutrifft, soll hier nicht näher untersucht werden. Ihre Existenz läßt sich schon mit dem Versäumnis rechtfertigen, die 3GLs für neuere anwendungsspezifische Anforderungen und Programmiertechniken weiterzuentwickeln. Innovative Konzepte von Unis nicht zu erwarten
Bis vor wenigen Jahren gab es an den Universitäten Lehrstühle für "Programmiersprachen". Diese sind inzwischen dem moderneren Software-Engineering gewichen. Da 3GLs kein Thema der Forschung mehr darstellen, sind innovative Konzepte für diesen Bereich von den Universitäten nicht zu erwarten. Ausnahmen bilden einige wenige Ansätze: funktionale Programmiersprachen, objektorientierte Produkte wie C+ + oder eine Spezialsprache für Linguisten wie Comskee, die problemorientierte Datentypen aufweist. Erst neuere Entwicklungen im Bereich der Oberflächen und Window-Systeme (X-Windows Motif, etc. ) in Verbindung mit objektorientierten Ansätzen lassen auf einen neuen Technologieschub hoffen.
Trotzdem müssen sich alle 4GL-Produkte an den klassischen Programmiersprachen messen. Nur Produkte mit einem ähnlich hohen Standardisierungsgrad wie Cobol haben eine Chance. Verlangt wird aber auch, daß sie so leicht einsetzbar, portabel und preiswert sind wie Pascal oder C und darüber hinaus eine elegante Lösung anbieten, um strukturierte oder gar objektorientierte Anwendungsentwicklung zu unterstützen.
Die Leistung der 4GL-Sprachen ergibt sich aus folgenden Eigenschaften: - Ein Vorteil besteht darin, die Programme und deren Ablauflogik konsequent von den Daten und der Benutzerschnittstelle zu trennen. - Die Benutzerschnittstelle wird durch entsprechende Masken- oder allgemeine Window-Systeme realisiert, wobei die üblichen Dialogarbeiten (Lesen Suchen, Schreiben, Blättern) automatisch und ohne weitere Anwendungsprogrammierung verfügbar sind. - Die Daten lassen sich - allerdings nur bei moderneren Systemen - mittels intelligenter Data-Dictionaries verwalten. Diese Systeme erlauben die objektorientierte Formulierung von Integritätsregeln und anderen anwendungsspezifischen Datenabhängigkeiten an einer zentralen Stelle. Auf diese Weise können wichtige anwendungsbezogene Designregeln vom Analytiker verbindlich und unumstößlich festgelegt werden. Der einzelne Anwendungsprogrammierer braucht sich um solche Zusammenhänge nicht mehr zu kümmern. - Die in der 4GL zu formulierenden Programme sind auf die anwendungsspezifischen Details und Ausnahmen beschränkt. Hierbei unterstützen die meisten 4GLs den Programmierer durch alltagsnahe Funktionen, die direkt aufgerufen werden können (zum Beispiel: "Gib_die Kalenderwoche_zu_Datum").
Die Entwickler unterscheiden generierende und interpretative 4GL-Systeme. Die Generatoren erzeugen meist C- oder Cobol-Code. Ein Vorteil dieses Ansatzes liegt darin, daß die auf diese Weise entstandenen Anwendungen so portabel sind wie ihre Zielsprache.
Da eine wesentliche Leistung von 4GLs in der Realisierung der Dialogkomponenten besteht und hier ein Standard leider fehlt, weichen die Anwender auf Produkte aus, die wegen ihrer großen Verbreitung als De-facto-Standard gelten. Generieren oder interpretieren
Ähnliches gilt bei der Datenbehandlung, wo meist die im Cobol-Laufzeitsystem enthaltene ISAM-Verarbeitung eingesetzt wird. Neuere Produkte nutzen jedoch die standardisierte Datenmanipulationssprache SQL.
Ein Nachteil generierender Systeme ist ihr langsamer Entwicklungszyklus. Dies rührt daher, daß nach dem Generieren ein Übersetzungslauf notwendig ist, bevor getestet werden kann. Ein Mangel ist auch, daß die erzeugten Anwendungen gewöhnlich nicht in Module zerlegbar sind. Je umfangreicher ein Programm ist, desto nachteiliger fallen Übersetzungs- und Bindezeiten ins Gewicht. Allerdings wird dieser Nachteil oft durch das gute Laufzeitverhalten solcher Systeme ausgeglichen.
Anders verhält sich die Sache bei Interpreter-Produkten. Dort gilt gerade das Laufzeitverhalten als Hauptschwäche - wenn auch nicht immer zu Recht. Die Systeme bestehen aus einem anwendungsunabhängigen Laufzeitsystem, das Anweisungen, Daten- und Formatbeschreibungen einer konkreten Anwendung zur Laufzeit interpretiert. Jede einzelne Anweisung endet dann im Aufruf einer zugeordneten, im allgemeinen anwendungsunabhängigen Funktion oder Prozedur.
Was die Portabilität der Anwendungen betrifft, so wird diese von den Eigenschaften des Laufzeitsystems bestimmt. Die Programme laufen überall dort, wo auch der Interpreter läuft. Wenn eine solche Umgebung in einer genormten Hochsprache wie ANSI-C oder ANSI-Cobol entwickelt wurde, kann eine Portierung zumindest prinzipiell einfacher sein als bei einer kompilierten Anwendung. Daher liegt in diesem Gebiet weder der Interpreter- noch der Generator-Ansatz vorne. Ein unbestrittener Vorteil interpretativer Systeme sind schnelle Entwicklungszyklen, die ohne aufwendige Kompilier- und Bindevorgänge arbeiten.
Auch Mischformen beider Ansätze werden angeboten: Eine Möglichkeit besteht darin, die anwendungsbezogenen Anweisungen in der Entwicklungs-, Test- oder Prototypphase auszuwerten und erst bei der Auslieferung oder Installation zu übersetzen. Dieser Ansatz verbindet meistens die Vorteile der beiden bereits genannten Methoden.
Es gibt eine weitere Mischvariante: Die Anwendungsprogramme werden in einen Zwischencode übersetzt (zum Beispiel P-Code) und dann von einem Laufzeitsystem interpretiert. Der so entstandene Zwischencode ist üblicherweise Rechner- und Betriebssystemunabhängig. Diese Lösung verbindet wohl eher die Nachteile als die Vorteile der beiden reinen Ansätze. Erwartungen gegenüber den 4GL-Möglichkeiten
4GLs werden in der Regel von großen Anwenderunternehmen und von Software-Anbietern benutzt. Beide Gruppen lösen sich aus ähnlichen Gründen von der Entwicklung mit den klassischen 3GL-Produkten.
Größere Unternehmen setzen 4GLs zumeist ein, um einem Anwendungsstau zu begegnen. Aus zwei Gründen sind 4GLs hierfür geeignet: Durch die einfache, schnelle und wegen der Verwendung von Data-Dictionaries fehlerarme Entwicklung kann die Software-Abteilung wesentlich mehr Anwenderwünsche erfüllen. Leider werden dadurch meistens neue Bedürfnisse geweckt. Zudem erhöht sich mit der Anzahl der erstellten Programme der Aufwand für ihre Wartung. Endanwender soll seine Probleme selbst lösen
Eine weitere Hoffnung, die mit dem Einsatz von 4GLs verbunden wird, richtet sich auf den Endanwender. Er soll, so die Illusion, seine Probleme selbst lösen. Doch diese Anforderung führt meist dazu, daß sich der Anwender den Umgang mit dem Werkzeug im Trial- und Error-Verfahren selbst beibringen muß. Der Erfolg: Das Herumprobieren frißt alle vom 4GL-Werkzeug erwarteten Zeitvorteile auf und bringt Unmengen von Softwareleichen hervor. Im privaten Umfeld mag eine solche Benutzung von 4GLs noch angehen, in einer professionellen Umgebung muß davor gewarnt werden.
Programmieren oder Organisieren lernt man nicht durch das Werkzeug. Kein Besitzer einer Säge und eines Hobels wird sich gleich als Tischler bezeichnen. Daher muß hier klargestellt werden, daß zur unzweideutigen, korrekten und vollständigen Formulierung von Anwenderproblemen - unabhängig vom benutzten Werkzeug - die innerbetrieblichen oder verwaltungsorientierten Zusammenhänge von einem Fachmann mit analytischen Fähigkeiten geklärt werden müssen. Bei entsprechender Schulung auch in den Analyse-Verfahren, können fähige Sachbearbeiter jedoch in kurzer Zeit selbst produktiv werden. Voraussetzung ist, daß die Basisregeln des Systems in einem aktiven Data-Dictionary von professionellen Analytikern festgeschrieben worden sind.
Es ergeben sich zwei Klassen von Entwicklern: Solche, die das Systemdesign spezifizieren und implementieren, also die Objekte und die zu ihnen gehörigen Operationen definieren und andere, die diese Objekte verwenden, um sie dann in spezifische Anwendungen umzusetzen. Einteilung in zwei Arten von Entwicklern
Software- oder Systemhäuser können ebenso wie größere Anwender mit eigener Entwicklermannschaft 4GLs gewinnbringend einsetzen, wenn sie beschriebenen Regeln beachten und die Werkzeuge nur zur Produktivitätssteigerung ohnehin fähiger Mitarbeiter nutzen. Die Einteilung in zwei Arten von Entwicklern ist besonders in diesem Umfeld von Interesse.
Immer bedeutender für den Einsatz von 4GLs wird die Möglichkeit, inhomogene Datenbanken und Datenspeicherungsmethoden unter einem gemeinsamen Dach zu nutzen Damit bringt man nur die Vielfalt gewachsener Anwendungen auf einen gemeinsamen Nenner. Bei diesem Vorgehen, die einzelnen Anwendungen nach und nach neu zu erstellen und so das Wartungs- und EntwicklungsKnow-how zu konzentrieren kann hier ein langfristig bedeutsamer Gewinn erzielt werden.
Auch die Unabhängigkeit der echten Anwendung von ihrer Repräsentation im "Look and Feel" der Benutzeroberfläche ist eine Qualität von 4GLs: Hier wird die Frage bedeutungslos ob "Open Look", "OSF/Motif", "MS-Windows" oder IBMs "CUA" die schönste (beste, benutzerfreundlichste, natürlichste) Oberfläche ist. Die Grenzen von 4GL-Werkzeugen
Wie gesagt: Der Einsatz von 4GLs ersetzt keineswegs den umsichtigen und geschulten Entwickler. Zudem muß der Käufer heute noch auf einige technische Schwächen gefaßt sein. Leider sind die meisten 4GLs bei der Anbindung von 3GL-Funktionen unflexibel und in der Anzahl der möglichen Sprachkonstruktionen wie Bedingungen oder Schleifen eng begrenzt.
Aus diesen Gründen können Anwendungen nicht wirklich benutzerfreundlich gestaltet werden, ohne daß der Programmierer zu umständlichen Konstruktionen greifen muß. Sie bleiben Prototypen und müssen weiter den Vergleich mit guten Anwendungssystemen in Cobol oder C scheuen, welche oft auch wegen der fehlenden Einbindung von 3GL-Functionen in die 4GL performanter sind und deshalb eine höhere Benutzerakzeptanz genießen.
Worauf sollte man also achten?
4GLs könen die meisten versprechen tatsächlich erfüllen, wenn neben den üblichen Kriterien bei der Softwarebeschaffung wie das Einholen von Referenzen und das Vergleichen mehrerer Anbieter folgende Bedingungen beachtet werden: - Die 4GL sollte mächtig und flexibel genug sein, eine 3GL voll zu ersetzen. - Die 4GL darf kaum proprietär sein (zum Beispiel C- oder 2 Cobol-artig). - Die Quellen von 4GL-Werkzeugen müssen verfügbar sein. - Ungeschulte oder ungeeignete Mitarbeiter können auch mit einer 4GL nicht plötzlich programmieren. - Bestehende Applikationen und Datenspeicherungsverfahren wie ISAM und SQL sind zu integrieren. - Das "Look and Feel" muß unabhängig vom Anwendungscode sein. - Die 4GL sollte auf möglichst vielen Plattformen ablauffähig sein.
Schließlich darf der Anwender bei allen Diskussionen um offene Betriebssysteme mit X/Open-Gütesiegel nicht vergessen, wie selten er wirklich mit den standardisierten Schnittstellen zu tun hat. Wichtig ist daher eher, inwieweit er sich mit dem Hersteller einer - leider - unstandardisierten 4GL einläßt, wenn er große Summen in die Erstellung von 4GL-basierter Anwendersoftware investiert.