*Reinhold Thurner ist Technischer Direktor bei der Schweizerischen Delta Software Technologie AG in Schwerzenbach.

Die Zukunft gehört der dezentralen Datenverarbeitung. Der Weg weg von der reinen Großrechnerlandschaft führt, so Reinhold Thurner*, über die Software-Entwickler. Von ihnen hängt es ab. ob der PC als Entwicklungstool für Mainframe-Software dient oder ob die PC-Möglichkeiten zu neuen Entwicklungs-Strategien führen.

Engpässe in der Verarbeitung, zunehmende Wartezeiten am Bildschirm, ganze Abteilungen wegen des Ausfalles einer Hardware- oder Software-Komponente lahmgelegt - dies sind die Symptome einer zu weit getriebenen Zentralisierung unserer Informationsverarbeitung.

Bisher wurde jede Klage in dieser Richtung mit dem Hinweis auf den angekündigten nächstgrößeren Computer abgetan. Jeder Ausfall wurde als ein -durchaus vermeidbares -menschliches Versagen gedeutet, das bei entsprechend mehr Kontrolle zu vermeiden gewesen wäre:

Unsere Systeme sind - trotz oder wegen des Bemühens, sie vollständiger, sicherer und leistungsfähiger zu machen ù schlußendlich immer komplexer und schwerer zu kontrollieren. So beklagt der Technologie-Kritiker Joseph Weizenbaum, daß niemand sie mehr "ganz durchschauen" kann.

Großrechner-Aufgaben gehen auf den PC über

Wir leiden an einer Inflation der Komplexität. Wir müssen ihr begegnen durch Entflechtung, Strukturierung, Dezentralisierung.

Dies klingt einfacher als es ist: Schnittstellen müssen klar definiert werden, die Aufteilung der Aufgaben muß gefunden werden, die Transportwege müssen organisiert werden und das Problem der verteilten Speicherung muß gelöst werden - und das schwierigste von alllem, wir müssen in verteilten Strukturen denken lernen. Der Großrechner wird künftig mehr und mehr Aufgaben an Abteilungsrechner oder vernetzte Einplatzsysteme abgeben müssen. Hierbei bieten sich vier Auslagerungsstufen an (siehe Abbildung auf Seite 34).

Bildschirmmasken werden auf die Abteilungsstation ausgelagert. Lediglich die Message selbst wird an die Arbeitsstation übermittelt. Ein Tastatur- und Bildschirmserver übernimmt die Message, holt die dazu passende Maske und gibt die Daten aus. Die Maske ist entweder lokal im PC, auf einem Server-PC oder in einem Abteilungsrechner gespeichert. Damit wird ein extrem gutes und konsistentes Antwortzeitverhalten erreicht. Durch die Verlagerung des Dialog-Managers auf den PC kann zudem der Grad der Dienstleistung wesentlich verbessert werden.

Der Dialog-Manager benötigt in der Regel ein Paket lokaler Daten (Menü-Baum, suspendierte Dialoge, Struktur des Dialog-Ablaufs) die im Speicher gehalten werden müssen. Die Auslagerung dieser Daten in die Arbeitsstation führt zu einer Entlastung des Hauptrechners.

In einem weiteren Schritt wird die Verarbeitung der Arbeitsstation übergeben. Der Mainframe wird in diesem Fall zu einer Art Datenbank Rechner. Der View-Manager verbleibt im Mainframe und stellt der Anwendung die angeforderten Daten bereit.

Mit der Verlagerung auch der Daten selbst in die Arbeitsstation treten ganz neue Probleme auf. Die Arbeitsstation wird nun zwar zu einem autonomen Rechner, gleichzeitig nimmt aber ihre Belastung und die Notwendigkeit zur Koordination bei parallelen Updates gewaltig zu.

Der Einsatz eines Datenbank-Systems auf dem PC, die Steuerung einer verteilten Datenbank führt denn auch in der Regel zu erheblich größeren Arbeitsstationen und zu Engpässen in der Arbeitsstation selbst.

Die Frage der Datensicherheit bei solcher dezentralen Speicherung stellt ein weiteres schwer zu lösendes Problem dar.

Bei dieser Form der Verteilung der Aufgaben migriert die Software von einer einzelnen Maschine ins Netz. Dadurch entstehen hohe Ansprüche an die Entwicklung: Sie muß in der Lage sein, nicht mehr Software für eine ganz bestimmte Maschine zu entwickeln, sondern vielmehr Software zu entwickeln, die auf mehrere Systeme verteilt ist und deren Komponenten eventuell neu verteilt werden, wenn sich die Randbedingungen ändern.

Software-Entwickler sind heute in der Regel auf Maschinen spezialisiert. Die Entwickler kennen häufig die anderen Maschinen nur ungenügend, sodaß ihre Design-Entscheidungen in der Regel einen Einsatz einer anderen als der ihnen bekannten Maschine ausschließt.

Häufig kann man sogar bei Entwicklern, die ein weiteres System kennengelernt haben, immer noch die gleiche strukturelle Beurteilung feststellen: Außerdem wird ein neues System oft aus dem Blickwinkel des Altbekannten beurteilt. Ein PC wird wie ein privater Mainframe mit speziellen Eigenschaften gesehen (Preis, Response-Zeit, Verfügbarkeit). Aber man will weiterhin den gleichen Editor und vor allem alle Daten lokal zur Verfügung haben. So wird der PC zu einer Art privater Mainframe. Ein Mißverständnis, dem man am besten durch den Einsatz solcher Systeme in der Entwicklung begegnet.

Der PC-Einsatz verändert die Software-Entwicklung

Für die Verlagerung der Entwicklung auf verteilte Systeme gibt es heute zwei grundsätzliche Ansätze:

-Man verwendet anstelle des Mainframe einen PC und arbeitet im übrigen gleich weiter.

-Man führt neue Methoden und Werkzeuge ein; diese sind jedoch auf verteilten Maschinen wesentlich besser einsetzbar als auf dem Mainframe, das heißt man lagert die Entwicklung auf dedizierte Entwicklungsumgebungen aus.

Das erste Rezept scheint auf den ersten Blick sehr einfach: Man nehme einen PC (einen möglichst schnellen) und ein System, das den Mainframe auf dem PC emuliert (gleicher Editor, gleicher Compiler, gleiche Utilities für TP-Dienste und DB-Dienste) ù und schon geht die Entwicklung mit Subsecond-Response-Zeit viel schneller.

Das Arbeitsverhalten muß nicht geändert werden. CICS auf dem PC ist wie CICS auf dem Mainframe, nur viel einfacher. Auf den zweiten Blick muß man sich allerdings die Frage stellen, ob - bei allen unbestrittenen Vorteilen dieser Lösung - der Mikro-Mainframe-Approach nicht am Ziel vorbei geht, dem Ziel nämlich, verteilte Anwendungen entwickeln zu können und die Frist, bis sie eine Notwendigkeit werden, mit dezentralisierter Entwicklung zu nutzen.

Das zweite Rezept heißt CASE:

Dieses Schlagwort hat in den letzten Jahren im Bereich der Software-Entwicklung die 4. Generationssprachen aus den Schlagzeilen verdrängt - CASE - Computer Assisted Software Engineering.

Der 4GL-Guru James Martin meinte auf die Frage "Warum befassen Sie sich heute nur mehr mit CASE und nicht mehr mit 4GLs?", ganz lakonisch "Once I got very excited about vaccum tubes".

Die Rückkehr zu den Prinzipien des Software-Engineerings ist allenthalben festzustellen, nachdem die versprochene Wunderwaffe des " programming without programmers" zu einigen Rohrkrepierern geführt haben.

Beim CASE-Konzept werden dezentrale Systeme als Träger für eine neue Klasse von Werkzeugen und vor allem Werkzeug-Oberflächen benutzt, die auf Mainframes praktisch nicht implementierbar sind.

Diese Werkzeuge sind gekennzeichnet durch folgende Elemente:

Wysiwyg - direkte Darstellung der Ergebnisse;

Menüs - Auswahl von Funktionen und Daten;

Grafik - bessere Visualisierung der Entwicklungsergebnisse;

Prototyping - Simulation von Zwischenergebnissen;

Verwaltung - das System übernimmt die Funktion der Verwaltung der Komponenten in einer Entwicklungs-DB;

Bausteine - Erstellung von Bausteinen mit spezialisierten Werkzeugen und Integration der Bausteine zu Systemen;

Kommunikation - bessere Kommunikationsmittel mit dem Anwender, aber auch unter den Entwicklern selbst.

Angesichts des Einsatzes mehrerer unterschiedlicher Maschinen in der Anwendung stellt sich auch in der Entwicklung die Frage nach der besten Aufgabenteilung, die Frage nach der für die Entwicklung am besten geeigneten Umgebung.

Dies setzt allerdings voraus, daß man in der Lage ist, auf einem Entwicklungssystem für verschiedene unterschiedliche Zielsysteme Software zu entwickeln.

Der erste Schritt in dieser Richtung waren dedizierte Editier- und Textverwaltungsysteme für Dokumentation und Programme wie zum Beispiel PET/Maestro. Der nächste Schritt ist die Cross-Entwicklung und deren Einbettung in eine dedizierte Entwicklungsumgebung.

Cross-Entwicklung heißt: Man entwickelt auf einer dedizierten Umgebung unabhängig vom Zielsystem und erzeugt die Software nach Fertigstellung für das entsprechende Zielsystem.

Ein Beispiel mag das verdeutlichen: In der Spezifikation wird verlangt, ein Verwaltungsprogramm für ein vorgegebenes Paket an Daten bereitzustellen. Diese Spezifikation ist unabhängig vom Zielsystem.

Ein Prototyp einer Maske (oder mehrerer Masken) wird erstellt und ein simulierter Ablauf ohne Daten definiert. Auch dies ist (abgesehen von der Bildschirmgröße) vom Zielsystem unabhängig.

Dieser Prototyp kann weiter ausgebaut werden und letztlich in das Programm münden. Die Spezifikation wird also auf dem dezentralen System erarbeitet, ein Prototyp wird definiert und getestet und dann erfolgt die Generierung der Software für das Zielsystem.

Diesen Weg ist die GMO (Gesellschaft für moderne Organisations-Verfahren, Köln) gegangen. Sie entwickelte ein umfangreiches System (mehrere hundert Masken) für den Bund deutscher Ortskrankenkassen (BDI).

Die Generierung für das Zielsystem steht am Ende

Die Software wurde zunächst auf IBM unter CMS entwickelt und weitgehend getestet. Danach wurde sie (immer noch auf IBM/CMS) mit Hilfe eines Anwendungsentwicklungssystems für die Nixdorf-Systeme 8860 generiert, wo man auch die Schlußtest durchführte.

In einer weiteren Entwicklungsphase wurde die Software auf einen PC verlegt. Die Entwicklung wurde dort fortgesetzt - dann auf die Nixdorf 8860 überspielt - also das gleiche Vorgehen wie vorher auf dem PC.

Dieses Beispiel zeigt, daß Software für durchaus heterogene Systeme auf dem für die Entwicklung geeignetsten System entwickelt werden und dann auf die Zielmaschine verlagert werden können.

Auf die Frage, welches System nun für die Entwicklung am besten geeignet ist, gibt es heute noch keine von allen akzeptierte Antwort.

Die Standardlösung heute ist zweifellos noch der Einsatz von Mainframes für Mainframes - auch wenn Tools eingesetzt werden, die den Anwender nicht auf diese Struktur einschränken.

Als Tool-Umgebung ist Unix besonders geeignet

Die klassischen 4GLs ziehen den Mainframe, manchmal ergänzt um einen Frontend auf PCs, vor: Dies wird in der Regel darin begründet, daß sie nicht portabel sind und auch nur auf dem Mainframe zum Einsatz gelangen können. Lediglich Runtime-Systeme (lnterpreter der auf dem Mainframe erstellten Definitionen) sind für dezentrale Systeme zu finden.

Der Trend in Richtung Unix als nahezu ideale Infrastruktur für eine Werkzeug-Umgebung ist jedoch nicht zu übersehen. Eine solche Unix-Umgebung ist zum Beispiel die Nixdorf-Targon-Serie. Hier wird eine zentrale Unix-Maschine als Time-Sharing-Rechner eingesetzt. Die Entwickler arbeiten mit Terminals, die direkt an der Unix-Maschine angeschlossen sind.

Die High-End-Version des Einsatzes von Unix finden wir in Software-Systemen, die auf Rechnern wie Apollo, Vax-Stationen oder Sun beruhen: Hier muß allerdings mit Kosten pro Arbeitsplatz gerechnet werden, die in der Software-Entwicklung heute nur schwer akzeptiert werden.

Mit den PCs ist ein neuer Markt entstanden. Es gibt heute eine große Anzahl von Werkzeugen, die auf Einzel-PCs die Erstellung von Dokumentation und Programmen unterstützen. Eine grafische Oberfläche und die Möglichkeit, sich rasch einzuarbeiten, hat zu einer Akzeptanz solcher Werkzeuge geführt.

Bei größeren Entwicklungs-Vorhaben stößt man jedoch mit Einzel-PCs rasch an eine Grenze, die nur durch Vernetzung und ein Entwicklungs-Dictionary gelöst werden können. Dieses Dictionary übernimmt die Aufgabe der Entkopplung der Speicherung der Daten von der Verwendung und schafft damit die Voraussetzung für den kontrollierten Zugriff mehrerer Entwickler auf eine gemeinsame Entwicklungs-Infrastruktur.

Dieser Ansatz empfiehlt sich, weil ohne eine integrierte Unterstützung der Speicherung und Kontrolle der Nutzung (Charge-Out) schier unüberwindbare Probleme der Koordination und Sicherung auftreten, wenn eine größere Zahl von Entwicklern zusammen arbeitet.

Es besteht kein Zweifel darin, daß ein Transaktions-System eine ungeeignete Entwicklungs-Umgebung darstellt. Ein TP-Monitor dient primär der eingeschränkten und darum effizienten Steuerung von Anwendungen. Die Entwickler benötigen aber einen wesentlich direkteren Zugriff zu den Diensten des Systems.

Diesen direkten Zugriff erhalten sie durch ein Timesharing-System oder durch vernetzte Einplatz-Systeme. Die optimale Lösung wird aber auch hier stark durch die Randbedingungen der Umgebung bestimmt. Eine Kombination von PCs als Arbeitsstationen und einem Server (Unix oder ein anderes System) oder die Lösung der High-End-Workstations scheint auf lange Sicht am meisten zu versprechen.

4GL-Sprachen ersetzen keinen Software-Ingenieur

Hier wird allerdings noch sehr viel Entwicklung zu erwarten sein, und man liegt auch nicht falsch mit der Annahme, daß folgende Kriterien die Spreu vom Weizen trennen werden

- Das System muß kompatibel mit der Anwendungs-Architektur und der Basis-Software des Herstellers sein. Es gab früher bessere TP-Monitoren, DB-Systeme, Spooling-Systeme, Sorts etc. als die des Herstellers, sie sind dem längeren Atem des Herstellers zum Opfer gefallen, weil sie seinen strategischen Absichten im Weg waren.

- Portabilität gehört zu den strukturellen Eigenschaften eines Systems und kann kaum nachträglich aufgepfropft werden. Portabilität eines Entwicklungssystems sichert dem Anwender die Möglichkeit zur Wahl der geeignetsten Umgebung. Die Migration der Entwicklungsumgebung vom Mainframe ins Netz, in die Unix-Maschinen und PCs ist nicht aufzuhalten.

- Das System sollte ausbaufähig sein. Neue Ideen kommen laufend dazu und müssen von den Systemen absorbiert werden.

- Eine Orientierung am Software-Engineering scheint sinnvoller als an 4GLs.

Vor einigen Jahren machte sich eine gewisse Verdrossenheit mit der Technik breit. Dies fand zuerst seinen Niederschlag in der Politik und Wirtschaft mit alternativen Ansätzen zur Lösung unserer Probleme: Einfache Lösungen und die Rückkehr zur Natur waren die Devise. Davon blieb auch die Informatik nicht unberührt. Programmierung ohne Programmierer wurde ein attraktives Schlagwort, attraktiv vor allem für jene, die eine ohnmächtige Abhängigkeit von den Entwicklern empfanden.

Wir haben aus dieser Reaktion gelernt und die einseitige Technikorientierung zugunsten einer Benutzer-Orientierung abgebaut. Software Engineering aber, als pragmatischer ingenieurmäßiger Ansatz hat eher neue Aktualität erhalten.

Software-Entwicklungs-Konzepte müssen in der Lage sein, bestehende Software-Bestände zu integrieren: Sie müssen die Wartung unterstützen.

Software-Entwicklung muß in der Lage sein, die Nutzung von Standard-Software als Bestandteil aufzunehmen. Isolierte Entweder-oder-Lösungen werden als konzeptionelle Inseln verkümmern.

Aus dem Gesagten ergibt sich die Notwendigkeit, eine Strategie für verteilte Verarbeitung zu entwickeln. Verteilte Verarbeitung ist eine Chance zur Erhöhung der Sicherheit, Verbesserung der Dienstleistung und Reduktion der Komplexität. Voraussetzung dafür ist aber, daß die Anwendungen mit einer Struktur verteilter Verarbeitung kompatibel sind.

Die heutigen Anwendungen sind in der Regel noch nach den Konzepten monolithischer Anwendungsstrukturen geschrieben - große integrierte Pakete.

Die Voraussetzungen für einen kontrollierten Übergang zu verteilter Verarbeitung müssen erst geschaffen werden. Die technischen Voraussetzungen, die System-Software und die kommerziellen Voraussetzungen werden nicht mehr lange auf sich warten lassen oder sind zum Teil schon gegeben.

Die bisherige Anwendungssoftware wird zum großen Engpaß für die Realisierung dieses Konzepts werden - Assembler-Programme aus den 70er Jahren, monolithische TP-Transaktionen aus den 80er Jahren.

Ein Umdenken und intensive Ausbildung der Entwickler sind Voraussetzungen, um die Weichen stellen zu können. Dieses Umdenken ist über eine intensive Beschäftigung der Entwickler mit solchen Konzepten und insbesondere durch Teilauslagerung der Entwicklung auf Arbeitsplatzsysteme zu erreichen.

Entwickler benötigen in zunehmendem Maße hohe interaktive Leistung vom Rechner. Diese Leistung kann durch verteilte Systeme rationeller erbracht werden.

Der Einsatz verteilter Systeme in der Entwicklung ist deshalb sowohl aus langfristig strategischen als auch aus kurz- bis mittelfristig kostenbezogenen Überlegungen zu empfehlen.