Unübersichtlicher Maskenaufbau schafft unnötige Schwierigkeiten:

TP-Monitor muß Benutzer "an die Hand" nehmen

20.02.1987

Im Bürobereich stellt sich ein transaktionsorientiertes System durch seine Masken und Ablaufe dar. Ein einheitliches und verständliches Design dieser Funktionen stellt sicher, daß der Benutzer sich mit diesem Hilfsmittel relativ schnell anfreunden kann. Bernd Voß* ergänzt seinen Überblick durch ein Betspiel aus der Praxis.

In den meisten Systemen stellt der TP-Monitor einerseits "nur" eine Task oder Region dar, andererseits verfügt er fast immer über Fähigkeiten des Betriebssystems oder ist letztlich im Betriebssystem eingebettet. Dies wird damit begründet, daß der Monitor vielen Benutzern kleine Antwortzeiten bieten muß, was nur mit einem System erreicht werden kann, das klug die Schwächen des Betriebssystems überdeckt. An dieser Einbettung wird sich vermutlich auch künftig nicht viel ändern lassen, und so werden sich TP-Monitore wie Betriebssysteme verschiedener Hersteller auch künftig unterscheiden. Diese Einbettung hat leider weitreichende Folgen für die Anwendungsentwicklung.

Der TP-Monitor bietet Schnittstellen zu Programmiersprachen, die aus Anwendungsprogrammen heraus und ähnlichen Ein-/Ausgabe auf Sichtgeräte und Drucker, Zugriffe auf Dateien/Datenbanken, die Benutzung von privaten oder allgemeinen Speicherbereichen, Steuerung von Programmen und Prozessen ermöglichen sowie Dienstfunktionen etwa für Recovery zur Verfügung stellen. Mit diesen Interfaces lassen sich, teilweise in Konkurrenz zur Betriebssystemebene, ähnliche Möglichkeiten für Anwendungsprogramme im TP-System schaffen. Begründet wird dies häufig damit, daß Anwendungsprogramme nicht direkt Unterbrechungen der TP-Region herbeiführen dürfen, da diese das Zeitverhalten schwer belasten.

Zielgerechte Übersetzung ist die bessere Lösung

Beispiel ist etwa die Anforderung der aktuellen Zeit. Erfolgt dies in einem Cobol-Programm durch ein "ACCEPT TIME", verliert der Monitor die Kontrolle; er muß warten, bis er wieder aktiviert wird. Folglich stellt der Monitor einen entsprechenden eigenen Aufruf zur Verfügung. Es bleibt die Frage, wie der sprachmäßige Aufruf im Programm unterbunden wird. Eine bessere Lösung ist die, daß der Compiler zielgerecht übersetzt - vorausgesetzt er kann zwischen Stapel- und Dialogprogrammen unterscheiden.

Große Probleme können sich dort ergeben, wo Funktionen zur Verfügung gestellt werden, die im Bereich kommerzieller DV in den üblichen Programmiersprachen normalerweise sich verfügbar sind und nur von der Systemprogrammierung benutzt werden. Ein "Wait" oder ein "Enqueue" etwa haben im Bereich der Anwendungsprogrammierung nichts zu suchen. Es ist sogar fraglich, ob solche Möglichkeiten überhaupt verfügbar sein müssen beziehungsweise ob nicht schlechtes Design des Monitors solche Funktionen erforderlich macht.

Aus der Sicht der Anwendungsentwicklung lassen sich die verfügbaren Funktionen etwa so klassifizieren: Funktionen des eigentlichen Monitors wie Bildschirm-Handling oder Zugriffe auf Ressourcen wie Datenbanken und Speicher, Hilfsfunktionen zur Erleichterung des täglichen Lebens und Systemfunktionen, deren Benutzung vermieden oder mindestens überwacht werden muß. Für einen Monitor sollte es Möglichkeiten geben, den in Richtung Anwendungsprogrammierung stehenden Funktionsumfang zu beschränken oder in geordnete Bahnen zu lenken. Der Monitor ist mehr oder weniger durchlässig für Anwendungsfehler. "Normale" Programmfehler dürfen nicht zum Absturz des gesamten Monitors führen. Dieser muß also in der Lage sein, Auswirkungen der Fehlersituation klein zu halten. Der Monitor sollte beim Bediener im Büro die Fehlersituation verständlich darstellen und erklären, oder ein spezielles Anwendungssystem mit dieser Aufgabe beauftragen können.

Die Schnittstellen werden üblicherweise in den Programmiersprachen der kommerziellen DV zur Verfügung gestellt, also etwa in Cobol und PL/1. Precompiler (Translator) dienen dazu, Monitoraufrufe im Sinne der benutzten Sprache aufzubereiten.

Die Einbettung der Monitorfunktionen wird mehr oder weniger luxuriös gelöst mit CALL-Schnittstellen oder auf der Basis sprachnaher Ergänzungen. Die Ergänzungen vieler Hersteller sind ähnlich und vergleichbar, aber syntaktisch immer verschieden. Herstellerwechsel beim Monitor schlagen auf alle Anwendungsprogramme durch und verbieten sich somit von selbst.

Beste Lösung wäre die direkte Einbettung der Funktionen in eine Programmiersprache wie Cobol als Bestandteil der herstellerunabhängigen Sprache. Einen Kompromiß stellt etwa die standardisierte KDCS-Schnittstelle dar, bei der allerdings einige Systemeigenschaften auf die Anwendungsprogramme durchschlagen.

Mit einigen Funktionen werden die Ziele höherer Programmiersprachen unterlaufen. Ein Beispiel ist das Halten von Adressen in Anwendungsprogrammen, wobei diese Adressen gewöhnlich numerische Felder sind die sich mit einfacher Arithmetik beliebig manipulieren lassen beziehungsweise manipuliert werden müssen. Ähnlich steht es mit den sehr systemnahen Funktionen wie WAIT oder ENQEUE. Umgekehrt enthalten Programmiersprachen

Sprachteile, die nur schwer zu Monitoren passen beziehungsweise deren Benutzung in einer Monitor-Umgebung zu verhindern ist. Solche Probleme würden geeignetere Sprachen mit direkter RP-Unterstützung nicht enthalten.

Im TP-Bereich werden in der Regel Programme häufig aufgerufen. Die Fähigkeit, Reentrant-Code oder mindestens Reusable-Code zu erzeugen, ist deshalb eine notwendige Leistung des Compilers. Dabei ist es wichtig, daß die Erzeugung von Reentrant-Code nicht von der Einhaltung unüblicher Konventionen abängig ist.

Im Bereich der Standard-Software stehen unabhängige Systeme zur Verfügung, die nach der Generierung ohne sonstige Programmierung im Büro benutzbar sind und abhängige Systeme, die in die Anwendungen eingebettet werden müssen. Eine Mischung stellen Textverarbeitungssysteme dar, die in Applikationen eingebettet völlig automatisch oder als eigengeständiges System Textverarbeitung realisieren. Der Einsatz von Standard-Software ist heute leider mehr davon abhängig, daß die funktionalen Anforderungen abgedeckt werden als davon, wie sie in die vorhandene Umgebung passen. Da fast nie Anpassungsmöglichkeiten gegeben sind, entstehen Systeme mit unterschiedlichen Oberflächen.

Für den Entwurf gut strukturierter Masken lassen sich viele allgemeingültige Regeln oder Normen finden. Die Einhaltung solcher festzuschreibenden Regeln muß durch zentrale Abnahmen und Freigaben im Sinne qualitätssichernder Maßnahmen kontrolliert werden.

Maskenfolge muß für User leicht verständlich sein

Wie die folgenden Beispiele zeigen, gibt es dafür einfache Regeln:

- Die Benutzung von Abkürzungen ist nur zulässig, wenn diese auch im Bereich des Benutzers üblich sind.

- Übersichtliche Masken sind gewährleistet, wenn Texte und Daten in Kolonnen links- und rechtsbündig untereinander erscheinen. Unruhe entsteht, wenn beim Maskenwechsel die begrenzenden Spalten wandern.

- Viele Felder auf einer Maske machen diese unübersichtlich.

- Die Bedienung der Felder muß sich bei ähnlichen Inhalten gleichen.

Ein Datum wird immer auf die gleiche Art und Weise in möglichst üblicher Form erfaßt (Beispiel 27. 06. 87 und nicht 06/27/ 87 oder gar 87178 - Industriekalender).

- Ähnliches gilt für Zahlen: Der Benutzer verwendet ein ihm aus seinem täglichen Leben bekanntes Format: 123,45 und nicht etwa 000123.450. Maßeinheiten wie "%" oder "DM sind Bestandteil der Maske

- Für Textfelder wie auch Fehlermeldungen und Feldbeschreibungen gilt die übliche Groß-/Kleinschreibung

- Fehlermeldungen sind einfache Sätze in (deutscher) Sprache oder Fremd- und DV-Fachwörter.

Der Ablauf als Folge von Masken muß für den Benutzer immer verständlich und durchsichtig sein. Eine Bedingung dafür ist die im gesamten System gleiche Benutzung der Steuerungsmöglichkeiten durch Eingaben oder Funktionstasten. Steuerungsfelder müssen auf Masken immer an gleicher Stelle zu finden sein. Die Wirkung der Funktionstasten muß alternativ durch Eingabe anderer Begriffe erzielbar sein.

Überall im System sollte es Helpfunktionen geben, die Inhalte von Feldern beschreiben oder Wertevorräte anzeigen. Bei Abläufen über mehrere Masken sind Blätterfunktionen notwendig. Dabei ist es häufig ausreichend, wenn seitenweise rückwärts und vorwärts geblättert werden kann. Wichtig ist eine "Papierkorbfunktion", mit der sich einzelne Abläufe stornieren lassen, ohne daß Spuren im System hinterlassen werden.

Ein Beispiel aus der Praxis: Bei der Realisierung eines TP-Konzeptes für eine Bausparkasse sollte ein System entstehe, das alle Bereiche der Kundenbetreuung einer Bausparkasse unterstützt. Dabei erfolgt die Betreuung der Kunden durch regional orientierte Sachbearbeitergruppen, die ihre Kunden in allen Fragen vom Abschluß eines Bausparvertrages bis zur Rückzahlung des Darlehens betreuen. Da Sachbearbeitung sofort und abschließend "auf Zuruf" erfolgen kann, müssen Vorgänge ohne Papierakte mit aktuellen Daten vollständig in einem Zuge abgewickelt werden können.

Das auf der Basis von CICS und IMS realisierte System umfaßt heute etwa 400 Online-Programme (Cobol-Command Level) mit 300 Masken.

Das Ziel, "jedem Sachbearbeiter jede Funktion" zu bieten, läßt einen Sachbearbeiter bei einer Fülle von Funktionell in jeder Funktion nur als Gelegenheitsbenutzer oder neuen Benutzer erscheinen.

Das Konzept sieht vor:

- Einheitlicher Maskenaufbau mit feststehendem Fuß beziehungsweise Kopf (siehe Abbildung 1 )

- Steuerung über sogenannte numerische Aktionsschlüssel, diese lassen sich leichter merken als Buchstabenkürzel

- Hierarchische Struktur mit einem Hauptmenü und beliebig vielen Untermenüs, deren Inhalt die Geschäftsvorfälle sind.

- Feste Vergabe der Funktionstasten

- Help-System

- Geschäftsvorfälle bestehen aus Anfang-, Mittel- und Updateprogramme.

- Die Steuerung erfolgt durch Steuerprogramme

- Zu jedem Zeitpunkt kann bedienergesteuert der aktive Geschäftsvorfall durch einen anderen ersetzt werden.

- Geschäftsvorfälle können von Bediener zu Bediener geleitet werden.

In der realisierten Lösung existiert je Benutzer eine Inhaltsübersicht der begonnenen, aber nicht abgeschlossenen Geschäftsvorfälle sowie der übergebenen Geschäftsvorfälle in der Benutzer-Datenbank (siehe Abbildung 2). Die Geschäftsvorfälle und Nachrichten befinden sich in einer Vorgangsdatenbank in Form von logischen Masken (entsprechend der Benutzung in Programmen).

Verläßt ein Sachbearbeiter eine Funktion vor Update, bleiben die Inhalte der Benutzer-DB und der Vorgangs-DB erhalten. Zusätzlich wird im Monitor für angemeldete Benutzer der Zustand des entsprechenden Vorgangs festgehalten. Solange der Zustand vorhanden ist, kann direkt auf die unterbrochene Maske zurückgekehrt werden. Bei Verlust muß der unterbrochene Vorgang mit der Einstiegsmaske wieder aufgenommen werden, damit der Zustand anhand der Masken neu aufgebaut werden kann.

Auf Unterprogrammtechnik wurde verzichtet

Für die vier definierten Programmarten existieren Rahmenprogramme, deren Benutzung obligatorisch ist. In den Rahmenprogrammen werden einfache Parameterleisten verändert und an fest definierten Stellen anwendungsbezogene Programmteile eingebaut. Auf Unterprogrammtechnik wurde wegen diverser, damit verbundener Adressierungsprobleme im CICS verzichtet.

Es ist eindeutig definiert, welche Funktionen durch die einzelnen Programmarten abgedeckt werden. Einleitungs-, Mittel- und Updateprogramme ähneln einander stark (siehe Abbildung 3). Jedes Programm realisiert eine Maske in einem Ablauf. Die Programme kennen von ihrer Umwelt nur das zugehörige Steuerprogramm.

Ein Mittelprogramm wird an zwei Stellen um anwendungsspezifische Teile ergänzt:

- Für die ersten Ausgaben der Maske wird ein Programmteil gebraucht, der notwendige Daten aus Datenbanken beschafft und den Anwendungsteil der Maske füllt.

- Bei jedem Empfang der Maske wird der Anwendungsteil unter anderem auf Richtigkeit geprüft.

Anwendungsteil und Rahmenprogramm kommunizieren über einen Parameter, der bei Korrektheit der Eingabemaske vom Anwendungsteil gesetzt wird. Dies führt zur Speicherung der Maske in der Vorgangs-DB und Rückkehr zum Steuerprogramm. Üblicherweise bleibt eine Maske solange auf dem Bildschirm des Sachbearbeiters, bis alle Fehler beseitigt sind. Die Fehlermeldungen betreffen immer den ersten Fehler auf der Maske, fehlerhafte Felder werden durch

Farbe beziehungsweise helles Leuchten kenntlich gemacht.

Die Mittelprogramme pflegen mit Ausnahme der Vorgangs-DB keine Dateien oder Datenbanken. Einleitungsprogramme prüfen und vergeben neue Schlüsselbegriffe und initialisieren außerdem die Benutzer- und Vorgangs-DB. Die abschließenden Programme behandeln die Segmente der Vorgangs-DB; ferner prüfen sie die Updates und führen diese durch (einschließlich der Löschungen in der Benutzer- und Vorgangs-DB).

Der Ablauf der Programme wird durch die Steuerprogramme kontrolliert. Sind sie alle gleich, sieht man von den Tabellen mit den zum Steuerprogramm gehörenden Bildschirmprogrammen ab. Je Untermenü exisitert ein Steuerprogramm. Die Steuerprogramme kennen in der Hierarchie nach oben nur das Hauptsteuerprogramm.

*Bernd Voß ist Projektleiter Banken und Versicherungen bei SCS, Hamburg.