Flexible Produktlinien

Transkript

1 Flexible Produktlinien Geschäftsregeln in einer modellgetriebenen Architektur Frank Egger und B. Lofi Dewanto OOP 2007

2 Agenda Situation und Herausforderung Lösung: Der Prozess-Manager Produktlinien (PL) und Model Driven Architecture (MDA) Rule-Engine mit Geschäftsregeln Beispiel und Demo Lessons Learned und Diskussion Seite 2

3 Situation und Herausforderung Seite 3

4 Situation (1) Ein Unternehmen möchte von seinen Bestandskunden Informationen einholen: Bilder Verbrauchsdaten Ein Unternehmen möchte Neukunden gewinnen: Marketing-Kampagnen Neue Produktangebote Seite 4

5 Situation (2) Seite 5

6 Herausforderung Abbildung unterschiedlicher Domänen Flexibilität und Transparenz Kombination unterschiedlicher Kommunikationskanäle Druck und Versand Scannen / Inhaltserschließung Call-Center Internet , SMS Zeitnahe Realisierbarkeit Seite 6

7 Eine mögliche Lösung... Es kann nicht nur eine geben! Seite 7

8 ProMI: Prozesssteuerung regelt die unterschiedlichen Kommunikationsformen Plausibilisierung Daten u. Ansteuerung Kommunikationswege ProMI 3 5 Aktivitäten

9 Produktlinien (PL): Gemeinsamkeiten Ähnliche Basiseigenschaften sämtlicher Mandanten und Endkunden Implementierung eines Basis-Domänenmodells Ähnliche Aktivitätstypen: Inbound-, Outbound- und Non- Directional Implementierung von Basiskonfigurationen (XSD, XML) Ähnliche Import- und Export-Formate (CSV, FIX, XML) Implementierung eigener Domain Specific Language (DSL) Verarbeitung großer Datenmengen Hohe Performanz! Basis: ProMI Platform (Core) Entwicklung für die Wiederverwendung! Seite 9

10 platform.core Gemeinsamkeiten (Basis): Basismodell, Basiskonfigurationen sowie Abstraktion der Import- und Export-Struktur Entwicklung für die Wiederverwendung

11 Produktlinien (PL): Unterschiede Details der einzelnen Mandanten und Endkunden Verwendung der Domänenmodelle mit Klassendiagrammen Geschäftsprozesse der Inbound-, Outbound- und Non- Directional-Aktivitätstypen Verwendung der Geschäftsregeln mit Aktivitätsdiagrammen Daten zum Import und Export Verwendung der eigenen DSL für die Realisierung der Daten-Validierung und -Transformation Domänen: Energiedatenmanagement, Gesundheitsdatenmanagement Entwicklung mit Wiederverwendungsansatz! Schwerpunkt dieses Vortrages Seite 11

12 Unterschiede (Domänen): Verwendung der Domänenmodelle, Geschäftsregeln und DSL Schwerpunkt dieses Vortrages domains.xxx Entwicklung mit Wiederverwendungsansatz

13 Bird s Eye View: Produktlinien-Architektur Mandant 1-n nterschiede (Domänen) Gemeinsamkeiten (Basis)

14 Einsatz der Model Driven Architecture Basis ProMI.platform.core: Modellierung und Generierung des Basismodells UML-Klassenmodelle Java SpringFramework, Hibernate Domänen ProMI.domains.evu, ProMI.domains.egk: Modellierung und Generierung der Domäne UML-Klassenmodelle Java SpringFramework, Hibernate Modellierung und Generierung der Geschäftsregeln UML-Aktivitätsmodelle Drools (JBoss Rules) XML Seite 14

15 Rule-Engine mit Geschäftsregeln Seite 15

16 Was ist eine Rule-Engine? Software, die auf einer bestimmten Menge an Fakten eine gewisse Menge an Regeln anwendet und daraus Konsequenzen ableitet Schema für Regeln: Auswertung der Regeln: WHEN <conditions> THEN <actions> Vorwärtsverkettung, datengetrieben: Wenn heute der 22. Januar ist, dann öffnet die OOP! Rückwärtsverkettung, zielgetrieben: Wann beginnt die OOP? -> 22. Januar Seite 16

17 Vorteile einer Rule-Engine Effizienz und Skalierbarkeit Regeln werden in Graphen abgebildet und können so besser optimiert werden (Zusammenführung, Indexing, Hashing ) Wartbarkeit Deklarative Beschreibung (was statt wie) Zentrale Wissensdatenbank (Rule-Base) Trennung der Daten und Logik Flexibilität Erweiterung / Änderung während Laufzeit ohne Programmierung und Compilierung möglich! Seite 17

18 Geschäftsregeln in ProMI Produkt: Drools (JBoss Rules) Verwendung: Bestimmung des/der nächsten Aktivitätstyp(en) (NextActivityType) auf Basis des aktuelle Aktivitätstypen (CurrentActivityType) Benötigte Informationen (Fakten): Aktuell ausgeführter Aktivitätstyp (Zustand) Aktuell bearbeitetes Client-Objekt (Endkunde) Liste sämtlicher für dieses Client-Objekt vorher durchgeführten Aktivitäten Zur Erinnerung Aktivitätstypen == Inbound, Outbound und Non-Directional Seite 18

19 Beispiel von Geschäftsregeln in ProMI (1) Seite 19

20 Beispiel von Geschäftsregeln in ProMI (2) Seite 20

21 Komplexes Beispiel für Geschäftsregeln in ProMI Unternehmen initiale / aktualisierte Kundenstammdaten Druck- und Lettershop Druckdaten anzurufende Kunden Versand Anschreiben, Antwortformulare, Anträge, Info.-Flyer etc. Call Center Call-Ergebnisse Nachfass (Outbound) Anrufe (Inbound) Kunden evtl. direkte Erfassung von Kundendaten Niederlassungen Ergebnisdaten, Statistiken / Berichte Legende: Verantwortung Unternehmen Kundendaten als Referenz für Prüfungen Prozesssteuerung Annahme- und Prüfstelle Ergebnisdaten Autorisierungsdaten Internetportal physisch Einlieferung von Rückläufern evtl. Login und Upload von Kundendaten evtl. elektronische Weiterleitung erfasster Kundendaten Internetportal Verantwortung DPAG evtl. elektronische Weiterleitung erfasster Kundendaten

22 Beispiel: Energieversorgungsunternehmen (EVU) EVU Deutsche Post AG EVU-Kunden EVU benötigt Verbrauchsdaten von einer Vielzahl von EVU-Kunden Die DPAG organisiert die Beschaffungsmaßnahme und wickelt diese komplett und zeitgerecht ab Der Kunde will seine Verbrauchsdaten ohne großen Aufwand zur Verfügung stellen können

23 Demo ProMI.domains.evu Verwendung von Geschäftsregeln Seite 23

24 Demo Seite 24

25 Lessons Learned und Diskussion Seite 25

26 Vorteile der Geschäftsregeln Deklarative Regelbeschreibungen Verbesserung der Systemkonfigurierbarkeit Ableitung bzw. Generierung aus Aktivitätsdiagrammen Übersichtlich und verständlich Ermöglichung der Orchestrierung von fein-granularer Anwendungslogik Analog zur Business Process Execution Language (BPEL) für die Orchestrierung von grob-granularen Anwendungslogik (Services) Verbesserung der Systemflexibilität Seite 26

27 Test-Aspekte Unit-Test: Basis (ProMI.platform.core) nicht lauffähig Unit-Test unabdingbar! Integrations-Test: Komplexe Abhängigkeiten der Domänen von der Basis Komplexe Geschäftsregeln Integrations-Test ohne Deployment sehr wichtig! Seite 27

28 ModellPunK-Dreieck (1) Gleichgewicht von Modellieren, Programmieren und Konfigurieren Seite 28

29 ModellPunK-Dreieck (2) *? + - Zu viel Modellieren (Domänenmodelle, Regeln) bedeutet (immer noch): Längere Transformations- bzw. Generierungszeit! Längerer Zyklus beim Programmieren Compilieren Test Produktivität sinkt! Seite 29

30 Diskussion Danke für Ihre Aufmerksamkeit! Frank Egger B. Lofi Dewanto Seite 30