Technische Beschreibung der pVAA - GDV

Gesamtverband der Deutschen
Versicherungswirtschaft e.V.
Prozesse
Objekte
Funktionen
Daten
Komponenten
Request Broker
VA A
Edition
1999
Die Anwendungsarchitektur der Versicherungswirtschaft
TECHNISCHE BESCHREIBUNG
DER P VAA
VERSION 2.1
PROZEDURAL
© GDV 1999
http://www.gdv.de/vaa
Autoren:
Der VAA-Arbeitskreis
Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.V., Berlin
http://www.gdv.de/vaa
© GDV 1999
Technische Beschreibung der pVAA
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 VAA-Wissens.
© GDV 1999
http://www.gdv.de/vaa
Technische Beschreibung der pVAA
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
Hauptdokument
neu
Anhang A – Use-Case-Modell –
neu
Anhang B – Klassenmodell –
neu
Modell in Rational-Rose-Format
neu
Objektorientiertes technisches Referenzmodell
neu
Produkt
neu
http://www.gdv.de/vaa
© GDV 1999
Technische Beschreibung der pVAA
I.
Inhalt
Einleitung .............................................................................................................. 3
II. VAA - Schichtenmodell ........................................................................................ 6
II.1.
Schichtenmodell der pVAA-Bausteine .......................................................................................... 7
II.1.1.
Steuerungsebene .................................................................................................................. 9
II.1.1.1.
Steuerungskomponenten .............................................................................................. 9
II.1.1.2.
VAA-Steuerung und Transaktionskonzepte ................................................................ 12
II.1.1.3.
Batchverarbeitung ....................................................................................................... 15
II.1.1.4.
Batchverarbeitung und ACID-Eigenschaften ............................................................... 15
II.1.1.5.
Workflow- und DV-Vorgangssteuerung ....................................................................... 16
II.1.1.6.
Dialogsteuerung .......................................................................................................... 19
II.1.2.
Arbeitsebene ....................................................................................................................... 20
II.1.2.1.
Charakteristika von Anwendungsbausteinen .............................................................. 21
II.1.2.2.
Einbindung eines Anwendungsbausteins .................................................................... 23
II.1.2.3.
Mögliche Anwendungsbausteine eines VU ................................................................. 23
II.1.3.
Dienstebene ........................................................................................................................ 26
II.1.3.1.
II.1.4.
Beispiele einzelner Dienste ......................................................................................... 27
Beispiel eines Durchlaufs durch das Schichtenmodell ........................................................ 28
II.2.
Entkopplungs- und Schnittstellenschicht ..................................................................................... 30
II.3.
Systemplattformen ...................................................................................................................... 32
III.
Kommunikation und Schnittstellen ............................................................... 33
III.1.
Schnittstellen ........................................................................................................................... 33
III.1.1.
Definition und Zielsetzung ................................................................................................... 33
III.1.2.
Schnittstellen in der prozeduralen VAA ............................................................................... 34
III.1.3.
Operative Datenschnittstelle ............................................................................................... 35
III.1.3.1.
Der Datenmanager aus Sicht eines AWB ................................................................... 35
III.1.3.2.
Prozeßdaten................................................................................................................ 36
III.1.3.3.
Beispiel der operativen Datenbeschaffung .................................................................. 37
III.2.
Kommunikationsstruktur.......................................................................................................... 38
III.2.1.1.
IV.
Kommunikationsmatrix ................................................................................................ 40
Anhang............................................................................................................. 42
IV.1.
Zusammenfassung spezifizierter Dienste ............................................................................... 43
IV.1.1.
Datenmanager .................................................................................................................... 43
IV.1.1.1.
Grundprinzipien des Datenmanagers .......................................................................... 43
IV.1.1.2.
Interface zum Datenmanager ...................................................................................... 45
IV.1.2.
Parametersystem ................................................................................................................ 46
IV.1.2.1.
Funktionalität des Parametersystems ......................................................................... 46
IV.1.2.2.
Interface zum Parametersystem ................................................................................. 46
IV.1.3.
IV.2.
Dialogmanager .................................................................................................................... 48
Kommunikationsdienste .......................................................................................................... 49
IV.2.1.
Request Broker ................................................................................................................... 49
IV.2.2.
Modul-Interface-Programm ................................................................................................. 49
© GDV 1999
i
Inhalt
Technische Beschreibung der pVAA
IV.2.3.
IV.3.
Beispiele für weitere Dienste ................................................................................................... 51
IV.3.1.
Archivierungsdienste ........................................................................................................... 51
IV.3.2.
Druck-Manager.................................................................................................................... 51
IV.3.3.
Feldkonverter ...................................................................................................................... 51
IV.3.4.
Handbuch-Verwaltung ......................................................................................................... 51
IV.3.5.
Hilfe-System ........................................................................................................................ 51
IV.3.6.
Mail-System......................................................................................................................... 51
IV.3.7.
Präsentation ........................................................................................................................ 52
IV.3.8.
Prompt-System.................................................................................................................... 52
IV.3.9.
Prüfsystem .......................................................................................................................... 52
IV.3.10.
Problembehandlung ........................................................................................................ 52
IV.3.11.
Referenz-Verwaltungssystem .......................................................................................... 52
IV.3.12.
Schnittstellenkonverter für Alt- und Fremdsysteme ......................................................... 52
IV.3.13.
Schriftguterstellung (Textverarbeitung)............................................................................ 53
IV.3.14.
Sprachenumsetzung........................................................................................................ 53
IV.3.15.
Termin-/Wiedervorlage-System ....................................................................................... 53
IV.3.16.
Vollmachten- und Berechtigungssystem ......................................................................... 53
IV.3.17.
Vorgangsspeicherverwaltung .......................................................................................... 54
IV.3.18.
Währungsumrechnung .................................................................................................... 54
IV.3.19.
Zeitrechnung ................................................................................................................... 54
IV.4.
ii
Kommunikationsinterface .................................................................................................... 50
Literaturverzeichnis ................................................................................................................. 55
© GDV 1999
Technische Beschreibung der pVAA
Einleitung
I. Einleitung
Die
Versicherungsanwendungsarchitektur
VAA
ist
ein
Konstruktionsprinzip
für
Versicherungssoftware. In ihrer prozeduralen Ausprägung besteht sie aus einem fachlichen Modell
und einem technischen Rahmenwerk.
Prozeßmodell
fachlich
Funktionenmodell
Datenmodell
Wiederverwendbare Software-Bausteine
technisch
Standardisierte Schnittstellenarchitektur
Abbildung 1: Hauptbestandteile einer Anwendungsarchitektur
Das fachliche Modell enthält
•
das Datenmodell mit den Entitäten, ihren Attributen und den Beziehungen zwischen den Entitäten,
•
das Funktionenmodell, das die Art der Funktionen und ihre betriebswirtschaftlichen Rollen, ihre
interne statische Struktur und ihren internen Ablauf zeigt,
•
das Prozeßmodell, mit seiner geregelten Folge von Teilprozessen zur Erledigung der Aufgaben
des Unternehmens.
Das technische Rahmenwerk enthält
•
die Anwendungsplattform mit generellen, parametrisierbaren und dadurch wiederverwendbaren
Softwarebausteinen,
•
die standardisierten Schnittstellen zwischen Softwareteilen, die den Kontrollfluß, die Parameterund Datenübergabe, die Modulsynchronisation, usw. festlegen.
Das vorliegende Dokument „Technische Beschreibung der pVAA“ enthält die wesentlichen
Komponenten des technischen Rahmenwerks:
Eine plattformübergreifend einsetzbare Anwendung wird am besten in verschiedene Schichten (Layer)
aufgeteilt, die dann bei Bedarf auf verschiedenen Plattformen ablaufen können. Die Aufteilung sollte
mindestens folgende Schichten umfassen, sofern die Verteilung der Verarbeitung gefordert wird:
© GDV 1999
3
Einleitung




Technische Beschreibung der pVAA
Steuerung: Realisiert arbeitsplatzübergreifende Vorgänge und bindet verschiedene elementare
Aktionen zu Prozessen zusammen, die an einem Arbeitsplatz meist in einem Fluß abgearbeitet
werden.
Präsentation/Interaktion: Stellt Ergebnisse dar und ermöglicht die Eingabe und Änderung von
Daten.
Anwendungslogik/Arbeitsebene: Realisiert die interne Fachlogik eines Anwendungssystems.
Datenebene/Dienstebene: Stellt Datenzugriffe,
anwendungsneutrale Dienste zur Verfügung.
Kommunikationsdienste
und
sonstige
Schichtung erlaubt:



Die Abstraktion von systemspezifischen Eigenschaften einzelner Plattformen in den spezialisierten
Schichten.
Eine einfachere Verteilbarkeit der Software auf verschiedene Rechnersysteme.
Erhöhung der Arbeitsteilung durch Abgrenzung der Funktionalität und Spezialisierung der
Software.

Kategorisierung und Strukturierung der Markt- und Technikvielfalt nach verschiedenen Kriterien.

Verringerung der Komplexität z.B. durch Trennung ansonsten vermischter Funktionsblöcke.

Offenlegung der in den Anwendungen versteckten Kommunikationsströme und Schnittstellen.

Abkopplung von systemtechnischen Eigenschaften diverser Hardware und Softwareplattformen.
Eine weitere wichtige Forderung ist die nach Interoperabilität: Die gemäß der VAA zu realisierenden
Anwendungen müssen problemlos zusammenarbeiten können. Innerhalb der VAA ist also eine
Schnittstellenarchitektur zu definieren. Sie muß es erlauben, mit Benutzern, Funktionen, Daten,
Anwendungen bzw. Systemteilen auch anderer Anwendungssysteme bzw. Systemprogramme über
standardisierte Schnittstellen (z.B.: DCE, RPC oder APPC) zu interagieren.
Interoperabilität ist dann gegeben, wnn verschiedenartige, also heterogene Systeme mit
unterschiedlichen Zweckbestimmungen in einem Verbund zusammenwirken, so daß sie sich dem
Benutzer wie ein einziges homogenes Leistungsgefüge darstellen.
Interoperabilität kann am einfachsten auf der Basis von Standards sichergestellt werden. Beispiele für
Standardisierungsfelder sind:

Benutzerschnittstellen,

Schnittstellen zu grafischen Aufbereitungen,

Betriebssystemschnittstellen,

Kommunikationsschnittstellen,

Schnittstellen zu Datenmanagementsystemen,

Softwareentwicklung.
4
© GDV 1999
Technische Beschreibung der pVAA
Einleitung
Im Anhang des vorliegenden Dokuments sind schließlich die wichtigsten Dienste der prozeduralen
Versicherungsanwendungsarchitektur pVAA zusammengestellt.
© GDV 1999
5
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II. VAA - Schichtenmodell
Ein wesentliches Grundprinzip der VAA ist die Aufteilung der Funktionalität in Schichten. Die
verschiedenen Schichten zeigen:

Trennlinien zwischen einzelnen Anwendungsteilen,

ein Ordnungsprinzip für Komponenten und Bausteine,

eine Möglichkeit der Schnittstellenminimierung und Offenlegung der Schnittstellen,

eine Möglichkeit zur Verteilung von Anwendungen,

eine Möglichkeit zur getrennten Entwicklung von Bausteinen.
Die VAA basiert auf folgendem Schichtenmodell:
Schichtenmodell der VAA-Bausteine
Steuerungsebene
Arbeitsebene
Dienste
Entkopplungs- und Schnittstellenschicht
Generische Generische Generische
OS-Auf ruf e TP-M-Auf ruf e DB-Auf ruf e
Operating
Sy stem
TP-Monitor
DBMS
Generische
Kommunikation
Generische
Client/Serv erAnbindung
Netzwerk
C/SPlattf orm
Systemsoftwareschicht
Hardwareschichten
Abbildung 2: Grundmuster des vorgeschlagenen Schichtenmodells
Die später beschriebenen Bausteine der Steuerungs-, Arbeits- und Dienstebene (siehe auch Abbildung
3) setzen auf einer Entkopplungs- und Schnittstellenschicht auf. Diese Schicht trennt die eigentlichen
Anwendungen von den systemtechnischen Gegebenheiten, z.B. von Datenbanksystemen,
Transaktionsmonitoren, Betriebssystemen, Netzwerken, und Client/Server-Plattformen.
Durch eine konsequente Einhaltung dieses Schichtenprinzips ist eine Verteilung der Anwendung erst
sinnvoll möglich.
6
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
II.1. Schichtenmodell der pVAA-Bausteine
Die wesentlichen Bestandteile der Infrastruktur sind ihre Softwarebausteine, ihre
Kommunikationsstruktur und ihre Schnittstellen. Die Softwarebausteine werden zuerst als
Schichtenmodell dargestellt und in ihrer Funktionalität beschrieben.
Die Bausteinschichtung beschreibt die statische Struktur von Anwendungen im Rahmen der
prozeduralen VAA und ist die Basis für die weitere Beschreibung. Die dynamische Struktur wird im
Beispiel auf Seite 28 beschrieben.
Steuerungsebene
WorkflowManager
Parametersystem
DialogManager
Datenmanager
DV-Vorgangsmanager
Arbeitsebene (Anwendungsbausteine)
Deckungsprüfung
usw.
Tarifierung
Dienstvermittler
Fehlerbehandlung
Provisionsermittlung
usw.
usw.
Präsentation
Dienste
Hilfesystem
Zeitrechnung
Textverarbeitung
Termin- und
Wiedervorl.
Problembehandlung
Abbildung 3: Kontrollflußschichtung
Die Steuerungsebene deckt die Funktionalität Workflowsteuerung, DV-Vorgangssteuerung und
Dialogsteuerung ab. Die Steuerungsebene kann in weitere Ebenen unterteilt werden, um eine
komplexe Hierarchie von Geschäfts- und Teilprozessen zu ermöglichen.



Die Workflowsteuerung legt fest, welche Teilprozesse wann von welchen Bearbeitern erledigt
werden. Dabei muß ein Geschäftsprozeß nicht notwendigerweise in allen Teilen dv-technisch
unterstützt sein. Wesentliche Aufgaben der Workflowsteuerung sind z.B. Prozeßverwaltung,
Prozeßerkennung und Prozeßhistorie. Die Workflowsteuerung deckt somit die organisatorische
Ablaufsteuerung ab. Der Workflowmanager als technische Realisierung der Workflowsteuerung
muß die Einbindung von in sich abgeschlossenen anderen Softwaresystemen erlauben.
Die DV-Vorgangssteuerung steuert die dv-technischen Teilprozesse innerhalb eines
Geschäftsprozesses. Sie regelt, was das DV-System wann, wo und in welcher Reihenfolge tut. Sie
deckt somit die Funktionalität der technischen Ablaufsteuerung ab.
Die Dialogsteuerung regelt die Interaktion des Benutzers mit den VAA-Komponenten. Dazu
bedient sie sich der Präsentationsdienste, die typische Benutzeroberflächen in ihrer
Grundfunktionalität steuern.
© GDV September 1996
7
VAA - Schichtenmodell
Technische Beschreibung der pVAA
Die Arbeitsebene beinhaltet die fachliche Welt eines Versicherungsunternehmen. Diese
Funktionalität wird in Anwendungsbausteinen zusammengefaßt, die ihre betriebswirtschaftliche
Funktionalität über Anwendungsbausteinfunktionen nach außen zu Verfügung stellen. Beispiele von
Anwendungsbausteinen sind:
 Deckungsprüfung
 Tarifierung
 Provisionsermittlung
Die Dienstebene beinhaltet alle generellen Funktionen in Form von Diensten, die von allen anderen
VAA-Komponenten zur Erfüllung ihrer Aufgaben benutzt werden. Beispiele sind:
 Datenmanager
 Parametersystem
 Textverarbeitung
 Präsentation
 Fehlerbehandlung
Die Softwarebausteine, die den Funktionskomplexen im Schichtenmodell entsprechen, werden als
VAA-Komponenten bezeichnet. Im einzelnen sind dies also:

Steuerungskomponenten
 Dialogmanager
 Workflowmanager
 DV-Vorgangsmanager

Anwendungsbausteine

Dienste
Die einzelnen Ebenen und Schichten werden im Detail in den folgenden Abschnitten spezifiziert und
verfeinert.
8
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
II.1.1. Steuerungsebene
Auf dieser Ebene werden die Geschäftsprozesse und ihre Teilprozesse gesteuert. Die Strukturierung
der zugrundeliegenden Geschäftsprozesse in ihrer fachlichen wie technischen Sicht beschreibt die
folgende Grafik:
Ereignis
1:1-Beziehung
1:n-Beziehung
llöst aus
wird unterstützt
Geschäftsprozeß
Ereignis
besteht
aus
steuerung)
veranlaßt
wird unterstützt
Teilprozessen
(Arbeitsfluß-
Workflowmanager
DV-Vorgang
benutzt
Anwendungsbaustein
steuert
oder abgearbeitet
besteht
aus
besteht
aus
Funktionsbaustein
Elementarprozeß
die fachliche Sicht
die technische Sicht
Abbildung 4: fachliche und technische Sicht der Geschäftsprozeßsteuerung
Der Geschäftsprozeß besteht aus einzelnen Teilprozessen. Falls notwendig, kann bis zum
Elementarprozeß weiter untergliedert werden. Den fachlichen Komponenten entsprechen die
technischen
Funktionen
„Workflowsteuerung“
und
„DV-Vorgangssteuerung“.
Die
Workflowsteuerung steuert dabei den Arbeitsfluß zwischen allen beteiligten Personen und
Programmen. Die DV-Vorgangssteuerung steuert die entsprechenden Anwendungsbausteine. Die
notwendige Interaktion mit der Außenwelt wird durch die Steuerung des Dialoges abgewickelt.
Anwendungsbausteine und Funktionsbausteine werden in der Arbeitsebene ab Seite 20 dargestellt.
II.1.1.1. Steuerungskomponenten
Die Abbildung der Ablauflogik (Ablaufsteuerung) der prozeduralen VAA findet in den
Steuerungskomponenten statt:



Der Workflowmanager
Geschäftsprozesse.
steuert
die
Der DV-Vorgangsmanager steuert die dvgestützten Teilprozesse.
Der Dialogmanager steuert die Interaktion
mit der Außenwelt.
© GDV September 1996
Ge schäftsprozeß
Work flow M anage r
Inte rak tion
DialogM anage r
DV-Vorgangs m anage r
DV-ge stützter Teilprozeß
Abbildung 5: Steuerungskomponenten und ihre Objekte
9
VAA - Schichtenmodell
Technische Beschreibung der pVAA
Mit diesen Elementen und den definierten Operationen kann generell die Abwicklung eines
Geschäftsprozesses innerhalb von VAA dargestellt werden. Siehe dazu auch das Beispiel in
Abbildung 14. Zur Steuerung der einzelnen Objekte Geschäftsprozeß, dv-gestützter Teilprozeß und
Interaktion mit der Außenwelt müssen die Steuerungskomponenten mindestens die Operationen
ausführen können, die in der folgenden Grafik dargestellt sind:
Workflowmanager:
Geschäftsprozeß...
...initiieren
...abschließen
...unterbrechen
...w iederaufnehmen
...w eiterleiten
...stornieren
Dialogmanager:
Interaktion...
...initiieren
...abschließen
...suspendieren
...fortführen
...abbrechen
DV-Vorgangsmanager:
DV-gestützten Teilprozeß...
...initiieren
...abschließen
...suspendieren
...fortführen
...abbrechen
Anwendungsbaustein
fachliche Funktionalität...
...initiieren
...abschließen
Abbildung 6: Steuerungshierarchie der VAA
Die Dialogsteuerung kann ebenfalls Anwendungsbausteinfunktionen lesend aufrufen. Dies bedeutet
insbesondere, daß Auskunftsanwendungen ohne DV-Vorgangssteuerung möglich sind.
Die folgende Tabelle beschreibt die einzelnen Eigenschaften der Steuerungsarten im direkten
Vergleich. Hier wird auch die notwendige Trennung zwischen Workflowsteuerung und DVVorgangssteuerung anhand der unterschiedlichen Eigenschaften und Operationen deutlich.
10
© GDV 1999
Technische Beschreibung der pVAA
Eigenschaften der Steuerungsarten
VAA - Schichtenmodell
Workflowsteuerung
DVVorgangssteuerung
Dialogsteuerung
Anwendungsb
austeinsteurung
Geschäftsprozeß
DV-gestützter
Teilprozeß
Interaktion
Fachfunktionen
Ja
Ja
Nein
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Nein
Nein
Ja
Nein
Ja
Ja
Ja
Nein
Nein
Ja
Nein
Ja
Ja
Nein
Nein
Nein
Nein
Nein
unvollständig
definiertes
Prozeßmodell
vollständig
definiertes
Prozeßmodell
Benutzersteuerung
intern
besitzt und
realisiert
Nein
Nein
Nein
Ja
Nein
Nein
Nein
Ja
Nein
Nein
Nein
Ja
--
--
--
Objekt der Verarbeitung
Aufgabe ist die Verwaltung des
Objektes von der Entstehung bis zu
seiner Vernichtung. Dabei entstehen
eine Reihe von Grundoperationen
zur Verwaltung der einzelnen
Objekte:
initiieren
abschließen
suspendieren/fortführen
unterbrechen/wiederaufnehmen
weiterleiten
abbrechen
stornieren
Art der Steuerung
Zustandsmodell
für externe Ereignisse
mehrere Bearbeiter parallel
für
eine
Instanz
Bearbeitungsobjekts
eines
Sitzungsübergreifende
Transaktionen
Transaktionen über die Dauer einer
Sitzung
bzw.
Eines
Verbindungsaufbaus hinweg.
Nachvollziehbarkeit
Protokollierung
der
Schritte
Festhalten des Protokolls
einzelnen
Tabelle 1: Eigenschaften der Steuerungsarten
Innerhalb der Vorgangssteuerung wird durch Suspendierung des DV-Vorgangs der dv-gestützte
Teilprozeß in den Hintergrund gestellt. Die Sitzung und damit die Zuordnung zum Benutzer bleibt
erhalten. Der dv-gestützte Teilprozeß kann jederzeit innerhalb der Sitzung fortgeführt werden.
Unterbrechung über Sitzungsgrenzen hinaus ist Aufgabe der Workflowsteuerung. Die Unterbrechung
schließt die Geschäftsprozeßbearbeitung ab und ermöglicht die Wiederaufnahme durch einen anderen
Benutzer an einem anderen Ort zu einem zukünftigen Zeitpunkt. Dies ist z.B. Voraussetzung für die
Weiterleitung von Geschäftsprozessen und die Realisierung von lang laufenden Transaktionen. Im
Falle eines Abbruchs werden alle Änderungen zurückgenommen und auf den Zustand vor Beginn des
Teilprozesses gesetzt. Im Gegensatz dazu bedeutet Stornierung den Abschluß eines
Geschäftsprozesses durch Kompensation der bisherigen Ergebnisse (z.B. Stornierung eines
Versicherungsvertrages oder Gegenbuchung auf einem Konto).
© GDV September 1996
11
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II.1.1.2. VAA-Steuerung und Transaktionskonzepte
Eine Transaktion1 [Gr81a] verkörpert das Nachvollziehen eines in einer betrieblichen oder
administrativen Anwendung auftretenden realen Vorgangs. Dies geschieht in dem durch eine fachliche
Anwendung und dem integrierten und verwendeten Datenbanksystem (DBS) abgebildeten Ausschnitt
einer Anwendung ("Miniwelt"). Das Ziel des Transaktionsbegriffes ist es, eine möglichst gute
Übereinstimmung der Abbildung dieser Miniwelt mit der realen Anwendung zu gewährleisten. Die
folgenden vier Eigenschaften charakterisieren diesen Transaktionsbegriff in einem technischen Sinne
und wurden in [HR83]2 als das "ACID-Prinzip" vorgestellt:




Atomicity (Ununterbrechbarkeit): Eine Transaktion wird entweder vollständig oder überhaupt
nicht abgewickelt (Prinzip des 'Alles oder Nichts')
Consistency (Erhalten der Konsistenz der Daten): Wird eine Transaktion erfolgreich beendet
und schreibt damit ihre Änderungen in der Datenbank fest, so ist die Datenbank danach wiederum
in einem konsistenten Zustand, falls sie es zu Beginn der Transaktion war. Transaktionen, die ihr
EOT ("End of Transaction") erfolgreich ausführen, wickeln damit per definitionem nur korrekte
Operationen auf der Datenbank ab.
Isolation (Voneinander isolierte Abläufe paralleler Transaktionen): Die von einer laufenden
Transaktion T in der Datenbank vorgenommenen Änderungen gelten solange als vorläufig, wie
diese Transaktion ihr EOT noch nicht erfolgreich abgeschlossen hat, und können bis zu diesem
Zeitpunkt jederzeit wieder rückgängig gemacht werden (z.B. aufgrund von Programmfehlern,
Fehlern in den Daten, Deadlocks mit anderen Transaktionen, Systemausfall usw.). Daher dürfen
solche vorläufigen Änderungen anderen Transaktionen T' auch erst nach dem EOT von T sichtbar
gemacht werden, um T' nicht vom Ausgang von T abhängig zu machen und somit ein isoliertes
Rücksetzen von T zu ermöglichen.
Durability (Dauerhaftigkeit festgeschriebener Änderungen): Erreicht eine Transaktion ihr EOT
und wird dieses erfolgreich beendet und dies dem Anwender bestätigt, so müssen die von der
Transaktion festgeschriebenen Änderungen der Datenbank alle eventuell folgenden Fehler
überdauern, so z.B. Fehler im DBS, im Betriebssystem (BS), einen Stromausfall und auch den
Verlust eines permanenten Speichers, auf dem die Datenbank gehalten wurde ("head crash" auf
einer Magnetplatte usw.).
Zum Einhalten dieser Eigenschaften werden in den meisten heutigen Datenbanksystemen
Sperrverfahren eingesetzt. Diese garantieren, daß eine beliebige parallele Ausführung mehrerer
Transaktionen die Konsistenz der Daten in der Datenbank erhält, indem diese Transaktionen so
miteinander synchronisiert werden, daß das Endergebnis nach ihrem Ausführen dem Ergebnis
entspricht, was durch eine beliebige, aber strikt nacheinander erfolgende Ausführung dieser
Transaktionen entstanden wäre ('Serialisierbarkeitskriterium'). Diese pessimistische Vorgehensweise
ist für "kurze Transaktionen" sinnvoll und bewährt, also für Transaktionen, die üblicherweise eine
Dauer von einigen Millisekunden oder wenigen Sekunden haben und während deren Ausführung
keine Interaktion mit dem Benutzer am Bildschirm stattfindet (die der Benutzer zum Leidwesen aller
anderen über eine z.B. 3-Stündige Kaffeepause offenhalten könnte - andere Benutzer müßten auf die
Freigabe der von ihm gesperrten Daten solange warten). Derartige Bildschirm-Ein-/Ausgaben wurden
1
[Gr81a]
1981, pp. 144-154.
Gray,J.N.: The Transaction Concept: Virtues and Limitations. Proc. 7th International Conference on VLDB, Cannes,
2
[HR83]
Härder,T.; Reuter, A.: Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys,
Vol. 15, No.4, Dec. 1983, pp. 287-317.
12
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
in der Vergangenheit einfach per Konvention verboten, d.h., die fachliche Funktionalität wurde so in
"technische" ACID-Transaktionen zerlegt, daß diese Konvention eingehalten wurde.
Diese Konvention einzuhalten, fällt bei der Ablösung von Masken-Terminals durch moderne
graphische Benutzeroberflächen zunehmend schwerer und ist kaum mehr durchzuhalten. Trotzdem
müssen Blockierungen durch Sperren vermieden und fachliche Transaktionen, die ggf. Stunden oder
Tage dauern, unterstützt werden. Es sind hierfür zwei Maßnahmen sinnvoll, die auch kombiniert
eingesetzt werden können:


Optimistische Synchronisationsverfahren, die so arbeiten, daß man jeder ablaufenden
Transaktion lokale Kopien ihrer Daten verfügbar macht und erst am Transaktionsende, bevor die
lokalen Kopien auf den persistenten Datenbestand zurückgeschrieben werden, überprüft, ob
Inkonsistenzen aufgrund von Parallelarbeit mehrerer Transaktionen auf den Daten entstehen
können. Wenn ja, so wird üblicherweise die Transaktion zurückgesetzt und der Benutzer davon
informiert („noch mal probieren“).
Verallgemeinerte Transaktionskonzepte, bei denen sich komplexere fachliche Transaktionen aus
kurzen ACID-Transaktionen zusammensetzen lassen. Man kann sich beispielsweise vorstellen, daß
eine Kette von ACID-Transaktionen als Sequenz abläuft und man fordert, daß alle Teile dieser
Kette ausgeführt werden müssen, oder die Kette keine Spuren im System hinterläßt („Atomicity“).
Scheitert eine ACID-Transaktion, so sorgt das DBMS üblicherweise dafür, daß diese Transaktion
keine Spuren hinterläßt - sie wird zurückgesetzt. Da dieses Glied der Kette isoliert abgelaufen ist,
haben keine andere ACID-Transaktionen seine Ergebnis-Zwischenstände „gesehen“ und darauf
Bezug genommen (isoliertes Rücksetzen statt kaskadiertes Rücksetzen von Transaktionen). Da die
anderen Transaktionen, in der Sequenz (aber nicht die vollständige Sequenz) jedoch erfolgreich
beendet wurden, sind deren Ergebnisse für andere ACID-Transaktionen (und auch Ketten) sichtbar
gewesen, und ihre Wirkung kann nur durch fachliche Gegentransaktionen kompensiert werden
(z.B. Storno-Transaktionen). Man sieht, daß von den ACID-Eigenschaften die Eigenschaft
"Isolation" diejenige ist, die man bei solchen verallgemeinerten Transaktionskonzepten fallenläßt.
Es ist leicht vorstellbar, nicht nur Ketten von ACID-Transaktionen abzuwickeln, sondern auch
Baumstrukturen zuzulassen - der Bezug zum Geschäftsprozeßmodell wird an dieser Stelle sichtbar.
(Technischer Hinweis: Führt man bei einer solchem Baum von ACID-Transaktionen die
Eigenschaft des Isolierten Ablaufs für den Baum selbst wieder ein, so ist man beim Konzept der
geschachtelten ACID-Transaktionen (Nested Transactions) - kommt räumliche Verteilung hinzu,
so betrachtet man sogar verteilte geschachtelte ACID-Transaktionen).
Beide Methoden, sowohl das Arbeiten mit lokalen Kopien („optimistische Synchronisation“), als auch
die Verwendung verallgemeinerter Transaktionskonzepte, werden in der VAA eingesetzt:

„optimistische Synchronisation“ beim Datenmanager,

„verallgemeinerte Transaktionskonzepte“ beim Geschäftsprozeß.
Damit nutzt die VAA eine eingeführte Terminologie und eine Fülle von bewährten und
dokumentierten technischen Konzepten, wie sie z.B. in [GR933] ausführlich dargelegt sind.
Ein Geschäftsprozeß kann als gerichteter Graph von ACID-Transaktionen aufgefaßt werden. Er hat
einen definierten Anfang und ein definiertes Ende. Dazwischen laufen - ggf. auch verzweigte - Folgen
3
GR93
Gray,J., Reuter,A.: Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers, ISBN 1-55860-190-2
San Francisco, 1993, 1070 S.
© GDV September 1996
13
VAA - Schichtenmodell
Technische Beschreibung der pVAA
von ACID-Transaktionen ab. Ein DV-Vorgang ruft Anwendungsbausteinfunktionen auf. Die
Anwendungsbausteinfunktionen dürfen selbst keine Anweisungen wie Beginne-Transaktion oder
ENDE-Transaktion enthalten, denn die Kontrolle über Anfang und Ende der ACID-Transaktion hat
der DV-Vorgang selbst.
Der DV-Vorgang wird vom Sachbearbeiter in einem Zuge abgearbeitet. Der DV-Vorgang ist daher als
fachliche Transaktion zu betrachten, die den sogenannten ACID-Prinzipien genügt4.
Die Tabelle 2 beschreibt wesentliche Eigenschaften der einzelnen Steuerungskomponenten der
Ablaufsteuerung in der VAA gemäß den ACID-Prinzipien5.
ACID-Eigenschaften der
Steuerungsobjekte
Workflow
steuerung
Atomicity (nicht unterbrechbar)
Consistency (Konsistenzerhaltung)
Isolation (Isolierter Ablauf)
Durability (Dauerhaftigkeit der Ergebnisse)
Nein
Nein
Nein
Ja
DVVorgangssteuerung
Ja
Ja
Ja
Ja
Dialog
steuerung
---------
Anwendungsbaustein
steuerung
---------
Tabelle 2: ACID-Eigenschaften der Steuerungskomponenten
Als fachliche Transaktion, die den ACID-Eigenschaften genügt, muß der DV-Vorgang isoliert
ablaufen. Isolation bedeutet, daß er von den anderen gleichzeitig ablaufenden DV-Vorgängen
abgekoppelt abläuft, so daß diese untereinander keine Änderungen am Datenbestand wahrnehmen, die
von einem noch laufenden und nicht erfolgreich beendeten DV-Vorgang stammen. Mit anderen
Worten: Ein Programmierer schreibt einen DV-Vorgang so, als ob er isoliert und alleine auf dem
Datenbestand arbeitet („logischer Einbenutzerbetrieb“) - das System sorgt dafür, daß er das tun kann
oder - mit anderen Worten - es sorgt für „Isolation“. Isolation wird durch Synchronisationsprimitive
erreicht, die im DBMS und im Datenmanager implementiert sind. Sie werden aus Sicht der DVVorgänge implizit genutzt. Man unterscheidet generell zwei Arten von Synchronisationsmechanismen:
pessimistische und optimistische. Die meisten in kommerziellen DBMS verwendeten Verfahren sind
sog. Sperrverfahren, bei denen gleichzeitiger Zugriff auf Daten durch Sperren von vornherein
verhindert wird. Sperrverfahren sind pessimistische Verfahren, die sich für Transaktionen mit relativ
kurzer Laufzeit bewährt haben. Optimistische(re) Synchronisation geht davon aus, daß
Zugriffskonflikte besonders selten sind (die Ursachen dafür liegen in der fachlichen Anwendung) und
gewähren jeden Datenzugriff (auch ändernde) sofort und ohne Blockierungen, allerdings auf einer
Kopie des Datums. Wenn mehrere Transaktionen auf dieselben Daten zugreifen, so erhält jede dieser
Transaktionen eine für sich lokale Kopie des Datums, auf der dann gearbeitet wird. Erst am Ende der
Transaktion (des DV-Vorgangs) wird überprüft, ob die Zugriffe zu Dateninkonsistenzen im
persistenten Datenbestand führen können. Wenn ja, so besteht in gewissen Fällen die Möglichkeit,
automatische Korrekturmechanismen zu verwenden oder die Transaktion zurückzusetzen und explizit
den Endbenutzer zu informieren. Optimistische Synchronisation wird häufig dann eingesetzt, wenn
man durch Sperren hervorgerufene Blockierungen, die letztlich auf den Endbenutzer am Bildschirm
durchschlagen,
vermeiden
will.
VAA
verwendet
ein
solches
optimistisches
Synchronisationsverfahren.
4
Weitere Details zu der Definition der ACID-Eigenschaften finden Sie in: Land, S.M./ Lockemann, P.C.; Datenbankeinsatz.
Springer-Verlag, 1995 ,Seite 614ff
5
14
P. C. Lockemann; J. W. Schmidt: Datenbankhandbuch.Springer Verlag, 1987, Seite 405
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
II.1.1.3. Batchverarbeitung
Neben
der
prinzipiell
angestrebten
Online-Verarbeitung wird es
innerhalb
der
Versicherungsgesellschaften weiterhin die Notwendigkeit geben, Batch-Anwendungen zu erstellen
und auszuführen.
Diese Anwendungen sind gekennzeichnet durch die Menge der zu verarbeitenden Daten bzw. durch
Geschäftsvorfälle, die durch ihre Art nicht für das Online-Geschäft geeignet sind.
Beispiele hierfür sind:

Massendatenpflege,

Statistiken,

Dokumentendruck,

Zahlungseinzug,

Mahnwesen.
Selbstverständlich können alle diese Geschäftsvorfälle bei entsprechenden fachlichen Anforderungen
und bei einem geringen Datenvolumen online verarbeitet werden. Der Druck einer Rechnung ist
natürlich nicht zeitkritisch, die Selektion und der Ausdruck aller Rechnungen zum Jahresinkasso ist
jedoch sehr zeitkritisch.
Die nächsten Abschnitte befassen sich mit dem Design und der Realisierung von Batch-Anwendungen
unter dem Gesichtspunkt der Einbindung der VAA-Komponenten.
Prinzipiell gilt, daß sich Batch-Anwendungen von Online-Anwendungen nicht unterscheiden. Es sind
jedoch in Bezug auf die Robustheit sowie auf die Performance Besonderheiten zu beachten.
Bezüglich der Robustheit gilt, daß geeignete Verfahren einzusetzen sind, um Synchronisations- und
Konsistenzpunkte zu gewährleisten, z.B. ein Checkpoint-/Restart-Verfahren. Hierbei werden in
bestimmten Zeitintervallen während des Programmlaufs definierte Zustände gesichert, auf die beim
Restart wieder aufgesetzt werden kann.
Um eine ausreichende Performance bei großen Batch-Anwendungen zu erreichen, sind evtl. besondere
Vorkehrungen bezüglich des Datenzugriffs sowie der Modellierung der entsprechenden Datenbanken
zu treffen und zu beachten.
Für die Abwicklung von Geschäftsprozessen innerhalb von Batch-Anwendungen müssen die VAAKomponenten Workflowmanager und DV-Vorgangsmanager ebenso wie bei Online-Anwendungen
nutzbar sein.
Die im Rahmen der pVAA definierten und zur Verfügung gestellten Dienste wie z.B. Datenmanager
und Parametersystem müssen ebenfalls in Batch-Anwendungen integrierbar und aufrufbar sein.
II.1.1.4. Batchverarbeitung und ACID-Eigenschaften
Die Batchverarbeitung zeichnet sich durch folgende Eigenschaften gegenüber Online-TransactionProcessing aus:
© GDV September 1996
15
VAA - Schichtenmodell

Hoher Ressourcenbedarf,

Große Datenmengen,

Sequentielle Zugriffsmuster.
Technische Beschreibung der pVAA
Ein Batch-Auftrag hat grundsätzlich ACID-Eigenschaften. Das bedeutet insbesondere:


Je nach Synchronisationsverfahren werden beim Einsatz von Sperrverfahren viele Sperren zum
Teil sehr lange gehalten. Dadurch werden parallel ablaufende Transaktionen (OLTP) blockiert
Gleichzeitig sinkt der Systemdurchsatz.
Beim Einsatz von optimistischen Synchronisationsverfahren ist die Anzahl in der
Validierungsphase zu überprüfenden Daten sehr hoch. Aufgrund der langen Laufzeit der
Transaktion steigt die Wahrscheinlichkeit für einen negativen Ausgang der Validierungsphase einer
Transaktion..
Deshalb werden Batch-Aufträge normalerweise in Folgen von Teilaufträgen zerlegt. Jeder Teilauftrag
ist eine ACID-Transaktion. Deshalb muß eine Batch-Anwendung eigene Vorkehrungen treffen
(Checkpoint/Restart), um nach einem Systemausfall so weiterzuarbeiten, daß möglichst wenig
geleistete Arbeit verlorengeht. Nach einem Systemausfall ist ein Teilauftrag entweder vollständig
ausgeführt oder zurückgesetzt worden, ohne Spuren im Datenbestand zu hinterlassen.
II.1.1.5. Workflow- und DV-Vorgangssteuerung
In der prozeduralen VAA Architektur bestehen Anwendungen aus einer Menge fachlich
zusammengehörender Geschäftsprozesse, die strukturierte und unstrukturierte Prozesse enthalten
können. Strukturierte Prozesse sind deterministisch. Sie basieren auf festgelegten Regeln und besitzen
einen definierten Anfang und ein definiertes Ende. Im Gegensatz dazu laufen unstrukturierte Prozesse
nicht in jedem Fall nach vorher definierten Regeln.
Bei einer derartigen Betrachtungsweise der Geschäftsabwicklung sind mindestens zwei verschiedene
Steuerungsmechanismen notwendig, um die unterschiedlichen Prozesse zu unterstützen.


Die Steuerung von unstrukturierten Prozessen, die vom Benutzer gesteuert abgewickelt werden
Die Steuerung von deterministischen Prozessen, die von einem DV-System abgewickelt und
gesteuert werden
Dabei kann von folgendem Bild ausgegangen werden: Die strukturierten und damit leicht in
Programme umzusetzenden Prozesse bilden einen Teil der Hilfsmittel, die in den unstrukturierten
Prozessen bei der Bearbeitung angewendet werden. Die Prozesse, die z.B. einen Brieflauf mit all
seinen Zufälligkeiten steuern sind unstrukturiert, die Adreßänderung selbst ist ein strukturierter
Prozeß. Weitere typische Beispiele sind Anwendungen, die mittels Fenstertechnik und ‘Drag and
Drop’ eine nicht festgelegte Verarbeitung zwischen Konsistenzpunkten erlauben.
Durch entsprechende Vereinbarungen und Organisationsregeln ist von einem Wechselspiel zwischen
strukturierten und unstrukturierten Prozessen auszugehen, wobei der Aspekt der Wirtschaftlichkeit den
Umfang der Regelungen bestimmen sollte. Unstrukturierte Prozesse können zu strukturierten
Prozessen mittels entsprechender Regelfestlegung umgeformt werden und umgekehrt. Die Grenze
zwischen den Prozeßtypen ist somit fließend und unternehmensindividuell zu definieren.
16
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
Die heutige Unterstützung der Sachbearbeitung im VU ist fast ausschließlich durch die Abbildung
strukturierter Prozesse realisiert. Hier werden die Regeln der Organisation und der Abwicklung ihrer
Aufgaben durch starre und damit inflexible Mechanismen abgebildet. Wo unstrukturierte Abläufe
auftauchen, werden sie durch Designentscheidungen künstlich in das Korsett eines strukturierten
Prozesses hineingezwängt. Strukturierte Prozesse sind notwendig. Sie müssen jedoch durch die
adäquate Umsetzung der unstrukturierten Abläufe ergänzt werden. Diese Komponente eines Systems
wird durch die Workflowsteuerung unterstützt.
Definition: Mit Workflowsteuerung wird die Steuerung der Abbildung von Geschäftsprozessen und
Teilprozessen auf die Ablauf- und Aufbauorganisation eines Unternehmens bezeichnet. Dazu gehören
insbesondere die Verteilung einzelner Arbeitsschritte auf die Organisationseinheiten und die
Steuerung der zeitlichen Abfolge eines Geschäftsprozesses (inklusive Terminsteuerung).
In unserer Terminologie deckt der Workflow somit sowohl den Bereich der unstrukturierten wie auch
der strukturierten Prozesse ab. Er steuert die Abfolge der einzelnen Knoten, der Teilprozesse des
Netzwerks.
Definition: Ein Teilprozeß ist die Zusammenfassung von Tätigkeiten / Elementarvorgängen, die eine
fachliche Funktion innerhalb eines Geschäftsprozesses abdecken. In diesem Sinne stellt ein Teilprozeß
einen Verarbeitungsabschnitt dar, der eine definierte Aufgabenabgrenzung zu seiner Umgebung hat.
Er kann durch mehrere Rekursionsebenen weiter verfeinert werden.
Die Workflowsteuerung legt einen konkreten Geschäftsprozeß an, steuert die zum Geschäftsprozeß
gehörenden Teilprozesse und sammelt und referenziert die Ergebnisse des Geschäftsprozesses in einer
virtuellen Geschäftsprozeßakte. Sie erstellt die zum Nachvollziehen eines Geschäftsprozesses
notwendigen Verdichtungen der Geschäftsprozeßakte und die benötigten Referenzierungen in Form
eines Logbuches.
Der Workflowmanager


bildet unstrukturierte Prozesse in Funktionalität der Organisation ab und steuert das
Zusammenwirken von Funktionalität, Organisation, Hilfsmitteln und strukturierten Prozessen,
erkennt auslösende Ereignisse eines Geschäftsprozesses und seine internen Zustände als Ergebnis
von strukturierten Prozessen und steuert die daraus resultierenden Teilprozesse in Form von DVVorgängen an.
Häufig wird Groupware als Oberbegriff für Workflowmanagement verwendet. Groupware ist nach
unserer Definition jedoch als Ergänzung eines Workflowmanagements zu sehen.
Definition: Groupware stellt eine Infrastruktur bereit, in der mehrere Stellen gleichzeitig am gleichen
Objekt mittels unter Umständen verschiedener Techniken arbeiten können. Groupware ergänzt also
den obigen Begriff von Workflow um bestimmte spezielle Arbeitsformen.
Ein DV-Vorgang bildet einen fachlichen Teilprozeß auf eine konkrete DV-Umgebung ab. Er kann aus
mehreren Dialogschritten und fachlichen Funktionen in Form von Anwendungs- und
Funktionsbausteinen bestehen.

Die DV-Vorgangssteuerung steuert DV-Vorgänge, die voll strukturierte Abläufe mittels DVTechnik abbilden.
© GDV September 1996
17
VAA - Schichtenmodell

Technische Beschreibung der pVAA
DV-Vorgänge können somit als
Geschäftsprozesses aufgefaßt werden.
dv-technische
Umsetzung
von
Teilprozessen
eines

Die DV-Vorgangssteuerung stößt die benötigten Anwendungsbausteine des Teilprozesses an.

Sie unterstützt die maschinelle dv-technische Umsetzung von festen Regelwerken der Teilprozesse.
Die folgende Tabelle zeigt in einer Gegenüberstellung die wesentlichen Unterschiede der einzelnen
Prozeßklassen und ihre Verwendungsmöglichkeiten.
Unstrukturierte Prozesse
Strukturierte Prozesse
Nur teilw eise oder nicht explizit und
verbindlich festgelegter Prozeß
Deterministischer, auf festen Regeln
basierender Prozeß
Nicht alle Einflußf aktoren sind bekannt bzw .
w erden behandelt
Alle Einflußfaktoren sind bekannt und w erden
behandelt
Keine erzw ungene, erw artete Reaktion
Definierte Reaktion muß erfolgen
?
Steuerung durch menschliche Eingriffe und in
Form von Ereignis-Nachrichtenverbindungen
Nutzung durch Aufruf des Prozesses mit
anschließendem Rücksprung
Sind charakterisiert durch eine Netzw erkstruktur mit Sendern und Empfängern als
Knoten und Nachrichten als Verbindungen
Sind charakterisiert durch Konstrukte w ie
z. B.: strukturierter Prozeß
Workflow netz
Sender/Empfänger
Nachrichten
> Parallelität
> Sequenz
> Sender/Empfänger, Bearbeiter
> Nachrichten
> Entscheidung
> Schleife
Erfahrungs- und entscheidungsbasiert
Regelbasiert
Knoten können durch strukturierte oder unstrukturierte Teilprozesse abgebildet w erden
Können in unstrukturierten/semistrukturierten
Prozessen eingebunden sein
Enthalten keine unstrukturierten Prozesse
Sender/Empfänger
Nachrichten
Beispiele:
>
>
>
>
Beurteilungsprozesse
Orientierungsprozesse
Verteilprozesse
Posteingang und Weiterleitungsmechanismen
w erden durch Workflow -Steuerung kontrolliert
> Änderung von Kundendaten
> Bearbeitung und Ergänzung von
Aktenteilen
w erden durch DV-Steuerung kontrolliert
werden durch Workflowsteuerung unterstützt
Abbildung 7: Charakteristika von Workflow- und DV-Steuerung
18
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
II.1.1.6. Dialogsteuerung
Die Dialogsteuerung6 übernimmt die Kommunikation und Koordination zwischen der
Anwendungslogik und der Präsentation. Der VAA liegt das Modell der Presentation-AbstractionController (PAC-Modell) von Coutaz
zugrunde. In diesem Modell wird die
Abstraktion
Präsentation
Anwender
Anwendungslogik
durch
die
Abstraktionskomponente dargestellt. Die
Ein- und Ausgabe wird in der
Steuerung
Präsentationskomponente kombiniert. Eine
separate Steuerungskomponente - die
Controlkomponente - stellt den Dialog in
Abbildung 8: Das PAC-Modell für interaktive Systeme
Übereinstimmung mit der Anwendung und
Präsentation dar. Im Gegensatz dazu basiert
das häufig verwendete Model-ViewController-Modell auf der Trennung von
Ein- und Ausgabe. Das Modell stellt die
Anwendungssemantik dar, die View
verwaltet die graphische und/oder textuelle
Ausgabe der Anwendung und der Controller
verwaltet die Eingabe. Alle Aktionen der
Abbildung 9: Das MVC-Modell für interaktive Systeme
Anwendung werden über Benutzereingaben
ausgelöst. Die Kommunikation erfolgt bei beiden Modellen über Nachrichten, die zwischen den
einzelnen Komponenten ausgetauscht werden.
View
Monitor
Model
Anwender
Controller
Maus
Tastatur
Durch die Konstruktion mittels des PAC-Modells wird eine Reihe von Eigenschaften ermöglicht wie
z.B.:

Portabilität durch Trennung der Oberfläche von der Anwendung.

Wiederverwendbarkeit.

Mehrfache Oberflächen zu einer Anwendung.
In dem PAC-Modell übernimmt die Dialogsteuerung die Verbindung zwischen Anwendung und
Präsentation auf physischen Endgeräten. Die Präsentation von Anwendungen kann nur über die
Dialogsteuerung erfolgen. Ein direkter Aufruf der Präsentation ist nicht möglich. Dadurch wird die
Implementierungsunabhängigkeit erreicht.
Um die an die Dialogsteuerung gestellten Anforderungen möglichst vollständig und über
unterschiedliche VAA-Softwarekomponenten auch möglichst gleichartig realisieren zu können,
werden diese in einer eigenständigen VAA-Komponente, dem Dialogmanager gebündelt.
Der Dialogmanager ist also ein Softwarebaustein, der - ähnlich wie ein VAA-Dienst - zentral die
Funktionalität der Dialogsteuerung sämtlichen anderen VAA-Komponenten zur Verfügung stellt.
6
Dix, Alan; Finlay, Janet; Abowd, Gregory; Beale, Russel: Mensch Maschine Methodik, Prentice Hall, 1995, Seite 411ff
© GDV September 1996
19
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II.1.2. Arbeitsebene
Aus dem betriebswirtschaftlichen Modell der fachlichen Funktionen und Geschäftsprozesse eines VU
werden die Anwendungsbausteine gebildet. Da die technische Architektur in der Lage sein muß,
beliebige Funktionalität aufnehmen zu können, erhält sie durch diese Abbildung erst ihren
Versicherungsbezug.
Die Arbeitsebene beinhaltet alle Anwendungsbausteine, die von der DV-Vorgangssteuerung
aufgerufen werden können, und die von ihnen benutzten Funktionsbausteine. Beide Bausteintypen
sind möglichst sparten- und vorgangsübergreifend zu entwickeln.
Dabei wird unter einem Anwendungsbaustein die technische Zusammenfassung spezialisierter
Funktionsbausteine zur Abwicklung fachlich zusammenhängender Aufgaben verstanden. Ein
Anwendungsbaustein benutzt die Funktionsbausteine, fügt sie zusammen und erweitert sie
gegebenenfalls.
Unter Funktionsbausteinen verstehen wir eine genau definierte und abgegrenzte Funktionalität, die
über eine definierte Schnittstelle zu Verfügung gestellt wird.
Die technische Architektur der Arbeitsebene bildet die Basis für die in den betriebswirtschaftlichen
und versicherungstechnischen Fachmodellen der prozeduralen VAA definierte fachliche
Funktionalität. Ihre Komponenten - Anwendungsbausteine und Funktionsbausteine - sind
Anwendungsrahmen (generische Bausteine) und idealerweise sparten- und vorgangsübergreifend
definiert. Ihre fachlichen Inhalte sollen außerhalb der Bausteine
im Parametersystem als
Wissenskomponenten gespeichert werden. Dadurch sind alle Bausteine der Arbeitsebene flexibel
konfigurierbar und können von den VU individuell benutzt werden. Die Individualität der Modelle
liegt in ihren ausgelagerten Parametern: dort sind die Geschäftsausprägungen festgehalten.
Die Einführung von Funktionsbausteinen erlaubt eine differenzierte Skalierung hin zu den
Anwendungsbausteinen. Dabei können Funktionsbausteine in mehreren Anwendungsbausteinen
eingebunden werden.
Ausgangspunkt für die Strukturierung der Arbeitsebene muß die abzuwickelnde
betriebswirtschaftliche Funktionalität sein, die bis zur Ebene von nicht mehr sinnvoll
untergliederbaren Elementarfunktionen mit ihren Schnittstellen vorliegen muß (Funktionenmodell).
Nur, wenn die unterste Ebene der betriebswirtschaftlichen Elementarfunktionen festgelegt und ihre
Funktionalität eindeutig beschrieben ist, kann die Arbeitsebene eines VU sinnvoll in technisch
handhabbare und inhaltlich definierbare Funktions- bzw. Anwendungsbausteine gegliedert werden.
Anwendungs- und Funktionsbausteine müssen unter anderem folgende Kriterien erfüllen:


Ihre betriebswirtschaftliche Funktionalität ist eindeutig und redundanzfrei festgelegt.
Sie müssen in handhabbare Blöcke mit geringer
Funktionskopplung nach außen abgegrenzt werden können.
Schnittstellenbreite
und
geringer

Ihre Granularität muß es erlauben, eine Vielzahl von Geschäftsprozessen zu unterstützen.

Sie müssen die Auslagerung fachlichen Wissens erlauben und somit extern konfigurierbar sein.
20
© GDV 1999
Technische Beschreibung der pVAA

VAA - Schichtenmodell
Sie beschaffen ihre Daten selbst, und zwar über den Datenmanager mittels ihrer individuellen
Datensichten.
Die folgenden Kapitel beschreiben die Eigenschaften von Anwendungsbausteinen und skizzieren
einen Weg, Anwendungsbausteine zu definieren. Dies kann unternehmensindividuell auf der Basis
definierter und vorgegebener Funktionsbausteine und des jeweiligen Prozeßmodells erfolgen. Eine
endgültige Abgrenzung kann erst erfolgen, wenn die betriebswirtschaftlichen Elementarfunktionen mit
ihrer Funktionalität, ihren Schnittstellenbeziehungen und ihren Daten vorliegen.
II.1.2.1. Charakteristika von Anwendungsbausteinen
Der Anwendungsbaustein (AWB) ist ein Softwarebaustein zur Abwicklung von fachlich
zusammenhängenden Aufgaben. Er stellt die fachliche pVAA-Komponente dar, die austauschbar ist,
und bildet somit die Einheit, die von Softwareherstellern angeboten werden kann. Der
Anwendungsbaustein stellt einen oder mehrere fachliche Dienste bzw. Funktionen zu Verfügung, die
von der DV-Vorgangssteuerung aufrufbar sind.
 Ein Anwendungsbaustein ist ein reiner
Diese
Dienste
nennen
wir
Softwarebaustein.
Anwendungsbausteinfunktionen
(AWB Ein Anwendungsbaustein wird nur von
Funktionen). Die AWB-Funktionen werden
der Steuerungsebene aufgerufen.
ausschließlich von der DV-Vorgangssteuerung
aufgerufen. Der Grund liegt in der Entflechtung
 Ein Anwendungsbaustein wird von
und Konzentration der Steuerung. Zwischen
Herstellern angeboten.
AWB darf es keine Herstellerabhängigkeiten
 Ein Anwendungsbaustein stellt eine oder
geben. Eine AWB-Funktion gehört zu genau
mehrere technische realisierte fachliche
einem AWB, hier ist keine Redundanz erlaubt.
Funktionen oder Dienste bereit
Die AWB-Funktionen sind nicht unterbrechbar,
sie verwenden keine Präsentation, sie haben kein
Gedächtnis. Der AWB beschafft seine Daten selbst über den Datenmanager. Die Nutzung externer
Ressourcen erfolgt nur über Dienste der prozeduralen VAA. Damit kann Plattformunabhängigkeit
sichergestellt werden. Der AWB muß erweiterbar sein (User-Schnittstelle, Exit o.ä.). Für die interne
Realisierung der AWB gibt es keine Designvorschriften. Möglich wären z.B. Objektorientierung,
prozedurale, generische Programme. Der AWB gruppiert die Funktionen ausschließlich nach
fachlichen Zusammenhängen und Abhängigkeiten (minimale Daten- und Funktionskopplung). Die
gleiche Funktion aus dem fachlichen Funktionenmodell kann in verschiedenen AWB vorkommen, hier
gibt es keinen Anspruch auf Redundanzfreiheit.
Eine Anwendungsbausteinfunktion ist nicht unterbrechbar. Diese Forderung hat weitgehende
Konsequenzen. Sie ist eines der wesentlichsten Kriterien zur Bestimmung einer
Anwendungsbausteinfunktion. Diese Forderung impliziert folgende Eigenschaften einer
Anwendungsbausteinfunktion:

Die Funktion darf keinen Dialog zulassen.

Die Funktion weiß nicht woher ihr Auftrag kommt und was nachher passiert.

Die Funktion hat kein Gedächtnis.
Wie die innere Funktionalität gebildet wird, ist hier nicht von Interesse. Sie kann von den Herstellern
eines Anwendungsbausteins nach den verschiedensten Verfahren realisiert werden, sofern das äußere
Verhalten des Anwendungsbausteins ohne Einschränkung nachgebildet wird. Redundanzfreie
© GDV September 1996
21
VAA - Schichtenmodell
Technische Beschreibung der pVAA
Codierung wird nicht verlangt. Um allerdings die hier aufgrund großer Anwendungsbausteine
notwendige exakte Beschreibung der Funktionalität handhabbar zu machen, um in einem ersten Schritt
das Design zu vereinfachen und um Wiederverwendbarkeit mindestens innerhalb eines
Anwendungsbausteins zu fördern, ist der Begriff der Funktionsbausteine notwendig.
Funktionsbausteine bilden die fachliche Funktionalität in eine dv-technische Umgebung ab.
Üblicherweise empfiehlt es sich, diese Abbildung auf der Ebene der fachlichen Elementarfunktionen
vorzunehmen.
Die Bildung von Anwendungsbausteinen ist eine Designentscheidung. Deshalb folgen einige
Hinweise, wie man zu Anwendungs- und Funktionsbausteinen kommen kann:
Anwendungsbaustein
Anwendungsbausteinfunktionen
Entity
Anwendungsbausteinfunktionen
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
DatenSchnittstelle
ParameterSchnittstelle
Aufrufschnittstelle
Funktion im
Funktionenmodell
Funktion im
Funktionenmodell
interne Steuerung
Funktion im
Funktionenmodell
SoftwareBaustein
fachlicher
Baustein
Entity
Entity
logisches
Datenmodell
Abbildung 10: Verbindung eines Anwendungsbausteins mit dem fachlichen Modell
Der Anwendungsbaustein faßt Funktionsbausteine (FBS) zusammen, die die interne Funktionalität des
Anwendungsbausteins beschreiben. Der Funktionsbaustein ist ein Konstrukt, welches als
Strukturierungs- und Dokumentationshilfe dient. Er kann für das Finden von Anwendungsbausteinen
hilfreich sein. Er ist keine Implementierungsvorschrift. Der Funktionsbaustein verbindet fachliche
Funktionalität mit der DV-Technik. Er stellt die dv-technische Realisierung einer oder mehrerer
Elementarfunktionen aus dem fachlichen Funktionenmodell dar. Fachliche Funktionen, die zwingend
voneinander abhängig sind, gehören in den gleichen Anwendungsbaustein. Der Zuschnitt der
Anwendungsbausteine in den Projekten Partner, Schaden/Leistung und Provision kann nur vorläufig
sein. Die endgültige Festlegung der Anwendungsbausteine muß unter Berücksichtigung aller
relevanten Fachfunktionen und ihrer Verwendung in den Geschäftsprozessen erfolgen.
Zusammenfassend bleibt festzuhalten:
Kern der versicherungstechnischen Leistungen der pVAA sind die Anwendungsbausteine der
Arbeitsebene.
Anwendungsbausteine
exportieren
ihre
Funktionalität
über
Anwendungsbausteinfunktionen an die DV-Vorgangssteuerung. Die Funktionalität eines
Anwendungsbausteins kann nur über die DV-Vorgangssteuerung angestoßen und genutzt werden.
Anwendungsbausteine gruppieren versicherungstechnische Funktionen nach sachlogischen
Gesichtspunkten. So wird zwischen Anwendungsbausteinen minimale Funktions- und Datenkopplung
gefordert. Die Funktionalität eines Anwendungsbausteins muß exakt spezifiziert werden, um gleiche
Anwendungsbausteine von verschiedenen Herstellern in die Architektur einbinden zu können. Anhand
dieser Spezifikation kann erst die VAA-Konformität der realisierten Funktionalität eines
Anwendungsbausteins und die eventuell notwendigen Erweiterungen ermittelt werden. Gefordert wird
22
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
mindestens die Realisierung einer Kernfunktionalität durch einen Hersteller. Redundanz im erstellten
Code wird hierbei in Kauf genommen, da nicht erwartet werden kann, daß die unterschiedlichen
Hersteller von Anwendungsbausteinen auf gemeinsame Codeteile herstellerübergreifend außerhalb der
definierten Dienste der VAA zurückgreifen werden.
II.1.2.2. Einbindung eines Anwendungsbausteins
Die folgende Abbildung beschreibt detaillierter die Einbettung eines Anwendungsbausteins in den
Kontext der VAA-Elemente:
DV-Vorgangssteuerung
Dialogsteuerung
ParameterSchnittstelle
Anwendungsbausteinfunktionen
Anwendungsbausteinfunktionen
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Funktionsbaustein
Datenmanager
Aufrufschnittstelle
DatenSchnittstelle
Parameter-system
Anwendungsbaustein
interne Steuerung
Abbildung 11: Einbindung eines Anwendungsbausteins
Anwendungsbausteine stellen der Steuerungsebene eine Reihe von versicherungsbezogenen Diensten,
sogenannte Anwendungsbausteinfunktionen, zu Verfügung. Diese Dienste werden von der
Steuerungsebene verwendet, um die Geschäftsprozesse eines Versicherungsunternehmens zu gestalten
und in DV-Unterstützung abzubilden. Einzig die DV-Vorgangssteuerung darf die
Anwendungsbausteinfunktionen nutzen. Andere Anwendungsbausteine können diese Funktionalität
nur über entsprechende Statusänderungen und über die Steuerebene nutzen, ohne direkt die
Folgefunktion zu kennen. Sie exportieren kein Verhalten, sondern bestimmen die Folgeverarbeitung
nur über Zustände, die die DV-Vorgangssteuerung kennt und interpretiert. Die von einer
Anwendungsbausteinfunktion zu leistende Arbeit wird nur durch die eindeutige
Schnittstellenspezifikation in Form eines genau spezifizierten Vertrages (Programming by Contract)
bestimmt.
II.1.2.3. Mögliche Anwendungsbausteine eines VU
Zur Ermittlung von Anwendungsbausteinen der Arbeitsebene wird ein erster Ansatz verfolgt, der sich
an den zentralen Geschäftsobjekten eines Versicherungsunternehmens orientiert. Jedes
Geschäftsobjekt bildet den Kern eines Anwendungsbereichs, innerhalb dessen mit Hilfe von
Anwendungsbausteinen und den dazugehörenden Funktionsbausteinen die Bearbeitung des
© GDV September 1996
23
VAA - Schichtenmodell
Technische Beschreibung der pVAA
Geschäftsobjektes stattfindet. Die Geschäftsobjekte werden als Aggregationen von Entitäten des
Datenmodells eines VU verstanden.
Wir beschreiben in diesem Abschnitt Anwendungsbausteine ohne Anspruch auf Vollständigkeit.
Endgültig kann ein normiertes Modell von Anwendungsbausteinen der Arbeitsebene nur durch
Verdichtung und Aggregation von definierten, fachlichen Elementarfunktionen strukturiert werden.
Wir gehen derzeit von den folgenden Geschäftsobjekten des versicherungstechnischen Kerngeschäfts
aus. Die zu den Geschäftsobjekten Versicherungsvertrag und Schaden/Leistung definierten
Anwendungsbausteine wurden durch die jeweiligen Projektgruppen erarbeitet. Eine detaillierte
Beschreibung der Funktionalität dieser Anwendungsbausteine kann den Dokumentationen der
Projektgruppen Vertrag und Schaden/Leistung entnommen werden.
Geschäftsobjekt7
beispielhafte Anwendungsbausteine
Versicherungsvertrag
Bedarfsanalyse
Versicherbares Objekt aufnehmen, Risikomerkmale erheben
Risikoprüfung und Bewertung
Produktbezogene Kundenberatung
Klauseln und Bedingungen vereinbaren
Versicherungstechnische Berechnungen
Provisionsbewertung und -berechnung
Führung, Beteiligung
Ausgehende
Dokumente,
Briefe
(Versicherungsschein,
Bedingungen, Korrespondenz)
Wahrung der Rechte Dritter (Sicherungs-, Abtretungsgläubiger)
Periodische Änderungsprozesse (Vertragsbestandsbezogen)
Genereller Änderungsdienst und Historienbildung
Schnittstellenerstellung für nicht Vertrag
Partner
Partnerbeziehungen/-rolle pflegen
Partnerdaten pflegen
Kommunikationsdaten pflegen (Adreßverarbeitung)
Schaden/Leistung
Eingangsbearbeitung
Schadenanlage
Reserve-Bearbeitung
Deckungsprüfung
Leistungs-Bearbeitung
Forderungs-Bearbeitung
Schadenrückkaufs-Bearbeitung
Ende-Bearbeitung
Angebote,
Geschäftsprozeß-Dokumentation Geschäftsprozeß-Akte führen (anlegen, bearbeiten, schließen)
Logbuch erstellen
Produkt
Produkt entwickeln/definieren
Produkt pflegen
Konto
Abrechnung des Kontos (Provision, Beitrag, Gehalt, Schaden)
Buchung durchführen
Geldeingang verarbeiten (MV)
Es ist zusätzlich das Geschäftsobjekt „Regelwerk“ vorstellbar, welches Vertragsbedingungen, Klauseln, etc. enthält. Die
Anwendungsbausteine zur Realisierung dieser Regelwerke sind im allgemeinen in der Dienstebene zu finden. Die im Vorfeld stattfindende
Entwicklung von Regelwerken ist Bestandteil der Arbeitsebene - in der Regel ohne Anwendungsbaustein.
7
24
© GDV 1999
Technische Beschreibung der pVAA
Geschäftsobjekt7
VAA - Schichtenmodell
beispielhafte Anwendungsbausteine
Geldausgang verarbeiten
Dokumentation von Geld- und Güterbewegungen
Versicherungsobjekt
Objektdaten pflegen
Objektbeziehungen pflegen (Standorte)
Dokument, Datenträger,
Schrifstück
Eingehende Dokumente verwalten und archivieren
Ausgehende Dokumente erstellen, verwalten und versenden
Archivverwaltung
Abbildung 12: Geschäftsobjekte und Anwendungsbausteine eines VU
© GDV September 1996
25
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II.1.3. Dienstebene
Die Summe aller Dienste bildet die Anwendungsinfrastruktur/Basisdienste der prozeduralen VAA.
Jeder Dienst stellt gemäß der noch zu definierenden Schnittstellenkonventionen der pVAA
wohldefinierte Schnittstellen zur Verfügung, die von den rufenden Softwarebausteinen einzuhalten
sind.
Die Dienstebene nimmt in der pVAA eine zentrale Stellung ein. Ihre Aufgabe besteht darin,
sogenannte Querschnittsfunktionen in Form von Diensten für alle Ebenen und Bereiche der VAA zur
Verfügung zu stellen. Aus dieser Aufgabenstellung heraus ergibt sich zwangsläufig, daß die Dienste
der Dienstebene Schnittstellen zu allen Softwarebausteinen bereitstellen müssen. Die Art und Weise
dieser Schnittstellentechnik - Dienstvermittlung genannt - bedarf daher einer besonderen und
intensiven Betrachtung.
Zunächst werden in der Dienstebene sämtliche Dienste ohne weitere Unterstrukturierung
zusammengefaßt. Ob eine weitere Strukturierung bei steigender Anzahl der Dienste in Zukunft
sinnvoller wäre, soll zunächst noch offen bleiben.
Die Dienstebene beinhaltet also wiederverwendbare Funktionen, die allgemeine Dienste für die
Steuerungs- und Arbeitsebene bereitstellen. Die Dienste müssen über eine Entkopplungsschicht von
physischen Details abgekoppelt werden. Einige Beispiele solcher Dienste sind:
 Hilfe-System
 Schriftguterstellung
 Datenmanager
Dienste können als selbstständige Softwarebausteine von den Steuerungskomponenten und von allen
Anwendungsbausteinen benutzt werden. Sie können sich auch gegenseitig nutzen. Typische Dienste
beschaffen sich eigenständig nur Konfigurationsdaten und lokal benötigte Daten. Operationale Daten
werden nur über die Aufrufschnittstelle übergeben und nicht selbst beschafft.
Ausgenommen von dieser Einschränkung sind

der Datenmanager und

das Parametersystem.
Diese zwei Dienste nehmen eine besondere Rolle ein. Dies liegt an ihrer Art (Datenversorgung), an
der Häufigkeit ihres Aufrufs und an der speziellen Funktionalität.
In der Kommunikation mit diesen Diensten ist ihrer besonderen Stellung Rechnung zu tragen. Aus
diesem Grund sind hierfür spezielle u.U. maßgeschneiderte Kommunikationsdienste zu entwickeln.
Die Verbindung zwischen dem Rufer und dem Dienst erfolgt über die sogenannte
„Dienstvermittlung“, eine Technologie, die gemäß der „Request-Broker-Methode“ arbeitet und sich an
den Prinzipien von CORBA anlehnt.
26
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
Der Rufer ruft über wohldefinierte Schnittstellen den Dienst. Ob, wo und unter welchen Bedingungen
der Dienst arbeitet, weiß nur der Dienstvermittler. Der Rufer erhält daraufhin nur die „geforderte“
Dienstleistung. Alle zusätzlichen Informationen sind für den Rufer transparent.
Bei der Implementierung der Dienstvermittlung werden die jeweiligen Standards von CORBA
berücksichtigt.
II.1.3.1. Beispiele einzelner Dienste
Beispielhaft werden hier einige Dienste aufgeführt.
 Request Broker und Modul-Interface-Programm
 Datenmanager und Parametersystem
 Präsentation
 Kommunikations- und Schnittstellendienste
 Hilfe-System
Eine weitergehende Beschreibung einzelner Dienste befindet sich im Anhang.
© GDV September 1996
27
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II.1.4. Beispiel eines Durchlaufs durch das Schichtenmodell
Der
folgende
Geschäftsprozeß
wurde
aus
einem realen
Geschäftsprozeß
eines
Versicherungsunternehmens entwickelt und verdichtet dargestellt. Dieser Geschäftsprozeß wird im
folgenden zur exemplarischen Darstellung seiner Realisierung durch das Zusammenspiel der einzelnen
Komponenten genutzt.
Antrag
liegt vor
manuelle
Vorarbeiten
DV-Vorgang "Antragsverarbeitung"
Kundendat.
verarbeiten
allg, Risiken
prüfen
Ablehnung
erstellen
Ablehnung
erstellt
Vollständ.
prüfen
Unterlagen
nachfordern
Nachf.
erstellt
fachl. Risiko
prüfen
Auflagen
erteilen
Auflagen
erteilt
Dokument
erstellen
Akzept
Provision
berechnen
Zahlung
RV
ermitteln
RV-Zahlung
Beitrag
berechnen
Abbildung 13: Beispiel eines einfachen Geschäftsprozesses ‘Antragsverarbeitung’
Die folgenden Darstellungen sollen die Zusammenhänge exemplarisch verdeutlichen. Deshalb sind an
einigen Stellen Vereinfachungen im Detaillierungsgrad vorgenommen, die der Klarheit der
Darstellung dienen.
Als erstes Beispiel wird das Zusammenwirken der einzelnen Steuerungskomponenten im Falle einer
Ablehnung des Antrags nach der allgemeinen Risikoprüfung aufgezeigt. Inwieweit angefallene Daten
in die operativen Daten des Unternehmens übernommen werden oder ob sie temporär genutzt werden,
28
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
ist im Dienst der allgemeinen Änderungsfunktion versteckt und ist hier nicht Gegenstand der
Darstellung.
WorkflowSteuerung
(GePro)
Zustand,
Ereignis
Antrag
liegt vor
Antragsbearbeitung
initiieren
DV-VorgangsSteuerung
(Teilprozeß)
Kundendaten
verarbeiten
DialogSteuerung
(Interaktion)
AWBFunktionen
Kundendaten
erfassen
ok
Kunde anlegen
ok
ok
Antragsdaten
verarbeiten
K
Antragsdaten
erfassen
ok
Risiko prüfen
Ablehnung
Brief erstellen
Ablehnung
erstellt
ok
ok
ok
Abbildung 14: Zusammenwirken der Steuerungskomponenten der VAA
Zustandsänderungen wie z.B. stornieren, entfernen, unterbrechen, weiterleiten der mit dem
Geschäftsprozeß korrespondierenden Daten bleiben der Workflowsteuerung vorbehalten, da sie als
einzige Komponente den Geschäftsprozeß in seiner Gesamtheit überblickt.
Es werden innerhalb des Geschäftsprozesses zwei Teilprozesse abgewickelt, die durch einen
möglichen Konsistenzpunkt (K) voneinander getrennt werden. Somit kann sichergestellt werden, daß
einmal aufgenommene Kundendaten im System nicht verloren gehen. Die Teilprozesse bedienen sich
der Dialogsteuerung, um Kundendaten und Antragsdaten zu erfassen. Anwendungsbausteine. Deutlich
wird in diesem Beispiel, daß Anwendungsbausteinfunktionen nur von der DV-Vorgangssteuerung
aufgerufen werden.
© GDV September 1996
29
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II.2. Entkopplungs- und Schnittstellenschicht
Die Erhöhung der Lebensdauer eines Anwendungssystems bei gleichzeitiger Reduzierung des
Wartungsaufwands ist eine Problemstellung, die die Softwareentwicklung seit den 60er Jahren
intensiv beschäftigt. Eine adäquate Lösung ist in der VAA bereits als Grundanforderung eingearbeitet
worden. Unter den Schlagworten „Plattformunabhängigkeit“, „Offenheit“ und „Portabilität“ wurden
Softwareeigenschaften gefordert, die es erlauben, Anwendungssysteme ohne bzw. mit nur geringem
Aufwand auf verschiedenen Systemplattformen lauffähig zu machen. Dieses Ziel wurde beim
Übergang von den Programmiersprachen der 2. Generation (Assemblersprachen) zu denen der 3.
Generation (problemorientierte Sprachen) bereits einmal verfolgt. Erhebliche technische
Weiterentwicklungen bei gleichzeitiger Stagnation der Sprachenentwicklung (siehe beispielhaft
COBOL) haben die Erreichung dieses Ziels allein mit Mitteln der Programmiersprache in weite Ferne
rücken lassen.
Wesentlich erfolgversprechender ist derzeit die Konzeption einer hierfür eigens zu realisierenden
Softwareschicht, die Entkopplungsschicht genannt wird. Aufgabe dieser Schicht ist die Entkopplung
von Anwendungssystem und Systemplattform. Die Entkopplungsschicht arbeitet so im Sinne einer
Middleware.
Sie vermittelt also Funktionalität einer tieferen Schicht (Systemplattform-Dienste) an die oberen
Schichten (Anwendungen) über logische Funktionsaufrufe, die je nach Ausprägung der unteren
Schichten in spezielle Funktionsaufrufe bzw. Funktionsketten umgesetzt werden:

zum Betriebssystem, z. B. MVS, OS/2, UNIX, Windows

zum Transaktionsmonitor, z. B. CICS

zum Datenbank-Managementsystem, z. B. IMS, DB/2

zum Netzwerk-Management und den Kommunikationsdiensten

zur Client/Server-Plattform

zur Präsentationssoftware.
Die Funktionsaufrufe innerhalb der Anwendungen erfolgen über standardisierte und offene APIs Application Programming Interfaces, die ihrerseits nur noch von der verwendeten
Programmiersprache abhängig sind. Die Aufrufe der Systemplattformschicht erfolgen spezifisch zur
Systemplattformausprägung.
Hierbei soll nicht ausgeschlossen werden, daß im Rahmen eines Middleware-Konzepts zwischen
Entkopplungsschicht und Systemplattform weitere Schichten existieren, die für die
Anwendungsarchitektur aber ohne jegliche Bedeutung sind.
30
© GDV 1999
Technische Beschreibung der pVAA
VAA - Schichtenmodell
Für jede Gruppe von Diensten der Entkopplungsschicht hier ein Beispiel:


der Aufruf einer Maskenanzeige aus einer Dialoganwendung mittels eines Maskenhandlingsystems
(z.B. MFS, BMS, FHS)
der Aufruf zur Datenbeschaffung aus einem hierarchischen DB-System (z.B. DL/1)
Anwendung
Entkopplungsmodul
Datenservices
DL/1
Interface
Datenmanager
DBAPI
DL/1
SystemProgramm
DL/1 DB
DBAPI
Abbildung 15: Arbeitsweise der Entkopplungsschicht am Beispiel DL/1


der Aufruf einer Transaktion (Anwendung) innerhalb eines Transaktionsmonitors (z.B. IMS/DC,
CICS, UTM)
der Aufruf einer Verfügbarkeitsprüfung eines Dienstes auf einem entfernten System
Alle Beispiele zeigen deutlich, daß ein direkter Aufruf ohne Entkopplungsschicht zu einer
vollständigen Abhängigkeit von der eingesetzten Systemplattform führen würde.
Bei der Implementierung der Entkopplungsschicht sollten, soweit vorhanden bzw. möglich, Standards
zum Einsatz gelangen (z.B. Embedded SQL für den Datenmanager), um so eine möglichst weite
Verfügbarkeit auf unterschiedlichsten Systemplattformen zu erreichen. Um die Portabilität zu
gewährleisten, kann es notwendig sein, bestimmte betriebssystemnahe Funktionen in die
Entkopplungsschicht zu legen.
© GDV September 1996
31
VAA - Schichtenmodell
Technische Beschreibung der pVAA
II.3. Systemplattformen
Die Systemplattform stellt einer Anwendung diejenigen Softwareteile zu Verfügung, die es erlauben,
die Anwendung in einer Laufzeitumgebung (Hardware, Betriebssystem, Systemprogramme, u.v.a.m.)
auszuführen. Diese Softwareschicht wurde häufig auf einer ganz speziellen Hardware eines einzigen
Herstellers bereitgestellt.
Anfang der 90er Jahre hat sich jedoch auch bei den Systemplattformen ein Trend zur Standardisierung
herausgebildet. Die marktgängigsten Hersteller wie IBM, Siemens/Nixdorf, HP, DEC, Microsoft,
Software AG u. a. bieten ebenfalls unter dem Begriff Anwendungsarchitektur Konzepte an,
Anwendungssysteme auf unterschiedlichen Systemplattformen ablauffähig zu gestalten. Diese
Konzepte waren je Anbieter sehr unterschiedlich und unterstützten im Regelfall auch ausschließlich
eine Systemunabhängigkeit innerhalb der entsprechenden Herstellerwelt. Eine Durchlässigkeit
zwischen unterschiedlichen Herstellerwelten war höchstens in Ansätzen erkennbar. Hier wurden in
den letzten Jahren mit der Verwendung der Internet-Technologie einerseits und dem
Komponentenansatz (CORBA 2.0, COM/DCOM) andererseits erhebliche Fortschritte gemacht.
Die in der Versicherungsbranche gängigsten Systemplattformen sind in der nachfolgenden Tabelle
dargestellt. Diese Plattformen sollten auf jeden Fall VAA-kompatibel gestaltet werden. Denn
Anwendungssysteme, die augenblicklich auf diesen Plattformen entwickelt werden, sollten später in
die VAA übertragen werden können. Diese Tabelle ist keine vollständige Übersicht.
Open Blueprint,
SAA
Kommunikation SNA/LU6.2/TCPIP/Token Ring
CUA/OSF-Motif/PM
Grafische
Oberfläche
Betriebssysetem MVS AIX OS/2
Interoperabilität
Prozessor
Anbieter
/370
RISC
IBM
Intel
DCE/DME
WOSA
...
TRANSDATA/TCPIP
OSF-Motif
TCP-IP/Novell
...
OSF-Motif/Windows
...
BS2000
SINIX
7.5xx und
RISC
7.8xx
Siemens/Nixdorf
Windows/Windows
NT
Intel/RISC
Microsoft
...
...
...
Tabelle 3:.Gängige Systemplattformen (beispielhaft)
32
© GDV 1999
Technische Beschreibung der pVAA
Kommunikation und Schnittstellen
III. Kommunikation und Schnittstellen
VAA ist eine komponentenbasierte Architektur. Die einzelnen Komponenten der VAA müssen exakt
spezifiziert und vollständig aufgezählt werden. Die Aufzählung und Beschreibung der einzelnen
Komponenten ist notwendig aber nicht hinreichend. Zur vollständigen Beschreibung der technischen
Architektur ist genauso notwendig, die Verbindung der einzelnen Komponenten exakt zu beschreiben
und festzulegen. Die Verbindung wird durch zwei Aspekte vollständig beschrieben. Diese sind:


die Schnittstellen, die die möglichen Verbindungen zwischen den einzelnen Komponenten und
ihre Struktur beschreiben.
die Kommunikationsmechanismen, die die tatsächliche Realisierung und Umsetzung der
möglichen Schnittstellen durch den Transport der ihnen innewohnenden Informationen möglich
machen.
III.1. Schnittstellen
Die Bedeutung des Schnittstellenthemas ergibt sich aus dem Bausteinprinzip und letztendlich aus dem
Prinzip der Modularisierung. Die Funktionalität der Bausteine muß benannt und klar abgegrenzt sein.
Die Strukturen, Inhalte und Auswirkungen aller relevanten Daten auf die Funktionen eines Bausteins
sind als Schnittstelle zu definieren und zu beschreiben. Nur über die Standardisierung von
Schnittstellen (Definition und Offenlegung der Spezifikation, allgemeiner Konsens) ist die angestrebte
Verwendung von vorgefertigten, wiederverwendbaren Bausteinen, ihre Austauschbarkeit und isolierte
Weiterentwicklung möglich.
Die detaillierte Festlegung von Schnittstellen wird im nächsten Schritt in Angriff genommen werden,
da umfassende Prinzipien und Definitionen noch zu klären sind und entsprechende Standards noch
nicht vorliegen.
III.1.1. Definition und Zielsetzung
Der Begriff der „Schnittstelle“ spielt in der Informationstechnologie, insbesondere hier in SoftwareArchitekturen, eine entscheidende und zentrale Rolle. Dies gilt auch für die VAA.
In der VAA wollen wir Schnittstellen als eine „Spezifikation der Art und Weise einer
Kommunikation/Verbindung
zwischen
zwei
oder
mehreren
wohldefinierten
Kommunikationspartnern“ verstehen. Klassische Beispiele von Schnittstellen sind:

die Schnittstelle zwischen Haupt- und Unterprogramm

die Schnittstelle zwischen einem PC und einem Drucker

die Schnittstelle in einer verteilten Datenbankarchitektur
Die Schnittstellenarchitektur innerhalb der VAA wird von folgenden Zielsetzungen getragen:

möglichst starke Vereinfachung der Schnittstellen
© GDV 1999
33
Kommunikation und Schnittstellen
Technische Beschreibung der pVAA

Klassifikation und Typisierung von Schnittstellenklassen

möglichst exakte Spezifikation der Schnittstellen

Nutzung vorhandener Standards

Berücksichtigung anerkannter Grundprinzipien, wie Kapselung, Entkoppelung etc.
III.1.2. Schnittstellen in der prozeduralen VAA
Die folgende Grafik beschreibt mit einigen hervorgehobenen Diensten (Datenmanager,
Parametersystem) das Zusammenwirken einzelner Teile der pVAA. Die möglichen Schnittstellen
zwischen den einzelnen Systemen werden durch Pfeile mit entsprechenden Nummern gekennzeichnet.
Deutlich wird hier das Zusammenspiel der einzelnen Steuerungskomponenten, die die Abwicklung
eines Geschäftsprozesses erlauben.
Param e te rSys te m m it
Ge s chäfts und Ste ue rungs Param e te rn
Date nm anage r
Ste ue rungs k om pone nte n
Workflowmanager
2
1
1
2
Vorgangsspeicher
DV-Vorgangsmanager
5
E/R Modellbeschreibung
Vorgangstabellen
Dialogmanager
1
4
Anw e ndungs baus te ine
3
Deckungsprüfung
Provisionsermittlung
Tarifierung
2
usw
.
logisches
Instanzenmodell
Bilddefinitionen
5
Tarifierungsmodelle
Die ns te
Fehlerbehandlung
Feldkonverter
Regelsystem
Präsentation
usw .
Abbildung 16: Zusammenspiel von VAA-Komponenten
Zwischen den einzelnen Komponenten bestehen folgende Schnittstellentypen:
(1) Steuerungskommunikation: Verbindung der zur Abwicklung eines Geschäftsprozesses
notwendigen Steuerungskomponenten
(2) operative Datenschnittstelle: Beschaffung der für den Geschäftsprozeß benötigten
Datenstrukturen.
(3) steuernde Datenschnittstelle: Beschaffung der für den Prozeß notwendigen Steuerungsdaten
und Parameter.
(4) Anwendungsbausteinschnittstelle: Aufruf der zur Abwicklung der fachlichen Inhalte
notwendigen Anwendungsbausteinfunktionen von jeder Steuerungskomponente.
(5) Diensteschnittstelle: Nutzung der allgemein verfügbaren technischen Dienste zur
Abwicklung des Geschäftsprozesses.
34
© GDV 1999
Technische Beschreibung der pVAA
Kommunikation und Schnittstellen
In der Dienstebene sind die Schnittstellentypen 2,3,5 erlaubt. Diese werden in der obigen Grafik nicht
dargestellt.
Jede Schnittstelle innerhalb der pVAA ist präzise zu spezifizieren.
III.1.3. Operative Datenschnittstelle
Die operative Datenschnittstelle ist von besonderer Bedeutung in der pVAA. Sie muß in der Lage sein,
vorhandene Datenstrukturen auf die Datenobjekte der VAA-Komponenten abzubilden. Aufgrund ihrer
hervorgehobenen Stellung wird diese Schnittstelle hier aus Sicht des Zusammenspiels der einzelnen
Komponenten detaillierter beleuchtet.
Die operative Datenschnittstelle versorgt die VAA-Komponenten mit den zu verarbeitenden Daten.
Grundsätzlich lassen sich zwei Arten von operativen Daten unterscheiden:


dauerhafte (persistente) Daten in externen Beständen, die die Ergebnisse der einzelnen
Geschäftsprozesse realisieren.
temporäre (transiente) Daten, die nur während der Abwicklung eines Prozesses notwendig sind.
Operative Daten werden von Komponenten der pVAA über den Datenmanager (siehe Seite 43.)
beschafft und als logische NF28-Datensichten in einem Vorgangsspeicher abgestellt.
III.1.3.1. Der Datenmanager aus Sicht eines AWB
Nur der Datenmanager kennt die dem Datenobjekt zugrundeliegenden physischen Strukturen und die
Transformationsregeln zur Bildung des (logischen) Datenobjekts. Er entkoppelt die VAAKomponenten von den physischen Details der Datenspeicherung. Er stellt den
Anwendungsbausteinfunktionen sogenannte komplexe Objekte (NF2-Objekte) zu Verfügung, die von
den einzelnen Anwendungsbausteinfunktionen verarbeitet werden.
Aus Sicht eines Anwendungsbausteins hat der Datenmanager erst einmal zwei grundsätzliche
Funktionen:


8
Bereitstellung von Datensichten (NF2) anhand der Informationen über das logische und physische
Datenmodell.
Abgleich der Datensicht mit dem physischen Speicher (schreiben und lesen).
Non First Normal Form: hierarchische Datensichten, die nicht mehr normalisiert sind.
© GDV 1999
35
Kommunikation und Schnittstellen
Technische Beschreibung der pVAA
Die folgende Abbildung zeigt beispielhaft den Aufbau eines komplexen Objekts:
Partner
Partner
Partner
Kommunikation
Partner
Partner
Bankverbindung
Bankdaten
Partner
Partner
Vertragsbündel
Partner
Partner
Einzelvertrag
Abbildung 17: Beispiel eines komplexen Objekts
Das Objekt in Abbildung 17 basiert auf dem logischen Datenmodell in Abbildung 18. Natürlich
handelt es sich hier um stark vereinfachte Beispiele, die nur die grundsätzliche Vorgehensweise
verdeutlichen wollen.
Kommunikationswege
Partner
1:n
n:m
Entity
Bankverbindung
Bankdaten
Vertragsbündel
Einzelvertrag
Abbildung 18: E/R-Modell, aus dem das komplexe Objekt gebildet wird
III.1.3.2. Prozeßdaten
Im Zuge der Bearbeitung eines Geschäftsprozesses sind eine Reihe von Daten zu speichern, die nicht
unmittelbar bestandswirksam werden sollen. Insbesondere die Abwicklung asynchroner Prozesse und
lange Transaktionen verlangen als Synchronisationsmechanismus einen Datenspeicher, der eben diese
temporären (transienten) Prozeßdaten aufnimmt. Dieser Datenspeicher wird Vorgangsspeicher
genannt. Zur Verwaltung des Vorgangsspeichers ist ein Dienst vorzusehen, die sogenannte
Vorgangsspeicherverwaltung. Die Datenbeschaffung (lesen und schreiben) der Komponenten der
pVAA erfolgt einheitlich über die Vorgangspeicherverwaltung. Dieser Dienst ist in der prozeduralen
VAA in der Dokumentation des Datenmanagers beschrieben.
36
© GDV 1999
Technische Beschreibung der pVAA
Kommunikation und Schnittstellen
III.1.3.3. Beispiel der operativen Datenbeschaffung
Die folgende Abbildung beschreibt die grundsätzliche Ablaufsteuerung der Datenbeschaffung aus
Sicht der Steuerungsebene:
DialogSteuerung
(Interaktion)
AWBFunktion
Dienste
Präsentationsdiienste
Dialogschritt 1
Workflow- DV-VorgangsSteuerung
Steuerung
(GePro)
(Teilprozeß)
Datenmanager
Vorg-spverrwal.
Vorg-spverrwal.
AWB-Fkt 1
AWB-Fkt 2
DV-Teilprozeß
Geschäftsprozeß
Vorg-spverrwal.
initialisieren
Datenmanager
Teilprozeß 2
Vorg-spverrwal.
Synchronisation
Abbildung 19: Beispiel einer Datenbeschaffung
In einem ersten Schritt werden die benötigten Datenstrukturen über die Vorgangsspeicherverwaltung
mittels des Datenmanagers initialisiert. Die folgenden Verarbeitungsschritte legen die modifizierten
Daten im Vorgangsspeicher ab. Am Ende des Teilprozesses 1 werden die Daten über die
Vorgangsspeicherverwaltung mittels des Datenmanagers mit den operativen Datenbeständen
abgeglichen.
© GDV 1999
37
Kommunikation und Schnittstellen
Technische Beschreibung der pVAA
III.2. Kommunikationsstruktur
Die Kommunikationsstruktur legt die Regeln des Kommunikationsflusses fest. Sie legt somit fest,
welche Funktion „wie mit wem“ reden darf. Sie beschreibt das Zusammenspiel der Komponenten und
die logische Entkopplung für verteilte Systeme.
RPC
APPC
APPC
MQI
...
MQI
Kommunikationskanal
...
VAA-Komponente
Interface
VAA-Komponente
RPC
Interface
Der Schnittstellenmechanismus in den einzelnen Komponenten der prozeduralen VAA entkoppelt die
Komponenten von der tatsächlichen Implementierung der Kommunikationsschnittstelle. Somit hat die
Komponente kein Wissen über die tatsächliche Art der Übertragungswege der in den Schnittstellen
übermittelten Informationen. Dies hat zur Folge, daß alle Teile einer Komponente auf einer Plattform
verfügbar sein müssen. Falls Komponenten auf verschiedenen Plattformen verfügbar sein sollen, ist
die ganze Komponente auf den geforderten Plattformen verfügbar zu machen.
Abbildung 20: Entkopplung der Kommunikationsmechanismen in der Schnittstelle
Die Verbindungen können sowohl asynchron wie auch synchron sein. Die Kommunikation setzt eine
standardisierte Funktionalität voraus, die die Verbindung zwischen verteilten Komponenten realisiert.
Dieser Dienst wird als Request Broker bezeichnet (siehe auch CORBA).
Rufer
Dienstaufruf
Dienstergebnis (-Leistung)
Dienstanfrage
Dienst
Dienstangebot
Dienstvermittler
Abbildung 21: Request Broker
Der Request Broker vermittelt einer Komponente eine transparenten Kommunikationskanal, über den
die Dienstleistung der aufgerufenen Komponente an den Aufrufer vermittelt wird.
Jede Kommunikation einer VAA-Komponente mit einer anderen VAA-Komponente muß über den
Request-Broker erfolgen, um eine individuelle Verteilung der einzelnen Komponenten zu
ermöglichen:
38
© GDV 1999
Technische Beschreibung der pVAA
Kommunikation und Schnittstellen
Parameterdienste
Workflowmanager
Datenmanager
Vorgangsspeicherverwaltung
Request Broker
DV-Vorgangsmanager
Dialogmanager
Sonstige
Basisdienste
(lokal oder verteilt)
Arbeitsstation
Anwendungsbausteinfunktion
Präsentations
-dienste
Drucker
Berechtigungsprüfung
Telefon
Datenmanager
Parameterdienste
physischer Datenzugriff
Datenverfügbarkeit
Datenaufbereitung
Selektion + Navigation
Workflowsteuerung
logische Datensicht
DV-Vorgangssteuerung
Kommunikation
und
Verteilung
Anwendungsbausteine-
Funktionsbausteine-
Buffermanagement
sonstige
Basisdienste
(lokal oder
verteilt)
Präsentationsmanager
Berechtigungsprüfung
API
API-Modul
Abbildung 22: Entwurf einer Kommunikationsstruktur der VAA
© GDV 1999
39
Kommunikation und Schnittstellen





Technische Beschreibung der pVAA
Die Verbindung aller Komponenten der VAA erfolgt immer über den Request-Broker
Die Verbindung innerhalb einer Komponente erfolgt mindestens über ein standardisiertes ModulInterface-Programm.
Komponenten benötigen Dienste zur Berechtigungsprüfung, Parameterdienste, Datendienste und
gegebenenfalls Präsentationsdienste, die über.den Request-Broker vermittelt werden.
Die Verteilung von Daten kann sowohl im Datenmanager wie auch im Kommunikations- und
Verteilungsbaustein realisiert sein.
Es sind sowohl synchrone wie auch asynchrone Verbindungen möglich.
III.2.1.1. Kommunikationsmatrix
Die Kommunikationsstruktur legt die prinzipiellen Charakteristika der Verbindung zwischen den
einzelnen VAA-Komponenten fest. Sie legt nicht fest, wer mit wem reden darf. Die erlaubten
Kommunikationswege werden deshalb in der folgenden Tabelle festgelegt.
Die Klassifikation der Schnittstellen kann im Rahmen der pVAA über die gewählte Schichtung
innerhalb der Architektur vorgenommen werden. Es entstehen somit Schnittstellen zwischen den
Schichten und ggf. innerhalb der jeweiligen Schicht.
Die Schnittstellen zwischen den Schichten werden nicht vollständig in der nachfolgenden
Schnittstellenmatrix aufgezeigt.
gerufen Workflow Vorgangs- Dialog-manager manager manager
Anwendungsbaustein
VAADienst
Datenmanager
Rufer
Workflow
-manager
-
ja
ja
ja
ja
ja
Vorgangsmanager
-
ja
(1)
ja
ja
ja
ja
Dialogmanager
-
-
ja
(2)
eingeschränkt
(3)
ja
eingeschränkt
(4)
-
-
-
ja
ja
VAADienst
-
-
ja
(6)
-
ja
(7)
eingeschränkt
(8)
Datenmanager
-
-
-
-
ja
-
Anwendungsbaustein
40
ja
(5)
© GDV 1999
Technische Beschreibung der pVAA
Kommunikation und Schnittstellen
An der Matrix erkennt man deutlich die „sogenannte“ Steuerungshierarchie, über die die Software im
„Steuerungsteil“ strikt strukturiert ist.
Erläuterungen zu einzelnen Schnittstellen:
(1)
Vorgangsmanager  Vorgangsmanager
Über diese Schnittstelle wird die Rekursivität des „Teilprozesses“ im fachlichen Modell realisiert. Bei
dieser Schnittstelle ist besonderen Wert auf das Verhalten des Vorgangsgedächtnisses zu legen.
(2)
Dialogmanager  Dialogmanager
Für diese Schnittstelle gilt analog das unter (1) Gesagte nur für die Objekte „Dialog“ bzw.
„Teildialog“.
(3)
Dialogmanager  Anwendungsbaustein
Im Sinne einer strikten Steuerungshierarchie müßte diese Schnittstelle eigentlich verboten sein, da
beide Steuerungskomponenten den selben fachlichen Baustein „Elementarprozeß“ realisieren. Da
innerhalb eines Dialoges jedoch Ein-/Ausgabedaten häufig auf Plausibilität zu prüfen sind, würde sich
durch diese Restriktion der sogenannte „Fahrstuhleffekt“ einstellen. Aus diesem Grund ist eine
eingeschränkte Schnittstelle erlaubt, d. h. der Dialogmanager darf ausschließlich zu Prüfzwecken
entsprechende Anwendungsbausteine aufrufen, die ihrerseits während der Ausführung den „Kontext“
der Steuerung (insbesondere Vorgangsgedächtnis) nicht ändern dürfen.
(4)
Dialogmanager  Datenmanager
Die Schnittstellen des Dialogmanagers zum Datenmanager darf ausschließlich für den Vorgang des
sogenannten „Nachlesens“ genutzt werden, d. h. wenn aus technischen Gründen die Menge der zu
präsentierenden Daten in „physische Portionen“ eingeteilt werden muß. Ein typisches Beispiel für
diese Situation ist die Präsentation einer Tabelle in Listform mit entsprechenden scrollingMöglichkeiten.
(5)
Anwendungsbaustein  Anwendungsbaustein
Der Aufruf von Anwendungsbausteinen untereinander ist prinzipiell nicht erlaubt. Verboten ist auch
der rekursive Aufruf eines Anwendungsbausteins durch sich selbst. Es bleibt an dieser Stelle
anzumerken, daß jeweils nur die nach außen exportierten Funktionen eines Anwendungsbausteins als
Schnittstelle zu benutzen sind.
(6)
VAA-Dienst  Dialogmanager
Diese Schnittstelle ist nur für solche VAA-Dienste zulässig, die über eine eigene Benutzeroberfläche
verfügen, z. B. Hilfe-System, Prompt-System.
(7)
VAA-Dienst  VAA-Dienst
Aufgrund ihrer ausgezeichneten Stellung der Dienste in der VAA sind hier jegliche Schnittstellen auch rekursiv - zulässig. In Bezug auf die Performance sollte jedoch auf die Aufruftiefe strikt geachtet
werden.
(8)
VAA-Dienst  Datenmanager
Daten, die durch den Datenmanager einem VAA-Dienst zur Verfügung gestellt werden, dürfen nur
„lokal“, d. h. innerhalb dieses Dienstes benutzt werden.
© GDV 1999
41
Anhang
Technische Beschreibung der pVAA
IV. Anhang
Der Anhang umfaßt eine Liste der zur Zeit vorliegenden Dienste. Die Liste ist noch nicht vollständig.
Dies ist der weiteren Arbeit vorbehalten. Ziel ist eine vollständige Liste aller benötigten Dienste und
ihrer Verwendung zu erarbeiten.
Die bisher beschriebenen Dienste sind in drei Abschnitte aufgeteilt:
1. Beschreibung der Dienste, die in Projekten detaillierter spezifiziert worden sind. Hier wird nur
eine Kurzfassung der Projektergebnisse dargestellt.
2. Beschreibung der in der Architektur erwähnten Kommunikationsdienste.
3. Exemplarische Aufzählung möglicher sonstiger Dienste.
42
© GDV 1999
Technische Beschreibung der pVAA
Anhang
IV.1. Zusammenfassung spezifizierter Dienste
IV.1.1. Datenmanager
Der Datenmanager bildet die Schnittstelle zwischen den Anwendungen und den extern gespeicherten
Daten. Er stellt den Anwendungen eine abstrakte Datenschnittstelle zur Verfügung, so daß sie
vollkommen befreit sind von dem Schema der darunterliegenden Datenbanken und deren
Zugriffslogik. Er beschafft die angeforderten Daten von externen Speichern, baut den
Vorgangsspeicher auf, kontrolliert seine Inhalte, schreibt die Daten im Vorgangsspeicher und auf den
Datenbanken fort. Er macht die Anwendungen unabhängig von der physischen Speicherungsform, von
den Zugriffsarten und dem eingesetzten Datenbankmanagementsystem (DBMS). Die Anwendungen
arbeiten ausschließlich mit dem logischen Datenmodell, das der Datenmanager kennt und verwaltet.
IV.1.1.1. Grundprinzipien des Datenmanagers




Der
Datenmanager
ist
die
zentrale
Datenschnittstelle für alle Anwendungen, d.h.
sämtliche Datenzugriffe (Lesen und Schreiben)
werden über den Datenmanager abgewickelt.
Die Zugriffe auf die Daten erfolgen auf der Basis
eines logischen E/R-Modells über Datensichten.
Diese
werden
im
Laufe
der
Anwendungsentwicklung definiert. Grundsatz
ist, daß jeder Anwendungsbaustein nur die Daten
zur Verfügung gestellt bekommt, die er auch
wirklich benötigt, um sie auszuwerten oder zu
ändern. Der Datenmanager trennt den
physischen Zugriff auf die Daten von der
Anforderung durch die Anwendungsbausteine,
d.h. für die Anwendung ist die konkrete
physische Ablage der Daten nicht relevant,
insofern hat auch eine Änderung der
Datenspeicherung (z.B. durch Migration von
VSAM nach DB2) keine Auswirkungen auf die
Anwendung.
Anwendung
Datensichten sind komplex
aufgebaute Datenstrukturen in Form
von Jackson-Bäumen
Logische E/R-Modelle sind
die Basis der Verarbeitung
Entkopplungsschicht (Middleware)
DBMS:
 relational
 hierarchisch
 sonstige
Die Anforderung der Daten erfolgt jeweils
zeitpunktbezogen, d.h. die Anwendung fordert
die zu einem bestimmten Zeitpunkt gültigen
Abbildung 23: Basis eines Datenmanagers
Daten an, und der Datenmanager sorgt dafür, daß
die richtigen Daten zur Verfügung gestellt
werden. Dabei ist es für die Anwendung nicht
von Bedeutung, ob es eine physische Trennung
von Historie- und aktuellen Daten gibt oder nicht. Außerdem ist es möglich, die Daten anzufordern,
die zu einem bestimmten Zeitpunkt dem System bekannt waren. Dies ist insbesondere für
Berichtigungen und Rückrechnungen interessant.
Pufferung der logischen Änderungen bis zum Erreichen von Konsistenzpunkten. Jeder Arbeitsgang
wird für sich modelliert, unabhängig von dem Kontext, in dem er läuft. In der Praxis kann aber der
© GDV 1999
43
Anhang
Technische Beschreibung der pVAA
gleiche Arbeitsgang entweder allein, aber auch im Rahmen von rückwirkenden Änderungen und in
Verbindung mit anderen, evtl. andere Systeme betreffenden Arbeitsgängen laufen. Die
Anforderung lautet dann häufig, daß mehrere zusammen ablaufende Arbeitsgänge nur zusammen
wirksam werden oder gar nicht.

Beispiel: Beim Neugeschäft wird zum einen der Arbeitsgang "Kunde erfassen" durchgeführt, zum
anderen der Arbeitsgang "Vertragsdaten erfassen". Dabei kann es vorkommen, daß die Erfassung
des Kunden korrekt abläuft, der Vertrag aber im beantragten Umfang nicht angenommen wird. Die
Anforderung kann dann lauten, daß auch die Anschrift des Kunden erst dann wirksam wird, wenn
der Vertrag von uns angenommen wird. Die Daten der Anschrift müssen also solange
zwischengepuffert werden, bis auch der Arbeitsgang "Vertragsdaten erfassen" korrekt beendet
wurde. Gleichwohl müssen sie diesem Arbeitsgang bekannt gemacht werden, wenn er sie benötigt.

Diese Aufgabe erledigt der Datenmanager. Er kennzeichnet die Daten als vorläufig und stellt sie
nur dem Geschäftsprozeß zur Verfügung, der diese Daten erzeugt hat, bis von der GeschäftsprozeßSteuerung das Kommando zum endgültig Abspeichern kommt. Dann werden die Daten allen
anderen Geschäftsprozessen bekannt und allgemein gültig gemacht.

Zwischenspeicherung von temporären Daten. Die Architekturprinzipien ‘Bausteinbildung’ und
‘Geschäftsprozeßorientierung’ machen es notwendig, Daten vorübergehend in einen Speicher
einzustellen und sie zu einem späteren Zeitpunkt wieder zu lesen. Dafür stellt der Datenmanager
eine Schnittstelle zur Verfügung.
Folgende wesentlichen Funktionen führt der Datenmanager durch:







44
Auswahl der logischen Datensichten: Die zutreffenden Datensichten werden aufgrund der
Anforderung der Anwendung ermittelt. Entweder teilt die Anwendung selbst die erforderlichen
Datensichten mit, oder der Datenmanager ermittelt aufgrund des rufenden Anwendungsmoduls die
Datensichten. Die entsprechenden Informationen müssen im Parametersystem zur Verfügung
stehen.
Selektion der benötigten Daten: Aufgrund der angeforderten Datensicht und der Beschreibung ihres
Aufbaus wählt der Datenmanager die entsprechenden physischen Daten aus und ermittelt, wo sie
physisch gespeichert sind.
Physischer Zugriff: Anschließend erfolgt der physische Zugriff auf die Daten in den ermittelten
Datenbanken und Dateien. Auftretende Fehler werden entweder ausgewertet oder, wenn dies nicht
möglich ist, an die Anwendung zurückgemeldet.
Aufbereitung der Daten: Die gelesenen Daten werden in die von der Anwendung geforderte Form
gebracht, d.h. es erfolgt die eigentliche Erstellung der logischen Datensicht, welche an die
Anwendung übergeben wird.
Übergabe der Daten an die Anwendung: Die logische Datensicht wird an die Anwendung
übergeben.
Lokale Änderung von Vorgangsdaten: Innerhalb eines Vorgangs sind alle Datenänderungen nur
dem Vorgang selbst bekannt, sie müssen daher lokal gespeichert werden und dürfen noch nicht
allgemein bekannt gemacht werden. Der Datenmanager stellt dazu einen sogenannten
Vorgangsspeicher bereit, in dem alle vorgangsbezogenen Daten abgelegt werden.
Änderungen auf den physischen Datenbeständen: Beim Vorgangsende erhält der Datenmanager
von der Anwendung den Auftrag zum Ändern der operationalen Datenbestände. Er führt dann die
erforderlichen Änderungs-, Einfüge- und Löschoperationen auf den physischen Datenbeständen
durch und gibt eine Statusmeldung an die auslösende Anwendung zurück.
© GDV 1999
Technische Beschreibung der pVAA
Anhang
IV.1.1.2. Interface zum Datenmanager
Das Interface zum Datenmanager stellt in Bezug auf seine technische Realisierung eine besondere
Herausforderung dar. Wegen der Häufigkeit ihrer Nutzung ist die Performance dieser Schnittstelle von
entscheidender Bedeutung.
Datenmanager
Anwendungsbaustein mit
Lese- oder
UpdateAnforderung
Datensichtprozessor
Logisches
Datenmodell
Datenhandler
Physische
Datenbank
Physische
Datenbank
Abbildung 24: Interface zum Datenmanager
Datenanforderungen eines Anwendungsbausteins erfolgen durch Datensichten auf der Basis des
logischen Datenmodells. Der Datensichtprozessor übersetzt diese Anforderung in Aufträge zur
Beschaffung oder Änderung der zugehörigen Entitäten an den Datenhandler. Dieser führt die Zugriffe
auf die externen Datenbanken durch und übergibt (bei Leseanforderungen) die Daten - wiederum in
der Form logischer Entitäten - an den Datensichtprozessor. Der Datensichtprozessor baut die
Anwendungsschnittstelle entsprechend der in der Datensicht definierten Struktur und Reihenfolge auf
und liefert sie so der aufrufenden Anwendung.
© GDV 1999
45
Anhang
Technische Beschreibung der pVAA
IV.1.2. Parametersystem
Parameter enthalten zum einen Steuerungsinformationen, die den Ablauf von Programmen und
Systemen beeinflussen. Zum anderen sind es wiederverwendbare, deskriptive Informationen, die aus
den operativen Systemen ausgelagert wurden (z. B. Textkonserven, Tarife, Maskendefinitionen).
Das Parametersystem stellt Funktionen zur Verwendung, zur Pflege und zur Verwaltung von
Parametern zur Verfügung.
IV.1.2.1. Funktionalität des Parametersystems

Erstellung, Verwaltung, Verteilung und Aktivierung von Parametern

Editieren und Generieren

Führung der Versionen

Archivierung

Entwicklungspfade, .stufen und Freigabeverfahren

Berechtigungsverwaltung

Bereitstellung von Parametern zur Ausführungszeit

standardisierte Zugriffsverfahren

optimierte Speicherverwaltung

Aktivierung von neuen Versionsständen zur Laufzeit

dezentraler Zugriff

Darstellung und Nutzung von Referenzen/Querverbindungen zwischen Parametern

Zugriff auf Teilinformationen (Tabellenzeilen usw.)

Verwendungsstatistiken

Testunterstützung
Neben der Bereitstellung von Parametern zur Laufzeit werden auch zusätzliche Funktionen zur
Entwicklungszeit häufig benötigt:

Bausteingeneratoren
Die Bausteingeneratoren erzeugen Runtime-Versionen von Softwarebausteinen für
unterschiedliche Systemplattformen.

Bausteineditoren
Sie werden für die Entwicklung der Softwarebausteine und der Konfigurationsdaten
benötigt, beispielsweise für die Beschreibung des Datenmodells, die Definition von
Datensichten, das Design von Geschäftsprozessen im Workflow-Manager oder die
Definition von Bildschirmmasken.
IV.1.2.2. Interface zum Parametersystem
Das Interface zum Parametersystem hat eine ähnlich zentrale Stellung in der VAA-Architektur, wie
der Datensichtprozessor, da es von sehr vielen Funktionsmodulen zur Beschaffung von Parametern
benutzt wird.
46
© GDV 1999
Technische Beschreibung der pVAA
Anhang
Parameter gewinnen in Softwarearchitekturen zunehmend an Bedeutung, da mit ihrer Hilfe
Forderungen nach Flexibilität, Wartbarkeit, Wiederverwendbarkeit erfüllt werden können. Das
Parameter-/Regelsystem und sein Interface müssen dann aber auch hohen Performanceanforderungen
genügen.
Bei der Implementierung des Parametersystems muß nichtsdestoweniger auf die
Hardwareunabhängigkeit geachtet werden, d.h. Hardware-Spezifika sind - soweit aus
Performancegesichtspunkten vertretbar - durch entsprechende Dienste der Entkopplungsschicht zu
kapseln.
© GDV 1999
47
Anhang
Technische Beschreibung der pVAA
IV.1.3. Dialogmanager
Der Dialogmanager ist also ein Softwarebaustein, der - ähnlich wie ein VAA-Dienst - zentral die
Funktionalität der Dialogsteuerung sämtlichen anderen VAA-Komponenten zur Verfügung stellt.
Gemäß den Anforderungen an eine Dialogsteuerung sind im Dialogmanager folgende 4
Teilkomponenten angesiedelt:

das Dialogsystem als zentrales Steuerungs- und Kontrollmodul

das Präsentationssystem als eigenständiger Präsentations- und Darstellungsdienst

das Schnittstellensystem zu den nutzenden VAA-Komponenten und

das Entwicklungssystem, als Entwicklungswerkzeug für Dialoge und Dialogsteuerungen für den
Anwendungsentwickler
Anwendung
Schnittstellensystem
Entwicklungssystem
Dialogsystem
Präsentationssystem
Abbildung 25: Bestandteile eines Dialogmanagers
Neben der Abdeckung der Funktionalität durch den Dialogmanager verbleiben im Rahmen der VAA
noch eine Reihe von Aufgaben zu behandeln, die aus Sicht des Endbenutzers für ein Gesamtsystem
unerläßlich sind. Es handelt sich hierbei um Anforderungen an die Standardisierung und
Gleichförmigkeit der Benutzeroberfläche und der Dialogsteuerung.
Aufgabe einer Weiterentwicklung der VAA in den nächsten Jahren im Bereich Dialoge wird es sein,
Standards für

Benutzeroberflächen

Dialogführungen

Dialogmodelle
in umfangreicher Ausprägung zu Verfügung zu stellen.
48
© GDV 1999
Technische Beschreibung der pVAA
Anhang
IV.2. Kommunikationsdienste
IV.2.1. Request Broker
Aufgabe und Ziel des Request-Broker ist es, die einzelnen VAA-Komponenten zu verbinden und
voneinander zu entkoppeln. Er stellt einem Diensteanforderer einen transparenten
Kommunikationskanal mit einem Diensterbringer zu Verfügung. Einzig und allein der Request-Broker
kennt die Lokation und Aufrufmodalitäten der einzelnen VAA-Komponenten. Er erfüllt die zentralen
Aufgaben:

Transformation (Übersetzung) etwaiger Übergabeparameter

Überprüfung und Kontrolle des gerufenen Kommunikationspartners

Fehlerhandling

Testoptionen und Testunterstützung
Sämtliche übrigen Informationen, wie z. B. Ort des Gerufenen, Sprache, Kommunikationsart, aber
auch Tätigkeiten, wie Spachübersetzung, Kommunikationskontrolle, Abbruch im Fehlerfall führt der
Request-Broker durch. Durch dieses Kommunikationsprinzip ist in Verbindung mit einem
standardisierten Kommunikationsinterface ein Höchstmaß an Flexibilität, Unabhängigkeit und
Erweiterbarkeit des Kommunikationsprozesses erreichbar.
IV.2.2. Modul-Interface-Programm
Die Modularisierung ist ein wesentliches Konstruktionsprinzip innerhalb der VAA. Insbesondere
innerhalb einer VAA-Komponente kann mit ihr eine effiziente und wiederverwendbare Strukturierung
erreicht werden. Da ein Anwendungssystem aufgrund dieses Ansatzes in viele hundert bzw. tausend
Module zerfällt, hat die „Modulverbindung“ eine wichtige Rolle.
Folgende Ziele müssen erreicht werden:

Höchste Effizienz

Unabhängigkeit von der Programmiersprache

Unabhängigkeit von der Darstellung der Parameterinhalte

Unabhängigkeit von Anzahl und Reihenfolge der Parameter

Automatische „Konfiguration“ über Compiler-Schnittstelle, u. a. m.
Verwirklicht wird dieser Ansatz durch das Modul-Interface-Programm. Es kennt beide
Modulschnittstellen und bildet das Bindeglied zwischen ihnen innerhalb einer VAA-Komponente.
© GDV 1999
49
Anhang
Technische Beschreibung der pVAA
Modul
A
Modul
B
MIP
Modul
Interface
Description
Abbildung 26: Modul-Interface-Programm (MIP)
Die Kommunikationsart dieses Dienstes sollte ein synchroner oder asynchroner Prozeduraufruf sein,
der sowohl „lokal“ als auch „entfernt“ ausführbar ist.
Neben der Aufgabe der „Schnittstellenübersetzung“ sollte das MIP eine Reihe von Optionen besitzen,
wie

Testoption TRACE

Testoption für fehlendes „gerufenes Modul“

Zentrales Return-Code-Handling usw.
IV.2.3. Kommunikationsinterface
Das Kommunikationsinterface entkoppelt die VAA-Komponenten von den Details der verwendeten
Kommunikationsverbindungen. Er muß z.B. die folgenden Kommunikationsarten unterstützen:

synchron mit entsprechender beidseitiger Kontrolle (z. B. APPC),

asynchron mit hierarchischer Kontrolle (RPC) und

asynchron ohne gegenseitige Kontrolle (Message Handling)
Analog zum Modul-Interface-Programm sollte auch das Kommunikationsinterface eine Reihe von
Testhilfen, Monitoring-Funktionen und sonstigen Hilfsfunktionen zur Verfügung stellen.
50
© GDV 1999
Technische Beschreibung der pVAA
Anhang
IV.3. Beispiele für weitere Dienste
IV.3.1. Archivierungsdienste
Die Archivierung ist ein zentraler Dienst zur Ablage und Verwaltung des gesamten Schriftgutes und
sonstiger aufbewahrungspflichtiger Informationen eines VU (elektronische Akte).
Dies sind im wesentlichen: Eingangs- und Ausgangspost, Nachweise manueller und maschineller
Bearbeitungsvorgänge, Notizen und Anmerkungen der Sachbearbeiter zu Vorgängen.
IV.3.2. Druck-Manager
Ein zentraler Druckmanager unterstützt sämtliche Druckausgaben, die im Rahmen des operativen
Geschäfts benötigt werden. Er erstellt aus logisch definierten Ausgabeformaten, Textbausteinen und
variablen Daten Bildschirmanzeigen und Druckbilder auf Listen. Er ermöglicht unternehmensweites
Drucken und vorgangsbezogene automatisierte Korrespondenz. Die Definition der Berichtsformate
und der Ausgabesteuerung auf Druckern und Poststraßen erfolgt über Dialog. Die Druckausgaben
können am Bildschirm angezeigt werden.
IV.3.3. Feldkonverter
Der Feldkonverter führt formale Transformationen und Prüfungen von Feldinhalten gemäß ihrem
Datentyp durch, und er interpretiert den Inhalt von Steuerungsfeldern (wie Befehle, Parameter und
Ordnungsbegriffe).
IV.3.4. Handbuch-Verwaltung
Informationssystem für umfangreiche Dokumentationen wie Rundschreiben, Arbeitsanweisungen,
Tutorial, Glossar oder Verkaufsinformationen, einschließlich Texterfassung und -pflege.
IV.3.5. Hilfe-System
Das Hilfe-System ist ein kontextsensitives System zur Anzeige und Erstellung von Hilfetexten. Die
Anzeige erfolgt in Abhängigkeit des Kontextes je nach Objekt-Typ, z. B. Hilfe für Felder, Hilfe für
Bilder, Hilfe für Fehlersituationen.
IV.3.6. Mail-System
Das Mail-System dient dem Austausch von Nachrichten zwischen den Benutzern des Systems,



zwischen Sachbearbeitern,
zwischen Programmen und Sachbearbeitern (z. B. Fehlermeldung zur Bearbeitung an den
Sachbearbeiter)
oder auch zwischen Programmen bzw. Anwendungssystemen (z. B. Meldung vom Bestandssystem
an das Zentralinkasso, daß aufgrund eines bestimmten Änderungsvorgangs ein Inkassostop zu
setzen ist).
© GDV 1999
51
Anhang
Technische Beschreibung der pVAA
Das Mail-System muß in die Vorgangsbearbeitung integriert werden können, so daß der
Sachbearbeiter jederzeit Nachrichten senden und empfangene Nachrichten anschauen und bearbeiten
kann, ohne von einem System ins andere wechseln zu müssen.
IV.3.7. Präsentation
Die Präsentationsdienste haben die Aufgabe, die Funktionalität der gewählten Oberfläche zu
realisieren. Dies umfaßt z.B. die üblichen Fensteroperationen in grafischen Oberflächen wie

Fenster vergrößern und verkleinern

Fenster aktivieren und deaktivieren

Darstellung von Kontrollelementen wie Schieberegler, Listboxen, etc.
Neben den üblichen grafischen Oberflächen wie den Presentation Manager für OS/2 oder der
Benutzeroberfläche der Windows-Familie müssen die Präsentationsdienste auch zeichenorientierte
3270-Dialoge unterstützen.
IV.3.8. Prompt-System
Das Prompt-System unterstützt den Endbenutzer bei der Erfassung strukturierter, inhaltsbezogener
Datenelemente durch die Anzeige von Auswahllisten, aus denen er ein zutreffendes Eingabedatum
selektieren und in das aktive Eingabefeld übertragen kann, z.B. Wagniskennziffern, Typenklassen,
Bankleitzahlen.
IV.3.9. Prüfsystem
Das Prüfsystem benutzt die Daten des Parameter- und Regelsystems zur Durchführung aller Prüfungen
in den Anwendungen. Die Regeln gehen als Parameter oder als generierter Code direkt in die Anwendungen ein. Das Prüfsystem kann um KI-Komponenten ergänzt werden.
IV.3.10. Problembehandlung
Die Problembehandlung analysiert Ausnahmesituationen und leitet Maßnahmen ein zur Klärung und
Behebung des Problems, z. B. durch das Senden einer Nachricht an den Benutzer, das Protokollieren
einer Fehlersituation im Problemmanagementsystem oder die Bereinigung undefinierter Situationen.
IV.3.11. Referenz-Verwaltungssystem
Das Referenz-Verwaltungssystem dient dem Aufbau flexibler und mehrfacher Ablageordnungen in
hierarchischer Form und unterstützt u.a. alternative Zugriffe auf die Geschäftsprozeßdokumentation.
Bei dieser virtuellen Sicht auf Daten, Schriftgut etc. wird das physische Dokument nicht redundant
gespeichert. Beispiele solcher virtueller Akten sind: Kundenakte, Vertragsakte, Geschäftsprozeßakte,
Schadenakte.
IV.3.12. Schnittstellenkonverter für Alt- und Fremdsysteme
Bei Entwicklung/Einführung von neuen Systemen ist in den meisten Fällen eine Einbindung von
Fremdsystemen erforderlich. Dies betrifft insbesondere die Teile Datenzugriff und Dialog.
52
© GDV 1999
Technische Beschreibung der pVAA
Anhang
Folgende Schnittstellen muß ein entsprechender Schnittstellenkonverter bereitstellen:








Zugriff auf Daten von Fremdsystemen
Dafür wird eine Schnittstelle bereitgestellt, die die Daten des Fremdsystems liest, aufbereitet und
der VAA-Anwendung so zur Verfügung stellt, als ob es ihre Daten wären.
Zugriff auf Daten der VAA-Anwendung aus Fremdsystemen
Soll die Anwendung eines Fremdsystems auf Daten einer VAA-Anwendung zugreifen, benutzen
beide den Datenmanager als Schnittstelle. Die entsprechenden Systemvoraussetzungen müssen
geschaffen werden.
Aufruf eines Dialogs in Fremdsystemen aus einer VAA-Anwendung heraus
Da nicht sämtliche Anwendungen eines Unternehmens zu einem Zeitpunkt umgestellt werden
können, müssen auch Dialoge aus Fremdsystemen in Vorgänge eines VAA-Systems eingebunden
werden können. Diese müssen genau wie Dialoge der VAA-Anwendung behandelt werden. Die
entsprechende Schnittstelle muß der Schnittstellenkonverter zur Verfügung stellen.
Aufruf eines VAA-Dialogs aus einem Fremdsystem heraus
Auch Benutzer, die überwiegend im Altsystem arbeiten, müssen die Möglichkeit haben, einen
Dialog einer VAA-Anwendung aufzurufen. Eine entsprechende Schnittstelle muß vom
Schnittstellenkonverter bereitgestellt werden.
Der Schnittstellenkonverter kommuniziert bei diesen Aufgaben mit den VAA-Komponenten
Datenmanager und DV-Vorgangssteuerung.
IV.3.13. Schriftguterstellung (Textverarbeitung)
Die Schriftguterstellung ist ein zentraler Dienst zur Erstellung sämtlicher Schriftgutarten für
Ausgangspost. Schriftgutarten sind Briefe, Policen etc.
IV.3.14. Sprachenumsetzung
Mehrsprachigkeit ist die Fähigkeit, Bildschirmanzeigen, Druck-Output und System-/Anwendungsmeldungen in verschiedenen Sprachen auszugeben. Durch Parametereingabe muß der
Benutzer je Vorgang die gewünschte Sprache auswählen können. Das bedeutet für die Anwendungen,
daß alle Textbausteine, Bildschirmfeld-Bezeichnungen, Listenüberschriften, Texte etc. in den
verschiedenen Sprachen parallel gehalten werden.
IV.3.15. Termin-/Wiedervorlage-System
Zentraler Dienst zur Verwaltung von Terminen auf Objektebene (User, Räume, Ressourcen). Das
System sollte über zentrale Benutzerschnittstellen (API) zugänglich sein für sämtliche Dienstes und
Anwendungen.
IV.3.16. Vollmachten- und Berechtigungssystem
Zentrales Verwaltungssystem sämtlicher Vollmachten und Berechtigungen auf der Anwendungsebene.
Aufgabe ist der Schutz von Anwendungen bzw. Anwendungsteilen gegen Mißbrauch.
Anwendungsteile können sein: Geschäftsprozesse, Funktionen, Daten, Tabellen.
© GDV 1999
53
Anhang
Technische Beschreibung der pVAA
Sämtliche Berechtigungen, Vollmachten und sachbearbeiterbezogene Informationen werden über das
VB-System eingegeben und gepflegt. Systeme, die eigene Berechtigungsprüfungen durchführen, wie
z. B. RACF, ASF oder MEMO werden vom VB-System beliefert.
IV.3.17. Vorgangsspeicherverwaltung
Dieser Dienst verwaltet die zur Abwicklung eines Geschäftsprozesses notwendigen temporären
(transienten) Daten. Über diesen Dienst können VAA-Komponenten ihre Prozeßdaten auch über
Sitzungsgrenzen hinweg ablegen. Operative Daten werden über den Datenmanager, der von der
Vorgangsspeicherverwaltung angestoßen wird, den einzelnen VAA-Komponenten zu Verfügung
gestellt.
IV.3.18. Währungsumrechnung
DM-Beträge müssen sich auch in andere Währungen umrechnen und in ihnen ausgeben lassen. Man
benötigt dafür Währungskurse, Umrechnungsfunktionen und entsprechend Platz bei der Ausgabe. Je
nach den Benutzererfordernissen muß auch die Speicherung der Werte in mehreren Währungen
vorgesehen werden, z. B. für die Buchhaltung in Fremdwährungen.
IV.3.19. Zeitrechnung
Die Zeitrechnung ermittelt Differenzen zwischen Zeitpunkten (Datum, Uhrzeit) und errechnet neue
Zeitpunkte (Zeitpunkt + oder - eine Anzahl von Zeiteinheiten (Jahre, Monate, Tage, Stunden, Minuten,
Sekunden). Sie kann Datum und Uhrzeit in allen bekannten Formaten darstellen und damit umgehen.
54
© GDV 1999
Technische Beschreibung der pVAA
Anhang
IV.4. Literaturverzeichnis
BUES, M.: Offene Systeme. Strategien, Konzepte und Techniken für das Informationsmanagement,
Springer-Verlag Berlin, 1994
DIX, ALAN; FINLAY, JANET; ABOWD, GREGORY; BEALE, RUSSEL: Mensch Maschine
Methodik, Prentice Hall, 1995
DORN, Bernhard (Hrsg): Unternehmensprinzip Offenheit, Grundlagen für offene Organisationen und
Kooperationen, Addison-Wesley, 1993
FARNY, Dieter: Versicherungsbetriebslehre, Karlsruhe: Verlag Versicherungswirtschaft, 1989
GRAY, J.N.: The Transaction Concept: Virtues and Limitations. Proc. 7th International Conference on
VLDB, Cannes, 1981, pp. 144-154.
GRAY, J., REUTER, A.: Transaction Processing: Concepts and Techniques.
Publishers, San Francisco, 1993
Morgan
Kaufmann
HÄRDER, T.; REUTER, A.: Principles of Transaction-Oriented Database Recovery. ACM
Computing Surveys, Vol. 15, No.4, Dec. 1983, pp. 287-317.
HEINRICH, Wilfried (Hrsg): Client-Server-Strategien, Upsizing - Downsizing - Rightsizing, Datacom
Fachbuchreihe, Datacom-Buchverlag, 1993
IBM: IBM Open Blueprint, Bauplan für offene Client/Server Lösungen. Eine Einführung, IBM 1994
KARER, Albert u. Müller, Bernd: Client/Server Technologie in der Unternehmenspraxis, SpringerVerlag Berlin, 1994
KOCH, Peter/Weiss, Wieland: Gabler-Versicherungslexikon, Wiesbaden, Gabler 1994
LOCKEMANN, P. C.; SCHMIDT, J. W.: Datenbankhandbuch. Springer Verlag, 1987
NAGL, Manfred: Softwaretechnik: Methodisches Programmieren im Großen, Springer Compass,
Springer Verlag Berlin, 1990
SCHMIDT, Reimer: Versicherungsalphabet, Begriffserläuterungen aus Praxis und Theorie der
Individualversicherung. Karlsruhe: Verlag Versicherungswirtschaft, 1982, 6. Auflage
STEINBOCK, Hans-Joachim: Potentiale der Informationstechnik. B.G. Teubner Verlag, Stuttgart,
1994
© GDV 1999
55