Gefördert vom Erfolg des offenen Betriebssystems Unix, wächst auch das Bedürfnis von Anwendern nach Datenbankunabhängigen 4GL-Tools. Dahinter steht nach Ansicht von Andreas Bereczky* ein deutlicher Trend zu anwendungsspezifischen Datenbank-Systemen.
Derzeit am Markt angebotene 4GL-Tools sind meist aus proprietären Produkten entstanden und lassen daher die von Anwendern gewünschte konzeptionelle Unabhängigkeit vermissen. Als geeignete Voraussetzung zur Erreichung des Ziels Unabhängigkeit erweist sich die konsequente Orientierung an der ANSI/ISO Drei-Schemen-Architektur.
Gängige Programmiersprachen wie Cobol, Fortran, Pascal oder C werden als Sprachen der dritten Generation (3GL) bezeichnet. Mit ihrer Entwicklung war das Ziel verbunden, Pro-gramme zu schreiben, die nicht mehr nur auf einer speziellen Hardware ablaufen, wie dies für Programme in Assembler oder Maschinensprachen gilt.
Produktivität durch Anwendungsorientierung
Anders als die Entwicklung von Sprachen der dritten Generation, die primär mit dem Ziel einer Produktivitätssteigerung der einzelnen Programmierer erfolgte, entstanden 4GLs mit der Absicht, die Produktivität durch die Unterstützung spezieller Anwendungen zu erhöhen. Hintergrund dieser Entwicklung war der steigende Marktbedarf an betrieblichen Informations- und Planungssystemen.
Sprachen der vierten Generation sind also primär anwendungsorientierte Werkzeuge. Dem Programmierer erleichtern sie die Arbeit, indem sie ihm im wesentlichen Bibliotheken von Routinen zur Verfügung stellen. Dort versteckt sich - unabhängig von der Zielumgebung - die Schnittstelle zur konkreten Umgebung des Programms. Die detaillierte Berücksichtigung der Schnittstellen zur konkreten Umgebung eines Programms ist für den Entwickler gleichsam unsichtbare Voraussetzung für einen Produktivitätsgewinn.
Es lassen sich auch Anwendungen für die spezielle Umgebung individuell in einer Sprache der dritten Generation entwickeln. Dies ermöglicht die Nutzung aller speziellen Eigenschaften einer vorgegebenen Umgebung und ist insbesondere dann von Vorteil, wenn die Leistungsfähigkeit der Installation in vollem Umfang genutzt werden muß. Auf der anderen Seite setzt diese Vorgehensweise detaillierte Kenntnisse der Schnittstellen zu dieser Umgebung voraus.
Programme hängen nicht nur von der Leistungsfähigkeit des Prozessors ab. In heute üblichen Anwendungen ergeben sich zusätzliche Abhängigkeiten von den verwendeten Betriebs- und Datenbanksystemen, Rechnernetzen und Benutzeroberflächen. Inzwischen gibt es in diesen Bereichen umfangreiche Bemühungen um Standardisierungen: Unix als "Standard"-Betriebssystem, TCP/ IP als "Standard"-Netzprotokoll und OSF/Motif als "Standard"-Benutzeroberfläche.
Eine allgemeine Akzeptanz dieser Standards würde allerdings die Entstehung "inter-operabler" Anwenderprogramme auf die Verwendung der standardisierten Schnittstellen reduzieren. Bisher kann davon jedoch keine Rede sein. Einerseits gehen die großen Hersteller immer wieder ihren individuellen Weg, andererseits sind die meisten umfangreicheren Installationen historisch gewachsen und basieren daher nicht auf "Standard"-Komponenten.
4GL-Werkzeuge bieten zwar eine deutliche Arbeitserleichterung bei der Entwicklung von Datenbankanwendungen. Das Dilemma der konkurrierenden Standards und den Bedarf der Anwender nach mehr Unabhängigkeit lösen sie jedoch nur bedingt. Die frühen 4GLs waren lediglich vertikal integrierte Produkte, die nur wenige Möglichkeiten zur Anbindung an andere Software vorsahen. Dem Trend zu anwendungsorientierten Datenbanksystemen und damit dem Bedarf an unabhängigen 4GL-Tools versuchen Anbieter inzwischen durch die nachträgliche Implementierung von Schnittstellen oder Gateways zwischen den Datenbanken gerecht zu werden.
Mit diesen Kompromißlösungen sind die Entwickler jedoch in der Regel nicht zufrieden, da das Problem, unabhängig von speziellen Datenbank- und Betriebssystemen, Rechnernetzen oder Benutzeroberflächen Software erstellen zu können, damit nicht konzeptionell gelöst wird.
Anwender-Befragungen belegen, daß der Aufbau eines 4GL-Tools nach der ANSI/ISO Drei-Schema-Architektur hierfür der konsequente Weg und der konzeptionelle Dreh- und Angelpunkt ist - mit den Vorteilen der Standardisierung. Dazu gehört nach Aussagen der befragten Softwarehäuser vor allem eine Erweiterung des Marktes durch Unabhängigkeit von Datenbanken und anderen Software-Komponenten.
Das bestätigen auch die Erfahrungen der Stollmann GmbH. Bevor dort der Unternehmensbereich Umweltinformatik die Entscheidung für ein 4GL-Tool traf, wurden verschiedene Werkzeuge mit dem Ergebnis getestet, daß fast alle auf die Zusammenarbeit mit bestimmten Datenbank-Systemen angewiesen sind.
Ulrich Sichau-Raff, Leiter Produktion bei Stollmann, hielt diese Systeme für sein Unternehmen für nicht geeignet Das von Stollmann mit 4GL entwickelte Standardinformationssystem "Uwis" soll neben spezifischen Verwaltungsabläufen eine ganzheitliche Sicht der Emissionen und Immissionen ermöglichen. Um die Software-Investitionen der Kunden zu schützen, wurde es so konzipiert, daß die Software dank der Drei-Schema-Architektur der 4GL auf verschiedenen Hardwareplattformen und Datenbanken einsetzbar ist. Inzwischen läuft das Produkt auf PCs und der MicroVAX II von Digital Equipment.
Chancen für 4GLs mit Drei-Schema-Architektur
Bei dem Aachener Softwarehaus Dr. Sommer + Dr. Glasmacher traf man die Auswahl des 4GL-Tools ebenfalls aufgrund der Unabhängigkeit von Datenbanken und Betriebssystemen. Auf der Basis dieses Werkzeugs wurde ein Buchhaltungspaket (FIBGS) entwickelt, das 15 verschiedene Betriebssysteme und zwölf verschiedene Datenbanken unterstützt.
Inzwischen erstellte das Softwarehaus mit der 4GL eine Auftragsverwaltung für Import/Export. Michael Glasmacher, Leiter der 4GL-Abteilung: " Entwickelt haben wir auf C-ISAM, portiert haben wir auf Oracle, IDM und RMS. Wir arbeiten auf einer Mehrplatzanlage mit acht Benutzerplätzen, haben aber auch auf PCs portiert."
Acht Entwickler unterstützen die Arbeit von Michael Glasmacher. Fast alle sind Mathematiker oder Systemanalytiker mit Kenntnissen in Fortran und C. "Wir brauchen nur noch ein Viertel der Entwicklungszeit. Wesentlich ist der Komfort bei der Listengeneration. Wo man früher mit den herkömmlichen
Programmiersprachen explizit programmieren mußte, greifen wir heute auf die vorhandene Konzeption zurück."
Die Erstellung von Belegschemata zur Dateipflege geschieht heute innerhalb von ein paar Minuten. Glasmacher: "Dafür haben wir früher einen halben Tag gebraucht. Die technischen und kommerziellen Chancen, die sich für 4GLs mit Drei-Schema-Architektur auftun, sind insbesondere für Softwarehäuser sehr erfolgversprechend."
"Der große Vorteil des von uns eingesetzten 4GL-Tools beruht auf der Unabhängigkeit von Hardware- und Software-Umgebung, so daß mit sehr geringem Aufwand für den Anwender Ergänzungen und Änderungen möglich sind," erläutert Hubert Bucher, Leiter Produktion bei ITK. Das Darmstädter Systemhaus hat mit "Marvis" ein Informationssystem zur Unterstützung der gesamten Vertriebsorganisation entwickelt.
Das modular aufgebaute System dient der strategischen Marketingplanung und Vertriebssteuerung. Für den Innendienst existiert eine zentrale Datenbasis. Bucher: "Alle Außendienstmitarbeiter kommunizieren regelmäßig mit dem Innendienstrechner, der sämtliche Informationen vorhält. Die Datenbankanwendung dazu, die auch mit einem größeren Host-System kommuniziert, wird von sechs Entwicklern mit dem 4GL-Tool realisiert."
Die derzeitige Hardwareumgebung für das System besteht aus einer Microvax 3600 mit 20 Benutzerplätzen, als Datenbank- System setzt das Unternehmen RMS ein. Geplant ist, auf Bull DPX2 mit Unix umzusteigen. Von der Portabilität und der Möglichkeit, kleine Änderungen schnell durchzuführen, profitieren auch die Kunden.
Bei anspruchsvollen Neuentwicklungen ist der Produktivitätsgewinn allerdings nicht so groß wie erhofft. Ein wenig zurückhaltend urteilt Hubert Bucher: "4GLs mit Drei-Schema-Architektur, die sich durch Unabhängigkeit von der Hardware und Software-Umgebung auszeichnen, werden wohl an Bedeutung gewinnen. Ihr Nutzen wird aber immer auch abhängig vom Ausbildungsstand des Entwicklers sein."
Die in Filderstadt bei Stuttgart ansässige Dataloc entwickelt und vertreibt im Schwerpunkt Qualitätskontroll- und Labor-Informationssysteme. Derzeit baut das Unternehmen mit Hilfe eines 4GL-Tools ein Labordatensystem unter SCO/Xenix. Dazu der Geschäftsführer Norbert Laub: "Wir wollten ein 4GL-Tool, mit dem wir Datenbank-unabhängig sind und das ein Höchstmaß an Funktionalität bietet. In unserem Geschäft, der Labordatenverarbeitung, kommen wir auch mit kleineren Datenbanken aus. Daher haben wir uns nicht für Oracle entschieden." Die momentane Konfiguration basiert auf einer HP 9000 als Host und Vectra-PCs von Hewlett-Packard.
Zur Zeit werden am Markt mindestens dreißig verschiedene 4GL-Tools angeboten, die sich erheblich in ihren Konzeptionen und im Leistungsumfang unterscheiden. In einer Anwenderbefragung ergaben sich eine Reihe von Fragen, die vor dem Kauf eines Systems beantwortet sein sollten (siehe Kasten).
Wer ein Datenbank-unabhängiges Entwicklungssystem haben möchte, der sollte zudem auf die Drei-Schemen-Architektur achten. Der Programmierer muß dabei in einem Data Dictionary das konzeptionelle Schema der in der Anwendung erforderlichen Daten definieren. Mit einer Festlegung der logisch darüber liegenden externen Schemata erfolgt eine Umsetzung dieses konzeptionellen
Schemas auf die "Sichten" der Daten, die dem Endanwender geboten werden (vergleiche Abbildung).
Diese Sichten können weitgehend automatisch auf Bildschirmmasken unter verschiedenen Benutzeroberflächen und auf Reports abgebildet werden. Auf der anderen Seite muß eine Umsetzung des konzeptionellen Datenschemas auf konkrete Datenbanken und Dateien und damit auf das interne Datenschema erfolgen. Hier soll die 4GL eine möglichst weitreichende Unterstützung bieten, so daß die Arbeit des Programmierers im wesentlichen in der Definition des Data Dictionaries seiner Anwendung besteht.
Man muß sich jedoch darüber im klaren sein, daß herstellerspezifische Tools, wie sie von Datenbankherstellern angeboten werden, im allgemeinen auch nur auf den Datenbanken dieser Hersteller einsetzbar sind. Im Zeitalter heterogener Umgebungen ist ein einheitlicher Zugriff auf unterschiedliche Datenbanksysteme besonders hoch zu bewerten.
Ein zentraler Punkt im Leistungsumfang eines 4GL-Tools besteht in der Unterstützung der Client-Server-Architektur. Rechenintensive Teile einer Anwendung sollten möglichst auf Workstations oder leistungsstarken PCs (Clients) ablaufen, während Server mit hoher CPU-Leistung nach Möglichkeit nur über ihren Netzzugang als Datenbankserver genutzt werden. Sehr wichtig ist in diesem Zusammenhang, daß durch die 4GL eine automatische Aufteilung der Anwendung in Prozesse, die auf dem Client ablaufen, und Prozesse, die auf dem Server ablaufen, vorgenommen wird. Durch Arbeitsteilung auf zwei CPUs werden die Antwortzeiten der Anwendung kürzer.
Diese Art der Aufteilung einer Anwendung bietet darüber hinaus den unschätzbaren Vorteil, daß das Werkzeug Anwendungen unterstützen kann, die auf den Daten unterschiedlicher Datenbankserver verschiedener Hersteller in verschiedenen Netzen unter verschiedenen Datenbanksystemen basiert. In der amerikanischen Fachpresse hat sich dafür bereits als Schlagwort "Corporate Processing" durchgesetzt. So können in einer Benutzersicht, etwa auf einer Bildschirmmaske, Daten aus mehreren Datenbanken und Netzen kombiniert dargestellt werden.
Wesentlich dabei ist, daß die Schnittstelle zwischen Client und Server so ausgelegt ist, daß der Server nicht jede Anfrage "von Grund auf neu" bearbeiten muß, sondern auf Informationen vorausgegangener Queries zurückgreifen kann. Darüber hinaus sollte in einer solchen Architektur die Möglichkeit genutzt werden, die Server als Gateway Rechner zwischen verschiedenen Netzen einzusetzen und so auch den Clients den Zugang zu diesen Netzen zu ermöglichen.
Der Markt für 4GLs wird derzeit auf etwa 3 Milliarden US-Dollar geschätzt. Eine Entwicklung, von der auch 4GL-Anbieter profitieren, ist die Ära der Client-Server-Architekturen. Ihr wesentlicher wirtschaftlicher Vorteil: Aufwendige Formate und Anwendungscodes können dort implementiert werden, wo es am kostengünstigsten ist - auf Workstations oder PCs.
Eine offene Client-Server-Architektur kann daher eine Schlüsselfunktion bei der Auswahl der 4GL einnehmen. Wesentlich für die Beurteilung der Leistungsfähigkeit einer 4GL ist auch das Spektrum der unterstützten Datenbank- und Betriebssysteme sowie der Benutzeroberflächen.
Ein bisher noch nicht erwähnter Vorteil von 4GLs liegt in der Möglichkeit zum schnellen Prototyping, das schon in frühen Phasen zu einer besseren Abstimmung mit dem Endanwender beiträgt. Für das schnelle Prototyping ist ein mächtiges Data Dictionary die entscheidende Voraussetzung.
Nicht zuletzt ist die Wahl der richtigen 4GL eine Frage des Leistungsumfangs im Endanwender Bereich. Dazu gehören Benutzeroberflächen, Pop-Up-Menues oder Scrolling Areas.
Kriterien für die Auswahl einer 4GL
- Welche Datenbanksysteme, Betriebssysteme und Benutzeroberflächen werden durch das Werkzeug unterstützt.
- Welchen Leistungsumfang bietet das Werkzeug für den Programmentwickler?
- Welchen Leistungsumfang (zum Beispiel Fenstertechnik) bieten die Routinen des 4GL-Tools für den Endanwender?
- Zu welchen herkömmlichen Programmiersprachen existieren Schnittstellen?
- Wie sieht es mit der Performance der erstellten Programme aus?
- Für welche CASE-Tools gibt es Schnittstellen?
- Welche Standard-Benutzeroberflächen werden vom 4GL-Tool unterstützt?