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
![preisliste_gdvprodukte_deutsch_03.02.201[...]](http://s1.studylibde.com/store/data/012194577_1-8163db4f8d0d9da4830b5abb65711d5c-300x300.png)
