In dem Maße, wie die Idee der dezentralen Software-Entwicklung um sich greift, gewinnen auch die Unix-basierten Entwicklungsumgebungen an Marktrelevanz. Jürgen Hertel* stellt die Sprachen der vierten Generation und die Programmgeneratoren den sogenannten "integrierten Systemen" gegenüber.

Hersteller, Software- und Systemhäuser sowie Endanwender blicken erwartungsvoll und gebannt auf das Geschehen in dem Markt der Unix-Systeme. OSF, Unix International, X/Open und eine wachsende Zahl von Benutzerorganisationen beweisen, daß es hier inzwischen um handfeste Interessen geht. Dieser Markt bietet erstmalig die Chance zu einer "Generalüberholung" der gesamten Anwendungssoftware für Mehrplatzsysteme, um die Möglichkeiten der modernen Hardware-Architekturen zu nutzen und den technischen Fortschritt im Software-Engineering umsetzen zu können.

Im Jahre 1992 wird mehr als jedes dritte Multiusersystem mit dem Betriebssystem Unix ausgestattet sein. Befand sich bis 1986 die Entwicklung eher noch im Pionierstadium, so haben sich in den letzten beiden Jahren auch die sogenannte öffentliche Hand und der Markt der kommerziellen Informationsverarbeitung dem Betriebssystem zugewendet. Einige Länder wie beispielsweise Nordrhein-Westfalen haben sogar Grundsatzentscheidungen in dieser Richtung getroffen. Diese Entwicklung wird von Tendenzen begleitet, die den technischen Wandel und das heute Machbare widerspiegeln, zum Beispiel:

-- die Ablösung von herstellerspezifischen MDT-Systemen durch offene Systeme,

-- die Einführung spezialisierter Rechnersysteme auf Abteilungsebene zwischen Groß-DV und Personal Computern,

- der Umstieg von "privaten" ISAM Strukturen auf wesentlich flexiblere relationale Datenbanken,

- die Integration von typischen PC-Funktionen wie Text, Spreadsheet und Grafik mit datenbankgestützter Informationsverarbeitung unter Unix und

- die Ablösung dummer" ASCII- Terminals durch "intelligente" Workstations mit anspruchsvoller Benutzeroberfläche.

Diesem systemtechnischen Wandel stehen Anforderungen der Anwender hinsichtlich der zugehörigen

Anwendungssoftware gegenüber:

Heutzutage hat sich die Software möglichst flexibel an die gewachsene Organisation und die Arbeitsabläufe

im Unternehmen anzupassen. Die so entstandene oder gegebenenfalls gekaufte Lösung muß durch das eigene Personal erweiterbar und pflegbar sein. Vor allem aber verlangen die Anwender, daß ihre Software-Investition durch problemlose Übertragung auf andere Unix-Systeme zukunftssicher ist. Solche Anforderungen des Marktes sind zugleich eine Herausforderung für die Hersteller von Software-Entwicklungstools für die nächsten fünf bis zehn Jahre.

Betrachten wir die Entwicklung von Programmiersprachen und den dazugehörigen Tools, so ist festzustellen, daß die Hochsprachen der dritten Generation seit mehr als 20 Jahren die Softwarelandschaft nachhaltig geprägt haben. Standardisierung sowie ausgefeilte Case-Methoden und -Tools haben eine Situation geschaffen, die nur noch wenig Spielraum für Rationalisierung bietet.

Der Aufwand für die laufende Softwarepflege läßt den "Backlog" weiterhin ansteigen, und die Möglichkeit einer nachhaltigen "Modernisierung" der Software ist ohne grundsätzliche Veränderungen so gut wie ausgeschlossen. Dieses Dilemma, in dem sich heute viele Firmen, Behörden und Verwaltungen weltweit befinden, kann nach Ansicht vieler Experten nur durch einen radikalen Schnitt, durch einen Generationenwechsel in Methoden und Entwicklungstools gelöst werden.

War der Ansatz der dritten Generation noch auf weitgehende Universalität hinsichtlich des Einsatzes einer Sprache gerichtet, so liegt den Entwicklungstools der vierten Generation eher der Gedanke von Anwendungsklassen oder Applikationsmodellen zugrunde. Solche Modelle sind zum Beispiel:

- CAD (interaktive Grafik),

- Prozeßsimulation (spezielle mathematische Methoden),

- Management-Entscheidungsunterstützung integrierte Datenbankabfrage, Kalkulation, Präsentationsgrafik),

- Verfahrens-Entscheidungsunterstützung sowie

- dialog- und transaktionsorientierte Informationsverarbeitung (Datenbank-Transaktionen, Maskenwerkzeuge, Daten- und Ausfallsicherheit).

Die einzelne Anwendung muß überwiegend den Charakter eines bestimmten Modells haben, um die Vorteile von Spezialwerkzeugen, die für dieses Modell geschaffen wurden, optimal nutzen zu können. Ähnlich wie bei einer Werkzeugmaschine gilt es, die für das Modell typischen, immer wiederkehrenden Funktionen und Arbeitsschritte zu automatisieren und den Entwickler von Routinearbeiten und der Erzeugung von Trivialcode zu befreien. Daß bei diesem Automatisierungsprozeß trotzdem die funktionale Flexibilität und die Einbindung in organisch gewachsene DV-Umgebungen erhalten bleiben müssen, versteht sich von selbst.

Für die Klasse der dialog- und transaktionsorientierten Informationsverarbeitung liegen die Möglichkeiten solcher Spezialwerkzeuge vor allem darin, daß die Nachteile von 3GLs wie Basic, Cobol oder PL/1 systematisch behoben wurden. Solche Nachteile sind zum Beispiel:

- umständliche Dialogverarbeitung,

- nicht integrierte Oberflächentools,

- keine Trennung zwischen logischer und physikalischer Datensicht,

- ineffiziente Schnittstellen zu Datenbanken,

- keine Implementierung des Transaktionsbegriffs,

- geringe Unterstützung des Engineering-Prozesses, insbesondere keine Unterstützung von Prototyping, sowie

- aufwendige und kostenintensive Softwarepflege.

Der Einsatz von 4G-Spezialwerkzeugen bietet dagegen erhebliche Chancen und wirtschaftliche Reserven, so daß schon deswegen mit Recht von einer neuen Generation gesprochen werden kann.

Jede dialog- und transaktionsorientierte Anwendung benötigt zunächst eine logische Datenstruktur, deren Implementierung heute fast ausschließlich in Form einer relationalen Datenbank mit Tabellen, Feldern, Attributen, Domains und zugehörigen Zugriffsmechanismen besteht. Mit maskengestützten Schema-Editoren oder über die DDL-Funktionen von SQL läßt sich ein Datenschema erstellen.

Die für die Datenmodellierung und zur Unterstützung des Normalisierungsprozesses erforderlichen Designwerkzeuge sind heute meist nur auf PCs oder auf grafikfähigen Workstations verfügbar und lassen sich selten direkt und bidirektional in ein normalisiertes Datenbankschema umsetzen. Das so erzeugte Data-Dictionary ist das Herzstück des gesamten Systems, indem es neben seiner zentralen Funktion als logische Datenbank - je nach Implementierung - zusätzlich globale Eigenschaften der Datensicherheit und Datenintegrität wie Typ-, Werte- und Bereichsprüfungen, Zugriffsrechte und Triggerfunktionen gewährleistet.

Generatoren und 4GLs arbeiten grundverschieden

Die Systemsicht des Anwenders erfolgt über die Benutzeroberfläche, die - auch bei "dummen" ASCII-Terminals - nach den Erfordernissen moderner Software-Ergonomie gestaltet sein sollte. Dazu gehören neben überlappenden Maskenfenstern die Gestaltung von Feldern und Prompts mit Beschreibungs- und Darstellungsattributen, eine Steuerung über im Kontext belegbare Funktionstasten sowie einblendbare Statusinformationen. Weiterhin gehören dazu ein Standard-Transaktionsmechanismus sowie überblendbare System- und Benutzerhilfen in Window-Technik.

Die im klassischen 3GL-Sinne wichtigste Komponente besteht aus den eigentlichen Programmstrukturen, die folgende Funktionen erfüllen:

( I ) Dialogfluß- und Transaktionssteuerung,

(2) dialogorientierte, maskengestützte Eingabe, Selektion und Ausgabe von Daten einschließlich aller dazugehörigen Prüfungen und Fehlerbehandlungen,

(3} prozedurale Selektion und Manipulation von Daten, deren algorithmische Verknüpfung, die Implementierung spezieller Funktionen und die Kommunikation mit anderen Programmen und Prozessen sowie

(4) die Steuerung von Hintergrund-Batchfunktionen.

Während (1) und (2) systemnahe Funktionen darstellen, definieren (3) und (4) die eigentliche Anwendung. Es liegt deshalb nahe, bei (1) und 42) anzusetzen, entweder über mächtige Sprachkonstrukte oder durch automatisch generierte Systemprozeduren den Entwickler weitestgehend von der Behandlung dieses Komplexes zu befreien. Diesen Ansatz wählen die meisten sogenannten Sprachen der vierten Generation.

Grundsätzlich sind Design, Entwurf und Implementierung von Softwaresystemen mit reinen 4GLs sehr ähnlich denen mit Sprachen der dritten Generation. Die 4GLs verfügen im allgemeinen nicht über generierbare Systemprozeduren, sondern behandeln auch die oben genannten systemnahen Funktionen (1) und (2) direkt aus der Sprache heraus. Der Effektivitätsgewinn wird hier überwiegend durch eine kompaktere Syntax, durch Verwendung von ESQL sowie zahlreicher Bibliotheksfunktionen erzielt.

Die Kompilierung erfolgt meist zweistufig über einen p-Code (zum Beispiel "C ") zu einem ausführbaren Programm. Dadurch sind diese Programme in der Regel schnell in der

Ausführung, es sei denn, die Abarbeitung der ESQL erfolgt interpretativ. Der Kompilier- und Bindevorgang ist dagegen relativ zeitaufwendig; ein interaktiver und interpretativer Source-Code-Debugger oder andere Testhilfen sind also unbedingt erforderlich.

Diametral entgegengesetzt zum 4GL-Ansatz ist der Generator-Ansatz. Hier wiederum gibt es keine eigentliche prozedurale 4GL. Die Entwicklung stützt sich vorwiegend auf einen komfortablen Maskengenerator mit Maskenflußsteuerung. An dessen Grundstrukturen werden kompilierbare, im allgemeinen nur beschränkt strukturierbare Funktionen "angehängt". Mit Hilfe dieser Funktionen kann dann im allgemeinen interpretativ, entweder über ESQL oder spezielle Schnittstellenfunktionen beispielsweise auf CISAM oder andere Dateistrukturen zugegriffen werden.

Die Merkmale und die Vorteile beider vorgenannten Ansätze vereinigt ,der integrierte Ansatz, eine Art Synthese aus Generator und 4GL. Hierbei steht die Idee im Vordergrund alle für die Entwicklung benötigten Strukturen und Elemente in einem Integrierten Data-Dictionary abzulegen, so daß alle mitgelieferten Tools wie Oberflächen-Generator Language-Editor, Compiler, Linker und Runtime-Monitor sowohl zur Entwicklungszeit als auch zur Laufzeit darauf zugreifen können und Informationen daraus beziehen können. Die Implementierung dieses Ansatzes ist somit weitaus komplexer als die beiden vorgenannten, bietet dafür aber konzeptionell ein hohes Maß an Flexibilität und Erweiterbarkeit.

Die Anwendung bestimmt die Auswahl der Methode

Jede der drei genannten Vorgehensweisen hat ihre spezifischen Vor- und Nachteile in puncto Offenheit der Entwicklungsumgebung, Prototyping, Entwicklungsgeschwindigkeit, Code-Umfang, Laufzeitverhalten, Fehlerfreiheit der Lösung, Pflegearbeit sowie Ergonomie der Benutzerführung. Je nach Anwendung wird die Gewichtung der einzelnen Kriterien unterschiedlich ausfallen. Allgemein gilt jedoch, daß der Erfüllungsgrad der genannten Kriterien in der aufgeführten Reihenfolge als ein Maß für die Qualität eines Entwicklungssystems der vierten Generation angesehen wird.

Eine reine 4GL ist immer dann zu bevorzugen, wenn bereits ein "Top-down"-Design (zum Beispiel für eine Cobol-Implementierung) vorliegt und die interaktive Dialogverarbeitung gegenüber prozeduralen Funktionen und batchartigen Abläufen eine untergeordnete Rolle spielt. Nachteilig ist jedoch, daß die gesamte Ablaufsteuerung aus dem 4GL-Programm heraus erfolgt, was typischerweise einen großen Programmumfang (Anzahl Programmzeilen) zur Folge hat.

Generatoren kommen vorwiegend dort zum Einsatz, wo der Benutzerdialog in Form von Query by Forms (QBF) auf die Datenbank im Vordergrund steht und auf komplexe logische, funktionale und prozedurale Strukturen "im Hintergrund" verzichtet werden kann. Hier wird die Einfachheit der Programmerzeugung und die damit verbundene Fehlerfreiheit der generierten Software bewußt mit Einschränkungen in bezug auf Offenheit und Verfeinerung der Lösung erkauft.

Integrierte Systeme vereinigen grundsätzlich die Stärken von Generatoren und 4GLs und beheben damit gleichzeitig deren Schwächen. Je nach Art der Anwendung werden zwischen 50 Prozent und 90 Prozent der Gesamtfunktionalität generativ ohne einen einzigen Programmbefehl realisiert. Dazu gehören die Definition von Masken und Fenstern sowie von Maskenfeldern und allen zugehörigen Attributen, die Erzeugung von automatischen Zugriffen auf die Datenbank, die Festlegung des Maskenflusses (Ablaufsteuerung), der Beginn beziehungsweise die Fortsetzung von Transaktionen bei Maskenwechsel sowie last but not least die Einbindung von Bedienerhinweisen und Hilfefenstern.

In diesem Fall erfüllt die 4GL eine grundsätzlich andere Funktion als im reinen Sprachansatz: sie ermöglicht ein "Programming by Exception", das heißt, sie dient zur Abrundung und Verfeinerung der generierten Rohversion (Prototyp). Dabei ist es von großer Bedeutung, daß die globalen Voreinstellungen des Generators (default definitions) jederzeit lokal durch die 4GL-Sprache aufgehoben oder ersetzt werden können. Nur so ist die volle Flexibilität - vergleichbar einem prozeduralen 3GL oder 4GL-Programm - erreichbar. Der erforderliche Umfang an Programmcode ist in der Regel geringer.

Während der reine Sprachansatz keinerlei Vorteile für das Prototyping bringt, eröffnen der Generator und der integrierte Ansatz dazu weitgehende Möglichkeiten. Dies vor allem deshalb, weil die Entwicklungsumgebung gleichzeitig alle Tools für die weitere Bearbeitung und Verfeinerung von Prototypen bereitstellt. Ob man nun die Anzahl oder Struktur von Tabellen, Feldern und Masken, die Details des Maskenaufbaus oder die prozeduralen Strukturen erweitern möchte, alle Änderungen sind ohne grundsätzliches Redesign machbar. Dies ist wohl die augenfälligste und gleichzeitig wirtschaftlich bedeutendste Eigenschaft von 4G-Systemen.

Anwender nehmen Einfluß auf die Programmerstellung

Ein nicht zu unterschätzender Nutzen des Prototyping ist die Möglichkeit, die Anwender in die Design-Phase einzubinden. Die Benutzer werden in Zukunft stärkeres Gewicht auf eine systematische Unterstützung des Prototyping als geschlossene Implementierungsmethode legen.

Die traditionelle Anwendungsentwicklung mit Sprachen der dritten Generation läuft dem natürlichen Denkprozeß eines Entwicklers eigentlich entgegen. Eine Anwendung wird in Programme zerlegt, diese wiederum in Funktionen, Unterprogramme und einzelne Anweisungen. Das Ergebnis wird erst ganz zum Schluß nach mehrfach interaktiven Kompilier-, Link- und Testläufen sichtbar. Sprachen der vierten Generation beschleunigen zwar diesen Prozeß, aber im Grundsatz erzeugen sie keine neue Qualität, sondern nur weniger und kompakteren Code.

Integrierte Entwicklungssysteme der vierten Generation unter Unix gehen hier völlig neue Wege: Ein relationales DBMS, ein WYSIWYG-Oberflächengenerator und eine aktionsorientierte 4GL sowie die dazugehörigen Tools - Compiler, Linker und Runtime-Monitor - arbeiten sämtlich auf der Basis eines integrierten Data-Dictionary und bilden dadurch eine Einheit. Der Entwicklungsprozeß läuft in folgenden Schritten ab:

1) Design des semantischen Datenmodells und Umsetzung auf relationale Strukturen (im allgemeinen nicht Bestandteil der 4GL);

(2) Erstellen des Datenbankschemas einschließlich eines aktiven Data-Dictionary;

(3) maskengeführtes und durch ein Online-Hilfesystem unterstütztes Definieren oder Generieren der gesamten Benutzeroberfläche einschließlich Bedienerschnittstelle über Funktionstasten;

(4) Ergänzen von anwendungsspezifischen Strukturen durch eine aktionsorientierte, überwiegend nichtprozedurale 4GL;

(5) Compilieren, Binden und Ausführen der gesamten Anwendung in einem Schritt.

Flexibilität führt zu Einbußen bei der Leistung

Dieser letzte Vorgang sollte so gestaltet sein, daß bei jedem Iterationsschritt der Erweiterung beziehungsweise Verfeinerung des Prototyps jeweils nur die Änderungen behandelt werden. Auf diese Weise kann die "turnaround "-Zeit selbst bei großen und komplexen Anwendungen im Bereich von wenigen Minuten liegen, wodurch ein aufwendiges und zeitraubendes Debugging weitestgehend entfällt.

Um die Flexibilität moderner Entwicklungswerkzeuge nutzen zu können, muß man in der Regel immer Konzessionen hinsichtlich der Performance machen. Die Hauptursache dafür liegt meistens in der Datenbank-Architektur. Die wesentlichen Eigenschaften, auf die deshalb bei der Datenbankauswahl in Zusammenhang mit 4G-Werzeugen zu achten ist, sind Performance (zum Beispiel über Zugriffsoptimierung), Daten- und referentielle Integrität sowie ein ausgeprägtes Sicherheits- und Transaktionskonzept.

Der ideale Generator unterstützt eine extrem visuelle Arbeitsweise: Es lassen sich Anwendermasken am Bildschirm zeichnen - genauso wie sie später in der fertigen Anwendung erscheinen. Danach werden die Maskencharakteristika und Feldattribute, der Maskenfluß und der Transaktionsstatus mit Hilfe von Spezifikationsfenstern im Kontext" definiert. Nach Ausblenden des Spezifikationsfensters wird das Ergebnis sofort sichtbar.

ESQL-Befehle sollten selbsterklärend sein

Der Generator leistet zwar den größten Teil der Arbeit, aber er hat natürliche Grenzen. Mit der komplementären 4GL läßt sich deshalb der bis dahin generierte Teil einer Anwendung verfeinern und ergänzen ("Programming by Exception").

Während reine 4GL-Produkte eine Menge prozeduraler Befehle selbst für einfache Aufgaben erfordern bieten aktionsorientierte 4GLs extensive, nichtprozedurale Möglichkeiten, können aber mit prozeduralen Strukturen und ESQL-Befehlen kombiniert werden. Eine natürlichsprachliche Syntax ist dabei nicht nur wegen der einfachen Erlernbarkeit von Bedeutung, sondern entspricht auch gleichzeitig den heutigen Anforderungen nach "Selbstdokumentation".

Die Sprache baut sinnvollerweise auf den generierten Masken und Feldern unter Verwendung von Sektionen (BEFORE FORM, AFTER FIELD) unter Verwendung von Befehlen (DISPLAY, SELECT) sowie Attributen und Funktionen auf. Mit Hilfe eines Trigger-Funktionen-Konzepts reagiert das 4GL-Programm spontan auf eine Vielzahl von Ereignissen (actions, events}.

Hervorzuheben ist, daß 4G-Systeme bei richtigem Design entgegen aller landläufigen Meinung vergleichbar gute Laufzeiteigenschaften aufweisen können. Alle I/O-Anforderungen sollten zum Beispiel direkt aus der 4GL heraus kompilierbare DB-Zugriffsroutinen aufrufen.

Eine erfolgsentscheidende Eigenschaft für 4G-Entwicklungssysteme ist ihre Offenheit gegenüber bestehenden oder entstehenden Industriestandards. Betrachtet man eine vollständige Entwicklungsumgebung in Form eines vereinfachten Schichtenmodells, so lassen sich vier Ebenen separieren: die Datenbank-Schicht, die Applikationsschicht, die Kommunikationsschicht und die Präsentationsschicht.

Da sich im Bereich der ersten Schicht mit dem ANSI-SQL/ESQL Standard eine normierte Schnittstelle zu Datenbanken anbietet, wird ein für Software- und Systemhäuser interessantes Entwicklungssystem auch Datenbanken anderer Hersteller unterstützen können. Ein kritischer Faktor ist dabei jedoch stets das Performance-Verhalten, da interne, meist nicht offengelegte oder dokumentierte Schnittstellen für die zeitkritische Interaktion mit der RDBMS-Schicht geeigneter sind als ESQL.

Unix-Systeme eignen sich zunehmend für Datenbanken

In ähnlicher Weise konkurrieren zur Zeit in der Präsentationsschicht einige herausragende Industriestandards, zum Beispiel MS-Windows (Microsoft), X/Windows, Open Look und OSF/Motif. Solange sich hier noch kein System als "der Standard" herausgebildet hat, muß ein Toolhersteller notgedrungen alle genannten Präsentationsschichten unterstützen.

Die aufgezeigten Methoden und Werkzeuge der Software-Entwicklung für die Klasse der dialog- und transaktionsorientierten Anwendungen auf Unix-Systemen eröffnen ein ungeahntes Potential für die "Erneuerung" eines großen Teils der existierenden Softwareprodukte und -lösungen. Die technischen und kommerziellen Chancen, die sich dabei mit 4G-Tools insbesondere für Software- und Systemhäuser auftun, sind vielfältig und erfolgversprechend.

Mit dem erkennbaren technischen Fortschritt bei Unix-Systemen als "Datenbank-Engine" und mit der zunehmenden Verbreitung grafikfähiger Benutzeroberflächen, verbunden mit dem Trend, Unix-Systeme in lokale und überregionale Netzwerke einzubinden, werden auch die Anforderungen an 4G-Entwicklungssysteme steigen. Die Chancen des sich öffnenden Unix-Marktes sind hier für die Software-lndustrie Anreiz und Ansporn zugleich.

*Dr. Jürgen Hertel ist Geschäftsführer der Unify GmbH in Baldham bei München.