Im Zeichen der zunehmenden Integration steigen auch die Anforderungen an dialogorientierte Systeme. Bei der Implementierung dieser Anwendungen gibt es deshalb oft in allen Projektphasen Probleme. Ein Konzept, das hier Abilfe schaffen soll, präsentiert Horst Böhm. Seine oberste Forderung heißt: strukturierter Aufbau der Applikationen.

Für die Beurteilung und zukünftige Neuausrichtung der heutigen Praxis der Systementwicklung von Dialoganwendungen sind zwei Phänomene entscheidend: die heutige Technik der Realisierung von Dialoganwendungen und die künftigen anwendungsbezogenen Anforderungen.

Jeder Dialog ist in Funktionalität und Realisierung durch vier Komponenten beschrieben:

- Masken,

- Dialogsteuerung (Verknüpfung der Masken),

- Kommunikationssteuerung (Informationsfluß zwischen Programm und Terminal/Nutzer),

- anwendungsspezifische Algorithmen.

Bei konventioneller Realisierung von Dialoganwendungen wird nur eine Komponente - die Maskenerstellung - separat behandelt; die übrigen drei Komponenten sind üblicherweise innerhalb eines Programmes realisiert und keinen besonderen Strukturierungsregeln unterworfen.

Während Masken häufig unter Mitwirkung der Fachabteilungen entstehen, sind die Endanwender bei der Dialoggestaltung nur eingeschränkt beteiligt. Denn die DV-Abteilung gibt viele Bestandteile des Dialoges wie Fehler-, Abbruch-, Help-Behandlung oder Verzweigungsmöglichkeiten fest vor.

Neue zusätzliche Wünsche der Fachabteilung werden häufig als "zu aufwendig abgewiesen". Darunter leidet in erster Linie die Qualität der Benutzerschnittstelle von Dialoganwendungen. Der angebotene Nutzer-Komfort der Lösung reicht oft nicht aus.

Drei anwendungsbezogene Anforderungen kennzeichnen die künftige Situation:

Zunehmende Anzahl von Dialoganwendungen

Moderne Anwendungssysteme werden überwiegend dialogorientiert konzipiert. Batchverarbeitung findet typischerweise nur noch als Folgeverarbeitung der Dialoganwendungen statt. Innerhalb der einzelnen Installationen wächst der absolute und relative Aufwand für Dialogkonzeption und Realisierung stark.

Verstärkter Einsatz "Geschäftsvorfallorientierter" Dialoganwendungen

Während herkömmliche Dialoge eher nach technischen Kriterien strukturiert sind, tritt für moderne Dialoge die Sicht des optimalen nutzerbezogenen Ablaufs in den Vordergrund: Das System führt den Nutzer und steuert sich selbst durch die Inhalte von Datenfeldern.

Solche "Geschäftsvorfall-orientierten" Dialoganwendungen sind durch eine Vielzahl von Masken und Verknüpfungen zwischen den Masken gekennzeichnet, deren softwaretechnische Ablaufsteuerung sehr komplex werden kann. Der Entwurf dieser Anwendungen erfordert ein Maximum an fachlichem und technischem Know-how. Prototyping-Techniken sind hilfreich, werden jedoch nur wenig eingesetzt, da oft entsprechende Werkzeuge fehlen.

Steigende Notwendigkeit der Kommunikation zwischen verschiedenen Dialoganwendungen.

Die in den vergangenen Jahren entstandenen Anwendungen müssen integriert benutzt werden können. Der Anwender erwartet eine Benutzeroberfläche, die es ihm gestattet, zum Beispiel seinen aktuellen Dialog "einzufrieren" und nahtlos andere Dialogsysteme zu betreten, in denen er sich spezielle Informationen (zum Beispiel Vertragsdaten, Inkassodaten, Anschriftdaten) beschafft. Dieser Zwang zur Anwendungsintegration vergrößert die Dialogsteuerungsproblematik und damit den Implementierungsaufwand.

Heutige Probleme der Realisierung von Dialoganwendungen betreffen alle Projektphasen:

- Es gibt keine praxisbewährte Spezifikationssprache für Mainframe-Dialoganwendungen; echtes Prototyping für solche Systeme erfordert die Wiederverwendbarkeit des Prototypen. Es scheitert an der nahtlosen Verfügbarkeit von Prototyp-Spezifikation in DV-Realisierungscode.

- Die heute erstellten Dialogspezifikationen verlieren während des Software-Life-Cycles in der Regel ihre Gültigkeit, weil die Wartung auf Ebene des Realisierungscodes erfolgt.

- Unabhängig von der funktionalen Komplexität der Anwendungs-Logik ist ein großer technischer Aufwand im Umgang mit dem Dialog-Träger-System erforderlich. Dieser Aufwand steigt mit zusätzlichem Benutzerkomfort überproportional an.

- Der Aufwand zur Implementierung der "Kommunikations-/Dialogsteuerung" muß für jeden neuen Anwendungskomplex mehr oder weniger neu erbracht werden; zwar lassen sich bestehende Lösungen kopieren und adaptieren, der Anpassungs- und Testaufwand ist jedoch in den meisten Fällen noch beträchtlich. Die Fehleranfälligkeit der adaptierten Lösungen ist hoch, da die Transparenz der Lösung verlorengeht.

- Die Erweiterungsspielräume für konventionell realisierte Dialoganwendungen sind entsprechend stark eingeschränkt.

- Der Wartungsaufwand für konventionell realisierte Dialoganwendungen steigt wegen der Vermischung von Steuerungs- und Anwendungsfunktionen stark an. Änderungen werden risikoreicher wegen der Komplexität der Steuerungsprogramme einerseits und der fehlenden Spezifikation andererseits.

Die Ursachen für diese Probleme sind darauf zurückzuführen, daß - im Gegensatz zu Batch-Anwendungen - noch keine anerkannte Methode für den Entwurf und die Realisierung von Dialoganwendungen existiert. Hier deshalb der Vorschlag für eine solche Methode und ihre maschinelle Unterstützung durch Tools:

Es empfiehlt sich, Dialoganwendungen strukturiert, normiert beziehungsweise standardisiert aufzubauen und sie anschließend aus der Spezifikation heraus zu generieren. Die Strukturierung und Normierung von Dialoganwendungen erfolgt über Separierung und Standardisierung.

Separierung

Die vier Dialogkomponenten (Masken, Kommunikationssteuerung, Dialogsteuerung, Anwendungsfunktionen) müssen während der Spezifikation und Realisierung deutlich unterschieden werden. Die Dialogsteuerung verknüpft die übrigen drei Komponenten miteinander.

Standardisierung

Die Bausteine, mit denen sich jede Dialoganwendung einfach beschreiben läßt, sind zu standardisieren. Die Analyse einer Vielzahl von Anwendungsdialogen in verschiedenen Einsatzgebieten zeigt, daß sich die Steuerung jedes Dialoges im wesentlichen aus den Bausteinen Knoten, Bilder, Verbindungen, Anwendungsfunktionen und Absichten zusammensetzt.

Diese Komponenten müssen dem Nutzer durch eine einfache Sprache zugänglich gemacht werden, in der er seinen Dialog vollständig beschreiben kann, und zwar mit Begriffen, in denen er als Enduser handelt und denkt. Rücksprünge, Ausflüge in andere Anwendungssysteme und Doppelverwendung von gleichen Bildern in verschiedenen Applikationen müssen problemlos formulierbar sein, ebenso wie Abbruch-, Fehler- und Ende-Behandlung. Die Spezifikation sollte ferner frei sein von technischen Details des Multi-User-Betriebes beziehungsweise der Kommunikationssteuerung.

Eine geeignete Spezifikationssprache könnte beispielsweise im wesentlichen aus den Konstrukten Dialog, Bild, Verbinde, Absicht, Variable und Ausflug bestehen. Mit Hilfe dieser Elemente lassen sich sowohl hierarchische als auch netzwerkartige Strukturen realisieren.

Die Spezifikationssprache sollte eine gemeinsame Kommunikationsbasis für Fach- und DV-Abteilung darstellen. Ein solches Konzept ist dringend erforderlich, da erst die Kombination von maximalem Fachabteilungs- und DV-Wissen zu optimalen Ergebnissen führt.

Der Einsatz von Generatoren ist nur dann sinnvoll und effizient, wenn es gelingt, sich wiederholende Vorgänge zu standardisieren. Deshalb sollte aus der Dialog-Spezifikation heraus der gesamte Code zur Steuerung des Dialoges maschinell erstellt werden, können. Dies kann auf dem Wege der Generierung von Source Code mit anschließender Compilierung erfolgen oder aber über Generierung von Code, der "at-run-time" interpretiert wird.

Die Generierung von Source-Code bietet mehrere deutliche Vorteile:

- Zum einen ist das Generierungsergebnis ohne das Generierungswerkzeug lauffähig. Dadurch können Abhängigkeiten vermieden werden.

- Außerdem läßt sich die Abarbeitung von Object-Code, der aus dem Source-Code durch Compilierung erzeugt wird, "at-run-time" fast immer schneller realisieren als die interpretative Durchführung.

Durch Einsatz einer Spezifikationssprache mit anschließender Generierung aus der Spezifikation heraus wird das zentrale Wartungsproblem - Auseinanderlaufen von Spezifikations- und Realisierungscode - eliminiert: Die Wartung findet ausschließlich auf der hohen Abstraktionsebene statt, Spezifikation und Realisierung stimmen immer überein. Änderungen können auf diesem Weg sicher und schnell implementiert werden.

*Horst Böhm ist Direktor für Marketing und Vertrieb bei der SWT GmbH, Bonn.

Aus: Kongreßband VI der Online '87, 10. Europäische Kongreßmesse für Technische Kommunikation vom 4. bis 7. Februar 1987 in Hamburg. Die Veröffentlichung kann bei der Online GmbH, Postfach 10 08 66 in 5020 Velbert 1, bestellt werden.