COESFELD - Der Mikrocomputer ließ den Funken überspringen: Schlagworte wie Software-Ergonomie, "Personal Computing", Künstliche Intelligenz, auch Local Area Network und integrierte Software lassen den Trend zu integrierten Systemen in der Informations- und Datenverarbeitung erkennen. Fast zwangsläufig resultiert daraus der Wunsch nach der einfachen, schnellen und sicheren Problemlösung. Hier das Modell dazu.

Voraussetzung für den Einsatz eines jeden informationsverarbeitenden Systems ist zweifellos die Hardware. Hierunter sollen alle Kategorien von Rechnertypen verstanden werden, einschließlich Peripherie sowie Vorrichtungen zur Telekommunikation. Die Spannweite der Rechnersysteme reicht dabei von den Heimcomputern und Arbeitsplatzrechnern über Anlagen der sogenannten mittleren Datentechnik bis hin zu Minicomputern und Mainframes. Dabei spielen Begriffe wie Rechenleistung, Verfügbarkeit, Mehrbenutzerbetrieb, verteilte Systeme (lokale Netzwerke, weltweite Netzwerke), Mikroprogrammierung etc. eine wichtige Rolle.

Wer heute über Computer spricht, denkt in erster Linie an das Von-Neumann-Rechner-Konzept. Im Zeichen der "5th Generation Computer Systems" (FGCS) erlangen neuartige Rechnerarchitekturen einen wichtigen Stellenwert. Ergebnisse aus der Very Large Scale Integration (VLSI)-Forschung ermutigen den Entwurf von Rechnern, die der Begrenzung der Rechenleistung wegen der physikalischen Grenze der Lichtgeschwindigkeit durch möglichst hohe Parallelität beikommen wollen.

Um auf der Ebene der Hardware die Voraussetzungen für die Integration und Vereinheitlichung zu schaffen, müssen zunächst einmal "äußerliche" Dinge auf einen Nenner gebracht werden. Dazu gehören grafikfähige Bildschirme, normierte, an das jeweilige Land angepaßte Tastaturen, Permanentspeichermedien wie Diskettenlaufwerke, Magnetbandeinheiten und Festplattenspeicher, sowie in Zukunft sicherlich optische Speicher. Für das "Innere" eines universellen Rechners ist die Forderung angebracht, daß er einen möglichst universellen Instruktionssatz besitzen soll. Vielfach kommt man dem nach, indem einfach mehrere verschiedene Mikroprozessoren in einen Rechner eingebaut werden, oder indem Instruktionssätze verschiedener Rechner auf der Ebene der Mikroprogrammierung emuliert werden, wie Tracy Kidder in "The Soul of a New Machine" beschreibt. Die Unabhängigkeit von diesen "äußeren" und "inneren" Dingen soll als Rechnerunabhängigkeit bezeichnet werden.

Die Vielfalt an Prozessoren und Rechnerhardware in der Klasse der Von-Neumann-Rechner schafft zunächst einmal ein ziemlich banal anmutendes Problem. Wie kann man die Rechnerleistung dem Anwender nutzbar machen? Und wenn das gelöst ist, kann man dann verhindern, daß sich die Anwender bei Wechsel auf ein anderes Rechnersystem erst umgewöhnen müssen? Diese Frage muß man sich natürlich bei allen Systemebenen stellen. Zudem müssen die Systemressourcen verwaltet und zugeteilt werden. Der konsequente Schritt in der Evolution der Rechner war die Entwicklung der Betriebssysteme.

In den Anfängen, hauptsächlich mit der Aufgabe der Bereitstellung von Systemdiensten wie Speicherplatzverwaltung oder Peripheriemanagement beauftragt, kristallisieren sich die Betriebssysteme immer mehr als eigenständige Systemschicht heraus, deren Hauptfunktion es nun ist, diese Dienste möglichst geräteunabhängig an den Benutzer weiterzugeben. Das bedeutet, der Benutzer kann die Befehle - etwa "Inhaltsverzeichnis eines Datenträgers listen" - auf verschiedenen Rechnern unterschiedlicher Größe mit den gleichen Kommandos aufrufen. Oft sind allerdings die Grenzen zwischen Betriebssystemen und Hardware bereits verwischt. Bestimmte Funktionen werden bereits in die Hardware, so Mikroprogramme, Basic-Interpreter im ROM oder auch vertikale Migration, mit eingebaut. Beispiele finden sich bei Karl-Heinz Hauer und Claus Seeger in "Hardware für Software". Sie stehen damit nach dem Einschalten des Rechners sofort zur Verfügung. Obwohl man noch strikt zwischen Großrechner und Kleinrechner-Betriebssystemen unterscheiden muß, sind zumindest in der jeweiligen Klasse die verschiedenen Betriebssysteme für die meisten Prozessortypen verfügbar wie DOS, UCSD-p, CP/M, MS-DOS, Unix, Oasis, MVS, VM oder BS2000.

Ein interessantes Problem stellte außerdem in der frühen Phase der Evolution der Rechnersysteme das sogenannte bootstrapping dar. Douglas R. Hofstadter bringt in "Gödel, Escher, Bach: An Eternal Golden Braid" eine exzellente Beschreibung dieses "Zum-Laufen-Bringens" von Betriebssystemen und Programmiersprachen auf dem nackten Rechner. Wenn man eine gewisse Stufe erreicht hat, so kann man Werkzeuge, die man sich selbst mühsam - im Fachjargon: zu Fuß - gebastelt hat, benutzen, um eben diese Werkzeuge zu verbessern. Wichtiges Beispiel aus dem Bereich der Programmiersprachen ist die Selbstkompilierbarkeit von Compilern. Oder es gibt Betriebssysteme, die in Programmiersprachen entwickelt werden, die wiederum unter diesen Betriebssystemen laufen wie C und Unix. Um eine möglichst hohe Rechnerunabhängigkeit zu erreichen, versucht man, den maschinenabhängigen Teil des Betriebssystems auf ein Minimum zu kondensieren (Smalltalk, p-Maschine). Damit ist eine Adaption auf ein neues Rechnersystem relativ schnell durchzuführen. Diese Art von Maschinenunabhängigkeit soll als Firmwareunabhängigkeit bezeichnet werden, da vielfach Betriebssystemfunktionen fest verdrahtet sind.

Kontrovers und mit Emotionen beladen wird darüber diskutiert, welches die geeignetste Programmiersprache beziehungsweise Programmiermethode ist. Sicherlich hängt das von der Problemstellung ab und von der zugrunde liegenden Rechnerarchitektur. Ebenso spielt die Leistungsfähigkeit unter dem Aspekt Geschwindigkeit eine große Rolle. Eine Grobeinteilung soll zunächst nach Programmiermethoden erfolgen (Abbildung 2).

Als Programmiersprachen, die dem Konzept des Von-Neumann-Rechners am ehesten Rechnung tragen, sind etwa Assembler, Basic, Fortran, Cobol, PL/ 1, Pascal, ADA zu nennen. Die Klassen der funktionalen und logischen Programmiersprachen, Repräsentanten sind Lisp, APL und Daplex sowie Prolog, können am besten durch Rechner bedient werden, die die Möglichkeit der Parallelverarbeitung bieten. Einen gänzlich anderen Programmierstil repräsentiert wiederum die Klasse der objektorientierten Programmiersprachen mit Simula, Smalltalk, Clascal etc., die als zugrunde liegende Konzepte Objekte und Nachrichten zwischen ihnen anbietet. Grundsätzlich kann man davon ausgehen, daß jedes Problem, welches innerhalb einer dieser Sprachklassen formulierbar ist, auch in jeder anderen Klasse ausgedrückt werden kann. Neben diesen universellen Programmiersprachen gibt es eine Reihe von dedizierten Programmiersprachen, die für spezielle Anwendungsgebiete entwickelt worden sind wie Textverarbeitung, CAD/CAM, Prozeßdatenverarbeitung sowie Entscheidungstabellen. Die sogenannten höheren Programmiersprachen schaffen eine weitgehende Unabhängigkeit von dem benutzten Rechnersystem, nicht vom Rechnertyp wie Von-Neumann etc. Oft kommt sogar noch eine Unabhängigkeit vom Betriebssystem dazu. Mit dem UCSD-p Pascal Compiler kann man beispielsweise Programme erzeugen, die sowohl unter dem Betriebssystem MS-DOS als auch unter Unix laufen. Eine Programmiersprachen-Unabhängigkeit läßt sich natürlich nicht nur dann erreichen, wenn die Charakteristika der verschiedenen Sprachklassen zu einer Superklasse vereinigt werden, die alle Programmierstile beinhaltet. Dies läßt sich wahrscheinlich nur in Form eines Meta-Interpreters realisieren, der in der Lage ist, Programme in verschiedensten Programmiersprachen ablaufen zu lassen und dessen Funktions- und Sprachvorrat durch Programmbausteine aus allen Sprachen dynamisch erweitert werden kann. Ein erster Ansatz in diese Richtung wurde mit dem Programmentwicklungssystem B-Gen-A unternommen. Näheres dazu findet sich bei Hermann Bense und Armin B. Cremers in "B-GEN-A Generalized Application Development System". Dort werden die Programmbausteine, die in Pascal erstellt wurden, einem ebenfalls in Pascal geschriebenen Hochsprachen-Interpreter zur Verfügung gestellt, dessen Sprachvorrat über eine Methodenbankkomponente erweitert werden kann. Als Sprachen, deren Sprachvorrat ebenfalls durch den Benutzer erweitert werden kann, sind auch Smalltalk, Lisp, Prolog, Forth und Elan bekannt.

Nimmt man nun Betriebssysteme und Programmiersprachen zusammen, bilden sie die Basis für die Entwicklung der Anwendungssysteme.

Anwendungssysteme ist die Klasse von Programmen, mit der der sogenannte Endbenutzer direkten Kontakt hat. Dabei sollte der Nutzer keine Kenntnisse der darunterliegenden Schichten besitzen müssen. Bei den Endbenutzern unterscheidet man allerdings nach dem Wissensstand eine Vielfalt von Typen. Das Spektrum reicht vom naiven, gelegentlichen Benutzer wie Schreibkräfte oder Datentypistin bis hin zum Anwendungsexperten, der sogar in der Lage ist, Anwendungssysteme wie dBase als Werkzeuge zur Erstellung neuer Problemlösungen zu nutzen. Viele Anwendungssysteme bieten zu diesem Zweck eigene Sprach- und Definitionsmittel an. Zu diesen teilweise als "Very-high-level-languages" eingestuften Anwendungsgeneratoren - Material dazu bieten Ellis Horowitz, Alfons Kemper und Balaji Narasimhan in "An Analysis of Application Generators" - können etwa Datenbanksysteme mit ihren Datendefinitions- und Manipulationssprachen gezählt werden. Ebenso stellen die praktisch gleich zeitig mit den Arbeitsplatzcomputern aufgekommenen Tabellenkalkulationsprogramme - Spreadsheets sind Visicalc, Multiplan, Lotus 1-2-3 - solche Werkzeuge dar.

Die komfortablen Menü-, Fenster- und Mausbedienungstechniken - etwa Xerox-Star, Lisa, Macintosh, jetzt mehr und mehr im Kommen - trugen einmal zur Verbreitung aller Arten von Anwendungssystemen bei.

In Abbildung 3 wird versucht, die wesentlichen Komponenten eines Anwendungssystems herauszukristallisieren. Der Mensch-Maschine-Dialog findet über die Benutzerschnittstelle statt. Hierüber werden sowohl Dateneingabe und -abfrage als auch die Steuerung der Anwendungen vorgenommen. Die zweite Schnittstelle eines Anwendungssystems ist die Kommunikationsschnittstelle. Sie ist für den Austausch von Daten und Informationen mit anderen Anwendungssystemen zuständig. Dies kann von Datentransfer innerhalb eines lokalen Netzwerkes bis hin zur weltweiten Kommunikation über Satelliten reichen. Die Kernaufgabe eines jeden informationsverarbeitenden Anwendungssystems ist die Manipulation, Abfrage und Archivierung von Daten. In der Regel verwendet jedes der Anwendungssysteme dazu seine eigenen Datenstrukturen und Speicherungsmethoden. Ebenso uneinheitlich werden Programmiersprachen und -werkzeuge zur Lösung von Problemen in den verschiedenen Anwendungsbereichen eingesetzt. Häufig werden für einzelne Anwendungsbereiche spezielle Programmiermethoden entwickelt, zum Beispiel Prolog für den Bereich der Expertensysteme und Sequel bei den Datenbanksystemen. Schließlich gibt es noch eine Komponente in Anwendungssystemen, die Aspekte wie Datensicherheit, Datenschutz, Datenintegrität oder auch Mehrbenutzerproblematik abdeckt, nämlich die Verwaltungs- und Überwachungskomponente. Ein Anwendungssystem kann also als Summe der Funktionen seiner Komponenten definiert werden. Spätestens an der Benutzerschnittstelle der Anwendungssysteme sollte eine totale Unabhängigkeit von Programmiermethode und -sprache erreicht sein. In Anlehnung an die Bezeichnungsweise in Datenbanksystemen soll diese Unabhängigkeit der Anwendungssysteme als Datenunabhängigkeit bezeichnet werden. Die meisten Anwendungssysteme sind aber von vornherein gar nicht auf dieses Ziel hin ausgerichtet. Eine Integration auf der Ebene der Anwendungssysteme ist wahrscheinlich nur durch Vereinheitlichung der Datenstrukturen und Zusammenfassen der Programmiermethoden, etwa in Form des schon erwähnten "Very-high-level"-Interpreters, möglich.

Will man also die Vorteile und Fähigkeiten der verschiedenen Anwendungssysteme kombinieren, so muß man eine Ebene höher zu den integrierten Systemen gehen. Gerade in jüngster Zeit gibt es eine Vielzahl von Ansätzen, die dem Endbenutzer die Konzepte mehrerer Anwendungssysteme als ein Programmpaket nutzbar machen. Beispiele sind Open Access, Framework, Lisa-Office-System, Macintosh-Deskop oder Microsoft-Windows. Die Vorzüge dieser integrierten Anwendungen bestehen hauptsächlich darin, daß Daten aus einem Programm mühelos und ohne konzeptionelle Schwierigkeiten in ein anderes übernommen werden können. So kann aus einer Datei einer Datenbank eine Tabelle zu Kalkulationszwecken erstellt werden. Die Ergebnisse der Kalkulation können als Grafik dargestellt und in einen Bericht eingefügt werden.

Je nach Ausgangsbasis ergeben sich dann automatisch Stärken dieser integrierten Systeme in den entsprechenden Bereichen. Als ganz starke Stützpfeiler haben sich hier die Tabellenkalkulationsprogramme und die Datenbanksysteme hervorgetan. Vielfach werden diese ergänzt um Grafik- und Textanschlüsse. Weniger häufig sind Kombinationen mit Anwendungen aus den Bereichen Information Retrieval, Netzplantechnik, Statistik, Wissens- und Integritätsbanken anzutreffen. Jedoch würde gerade der Anschluß dieser komplementären Gebiete an die besser beherrschten Bereiche eine ideale Abrundung zu einem wirklich allumfassenden System darstellen.

Da auf der Ebene der integrierten Systeme alles in sich selbst beziehungsweise mit sich selbst definiert ist, ist es eigentlich müßig, eine Schnittstelle zur nächsthöheren Ebene zu definieren. Der Vollständigkeit halber soll diese fiktive Schnittstelle mit Systemunabhängigkeit" bezeichnet werden. Das bedeutet nichts anderes als: Wenn ein System mit einem solchen Integritätsgrad zur Verfügung steht, kann im Prinzip alles das gemacht werden, was mit einer beliebigen Hardware und einem beliebigen Anwendungssystem realisiert ist.

Die Ansätze zur Integration bewegen sich um die Fragestellung, wie man zu einem integrierten Gesamtsystem kommt, in dem die Leistungen aller Anwendungssysteme gleichberechtigt und effizient unter Geschwindigkeits- und Speicherplatzgesichtspunkten angeboten werden. Hier ergeben sich von vornherein zwei Möglichkeiten, die man verfolgen könnte und die bereits in Abbildung 1 angedeutet sind.

Die naheliegendere soll mit der Bezeichnung horizontale Integration belegt werden.

Bei ihr wird versucht, die in einer Ebene liegenden Komponenten zu integrieren beziehungsweise eine Standardkomponente zu schaffen, die die Eigenschaften der anderen Komponenten möglichst umfaßt. Gelingt dies, so besteht für die direkt darüber liegende Ebene kein Zweifel mehr, auf welches Subsystem aufgesetzt werden soll. Damit stellt sich die Anschlußfrage, ob es eine Tendenz in Richtung Standard bei Hardware, Betriebssystem, Programmiersprache und Anwendungssystem gibt. Solch ein Standardsystem muß aber die wesentlichen Eigenschaften seiner Subsysteme vereinigen. Sonst läßt sich sicher ein Problem finden, das mit diesem angenommenermaßen universellen System nicht lösbar wäre.

Für die Hardware zeichnen sich im Arbeitsplatzrechnerbereich Trends zu gewissen Standardkonfigurationen ab. Ein oder bisweilen mehrere Mikroprozessoren bilden das Herz eines Arbeitsplatzcomputers. Nach der mehrjährigen Einführungsphase mit den 8-Bit-Rechnern und dem relativ kurzen Leben der 16-Bit-CPUs scheinen jetzt im wesentlichen die 32-Bit-Systeme die entscheidende Rolle um die Behauptung des Mikromarktes zu spielen. Dedizierte Systeme, wie etwa die Lisp-Maschinen von Symbolics, spielen zur Zeit noch eine - an der Marktverbreitung gemessen - geringe Rolle.

Ein Betriebssystem, das durchgängig auf allen Rechnerklassen verfügbar ist, existiert noch nicht. Die immer mächtiger werdende Hardwareausstattung der Arbeitsplatzrechner, zusammen mit einem Trend zum Betriebssystem Unix, läßt schon bald die Verfügbarkeit von Systemdiensten erwarten, die früher nur "größeren" Anlagen vorbehalten waren. Damit kann man im Bereich der Von-Neumann-Rechner-Klasse schon bald mit der durchgängigen Verfügbarkeit eines Betriebssystems vom Mikrorechner bis zu Mainframes ausgehen. Vergleichbare Anstrengungen werden ebenfalls von der Mehrzahl japanischer Mikrocomputerhersteller mit dem Betriebssystem MSX unternommen. Bisher kann noch nicht abgesehen werden, wieweit sich dieses System im Markt behaupten können wird. Einen interessanten und gleichzeitig auch schon sehr alten Weg beschritt IBM mit seinem Betriebssystem Virtual Machine "VM". Unter VM können verschiedene traditionelle Betriebsysteme wie DOS und MVS betrieben und verschiedene Hardwarekomponenten emuliert werden. Damit ist für den Mainframebereich eindeutig ein Integrationstrend für diesen Bereich absehbar. IBM brachte mit dem PC-AT einen Rechner mit bis zu 3 MB Hauptspeicher auf den Markt. Also kann davon ausgegangen werden, daß Betriebssysteme wie VM demnächst auch auf Arbeitsplatzrechnern zur Verfügung stehen, um die gleichen Anwendungen wie auf den Großrechnern fahren zu können. Auf die Dauer wird man allerdings nicht darum herumkommen, verteilte Betriebssysteme zu entwickeln, die die Unterstützung lokaler und globaler Netze mit Drucker- und Plattendiensten gewährleisten.

Man kann integrierte Systeme, die mit den Anforderungen der Benutzer wachsen, also nur realisieren, wenn erweiterbare und offene Funktionen zumindest ab der Ebene der Betriebssysteme gewährleistet sind. Dies gilt besonders für die Ebene der Programmiersprachen. Unter einem interpretierenden System wird es möglich sein, einen Programmteil einer beliebigen Programmiersprache von einem Programmstück einer anderen Programmiersprache aufzurufen. Erst wenn dies ohne Einschränkung gelingt, kann man von einer Integration auf der Ebene der Programmiersprachen sprechen. Dies ließe sich als "Forderung der gegenseitigen Aufrufbarkeit und Implementierbarkeit" bezeichnen. Von Hans-Jürgen Appelrath und Hermann Bense in "Zwei Schritte zur Verbesserung von Prolog-Programmiersystemen: DB-Unterstützung und Meta-Interpreter" wird gezeigt, wie ein Prolog-Interpreter auf der Basis eines Datenbanksystems in Pascal implementiert wird. Ebenso könnte man ohne große Schwierigkeiten ein Prolog-Interpreter in Lisp oder Lisp in Pascal implementieren. Dazu gehört auch, daß eine Sprache in sich selbstimplementiert werden kann. Ziel einer "sauberen" Integration von Programmiersprachen wäre natürlich das maßvolle Zusammenfassen aller wichtigen Eigenschaften und Konzepte der verschiedenen Programmiersprachenklassen zu einer Universal-Sprache.

Bisher wurde nur zaghaft versucht, verschiedene Anwendungssysteme zu integrieren. Eine vollständige Lösung würde die paarweise Integration der Anwendungen der vier Problemklassen: Datenverarbeitung mit festen und freien Formaten, Organisations- und Planungsanwendungen sowie Expertensysteme bedeuten. Besonders bei den Integrationsversuchen von Datenbanksystemen, Information-Retrieval-Systemen und Expertensystemen gibt es bereits eine Reihe von Arbeiten.

Datenbanksysteme sind wegen ihrer Mehrbenutzerfähigkeit und Datenverwaltung bereits dafür prädestiniert als Ausgangspunkt der Integrationsansätze zu dienen. Flaschenhals hierbei könnte sehr schnell die niedrige Transaktionsrate sein, die im Vergleich zu normalen Anwendungen erreicht werden kann. Deshalb wird es eine der Hauptaufgaben sein, universelle Daten- und Speicherungsstrukturen für alle Anwendungsklassen zu entwickeln.

Die zweite, weitaus weniger diskutierte Integrationsrichtung, ist die vertikale Integration. Hier lautet die grundlegende Frage: Muß man überhaupt zwischen verschiedenen Systemebenen unterscheiden? Oder werden nicht irgendwann einmal Betriebssysteme, Programmiersprachen und Anwendungssysteme direkt in die Hardware fest verdrahtet werden können; Stichworte sind vertikale Migration und Datenbankbetriebssysteme. Auf den untersten Systemebenen - Mikroprogrammierung, Betriebssysteme - ist dies schon lange üblich. Auch auf höchsten Sprachebenen zeichnen sich Bestrebungen ab, durch dedizierte Systeme, sprich Datenbankmaschinen, FGCS oder VLST hohe Leistungen zu erreichen.

Der Ausgangspunkt war, daß eine Systemschicht komplett auf der nächst niedrigeren aufsetzte. Konsequenterweise könnte man also da von ausgehen, benachbarte Ebenen zusammenzufassen. In mindestens eine Richtung ist dies zumeist problemlos möglich. Wie bereits zuvor erwähnt, ist es bereits häufig praktiziert worden, Betriebssystemfunktionen und sogar Programmiersprachen in die Hardware zu integrieren. Hier ist allerdings zu bedenken, daß die Grundforderung der Erweiterbarkeit unter Umständen verletzt ist, da Hardware natürlich nicht ohne weiteres verändert werden kann.

Betriebssysteme sind immer in einer bestimmten Programmiersprache geschrieben, so daß automatisch eine Einbettung vorliegt. Der Schritt von den Programmiersprachen zu den Anwendungssystemen gestaltet sich da im allgemeinen schon größer. Oft werden als Anwendungssysteme sogenannte "nicht-prozedurale" Programmiersprachen entwickelt, also Reportgeneratoren oder Tabellenkalkulationsprogramme. Zur Integration müßte die Programmiersprachenebene in die Ebene der Anwendungssysteme eingebettet beziehungsweise umgekehrt werden. Das bedeutet, das integrierte Anwendungssystem besäße alle sprachlichen Mittel, um beliebige Programme erstellen zu können. Smalltalk scheint hier wiederum das System zu sein, bei dem dies am weitesten gelungen ist.

Personal Computing, wohin geht die Entwicklung? Als Resümee zu den Entwürfen über die Integration von Anwendungssystemen bei Arbeitsplatzrechnern läßt sich formulieren: Die Trends zu integrierten Systemen in der Informations- und Datenverarbeitung sind unverkennbar. Viele Grenzen fallen durch das ständig wachsende Angebot an Rechenleistung und Kapazität. Letztendlich kommt dies dem Benutzer von Rechensystemen zugute. Die heutigen Integrationsansätze verdanken ihre Existenz hauptsächlich Anforderungen aus der Praxis. Demnach kann man auch heute noch kaum ein homogenes Hardware-/Softwaresystem finden, welches die Minimalanforderungen beliebiger Anwendungssysteme erfüllen könnte. Ein mehr planmäßiges Vorgehen, das auf den hier vorgestellten Ansätzen der horizontalen und vertikalen Integration basiert, ist vermutlich der einzige Weg, der zu einem benutzerfreundlichen informationsverarbeitenden System führt. Die hier vorgestellten Architekturentwürfe können dazu als Rahmen dienen.

Literaturhinweise

Hans-Jürgen Apperath, Hermann Bense "Zwei Schritte zur Verbesserung von Prolog Programmiersystemen: DB-Unterstützung und Meta-Interpreter". Gl Fachtagung "Datenbanksysteme in Büro, Technik und Wissenschaft" März 1985 Hermann Bense, Armin B. Cremers, B-GEN-A Generalized Application Development System Forschungsbericht Nr. 178, Universität Dortmund, Abteilung Informatik, 1984.

Karl-Heinz Hauer, Claus Seeger (Hrsg.) Hardware für Software, Tagung III/1980, German Chapter of the ACM, 10. bis 11. Oktober 1980, Konstanz, Teubner, Stuttgart

Douglas R. Hofstadter, Gödel, Escher, Bach an Eternal Golden Braid Basic Books, Inc., New York 1979

Ellis Horowitz, Alfons Kemper, Baiaji Narasimhan, An Analysis of Application Generators, TR-83-208, Computer Science Department, University of Southern California, Los Angeles, March 1983

Tracy Kidder, The Soul of a New Machine Atlantic Monthly Press and Little, Brown and Company, Boston, 1981