Anwender in den Fachabteilungen verlangen meist ein breites Spektrum individueller DV-Lösungen. Bei Durchsatz und Komplexität

hingegen stellen sie vergleichsweise geringe Anforderungen. Dieses

auf die Sprachen der vierten Generation zugeschnittene Profil macht

Abteilungsrechner zu einem der interessantesten Einsatzgebiete für 4GL-Anwendungen.

Die Sprachen der vierten Generation wurden entwickelt, als es möglich erschien, die meisten Tätigkeiten bei Software-Spezifikation und -Realisierung integriert zu unterstützen und anfallende Routine-Aufgaben automatisch abzuwickeln. Eine 4GL nutzt dazu ein Datenbank-Management-System (DBMS) mit Data Dictionary, hilft bei der Festlegung von Bildschirmmasken, Listen und Bearbeitungs-Abläufen und generiert schließlich aus den Eingaben ein funktionierendes Programm.

Der Enthusiasmus führt leider 4GL-Entwickler oft dazu, ihre Produkte mit zu großen Ansprüchen auf den Markt zu bringen und dadurch die Erwartungen mancher Anwender zu enttäuschen. Anwender und Anbieter haben so seit einigen Jahren ihre Erfahrungen gewonnen. Das hat erfreulicherweise bewirkt, daß gute Produkte heute zusätzlich zu den eigentlichen Bearbeitungsfunktionen noch folgende nützliche Eigenschaften bieten: eine akzeptable Benutzeroberfläche für alle Aufgaben sowie gezielte Messung interner Bearbeitungsvorgänge und Modularisierung. Das heißt: Integrationsmöglichkeiten von unabhängig erstellten 4GL- und 3GL-Programmen.

Eine Anwendung läßt sich rasch in einer 4GL realisieren, die Änderungswünsche des Anwenders werden sofort eingearbeitet. Der Prototyp bildet anschließend den größten Teil der Spezifikation: Auf dieser Basis kann die DV-Abteilung ein einsatzfähiges Programm in gewohnter Weise realisieren. Der Prototyp verringert vor allem die sehr teure Nacharbeit beträchtlich, die durch Mißverständnisse und Lücken bei der Spezifikation entsteht.

Am sichersten und kostengünstigsten wäre die Realisierung des Einsatzprogrammes natürlich, wenn sich der Prototyp direkt dafür umwandeln ließe. Das ist dann unmöglich, wenn es für das eingesetzte DBMS und andere zu integrierende Programme keine geeignete 4GL gibt, oder wenn die Anwendung für die vorhandene Computerkapazität zu groß ist.

Anwender in Betriebsabteilungen verlangen viele individuelle Lösungen, stellen aber bei Durchsatz und Komplexität meist keine hohen Anforderungen. Durch dieses auf 4GLs zugeschnittene Profil sind Abteilungsrechner der Größenordnung VAX und 9370 das interessanteste Einsatzgebiet für produktive 4GL-Anwendungen.

Bei kurzlebigem Einsatz, etwa zur Abwicklung einer einmaligen Aktion, ist es wirtschaftlich, auf großzügig dimensionierter Hardware einen mit geringem Aufwand überarbeiteten Prototypen zu verwenden. Für den Dauereinsatz dagegen lohnt sich die genaue Messung von Belastungs-Profilen und ein größerer Aufwand für die Optimierung. Die Unterstützung von Leistungsmessung und Modularisierung ist zur Bewältigung dieser Aufgaben notwendig.

Die Zusammenarbeit von Anwendern und 4GL-Spezialisten muß effizient organisiert sein, damit sowohl der Informationsfluß des Gesamtunternehmens gesichert wird und auch Optimierungserfahrungen überall angewendet werden. Mit Auswertungen und Abfragen wird ein interessierter und geschulter Anwender diese Spezialisten bald nicht mehr belasten.

Durch den Fortschritt bei Hardware und 4GL-Technik werden so immer größere Aufgaben realisierbar. Der Prototyp - oder zumindest große Teile von ihm - finden sich dann auch in anspruchsvollen Einsatzprogrammen wieder.

Es erfordert viel System-Know-how, Informationen aus Daten zusammenzustellen, die über verschiedene Datenbanken verteilt sind. Wenn man das Glück hat, den Anbieter einer 4GL zu finden, der alle eingesetzten Datenbank-Management-Systeme unterstützt, ergibt sich für Abfragen und einfache Bearbeitungen eine gute Arbeitsbasis.

Verfolgt man das Angebot und die Ankündigungen der Hersteller von Sprachen der vierten Generation, so läßt sich eine gewisse Konvergenz der Konzepte beobachten. Am PC wird meist spezifiziert und editiert, wobei zunehmend auch grafische Methoden zur Verfügung stehen. Der PC ist häufig auch ein Zielsystem, auf dem die in der 4GL erstellte Software läuft. Das ermöglicht kostengünstigen dezentralen Einsatz und entlastet die größeren Systeme bei der Testarbeit.

Die meisten Zielrechner sind Minis und Mainframes, die während der Entwicklung für Code-Generierung und Projektverwaltung genutzt werden. Weit verbreitete DBMS und Dateisysteme der Zielrechner werden in die 4GL integriert, wenn nicht aus schließlich ein eigenes DBMS unterstützt wird.

Aus der Geschichte des 4GL-Herstellers kann man oft auf die Eigenschaften seines Produktes schließen: Ein Datenbankhaus wird zur langfristigen Bindung seiner Kunden die Produkte effizient aufeinander abstimmen und darauf auch bei der Weiterentwicklung großen Wert legen. Reine 4GL-Häuser sehen meist ihren Markt in offenen Produkten, die verschiedene DBMS unter einer einheitlichen Benutzeroberfläche vereinigen.

Die Entwickler von Software-Methoden und -Tools bieten für frühe Projektphasen meist hervorragende grafische Unterstützung. Je mehr man sich aber ausführbaren Befehlen und einzubindenden fertigen Programmteilen nähert, desto karger werden heute noch bei vielen die Referenzen. Eine interessante Ausgangsposition haben die Hersteller von Data Dictionaries, denn sie sitzen bereits an den zentralen Schaltstellen für Daten und können so ihren Stammkunden einige Einführungsschritte erleichtern.

Der ausführbare Code wird vom 4GL-System nicht immer direkt erzeugt. Wenn die Resultate der 4GL-Bearbeitung Source-Befehle einer "alten" Sprache sind, ergeben sich Vorteile bei der Integration vorhandener Programmteile. Cobol-Generatoren dieser Art werden auch eingesetzt, wenn schrittweise in die 4GL-Welt umgestiegen werden soll.

Interessant ist es natürlich, wie sich die großen Hardware-Anbieter zu den Sprachen der vierten Generation stellen: IBM hat mit der Ankündigung von SAA und OS/2 viele Spekulationen ausgelöst. Diese Entwicklung dürfte das Angebot für die Benutzeroberfläche und die Entwicklungs-Tools des Marktführers entscheidend mitgestalten.

Mit grafischen Editoren werden Eingaben für Generatoren erstellt, die daraus für verschiedene Zielsysteme und Datenbanken Befehle erzeugen und schließlich ablauffähige Programme zusammenstellen. Der Entwicklungsaufwand für das notwendige universelle Data Dictionary und allgemein einsetzbare Debugging-Tools dürfte die Investition in die grafischen Editoren übertreffen.

Die-4GL-Idee wird aller Voraussicht nach durch dieses Engagement der IBM eine weite Verbreitung finden. Es ist damit zu rechnen, daß durch die De-facto-Standardisierung die Vielfalt des 4GL-Angebots zurückgeht.

Im Lager der Konkurrenz vertreibt Unisys ein eigenes Produkt sehr aggressiv. Und Digital Equipment deckt, zumindest in den USA, durch ein Marketing-Agreement für ein Fremdprodukt den Abteilungsrechnermarkt ab.

Eine Standardisierung der Darstellung von Dateistrukturen und Bearbeitungsvorgängen würde eine globale Einführung von 4GLs stark fördern, besonders wenn viele Anwender einen einfachen Zugang zu diesen Darstellungen hätten. Der Anstoß dazu ist aus dem PC-Bereich zu erwarten: Die leicht verständliche grafische Darstellung von Entity-Relationships, logischen Datenmodellen Datenfluß-Diagrammen und Aktions-Diagrammen stellt technische Anforderungen, die schon von einer EGA- oder Hercules-Karte erfüllt werden. Mit dem Bild muß immer auch seine in Listen erfaßte logische Struktur editiert werden.

Die weite Verbreitung wäre gegeben, wenn die entsprechenden Icons zusammen mit der notwendigen Verknüpfungslogik ein Bestandteil von populären grafischen Benutzeroberflächen würden. Wenn dort noch SQL oder ein anderer Standard zur Nutzung von Datenbanken integriert sind, entsteht ein komfortabler Spezifikations-Editor.

Ist auf einem solchen universellen System die Programm- und Daten-Logik fertig spezifiziert, erzeugt der 4GL-Generator nach Konsistenzprüfungen die Befehle für Data Dictionaries, Datenbanken und sonstige Funktionen. Objektorientierte Programmiersysteme, die diesen Weg einschlagen, kursieren heute schon in Informatikerzirkeln.

Wirtschaftliche Aspekte

Die folgenden Fragen dienen dazu, den 4GL-Einsatz möglichst wirtschaftlich zu gestalten:

- Wurden Abteilungsrechner nicht eingesetzt, weil keine Möglichkeit für die Beschaffung oder Erstellung geeigneter Software bestand?

- Sind Projekte auf unerwartete Einführungsprobleme bei den Anwendern gestoßen?

- Werden von den Anwendern oft kleine Programme und Auswertungen verlangt, die den Zugriff auf mehrere unterschiedliche Datei-Systeme und Datenbanken erfordern?

Ein Ja zu einer der Fragen sollte dazu anregen, sich stärker mit den Sprachen der vierten Generation zu beschäftigen. Durch das sorgfältige Eingehen auf konkrete Aufgaben, durch das Abwägen von alten und neuen Abhängigkeiten und durch engagiert durch geführte, aber genau analysierte Probeprojekte läßt sich eine erfolgreiche systematische 4GL-Einführung vorbereiten. Die intensive Zusammenarbeit von 4GL-Spezialisten mit den Anwendern bei Spezifikation, Optimierung und Schulung sichert dann die größtmögliche Wirtschaftlichkeit.