Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent

Transkript

1

2

3 Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

4 Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann 123

5 Gerhard Rempp Martin Löffler Mark Akermann Jens Lehmann ISSN ISBN e-isbn DOI / Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Springer-Verlag Berlin Heidelberg 2011 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: KünkelLopka GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (

6 ...für Yvonne und Julian

7 Vorwort Liebe Leserin, lieber Leser, Innovationen werden anfangs maßlos überschätzt, auf Dauer aber maßlos unterschätzt. Achim Berg, ( 1964), Chef Microsoft Deutschland, Quelle: Kölner Stadt-Anzeiger Querverweise: Medienlandschaft Lange ist es her, als MDA oder SOA in der Softwareentwicklung noch als Hype galt. Die euphorischen Vertreter der Softwareindustrie stellten uns damals MDA bzw. MDSD in zahllosen Vorträgen und Publikationen als die wahrscheinlich einzige Art dar, einen erfolgreichen Softwareentwicklungsprozess zu gestalten und zukunftsfähige Software zu erstellen. Also folgten wir gutgläubig den Protagonisten und versuchten uns technisch dem Ziel zu nähern. Meist holten wir uns jedoch eine blutige Nase, anstatt den vorhergesagten Erfolg zu erzielen. Es formierten sich daraufhin die Antagonisten und argumentieren, dass MDA und SOA aufgrund des hohen Abstraktionsgrads und der Komplexität so nie funktionieren werde und plädieren dafür, die Anwendungsentwicklung so weit zu simplifizieren wie es nur geht. Als Credo gelten hier leichtgewichtige Frameworks und Praktiken wie z.b. Convention over Configuration die das komplexe Vorgehen eliminieren und zum gewünschten Erfolg führen sollen. Indikatoren wie kurze Entwicklungszeiten scheinen den Antagonisten auf den ersten Blick ja auch recht zu geben. Die Realität zeigt uns heute jedoch eine Vermehrung von schlecht integrierten Insellösungen, die uns im Blick auf Wartungskosten vor viele Herausforderungen stellt. Negativ fallen vor allem ad hoc SOA-Anwendungen auf, die nach dem CRUD- Muster ohne übergreifende Integrationsmethode produziert wurden. Man gewinnt teilweise den Eindruck, als ob sich alle Anforderungen und Services auf Basis der Create-, Read-, Update- und Delete-Operationen in einer Datenbank abbilden lassen. Plattformübergreifende Integrationskonzepte und prozessorientierte Automatisierungsszenarien werden bei diesem Ansatz entweder nachgelagert implementiert oder einer Integrationsabteilung überlassen. Diese müssen die lokal VII

8 VIII Vorwort duplizierten Stammdaten und Benutzerverwaltungen dann per SOA-Mitteln replizieren, womit die Prozessorientierung ad absurdum geführt wird. Wiederverwendung verlangt also eine übergreifende Strategie und das Wissen, wie von der Anforderung bis zur Implementierung zentrale Services, Komponenten und Daten gewinnbringend eingesetzt werden können. Dazu bedarf es einer vermittelnden Einheit - das zentrale Modell gepaart mit einem methodischen Vorgehen. Wollen wir zudem der vom Business geforderten Agilität und dem Automatisierungsgrad heute und in naher Zukunft nachkommen, so muss bei dem Ansatz ein nahtloser Übergang von der Fachmodellierung bis in die Zielarchitektur möglich sein, und zwar in einem Roundtrip- statt in einem einmaligen Wasserfall-Ansatz. Wir benötigen also eine Art serviceorientierte Softwarefabrik, die einen kohärenten Softwareentwicklungsansatz von der Fachanforderung über Anwendungsdesign und Entwicklung bis zur Wartung und Modernisierung liefert. Fragen, wie die bestehenden Notationen UML und BPMN2 vereint werden und sich Modelle auf das Wesentliche reduzieren lassen, müssen beantwortet sein, um modellgetrieben zu einer effizienten serviceorientierten Anwendungslandschaft zu gelangen. Bei einem solchen Ansatz müssen wir die wichtigsten Innovationen in der Softwareentwicklung aufgreifen und uns dabei schon auf methodischer Ebene zu nutze machen. Synthetisierende Ideen wie MDA, domänenspezifische Sprachen (DSL), Software-Produktlinien, Architekturansätze wie Serviceorientierung und agile Frameworks, gepaart mit einer Methodik können dann erst zu einem durchgängigen Softwareentwicklungsansatz führen. Alle, die an einem solchen durchgehendem Vorgehen interessiert sind und bisher die Aspekte SOA, BPMN, UML oder MDA nur als Einzelteile kennen gelernt haben, werden mit diesem Buch an die Hand genommen und von der Anforderungsanalyse bis zum lauffähigen Endsystem durch das entwickelte MDSOA Vorgehensmodell geführt. Die Autoren haben es in erstaunlich einfacher Weise geschafft, ein praxistaugliches und zugleich durchgängiges Vorgehensmodell zu beschreiben, ohne sich in einem Labyrinth von Details zu verlieren. Genau diese veranschaulichende Beschreibung hat mir bei meinem letzten modellgetriebenen SOA Projekt gefehlt und mich daher viel Mühe gekostet, die notwendigen Modellkonventionen zu entwickeln und das gesamte Team auf Linie zu bringen. Hervorzuheben ist, dass bei dem niedergeschriebenen Ansatz genug Freiräume sind, seine individuellen Anforderungen und Architekturvarianten mit einzuweben und seine eigene MDSOA Version zu schaffen. Für mein nächstes Projekt wird das Buch auf jeden Fall Pflichtlektüre sein. München, Deutschland, März 2011 Berthold Maier

9 Danksagung Wir möchten uns ganz herzlich bei folgenden Personen bedanken, die uns direkt oder indirekt bei der Erstellung dieses Buches unterstützt haben. Herrn Christian Kössel, die Diskussionen um die beste Umsetzung der EJB3- Generierung haben uns vorangebracht und so sind wertvolle Hinweise aus der Praxis eingeflossen. Dr. Guido de Melo hat uns beim Einsatz des M2M-SDK unterstützt. Herzlichen Dank Guido, hast uns wirklich weitergebracht! Herrn Christoph Bergner der uns bei der Kontaktaufnahme mit dem Verlag zur Hand ging und uns mit der Zusage seiner Unterstützung Türen geöffnet hat. Der Geschäftsführung der MID GmbH, die uns mit der zur Verfügungsstellung von Infrastruktur, moralischer Unterstützung und Entscheidungen zur Umsetzung unserer Anforderungen im Produkt sehr geholfen hat und die immer an uns geglaubt hat. Martina Stiglmaier und Jens Hamann, die uns insbesondere für das Kap. 10 Dokumentation wertvollen Input geliefert haben und für ihre sehr hilfreichen Tipps zum Thema. Thomas Henninger für seinen Rat und seine Beiträge in den Kap. 2 und 5. Maria Deeg, die tiefgehenden Diskussionen und die gemeinsame Erstellung von Schulungsunterlagen zum Thema fachliche Servicemodellierung mit ihr haben für Kap. 5 wertvollen Input geliefert. Allen Entwicklern der MID und hier ganz besonders Oliver Pera, Josef Nagl, Roland Patka und Ilias Keser für Ihre Unterstützung und ihr offenes Ohr sowie die Zeit, die sie in viele Details der Umsetzung investiert haben. Ganz besonders Martin Starzmann, der unsere kleine Geschichte um den Meisterschüler Sean so wunderbar und kreativ illustriert hat. Allen Freunden, die wir nicht im Einzelnen genannt haben, ohne die aber weder das Tool noch das Buch möglich gewesen wären. Euer Feedback und eure kritischen Anmerkungen haben uns zu Höchstleistungen angetrieben! Unseren Familien und unseren Partnern, die es toleriert haben, dass wir so viel Zeit in ein Buch gesteckt haben und nicht die Geduld mit uns verloren haben, auch wenn wir doch hin und wieder sehr kurz angebunden waren. Stuttgart, Deutschland, April 2011 IX

10 Inhaltsverzeichnis 1 Einleitung... 1 EinBuchfürdenPraktiker... 2 Kapitel 2 Grundlagen Kapitel 3 Die Modellierungsmethodik Kapitel 4 Das Beispiel Überblick über alle Phasen... 4 Kapitel 5 Initiation Kapitel6SystemEvaluation... 5 Kapitel7ArchitectureProjection... 6 Kapitel8ConstructionundDeployment... 6 Kapitel9Automatisierung... 7 Kapitel 10 Dokumentation... 7 Kapitel11AusblickundFazit... 7 Kapitel 12 Anhang und Sachverzeichnis Formalitäten Viel Spaß! Grundlagen MDA&MDSD Model Driven Architecture (MDA) der OMG Modelbasierte Softwareentwicklung (MDSD) Modellierungssprachen UMLundDialekte BPMN BPMN-WissenzumBuch Modellierungswerkzeuge MIDInnovator AndroMDA Eclipse Webservice-Technologien DieSOAPlattform Literatur Links XI

11 XII Inhaltsverzeichnis 3 Die Modellierungsmethodik Model Driven SOA (MDSOA) MDSOAAblauf Unterstützende Prozesse und Tätigkeiten Phase Initiation Fachliche Anforderungen aufnehmen Geschäftsprozesse aufnehmen Fachliche Services definieren Phase System Evaluation Phase Architecture Projection Phase Software Construction Rollen Requirements-Engineer Fachexperte Business-Analyst Stakeholder Anforderungsanalytiker System-Architekt System-Entwickler Testingenieur Software Asset Management Operations Management Glossar Vorgaben Ergebnisse aus Initiation Ergebnisse aus Evaluation Ergebnisse aus Architecture Anwendung(en) Anforderungsspezifikation Literatur Links Das Beispiel Überblick über alle Phasen Rückblende M 3 inkurzfassung Motivation Was soll mit dem Beispiel vermittelt werden? Die Phasen, das Vorgehen, eingesetzte Tools und Diagramme Phase Initiation (INI) Phase System Evaluation (EVA) Phase Architecture Projection (ARC) Phase System Construction (CON) Besonderheit Datenbank OOER-Mapping und EJB3 Annotations Zusammenfassung Literatur

12 Inhaltsverzeichnis XIII 5 Initiation Ziele und Vorgehen in der Phase Initiation Prozessbeschreibung des Fachbereichs ErsteErfassungderProzesse Prozess Investitionsantrag mit automatischer Bestellung Erstellung des Prozessmodells des Fachbereichs Entwicklung der Prozess-Skizzen Analyse der fachlichen Prozess-Skizzen Defizite in der Modellierung Modellierungsstil Gesamtablauf über Kollaboration Fazit zur Entwicklung der Prozessskizzen Ableitung der fachlichen Services KategorisierungvonServices Servicetypen Vorgehen bei der Ableitung von Serivces BestPracticezurService-Identifikation Umsetzung in der Modellierung Einordnung in ein Gesamtprozessmodell Die Prozesslandkarte Die Hauptprozesse DieTeilprozesse Die Arbeitsschritte Modellergänzungen Zusammenfassung Literatur System Evaluation Ziele und Vorgehen in der Phase Evaluation Der Übergang von Initiation nach Evaluation Fachklassen als logisches Datenmodell Der Investitionsantrag Exkurs: Abbildung der Fachklassen auf ein konzeptionelles Datenmodell und Mapping zum physischen Datenbankmodell Maskenflüsse (Workflows) Technisches Prozesse Technische Services Servicekollaboration Prozessautomatisierung Modellierung von Anwendungsfällen Zusammenfassung Literatur Links

13 XIV Inhaltsverzeichnis 7 Architecture Projection Ziel/Überblick Der Übergang von Evaluation nach Projection An Innovator Object excellence anmelden Mapping Evaluation Projection Schichtenarchitektur Datenhaltungs-Schicht Service-Schicht Design der technischen Architektur der Services Presentation- Schicht Design der technischen Architektur des Webinterfaces Zusammenfassung Literatur Construction und Deployment: Generierung, Implementierung und Integration Einleitung Überblick: Vorgehen in der Construction Phase Generierung der Artefakte Systemlandschaft Service-Implementierung Deployment Zusammenfassung Literatur Links Automatisierung Modelltransformationen Die Ablaufsteuerung Die Modelltransformation InplaceTransformation(InnovatorAPI) Konfigurieren einer Engineeringaktion Entwickeln einer Engineeringaktion M2T Transformationen (OAW-Generatoren) Generierung SessionBean Der Prüfmanager des Innovators Die Oberfläche des Prüfmanagers Die Konfiguration des Prüfmanagers Eigene Prüfungen schreiben Die Erweiterung des Prüfmanagers Dokumentation Dokumentation ist notwendig Automatisierte Erzeugung von Dokumentation mit dem InnovatorforBusinessAnalysts Der Konfigurationseditor

14 Inhaltsverzeichnis XV Die Ansicht Dokumentation Die Ansicht Ausführungsrechte Generierung der Dokumentation Literatur Ausblick und Fazit Ausblick weiteremöglichkeiten AusführbaresBPMN Direkte Anbindung an ein Service-Repository Generierung von Oberflächen Generierung von ausführbaren Regel-Services Direkte Anbindung an Regel-Maschinen (Rule-Engines) REST-based WebServices Andere SOA-Plattformen Fazit Anhang SOPERA Service-Entwicklung Schritt für Schritt Service-Deployment Schritt für Schritt Service-Test Schritt für Schritt InnovatorforBusinessAnalysts Navigation Abbildung von technischen Services im Modell ServicePaketeundNamensraum ServiceInterface und Operationen Nachrichten und Fehler Strukturen von Nachrichten Excel-Vorlage zur Prozesserfassung Sachverzeichnis Die Autoren

15 Kapitel 1 Einleitung Abb. 1.1 Sean macht sich auf den Weg Sean hatte sich von allen verabschiedet. Seine Mutter hatte ihn ein letztes Mal umarmt. Sein Vater, reserviert wie immer, hatte ihm die Hand gedrückt, ihm auf die Schulter geklopft und ihm verstohlen noch einen weiteren Schein zugesteckt. Seine Freunde hatten ihm Glück gewünscht und bei manchem blitze etwas Neid in den Augen. Jetzt war er auf dem Weg. Am Morgen hatte er zügig die Nonabu-Sümpfe umgangen. Jetzt lag das Dorf schon einen Tagesmarsch hinter ihm und er befand sich in der Einöde des Vorgebirges. Sean erreichte die Ausläufer des Babschinar und blickte auf die majestätischen schneebedeckten Gipfel des Massivs. Sie waren seine erste Hürde, welche ihn von seinem endgültigen Ziel, ein Meister zu werden, noch trennten. Nun, Babschinar musste von jedem bezwungen werden, der es zu einem Meister in den Sprachen der Ingenieure bringen wollte. Die Sprachmeister suchten immer G. Rempp et al., Model Driven SOA, Xpert.press, DOI / _1, C Springer-Verlag Berlin Heidelberg

16 2 1 Einleitung fleißige Adepten, denen sie ihr Wissen und ihre Erfahrung weitergeben konnten. Im Gegenzug halfen die Adepten den Meistern in der unwirklichen und kargen Umgebung ihr tägliches Brot zu verdienen. Sean atmete tief durch, nahm sein Bündel wieder auf und machte sich an den Aufstieg. Das vorliegende Buch gibt Ihnen einen umfassenden Überblick über modellgetriebene Softwareentwicklung von SOA 1 Anwendungen. Dabei hatten die Autoren vor allem die Praxis im Blick. Aus diesem Grund wurden zwei Schwerpunkte gesetzt: Das praxisgerechte Vorgehen, gepaart mit einer entsprechenden Methodik. Die Anwendung der genannten Modellierungssprachen und -notationen, so wie der verwendeten Werkzeuge und Frameworks. Woher kam die Motivation solch ein Buch zu schreiben? Ein Buch für den Praktiker Die Autoren sind Berater, die seit Jahren die verschiedensten Projekte mit unterschiedlichsten Zielsetzungen begleiten. Dabei versuchen sie vor Ort und mit dem Kunden die bestmögliche Lösung zu finden. Die Projekte lenken den Blick meist auf eine Hauptaufgabe. So haben manche zum Beispiel das Ziel, ein Standardvorgehen für die einheitliche Erstellung von umfassenden Pflichtenheften zu definieren. Pflichtenhefte werden danach automatisiert aus den Modellen generiert. Dabei liegen Geschäftsprozesse und die objektorientierte Analyse im Fokus. Andere Projekte beginnen direkt mit der System-Analyse. Das Ziel ist es vordergründig Sourcecode oder allgemeiner verschiedenste Artefakte zu generieren, welche auf einer gewählten Plattform ausführbar sind. Das können zum Beispiel EJB3 Quellcode, C#-Code oder WSDL Dateien sein. Durch die Hintertür wird dabei meist auch ein Vorgehen oder eine Methodik definiert, obwohl dies zunächst gar nicht das Ziel an sich war! Nicht alle Projekte bringen eine eigene Methodik oder ein Vorgehen mit. Trotzdem wird irgend ein Vorgehen oder eine Methodik immer gelebt! Meist ist diese leider nur unzureichend dokumentiert. Modellgetriebene Softwareentwicklung hilft hier. Innerhalb der MID ist im Laufe der Jahre die Modellierungsmethodik M 3 entstanden. Ziel war eine schlanke und praxisbezogene Methodik, die leicht für Kundenprojekte anpassbar ist und idealerweise werkzeuggestützt angewendet werden kann. Die Autoren haben die M 3 in verschiedenen Projekten angewendet, 1 Service-oriented Architecture (deutsch: serviceorientierte Architektur, dienstorientierte Architektur).

17 Ein Buch für den Praktiker 3 angepasst und erweitert. Mit der M 3 in der Tasche und der Erfahrung ihrer Anwendung in verschiedensten Projekten wuchs das Bedürfnis eine ganzheitliche Sicht und die besten Ansätze zu dokumentieren. Das hat mit einzelnen HowTo-Dokumenten für Kunden und Kollegen begonnen. Dazu kamen weitere wissenschaftliche und studentische Arbeiten, wie Bachelor- oder Master-Arbeiten. Daraus wurde dann der Wunsch geboren, all das gesammelte Wissen in einem Buch aufzuarbeiten. Damit kann ein umfassender und durchgängiger Blick auf die gesammelten Erfahrungen der Autoren vermittelt werden. Ach ja, und wie oft hat man nicht schon gesagt da sollte man eigentlich ein Buch drüber schreiben. Nun, wir haben es jetzt getan und hoffen, dass Ihnen der Inhalt einen echten Nutzen für ihre tägliche Arbeit bringt. Wie ist dieses Buch zu lesen? Das Buch ist in aufeinander aufbauende Kapitel eingeteilt. Das bedeutet, die natürliche Art und Weise dieses Buch zu lesen ist, von vorne nach hinten. Das heißt aber noch lange nicht, dass man auch so vorgehen muss. Jemand der schon Erfahrung gesammelt hat und eventuell schon modellgetrieben vorgegangen ist, der kann nach eigenem Ermessen das eine oder andere Kapitel überspringen. Damit der Leser sich hierzu ein Bild machen kann, gehen wir zunächst auf die einzelnen Kapitel ein. Ein grundsätzlicher Punkt noch vorne weg. Dieses Buch ist ein Buch für Profis und wir setzen eine gewisse Erfahrung in der praktischen Umsetzung von IT-Projekten voraus. Das heißt nicht, dass es nicht auch für Anfänger und Neueinsteiger geeignet wäre. Wir möchten nur darauf hinweisen, dass wir einzelne Themen nicht von Null betrachten und auch nicht einzelne Details vertiefen, die für das Verständnis der Inhalte dieses Buches nicht notwendig sind. Dazu gibt es Lehr- und Einführungsbücher, auf die wir in den einzelnen Kapitel hinweisen und die auch in der Literaturliste aufgeführt werden. Kapitel 2 Grundlagen Kapitel 2 stellt ihnen alle Informationen zur Verfügung, die sie für das weitere Verständnis der nachfolgenden Kapitel benötigen. Dabei haben wir Wert darauf gelegt den Inhalt auf das Notwendige zu beschränken. Dieses Kapitel gibt ihnen einen Überblick über die verwendeten Sprachen und Notationen. Es werden die Grundlagen zu UML 2, SoaML, SysML und BPMN 2.0 aufgezeigt. Dabei erfahren sie auch, warum wir welche Notation für was verwenden oder auch warum gerade nicht. Außerdem erhalten sie eine Einführung in die Entwicklung von Modelltransformationen und Generatoren. Da wir hierzu oaw und Java verwenden, werden auch hier die Grundlagen gelegt, die für das weitere Verständnis vorausgesetzt werden müssen. Ein kurzer Abriss über MDA (Modeldriven Architecture) der OMG und die Gegenüberstellung zu MDSD (Modeldriven Softwaredevelopment) hilft die eingesetzte Methodik besser zu verstehen, da sie auch Anleihen aus dem MDA Ansatz nimmt, aber sich nicht nur auf die UML beschränkt.

18 4 1 Einleitung Zu guter Letzt werden auch die Plattform und die verwendeten Werkzeuge vorgestellt. Dies ist wichtig, weil mit der Wahl der Plattform implizite Randbedingungen geschaffen werden, die sich auf die Methodik im plattformnahen Bereich und natürlich auf die Generierung auswirkt. Auch ist zu entscheiden, was aus Modellen erzeugt wird und was besser mit den Werkzeugen der Plattform umgesetzt wird. Nach Kap. 2 sind sie gut gerüstet, den Rest des Weges zusammen mit unserem Adepten Sean zu gehen, der sich aufgemacht hat, ein Meister zu werden! Kapitel 3 Die Modellierungsmethodik Die deutsche Wikipedia beschreibt sehr treffend, was in der Softwareentwicklung unter einer Methode zu verstehen ist: Als Methode bezeichnet man in der Softwaretechnik ein einzelnes Verfahren zur Softwareentwicklung. Mehrere Methoden zusammen bilden den Softwareentwicklungsprozess. Eine Methode beschreibt dabei für einen bestimmten Anwendungsbereich eine Vorgehensweise. 2 Ganz in diesem Sinne beschreibt MDSOA 3 die Verwendung verschiedener Methoden und Notationen, die Verfeinerung der Modelle über automatisierte Modelltransformationen und die Generierung von Artefakten mit Generatoren. Unser Anwendungsbereich in diesem Buch ist die serviceorientierte Architektur. Grundsätzlich ist MDSOA für beliebige Softwareentwicklungsprozesse anwendbar. Kapitel 3 beschreibt die Methodik und die verwendeten Methoden auf einer abstrakten Ebene. Die Methodik mit ihren einzelnen aufeinander aufbauenden Phasen tendiert grundsätzlich dazu relativ stabil zu bleiben. Hingegen ist die Ausgestaltung im Projekt und die konkret verwendete Notation relativ variabel. MDSOA kann somit für SOA, aber auch für SAP, EJB3 und den Embedded Bereich eingesetzt werden. Dabei bleibt der grundsätzliche Charakter der einzelnen Phasen erhalten. Es dürfte aber klar sein, das die Analyse eines Parkleitsystems mit der SysML den Schwerpunkt auf anderen Inhalte legt, als die Entwicklung einer SOA Anwendung. Kapitel 4 Das Beispiel Überblick über alle Phasen Für diejenigen unter den Lesern, die selbst schon Erfahrungen mit dem MDSD Ansatz gemacht haben und die sich rasch einen Überblick verschaffen wollen, empfehlen wir Kap. 4 Das Beispiel Überblick über alle Phasen. Experten MDSOA baut auf die MIDModellierungsmethodik M 3 auf.

19 Ein Buch für den Praktiker 5 der modellgetriebenen Softwareentwicklung können sich hier informieren und die dargestellte Methodik mit ihren ganz persönlichen Ideen und Vorgehensweisen vergleichen. Kapitel 4 geht auf die konkrete Ausgestaltung der MDSOA im Zuge der Entwicklung von SOA ein. Es wird für die jeweilige Phase beschrieben, welche Notationen verwendet werden, welche Inhalte damit dargestellt werden, welche Modelltransformationen durchgeführt werden und welche Ergebnisse am Ende jeweils vorliegen. Es nimmt aber noch nicht alle Details vorweg, die in den Kapiteln für die jeweiligen Phasen tiefer diskutiert werden. Kapitel 4 sollte aus unserer Sicht auf jeden Fall gelesen werden, bevor man in den nachfolgenden Kapiteln in die tieferen Details der einzelnen Phasen eintaucht. Kapitel 5 Initiation Nach den notwendigen Grundlagen und der Übersicht geht es nun in Kap. 5 in die erste Phase der MDSOA. Es wird gezeigt, wie aus einem initialen Wurf der fachlichen Aufnahme der Geschäftsprozesse in mehreren Iterationen ein detailreicher und ausformulierter Geschäftsprozess mit der BPMN 2.0 modelliert wird. Dabei wird auch auf die einzelnen Entscheidungen eingegangen, die der Businessanalyst gefällt hat. Da die Initiation Phase die Grundlage aller folgenden Phasen bildet SOA soll ja idealerweise Geschäftsprozesse optimal unterstützen ist sie eine sehr wichtige Phase. Die Inhalte werden von den Fachexperten bestimmt und spiegeln das gelebte oder erwartete Verhalten aller Beteiligten an einem Geschäftsprozess wider. Grundsätzlich dienen die modellierten Inhalte dazu, die Fachlichkeit zu verstehen und zu durchdringen. Um die späteren Anwender besser zu unterstützen muss verstanden werden, wie diese täglich ihre Arbeit erledigen. Die Inhalte sind Voraussetzung für einen vernünftigen und zielgerichteten Serviceschnitt. Immer wieder Anlass zur Diskussion: die Granularität von Services. In der Initiation Phase werden die Services nach fachlichen Anforderungen geschnitten. Wie genau und warum, darauf geht diese Kapitel ebenfalls ein. Alles wird anhand des durchgängigen Beispiels transparent gemacht. Kapitel 6 System Evaluation Die Initiation Phase ist durch die Erfassung der fachlichen Anforderungen bestimmt. Sie bildet die Grundlage für das weitere Ausarbeiten der Inhalte in der Evaluation Phase. In der Evaluation Phase wird ausgeführt, wie für die fachlichen Prozesse der Initiation Phase die technischen Prozesse definiert werden. Dabei wird auch entschieden, was aus dem fachlichen Prozess automatisiert auf einer Prozessengine ablaufen soll.

20 6 1 Einleitung Inhalt ist zunächst der Abgleich der fachlichen Services gegen eventuell schon vorhandene Services. Kann die Funktionalität nicht vollständig abgedeckt werden, dann müssen vorhandene Services angepasst oder neue Services spezifiziert werden. Ein weiteres Thema ist, welcher Typ von Service verwendet werden soll und wie genau die Nachrichten formuliert werden. Für die Daten werden entsprechende Fachklassen definiert, welche die Grundlage für die Persistierung und später für die Generierung von Entity-Beans sind. Es wird gezeigt, wie der technische Prozess mit den vorhandenen und neuen Services aufgebaut wird und wie über Service-Kollaborationen der Grundstein für die Generierung von BPEL gelegt wird. Auch hier machen Beispiele die Entscheidungen und Modellinhalte transparent. Kapitel 7 Architecture Projection Das Kapitel Architecture Projection geht auf die Architektur und das Design ein. Zunächst wird gezeigt, wie eine n-tier-architektur im Modell abgebildet werden kann und wie über Modelltransformationen Inhalte aus der Evaluation Phase auf Komponenten und Klassen in der Architecture Phase abgebildet werden. Die erzeugten Komponenten werden weiter ausgestaltet, denn aus ihnen werden die zu implementierenden Services generiert. Ebenso die entsprechenden Klassen der Persistenzschicht. Für das leichtere Verständnis werden außerdem Architekturdiagramme erstellt, die zeigen, wie die einzelnen Komponenten miteinander zusammenhängen. Der Designaspekt zeichnet sich zum Beispiel durch die genauere Typisierung von Komponenten, Klassen und Attributen aus. Es wird am Beispiel erklärt, welche Zielartefakte aus den Inhalten der Architecture Phase generiert werden. Kapitel 8 Construction und Deployment Das Kapitel Construction und Deployment führt aus, wie alle notwendigen Artefakte zum Bau einer SOA Anwendung aus den diversen Modellinhalten generiert, plattformspezifisch bis zur Lauffähigkeit ausformuliert und auf der Plattform integriert werden. Hier zeigt sich, wie sich einzelne Entscheidungen des modellgetriebenen Vorgehens auswirken und wie generierte Inhalte mit manuell erstellten Inhalten zusammenspielen. Da jede Plattform auch ihre eigenen Werkzeuge mitbringt, gehen wir auch darauf ein. Ergebnis ist die komplette SOA Anwendung, die über die Benutzeroberfläche den Workflow abbildet, Prozesse und Aktivitäten über Webservices nutzt und so ihre Leistung für den Anwender erbringt. Anschauliche Beispiele helfen die Zusammenhänge zu verstehen und nachzuvollziehen.