Final Edition. Das Objektorientierte Fachliche Referenzmodell. Version 2.0

July 10, 2019 | Author: Alexandra Simen | Category: N/A
Share Embed Donate


Short Description

1 Final Edition Das Objektorientierte Fachliche Referenzmodell Version 2.02 Autoren: Das Projektteam "OO fachliches...

Description

Final Edition Das Objektorientierte Fachliche Referenzmodell Version 2.0

Autoren:

Das Projektteam "OO fachliches Referenzmodell"

Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.V., Berlin

http://www.gdv.de/vaa

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Willkommen bei VAA Final Edition! Liebe Leserin, lieber Leser, haben Sie bereits eine der Broschüren der VAA Final Edition gelesen? Dann können Sie gleich weiter blättern, denn dieses Kapitel steht gleichlautend am Anfang jedes Dokuments dieser VAA-Edition. Wir freuen uns über Ihr Interesse an der Versicherungs-Anwendungs-Architektur und gratulieren Ihnen zu Ihrer Entscheidung, sich mit diesem Thema zu beschäftigen. Daran haben wir seit Jahren mit Engagement und Spaß gearbeitet, was in der Qualität der Ergebnisse seinen Niederschlag findet, wie wir glauben. 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 auf der VAA-CD und im Internet (Adresse http://www.gdv.de/vaa) nachlesen. Nun zur Sache: Wir können die erfreuliche Mitteilung machen, daß die VAA-Initiative erfolgreich zum Abschluß gekommen ist. Nachdem wir in einer ersten Arbeitsphase von ca. 1994 bis 1997 die sog. prozedurale Architektur (pVAA) konzipiert und beschrieben haben, entwickelten wir im Anschluß daran im Zeitraum von 1997 bis 2000 die objektorientierte Architektur (oVAA) als fachliches und technisches Referenzmodell und darauf aufbauend das VAA-Komponentenmodell. Alle Arbeitsergebnisse wurden abschließend dokumentiert. Dabei entstand eine Reihe von zum Teil sehr umfangreichen Dokumenten, die auf drei Wegen veröffentlicht werden: • CD-ROM, • Internet • und zum Teil als gebundene Broschüren in Papierform. Um Ihnen die Orientierung zu erleichtern, haben wir als Übersicht über die verfügbaren Dokumentationen der VAA Final Edition einen grafischen Wegweiser erstellt, den Sie auf der nächsten Seite finden können. Möglicherweise kann er Ihnen dabei behilflich sein, Ihre Sie interessierenden Schwerpunktthemen schnell zu finden. Viel Spaß beim Studium der VAA-Unterlagen.

© GDV 2001

http://www.gdv.de/vaa

Das Objektorientierte Fachliche Referenzmodell

Dokumentenstruktur der VAA Final Edition Management Summary

neu

Anforderungen und Prinzipien

überarbeitet

Glossar VAA prozedural (pVAA) Version 2.1 Prozeduraler Rahmen

überarbeitet

Technische Beschreibung Datenmanager Datenmanager Historienführung und Anhang Dialogmanager Parametersystem Workflow-/Vorgangsmanager Fachliche Beschreibung Inkasso/Kontokorrent Partner Partner/Anhang Produkt Provision Schaden/Leistung Vertrag VAA objektorientiert (oVAA) Version 2.0 Das Objektorientierte Technische Referenzmodell

überarbeitet

Das Objektorientierte Fachliche Referenzmodell

überarbeitet

Fachliche Modelle in MID-Innovator-Format

neu

Fachliche Modelle in HTML-Format

neu

Fachliches Referenzmodell aus Edition 1999 Generischer Produktansatz Das Fachliche Komponentenmodell

http://www.gdv.de/vaa

neu neu

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Inhalt

1. Einleitung................................................................................................................... 5 1.1. Motivation ............................................................................................................................ 5 1.2. Einbettung (Rahmen) .......................................................................................................... 6 1.2.1. Zusammenarbeit mit anderen Projekten ...................................................................... 6 1.2.2. Zusammenspiel von fachlichem und technischem Modell........................................... 6

2. Ziel/Auftrag ................................................................................................................ 8 2.1. Projektauftrag...................................................................................................................... 8 2.2. Prämissen / Ergänzungen...................................................................................................8

3. Vorgehensweise...................................................................................................... 10 3.1. Überblick ........................................................................................................................... 10 3.2. Methodik und Pragmatik beim Einsatz von UML .............................................................. 11 3.2.1. Adoption von UML ...................................................................................................... 11 3.2.2. Ergebnistypen............................................................................................................. 12 3.2.3. Erstellung der Ergebnistypen ..................................................................................... 15 3.3. Der Weg zum fachlichen Komponentenmodell................................................................. 21 3.3.1. Das Komponentenmetamodell ................................................................................... 22 3.3.2. Das Komponentenschichtenmodell der VAA ............................................................. 23 3.4. Konkretes Vorgehen bei den Arbeitsgebieten .................................................................. 24 3.4.1. Vorgehensweise Partner ............................................................................................ 24 3.4.2. Vorgehensweise Subjekt............................................................................................ 25 3.4.3. Vorgehensweise Produkt ........................................................................................... 27 3.4.4. Vorgehensweise Schaden/Leistung........................................................................... 30 3.4.5. Vorgehensweise Vertrag ............................................................................................ 32 3.4.6. Vorgehensweise Kontokorrent ................................................................................... 37 3.4.7. Vorgehensweise Provision ......................................................................................... 38

4. Ergebnisse............................................................................................................... 40 4.1. Fachliche Design-Patterns................................................................................................ 40 4.1.1. Objekt suchen ............................................................................................................ 40 4.1.2. Objekt anzeigen ......................................................................................................... 40 4.1.3. Objekt ändern ............................................................................................................. 41 4.2. Status ................................................................................................................................ 41 4.3. Darstellung der Ergebnistypen.......................................................................................... 42

5. Beispiele und Erläuterungen ................................................................................. 43 5.1. Anwendungsbeispiel ......................................................................................................... 43 5.2. Iteration I. .......................................................................................................................... 43 5.3. Iteration II. ......................................................................................................................... 44 5.4. Iteration III. ........................................................................................................................ 46

6. Umgang mit dem Referenzmodell ......................................................................... 48 6.1. Nutzen des Referenzmodells............................................................................................ 48 6.2. Verwendung des Referenzmodells................................................................................... 48 6.2.1. Basis für neue Entwicklungen .................................................................................... 48 6.2.2. Abgleich mit existierenden Unternehmensmodellen.................................................. 49 6.2.3. Grundsätzliche Verwendungsmöglichkeiten .............................................................. 51

7. Referenzen............................................................................................................... 53 7.1. Use-Case-Modell .............................................................................................................. 53 7.2. Klassenmodell................................................................................................................... 53 7.3. Fachliche Dienste.............................................................................................................. 53 7.4. Literaturhinweise ............................................................................................................... 53

© GDV 2001

i

Inhalt

Das Objektorientierte Fachliche Referenzmodell

Abbildungen Abbildung 1: Weg zu SW-Komponenten ......................................................................................7 Abbildung 2: Zyklisch-Iteratives Vorgehen der Phase 1 .............................................................10 Abbildung 3: Vorgehen der Phase 2 ............................................................................................11 Abbildung 4: Vorgehensweise Komponentenmodell ..................................................................22 Abbildung 5: Das Komponentenmetamodell der VAA ...............................................................23 Abbildung 6: Das Komponentenschichtenmodell der VAA........................................................24 Abbildung 7: Grobprozess - Vertragsabschluß............................................................................33 Abbildung 8: Grobprozess - Vertragsauskunft ............................................................................33 Abbildung 9: Grobprozess - Vertragsänderung ...........................................................................34 Abbildung 10: Anwendungskomponenten im Vertragsbereich...................................................35 Abbildung 11: Prozesskomponente Versicherungsverhältnisverwaltung....................................36

ii

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Abstract Das Projekt ‚Objektorientiertes fachliches Referenzmodell‘ (kurz: OFRM) wurde im März 1998 vom AK VAA ins Leben gerufen. Der Auftrag war zunächst, ein „unternehmensübergreifendes und spartenunabhängiges Referenzmodell für die deutsche Versicherungswirtschaft“ zu erstellen. Die vorgegebene Projektlaufzeit betrug 9 Monate. Sie wurde im Dezember 1998 um 3 Monate verlängert. Das bis dahin vorliegende Ergebnis war eine vielversprechende Basis für ein Komponentenmodell. Deshalb hat man im März 1999 eine zweite Projektphase aufgesetzt, um die fachlichen Komponenten auf Basis des vorliegenden Referenzmodells unternehmensübergreifend festzulegen und zu definieren. Die fachliches Basis für das Referenzmodell waren die fachlichen Ergebnisse aus VAA 2.0, sowie weiterer fachlicher Input aus Reviewergebnissen von zusätzlichen Partnern aus der Branche. Ziel war zunächst, das neue Referenzmodell nach den Techniken und Methoden der sogenannten Objektorientierung zu beschreiben. Diese Technologie versprach am ehesten, die Vision eines Komponentenmarktes für Versicherungsanwendungen zu realisieren. Eine objektorientierte Analyse sowie die Erstellung von fachlichen Komponenten sind Neuland für die Versicherungen. Das Projektteam hat diese Vorgehensweisen erarbeitet, praktiziert und dokumentiert. Die Projektergebnisse bestehen aus •

dem vorliegenden Dokument



dem Komponentenmodell



dem fachlich/inhaltlichen Modell in verschiedenen elektronischen Darstellungen (Innovator, HTML-Format)



einem Glossar.

Das fachlich inhaltliche Modell sowie das Komponentenmodell decken folgende Arbeitsgebiete ab: •

Produkt



Partner



Subjekt



Vertrag



Schaden/Leistung



Kontokorrent



Provision.

© GDV 2001

3

Das Objektorientierte Fachliche Referenzmodell

Einleitung

1. Einleitung 1.1. Motivation Die deutschen Versicherungsunternehmen müssen sich großen Herausforderungen stellen. Ein sich stark veränderndes Kundenverhalten führt immer weiter weg vom Angebotsmarkt und immer weiter hin zum Nachfragemarkt. Die Unternehmen bestimmen nicht mehr in dem Maße wie bisher die Angebote, sondern der Kunde fordert und wählt, was er für sich ganz individuell möchte. Die Produktvielfalt und -flexibilität rückt immer mehr in den Mittelpunkt des Geschehens. Kürzere Produktzyklen erhöhen den Innovationsbedarf. Dies bedeutet für eine Vielzahl von Unternehmen einen gewaltigen Umbruch ihrer Systeme. Es ist eine anpassungsfähige Software erforderlich, die der weiter wachsenden Marktdynamik, deren Ende noch nicht absehbar ist, gerecht wird. Die Anforderungen an unsere bisherigen Systeme wachsen weiter. Entwicklungszeiten und Kosten müssen reduziert werden. Gleichzeitig müssen die Systeme flexibler und offener werden. Um allen diesen Anforderungen gerecht zu werden, müssen Unternehmen mehrgleisig fahren. Eigene Softwareentwicklung wird auch weiterhin ein wichtiger Faktor im Unternehmen sein. Andererseits ist es aber auch notwendig, interessante Fremdsoftware leicht in bestehende Strukturen integrieren zu können. Nur so wird ein Unternehmen auf Dauer dem immer härteren Konkurrenzdruck stand halten können. Langfristig wird der ursprüngliche Wunsch nach integrierbaren Systemen zum Überlebenskampf der Unternehmen. Deshalb hat sich 1994 durch eine Initiative des GDV eine Gruppe von Versicherern zusammengeschlossen, eine Basis für Softwarekomponenten zu schaffen. Dies bedeutete zum einen die Entwicklung von versicherungstechnischen Fachkonzepten als Grundlage für die Komponenten und zum anderen eine Definition eines technischen Umfelds für diese Fachabläufe. Man hat für die damals wichtigsten Versicherungsbereiche (Vertrag, Partner, Schaden/Leistung, Provision) für die fachliche Spezifikation Projekte aufgesetzt mit dem Ziel, ein Funktionen- Daten- und Prozessmodell zu definieren, passend zum technischen Umfeld. Die entsprechenden Ergebnisse sind in VAA 2.0 ersichtlich. Es war der erste Versuch, gemeinsam unternehmensübergreifend Fachmodelle zu bauen. Dieses Ziel wurde auch erreicht. Leider kam es aber noch nicht soweit, eine Basis für Komponenten zu schaffen. Als dann Mitte der 90er Jahre die Welle der objektorientierten Analyse- und Entwurfsmethoden auch bzw. gerade für fachliche Modelle hochkam, stand man vor der Entscheidung, diese Methoden zu integrieren oder nur den prozeduralen Weg weiterzuverfolgen. Obwohl die Versicherungsbranche insgesamt den objektorientierten Methoden zunächst sehr skeptisch gegenüberstand und das teilweise auch heute noch tut, hat sich die GDV-Initiative Ende 1997 entschieden, den objektorientierten Weg zu beschreiten. Durch die einheitliche Betrachtung von Daten und Funktionen erhofft man sich eine einfachere Abgrenzung der Systeme und somit eine bessere Basis für Komponenten. Im März 1998 wurden dann zwei Projekte initiiert. Zum einen das ‚Objektorientierte fachliche Referenzmodell‘ (OFRM) und zum anderen das ‚Objektorientierte technische Referenzmodell‘. Parallel zu

© GDV 2001

5

Einleitung

Das Objektorientierte Fachliche Referenzmodell

den OO-Projekten liefen im Rahmen der fachlichen Modellierung noch zwei weitere Projekte: Zum einen das Projekt ‚Produkt‘ mit dem Ziel, diesem wichtigen Thema in der Versicherungsbranche mehr Gewichtung zu geben und zum anderen das Projekt ‚Inkasso‘, das bei VAA 2.0 noch nicht berücksichtigt wurde. Beide Projekte liefen zunächst ein Jahr. Im März 1999 wurde sowohl das technische als auch das fachliche Referenzmodell veröffentlicht. Da dieses ersten Zwischenergebnisse in Richtung Komponenten sowohl fachlich als auch technisch sehr vielversprechend waren, sollten beide Projekte in einem weiteren Projektjahr den Schritt in die Komponentenwelt vollziehen. Hierzu wurden die Ergebnisse aus den Referenzmodellen verwendet, ergänzt um Reviewergebnisse und um weiteren Input den das bisherige Projektteam durch zusätzliche neue Mitarbeiter vor allem aus Softwarehäusern erhielt. Die Ergebnisse aus dem Arbeitskreis ‚Produkt‘ und ‚Inkasso‘ wurden ebenfalls, sofern noch nicht geschehen, in das Gesamtmodell integriert.

1.2. Einbettung (Rahmen) 1.2.1. Zusammenarbeit mit anderen Projekten 1.2.1.1. Arbeitsgruppe VAA Produkt Die Arbeitsgruppe VAA-Produkt hatte im März 1999 ihre Arbeit abgeschlossen. Die Arbeitsgruppe wurde zu Gunsten der Integration in das Gesamtmodell aufgelöst. Die Mitarbeiter konnten teilweise als Reviewpartner bzw. als aktive Projektmitarbeiter im Projekt ‚Objektorientiertes fachliches Referenzmodell‘ gewonnen werden. Damit war gewährleistet, dass das erarbeitete Ergebnis des Parallelprojekts in die Überlegungen der Komponentenfindung mit einfloss.

1.2.1.2. Arbeitsgruppe VAA Inkasso 2.1 Ebenso wie die Arbeitsgruppe ‚Produkt‘ hatte auch die Arbeitsgruppe ‚Kontokorrent‘, wie sie sich selbst nannte, ein prozedurales Modell im März 1999 fertig. Dieses galt es nun im weiteren Projektjahr in die OO-Ergebnistypen zu übertragen und in das Gesamtmodell zu integrieren. Auch hier konnten Mitarbeiter aus dem ‚Kontokorrentprojekt‘ gewonnen werden, sodass eine fachliche Übertragung zu 100 Prozent gewährleistet ist.

1.2.2. Zusammenspiel von fachlichem und technischem Modell Wie bereits erwähnt wurden die beiden OO-Projekte ‚OFRM‘ und ‚technisches Referenzmodell‘ zeitgleich gestartet. Beide Projekte hatten jeweils zur Aufgabe, ein Referenzmodell zu erstellen. Unter dem Begriff Referenzmodell verstehen wir für Versicherungsunternehmen: Ein Referenzmodell ist eine einheitliche, in sich widerspruchsfreie Struktur, die es erlaubt, minimal und vollständig die Strukturen von Versicherungsunternehmen zu beschreiben. Demzufolge ist ein fachliches Referenzmodell wie folgt definiert: Ein fachliches Referenzmodell ist eine einheitliche, in sich widerspruchsfreie Struktur, die es erlaubt, minimal und vollständig die Fachlichkeit von Versicherungsunternehmen strukturiert zu beschreiben. In gleicher Weise leitet sich die Definition eines technischen Referenzmodells ab: 6

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Einleitung

Ein technisches Referenzmodell ist eine einheitliche, in sich widerspruchsfreie Struktur, die es erlaubt, minimal und vollständig den technischen Lebensraum von Versicherungskomponenten zu beschreiben. Grundprinzipien

fachliches Referenzmodell

technisches Referenzmodell

strukturerhaltende Präzisierung der Geschäftsobjekte

Fachmodelle

strukturerhaltende Präzisierung der techn. Services

Paketbildung

fachliches technisches Komponenten- Komponentenmodell modell

Paketbildung

Technikmodelle

Herstellung

SW-Komponenten Steuerung Anwendungsbausteine

Dienste

Abbildung 1: Weg zu SW-Komponenten

Für die Erstellung dieser Referenzmodelle war eine Zusammenarbeit zwischen Technik- und Fachteam für die erste Iteration nur bedingt notwendig. Die Darstellung von Fachlichkeit in einem Versicherungsunternehmen lässt sich im ersten Schritt ohne Kenntnis der Technik machen. Deshalb hat sich der Abstimmungsbedarf zwischen den beiden Projekten konkret nur auf das Thema ‚Dienste‘ beschränkt. Diese wurden identifiziert und soweit als möglich technisch oder fachlich zugeordnet und jeweils definiert. Des weiteren fanden mehrere Sitzungstermine parallel statt. Das technische Modell wurde immer wieder mit der Fachgruppe diskutiert, um konträre Modellierung zu vermeiden. In der zweiten Projektphase war der Hauptaufwand bezüglich der Komponenten eindeutig im Fachteam vorhanden. Das technische Modell war insoweit bereits so offen und flexibel, daß es in der Lage war, jegliche fachliche Komponenten miteinander zu verknüpfen. Dabei darf es keine Rolle spielen, ob die Modelle objektorientiert oder prozedural realisiert sind. Dieser Anspruch wurde anhand des vom Fachteam erstellten Komponentenmetamodells mehrfach diskutiert und geprüft und es wurden die Begriffe abgeglichen und gemeinsam definiert.Die fachlichen Komponenten passen in das technische VAA-Modell, sollten aber auch für andere technische Umfelder benutzbar sein. Umgekehrt soll es möglich sein, in das technische VAA-Modell andere fachliche Komponenten zu integrieren. Die beiden Projektteams sind der Meinung, diesen Anforderungen gerecht geworden zu sein.

© GDV 2001

7

Ziel/Auftrag

Das Objektorientierte Fachliche Referenzmodell

2. Ziel/Auftrag 2.1. Projektauftrag Es soll ein objektorientiertes fachliches Referenzklassenmodell mit maximal 100 Geschäftsobjekten erstellt werden. Das Modell soll unternehmensübergreifend, branchenspezifisch, vollständig, minimal, konsistent und widerspruchsfrei sein. Es soll durch objektorientierte Darstellungsmittel (UML 1.1) dargestellt werden. Das fachliche Modell ist durch entsprechende grundlegende Verarbeitungsmechanismen wie Historienbildung, Kontenführung, Nummernvergabesysteme (Policennummer, Schadennummer), usw. zu verfeinern. Fachliche Basis ist VAA 2.0. Hier liegen prozedurale Fachmodelle für die Bereiche Partner, Vertrag, Schaden/Leistung, Povision sowie das allgemeine Papier „Fachliche Architektur“ vor. Des weiteren soll das Thema Produkt mitmodelliert werden. Inhaltlich haben diese Papiere nach wie vor Gültigkeit und können deshalb benutzt werden. Des weiteren sollen - sofern vorhanden - Objektmodelle von Unternehmen bzw. Unternehmensprojekten bei der Erarbeitung des Referenzmodells berücksichtigt werden. Auf der Basis dieses Referenzmodells sollen nach bestimmten Kriterien, die das Projektteam festzulegen hat, fachliche Komponenten geschnitten werden. Das Ziel soll ein fachlich vollständiges und beschriebenes Komponentenmodell für die Bereiche Produkt, Vertrag, Partner, Schaden/Leistung, Provision und Kontokorrent sein. Der Komponentenschnitt soll nachvollziehbar sein. Dieses Komponentenmodell soll Basis für die Entwicklung eines offenen Marktes für standardisierte Anwendungs- und Basissoftwarebausteine für die Versicherungswirtschaft sein.

2.2. Prämissen / Ergänzungen Durch die recht kurze Projektlaufzeit bereits in Phase 1 des Projekts musste das Projektteam von Beginn an fachlich folgende Gewichtungen vornehmen: •

Nur Erstversicherungsgeschäft



Komposit, Kranken, Leben



Schwerpunkt auf reinem Versicherungsgeschäft



Andere Geschäftsprozesse werden soweit notwendig mitmodelliert



Schwerpunkt auf operativem Geschäft (Data-Warehouse wird nicht modelliert)



Nicht modelliert wird:

Hypothekengeschäft, Wertpapierverwaltung, Grundstücksverwaltung, Immobilien, Finanzbuchhaltung, Zentrales Berichtswesen, Personalsysteme, Aktive Rückversicherung Diese fachlichen Einschränkungen blieben auch für die zweite Phase erhalten.

8

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Ziel/Auftrag

Für die zweite Phase war das Komponentenmodell das primäre und wichtigste Ziel. Das Referenzmodell wurde, sofern es als Basis für das Komponentenmodell notwendig war, hinsichtlich Vollständigkeit, Granularität und Ergänzungen aus den Reviews so gut wie möglich überarbeitet. Eine komplette Erstellung eines konsolidierten Gesamtreferenzmodells war jedoch in der weiteren Projektlaufzeit nicht möglich.

© GDV 2001

9

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

3. Vorgehensweise Der hier verwendete Prozess als Mittelweg zwischen Theorie und Praxis wird im Folgenden erläutert. Der mittlerweile von Rational entwickelte „Rational Unified Process“ wurde beim Vorgehen im Projekt teilweise berücksichtigt. Der Grad der Anwendung ist in den verschiedenen Teilteams jedoch unterschiedlich. Deshalb ist dieses Kapitel das Ergebnis von Erfahrungen teilweise unterschiedlicher Vorgehensweisen die jedoch alle zu einem Ziel geführt haben, nämlich der Erstellung eines Komponentenmodells für die Versicherungsbranche. In den folgenden Kapiteln wird die Vorgehensweise aus Phase 1 und Phase 2 beschrieben. Der Übergang ist fließend. Allerdings hat sich das Projektteam von Phase 1 nach Phase 2 zunächst verdoppelt und somit auch die Arbeitsweise des Gesamtteams beeinflusst. Neue Ideen, zusätzliche fachliche Ergänzungen und methodisch neue Ansätze führten zu teilweise unterschiedlichen Arbeitsweisen in den jeweiligen Arbeitsgebieten, was wiederum Auswirkungen auf die Ergebnisse hatte. Trotzdem wurde das Ziel erreicht, ein Gesamtkomponentenmodell für die Versicherungsbranche zu erstellen.

3.1. Überblick Grundidee der Vorgehensweise ist die logische Durchgängigkeit von Prozessbeschreibung und Klassenmodell. Die Schlüssigkeit ist dann gegeben, wenn von einem Use Case-Modell ausgehend ein erstes sogenannntes konzeptionelles Klassenmodell erstellt wird und dieses durch Methoden angereichert wird. Hierdurch entsteht ein statisch und dynamisch spezifiziertes Klassenmodell.

Use-Cases beschreiben

Klassenmodell spezifizieren

„Arbeitsgebiete“ festlegen

Prozeßmodelle

Konzeptionelles Modell erstellen

Interaktionen beschreiben

Datenmodelle

Funktionenmodelle

Abbildung 2: Zyklisch-Iteratives Vorgehen der Phase 1

Das Erstellen des Dynamikmodells hat im Analyse-/Entwurfsprozess Rückwirkungen auf das Use Case-Modell, wodurch sich ein zyklisches bzw. verfeinerndes Vorgehen ergibt, wie Abbildung 2 zeigt. 10

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

Zu Zwecken der Modellstrukturierung werden sowohl Use-Cases als auch Klassen und auch später die Komponenten in sogenannten „Arbeitsgebieten“ zusammengefasst. Bereits vorhandene Ergebnisse aus VAA 2.0 fließen sowohl in das Use Case- als auch in das - statische und dynamische - Klassenmodell mit ein. Für die Erstellung des Komponentenmodells müssen zunächst in einer zweiten Phase die Ergebnisse der Phase 1 hinsichtlich der Konsistenz, der fachlichen Vollständigkeit und der Granularität verbessert werden. Diese Punkte waren unter anderem auch Ergebnisse aus den Reviews, die nach Phase 1 mit bisher an dem Projekt nicht teilnehmenden Versicherungsunternehmen und Softwarehäusern stattfanden. Für das Ziel, letztendlich die fachlichen Komponenten festzulegen und zu beschreiben ist es des weiteren erforderlich, Kriterien zu finden. Die gesamte Vorgehensweise der Phase 2 ist aus Abbildung 3 ersichtlich.

Use-Cases vervollständigen/ vereinheitlichen

ReviewErgebnisse

Work-ShopErgebnisse

Klassenmodell vervollständigen/ vereinheitlichen

Projektzeit: 1 Kalenderjahr Team:18 30 % Arbeitszeit

Konzeptionelles Modell prüfen

Iteration 2

Andere Komponentenmodelle

Interaktionen detaillierter beschreiben

Kriterien

K O M P O N E N T E N

Abbildung 3: Vorgehen der Phase 2

3.2. Methodik und Pragmatik beim Einsatz von UML Zyklisches Vorgehen kann einerseits durch eine Vielzahl an theoretischen Ansätzen untermauert werden. Andererseits wurde die konkrete Vorgehensweise stets den konkreten Projekterfordernissen auf praktikable Weise angepasst. Dies äußert sich mitunter in einem individuellen Verständnis der verwendeten Modellierungssprache UML. Die im Folgenden beschriebene Vorgehensweise ist eine Sammlung von Beobachtungen und Vereinbarungen, die bei der Arbeit am OFRM gemacht wurden. Einige Erkenntnisse beziehen sich speziell auf den Umgang mit Referenzmodellen. Viele Erkenntnisse sind jedoch übertragbar auf reale Projekte.

3.2.1. Adoption von UML Für die Darstellung der Ergebnisse des OFRM wird die standardisierte Modellierungssprache UML 1.1 (Unified Modeling Language) verwendet [1]. Darüber hinaus bietet UML alle Elemente zur © GDV 2001

11

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

durchgängigen logischen Erarbeitung der wichtigsten Aspekte des Modells. Somit wird die UML für die Zwecke der objektorientierten Modellierung von der VAA adoptiert. Zur Modellerstellung wurde in diesem Projekt das Werkzeug Rational Rose 98 eingesetzt. Es wurde keine explizite Toolbewertung durchgeführt; diese Entscheidung bedeutet auch keineBindung an einen bestimmten Hersteller. Weitere angebotene Modellformate sind in Abschnitt 4.3 beschrieben.

3.2.2. Ergebnistypen Die im Projekt verwendeten bzw. zu erstellenden wesentlichen Ergebnistypen sind: •

Use Case Modelle (mit ihren Modellelementen)



Klassenmodelle (mit ihren Modellelementen)



Sequenzdiagramme



Paketdiagramme



Komponenten

sowie ein Fachglossar, das die Beschreibung der im OFRM enthaltenen Klassen beinhaltet.

3.2.2.1. Use Case Modell Ein Use Case Modell dokumentiert Aspekte von Geschäftsprozessen und dient als Grundlage für die Erstellung eines objektorientierten Klassenmodells. Es beinhaltet folgende Modellelemente: 3.2.2.1.1. Use Case Diagramm Ein Use Case Diagramm ist eine graphische Darstellung eines Use Case Modells. Es kann Use Cases, Akteure und Beziehungen in ihrer jeweiligen graphischen Darstellung beinhalten. 3.2.2.1.2. Use Case Use-Cases identifizieren und beschreiben Abläufe bzw. Aktivitäten, die isoliert betrachtet werden können. Solche Aktivitäten können etwa von einem Sachbearbeiter durchgeführt werden. Im Fall einer DV-gestützten Aktivität beschreibt ein Use Case die entsprechende Interaktion mit dem System, z.B. über eine Dialogschnittstelle. Ein Use Case kann aber durchaus auch von einem Batch-Prozess ausgeführt werden. Use Cases wurden unter folgenden Aspekten identifiziert:

12



Zerlegung in Teilaktivitäten nur dann, wenn diese immer in zeitlichem Zusammenhang stehen (also keine reine funktionale Zerlegung).



Es wird dennoch keine Reihenfolge der Aktivitäten vorgegeben (dies ist VU-spezifisch).



(Teil-)Aktivitäten und damit Use Cases können/sollen wiederverwendet werden (ReuseAspekt).



Use Cases dienen als Aufhängepunkt für spätere Sequenzdiagramme, die zur nachvollziehbaren Erstellung des Klassenmodells führen.

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.2.2.1.3. Use Case-Beschreibung In jedem Use Case wird der Ablauf der durchgeführten Aktivität beschrieben. Eventuell sind verschiedene Szenarien möglich. Die Beschreibungen wurden nach folgendem Muster verfasst:

Kurzbeschreibung: Auslöser:

Ereignis, das den Use Case anstößt.

Vorbedingungen:

Geforderter Zustand des Systems, bevor der Use Case eintritt.

Nachbedingung:

Zustand des Systems, nachdem der Use-Case abgelaufen ist.

Ergebnis

Geforderter Zustand des Systems, nachdem der Use Case erfolgreich durchlaufen wurde. (optional)

Szenarien-

Ablauf eines typischen Szenarios: 1. Option: wird vollständig zerlegt 2. Option: vollständige Beschreibung (wenn auf weitere Zerlegung der UC verzichtet wird)

beschreibung:

Akteure:

VU oder andere

Variantenbeschrei-

1. Option: keine Sequenzdiagramme vorhanden 2. Option: Freitext für verschiedene Szenarien und mehrere Sequenzdiagramme

bung:

3.2.2.1.4. Use-Case-Beziehungen Im vorliegenden Modell werden Use Cases über folgende Verbindungstypen in Beziehung gesetzt: 1. Die „uses“-Beziehung wird verwendet, wenn eine Teilaktivität in verschiedenen Anwendungsfällen gleich ist und man sich das Kopieren ersparen kann. Use Cases, die mit „uses“ verknüpft sind, bilden das typische Verhalten ab. Bei der Use Case Analyse wurde die „uses“-Beziehung im Sinne einer „muss“-Beziehung verwendet. 2. Die „extends“-Beziehung lagert ebenfalls Teilaktivitäten aus Anwendungsfällen aus, aber diese Teilaktivitäten stellen dann Variationen des typischen Verhaltens dar.1 Bei extends sollten die Regeln und die Gründe für die Ausnahme in der Dokumentation zum Pfeil immer festgehalten werden. Bei der Use Case Analyse wurde die „extends“-Beziehung im Sinne einer „kann“-Beziehung verwendet. 3. Für die asynchrone Kommunikation zwischen Use Cases werden Assoziationen verwendet. Uses und Extends sind in UML immer Vererbungsbeziehungen, dargestellt durch einen Pfeil mit geschlossener Pfeilspitze. 3.2.2.1.5. Akteur Ein echtes Rollenmodell war unternehmensübergreifend nicht möglich. Nur bei Eindeutigkeit wurde ein Akteur genannt. Ansonsten gilt als Akteur das VU stellvertretend für alle möglichen Akteure.

© GDV 2001

13

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

3.2.2.1.6. Public Use Case (Stereotype) Ein Public Use Case ist ein Use Case, der sich in weitere Unter-Use Cases gliedert und von mehreren anderen Use Cases (d. h. in unterschiedlichem fachlichen Prozess-Kontext) benutzt wird (reusable). Dies sind vor allem Use Cases die Suchfunktionalität beinhalten. Beispiel: Partner suchen, Schadenfall suchen, Produkt suchen. Die Beschreibung der Use Cases und auch das dazugehörige Sequenzdiagramm wurden stellvertretend für alle anderen einmal beschrieben, und zwar bei Partner suchen. Teilweise wurde anstatt ‚suchen‘ auch das Verb ‚ermitteln‘ benutzt. Die beiden sind hier synonym zu betrachten.

3.2.2.2. Sequenzdiagramm Ein Sequenzdiagramm ist eine graphische Darstellung eines Szenarios. Szenarien sind beispielhafte Abläufe eines Use Case und werden immer dann beschrieben, wenn sie zusätzlichen fachlichen Gehalt liefern. Ein Sequenzdiagramm entspricht also einer beispielhaften Ausprägung eines Use Cases. Sequenz- bzw. allg. Interaktionsdiagramme stellen die logische Verbindung zwischen Use Cases und den Fachklassen her: Sie bilden Abläufe bzw. Interaktionen zwischen Objekten ab und orientieren sich dabei an Use Cases. Teilweise waren sie Basis für die Gewinnung der Services und Methoden der Komponenten. Sie werden mit veröffentlicht, da sie an dieser Stelle die Nachvollziehbarkeit der Komponenten teilweise ermöglichen.

3.2.2.3. Klassenmodell Ein Klassenmodell dokumentiert die Klassen mit ihren Attributen, Methoden und Beziehungen. Es beinhaltet folgende Modellelemente: 3.2.2.3.1. Klassendiagramm Das Klassenmodell wird durch Klassendiagramme repräsentiert und ist der zentrale Ergebnistyp der objektorientierten Analyse. Klassendiagramme werden somit als wichtigstes Endergebnis dieses Papiers auftreten. 3.2.2.3.2. Klasse Eine Klasse beschreibt eine Gruppe von Objekten mit ähnlichen Eigenschaften (Attributen), einem gemeinsamen Verhalten (Methoden), gemeinsamen Beziehungen zu anderen Objekten und einer gemeinsamen Semantik. Eine Klasse kann von einem bestimmten Stereotyp sein (z. B. „Controller“). 3.2.2.3.3. Klassenbeschreibung In jeder Klasse werden das Verhalten und die Verantwortlichkeiten der durch sie repräsentierten Objekte beschrieben. Die Beschreibung besteht (mindestens) aus einer Kurzbeschreibung sowie (falls möglich) einer Referenz auf bestehende VAA (z. B. bei „Partner“).

1

vgl. Fowler, Martin: UML konzentriert: die neue Standard-Objektmodellierungssprache anwenden, 1998, S. 59

14

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.2.2.3.4. Methode Methoden (im Tool Rational Rose „operations“) sind Bestandteile einer Klassenbeschreibung. Sie sind selbst wieder beschrieben. Falls möglich, wird auf bestehende VAA referenziert (z. B. bei „Partner“). 3.2.2.3.5. Attribute Sie sind nicht Bestandteil des OFRM. 3.2.2.3.6. Beziehungen Beziehungen sind keine eigenständigen Ergebnistypen und nicht beschrieben (i. d. R. auch nicht mit Namen versehen). Beziehungen zwischen zwei Klassen ergeben sich aus der Kommunikation zweier Objekte (aus den jeweiligen Klassen). Die Differenzierung nach Art der Beziehung (Assoziation, Aggregation, Komposition) wird, falls nicht sofort offensichtlich, in der zweiten. Iteration (s. Abschnitt 1.1) durchgeführt. 3.2.2.3.7. Vorgangsklasse (Stereotype) Eine spezielle Klassifizierung sind die sogenannten „Vorgangsklassen“, gekennzeichnet durch den Stereotype „Controller“.2 Vorgangsklassen repräsentieren die Ablaufsteuerung innerhalb eines Use Cases. Sie dienen als geeignetes Werkzeug zum aktiven Versenden von Nachrichten an Fachklassen, die möglichst keine Ablaufkenntnisse besitzen sollen. Controller, die wiederum von einer WorkflowSteuerung bedient werden, sind nicht Bestandteil dieses Referenzmodells.

3.2.3. Erstellung der Ergebnistypen 3.2.3.1. Vorgehensmuster Use Case Diagramme sind der erste Ergebnistyp, der erstellt wird. Zu jedem Use Case wird eine Beschreibung angefertigt, die durch ein oder mehrere Szenarien ergänzt werden kann. Die Use Case Modelle werden zumeist ohne Akteure angefertigt, da die Definition derselben (und auch die Trennung in maschinelle / manuelle Ablaufanteile) kaum unternehmensübergreifend gültig sein kann. Zur Vermeidung von Unternehmens- oder Spartenspezifika besitzen Beschreibungen der Use Cases i. d. R. keine Vor- oder Nachbedingungen. Nach Erstellung von Use Case Diagrammen (zunächst ohne Szenarien) wird ein konzeptionelles (sehr grobes) Klassenmodell erstellt, das die wesentlichen Geschäftsobjekte enthält. Zur weiteren Analyse werden nun Szenarien entworfen. Jedes Szenario wird in Form eines Sequenzdiagramms dargestellt. Das Sequenzdiagramm hat drei Funktionen: -

Es reichert das Klassenmodell mit Methoden an.

-

Es erweitert das Klassenmodell um weitere Klassen.

-

Es liefert Services von anderen Komponenten.

2

Im technischen Referferenzmodell [4] bezeichnet als „Process Business Object“ (PBO).

© GDV 2001

15

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

Also werden Sequenzdiagramme bzw. Szenarien so gewählt, dass möglichst viele Methoden / neue Klassen erkannt werden können. Sequenzdiagramme sind einem Use Case zugeordnet. Hier ist abgebildet, welche Klassen in welchem Use Case verwendet werden; hier wird also die „prozesshafte“ Struktur in eine „objektorientierte“ Struktur abgebildet. Das Abbilden von Sequenzdiagrammen kann dazu führen, dass die Notwendigkeit weiterer Szenarien erkannt wird, also kann noch eine dritte Funktion des Sequenzdiagramms auftreten: -

Es ergänzt Use Cases um weitere Szenarien.

Das Abbilden eines typischen „Bereitstellen“-Use Case als Sequenzdiagramm schließlich führte zu der Erkenntnis, dass ein Sequenzdiagramm auch Use Case-Diagramme um weitere Use Cases ergänzen kann. Bei der Modellierung der Sequenzdiagramme wird ein beispielhafter Ablauf dargestellt. Die Steuerung dieses Ablaufes wird einem Objekt einer Klasse des Stereotyps „PBO“ (Proces Business Object) überlassen., die jeweils links im Diagramm zu finden ist und den gleichen Namen trägt wie der Use Case.

3.2.3.2. Erfahrungen Beim Arbeiten mit den unterschiedlichen Diagrammtypen ließ sich folgendes feststellen: -

Use Case Diagramme lassen sich beliebig detaillieren, d. h. ein Use Case kann in mehrere beteiligte Use Cases unterteilt werden. Die Wahl der „richtigen“ Granularität der Use Cases beinhaltet neben einigen benennbaren Regeln auch einen Restanteil Intuition; hier sind unternehmensspezifische Abweichungen wahrscheinlich, was die Anwendbarkeit des Referenzmodells nicht beeinflussen muss, solange die Vollständigkeit (im Sinne der Allgemeingültigkeit) gegeben ist.

-

Klassendiagramme lassen sich „einstufig“ detaillieren, wenn man das Konstrukt der Fassadenklassen verwendet. Es entsteht ein grobes Diagramm, das die Zusammenhänge der Fassadenklassen (das sind im weiteren die Komponentenkandidaten) abbildet; jede Fassadenklasse kann entsprechend detailliert werden. Verwendet man bei der Detaillierung der inneren Struktur einer Fassadenklasse weitere Fassadenklassen, lassen sich weitere Detaillierungsstufen abbilden.

-

Sequenzdiagramme lassen sich analog der Klassendiagramme detaillieren.

Beim Abbilden der Use Cases in Sequenzdiagrammen stellte sich allerdings heraus, dass eine Reduktion auf die Fassadenklassen nicht sinnvoll ist. Man erhält dann ein sehr abstraktes Klassenmodell (im Prinzip das konzeptionelle Modell); das Modellieren von Details, insbesondere die Qualitätssicherung darauf, fällt schwer. Es hat sich (zur Analysezeit) eine Mischform herausgebildet: Jedes Arbeitsgebiet (s. Abschnitt 3.2.3.5) wird für sich im Detail modelliert und beschränkt sich bei Anforderungen, die an andere Arbeitsgebiete gehen, auf das Ansprechen der Fassade dieses Bereiches. Folge: Die notwendigen Details innerhalb eines Arbeitsgebietes können strukturiert abgebildet werden, und die einzelnen Arbeitsgebiete können zunächst parallel bearbeitet werden.

16

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.2.3.3. Abbildung von Geschäftsprozessen Use Cases können gleichermaßen verschiedene Abstraktionsstufen des Versicherungsgeschäftes darstellen: 3.2.3.3.1. Wesentlicher Geschäftsprozess Auf oberster Ebene wurden zunächst auf Basis VAA 2.0 fünf wesentliche Geschäftsprozesse identifiziert, die durch Use Cases repräsentiert und weiter zerlegt werden können: 1. Produkt einführen und verkaufen 2. Vertrag verwalten 3. Schaden/Leistung verwalten 4. Be- und Abrechnung durchführen 5. Partner verwalten 3.2.3.3.2. Geschäftsprozess Die identifizierten „wesentlichen Geschäftsprozesse“ werden wiederum in Geschäftsprozesse bzw. weitere Use Cases zerlegt. Größtenteils entsprechen die „Geschäftsprozesse“ den Prozessen aus VAA 2.0. 3.2.3.3.3. Teilaktivität Die „Geschäftsprozesse“ werden in Teilaktivitäten (weitere Use Cases) zerlegt, die aus Benutzersicht in einem VU durchgeführt werden.

3.2.3.4. Einarbeitung bisheriger VAA-Ergebnisse Ausgehend von der in VAA 2.0 vorgefundenen Situation (es existiert eine umfassende VAAAusarbeitung zu gewissen technischen und fachlichen Bereichen) ergeben sich folgende vier Möglichkeiten zur Übernahme vorhandener Ergebnistypen: 3.2.3.4.1. Nutzung von Prozessmodellen Man nutzt die Beschreibung von Prozessen / Funktionen „formatfrei“ als Input der Analyse, in der man UML-Diagramme erstellt, d. h. man muss gewisse Diagrammtypen erstellen, nämlich •

Klassendiagramm



Use Case Diagramm



Sequenzdiagramm



ggf. Paket-Diagramm

und hierbei hohen Aufwand leisten. 3.2.3.4.2. Nutzung von Datenmodellen Man verwendet •

Entitäten (bzw. E-R-Diagramme)

als Input für © GDV 2001

17

Vorgehensweise •

Das Objektorientierte Fachliche Referenzmodell

Klassendiagramme.

Aufgrund der strukturellen Ähnlichkeit der beiden Ergebnistypen ist der Anpassungsaufwand hier gering. 3.2.3.4.3. Nutzung von Funktionenmodellen Man verwendet •

Funktionen

als Input für •

Methoden.

3.2.3.4.4. Nutzung von Modellsichten Das im Projekt „OFRM“ angestrebte Gesamtergebnis setzt sich aus mehreren Teilergebnissen zusammen, die jeweils in „Packages“ (Paketen) strukturiert sind (dies waren bereits vielversprechende Komponenten-Kandidaten). Die Packages ergeben sich aus den Arbeitsgebieten (s. Abschnitt 3.2.3.5). Man verwendet •

Modellsichten

als Input für •

Paketbildung.

Diese Möglichkeiten wurden in unterschiedlicher Gewichtung verwendet. Wie die Gewichtung ausfiel, war abhängig von den vorhandenen Informationen und Ergebnistypen (insbesondere) aus den VAA-Unterlagen; aus pragmatischen Gründen wurde jeweils der zeitsparendere Ansatz gewählt (Beispielsweise wurde im Arbeitsgebiet Partner auf eine vollständige Analyse der Prozesse/Funktionen verzichtet). Maximal mögliche Qualität hätte man dann erreicht, wenn parallel alle Ansätze durchgeführt und dann abgeglichen worden wären. Um unter den gegebenen Rahmenbedingungen (zur Verfügung stehende Zeit und Ressourcen) ein akzeptables, weiterverwendbares Ergebnis (und nicht nur ein Fragment) erzielen zu können, hat man auf diese (zeitaufwendigen) qualitätssichernden (bzw. –erhöhenden) Maßnahmen verzichtet und (stellenweise ungeprüft) auf bestehenden Ergebnissen der VAA-Papiere aufgesetzt.

3.2.3.5. Verteilte Analyse: Parallelisierung und Harmonisierung von Arbeitsgebieten Das Erarbeiten eines fachlichen Modells, in welchem alle fachlichen Aspekte eines Versicherungsunternehmens abgebildet sind, ist mit einem Projektteam in Form einer gemeinsamen Analyse nicht in einer realistischen Zeit zu leisten. Hier wird es notwendig, das Gesamtproblem in Teilprobleme zu zerlegen und diese parallel in kleinen Teams zu bearbeiten. Es werden also mehrere Ergebnisse erzeugt (die auch Abhängigkeiten untereinander besitzen), die dann konsolidiert werden müssen. Um so arbeiten zu können, wurden Fassadenklassen (s. Abschnitt 3.2.3.2) verwendet. Die Verwendung von Fassadenklassen ermöglicht es, Anforderungen an „externe“ Bereiche (deren innere Struktur

18

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

unbekannt ist) an passender Stelle zu sammeln, damit diese (zeitversetzt) berücksichtigt werden können. Die Koppelung der einzelnen Teilbereiche miteinander ist dann nicht so stark wie ohne Benutzung der Fassadenklassen. Es wird ein Grundprinzip der Objektorientierung, die Kapselung, auf einer höheren Ebene angewendet. Insbesondere, wenn die hinter der Fassadenklasse verborgenen Klassen dem Inhalt einer Komponente entsprechen, ist die Beschreibung der Komponentenschnittstelle mit der Beschreibung der Fassadenklassen-Schnittstelle identisch; Komponentenbildung wird hierdurch also unterstützt. Die Auflösung der Fassadenklassen erfolgte in Phase 2 auf Grund der höheren Priorität des Komponentenmodells nicht mehr. Sie sind deshalb sofern modelliert im Modell noch enthalten und enthalten genau die aus dem jeweiligen Fachgebiet geforderten Services einer anderen Komponente. Zum Beispiel: S/L Produkt ist die Fassadenklasse Produkt im Arbeitsgebiet Schaden. Hier stehen alle Services, die das Arbeitsgebiet Schaden in der Komponente Produkt bereitgestellt haben möchte. Die Ersparnis durch paralleles Vorgehen steht einem hohen Aufwand beim Abgleich der Ergebnisse gegenüber. Dieser Aufwand konnte in Phase 2 teilweise nicht mehr erbracht werden, so dass das Referenzmodell nur teilweise konsolidiert ist. Dies wirkt sich an diversen Stellen aus. Man findet nicht eingehaltene Namenskonventionen, unterschiedliche Templates und wie bereits erwähnt nicht aufgelöste Fassadenklassen. Dies sollte jedoch die Lesbarkeit und auch die Qualität des Modells nicht allzu sehr beeinflussen.

3.2.3.6. Übergreifende Integration mit technischer Architektur Da neben dem „fachlichen“ das „technische“ Referenzmodell parallel entwickelt wurde, wurden die im technischen Team festgelegten Stereotypen für die Klassen übernommen und berücksichtigt: -

Entity Business Object (EBO)3

-

Dependent Object (DO)

-

Process Business Object (PBO).

3.2.3.7. Konventionen 3.2.3.7.1. Klassenstruktur -

Template zur Klassen-Beschreibung (s. Abschnitt 3.2.2.3.3)

-

Verwendung von Stereotypes (Controller, EBO, DO)

-

Beziehungen i. d. R. nicht beschrieben

-

Namen von Klassen nicht „normiert“; keine Tätigkeit, sondern nur Substantiv

3.2.3.7.2. Use-Case-Struktur -

Template zur Use Case-Beschreibung (s. Abschnitt 3.2.2.1.3)

-

Granularität des Use Case: keine festen Regeln

3

Entspricht in etwa dem hier verwendeten „Controller“.

© GDV 2001

19

Vorgehensweise -

Das Objektorientierte Fachliche Referenzmodell

Namen von Use Cases nicht „normiert“, sondern möglichst sprechend

3.2.3.7.3. Methodenstruktur Nahezu jede Methode liefert einen Returnwert. Dies ist in den Sequenzdiagrammen (als gegenläufiger Pfeil) nur in Einzelfällen modelliert. Viele Methoden werden mit Parametern versehen. Wo diese explizit (allgemeingültig) definiert werden können, sind sie in der Beschreibung der Methode erwähnt. Klassenmethoden (siehe Smalltalk) werden nicht aufgenommen. Die wesentlichen Methoden der Objekterzeugung und der Suche sind als Methoden eines BO-Managers modelliert.Die fundamentalen Methoden „...anlegen“, „...bereitstellen“, „...aktualisieren“ sind wie folgt vereinbart: 1.) ...anlegen:

legt eine Referenz auf ein anderes Objekt an

2.) ...aktualisieren:

a.) das (reine) Befüllen von Attributen mit Inhalten (Aufruf mit Parametern Attributtyp/Attributinhalt) b.) das Befüllen von Attributen sowie Überprüfen gewisser (attributspezifischer Plausibilitäten c.) Das erstmalige Anlegen des (leeren) Objekts d.) Die Referenz auf andere Objekte (Aufruf mit Parametern ‚Objekt, das zu referenzieren ist‘) e) Das (logische) Löschen eines Objekts

3.) ...bereitstellen:

es wird ein Objekt (genauer: Attributinhalte seiner Attribute) bereitgestellt.

zu 1.): Es wird ein Dienst als gegeben vorausgesetzt, der Instanzen einer Klasse erzeugt; somit wird keine „anlegen“-Methode benötigt, die ein Objekt neuanlegt. Dieser Dienst ist im Referenzmodell in Form einer Methode „erzeugen“ eines BO-Managers abgebildet. Die Methode „anlegen“ wird also nur dann (als fachliche Methode) benötigt, wenn eine Referenz auf ein oder mehrere andere Objekte angelegt werden soll. Beispielsweise wird eine neue PartnerAdresse angelegt, indem die Methode partnerBankverbindungAnlegen (bei Partner) eine Referenz zu einer (bereits existierenden) Bankverbindung anlegt. Die Methode wird in einem Ablauf i. d. R. gefolgt von der Methode „...aktualisieren“. zu 2.) a): Hieraus ergibt sich, dass die Methode (immer) parametrisiert aufgerufen wird. Struktur der Parameter: (: , : , ...). Somit ist die Methode entkoppelt von der inneren (Daten-) Struktur des Objektes. Es entscheidet ein (technischer) Historisierungsmechanismus anhand der auf Klassenebene getroffenen Festlegung zum Historisierungsbedarf, ob die Attributinhalte überschrieben werden oder eine „Zeitreihe“ aufgebaut bzw. fortgeführt werden muss. zu 2.) e): Ob das Löschen physisch oder logisch stattfindet, ist eine technische Entscheidung für die Zugriffsschicht. zu 3.): Die Methode setzt voraus, dass bereits ein Objekt gefunden wurde, das man dazu auffordern kann, sich (bzw. seine Attributinhalte) bereitzustellen bzw dass eine Referenz auf ein oder mehrere Objekte existiert. Für das Auffinden eines Objektes wird ein Suchdienst vorausgesetzt. Die Methode 20

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

stellt die Inhalte aller Attribute des Objektes zur Verfügung. Existiert in einer Klasse nur eine einzige Methode „bereitstellen“, so reicht dies als Methodenname aus. Beinhaltet die Klasse mehrere „bereitstellen“-Methoden, d. h. es existieren Dependent Objects, so wird der Methodenname um den Namen der Klasse erweitert, die das Dependent Object enthält. Methodennamen sind identisch mit den Namen der Nachricht, welche die Methode aufruft. Der Name einer Nachricht besteht i. d. R. aus einem Substantiv und einem Verb, wobei vereinbart wurde, das Verb ans Ende des Methodennamens zu stellen. Die Benennung erfolgt aus Sicht des „Dienstleisters“ (derjenigen Klasse, welche die Methode ausführt) und nicht aus Sicht des „Nutzers“ (also derjenigen Klasse, welche die Nachricht verschickt). Bemerkungen zu den „fundamentalen“ Methoden aktualisieren und bereitstellen: Nimmt man eine stark datenorientierte Sicht ein, so lassen sich viele Methoden reduzieren auf die Methodenbestandteile „...bereitstellen“, „...aktualisieren“, „...prüfen“, „...berechnen“. Aus Gründen einer besseren Lesbarkeit wird bei Methoden, deren Funktionalität sich mit in der Versicherungsbranche gängigen Vokabeln ausdrücken lässt, darauf verzichtet, ihren Namen auf eine der vier „Fundamental“-Bezeichnungen zu normieren. Die Beschreibungsstruktur der Methoden (Text-Template) sieht aus wie folgt: -

Beschreibung: eine kurze Beschreibung der Funktionalität; Parameter ja/nein

-

Besonderheit: spezielle Bemerkungen, falls nötig

-

Beispiel: kurzes, sprechendes Beispiel, wo sinnvoll

-

Referenz auf bestehende VAA: Bezug zu alten VAA-Papieren

Hierbei sollte die Beschreibung immer vorhanden sein. Ob alle Template-Abschnitte vorhanden sind, hängt von den Rahmenbedingungen des jeweiligen Bereichs ab (z. B. gibt es beim Bereich Inkasso keine „Referenz auf bestehende VAA“). Typische Auswertungsmethoden (Stichwort „Data Warehouse“), die nicht aus einem operativen Geschäftsprozess entstehen (z. B. bestehende VAA „Partner“, FK0115 „Regionale Informationswerte ermitteln“), sind im Referenzmodell nicht enthalten. Bei einer Detaillierung des Modells in einem Folgeprojekt (s. Abschnitt 1.1) können sie prinzipiell mit untergebracht werden.

3.3. Der Weg zum fachlichen Komponentenmodell Auf dem Gebiet der Komponentenmodellierung gab es bisher nur sehr wenige methodische Ansätze. Sicher waren in der Versicherungsbranche immer wieder Bestrebungen im Gange, fachliche Komponenten festzulegen und zu beschreiben. Nachvollziehbare, auf einem bestehenden Referenzmodell basierende Komponenten lagen dem Projektteam zu Beginn seiner Arbeit jedoch nicht vor. Deshalb war es zunächst erforderlich, Kriterien für die Komponenten zu finden und festzulegen. Des weiteren wurde recht schnell klar, dass der Begriff Komponente in der IT-Branche zwar weit verbreitet ist, jedoch sehr unterschiedlich interpretiert und verwendet wird. Um für seine Arbeit am Komponentenmodell eine gemeinsame Sprachregelung und ein einheitliches Verständnis zu finden, war es für das Projektteam unabdingbar, Begriffe, die im Zusammenhang mit dem Komponentenmodell stehen, für

© GDV 2001

21

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

VAA neu zu definieren. Erst dann war für die Beteiligten ein Arbeiten ihn die gleiche Richtung möglich. Die folgende Abbildung zeigt einen möglichen nachvollziehbaren Weg vom Referenzmodell zum Komponentenmodell. Für die Arbeitsgebiete Schaden/Leistung, Provision, Kontokorrent und teilweise Vertrag wurde diese Vorgehensweise weitgehend umgesetzt. ‡9ROOVWlQGLJH$EELOGXQJDXIGDV)DFKPRGHOO ‡6WHUHRW\SHQ3%2XQG(%2 ‡%HVFKUHLEXQJ|IIHQWOLFKHU0HWKRGHQ

Use-CaseModell

1

‡ *UXSSLHUXQJYRQ.ODVVHQ]X(LQKHLWHQ ‡ 3.JUXSSLHUW3%2V$:.(%2V ‡ 9HU|IIHQWOLFKXQJYRQ0HWKRGHQDXV GHP)DFKPRGHOO

FachModell

2

(Analysemodell)

Fachliches KomponentenModell (Textmodell)

,QWHUIDFHV 6DPPOXQJ|IIHQWOLFKHU 0HWKRGHQEHVFKUHLEXQJHQ

Abbildung 4: Vorgehensweise Komponentenmodell

Die Arbeitsgebiete Subjekt und Partner sind eher klassenmodellgetrieben und hatten deshalb bereits mögliche Komponentenkandidaten vorliegen; hier wurde mit dem Fachmodell begonnen. Für das Arbeitsgebiet Produkt ist auf Grund seiner Bedeutung als zentraler Kern des Fachmodells eine andere Vorgehensweise gewählt worden. Diese Vorgehensweise bei Produkt und die daraus entstandenen Ergebnisse werden in einem separaten Dokument beschrieben. Für einen Abgleich lag dem Team ein Vorschlag der IBM (IAA-Gold) eines fachlichen Komponentemodells vor. Inwiefern das Modell für die Fachkomponenten relevant war, ist in den einzelnen Arbeitsgebieten nachzulesen.

3.3.1. Das Komponentenmetamodell Bei dem Versuch, aus den Analysemodellen (Klassendiagramme und Use-Case-Modelle) Komponentenfunktionalität zu gewinnen, gelang es nicht, Einheiten zu „schneiden“, die allen Komponentenkriterien (insbesondere der funktionalen Abgeschlossenheit und der Kontextunabhängigkeit) gleichzeitig genügten. Als Basis für die fachlichen Komponenten in der Versicherungsbranche wurde daher zunächst ein Komponentenmetamodell entwickelt.(siehe Abbildung 5).

22

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

Abbildung 5: Das Komponentenmetamodell der VAA

Zunächst unterscheidet VAA zwei Hauptkomponententypen: •

Eine Prozesskomponente ist eine logische Zusammenfassung von Funktionalität. Diese Funktionalität läuft bezüglich eines bestimmten Ereignisses immer gleich ab. Dieser Ablauf wird also fest definiert. Er dient als Unterstützung bei der Bearbeitung von Aktivitäten (Teilprozesse und Arbeitsschritte). Die Steuerung der Prozesskomponente erfolgt durch das Process Business Object (PBO). Aufgrund des fest definierten Ablaufs sind Prozesskomponenten unter Umständen VUspezifisch, ein „customizing“ also grundsätzlich möglich. In die Architektur zu integrierende Legacy-Systeme wären als PKn abzubilden.



Eine Anwendungskomponente ist eine Gruppe von nicht-redundanten Funktionalitäten. Sie ist definitiv kontextunabhängig und kann im Prinzip überall verwendet werden. Die Anwendungskomponenten werden repräsentiert durch 1 – n sogenannte Entity Business Objects (EBO’s). Die EBO’s stellen überschneidungsfrei Daten und Funktionen zur Verfügung und stellen in ihrer Gesamtheit ein vollständiges Raster der Gesamtheit von Daten und Funktionen in dem modellierten Bereich dar. Anwendungskomponenten haben somit Standard- bzw. Pflichtcharakter.

Die durch PKn zusammengefasste Funktionalität wird durch Services von AWKn zur Verfügung gestellt. Alle Steuerung zwischen AWKn findet durch PKn statt.

3.3.2. Das Komponentenschichtenmodell der VAA Die Prozess- und Anwendungskomponenten sind natürlich im Gesamtzusammenhang zu sehen. Eine Prozesskomponente kann 1-n Anwendungskomponenten benutzen. Der Gesamtzusammenhang lässt © GDV 2001

23

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

sich in Abbildung 6 erkennen. Basis für die Grundidee war ein Entwurf der IBM in IAA-Gold. Die Ebenen wurden übernommen. Es folgte jedoch eine Anpassung der Begriffe und Definitionen.

PBO

AWK EBO

PBO

Prozesskomponente

PBO

AWK EBO

PBO

AWK

AWK

EBO

EBO

EBO EBO

EBO

EBO

PBO

AWK EBO

EBO

EBO

Fachliche Dienste

Technische Dienste

Prozesskomponente

EBO

FRAMEWORK Abbildung 6: Das Komponentenschichtenmodell der VAA

3.4. Konkretes Vorgehen bei den Arbeitsgebieten 3.4.1. Vorgehensweise Partner 3.4.1.1. Allgemeines Der Bereich „Partner“ findet immer mehr Beachtung. Schlagworte wie CRM (Customer Relationship Management), e-Commerce, e-Procurement und ähnliche sind Themen immer höherer Priorität. Hier jetzt schon unternehmensübergreifende Festlegungen zu machen erwies sich als undurchführbar. Die Architektur der VAA Final Edition erlaubt es allerdings, ohne weiteres weitere Prozesskomponenten zu definieren. So könnte man eine Prozesskomponente CRM definieren, die im wesentlichen Funktionalitäten der Anwendungskomponente Partner bzw. Rolle sowie Mechanismen aus dem Bereich Produkt nutzt. Der hier betrachtete Bereich „Partner“ entspricht also weitgehend dem „klassischen“ Verständnis. Für das Abbilden von Partnertypen wurde das Kompositionsmuster verwendet. Für das Anlegen rollenspezifischer Bankverbindungen ist die Komponente Rolle zu verwenden. Generell: Der Bereich „Partner“, wie er in oVAA Edition 99 definiert worden war, zerfällt in die Bereiche „Kommunikation“ (postalische und elektronische Adressen) und „Partner“. Im Rahmen von „Partner“ wurde der Bereich „Rolle“ (eines Partners oder Subjekts) betrachtet.

3.4.1.2. Use-Case-Modell VAA Final Edition Es existiert ein Use-Case-Modell zum Bereich Partner. Die enthaltenen Use Cases sind solche, die eher einen Dialog als einen Prozessablauf abbilden. Es existiert ein entsprechendes Use-Case-Modell zum Bereich Kommunikation. 24

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.4.1.3. Klassen-Modell VAA Final Edition Die Klassenstruktur im Bereich Partner hat sich im Vergleich zu VAA 2.0 (Edition 1999) nicht wesentlich verändert. Es sind die Klassen Telekommunikation und Bankverbindung hinzugekommen. Die Operationen der einzelnen Klassen sind im Vergleich zu VAA 2.0 stärker kompaktifiziert worden, d. h. Details (etwa auf „get“- oder „set“-Ebene) wurden in allgemeineren Operationen gekapselt. Diese Operationen sind dann stark parametrisiert.

3.4.1.4. Anwendungskomponenten VAA Final Edition Für die Services der Anwendungskomponente dienen als Quelle die (öffentlichen) Methoden aus dem Bereich „Partner“ im Objektmodell. Das sind im wesentlichen die Methoden der EBO-Klassen. Weitere Funktionalität wird durch den Partner-Manager zur Verfügung gestellt (Suchen, Erzeugen). Die Granularität der Services ist eher grob. Einzelne Attribute werden über Argumente/Parameter abgerufen/gesetzt. Wo allgemeingültig (sparten- und VU-unabhängig) Attribute genannt werden können, geschieht dies. Insbesondere aber risiko- bzw. produktabhängige Partnereigenschaften werden nicht explizit abgebildet (sondern generisch produktabhängig zur Laufzeit erzeugt; siehe Bereich „Produkt“). Es existieren im Bereich „Partner“ drei Anwendungskomponenten („Partner“, „Kommunikation“ sowie „Rolle“).

3.4.1.5. Prozesskomponenten VAA Final Edition Die gefundenen Use Cases führen zu zwei Prozess-Komponenten („Partnerverwaltung“, „Kommunikationsverwaltung“).

3.4.1.6. Vergleich mit anderen Modellen Die Funktionalität der AWK Kommunikation entspricht in den wesentlichen Teilen der Funktionalität der IAA-Komponente "Contact point and place" (C-Ebene). Die Funktionalität der AWK Partner entspricht in den wesentlichen Teilen der Funktionalität der IAAKomponente "Party" (C-Ebene). Einige IAA-Funktionen wie "Maintain party health information" oder "List insurance agreements for party" entsprechen Services der VAA-AWK "Rolle".

3.4.2. Vorgehensweise Subjekt 3.4.2.1. Allgemeines Generell beinhaltet der Bereich „Subjekt“ (physische) Objekte. Personen sind nicht enthalten (da sie komplett über den Bereich Partner abgebildet werden). Um den Begriff „Objekt“ exklusiv für Objekte im Sinne der Objektorientierung verwenden zu können, wurde trotzdem der Begriff „Subjekt“ für den vorliegenden Bereich beibehalten, auch wenn es sich definitiv um (physische) Objekte handelt. Es kann sein, daß man Beziehungen zwischen Subjekten und Partnern abbilden muss. Dies gelingt über die Rolle. Es handelt sich gewissermaßen um einen Spezialfall der Rollennutzung. Der Umgang mit der Rolle ist analog zu der Vorgehensweise in Vertrag und in Schaden/Leistung.

© GDV 2001

25

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

Für die Verknüpfung des Subjekts mit der Außenwelt (über die Rolle) ist eine gewisse Analogie zum „Partner“ zu beobachten. Abhängig davon, für welche Sparte die Komponente Subjekt eingesetzt werden soll, ist sie von größerer oder geringerer Bedeutung. Für die Unternehmen, welche eher komplexe Subjektstrukturen verwalten, ist (analog zu „Partner“) ein Dublettenhandling denkbar. Hierzu könnte man die gleiche Strategie verwenden wie bei „Partner“. Ein Dublettenhandling ist hier allerdings nicht vorgesehen. Die Differenzierung der Subjekttypen, insbesondere in Abhängigkeit der zu bedienenden Sparten, ließe sich über entsprechende Subklassen zu „Subjekt“ erreichen. Diese sind hier nicht vorgesehen.

3.4.2.2. Use-Case-Modell VAA Final Edition Es existiert ein Use-Case-Modell zum Bereich Subjekt. Die enthaltenen Use Cases sind solche, die eher einen Dialog als einen Prozessablauf abbilden.

3.4.2.3. Klassen-Modell VAA Final Edition Die Klassenstruktur im Bereich Subjekt hat sich im Vergleich zu VAA 2.0 (Edition 1999) nicht verändert. Die Operationen der einzelnen Klassen sind im Vergleich zu VAA 2.0 stärker kompaktifiziert worden, d. h. Details (etwa auf „get“- oder „set“-Ebene) wurden in allgemeineren Operationen gekapselt.

3.4.2.4. Anwendungskomponenten VAA Final Edition Für die Services der Anwendungskomponente dienen als Quelle die (öffentlichen) Methoden aus dem Bereich „Subjekt“ im Objektmodell. Das sind im wesentlichen die Methoden der EBO-Klassen. Weitere Funktionalität wird durch den Subjekt-Manager zur Verfügung gestellt (Suchen, Erzeugen). Die Granularität der Services ist eher grob. Einzelne Attribute werden über Argumente abgerufen/gesetzt. Wo allgemeingültig (sparten- und VU-unabhängig) Attribute genannt werden können, geschieht dies. Insbesondere aber risiko- bzw. produktabhängige Partnereigenschaften werden nicht explizit abgebildet (sondern generisch produktabhängig zur Laufzeit erzeugt; siehe Bereich „Produkt“). Es existiert im Bereich „Subjekt“ eine Anwendungskomponente („Subjekt“). Diese Anwendungskomponente unterliegt den gleichen Abhängigkeiten zu „Kommunikation“ und „Rolle“ wie die Anwendungskomponente „Partner“ (siehe Bereich „Partner“).

3.4.2.5. Prozesskomponenten VAA Final Edition Die gefundenen Use Cases führen zu einer Prozess-Komponente („Subjektverwaltung“).

3.4.2.6. Vergleich mit anderen Modellen Die Funktionalität der AWK Subjekt entspricht in den wesentlichen Teilen der Funktionalität der IAA-Komponente "Physical object" (C-Ebene)."

26

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.4.3. Vorgehensweise Produkt 3.4.3.1. Allgemeines Das Produkt, genauer die Produktparametrisierung bzw. –Abstraktion der Versicherungsbranche, hat viele Facetten, in die man blicken kann. Für den einen ist es eine elegante Methode, sein Spartensystem zu parametrisieren, um Aufwände in der Anwendungsentwicklung zu sparen. Für einen anderen ist es ein zentrales Instrument, das Kerngeschäft seines Unternehmens zu beschreiben und die Beschreibung maschinell in der Organisation durchzusetzen. Ein dritter faßt es als Hauptordnung auf, um seine Legacy-Systeme zu redesignen und zu synchronisieren, damit er spartenübergreifende oder strukturinvertierende Ansätze verfolgen kann, die aus Konzepten wie z.B. CRM oder eBusiness resultieren (Privatkunde statt Lebensversicherungskunde, Haushalt statt VN). Produkte sind natürlich Dinge, die man kaufen kann, genauer zu denen man einen Vertrag abschließen kann. Produkte im hier vorliegenden Verständnis sind aber auch generell Vorlagen für Geschäftsobjekte der Sachbearbeitung bzw. der Dienstleistung eines Versicherungsunternehmens, z.B. eine anzulegende Schadenakte zu einer Supersparte oder ein zu bestimmender Provisionsanspruch. Das Produktteam VAA Final Edition stand vor der Herausforderung den klassischen Ansatz, wie er erfolgreich vom Vorgängerteam 1999 mit oVAA 1.0 vorgestellt wurde, mit der Dienstorientierung entsprechend z.B. IAA / Gold von IBM und dem generischen Produktansatz abzugleichen und zu integrieren. Konsequenterweise finden sich drei Modelle bzw. Ansätze in der VAA Final Edition zu dem Thema Produkt wieder: a) Produkt – klassisch: Ein Extrakt, der die Ergebnisse aus oVAA 1.0 beinhaltet b) Produkt – fachlich: Eine nahezu vollständige Aufzählung aller Arbeiten, die an einem Produktentwicklerarbeitsplatz auftreten c) Produkt – generisch: Eine Blaupause für ein Produktverwaltungssystem, das spezifisch für die Abbildung der Informationsprodukte der Versicherungsbranche ist, aber nicht für einzelne existierende oder noch zukünftig einzuführende Produkte.

3.4.3.2. Use-Case-Modell VAA Final Edition a) Produkt – klassisch: Dieser Extrakt aus dem Innovator-Modell der oVAA 1.0 (Use-Cases aus dem VAA Use-Case Modell) enthält die übergreifende Fachlichkeit bezüglich des Lebenszyklus eines Produktes bzw. des Prozesses seiner Entwicklung und Pflege. Die Use-Cases der Produktbereitstellung im Tagesgeschäft sind überwiegend prozedural zerlegt, was dem tayloristischen Ansatz der Epoche entspricht, in dem sich dieses Konzept bewährt hat. b) Produkt – fachlich: Ein Schwerpunkt dieser Use-Cases ist die Trennung der Verantwortlichkeit in der Produktentwicklung, die eine Voraussetzung für einen integrierten Produktentwicklungsprozeß im Versicherungsunternehmen ist. © GDV 2001

27

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

Die spezifische Verantwortung wird von den Aktoren bzw. Rollen: BO-Mitarbeiter, Darlehnsproduktentwickler, Fondsgeber, Gesetzgeber, Gewinnverbandverwalter, Leistungsproduktentwickler, Produktadministrator, Produktpreisentwickler, Provisionsproduktentwickler, Textbausteinverwalter, Verband, Verkaufsproduktentwickler wahrgenommen. Hinter jedem Aktor steht eine Rolle, die ein spezifisches, organisatorisches Interesse wahrnimmt. Manchmal haben gleich mehrere Rollen Einfluß auf die gleiche Produktbeschreibungsgröße, die in verschiedenen organisatorischen Interessensphären liegen (siehe hierzu auch den Abschnitt Prozesskomponenten VAA Final Edition 3.4.3.5 b). Beim Abgleich der VAA-Use-Cases mit den Business-Component-Services von IAA / Gold zeigte sich ein hoher Grad an Übereinstimmung bezüglich des gemeinsamen Verständnisses der Fachlichkeit der konkreten Produktentwicklung, so daß in der Kommentierung der Use-Cases die entsprechenden Services zugeordnet werden konnten. c) Produkt – generisch: Die Use-Cases dieses Ansatzes beschreiben die immer wiederkehrenden strukturell gleichen Aufgaben der Produktbeschreibung: Begriffe definieren, Kontexte setzen, Produktteile zusammenzusetzen zu komplexeren Produkten, Ergänzung der Produkte durch spezifische Operationen (z.B. Berechnungen oder Prüfungen) und die Beschreibung der Produktauswahl, unter welchen Bedingungen (Vorgaben, operative Ausprägungen) eine Produktbeschreibung zutreffend ist.

3.4.3.3. Klassen-Modell VAA Final Edition a) Produkt – klassisch: Das Objektmodell enthält das Fachmodell zur derzeit typischen Strukturierung und Abildung von Produkten. Neben der Komposition der Deckung und des abstrakten bzw. des Verkaufsproduktes ist hier die Analogie zwischen Produkt und Vertrag dargestellt. b) Produkt – fachlich: Hierzu ist kein Klassenmodell angelegt worden, da für diesen Ansatz die reine Anwendersicht auf den Produktentwickler-Arbeitsplatz eingenommen worden ist. Für diese Sicht ist die interne Abbildung der Produkte nicht relevant. c) Produkt – generisch: Beispiel-OM-Diagramme zeigen die Evolution von einer statischen Komposition, die aus dem Anwendungsdatenmodell importiert wird, über eine dynamische Komposition, die über die generische Komposition geleistet wird, bis zur Produkt-Komposition, die auch in Substrukturen noch Verzweigungen gemäß Produkt-Auswahllogik möglich macht. Schlüssel für dieses Konzept ist, daß die zu verwendenden Klassen der zu integrierenden Systeme die Schnittstellenklasse (Interface) "Zusammensetzbares Objekt" implementieren, also ihr Protokoll ergänzen, anstelle einer Typisierung über eine hierarchischen Vererbungsbeziehung. Diese so konfektionierten Klassen sind der Produktverwaltung zugänglich und werden im Rahmen von Fabrik-Methoden zur Produktbereitstellung der Geschäftsobjekte genutzt. Über diesen Mechanismus können auch nicht objektorientierte Systeme angebunden werden, was das Potential der Kombinierbarkeit von Komponenten wesentlich erweitert. 28

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.4.3.4. Anwendungskomponenten VAA Final Edition Siehe hierzu den nächsten Abschnitt, in dem die Unterscheidung zwischen Anwendungs- und Prozesskomponenten getroffen wurde.

3.4.3.5. Prozesskomponenten VAA Final Edition a) Produkt – klassisch: In diesem Ansatz sind als Komponenten Parameter- und Tabellensysteme, Formel- und Prüfungsmodule und die eng mit diesen zusammenarbeitenden Anwendungssysteme erkennbar. Wiederverwendung ist innerhalb der Anwendungsarchitektur eines Versicherungsunternehmens möglich, die Trennung zwischen Anwendungs- und Prozeßkomponenten ist nicht immer transparent, da oft Produkt in den entsprechenden Komponenten „implementiert“ wird. b) Produkt – fachlich: Dominant ist hier das Produktserver-Entwurfsmuster: die sorgfältige Trennung zwischen den Komponenten Produktdefinition (Prozeßkomponente) und Produktbereitstellung (Anwendungskomponente). Quer dazu bietet sich eine weitere Komponentenschneidung insbesondere in der Produktbereitstellung entsprechend der Verantwortlichkeit der Produktdefinition an, wie sich diese aus den organisatorischen Interessensphären ergibt: •

Produktadministration



Produktinitialisierungs und -prüfungsverwaltung



Darlehnsproduktverwaltung



Textbausteine



Verwaltung externer Einflußfaktoren



Produktregelverwaltung für Geschäftsprozesse



Gewinnverbandsverwaltung



Leistungsproduktverwaltung



Produktpreis und –Prämienverwaltung



Verkaufsproduktverwaltung

Auch hier ist Wiederverwendung innerhalb eines Versicherungsunternehmens möglich. c) Produkt – generisch: In diesem Ansatz wurden die Komponenten "Kontext und Begriffe", "Generische Komposition", "Generische Operation", "Produktauswahl" geschnitten. Hauptmotiv für diesen Schnitt war es, auch Teile dieses Konzeptes nutzen zu können, ohne gleich der gesamten Komplexität ausgesetzt zu sein.

© GDV 2001

29

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell



Komponente: „Kontext- und Begriffsverwaltung" ist von verschiedenen Systemen nutzbar, um eine gemeinsame, standardisierte Nomenklatur einzuhalten.



Komponente "generische Komposition" wird auch ohne Tarif- oder Produktkontext benötigt, um Strukturen parametrisiert pflegen zu können.



Komponente "generische Operation" ist das Mittel der Wahl, um eine funktionale Integration heterogener Systeme durchführen zu können bzw. Funktionen zu beschreiben.



Komponente "Produktauswahl" steuert die eigentliche Parametrisierung im Sinne von "Produkt" bei, d.h. Beschreibung und Wiederverwendung von Produktteilung in verschiedenen Produktkonstellationen und –Kontexten.

Alle Komponenten werden in drei "Phasen" gestaltet bzw. eingesetzt: •

Komponentenerstellung: Standards für Entwurf und Implementierung, z.B. Vorgabe zu implementierender Schnittstellenklassen



Prozeßkomponente: Definition und Verwaltung z.B. Bündelung einzelner Produkte zu einem spartenübergreifenden Produkt



Anwendungskomponente: Bereitstellung für operativen Betrieb z.B. Herstellen von Geschäftsobjekten, die in Struktur und Verhalten der Produktdefinition entsprechen.

Wiederverwendung ist in objekt- und komponentenorientierten Anwendungslandschaften übergreifend möglich.

3.4.3.6. Vergleich mit anderen Modellen Siehe hierzu Abschnitt: 3.4.3.2 b)

3.4.4. Vorgehensweise Schaden/Leistung 3.4.4.1. Allgemeines Die Bedeutung des Bereiches „Schaden/Leistung“ für die Leistungsfähigkeit eines Versicherungsunternehmen steigt kontinuierlich mit der sich verschärfenden Konkurrenzsituation, in der sich die meisten Unternehmen zur Zeit befinden. Bei keiner anderen Tätigkeit ist der Kundenkontakt so ausgeprägt, wie bei der Erfüllung der Verpflichtungen, die ein Versicherungsunternehmen in einem Versicherungsvertrag eingeht. Gerade in diesem Fall kann Kundenfreundlichkeit, Nähe, Unterstützung etc. demonstriert werden. Voraussetzung hierfür sind gut ausgebildete, freundliche Mitarbeiter, ausgezeichnete Geschäftsprozesse und vor allem eine sehr gute Unterstützung durch entsprechende DVSysteme. Durch konsequente Umsetzung von bzw. dem kreativen Umgang mit aktivem Schadenmanagement, bzw. Gesundheitsmanagement bei Krankenversicherern, kann eine vertrauensvolle und damit dauerhafte Kundenbindung erreicht werden. 30

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

Das VAA-Schadenkomponentenmodell wird so weit als möglich diesem Anspruch gerecht. Sämtliche Bearbeitungsschritte von der Schadenmeldung über die Schadenanlage bis zur kompletten Leistungsbearbeitung sind vollständig abgebildet. Darüber hinaus wurde in jüngerer Zeit bei einzelnen Versicherungsunternehmen das Thema ‚offensive Schadenbearbeitung‘ an verschiedenen Stellen forciert. Hier wird aus Sicht der Unternehmen noch aktiver der Kunde bzw. Geschädigte unterstützt in Form von Hilfen bei der Schadenminimierung, der Schadenfolgeaktivitäten, sowie der Schadenregulierung. Diese Ansätze sind jedoch derzeit noch sehr rudimentär vorhanden. Deshalb konnten sie im derzeitigen Modell als allgemeingültig und unternehmensübergreifend noch keine Berücksichtigung finden. Es dürfte jedoch gegebenenfalls kein Problem sein, eine Komponente aktive Schadenbearbeitung unternehmensspezifisch zu bauen und mit den anderen Komponenten zu vernetzen.

3.4.4.2. Use-Case-Modell VAA Final Edition Es existiert ein fachlich nahezu vollständiges Use-Case-Modell. Die jeweiligen Sequenzdiagramme sind ebenfalls nahezu vollständig erarbeitet.

3.4.4.3. Klassen-Modell VAA Final Edition Die Klassenstruktur hat sich im Bereich Schaden/Leistung im Vergleich zu VAA 2.0 (Edition 1999) nicht wesentlich verändert. Es sind die Klassen Deckung und Haftung hinzugekommen. Die Anzahl der Methoden hat sich jedoch auf Grund einer anderen Granularität (nicht mehr so fein) reduziert.

3.4.4.4. Anwendungskomponenten VAA Final Edition Für die Services der Anwendungskomponenten dienen als Quelle die (öffentlichen) Methoden aus dem Bereich Schaden/Leistung im Objektmodell. Basis hierfür waren die Sequenzdiagramme. Deshalb sind die Methoden im Modell nachvollziehbar vorhanden. Die Granularität ist im Vergleich zu Phase 1 eher grob. Attribute werden so gut wie nicht gesetzt bzw. abgerufen. Im Bereich Schaden existieren 6 Anwendungskomponenten: •

Schadenereignis



Schadenfall



Deckung/Haftung



Forderung



Leistung



Reserve.

3.4.4.5. Prozesskomponenten VAA Final Edition Die identifizierten 3 ‚Haupt-Use-Cases‘ lassen ad hoc auf 3 Prozesskomponenten schließen: •

Schadenanlagebearbeitung

© GDV 2001

31

Vorgehensweise •

Leistungsbearbeitung



Forderungsbearbeitung.

Das Objektorientierte Fachliche Referenzmodell

Hier handelt es sich jedoch nur um Vorschläge. Es sind auch kleinere Einheiten bzw. andere Kombinationen der Anwendungskomponenten denkbar.

3.4.5. Vorgehensweise Vertrag 3.4.5.1. Allgemeines Das Vertragsteam hatte die Aufgabe, die Review-Ergebnisse zum Vertragsteil der VAA 2.0 Edition 1999 aufzuarbeiten, und einen Komponentenschnitt für den Vertragsbereich zu erstellen. Ziel war es, einen stabilen Komponentenkern mit der Grundfunktionalität einer Versicherung abzubilden. Die Verantwortlichkeiten sollten im Vertragsbereich liegen, die Komponenten wenige und einfache Schnittstellen zur Verfügung stellen. Neue prozedurale Anforderungen an eine Vertragskomponente, wie eCommerce oder CRM (Customer Relationship Management) sollen sich mit den gefunden Komponenten abbilden lassen.4 Hierfür wurden in einem ersten Schritt die Prozesse im Vertragsbereich bestimmt. Hierauf aufbauend wurde das bestehende Use-Case-Modell überarbeitet. Anschließend wurde der Komponentenschnitt durchgeführt und das Klassendiagramm der VAA 2.0 Edition 1999 an den Komponentenschnitt angepasst. Im Bereich Vertrag wurden allgemeine Prozesse skizziert, um die Use-Cases für die weitere Arbeit zu finden. Die Prozesse decken die Bereiche Angebot, Antrag und Vertrag auf einer abstrakten Ebene ab.5 Durch die Abstraktion der Prozesse wurde es möglich, die hieraus gewonnenen Use-Cases wiederzuverwenden und damit die Schnittstelle der Komponenten klein zuhalten. Deutlich wird dieses z.B. an dem Prozess der Vertragsänderung. Der Prozess kann sowohl auf bestehende Verträge, als auch auf Angebote und Anträge angewendet werden. Die abstrakten Prozesse sind in ähnlicher Form in jedem Versicherungsunternehmen vorzufinden.

Folgende Prozesse werden bis zum Ende eines Versicherungsvertrages durchlaufen. Der Kunde fragt wegen einer Versicherung an. Das Versicherungsunternehmen erstellt ihm ein entsprechendes Angebot. Ist der Kunde an dem Angebot interessiert, stellt er einen Antrag auf Abschluss einer Versicherung. Das Versicherungsunternehmen prüft den Antrag, nimmt ihn evtl. an und schließt damit den Versicherungsvertrag mit dem Kunden.

4

Diese Anforderungen sind nicht Schwerpunkt der Arbeit gewesen. Das Vertragsteam geht aber davon aus, daß diese Anforderungen abge-

bildet werden können. 5

Schaden/Leistung wird in einer eigenen Komponente beschrieben.

32

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

9HUVLFKHUXQJV VFKXW] DQIUDJHQ

Vorgehensweise

$QWUDJ VWHOOHQ

.XQGH

$QJHERW HUVWHOOHQ

$QWUDJV HUIDVVXQJ GXUFKIKUHQ

9HUWUDJ HUVWHOOHQ

98 Abbildung 7: Grobprozess - Vertragsabschluß

Während der Laufzeit des Vertrages kann der Kunde Fragen zum Vertrag haben oder Änderungen an ihm vornehmen bzw. ihn kündigen.

9HUWUDJV DXVNXQIW HLQKROHQ .XQGH

9HUWUDJV DXVNXQIW HUWHLOHQ 98 Abbildung 8: Grobprozess - Vertragsauskunft

© GDV 2001

33

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

9HUWUDJV lQGHUXQJ DQIUDJHQ

$QWUDJ VWHOOHQ

.XQGH

$QJHERW HUVWHOOHQ

9HUVLFKHUXQJV YHUWUDJ lQGHUQ

98 Abbildung 9: Grobprozess - Vertragsänderung

3.4.5.2. Use-Case-Modell VAA Final Edition Es existiert ein Use-Case-Modell zum Bereich Vertrag. Die Use-Cases geben die wichtigste Aufgaben im Verantwortungsbereich der Vertragskomponenten wieder. Sie decken den Lebenszyklus eines Versicherungsvertrags vom Angebot bis zur Vertragsbearbeitung inkl. der Kündigung ab. Die Schadens- und Leistungsbearbeitung wird durch die Schadenskomponenten behandelt.

3.4.5.3. Klassenmodell VAA Final Edition Die Klassenstruktur im Bereich Vertrag hat sich im Vergleich zu VAA 2.0 (Edition 1999) nicht wesentlich verändert. Es wurden einige Vererbungen und Relationen überarbeitet. Außerdem wurden Klassen aus dem Klassendiagramm entfernt, welche durch den Komponentenschnitt nicht mehr in die Verantwortlichkeit der Vertragskomponenten gehören.

3.4.5.4. Anwendungskomponente VAA Final Edition Es existieren im Bereich Vertrag die drei Anwendungskomponenten: Angebot Antrag Vertrag Für die Services der Anwendungskomponente werden die Methoden der EBO-Klassen aktualisieren und bereitstellen genutzt. Die Granularität der Services ist eher grob. Einzelne Attribute werden über Argumente abgerufen/gesetzt. Weitere Funktionalität (suchen, erzeugen) wird durch den VertragsManager zur Verfügung gestellt. Zusätzlich enthält die Schnittstelle den Service starteOpertation um Funktionalität auszuführen, die durch Produkt vorgegeben wurde. Die fachliche Konsistenz wird über die Prozesskomponente sichergestellt.

34

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

Abbildung 10: Anwendungskomponenten im Vertragsbereich

$QJHERW (%2

$QJHERW

$QWUDJ (%2

$QWUDJ

9HUWUDJ (%2

9HUWUDJ

© GDV 2001

‡ EHUHLWVWHOOHQ ‡ DNWXDOLVLHUHQ ‡ VXFKHQ ‡ HU]HXJHQ ‡ VWDUWH2SHUDWLRQ

‡ EHUHLWVWHOOHQ ‡ DNWXDOLVLHUHQ ‡ VXFKHQ ‡ HU]HXJHQ ‡ VWDUWH2SHUDWLRQ

‡ EHUHLWVWHOOHQ ‡ DNWXDOLVLHUHQ ‡ VXFKHQ ‡ HU]HXJHQ ‡ VWDUWH2SHUDWLRQ

35

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

3.4.5.5. Prozesskomponente VAA Final Edition Es existiert im Bereich Vertrag die Prozesskomponente: Versicherungsverhältnisverwaltung6 Die gefundenen Use-Cases wurden in der Prozesskomponente Versicherungsverhältnisverwaltung zusammengefasst. Die Namen der Use-Cases bilden dabei die Schnittstelle der Komponente. Die Prozsskomponente beinhaltet die drei Vertrags-Anwendungskomponenten. Die Prozesskomponente stellt den Anwendungskomponenten die fachlichen Prüfungen zur Verfügung. D.h. damit der konsistente Zustand der Anwendungskomponente zu jeder Zeit, gewährleistet werden kann, darf nur über die Prozesskomponente auf diese zugegriffen werden.

9HUVLFKHUXQJVYHUKlOWQLVYHUZDOWXQJ ‡ $QJHERWHHUVWHOOHQ ‡ $QWUDJVHUIDVVXQJGXUFKIKUHQ ‡ *HVFKlIWVYRUIDOOSUIHQ ‡ 9HUVLFKHUXQJVYHUKlOWQLV]X3DUWQHUVXFKHQ ‡ 9HUVLFKHUXQJVYHUKlOWQLV]X6XEMHNWVXFKHQ ‡ 9HUVLFKHUXQJVYHUWUDJlQGHUQ$XVO|VHULVW.XQGH ‡ 9HUVLFKHUXQJVYHUWUDJlQGHUQ ‡ $QJHERWVDXVNXQIWHUWHLOHQ ‡ $QWUDJVDXVNXQIWHUWHLOHQ ‡ 9HUWUDJVDXVNXQIWHUWHLOHQ ‡ 9HUWUDJVUHOHYDQ]UHJLVWULHUHQ ‡ 91.QGLJXQJEHDUEHLWHQ ‡ 98.QGLJXQJEHDUEHLWHQ ‡ :LGHUUXI:LGHUVSUXFK5FNWULWWEHDUEHLWHQ

3%2

$QJHERWHUVWHOOHQ

3%2

9HUWUDJVDXVNXQIWHUWHLOHQ

3%2

9HUVLFKHUXQJVYHUKlOWQLVlQGHUQ

3%2

:LGHUUXI:LGHUVSUXFK5FNWULWW EHDUEHLWHQ



$QJHERW

$QWUDJ

9HUWUDJ

Abbildung 11: Prozesskomponente Versicherungsverhältnisverwaltung

6

Der Begriff Versicherungsverhältnis faßt die Begriffe Angebot, Antrag und Vertrag zusammen. Im Klassenmodell ist die Klasse Versiche-

rungsverhältnis die Superklasse der Klassen Angebot, Antrag und Vertrag.

36

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.4.6. Vorgehensweise Kontokorrent 3.4.6.1. Allgemeines Das objektorientierte Referenzmodell basiert auf der fachlichen Beschreibung des prozeduralen Zentralkontokorrent (ZKK). Die Beschreibungen wurden z. T. übernommen. In der Vergangenheit wurde der kunden- bzw. gesellschaftsübergreifenden Verwaltung und Abwicklung von Forderungen (z. B. Beiträge) und Verbindlichkeiten (z.B. Provisionen) in den Versicherungsunternehmen nur geringe Bedeutung beigemessen. Dabei entstehen am Ende fast aller Geschäftsprozesse (ca. 80% bis 90 %) Forderungen bzw. Verbindlichkeiten. Demzufolge existieren zur Zeit für die Abwicklung des Inkassos und der Provisionen in vielen Unternehmen mehrere Kontokorrent- oder Inkasso-/Vergütungssysteme nebeneinander, welche keinen oder nur einen indirekten Bezug zueinander haben. Heutzutage steht der Kunde für die Produkte und damit auch für die Systeme immer stärker im Mittelpunkt. Vom Markt werden immer komplexere Produkte gefordert, welche die Rundum-Abdeckung eines Risikos zu einem Preis bieten. Diese Produkte stellen dabei hohe Anforderungen an die technische Verwaltung. Dies gilt vor allem für die Kontokorrent- und Inkassosysteme, welche die zumeist sparten- und gesellschaftsübergreifende Abwicklung sicherstellen sollen. Die zunehmende Verschmelzung der Weltwirtschaft wird sich auch auf die Produktlandschaft der Versicherungsunternehmen auswirken. Die Unternehmen werden sich darauf einstellen müssen, Verträge in fremder Währung in Verwaltung, Inkasso und Abrechnung verstärkt zu berücksichtigen. Auch wenn der EURO den stärksten Druck mildern wird, ist es unumgänglich, die Systeme umfassend mehrwährungsfähig zu organisieren. Es wird sich zeigen, ob speziell die in den Unternehmen vorhandenen Kontokorrent-, Inkasso- und Vergütungsabrechnungssysteme die notwendige Anpassungsfähigkeit besitzen. Auch die neuen Techniken (Internet, Elektronischer Antrag etc.) werden sich auf die Verwaltung von Forderungen und Verbindlichkeiten auswirken. Nur wenn die Schnittstellen und die Verteilung der Aufgaben in den Systemen sauber definiert sind, können diese neuen Medien sauber in die Geschäftsvorfälle integriert werden. Das Zentralkontokorrent wird diesen Ansprüchen gerecht. Es übernimmt für die angeschlossenen Liefersysteme - unter Beachtung der jeweiligen Besonderheiten - alle buchhalterischen Funktionen, bis hin zur Bedienung der Hauptbuchhaltung. Des weiteren stellt das Zentralkontokorrent alle erforderlichen Dienste und Anwendungen für die Verfolgung und Abwicklung der übergebenen Werte zur Verfügung.

3.4.6.2. Use-Case-Modell VAA Final Edition Es existiert ein aus dem prozeduralen VAA 2.0 (Edition 1999) abgeleitetes Use-Case-Modell.

3.4.6.3. Klassenmodell VAA Final Edition Es existiert ein aus dem prozeduralen VAA 2.0 (Edition 1999) abgeleitetes Klassenmodell.

© GDV 2001

37

Vorgehensweise

Das Objektorientierte Fachliche Referenzmodell

3.4.6.4. Anwendungskomponenten Im Arbeitsgebiet Kontokorrent wurden acht Anwendungskomponenten spezifiziert: •

Buchungskern



Inkasso



Exkasso



Provision



AD-Abrechnung



Dienststellenbuchhaltung



Hauptbuch



ZK-Auftrag.

Die Ableitung der Komponenten erfolgte nicht über das Klassenmodell und die Identifikation der EBO’s, sondern eher motiviert aus dem Use-Case-Modell.

3.4.6.5. Prozesskomponenten Prozesskomponenten wurden vom Teilteam keine festgelegt.

3.4.7. Vorgehensweise Provision 3.4.7.1. Allgemeines Gerade im Bereich „Provision“ sind im Versicherungsmarkt zunehmende Änderungen festzustellen. Die Arten und Ereignisse, welche zu einer Provisionszahlung führen können, werden immer variabler. Die Auslöser für Provisionszahlungen können aus Systemen kommen, zu welchen vorher keine Schnittstelle implementiert und gepflegt werden musste. Gerade neuere Vertriebswege, wie z.B. Direktvertrieb via Internet, vergrößern die Menge der möglichen Provisionsempfänger, der zu verwaltenden Beziehungen zu diesen, der festzulegenden und zu verwaltenden Konditionen etc. Für neue Vertriebswege Insellösungen zu schaffen, ist sicher nur eine Notlösung: schließlich können Beziehungen zwischen unterschiedlichen Provisionsarten bei unterschiedlichen Vertriebswegen bestehen. Zudem beschränken sich moderne Versicherungsunternehmen nicht weiter auf einen oder wenige Vertriebswege, sondern versuchen, eine gesunde Mischung aus den sich bietenden Möglichkeiten auszuwählen. Die zu beachtenden Randbedingungen werden durch die vorhandenen Provisionsverwaltungssysteme vorgegeben. Ein neu zu erstellendes System muss daher auf einer eher abstrakten Ebene beschrieben und realisiert werden, um das Versicherungsunternehmen nicht einzuengen. VAA-Provision stellt einen Framework bereit, um diesen Anforderungen an Provisionssystemen gerecht zu werden. Es stellt eine einfache Strukturierung dar, welche kompatibel zu allen VAAKomponenten und allen legaten Systemen in die DV-Architektur integriert werden kann. Die identifizierten Komponenten und die beteiligten Entitäten und deren Services sind mit entsprechenden Beispielen beschrieben. 38

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Vorgehensweise

3.4.7.2. Use-Case-Modell VAA Final Edition Es existiert ein Use-Case-Modell auf Basis des prozeduralen VAA-Papiers Provision.

3.4.7.3. Klassenmodell VAA Final Edition Es existiert ein Klassenmodell, das methodisch durch die Erstellung von Sequenzdiagrammen ermittelt wurde.

3.4.7.4. Anwendungskomponenten Im Bereich Provision wurden zwei Anwendungskomponenten identifiziert: •

Vertriebsresultat



Vertriebseinheit.

Die Begründung für diesen Schnitt ist folgende: Die Vertriebseinheits-Verwaltung kann für sich alleine stehen. Diese Komponente bildet die bestehende Aussendienst/Vertriebsstruktur mit allen Besonderheiten und allen vertraglichen Regelungen ab und ist ein statisches Gebilde. Der Provisionsbaustein ist abhängig von den Strukturen der Vertriebseinheits-Verwaltung und kann nicht allein betrachtet werden. Das Formelwerk ist abhängig von den Beziehungen und Strukturen, wie sie in der Vertriebseinheits-Verwaltung gehalten werden. Der Provisionsbaustein verarbeitet dynamisch Vorgänge, konkret verarbeitet er Vertriebsresultate über Bewertungen zu Provisionsansprüchen, so sind auch diese Klassen voneinander abhängig (und eng zusammengehörig): ohne Resultat keine Bewertung, ohne Bewertung kein Provisionsanspruch. Auch die Klassen der Vertriebseinheits-Verwaltung sind voneinander abhängig: auf den Vertriebseinheiten bauen alle drei anderen Klassen auf. Die Vertriebseinheits-Verträge bestimmen das Verhältnis der VE´en zum VU, und die Konditionen sind eigentlich nur eine Unterklasse der Verträge. Die Vertriebseinheits-Beziehungen bestimmen das Verhältnis der Vertriebseinheiten untereinander.

3.4.7.5. Prozesskomponenten Im Bereich Provision wurden fünf Prozesskomponenten festgelegt: •

Bankverbindung für Vertriebseinheits-Vertrag bereitstellen



Provisionsansprüche ermitteln



Vertriebseinheits-Konditionen einrichten/pflegen



Vertriebseinheits-Vertrag abschließen



Vorgang bewerten.

© GDV 2001

39

Ergebnisse

Das Objektorientierte Fachliche Referenzmodell

4. Ergebnisse 4.1. Fachliche Design-Patterns Während der Analysearbeit hat sich herausgestellt, dass es in einigen Arbeitsgebieten gleichartige Sachverhalte gibt. Beispielsweise beinhaltet das „Suchen“ gleichartige Funktionalität, auch wenn unterschiedliche fachliche Objekte zugrunde liegen. Diese Gleichartigkeit führte dazu, diese Aspekte als fachliche Design-Patterns festzulegen.

4.1.1. Objekt suchen Am Beispiel des „Partner suchen“ wird gezeigt, wie mit den unterschiedlichen Suchbedürfnissen umgegangen wird. 1. Eine Suche ohne Dialog: Wird eine „Hintergrundsuche“ ohne Dialog gestartet, so wird dieses über den (direkten) Aufruf des Suchdienstes abgewickelt. 2. Eine Suche mit kontextunabhängigem Dialog: Unter kontextunabhängigem Dialog ist eine Suche mit Kriterien zu verstehen, die nur am gesuchten Objekt Partner hängen und nicht am Prozesskontext, in welchem sich die Suche abspielt (wie etwa „Schadenpartner suchen“). Diese Suche wird über das PBO „Partner suchen“ abgewickelt, d. h. über einen Service, der über einen eigenen (kontextunabhängigen) Dialog verfügt. 3. Eine Suche mit kontextabhängigem Dialog: Hierunter ist das entsprechende Gegenstück zur kontextunabhängigen Suche zu verstehen. Bei dieser Art der Suche ist der Prozesskontext mit zu berücksichtigen. Beispielsweise wird ein Schadenpartner sowohl mit Partnereigenschaften (Name, Vorname) als auch mit Schadendaten (Schadentag) gesucht. Diese Suche wird in der Verantwortung desjenigen PBO’s durchgeführt (und auch der entsprechende Dialog gesteuert), das den Kontext definiert (z. B. „Schaden aufnehmen“), d. h. dies ist eine Fähigkeit, die sich entweder als Service der entsprechenden Prozesskomponente darstellt oder nur innerhalb der Prozesskomponente gefordert wird (und somit nicht als Service in Erscheinung tritt). Diese Art der Suche bedient sich der unter 1. beschriebenen Suche ohne Dialog, ruft also den Service einer Anwendungskomponente auf. Gelegentlich tritt in einigen Modellteilen auch „Objekt ermitteln“ auf. Das „Ermitteln“ ist synonym zum „Suchen“ zu sehen.

4.1.2. Objekt anzeigen Am Beispiel des „Partner anzeigen“ wird gezeigt, wie mit den unterschiedlichen Anzeigevarianten umgegangen wird. 1. Eine „Anzeige“ ohne Dialog. Das macht bei der eigentlichen Anzeige keinen Sinn; das Analogon zu Punkt 1. bei der Objektsuche ist hier das Bereitstellen von Attributinhalten. Dies wird über einen entsprechenden Service („Partner bereitstellen“) der Anwendungskomponente abgewickelt. 2. Eine Anzeige mit kontextunabhängigem Dialog: Unter kontextunabhängigem Dialog ist eine Anzeige von Attributen zu verstehen, die nur das gewünschte Objekt Partner betreffen. Diese Anzei-

40

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Ergebnisse

ge wird über das PBO „Partner anzeigen“ abgewickelt, d. h. über einen Service, der über einen eigenen (kontextunabhängigen) Dialog verfügt. 3. Eine Anzeige mit kontextabhängigem Dialog. Bei dieser Art der Anzeige ist der Prozesskontext mit zu berücksichtigen. Beispielsweise wird ein Vertragspartner sowohl mit Partnereigenschaften (Name, Vorname) als auch mit Vertragsdaten (Art des Vertrages, Vertragsbeginn) gesucht. Diese Anzeige wird in der Verantwortung desjenigen PBO’s durchgeführt (und auch der entsprechende Dialog gesteuert), das den Kontext definiert (z. B. „Vertrag verwalten“), d. h. dies ist eine Fähigkeit, die sich entweder als Service der entsprechenden Prozesskomponente darstellt oder nur innerhalb der Prozesskomponente gefordert wird (und somit nicht als Service in Erscheinung tritt). Diese Art der Anzeige bedient sich der unter Punkt 1 beschriebenen „Anzeige“ ohne Dialog, ruft also den Service einer Anwendungskomponente auf.

4.1.3. Objekt ändern Am Beispiel des „Partner ändern“ wird gezeigt, wie mit den unterschiedlichen Änderungsvarianten umgegangen wird. 1. Eine „Änderung“ ohne Dialog. Das Analogon zu Punkt 1. bei der Objektsuche ist hier das Aktualisieren von Attributinhalten. Dies wird über einen entsprechenden Service („Partner aktualisieren“) der Anwendungskomponente abgewickelt. 2. Es gilt die Entsprechung des bei „Objekt anzeigen“ unter Punkt 2 Ausgeführten. Sieht man von technischen Details ab, sind die Benutzeroberflächen von „...ändern“ und „...anzeigen“ identisch. Abweichungen gibt es insbesondere aber bei Partner, wo jedes Ändern vor dem Wirksamwerden eine Dublettensuche anstößt. 3. Es gilt die Entsprechung des bei „Objekt anzeigen“ unter Punkt 3 Ausgeführten. Das Ändern bzw. Aktualisieren von Objekten beinhaltet neben der naheliegenden Funktionalität zwei Spezialfälle: -

Das erstmalige Anlegen des (leeren) Objekts

-

Die Referenz auf andere Objekte (Aufruf mit Parameter: „Objekt, das zu referenzieren ist“)

4.2. Status Dieses Projekt stellt die zweite und letzte Iteration auf dem Weg zu einem fachlichen Komponentenmodell dar. Die wesentlichen Ergebnisse dieses Projektes (bis 31.12.2000) umfassen •

eine Komponentenarchitektur (Metamodell)



ca. 35 Komponenten



ein ca. 90 Klassen umfassendes Fachmodell, bestehend aus acht Teilbereichen mit Referenzcharakter



ein Use-Case-Modell zur Beschreibung bestehend aus ca. 65 Use-Cases

• ca. 30 Sequenzdiagramme Fachliche Analyse- bzw. Design-Patterns

© GDV 2001

41

Ergebnisse

Das Objektorientierte Fachliche Referenzmodell

4.3. Darstellung der Ergebnistypen Das Use Case Modell sowie das Klassenmodell wird in verschiedenen Formen zur Verfügung gestellt: 1. Innovator Modell 2. HTML Mit dem Innovator-Modell hat man die Möglichkeit, das Modell in der Form zu betrachten, wie es von dem Team ausgearbeitet wurde. Um die Verfügbarkeit des Modells zur erweitern, wurden sowohl eine Innovator- als auch eine HTML-Version erzeugt. Für die HTML-Version ist lediglich ein Java-tauglicher Internetbrowser (Internet Explorer 4.01, Netscape 4.08 oder ähnliche) erforderlich. Hierbei sind die Bearbeitungsmöglichkeiten eingeschränkt. Selbstverständlich werden die Ergebnisse auch in gedruckter Form veröffentlicht.

42

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Beispiele und Erläuterungen

5. Beispiele und Erläuterungen An dem folgenden Beispiel wird erläutert, wie die einzelnen Komponenten zusammenspielen. Es wird der Abschluss einer Hausratsversicherung beschrieben. In drei Iterationen wird das fachliche Beispiel immer feiner strukturiert und abstrahiert, bis die Ebene der Komponenten erreicht ist.

5.1. Anwendungsbeispiel Herr Dr. Helmut Schmitt möchte gerne eine Versicherung für sein Anwesen (14.500 qm Grundstück, 350 qm Wohnfläche, exklusiv eingerichtet) an der Elbe abschließen. Gleichzeitig ist er an der Versicherung seiner Segeljacht („Masuren 9005“, 250 qm Segelfläche, 13 m Länge) interessiert. Aus der Liste der möglichen Produkte passt für ihn am Besten das Produkt „VAA - Schöner Wohnen“. „VAA – Schöner Wohnen“ bietet eine Versicherung für gehobene Ansprüche und umfasst eine Versicherungssumme von 2400 EUR je qm. Die Wertsachen in Wochenendhäusern und Autos sind mitversichert. Die Versicherung der Segeljachten kann abgeschlossen werden. Im Angebot wird Hr. Schmitt als Versicherungsnehmer aufgenommen. Hr. Schmitt ist schon als Partner des VU’s bekannt. Seine Daten können aus dem System übernommen werden. Als versicherte Subjekte werden sein Anwesen und die Segeljacht mit ihren beitragsrelevanten Daten erfasst. Außerdem wird dokumentiert, dass Hr. Schmitt Skipper der Segeljacht ist. Aus den Daten wird der monatliche Beitrag berechnet und Hrn. Schmitt mitgeteilt. Hr. Schmitt prüft das Angebot, entscheidet sich dieses anzunehmen und einen Antrag zu stellen. Während der Antragserstellung wird eine Deckungszusage erteilt. Es werden Sicherungsdaten z.B. Schließsysteme und Einbruchmeldeanlagen für die Jacht oder ähnliche aufgenommen. Herr Schmitt zahlt nicht den Beitrag. Dieses wird sein Geschäftspartner Hr. Schröder übernehmen. Aufgrund des hohen Wertes der Segeljacht wird ein Gutachten eingefordert. Nach Prüfung der Antragsdaten wird der Antrag durch das VU angenommen. Nun wird eine Police erstellt und Folgeaktivitäten veranlasst. z.B. muss die Deckungszusage gekündigt, Vermittlerprovision berechnet und Inkasso über einen neuen Vertrag informiert werden.

5.2. Iteration I. 1. Angebot erstellen Herr Dr. Helmut Schmitt möchte gerne eine Versicherung für sein Hausrat abschließen. Ihm wird ein Angebot ausgestellt. 1. Produkt aus der Menge der vorhandene Produkte aussuchen 2. Angebotsdaten erfassen 3. Beiträge und Versicherungssummen ausrechnen und Angebotsschreiben erstellen 2. Antrag erstellen Der Dr. Helmut Schmitt hat sich für ein Angebot entschieden und möchte ein Vertrag abschließen. 1. Daten aus dem Angebot in das Antrag übernehmen und fehlende Daten erfassen. 2. Deckungszusage erteilen 3. Fehlende Daten der/des Partner(s) erfassen 4. Fehlende Daten der/des Subjekte(s) erfassen 5. Antragsdaten prüfen © GDV 2001

43

Beispiele und Erläuterungen

Das Objektorientierte Fachliche Referenzmodell

3. Vertrag erstellen Die Prüfung des Antrages ist positiv verlaufen. Dem Kunde wird eine Police erstellt. 6. Daten aus dem Antrag in den Vertrag übernehmen. 7. Police erstellen und dem Kunde aushändigen. 8. Deckungszusage kündigen, Provision berechnen und Inkasso informieren.

5.3. Iteration II. 1. Angebot erstellen 9. Produkt aus der Menge der vorhandene Produkte aussuchen 1. Die Produktkomponente stellt eine Liste der vorhanden Produkte 1. Produkt suchen Es wird eine Auswahl von Produkten zur Hausratversicherung bei der Produktkomponente angefordert. Aus der Ergebnis Liste wird das Produkt „VAA - Schöner Wohnen“ ausgesucht. 2. Die Produktkomponente stellt die passenden Strukturen (Angebot, Partnerrolle(n), Subjektrolle(n) und...) bereit. 2. Produktdefiniertes Objekt bereitstellen (PK – Produkt) “VAA – Schöner Wohnen“ bietet eine Versicherung für gehobene Ansprüche und umfaßt eine Versicherungssumme von 2400 MHTP'LH:HUWVDFKHQLQ:RFKHQHQGKlXVHUQ und Autos sind mitversichert. Die Versicherung der Segeljachten kann abgeschlossen werden. Die Produktkomponente stellt eine Angebotsstruktur bereit. Sie bietet z.B. die Eingabe der Segelfläche. 10. Angebotsdaten erfassen 3. aktualisieren Alle, für die Berechnung des Beitrages, notwendigen Daten werden erfasst, z.B. die Segelfläche von 250qm. Zusätzlich werden auch die Daten des Kunden erfasst. 3. Partner Suchen (PK – Partner) Es wird eine Auswahl von Partnern mit Namen Schmitt bei der Partner Komponente angefordert. Aus der Ergebnisliste wird der Herr Schmitt aus Hamburg ausgewählt. 4. Rolle aktualisieren Der Herr Schmitt wird in der Rolle VN dem Angebot zugeordnet (aktualisieren AWK_Rolle) 5. Subjekt Suchen (PK – Subjekt) es wurde kein passendes Subjekt im Bestand gefunden Es wird eine Auswahl von Subjekten mit entsprechenden Eigenschaften z.B. Segelfläche 250qm bei der Subjekt Komponente angefordert. Es wird kein passendes Subjekt gefunden. 6. Subjekt ändern (PK – Subjekt) Es wird ein neues Objekt von der PK - Subjekt erzeugt. Hierzu wird analog zur Erzeugung des Angebotes der Service Produktdefiniertes Objekt bereitstellen aufgerufen. 7. Rolle aktualisieren Der Herr Schmitt wird in der Rolle Skipper dem Subjekt zugeordnet (aktualisieren AWK_Rolle) 44

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Beispiele und Erläuterungen

11. Beiträge und Versicherungssummen ausrechnen und Angebotsschreiben erstellen. Die Berechnung versicherungstechnischer und sonstiger Angebotswerte wird veranlasst .Ein Beitrag, bei monatlicher Zahlweise, von 163,00 ZXUGHHUPLttelt. starteOperation(MonatlicherBeitragBerechnen) Das Angebot wird ausgedruckt: UC - Geschäftsvorfall dokumentieren [für Angebote erstellen] 2. Antrag erstellen Herr Dr. Helmut Schmitt hat sich für das Angebot entschieden und möchte ein Vertrag abschließen. 12. Daten aus dem Angebot in den Antrag übernehmen. Die Produktkomponente stellt eine Antragsstruktur bereit. Die im Angebot erfassten Daten werden in diese Struktur eingestellt. Antragsstruktur zu Produkt bereitstellen (Produkt, Angebot, Voreinstellung) (PK - Produkt -> Produktdefiniertes Objekt bereitstellen) 13. Deckungszusage erteilen Für die Dauer der Antragserfassung wird eine Deckungszusage erteilt. 14. Fehlende Antragsdaten erfassen. Es werden Sicherungsdaten z.B. Schließsysteme und Einbruchmeldeanlagen für die Jacht oder ähnliches aufgenommen. Zusätzlich werden Rollendaten zum Beitragszahler Hrn. Schröder erfasst. Ein Gutachten über das Segelboot wird angefordert. 4. Antragsdaten prüfen (UC Geschäftsvorfall prüfen [für Antragserfassung durchführen]) Fachlicher Dienst 8. Formale Prüfung Ist die Willenserklärung schriftlich erfolgt? z.B. Hat Hr. Schmitt unterschrieben?. 9. Rechtliche Prüfung Ist Hr. Schmitt Eigner der Segeljacht? 10. Fachliche Prüfung Ist Hr. Schmitt geeignet und berechtigt die Segeljacht als Skipper zu führen. 5. Fehlende Daten der/des Partner(s) erfassen 6. Fehlende Daten der/des Subjekte(s) erfassen Alle Prüfungen sind positiv verlaufen. Der Antrag wird durch das VU angenommen. 3. Vertrag erstellen Nun wird eine Police erstellt und Folgeaktivitäten veranlasst. z.B. muss die Deckungszusage gekündigt, Vermittlerprovision berechnet und Inkasso über einen neuen Vertrag informiert werden. 15. Daten aus dem Antrag in den Vertrag übernehmen. Die Produktkomponente stellt eine Vertragsstruktur bereit. Die im Antrag erfassten Daten werden in diese Struktur eingestellt. Vertragsstruktur zu Produkt bereitstellen (Produkt, Antrag, Voreinstellung) (PK - Produkt -> Produktdefiniertes Objekt bereitstellen). 16. Police erstellen und dem Kunde aushändigen. UC - Geschäftsvorfall dokumentieren 17. Vertragsabschluß an Ereignisverwalter melden. © GDV 2001

45

Beispiele und Erläuterungen

Das Objektorientierte Fachliche Referenzmodell

18. Deckungszusage kündigen (PK - Versicherungsverhältnis -> Versicherungsvertrag ändern) 19. Provision berechnen 20. Inkasso Beitrag einziehen 21. Auswirkungen auf Folgeereignisse prüfen UC - Vertragsrelevanz registrieren [für Antragserfassung durchführen] Aufgrund verschiedener, vertraglicher (produktdefinierten) Grundlagen, muss ein Versicherungsverhältnis auf verschiedene Ereignisse reagieren. Die produktdefinierte Operation, mit der das Versicherungsverhältnis bei Eintritt des Ereignisses aufgerufen werden möchte, muss das Versicherungsverhältnis dem Ereignisverwalter mitteilen. Adressänderung des Partners Änderung des Liegeplatz des Bootes Änderung der qm des Hauses

5.4. Iteration III. Der beschriebene Sachverhalt lässt sich in der Prozesskomponente Versicherungsverhältnis mit den Services angebotErstellen und antragserfassungDurchfuehren versorgen. Hierzu benötigt die Prozesskomponente die Funktionalität der folgenden Komponenten: 4. Angebot erstellen (PK – Versicherungsverhältnis -> angebotErstellen) 22. PK_Produkt ->ProduktSuchen(ProduktTyp(Hausrat)) 23. AWK_Angebot ->erzeugen(Produkt(„VAA - Schöner Wohnen“)) Da es sich bei Angebot um ein produktdefiniertes Objekt handelt, benötigt die AWK zur Erzeugung des Objekts (bzw. der Angebot-Manager) die entsprechende Funktionalität der PK_Produkt: „PK_Produkt ->ProduktdefiniertesObjektBereitstellen(ObjektTyp(Angebot), Produkt („VAA - Schöner Wohnen“))“ 24. AWK_Angebot -> aktualisieren(Schlüssel, Wert); 25. PK_Partner -> partnerSuchen(name(Schmitt) adresse(Hamburg)) 26. AWK_Rolle -> aktualisieren(bezeichnung(VN) „Partner-ID“) Mit der „Partner-ID“ wird eine Referenz auf das betreffende Partner-Objekt mitgegeben. 27. PK_Subjekt -> subjektSuchen(bezeichnung(Masuren 9005)) 28. AWK_Subjekt -> erzeugen(Produkt(„VAA - Schöner Wohnen“)) 29. AWK_Subjekt -> aktualisieren(bezeichnung(Masuren 9005)) 30. AWK_Subjekt -> aktualisieren(rolleBezeichnung(Skipper) „Partner-ID“) Das zweite Aktualisieren dient lediglich dazu, die Rolle zu aktualisieren (die an das Subjekt geknüpft ist) und den Partner der Rolle zuzuordnen. Dies könnte man auch mit einem „aktualisieren“ - Aufruf machen. 31. AWK_Angebot -> starteOperation(MonatlicherBeitragBerechnen) 32. PK_Versicherungsverhaeltnis -> vertragsrelevanzRegistrieren(Ereignis, GeVo, Angebots-ID) Wird aus dem Angebot ein Antrag muss das Angebot entsprechend markiert werden. 33. DK_Geschäftsvorfall dokumentieren „DK“ steht (Arbeitstitel) für Dienst-Komponente und soll den Aufruf eines fachlichen Dienstes symbolisieren. 5. Antrag erstellen (PK – Versicherungsverhältnis -> antragserfassungDurchfuehren) 46

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Beispiele und Erläuterungen

34. AWK_Antrag -> erzeugen (Angebot) (PK_Produkt -> Produktdefiniertes Objekt bereitstellen) Da es sich bei Antrag um ein produktdefiniertes Objekt handelt, benötigt die AWK zur Erzeugung des Objekts (bzw. der Antrags-Manager) die entsprechende Funktionalität der PK_Produkt: „PK_Produkt ->ProduktdefiniertesObjektBereitstellen(ObjektTyp(Antrag), Produkt („VAA - Schöner Wohnen“), Angebot)“ 35. DK_Ereignisverwalter -> melde(Antrag erstellt, Antrags-ID) 36. AWK_Antrag -> aktualisieren(Schlüssel, Wert) Beim Aktualisieren werden auch Rollen und Partner-/Subjektwerte (z.B. Einbruchmeldeanlage) zum Aktualisieren an die notwendigen Komponenten weitergereicht. Gleichzeitig wird der Wert für die Deckungszusage gesetzt. 37. PK_Versicherungsverhaeltnis -> geschaeftsvorfallPruefen(Kontext „Antragserfassung durchführen“, Antrag) 38. PK_Versicherungsverhaeltnis -> vertragsrelevanzRegistrieren(Ereignis, GeVo, Antrags-ID) Wird aus dem Antrag ein Vertrag muss der Antrag entsprechend markiert werden und die Dekkungszusage gekündigt werden. 6. Vertrag erstellen 39. AWK_Vertrag -> erzeugen(Antrag) Da es sich bei Vertrag um ein produktdefiniertes Objekt handelt, benötigt die AWK zur Erzeugung des Objekts (bzw. der Vertrags-Manager) die entsprechende Funktionalität der PK_Produkt: „PK_Produkt ->ProduktdefiniertesObjektBereitstellen(ObjektTyp(Vertrag), Produkt („VAA - Schöner Wohnen“), Antrag)“ 40. DK_ Geschäftsvorfall dokumentieren Police erstellen 41. DK_Ereignisverwalter -> melde(Vertrag erstellt, Vertrags-ID) 42. PK_Versicherungsverhaeltnis -> vertragsrelevanzRegistrieren(Ereignis, GeVo, Vertrags-ID)

© GDV 2001

47

Das Objektorientierte Fachliche Referenzmodell

6. Umgang mit dem Referenzmodell 6.1. Nutzen des Referenzmodells Ein objektorientiertes Referenzmodell VAA hat drei wesentliche Nutzenaspekte für die Versicherungsunternehmen. 1. Basis für Komponentenmarkt Die Methodik der Objektorientierung in Verbindung mit der unternehmensübergreifenden und vollständigen Fachlichkeit der Modelle ist eine Hauptvoraussetzung dafür, daß an unterschiedlichen Stellen von unterschiedlichen Teams Versicherungsanwendungen entwickelt werden können, die reibungslos miteinander arbeiten. Nur so kann die jetzige Kostendynamik in der EDV der Unternehmen bedingt durch zur Zeit noch notwendige umfangreiche Eigenentwicklungen – wirkungsvoll unterbrochen werden. Das Referenzmodell hat gewissermaßen die Funktion eines Standards für EDVAnwendungen von Versicherungsunternehmen. 2. Basis für den Abgleich mit bestehenden Unternehmensmodellen Das Referenzmodell ist eine sehr gute Unterlage, bestehende Unternehmensmodelle daran abzugleichen. Das Motiv für einen solchen Abgleich kann z. B. darin liegen, sich mit den eigenen EDVAnwendungen in den entstehenden Komponentenmarkt rechtzeitig einzuphasen. 3. Basis für Eigenentwicklungen in Versicherungsunternehmen Unabhängig von dem sich entwickelnden Komponentenmarkt gibt es einen unmittelbaren Nutzen für die Unternehmen, die jetzt mit der Analyse oder dem Entwurf neuer Anwendungen beginnen. Das Referenmodell mit seinem planmäßig durchdachten Blick für Fachlichkeit eines Versicherungsunternehmens ist eine hervorragende Hilfe für den Entwurf neuer Anwendungen. Planungsprozesse und Entscheidungen – sowohl fachlich als auch geschäftsstrategisch – können schneller und sicherer erfolgen.

6.2. Verwendung des Referenzmodells 6.2.1. Basis für neue Entwicklungen Bei einer unternehmensstrategischen Komponentenbildung, sei es bei

Ausrichtung

ohne

Berücksichtigung



kompletter Neugestaltung von Versicherungsanwendungen oder



bei bereits unternehmensstrategisch vorgegebener Komponentenbildung

der

VAA-

kann das Referenzmodell in der derzeitigen Form bereits Verwendung finden, und zwar sowohl •

zu Beginn derartiger Vorhaben als auch



zur Verifikation bereits existierender Modellbildungen.

Hierbei kann folgendermaßen vorgegangen werden:

48

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Umgang mit dem Referenzmodell

Nachdem das OFRM in seiner Gänze und Struktur hinreichend durchdrungen wurde, gilt es zunächst den neu zu gestaltenden Bereich innerhalb des unternehmensspezifischen Sollprozessmodells zu identifizieren und abzugrenzen, bzw. ein entsprechendes Sollprozessmodell zu entwickeln. Dann sollte der Abstraktionsgrad der Modelle für das VU festgelegt werden. Auf des Ebene der Anwendungsfälle (Use Cases) sollten nun die im Referenzmodell zu dem Bereich gehörigen Use Cases identifiziert werden. Diese sollten in das Sollprozessmodell eingebettet werden. Die so abgegrenzten Use Case-Bereiche sollten nun ergänzt bzw. reduziert werden im Hinblick auf:: •

Vollständigkeit im Sinne des Prozessmodells



einen einheitlichen Abstraktionsgrad



Spartenspezifika



VU-Spezifika



Vollständigkeit / Exaktheit der Use Case-Dokumentationen



Anpassung der „Muss“- (uses) bzw. „Kann“- (extends) Abläufe

Anschließend werden vorhandene Daten- bzw. Funktionsmodelle verwendet, um ein grobes Klassenmodell zu strukturieren. Nun werden die interessanten Use Cases in Form von Szenarien (als Sequenzdiagramme) fachlich diskutiert unter Berücksichtigung des konkreten Prozessmodells, des gewählten Abstraktionsgrades und der Sparten und VU-Spezifika.. Dies dient der Identifikation weiterer Klassen und Methoden. Alle Anforderungen aus den Szenarien an Bereiche außerhalb des neuzugestaltenden Komplexes werden in Fassaden gesammelt. Sie dienen der Beschreibung der Außenschnittstellen. Durch stetes Durchdiskutieren aller relevanter Szenarien wird das Klassenmodell immer wieder überarbeitet und verfeinert. Im Prinzip entspricht diese Vorgehensweise der im VAA/OO-Projekt verwendeten unter Einbeziehung der konkreten Prozess- und Spartensituation eines VU. Die Verwendbarkeit der innerhalb des VAA/OO-Projektes diskutierten Szenarien dürfte eher zufällig sein, da auf den Ablauforganisationebene erfahrungsgemäß die einzelnen VU sehr individuell strukturiert sind. Durch das beschriebene Vorgehen erhält man neben den genannten Modellergebnissen eine Sollstrukturierung des betrachteten Anwendungsfeldes.

6.2.2. Abgleich mit existierenden Unternehmensmodellen Aus dem Projektauftrag geht der Anspruch an das OFRM hervor. Die wesentlichen (abstrakten) Kriterien sind insbesondere -

Konsistenz und Widerspruchsfreiheit der Gesamtstruktur minimale Vollständigkeit branchenspezifischer Inhalt (gültig für VU im deutschsprachigen Raum) Sparten- und VU-Unabhängigkeit

Um Vollständigkeit und gleichzeitig branchenspezifische Allgemeingültigkeit zu erhalten, musste (auch im Klassendiagramm) eine „flache“ Modellierungstiefe eingehalten werden. Das bedeutet, dass

© GDV 2001

49

Umgang mit dem Referenzmodell

Das Objektorientierte Fachliche Referenzmodell

ein spezielles VU, wenn es sich nach dem Referenzmodell ausrichten will, dieses in folgender Weise modifizieren muss: •

Das Klassenmodell muß um weitere Klassen erweitert werden; es muss in bestimmten Bereichen des Modells eine Klasse durch mehrere andere ersetzt werden.



Strukturen des Klassenmodells müssen ggf. an unternehmensspezifische Design-Grundsätze angepasst werden.



Klassen müssen um VU- oder branchenspezifische Attribute und/oder Methoden erweitert werden.



„extends“-Beziehungen müssen ggf. in „uses“ geändert werden oder gelöscht werden.



Use Case-Beschreibungen müssen ggf. weiter detailliert werden (das können Erweiterungen und/oder Einschränkungen sein).



Template-Use Cases müssen aufgelöst werden.



Sequenzdiagramme haben keinen Referenzcharakter; ihre Verwendbarkeit ist allenfalls zufällig.

Bem.: Um die Verwendbarkeit des Referenzmodells für ein spezielles VU besser prüfen zu können, kann es hilfreich sein, auch die Use Cases zu „konkretisieren“, d. h. mit ihnen die VU-spezifischen Abläufe/Prozesse darzustellen (und dann den Vergleich auf „Prozess“- und nicht auf Klassenebene durchzuführen). Nutzt man die in der Beschreibung vorgesehene Struktur zur Abbildung von Auslöser, Vorbedingungen und Nachbedingungen entsprechend, so lässt sich (bis zu einem gewissen Grade) der Ablauf-/Prozessaspekt abbilden. Insbesondere hilft die Betrachtung der Sequenzdiagramme, die Verwendbarkeit des Klassendiagramms zu prüfen. Das Referenzmodell ist ein Analysemodell, in dem die Semantik der Geschäftsobjekte strukturiert abgebildet ist. Es finden keine Designüberlegungen statt. Insbesondere Performance-Überlegungen, die abhängig sind vom Mengengerüst der Instanzen der jeweiligen Klassen, könnten also durchaus zur Notwendigkeit struktureller Änderungen für ein VU führen, welches das Referenzmodell anwenden will.

Konkretisierungsgrade im Referenzmodell Das fachliche Modell kann Bereiche unterschiedlicher Konkretisierung beinhalten. -

konkrete Ebene Es wird konkret ausmodelliert. Beispiel: Beitrag berechnen; modelliert wird: „Es ist ‚Alter x 100 DM‘ zu berechnen“. Diese Ebene der Ausmodellierung kann nur dann genutzt werden, wenn die im Use Case beinhaltete Aktivität in dieser (konkreten) Form allgemeingültig durchgeführt wird. Wo diese Ebene erreicht werden konnte (im fachlichen Modell), entfällt für ein spezifisches VU die Anpassung der Aktivität. Hier entsteht kein zusätzlicher Aufwand, um das Referenzmodell zu „instanzieren“.

-

50

„Meta-“Ebene

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Umgang mit dem Referenzmodell

Es wird nicht die konkrete Aktivität (d. h. deren Inhalt) ausmodelliert, sondern nur die Bezeichnung. Beispiel: Beitrag berechnen; wie die Beitragsberechnung abläuft, wird nicht modelliert. Bei dieser Modellierungsebene muss ein spezifisches VU die Aktivität erst mit konkretem Inhalt füllen, damit das Modell angewendet werden kann. Das Modell muss also „in die Tiefe“ erweitert werden. In der Beschreibung des Use Case sollte begründet werden (wo möglich), warum keine konkrete Ausmodellierung stattfindet, zumindest dann, wenn der Grund Spartenabhängigkeit ist. Beispiel: Leistung berechnen wird für Krankenversicherungen, Lebensversicherungen und Hausratversicherungen jeweils unterschiedlich berechnet. Hier gibt es allenfalls „Spartenpatterns“, d. h. eine begrenzte Anzahl Modellierungsmuster, die Allgemeingültigkeit (d. h. VU-Unabhängigkeit) innerhalb einer Sparte besitzen. -

Es ist eine noch höhere Ebene denkbar, nämlich da, wo selbst die Frage, ob die Aktivität (wie auch immer) ausgeführt werden soll, nicht allgemeingültig beantwortet werden kann. Beispiel: Beitrag berechnen wird bei gewissen Sparten / VU nicht ausgeführt. Hier kann es sein, dass das fachliche Modell diese Aktivität - nicht enthält (bei Situationen, wo nicht bewertet werden kann, ob die Aktivität mehrheitlich ausgeführt wird bzw. bei Situationen, wo die Aktivität mehrheitlich nicht ausgeführt wird) oder - als einen Use Case enthält, der aus einem anderen Use Case über eine -Beziehung aufgerufen wird (bei Situationen, wo der Use Case mehrheitlich ausgeführt wird). Das spezielle VU muss dann ggf. das Modell erweitern („in die Breite“, d. h. einen Use Case hinzufügen, der nicht enthalten ist) oder den Beziehungstyp der Use Case-Beziehung ändern (von in ), falls die Aktivität immer ausgeführt wird.

6.2.3. Grundsätzliche Verwendungsmöglichkeiten Über die oben genannten Verwendungsmöglichkeiten des Referenzmodells hinaus ergeben sich einen Reihe weiterer Nutzungsmöglichkeiten für neue und laufende Projekte. Zum Beispiel: -

Übernehmen von Vorgehensweise/Teilen von Vorgehensweise

-

Benutzung von Modellierungsmustern

-

Verwendung von Ideen für Fachabläufe/fachliche Arbeitsorganisation

-

Ergänzung des fachlichen Know-hows

-

Hilfe bei Modellierungsentscheidungen

-

Ideen für die Organisation der Arbeit in komplexen Projekten

© GDV 2001

51

Das Objektorientierte Fachliche Referenzmodell -

Verwendung von fachlichen Begriffsdefinitionen/Glossarergänzungen

-

Unterstützung bei der Abgrenzung von Klassen

-

Ideen für die Vergabe von Namenskonventionen

-

Basis für Vollständigkeitsprüfung von Modellen

-

Erfahrungen beim pragmatischen Umgang mit komplexen Modellen übernehmen (Richtiges Maß für Übersichtlichkeit und Handhabbarkeit sowie Granularität)

Noch eine generelle Bermerkung zum Schluß: Alle Versicherungsunternehmen, die sich gerade im Fusionsprozeß befinden (oder einen solchen vor sich sehen), haben durch die geschickte Nutzung von VAA (angefangen mit der „trivialen“ Nutzung, sich mittels VAA auf die Benennung der wesentlichen Bereiche zu einigen) die Chance, mühsame Einigungs- und Erkenntnisprozesse abzukürzen. Da in einem solchen Umfeld häufig versucht werden muß, die Fusion im IT-Bereich mit „Null-Aufwand“ abzuwickeln, d. h. ohne daß das laufende ITGeschäft beeinträchtigt wird, sollte dies ein wirklich attraktives Angebot sein.

52

© GDV 2001

Das Objektorientierte Fachliche Referenzmodell

Referenzen

7. Referenzen 7.1. Use-Case-Modell Siehe Internet-Adresse: http://www.gdv.de/vaa oder CD-ROM VAA Final Edition

7.2. Klassenmodell Siehe Internet-Adresse: http://www.gdv.de/vaa oder CD-ROM VAA Final Edition

7.3. Fachliche Dienste Die Beschreibung der fachlichen Dienste ist im Ergebnisdokument “Technisches Referenzmodell“ (OTRM) nachzulesen.

7.4. Literaturhinweise [1]

Jim Rumbaugh, Ivar Jacobson, and Grady Booch: Unified Modeling Language Reference Manual. ISBN 0-201-30998-X, Addison-Wesley, est. publication December 1997.

[2]

UML-Reference-Guide (wird auch auf WWW-Server abgelegt)

[3]

Martin Fowler, Kendall Scott: UML konzentriert: Die neue Standard-Objektmodellierungssprache anwenden. ISBN 3-8273-1329-5, Addison-Wesley, 1998.

[4]

Objektorieniertes technisches Referenzmodell, Version 1.0, 1999.

[5]

Produkt

[6]

Schönsleben/Leuzinger: Innovative Gestaltung von Versicherungsprodukten. ISBN 3-409-19470-3, Gabler 1996.

[7]

Kotler/Bliemel: Marketing Management. ISBN 3-7910-1310-6, Schäffer-Poeschel 1999

[8]

Prof. Dr. jur. Peter Koch/Prof. Dr. rer. pol. Wieland Weise: Gabler Versicherungslexikon ISBN 3-409-18508-9, Dr. Th. Gabler GmbH 1994

[9]

Volker Kurzendörfer: Einführung in die Lebensversicherung, 2. Überarbeitete Auflage ISBN 3-88487-554-x, Verlag Versicherungswirtschaft 1996.

.

© GDV 2001

53

View more...

Comments

Copyright � 2017 SILO Inc.