magazin Delivery Continuous JAVA Mag DVD-INHALT Die letzte Meile zum Release 20 Was zählt, ist gutes Design! Model-driven Beans JDeveloper und ADF

Transkript

1 inkl. JAVA Mag DVD Happy new Grails! Version 2.0 ist da 14 Deutschland 9,80 Österreich 10,80 Schweiz sfr 19, magazin Java Architekturen Web Agile DVD-INHALT Java ist tot? Nein, #1! von Adam Bien Video von der JAX 2011 The New Generation of Enterprise Java von Stephen Burton Video von der W-JAX 2011 Google Wallet Die elektronische Brieftasche 91 Qt Java Bindings Mit Java auf die Qt Libraries zugreifen 97 Programm ab Seite 51 Continuous Delivery Buchauszüge Cloud Computing Java-Core- Programmierung Single Source Publishing Die komplette Ausgabe des Android Magazin 3.11 als PDF Die letzte Meile zum Release 20 Was zählt, ist gutes Design! Interview mit Martin Fowler, Erik Dörnenburg und Wolf Schlegel 29 Alle DVD-Infos ab Seite 2 Cloud-Plattform OpenShift JBoss in den Wolken S. 35 JDeveloper und ADF ADF goes mobile S. 84 Model-driven Beans EJB 3 modellgetrieben entwickeln S. 61

2 EJB 3 Enterprise Model-driven Beans EJB 3 modellgetrieben entwickeln Das Modell wird zum Hauptdarsteller Die modellgetriebene Softwareentwicklung (Model-driven Development, kurz MDD) wird in der Softwaretechnik seit einigen Jahren nicht mehr nur als vielversprechender Ansatz diskutiert, sondern in mittleren und großen Projekten erfolgreich praktiziert. Dabei gibt es einige Eigenheiten, die es für eine erfolgreiche Realisierung zu beachten gilt. In diesem Artikel wird die modellgetriebene Softwareentwicklung in Kombination mit der Komponentenarchitektur der Enterprise Java Beans vorgestellt. von Christian Schwörer und Konrad Pfeilsticker Unabhängige Technologie- und Marktforschungsunternehmen, wie Forrester [1] oder Gartner mit ihrem jährlich erscheinenden Hype Cycle [2], attestieren dem modellgetriebenen Paradigma eine zunehmende Schlüsselrolle in der Softwareentwicklung. Auch praxisnahe Umfragen, die sich mit Verbreitung und Einsatz modellgetriebener Techniken und Werkzeuge beschäftigen, bestätigen die steigende Relevanz [3], [4]. Bei der praktischen Umsetzung von MDD können für den Entwicklungsprozess zahlreiche Vorteile und Verbesserungen erreicht werden. Jedoch gilt es im Umkehrschluss, auch einige neue Aspekte zu berücksichtigen, die bei der konventionellen Softwareentwicklung so nicht auftreten. Daher wird im Folgenden zunächst das modellgetriebene Paradigma charakterisiert, um anschließend die Enterprise Java Beans 3 (EJB 3) als mögliche Zielarchitektur kurz vorzustellen. Basierend auf dieser grundlegenden Einführung wird dargelegt, wie eine ideale Verknüpfung der beiden Technologien erreicht werden kann. Insbesondere wird darauf eingegangen, mit welchen Strategien generierte Quelltexte und manuelle Codeergänzungen kombiniert werden können. Modellgetriebene Softwareentwicklung Nicht erst seit das modellgetriebene Paradigma Einzug gehalten hat, wird Modellierung in der Softwareerstellung eingesetzt. Im Unterschied zur konventionellen Vorgehensweise bei der Softwareentwicklung dienen hier Modelle nicht ausschließlich zu Dokumentationszwecken, sondern stellen zentrale Bestandteile der Anwendungsentwicklung dar. Entsprechend werden große Teile der Anwendung im Modell spezifiziert, anstatt diese wie bei der codezentrierten Softwareentwicklung vollständig in einer Programmiersprache auszuformulieren. Demzufolge hat MDD das Ziel, automatisiert möglichst viele Artefakte eines zu erstellenden Softwaresystems generativ aus formalen Modellen abzuleiten. Die Modelle nehmen daher eine zentrale treibende Rolle in der Anwendungsentwicklung ein und sind in ihrer Bedeutung dem Quellcode gleichgestellt. Die formalen Modelle werden mit einer domänenspezifischen Sprache (DSL) erstellt. Oftmals wird dazu die Unified Modeling Language (UML) mittels des Profilmechanismus spezifisch angepasst. Prinzipiell sind aber auch andere grafische oder textuelle Notationen möglich. Einige elementare Begrifflichkeiten der modellgetriebenen Softwareentwicklung werden im Kasten Begriffsdefinition MDD definiert. Der Umstand, dass das modellgetriebene Paradigma eine höhere Automatisierung des Entwicklungsprozesses beabsichtigt, impliziert, dass dem Einsatz von Werkzeugen eine maßgebliche Bedeutung zukommt. Neben geeigneten Modellierungstools ist dies in erster Linie der Generator. In ihm sind die Transformationen vom abstrakten Modell bis zu den konkreten Quellcodeartefakten realisiert. Diese Werkzeuge müssen in den Entwicklungsprozess integriert werden. Abbildung 1 zeigt beispielhaft eine modellgetriebene Werkzeugkette. Das modellgetriebene Vorgehen verspricht gegenüber der konventionellen Softwareentwicklung eine Reihe von Vorteilen: Die Anwendungsentwicklung erfolgt auf einer höheren Abstraktionsebene. Architekturvorgaben lassen sich besser durchsetzen. Zentrale Framework- oder Architekturänderungen lassen sich besser ausrollen. Die Entwicklungseffizienz und der Automatisierungsgrad werden erhöht. javamagazin

3 Enterprise EJB 3 Zielplattform, für die Code generiert wird, Auswirkung auf die Definition der Transformationsregeln und somit des Generators. Im Folgenden werden einige dieser zu berücksichtigenden Besonderheiten für die Zielplattform Java EE skizziert. Abb. 1: Exemplarische modellgetriebene Werkzeugkette Die Wiederverwendung wird vereinfacht. Die Softwarequalität kann gesteigert werden. Eine Plattformunabhängigkeit lässt sich einfacher realisieren. Diese Vorteile ergeben sich jedoch nicht von selbst. Vielmehr müssen für eine erfolgreiche Umsetzung bestimmte Faktoren beachten werden. Unter anderem hat die Begriffsdefinitionen MDD Formales Modell: Ein Modell ist stets ein abstrahiertes Abbild eines Originals. Bei formalen Modellen handelt es sich um Modelle mit klarer Syntax und Semantik. Das heißt, es ist eindeutig geregelt, welche Notationselemente (Symbole, Zeichen, Wörter) erlaubt sind und was genau diese Elemente bedeuten. Metamodell: Bei der Metamodellierung werden Modelle wiederum durch Modelle beschrieben, die dann Metamodelle genannt werden. Das Metamodell bringt somit Struktur, Beziehungen und Einschränkungen eines konkreten Modells zum Ausdruck. Domäne: Modellgetriebenes Vorgehen erfolgt immer im Rahmen einer Domäne. Darunter versteht man ein klar abgegrenztes Interessens- oder Wissensgebiet. DSL: Bei einer domänenspezifischen Sprache handelt es sich um eine formale Sprache zur abstrakten Darstellung von Sachverhalten einer Domäne. Die Ausdrücke einer DSL sind für Mensch und Maschine verständlich: Ein vom Domänenexperten mit der DSL erstelltes, formales Modell kann von einem Generator verarbeitet werden. M2M-Transformation: Eine Modell-zu-Modell-Transformation (M2M) ist eine Komponente einer MDD-Werkzeugkette, die Modelle entgegennimmt und daraus wiederum ein oder mehrere Modelle erzeugt. Dies dient zur Überbrückung der Lücke zwischen verschiedenen Abstraktionsebenen. M2T-Transformation: Bei einer Modell-zu-Text-Transformation (M2T) werden aus formalen Modellen plattformspezifische Textartefakte wie Quellcode und Konfigurationsdateien generiert. Die Transformationsart wird auch als Modellzu-Code (M2C) oder ganz allgemein als Codegenerierung bezeichnet. EJB Einen wesentlichen Bestandteil der Java-EE-Plattform bilden EJBs. Sie stellen die serverseitige Komponentenarchitektur zur modularen Entwicklung von komplexen, verteilten Softwaresystemen dar. Seit Java EE 5 gibt es EJB 3, das einige gravierende Nachteile der Vorgängerversionen ausräumt [5]. So steht etwa mit dem Java Persistence API (JPA) als Bestandteil von EJB 3 eine deutlich vereinfachte Schnittstelle zur persistenten Abbildung von Objekten in Datenbanken bereit (Anmerkung: Seit JPA 2.0 ist dieses eigenständig und steht nicht mehr in zwingender Abhängigkeit zu den EJBs). Dieser Weg der Vereinfachung wird mit Java EE 6 und der darin spezifizierten EJB-Version 3.1 konsequent fortgeführt. Grundsätzlich lassen sich drei EJB-Typen unterscheiden: Session Beans, Entities und Message-driven Beans (Kasten: EJB-Typen ). Ein seit Java EE 5 stark genutztes Prinzip, das maßgeblich zur Reduktion der Komplexität beiträgt, ist Convention over Configuration (CoC). Darunter ist der Grundsatz zu verstehen, dass alle Artefakte der Anwendungsentwicklung, die der JEE-Konvention folgen, nicht konfiguriert werden müssen. Lediglich applikationsspezifische und unkonventionelle Aspekte einer Anwendung müssen explizit konfiguriert werden. Ist aus Konfigurationsgründen das Hinzufügen von Metadaten erforderlich, werden diese üblicherweise im Quelltext über das Sprachelement der Annotationen eingebunden. So wird beispielsweise die Ausprägung der erwähnten Session Beans anhand der definiert. Ein weiteres Konstrukt zur Angabe von Metadaten sind die bereits aus früheren Java-EE-Versionen bekannten Deployment-Deskriptoren. In diesen können XML-basiert Metainformationen hinzugefügt oder im Quelltext definierte Annotationen überschrieben werden. Es lässt sich also prinzipiell folgende Hierarchie festhalten: Als erstes Prinzip steht CoC, das heißt, alle der JEE-Konvention entsprechenden Elemente müssen nicht konfiguriert werden. Notwendige Abweichungen werden über Annotationen definiert, die wiederum durch Deployment-Deskriptoren ergänzt und überschrieben werden können. Besonderheiten der modellgetriebenen Entwicklung mit EJB 3 Will man nun eine optimale Kombination des beschriebenen Ease of Use von EJB 3 mit den Vorteilen des modellgetriebenen Vorgehens erreichen, gilt es einige 62 javamagazin

4 EJB 3 Enterprise Besonderheiten zu berücksichtigen. So stellt unter anderem die Kombination von generiertem und manuell implementiertem Quellcode eine zentrale Herausforderung dar. Dies hat den Hintergrund, dass eine pragmatische Auslegung des modellgetriebenen Ansatzes in der Regel nicht zum Ziel hat, alle Bestandteile einer Anwendung generativ zu erzeugen. Vielmehr wird ein Implementierungsrahmen generiert, der große Teile des Infrastrukturcodes enthält. Dieser Code kann bis zu zwei Drittel einer Unternehmensanwendung ausmachen und ist gekennzeichnet durch sich wiederholende Konstrukte, sodass er sich für die automatisierte Erzeugung anbietet. Der so generierte Implementierungsrahmen wird vom Entwickler durch manuell in der Zielsprache implementierten Code ergänzt, der weitere Teile der fachspezifischen Anwendungslogik enthält. Dies erfordert jedoch ein Verfahren, wie generierter Quelltext mit manuellen Ergänzungen kombiniert werden kann. Dazu sind die nachfolgenden Strategien denkbar. Geschützte Bereiche Bei dieser Vorgehensweise werden in den generierten Codeartefakten so genannte Protected Regions vorgesehen, in denen der Entwickler manuellen Code einfügen kann. Die Bereiche sind speziell markiert, sodass sie vom Generator erkannt werden. Bei den folgenden Generatorläufen wird der manuell hinzugefügte Quelltext nicht überschrieben. Bei diesem einfach zu realisierenden Ansatz findet keine Trennung von Generator und handgeschriebenen Ergänzungen auf physikalischer Dateiebene statt, was einige gravierende Nachteile mit sich bringt. So ist beispielsweise das Versionsmanagement unsauber, da auch der generierte Code zwangsläufig in das Versionierungssystem eingecheckt wird. Ebenso gehen manuelle Ergänzungen außerhalb der geschützten Bereiche bei der nächsten Generierung unweigerlich verloren. Zusätzlich wird der Codegenerator komplexer, da er geschützte Bereiche verwalten, erkennen und erhalten muss. Daher wird dieser Ansatz auch nicht von allen Generatorframeworks unterstützt. Vererbung Eine striktere Trennung der Artefakte lässt sich erreichen, indem die Mittel der Zielsprache genutzt werden, um die unterschiedlichen Aspekte in verschiedenen Dateien zu hinterlegen. Eine Lösung, die sich bei einer objektorientierten Sprache wie Java anbietet, ist die Aufteilung mittels Vererbung. Abbildung 2 zeigt diese Strategie, erweitert um eine mögliche Ableitung von Frameworkklassen. Dabei wird vom Generator eine abstrakte Oberklasse erzeugt, die alle aus dem Modell abgeleiteten (und somit generierbaren) Aspekte beinhaltet. Diese Klasse wird bei jedem Generatorlauf überschrieben und beinhaltet demzufolge immer die im Modell definierten Informationen. Abgeleitet von dieser Oberklasse ist die Implementierungsklasse, die nur initial vom Generator erzeugt und bei den folgenden Generatorläufen nicht mehr automatisch überschrieben Abb. 2: Kombination von generiertem und manuell ergänztem Quelltext mittels Vererbung Abb. 3: Kombination von generiertem und manuell ergänztem Quelltext mittels Delegation Kann eine Schulungseinrichtung für mehr als EINEN Themenbereich berühmt werden? Das Linuxhotel ist bekannt für erstklassige Open- Source-Schulungen. In den letzten Jahren kamen Java und andere Programmiersprachen hinzu - wie immer in Kooperation mit führenden Spezialisten. Es ist naheliegend, auch Entwicklerthemen bei den OpenSource lern zu lernen, weil man dort schon immer sehr unter die Haube guckte... Mehr siehe

5 Enterprise EJB 3 durch Vererbung für EJB 3 nicht problemlos übernommen werden. Abb. 4: Mikroarchitektur zur Trennung von generiertem und manuell erstelltem Code am Beispiel der Session Bean CustomerService Delegation Neben der Vererbung bieten objekt orientierte Sprachen wie Java mit der Delegation ein zweites Konzept zur Wiederverwendung von Programmcode an. Dabei stellt ein Objekt zwar Funktionalität nach außen zur Verfügung, delegiert aber die Verantwortung dafür an andere Objekte. Wird dieses Prinzip zur Trennung von generierten und manuell zu ergänzenden Artefakten bei EJB 3 angewendet, enthält eine generierte Klasse sämtliche notwendige Metainformationen in Form von Annotationen. Methodenaufrufe werden von ihr an eine manuell veränderbare Implementierungsklasse weitergeleitet, das heißt delegiert (Abb. 3). Die Umsetzung der Delegation für EJB 3 stellt sich jedoch sehr aufwändig dar, da die Mikroarchitektur der generierten Artefakte äußerst komplex wird und somit ihre Les- und Wartbarkeit erschwert werden. Abb. 5: Mikroarchitektur zur Trennung von generiertem und manuell erstelltem Code am Beispiel der Entity Customer wird. Folglich können hier manuelle Erweiterungen vorgenommen werden. Diese Strategie basiert auf dem so genannten Generation Gap Pattern [6]. Leider lässt sich dieses in der MDD-Praxis etablierte Prinzip nicht problemlos auf EJB-3-Artefakte übertragen, da die Vererbung von Java-Annotationen nur bedingt möglich ist. So muss etwa die Annotation zur Ausprägung einer Session Bean (@Stateful direkt in der Implementierungsklasse angegeben werden und kann nicht von einer generierten, abstrakten Oberklasse geerbt werden. Ebenso verhält es sich bei der Definition einer persistenten Entity (@Entity), die in der konkreten Implementierungsklasse erfolgen muss. Da sich diese Metadaten jedoch aus den im Modell spezifizierten Informationen ergeben und demzufolge generativ erzeugt werden, kann der Ansatz der Trennung Deployment-Deskriptoren Die Auslagerung aller Metadaten in die Deployment-Deskriptoren ist eine EJB-spezifische Strategie. Wie zuvor beschrieben, lassen sich prinzipiell alle Metadaten in die Konfigurationsdateien auslagern. Dazu werden zusätzlich zu den einmalig beim ersten Generatorlauf erzeugten Implementierungsklassen die benötigten Deployment-Deskriptoren generiert. Sie enthalten alle Metainformationen und werden bei jedem Generatorlauf neu erzeugt. Ein Hauptproblem dieses Ansatzes besteht darin, dass beispielsweise das nachträgliche Hinzufügen einer Methode zu einer bestehenden Session Bean im Modell nicht generativ abgebildet werden kann, da die Implementierungsklasse nur einmalig erzeugt und dann manuell verändert wird. Zudem stellt die reine Nutzung von konfigurativen Deployment-Deskriptoren sozusagen einen Rückfall in die J2EE-Welt dar und berücksichtigt die Vorteile des aktuellen Java- EE-Standards nicht. Konkrete Realisierung Wie aus dem vorherigen Abschnitt hervorgeht, kann keine der beschriebenen Strategien problemlos für 64 javamagazin

6 EJB 3 Enterprise EJB 3 adaptiert werden: Die geschützten Bereiche bringen prinzipiell eine Reihe von Nachteilen mit sich und sollten nur als Notlösung betrachtet werden. Der Einsatz von Vererbung hat das Problem, dass nicht alle EJB-Annotationen ableitbar sind. Bei Delegation dagegen werden die generierten Codeartefakte unnötig komplex. Eine reine Nutzung von Deployment- Deskriptoren ist wiederum zu unflexibel bezüglich Modelländerungen. Aus diesem Grund müssen für die EJB-Typen Session Bean und Entity spezielle Vorgehensweisen definiert werden. Entscheidendes Kriterium für die Erstellung der Strategien ist neben der strikten Trennung auch eine einfache Realisierbarkeit, damit die Transformationen und somit der Codegenerator beherrschbar bleiben. Zusätzlich sollen die Codebereiche, in denen der Anwendungsentwickler manuelle Ergänzungen vornehmen kann, möglichst frei von EJB- Metadaten bleiben. Dies hat sich in der Vergangenheit als Best Practice erwiesen. Vorweggenommen sei, dass es sich in beiden Fällen um eine Kombination der beschriebenen Vorgehensweisen Vererbung und Deployment-Deskriptoren handelt. Session Beans Generell wird der Ansatz der Vererbung soweit wie möglich eingesetzt. Das bedeutet, dass eine abstrakte Basisklasse generiert wird, die alle sinnvoll durch Vererbung ableitbaren Metainformationen als Annotationen beinhaltet. Darunter fallen beispielsweise eine aus dem Modell abgeleitete Injektion einer anderen EJB über oder die Einbindung des JPA-Entity- Managers Die generierte Basisklasse erhält als Namenszusatz Bean (also zum Beispiel CustomerServiceBean). Zusätzlich wird auch die Geschäftsschnittstelle, d. h. das Business Interface der Session Bean, vollständig generativ erzeugt. Sie enthält alle entsprechend modellierten Methoden, die die Session Bean bereitstellt. Die konkrete Implementierungsklasse wird einmalig generiert. Ihr Bezeichner erhält den Namenszusatz Bean- Impl, also beispielsweise CustomerServiceBeanImpl. Sie enthält bei der Erzeugung lediglich die aus dem Modell resultierenden Attribute und die Methodenrümpfe. Anschließend kann sie vom Entwickler manuell erweitert werden, das heißt, er ergänzt die einzelnen Methoden um ihre Fachlogik. Bei einer Neugenerierung wird diese Klasse nicht überschrieben. Das vierte generierte Artefakt ist der Deployment- Deskriptor (ejb-jar.xml). Er enthält alle Metainformationen, die von der Implementierungsklasse nicht sinnvoll aus der Basisklasse abgeleitet werden können. Dazu zählen unter anderem der Zustand (<session-type>stateless</session-type> bzw. <session-type>stateful</session-type>) sowie die Angaben zur Transaktionalität der Klasse oder einer Methode (<trans-attribute>...</trans-attribute>). Die Implementierungsklasse bleibt somit komplett frei von EJB- Metadaten und kann vom Entwickler wie ein echtes POJO vervollständigt werden. Auch der Deployment- Deskriptor wird, wie die abstrakte Basisklasse und das Business Interface, bei einer erneuten Generierung komplett neu erzeugt und überschrieben. Den Zusammenhang der einzelnen Artefakte zeigt die Mikroarchitektur in Abbildung 4. Entities Auch bei den Entities wird die Trennung durch den Vererbungsansatz in Kombination mit dem Deployment- Deskriptor realisiert, wie in Abbildung 5 zu sehen ist. Bei jedem Generatorlauf wird eine Basisklasse generiert, die alle sich aus dem Modell ergebenden Attribute mit den zugehörigen Getter- und Setter-Methoden enthält. Diese werden soweit möglich mit JPA-Annotationen versehen. Darunter fallen beispielsweise Angaben zu Tabellenspalten (@Column), Primärschlüsseln (@Id) und Relationen zwischen Für eine korrekte, objektrelationale Abbildung muss die abstrakte Basisklasse anstelle mit der gekennzeichnet werden. Damit wird sichergestellt, dass lediglich die abgeleitete Implementierungsklasse, die alle Attribute und die entsprechenden Mapping-Informationen von erbt, persistiert wird. Alle Metadaten, die nicht aus der generierten Oberklasse abgeleitet werden können, werden wiederum in den entsprechenden Deployment-Deskriptor (orm.xml) ausgelagert. Hierunter fällt etwa die Kennzeichnung der Implementierungsklasse als persistente Entity (mittels <entity.../>). Somit ist auch hier die Implementierungsklasse, die nur einmalig erzeugt wird und anschließend manuell ergänzt werden kann, frei von EJB-spezifischen Metadaten. EJB-Typen Bei Session Beans handelt es sich um nicht persistente Komponenten, in denen die Geschäftslogik einer Anwendung implementiert ist. Es gibt sie in den zwei verschiedenen Ausprägungen zustandsbehaftet (stateful) und zustandslos (stateless). Entities stellen die fachlichen Geschäftsobjekte dar, mit denen die in den Session Beans implementierte Geschäftslogik arbeitet. Eine persistente Entity repräsentiert somit eine Objektsicht auf gespeicherte Daten. Entities enthalten folglich keine nennenswerte Logik, vielmehr kapseln sie lediglich den Zugriff auf private Attribute mittels Getterund Setter-Methoden. Für die dauerhafte Speicherung der fachlichen Objekte und Sachverhalte basieren persistente Entities auf dem Konzept der objektrelationalen Abbildung (Object-Relational Mapping, ORM), die im Regelfall über JPA realisiert wird. Message-driven Beans (MDB) dienen zur Realisierung nachrichtenbasierter Kommunikation in Java-EE-Systemen. Beim weiteren Vorgehen finden MDBs keine Verwendung, weshalb auf eine ausführlichere Beschreibung verzichtet wird. javamagazin

7 Enterprise EJB 3 Im Gegensatz zu den oben beschriebenen Artefakten der Session Beans erhält bei einer Entity lediglich die Basisklasse einen Namenszusatz. Dies hat den Hintergrund, dass der Verwender einer Session Bean immer mit der Geschäftsschnittstelle arbeitet und die Implementierungsklasse für ihn verborgen bleibt. Hier ist die Benennung der Geschäftsschnittstelle ausschlaggebend. Der Verwender einer Entity arbeitet dagegen mit der konkreten Implementierungsklasse, sodass diese sinnvoll benannt sein muss. Demgemäß erhält die Implementierungsklasse den prägnanten Namen (zum Beispiel Customer) und die Basisklasse einen Namenszusatz (entsprechend CustomerBase). Fazit Die beiden dargestellten Generierungsstrategien folgen der zu Beginn beschriebenen Hierarchie, gemäß derer das CoC-Paradigma mittels Annotationen und Deployment-Deskriptoren überschrieben werden kann. Sie basieren somit auf einem der Grundprinzipien des aktuellen Java-EE-Standards. Grundsätzlich lässt sich festhalten, dass für eine sinnvolle Trennung von generierten und manuell erstellten Quelltexten nach Möglichkeit die Mittel der Zielsprache genutzt werden sollten. Für objektorientierte Sprachen empfiehlt sich die beschriebene Vererbungsstrategie, da sie sich in der modellgetriebenen Praxis etabliert hat und relativ einfach zu realisieren ist. Des Weiteren ist der Zusammenhang der generierten Artefakte für den Anwendungsentwickler gut nachvollziehbar und beispielsweise auch problemlos Debug-fähig. Sollte die Strategie nicht vollständig nutzbar sein, muss sie spezifisch erweitert werden, so wie im beschriebenen Fall für EJB 3 mit den Deployment-Deskriptoren. Um die Trennung auf der Dateiebene weiter zu manifestieren, sollten für die unterschiedlichen Artefakte auch verschiedene Quellordner verwendet werden. Als Best Practice hat sich etabliert, die Generate in ein Verzeichnis src-gen zu erzeugen. Die manuell ergänzten Implementierungsklassen werden dagegen in einem Quellverzeichnis src-man gespeichert. Diese Aufteilung bildet auch die Grundlage für eine saubere Trennung bei der Versionskontrolle. Der generierte Code ist vollständig aus dem Modell reproduzierbar und sollte daher auch nicht in ein Versionierungssystem eingecheckt werden. Somit müssen zusätzlich zu den Modellen, in denen die relevanten Informationen enthalten sind, lediglich die Quelltexte in src-man versioniert werden. Weitere, allgemeiner gehaltene Informationen und Handlungsempfehlungen zur modellgetriebenen Softwareentwicklung finden sich unter [7] bzw. [8]. Abschließend lässt sich festhalten, dass die Praxistauglichkeit der beschriebenen Umsetzungsstrategien anhand eines Migrationsprojekts verifiziert wurde. Dabei wurde die Zielplattform eines modellgetriebenen Entwicklungsprozesses, der von 200 Entwicklern genutzt wird und auf dessen Basis Anwendungen für mehr als 4000 Nutzer entwickelt werden, erfolgreich auf eine neue Technologie angehoben. Genauer gesagt hatte das Projekt zum Ziel, die bisherige EJB-2-basierte Anwendungsplattform durch eine EJB-3-basierte zu ersetzen. Prämisse war dabei eine möglichst geringe Beeinträchtigung des etablierten modellgetriebenen Verfahrens. Der modellgetriebene Ansatz erlaubte es, die Anwendungsentwicklung zentral umzustellen: Die UML-basierte DSL wurde angepasst und der zentral gewartete Generator, d. h. die darin enthaltenen Transformationsregeln, wurde erweitert. Durch die Verwendung der beschriebenen Trennungsstrategie konnten die Auswirkungen auf die bestehende Anwendungsentwicklung wie erhofft minimiert werden. Christian Schwörer ist Senior Consultant bei der NovaTec - Ingenieure für neue Informationstechnologien GmbH. Neben der modellgetriebenen Softwareentwicklung liegen seine Beratungsschwerpunkte im Bereich der serverseitigen Anwendungsentwicklung mit Java EE, insbesondere mit dem Java Persistence API (JPA) und Hibernate. Kontakt: christian.schwoerer@novatec-gmbh.de. Konrad Pfeilsticker ist Senior Managing Consultant und Mitglied des Managements bei der NovaTec Ingenieure für neue Informationstechnologien GmbH. Er besitzt langjährige Erfahrung in der Erstellung von Enterprise-Java-Anwendungsentwicklungs-Plattformen als Basis für die modellgetriebene Softwareentwicklung. Kontakt: konrad.pfeilsticker@novatec-gmbh.de. Links & Literatur [1] Forrester Research, Inc.: The State of Model-Driven Development Claryfying The Options For Application Development Teams, 2007, Market Research [2] Gartner Inc.: Hype Cycle for Application Development, 2010, Research [3] Forschungszentrum Informatik/Generative Software GmbH: Umfrage zu Verbreitung und Einsatz modellgetriebener Softwareentwicklung, Abschlussbericht: [4] OFFIS Institut für Informatik: MDSD Umfrage Ergebnisse und Trends- IF-ModE: MDSD_Umfrage_2009.pdf [5] Sun Microsystems Inc.: Enterprise JavaBeans 3 Final Release: download.oracle.com/otndocs/jcp/ejb-3_0-fr-eval-oth-jspec/ [6] Vlissides, John: Pattern Hatching Generation Gap: ibm.com/designpatterns/pubs/gg.html [7] Schwörer, Christian: Automatisierung durch modellgetriebene Softwareentwicklung: Aufbau einer modellgetriebenen Entwicklungsplattform, VDM Verlag Dr. Müller, 2011 [8] Völter, Markus et al.: Modellgetriebene Softwareentwicklung: Techniken, Engineering, Management, 2. Auflage, dpunkt Verlag, javamagazin