Projekt bei einem Versicherungsunternehmen
Oktober 2006 – April 2007
Aufgabenbeschreibung meiner durchgeführten Tätigkeiten
Als Spezialversicherer der Bauwirtschaft präsentierte der Auftraggeber seinen Kunden zu Beginn des Jahres 2005 einen innovativen und komplett neuen Versicherungstypus, welches den Bauherren während der gesamten Bauphase bis hin zur Abnahme der Bauleistung vor möglichen finanziellen Folgen schützt, die z.B. durch die Insolvenz des beauftragten Bauunternehmers eintreten kann.
Um insbesondere auch die IT-Kosten während der Anlauf – und Startphase niedrig zu halten, wurden die Bestandsdaten zunächst in Microsoft-Excel-Tabellen bzw. in Word-Dateien gehalten und gepflegt. Nicht zuletzt aufgrund des grossen Erfolgs wurde dieses preliminäre Bestandsdaten-System den für Versicherungen im Allgemeinen üblichen hohen Anforderungen bezüglich Daten-Konsistenz und Transaktionsssicherheit schon bald nicht mehr gerecht. Deshalb entschied sich das Versicherungsunternehmen schliesslich dazu, diese Lösung durch eine auf dem relationalen Datenmodell basierende, Datenbanksystem-gestützte Software zu ersetzen.
Meine Aufgaben innerhalb des Projekts definierten sich nun wie folgt:
| 1.) | Planung, Analyse, Entwurf und Realisierung eines relationalen Datenbanksystems zur Verwaltung von Bestandsdaten im DB2-Umfeld |
| 2.) | Planung, Analyse, Design und Implementierung einer Software incl. Benutzerschnittstelle für den Zugriff auf das Bestandsdaten-Datenbanksystem |
1.) Datenbanksystem
Zu meinen Aufgaben gehörte zunächst das Design eines auf der Relationentheorie basierenden Datenmodells für die Bestandsdaten unter Berücksichtigung der Normalisierungsverfahren. Im nächsten Schritt erfolgte die Umsetzung dieses Modells in ein physikalisches Datenbank-Schema fuer das relationale Datenbanksystem DB2. Die Migration von Bestandsdaten aus Excel-Tabellen und Word-Dokumenten erfolgte anschliessend unter Verwendung des Hilfs- und Dienstprogramms Apache POI zum Lesen und Schreiben von Dateien im Microsoft Office-Format. Schliesslich wurde die Qualität des physikalischen Datenbank-Schemas wie auch die Konsistenz der migrierten Daten unter Verwendung der standardisierten Datenbankabfragesprache SQL im automatisierten Verfahren verifiziert.
2.) Software zur Datenbanksystem-Anbindung und zur Datenübertragung
mit Mainframe-Prozessen (Hardwarekonfigurationen).
Mein Aufgabenbereich gliederte sich in vier Teile:
| a.) | Anbindung des Datenbanksystems für Bestandsdaten mit Hilfe des objekt-relationen Persistenz-Frameworks hibernate; | |
| b.) | Anbindung eines Datenbanksystems für Geschäftspartner zur Adressplausibilierung; | |
| c.) | Realisierung einer systemtechnischen Schnittstelle zur Datenübertragung mit COBOL-Prozessen einer Host- und Mainframestruktur (Hardwarekonfigurationen); | |
| d.) | Entwicklung einer web-basierten Benutzerobfläche zum Zugriff auf das Bestandsdaten- und Partnerdaten Datenbankmanagement-System; Etablierung eines Testlabors zur Qualitätskontrolle der gesamten Software; |
Unter Verwendung standardisierter Vorgehensmodelle zur ingenieurmässigen Softwareentwicklung (Wasserfallmodell, Rational Unified Process) habe ich mich an die strengen Vorgaben der durch die interne Produktentwicklung vorgegebenen Software-Entwicklungsprozesse gehalten. In diesem Vorgehensmodell wird ein aus verschiedenen Phasen bestehender Zyklus aus Konzeptionsphase, Entwurfsphase, Konstruktionsphase und Übergabephase sequentiell durchschritten. Um die Nutzbarkeit und Konformität der zu entwickelnden Software zu erweitern, wird dieser Zyklus optimalerweise zirkulär wiederholt.
| a.) | Softwareentwicklung basiert heutzutage standardmässig auf dem Softwarentwicklungsparadigma der Objektorientierung. Um hierarchisch strukturierte Objekte schliesslich in eine zwei-dimensionale relationale Struktur einer Datenbank persistieren zu können, bedient man sich sogenannter Objekt-relationaler Mapper, deren bekanntester Verteter das Persistenz-Framework hibernate ist. Meine Aufgabe bestand nun zunächst in dem Design eines objekt-basierten Domain-Modells, welches die an den zu implementierenden Geschäftsprozessen beteiligten Entitäten beschreibt. Im nachfolgenden Schritt wurden diese Entitäten in Form von Java-Geschäftsobjekten bzw. die sie repräsentierenden Klassen definiert. Schliesslich erfolgte die Konstruktion von XML-basierten mapping-Dateien, welche die Beziehungen zwischen Geschäftsobjekten und den entsprechenden Datenbank-Relationen abbilden. Zum eigentlichen Speichern von Objekten wurde von mir das standardisierte Softwarepattern Data Access Object(DAO) verwendet, wobei die Persistenzlogik aus dem eigentlichen BusinessObject herausgezogen und in einer eigenen Schicht realisiert wird. Für jedes Geschäftsobjekt wurde nun eine Klasse bereitgestellt, die deren Persistenzfunktionalitäten (lesen, schreiben, löschen) durch Verwendung der hibernate-eigenen Abfragesprache HQL realisierte. Die Qualität der implementierten Objekt-relationalen Persistenz-Software wurde schliesslich mit Hilfe des Hilfs-und Dienstprogramms JUnit auf Basis des testgetriebenen Softwareentwicklungs-Paradigmas im automatisierten Verfahren verifiziert. |
| b.) | Zur Anbindung eines Geschäftpartner-Datenbanksystems zur Adressplausibilierung wurde in analoger Weise wie in a.) beschrieben verfahren, d.h. es wurden die entsprechenden Entitäten in das vorhandene Domain-Modell integriert, diese in Form von Geschäftsobjekten implementiert und das Resultat über XML-basierte Mapping-Dateien mit dem relationalen Schema des Partnerdaten-Datenbanksystems verknüpft. Funktionaliät bzw. Qualität der Persistenz-Implementierungen erfolgte wie in a.) beschrieben mittels des testgetriebenen Methodenansatzes. |
| c.) | Ein Grossteil der Geschäftlogik für Vertragsdaten (Plausibilisierungen, Schadensfälle) befindet sich auf IBM-Hardwarekonfigurationen (auch Mainframes genannt), und ist in Form von COBOL-Software implementiert. Diese Anwendungen und die sie innewohnende Geschäftslogik werden überwiegend als Transaktionen durchgeführt, und stehen unter der Kontrolle von sog. Transaktionsmonitoren, wie dem Customer Information Control System (CICS). Meine Aufgabe bestand nun darin, eine System-Software für den Zugriff auf Mainframe-Businesslogik zu entwickeln. Über das CICS Transaction Gateway (CTG) wurden die CICS-Transaktionen auf dem Application-Server verfügbar gemacht und über die Java Connector Architecture (JCA) an die Host-Anwendungen angebunden. Die eigentliche Kommunikation der CICS- Hardwarekonfiguration Host und der Java-Server erfolgte dabei über das "External Call Interface" (ECI). Als Grundlage für die von mir zu entwickelnden Datenstrukturen dienten die vorhandenen COBOL Copystrecken. Da Copybook Definitionen in Cobol geschrieben sind, lassen sich diese Dateien nicht ohne weiteres von einer Java Anwendung interpretieren. Zu diesem Zweck entwickelte ich eine Parser-Software, welcher die Beschreibung aus der Cobol Syntax in Java Beans übersetzte. Und somit einen Brückenschlag zwischen der Hardwarekonfiguration und Java-Anwendungen herstellte. |
| d.) | Realisierung einer GUI-Komponente |
Basierend auf den neuesten Java 2 Enterprise Edition (J2EE) Standards und Technologien entwarf ich eine für Web-basierte Software typische, auf dem dem Model-View-Controller-Pattern basierende Architektur
| a.) | Die Präsentationsschicht(View) stellt die eigentliche Benutzerschnittstelle für die Datenrepräsentation und Benutzereingaben dar und wurde von mir auf Basis der Java Server Pages (JSP) Technologie in Form selbst ersteller JSP templates realisiert; |
| b.) | Die Steuerungs-Schicht (Controller) nimmt die Benutzereingaben entgegen, leitet die Anfrage an die Businesslogik weiter und übergibt das Ergebnis an die View tur Darstellung. Die Implementierung des Controllers wurde von mir auf Basis des Spring-MVC- Frameworks für Java-Enterprise-Anwendungen realisiert. |
| c.) | Das Modell enthält die eigentliche Geschäftslogik, sie bildet hier konkret die in 2a. und 2b.) beschriebenen Schnittstellen zum Datenbankzugriff (DAO) sowie die in 2c.) beschriebenen systemtechnischen Schnittstellen auf die COBOL-Host-Systeme. |
Die Qualität der Implementierungen wurde mit Hilfe standardisierter JUnit-Komponententests überprüft und sichergestellt. Um den iterativen Zyklus aus Planung, Analyse, Entwurf, Entwicklung und Test zu unterstützen, bediente ich mich dabei nachfolgender Hilfs- und Dienstprogramme: des CASE-Tool JBoss sowie des Unified Modelling Language (UML) Software-Design Tools Poseidon UML von Gentleware.
Die finale Qualitätskontrolle erfolgte schliesslich in einem von mir eigens konzipierten Testlabor. Unter Verwendung des Hilfs- und Dienstpogramms JUnit wurden Testfälle erstellt, die nach dem Black-Box-Testverfahren alle relevanten Geschäftsvorfälle abbildeten. Im Zuge dieser automatisierten Testläufe wurden aufkommende Fehler priorisiert und kategorisiert und in einem Hilfs- und Dienstprogramm für Problem-Melde-Wesen (Bugzilla) erfasst. Nach erfolgter Korrektur wurden von mir Nach-Tests durchgeführt, bis schliesslich keine Fehler der Kategorie „Abnahmeverhindernd“ mehr vorhanden waren und somit meine ingenieurvergleichbare Tätigkeit abgeschlossen werden konnte.