Das Kürzel 4GL löst längst keine Begeisterung mehr aus. Doch auch das computerunterstützte Software-Engineering (Case) hat sich bisher nicht als des Rätsels Lösung erwiesen. Hartmut Skubch* zeigt, wie Mängel und Vorteile sowohl von Case als auch von den 4GL-Sprachen über sich hinweg auf eine Methode verweisen, die er zur fünften Generation zählt.
Mit viel Begeisterung wurde seinerzeit die Einführung der 4Gls begrüßt, und selbst eingefleischte Assembler-Freaks zählen sich mittlerweile zu den 4GL-Fans. Schließlich sind dem DV-Entwickler viele äußerst mühsame Aktivitäten abgenommen worden. Aufwendige Maskenbeschreibungen haben sich ebenso erledigt wie die komplex parametrisierten Datenbank-Schnittstellen. Vor allem die Möglichkeit, den Bildschirm schnell "flackern" zu lassen, erhöhte die Akzeptanz erheblich, da damit bei der Fachabteilung geglänzt werden konnte. Eine erfrischende Veränderung nach den vielen Vorwürfen über zu lange Projektlaufzeiten und den Lamentos über den Anwenderstau.
Zur Beurteilung der Perspektiven der 4GLs ist die Unterscheidung in 4GL als Entwicklungs- und als Endbenutzersprache notwendig. Ich möchte im Folgenden nur auf den ersten Aspekt eingehen.
Die vierte Generation wird nicht die letzte sein
Die rasante Verbreitung der 4GLs als Entwicklungssprachen ist nicht nur von Jubelrufen begleitet. Die Erwartungen bei den Fachabteilungen, hervorgerufen durch einen brillanten Prototyp, sind häufig nur schwer mit der Realität zu vereinbaren. Laien ist es schwer zu vermitteln, daß zu zwischen einem Prototyp und einem produktionsreifen System Monate, sogar Jahre an Entwicklungsarbeit liegen können. Doch die Simulation der Benutzeroberfläche umfaßt leider noch nicht das gesamte System.
Unbestritten, Programme lassen sich mit einer 4GL viel schneller schreiben als in herkömmlichen Programmiersprachen oder gar in Assembler. Aber ist das auch immer mit einer Steigerung der Produktivität gleichzusetzen?
Produktivität definiert sich aus der produzierten Menge bezogen auf eine Zeiteinheit, wobei allerdings eine bestimmte Qualität unterstellt wird. Etwas salopp formuliert: Mit einer 4GL kann man leider auch sehr schnell sehr viel "Mist" produzieren.
Trotzdem haben die 4GLs erhebliche Vorteile, und in vielen Unternehmen tragen sie zur Produktivitätssteigerung bei. Die wichtigsten Eigenschaften hierbei sind:
* Reduzierung des Codieraufwandes durch mächtige automatische Funktionen.
* Eingebettete DB/DC-Befehle in der Sprache statt CALL-Konstrukte oder Makros.
* Weitgehend nichtprozedurale Sprachelemente, um die Abhängigkeit von der Programmierlogik zu reduzieren. (Zum Beispiel Datenbankoperationen, Reports, Datenprüfungen).
* Möglichst viele programmexterne Definitionen und Verarbeitungsregeln (zum Beispiel Datendefinitionen, Masken, Editierregeln, Überschriften, Fehler- und Hilfstexte, Prüfregeln, Integritätsregeln). Speicherung dieser programmexternen Definitionen in einem Data Dictionary.
* Automatische Integration zwischen 4GL und Data Dictionary.
* Interaktive Entwicklung einschließlich Umwandlung, Text und Ausführung.
* Alle Funktionen mit einer homogenen Benutzeroberfläche.
* Programmunabhängigkeit vom TP-Monitor.
* Ausreichender Sprachumfang um alle Anwendungen, die bisher mit 3GLs geschrieben wurden, zu realisieren, sowie zusätzliche Sprachelemente für dispositive Aufgaben.
Ein anderer Ansatz zur Steigerung der Produktivität verbirgt sich hinter dem Schlagwort Case. Konkret geht es dabei um folgende Eigenschaften:
* Unterstützung des gesamten Software-Lifecycle einschließlich der Wartung
* Möglichst hohe Durchgängigkeit vom Entwurf bis zur Realisierung.
* Unterstützung der kreativen Entwicklungsarbeit durch eine Workstation mit Gafikmöglichkeiten.
* Unterstützung des Projektmanagements
* Ablage aller Ergebnisse in strukturierter Form auf einer Entwicklungsdatenbank
* Maschinelle Überführung der jeweils notwendigen Ergebnisse in unterschiedliche Zielsysteme (zum Beispiel Datendefinitionen in verschiedenen DB-gebundenen Data-Dictionaries).
Wie harmonieren nun diese beiden Ansätze miteinander? Mir ist keine Case-Umgebung bekannt, die bewußt in ihrer Konzeption eine 4GL verwendet. Meistens war sie schon da, und danach kamen die Case-Überlegungen. Insofern erscheint die Frage, ob hier eine synergetische Ergänzung, eine Substitution oder ein Konflikt vorliegt wohl berechtigt.
So versucht die Software AG die oben geschilderten Probleme mit ihrem 4GL-Produkt Natural durch eine Verschmelzung mit der Isotec-Methode von Plönzke zu lösen. Die SAG hat damit das vielversprechende Verfahren der Programm-Montage eingeführt. Das Produkt - Predict-Case - muß sich jedoch noch bewähren .
Der Gedanke, eine fachliche Spezifikation in eine 4GL zu übersetzen sei es mit einem Generator oder mittels Programm-Montage erscheint nicht sehr zwingend: Warum diese Zwischensprache?
Dieselbe Frage könnte man sicherlich auch Generatoren wie Delta oder Telon vorwerfen, die Spezifikationen in 3GLs übersetzen. Doch ist hier die Sachlage erheblich anders. Das Generieren in eine Zwischensprache der 3. Generation (zum Beispiel Cobol) erscheint unter Risikoaspekten durchaus sinnvoll. Ein generiertes Cobol-Programm, auch wenn es vielleicht schlecht lesbar ist, kann auch noch benutzt werden, wenn der Generator nicht mehr eingesetzt wird, sei es, daß der Lieferant vom Markt verschwunden ist, oder das neue Produkt eines anderen Lieferanten eingesetzt werden soll.
Die Bindung an eine Sprache der vierten Generation ist ungleich stärker. Eigentlich bedeutet es sogar einen Widerspruch, die mit einer fachlichen Spezifikation erreichte Unabhängigkeit durch eine 4GL-Bindung wieder aufzuheben. Doch eine stärkere Integration von Produkten erzeugt zugleich stets eine zusätzliche, Abhängigkeit vom Hersteller.
Verzichten wir also auf die Herstellerunabhängigkeit zugunsten der stärkeren Integration, dann bleibt die Frage zu klären, warum überhaupt noch in eine Zwischensprache übersetzen? Warum nicht die Modellebene, die fachliche Spezifikation zur Systembeschreibungsebene machen? Aber auch hier treten Schwierigkeiten auf.
Führt die Modellbeschreibung --möglichst in grafischer Form - direkt zum lauffähigen System, so muß hochgradig interpretativ gearbeitet werden. Ein Performance-Problem entsteht.
Auf der anderen Seite gibt es zwar klare Verfahren zur Strukturierung der Daten und ihrer Beziehungen, doch im Bereich der Funktionsanalyse haben wir heute noch Freiheitsgrade oder besser "unklare Situationen", die nicht ohne weiteres zu einem automatischen Systemablauf führen können. Beim Verzicht auf eine Zwischensprache zeigt sich daher ein methodisches Problem beim Funktionsentwurf .
Und schließlich stellt dieser Verzicht ungemein höhere Anforderungen an die DV/Org.-Abteilungen hinsichtlich Ausbildungsstand, Erfahrungsschatz im Einsatz von Design-Methoden und Projektabwicklung.
Unterstellen wir, diese Probleme seien gelöst, so eröffnen sich ganz neue Perspektiven: Keine Übersetzungsprobleme mehr vom Fachkonzept zum DV-Konzept. Keine Konsistenzprobleme bei der Wartung. Direkte Kommunikation in Form einer grafischen Sprache zwischen DV-Spezialist, Organisator, Fachbereich und Computer.
Vielleicht sind das die Sprachen der 5. Generation? Einige Hersteller scheinen bereits an einem Produkt mit völliger Durchgängigkeit zu arbeiten.
Unter diesem Gesichtspunkt bedeutet der Einsatz von 4GLs als Entwicklungssprache eigentlich eine Zwischenlösung; entstanden aus den technischen Unzulänglichkeiten von Sprachen der dritten Generation. Genauso "überflüssig" erscheint dann auch der Einsatz eines Cobol-Generators. Doch Zwischenlösungen haben einen natürlichen Drang zur Beständigkeit. Zudem sagt die technische Machbarkeit noch gar nichts aus über die organisatorische Umsetzbarkeit.
Bedenkt man, wie lange es gedauert hat und teilweise noch dauert, bis Methoden der Datenanalyse in die praktische Arbeit der Entwickler Einzug gehalten haben, so werden sowohl 4GLs als auch Generatoren noch mindestens eine Dekade unsere vertrauten Wegbegleiter sein.
Trotzdem, Unternehmen, die von sich behaupten, die Gestaltung ihrer Zukunft nicht unbedingt dem Zufall zu überlassen, müssen sich schon heute mit der Technologie von morgen auseinandersetzen.
*Hartmut Skubch ist Geschäftsführer der Wiesbadener Plenum Management Consulting GmbH.