LEONBERG (je) - Wie schwerwiegend die Unterschiede sind, wenn man die Resultate konventioneller Daten- und Sprachtechniken mit denen von "very high-level languages" vergleicht, läßt sich am besten an einem bewußt simpel gehaltenen Beispiel demonstrieren. Ausgehend von dieser Überlegung versucht Wolfgang J. Mudter, European Sales Manager der Applied Data Research (ADR) Deutschland GmbH, nachzuweisen, daß das Entwickeln von Applikationen auf ein pures Definieren von Anwendungslogiken hinauslaufen muß. Sein Joker: Das Multifunktionssystem "Ideal", mit dem ADR Ende 1982 auf den Markt kommen wird.

Die derzeitige Lage kennzeichnet Mudter folgendermaßen: "Die Hardware entwickelt sich in atemberaubendem Tempo, die Software wird funktionsgeladener und komplexer; nur die Anwendungsentwicklung hat Schwierigkeiten, dieses Marschtempo mitzumachen. Trotz MVS, Megabytes und Nanosekunden muß der Anwender Monate und Jahre auf Dienstleistungen der DV - sprich Anwendungen - warten.

Folgt man den sattsam bekannten Darstellungen der überproportional wachsenden Anwenderforderungen und quasi stagnierender Entwicklungskapazitäten, steuert die Anwendungsentwicklung mit ihren herkömmlichen Techniken zielstrebig in ein informatorisches Chaos. Lösungen in Teilbereichen erweisen sich aufgrund komplexer Zusammenhänge und Abhängigkeiten zwischen Anwendungsentwicklung, Datenadministration, Dokumentation und Ausführung als untaugliche Mittel, spürbare Produktivitätssteigerungen herbeizuführen."

Schuld ist jeder

Für Mudter ist unstrittig, daß eine wirkliche Lösung sich allumfassend gestalten muß, zumal jeder der genannten Bereiche für sich genommen ursächlich für das Dilemma der Anwendungsentwicklung verantwortlich zeichne. Der ADR-Manager präzisiert:

- Die Datenadministration sollte in die Lage versetzt werden, jede benötigte Informationskonstellation (Benutzersicht) ohne Störung bestehender Komponenten evolutionär bereitzustellen. Dies gilt insbesondere für spontane Informationsanforderungen.

- Die Anwendungsentwicklung muß weitgehend von auferlegten Sachzwängen der Datentechnik, der Dokumentation und der operativen Aspekte befreit werden. Redundante Arbeitsgänge sind durch Zentralisation im Rahmen einer Dokumentationsdatenbank zu eliminieren.

- Diese Dokumentationsdatenbank zeigt alle informatorischen Zusammenhänge zwischen Anwendungsentwicklung, logischer und physischer Datendarstellung, Benutzer und Benutzungsarten auf.

Datenmanipulationslogik implizit

Daraus leitet Mudter die Forderung nach einer relationalen Datenbanktechnik ab, frei von physischen Strukturen, um auch nicht geplante Informationskonstellationen bereitzustellen, ohne daß sich hierdurch Auswirkungen auf bestehende Datenspeicherungen oder Anwendungen ergeben.

Im Sprachenbereich bedeute dies eine strukturierte, nichtprozedurale Funktionssprache mit impliziter Datenmanipulationslogik ("database sublanguage" / "relational calculus").

Einfaches Programmbeispiel:

FOR EACH ARTIKEL

WHERE STÜCKPREIS = 10,00

SET BESTANDSWERT = MENGE

* STÜCKPREIS

PRODUCE KLEINTEILE-BERICHT

END FOR

ARTIKEL bedeutet hierbei, wie Mudter erläutert, eine Informationskonstellation in tabularer Darstellung, wie sie möglicherweise nur für diese Anwendung relevant ist und keinen Sachzusammenhang mit der physischen Speicherung in sich birgt (Logische Benutzersicht der Daten oder "Dataview").

STÜCKPREIS, MENGE UND BESTANDSWERT sind Attribute (Felder) einer Dataview. Folgert Mudter: Ist BESTANDSWERT Attribut einer Dataview, für die in dieser Kombination attributabhängige Veränderungen zugelassen sind, so stellt die SET-Anweisung eine UPDATE-Funktion und gleichzeitig die einzig notwendige "Datenmanipulationskenntnis" des Anwendungsentwicklers dar. KLEINTEILE-BERICHT wurde in einer separaten Berichtsdefinition mit Ausfüllcharakter definiert.

Bei dem Anwendungsbeispiel handelt es sich, wie Mudter betont, um eine simplifizierte Problemstellung. Aber auch so würden bei der Gegenüberstellung einer Lösung des gleichen Problems mittels konventioneller Daten- und Sprachtechniken die erheblichen Unterschiede in Aufwand, Klarheit und Flexibilität sichtbar werden. Ebenso deutlich sei damit, meint Mudter, daß die Erstellung eines Anwendungsprogramms ausschließlich in der Definition der Anwendungslogik bei völliger Nichtbeachtung daten-, betriebs-, system- oder ausführungstechnischer Gegebenheiten bestehe.

Mudter weiter: Die Dokumentationsdatenbank - üblicherweise als Data-Dictionary bezeichnet - wird die Dataviews und die jeweils darunterliegende physische Speicherung, die Beschreibung der Datenbank, deren Inhalt, die Benutzerdaten, Berichte, Bildschirmformate, Anwendungsgebiete und alle Aspekte, die sich aus dem funktionalen Kontext ergeben, verwalten und die Einhaltung der Standards und Regeln dynamisch überwachen. Somit werde die Forderung nach einem integrierten Data Dictionary unverzichtbar.

Daß Anwendungsentwicklung nur interaktiv erfolgen kann, ist für Mudter selbstverständlich. Idealerweise habe der notwendige Editor eines solchen Systemes syntaktische und strukturelle Intelligenz: Bei der Nennung der FOR-Anweisung im gewählten Beispiel generiere das System die END-FOR-Anweisung automatisch und führe den Benutzer in syntaktischem und auch strukturellem Sinne.

Logische Fehler würden zum frühestmöglichen Zeitpunkt erkannt, so daß die Prüfung zwangsläufig auf alle abprüfbaren, logischen Sachzusammenhänge auszudehnen sei, was ein weiteres Mal die Notwendigkeit der interaktiven Nutzung eines Data Dictionary belege.

Interaktion, stellt Mudter fest, erfordert zunächst einmal Software zur Datenkommunikation und einen TP-Monitor (idealerweise mit Systemkomponenten wie Datenbanksystem und Data Dictionary integriert). In der Folge stellt sich, wie Mudter weiter ausführt, die Erstellung einer unter dem Monitor abzuwickelnden Online-Anwendung ähnlich der einer überkommenen Batch-Anwendung dar: Sofern tatsächlich die reine Definition der Anwendungslogik erreicht werde, hätten "Batch" und "Online" als operative Aspekte ihre Daseinsberechtigung in der Anwendungsentwicklung verloren.

Diese Überlegungen führten, wie Mudter angibt, bei ADR zur Entwicklung des als Anwendungsentwicklungsinstrument apostrophierten "Ideal".

Die Basis von Ideal, beschreibt Mudter, wird aus dem von ADR als relational eingestuften Datenbanksystem "Datacom/DB" unter gleichzeitiger Zulassung VSAM-gespeicherter Daten und dem integrierten Data Dictionary "Datacom/DD" gebildet. Wahlweise könnten "Datacom/D-Net" und "-/DC" beziehungsweise das ADR-Produkt "Roscoe" oder IBMs CICS hinzukommen.

Die Anwendungsentwicklung, erläutert Mudter, könne damit sowohl auf einem einzelnen Rechner wie auch im Rahmen eines Verbundnetzes beliebiger Kombinationen von DOS-, OS- und MVS-Systemen ablaufen. Das System arbeite in allen Teilbereichen, in der Datenadministration, dem Anwendungsdesign, der Anwendungsentwicklung, im Debugging und im Test ebenso wie in der Ausführung interaktiv.

Der Endbenutzer, prophezeit der ADR-Mann, wird stärker in die Anwendungsentwicklung einbezogen werden; der Anwendungsprogrammierer jedoch wird sich - völlig im Gegensatz zu gelegentlich geäußerten Befürchtungen - keineswegs seines Arbeitsplatzes beraubt sehen. Im Gegenteil: Die Eliminierung anwendungsfremder Routinearbeiten wird seine Produktivität und Arbeitsqualität steigern.