Bei der Anwendung der Informationstechnik sind in den kommenden Jahren umfassende Erweiterungen zu erwarten, aus denen sich erweiterte Benutzeranforderungen ergeben, die auf das Zusammenspiel der einzelnen Produkte abzielen. Jürgen Gutmann* fordert daher in seinem Beitrag die Entwicklung von Laufzeit-Umgebungen, die diese Anforderungen befriedigen und darüber hinaus die Anwendungen von der Benutzerschnittstelle unabhängig machen.

Die aktuelle Nutzung von Informationstechnik, das Angebot und die Ankündigungen der Hard- und Softwareanbieter sind heute von folgenden Tendenzen gekennzeichnet:

Die Hardwareausstattung in der Fachabteilung wird vielfältiger. Wo gestern nur zeilenorientierte Bildschirme und Drucker ohne lokale Rechen- und Speicherkapazität standen, finden sich heute zusätzlich POs und Workstations mit grafikfähigen Bildschirmen, Druckern und neuartigen Eingabeeinheiten wie Mäusen, Scannern und Grafiktabletts.

Komplexität und Vielfalt der von einem einzelnen Mitarbeiter genutzten DV-Funktionen wachsen an. Wo er gestern nur wenige einfache Erfassungs- und Abfragefunktionen durch tägliche Routine beherrschte, wird er morgen mit komplexen Dialogen konfrontiert, die unterschiedliche Bilder und Bearbeitungszustände haben und abhängig von Bild und Zustand unterschiedliche Eingaben erwarten. 80 Prozent seiner Tätigkeit am Bildschirm wickelt er mit 20 Prozent der Funktionen ab, für die er berechtigt ist. Die restlichen 80 Prozent benutzt er so selten, daß er jedesmal neu über die Bedeutung der angezeigten Information und seiner Eingaben nachdenken muß.

Häufig wiederkehrende, variationsarme Tätigkeiten, die gut in Einzelschritte strukturierbar sind, werden heute weitgehend durch transaktionsorientierte Anwendungen unterstützt - jedenfalls in größeren Unternehmen.

Neue Einsatzfelder für umfassende DV-Unterstützung - zum Beispiel Büro, Konstruktion, Disposition - sind charakterisiert durch relativ lange Bearbeitungszeiten für jeweils ein Objekt, zum Beispiel Text, Stückliste, Bestandsentwicklung. Die Objekte sind häufig so komplex, daß sie nicht auf einmal am Bildschirm dargestellt werden können, und zu jedem Zeitpunkt eine Reihe unterschiedlicher Darstellungs- und Bearbeitungsoptionen wählbar sind. Die einzelnen Bearbeitungsschritte sind nicht mehr durch das Programm vorbestimmt, sondern müssen vom Anwender selbst ausgelöst werden. Es ist erforderlich, eine Tätigkeit unterbrechen zu können, um zusätzliche Informationen zu beschaffen oder um kurzfristig eine von außen kommende Anfrage zu befriedigen.

Daten und Programme künftig mehr verteilen

Das Anwendungsspektrum wird vielfältiger. Neben die auskodierte Unterstützung von wiederkehrenden Geschäftsvorfällen mit formularähnlichen Masken treten Werkzeuge oder verallgemeinerte Anwendungen, mit denen individuelle Anwendungen ad hoc erstellt und (interpretierend) ausgeführt werden. Zusätzlich gibt es immer mehr Anwender, die mit mehreren Produkten unterschiedlicher Hersteller arbeiten müssen beziehungsweise zwischen hauseigenen Anwendungen und externen Diensten wechseln.

Gespeicherte Daten und ihre schnelle und bedarfsgerechte Aufbereitung zu aussagekräftigen Informationen werden zunehmend zu einem wichtigen Wettbewerbsfaktor. Die Datenmengen, die gespeichert und immer mehr Anwendern aufbereitet verfügbar gemacht werden, wachsen rapide. Sowohl Daten als auch Anwendungen müssen in Zukunft verteilt werden, um die Forderung nach vertretbaren und stabilen Responsezeiten zu befriedigen.

Eine neue Generation von Anwendern kommt in die Unternehmen. Sie kennen die Ataris, Amigas, PCs, Macs und Workstations durch Schule, Studium und Hobby. Wer ihnen 3270-Terminals mit transaktionsorientierter Verarbeitung anbietet, verleidet ihnen auf Dauer die Nutzung der Informationstechnik des Unternehmens. Ein Wildwuchs persönlicher Lösungen, der durch ein mangelhaftes Angebot ausgelöst wird, wirkt für das Gesamtunternehmen sehr schnell kontraproduktiv.

In dem so skizzierten Szenario sollen aus der Position des Fachabteilungsanwenders eine Reihe konkreter Forderungen aufgestellt werden, die Qualitätseigenschaften präzisieren, die im allgemeinen unter der Überschrift Benutzerfreundlichkeit von Anwendungssoftware zusammengefaßt werden: Aufgabenangemessenheit, Verläßlichkeit, Selbsterklärunsfähigkeit, Steuerbarkeit, Zugänglichkeit und Assimilationsfähigkeit.

Bei genauerer Betrachtung stellt sich heraus, daß sich viele dieser Forderungen nicht auf spezifische Anwendungsfunktionen richten, sondern auf das Zusammenwirken derselben, unabhängig vom jeweiligen Anwendungsinhalt.

So wie Datenbankmanagementsysteme als Puffer zwischen einer logischen Anwendungssicht und der physischen Speicherung von Daten wirken, können diese Forderungen von einer standardisierten, gemeinsamen Softwareschale befriedigt werden, die die eigentliche Anwendung von den physischen Gegebenheiten der Benutzerinteraktion abschirmt.

Weil derzeit alles Wichtige in der Branche einen CA-Namen haben muß, nennen wir Produkte, die so eine Schale implementieren, Care-Pakete. Care steht für Computer Aided Runtime Environment. Damit hier keine Mißverständnisse entstehen: Care-Pakete müssen Anwendungen eine viel höhere Schnittstelle bieten als sie zum Beispiel in SAA im Common Programming Interface für Dialog- und Presentation Service vorgesehen ist. Die Schnittstellenniveaus sind sicher soweit voneinander entfernt wie SQL- von DAM-Zugriffsbefehlen.

Kommen wir zu den Forderungen: Ein Wechsel zwischen unterschiedlichen Aus- und Eingabe-Einheiten für zwei von einem Mitarbeiter genutzte Anwendungen ist nicht zumutbar. Alle Anwendungen müssen auf die gleiche Weise mit einem Satz von Hardware bedient werden: Zugänglichkeit.

Die Eingabetechnik muß entsprechend der persönlichen Vorliebe, der Verfügbarkeit spezialisierter Eingabeeinheiten und der Vertrautheit mit der Anwendung frei wählbar sein (Beispiel: Selektion durch Mouseclick, Cursorpositionierung und Funktionstaste, Eingabe einer Nummer oder signifikanter Stellen eines Namens, Lichtgriffell, Funktionstaste, Tastenkombination, Spracheingabe): Steuerbarkeit.

Deswegen hat die Abfrage von Funktionstasten auch nichts im Anwendungscode verloren; das Care-Paket sorgt für die Analyse der Benutzeraktion und - soweit es die Aktion nicht selbst ausführen kann - die Umsetzung in ein allgemeines Befehlsformat, das im Anwendungscode unter einem symbolischen Namen abgefragt wird.

Wenn ein Mitarbeiter mehr und komplexere Funktionen unterschiedlich häufig benutzt, er also Experte einiger, aber gelegentlicher Benutzer vieler Funktionen ist, werden intelligentere Erklärungskomponenten benötigt als eine Funktionstaste, mit der man einen festen Helpschirm anfordert: Selbsterklärungsfähigkeit. Erforderlich sind zum Beispiel:

- Hinweise zur Sitzungssituation: welche Anwendung in welchem Fenster, in welchem Bearbeitungszustand, welche Belegung von Funktionstasten, welche Möglichkeiten zur Befehlseingabe?

- Hinweise zur Anwendungssituation im aktuellen Fenster: welcher Dialogzustand, welche Eingabemöglichkeiten, welche Informationen?

- Hinweise zu einem Feld oder einer Feldgruppe: Welche Bedeutung hat es allgemein und in dieser Anwendung? Welche Eingaben sind zulässig mit welchen Wirkungen?

- Hinweise zu einer Fehlermeldung: Warum ist der Fehler gemeldet, wie kann man korrigieren?

Auf diese Erklärungen muß man wahlfrei zugreifen können. Aus ihnen sollte man Aktionen mitnehmen können, zum Beispiel: Ausflug zu einer parallelen Anwendung in einem anderen Fenster, neue Belegung von Funktionstasten, Auswahl eines Befehls, Belegung eines Feldes.

Zur Bearbeitung komplexen Objekte werden unterschiedliche Darstellungsformen benötigt - zum Beispiel Bäume oder Einrückdiagramme für Hierarchien. Zwischen den Darstellungsformen muß man wechseln und sie in unterschiedlicher Größe und Auflösung betrachten und bearbeiten können: Steuerbarkeit.

Die Anwendung stellt nur die Objektdaten zur Verfügung. Care behandelt selbst die Darstellungswechsel abhängig vom jeweiligen Objekttyp und reicht die übrigen Benutzer-Aktionen an die Anwendung durch - in einem allgemeinen, eingabeunabhängigen Format.

Ebenso übernimmt Care die bei langen Bearbeitungszeiten erforderlichen Zwischensicherungen des bearbeiteten Objekts und gegebenenfalls das Zurücksetzen auf einen konsistenten Zustand: Verläßlichkeit.

Natürlich muß man in mehreren Anwendungen parallel arbeiten können: Zugänglichkeit. Care besorgt den wahlfreien Wechsel und bei Bedarf die Übernahme von Daten zwischen ihnen, falls der Benutzer hierzu berechtigt ist, wofür entweder ein Dictionary oder die Anwendung selbst befragt werden muß.

Werkzeuge müssen in Anwendungen integriert sein, an Werkzeuge müssen Anwendungen anschließbar sein, zum Beispiel kann ein Baumeditor für alle hierarchischen Objekte eingesetzt werden. Kalkulationsprogrammen werden die Daten von Anwendungen direkt zur Verfügung gestellt, die Formulierung einer Query muß mit Informationen aus einer auskodierten Kundenübersicht möglich sein. Auch die Werkzeuge müssen deshalb den Schnittstellenkonventionen von Care genügen und wie Anwendungen unter seiner Kontrolle laufen: Assimilationsfähigkeit.

Bei der gemeinsamen Nutzung von Daten muß man sich auf ein funktionierendes Transaktionskonzept verlassen können, auch für größere Datenmengen, die temporär für eine effizientere Bearbeitung in privaten Speicher ausgelagert werden: Verläßlichkeit. Hierfür darf aber nicht das Anwendungsprogramm zuständig sein, sondern Care und das (natürlich relationale) Datenbankmanagementsystem auf der Basis von Dictionaryinformationen.

Sicherungen von Abteilungs- und privaten Daten für den Fall eines Hardwarefehlers dürfen nicht Aufgabe des Endbenutzers sein, sondern einer Standardanwendung, die periodisch in belastungsarmen Zeiten läuft.

Unabhängigkeit der Antwortzeiten von dem, was andere Benutzer an anderer Stelle im Unternehmen tun, ist essentiell für eine produktive Nutzung der verfügbaren Funktionen: Verläßlichkeit. Die Anwendung soll nur in den Teilen auf dem Host laufen, die aus Durchsatzgründen - zum Beispiel für komplexe Kalkulationen - oder zur Sicherung der Integrität von Unternehmensdaten dort laufen müssen. Gefordert werden also verteilte Datenbanken (Aufgabe des DBMS) und verteilte Anwendungen (Aufgabe von Care). Im Anwendungscode muß beides transparent sein. Die auf APPC basierende Kommunikationsschnittstelle im Common Programming Interface von SAA wird eine technische Basis für die Verteilung einer Anwendung liefern, verteilte relationale Datenbanken mit SQL-Schnittstelle werden heute angeboten.

Anwender mit PC-Erfahrungen erlauben und fordern eine wesentlich stärkere Beteiligung bei der Systementwicklung als bisher üblich. Prototypen kann man gemeinsam mit ihnen bauen, die Ausgestaltung der Anwenderoberfläche kann ihnen vollständig überlassen werden. Die Aufgabe der zentralen Systementwicklung besteht darin,

- Anwendungsteile bereitzustellen, welche die eigentliche Anwendungslogik enthalten (betriebliche Algorithmen),

- Unternehmens- und Abteilungsdaten zu organisieren und Module zur Verfügung zu stellen, welche die Integrität der Daten in allen Anwendungen sicherstellen,

- Endbenutzerwerkzeuge so zu integrieren, daß ihr, Systemverhalten dem der übrigen Anwendungen entspricht und Schutz und Integrität der Unternehmens- und Abteilungsdaten nicht gefährdet werden,

- Support zu leisten bei der Bedienung der auscodierten Anwendungen sowie der Erstellung und Integration von individuellen Anwendungen.

Konstruktionsschema für Anwendungen

Mit diesen Forderungen haben wir ein wenig von außen an einem CARE-Paket geschnuppert. Bevor wir nach einer mildtätigen Organisation Ausschau halten, die uns damit versorgt, wollen wir es ein wenig aufschnüren und nachsehen, was dies Konzept für die Anwendungsentwicklung bedeutet.

Hierbei ist eine Aufteilung der vom gesamten Softwaresystem zu erbringenden Leistungen auf mehrere Schichten hilfreich, wie sie die Abbildung 1 zeigt und wie sie sich idealerweise in der Softwarekonstruktion (Modulstruktur) wiederfindet.

In der Interaktionsschicht erfolgt die Entkopplung der physischen Realisierung der benutzerbezogenen Ein- und Ausgaben von ihrem logischen Gehalt und die Navigation auf den von der Anwendung bereitgestellten Benutzerdaten, zum Beispiel durch

- Analyse der Benutzeraktionen und Umsetzung in logische Befehle

- Mischen der von der Anwendung gelieferten Daten mit der aktuell gültigen Darstellungsform (Formular, Tabelle, Text, Baum etc.)

- Wechsel der Darstellungsform

- Verschieben des physischen Fensters auf einem größeren logischen Fenster

- Ändern der Fenstergröße, -lage und des Vergrößerungsmaßstabs

- Anordnung der Daten im logischen Fenster

- Formalprüfung von Daten- und Befehlseingaben

- Aufruf lokaler Prüffunktionen.

Die Sitzungsschicht dient der logischen Steuerung der verschiedenen, parallel geführten Sitzungen eines Benutzers, zum Beispiel:

- Aufruf von anwendungsneutralen Funktionen

- Aufruf von Anwendungsfunktionen

- Durchführung des Sitzungswechsels

- Function-Shipping für verteil Anwendungen

- Prüfung funktionsbezogener Berechtigungen

- Steuerung der Dialogschrittfolge innerhalb einer Funktion

- Steuerung individueller Arbeitspläne

- Steuerung von Vorgangsnetzen

In der Funktionsschicht werden die von Interaktions- und Steuerungsschicht nicht bearbeitbaren Benutzerbefehle ausgeführt. Hierfür kommen anwendungsneutrale Funktionen und Anwendungsfunktionen zum Einsatz.

Anwendungsneutrale Funktion sind beispielsweise

- Anwendungs- und Funktionsauswahl (Menübrowser)

- Objektauswahl (Objektlistenbrowser)

- Vorgangsauswahl (Mailboxbrowser)

- Dictionaryverwaltung für verschiedene Objekttypen (Menüs, Objekte, Benutzerklassen, Dialoge, Vorgangsnetze, Nachrichtenarten, Netzknoten, Relationen, Views, Masken, Datenfelder, Domainen etc.)

- Driver für das Prototyping von Masken und Dialogen

- Querygeneratoren und entsprechende Interpreter

- Nachrichtenverwaltung für verschiedene Nachrichtentypen (Drucklisten, Hardcopies, Benutzernachrichten, Systemnachrichten, Interanwendungsdaten)

- Textverwaltung

- Administration von Parametertabellen

Die Schicht der Dienste wird von Modulen gebildet, die den Funktionen definierte Operationen auf Objekten (zum Beispiel Aufträge, Stückliste, Kunde, realer und dispositiver Materialbestand, Materialfluß, Kalender) zur Verfügung stellen.

Die Dienste verbergen, wie auch die Interaktions- und Sitzungssteurung, technische Details vor der Anwendung. Sie sorgen insbesondere für Aspekte der Datenintegrität, die von Datenbankmanagementsystemen (noch) nicht gewährleistet werden - referentielle Integrität.

Die unterste Schicht sorgt für die Datenzugriffe auch für verteilt gehaltene Daten. Die Dienste verwenden eine logische Sicht auf die Daten, die von der Zugriffsschicht entsprechend der physischen Organisation umgesetzt werden. Die Schnittstelle zwischen Diensten und Datenzugriffen ist normalerweise imbedded, das heißt, es handelt sich um eine SQL-Abfrage.

Bevor wir zur Positionierung von CARE innerhalb einer derartigen Architektur kommen, sollen einige Vorteile eine konsequenten Realisierung dieser Schichtenarchitektur skizziert werden. Konsequent heißt hier explizite Abgrenzung der Schichten durch statischen oder dynamischen Call beziehungsweise Program-to-Program-Communication und nicht das Verstecken in Hochsprachenkonstrukten oder Macros, die beim Kompilieren aufgelöst werden. Das bedeutet auch, daß die beiden oberen Schichten aufgrund von Dictionary-Information weitgehend interpretierend arbeiten müssen. Die beherrschenden Konstruktionsprinzipien sind Orthogonalität; also die Lösung verschiedener Probleme an verschiedenen Stellen, und Information-Hiding, also das Verstecken von Implementierungseigenschaft vor der Außenwelt.

Anhebung des Sprachniveaus ist der falsche Weg

Ihre konsequente Anwendung sorgt für die wesentlichen Vorteile:

- Die Benutzerschnittstelle kann weitgehend losgelöst von der Anwendung geändert werden, sowohl, bei Mißfallen der Anwender als auch bei Verfügbarkeit fortgeschrittener Hardware.

- Funktionale Verbesserungen des installierten DBMS oder sein Wechsel schlagen höchstens bis in die Ebene der Dienste durch (wenn man einmal nicht an die Wirksamkeit des SQL-Standards glaubt).

- Die Einheitlichkeit der Benutzerschnittstelle wird nicht durch Konvention erreicht, an die sich alle Produktentwickler halten müssen (wie bei SAA), sondern durch einmalige Implementierung.

- Die Ebenen liefern eine Entwurfsrichtlinie, die häufig für die Modularisierung einer Anwendung ausreicht.

- Die Anwendungsentwickler haben mit technischen Details weder auf der Daten- noch der Terminalseite etwas zu tun, sie können sich auf die reine Anwendungslogik konzentrieren.

- Portabilitätsüberlegungen betreffen nicht das komplette System, sondern nur die beiden oberen und unteren Schichten, also nicht den Anwendungskern.

- Die Schnittstellen zwischen den Ebenen liefern unterschiedliche Möglichkeiten zur Verteilung der Systemlast, zum Beispiel:

- Benutzerinteraktion auf PC/ Workstation, alles andere auf Abteilungsrechner oder Host.

- Datenzugriff und bestimmte Dienste auf Host, alles andere lokal.

- Die Funktionen der Interaktions- und Steuerungsebene lokal, die unteren Ebenen je nach Anwendung und Speicherungsort der Daten für jede der parallelen Sitzung komplett lokal oder zentral.

Ein CARE-Paket sollte die oberen beiden Schichten umfassen und möglichst viele der anwendungsneutralen Funktionen und Dienste zur Verfügung stellen. Für homogene Hard- und Basissoftware (etwa 3270 - Datenstrom und CICS) sind derartige Produkte seit einigen Jahren im Markt verfügbar. Manche Produkte der 4. Generation versuchen das Problem durch Anheben des Sprachniveaus zu lösen. Das scheint auch die Schlagrichtung von SAA durch das Common Programming Interface zu sein. Gebraucht wird aber etwas anderes. So wie das 3-Schichten-Modell nach ANSI-SPARC und das relationale Modell eine exakte logische Ebene für Definition und Zugriff auf Daten geliefert haben, werden entsprechende Modelle für das Interaktions- und Sitzungsmanagement benötigt, die allgemein akzeptiert sind und an denen sich die Produzenten orientieren können.

Liste der Benutzeraktionen ist die erste Voraussetzung

Die großen Hard- und Softwarehersteller werden eigene Modelle und darauf basierende Produkte entwickeln, deren Einsatz für einen Anwender ähnlich strategische Bedeutung haben werden, wie es die Entscheidung für ein bestimmtes Datenbankmanagementsystem bis heute war vor der allgemeinen Akzeptanz des relationalen Modells und SQL als Schnittstelle zwischen DBMS und Benutzer(programm).

Für Anwender können Frontend-Interpreter bedeutsam werden, in denen das technische Benutzerverhalten unterschiedlicher Produkte umgesetzt wird in ein gemeinsames Verhalten. Aber auch diese werden nur auf solche Produkte aufgesetzt werden können, für die ein einheitliches Benutzerverhalten implementiert ist. Erforderlich ist in jedem Fall eine Liste logischer Benutzeraktionen, für die die Abbildung 2 ein sicher unvollständiges Beispiel ist und die Prüfung, ob und wie die einzelnen Aktionen in einem zur Auswahl stehenden Produkt implementiert sind. Nur so kann bewertet werden, in welchem Ausmaß und zu welchen Kosten eine Angleichung an vorhandene Standards durch Produktanpassung beziehungsweise Frontend-Umsetzung möglich ist, beziehungsweise welche Inkompatibilitäten den Benutzern zugemutet werden.

Endziel sind Care-Pakete, die zu Anwendungen eine standardisierte logische Schnittstelle haben und Produkte, die ihre Benutzer-IO-Aktionen nur noch auf dieser logischen Ebene abwickeln, also unter beliebigen Care-Paketen ablaufen, die den Standards genügen.