Mit den Sprachen der vierten Generation lassen sich Programme unheimlich schnelle aber auch schlampig erstellen. Computergestütztes Software-Engineering garantiere dagegen ein Mindestmaß an Qualität. Doch nicht immer gelingt die Umsetzung des Designs in ablauffähigen Code. Im Team jedoch, so Michael Bauer, könnten beide Konzepte unschlagbar sein.
Bei allen DV-Abteilungen besteht der Bedarf, die Anwender schneller mit guten DV-Lösungen zu versorgen, um so den Anwendungsstau abzubauen. Mit Sprachen der vierten Generation wurde ein Schritt in diese Richtung getan. Programme lassen sich eindeutig schneller entwickeln und leichter warten als mit herkömmlichen Programmiersprachen.
Umfragen des Autors unter deutschen DV-Anwendern belegen, daß sich im Durchschnitt der Aufwand für Programmerstellung auf 48,3 Prozent, für Programmwartung auf 48,6 Prozent verringert hatte. Bedingt durch die unterschiedliche Leistungsfähigkeit und Mächtigkeit der eingesetzten 4GL schwankten die Erfahrungen der Anwender stark.
Die direkte Ausführung und Änderung von Bildschirmmasken und Programmen am Terminal bei Einsatz einer 4GL ermöglicht, Prototyping zusammen mit der Fachabteilung zu betreiben. Deshalb reduzierte sich nach den Erfahrungen der Anwender auch der Aufwand für die Organisation neuer Anwendungen im Durchschnitt auf 82,8 Prozent.
Mehr Produktivität bei oft schlechterer Qualität
So gesehen, kann man konstatieren, daß Sprachen der vierten Generation die Programmierproduktivität steigern. Aber lösen sie damit auch das eigentliche Problem?
Etwas salopp formuliert, kann man sagen: Wenn man zehnmal schneller programmiert, kann man auch zehnmal schneller "Schrott" produzieren. Denn zur Software-Entwicklung gehört auch der Faktor "Qualität".
Genau an dieser Stelle setzen die CASE-Tools an. Sie haben die Ziele:
- die kreative Entwicklungsarbeit
- Analyse und Design mit formalen Prozeduren und Grafik zu unterstützen,
- die Kontrolle des Projektablaufes und der einzelnen Arbeitsschritte sicherzustellen,
- alle Ergebnisse in strukturierter Form in einer Entwicklungsdatenbank abzulegen,
- die Ergebnisse maschinell umzusetzen als DB-Definitionen, Bildschirmmasken, Programmrahmen und Dokumentation.
Die Stärke der CASE-Tools liegt in den Phasen Analyse und Design, während die 4GL-Produkte stärker Programmierung und Test sowie Wartung abdecken. Hierbei gibt es Überschneidungen, wie die Grafik in Abbildung 1 verdeutlicht.
Die heutigen CASE-Tools haben eindeutig ihre Stärke in der Unterstützung des Entwurfs. Ihr Schwachpunkt aber liegt in der Umsetzung der fachlichen Spezifikation in ablauffähige Form. Wie können aus Entwürfen der Benutzeroberfläche Bildschirmmasken oder Listen werden? Wie können Prüfregeln für Daten an jeder Stelle automatisch angezogen werden? Wie werden Funktionsbeschreibungen in Programmcode und textliche
Dokumentation in eine Hilfe-Funktion überführt? Hierzu bieten die Produkte mehr oder weniger leistungsfähige Code-Generatoren an.
Generatoren erzeugen redundanten Code
Oft werden nur Programmrahmen erzeugt, die die Programmierer dann selbst mit Leben füllen müssen.
Selbst wenn eine umfassende Code-Generierung möglich wäre, müßte bei der Generierung von Cobol oder PL/1 jedesmal eine ganze Menge an redundantem Code erzeugt werden: für die Funktion Bildschirmblättern, für die Ausführung von Datenprüfungen, für die Hilfe-Funktion, für die Kommunikation mit TP-Monitor und DBMS und ähnlichem mehr alles Dinge, die in einer der Sprachen der vierten Generation schon als fertige Automatismen vorhanden sein können.
Hinzu kommt, daß der generierte Code im Batch umgewandelt, die Masken im Batch assembliert und die Programme in Tabellen des TP-Monitors eingetragen werden müssen, bevor ein Test beginnen kann, Tritt ein Fehler auf, so wiederholt sich die Prozedur wieder von vorne: Generierung, Umwandlung, Test. All dies haben aber die 4GLs durch ihre interaktive Ausführung bereits überwunden, so daß mit ihnen iteratives Prototyping und sofortiger Test möglich sind.
Das Team CASE/4GL ist mehr als nur Wunschtraum
Was läge also näher, als die CASE-Tools und die Sprachen der vierten Generation zu verbinden? Dann können schon in der Analyse- und Design-Phase Komponenten geschaffen werden, die sofort nutzbar sind: Bildschirmmasken mit dem Screen-Painter der 4GL, Prüfregeln für die Daten formuliert in der 4GL, statt Pseudocode gleich Anweisungen der 4GL und Dokumentation, die von der Hilfe-Funktion der 4GL gleichzeitig genutzt werden kann. Ein solcher Weg würde zu einer Integration von CASE-Tool und 4GL führen, wie er in Abbildung 2 dargestellt ist.
Ist das illusorisch? Nein, denn die Entwicklung vorhandener Produkte weist in diese Richtung. So wurde beispielsweise die 4GL Natural um das "Upper-CASE"-Tool Predict-CASE ergänzt, die neue Komponente CASE-Generator von Oracle erzeugt Anweisungen für SQL. Forms und auch für andere 4GLs sind CASE-Tools als Front/End in Arbeit. Nicht zuletzt die Aufnahme von CSP als Bestandteil des IBM-Konzeptes A-D/Cycle wird dazu führen, daß CASE-Tools statt Cobol direkt 4GL-Codes erzeugen und sich damit die Nutzen zweier Technologien verbunden werden.
Es muß also nicht heißen 4GL oder CASE, sondern 4GL und CASE.