Die aktuellen CASE-Diskussionen, lassen die Sprachen der vierten Generation vielfach obsolet erscheinen. Erich Leitner* plädiert jedoch für einen Anwendungsentwicklungs-Ansatz, der strukturierte Verfahren mit einer 4GL-Umgebung verbindet - vor allem deshalb, weil diese Kombination ein schnelles Prototyping unterstützt.

Das Dilemma der Software-Produktion ist seit den frühen 80er Jahren bekannt, doch nach wie vor unvollständig gelöst: Lediglich 30 Prozent der Entwicklungszeit stehen für neue Projekte zur Verfügung, 70 Prozent müssen für Wartung und Pflege aufgebracht werden. Das entspricht nicht gerade dem Idealbild einer "Software-Factory,", also der Produktion von Programmen wie am Fließband.

Damit Entwicklung und Wartung komplexer Softwaresysteme innerhalb eines akzeptablen Zeit- und Kostenrahmens kein Wunschtraum bleibt, haben die Software-Experten zwei verschiedene Lösungsansätze entwickelt: Die einen sehen das Hauptproblem in der Engineering-Qualität und glauben, viel Zeit durch gründlichere Anforderungsanalysen und exaktere Systemkonzeption sparen zu können.

Dieser Ansatz führte zur Entwicklung der strukturierten Programmierung, des strukturierten Designs und der strukturierten Analyse.

Für die anderen ist die Schwachstelle der bisherigen Software-Entwicklung in der Entwicklungsproduktivität zu suchen; ihrer Ansicht nach lassen sich Fehler im Design und bei der Programmierung einfacher beheben -und damit insgesamt mehr Systeme entwickeln -, indem Möglichkeiten geschaffen werden, um die Programme schneller schreiben und modifizieren zu können. Dieser Ansatz führte zur Entwicklung von Sprachen der vierten Generation.

Die Verfechter beider Ansätze konnten bislang nur Teilerfolge verbuchen. Immer noch lehnen viele Entwickler die strukturierten Verfahren ab, weil sie nicht bereit sind, deren "Starrheit" zu akzeptieren oder weil sie sich durch den erheblichen Aufwand abschrecken lassen, der für die konsequente Anwendung einer solchen Methode erforderlich ist.

Bislang wurden nur Teilerfolge verbucht

Die 4GL-Anhänger hingegen können auf Schwierigkeiten stoße, wenn sie schlecht konzipierte Systeme kodieren sollen oder wenn die zu kodierenden Systeme auf einer "falschen" Aufgabenstellung basieren.

Zur Zeit ist das Thema CASE in der Diskussion. Die Vertreter des strukturierten Ansatzes offerieren in diesem Bereich Tools, die zu einer Erhöhung der Produktivität in der Analyse- und Design-Phase führen, aber die Programmierung wenig berücksichtigen. 4GL-Anbieter wiederum haben Tools zur Steigerung der Programmier-Produktivität in der Implementierungsphase entwickelt; diese Werkzeuge tragen aber kaum dazu bei, die Qualität des Systemdesigns und der Anforderungsdefinitionen sicherzustellen.

Tatsächlich ist diese Kontroverse höchst überflüssig, denn selbstverständlich bieten auch 4GLs genügend Angriffspunkte für strukturierte Methoden. Ein Vorteil der Kombination von Viertgenerationssprache und strukturierter Methode liegt darin, daß damit ein rasches Prototyping unterstützt wird.

Die "Software-Factory" und der "Wasserfall-Ansatz", die von einem sequentiellen Produktionsprozeß ohne jede Rückkopplung ausgehen, haben sich als nahezu unpraktikabel erwiesen: Kein Anwender kann exakt definieren, wie seine Applikation aussehen soll; im nachhinein weiß er nur, was er nicht wollte. Auch die Erstellung von Lasten- und Pflichtenheften ist nicht der Weisheit letzter Schluß, denn wer kann sich bei der Bedarfsanalyse schon das "funktionierende" System vorstellen? Also wird in der Praxis so manches Design als korrekt verabschiedet, das sich bei der Implementierung des Systems als fehlerhaft herausstellt.

Das Prototyping kann dieses Problem lösen, weil hier der Anwender umfassend in den Prozeß eingebunden wird: Ein Entwicklungsteam führt 80 oder 90 Prozent der Phasen "Analyse" und "Design" durch, erstellt ein lauffähiges System und demonstriert es den Anwendern. Mögliche Schwachpunkte lassen sich dabei erkennen und eliminieren. Erst wenn die Vorstellungen des Anwenders in den funktionalen Prototypen verwirklicht sind, wird die Entwicklung abgeschlossen.

Dieser Weg erfordert zwar völlig neue Ansätze für die Planung, das Projektmanagement und die Einbindung der Anwender. Aber dadurch, daß die Systeme exakt auf die Belange der Anwender zugeschnitten sind, lassen sich optimale Resultate erzielen. Zudem wirkt sich diese Vorgehensweise positiv auf die Entwicklungskosten aus, da frühzeitig erkannte Analyse- und Designfehler ebenso frühzeitig behoben werden können.

Die Produktivität einer 4GL, ist hauptsächlich darauf zurückzuführen, daß zur Implementierung von Programmen weitaus weniger Source-Anweisungen erforderlich sind als bei einer Sprache der dritten Generation. Der Grund dafür liegt in zwei Basistechniken, die das System-Design beeinflussen.

Zum einen arbeiten 4GLs mit intelligenten Vorgabewerten, mit deren Hilfe die Zahl der Anweisungen verringert wird; möglich wird das durch vorprogrammierte Routinen und ein aktives Data-Dictionary.

Große Bedeutung der Datenanalyse

Dieses Dictionary, gewährleistet zudem die Unabhängigkeit der Programme von den Datenstrukturen, weshalb die Programme über verschiedene Hardware und Datenbank-Systeme portabel sind. Allerdings kann jedes Programm in einem 4GL-Systeme nur solange einfach geschrieben oder geändert werden, wie die Datenstrukturen richtig sind. Der Datenanalyse kommt daher eine große Bedeutung zu. Hier finden stark strukturierende Methoden wie das Entity Relationship Model (ERM) oder die Normalisierung von Datenstrukturen Anwendung.

Zum anderen verfügen 4GLs über integrierte Modelle für Abläufe. Bei der Realisierung muß das Ablauf-Design von der Transaktionslogik her auf diese vorgegebenen Abläufe abgestimmt werden. Außerdem sind in die 4GL bereits viele Einrichtungen für die Interaktion mit denn Anwender eingebunden, weshalb hier die Notwendigkeit detaillierter Spezifikationen entfällt. Das Arbeiten mit einer 4GL bietet folglich zahlreiche Anknüpfungspunkte für eine strukturierte Programmierung.

Typischerweise ist eine 4GL mit einer relationalen Datenbank verknüpft. Das schließt einige "exotische" Arten des physischen Datendesigns (beispielsweise codierte Datensätze und wiederholende Gruppen) aus und drängt den Analytiker zur Normalisierung. In einer 4GL-Umgebung werden die Begriffe Prozeß, Programm und Transaktion zu Synonymen, wobei ein Programm einen Prozeß abbildet, der eine Transaktion auf die Datenbank anwendet.

Das Schlagwort beim Prototyping heißt Einbindung der Anwender. Um deren Begeisterung aufrechtzuerhalten, ist es zwingend notwendig, daß die Zeiträume ohne Anwender--Beteiligung möglichst kurz gehalten werden. Gefordert ist also Flexibilität bei gleichzeitiger Strukturerhaltung. Sobald der erste Prototyp vorgeführt ist, werden Revisionen erforderlich. Dazu muß das "Design" in einer Form vorliegen, in der die Auswirkungen vorgeschlagenen Modifikationen leicht nachvollziehbar sind und Änderungen einfach durchgeführt werden können.

Folglich muß das Design selbst in einem integrierten Modell vorhanden sein. Strukturieren heißt hierbei, den Datenfluß und die Funktionalität des Komplexes von Anwendungsprogramm und Basissoftware durch einen Schichtaufbau zu entflechten: "Top" ist dabei die oberste Schicht zum Benutzer hin, "bottom" liegen die Schnittstellen zum Betriebssystem.

Wichtig ist, daß das Design jederzeit als ein einziges, in sich konsistentes Modell gesehen werden kann. Vorteilhaft ist das besonders bei eventuellen Änderungen: Sobald die zu modifizierenden Abläufe und Entities identifiziert sind, lassen sich ihre Auswirkungen leicht nachvollziehen; erforderliche Korrekturen während des Design müssen dann nur ein einziges Mal durchgeführt werden.

Ebenfalls wichtig ist, daß das Design-Modell zwar klar zwischen logischem und physischem Design unterscheidet, aber beide Design-Modelle miteinander integriert. Zwar darf das physische Modell aus Performance-Gründen vom logischen abweichen, aber die Integrität von logischen und physischen Modell muß vom Werkzeug gewährleistet werden, damit sich die Auswirkungen aller vorgeschlagenen Änderungen sowohl während der iterativen Entwicklung als auch später bei der Wartung analysieren lassen.

Änderungen sind vorgesehen

In jedem System sind die Daten beständiger als die Verarbeitung. Das gilt auch für das Prototyping mit einer 4GL: Nicht nur, daß sich Programme einfach umschreiben lassen, es wird sogar vorausgesetzt, daß sie sich ändern. Deshalb muß sich das Ablaufdesign eng an die Daten anlehnen.

Ein erstes Datendesign läßt sich mit denn Top-Down-Verfahren und in Form eines mehrstufigen Entity-Relationship-Modells erstellen. Sobald das Modell vollständig ist, bekommt jede Entity eine Reihe von Attributen zugewiesen, die anschließend innerhalb dieser Entity normalisiert werden. Ein erfahrener Analytiker wird ohnehin Entities in der Boyce-Codd' schen Normalform (BCNF) erstellen.

Auf der Ablaufseite beginnt das Design mit der Definition der externen Schnittstellen, die das System bereitstellen muß. Das entsprechende Diagramm bildet die Systemumgebung ab und stellt das oberste aus einem Set von top-down angeordneten Datenfluß-Diagrammen dar. Die Diagramme sind in dieser integrierten Umgebung mit dem ERM verbunden und verarbeiten die Entities.

Eine solche Erweiterung in den Datenfluß-Diagrammen bietet eine Reihe von Vorteilen: Zunächst lassen sich die Auswirkungen von Datenänderungen auf Abläufe, (und umgekehrt) einfacher analysieren. Auch die Überführung in ein relationales Modell der Datenspeicherung wird vereinfacht. Und schließlich ist eine Form von Entity-Life-Histories möglich, die zur Überprüfung des Ablauf-Designs benutzt werden können.

Das anfängliche physische Design sollte ebenfalls strukturiert entwickelt werden - nach einer Reiche von Regeln, die eine Eins-zu-eins-Entsprechung zwischen physischen Objekten (Relationen, Feldern in Relationen, Programmen und logischen Objekten (Entities, Entity-Attributen, Abläufen) nach sich ziehen. Dadurch läßt sich ein sofort einsetzbares Design erstellen, woraus sich - aufgrund der Implementierung im RDBMS und in der 4GL - ein erster Prototyp ergibt. Dieser Ablauf kann wiederholt werden, bis das logische Design stabil ist.

Um die Geschwindigkeit der Entwicklung zu steigern, ist es wichtig, den Code algorithmisch aus den Design selbst abzuleiten. Voraussetzung dafür ist eine enge Verbindung zwischen der Methode und der geplanten 4GL sowie der Datenbank. Erreicht wird damit zweierlei: Zum einen läßt sich das Design schnell und konsistent im Code abbilden, zum anderen wird der Weg zu automatischer Code-Generierung geebnet.

Wenn das logische Design schließlich stabil und mit dem Anwender abgestimmt ist, kann das physische Design optimiert werden. Auch hier müssen sich die Techniken eng am Datenbanksystem und der benutzten 4GL ausrichten; andernfalls können Entscheidungen getroffen werden, die die Performance in dem einen RDBMS verbessern, aber in einem anderen zu Engpässen führen.

Selbst in dieser Phase ist der Drang zur "Denormalisierung" sorgfältig zu überwachen. Unternehmensabläufe werden mit der Zeit modifiziert, was zu Änderungen des Softwareprodukts führen kann. In einem physischen Design lassen sich diese Korrekturen nur dann einfach implementieren, wenn es nach wie vor normalisiert ist und sich eng an das Design anlehnt.

* Erich Leitner ist Manager Technical Support bei der Cognos GmbH in Frankfurt.