Vom Mathematikerparadies zum "Jedermann-Programm mit Limits":

Baukonzepte grenzen den Einsatzbereich ab

23.08.1985

Die Datenverarbeitung hat seit der Zeit des Inputs über Lochkarten und der sequentiellen Files einen langen Weg bis zur heutigen Ära der vierten Generation zurückgelegt. Jim Cluchey* analysiert in seinem Beitrag die Entwicklungsgeschichte zum Status quo.

Computer arbeiten auf jeder Ebene mit bestimmten Verfahren. Von dieser grundlegenden Tatsache gibt es keine Abweichungen.

Die Software-Industrie, die immer mehr und größere Systeme entwickelte, durchlief eine Reihe von methodischen Phasen.

Maschinencode

Programmierte Anweisungen auf der untersten Ebene, die dem Computer sehr detailliert beschreiben, wie die Speicher- und Verarbeitungskapazitäten auf der Ebene der Bits und Bytes behandelt werden.

Die Software-Ingenieure erkannten schnell, daß der Aufbau umfassender Systeme mit derart rudimentären Instruktionen eine schwere, wenn nicht unlösbare Aufgabe war. Schlimmer noch: Die Benutzung von Maschinencode bedeutete ebenfalls, daß einstellige Zahlen als Code eingesetzt werden mußten. Für einen Außenseiter konnte dies nur als "Paradies für den Mathematiker" angesehen werden.

Assembler

Die "Tokens" werden erfunden: An die Stelle der Zahlen treten sinnvolle Abkürzungen von Verben, die mit den erforderlichen Handlungen in Beziehung stehen. So traten Ausdrücke wie "Move", "Multiply" , "Add", "Jump" oder deren Abkürzungen in das Leben des Software-Ingenieurs.

Auch war Assembler sehr eng mit der Architektur des Prozessors verbunden, die Instruktionen lang, ermüdend zu schreiben, schwer auf einen Blick zu verstehen und nur mühsam zu modifizieren (außer für den Codierer selbst, der das Originalprogramm erstellt hatte).

Dieser Ansatz hatte noch einen weiteren "Schönheitsfehler": Es gab zu viele Wege, die gleichen Instruktionen an den Computer zu übermitteln. Hier herrschte immer noch das Paradies der Logiker und Mathematiker vor - nicht das der Systemanalytiker und Anwender. Ein Programmierer mußte eine lange Trainingsphase überstanden haben, die internen Arbeitsvorgänge im Rechner gut verstehen und sehr beweglich im Denken sein.

Hochsprachen

Der entscheidende Durchbruch in der Anfangszeit der Software-Ingenieure war die Erfindung der "Compiler". Die Anweisungen an den Rechner mußten zwar immer noch in der Schlußanalyse im Detail gegeben werden, doch konnte der Programmierer auf eine andere, höher entwickelte und besser verständliche Sprache zurückgreifen; unter der Voraussetzung, daß passende Übersetzer die Sprache in Assembler oder ähnlichen Code konvertierten.

Zu unterschiedlichen Zeitpunkten entstanden so zum Beispiel Cobol, Fortran und Pascal. Diese Programmiersprachen waren enger mit den Anwendungsbedürfnissen und der Sprache des Wissenschaftlers verbunden. Fortran übersetzt mathematische Formeln in Computeranweisungen; Die Formulierungen sind für den Mathematiker oder den Wissenschaftler einfach zu lesen, weil sie - abgesehen von einigen Kompromissen - den Gleichungen und Formeln aus den Textbüchern ähnlich sind.

Fortran war allerdings immer noch prozeßorientiert und für den Laien schwer verständlich, stellte aber dennoch eine große Verbesserung gegenüber der Assemblertechnologie dar.

Spezialisierte, nicht prozeßorientierte Sprachen

Nach jahrelanger Erfahrung mit Sprachen wie Cobol und Fortran stellte die "Bruderschaft der Software-Gurus" fest, daß bestimmte Anwendungsbereiche nur in Verbindung mit Ermüdungserscheinungen und Wiederholungen mit Cobol und Fortran bearbeitet werden konnten. Das war die Geburt der "Vierten Generation".

Im Gegensatz zur vielfach verbreiteten Meinung war dies aber keine Revolution, sondern die Folge einer kontinuierlichen Entwicklung seit den 60er Jahren.

Einen klassischen Anwendungsbereich stellt der "Bericht" dar. Softwarehersteller begannen, sogenannte "data driven"- sowie "parameter driven"-Programme zu schreiben, um die ständigen Wiederholungen desselben Cobol-Codes zu vermeiden. Von dieser Art gab es viele strukturähnliche Programme.

Die erste allgemeine Analyse dieses "Reporting Cycle" erschien, als Übertragungslistings und Berichtsgeneratoren wie RPG aufkamen. Das waren die ersten nicht-prozeßorientierten Sprachen. Der Prozeßzyclus innerhalb des Masterprogramms bot zwar eine enorme Produktivitätshilfe, entpuppte sich für den Softwerker aber auch als eine Zwangsjacke, sobald er etwas außerhalb des Prozeßzyklus realisieren wollte. Im Gegensatz zu Cobol war keine vollständige Kontrolle der Prozesse gegeben, sondern nur über Teile des Ablaufes. Die Kraft und Flexibilität solcher Sprachen war in kritischer Weise abhängig davon, wie allgemein das Design des Prozeßzyklus gehalten war.

Oftmals wurden Produktivitätsgewinne nur auf Kosten der Eingrenzung möglicher Applikationen erreicht. Diese Einschränkung war meistens durch einen zu engen Spielraum in dem Hauptprozeßzyklus bedingt; wiederum in Zusammenhang mit der Unfähigkeit, einen angemessenen Prozeß für Bedürfnisse in allen Bereichen zu finden.

Viele Anwender wurden durch solche Systeme enttäuscht und kehrten zu gewohnten Programmierverfahren zurück.

Inzwischen erzielten die Entwickler im Bereich der Datenbanken einen bemerkenswerten Fortschritt: von rudimentärem Filehandling zu hochentwickelten Schlüsselstrukturen, die Datenbeziehungen auf hoher Ebene modellhaft darstellen konnten. Ebenso bemerkenswert war der Fortschritt im Bildschirmhandling und im Aufbau von on-line-Systemen. Cobol bekam Schnittstellen zu Datenbanken und Bildschirmverarbeitung.

Auch bei den nicht-prozeßorientierten Systemen blieb die Entwicklung nicht stehen. Ein Beispiel aus der Technik: urheberrechtlich geschützte Simulationssprachen.

Der Anwender mußte bei diesen Sprachen feststellen, daß sie ihm nicht gestatteten, eine allgemeine Logik des Simulationsprogramms zu entwerfen. Dieses wurde geschrieben und im Compiler eingebettet. Eingriffe waren nur in die Beschreibung und Auflistung der Ereignisse möglich - also wieder das alte Hauptprozeß-Problem, nur höher entwickelt. Ein Vergleich des Autors ergab, daß die Fertigstellung des gewünschten Simulationssystems etwa zwei Drittel der Zeit im Verhältnis zu Fortran in Anspruch nahm. Das war die Situation in den 70er Jahren vor dem Erscheinen der Konzepte für Sprachen der vierten Generation.

Hochsprachen helfen der Wissenschaft

Heute gehört die Bewertung kommerzieller "4 GL"-Programme zu den Aufgaben der Datenverarbeitungsmanager in kommerziellen Umgebungen. Ihnen ist meist unbekannt, daß auch Universitäten, Laboratorien und wissenschaftliche Anwender eine Vielzahl von Sprachen der 4. Generation nutzen. Dazu gehören urheberrechtlich geschützte Sprachen zur statistischen Analyse, Simulationsprogramme für Ereignisse oder Lösungshilfen für Differentialgleichungen.

Diese nicht-prozeßorientierten Sprachen sind mehr beschreibend als prozeßorientiert konfiguriert, auch wenn viele über prozeßorientierte Komponenten verfügen. Bei allen ist eine Form des "processing cycle" oder des "master program"-Konzepts implementiert, abgesehen davon, daß es sich heute eher um ein hochentwickeltes Netzwerk von Zyklen handelt als um ein lineares Konzept.

Geringe Bandbreite bremst den Erfolg

Die Basis ist bei den meisten Vorgehensweisen gleich, ausschlaggebend ist die Implementierung. Einige Produkte sind schlecht entworfen und haben nur eine geringe Bandbreite. Sie zählen nicht zu den echten Sprachen im engeren Sinn, sondern stellen generalisierte Pakete für spezielle Anwendungen dar. Der Schlüssel zu wirklichen Ausführungsgewinnen liegt im zugrundeliegenden "master cycle" einer Sprache der 4. Generation oder ihrer Komponenten.

Viele dieser Sprachen sind aus urheberrechtlich geschützten - oftmals relationalen - Datenbanksystemen entstanden. Den Systemen können Utilities wie Reportgeneratoren, Maskengenerator und Grafikpakete hinzugefügt werden, um dem Endanwender die Möglichkeiten der Datenbank zugänglich zu machen. Professionelle Systeme sind häufig mit Hilfe solcher geschützter Datenbanken aufgebaut.

Im Gegensatz dazu sind andere Systeme als "dictionary driven"-Sprachen angelegt. Diese Systeme sind meistens in einer Hardwareherstellungsumgebung entstanden. Entwickler neigen dazu, diese Produkte als Sprachen, nicht als Datenbanken zu bezeichnen. Sie arbeiten häufig im professionellen MlS-Bereich. Vorteil ist, daß dem Anwender keine urheberrechtlich geschützte Datenbank aufgezwungen wird. Meist sind diese Softwarepakete auch preisgünstiger als relationale Datenbanken.

Hochentwickelte Data-Dictionaries

Die meisten guten Sprachen der vierten Generation bieten heute Data-Dictionaries an, die für gute Produktivität notwendig sind. Die Vorteile eines Data-Dictionaries liegen auf der Hand:

- Zentralisierte Datenbeschreibung (keine multiplen und verschiedenen Beschreibungen in verschiedenen Cobol-File-divisions). Beschreibungen werden für die Benutzung in einer gesamten Applikation nur einmal ausgearbeitet und in eine Datei gebracht).

- Größerer Informationsinhalt. Dictionaries definieren nicht mehr nur interne Feldformate, sondern ebenso externe, die für Berichte oder Bildschirmdarstellungen unterschiedlich sein können. Sie definieren Editionsmasken, Validierungskriterien, Tabellenbezüge, Bezüge zwischen Feldern, Datenkategorien und Informationsbotschaften. Derartige generische Information ist über die gesamte Applikation hinweg automatisch verfügbar. Dadurch entfällt eine große Menge der langweiligen Wiederholungen beim Schreiben individueller Module für Berichte, Prozesse und Bildschirm.

- Generische oder logische Datenstrukturen. Charakteristikum der Fähigkeit, ein Feld zu definieren, ist eine logische Einstellung (attribute); zum Beispiel "Currency type" anstelle einer physischen Einstellung "9(6) Comp".

- Utilities beschreiben die Fähigkeit, physische Datenstrukturen in der Datenbank automatisch auf der Basis des Inhalts des Dictionaries zu erzeugen.

Im Bereich der intelligenten FehIerbehandlung (defaulting) bringen die "4 GL" viel Effektivität. Gut aufgebaute Systeme sorgen für Zuweisung von Default-Parametern, die auf der Grundlage einer intelligenten Analyse der Bedürfnisse des Anwendungsmodules aufgebaut sind. Zum Beispiel wird die Aufgabe gestellt, nach einem System zu suchen, daß nach der kleinstmöglichen Ressource sucht, wenn diese Option besteht, nicht nach dem Maximum. Für einen trennscharfen Test muß sorgfältig beobachtet werden, was die "4 GL" unternimmt, wenn keine explizite Vorgabe der Vorgehensweise gegeben ist. Diesem Bereich schenkten die Ersteller von kommerziellen

"4 GL" nur wenig Aufmerksamkeit.

Überwachungsmögilchkeiten nicht präzise genug

Viele "4 GL" gestatten die schnelle Erstellung von Mustern und unterstützen so den Anwender beim Design von Systemen. Manche hingegen lassen keine Entwicklung über den Prototyp hinaus zu. Die Besten entwickeln Muster in einem nahtlosen Prozeß von Anfang bis Ende. Viele bieten einen "layered" Ansatz; sie füllen die Details aus, wenn der Anwender dies versäumt. Dieser Vorgang ist aber rückgängig zu machen: Der Programmersteller kann immer noch selbst die Details eingeben, wenn er die vorgegebenen Werte nicht akzeptiert. Für den Analyse-Zyklus bringt diese Eigenschaft beachtenswerte Vorteile.

Jede der oben genannten Eigenschaften trägt in kritischer Weise zur Effektivität der "4 GL" in einer kommerziellen Umgebung bei. Sind alle gegeben und gut implementiert, kann der Produktivitätsgewinn beim Aufbau von Systemen spektakulär sein.

*Jim Cluchey, Regional Manager Europe bei Cognos, Berkshire (Großbritannien)