Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Der kommerzielle Erfolg läßt auf sich warten, doch


19.01.1990 - 

SQL konnte den 4GL-Tools zum Durchbruch verhelfen

Genau wie Unix die Hardware nebensächlich macht, und somit die Anwender nicht mehr von einem einzigen Hersteller abhängig sind, so erzielt die schrittweise Etablierung von SQL-orientierten Abfragesprachen den gleichen Effekt im Bereich der Datenbanken. Zu diesem Ergebnis kommt eine Untersuchung des Forschungsteams Martin Butler und Robin Bloor.

Der Rückblick auf die achtziger Jahre zeigt einen Marktbereich, der mehr versprochen als gehalten zu haben scheint. Von Beginn des vergangenen Jahrzehnts an wurden die unglücklichen Cobol-Programmierer mit Verkaufsinformationen bombardiert, aus denen hervorging, daß sie bald überflüssig sein würden. Technisch orientierte Anwender (die nicht einmal Programmierer sein mußten) sollten ihre Aufgaben übernehmen können. Dabei sollten sie mit Tools arbeiten, die komplexe Anwendungen zehnmal schneller als die ausgebildeten Programmierer entwickeln würden, und die als Dreingabe auch noch portierbar und flexibler wären.

4GL-Tools beeindrucken nur bei Standardroutinen

Theoretisch müßten eigentlich die meisten professionellen Softwareentwickler die traditionellen Programmiersprachen schon längst komplett an den Nagel gehängt haben. In der Praxis gehen Schätzungen allerdings davon aus, daß noch immer 40 Prozent der zur Zeit in den USA entwickelten Systeme in Cobol geschrieben werden, während gleichzeitig der Einsatz von C aufgrund der Portabilitäts-Vorteile und der engen Unix-Anbindung boomt. Was lief denn da eigentlich schief und was stimmt heute noch?

Die Untersuchung (4GLs: An Evaluation and Comparison, veröffentlicht von der Butler Bloor Ltd.**) identifiziert eine Anzahl von zentralen Faktoren für den Erfolg von 4GL-Sprachen, die anfangs nicht allgemein erkannt wurden. Was die 22 untersuchten 4GL-Produkte gemeinsam hatten, war, daß sie alle ein Daten-Dictionary, feste Datenfelder, Datenbank-Tabellen, Formulare und gelegentlich identische Prozeduren einsetzen. Solche Sprachen aber sind lediglich ein Front-End-Produkt, um die in diesem Dictionary enthaltenen Daten zu verwenden und man sollte dies beim Schreiben von Programmcode nicht vergessen.

Es wäre sinnvoller, so die Studie, in den Kategorien einer 4GL-Umgebung zu denken, die mit Dictionary, Verwaltungspaket für Formulare, Abfragesprache, Berichtgenerator und einer traditionellen Programmiersprache der dritten Generation

ausgerüstet ist und die dazu ermutigen, mehr Aktivität in die Analyse- und Design-Phasen zu investieren. Und von genau diesen Dingen wollten uns die 4GL-Verkäufer weismachen, daß sie überflüssig geworden wären. Diese neuen Sprachen beeindrucken dann, wenn sie Routinen für häufig verwendete Funktionen generieren, etwa einfache Datenoperationen. Allerdings scheitern sie oft an Aufgaben, die nicht aus dem Standardbereich stammen. Eine Fallstudie der Untersuchung berichtet von einem Anwender, der zwei Wochen mit dem "Zusammenstricken" einer Strichcode-Routine verbracht hat, die in einer traditionellen Programmiersprache binnen einer Stunde hätte realisiert werden können.

Es stellte sich schnell heraus, daß die Funktionalität der 4GLs praktisch immer auf Kosten der Leistung ging.

Die ersten 4GL-Produkte waren häufig sehr langsam und erforderten enorme Speicherkapazitäten. Darüber hinaus entstanden durch die Vorteile von anwenderseitig einstellbaren Elementen oft extrem komplexe Berichtfunktionen, die sehr viel CPU-Zeit benötigten. Und die Forderung nach Benutzerfreundlichkeit hatte zur Folge, daß viele der frühen 4GL-Produkte nicht prozedurorientiert arbeiteten. Die daraus resultierende Inflexibilität hat dazu geführt, daß neuere 4GL-Produkte wieder Prozeduren kennen.

Ein Bereich, den die 4GLs immer noch nicht zufriedenstellend abdecken, ist das Debugging, was umso erstaunlicher ist, als eine neuere Untersuchung der Ready Systems Inc. ergab, daß die Software-Pflege bis zu 67 Prozent der gesamten Projektkosten ausmacht, Tests verbrauchen 15 Prozent, Analyse einschließlich Design elf Prozent und die eigentliche Programmierung nur noch sieben Prozent des finanziellen Aufwands.

Trotz allem geht es dem 4GL-Markt gut. Schätzungen gehen von Umsatzzahlen von drei Milliarden Dollar für Datenbanken und dazugehörige Sprachen für , 1990 aus. Die Produkte wurden weiterentwickelt und die Hardware der neuen Generation kann heute besser mit den zusätzlichen Anforderungen der 4GL-Produkte umgehen.

Schlechte Testergebnisse erzielten alte Sprachen

Die Untersuchung unterstreicht, daß fast alle großen Softwarehäuser wie Computer Associates, Oracle, Ashton-Tate, Ingres, Cincom Systems, Software AG, Cognos und Information Builders 4GL-Sprachen anbieten. Außerdem bietet eine Reihe von kleineren, aber nicht unbedeutenden Unternehmen vielversprechende Produkte an, wie zum Beispiel Sybase, Unify und die holländische Firma Uniface. Für DECs VAX-Umgebungen gibt es rund 40 Produkte, für die Unix-Umgebungen etwa 30.

Nur sehr wenige 4GL-Produkte laufen nur auf einer bestimmten herstellerspezifischen Hardware. Dazu gehören das VAX-spezifische Systel und das IBM-spezifische Synon/2. Die restlichen 20 der 22 untersuchten Produkte laufen alle unter Unix - außer Natural von der Software AG und DB-Gen von Computer Associates, die beide "bald" auch als Unix-Versionen verfügbar sein sollen.

Der Bericht beurteilt die Produkte nach sechs Kriterien: Entwicklungs-Umgebung, Leistung, Architektur und Leistungsumfang, Interoperation, Anwender-Funktionalität und Portabilität. Die besten Gesamtergebnisse erzielten die Produkte von Computer Associates und der Software AG, die beide in den Bereichen "Leistung" und "Architektur und Leistungsumfang" Bestnoten erzielten.

Andere Produkte, die sich in der Untersuchung auszeichnen konnten, sind Accell von Unify und Uniface, das in Europa mit der Sybase-Datenbank unter dem Namen Fastbuild angeboten wird. Diese Produkte erhielten Bestnoten für das Kriterium "Entwicklungs-Umgebung", wobei das Uniface-Produkt intensiv auf ein leistungsfähiges Daten-Dictionary zugreift und über ein gutes Formular-Management und eine vollständige Datenbank-Unabhängigkeit verfügt.

Die Produkte, die weniger gute Ergebnisse erzielten, sind ältere Sprachen wie Sculptor von Microprocessor Development Group (Probleme beim Interfacing mit 3GL) und Filetab vom UK National Computer Centre. Andere in der Untersuchung bewertete Produkte sind Focus, Informaix, Ingres, Mimer, Oracle, Powerhouse, Pro IV, Progress und SAS.

DB-Unabhängigkeit Ist der wichtigste 4GL-Grund

Die 4GL-Explosion hat gerade erst begonnen. Der zunehmende Einsatz von SQL bedeutet, daß die Preise für Datenbanken fallen werden und die Anbieter einen Weg finden müssen, ihre Produkte von denen ihrer Mitbewerber abzugrenzen. Der wichtigste Trend im 4GL-Markt ist die Datenbank-Unabhängigkeit, deutlich sichtbar am Beispiel der Unify Corp., die erst kürzlich das Accell-Toolset von der eigenen Datenbank getrennt - und selbst den eingefleischten Mitbewerber Oracle davon so überzeugt hat, daß mittlerweile selbst Oracle dieses Produkt vertreibt.

Wenn man die Interoperation betrachtet, dann ist es wahrscheinlich, daß einige Anbieter "Konvertierungs-Produkte" auf den Markt bringen werden, mit denen die Anwender von einer 4GL auf eine andere wechseln können, womit die Verankerung einzelner Produkte im Unternehmen aufgelöst wird. Dieser Trend hat bereits mit Cobol in der dritten Generation begonnen und wird sich mit den 4GL-Produkten weiter fortsetzen.

Die objektorientierte Funktionalität wird immer wichtiger werden, wobei immer engere Anbindungen zwischen Bibliotheken der dritten und vierten Generation entstehen werden. Der Untersuchungsbericht sagt weiter, daß der Hardware. Trend zu Client/Server-Konfigurationen die Probleme der Leistungsbeschränkung lösen wird. Diese Architekturen "sind die ideale Hardware für 4GL-Systeme". Vielleicht sind die Tage von Cobol wirklich gezählt.