Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine...

6
magazin Java Architekturen Web Agile www.javamagazin.de JAVA Mag 2.2014 GlassFish-Support: Eine strategische Entscheidung und ihre Konsequenzen 45 MEHR THEMEN: Neo4j: Produktiv mit Graphen | Android KitKat und das Project Svelte | Continuous Integration mit Liferay 6.1 REST-assured Restlos glückliches Testen 42 Testautomation Mit SoapUI, Maven und Jenkins 88 Alle Infos hier im Heft! 35 Architektur- konzepte mit Spring Modularität als Tugend 94 Redis – klein und universell Mehr als eine NoSQL- Datenbank 66 Default- Methoden in Java 8 Methoden in Interfaces implementieren 19 Spiele entwickeln mit Android Technische Herausforderungen und Lessons Learned 109 Sonderdruck Consileon

Transcript of Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine...

Page 1: Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine An-wendungsdomain • Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert

magazinJava • Architekturen • Web • Agile www.javamagazin.de

JAVA

Mag

2.2014

GlassFish-Support: Eine strategische Entscheidung und ihre Konsequenzen 45

MEHR THEMEN: Neo4j: Produktiv mit Graphen | Android KitKat und das Project Svelte | Continuous Integration mit Liferay 6.1

REST-assured Restlos glückliches Testen 42

Testautomation Mit SoapUI, Maven und Jenkins 88

agazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinagazinwww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.dewww.javamagazin.de

agazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinagazinwww.javamagazin.de

agazinAlle Infos hier im Heft!

35

Architektur-konzepte mit SpringModularität als Tugend 94

Redis – klein und universellMehr als eine NoSQL-Datenbank 66

Default-Methoden in Java 8Methoden in Interfaces implementieren 19

Spiele entwickeln mit AndroidTechnische Herausforderungen und Lessons Learned 109

Modularität als Tugend 94 universellMehr als eine NoSQL-Datenbank 66

Default-Methoden Spiele

entwickeln Sonderdru

ck Consileon

Page 2: Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine An-wendungsdomain • Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert

2 www.JAXenter.dejavamagazin 2 | 2014

AgileSonderdruck

© Software & Support Media GmbH2 www.JAXenter.de

von Dr. Hans Schuster, Frank Redlich und Stefan Kallinich

Standen Sie auch schon vor der Aufgabe, eine fachliche Anwendung zu erstellen, die für verschiedene Kunden eingesetzt werden soll? Besonders komplex wird diese Thematik, wenn die Kunden in unterschiedlichen Bran-chen angesiedelt sind. Insbesondere bei IT-Dienstleis-tern stellt sich diese Problematik regelmäßig, aber auch in vielen Konzernen steht das Thema bei der IT auf der Tagesordnung, nur mit dem Unterschied, dass die „Kunden“ in diesem Fall aus dem eigenen Haus und in der Regel der gleichen Branche kommen. Dafür ist das Unverständnis aber umso größer, wenn eine Lösung für Bereich A nicht ohne großen Aufwand auch für Bereich B verwendet werden kann, der scheinbar ähnliche An-forderungen hat.

Themen für solche Anwendungen sind z. B. Buchhal-tung, CRM, Vertriebsvergütung, Vertriebscontrolling, Billing, BI-System etc. Das Ziel für solche Software ist ein hoher Grad an Wiederverwendung bei gleichzeitiger Individualisierungsmöglichkeit durch kundenspezifische Anpassungen, die im optimalen Fall auch noch sehr be-dienerfreundlich durchzuführen sind. So ist es beispiels-weise selbstverständlich, dass ein Buchhaltungssystem individuelle Kontenrahmen und Schnittstellen ermög-licht.

Etwas abstrakter betrachtet ist unser Ziel, dass wir Softwarelösungen für „ähnliche“ fachliche Proble-me nicht für jeden Kunden von Grund auf neu entwi-ckeln wollen, sondern eine Basislösung – im Prinzip ein Softwareprodukt – erstellen, das die Grundlage für die individuellen Kundenlösungen bildet. Vom Grund-

prinzip her entspricht dies dem Einsatz von Program-mierframeworks zur Lösung bekannter technischer Fragestellungen, z. B. dem Einsatz von Hibernate zur Implementierung von Persistenz. Wir wollen den Wie-derverwendungsgedanken hinter solchen Frameworks auf fachliche Problemstellungen ausdehnen.

Eine besondere Herausforderung ist hierbei, dass vor allem komplexe Softwarelösungen in der Regel über vie-le Jahre genutzt und weiterentwickelt werden. Es wäre deshalb nur wenig gewonnen, wenn die Weiterentwick-lungen für jeden Kunden ausschließlich individuell er-folgen würden. Wir müssen unbedingt erreichen, dass auch die Basislösung permanent weiterentwickelt wer-den kann und neue Versionen davon möglichst leicht in die individuellen Kundenlösungen eingebaut werden können.

Kostengünstig, standardisiert und trotzdem individuellAbbildung 1 visualisiert das Ziel dieser Artikelserie: Wir werden am Beispiel unserer Softwarelösung „ConProv“ aufzeigen, wie man für eine bestimmte fachliche Domain eine individualisierbare Softwarelösung umsetzen kann. Eine solche Lösung erreicht einen möglichst hohen Grad an Wiederverwendung zwischen verschiedenen Kunden

Artikelserie

Teil 1: Individuelle Lösung und Wiederverwendbarkeit unter einem DachTeil 2: Datenmodell: O/R Mapping, Template Patterns und AbfragenTeil 3: Prozessmodell: Eine spezielle Anwendungsdomain braucht eigene Berechnungs- und Prozessmodelle

Individuelle Lösung und Wiederverwendbarkeit unter einem Dach

Das Meta macht den Unterschied Individualisierbare Standardsoftware wagt den Spagat zwischen möglichst großer Wiederverwendung und größtmöglichem Eingehen auf den individuellen Bedarf von Kunden bei möglichst geringen Projektkosten. Erreicht wird das durch die Definition von fachlichen Metamodellen, welche die Abbildung der Kundenanforderungen erlau-ben und von der Software ohne weitere Programmierung ausgeführt werden können.

Page 3: Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine An-wendungsdomain • Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert

3www.JAXenter.de javamagazin 2 | 2014

AgileSonderdruck

© Software & Support Media GmbH 3www.JAXenter.de

bei gleichzeitig hohem Individualisierungsgrad für jeden einzelnen Kunden. Dabei wollen wir uns nicht nur auf das How-we-did-it konzentrieren, sondern vielmehr das Why-we-did-it in den Vordergrund stellen, um dem Leser den Transfer auf eigene Problemstellungen zu er-leichtern.

Was ist nun das Besondere an einer individualisier-baren Softwarelösung? Sie zielt auf den Spagat zwi-schen möglichst maximaler Wiederverwendung und größtmöglichem Eingehen auf den individuellen Bedarf des Kunden bei möglichst geringen Projektkosten ab. Es ist klar, dass ein 100-prozentiges Erreichen dieser Ziele nicht möglich ist, da alleine schon Individualität und Wiederverwendung prinzipiell konträre Ziele sind. Nichtsdestotrotz sollten wir uns nicht mit dem Status Quo der anpassbaren- und wiederverwendbaren Soft-warelösungen zufriedengeben. In diese Klasse fallen viele der heutigen Lösungen im Bereich ERP und CRM. Sie bieten eine oft kaum zu überschauende Zahl von Parametrisierungsmöglichkeiten sowie eine Vielzahl von Programmierschnittstellen, manchmal sogar eige-ne Programmiersprachen. Gerade durch die Vielzahl der Parametrisierungsmöglichkeiten sind Einführungs-projekte mit individuellen Anpassungen oft schnell kostspielig. Trotzdem bleibt zwischen der Parametri-sierung, welche die Funktionen der Basissoftware opti-mal nutzt, und der individuellen Programmierung eine beträchtliche Lücke hinsichtlich der Individualität der Lösung. Trotz des heutzutage üblichen Einsatzes von Frameworks ist auch Individualsoftwareentwicklung oft vergleichsweise teuer. Mit unserem modellbasierten Ansatz für individualisierbare Software schlagen wir eine Brücke zwischen diesen beiden Welten bei gleich-zeitiger Verringerung der Projektkosten.

Die theoretischen Grundlagen dieses Ansatzes sind nicht neu. Die prominenteste und auch kommerziell erfolgreichste Umsetzung erfolgte durch relationale Datenbanksysteme. Das relationale Modell ist in sich geschlossen und alle Anwendungsdatenmodelle kön-nen mit der zugehörigen Modellsprache – SQL – um-gesetzt werden. APIs zur Erweiterung der Funktionen der Datenbank gibt es zumindest in den klassischen re-lationalen Datenbanksystemen nicht. Im Gegensatz zu unserem Ansatz sind sie anwendungsneutral und das relationale Modell enthält keinerlei domainspezifische Fachlogik.

Wieso sollte man das Ziel einer individualisierbaren Softwarelösungsplattform anstreben? Gerade im letzten Jahrzehnt ging der Trend bei fachlichen Anwendungs-systemen doch stark in die Richtung Standardisierung (Stichwort SAP). Zur Frage gibt es zwei Antworten: Ers-tens sind echte Standardlösungen selten. Die Regel sind mehr oder weniger stark individuell angepasste Systeme. Zweitens gibt es Anwendungsbereiche, die sich prinzipi-ell für eine fachliche Standardisierung nicht eignen, weil die Individualität ein wichtiges Differenzierungsmerk-mal im Wettbewerb ist. In so einem Fall sind individuel-le Lösungen ein Muss, die zusätzlich einer permanenten

Weiterentwicklung unterliegen, denn der Markt schläft bekanntlich nicht.

Ein Beispiel für so eine Anwendungsdomain ist Ver-triebsvergütung und Billing. Gerade im Bereich der Finanzdienstleitungen, sprich Bank- und Versicherungs-produkte, unterscheiden sich die einzelnen Anbieter im Bereich der Produkte nur marginal. Jede Bank bietet z. B. Zahlungsverkehr, Sparprodukte, Kreditprodukte, Ak-tien- und Fondshandel etc. an. Der Wettbewerb findet stattdessen primär in den Bereichen Service und Vertrieb statt. Dementsprechend sind die Vergütungsmodelle je-doch bereits im Endkundenbereich aber insbesondere im Geschäftskunden- und Kooperationsbereich hoch-gradig unterschiedlich.

An dieser Anwendungsdomain wollen wir im Rahmen unserer Artikelserie zeigen, wie wir durch das Konzept der individualisierbaren Software auf effiziente Weise für jeden Kunden eine spezialisierte Lösung anbieten können und trotzdem den Großteil des Kodierungsauf-wands durch Wiederverwendung einsparen können. Konkret werden wir uns in den einzelnen Teilen der Ar-tikelserie folgenden Themen widmen:

Abb. 2: Vereinfachtes Domainmetamodell

Abb. 1: Magisches Dreieck aus Projektkosten, Individualität der Lösung und Wieder-verwendung

Page 4: Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine An-wendungsdomain • Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert

4 www.JAXenter.dejavamagazin 2 | 2014

AgileSonderdruck

© Software & Support Media GmbH4 www.JAXenter.de

•Einführung: Design eines Metamodells für eine An-wendungsdomain

•Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert für eine Anwendungsdo-main

•Prozessmodell: Eine spezielle Anwendungsdomain braucht eigene Berechnungs- und Prozessmodelle

Der Schlüssel ist das DomainmetamodellDer Spagat zwischen Individualität, Wiederverwendung und Kosten kann nicht alleine durch den punktuellen Einsatz der klassischen Techniken für wiederverwend-bare Software (Kasten: „Was wird unter Wiederver-wendung von Software verstanden?“) erreicht werden. Zuallererst muss die grundlegende Abstraktion der Zieldomain gefunden werden, sprich wir müssen identi-fizieren, was allen denkbaren Anwendungen in unserer Zieldomain gemein ist. Dies ist eine extrem schwieri-ge Aufgabe und es ist die Hauptursache, warum die Wiederverwendung einer Lösung für weitere Kunden scheitert bzw. die Aufwände für die Anpassungen ex-plodieren. Analoges gilt für das Ausufern von Einfüh-rungsprojekten von Standardsoftware. Die vorliegenden Abstraktionen passen einfach nicht so richtig zu dem gewünschten Zielsystem. Deshalb müssen an allen mög-lichen Stellen „Erkerchen“ an das „Softwarehaus“ dran gebaut werden, bis aus dem modernen und effizienten Softwarefirmengebäude ein „Märchenschloss“ gewor-den ist.

Ein guter Lösungsansatz für dieses Problem ist die Einführung einer zusätzlichen Modellebene, das Do-mainmetamodell. Es enthält nur diejenigen Abstraktio-nen, die ganz sicher für alle konkreten Zielanwendungen gelten, und erlaubt zusätzlich, konkrete Modelle für individuelle Kundenmodelle zu definieren. Um bei dem Hausbild von oben zu bleiben, versuchen wir gar nicht, ein Haus wiederzuverwenden und dann auf das Ziel an-zupassen, sondern wir erstellen einen „Hausbaukasten“ mit Komponenten und Werkzeugen, mithilfe derer das Zielgebäude aufgebaut wird.

Abbildung 2 zeigt das stark vereinfachte Metamodell für unsere Domain Vergütung/Billing. Das generelle und auf den ersten Blick sehr einfache Grundprinzip dieser Domain ist, dass Leistungserbringer für Leis-tungsempfänger Leistungen erbringen, und dafür

Was wird unter Wiederverwendung von Software verstanden?

Eine wiederverwendbare Software kann in mehreren Projekten eingesetzt werden. Das sind z. B. Bibliotheken, Frameworks (z. B. Hibernate) oder auch komplette Softwaresysteme, die ein oder mehrere klar definierte Metamodelle besitzen können (z. B. Daten-banksysteme, Workflow-Management-Systeme). Die Merkmale einer wiederverwendbaren Software sind die Nutzbarkeit für den Entwickler, Adaptierbarkeit sowie die Portierbarkeit [1]. Anpassbare Software ist ein Spezialfall von wiederverwendbarer Software. Die Basis dafür ist eine Standardsoftware, die nur allgemeingültige und parametrierbare Methoden und kein Customizing enthält. Auf die Standardsoftware wird im Rahmen der Einführung bei einem Kunden die Parametrierung als Customizing aufgesetzt und kundenspezifische Einstellungen (z. B. Pfade, Rundungsgenauigkeiten) in Konfigurationsdateien hinterlegt.

eine Vergütung fließt. In konkreten Anwendungen finden wir dann Ausprägungen dieses abstrakten Me-tamodells. Zum Beispiel vermitteln im Kontext einer Versicherung Versicherungsmakler Versicherungspro-dukte an Kunden. Die Kunden zahlen der Versicherung für die Versicherungsleistung eine Prämie bzw. einen Beitrag. Die Versicherung zahlt den Maklern für die Vermittlungsleistung Provisionen. Formell gesprochen sind die Typen Versicherung und Versicherungsmakler Ausprägungen des Metatyps Leistungserbringer, die Prämien- und Provisionszahlungen Ausprägungen von „wird vergütet“ und der Kunde von Leistungsemp-fänger. Das Beispiel ist sehr stark vereinfachend, denn in der Realität gibt es eine Vielzahl von Produkten, verschiedene (in der Regel hierarchische) Vertriebsor-ganisationen und vor allem verschiedenste Berech-nungsregeln für die Vergütung.

Im Kontext des Geschäftskundenbereichs einer Bank erbringt dieser (Leistungserbringer) zum Beispiel euro-päische und internationale Zahlungsverkehrsdienste für Geschäftskunden (Leistungsempfänger). Hierfür ent-richten die Kunden verschiedene Gebühren (transakti-onsbasiert und/oder pauschalisiert) an die Bank.

Das Grundprinzip der individualisierbaren Software ist somit, dass der wiederverwendbare Teil nur das Do-mainmetamodell in seiner Struktur und seiner Dynamik implementiert. Die Individualisierung zu einer konkre-ten Anwendung erfolgt dann durch die Definition der konkreten Anwendungsmodelle.

Die Gesamtheit der Anforderungen ist wichtigWie kommt man nun zu einer individualisierbaren Softwarelösung für eine Anwendungsdomain? Manche Hersteller von Tools bzw. Frameworks und Publikatio-nen legen nahe, dass man nur die richtigen Werkzeuge auswählen braucht, dann kann schon nichts mehr pas-sieren. Das sehen wir nicht so: die unabdingbare Vor-aussetzung ist ein möglichst vollständiges Verständnis der Anwendungsdomain in allen Facetten. Nur dadurch ist es möglich, Abstraktionen in Form eines Domain-metamodells zu bilden, das im Optimalfall für alle Kundeneinsätze zutreffend bzw. zumindest nicht wider-sprüchlich ist.

Eine „echte“ Anforderungsanalyse würde natürlich den Umfang dieser Artikelserie bei Weitem sprengen.

Page 5: Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine An-wendungsdomain • Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert

5www.JAXenter.de javamagazin 2 | 2014

AgileSonderdruck

© Software & Support Media GmbH 5www.JAXenter.de

Deshalb werden wir anhand unserer Beispieldomains charakteristische Anforderungsbereiche herausgreifen und daran zeigen, wie gründlich die Analyse erfolgen muss und wie daraus Entscheidungen für das Domain-metamodell abgeleitet werden. Als Erstes betrachten wir die zu verarbeitenden Daten:

•Leistungen: Je nach Kunde können zu vergütende Leistungen ganz unterschiedlich sein, z. B. ein Versi-cherungsvertrag, eine Beratung an sich, eine vermit-telte Immobilie, eine Finanztransaktion etc. Es gibt aber auch Szenarien, in denen Leistungen aus ande-ren zusammengesetzt sind, z. B. eine Finanzierung, die aus Tranchen besteht oder ein Wertpapierdepot, in dem sich Positionen befinden, die wiederum über eine Reihe von Trades aufgebaut wurden. Es liegt auf der Hand, dass für diese verschiedenen Leistungen jeweils auch unterschiedliche Datenfelder benötigt werden, welche die spezifischen Eigenschaften auf-nehmen. Außerdem ist zwischen dem Typ einer Leis-tung, z. B. Aktien-Trade, und dessen Instanzen, z. B. der konkrete Handel von zehn Stück Daimler-Aktien zu unterscheiden.

•Leistungsempfänger: Die klassischen Leistungsemp-fänger sind individuelle Kunden (natürliche Perso-nen), aber natürlich auch Firmen, deren Abteilungen und Mitarbeiter als Kunden auftreten. Das heißt, wir haben es auch hier mit zusammengesetzten Struk-turen zu tun und müssen auch zwischen Typen und Instanzen unterscheiden.

•Leistungserbringer: Üblicherweise finden sich in die-ser Kategorie Vertriebsmitarbeiter und Vertriebsor-ganisationen sowie Produktgeber, falls es sich bei den Leistungen um Produkte, z. B. eine Versicherung, handelt. Ein Leistungserbringer kann aber auch ein Kunde sein, wenn er beispielsweise einen Neukun-den wirbt. Zusammengesetzte Strukturen sind auch hier die Regel. Der Klassiker ist die hierarchische Vertriebsorganisation, aber auch andere Organisa-tionsformen sind denkbar und müssen unterstützt werden. Auch hier sind Typen und Instanzen zu unterscheiden.

Betrachtet man diese Anforderungen von der techni-schen Seite, fällt sofort auf, dass alle drei Kategorien zwar fachlich völlig andere Dinge darstellen, aber sehr ähnliche technische Eigenschaften haben: Objekte mit frei definierbaren Attributen, aus denen komplexe (je-doch meist hierarchische) Objektstrukturen aufgebaut werden können, sowie die Darstellung von Typen und Instanzen.

Der zweite Kernbereich der Anforderungen betrifft die Regeln, nach denen Leistungen vergütet werden sollen. Diese Regeln stellen auch wieder Typinformati-onen dar. Die Abrechnungen konkreter Leistungen sind die Instanzen. Kundenwünsche in diesem Bereich sind ungeheuer vielfältig und komplex, weil gerade hier oft der Wettbewerb stattfindet. Deshalb folgt nur eine un-

vollständige Liste von Beispielen, was alles durch unser Domainmetamodell abgedeckt sein muss:

•Grundlegende Kennzahlen, die zu bestimmen sind: geplante Vergütung (maximales Angebot erstellt), erwartete Vergütung (Leistung ist in Anbahnung bzw. Auftrag ist erteilt), konkrete Ansprüche, nach-dem eine Leistung tatsächlich erbracht wurde, (Teil-)Zahlungen, Storno bzw. Korrektur für den Fall der Rückabwicklung einer Leistung oder nur der teilwei-sen Leistung.

•Wer vergütet bzw. wird vergütet? Vor allem, wenn Organisationen im Spiel sind, ist alles erlaubt bzw. gewünscht. Ein klassisches Beispiel ist die Vermitt-lung einer KFZ-Versicherung zusammen mit einem Verkehrsrechtschutz durch einen Versicherungsver-treter. Wir haben es mit einem zusammengesetzten Produkt zu tun, dessen Komponenten von verschie-denen Organisationseinheiten der Versicherung stammen. Dementsprechend muss die Vergütung von diesen Einheiten „gesammelt“ werden. Die Vergü-tung erfolgt an den Vermittler, wobei oft dessen Vor-gesetzter auch einen Anteil erhält.

•Vergütung muss nicht immer nur direkt sein. Oft werden Umsatzziele verwendet. Mit dem Erreichen von gewissen Umsatzschwellen kann eine Boni-fikation verbunden werden. Im Falle von Billing werden zusammen mit Umsatzzielen gerne Rabatte eingeräumt. In beiden Fällen haben wir es mit mehr-stufigen Modellen zu tun: Basis sind die konkreten Leistungen. In den Folgestufen werden dann Aggre-gationen der Leistungen berechnet und bewertet.

•Weil die Kundenwünsche noch nicht Herausforde-rung genug sind, gibt es zusätzlich eine Reihe von regulatorischen Vorgaben, die ein System einhalten muss, das Vergütungen berechnet. Die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssyste-me (GoBS) [2] sind in der Regel immer einzuhalten und erfordern unter anderem weitrechende Doku-mentations- und Nachweisfunktionen. Wenn es sich bei den Leistungen um Finanzprodukte handelt, dann

Abb. 3: Lösungsarchitektur

Page 6: Sonderdruck Consileon JM2 14 · • Einführung: Design eines Metamodells für eine An-wendungsdomain • Datenmodell: O/R Mapping, Template Patterns und Abfragen maßgeschneidert

6 www.JAXenter.dejavamagazin 2 | 2014

AgileSonderdruck

© Software & Support Media GmbH6 www.JAXenter.de

kommen noch zusätzliche Dokumentationsregeln nach der Richtlinie über Märkte für Finanzinstru-mente (MiFID) [3] hinzu.

Hier fällt es nun deutlich schwerer, einen offensichtli-chen Lösungsansatz zu finden. Wir brauchen jedenfalls ein sehr flexibles, mehrstufiges Berechnungsmodell, das sehr gut nachvollziehbar ist und optimalerweise jede Berechnung auch noch automatisch dokumentiert. Eher technische Anforderungen gibt es natürlich auch:

•Import-/Export-Schnittstellen•Sicherheit, Rollen-/Rechte-Modell•N-Augenprinzip bei Änderungen kritischer Daten,

Wiedervorlage- und Freigabemechanismen •Mandantenfähigkeit•Performance etc.

Abbildung 3 zeigt schematisch, wie wir all diese Anfor-derungen in eine Softwarearchitektur bringen können. Dabei ist das Grundprinzip, dass die individualisierbare Software ein Domainmetamodell implementiert. Mit dessen Konstrukten werden die oben genannten Daten- und Berechnungsregeln für die Kundenanwendung defi-niert, das so genannte Kundenmodell. Software und das Kundenmodell zusammen ergeben dann die individuelle Lösung für den Kunden.

In der Lösungsarchitektur manifestiert sich die oben diskutierte Beobachtung, dass alle Domaindaten auf der technischen Seite große strukturelle Gemeinsamkeiten haben. Ein generischer O/R Layer setzt ein Objektme-tamodell um, das die technische Basis für alle fachlichen Objekte bildet. Auf dieser Ebene wird auch das Man-dantenmodell abgebildet und ist damit ebenso für alle Arten von Objekten im System verfügbar.

Das fachliche Datenmodell wird durch Business Objects abgebildet. Auch alle statischen Aspekte der Berechnungsregeln werden durch Business Objects re-präsentiert. Der Business Objects Layer implementiert somit das fachliche Datenmetamodell und bildet die Grundlage für unsere Abfrage- und Reporting-Kom-ponente. Durch die Prozesskomponente werden die dynamischen Aspekte des Prozess- und Berechnungsme-tamodells umgesetzt.

Die Benutzeroberfläche unseres Systems wird über Services angebunden, die prinzipiell auch von Fremd-systemen genutzt werden können. In der Regel werden

Fremdsysteme jedoch über spezielle Schnittstellen ange-koppelt.

In Teil 2 unserer Artikelserie werden wir uns den De-tails der Datenmodellierung und dem damit eng in Be-ziehung stehenden Ansatz für Abfragen und Reporting widmen. Teil 3 beschäftigt sich dann mit den dynami-schen Aspekten der Berechnungsregeln und den Schnitt-stellen.

FazitIndividuelle Softwarelösungen und Wiederverwendung müssen sich nicht widersprechen. Mit dem Ansatz einer individualisierbaren Softwarelösung können beide Zie-le erreicht werden. Er basiert auf der Definition eines Metamodells für eine spezifische Anwendungsdomain. Mithilfe dieses Metamodells werden die individuellen Kundenmodelle definiert, die dann zusammen mit dem wiederverwendbaren Softwarekern die Kundenlösung bilden. Eine solche Lösung ist aber nur zu erreichen, wenn die Anwendungsdomain wirklich in allen Facet-ten verstanden ist, denn fehlendes Verständnis führt zwangsläufig zu Fehlern und Lücken im Metamodell, die dann oft durch individuelle Programmierung aus-gewetzt werden. Ein gutes Metamodell erlaubt jedoch die Umsetzung des Großteils der Kundenanforderung ohne Programmierung, was sich dann sehr positiv auf die Wartbarkeit der Kundenlösung auswirkt.

Dr. Hans Schuster ist Partner bei der Consileon Business Con-sultancy GmbH. Er ist für das Produkt ConProv bei der Consileon verantwortlich. Seine Schwerpunkte liegen in den Bereichen IT-Projektmanagement, Daten- und Prozessmodellierung, Big Data und Softwareentwicklung.

Frank Redlich ist Senior Consultant bei der Consileon Business Consultancy GmbH. Sein Spezialgebiet ist die Umsetzung von Ver-gütungslösungen und hierbei insbesondere die Schnittstellen zu Fremdsystemen.

Stefan Kallinich ist Specialist bei der Consileon Business Con-sultancy GmbH. Sein Fokus liegt auf Beratungsthemen vor allem in den Bereichen Vertriebssteuerung und Provisionssysteme.

Links & Literatur

[1] http://tumb1.biblio.tu-muenchen.de/publ/diss/in/2002/stuetzle.pdf

[2] http://bit.ly/qP2Uez

[3] http://bit.ly/1efPsTV