Entwicklungstools der vierten Generation gaukeln eine Lösung des allgegenwärtigen Anwendungsstatus vor. Doch, so Marc Hirschleber*, erst die Einbindung solcher Werkzeuge in eine ausgeklügelte Infrastruktur für Anwendugsentwicklung verspricht Erfolg.

Um der Backlog-situation entgegenwirken zu können, muß neben Softwarequalität auch Produktivität gefordert werden. Dafür jedoch sind die Sprachen der vierten Generation (4GLs) nicht ausgelegt.

Ein für den Abbau des Anwendungsstaus hinreichender Produktionszuwachs ist langfristig nur zu erreichen, wenn 4GL-Entwicklungssysteme über eine standardisierte Infrastruktur den gesamten Life Cycle eines Systems erfassen und dabei zudem von einem Programmgenerator unterstützt werden. Nur so können Aspekte von Case die im folgenden dargestellten Schwierigkeiten bei der Automatisierung der Anwendungsentwicklung gelöst werden.

Nachdem der Begriff des Software-Engeneerings lange genug strapaziert wurde - ohne die Probleme hinreichend beheben zu können - wurde die Zauberformel Case auf die " Workbench" gebracht. Warum nicht computerunterstützt arbeiten?

Computer Aided Software Engineering (Case) verlangt Standards, Automation und ingenieurmäßiges Vorgehen. Das "Computer Aided" hat sicherlich seine Berechtigung, denn neben allen anderen Arbeitsbereichen sollten auch und gerade die Softwareentwickler in den Prozeß einbeziehen. Schwierigkeiten haben wir mit dem "Engineering". Was machen wir eigentlich falsch?

Engineering bedeutet strukturiertes, standardisiertes Vorgehen. Dieses beginnt bei der Methodik und nicht beim Kauf einzelner Werkzeuge, die uns schöne Grafiken auf dem Bildschirm bescheren . Leistungsstarke Tools für die Systemenentwicklung sind verfügbar. Das Problem liegt daher im uneinheitlichen Entwicklungsprozeß, bei dem die potentiell vorhandenen Hilfsmittel nicht methodisch integriert werden. Der Grund liegt meines Erachtens in einem mangelden Bewußtsein für folgende Problembereiche.

* Der Systementwicklungprozeß ist nicht durchgängig unterstützt denn es gibt kein Produkt , das alle Aspekte von Case abdeckt.

* Die Informationslücke zwischen Aufgabenstellung und Aufgabenbewältigung wird unterschätzt.

* Es fehlen Standards für die Anwendungsentwicklung .

* Im Bereich der Wartung von Software gibt es kaum Tools.

* Die Kenntnisse über Methoden sind unzureichend .

Case muß die Automatisierung des gesamten System Life Cycles umfassen und damit auch die Bereiche Kontrolle, Projekt- und Konfigurationsmanagement abdecken. Diese erweiterte Betrachtung von Case kann als Case-Environment bezeichnet werden . Um eine solche Umgebung zu schaffen, sind folgende Voraussetzungen unabdingbar:

* Verständnis für die Einflüsse und Entwicklungen , die zur Festlegung von Standards innerhalb der DV- Welt führen;

* eine offene Architektur, die die Flexibilität zur Anbindung verschiedener Tools liefert, um eine effektive Gesamtlösung zu erhalten;

* eine Gesamtlösung sollte einfache Handhabung und strukturierte Vorgehensweise für und optimale Kommunikation zwischen den integrierten Tools offerieren.

Vor dem Kauf von Werkzeugen sollte Klarheit über die einzusetzende Methode und sich abzeichnende Standards herrschen. Aufbauend auf einem fundierten Grundkonzept können die Hilfsmittel sodann aufeinander abgestimmt werden. Für die Benutzbarkeit ist es erforderlich, daß sich die Werkzeuge dem Anwender gegenüber gleichartig verhalten. Den Mittelpunkt bildet idealerweise eine zentrale Informationsbasis, die eine aktuelle und umfassende Kommunikation zwischen Entwicklern und Endanwendern einerseits und wischen den Werkzeugen andererseits ermöglicht.

Integration ist der Schlüssel zur Unterstützung eines Case-Environments. Integration wird erreicht, wenn Tools auf eine gemeinsame Informationsbasis zugreifen, allgemein bekannt als Repository. Dieser wird zum Herz des Case-Environments, indem alle Systeminformationen verfügbar und sowohl Konsistenz als auch Integrität garantiert sind.

Das Repository legt das Informations Resource Dictionary (IRDS) fest. Damit werden die Schnittstellen für die zu integrierenden Werkzeuge deklariert. Es wird verschiedene Toolsets geben . Es wird verschiedene Toolsets geben, die über eine einheitliche Benutzeroberfläche zugänglich sein werden. Kein Unternehmen kann hier in allen Bereichen das jeweils "beste" Tool anbieten . Als Basis diese Flexibilität kommt nur eine offene Architektur auf Seiten der Tools in Frage.

Zur Zeit arbeiten wir mit Schnittstellen, die die Brücke zwischen den einzelnen Tools direkt herstellen (Interface Life Cycle Support ). Um in den Status eines "Integrated Life Cycle Supports" zu gelangen, kann die Entwicklung jedoch nur über Industriestandards (Portabilität, einheitliche Benutzungsoberfläche, Repository, normierte Datenbankschnittstelle) und Offene Architekturen (Analyse/Designschnittstelle, Workstation-Unterstützung, Case-Environment-Unterstützung ) zur Integration (Change Management, Configuration Management, Reverse Engineering) führen.

Reine MS-DOS-Tools werden nicht überleben

Die Auswahl benötigter Werkzeuge sollte sich an diesen Prinzipen orientieren, um Leistungsfähigkeit in Verbindung mit Unabhängigkeit zu gewährleisten. Wichtig für die Oberflächen des Gesamtsystems und die Möglichkeit der freien Auswahl leistungsfähiger Tools für die verschiedenen Aufgaben der Awendungsentwicklung . Zur Durchführung dieses Konzeptes müssen Host und (intelligente) Workstation kooperieren und ein gemeinsames Repository nutzen (vergleiche Abbildung 1 auf Seite 33).

Der PC ist in den vergangenen Jahren zum Tummelplatz für Hunderte von Front-End-Tools geworden. Ihr Schwerpunkt liegt in der Analyse wo die Stärken des PCs voll ausgenutzt werden können - zum Teil werden auch Bereiche der Planung für das Design abgedeckt . Diese "Analyst-Workbench"- Produkte sollten hinsichtlich der Methode auf Konformität mit dem bisherigen Vorgehen, benötigen Schulungsaufwand sowie Weiterentwicklung auf ein zukünftiges Betriebsystem untersucht werden.

Reine MS-DOS-Tools werden jedoch nicht überleben. Das Betriebssystem MS-DOS wird kein Standard, so daß wir von einer starken Reduzierung des heutigen Angebotes von Analyse-Werkzeugen ausgehen müssen Die Unterschiede der zugrunde liegenden Methoden beschränken sich auf den Ansatz (daten-/funktionsorientiert ) , die verwendete Notation und Technik, die Liste auszuführender Tätigkeiten und auf die erzeugten Ergebnisse.

Für die Auswahl eines Analyse-Tools ist die nachfolgende Integration von größter Bedeutung. Akzeptanz, Projektverwendbarkeit, generelle Anpassungsfähigkeit in die bestehende Organisation und potentielle Durchsetzbarkeit sind neben dem zu erwartenden Trainingsaufwand zu beachten.

Weiterhin ist die Erwartungshaltung hinsichtlich Front-end-Tools relevant. Die Verwendung von strukturierten Techniken, die durch den Computer unterstützt werden und in visueller Darstellung ihren Ausdruck finden, führen zu erhöhter Qualität bei der Software. Wird das angestrebt, so ist eine Investition gerechtfertigt.

Produktivität dagegen ist primär nicht über ein Front-end-Tool zu erreichen.

Sekundär jedoch senkt erhöhte Qualität die Kosten und steigert damit auch die Produktivität. Erwähnenswerte Steigerungen sind dennoch frühestens nach drei Jahren zu erwarten.

Zur Überbrückung der Infortmationslücke zwischen tatsächlichen Benützer und erfolgender Aufgabenbewältigung ist es unerläßlich, den Endanwender in den Systementwicklungsprozeß stärker einzubeziehen und den Schwerpunkt auf die Systembeschreibung zu verlagern. Hier bietet sich der "Prototyping-Approach" an der computerunterstützt die Arbeit des Benutzers fördert und eine einfache, schnelle und änderungsfreundliche Methode zur Erprobung der Software darstellt. Prototyping heißt jedoch nicht Verzicht auf systematische Analyse, sondern setzt sie voraus.

Nach der Spezifizierung des "Was" sollte die automatische Generierung der lauffähigen Programme stehen. Umfangreiche Regelwerke übernehmen die Realisierung für das gewünschte Zielsystem, wobei die erzeugte Sprache auf sich eine untergeordnete Rolle spielt. Dennoch bedeutet die Investition in einem Generator für eine Standardsprache (Cobol, PL/1) ein erhöhtes Maß an Unabhängigkeit vom Anbieter.

An dieser Stelle kommt der Aspekt der Produktivität wesentlich stärker zum Tragen. Dennoch ist das vorrangige Anliegen bei der Benutzung leistungsfähiger Generatoren das Erstellen wartungsfreundlicher Programme. Der Produktivitätsgewinn wird also - bei guten Generatoren - mehr in der Wartung als bei der eigentlichen Neuentwicklung liegen.

Beim Aufbau einer Entwicklungsumgebung muß die Unterstützung aller Projektphasen gewährleistet sein. Bereits die Planung neuer Anwendungen kann computergestützt erfolgen. In dieser Phase setzten Projektmanagementsysteme ein. Sie geben Aufschluß über Zeiten, Kosten und Resourcen der Systementwicklung. Darüber hinaus werden diese Werkzeuge simultan und alle Phasen übergreifend als Projektsteuerungssysteme eingesetzt. Im weiteren Sinne können bereits "Electronic-Mail" Systeme als Case-Komponente betrachtet werden.

Vor der Erfassung und Abbildung der zu automatisierenden Geschäftsbereiche hat eine Analyse stattzufinden, die die Kommunikation mit der Fachabteilung berücksichtigt. Unabhängig davon, ob mit der Informationsanalyse oder der Funktionsbeschreibung begonnen wird, muß der spätere Anwender beziehungsweise ein Vertreter in die Analyse einbezogen werden.

Da alle bekannten Analysemethoden grafische Darstellungsformen als wesentliches Element einschließen, liegt es nahe, hier die entsprechenden Möglichkeiten von PCs beziehungsweise Workstations zu nutzen. Daten- und Funktionsmodelle lasse n sich dort leicht über Datenflußdiagramme zusammenführen. Aktionsdiagramme bilden dann einen Pseudocode für die spätere Anwendung ab (vergleiche Abbildung 2 auf Seite 34).

Mit den Möglichkeiten von Mausunterstützung, Pull-down-Menüs und Windowing bieten Analyse-Tools eine Benutzeroberfläche, wie sie sich auf Mainframe-Terminals nicht darstellen läßt. Damit diese Werkzeuge jedoch nicht zu "Malkästen" abqualifiziert werden, ist es erforderlich, eine Anbindung an Tools der nach folgenden Phasen zu ermöglichen. Sie kann in der Anfangsphase über einen Datenimport beziehungsweise -export realisiert werden. Grundsätzlich sollte aber die Möglichkeit begeben sein, eine Integration über das Repository zu erreichen. Prinzipiell gilt, alle Informationen, die Grundlage für das Systemdesign sind, dem Designwerkzeug zur Verfügung zu stellen.

Im Design werden Analyse-Informationen zu konkreten Systemdesignvorschlägen weiterverarbeitet. Was betrifft zunächst die Benutzerschnittstelle in Form von Bildschirmen und Listbildern. Ein Gestaltungswerkzeug muß also flexible Unterstützung beim Entwurf von Bildschirmbildern bis hin zu kompletten Transaktionen bieten.

Der Programmierer muß vor allem übersetzen

Feld- und Konsistenzprüfungen sowie Dialogablauf sind Teil der Benutzeroberfläche und sollten weitgehend unabhängig von einem lauffähigen Programm im Design spezifiziert werden können. Am Ende kann die komplette Anwendung dargestellt werden, ohne daß ein fertiges Programm vorliegt: Die Basis für ein Prototyp ist geschaffen (vergleiche Abbildung 3).

In Zusammenarbeit mit dem späteren Systemnutzer wird nun die Gestaltung verifiziert. Änderungswünsche können interaktiv eingebracht und ihre Wirksamkeit im Prototyping unmittelbar überprüft werden. Am Ende dieses Prozesses liegt ein realisierbares Design vor.

Konstruktion von Programmen bedeutet Umsetzung der Design-Informationen in eine dem Computer verständliche Form. Die Arbeit des Programmierers gleicht somit der eines Übersetzers. Die komplexe Systemarchitektur des Mainframes erfordert dabei umfassende Kenntnis des eingesetzten TP-Monitors und der benutzten Datenbank. Oft wird der größte Teil des Programmcodes benutzt, um die Anwendung für eine bestimmte Zielumgebung lauffähig zu machen, und nur ein relativ geringer Teil des Codes wird für die Anwendung selbst benötigt.

Um der Backlog-Situation entgegenwirken zu können, wurde Produktivität der Programmierung gefordert. Das Resultat war der Einsatz verschiedenster Programmierwerkzeuge, die auf einer rein anwendungsorientierten Ebene angesiedelt sind. Sprachen der vierten Generation (4GL) erhöhen zweifellos die Produktivität der Anwendungsentwicklung - soweit sie der konventionellen Programmierung (3GL) gegenübergestellt werden.

Trotzdem stecken wir mit den Sprachen der vierten Generation in einer Sackgasse. So reicht der Produktionszuwachs nicht aus, um den Anwendungsstau entscheidend abzubauen. Trotz vieler Produkte sind weder ein Standard noch ein Cobol-Äquivalent in Sicht. Außerdem leiden die 4GL-Systeme unter Performance-Problemen und verstärken als "Insellösungen" die Abhängigkeit vom Hersteller. Bei all dem bleibt die Qualität der Software immer noch von den Fähigkeiten des Programmierers abhängig.

Programmierung ist mehr und mehr Übersetzungsarbeit geworden, die sinnvollerweise von einem Automaten (Generator) übernommen werden sollte. Erforderlich ist ein Werkzeug, das auf einer Ebene oberhalb der konventionellen Programmierung aufsetzt, sie selbst aber so weit wie nur möglich erspart.

In Form einer Spezifikation wird nur noch mitgeteilt, was gemacht werden soll. Das "Wie" unterliegt dem Generator. Über die so realisierte Automatisierung der "Übersetzungsarbeit" wird die Zahl der zur Programmerstellung notwendigen Tastenanschläge erheblich reduziert, indem der Entwickler seine Anwendung nicht mehr programmiert, sondern spezifiziert. Für ein derartiges Werkzeug gelten folgende Kriterien:

* Das Design des Systems umfaßt alle Bereiche.

* Prototyping muß ohne die Erzeugung von lauffähigen Lademodulen bereits auf der Designebene möglich sein.

* Es soll keine neue Makrosprache eingeführt werden. Die Spezifikation erfolgt menügeführt und/oder nach der "Fill-in-the-blank"-Technik.

* Wird aufgrund der Problemstellung ein bestimmter Algorithmus im Programm benötigt, so sollte dieser in gewohnter Form (Cobol oder PL/1) im Rahmen der Spezifikation eingefügt werden.

* Die Benutzeroberfläche muß der gewohnten Umgebung entsprechen.

* Das Werkzeug läßt sich problemlos in die bestehende Anwendungsentwicklungsumgebung einpassen (offene Architektur).

Die Spezifikationsinformationen werden einem Generator zur Verarbeitung übergeben. Dieser fungiert als "Black Box" und erstellt immer gleichartig strukturierten Sourcecode, der dann unmittelbar compiliert und gelinkt werden kann. Es entstehen Load-Module, die völlig unabhängig vom Entwicklungssystem eingesetzt werden können. Das Ziel ist die Erzeugung portabler Anwendungen (vergleiche Abbildung 4).

Generatoren reduzieren den Test- und Debuggingaufwand

Der Aufwand für Test und Debugging reduziert sich durch den Einsatz eines Generators erheblich. Meist genügt ein Datenbanktracking, um die Funktionalität des Programmes zu testen. Sollte bereits ein Werkzeug zum Testen und Debuggen vorhanden sein, so kann dieses nach wie vor in gewohnter Form benutzt werden.

Der Einsatz eines Generators bietet so nicht nur die Möglichkeit einer beschleunigten Realisierung, sondern vereinheitlicht simultan die Struktur aller Programme. Dieses hat einen nicht zu unterschätzenden Vorteil in der Wartung, da nicht mehr der einzelne Programmierer die Struktur eines Programmes bestimmt. Nachfolgende Entwicklergenerationen werden diesen Umstand gar hoch zu schätzen wissen. Das Suchen im fremden Programmcode findet ein Ende. Die Orientierung in der Designoberfläche des Generators ist um ein Vielfaches leichter. So nimmt dieses Werkzeug einen zentralen Platz im Rahmen des phasenorientierten Vorgehens ein. Seine Anbindung an das zentrale Repository ermöglicht die vollständige Integration in das Case-Environment.

Im Rahmen der Wartung werden sämtliche Entwicklungsphasen noch einmal durchlaufen. Der Entwickler begibt sich bei Änderungswünschen nicht mehr in den Quellcode, sondern führt die Änderungen auf der Analyse- und/oder Designebene durch. Diese Modifikationen wirken sich unmittelbar auf den Prototyp und die Konstruktion der Anwendung aus (vergleiche Abbildung 5).

Der Produktivitätszuwachs wird bei Einsatz der oben genannten Werkzeuge den bei der Neuentwicklung mehrfach überschreiten und die Investitionen in eine solche Umgebung nach kurzer Zeit amortisieren.

So kann die gesamte Infrastruktur der Case-Umgebung nicht nur für die Neuentwicklung, sondern ebenso für die Wartung von Systemen genutzt werden.

*Marc Hirschleber ist Systemberater bei der Pansophic GmbH in Hamburg.