Die Herrschaft der DV-Technik über die Anwender ist vorbei. Nicht mehr der Rechner sondern die Anforderungen des Arbeitsplatzes bestimmen die Arbeitsabläufe. Um hier den Ansprüchen der durch PC-Komfort verwöhnten Benutzern gerecht werden zu können, brauchen die Entwickler Werkzeuge, mit denen sie rasch auf Kundenforderungen reagieren können. Objektorientierte Applikationsgeneratoren könnten, so Rolf Hauber*, eine Lösung für dieses Problem darstellen.

Die Wünsche der Anwender von Datenbanken liegen naturgemäß immer ein paar Schritte vor den Möglichkeiten der Anbieter. War ein GB gestern noch eine respektable Größe für eine Datei, so werden heute 100 oder mehr GB gefordert. Ähnliches gilt für die Gestaltung der Benutzeroberfläche und für die Flexibilität beim Zugriff auf die gewünschten Daten.

Rapid Prototyping sichert Akzeptanz

Zunehmend führt auch das Vordringen der PCs in allen Bereichen der Unternehmen zu der Forderung, die sich im als Standard abzeichnende Bedienweisen aus Gründen der Einheitlichkeit zu berücksichtigen. Zu den Wünschen gehören multiple Windows, Pulldown-Menüs, Mausbedienung, grafische Symbole, On-line-Hilfsfunktionen.

Blickt man etwas weiter zurück, so läßt sich generell feststellen: Stand früher die optimale Ausnutzung der teuren Hardware im Vordergrund, so fordern die Anwenderunternehmen bei der Einführung einer neuen Applikation

- Erhöhung der Mitarbeiterproduktivität,

- Akzeptanz der Endbenutzer und

- die zeitgerechte Realisierung der Projektschritte.

Besonderes Gewicht legen die Unternehmen auf die Akzeptanz der Endbenutzer. Vielfach ergaben sich trotz umfassender Systemanalyse, strukturierter Programmierung und sorgfältiger Tests beim Anwender immer wieder Widerstände gegen die Einführung der Applikation. Aufwendige Nachbesserungen, Verschiebung der Termine und Nachtarbeit der Anwendungsspezialisten waren die Folge.

Es ist daher verständlich, daß die Entwickler frühestmögliche Absicherung der Akzeptanz der Endanwender für ein zu entwickelndes Programm suchen. Die Lösung heißt "Rapid-Prototyping" und stellt eine Technik dar, die es erlaubt, eine Benutzeroberfläche inklusive Dialogverhalten und Layout-Gestaltung vorzustellen, bevor die eigentliche Funktionalität der Anwendung im Detail erstellt wurde.

Der Rapid-Prototyp wird dem Endanwender vorgeführt und nach seinen Wünschen verändert. Der akzeptierte Prototyp bildet anschließend die Grundlage der Applikation. Erst jetzt werden Detailberechnungen und komplexe Abfrage-Operationen in die Anwendung eingefügt und ausgetestet.

Voraussetzung für diese Möglichkeit des Rapid-Prototyping ist die Trennung von Funktionsstruktur und Oberfläche des Programmsystems. Desktoporientierte Benutzeroberfläche und Rapid-Prototyping sind nur zwei von vielen Anforderungen, welche die Anwendungsentwickler an die Hersteller von Applikationsentwicklungs-Werkzeugen weitergeben.

Darüber hinaus werden in der Praxis eine Reihe zusätzlicher Eigenschaften von einem solchen Tool gefordert. Im Hinblick auf die organisatorische Einbindung sind das Hardware- und Datenbankunabhängigkeit sowie Unterstützung von Standards.

Zunehmend wird auch eine einheitliche Benutzeroberfläche (gleiches "Look and Feel") auf parallel eingesetzten alphanumerischen und grafischen Terminals gewünscht

Die Anpassung an sich verändernde Bedingungen im Unternehmen erfordern zudem gestaltbare Masken mit der Möglichkeit funktionaler Erweiterung. Aus Gründen des Datenschutzes ist außerdem erforderlich, daß der Systemadministrator die Benutzerschichten auf die Datenbank immer wieder neu definieren kann.

Nicht nur im Hinblick auf den EG-Markt ist bei unternehmensweitem Einsatz die Mehrsprachigkeit gefordert, mitunter am selben Terminal. Die Mehrsprachigkeit darf dann nicht auf die Texte der Masken beschränkt bleiben, sondern muß auch verschiedensprachige Daten berücksichtigen.

Aber auch von seiten der Systemtechnik bestehen Anforderungen, um die Erweiterbarkeit und die Wartung von Applikationen mit vertretbarem Aufwand zu realisieren. Neben der Modularität der Programme ist hier die Release-Fähigkeit in dem Sinne abzusichern, daß bestehende Programme ohne Änderung auch unter dem neuen, erweiterten und geänderten Software-Release laufen.

Für das Design der Programmentwicklungs-Tools bedeutet dies in der Konsequenz:

- Trennung der Benutzeroberfläche von der Applikation,

- Trennung der Datenbank von der Applikation und letztlich und ,

- Einsatz eines Tool eigenen erweiterten Data-Dictionarys für die Ablage von Masken, Menüs und der Beziehungen zwischen den Datenbankobjekten.

Werkzeuge für die Programmentwicklung

Nach der 80-20-Regel besteht der Großteil einer Applikation (eben 80 Prozent) aus Strukturen, die nach wiederkehrenden Verfahren zu realisieren sind. Die restlichen 20 Prozent enthalten die spezifischen applikationsabhängigen Funktionen. Der Ausgangspunkt bei der Entwicklung von Werkzeugen, welche die Programmierung von Anwendungen vereinfachen sollen, heißt deshalb: Verringerung der Routinearbeit.

Der Anwendungsprogrammierer hat heute die Wahl zwischen folgenden Klassen von Werkzeugen, die ihm die Routinearbeit erleichtern sollen und hinsichtlich Funktionsumfang und Handhabung klassifiziert werden können (vergleiche Abbildung 1):

- Programmgeneratoren, 3GLs (Third Generation Languages),

- 4 GLs (Fourth Generation Languages) und,

- integrierte objektorientierte Applikationsgeneratoren.

Die Programmiersprachen der dritten Generation haben schon immer dem Programmierer ein gewisses Maß an Routine abgenommen Das gilt vor allem dann, wenn man sie mit den Assembler-Sprachen vergleicht, die lange Zeit die einzige Alternative boten . Zu den 3GLs gehören Cobol, Fortran, Basic, C und Pascal - um nur einige der wichtigsten Vertreter dieser Gruppe zu nennen.

Für die heutigen Anwendungen mit Zugriff auf eine Datenbank und Präsentation der Daten am Bildschirm waren und sind jedoch ständig Routineoperationen zu programmieren. In dieser Situation hilft sich der Anwendungsprogrammierer mit dem Aufbau einer Bibliothek von selbsterstellten Programmroutinen, die durch Namensaufruf wie ein Befehl einsetzbar sind.

Unter Programmgeneratoren versteht man heute meist Systeme zur Erstellung von Masken und Menüs. Diese Funktionalität wird auch für das Rapid-Prototyping genutzt. Auf die damit generierten Grundstrukturen lassen sich dann - wie oben dargestellt - einfache Funktionen aufsetzen, die allerdings in vielen Fällen nicht ausreichen, um die Aufgabenstellung insgesamt zu lösen, so daß zusätzlich der Einsatz von 3GLs erforderlich wird .

Am Beginn der 4GL-Entwicklung standen Bibliotheken von Unterroutinen, die häufig zum Einsatz kamen und die dann durch ein Skript, einen Format File oder durch eine in 4GL geschriebene Sprache aufgerufen wurden. So konnte der Anwender mit jedem Statement eine Funktionskette auslösen, für die früher eine ganze Reihe von 3GL- oder Assemblerstatements nötig gewesen wäre. Allerdings müssen auch bei 4GLs Funktionen wie die Ansteuerung der Bildschirmausgabe einzeln implementiert werden. Den Zugriff auf Datenbanken unterstützen die Bibliotheksfunktionen.

4GL-Sprachen weisen aber auch Nachteile auf. Während die klassischen Programmiersprachen längst standardisiert wurden und fast überall laufen, sind die Sprachen der vierten Generationen anbieterspezifisch. Zumeist bieten sie Datenbankhersteller als Werkzeuge an.

Obiektorientierte Anwendungsgeneratore

Eine Weiterentwicklung der verschiedenen Ansätze stellen integrierte, objektorientierte Applikationsgeneratoren dar. Sie verknüpfen die Vorzüge von Generatoren und 4GLs, indem sie objektorientierte Generatoren zur Verfügung stellen und implizierte Funktionen zum Datenzugriff beinhalten.

Alle Teilkomponenten des Werkzeugs (Objekte, Masken, Menüs, Reportgenerator, Editor und Interpreter) greifen auf die gleichen Informationen zu, die in einem eigenen erweiterten Data-Dictionary abgelegt sind. Dieses Konzept erlaubt dynamische Programmänderungen zur Laufzeit und ist damit flexibel von Entwicklern und Endanwendern einsetzbar.

Die grafischen Benutzeroberflächen

Bei grafischen Benutzerflächen kommt es für den Applikationsprogrammierer zu einer Umkehr der Verhältnisse. Selbst bei Verwendung von Werkzeugen wie "OSF/Motif" oder "Open Look" müssen bis zu 70 Prozent des Aufwandes in die Benutzeroberfläche anstatt in die eigentliche Programmlogik gesteckt werden. Der Implementierungsaufwand steigt also beträchtlich. Aus diesem Grunde werden Entwicklungswerkzeuge, die auf den standardisierten Grafik-Tools aufsetzen, User-Interface-Management-Systeme (UIMS), eingesetzt. Ein solches System entlastet den Anwendungsprogrammierer von den Routinearbeiten an der Benutzeroberfläche und sichert die Portabilität der Anwendung. Zunächst wird das Layout festgelegt, anschließend der Dialogablauf getestet und schließlich werden die Funktionen programmiert.

Ein UIMS hat demzufolge vier Aufgabenbereiche abzudecken:

- In der Objektbeschreibung definiert der Anwender Lage und Ausprägung der Elemente der grafischen Benutzeroberfläche, wie Menüs, Formulare, Listen, Eingabefelder, Texte, etc., und der Attribute anhand

vorgegebener Elemente.

- Die Dialogbeschreibung legt alle Aktionen fest, die bei einem bestimmten Ereignis angestoßen werden sollen, etwa der Aufruf einer Maske, das Anspringen eines Feldes, das Berechnen eines Wertes etc. Sie enthält die Dialogfluß und Transaktionssteuerung und beherbergt gleichzeitig die eigentliche Logik der Anwendung.

- Der Datenbankanschluß ermöglicht die Kommunikation zwischen Applikation und der Datenbank entweder durch SQL-Befehle, sprich: Dialogbeschreibung, oder über eine Information im erweiterten Data-Dictionary.

- Der Benutzeroberflächen-Anschluß entlastet den Programmierer von der Ansteuerung des Ausgabeformats und gewährleistet die Unabhängigkeit von dem eingesetzten Window-System.

Ein Applikationsentwicklungs-Werkzeug, das grafische Bedienoberflächen unterstützt sollte daher auch die Funktionalität eines UIMS bereithalten (siehe Abbildung 2).

Betrachtet man die Anforderungen der Praxis seitens Endanwender und Entwickler sowie die unterschiedlichen Konzepte der Werkzeugklassen zur Erstellung von Anwendungen, läßt sich leicht der Schluß ziehen, daß integrierte, obiektorientierte Applikationsgeneratoren künftig in verstärktem Maße zum Einsatz kommen werden. Mit Hilfe dieser Tools lassen sich Anwendungen mit anspruchsvoller Benutzeroberfläche in relativ kurzer Zeit und unter Berücksichtigung der Akzeptanz der Endanwender erstellen

*Rolf Hauber ist Marketingleiter der Pisa GmbH, Berlin.