Oft sind die als Systeme gepriesenen 4GL-Toolsets nichts weiter als zusammengeschusterte und durch Aktientausch uebernommene Komponenten, kritisiert Johann Baumeister*. Was die Produkte taugen, will er anhand einiger aktueller Beispiele aufzeigen.

Zu den erfolgreichsten derzeit am Markt angebotenen Werkzeugen, zaehlen zweifelsohne "Enfin" von Easel (Vmark), "Powerbuilder" von Sybase, "Progress" von der gleichnamigen Company, "SQL Windows" der Firma Gupta, "Visual Basic Professional Edition" in der Version 3.0 von Microsoft, "Uniface" von Compuware sowie "Visualworks" von Parcplace.

Der Vorteil von Visual Basic: Es wird fuer wenige hundert Mark angeboten. Fuer kleine, lokale Applikationen kann es durchaus erste Wahl sein, doch verglichen mit den anderen Entwicklungsumgebungen zieht das Microsoft-Produkt den kuerzeren. Die Sprache ist auf einen Entwickler und ausschliesslich fuer Windows zugeschnitten.

Enfin dagegen bewegt sich im Bereich fuenfstelliger Betraege. Es stellt ein ausgereiftes und umfangreiches Entwicklungssystem nicht nur fuer Windows oder OS/2 dar. Allerdings muessen sich die Enfin- Entwickler nicht nur mit der Umgebung, sondern auch mit Smalltalk und dessen Performance-Problemen auseinandersetzen.

SQL Windows und Powerbuilder haben in der Vergangenheit Massstaebe gesetzt. Doch in den vergangenen Monaten haben Entwickler ihren Unmut ueber die Instabilitaet von Powerbuilder geaeussert. Ob das Produkt nach der Uebernahme durch Sybase, wie Analysten vermuten, zu einem proprietaeren Produkt fuer den SQL Server wird, zeigt die Zukunft. Dass das nicht sein muss, beweist Gupta mit SQL Windows. Denn schliesslich hat Gupta mit SQL Base ebenfalls eine Datenbank im Angebot.

Das grosse Manko aller Systeme liegt im extremen Ressourcenbedarf. So ist selbst bei einem 486er PC mit 66 Megahertz und 16 MB RAM nur ein normales zuegiges Arbeiten moeglich. Eine solche Umgebung mag fuer ein Entwicklungssystem angemessen sein, fuer die Zielsysteme aber mit Sicherheit nicht.

Verschwenderischer Umgang mit Ressourcen

Die derzeit gaengigen Client-Server-Werkzeuge teilen Applikationen in zwei Ebenen (two-tier). Der Desktop beheimatet den Code, der zur Visualisierung von Daten und zur Abbildung der Geschaeftslogik benoetigt wird. Die Daten und das verbundene Datenbanksystem liegen auf Servern. Durch Middleware-Komponenten und Gateways werden Clients und Server verknueft. Doch nachdem die Tools leistungsfaehiger und der Code umfangreicher werden, muessen entsprechend auch die Clients aufgeruestet werden. Das fuehrt zum sogenannten Fat-Client.

Zu den Werkzeugen, die die Hersteller zur zweiten Generation zaehlen, gehoeren "Axiant" von Cognos, "CDE" von Oracle, "Dynasty" von Dynasty Technologies, "Forte" von Forte Software oder "Newera" von Informix. Im Unterschied zu ihren Vorgaengern sollten diese Entwicklungssysteme Eigenschaften bereithalten wie:

- Skalierbarkeit der Applikation,

- Portabilitaet ueber mehrere Graphical User Interfaces (GUIs),

- Portabilitaet ueber mehrere Betriebssysteme und Hardwareplattformen,

- erweiterte Integration von bestehenden Desktop-Programmen,

- flexible Verteilung der Applikation (Application Partitioning),

- Skalierbarkeit von Workgroups bis hin zu unternehmensweiten Systemen,

- konkurrierender Zugriff auf mehrere Datenquellen in heterogenen Umgebungen sowie

- Konfigurations-Management und Versionskontrolle.

Entwicklungssysteme stellen geschlossene Welten dar, in denen eine grosse Zahl an Programmkomponenten ineinanderspielen. So ist es nicht ohne Komplikationen moeglich, Programm-Module aus einem Entwicklungssystem herauszuziehen und in ein anderes System zu integrieren. Entweder erstellt und verwaltet das Entwicklungssystem eine Vielzahl separater Dateien fuer alle Bausteine: Code, Definitionen von Masken, Menues, Dialogabfragen, Berichte, Datenbankanbindung, Bilder (BMP-Dateien), allgemeine Definitionen und Makefiles. Zu diesem Typ zaehlt etwa "Visual C++" von Microsoft.

Oder die Komponenten werden von einer integrierten Umgebung (SQL Windows: Designer und APP-Dateien) verwaltet. Nach aussen ist dann nur eine Datei sichtbar, und der Entwickler kommuniziert ausschliesslich mit dem Verwaltungssystem.

Standardisierte Schnittstellen garantieren Offenheit. In der Regel laesst sich fremder Code per Dynamic Link Library (DLL) oder Visual Basic Extensions (VBXs) in die 4GL-Umgebung einbinden. Der Zugriff auf Datenbanken erfolgt via Middleware ueber Open Database Connectivity (ODBC) oder orientiert sich an Windows-Schnittstellen wie Dynamic Data Exchange (DDE) oder Object Linking and Embedding (OLE).

Die Erzeugung von Anwendungscode spielt die zentrale Rolle und wird von allen erwaehnten Werkzeugen abgedeckt - ob als herkoemmliche prozedurale 4GL-Programmierung oder vollstaendig objektorientiert. Ein Mittelweg zwischen beiden Verfahren wird mit der ereignisgesteuerten Programmierung eingeschlagen.

Enfin oder Visualworks gehen mit Smalltalk den objektorientierten Weg. Smalltalk-Anwendungen basieren auf einem Runtime-System und den Basisklassen. Der Portierungsaufwand geht gegen Null. Nachteil aller Runtime-Systeme im Vergleich zu kompilierten Programmen ist die Performance.

Guptas SQL Windows operiert mit der an prozedurale Sprachen angelehnten SQL Windows Application Language (SAL). Aehnlich ist auch "Powerscript" von Powerbuilder oder Microsofts Visual Basic strukturiert, wobei beide Systeme Anleihen in der objektorientierten Welt machen. Das Programmiermodell ist ereignisgesteuert.

Ausser den Smalltalk-Systemen sind alle Sprachen der vierten Generation in der Lage, direkt ausfuehrbare Programme zu erzeugen. Das ist jedoch kein Garant fuer kleinen, kompakten Code, denn haeufig liegen viele der Basisfunktionen in anderen DLLs bereits auf dem System und werden zum Lauf benoetigt. Saemtliche Tools erlauben uebrigens das Einbinden von C-Code.

Werkzeuge fuer portable Anwendungen sind rar

Oberflaechen unterscheiden sich in grafische und zeichenbasierte. Die grafischen unterstuetzen Windows, Motif, OS/2 PM oder Macintosh. Besteht die Notwendigkeit, neben der schoenen bunten Fensterwelt auch die Zeichenorientierung zu unterstuetzen, laesst sich das mit Uniface oder Progress muehelos bewaeltigen.

Die meisten Entwicklungssysteme unterstuetzen Windows. Sollen jedoch portable Applikationen erstellt werden, in die ueberdies GUIs anderer Hersteller eingebunden werden koennen, grenzt sich das Feld auf die Smalltalk-Produkte Enfin und Visualworks ein.

Zum Aufbau von Benutzer-Interfaces benoetigen Entwickler Design- Tools. In der Regel koennen sie aus einer Palette von Gestaltungselementen mittels Drag and drop waehlen: Controls, Listboxen, Eingabefelder, Auswahlknoepfe.

Zwar wird die Designfunktion in verschiedenen Ausfuehrungen angeboten, fuer die Verwendbarkeit spielt das jedoch nur eine untergeordnete Rolle. Dagegen fallen Funktion und Reichweite der Elemente ins Gewicht. Beschraenkt sich der Umfang lediglich auf die Basis-Controls des Betriebssystems, so muessen unter Umstaenden Kontrollobjekte selbst erstellt werden.

Alle Systeme ausser Visual Basic 3.0 kennen ein Tabellen-Control. Wird dieses mit Datenbanktabellen verbunden, koennen die Saetze ohne manuelle Programmierung direkt angezeigt werden. Sind darueber hinaus auch noch Beschraenkungen auf Zeilen (Select) und Spalten (View) moeglich, reduziert sich der Programmieraufwand nochmals. SQL Windows 5.0 etwa erlaubt den Quick-Controls die direkte Zuordnung einer Quest-Abfrage zu dem zugehoerigen Anzeigeobjekt.

Mit Visual Basic 4.0 will auch Microsoft Tabellen einfuehren. Die Version 3.0 kennt nur die feldweise Verarbeitung. Um den Aufbau von Tabellen muss sich der Entwickler bisher selbst kuemmern oder sich von Drittherstellern entsprechende Erweiterungen besorgen. Die VBX haben allerdings eine rasante Verbreitung gefunden. So sind auch die Werkzeuge Powerbuilder und SQL Windows in der Lage, VBX-Funktionen zu integrieren.

Trotzdem wird Microsoft das VBX-Modell nicht weiterpflegen. Die Funktionen sollen durch 32-Bit-OCX-Module abgeloest werden (OCX = OLE Custom Controls).

Um relationale Daten an die Objektwelt anzubinden, bietet das Easel-Werkzeug ein Mapping-Tool an. Allerdings ist das Mapping auf eine Eins-zu-eins-Zuordnung begrenzt. Demnach ist es unmoeglich, einem Objekt zwei Felder einer Datenbank zuzuordenen oder umgekehrt ein Objekt als Substring eines Feldes zu behandeln.

Bestandteil nahezu jeder Entwicklungsumgebung - Visual Basic ist auch hier die Ausnahme - sind Report-Generatoren. Diese ermoeglichen den automatischen Aufbau von Listen und unterstuetzen ueblicherweise die Erzeugung von Tabellen sowie frei definierbaren Berichten. Sie lassen sich ausserdem fuer die Erstellung von Adressaufklebern fuer Mailings verwenden.

Um nicht fuer jede Online-Auswertung neue Programme erstellen zu muessen, haben sich ausserdem Dialogabfragewerkzeuge eingebuergert. Die Query-Tools erlauben den dynamischen Aufbau von Abfragen und ihre Speicherung. Ausser Visual Basic verfuegen alle erwaehnten Tools ueber diese Funktion.

Dass viele der angesprochenen Funktionen nicht in Visual Basic enthalten sind, heisst nicht, dass sie in dieser Sprache nicht umgesetzt werden koennten. Nur sind sie nicht direkter Bestandteil von Visual Basic, sondern muessen als VBX erworben werden. Ausserdem bleibt es jedem Entwickler unbenommen, sie selbst zu programmieren.

Repositories gehoeren noch zu den Ausnahmen

Insgesamt gilt: Basisfunktionen werden von allen Systemen unterstuetzt. Die wesentlichen Unterschiede liegen in den fortgeschrittenen Eigenschaften. Ein Data-Dictionary beispielsweise findet sich nur bei Enfin, Powerbuilder und SQL Windows. Mit Hilfe dieser Bibliotheken werden Informationen ueber die Daten, sogenannte Metadaten, verwaltet.

Repositories ermoeglichen darueber hinaus die Verwaltung weiterer mit der Applikation auftretender Informationen: Verwendungszweck, Definitionen und Geschaeftsregeln etwa. Daneben speichert ein Repository Prozess-, Daten- und Organisationsmodelle.

Die vorgestellten Produkte erlauben jedoch bestenfalls ein Management der Programmkomponenten wie Codes, Masken und Reports. Hier werden wohl erst die naechsten Generationen der C/S-Tools Abhilfe schaffen. Auch Aspekte der Modellierung von Daten, Funktionen oder Prozessen werden ausser in Enfins "Synchronicity" von keinem der Systeme abgedeckt. Dazu muessen Entwickler wie ehedem auf zusaetzliche Tools zurueckgreifen.

Die Arbeitsweise von Synchronicity ist dreigeteilt. Im ersten Schritt erstellt der Entwickler mit Hilfe grafischer Unterstuetzung das Daten- beziehungsweise Objektmodell fuer die Applikation. Die benoetigten Klassen werden durch Synchronicity generiert. Anschliessend wird ein Interface aufgebaut.

Der Begriff Objektorientierung schmueckt, deshalb wird damit leider sehr viel Marketing-Schindluder getrieben. Eine OO-Oberflaeche wie die Workplace-Shell von OS/2 beispielsweise hat nichts mit OO- Programmierung zu tun. Die Werkzeuge, die sich dieses Etikett anheften, muessen auf die Eigenschaften Kapselung, Vererbung und Polymorphismus abgeklopft werden.

Am leichtesten laesst sich die Kapselung realisieren. Sie stellt sicher, dass die Datenbereiche der Objekte nicht fehlerhaft veraendert werden koennen. SQL Windows und Powerbuilder unterstuetzen ausserdem die Vererbung. So kann ein Objekt, etwa eine Maske, in anderen Modulen wiederverwendet und adaptiert werden. Fuer Smalltalk-Systeme stellt das keine Herausforderung dar.

Der Themenkomplex Projektverwaltung mit Versionsfuehrung, Sourcecode-Control-System oder Konfigurations-Management werden von nahzu allen 4GLs abgedeckt. Ausnahme auch hier: Visual Basic. Die Hilfen basieren meist auf den Konzepten zum Checkout oder -in.

Bevor ein Entwickler Aenderungen an einem Modul vornehmen kann, muss er dieses explizit aus dem Entwicklungssystem laden (Checkout). Nach der lokalen Bearbeitung wird das Modul wieder in das Entwicklungssystem gestellt (Checkin) und somit fuer alle beteiligten Personen verfuegbar. "PVCS" von Intersolv ist ausschliesslich fuer die Versions- und Konfigurationsverwaltung gedacht.

* Jochen Baumeister ist freier Autor in Muenchen.