Sprachen der vierten Softwaregeneration gewinnen in Deutschland zunehmend an Bedeutung. Befürworter prophezeien den Sprachen der dritten Softwaregeneration ein baldiges Ende. Die Skeptiker sehen im Einsatz von Endbenutzersprachen hingegen einen folgenschweren Irrtum.

In der DV Szene geistert der Begriff der Softwarekrise umher. Ein zu hoher Teil der Kapazitäten ist durch Wartung und Pflege gebunden (bis zu 80 Prozent, abhängig vom Unternehmen und der Definition des Begriffs Wartungsaufwand).

Die verbleibende Manpower für die Entwicklung neuer Systeme reicht bei weitem nicht aus, die ständig steigenden Benutzerwünsche befriedigen zu können. Folge dieser Entwicklung ist ein kontinuierlich wachsender Anwendungsstau, der nur noch über Prioritätslisten zu steuern ist. Berechtigte Wünsche von seiten der Fachabteilung werden häufig gar nicht mehr aktualisiert, da eine kurzfristige Realisierung nicht zu erwarten ist.

Dieses Dilemma versucht die Softwareindustrie auf zwei unterschiedlichen Wegen zu lösen. Einerseits wird versucht, das gesamte latente Entwicklungspotential im Unternehmen %u aktivieren. Dieses latente Potential ist der Endbenutzer in der Fachabteilung. Wird er in die Lage versetzt, seine originären Probleme ohne Hilfe von DV-Spezialisten selbst zu lösen, so potenziert sich die Gesamtentwicklungskapazität im Unternehmen.

Nichtprozeduralität prägt "neue" Sprachengeneration

Um diesen Ansatz realisieren zu können, wurden Sprachen der vierten Softwaregeneration in Form von Endbenutzersystemen entwickelt. Diese "neue" Sprachengeneration zeichnet sich durch ihre Nichtprozeduralität aus. Lediglich das "Was" wird problemorientiert formuliert. Wie die Datenverarbeitung die Anforderung realisiert, das "Wie" der prozeduralen Sprachen der dritten Softwaregeneration (Cobol, PL/I, Pascal, Ada) steht hierbei im Hintergrund. Auf diese Weise erhält der Endbenutzer einen direkten Zugang zur Datenverarbeitung - in dieser Form auch als "individuelle Datenverarbeitung" bezeichnet - , ohne die DV-technologische Realisierung seiner Anforderungen kennen und formulieren zu müssen.

Kritiker dieses Ansatzes sehen in dieser Zielrichtung einen Irrweg. Sie sehen ein EDV-Babylon in Form von Insellösungen entstehen. Bereits vorhandene Systeme werden aus Unkenntnis oder Profilierungssucht neu entwickelt, das Rad wird also immer wieder neu erfunden. Fehler der Vergangenheit, aus denen die DV bereits gelernt hat, treten beim Endbenutzer wegen mangelnder Erfahrungen in gravierender Weise erneut auf.

Aus diesem Grunde setzen sie den Handel an einer anderen Stelle an. Ihr Ziel ist es, die hohe Bindung der vorhandenen DV-Ressourcen für Wartung und Pflege zu minimieren.

Sie erkennen, daß alle Methoden wie strukturierte, nominierte oder modulare Programmierung nicht den erwünschten Erfolg erzielen, wenn diese Methoden nicht durch adäquate Tools unterstützt werden.

In der Praxis wird häufig mit großem Aufwand während des Grob- und Detailkonzeptes eine Dokumentation beziehungsweise Programmvorgabe erstellt. Eine kongruente Abbildung dieser Vorgabe im Code findet jedoch nicht immer statt. Aber auch wenn die Dokumentation bei der Neuerstellung noch mit dem Source-Code übereinstimmt, so ist ein zumindest partielles Auseinanderlaufen während des Softwarelife- cycles kaum zu verhindern.

Sollen nun Änderungen vorgenommen werden, so "sucht" der Programmierer verzweifelt die entsprechende Stelle im Code. Ursprünglich gut strukturierte Systeme ähneln nach jeder Änderung mehr einem Flickwerk denn einem organischen Ganzen. Soll nun der Wartungsaufwand minimiert werden, so werden Werkzeuge benötigt, die einerseits verhindern, daß eine "saubere" Programmstruktur "kaputtgepflegt" wird und andererseits das Auseinanderlaufen von Dokumentation und Source unterbunden wird. Ausdruck dieser Forderungen sind Programmgeneratoren und Spezifikationssprachen.

Durch die Verwendung von Programmgeneratoren erfolgt die Programmerstellung nicht mehr direkt in der Sprache der dritten Softwaregeneration, sondern der Generator erzeugt aufgrund der Notationen den benötigten Code. Ebenso werden Änderungen lediglich im Generator formuliert und ein neuer Programmcode generiert.

Da der direkte Eingriff im Source nicht mehr notwendig ist, bleibt die Programmqualität trotz häufiger Änderungen erhalten. Der Wartungsaufwand vermindert sich hier drastisch. Um ein Auseinanderlaufen von Dokumentation und Programm zu verhindern, wurden generierende Spezifikationssprachen entwickelt. Diese Sprachen ermöglichen - zumindest für die Bereiche der Programmsteuerung und Datenzugriffe - eine Formulierung, die auf der gleichen Abstraktionsebene steht, wie traditionell erzeugte Programmvorgaben beziehungsweise -dokumentation.

Aus dieser Spezifikation kann jedoch, im Gegensatz zur üblichen Dokumentation, direkt der Code generiert werden. Die Anwenderspezifikation (Programmvorgabe) ist in diesen Bereichen immer ein deckungsgleiches Abbild der DV-Spezifikation (Programm) .

Die Softwareindustrie bietet somit heute zwei völlig unterschiedliche Werkzeuglinien an:

- Generierende Werkzeuge basierend auf Sprachen der dritten Softwaregeneration zur Minimierung des Wartungsaufwandes in der klassischen DV-Systementwicklung.

- Sprachen der vierten Softwaregeneration zur Verlagerung der Systementwicklung direkt in die Fachabteilung.

Beide Richtungen basieren auf der Zielsetzung des Abbaus des Anwendungsstaus, Mittel und Wege sind jedoch fundamental verschieden. Soll nun eine Entscheidung über das Für und Wider des Einsatzes von Sprachen der vierten Softwaregeneration erfolgen, so dürfen weder die Kassandrarufe zentralistisch denkender DV-Spezialisten, noch die euphorischen Stimmen aus der Fachabteilung als Maßstab genommen werden. Sprachen der vierten Softwaregeneration stellen nämlich keinen Ersatz, sondern lediglich eine sinnvolle Ergänzung des vorhandenen Werkzeugspektrums dar.

Das jeweilige Einsatzgebiet kann aufgrund der Merkmale

- DV-Unterstützungsebene

- DV-Bedarf

- Komplexitätsgrad

- Integrationsgrad bestimmt werden.

Die klassische Systementwicklung deckt traditionellerweise den repetitiven DV-Bedarf auf operativer Ebene ab. Es handelt sich hier um die Basisdialogein/-ausgabesysteme, denen sich der Sachbearbeiter für die Unterstützung seiner sich ständig wiederholenden Routinetätigkeit bedient .

Der Komplexitätsgrad dieser repetitiven Systeme ist sehr hoch, da die führenden komplexitätsarmen Insellösungen mittlerweile zu hochintegrierten, komplexen Gebilden zusammengewachsen sind. Wegen ihres integrativen Charakters werden sie abteilungsübergreifend eingesetzt. Besteht ein solcher Software-entwicklungsbedarf, so stehen Effizienz- und Sicherheitsgesichtspunkte im Vordergrund. Wegen ihres repetitiven Charakters ist diese Entwicklungskategorie vorausschaubar und somit planbar.

Diese Systeme sollten durch DV-Professionals mittels Generatoren und Spezifikationssprachen entwikkelt werden. "Schnellschüsse" von Endbenutzern stellen hier eine große Gefahr dar, da der Endbenutzer in der Fachabteilung die abteilungsübergreifenden Aspekte meist nicht kennt beziehungsweise nicht kennen kann und somit das Risiko der Entstehung inkompatibler, redundanter oder gar fehlerhafter Insellösungen aufs neue erwächst.

Wegen der mangelnden DV-Kenntnis wird die Effizienz und Pflegbarkeit solcher Systeme unter Umständen vermindert. Generatoren und Spezifikationssprachen basierend auf Sprachen der dritten Softwaregeneration besitzen aufgrund dieser Aspekte somit auch in Zukunft ihre Daseinsberechtigung.

4 GLs sind keine Modeerscheinung

Sprachen der vierten Softwaregeneration werden jedoch ebenso nicht lediglich eine kostspielige Modeerscheinung sein. Ihr Einsatzgebiet liegt in der Unterstützung des situativen Informationsbedarfs, der sich vor allem auf dispositiver und strategischer Ebene manifestiert. Ein solch situativer DV-Bedarf ist der spontane, sich aus der Situation in dieser Kombination voraussichtlich nur einmal ergehende Informationsbedarf.

Hier kann der Endbenutzer beziehungsweise Manager nicht auf den langen Weg (Prioritätenkataloge, Entwicklung durch DV-Spezialisten) bis zur Realisation der Anforderungen warten, da er unverzüglich entscheiden und handeln muß. Eine spätere Realisierung bringt ihm keinen Nutzen, da zu diesem Zeitpunkt bereits völlig andere Problemfelder zu bewältigen sind und sich aufgrund dessen der Informationsbedarf entsprechend verlagert hat. Dieser situative DV-Bedarf ist in der Regel komplexitätsarm.

Es zeigt sich also daß heute völlig verschiedene Werkzeuge für unterschiedliche Softwareentwicklungskategorien und Benutzergruppen zur Verfügung stehen. Aufgabe der DV muß es nun sein, entsprechend dieser zwei Entwicklungskategorien die geeigneten Werkzeuge auszuwählen, einzusetzen und somit einen optimalen Toolmix zu definieren.

* Heribert Thimme arbeitet als Systemanalytiker im Gerling-Konzern, Köln.