Die Anwendungsentwicklung wird künftig immer stärker von neuen Disziplinen der SW-Technik geprägt sein, Im Mittelpunkt stehen dabei das Computer Aided Software Engineering (CASE), Repositorien. verteilte Datenverarbeitung und die Verknüpfung von DBMS-Umgebungen mit Expertensystemen. Maßgeblich für die Aktivitäten im Bereich der Datenbank-Management-Systeme bleibt auch weiterhin das relationale Modell. Ausgehend von der zeitlichen Abfolge der Softwaregenerationen und der historischen Entwicklung skizziert George Schussel* das SW-Szenarlo der 90er Jahre.
Die erste Softwaregeneration ist charakterisiert durch die in den 50er Jahren vorherrschende DV-Umgebung: Damals waren Computer nur eingeschränkt verfügbar; in der Anwendungsentwicklung kamen fast ausschließlich Maschinensprachen zum Einsatz. Einen ersten Fortschritt repräsentierte dann die Einführung der Assemblersprachen, die zusammen mit anspruchsvoller I/O-Software und den Möglichkeiten der Dateiverwaltung kennzeichnend für die zweite SW-Generation waren. Diese Ära dauerte grob geschätzt von den späten 50ern bis in die frühen und mittleren 60er Jahre.
Etwa zu diesem Zeitpunkt erblickten dann Cobol und Fortran das Licht der Welt und wurden auch schon bis zu einem gewissen Grad standardisiert. Dementsprechend ist die Entwicklung von Applikationen in diesen Sprachen charakteristisch für die SW-Szene der dritten Generation. In den 70er Jahren kamen dann wichtige Hilfswerkzeuge zur Anwendungsentwicklung auf den Markt, beispielsweise TP-Monitore und Datenbank-Management-Systeme .
Zu Beginn der jetzigen Dekade war dann die Zeit für die Sprachen der vierten Generation gekommen. Diese Entwicklung ist eng verknüpft mit dem Aufstieg der relationalen Datenbank-Management-Systeme, der Sprachen der vierten Generation und der Decision-Support-Systeme.
Stellte Cobol für die Anwendungsentwicklung der dritten Generation weitgehend einen Standard dar, so ist die vierte Generation geprägt durch eine Vielzahl eigentumsrechtlich geschützter Sprachen. Sowohl Hardware- als auch Softwarehersteller fanden hier ein breites Betätigungsfeld.
Um eine moderne Form der Anwendungsentwicklung sicherzustellen, reicht es jedoch nicht aus, einfach Sprachen der vierten Generation und relationale Datenbanken zu verwenden. Die Frage, wer mit den Informationen arbeitet, ist vielmehr ebenso entscheidend wie die technischen Aspekte der Software selbst. In diesem Zusammenhang kann die "Entdeckung" der Enduser-orientierten Datenverarbeitung als eines der wichtigsten Merkmale der vierten Generation gelten. Serviceleistungen, die auf diesen Abnehmerkreis zielen, lassen sich über Informationszentren auf Mainframe-Basis oder durch PCs bereitstellen, die mit Tabellenkalkulationsprogrammen, Datenbank und Textverarbeitungssoftware ausgerüstet sind.
Relationales Datenmodell übernimmt Vorherrschaft
Das relationale Datenmodell wird in der Branche vielfach als signifikante Verbesserung gegenüber den DBMS-Ansätzen der dritten Generation gefeiert. Hersteller, die ihre Systeme zunächst dem Codasyl-Ansatz entsprechend oder gemäß einer Netzwerk- oder hierarchisch strukturierten Topologie aufbauten, erweitern ihre Produkte zunehmend um relationale Fähigkeiten. Die relationale Sicht der Daten übernimmt somit die Vorherrschaft in der vierten Generation und wird ohne Zweifel auch künftig das maßgebliche Datenbankmodell sein.
Gelegentlich ist bereits von "postrelationalen" DBMS-Konzepten die Rede. Für die absehbare Zukunft scheint es jedoch unwahrscheinlich, daß ein solcher Ansatz tatsächlich Realität werden konnte. Denn das relationale Modell bietet eine logische Sicht der Daten - und erlaubt somit eine unbegrenzte Zahl physischer Implementierungen, Weitere Vorteile bieten der exakte mathematische Unterbau dieses Konzepts sowie die Übernahme des ANSI-Standards für die Abfragesprache SQL. Daß eine andere logische Sicht der Daten im Bereich der kommerziellen DV eine derart breite Akzeptanz finden wird, läßt sich für die nächsten zehn Jahre nicht absehen.
Eine Schwäche des relationalen Modells liegt allerdings in seiner eingeschränkten Fähigkeit, Sinnzusammenhänge in gleicher Weise darzustellen wie es Netzwerk-orientierte Datensichten vermögen. Folglich ist damit zu rechnen, daß verschiedene "semantische Modelle" als Erweiterungen des relationalen Konzepts entstehen und auch Akzeptanz im Markt finden werden. Die Fähigkeit, mehr Sinnzusammenhänge in der Datenbankstruktur einzubinden, kann signifikante zusätzliche Einsparungen auf der Programmierebene und eine übergeordnete Kontrolle der Datenverwaltung bedeuten.
Hersteller trimmen Systeme auf Transaktionsfähigkeit
Da die DV immer stärker zu einem unternehmerisch entscheidenden Faktor wird, gewinnen transaktionsorientierte Anwendungen zunehmend an Bedeutung. In dieser Domäne der Netzwerk-orientierten Strukturen haben sich DBMS-Produkte mit relationalem Aufbau aufgrund ihres Overhead bislang nur wenig behaupten können. Der Einsatz dieser Systeme für komplexe Anwendungen, die 20 bis 200 oder mehr Transaktionen pro Sekunde generieren, muß als fragwürdig gelten.
Mehrere neue Datenbank-Management-Systeme zielen nunmehr genau auf diesen Markt. Die Hersteller behaupten, verteilte Verarbeitungsfähigkeiten und ein wesentlich höheres Potential bei der Transaktionsverarbeitung zu bieten. Auch die Produzenten etablierter relationaler Produkte wie Oracle, Ingres und Informix sind bemüht, die Transaktionsfähigkeit ihrer Systeme um durchschnittlich 30 Prozent jährlich zu steigern.
IBM läßt DB-Rechner auch künftig außen vor
Entscheidende Impulse für die Transaktionsverarbeitung in komplexen relationalen Umgebungen lassen sich von seiten der Datenbankmaschinen erwarten. Zwei wichtige Hersteller, die sich in diesem Bereich engagieren, sind Teradata und Britton Lee. IBM wird sich in diesem Feld aller Voraussicht nach nicht betätigen.
Der Grund für diese "Zurückhaltung" des Marktführers ist wohl kaum im technischen Bereich zu suchen; ausschlaggebend dürfte vielmehr eine geschäftspolitische Motivation sein: Der Durchbruch der PCs auf breiter Basis hat dazu geführt, daß viele Funktionen des Mainframe auf die preisgünstigeren kleinen Maschinen übertragen wurden. Von der Architektur her könnte man sagen, daß sich die Mainframes zu Datenbankmaschinen und Netzwerkservern weiterentwickeln. Das Konzept einer Datenbankmaschine ß la Teradata oder Britton Lee ist darauf ausgelegt, den DB-Zugang und die Kontrolle über die Datenbank vom Mainframe auf einen Mikrocomputer herunterzuladen, der über Fähigkeiten der Parallelverarbeitung verfügt. Ist nun das Handling der Benutzerschnittstelle Sache des PC und wird der DB-Zugriff über Backend-Maschinen geregelt, so stellt sich die Frage, was eigentlich für den Mainframe übrigbleibt. Die Antwort lautet natürlich: "Nichts". Und das ist der Hauptgrund, warum IBM kein Interesse daran hat, die Weiterentwicklung der Datenbankmaschinen zu fördern.
Codasyl-Ansatz findet nur geringe Akzeptanz
Eine Schlüsselposition in der DBMS-Diskussion haben die Abfragesprachen. Ehe SQL die Bühne betrat, gab es hier keinen Standard. Am nächsten kamen solch einer genormten Guideline die verschiedenen Implementierungen von "Codasyl DBTQ". Aber auch 1982, als die Marktdurchdringung der Sprachen auf Codasyl-Basis ihren Höhepunkt erlebte, machten die entsprechenden Produkte maximal 15 Prozent der weltweit installierten DBMS-Software auf Minicomputern und Mainframes aus.
Bei SQL sieht das Bild völlig anders aus. Die Query Language wurde von IBM in den späten 70er Jahren entwickelt. Big Blue legte seine beiden strategischen DBMS-Produkte, DB2 und SQL/DS, auf der Grundlage von dieser Query Language an. Das American National Standards Institute (ANSI) und die International Standards Organization (ISO) haben SQL zur Standardabfragesprache für relationale DBMS-Produkte erklärt. Und das US-Verteidigungsministerium macht SQL inzwischen bei der Vergabe von Regierungsaufträgen zum festen Bestandteil der Ausschreibungsbedingungen .
Hersteller relationaler Systeme, die nicht SQL bieten, versuchen dieses Manko schnellstmöglich auszugleichen. Auch viele nicht-relationale Anbieter haben angekündigt, daß sie SQL unterstützen wollen. All diese Faktoren sprechen dafür, daß SQL in den 90er Jahren die Standardsprache für Manipulation, Definition und Kontrolle von Daten sein wird. Daraus wiederum ergeben sich entscheidende Vorteile bei der Softwareentwicklung, vor allem ein hohes Maß an Portabilität.
Nachteile von SQL treten stärker ans Tageslicht
Die künftige Rolle von SQL wird aber auch dazu führen, daß die Nachteile dieser Sprache einen höheren Bekanntheitsgrad erlangen: SQL ist als Sprache für den Enduser nicht geeignet, sondern eignet sich fast ausschließlich für Programmierer.
In amerikanischen Expertenkreisen wird der Umgang mit SQL vielfach in Analogie zum Schachspiel gesetzt. Alle grundlegenden Bewegungen, so heißt es, könnten in einer halben Stunde erlernt werden. Es erfordere jedoch lebenslange Übung, um über die Anfangsschritte hinauszukommen.
Generatoren fassen zunehmend Fuß im Markt
Daher kann man davon ausgehen, daß SQL-Generatoren zunehmend an Bedeutung gewinnen. Wird es nämlich überflüssig, die einzelnen Statements "zu Fuß" zu erstellen, sind viele Barrieren für den Benutzer von vornherein aus dem Weg geräumt. Er braucht dann nicht auf die ihm vertrauten Schnittstellen zu verzichten und kann Anwendungen erzeugen, die von einer Datenbankmaschine zur anderen portierbar sind. In den nächsten Jahren dürfte die Hauptbedeutung von SQL darin liegen, als Standardsprache die Kommunikation zwischen verschiedenen Softwaresystemen zu unterstützen. In dieser Funktion wird SQL dann letztlich bedeutender sein als für die Interaktion zwischen Mensch und Maschine.
Nächster logischer Schritt in dieser Entwicklung ist dann die Entscheidung für die verteilte Datenverarbeitung: Viele marktführende Organisationen werden in den 90er Jahren einen dreigleisigen Rechnereinsatz fahren. Dieses Konzept basiert auf der Idee, die DV-Arbeitslast auf mehrere Maschinen zu verteilen. Workstations übernehmen die Verarbeitung von individuellen oder gruppenbezogenen Daten am Arbeitsplatz; Minicomputer sind für die Aktivitäten auf Abteilungsebene zuständig und die Mainframes schließlich verwalten DB-Anwendungen, die von mehreren Abteilungen oder Unternehmen benötigt werden.
Eine solche Vorgehensweise bringt für den Anwender enorme wirtschaftliche Vorteile. Denn die Verarbeitungskosten auf einer Workstation betragen nur etwa ein Zehntel dessen, was für die Ausführung der Applikation auf einem Minicomputer zu veranschlagen ist. Ähnlich sieht es aus, wenn man die Kosten der Verarbeitung auf dem Mini in Relation zum Mainframe setzt.
Schaden bei Systemausfall wird in Grenzen gehalten
Diese Verteilung der Arbeitslast wirkt sich auch im Falle eines System-Crash positiv aus: Versagen in einem Verbund ein bis zwei Rechner, so bedeutet dies lediglich den Ausfall von etwa zehn Prozent der verfügbaren Ressourcen. Sind aber alle Aktivitäten an einem einzigen Mainframe aufgehängt, so wirkt es sich für alle Benutzer fatal aus, wenn die Maschine in die Knie geht. Allerdings wird sich dieser dreigleisige Verarbeitungsansatz nur zögernd in der Praxis durchsetzen, falls sich die Programmierung in einer solchen Umgebung als schwierig erweist.
Zwei Software-technische Ansätze wollen hier Abhilfe schaffen: die verteilten Datenbanken und Systeme, die eine kooperative Verarbeitung unterstützen. Die Idee der Distributed Data Base besteht darin, eine einzige logische Datenbank über diverse Maschinen zu verteilen. Erste Lösungen in diesem Bereich haben inzwischen Hersteller wie Oracle, Relational Technology International und ADR auf den Markt gebracht. Weitere Anbieter dürften in den kommenden Jahren mit eigenen Produkten nachziehen.
Systeme, die eine kooperative Verarbeitung unterstützen, sind beispielsweise PC/SQL-Link von Micro-Design Ware aus Boulder/Colorado oder Super-Link von Multisoft aus Edison/New Jersey. Diese Systeme stellen eine Alternative zum Einsatz verteilter Datenbanken dar. Sie bieten 4GL-Anwendungsentwicklung auf einer Workstation, die mit einem aktiven Data-Dictionary auf einem zentralen Minicomputer oder Mainframe gekoppelt ist. Die Stärke des Dictionary liegt darin, daß wiederbenutzbare Funktionen in das System eingebaut werden können und daß die Logik seiner Architektur sowohl Entwicklung als auch Ausführung auf verteilter Basis gestattet.
Sechs Betriebssysteme können sich behaupten
Im Betriebssystembereich ist damit zu rechnen, daß sich in den frühen 90er Jahren sechs Umgebungen herauskristallisieren, die aufgrund ihrer weiten Verbreitung als Standard gelten können. Für die IBM-Welt sind dies MVS und VM, DEC ist mit VMS vertreten. Hinzu kommen die AT&T-eigene Unix-Version sowie für die kleineren Maschinen MS-DOS von Microsoft und OS/2, eine Koproduktion von IBM und Microsoft. Die gebräuchlichen Softwaretools werden für all diese Betriebssystemumgebungen erhältlich sein. Mit anderen Worten: Noch bis zum Beginn der nächsten Dekade müssen die im Markt etablierten SW-Produkte auf eine Vielzahl von Betriebssystemen und Schnittstellen ausgelegt sein.
Weitere wichtige Impulse für die SW-Entwicklung sind durch das Computer Aided Software Engineering (CASE) zu erwarten. Diese Disziplin steht noch ganz am Anfang ihres Lebenszyklus und weist gewisse Analogien zu der Bedeutung von CAD/CAM für das Ingenieurwesen auf. Ein CASE-Produkt kann man sich am leichtesten als grafisches Design-Werkzeug vorstellen, das auf einer Workstation läuft, von der aus Zugriffsmöglichkeit auf das Repository und den eigentlichen Code-Generator besteht. Üblicherweise sind das Repository und der Code-Generator auf einem Mini oder Mainframe installiert.
Analytiker machen künftig Programmierer überflüssig
CASE-Umgebungen werden normalerweise von Analytikern und nicht von Programmierern erstellt. Dabei erfolgt die Definition der Anwendung auf der Workstation-Ebene. Datendefinitionen und Verarbeitungslogik werden im Repository abgelegt. Ist die Dialogsitzung zur Definition der Anwendung abgeschlossen, generiert das Softwaresystem den Code.
In den nächsten Jahren werden viele Unternehmen mit der CASE-Technik experimentieren. Schon zu Beginn der 90er Jahre könnte dies für die DV-Realität bedeuten, daß der Systemanalytiker komplette Anwendungen erstellt und es keinen Bedarf mehr für Applikationsprogrammierer gibt. Eine Schlüsselposition im Rahmen des CASE-Konzepts kommt den Repositorien und Dictionaries zu. Das Repository ist eine aktive Kontrollumgebung, nicht nur einfach ein passiver Speicher für Informationen. Es läßt sich mit anderen Systemen integrieren, beispielsweise mit DBMS-Produkten, Query-Sprachen und TP-Monitoren.
Der Aufbau eines Repository ähnelt dem eines integrierten Data-Dictionary, wie es in den 80er Jahren gebräuchlich wurde. Im Repository sind jedoch nicht nur Informationen über Daten gespeichert, sondern auch Eckwerte zu Bildschirmmasken, Reports und Verarbeitungsfunktionen. Dadurch, daß diese Informationen im Dictionary abgelegt sind und nicht im Programm, lassen sie sich leichter wiederverwenden; und dies führt zu einer gesteigerten Produktivität.
Natürlich ist es nicht besonders sinnvoll, ein CASE-System mit Repository nur für die Erstellung von einigen wenigen Anwendungen einzusetzen. Ihre wirkliche Power können diese Produkte nur entfalten, wenn alle Applikationen in einem Unternehmen auf dieser Basis aufbauen und die Benutzer mit dieser Technik wirklich vertraut sind. Allerdings hat die Erfahrung gelehrt, daß erhebliche Investitionen in Mitarbeiterschulung erforderlich sind, bevor das CASE-Konzept dem Anwender echte Vorteile bringen kann.
Ein weiteres Schlagwort der modernen DV-Technik ist die Künstliche Intelligenz. Bis heute ist nur wenig von dieser Disziplin in die Welt der kommerziellen Systeme eingedrungen. Expertensysteme haben jedoch die beste Aussicht, dieses Bild zu ändern. Expertensysteme sind regelbasierte Programmierumgebungen, die mit einem Schlußfolgerungsmechanismus zusammenarbeiten. Kann menschliches Expertenwissen in einem begrenzten Bereich in logische Regeln gefaßt werden, ist das Konzept des Expertensystems der beste Weg, solche Entscheidungsfunktionen zu automatisieren.
In den 90er Jahren wird die regelbasierte Programmierung zum State-of-the-Art der kommerziellen DV-Welt gehören. Expertensysteme dürften zu diesem Zeitpunkt für den Anwendungsentwickler eine ähnliche Rolle spielen wie Datenbank-Management-Systeme, TP-Monitore und Reportgeneratoren.
Expertensysteme laufen auf konventioneller Hardware
Der Einsatz von Expertensystemen, die über Forward- und Backward-Chaining-Fähigkeiten verfügen, nimmt sehr viel HW-Ressourcen in Anspruch. So weist beispielsweise eine neuere in den USA erstellte Studie durchschnittliche Kosten von 260 000 Dollar für die Entwicklung von Expertensystemen aus. Eine wesentlich preisgünstigere Alternative ist es, die SW-Erstellung auch in diesem Bereich auf Maschinen durchzuführen, die auf den Mikroprozessoren 68030 von Motorola oder dem 80386 basieren. Teure, spezialisierte KI-Prozessoren dürften deshalb aller Voraussicht nach schon bald nur noch in Ausnahmefällen benötigt werden. Der technische Fortschritt im Bereich der Workstations wird also ziemlich sicher dazu führen, daß sich Expertensysteme zunehmend kostengünstiger realisieren lassen.
KI-Welt und traditionelle Systeme wachsen zusammen
Allerdings lassen sich der Engpaß an Know-how-Trägern und die mangelhaften Ausbildungsmöglichkeiten nicht von heute auf morgen beseitigen, und so wird die Entwicklung von Expertensystemen wohl nach wie vor relativ teuer bleiben. Aber auch hier zeichnet sich ein Lichtstreif am Horizont ab, da immer mehr Hochschulabsolventen schon während des Studiums mit KI-basierten Systemen konfrontiert werden.
Es kann als gesicherte Annahme gelten, daß die Verknüpfung von Expertensystemen mit konventionellen Produkten aus dem DBMS-, 4GL- und CASE-Bereich stark an Bedeutung gewinnt. Zu Beginn der nächsten Dekade wird die Möglichkeit, regelbasierte Systeme zusammen mit konventionellen SW-Produkten einzusetzen, bereits zur Realität des DV-Alltags gehören.