Open Source MDA bei Lufthansa Systems. Peter Friese Stefan Reichert. Organized by:

Transkript

1 Di 1.2 January 22 th -26 th, 2007, Munich/Germany Open Source MDA bei Lufthansa Systems Peter Friese Stefan Reichert Organized by: Lindlaustr. 2c, Troisdorf, Tel.: +49 (0) , Fax.: +49 (0)

2 Open Source MDA bei Lufthansa Systems Abstract Lufthansa Systems hat in einem großen Kundenprojekt im Logistikbereich den Open Source MDA Generator AndroMDA 1 eingesetzt. Dieser Beitrag berichtet von den Erfahrungen, die dabei gemacht wurden. Insbesondere wird auf folgende Punkte eingegangen: Eingliederung des MDA-Ansatzes in den Entwicklungsprozess, Akzeptanz bei den Entwicklern, Beachtenswertes bei der Auswahl des Modellierungstools, Kosten- / Nutzen Betrachtung 1 : Andromeda gesprochen Seite 2

3 Peter Friese heute Studium der Wirtschaftsinformatik (Nordakademie) Lufthansa Systems, Software Engineer Lufthansa Systems, Software Architect Gentleware, Software Architect Speaker Autor Committer JAX, OOP, openarchitecture, ix Konferenz ix, JavaMagazin, EclipseMagazin, OBJEKTspektrum AndroMDA, FindBugs Kontakt: Seite 3 Stefan Reichert heute Studium der Wirtschaftsinformatik (Nordakademie) Lufthansa Systems, Software Engineer Autor JavaMagazin, EclipseMagazin Contributor Committer AndroMDA WickedShell verheiratet, Privatzoo Kontakt: stefan.reichert@lhsystems.com stefan@wickedshell.net Seite 4

4 Model Driven Architecture Agenda Ideen und Konzepte Praxisbeispiel Bewertung Seite 5 Model Driven Architecture Agenda Ideen und Konzepte Seite 6

5 Historische Einordnung der MDA Abtraktionsniveau MDA Frameworks (OOP) (next big wave) Objektorientiert Prozedural Assembler Zeit Seite 7 Kernziele der MDA Erhöhung des Abstraktionsniveaus Alles ist ein Modell Ein Bild sagt mehr als 1000 Worte Fokus auf Fachlichkeit Formalisierung der Spezifikation Metamodelle legen Sprachumfang der Modellierungssprache fest Modellvalidierung Trennung zwischen Fachlichkeit und Technologie / Architektur Plattformunabhängigkeit Wiederverwendbarkeit der fachlichen Konzepte Entwickler können sich auf die Geschäftslogik konzentrieren Homogenisierung der Implementierung Erhöhung der Qualität Seite 8

6 Alles ist ein Modell Spezifikationen der OMG MDA CWM (Common Warehouse Metamodel) Definition von Metadaten für Data Warehousing UML (Unified Modelling Language) Allzweck Modellierungssprache Erstellung von Systemmodellen Grafische Notation MOF (Meta Object Facility) Standard, um Metamodelle zu definieren XMI (XML Metadata Interchange) Austausch von MOF-basierten Modellen Seite 9 Metamodelle Metamodell = Sprache eines Modells OMG: UML ist Metamodell für MDA MDSD: UML muss nicht zwangsläufig Metamodell für Generierung verwendet werden M3 MOF Metametamodell M2 UML Metamodell <<MOF Element>> Class <<UML Metaelement>> Class -name: String <<instanceof>> M1 Modell Person -name: String -alter: int <<instanceof>> <<instanceof>> M0 Instanz (Laufzeit!) name: Peter age: 32 Seite 10

7 Abstraktion durch Modelle / 1 Modell = vereinfachtes Abbild der Realität Modelle werden in der Informatik seit langem eingesetzt Datenmodelle (ERM - Entity Relationship Model) Prozessmodelle (EPK - Ereignisgesteuerte Prozessketten) Softwaremodelle (z.b. OML - Open Modeling Language, PAP Programmablaufplan, Nassi-Shneiderman, ) UML ist heute der Quasi-Standard für Softwaremodellierung verschiedene Diagrammtypen (statisch, dynamisch) große Auswahl an Tools Abstraktionsgrad der UML teilweise zu gering Klassenmodelle werden 1:1 in Software abgebildet bei heutigen Softwaresystemen führt dies zu einem undurchschaubaren Modell von Modell = vereinfachtes Abbild der Realität kann keine Rede sein Seite 11 Abstraktion durch Modelle / 2 Wie kann der Abstraktionsgrad erhöht werden? 1:1 Zuordnung aufgeben Modellierung höherwertiger Konzepte vorher nacher BookingBeanHome BookingBeanRemote <<Service>> BookingService BookingBean Deployment Deskriptor Seite 12

8 Abstraktion durch Modelle / 3 Typen von Modellen Platform Independent Model (PIM) Platform Specific Model (PSM) PIM PSM <<Service>> BookingService BookingBeanHome BookingBeanRemote Deployment Deskriptor BookingBean Seite 13 Abstraktion durch Modelle / 4 Transformationen bilden Modelle ineinander ab Model to Model Transformationen (M2M) (z.b. QVT Queries, Views, Transformations) Model to Text Transformationen (M2T) (z.b. Template Engine) PIM PSM <<Service>> BookingService Transformation (M2M) BookingBeanHome BookingBeanRemote Deployment Deskriptor BookingBean Tf (M2T) public class BookingBeanHome { } public class BookingBeanRemote { } Code <ejb> </ejb public class BookingBean { } Seite 14

9 Abstraktion durch Modelle / 5 Domänenspezifische Sprachen (DSL) können auf Basis von MOF definiert werden oder durch Bildung von UML Profilen <<Service>> AService <<Entity>> AnEntity <<Finder>> findall() <<Finder>> findbyname(name) Semantische Bedeutung der Stereotype wird durch Transformationsregeln festgelegt Seite 15 Plattformunabhängigkeit Aus dem PIM in PSMs für unterschiedliche Plattformen transformieren PSM (Java EE) PIM Transformation (Java EE) <<Service>> BookingService PSM (.NET) Transformation (.NET) Seite 16

10 MDA Generatoren Generator übersetzt Modelle in: Code andere (Zwischen)modelle Bekannte Generatoren / Generatorframeworks: openarchitectureware (Open Source) AndroMDA (Open Source) ArcStyler (kommerziell, komplette MDA-Umgebung) OptimalJ (kommerziell, komplette MDA-Umgebung) Cartridge Konzept vorkonfektionierte Transformationen für marktgängige Frameworks / Plattformen können bedarfsgerecht angepasst werden (anders als bei CASE Tools) Seite 17 Mögliche Artefakte Was kann erzeugt werden? Architekturcode Oberflächen Ablauflogik Deployment / Infrastrukturdiagramme Architekturcode sehr gut geeignet, hohe Codeähnlichkeit Beispiele: Struts (Actions, Config), Spring (Services, DAOs, Context) Oberflächen vor allem für schematische GUIs idealer Kandidat: Databinding / Validierung anhand von Datenmodell Constraints Ablauflogik mittels Sequenz- oder Zustandsdiagrammen wird schnell unübersichtlich nur sinnvoll für grobgranulare Abläufe Infrastrukturdiagramme Modellierung des Deploymentprozesses Erzeugung Systeminformationen für das Monitoring-System Ausfallanalyse Seite 18

11 Herausforderung Oberflächen Abstraktion von der eingesetzten Plattform Hochgradige Individualität Unterschiedliche Paradigmen Modellierung des Layouts Layout ist das Herz einer Oberfläche Informationen häufig sehr reichhaltig Oberflächenfunktionalität Feldabhängigkeiten Databinding und Validierung Oberflächen bedingen sowohl Strukturinformationen als auch Ablauflogik Seite 19 Herausforderung Oberflächen Lösungsansätze M2M Transformationen Schematische GUI M2M Transformationen Inhalt, Struktur und Funktionalität der Oberfläche trennen Schrittweise zusammenführen Trotzdem schwierig Schematische GUI Schema der GUI vorgeben, beispielsweise CRUD Manuelles Anpassen der GUI zulassen ( Oberflächenarchitektur ) Kein reines PIM, sondern angereichertes PSM Eingeschränkte Anwendungsfelder Seite 20

12 Model Driven Architecture Agenda Praxisbeispiel Seite 21 Referenzprojekt - Kombiverkehr Der Kunde Kombiverkehr ist ein logistisches Dienstleistungsunternehmen für Speditionen und Transportunternehmen, das ein europaweites Netz für den Kombinierten Verkehr Schiene- Straße entwickelt, organisiert und vermarktet (Nr. 1 in Europa) Jährlich verlagert das Unternehmen rund 23 Millionen Tonnen Güter respektive rund Lkw-Ladungen von der Straße auf die Schiene Täglich 120 Züge europaweit Kommanditisten: ca. 230 nationale/internationale Spediteure und die Stinnes AG Umsatzerlöse: 300 Mio. Euro Mitarbeiter: 165 ( ) Seite 22

13 Referenzprojekt - Kombiverkehr Die Aufgabenstellung Prozessverlagerungen und Prozessoptimierungen im Bereich Operations Research I I Planung und Steuerung des Transportnetzes I Angebotsplanung, Nachfrage-Verteilung, Planung und Optimierung der Zugkonfigurationen I Steuerung von Reservierungen und Buchungen zur optimalen Auslastung des Transportnetzes, Optimierung der Zugkonfiguration Operations und Handling I Beladeplanung, Optimierung der Ladekapazitäten, Auftragshandling I Auswirkungen auf Kunden und interne Organisation Entwicklung eines Kapazitätsmanagement-Systems für die Funktionsbereiche I I I I Buchung / Auslastung Reservierung / Kapazität Anlieferung / Verladung Ankunft / Abholung Seite 23 Warum MDA? Umfangreiches System Viele wiederkehrende Muster Geschäftslogik -> EVA Prinzip Optimierungsroutinen (Collector, Transformer, Solver) Schnittstellen Ziel: hohe Qualität homogener Code Einhaltung definierter Standards Ziel: Konzentration auf die Geschäftslogik Entwickler sollen sich nicht mit Beiwerk (z.b. Deployment-Deskriptoren) beschäftigen Reduktion der Komplexität (kein Expertenwissen über verwendete Bibliotheken notwendig) Ziel: Faster Time to Market mehr in kürzerer Zeit Seite 24

14 Warum AndroMDA? Unterstützung der Zielarchitektur (Spring / Hibernate) gute Dokumentation vorhanden (Beispielapplikationen, How-To s, Handbuch) Verfügbarkeit von freiem und kommerziellem Support breite Akzeptanz (AndroMDA ist mit oaw eines der meistgenutzten Generator-FWs) Erfahrungen aus einem vorangegangenem Projekt Seite 25 KMS Komponenten PC / Thin Client KMS Core KMS Interfaces Externe Systeme KMS Optimizer KMS DB Seite 26

15 Tools / Frameworks Modellierungstool: Together Generator: AndroMDA IDE: Eclipse Backend: Spring ORM: Hibernate Seite 27 Wirkungskreis des Generators Modell (annotiertes PIM) Services Entities Spring Generator (AndroMDA) Hibernate Software (KMS) GUI Services DAOs OR Mapping DDL Views, Trigger Seite 28

16 Implementierung der KMS Komponenten Große Anteile des serverseitigen Codes werden generiert I I I Service Interfaces und Basisklassen für der Implementierung (Spring) Konfigurationsdateien für die Kommunikation (Spring Konfiguration) Implementierung der Kommunikation (Spring mit HTTPInvoker) Die Implementierung der Business Logik erfolgt per Hand I I Implementieren der generierten Service Interfaces Bei Bedarf Zugriff auf Service Interfaces (anderer Server) Service Interfaces G G Service Implementierung Service Implementierung G Service Interfaces G KMS Core KMS Interfaces G = generiert Seite 29 Softwaretechnische Ansicht <<Service>> BookingService + createbooking(booking: Booking): void + loadbooking(key: int): Booking + findbooking(customerno: int): Booking <<interface>> BookingService BookingServiceBase BookingServiceImpl BookingServiceException applicationcontext.xml (Spring Konfiguration) PIM (Platform Independent Model) PSM (Platform Specific Model) Seite 30

17 Mengengerüst Use Cases : 40 Entwickler : 8 Anzahl Klassen : ~ 6300 Backend, generiert : ~ 2500 Backend, manuell : ~ 800 Frontend, manuell : ~ 3000 Entitäten : 200 Seite 31 Klassischer Implementierungssprozess ohne MDA create table Buchungen... <<deploy>> Der Anwender Framework: Spring startet die Transaktion über den Button Start. Persistenz: Hibernate Protokoll: HTTP, JMS DDL Requirements Architektur for (int i = 0; i <= 42; i++) { service.findall(); <<deploy>> DB } Java Server Designmodell Design Umsetzung Seite 32

18 Implementierungsprozess mit MDA Der Anwender startet die Transaktion über den Button Start. create table Buchungen... <<deploy>> Requirements Analysemodell <<generate>> DDL G DB <<generate>> for (int i = 0; i <= 42; i++) { service.findall(); } for (int i = 0; i <= + 42; i++) { <<deploy>> service.findall(); } Designmodell Java G Java Server Design Umsetzung G = generiert Seite 33 Model Driven Architecture Agenda Bewertung Seite 34

19 Vor- und Nachteile Vorteile Nachteile Mehr Effizienz Weniger Code zu schreiben Weniger Bugs Bugs im Architekturcode können zentral behoben werden Bessere Qualität Versionierung von Modelle nicht ganz unproblematisch Leistungsstarke Rechner erforderlich Hohe Anforderungen an die Modellierungstools Homogener Code Stringente Architektur Gute Akzeptanz bei Entwicklern Dokumentation Ist permanent up-to-date Modelle sind 1st class citizens und keine Schrankware Macht Technologien beherrschbar Entwickler müssen sich nicht mit allen Technologien im Detail auskennen Seite 35 Best practices Modell und Implementierung gleichzeitig einchecken Kontinuierliche Integration (z.b. CruiseControl / Continuum) Feedbackschleifen, Erweiterung des Generators um häufig verwendete Features Seite 36

20 Modelle in der Praxis konkurrierender Zugriff Single File Model: Flaschenhals Multi File Model: besser, handhabbar Teamserver (exklusiver Zugriff): teuer, aber vielleicht die beste Lösung Versionierung Branching / Merging: nahezu unmöglich Problem: Wartung & Weiterentwicklung Partitionierung Bildung von Komponenten / isolierteres Arbeiten möglich Verkürzung der Generatorläufe XMI korrektes XMI ist selten Tools unterstützen meist nur wenige Metamodelle Seite 37 Kritische Punkte Was ist mit Wartung / Weiterentwicklung? Die Mitarbeiter müssen qualifiziert sein / werden ansonsten wird die erstellte Software entstellt Archivierung der kompletten Entwicklungsumgebung Generator / Templates Modellierungstool Refactoring modellbasiertes Refactoring derzeit nicht möglich Refactoring des Codes kann zu ungewünschten Situationen führen Refactoring derzeit nur möglich als Kombination aus Code-Refactoring und manuellen Operationen im Modell Seite 38

21 Kosten / Nutzenvergleich Posten Kosten MDA Kosten traditionell Lizenzen Einarbeitungsaufwand UML-Tool Metamodell Prozess Frameworks Anpassung des Generators Entwicklung XMI Exporter Kosten für Entwicklung Einfacher Usecase Mittlerer Usecase Komplexer Usecase Umbau Domänenmodell Summe x x x x x x x x Seite 39 Kosten / Nutzenvergleich MDA traditionell /1/1 5/5/5 10/10/5 20/20/10 40/40/20 Seite 40

22 Break Even Analyse Fixkosten MDA Ersparnis MDA /1/1 5/5/5 10/10/5 20/20/10 40/40/20 Seite 41 Q & A Seite 42