Dialogmanager - GDV

Werbung
Gesamtverband der Deutschen
Versicherungswirtschaft e.V.
Prozesse
Objekte
Funktionen
Daten
Komponenten
Request Broker
VAA
Edition
1999
Die Anwendungsarchitektur der Versicherungswirtschaft
DIALOGMANAGER
VERSION 2.1
PROZEDURAL
© GDV 1999
http://www.gdv.de/vaa
Autoren:
Administration, Koordination:
http://www.gdv.de/vaa
VAA-Projektteam Dialogmanager
Gesamtverband der Deutschen Versicherungswirtschaft e. V., Berlin
© GDV 1999
Dialogmanager
Willkommen bei VAA Edition 1999!
Liebe Leserin, lieber Leser,
haben Sie bereits eine der Broschüren der VAA Edition 1999 gelesen? Wenn ja, können Sie gleich
weiter blättern, denn dieses Kapitel steht gleichlautend am Anfang jedes Dokuments dieser VAAEdition.
Ansonsten freuen wir uns über Ihr Interesse an der VAA und gratulieren Ihnen zu Ihrer Entscheidung,
sich mit diesem Thema zu beschäftigen, an dem wir seit Jahren mit großem Engagement und immer
noch mit viel Spaß arbeiten.
Mit WIR sind alle gemeint, die sich in den letzten Jahren direkt an der Arbeit in den VAA-Gremien
beteiligten. Um wen es sich dabei im einzelnen handelt, können Sie in einem Anhang der Broschüre
ANFORDERUNGEN UND PRINZIPIEN nachlesen, darüber hinaus werden die VAA-Gremien auf der neuen
VAA-CD und im Internet (Adresse http://www.gdv.de/vaa) vorgestellt.
Nun zur Sache:
Die VAA wurde in den vergangenen zwei Jahren in zwei Richtungen weiterentwickelt.

Der erste Schritt in Richtung Objektorientierung ist getan. Sie finden in der VAA Edition 1999 das
OBJEKTORIENTIERTE FACHLICHE REFERENZMODELL
und das OBJEKTORIENTIERTE TECHNISCHE
REFERENZMODELL der VAA. Das Geschäftsobjekt PRODUKT wurde bereits detailliert ausgearbeitet.

Die prozedurale Variante lebt weiter. Sie wurde ergänzt um eine weitere fachliche Komponente,
INKASSO/KONTOKORRENT.
Darüber hinaus wurden die aufgrund der Aufnahme der Objektorientierung notwendig gewordenen
Überarbeitungen und Ergänzungen der Dokumente der 2. Auflage von VAA vorgenommen. Es
entstand eine Vielzahl von zum Teil sehr umfangreichen Dokumenten, die auf drei Wegen
veröffentlicht werden: CD-ROM, Internet und als gebundene Broschüren in Papierform.
Um Ihnen die Orientierung zu erleichtern, haben wir als Übersicht über die verfügbaren
Dokumentationen der VAA Edition 1999 einen grafischen Wegweiser erstellt, den Sie auf der
nächsten Seite finden können. Vielleicht hilft er Ihnen, sich zurechtzufinden und Ihre
Schwerpunktthemen "herauszufischen".
Viel Spaß beim Studium des hier und in den übrigen Dokumenten zusammengestellten VAAWissens.
© GDV 1999
http://www.gdv.de/vaa
Dialogmanager
Dokumentenstruktur der VAA Edition 1999
Anforderungen und Prinzipien
neu
Glossar
überarbeitet
VAA prozedural (pVAA) Version 2.1
Prozeduraler Rahmen
neu
Fachliche Beschreibung
Inkasso/Kontokorrent
neu
Partner
Partner/Anhang
Provision
überarbeitet
Schaden/Leistung
Vertrag
Technische Beschreibung
Datenmanager
Datenmanager/Anhang
Dialogmanager
Parametersystem
Workflow-/Vorgangsmanager
VAA objektorientiert (oVAA) Version 1.0
Objektorientiertes fachliches Referenzmodell
4
Hauptdokument
neu
Anhang A – Use-Case-Modell –
neu
Anhang B – Klassenmodell –
neu
Modell in Rational-Rose-Format
neu
Objektorientiertes technisches Referenzmodell
neu
Produkt
neu
© GDV 1999
Dialogmanager
I.
Inhalt
Abgrenzung und Wirkungsweise der Steuerungskomponente ........................ 3
I.1.
Beschreibung der Steuerungskomponente „Dialogmanager“ ....................................................... 3
I.1.1.
Einleitung und Problemstellung ............................................................................................ 4
I.1.2.
Funktionale Anforderungen ................................................................................................. 12
I.1.3.
Technische Anforderungen ................................................................................................. 32
I.1.4.
Anforderungen an Schnittstellen ......................................................................................... 33
I.2.
Abgrenzung, Einschränkungen und offene Punkte ..................................................................... 35
I.3.
grundlegende Bauprinzipien und Algorithmen ............................................................................ 35
II. Schnittstellenbeschreibung .............................................................................. 36
III.
III.1.
IV.
vorhandene Produkte und aktuelle Entwicklungen ...................................... 36
vorhandene Produkte .............................................................................................................. 36
Anhang ............................................................................................................. 37
IV.1.
Literaturverzeichnis ................................................................................................................. 37
IV.2.
Mitwirkende ............................................................................................................................. 38
IV.2.1.
eteiligte Firmen ................................................................................................................... 38
IV.2.2.
Beteiligte Personen ............................................................................................................. 38
© GDV 1999
i
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
I. Abgrenzung und Wirkungsweise der
Steuerungskomponente
I.1. Beschreibung der Steuerungskomponente
„Dialogmanager“
In diesem Abschnitt der Spezifikation soll die VAA-Steuerungskomponente
„Dialogmanager“
in ihrer groben, technischen Arbeitsweise sowie ihr Zusammenspiel mit den weiteren
Steuerungskomponenten
 Workflowsteuerung und
 DV-Vorgangssteuerung
beschrieben werden.
Ziel dieser Spezifikation ist eine Grobbeschreibung aus der mehr „fachlichen“ Sicht und die
Darstellung von Zusammenhängen. Die Festlegung von technischen Einzelheiten bleibt
einer Feinspezifikation vorbehalten, die jedoch erst als direkte Vorphase einer
Implementierung erfolgen sollte, um eventuelle Implementierungsnotwendigkeiten hierbei
ausreichend berücksichtigen zu können.
© GDV 1999
3
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.1. Einleitung und Problemstellung
Moderne Softwaresysteme sind geprägt durch eine ausgefeilte, bedienerfreundliche
Benutzerinteraktion, d. h. die Sachbearbeitung wird mittels eines sachgerechten, leicht
nachvollziehbaren Dialogs zwischen dem Sachbearbeiter und dem Computer durchgeführt.
In der Vergangenheit war das Softwaresystem nicht oder nur unzureichend in den rein
fachlichen Teil der Sachbearbeitung und den Interaktionsteil (Dialog) getrennt. Diese
mangelnde Separierung führte und führt sowohl bei Fehlersituationen bzw. bei fachlichen
Erweiterungen oder technischen Neuerungen im Bereich der Informationsdarstellung (z. B.
grafische Benutzeroberflächen) zu unüberschaubaren Modifikationen oder häufig gar zur
Neuprogrammierung.
Ziel der VAA-Architektur muß es daher sein, beide Teile strikt voneinander zu trennen,
gegeneinander zu kapseln und den immer wieder relativ gleich ablaufenden Dialogteil durch
eine entsprechend wiederverwendbare, allgemeingültige VAA-Steuerungskomponente zu
unterstützen.
Die Steuerungskomponente, die diese Aufgabe innerhalb der VAA übernimmt, wird
„Dialogmanager“
genannt.
Folgt man der bisher beschriebenen Aufgabenteilung, so muß der Dialogmanager folgende
Aufgaben übernehmen:
 Dialogsteuerung
Die im Rahmen eines Vorgangsschrittes (Elementarprozeß) zwischen dem
Anwendungssystem und dem Benutzer notwendig durchzuführende Interaktion ist zu
steuern. Dabei muß diese Dialogsteuerung möglichst auf die Gegebenheiten des
Benutzers flexibel eingehen können, um so dem Benutzer neben der Zufriedenheit über
die Arbeitsweise auch die notwendige Effizienz und Sicherheit bei der Durchführung
dieser Tätigkeit zu vermitteln bzw. zu ermöglichen. Hierzu bedarf es zusätzlicher Normen
und Standardisierungen wie z. B. Bildschirmstandards, Dialogführungsstandards u. a. m.
 Input/Output-Verarbeitung
Die für die Bearbeitung benötigten Informationen sind dem Benutzer zu präsentieren
(Output) und etwaige Eingaben (Input bzw. Kommandos) sind zu verarbeiten und zu
validieren.
 Schnittstellenbearbeitung
Für die Kommunikation zwischen fachlicher Anwendung und Dialogmanager ist eine
standardisierte Schnittstelle zur Verfügung zu stellen. Im Rahmen dieser Schnittstelle sind
folgende Aufgaben wie Transformationen, Synchronisation u. a. m. zu erledigen. Hierbei
ist insbesondere auf Kapselung und Entkopplung zu achten.
4
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
 Entwicklerunterstützung
Die für den Dialogmanager notwendigen Entwicklungsinformationen (Sourcen) sind im
Rahmen einer Entwicklungsunterstützung (Werkzeug/Tool) bereitzustellen. Auch für
diese Funktionalität ist im Sinne einer effizienten Entwicklungsunterstützung eine
umfassende Lösung vorzusehen.
I.1.1.1. Der Begriff „Dialogsteuerung“
Um die VAA-Steuerungskomponente „Dialogmanager“ exakt spezifizieren zu können, ist
zunächst die gemäß VAA-Architektur vorgesehene
Steuerungs-Ebene
genauer zu beschreiben und sind unterschiedliche Steuerungsarten zu klassifizieren.
Ziel dieser Klassifikation ist es, den unterschiedlichen VAA-Steuerungskomponenten „ihre
Aufgaben“ zur Steuerung einer Anwendung zuzuordnen und die Steuerungskomponenten
auch untereinander abzugrenzen.
Die unterschiedlichen Arten der Steuerung in einem VAA-Anwendungssystem
(Klassifizierung) sind:

Workflow-Steuerung

Vorgangssteuerung (DV-Vorgang)

Dialogsteuerung

Anwendungssteuerung
Im folgenden werden diese Steuerungsarten näher beschrieben:
 Workflow-Steuerung
© GDV 1999
5
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Diese Steuerungsart umfaßt sämtliche Steuerungsformen für die Be- bzw. Verarbeitung
von Geschäftsprozessen bzw. deren Management. Die Funktionen werden vom
Workflow-Manager
zur Verfügung gestellt und im Regelfall durch den Endbenutzer ausgeführt. Eine APISchnittstelle ermöglicht jedoch auch die Aktivierung einer solchen Steuerungsfunktion
aus der Anwendung heraus.
Beispiele von Workflow-Steuerungsfunktionen:
 Initialisieren eines Workflows (Geschäftsprozess)
 Unterbrechen eines Workflows
 Wiederaufnahme eines Workflows
 Weiterleiten eines Workflows
 Verbinden zweier oder mehrerer Workflows zu einem übergeordneten Workflow
 Anzeigen zugeordneter Workflows zu einem Sachbearbeiter
 Löschen eines Workflows
 Suspendieren eines Workflows
 Vorgangssteuerung
Die DV-Vorgangssteuerung übernimmt die Aufgabe der Steuerung durch einen
Teilprozeß (Geschäftsprozeß) gemäß einem vorgegebenen, formalen Prozeßmodell für
den entsprechenden Teilprozeß. Die Steuerung wird in der Regel automatisch durch den
Vorgangspartner durchgeführt.
Beispiele von Vorgangssteuerungsfunktionen:
 Aktivieren eines Prozeßmodells
 Aktivieren eines Elementarprozesses
 Ermittlung des nächsten Prozeßschrittes
 Unterbrechen eines DV-Vorgangs
 Rücksetzen eines durchgeführten Arbeitsschrittes
 Protokollieren/Tracen eines Prozeßschrittes
6
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
 Dialogsteuerung
Die Dialogsteuerung steuert eine Interaktionsfolge mit dem Endbenutzer. Ziel dieser
Interaktion ist es, dem Endbenutzer die Durchführung eines Elementarprozesses
(Prozeßschritt) zu ermöglichen, der nicht automatisch durch einen Baustein (Programm)
auf einer DV-Anlage ohne manuellen Eingriff durchgeführt werden kann. Die
Dialogsteuerung wird von der DV-Vorgangssteuerung bzw. Workflowsteuerung aktiviert,
nimmt danach Steuerungsbefehle durch den Endbenutzer entgegen und gibt nach
Eingabe von Informationen an ihrem Ende die Kontrolle an die DV-Vorgangssteuerung
bzw. Workflowsteuerung zurück. Dabei ist der Aufruf der Dialogsteuerung sowohl
synchron als auch asynchron möglich: Bildschirm, Liste, Formulare (Vertrag ...), Fax.
 Anwendungssteuerung
Die Anwendungssteuerung übernimmt die prozedurale Steuerung (Verbindung) von
Funktionsbausteinen zu einer höheren Granularität eines Bausteins (Anwendungs- bzw.
Funktionsbaustein).
Die Steuerung ist vorgegeben und wird von der Maschine ausgeführt.
Ziel ist die Zusammensetzung von wiederverwendbaren Modulen (Elementarfunktionen)
zu höherwertigen, fachlichen Bausteinen.
Beispiel:
Eine „Tarifmaschine“ zur Tarifberechnung sämtlicher Versicherungsarten (Produkte).
© GDV 1999
7
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.1.2. Das Zusammenspiel der Dialogsteuerung mit den anderen
Steuerungsarten
Neben der Definition der Steuerungsarten ist ihr Zusammenspiel von besonderem Interesse,
um die notwendige Funktionalität der entsprechenden VAA-Steuerungskomponenten
spezifizieren zu können.
Das Zusammenspiel der vier Steuerungsarten läßt sich am besten an der nachfolgenden
Grafik veranschaulichen (technischer Kontrollfluß):
Steuerungshierarchie
Geschäftsprozeß
Teilprozeß
Elementarprozeß
W
W
V
V
Dia.....
Anw....
V
D
V
D
A
A
W
V
D
A
8
-
Workflow
Vorgangssteuerung
Dialogsteuerung
Anwendungssteuerung
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Während ein „Dialog“ im Sinne der Architektur die Interaktionsfolge zur Realisierung eines
Elementarprozesses ist, kann der Dialog aus Sicht des Endbenutzers eine Interaktionsfolge
sowohl aus D-Steuerung, V-Steuerung und W-Steuerung sein, da der Endbenutzer die
Grenzen der jeweiligen Steuerungsarten nicht wahrnehmen kann, ja sogar nicht
wahrnehmen sollte.
I.1.1.3. Der Begriff „Dialog“
Gemäß der bisher vorgenommenen Definitionen und Erläuterungen ist es nun möglich, den
im Software-Engineering bekannten Begriff des „Dialoges“ innerhalb der VAA konform zu
benutzen, ihn sogar durch die konkreten Umfeldbedingungen in einer noch eingegrenzteren
(speziellen) Form zu benutzen.
Nachfolgende Definition des Begriffs „Dialog“ ist dem Buch von E. Denert, Software
Engineering, Springer Verlag, 1995 entnommen:
„Ein Dialog bildet eine Einheit in der Mensch/Maschine-Kommunikation derart, daß dann für
den Benutzer zusammenhängende Daten und Funktionen verfügbar sind.“
Innerhalb der VAA kann „zusammenhängende Einheit“ durch den Bezug auf
„Elementarprozeß“ erheblich genauer präzisiert werden.
Mittels der so definierten Begriffe können jetzt aus dem Software-Engineering bekannte
Spezifikationsmethoden übernommen und angewandt werden.
Eine dieser Methoden ist das
„Interaktionsdiagramm“
(s. E. Denert).
Nachfolgend ist hierzu ein Beispiel aus der Versicherungsbranche dargestellt:
© GDV 1999
9
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Interaktionsdiagramm "KFZ-Antrag erfassen"
(Notation nach E. Denert)
Blättern
Matchcode
Kunden
aus Liste
selektieren
KFZHalter
erfassen
KFZ-Halter
eingegeben
KfZDaten
erfassen
KFZ-Halter ausgewählt
Zusatzdaten
ermitteln
ja
Weitere
Zusatzdaten
Zusatzdaten
erfassen
nein
alle Daten erfaßt
Antragsdaten
erfaßt,
Dialog beenden
Legende:
Start
10
Dialogzustand
Aktion
Übergang
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
I.1.1.4. Aufgabenstellung Dialogmanager
Nach den vorbereitenden Definitionen kann nun die Aufgabenstellung des Dialogmanagers
klar abgegrenzt werden.
Der Dialogmanager übernimmt die Aufgabe, sämtliche Dialoge auszuführen. Hierfür benutzt
er entsprechende Definitionen der Dialogsteuerung, der Benutzeroberfläche
(Präsentationssystem) sowie der gemäß Steuerungshierarchie notwendigen Schnittstellen.
Die Aufgabe läßt sich auch grafisch wie folgt darstellen:
Steuerung und Dialogmanager
Workflow-Steuerung
Vorgangssteuerung
Dialogmanager
Dialogsteuerung
mittels
Dialogssystem
Präsentationssystem
Anwendungsbaustein
Anwendungssteuerung
Funktionsbaustein
ruft
Dienst
© GDV 1999
ruft
Dienst
11
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.2. Funktionale Anforderungen
Im folgenden werden die „fachlichen Anforderungen“ des Dialogmanagers näher
beschrieben.
Die Betrachtung zielt ausschließlich auf die Frage
„Was muß der Dialogmanager leisten?“
Technische sowie verfahrenstechnische Fragestellungen werden hier nicht betrachtet.
I.1.2.1. Die fachlichen Anforderungen im Überblick
Die VAA-Steuerungskomponente „Dialogmanager“ übernimmt in der VAA-Architektur im
wesentlichen die zwei nachfolgenden Funktionsbereiche:
 Durchführung sämtlicher Funktionen im Bereich der Dialogsteuerung
 Präsentation von Informationen und Bearbeitung sämtlicher Benutzereingaben im
Rahmen der Mensch-Maschine-Kommunikation.
Durch diese Festlegung wird der Dialogmanager die zentrale Schnittstelle zwischen einer
Anwendung und den sie nutzenden Anwendern.
Um diese Aufgabe vollständig zu beschreiben, ist die funktionale Zergliederung in vier grobe
Funktionsblöcke sinnvoll.
12
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Grobes Funktionsmodell des
Dialogmanagers
Dialogmanager
API
BTS
DS
PS
API = Anwendungsschnittstellensystem
(Application Programming Interface)
BTS = Built-Time-System
DS = Dialogsystem
PS = Präsentationssystem
© GDV 1999
13
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Kurzbeschreibung des Dialogmanagers
 Anwendungsschnittstellensystem (API)
Bereitstellung einer Anwendungsschnittstelle (API) auf High Level Niveau
 Build-Time-System (BTS)
Entwicklungskomponente für Präsentation und Dialog
 Dialogsystem (DS)
Kontroll- und Steuerungssystem der Dialoge bzw. der Präsentation (eventuelle
Interpretation eines Dialogskriptes).
 Präsentationssystem (PS)
Darstellung der Information bzw. Steuerungsbefehle auf einem Datenendgerät
(Bildschirm, PC, Drucker etc.)
Das Zusammenspiel dieser vier Funktionskomponenten wird in nachfolgender Grafik
veranschaulicht.
14
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Aufbau des Dialogmanagers
(prozeßorientiertes)
Anwendungssystem
Anwendungsentwicklung
API
Built-Time-System
Dialogsystem
Präsentationssystem
Endbenutzer
der Anwendung
(Dialog)
© GDV 1999
15
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.2.2. Funktionsbeschreibung des Dialogsystems
Das „Dialogsystem“ ist das funktionale Herzstück des Dialogmanagers. Es übernimmt die
Aufgabe der
„Dialogsteuerung“.
Kernstück dieser Überlegung ist dabei, daß die Dialogsteuerung bei jedem Aufruf als
steuerndes Objekt jeweils einen
„Dialog“
ausführt.
Hierbei entspricht „Dialog“ der allgemeinen Festlegung des Software-Engineerings, wie er
beispielhaft in E. Denert, Software-Engineering, S. 132 ff, eingeführt ist.
Mittels dieses Kunstgriffes werden alle für Dialoge bekannten
 Methoden,
 Standards,
 Normungen und
 Erkenntnisse
ins VAA-Umfeld transferierbar, siehe z. B. Spezifikationsmethoden wie
Interaktionsdiagramme u. v. a. m.
Gliedert man die Funktionalität des Dialogsystems eine Ebene tiefer, so ergeben sich
folgende Funktionsblöcke:
■ Steuerung eines Dialoges anhand eines Dialogsteuerungsnetzes
(Dialogspezifikation). Hierbei sollte ein Netzmodell (z. B. Petrinetze) zum Einsatz
kommen, das folgenden Anforderungen genügt:
 parallele Verarbeitung durch den Endbenutzer
 Zwangsfolge eines Dialoges
 Experten- und Laienmodus u. a.
 Einbindung von Standarddialogen in alle bzw. ausgezeichnete Dialogschritte
(Zustände).
Hinweis:
Da im Rahmen des Workflow-Managers Geschäftsprozesse ebenfalls spezifiziert und
modelliert werden, sollte möglichst eine durchgängige Netztheorie eingesetzt werden.
Eine solche Zusammenführung würde das Problem der richtigen Granularität des
Prozeßmodells innerhalb der VAA wesentlich entschärfen bzw. vereinfachen.
16
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Notwendige Schnittstelle:
Modellierungswerkzeug für Dialognetze sowie Run-Time-Generierung für das
Dialogsystem (interpretativ und generierend)
þ Verwaltung und Bereitstellung eines „Dialoggedächtnisses“
Um einzelne Dialogschritte (Zustände) sowie ihre Informationen bzw. Aktionen festhalten
zu können, besitzt jeder Dialog einen entsprechenden Datenspeicher (Dialoggedächtnis).
Durch dieses Gedächtnis wird es möglich, daß der Endbenutzer Funktionalitäten wie z. B.
 Dialogschritte zurücksetzen
 Dialoge suspendieren oder löschen
 Ausflüge in andere Dialoge
 Einbindung von Altsystemen
während jedes bzw. bei ausgewählten Dialogschritten ausführen kann. Hierbei wirken
diese Funktionen entweder auf
 Dialogebene,
 Vorgangsebene oder
 Workflowebene.
Notwendige Schnittstelle:
Etwaige Gedächtnisse auf den Steuerungsebenen:
 Vorgangssteuerung
 Workflowsteuerung
müssen synchron, möglichst sogar gleichartig und übergreifend behandelt und verarbeitet
werden.
þ Integrierte Schnittstelle zu dialogunterstützenden VAA-Diensten
Im Verlauf eines Dialoges sind dem Endbenutzer in jedem Dialogzustand bzw. bei jeder
Aktion eine Reihe von standardisierten, dialogunterstützenden Services zur Steuerung
der Dialogverarbeitung zur Verfügung zu stellen. Einige Beispiele hierfür sind:
 Hilfe-System
 Problemhandling/Fehlerhandling
 Menüsystem/Navigationssystem
 Kommandohandler
 Mehrsprachigkeit
© GDV 1999
17
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Wegen der Häufigkeit des Aufrufes dieser Schnittstellen aus dem Dialogsystem ist auf
eine entsprechende Integration Wert zu legen.
Die Nutzung dieser Dienste muß einheitlich geschehen und hat Auswirkungen auf die
Steuerungsarten (Workflow-, Vorgangs- und Dialogsteuerung). Die Implementierung ist
daher möglichst zentral vorzunehmen, und alle nutzenden VAA-Dienste sind mit einer
integrierten Schnittstelle zu versehen.
Hinweis:
Art, Umfang und Funktionsweise sämtlicher übergreifender, dialogunterstützender
Services sind zwischen den VAA-Steuerungskomponenten einheitlich festzulegen.
þ Schnittstelle zu Alt-Systemen
Um alte Dialogsysteme in die neue VAA-Architektur einbinden zu können, sollte das
Dialogsystem eine „Dialogkapsel“ zur Verfügung stellen, die aus Sicht des Dialogsystems
einen Alt-Dialog soweit VAA-fähig gestaltet, daß zumindest der Aufruf und der
Rücksprung in bzw. aus diesem Altdialog sich VAA-konform verhält. Inwieweit zusätzliche
Konformitätsbedingungen ebenfalls garantiert werden können, ist der genauen
technischen Spezifikation vorbehalten.
PM
Dialogsystem
ruft VAA-konform
DS-Schnittstellen zu Alt-/FremdSystemen
Altdialog
18
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
þ Dialog-Standards
Um den Dialogen innerhalb von VAA ein einheitliches Erscheinungsbild zu geben, sind
sogenannte Design- und Implementierungsstandards für VAA zu definieren. Hierbei
können bereits vorhandene Standards weitestgehend benutzt werden (s. E. Denert,
Softwareengineering), da die VAA-Definition des Dialogs zu den bisherigen Definitionen
des Softwareengineering äquivalent ist.
þ Dialog-Service-Funktionen
Neben der Dialogsteuerung und der Bereitstellung des Dialoggedächtnisses bilden die
Dialog-Service-Funktionen das Herzstück des Dialogsystems. Dialog-Service-Funktionen
sind diejenigen zentralen Funktionen, die jeder Dialog dem Endbenutzer zur optimalen
Bedienung eines Anwendungssystems bereitstellt.
Beispielhaft seien als Dialog-Service-Funktionen folgende genannt:
 Abbruch eines Dialoges
 Unterbrechung eines Dialoges
 Suspendieren eines Dialoges
 Wiederaufnahme eines Dialoges
 Dialogwechsel
 Rücksetzen eines Dialogschrittes (UNDO)
Die zentrale Bereitstellung dieser Service-Funktionen gewährleistet die Einheitlichkeit in
der Nutzung und Bedienung.
Einige der Dialog-Service-Funktionen haben nicht nur Auswirkungen auf die
Dialogsteuerung, sondern auch auf die Vorgangs- bzw. Workflowsteuerung. Eine
Abstimmung mit den entsprechenden anderen VAA-Steuerungskomponenten ist daher
zwingend erforderlich.
© GDV 1999
19
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.2.3. Funktionsbeschreibung des Präsentationssystems
Das Präsentationssystem hat die Aufgabe, die Mensch-Maschine-Kommunikation zu
realisieren. Dies bedeutet im wesentlichen die entsprechenden Informationen bzw.
Steuerungsbefehle zwischen der Anwendung bzw. dem Endbenutzer zu übertragen und in
der jeweils geeigneten Form darzustellen. Da das Medium zur Darstellung ein sogenanntes
Datenendgerät ist, wird das Präsentationssystem im wesentlichen eine
„Technikkomponente“ sein. Trotz dieser Technikausrichtung lassen sich für das
Präsentationssystem die folgenden fachlichen Funktionen spezifizieren.
þ Präsentation von Informationen (Daten- und Steuerungsinformationen)
Um die Mensch-Maschine-Kommunikation durchzuführen, ist es notwendig, sämtliche
Informationen von der jeweiligen Darstellung des jeweilig anderen
Kommunikationspartners umzuwandeln (Präsentation). Präsentation ist somit der
Transformationsprozeß, der Daten an der internen Rechnerdarstellung in ein
entsprechendes Präsentationsobjekt abbildet und dieses auf einem Datenendgerät
darstellt.
Beispiele einer solchen Abbildung (Transformation) sind:
(internes) Datenfeld
Fehlermeldungstext
Tabelle
Steuerungsbefehl
Tabelle





Ausgabefeld
Fehlermeldungszeile
List box
Push button
Graphik
Nach dieser „formalen“ Transformation muß das Präsentationsobjekt in einem zweiten
Teilprozeß dann grafisch präsentiert werden (Formatierung). Der Formatierungsprozeß ist
direkt abhängig von den technischen Darstellungsmöglich-keiten des jeweils genutzten
Endgerätes.
Bis zu welcher Tiefe dieser Präsentationsprozeß von der genutzten Hardware
unabhängig zu gestalten ist, kann letztendlich erst nach einer genauen technischen
Feinspezifikation festgeschrieben werden.
Zur besseren Verdeutlichung dieses Prozesses sei er exemplarisch für das Produkt
IMS/MFS der IBM schematisch dargestellt.
20
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Präsentation unter IMS/MFS
Anwendung
Anwendung
(Ausgabe)
Datenstruktur
(Eingabe)
Datenstruktur
Präsentation
Eingabe
(Daten und
Steuerungsbefehle)
Präsentationsbeschreibung
Eingabebeschreibung
Bildschirmmaske
MOD; DOF
MFS
Datenstruktur (Ausgabe)
MID; DIF
MFS
Bildschirmmaske (Ausgabe)
Benutzerinteraktion
Datenstruktur (Eingabe)
Bildschirmmaske (Eingabe)
Notwendige Beschreibungen und Parameter liegen als externe Sourcen der
Präsentation vor.
© GDV 1999
21
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
þ Transformation von Informationsinhalten (internes/externes Format)
Häufig werden Informationen aufgrund technischer Gegebenheiten in einem „internen“
Format dargestellt bzw. gespeichert. Diese Formate sind hingegen für den Endbenutzer
nicht gut bzw. nicht leicht lesbar. Um diese Daten dem Endbenutzer in der ihm
angemessenen Form zu präsentieren, wird je nach Datentyp eine entsprechende
Transformation im Präsentationssystem durchgeführt, ohne daß hiervon die eigentliche
Anwendung tangiert wird.
Beispiele:
interne reelle Zahl
betätigte Funktionstaste
interner Anredeschlüssel



ext. Form mit Punkt als Lesehilfe
interne Darstellung Fnn
Herr, Frau, Fräulein, ....
Anhand dieser Beispiele ist zu erkennen, daß sich die Transformation in die Gruppen:
 Präsentationen/Darstellungen und
 Codierungen/Verschlüsselungen
einordnen lassen.
Neben den Transformationen gibt es noch Syntax- und Semantikprüfungen wie:
 Syntaxprüfungen
 Wertebereichsprüfungen
 Korrelationsprüfungen
Anders wie die reinen Transformationen gehören Syntax- und Semantikprüfungen jedoch
nicht zu den direkten Aufgaben des Dialogmanagers. Hierfür ist in der VAA ein
gesonderter Dienst, der
„Prüfdienst für Feldinhalte“
vorgesehen.
þ Bereitstellung eines Präsentations-Speichers
Auch das Präsentationssystem muß für die Dauer der Präsentation einen
entsprechenden Arbeitsspeicher besitzen, da z. B. nicht alle Daten zur gleichen Zeit auf
dem Datenendgerät präsentiert werden sollen. Das gleiche kann auch bei
entsprechenden Eingaben vorkommen. Weiterhin können alle bzw. ausgesuchten
Präsentationsobjekte in Form eines „snap shot“ festgehalten werden, um sie
gegebenenfalls nach Bedarf für den Endbenutzer nochmals wiederherzustellen. Neben
diesen Funktionen sollte der Arbeitsspeicher die Möglichkeit eröffnen, eventuelle Daten
für die Präsentation nachzulesen. Diese Funktion sollte z. B. zum Nachlesen bei der
Präsentation „sehr großer“ Tabellen Anwendung finden.
þ Präsentationsstandards (Benutzeroberflächenstandards)
22
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Um dem Endbenutzer die Bedienung eines Rechners mittels eines Dialoges zu
vereinfachen, ist es sinnvoll, die Benutzeroberfläche zu standardisieren.
Hierzu sind bisher von Normungsgremien oder Herstellern bereits entsprechende
Standards entwickelt worden (z. B. OSF/Motif, CUA, Windows 95, etc.). Der Nachteil
dieser Lösungen liegt darin, daß sie weder einheitlich, noch plattformübergreifend sind.
Diese Forderung ist von der VAA jedoch soweit wie möglich umzusetzen.
Lösung dieses Problems ist ein virtueller Standard. Er sollte aus einer Reihe „virtueller“
Präsentationsobjekte bestehen, die je nach eingesetzter Plattform auf die
plattformgemäße Lösung transformiert werden.
OSF/
Motif
VAAPSStandards
CUA
Windows
3.1x
© GDV 1999
Windows
'95/NT
23
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Hierbei kommt es vor, daß nicht vorhandenene Präsentationsobjekte des jeweiligen
„Endgerätes“ durch andere Darstellungen ersetzt werden müssen.
Neben der Angleichung der unterschiedlichen grafischen Standards muß ebenfalls eine
„Angleichung“ der unterschiedlichen Endgeräte-Klassen erfolgen. Auch hierzu ist ein
„virtuelles“ Schichtenmodell zu definieren, welches erlaubt, nicht vorhandene
Präsentationsobjekte auf entsprechende Ersatzdarstellungen abzubilden. So können
z. B. drei Level an Geräteklassen definiert werden:
VAA-BOS 1 für
VAA-BOS 2 für
VAA-BOS 3 für
alpha-numerische Geräte
„pseudo-grafische“ Geräte
„volle“ grafische Geräte.
Diese Stufung der Geräteklassen ließe sich insbesondere mit Sicht auf zukünftige
Entwicklungen auch erweitern. So stellt heute bereits die Entwicklung im MultimediaBereich eine Anforderung dar, ein entsprechendes neues (4) Level zu definieren.
Sind diese Standards jeweils Teilmengen voneinander, so können sie entweder mittels
Ersatzdarstellungen den jeweils höherwertigen „emulieren“ oder innerhalb einer
Anwendung ist die Nutzung auf einen Level einzuschränken.
VAA - BOS 3
VAA
BOS 1
VAA - BOS 2
BOS =
Benutzeroberflächenstandard
Neben der Festlegung eines Präsentationsstandards ist die Forderung nach einem Style
Guide zu stellen. Hierdurch wird eine „weitgehend konsistente“ Benutzeroberfläche über
Anwendungsbausteine bzw. Dialoge hinweg erzielt. Ein Style Guide enthält neben
Design-Richtlinien auch Qualitätssicherungs- und Qualitätsprüfmaßnahmen.
24
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
I.1.2.4. Funktionsbeschreibung des Anwendungsschnittstellensystems
(API-System)
Das API-System soll im Dialogmanager die zentrale Aufgabe der Schnittstellenkonvertierung
zu den Bausteinen bzw. Diensten übernehmen. Da der Dialogmanager aufgrund seiner
zentralen Stellung in der VAA sehr häufig aus einer Reihe von Diensten genutzt wird, sollte
diese Schnittstellenkonvertierung möglichst effizient - also integriert - und für die rufende
Seite möglichst einfach und unabhängig erfolgen.
Die Funktionalität des API-Systems läßt sich am sinnvollsten gemäß der jeweiligen
Kommunikationsrichtung (Aufrufrichtung) beschreiben:
 Der Dialogmanager wird von einer Steuerungskomponente bzw. einem Dienst
gerufen
Diese Aufrufrichtung ist entweder nur aus der Steuerungsebene (Workflow- bzw.
Vorgangssteuerung) zulässig oder von VAA-Diensten, die ihrerseits eine eigene,
spezialisierte Benutzeroberfläche besitzen (z. B. Hilfesystem, Termin-/Wiedervorlagesystem, Textverarbeitungssystem u. v. a. m.).
Als Kommunikationsformen sind folgende drei Arten vorzusehen:
 asynchrone Kommunikation
 synchrone Kommunikation mit Wait-Status des Rufers
 synchrone Kommunikation ohne Wait-Status des Rufers (sofern technisch möglich)
Das Schnittstellenverhalten ist weiterhin so auszuprägen, daß sämtliche allgemeine
Funktions-Services der Dialogsteuerung wie z. B.
 Dialog unterbrechen
 Dialog beenden
 Dialog suspendieren
innerhalb des Dialogmanagers durchgeführt und gegebenenfalls mit der
Steuerungsebene synchronisiert werden können.
© GDV 1999
25
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Formaler Aufbau der Schnittstellen
Über die Schnittstelle zwischen Arbeits- bzw. Steuerungskomponentenebene und
Dialogmanager sollen als Objekte ausschließlich
„Dialoge“
gerufen werden. Hierbei sind vier formale Parameter als Mindestanforderung fest
vorgegeben:
bezeichnet den Identifier des „gerufenen“ Dialoges
ist die Bezeichnung der auszuführenden Methode auf das
entsprechende Dialogobjekt (Dialogtyp)
<Dialogdaten>
ist ein für die Dialogausgabe notwendiger Datenbereich
<Return-Code>
ist eine entsprechende Statusmeldung, die der
Dialogmanager nach Abarbeitung des Dialoges der
rufenden Steuerungskomponente bzw. der Anwendung
zurückliefert.
(Dieser Parameter entfällt bei asynchroner Kommunikation.)
<Dialogname>
<Dialogfunktion>
Eine Anzahl weiterer Parameter ist je nach Spezifikation des Dialogtyps möglich. So wird
ein „Eingabedialog“ einen entsprechenden Datenbereich als Eingabedatei der rufenden
Steuerungskomponente bzw. der Anwendung übergeben.
Welche Dialogtypen mit welchen Subtypen zu spezifizieren sind und welche
Dialogfunktionen hierfür jeweils zur Verfügung gestellt werden, bleibt der technischen
Spezifikation überlassen. Ihre Festlegung hat nämlich entscheidende Auswirkungen auf
die jeweilige technische Realisierung, jedoch gibt es aber auch hierfür fachliche
Argumente, die zu berücksichtigen sind. So sollte z. B. ein Auskunftsdialog zwar
suspendierbar (kurzzeitig unterbrechbar), aber nicht generell unterbrechbar sein, da sonst
die Integrität bzw. die Aktualität der Auskunftsdaten nicht mehr gewährleistet werden
kann.
 Der Dialogmanager ruft einen Dienst bzw. einen Anwendungsbaustein
Diese Aufrufschnittstelle nutzt der Dialogmanager selbst für den Fall, daß er sich selbst
während der Ausführung eines Dialoges weiterer VAA-Dienste bzw.
Anwendungsbausteine bedienen muß.
Beispielhaft seien an dieser Stelle folgende Möglichkeiten dargestellt:
 Während der Darstellung innerhalb einer Benutzerinteraktion ruft der Endbenutzer das
Hilfesystem bezogen auf ein Darstellungsobjekt (z. B. ein Eingabefeld) auf.
 Eingegebene Daten sind bzgl. Syntax bzw. Wertebereiche zu validieren.
 Der Dialogmanager erkennt während seiner Bearbeitung eine Fehlersituation und ruft
den Fehlerhandlings-Dienst.
 Für die Darstellung einer Tabelle als Ausgangsobjekt müssen für das „logische
Blättern“ entsprechende Daten nachgelesen werden.
26
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Aufgrund der dargestellten Beispiele wird bereits deutlich, daß der Dialogmanager während
der Ausführung eines Dialoges diese Aufrufschnittstelle sehr häufig benutzt. Um die
Abarbeitung des Dialoges nicht zu gefährden, sind als Kommunikationsformen nur
zugelassen:
 synchron bzw.
 „virtuell“ synchron.
Hierbei bedeutet „virtuell synchron“, daß der aufgerufene Dienst dem Dialogmanager bei
einem Rücksprung in die Steuerungsebene nicht explizit die Kontrolle zurückgeben muß,
jedoch sein Rücksprungverhalten alle Funktionen des Rücksprungverhaltens des
Dialogmanagers mit ausführt. Grund dieser Überlegung sind ausschließlich PerformanceBetrachtungen.
Welche VAA-Dienste, welche hierin definierten Objekte und welche hierauf operierenden
Methoden für den Aufruf erlaubt sind, muß in der technischen Spezifikation ebenfalls
genauer bestimmt werden.
Neben der Bereitstellung der Funktionalität der beiden Kommunikationsschnittstellen des
Dialogmanagers durch die API-Komponente sollte diese jegliche Aufrufe auf
Zuverlässigkeit, Syntax und semantische Gültigkeit möglichst frühzeitig und damit
performant überwachen. Zu diesen Prüfungen gehören beispielhaft:
 Verfügbarkeit des gerufenen Dialoges
 Berechtigung zur Nutzung des Dialoges durch den aktuellen Endbenutzer
 Zulässigkeit der ausgewählten Dialogfunktion
 Zulässigkeit der gerufenen VAA-Dienste
 Korrektheit in Form und Anzahl der übergebenen Parameter
Über diese fachlichen Anforderungen hinaus ist das API-System von einer Fülle von
technischen Anforderungen geprägt, die in dem entsprechenden Kapitel dieser
Spezifikation niedergelegt sind.
I.1.2.5. unktionsbeschreibung des Build-Time-Systems (BTS)
Beschreiben die bisherigen Komponenten des Dialogmanagers das Laufzeitverhalten dieser
VAA-Steuerungskomponenten, so ändert sich dies bei der Build-Time-Komponente.
Ihre Aufgabe besteht darin, das Bindeglied zwischen Entwicklung und Ausführung von
Dialogen sicherzustellen.
Die nachfolgende Aufzählung von Funktionen der Build-Time-Komponente stellt die
Anforderungsliste aus Sicht des Laufzeitsystems dar, d. h. es sind die Funktionen genannt,
die zum Betrieb bzw. zur Definition von Objekten für das Laufzeitsystem unbedingt
notwendig sind. Fachliche Funktionen aus Sicht der Erstellung, d. h. unterstützende
Software-Engineering-Funktionen sollten bei einer Feinspezifikation ergänzt werden, um das
entstehende Tool funktional abzurunden und beim Entwickler eine entsprechende Akzeptanz
zu gewährleisten.
© GDV 1999
27
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
Aus fachlicher Sicht zerfällt der Entwicklungsprozeß in die beiden Unterfunktionen:
 Erstellen (Editieren) aller notwendigen Sourcen
 Testen und Bereitstellen der Sourcen für die Ausführung in den Laufzeitkomponenten
(Generieren bzw. Interpretieren).
Ob aus technischer Sicht diese Funktionsgliederung auch zu eigenständigen technischen
Komponenten führt und ob die „Editier-Komponente“ auch für andere VAASteuerungskomponenten genutzt werden kann oder sollte, bleibt der technischen
Spezifikation überlassen.
I.1.2.5.1. Funktionsbeschreibung der Editierkomponente
Aus Sicht des Entwicklers und aufgrund der Funktionalität des Laufzeitsystems des
Dialogmanagers sollten folgende Editierfunktionen für spezielle Sourcen vorhanden sein:
 Entwicklung von Dialogsteuerungs-Netzen
Zur Modellierung von Dialogsteuerungs-Netzen ist ein grafischer Netzeditor mit heute
üblichen Editierfunktionen vorzusehen. Hierbei sollte die Mehrfachverwendung in
Verbindung mit dem Workflowmanager überprüft und gegebenenfalls berücksichtigt
werden.
Zur genaueren Festlegung der Spezialfunktionen werden bereits vorhandene Produkte
des Marktes im entsprechenden Kapitel als Spezifikation aufgenommen.
 Animation und Simulation von Dialogsteuerungs-Netzen
Um die Design- und Modellierungsarbeit des Entwicklers wirkungsvoll zu unterstützen,
sollte eine Animations- und Simulationsmöglichkeit für grafische Dialogsteuerungsnetze
existieren, die ohne Notwendigkeit einer Generierung bzw. Umwandlung auf der
Netzgrafik aufsetzt. Eine parallele Möglichkeit zum Verändern des Netzes in einer zweiten
Session sollte die Funktionalität abrunden.
28
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
 Entwicklung von Benutzeroberflächen
Gemäß der definierten Benutzeroberflächenstandards der VAA ist ein entsprechendes
Entwicklungswerkzeug für Benutzeroberflächen anzubieten. Dabei sollte der gewünschte
BOS-Standard einstellbar sein und vom Werkzeug auch überwacht werden.
Eventuell mit der Benutzeroberfläche verbundene weitere Beschreibungen wie
 Syntax- und Wertebereichsprüfungen
 Hilfetexte
 Fehlermeldungen
sollten ebenfalls im Entwicklungswerkzeug der Benutzeroberfläche spezifiziert werden,
damit aus Sicht des Entwicklers das einheitliche Layout gewahrt bleibt.
 Simulationsfunktion für Benutzeroberflächen
Analog wie bei der Entwicklung von Dialogsteuerungs-Netzen kommt dem parallelen
Testen und Simulieren von Benutzeroberflächen in der Entwicklung ein besonderer
Stellenwert zu. Ein entsprechend funktional gut gestaltetes Werkzeug hilft, die
Komplexität moderner grafischer Benutzeroberflächen erst beherrschbar zu machen.
Ferner sollten die Werkzeuge für die Simulation von Dialogsteuerungs-Netzen und
Benutzeroberflächen insoweit gekoppelt sein, daß ein Dialog inklusive seiner
Benutzeroberfläche animiert werden kann und so der Endbenutzer eines Dialoges
frühzeitig diesen prototypen kann.
 Design von C/S-Anwendungsschnittstellen
Da die VAA-Architektur grundsätzlich eine Lauffähigkeit ihrer konformen Anwendungen
auf C/S-Netzen beinhaltet, ist die Verteilung von Anwendungsteilen auf die einzelnen
Rechnerkomponenten eine wichtige Entwicklungstätigkeit. Dies gilt insbesondere für
Dialoge mit entsprechenden Benutzeroberflächen. Ein entsprechend intelligentes
Werkzeug sollte den Entwickler bei dieser Tätigkeit unterstützen. Hierbei sollte die
Spezifikation der Verteilung so genau sein, daß durch Hinzufügen etwaiger HardwareInformationen die C/S-Schnittstellen der einzelnen Anwendungsteile vollständig generiert
werden können.
 Verwaltung von Sourcen
Da moderne Anwendungssysteme aufgrund ihrer Modularität aus einer sehr großen
Anzahl von Einzelteilen besteht, sollte ein umfangreiches Change- und ConfigurationManagement-Werkzeug die Sourcen kontrollieren. Dies gilt auch für sämtliche Sourcen
des Dialogmanagers.
© GDV 1999
29
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.2.5.2. Funktionsbeschreibung der Generierungs- bzw
Interpretationsfunktionen (Build-Funktionen)
Neben den reinen Entwicklungsfunktionen von Sourcen in einem benutzerfreundlichen
Format ist eine weitere Aufgabe des Entwicklungsprozesses die Konvertierung in ein
maschinell verwendbares Format. Überläßt man diese Aufgabe dem Rechner, so spricht
man auch von
„Build-Funktionen“.
Der Aufbau eines nach diesen Prinzipien gebauten Systems läßt sich grafisch wie folgt
darstellen:
Entwickler
Editier- und
Simulationsfunktion
BuildFunktion
Run-Time-Funktion
des Präsentationsmanagers
30
Design des
Dialoges
Programmierung
des Dialoges
Lauffähiger
Dialog
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
Der Dialogmanager benötigt folgende Build-Funktionen:
 Generierung bzw. Interpretation von Dialogsteuerungs-Netzen,
Benutzeroberflächen und C/S-Anwendungsschnittstellen
Alle Sourcen des Editierprozesses sind unter Hinzunahme bzw. Hinzufügung von
Hardware- und Systemparametern zu entsprechenden lauffähigen Modulen zu generieren
bzw. als Source zu interpretieren. Welche Technik im jeweiligen Fall zum Einsatz kommt,
sollte möglichst spät, eventuell sogar alternativ entschieden werden. Wichtig zur
Entscheidung dieser Frage ist häufig jedoch die Performance. Aus diesem Grunde wären
sogar Mischformen denkbar und sinnvoll.
Welche Sourcen zu welchen lauffähigen Modulen in welcher Systemumgebung führen, ist
im Rahmen der technischen Spezifikation ausführlich zu beschreiben.
 Syntax- und Semantik-Checker
Alle Sourcen sind beim Build-Prozeß möglichst intensiv auf Syntax- und Semantikfehler
zu überprüfen. Aufgrund der komplexen Zusammenhänge sollte die Fehleranalyse sehr
ausgeprägt mit entsprechenden Rückverfolgungen auf den Quellcode der jeweiligen
Source durchgeführt werden.
 Überprüfung von Normen und Standards
Neben der reinen Syntax- und Semantikprüfung sollten die Build-Funktionen die
Möglichkeit besitzen, vorher deklarierte Normen und Standards für die jeweiligen Sourcen
auf ihre Einhaltung zu überprüfen. Solche Normen und Standards können sein:
 Namenskonventionen
 ergänzende Benutzeroberflächen-Standards
 Dialogsteuerungs-Normen
 etc.
 Integrierte Testwerkzeuge
Neben den Simulations- und Animationsfunktionen im Entwicklungsbereich sollten im
Build-Umfeld weitreichende, integrierte Testwerkzeuge für sämtliche Sourcen zur
Verfügung stehen. Diese Werkzeuge dienen insbesondere der Qualitätssicherung. Hierzu
sollten insbesondere anerkannte Software-Metriken Einsatz finden.
© GDV 1999
31
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
I.1.3. Technische Anforderungen
Wie in der Einleitung zu diesem Kapitel bereits erwähnt, sind die wesentlichen
Anforderungen aus technischener Sicht erst direkt im Vorfeld der Implementierung in einem
entsprechenden Umfang festzulegen. Alle bereits in einer Grobspezifikation erkennbaren
technischen Anforderungen sind nachfolgend in einer unsortierten Liste zusammengestellt:
þ Anwortzeiten
Das Antwortzeitverhalten muß den heutigen ergonomischen Anforderungen genügen und
darf daher nur im 1-Sekunden-Bereich liegen. Aus dieser Anforderung heraus ist der
besondere Hinweis auf die
„Performance“
sämtlicher VAA-Komponenten nochmals strikt hervorzuheben.
þ Realisierungsplattform
Aus Sicht der Spezifikationsgruppe wurde eine Mindestliste (Positiv-Liste) für eine
Mainframe- als auch eine C/S-Umgebung wie folgt aufgestellt:
HW/SW-Liste für RUN-TIME-System des Dialogmanagers
Mainframe
Betriebssystem
OS/390 (MVS)
OSD (BS/2000)
Transaktionsmonitore IMS/DC mit MFS
CICS mit BMS
UTM mit FHS
C/S-Umgebung
32
Betriebssystem
Windows 3.1x
Windows 95
Windows NT
OS/2 mit PM
UNIX mit OSF Motif
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
I.1.4. Anforderungen an Schnittstellen
Der Dialogmanager hat folgende Typen von Schnittstellen zu bedienen:
(1)
(2)
(3)
(4)
Dialogmanager
Dialogmanager
Dialogmanager
Dialogmanager




Anwendungsbausteine
allgemeine VAA-Dienste
Datenmanager
Parametersystem
Die jeweiligen Anforderungen an diese Schnittstellen werden nachfolgend im einzelnen
beschrieben. Aufgrund der Schnittstellenarchitektur der VAA besitzt der Dialogmanager
keine aktive Schnittstelle zu den Steuerungskomponenten
 Workflowsteuerung
 Vorgangssteuerung
Jeder Aufruf dieser Komponenten basiert auf einem entsprechenden Aufruf und ist daher als
„Rücksprung“ zu betrachten.
þ (1) Schnittstelle „Dialogmanager  Anwendungsbausteine“
Diese Schnittstelle wäre bei einem puristischen Architekturansatz zu verbieten, da beide
VAA-Komponenten die Realisierung des „Elementarprozesses“ an dem fachlichen
Prozeßmodell darstellen. Dies würde in vielen Dialogen jedoch zum Fahrstuhleffekt führen,
d. h. weil Dialogeingaben durch den Endbenutzer auf fachliche Gültigkeit überprüft werden
müssen, ist der Dialog zu verlassen und über den Umweg der Vorgangssteuerung die
entsprechende Prüffunktionalität eines Anwendungsbausteins aufzurufen.
Um diesen „unnötigen“ Umweg zu vermeiden, erlaubt die Schnittstelle den Aufruf eines
Anwendungsbausteins aus dem Dialogmanager unter folgenden Restriktionen:
 fachliche Daten dürfen gelesen, aber nicht verändert werden
 der Vorgangsspeicher bleibt unverändert
 der Rücksprung erfolgt an die vorgesehene Stelle des „rufenden“ Dialoges
Bei den Prüfvorgängen ist darauf zu achten, daß es sich um fachlich inhaltliche Prüfungen
handelt; Prüfungen im Rahmen der Präsentation müssen im Dialogmanager durchgeführt
werden.
© GDV 1999
33
Abgrenzung und Wirkungsweise der Steuerungskomponente
Dialogmanager
þ (2) Schnittstelle „Dialogmanager  allgemeine VAA-Dienste“
An diese Schnittstelle sind - allein aufgrund der ausgezeichneten Stellung der Dienste in der
VAA - keine besondere Anforderungen bzw. Restriktionen aus Sicht des Dialogmanagers zu
stellen. Besonders anzumerken ist jedoch eine häufig sehr große Aufruftiefe zwischen
Dialogmanager und VAA-Diensten, z. B. zwischen
 Dialogmanager
 Hilfe-System
 Prompt-System
 Prüfsystem
 Feldkonverter etc.
Innerhalb des Dialogstandards sollte auf diese Situation besonders eingegangen werden,
um das Zusammenspiel dieser vielen Komponenten eindeutig und unmißverständlich
festzulegen.
þ (3) Schnittstelle „Dialogmanager  Datenmanager“
Diese Schnittstelle ist zwar vorhanden und ihre Nutzung prinzipiell nicht eingeschränkt,
jedoch sollte der Dialog sich im Normalfall auf die Daten des Vorgangsgedächtnisses
beziehen und sich diese nicht direkt vom Datenmanager beschaffen. Aufgrund von
Restriktionen bei der Präsentation gibt es aber auch sinnvolle Aufrufe des Datenmanagers,
z. B. beim Präsentieren von Daten in Tabellenform und in diesem Zusammenhang das
Nachlesen von relevanten Datensätzen.
þ (4) Schnittstelle „Dialogmanager  Parametersystem“
Als Besonderheiten an dieser Schnittstelle aus Sicht des Dialogmanagers bleibt
festzuhalten:
 Aus Sicht der Präsentationskomponente sollten Parameter als Menge, sog. „bulk“Beschaffung möglich sein.
 Das Parametersystem muß auch auf Clients/Workstations verfügbar sein, da hier die
Präsentation vorgenommen wird.
34
© GDV 1999
Dialogmanager
Abgrenzung und Wirkungsweise der Steuerungskomponente
I.2. Abgrenzung, Einschränkungen und offene Punkte
Als Ergebnis der Grobspezifikation werden in diesem Kapitel zunächst ausschließlich die
offenen Punkte
beschrieben, die innerhalb der Feinspezifikation oder der Realisierung, aber auch
möglicherweise parallel - dies gilt insbesondere für die Erstellung von Standards und
Rahmenrichtlinien - durch separate VAA-Entwicklungsschritte zu behandeln sind.
þ Liste der offenen Punkte
 VAA Benutzeroberflächenstandards (BOS) einschließlich Klassifizierung und
Transformationsregeln auf gängige User-Interface-Management-Systeme
 Style Guide für grafische und alphanumerische Benutzeroberflächen einschließlich
Interaktionsregeln
 Standard für Dialogführung und Dialoginteraktion
 Klassifikation von Dialogtypen und Definition von Dialogbausteinen (Standard-Dialogen)
 Entwicklungs- und Darstellungsmethode für Dialogsteuerungen (Petri-Netze)
 Funktionale Beschreibung des Zusammenwirkens unterschiedlicher Gedächtnisse in der
Steuerungsebene:
- Workflow-Gedächtnis
- Vorgang-Gedächtnis
- Dialog-Gedächtnis.
I.3. grundlegende Bauprinzipien und Algorithmen
Die Ausarbeitung dieses Kapitels bleibt der Feinspezifikation vorbehalten, da ein konkreter
Bezug zur späteren Realisierung zwingend notwendig ist.
© GDV 1999
35
Schnittstellenbeschreibung
Dialogmanager
II. Schnittstellenbeschreibung
Auch dieser Abschnitt der Spezifikation sollte im Rahmen einer detaillierten Feinspezifikation
erst endgültig beschrieben werden.
III. vorhandene Produkte und aktuelle
Entwicklungen
III.1. vorhandene Produkte
Bei den nachfolgend aufgeführten Produkten handelt es sich um Nennungen aus dem Kreis
der Projektmitglieder. Es war weder Ziel noch Aufgabe dieses Kreises, eine möglichst
umfassende Marktstudie zu erarbeiten.
Als Kriterium für eine Auflistung wurde jedoch herangezogen, daß die zugrunde liegende
Produkt-Idee der in dieser Spezifikation niedergelegten Strategie nahe kommt; So wurden
reine GUI-Werkzeuge zur Erstellung von grafischen Benutzeroberflächen nicht
berücksichtigt.
þ Liste der Produkte
 ISA Dialogmanager der Firma ISA, Stuttgart
 SWT/VDA der Firma SWT, Siegburg
 GENIUS Prototyp des IAO (Fhg-Institut), Stuttgart
36
© GDV 1999
Dialogmanager
Anhang
IV. Anhang
IV.1. Literaturverzeichnis
Die nachfolgend aufgeführten Literaturreferenzen sollen als Sammlung im Zusammenhang
mit dieser Spezifikation gesehen werden. Sie behandeln auch angrenzende Themen und
Sachgebiete.
Die Liste ist keine Referenzliste im Sinne einer wissenschaftlichen Veröffentlichung.
 Prof. Dr. E. Denert: Software Engineering, Springer Verlag, 1995
Literaturliste von Standards zur Gestaltung von Benutzungsoberflächen:
 SAA/CUA (System Application Architecture - Common User Access)
IBM Corp.: Object-Oriented Interface Design, Que Corporation, Carmel IN, 1994
 OSF/Motif Style Guide (Open Software Foundation) Revision 2.0, 1994
zu beziehen durch: Open Software Foundation, Eleven Cambridge Center, Cambridge,
MA
02142
 OPEN LOOK - Graphical Interface Functional Specification, 1990
Addison-Wesley Publishing Company Inc.
 OPEN LOOK - Graphical Interface Application Styleguide, 1990
Addison-Wesley Publishing Company Inc.
 Apple - Human Interface Guidelines, The Apple Desktop Interface
Apple Computer Inc. 1986, Cupertino, CA
 Apple - Human Interface Guidelines,
Apple Computer Inc. 1993, Cupertino, CA
 IBM - Empfehlungen zum Dialog- und Bildschirmdesign, IBM Form GE 12-1603-0
 Microsoft Corporation:
The Windows Interface. An Application Design Guide. Microsoft Press, Redmount
Washington, 1992
 Microsoft Corporation:
The Windows Interface. Guidelines for Software Design. Microsoft Press, Redmount
Washington, 1996
 Smith, S. L.; Mosier, J. N.: Guidelines for Designing User Interface Software; MITRE,
Bedford, Massachusetts
 VDI-Richtlinie 5005: Software-Ergonomie in der Bürokommunikation
 DIN 66234 Teil 8: Grundsätze ergonomischer Dialoggestaltung
 ISO 9241: Ergnonomic requirements for office work with visual display terminals (VDTs),
derzeit im Entwurf
 Brown, C. M.: Human-Computer Interface Design Guidelines. Ablex Publishing
Corporation,
Norwood, New Jersey; 1988
© GDV 1999
37
Anhang
Dialogmanager
 Hoffmann, T.; Klose, H.-G.; Martin, H.: Handbuch zur software-ergonomischen
Gestaltung
von Bildschirmmasken, VDI-Fortschrittsberichte, Reihe 10, Nr. 103, VDI-Verlag,
Düsseldorf,
1989
 Siemens/Nixdorf: Richtlinien zur Gestaltung von Benutzeroberflächen
(Benutzerhandbuch/Checkliste) Bestell-Nr. U6615-J-Z97-1 und U6542-J-/97-1 bei: AP
Internationales Dokumentationszentrum, Otto-Hahn-Ring 6, 8000 München 83
IV.2. Mitwirkende
IV.2.1. eteiligte Firmen
Aachener und Münchener Informatik-Service AG, Aachen
Deutscher Ring Lebensversicherungs AG, Hamburg
Hamburg-Mannheimer Versicherungs AG, Hamburg
Münchener Verein Versicherungsgruppe, München
SWT Software-Technologie und Systemberatung GmbH, Aachen
Württembergische Versicherung AG, Stuttgart
IV.2.2. Beteiligte Personen
Projektteam:
J. Berg,
K. Buse,
J. Gruber,
K. Krüger,
W. Lambertz,
A. Sturm,
K. Wolf,
Deutscher Ring Lebensversicherungs AG, Hamburg
Hamburg-Mannheimer Versicherungs AG, Hamburg
SWT Software-Technologie und Systemberatung GmbH, Aachen
Aachener und Münchener Informatik-Service AG, Aachen
Württembergische Versicherung AG, Stuttgart
Münchener Verein Versicherungsgruppe, München
Aachener und Münchener Informatik-Service AG, Aachen
Projektbetreuung:
B. Gresser,
N. Salentin,
38
Deutscher Ring Lebensversicherungs AG, Hamburg
Aachener und Münchener Informatik-Service AG, Aachen
© GDV 1999
Herunterladen
Explore flashcards