Vielleicht waren die Erwartungen zu hoch gesteckt. Jedenfalls haben die Programmiersprachen der vierten Generation - Branchenkürzel: 4GL - bei vielen Anwendern nicht ganz das gehaltene was man sich versprochen hatte. Trotzdem, bei großen Anwendungssystemen scheint kaum ein Weg an diesen Tools vorbeizuführen.
Viele DV-Leiter hatten gehofft, daß die Sprachen der vierten Generation ihnen spürbar helfen würden, den vielzitierten Anwendungsentwicklungsstau zu verringern. Und wenn eine Reihe von Systemen, die als "benutzerfreundlich"- angepriesen waren, eher "systemfreundliche Benutzer" erforderten, trug das nicht gerade zur Vertrauensbildung bei.
Zusätzliche Irritation schuf sicher auch die Verwechslung mit bestimmten PC-Werkzeugen, wie zum Beispiel PC-Focus, die fälschlich mit echten 4GL-Werkzeugen gleichgesetzt werden, allerdings auch billiger und leichter einsetzbar sind.
Die Abgrenzung zur 3GL ist nicht immer einfach
Erschwert wird die 4GL-Diskussion weiterhin durch die München des Laien, die Sprachen der vierten Generation eindeutig gegenüber den Sprachen der dritten Generation abzugrenzen. Grundsätzlich kann man sagen, daß die Sprachen der dritten Generation der maschinenunabhängigen und prozeduralen Formulierung von Problemlösungen dienen. Typische 3GL-Sprachen sind unter diesem Aspekt die bekannten Programmiersprachen wie Cobol, Fortran oder Basic. Auch PL/1 oder "C" gehören dazu. Alle diese Sprachen erfordern Programmierkenntnisse.
Sprachen wie Lisp oder Prolog, die der Wissensverarbeitung dienen, werden von Fachleuten bereits zur fünften Generation gezählt. Dazwischen bewegen sich nun - nicht eindeutig abgrenzbar - die Sprachen der vierten Generation. Wobei es sich nur teilweise um echte Sprachen handelt. Dazu gehören Sprachen wie Natural oder SQL.
Da die Aktionsauslöser den Makrobefehlen von Programmroutinen vergleichbar sind, werden die 4GLs heute eher als Werkzeuge oder Tools bezeichnet. Sprachen der vierten Generation "interpretieren" die Anweisungen und bedürfen daher nicht erst der Umsetzung durch einen Compiler.
Den 4GL-Werkzeugen ist generell folgendes gemeinsam: Sie sind für den Dialog-orientierten Einsatz konzipiert, hier dreht es sich also nicht zuletzt um das Abfragen und die Manipulation gespeicherter Daten. Der Komfort besteht darin, daß die Benutzer in vielen Fällen rein objektorientiert agieren können und sich über das Zustandekommen des Ergebnisses keine Gedanken machen müssen. Prozedurale Sprachen verlangen hingegen die genaue Beschreibung des Lösungsweges. Einige Werkzeuge bieten darüber hinaus Funktionen des Data Dictionary, das Informationen über gespeicherte Daten liefert. Auch Benutzerhilfen wie Fenstertechnik, Menüsteuerung oder interaktive Führung werden angeboten.
Der eigentliche Nutzen der 4GL-Tools liegt darin, daß für die Softwareentwicklung weniger Programmschritte erforderlich sind als bei traditionellem Vorgehen. Dabei übernehmen die Werkzeuge beispielsweise Generatorfunktionen oder das Dateihandling. Auch der Wartungsaufwand verringert sich dementsprechend. Allerdings gelten diese Vorteile zunächst nur für Softwareprofis. Anfänger benötigen, wie die Erfahrung zeigt, in der Lernphase wesentlich längere Zeiten als bei konventioneller Programmerstellung.
Bei den 4GL-Werkzeugen unterscheiden viele Fachleute noch zusätzlich zwischen Entwicklungssystemen für die Softwareerstellung und den Endbenutzersystemen. Doch nicht alle halten eine solche starre Trennung heute noch für gerechtfertigt. Richtig ist, daß eine Reihe von Produkten wie zum Beispiel CSP, Ideal, Mantis, Natural, Unify oder ZIM (vergleiche Übersicht) primär für den Einsatz in der Anwendungsentwicklung geeignet erscheinen. Produkte wie AS, ES, Focus, IC/1, Nomad 2, Ramis II oder SAS werden hingegen eher als Endbenutzerwerkzeuge, das heißt als Werkzeuge für die individuelle Datenverarbeitung (IDV), gesehen. Andererseits ist es heute ohne weiteres möglich, ein Natural für Aufgaben der individuellen Datenverarbeitung einzusetzen, oder Focus für die professionelle Entwicklung von DV-Anwendungen zu benutzen.
Manche Nichtspezialisten mag es überraschen, daß auch Datenbankmanagementsysteme wie Ingres oder Oracle zu den 4GL-Tools gerechnet werden. Der Grund ist einfach: Diese Produkte verfügen über zusätzliche Leistungsmerkmale, die der Entwicklung von Software dienen. Sie liegen damit auf einer Linie, die in jüngerer Zeit häufiger zu beobachten ist: der Tendenz - zum universellen Werkzeug. Im übrigen hat sich gezeigt, daß sich Datenbank-Systeme in Verbindung mit 4GL-Tools wesentlich leichter handhaben lassen.
Als Endbenutzersysteme konzipierte 4GL-Werkzeuge sind teilweise noch mit zusätzlichen Leistungsmerkmalen ausgestattet, so mit Spezialpaketen für bestimmte Benutzerbedürfnisse (Finanzplanung, statistische Alternativen), mit Entscheidungshilfen ("Was wäre, wenn ... ?"), mit Reportgeneratoren (Abfragesprachen zur Erzeugung von Berichten, Listen) oder mit Werkzeugen zur Erstellung von Präsentationsgrafik.
Die meisten 4GL-Tools sind allerdings Entwicklungssysteme. Mit dieser Eigenschaft werden sie sehr leicht in die Nähe der CASE-Werkzeuge (CASE = Computer-aided Software Engineering) gerückt. Den 4GL-Werkzeugen fehlt es allerdings an der Kerneigenschaft der CASE-Tools: der DV-technischen und grafischen Unterstützung der Phase "Analyse und Design" im Lebenszyklus eines Softwareprodukts.
Der Zeitgewinn ist nicht zu verachten
Gleichwohl können 4GL-Werkzeuge deutliche Beiträge zur Produktivitätssteigerung bei der Softwareentwicklung liefern, auch wenn die Steigerungsraten nicht so traumhaft hoch liegen wie Werkzeuganbieter bisweilen glauben machen wollen. Auf jeden Fall leisten sie Unterstützung bei der Organisation neuer Anwendungen, bei der Programmerstellung selbst wie auch bei Programmänderungen (Wartung). Hier sind in der Regel deutliche Zeiteinsparungen festzustellen. Auch für den gemeinsamen Entwurf von Anwendungssystemen durch Entwickler und Anwender (Prototyping) bieten sie Hilfen, indem sie das Modell, etwa eine Grafik oder eine Bildschirmmaske, auf dem Terminal sichtbar machen.
Das Angebot an 4GL-Werkzeugen ist inzwischen recht reichhaltig geworden. Allerdings muß man sich darüber im klaren sein, daß die herstellerspezifischen Tools meistens auch nur auf den Maschinen dieser Hersteller einsetzbar sind. Es muß also überlegt werden, ob Portabilität erforderlich ist oder nicht. Im Zeitalter wachsender Multivendor-Umgebungen empfiehlt es sich meistens, der Portabilität höhere Priorität einzuräumen als anderen Merkmalen.
4GL-Werkzeuge sind in erster Linie für den Einsatz in Mainframe-Umgebungen geeignet, auf denen größere Anwendungssysteme laufen. Auch vom Preis her ergibt sich das im Grunde, denn 4GL-Tools kosten im allgemeinen um die 200 000 bis 500 000 Mark, manchmal auch mehr. Zwar gibt es billigere Werkzeuge, die, wie Siron, in Größenordnungen von 30 000 bis 50 000 Mark liegen, aber natürlich ist bei solchen Paketen auch der Leistungsumfang wesentlich geringer. Allgemein gilt: Mächtigkeit und Komfort von 4GL-Tools müssen teuer bezahlt werden.
Teuer bezahlt werden müssen sie auch noch in anderer Hinsicht: Ihr Einsatz erfordert zu gleich Rechnerleistung. Je intensiver der Einsatz, desto höher der Kapazitätsbedarf. Wer mit den Werkzeugen die Rechnerleistung nicht aufstockt, wird sehr bald Leistungseinbußen gewahr: Das Anwortzeitverhalten im Dialog wird schlechter, Stapelverarbeitungen nehmen längere Laufzeiten in Anspruch.
Wer 4GL-Werkzeuge mit Erfolg einsetzen will, muß über die entsprechende Infrastruktur verfügen. Dazu gehören neben einer leistungsfähigen Rechnerumgebung vor allem geeignetes Personal, das im Umgang mit diesen Werkzeugen geschult ist und vor allem aber auch die innere Bereitschaft für Neuerungen mitbringt. Den vollen Nutzen von 4GL-Tools hat nur, wer den Umgang beherrscht und zu kreativem Einsatz fähig ist.
Wie stets, so ist es auch hier wichtig, vor der Auswahl einen Anforderungskatalog aufzustellen. Und den kann der Leiter der Systementwicklung nicht im stillen Kämmerlein formulieren, sondern nur in Kommunikation mit seinen Mitarbeitern. Wenn jeder von ihnen noch ein paar nützliche Ideen beisteuert, kann man am Ende halbwegs sicher sein, daß der Anforderungskatalog komplett ist. Diesen vergleiche man dann mit dem Leistungskatalog der verschiedenen Anbietet, und sehr bald wird das Preis-/Leistungs-Verhältnis offenbar. Erfahrungsgemäß findet man nirgendwo die Ideallösung, das heißt es muß entschieden werden, auf welche Merkmale man notfalls verzichten kann beziehungsweise ob bestimmte Merkmale den erhöhten Preis rechtfertigen.
Last but not least muß in diesem Zusammenhang auch geprüft werden, inwieweit das Werkzeug über die erforderlichen Schnittstellen zu der vorhandenen 3GL-Software verfügt. In der Regel sind sie im Tool enthalten. Wo sie allerdings fehlen, entsteht die Gefahr von Insellösungen.
Manche Leute fragen, ob man 4GL-Tools Oberhaupt braucht. Die Antwort lautet: Bei großen Anwendungssystemen sind sie nahezu unentbehrlich. Ohne ihren Einsatz bestehen wenig Chancen, dem Entwicklungs- und Wartungsstau wirksam zu begegnen. Eine Alternative stellen 5GL-Tools dar - Pakete wie Sapiens von Systor oder Enterprise Builder Generator von Cullinet weist in diese Richtung aber noch sind sich die Gelehrten keineswegs einig, ob 5GL-Tools wirklich die Nachfolge der 4GL-Werkzeuge antreten werden. Soviel steht fest: Die 4GL-Tools können nützliche Hilfsmittel sein, vorausgesetzt, die Einsatzumgebung stimmt. Sie sind auch nicht ganz billig, aber welcher Automationsfortschritt hätte bisher nicht seinen Preis gehabt? Es sind immer häufiger die qualitativen Aspekte, die eine Entscheidung beeinflussen. Wer im Softwareentwicklungsstau steckt, hat wenig Alternativen.