Die Grundlinien der Software-Architektur wurden bisher von zwei Kardinalforderungen bestimmt. Erstens: Ausnützung der im Hardware-Umfeld vorhandenen "wertvollsten" Betriebsmittel; zweitens: Notwendigkeit einer gemeinsamen Datenbenützung bei bestimmten Anwendungen. In den letzten Jahren gesellte sich zu diesen Zielsetzungen noch die Forderung, eine geeignete Anwender-Schnittstelle in Form von Datenendgeräten bereitzustellen. Lange Zeit war die erste Forderung durch eine gemeinsame Benützung von Zentraleinheit und Speicher und die zweite durch eine gemeinsame Benützung des Speichers beeinflußt. Die dritte wurde in der Regel ignoriert.
In einer Welt kostengünstiger mikroprozessorgestützter Systeme hat die so schnell eingetretene enorme Verbesserung der Wirtschaftlichkeit den Wert des Menschen über die Kosten der Maschine gestellt Infolgedessen gibt es einen Wendepunkt in der Wirtschaftlichkeit des Rechnereinsatzes, der alle Software-Fragen durchdringt. Die Frage lautet nun, wie sich die Software-Architektur in einem Umfeld zahlreicher Anwender und der verteilten sowie interaktiven Datenverarbeitung ändern wird.
Déjá vu! - Alles schon mal dagewesen - könnte man sagen. Mit dem Mikroprozessor fühlen wir uns zurückversetzt in die Situation des Einzelbenutzers, der Einzelanwendung, des Einzelcomputermilieus, die für die Frühzeit der Datenverarbeitung kennzeichnend waren. Damals hatten viele Benutzer Zugang zum Computer, aber nur einer nach dem anderen. Der kostengünstige persönliche Computer von heute ist andererseits ein dediziertes Gerät, bei dem die gemeinsame Benützung der Betriebsmittel nicht von Belang ist und der sich selbst bei nur gelegentlicher Benützung bezahlt macht.
Mit dem Fortgang des Wettstreits zwischen Mikrocomputern und kleinen Minicomputern einerseits und zwischen den 8-Bit-Chips und seinen größeren 16-Bit- und 32-Bit-Vettern andererseits, naht auch prompt die Versuchung einer gemeinsamen Benützung der "wertvollsten" Betriebsmittel.
Wie baut man Mehrbenutzer-Systeme auf? Soll man preiswerte, stupide Terminals und leistungsfähige, im Teilnehmerbetrieb arbeitende Zentralprozessoren und Speicher nehmen (Shared Cluster Systems) oder intelligente, selbständige Terminals mit gelegentlichem Zugriff zu häufig gebrauchten Daten (Distributed Intelligence Systems)?
Beteiligung an den Betriebsmitteln
Da wir uns in einer Übergangsphase befinden, wird die Antwort noch nicht völlig eindeutig ausfallen. Einige sehr überzeugende Argumente und Vorteile geben aber doch dem einen Modell ein Übergewicht über das andere. Wir bewerten die Situation vom Standpunkt der Betriebsfähigkeit des Systems, der Wirtschaftlichkeit und den Anforderungen an die Software aus.
Das "Shared Cluster System´´ - ob es nun auf konventionellen Rechnern oder auf Minicomputern beruht - hat letztendlich betriebsmäßige Grenzen, entweder in der Leistung des Zentralprozessors oder in der Möglichkeit des gemeinsamen Zugriffs zu den Daten durch viele Benutzer. Zwingt man einem solchen System nun einen Teilnehmerbetrieb auf, geht das zu Lasten der Systemleistung. Was aber viel wichtiger ist: Das System wird bei seinem gegebenen monolithischen Aufbau im Zusammenhang mit bestimmten entscheidenden Komponenten, zu denen vor allem der Zentralprozessor gehört, im höchsten Grad anfällig. Außerdem können leicht Auseinandersetzungen um periphere Geräte, zum Beispiel Drucker, entstehen. Kaum zu erwähnen braucht man noch den Komfortfaktor; im Sinne der verteilten Verarbeitung ist an eine vollständige Endbenutzer-Kontrolle nicht zu denken. Andererseits bietet die volle Verteilung der Verarbeitungsleistung auf einen Mikrocomputer mit zugehöriger Peripherie eine optimale Leistung, ungehinderten Zugriff und eine jederzeitige und bequeme Verfügbarkeit der Druckausgabe.
Viele Argumente zugunsten "Clustered Systems" weisen auf scheinbar höhere Kosten für selbständige intelligente Terminals (verteilte Logik) im Vergleich mit zentralisierten Multiterminal-Konfigurationen im Teilnehmerbetrieb hin. Ansichten dieser Art sind aber schon überholt oder werden es in Kürze sein. Bei den sehr niedrigen Kosten der in Massenproduktion hergestellten Chips und Boards erübrigt sich eigentlich die Frage des "Sharing" bei der Elektronik. Was hat es beispielsweise für einen Sinn, wenn Benutzer sich einen 16-Bit-Prozessorchip für 100 Dollar teilen, wenn dieser in zwei Jahren wahrscheinlich nur noch 10 Dollar kosten wird?
Die Kosten der Hardware bewegen sich rasch in Richtung auf die materiellen Komponenten, zum Beispiel der Verkleidungsteile, der Grundplatte und des Tastatur-Gehäuses - nicht mehr so sehr in Richtung auf die Elektronik-Komponenten.
Der Grad der Terminal-Intelligenz sollte deshalb bei der Entscheidung über eine angemessene gesamte Hardware-Topologie oder -Architektur nicht mehr der ausschlaggebende Faktor sein. Tatsächlich können die völlig dezentralisierten und verteilten auf Mikrocomputern beruhenden Systeme von heute jederzeit dem Preis nach mit Cluster-Konfigurationen auf Minicomputer-Basis konkurrieren. Berücksichtigt man dann noch die weiteren Elemente der Zuverlässigkeit, der individuellen Kontrolle und des Bedienungskomforts, dann fällt der Vergleich überwältigend zugunsten des dedizierten Tischrechners aus.
Diese Lösung erfüllt natürlich keinesfalls die Bedingung der gemeinsamen Datenbenutzung im Anwendungsumfeld vieler Benutzer. Erreicht wird das aber durch die Möglichkeit lokaler Netze dieser intelligenten Terminals - entweder durch eine Ringleitungs-Improvisation oder durch eine vergleichbare Ethernet-artige Übertragungseinrichtung. Die gemeinsame Datenbenützung wird somit über einen wechselseitigen Zugriff zu Festkopf-Plattenspeichern erzielt, die dadurch tatsächlich den Hardwarekosten und der Anfälligkeit von System-Komponenten nach zum "wertvollsten" Betriebsmittel der Grundforderung werden.
Der Kern der Sache
Das führt uns nun zum Kern der Streitfrage und unseres Interesses: zur Software.
Wir sind ernsthaft davon überzeugt, daß sich die Anwendungs-Software sehr rasch in Richtung auf eine zweifache Betriebsart zubewegt. Diese gibt die Dualität der Datenverarbeitung wieder, die im Umfeld von Datenstation und größerem Rechner möglich ist. Ein Teil dieser Software wird durch eine Datenstation mit Mikroprozessor ausgeführt, die übrige Verarbeitung ist Sache eines größeren Rechners. Dateneingabe, interaktiver Dialog, Abfrage und bestimmte Verarbeitungsvorgänge erfolgen im wesentlichen selbständig an der Datenstation.
Die Übertragung von Anforderungen und Daten findet zwischen der Datenstation .und dem zentralen Rechner statt, auch bestimmte Verarbeitungsvorgänge werden zwangsläufig von diesem Rechner unterstützt. Dasselbe gilt für die Speicherung und Fortschreibung großer Datenbanken. Wir betrachten das Ganze als ein lose gekoppeltes, verteiltes Verbundnetz von Datenstationen und größeren Rechnern.
Die Software für so moderne Hardware-Systeme muß deshalb im Zusammenhang des unabhängigen Betriebs von Mikrocomputern und als Anhängsel der Software gesehen werden, die zentral arbeitet. Im ersteren Fall ist die Software für die unabhängige, lokale Betriebsart strukturiert, im zweiten muß sie sich an ein fremdes System anschließen, von dem sie ein Teil ist. Beide Gesichtspunkte haben einen erheblichen Einfluß auf den zukünftigen Software-Entwurf für derartige Verbundsysteme.
Erstens besteht für die Software an der Datenstation ein gemeinsames und einfaches Umfeld. Die für einen einzelnen Tischrechner entworfene Software bedarf, wenn überhaupt, weniger Sicherheitsmaßnahmen und im wesentlichen keiner betrieblichen Prioritätsplanung. Die physische und Vorrangsteuerung ist an den Ein-/Aus-Schalter gebunden und die Datensteuerung wird ermöglicht durch eine portable Diskette oder ein Kennwort für die Übertragung. Das Betriebssystem arbeitet mit Einzelkanal oder hat höchstens eine Spooling-Einrichtung. Es gibt keinen TP-Monitor und keine Notwendigkeit eines Reentrant-Codes. Unnötig ist außerdem die Betriebsmittel-Terminierung, wie es beim Job-Management erforderlich ist. Selbst die Job-Abrechnung ist unnötig geworden - zumindest sofern sie die Datenerfassung zur späteren Rückbelastung oder dergleichen betrifft. Die Betriebsmittel sind zu einer Art von "Wegwerf-Artikeln" geworden, die Hardware zu einem Einrichtungsstück.
Die Kommunikation für Eingabe und Ausgabe ist lokalisiert und kann für bestimmte Geräte getuned oder sogar mikrocodiert werden. Alles in allem wurde das Software-Umfeld der Datenstation beziehungsweise des Arbeitsplatzes beträchtlich vereinfacht.
Neues Umfeld - neue Anforderungen
Das neue Umfeld stellt aber auch neue Anforderungen. Die Ausrichtung auf den Anwender und dessen Bedienungskomfort erlangen allergrößte Bedeutung. Nicht nur muß der Bildschirm beim interaktiven Arbeiten auf die sich entwickelnden Erfahrungen und den Background des Anwenders eingehen, er muß sich diesen auch anpassen. Häufige Systembenutzer wollen nämlich im Laufe der Zeit in die Lage kommen, die Dialoge mit dem System dynamisch umzudirigieren, indem sie - wenn die Vorgehensweise bekannt oder oftmals wiederholt wird - Standardverfahren abkürzen. Somit wird ein anwenderdefiniertes, bildschirmorientiertes "Makro" eine notwendige Funktion.
Andere wünschenswerte Einrichtungen sind die Benutzerführung und die Help-Funktion. Dasselbe gilt für die vom Benutzer einzuleitende und durchzuführende Software- und Hardware-Diagnostik. Dies allerdings verlangt einige Neuerungen in der Software-Wartung.
Eine andere Einwirkung auf die Software-Entwicklung und -Architektur besteht in der Entkopplung einiger Betriebsfunktionen vom Zentralrechner und deren Übertragung an die Datenstation. Die Anwendungs-Software muß der Funktion nach in Vordergrund- und Hintergrund-Sektionen getrennt werden, die rationell an der Datenstation und am lose gekoppelten Zentralrechner ausgeführt werden.
Diese Forderung ist aber keineswegs ein nebensächlicher Trick. Mit ihr stellt sich nämlich sofort das vertraute Entscheidungsproblem, welche Daten im lokalen Speicher der Datenstation zu führen sind und wie diese Daten mit der zentralen Datenbank koordiniert werden sollen. Noch komplizierter wird das Problem durch die Notwendigkeit, mit den Daten im Gleichschritt zu bleiben, die von den anderen Datenstationen des Bereichs verwendet werden. Diese Entscheidungen des Systementwurfs hängen mit dem Grad der lokalen Aufbereitung und Prüfung zusammen, der für die Dateneingabe-Funktionen vorgesehen ist, und mit der Unabhängigkeit, die man der Datenstation im Falle von Abfrage- und Berichtsoperationen gewähren kann.
Kein Patentrezept
Natürlich gibt es dafür kein Patentrezept. Das Problem muß für jede Anwendung neu gelöst werden.
Es bedarf kaum der Erwähnung, daß der Grundentwurf diese identifizierten Funktionen enthalten soll und daß sich das System entsprechend umschalten lassen muß, um entweder mit den lokalen Daten zu arbeiten oder um Daten in den zentralisierten Dateien zu suchen.
Die letzte Forderung, die an diese neue Software zu richten ist, besteht in der Bereitstellung einer Implementierungs-Unterstützung für die Benutzer von Datenstationen,. wenn diese Ad-hoc-Probleme zu lösen haben, wie sie von Zeit zu Zeit auftreten. Während es sich bei solchen Funktionen gewöhnlich um das übliche Information Retrieval oder das Berichtswesen handelt, besteht auch ein Bedarf an spezifischeren, anwendungsorientierten Problemlösungen. Dazu braucht man aber einen Satz von Software-Hilfen, die entsprechend aufgebaut sind und sich für die verschiedenen Anwenderklassen eignen - vom erfahrenen Programmierer bis hin zum gelegentlichen Endbenutzer.
Gerade diese Forderung stellt für alle in der Software-Entwicklung tätigen Spezialisten die Herausforderung dieses Jahrzehnts dar.