-Hier in Madrid auf dem internationalen Presseseminar über die Arbeit der wissenschaftlichen Zentren der IBM haben Sie heute über "High Level Communication" mit dem Computer referiert, über Ihre Arbeit in Heidelberg berichtet und dabei angedeutet, daß künftig auch für die Nicht-EDV-Spezialisten der Umgang mit dem Rechner immer leichter werde. Wohin geht der Trend?

Wir in Heidelberg sind keine Propheten, sondern wir beschäftigen uns mit Grundlagenforschung für den Endbenutzer von Maschinen. Dabei gehen wir von folgender Ausgangssituation aus: Seit Jahren werden die Computer immer schneller und wird Rechnerleistung immer billiger. Gleichzeitig wächst die Zahl derer, die diese Computerleistung nützlich in Anspruch nehmen könnten. Unsere Aufgabe heißt nun: Wie diese wachsende Computerleistung, die auf immer neue Weise nützlich angewendet werden könnte, der wachsenden Zahl von möglichen Benutzern aufschließen? Oder umgekehrt: Wie die wachsende Zahl der potentiellen Benutzer an die neuen DV-Möglichkeiten heranführen? Solange Computerkapazitäten im Closed Shop-Betrieb von wenigen Spezialisten geplant, in Betrieb gehalten und der Anwendung zugeführt wurden, gab es dieses Problem in dieser Schärfe nicht.

- Soweit die Aufgabenstellung. Zeichnen sich Lösungen ab?

Wirksamere Mensch-Maschine-Kommunikation auf dieser Ebene der Nicht-EDV-Fachleute kann nur zustande kommen, wenn der Rechner genutzt wird, um ihn zu nutzen. Ein solcher Dialog muß aber frei sein von Computerdetails. Es muß ohne viel Lernen einen einfachen Einstieg geben, und die Kommunikation muß sich dem Profil des Benutzers, also seinem Wissensstand, anpassen.

- Welche Verfahren, welche Techniken kann man zu diesem Zweck nutzen?

Da ist zunächst einmal die "Menü-Technik". Das bedeutet, daß im Dialog jeweils eine Aufzählung von Möglichkeiten angeboten wird, und der Benutzer wählt eine von diesen aus. Des weiteren "Tutorials". Darunter verstehen wir, daß das System seine eigenen Fähigkeiten erläutert, wenn der Benutzer nicht mehr weiter weiß und es dann befragt. Als drittes: "Prompting", das heißt, das System fordert den Benutzer, wenn erforderlich, zur Dateneingabe auf und zeigt dabei die notwendigen Einzelheiten an. Zusammenfassend kann man sagen, diese Kommunikation sollte in Benutzer-Terminologie stattfinden, so daß dem Problemlöser und Sachbearbeiter der Dialog natürlich erscheint.

- Im wissenschaftlichen Zentrum Heidelberg nun arbeiten Sie an solchen High-Level-Communication-Systemen. Welche Projekte gibt es im einzelnen?

Wir unterscheiden zwei Problemklassen. Zum ersten: Probleme, die in ihren Anforderungen und Verarbeitungsregeln gut bekannt sind und bei denen auch die zu bearbeitenden Daten vorliegen. Häufig sind diese Probleme wiederkehrend. Für diese Problemstellung - wir nennen die Rolle des Endbenutzers hier "Anwendungs-Entwickler" - haben wir ein experimentelles System entwickelt, das wir IPE, interaktive Programmierung durch den Endbenutzer, nennen. Daneben existiert noch der Problemlöser, der sich mit der Entwicklung einer Lösung für nicht-strukturierte Probleme beschäftigt, bei denen das Lösungsverfahren sich nicht von Anfang an abzeichnet und bei dem die Daten nicht vorhanden oder nur unvollständig vorhanden sind. Für dieses Gebiet gibt es mehrere Projekte im Wissenschafts-Zentrum Heidelberg.

-Wie soll diese interaktive Programmentwicklung durch den Endbenutzer aussehen?

Für den Anwendungs-Entwickler haben wir mit IPE eine Formularorientierte Programmierung entwickelt. Dabei gibt der Benutzer in drei Phasen eine indirekte, aber exakte Definition des Programms. Als erstes wird eine Lay-Out-Phase im Dialog durchgearbeitet. Der Benutzer definiert Überschriften, Zeilen und Spalten seines Formulars oder seiner Tabellen. Dann kommt die Definition der Daten-Eingabe bezugnehmend auf die vorhandene Datenbank. Und schließlich kommt die Angabe der Rechenregeln für Ausgabewerte. Im Grunde genommen tut der Benutzer so nichts anderes als wenn er seine Probleme mit Bleistift und Papier lösen würde.

- Das klingt zunächst wie RPG, sollte aber doch wohl mehr sein?

Ist es auch. Zum einen, weil es ein Dialogsystem ist. Zum anderen hilft es dem Benutzer, wann immer er Hilfe braucht. Und zum dritten reicht die Rechenfähigkeit weit über RPG hinaus, da alle Möglichkeiten der dem System zugrunde liegenden Sprache APL genutzt werden können.

- Ist "Formular-orientiert" dafür ein glücklicher Begriff?

Viele Vorgänge im Unternehmen werden durch Formulare beschrieben und gesteuert. Wir wollen mit dem Namen "Formular-orientiert" andeuten, daß das System besonders für solche Anwendungen geeignet ist, bei denen sich eine formularmäßige Darstellung anbietet.

- Und das gibt es heute bei Ihnen auf der Maschine? Dazu bitte einige Details.

Ein Prototyp des Programms ist fertig und zur Zeit bei IBM intern in der Erprobung.

- Glauben Sie, daß diese interaktive Programmierung durch den Endbenutzer ein IBM-Standard-Programm-Produkt werden wird?

Wir beschäftigen uns in Heidelberg mit wissenschaftlicher Arbeit. Wenn wir technische Machbarkeit nachgewiesen haben, dann ist damit noch lange nichts über Marketing und Vertrieb entschieden. Da kommen noch viele andere Fragen ins Spiel, über die wir als Wissenschaftler überhaupt nichts sagen können. Aber, das ist richtig, alle Ergebnisse, die wir in Heidelberg erzielen, werden in aller Öffentlichkeit publiziert, so daß sie jedem zugänglich sind.

- Soweit die High-Level-Communcation für den Anwendungs-Entwickler, der sein Problem und seine Daten kennt. Was aber wird man künftig den Problemlösern, dem großen Kreis derjenigen bieten können, bei denen die Problemstellung weit weniger klar ist?

Die Situation des Problemlösers ist dadurch gekennzeichnet, daß er einerseits mit Daten und Programmen zu tun hat, andererseits mit Informationen, die diese Daten und Programme beschreiben. Er braucht ein System, das ihm bei der Auswahl von Daten und Programmen hilft und auch bei der Anwendung der Programme auf ausgewählte Daten. Für beide Fälle laufen Projektstudien in Heidelberg. Wir arbeiten einerseits an Verfahren, Methodenbanken benutzerfreundlich zu gestalten, und andererseits an verschiedenartigen Abfrage- und Manipulationssprachen für Datenbanken, die von einer grafisch-orientierten Sprache bis hin zu Formulierungen reichen, die natürlicher Sprache ähnlich sind.

- Damit haben Sie das Stichwort "natürliche Sprache" gegeben. Wie weit ist man denn mit der Programmierung in natürlicher Sprache?

Von Programmierung in natürlicher Sprache war nicht die Rede. Wir wollen eine Abfragesprache zur Verfügung stellen, die dem Benutzer natürlich erscheint.

- Aber das ist nicht der erste Schritt zur Programmierung in natürlicher Sprache? Indem ich eine Abfrage formuliere, programmiere ich ja Abläufe auf dem Rechner.

So gesehen haben Sie wohl recht. Aber das ist erst ein kleiner Schritt, denn Voraussetzung ist die Datenbank.

- Was ist heute schon möglich?

Beim jetzigen Entwicklungsstand unseres Projektes, das wir "Benutzerspezifische Sprachen" nennen, kann der Rechner eine Frage interpretieren, die etwa so lautet: "Welche unverheirateten Mitarbeiter wohnen in Heidelberg und verdienen mehr als 5000?

- Würde das System die gleiche Antwort auch liefern, wenn gefragt worden wäre: "Welche Heidelberger Mitarbeiter sind unverheirateten und haben ein Einkommen, das größer als 5000 ist?"

An genau solchen Problemen arbeiten wir. Den zweiten Text müßte man mal ausprobieren. Wenn es nicht auf Anhieb klappt, kann man analysieren, welche Grammatik-Regeln in unserem System noch nicht enthalten sind. Dann würde man leicht Abänderung schaffen können.

- Sie bringen also letztendlich doch dem Computer bei, die Umgangssprache zu verstehen?

Durch die Einschränkung auf den jeweiligen Datenbank-Kontext, ist es nicht das gesamte Problem der Analyse der natürlichen Sprache, das hier zu lösen ist. Vielmehr haben wir es mit einer Untermenge zu tun, was Mehrdeutigkeit und die Ungenauigkeit der menschlichen Sprache, deutlich einschränkt. Für eine benutzerspezifische Sprache gibt es also weniger Regeln und auch weniger Ausnahmen, und die Probleme sind deshalb leichter zu lösen.

- Götterdämmerung für Programmierer, wenn künftig jeder Endbenutzer seine Probleme im Dialog mit dem Computer selber lösen kann?

Keinesfalls. Wir glauben, es gibt genug Datenverarbeitungsaufgaben, für die qualifizierte Programmierer gebraucht werden, und das sind genau die Probleme, für die sich der professionelle Datenverarbeiter interessiert, die er gerne macht und die er eigentlich freigestellt sein sollte. Daneben gibt es Probleme, die so stark anwendungsorientiert sind, daß sie wahrscheinlich besser und effizienter vom Anwendungsexperten selber bearbeitet werden sollten. Was wir also anstreben, ist eine bessere Arbeitsteilung und eine bessere Zusammenarbeit zwischen beiden Gruppen.

Ulrich Schauer (45)

arbeitet seit 1974 am Wissenschaftlichen Zentrum Heidelberg der IBM Deutschland. Forschungs-Schwerpunkt: Datenbank-Systeme, insbesondere Datenbank-Sprachen für Problemlöser.

Nach dem Mathematik-Diplom (1956) blieb Schauer bis 1962 an der Technischen Hochschule Stuttgart, um dann zur IBM-Anwendungsentwicklung zu gehen, wo er sich vornehmlich mit dem Scientific Subroutine Package und anderen Software-Paketen beschäftigte.

1968- wechselte er zum IBM-Programm-Entwicklungscenter und arbeitete dort bis 1974 an Software für Mathematik- und Operations Research-Problemstellungen.

DasIBM-Wissenschaftszentrum Heidelberg wurde 1968 gegründet und beschäftigt heute 20 Professionals, die vornehmlich Forschung und Entwicklung auf der Basis der APL-Sprache betreiben. -m-