Konzeption und Entwicklung einer Software Factory für Java-Enterprise-Anwendungen basierend auf der Eclipse-Plattform

Transkript

1 Hochschule für Technik und Wirtschaft Dresden (FH) Fachbereich Informatik/Mathematik Friedrich-List-Platz Dresden Diplomarbeit im Studiengang Informatik Konzeption und Entwicklung einer Software Factory für Java-Enterprise-Anwendungen basierend auf der Eclipse-Plattform Stefan Bley 3. Januar 2008 Betreut durch: Prof. Dr.-Ing. habil. Hartmut Fritzsche und Dipl.-Inf. Stefan Ocke

2 Inhaltsverzeichnis 1 Einleitung Problemstellung Aufbau der Arbeit Java-Enterprise-Anwendungen Verteilte Anwendungen und Middleware Der Java-Enterprise-Standard Muster und Frameworks Konzepte und Muster einer Java-Enterprise-Architektur Die Architektur des Domänenmodells Modellgetriebene Softwareentwicklung Grundlagen Begriffe Ziele Metamodellierung Model-Driven Architecture Ziele MDA-Modelle Metamodellarchitektur Spezifikationen Domänenspezifische Modellerweiterung der UML Software Factories Der Begriff in der Literatur Eigene Interpretation Rollenverteilung Software Factories und MDA Technologien und Werkzeuge der MDSD 32 i

3 Inhaltsverzeichnis Inhaltsverzeichnis 4.1 Eclipse Plugin-Mechanismus Eclipse Modeling Framework Das Ecore-Metamodell Codegenerierung Erstellung grafischer Editoren Anwendungsgebiete openarchitectureware Bestandteile Integration in Eclipse Zusammenfassung Atlas Transformation Language AndroMDA Architektur Ausblick auf Version OptimalJ Microsoft Software Factories und DSL-Tools Software Factories Domain-Specific Language Tools Die Software Factory Anforderungen Überblick Konzept Technologiewahl Software-Factory- und Anwendungsentwicklung Modellierung des Problemraums Das Metamodell Domain Die DSL Domain als EMF-Modell Grafische Syntax mit GMF Cartridges Aufbau Schnittstellen Leitlinien für die Cartridgeentwicklung Exemplarische Cartridges Module Project Creator ii

4 Inhaltsverzeichnis Inhaltsverzeichnis POJO Creator for Domain Objects JPA Annotation Creator Data Access Object Generator JPA Data Access Object Generator Spring 2.0 Service Beans Generator Kern- und GUI-Komponente Der Kern Die GUI-Komponente Installation und Bedienung Installation Bedienung Zusammenfassung und Ausblick Zusammenfassung Zukünftige Arbeiten Erweiterung der DSL Domain Entwicklung weiterer Cartridges Konzeptionelle Überlegungen A Anhang 115 A.1 Zusicherungen des Metamodells Domain A.2 GMF-Definitionsmodelle für die DSL Domain A.3 Codebeispiele iii

5 Abbildungsverzeichnis 2.1 Drei-Schicht-Architektur verteilter Anwendungen Muster für Domänenmodelle Beispiel für ein Domänenmodell einer Enterprise-Anwendung Metamodellarchitektur Offizielles Symbol der MDA MDA-Metamodellarchitektur QVT-Architektur Definition und Anwendung eines Stereotyps Domänenspezifische Modellerweiterung durch Spezialisierung Definition und Erweiterung eines Extension Points Ecore-Klassenhierarchie GMF Dashboard MDA in OptimalJ Definition und Anwendung einer DSL mit den Visual Studio DSL Tools Konzept der Software Factory Ausführung der Cartridges Build mit M2M-Transformationen Entwicklungsumgebungen für SF und Java EE im Vergleich Das Metamodell Domain Vererbungsbeziehungen zwischen Domain und Ecore Shortcuts im grafischen Domain-Modell Validierung im grafischen Domain-Modell Extension Point com.saxsys.sf.cartridge Erweiterung des Extension Points com.saxsys.sf.cartridge Extension Point com.saxsys.sf.core.projectcontributions Extension Point com.saxsys.sf.core.classpathcontributions iv

6 Abbildungsverzeichnis Abbildungsverzeichnis 5.13 Ausgangsmodellelement für Generierung Eclipse-Workspace nach Ausführung des Module Project Generators Spring Beans Generator: Ausgangsmodell Software-Factory-Einstellungen Ungültige Referenz bei einem einmalgenerierten Artefakt Featuremodell für Java-Enterprise-Anwendungen A.1 Werkzeugdefinitionsmodell der grafischen DSL Domain A.2 Grafikdefinitionsmodell der grafischen DSL Domain A.2 Mappingmodell der grafischen DSL Domain v

7 Tabellenverzeichnis 3.1 UML-Diagrammtypen Bestandteile der Microsoft Software Factories Gegenüberstellung Software-Factory- und Anwendungsentwicklung POJO Creator: Mapping Domain-Modell Java/AspectJ JPA Annotation Creator: Mapping Domain-Modell Java/XML DAO Generator: Mapping Domain-Modell Java/AspectJ Spring Beans Generator: Mapping Services Spring Software Factory Eclipse Features A.1 Zusicherungen für Domain-Modelle vi

8 Listings 3.1 UML-Modell als XMI-Dokument Definition einer Zusicherung in Check MM-Extension für den Namen einer Service-Implementierungsklasse Template für die Bean-Definition von Services in Spring Template für eine Entityklasse Template für JPA-Annotationen an eine Entityklasse Template für eine persistence.xml in JPA Template für Hibernate als Persistenzprovider Eigenschaftendatei mit Ausgabeverzeichnissen Workflow mit Generatorkomponente Generierte Klasse mit geschütztem Bereich Vererbung: generierte abstrakte Basisklasse Vererbung: manuell erstellte Implementierungsklasse AOP: generierte Basisklasse AOP: manuell erstellter Implementierungsaspekt Spring Beans Generator: generierte spring-dao.xml Spring Beans Generator: generierte spring-services.xml A.1 plugin.xml des Plugins com.saxsys.sf.gen.persistence.jpa A.2 Workflow der Cartridge com.saxsys.sf.gen.module A.3 Xpand-Template zur Generierung eines Service-Interfaces A.4 Xtend-MM-Extensions für DAO-Artefakte A.5 Check-Datei mit Zusicherungen für Services vii

9 Abkürzungsverzeichnis ADT AJDT AOP API ATL CIM CMOF ATL Development Tools AspectJ Development Tools Aspektorientierte Programmierung Application Programming Interface Atlas Transformation Language Computation-Independent Model Complete MOF CORBA Common Object Request Broker Architecture CRUD CVS CWM DAO DBMS DDD DI Create, Read, Update, Delete Concurrent Versions System Common Warehouse Metamodel Data Access Object Database Management System Domain-Driven Design Dependency Injection viii

10 Abkürzungsverzeichnis Abkürzungsverzeichnis DSL EJB EMF EMOF EPL GEF GMF GMT GUI IDE IL IoC J2EE Domain-Specific Language Enterprise JavaBeans Eclipse Modeling Framework Essential MOF Eclipse Public License Graphical Editing Framework Graphical Modeling Framework Generative Modeling Technologies Graphical User Interface Integrated Development Environment Infrastructure Library Inversion of Control Java 2 Enterprise Edition Java EE Java Enterprise Edition JDT JEM JPA JSF JTA MCR Java Development Tools Java EMF Model Java Persistence API Java Server Faces Java Transaction API Model-Code Repository ix

11 Abkürzungsverzeichnis Abkürzungsverzeichnis MDA MDD MDR MDSD MDT MM MOF MVC M2C M2M M2T oaw OCL OMG OR PDE PIM PLE PM POJO Model-Driven Architecture Model-Driven Development Meta Data Repository Model-Driven Software Development Model Development Tools Metamodell Meta Object Facility Model View Controller Modell-zu-Code Modell-zu-Modell Modell-zu-Text openarchitectureware Object Constraint Language Object Management Group Object-Relational Plugin Development Environment Platform-Independent Model Product Line Engineering Platform Model Plain Old Java Object x

12 Abkürzungsverzeichnis Abkürzungsverzeichnis PSI PSM PT QVT RCP RFP SDK SF SQL SPLE UML VO WTP XMI XML XSD Platform-Specific Implementation Platform-Specific Model Personentag(e) Query/View/Transformation Rich Client Platform Request for Proposal Source Development Kit Software Factory Structured Query Language Software Product Line Engineering Unified Modeling Language Value Object Web Tools Project XML Metadata Interchange Extensible Markup Language XML Schema Definition xi

13 1 Einleitung Die Softwareentwicklung ist heutzutage durchgehenden Veränderungen ausgesetzt. Kunden erwarten ständig innovative Lösungen bei gleichzeitig hoher Qualität, schneller Fertigstellung und geringen Kosten. Um diesen Anforderungen gerecht zu werden, entstehen immer komplexere Softwaresysteme mit neuartigen Technologien, Plattformen, Frameworks und Programmiersprachen. Der Entwickler ist somit gezwungen, sich immer wieder mit technologischen Details auseinander zu setzen, wodurch wertvolle Zeit für die eigentliche Betrachtung der Fachlichkeit verloren geht, die der Auftraggeber letztendlich umgesetzt haben möchte. Jacobson [Jac02] sieht den Anteil an solcher kreativer Arbeit eines Softwareentwicklers bei nicht mehr als 20 %. Die hohe Komplexität der Anwendungen und Plattformen führt zu hoher Fehlerhäufigkeit, zumal die Fachlogik im Quellcode von Programmiersprachen verteilt ist und dies die Fehlerfindung und -beseitigung erschwert. Mit der Einführung des Modellierungsstandards Unified Modeling Language (UML) gab es die Möglichkeit, grafische Modelle für die Fachlogik zu erstellen. Diese hatten aber nicht immer formalen Charakter und konnten demzufolge nicht für eine automatische Codeerstellung genutzt werden. Sie dienten als Dokumentation des Softwaresystems, nicht als primäres Quellartefakt. Die Modellgetriebene Softwareentwicklung beschreibt einen Weg, den klassischen Problemen der Anwendungsentwicklung zu begegnen, indem der fachliche Bereich in Form von formalen Modellen zugänglich gemacht wird. Die Entwicklungsgeschwindigkeit und Softwarequalität lassen sich durch automatisierte Transformationen dieser Modelle in Artefakte der Zieltechnologie erhöhen; die Produktivität steigt. 1

14 1 Einleitung 1.1 Problemstellung 1.1 Problemstellung Zum Leistungsspektrum der Saxonia Systems AG 1 gehört die Erstellung individueller Softwarelösungen. In zahlreichen Projekten steht dabei die Entwicklung von Java- Enterprise- 2 Anwendungen im Mittelpunkt. Um die Produktivität bei der Entwicklung solcher Anwendungen zu steigern, soll die modellgetriebene Softwareentwicklung in Form einer Software Factory eingeführt werden. Dazu sind die typischen Architekturmerkmale von Java-EE-Applikationen zu identifizieren und als Grundgerüst von der Software Factory bereitzustellen. Die Verwendung spezieller Plattformen und Frameworks (z. B. Enterprise Java Beans, Spring) muss variabel konfigurierbar sein, sodass auch Projekte, die unterschiedliche Technologien verwenden, die Software Factory zur Anwendungsentwicklung nutzen können. Die Software Factory soll über Plugins (sogenannte Cartridges) für unterschiedliche Technologien erweitert werden können. So ist sie von technologischen Neuerungen im Bereich von Java EE unabhängig und durch die Entwicklung entsprechender Cartridges weiterhin einsetzbar. Für ein konkretes Projekt muss es möglich sein, Cartridges zu bestimmen, die zur Erstellung der Zielartefakte verwendet werden sollen. Um die praktische Eignung der Software Factory nachzuweisen, sind im Rahmen der Diplomarbeit für eine Auswahl an Zieltechnologien exemplarische Cartridges zu entwickeln. Die Entwicklungsplattform Eclipse bietet bereits zahlreiche Plugins zur Unterstützung bei der Erstellung von Java-Enterprise-Anwendungen an. Um die Entwicklung zentral in Eclipse halten zu können, wird eine bestmögliche Integration der Software Factory in diese Entwicklungsumgebung angestrebt. Die Verwendung der Software Factory soll für den Anwendungsentwickler intuitiv und verständlich sein. Hierzu sind zweckmäßige und vertraute Mittel wie Editoren, Modellierungswerkzeuge und Assistenten (Wizards) bereitzustellen. 1 vgl. für nähere Informationen zum Unternehmen 2 kurz: Java EE 2

15 1 Einleitung 1.2 Aufbau der Arbeit 1.2 Aufbau der Arbeit Die vorliegende Arbeit gliedert sich in sechs Kapitel. Nachdem im ersten Kapitel das Thema und Ziel der Arbeit vorgestellt wird, beschreibt Kapitel 2 die grundlegenden Eigenschaften von Java-Enterprise-Anwendungen. Dabei werden Muster zusammengetragen, mit denen sich eine Java-Enterprise-Architektur beschreiben lässt und die später die Elemente einer Modellierungssprache für diese Architektur bilden sollen. Anschließend beschäftigt sich Kapitel 3 mit den Grundlagen modellgetriebener Softwareentwicklung. Es erklärt das Prinzip der Metamodellierung und zeigt am Beispiel der UML, wie eine Modellierungssprache für einen spezifischeren Problemraum erweitert werden kann. Danach wird der Begriff der Software Factory als Grundlage des in der Arbeit erstellten Softwaresystems erörtert. Nach der Vermittlung der theoretischen Voraussetzungen stellt Kapitel 4 dann aktuelle Technologien und Werkzeuge der modellgetriebenen Softwareentwicklung vor. Hierbei stehen vor allem die Technologien im Blickpunkt, die für die Erstellung einer Eclipse-basierten Software Factory von Interesse sind. Das Konzept und die praktische Umsetzung der Software Factory sind Gegenstand des 5. Kapitels. Den Abschluss bildet das Kapitel 6, das die Ergebnisse der Arbeit noch einmal zusammenfasst und auf offene Fragen eingeht. Dies umfasst auch die Angabe von Aufgaben, die im Rahmen zukünftiger Arbeiten zu erledigen sind. 3

16 2 Java-Enterprise-Anwendungen Dieses Kapitel beschreibt die Grundlagen von Java-Enterprise-Anwendungen. An die Ausführungen zu verteilten Anwendungen und der Verwendung von Middleware in verteilten Systemen schließt sich eine Betrachtung des Java-Enterprise-Standards. Danach werden Entwurfsmuster und Frameworks in den Kontext der Entwicklung von Java- Enterprise-Applikationen eingefügt. Abschließend werden wichtige Konzepte und Muster zusammengetragen, die sich als Vokabular zur Beschreibung einer Enterprise-Architektur eignen. 2.1 Verteilte Anwendungen und Middleware Eine Java-Enterprise-Anwendung ist eine verteilte Anwendung, die auf der Middleware- Plattform Java-Enterprise-Plattform (Java EE) basiert. Eine verteilte Anwendung besteht aus weitgehend voneinander unabhängigen Anwendungskomponenten, die an verschiedenen Stellen eines verteilten Systems liegen und miteinander kommunizieren. Die typischen Aufgaben verteilter Anwendungen sind: Präsentation Präsentation bedeutet die Bereitstellung einer interaktiven Benutzerschnittstelle zur Anwendung, z. B. über Webseiten. Anwendungslogik Die Anwendungslogik enthält die Funktionalität, die die Anwendung fachlich bieten soll, d. h. der eigentliche Sinn der Anwendung. Datenhaltung Datenhaltung ist die dauerhafte Speicherung der Daten. Diese Aufgabenteilung führt zu einer oft verwendeten Aufteilung der Architektur in Schichten (engl. Tiers), die in Abbildung 2.1 dargestellt ist. Die Präsentationskompo- 4

17 2 Java-Enterprise-Anwendungen 2.1 Verteilte Anwendungen und Middleware nente liegt auf der Client-Schicht, die Anwendungslogik auf der Mittelschicht und die Datenhaltung auf der Server-Schicht. Abbildung 2.1: 3-Schicht-Architektur nach [Ham05, S. 26] Für die Kommunikation zwischen den Anwendungskomponenten existieren Middleware- Technologien, die von den Kommunikationsmitteln des verteilten Systems abstrahieren. Sie stellen eine Laufzeitumgebung (Container) und Dienste für die Anwendung bereit. Die Laufzeitumgebung verwaltet Ressourcen, ermöglicht die nebenläufige Nutzung der Anwendung und kümmert sich um Sicherheitsaspekte. Typische Dienste sind Sitzungsverwaltung, Transaktionsmanagement und Persistenz. Die Aufteilung der Anwendung in Komponenten als wesentliches Merkmal verteilter Anwendungen wird durch die Middleware unterstützt, indem der Container den Lebenszyklus der Komponenten verwaltet und ihnen benötigte Dienste bereitstellt. Ein Anwendungsserver (Application Server) stellt eine Middleware-Technologie für die Anwendungslogik auf der Mittelschicht dar. Werden Anwendungen auf allen Schichten unterstützt und auch die Anwendungsintegration adressiert, so spricht man von einer Middleware-Plattform [Ham05, S. 60]. Die Java-Enterprise-Plattform ist ein Standard für Middleware-Plattformen. Weitere Standards dieser Art sind.net und Common Object Request Broker Architecture (CORBA). 5

18 2 Java-Enterprise-Anwendungen 2.2 Der Java-Enterprise-Standard 2.2 Der Java-Enterprise-Standard Der Java-Enterprise-Standard [JEE06] bietet eine Spezifikation für das Architekturmodell einer Java-EE-Middleware-Plattform. Das zum Standard gehörende Komponentenmodell Enterprise JavaBeans (EJB) ist von zentraler Bedeutung: Anwendungslogik ist in EJB-Komponenten (Beans) gekapselt, die vom EJB-Container des Anwendungsservers auf der Mittelschicht verwaltet werden. Ein weiterer wichtiger Container ist der Web-Container, der auf dem Webserver läuft und die Ausführung von Webanwendungen ermöglicht. Beans können über Schnittstellen miteinander kommunizieren. Dazu ist es nötig, dass sie im Container angemeldet sind. Das Anmelden (Deployment) erfolgt, indem ein Deployment Descriptor für die Bean erstellt wird. Er definiert Namen und Beantyp und beschreibt, welche Dienste benötigt werden 1. Zusammen mit den kompilierten Java-Klassen wird er dann in ein Jar-Archiv gepackt und auf die Zielplattform kopiert. Alsdann ist die Anmeldung erfolgt und die Komponente verfügbar. Die Java-Enterprise-Plattform stellt eine Reihe von Diensten bereit. Dazu gehören in der aktuellen Version Java EE 5 Dienste für Transaktionsmanagement (Java Transaction API) und Persistenz (Java Persistence API). Für die Präsentationsschicht stehen Technologien wie Java Server Faces (JSF) und Servlets zur Verfügung. 2.3 Muster und Frameworks Mit Java Enterprise existiert eine Plattform, die das Entwickeln verteilter Anwendungen maßgeblich unterstützt. Dies ist jedoch nur die Basis für die Erstellung einer solchen Applikation. Die Anwendungslogik muss in die Formen gegossen werden, die Java EE in Form von Spezifikationen und Application Programming Interfaces (API) bereitstellt; eine aufwändige Arbeit, vor allem bei Verwendung der Java 2 Enterprise Edition (J2EE), dem Vorgänger von Java EE 5. Im Laufe der Zeit haben sich für diese wiederkehrenden Aufgaben Entwurfsmuster (Pat- 1 In Java EE 5 ist es gegenüber der Vorgängerversion J2EE möglich, diverse Einstellungen statt im Deployment Descriptor in Java-Annotationen festzulegen. 6

19 2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster terns) herauskristallisiert, die auf Erfahrungen beruhen und allgemein anwendbar sind. Besonders populäre Kataloge, in denen diese Muster zusammengetragen wurden, sind die Entwurfsmuster der Gang of Four [GHJV95], die Core J2EE Patterns [ACM03] sowie die von Fowler zusammengetragenen Muster für Enterprise Application-Architekturen [Fow03]. Einige dieser Muster werden in Abschnitt 2.4 zur Beschreibung der wichtigsten Konzepte einer Java-Enterprise-Architektur verwendet. Des Weiteren begegnete man der Komplexität der Standards und APIs durch die Entwicklung von Frameworks. Dabei handelt es sich um Programmiergerüste, die eine Anwendungsarchitektur oder Teile davon bereitstellen und durch eine Implementation ergänzt werden müssen. Beispielsweise unterstützt das Persistenz-Framework Hibernate [Hib] die Datenhaltung durch die Abbildung von Java-Klassen auf Tabellen relationaler Datenbanken. Das Framework nimmt diese Mappings entgegen und kümmert sich selbstständig um das korrekte Lesen und Schreiben der Datenbanktabellen. Eine bedeutsame Rolle kommt auch dem Spring-Framework [Spra] zu, das die Anwendungsentwicklung ganzheitlich vereinfacht, indem Komponenten zu einem hohen Grad entkoppelt werden. Dies geschieht basierend auf den Konzepten der Dependency Injection (DI) 2 und der Aspektorientierten Programmierung (AOP). Frameworks wie Spring und Hibernate haben maßgeblich die Entwicklung des Java- Enterprise-Standards beeinflusst. So sind einige innovative Konzepte dieser Frameworks in den mit Java EE 5 eingeführten Technologien EJB3 und Java Persistence API (JPA) übernommen worden. 2.4 Konzepte und Muster einer Java-Enterprise-Architektur In Abschnitt 2.1 wurde bereits ein wichtiges Architekturmerkmal von Java-Enterprise- Anwendungen bzw. Enterprise-Anwendungen im Allgemeinen dargestellt: die Aufteilung in Schichten. Dabei kommt meist eine Struktur mit drei oder mehr Schichten zum Einsatz. Die Anwendungslogik auf der Mittelschicht enthält das fachliche Wissen der Software, d. h. die inhaltlichen Konzepte, für die die Software in Auftrag gegeben wurde. Für die Strukturierung dieses Konzeptraums, auch Domäne genannt, sind verschiedene 2 Dependency Injection und deren Anwendung im Spring-Framework sind in [WB07] ausführlich beschrieben. 7

20 2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster Herangehensweisen möglich. Fowler stellt in [Fow03] drei wesentliche Muster vor: Das Transaction Script organisiert die Domänenlogik nach Prozeduren. Dabei führt eine Benutzeraktion, die über die Präsentationsschicht ausgelöst wird, zur Ausführung einer Prozedur. Diese umfasst einen vollständigen Ablauf, angefangen vom Entgegennehmen der Eingaben über die Durchführung von Berechnungen bis zum Speichern von Daten in Datenbanken. Einen anderen Weg schlägt das Muster Domain Module ein. Statt Prozeduren stehen hier Objekte im Mittelpunkt. Die Domäne wird durch Objekte beschrieben, die miteinander in Beziehung stehen und ihren Teil an der Domänenlogik tragen. Eine Benutzeraktion leitet somit den Aufruf an Objekte entlang einer Kette weiter. Diese Entkopplung von Logik ermöglicht eine einfachere Beherrschung komplexer Abläufe als das Transaction Script, bei dem die gesamte Logik einer Aktion in einem einzigen Script enthalten ist. Das dritte vorgeschlagene Muster ist das Table Module. Es ist dem Domain Model sehr ähnlich, orientiert sich jedoch stärker an dem Konzept der Datenbanktabellen. Es ist im Bereich von Java- Enterprise-Anwendungen kaum verbreitet und kommt vorwiegend in Umgebungen zum Einsatz, die mit Record Sets arbeiten [Fow03, S. 553], wie zum Beispiel.NET Die Architektur des Domänenmodells Ist die Entscheidung gefallen, die Anwendungslogik nach dem objektorientierten Ansatz des Domain Models zu strukturieren, stellt sich die Frage, wie dieses Modell aufgebaut ist, d. h., aus welchen Kernelementen es besteht. Evans trägt in [Eva03] eine Reihe von Mustern zur Beschreibung des Domänenmodells einer Enterprise-Anwendung aus der Sicht des Domain-Driven Designs (DDD) zusammen. Abbildung 2.2 zeigt die wichtigsten dieser Muster in der Übersicht. Ein Domänenmodell kann demnach durch die nachfolgend erläuterten Muster charakterisiert werden. Entitäten Ein wesentlicher Bestandteil sind Entitäten. Sie repräsentieren Objekte einer Domäne. Um in einem Softwaresystem referenzierbar zu sein, haben sie eine eindeutige Identität, die unabhängig vom aktuellen Zustand diese Systems ist und für den gesamten Lebenszyklus des Objekts gleich bleibt. Der Lebenszyklus ist dabei nicht auf die Laufzeit des 8

21 2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster Abbildung 2.2: Muster für Domänenmodelle in Anlehnung an [MA06, S. 36] Systems beschränkt. Die Entität kann auch darüber hinaus fortbestehen, etwa indem sie in eine Datenbank gespeichert wird, und zu einem späteren Zeitpunkt wieder in die laufende Software geladen wird. Entitäten haben stets einen Zustand, der durch ihre Attribute ausgedrückt wird. Das identitätsstiftende Merkmal ist meist ein Attribut oder eine Kombination von Attributen der Entität. Werteobjekte Es gibt Objekte, die in einer Anwendung nicht referenzierbar sein müssen und daher auch keine Objektidentität benötigen. Diese Werteobjekte (Value Objects, VO) 3 stellen lediglich einen Container für Werte dar. Beispielsweise ist ein Datum ein Werteobjekt. Es speichert einen Datumswert, wobei es völlig unerheblich ist, ob das Objekt eindeutig referenzierbar ist. Es ist nur der enthaltene Wert relevant. Werteobjekte sollten unveränderlich sein, damit sie von mehreren Objekten referenziert werden können, um damit Performancegewinne zu erzielen [MA06, S. 35]. Sie können nur geändert werden, indem sie neu erstellt werden. Ein Werteobjekt kann weitere Werteobjekte sowie Referenzen zu Entitäten enthalten. 3 Auch Fowler beschreibt dieses Muster [Fow03, S. 530]. Es ist nicht mit dem Data Transfer Object der Core J2EE Patterns gleichzusetzen, das zuvor auch Value Object hieß [ACM03]. 9

22 2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster Services Das Verhalten einer Domäne lässt sich gedanklich in Aktionen unterteilen. Einige dieser Aktionen lassen sich den Objekten direkt zuordnet. Es gibt jedoch Aktionen, die nicht zu einem bestimmten Objekt gehören, sondern vielmehr domänenspezifisches Verhalten repräsentieren. Dieses Verhalten wird von Services umgesetzt und in Form von Operationen für das Softwaresystem verfügbar gemacht. Die Operationen dienen somit als Schnittstelle für den Zugriff auf Domänenlogik, beispielsweise aus der Präsentationsschicht heraus. Module Bei umfangreichen Anwendungen kann die hohe Anzahl an Domänenobjekten und Services schnell zu Unübersichtlichkeit führen. Daher wird die Domäne in Module unterteilt, die (hauptsächlich funktional) zusammenhängende Teile gruppieren. Durch diese Modularisierung wird die Komplexität der Domäne beherrschbar. Ein funktional kohärentes Modul bietet den Vorteil, ohne Betrachtung weiterer Module einen für sich stehenden Teilaspekt der Domäne auszudrücken. Dies bedeutet nicht, dass Module voneinander isoliert sind. Sie sind über Referenzen verbunden und repräsentieren in ihrer Gesamtheit die Domäne. Während die Objekte und Services innerhalb eines Moduls einen engen Bezug zueinander haben, sind die Module untereinander lose gekoppelt. Diese vier Muster bilden die Grundlage für die Beschreibung eines Domänenmodells einer Enterprise-Anwendung. Abbildung 2.3 veranschaulicht ihr Zusammenspiel an einem einfachen Beispiel. Darüber hinaus haben sich Muster etabliert, die sich mit der Lebenszyklusverwaltung von Objekten befassen. Objekte durchlaufen in einem Softwaresystem einen bestimmten Lebenszyklus. Sie werden erstellt, verändert, möglicherweise persistiert, und gelöscht. Dabei muss die Datenintegrität bewahrt werden, ohne das Domänenmodell mit Komponenten zu überladen, die sich um die Verwaltung des Lebenszyklus kümmern. Die Muster Aggregat, Fabrik und Repository adressieren diese Problematik. 10

23 2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster Abbildung 2.3: Beispiel für ein Domänenmodell einer Enterprise-Anwendung Aggregate Die Objekte einer Domäne stehen in Beziehung zueinander, d. h., sie sind voneinander abhängig. Die Abhängigkeiten sollten generell so gering wie möglich gehalten werden. Das Geflecht an Beziehungen wird sonst unüberschaubar und schlecht wartbar, vor allem wenn Objekte gemeinsam gelöscht werden sollen. Diesem Problem kommt das Aggregat entgegen. Es gruppiert zusammenhängende Entitäten und Werteobjekte, wobei eine Entität die Rolle des Wurzelelements im Aggregat einnimmt. Von außerhalb des Aggregats darf nur auf dieses Element referenziert werden. Es koordiniert den Zugriff auf die anderen enthaltenen Objekte und wenn es gelöscht wird, so wird stets das gesamte Aggregat gelöscht. Dadurch ist die Datenintegrität gewährleistet. Fabriken Die Erstellung von komplexen Objekten kann mitunter recht umfangreich sein, insbesondere wenn sie die Erstellung weiterer Objekte nach sich zieht, so wie es innerhalb von Aggregaten der Fall ist. Solch umfassende Erzeugungslogik wird in eigene Objekte, die Fabriken (Factories), ausgelagert. Eine Fabrik kann dabei für Erstellung einer Entität, 11

24 2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster eines Werteobjekts oder eines Aggregats verantwortlich sein. Repositories Abschließend seien die Repositories erwähnt. Sie kapseln den Zugriff auf persistierte Objekte. Anstatt an jeder Stelle, an der ein Objekt angefordert wird, konkrete Datenbankabfragen zu stellen, wird bei einem Repository angefragt. Dieses leitet die Abfrage an die Datenbank weiter und gibt das gefundene Objekt zurück. Bei Aggregaten bieten Repositories nur Zugriff auf die Entität, die als Wurzelelement fungiert. 12

25 3 Modellgetriebene Softwareentwicklung Dieses Kapitel befasst sich mit der Modellgetriebenen Softwareentwicklung (MDSD). Dabei werden zu Beginn die Grundlagen und Ziele dieses Ansatzes beschrieben. Anschließend folgt eine Betrachtung der Metamodellierung, die in der Modellgetriebenen Softwareentwicklung eine bedeutende Rolle spielt. Im Weiteren wird die MDSD-Ausprägung Model-Driven Architecture der Object Management Group (OMG) vorgestellt, bevor das Kapitel mit der Beschreibung der Software Factories schließt. Diese stellen den theoretischen Hintergrund für die in dieser Arbeit erstellte Software dar. 3.1 Grundlagen Die Modellgetriebene Softwareentwicklung (Model-Driven Software Development, MDSD) 1 beschreibt die Idee, ein Softwaresystem auf einem höherem Abstraktionsniveau als dem von Programmiersprachencode, Konfigurationsdateien und anderen Softwarebestandteilen formal zu beschreiben und daraus automatisiert lauffähige Software zu erzeugen [SVEH07, S. 11]. Die Beschreibung erfolgt in Form von Modellen, die den Ausgangspunkt für die Erstellung des Softwaresystems darstellen. Sind sie primäres Artefakt im Entwicklungsprozess. Dies ist ein herausragendes Merkmal im Vergleich mit der konventionellen Verwendung von Modellen als Mittel zur bloßen Dokumentation und Veranschaulichung von Software. Vor allem mit der Einführung des Notationsstandards Unified Modeling Language (UML) gewannen Modelle zunehmend an Bedeutung. Quellcode ließ sich mit Hilfe von Modellierungswerkzeugen grafisch darstellen (Reverse-Engineering) und wurde mitunter auch zur erneuten Erzeugung des Quellcodes verwendet (Roundtrip-Engineering), was häufig zu Konsistenzproblemen führte. Die Schwierigkeiten zogen in der Praxis meist die 1 auch: Model-Driven Development, MDD 13

26 3 Modellgetriebene Softwareentwicklung 3.1 Grundlagen Entscheidung nach sich, die Nutzung von Modellen aufzugeben [SV05, S. 15]. Der größte Nachteil von Reverse- und Roundtrip-Engineering ist jedoch, dass das Abstraktionsniveau nicht wesentlich über das von Programmiersprachen gehoben wird. Die Modellgetriebene Softwareentwicklung zielt darauf ab, Software auf einer höheren Ebene zu modellieren, d. h. mit den Konzepten eines abgegrenzten Problemraums (Domäne), der den Wirkungsbereich der Software beschreibt. Um aus diesen Modellen automatisiert lauffähige Software zu erstellen, ist es erforderlich, dass die Modelle formal sind, damit sie von Transformatoren und Generatoren verabeitet werden können. Zur Formalisierung der Modelle wird eine Sprache benötigt, mit deren Vokabular sich das domänenspezifische Wissen ausdrücken lässt (Domänenspezifische Sprache, DSL). Die formalen Modelle werden durch Transformationen sukzessiv an die Zielplattform herangebracht. Der letzte Schritt in der Transformationskette ist dabei die Erstellung der Zielartefakte wie z. B. Quellcode, Testskripte und Konfigurationsdateien Begriffe Im Folgenden werden einige wichtige Begriffe erklärt, die zur Beschreibung des Konzeptes der Modellgetriebenen Softwareentwicklung benötigt werden. Domäne Eine Domäne bezeichnet einen abgegrenzten Problemraum, d. h. einen Interessenbereich, über den Wissen verfügbar ist. Die Anwendung von MDSD bezieht sich immer auf eine solche Domäne. Diese kann fachlicher Natur (z. B. Finanzen, Krankenkasse) oder technischer Natur (z. B. Persistenz, Workflow) sein. Domänen können auch in Unterdomänen gegliedert sein. In der vorliegenden Arbeit ist die Domäne die Architektur von Java- Enterprise-Anwendungen. Formale Sprachen Eine Sprache ist dann formal, wenn ihre Syntax und ihre Semantik formal spezifiziert sind. Die Syntax legt die Struktur einer Sprache fest und die Semantik gibt dieser Struk- 14

27 3 Modellgetriebene Softwareentwicklung 3.1 Grundlagen tur eine Bedeutung. Es wird zwischen abstrakter und konkreter Syntax unterschieden: Die abstrakte Syntax bestimmt, welche Elemente die Sprache enthält und wie diese aus anderen Elementen gebildet werden. Die konkrete Syntax definiert die Ausdrucksmittel, mit der die abstrakte Syntax formuliert werden kann. Dazu zählen grafische Darstellungsformen und Notationsregeln. Eine abstrakte Syntax lässt sich also durch unterschiedliche konkrete Syntaxformen darstellen und ist somit wiederverwendbar. Die statische Semantik legt fest, wie Instanzen von Sprachkonstrukten miteinander verbunden werden müssen, um eine Bedeutung zu erhalten. Dies wird auch als Wohlgeformtheit bezeichnet. Die eigentliche Bedeutung des wohlgeformten Konstruktes wird durch die dynamische Semantik bestimmt. Domänenspezifische Sprachen Eine domänenspezifische Sprache (Domain-Specific Language, DSL) hat die Aufgabe, eine formale Beschreibung wesentlicher Aspekte der Domäne zu ermöglichen. Sie enthält die abstrakte Syntax, eine entsprechende konkrete Syntax sowie die statische Semantik. Abstrakte Syntax und statische Semantik werden durch ein Metamodell festgelegt (vgl. Abschnitt 3.2). Die konkrete Syntax kann grafischer oder textueller Natur sein. Die dynamische Semantik der DSL leitet sich aus dem Domänenwissen ab Ziele Der Ansatz der Modellgetriebenen Softwareentwicklung hat zum Ziel, den Anforderungen an moderne Softwaresysteme gerecht zu werden. Der Auftraggeber erwartet robuste Software in hoher Qualität, wobei die Entwicklungskosten sowie die Entwicklungszeit gering zu halten sind. MDSD versteht sich als ein weiterer Schritt in der Entwicklung der Softwaretechnologie, um diese Anforderungen bestmöglich zu erfüllen. Im Besonderen werden mit dem modellgetriebenen Ansatz die folgenden Ziele erreicht (vgl. [SV05]): 15

28 3 Modellgetriebene Softwareentwicklung 3.2 Metamodellierung Durch die automatisierte Codeerstellung aus den Modellen wird eine Erhöhung der Entwicklungsgeschwindigkeit erreicht. Die zeitaufwändige manuelle Codierung wird eingedämmt und somit der Fokus des Entwicklers mehr auf die Umsetzung der fachlichen Anforderungen gelenkt. Die Qualität der Software wird erhöht, da die Zielartefakte aus formal definierten Modellen abgeleitet werden. Diese Modelle sind in einer domänenspezifischen Sprache formuliert, wodurch die Fachlogik präziser beschrieben werden kann, als z. B. mit Allzweckprogrammiersprachen. Der Einsatz von auf eine Domäne zugeschnittenen Sprachen fördert die Kommunikation zwischen IT-Fachleuten und Auftraggebern [LS06]. Die Wiederverwendbarkeit wird gefördert, da einmal erstellte DSLs, Transformations- und Generierungsvorschriften für die Erstellung aller Produkte der Problemdomäne genutzt werden können. Die Verbindung von fachlichen Anforderungen und nichtfunktionalen Anforderungen wird zentral in den Transformationsvorschriften gehalten. Dadurch erhöht sich die Wartbarkeit der Software. Der fortwährende Technologiewandel wird beherrschbar, denn Domänenwissen und Technologiespezifika werden in unterschiedlichen Modellen gehalten und erst durch Transformation und Generierung miteinander in Verbindung gebracht. Beim Austausch der gewählten Technologie bleibt die Fachlichkeit unberührt. Nicht zuletzt wird mit den genannten Zielen auch die Reduzierung der Softwareentwicklungskosten angestrebt. 3.2 Metamodellierung Wie dargestellt, werden Modelle im Kontext der modellgetriebenen Softwareentwicklung mit Hilfe von domänenspezifischen Sprachen formuliert. Ein Metamodell (MM) legt die zur DSL gehörende abstrakte Syntax sowie die statische Semantik fest. Des Weiteren werden Metamodelle für die Modellvalidierung, -transformation sowie zur Erstellung 16

29 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture von Modellierungswerkzeugen benötigt (vgl. [SV05, S. 91]). Ein Metamodell ist ein Modell, das die Syntax eines anderen Modells definiert. Aussagen über die inhaltliche Bedeutung des Modells werden dabei nicht gemacht. Das Metamodell befindet sich auf einer höheren (Meta-)Ebene als das Modell, es ist jedoch möglich, dass beide Modelle dieselbe konkrete Syntax verwenden. Die abstrakte Syntax sowie die Semantik des Metamodells sind aber unterschiedlich. Ein Modell wird als Instanz seines Metamodells angesehen, somit sind alle Modellelemente Instanzen der Metamodellelemente. Um ein Metamodell zu beschreiben, wird ebenfalls ein (Meta-)Metamodell verwendet, welches wiederum durch ein Metamodell definiert ist. Dadurch ergibt sich eine Metamodellarchitektur mit beliebig vielen Modellebenen. In der Praxis beschränkt man sich jedoch auf eine vierschichtige Architektur, wie sie durch die OMG in der Spezifikation der Meta Object Facility (MOF) in Version 1.4 beschrieben ist. Abbildung 3.1 zeigt sie an einem Beispiel: Das MOF-Modell auf Ebene M3 definiert ein Element Class. Dieses ermöglicht die Beschreibung des UML-Metamodellelements Class auf Ebene M2. Mit Hilfe dieses Elements lässt sich eine Klasse in einem UML-Modell definieren, hier die Klasse Person. Zur Laufzeit wird dann eine Instanz dieser Klasse erzeugt, welches in der UML-Terminologie auch als Objekt bezeichnet wird. Im Beispiel in Abbildung 3.1 ist die Person David ein solches Objekt. 3.3 Model-Driven Architecture Die Model-Driven Architecture (MDA) ist ein Ansatz der modellgetriebenen Softwareentwicklung, der von der Object Management Group (OMG), einem Konsortium, das Industriestandards für die Softwaretechnologie entwickelt, vorangetrieben wird [MDA]. Kernbestandteile der MDA sind die drei OMG-Spezifikationen Meta Object Facility (MOF), Unified Modeling Language (UML) und Common Warehouse Metamodel (CWM) [PM06]. Die Grundidee ist die Trennung von fachlichen Details eines Softwaresystems und der Technologieplattform, auf der diese Fachlichkeit später ausgeführt werden soll. Beide Aspekte werden erst durch Modelltransformationen zusammen gebracht, zuvor sind sie aber unabhängig voneinander und somit auch einzeln bearbeitbar und austauschbar. 17

30 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture Abbildung 3.1: Metamodellarchitektur nach [MOF05] 18

31 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture Abbildung 3.2: Offizielles Symbol der MDA Ziele Da die MDA eine Ausprägung der MDSD ist, verfolgt sie auch die in Abschnitt auf S. 15 genannten Ziele. Darüber hinaus konzentriert sich die Model-Driven Architecture nach [SV05] auf zwei weitere Ziele für zukünftige Softwaresysteme: Interoperabilität, d. h. Herstellerunabhängigkeit durch Standardisierung Portabilität (Plattformunabhängigkeit) Die MDA stellt dazu Richtlinien und Standards wie etwa MOF und UML bereit. Wenn die Hersteller von Werkzeugen und Editoren diese Standards umsetzen, kann eine leistungsfähige Werkzeugkette für die modellgetriebene Softwareentwicklung aufgebaut werden. Statt proprietärer und inkombatibler Formate verfügen die Werkzeuge über eine einheitliche Schnittstelle. MDA-konforme Modelle können dann zwischen den Werkzeugen über Systemgrenzen hinweg (Portabilität) ausgetauscht werden. 19

32 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture MDA-Modelle Um die zuvor genannte Trennung der fachlichen von der technischen Spezifikation zu ermöglichen, werden in der MDA die folgenden Modelle definiert: Plattformunabhängiges Modell In einem Plattformunabhängigen Modell (Platform-Independent Model, PIM) werden die fachlichen Aspekte definiert. Eine an die Domäne angepasste Modellierungssprache (DSL) legt dafür die Syntax fest. Technologische Details kommen im PIM zu keiner Zeit vor. Das im PIM enthaltene Fachwissen ist somit nicht an eine spezielle Plattform gebunden und demzufolge für den Einsatz auf mehreren Plattformen vewendbar. Plattformmodell Das Plattformmodell (Platform Model, PM) ist ein Modell, das die Struktur und die Konzepte einer Zielplattform beschreibt. Es abstrahiert über die Implementierung der Plattform, da die technologischen Details für das Verständnis der Funktionsweise der Plattform nicht notwendig sind. Das PM enthält keine fachlichen Informationen. Plattformspezifisches Modell Durch automatisierte Modelltransformationen wird das PIM in ein Plattformspezifisches Modell (Platform-Specific Model, PSM) überführt. In diesem Transformationsschritt wird das Modell um die plattformspezifischen Konzepte eines PMs erweitert. Da der Begriff der Plattform relativ ist, kann das PSM wiederum als PIM gegenüber der darunter liegenden Plattform angesehen werden. Das heißt, das Fachmodell wird über mehrere Plattformen transformiert, wobei als letzter Transformationsschritt die Erzeugung der Zielartefakte wie z. B. Quellcode 2 steht. Im einfachsten Fall ohne Zwischenmodelle besteht der Erstellungsprozess also aus einem Transformationsschritt. Plattformspezifische Implementierung Die Plattformspezifische Implementierung (Platform-Specific Implementation, PSI) ist der Quellcode, der die fachliche Logik auf der Zielplattform letztendlich zur Ausführung bringt. Die PSI ist ein PSM, das aus Quellcode besteht, eine Unterscheidung der beiden Modelle ist daher nicht zwingend nötig (vgl. [PM06, S. 106]). 2 Die Bezeichnung Quellcode ist im Kontext der MDSD irreführend, da er ein Zielartefakt der Generierung darstellt. Erst zur Übersetzungszeit nimmt der Quellcode wieder die Rolle eines Quellartefaktes für den Compiler ein. 20

33 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture Eine unbedeutendere Rolle spielt das Computation-Independent Model (CIM). Es beschreibt das System aus einer noch abstrakteren Sicht als das PIM und muss nicht formal sein. Das CIM wird (nicht zwangsläufig automatisch) in das PIM überführt Metamodellarchitektur Wie in Abschnitt 3.2 vorgestellt, definiert die OMG in der MOF-Spezifikation [MOF05] eine vierschichtige Metamodellarchitektur. Sie ist in Abbildung 3.3 dargestellt: Auf der Abbildung 3.3: MDA-Metamodellarchitektur Metaebene M2 befindet sich die Modellierungssprache UML. Ihr Metamodell ist die MOF auf Ebene M3, welche die oberste der vier Ebenen darstellt. Da es darüber keine weitere Modellebene gibt, wird die MOF also selbst durch M3-Modelle beschrieben (siehe 3.3.4). Modelle, die durch die UML beschrieben sind, befinden sich auf der Ebene M1. Das sind vom Nutzer erstellte UML-Diagramme, in denen das Domänenwissen modelliert wird. Konkrete Ausprägungen der dort definierten Objekte zur Laufzeit sind in der Datenebene M0. 21

34 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture Spezifikationen Nachfolgend werden die wichtigsten der von der OMG spezifizierten MDA-Standards vorgestellt: Meta Object Facility Die erste Version der Meta Object Facility (MOF) wurde 1997 von der OMG spezifiziert. Aktuell gibt es die MOF 2.0 [MOF06]. MOF ist eine (Meta-)Metamodellsprache zur Beschreibung von Metamodellsprachen wie UML oder CWM. Sie nutzt aus der UML bekannte Konzepte wie Klassen und Vererbung 3. MOF befindet sich auf der Metaebene M3 und beschreibt sich selbst. Dies ist möglich, da sowohl MOF als auch UML die Infrastructure Library (IL) verwenden, welche grundsätzliche Konzepte für Metamodellsprachen und einen Erweiterungsmechanismus bereithält. Die IL wird also auf den Ebenen M2 und M3 verwendet. Folglich lassen sich mit M3-Modellen neben M2-Modellen auch M3-Modelle beschreiben. Ausführliche Beschreibungen des Zusammenspiels von MOF, UML und IL finden sich in der MOF-Spezifikation [MOF06] und in [PM06, S. 61ff.]. Die Meta Object Facility ist in zwei Teile gegliedert: Die Essential MOF (EMOF) bildet den Kern und spezifiziert Modellelemente, die in den meisten Fällen für die Definition geeigneter Metamodelle zur Beschreibung von Softwaresystemen ausreichen. Das Metamodell Ecore des Eclipse Modeling Frameworks, das in Abschnitt vorgestellt wird, verwendet EMOF als Vorlage [GPR06, S.292]. Um umfangreichere Metamodelle zu erstellen, kann die Complete MOF (CMOF) verwendet werden. Sie ergänzt EMOF um Reflection- und Erweiterungskomponenten. XML Metadata Interchange In Abschnitt wurde erläutert, dass die Austauschbarkeit der Modelle über verschiedene Werkzeuge eines der Hauptziele der MDA darstellt. Die MOF-Spezifikation bringt dafür ein serialisierbares Modellformat mit, das XML Metadata Interchange (XMI) [XMI05]. Leider ist die Unterstützung des XMI-Formates durch die derzeit auf 3 Die UML gab es schon vor der MOF. MOF wurde später als Grundlage für die formale Beschreibung der UML entwickelt [SV05, S. 96]. 22

35 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture dem Markt erhältlichen Modellierungswerkzeuge teilweise noch mangelhaft (vgl. [SV05, S. 377]). Listing 3.1 zeigt beispielhaft eine UML-Klasse als XMI-Datei [XMI05, S. 16f.]. < xmi:xmi xmlns:uml =" http: // schema. omg. org / spec / UML /2.0 " xmlns:xmi =" http: // schema. omg. org / spec / XMI /2.1 "> < UML:Class name ="C1"> < feature xmi:type =" UML:Attribute " name ="a1" visibility =" private "/> </ UML:Class > </ xmi:xmi > Listing 3.1: UML-Modell als XMI-Dokument Unified Modeling Language Die Unified Modeling Language (UML) [UML07a]/[UML07b] ist eine Modellierungssprache, mit der sich statische Strukturen und dynamisches Verhalten abbilden lassen. Obwohl sie hauptsächlich für die Beschreibung von Struktur und Verhalten von Softwaresystemen verwendet wird, lässt sich die UML prinzipiell für viele Arten von Daten nutzen, deren grafische Visualisierung das Verständnis ihrer Bedeutung fördert. So kommt die UML auch häufig zur Geschäftsprozessmodellierung zum Einsatz. Das Metamodell der UML ist die MOF, wobei beide auch gemeinsame Komponenten nutzen (siehe Abschnitt 3.3.4). Die seit 2005 bestehende Version 2.0 definiert 13 Diagramme, mit denen ein System umfassend beschrieben werden kann. Tabelle 3.1 gibt einen Überblick über ausgewählte Diagramme und ihre Funktion. Object Constraint Language Ein weiterer OMG-Standard ist die Object Constraint Language (OCL) [OCL06]. Sie ist eine formale, deklarative Sprache und ermöglicht es, die statische Semantik von Modellen (meist sind dies UML-Modelle) zu spezifizieren. Mit Hilfe der OCL lassen sich Vorund Nachbedingungen sowie Klasseninvarianten in Form von logischen Ausdrücken formulieren. OCL-Ausdrücke sind aber z. B. auch für die Beschreibung von Modellabfragen (Queries) hilfreich. 23

36 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture Diagramm Verwendung Strukturdiagramme Klassendiagramm Objektdiagramm Komponentendiagramm Paketdiagramm beschreibt die statischen Elemente (Klassen) und deren Beziehungen zueinander zeigt aktuelle Ausprägungen dieser Klassen (Objekte) modelliert die Beziehungen und Abhängigkeiten der Systemkomponennten visualisiert die Gruppierung von Klassen (Pakete) und deren Beziehungen Verhaltensdiagramme Anwendungsfalldiagramm Aktivitätsdiagramm Zustandsdiagramm Sequenzdiagramm beschreibt die Beziehungen zwischen den Anwendungsfällen und den Akteuren stellt das Verhalten einer Klasse oder Komponente dar modelliert Systemzustände, deren Übergänge und Ereignisse veranschaulicht die zeitliche Abfolge von Interaktionen zwischen Objekten Tabelle 3.1: UML-Diagrammtypen MOF Query/View/Transformation Für die im Abschnitt beschriebenen Modelltransformationen bedarf es einer Transformationssprache. Die OMG hat einen Standard zur Definition solcher Sprachen auf den Weg gebracht, die Query/View/Transformation (QVT) [QVT07]. In Abbildung 3.4 ist die Architektur von QVT dargestellt: QVT erlaubt die Spezifikation von Trans- Abbildung 3.4: QVT-Architektur nach [QVT07, S. 9] formationen auf deklarative (Relations) und imperative (Operational Mappings) Weise. Deklarativ bedeutet, dass Gleichheitsbeziehungen zwischen Elementen des Quell- und 24

37 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture des Zielmetamodells definiert werden, die nach Ausführung der Transformation wahr sind. Diese Variante wird nach Bohlen [Boh06b, S. 1] von der OMG empfohlen. Operational Mappings ermöglicht es hingegen, Transformation imperativ anzugeben, was für Entwickler intuitiver anwendbar ist [Boh06b, S. 1]. Die Komponente Black Box sieht die Einbindung von Transformationssprachen vor, die nicht auf QVT beruhen. Der QVT-Standard ist bislang noch nicht endgültig verabschiedet worden. Allerdings gibt es bereits Implementierungen, die Teile des Standards umsetzen. So z. B. medini QVT [med] oder die Atlas Transformation Language (ATL), die in Abschnitt 4.4 vorgestellt wird Domänenspezifische Modellerweiterung der UML In Abschnitt wurde darauf hingewiesen, dass sich die Modellgetriebene Softwareentwicklung immer auf einen konkreten Problemraum, eine Domäne, bezieht. Um Wissen und Fachlogik aus einer solchen Domäne auszudrücken, ist eine domänenspezifische Sprache von Vorteil. Die im Kontext der Model-Driven Architecture überwiegend eingesetzte UML allein ist aber eine Allzweckmodellierungssprache und muss erst an die konkrete Domäne angepasst werden. UML und MOF in den aktuellen Spezifikationen stellen dafür zwei Erweiterungsmechanismen bereit: die schwer- und die leichtgewichtige Erweiterung. Ergänzt werden diese durch den feder- und den mittelgewichtigen Ansatz, welche in [Hus07] beschrieben sind. Schwergewichtige Erweiterung Der schwergewichtige Ansatz ist, ein Metamodell zu erstellen, das den Anforderungen der Domäne gerecht wird und dieses mit Teilen des UML-Metamodells zu einem neuen Metamodell zu vereinen. Dieser Erweiterungsmechanismus ist in der MOF 2.0 spezifiziert, und wird dort ebenfalls vielfacht angewandt [MOF06]. Der Nachteil dieser Herangehensweise liegt in der Gefahr, sich von Standards zu entfernen und so die Verarbeitbarkeit durch Werkzeuge zu verlieren. Des Weiteren erfordert der Ansatz ausreichende Kenntnisse der Metamodellierung innerhalb der MOF. 25

38 3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture Leichtgewichtige Erweiterung Ein anderer Weg ist die leichtgewichtige Erweiterung durch UML-Profile [UML07a, S. 173ff.]. Ein Profil ist eine Menge von Stereotypen, Tagged Values und Zusicherungen. Stereotypen sind Metamodellelemente, mit denen UML-Metamodellelemente durch semantische Informationen angereichert werden können 4. Bei der Definition eines Stereotyps muss festlegt werden, für welche Elemente er angewendet werden kann (z. B. Class, Property). Einem Element können beliebig viele Stereotypen zugeordnet werden. Stereotypen können zusätzliche Attribute enthalten, so genannte Tagged Values. Dabei handelt es sich um einfache Schlüssel-Wert-Paare, mit denen weitere semantische Details ausgedrückt werden können. Abbildung 3.5a zeigt die Vereinbarung eines Stereotyps mit einem Tagged Value. Dieser Stereotyp wird in Abbildung 3.5b einer Klasse zugeordnet. Eine weitere Möglichkeit der Beschreibung von Semantik mit UML-Profilen sind Zusicherungen (Constraints). Das sind OCL-Ausdrücke, mit denen Bedingungen und Invarianten formuliert werden können (siehe Abschnitt auf S. 23). Beispielsweise könnte für die Klasse Entity in Abbildung 3.5a die Zusicherung tablename.length > 2 festgelegt werden. (a) Der Stereotyp Entity ist auf Elemente vom Typ Class anwendbar und enthält den Tagged Value tablename. (b) Anwendung des Stereotyps Entity auf die Klasse Person. Dem Attribut tablename wird ein Wert zugewiesen. Abbildung 3.5: Definition und Anwendung eines Stereotyps 4 Vielmehr ist der Profilmechanismus nicht nur für das UML-Metamodell, sondern generell für MOFkonforme Metamodelle anwendbar (vgl. [PM06, S. 74]). 26

39 3 Modellgetriebene Softwareentwicklung 3.4 Software Factories Federgewichtige Erweiterung Die federgewichtige Variante [Hus07, S ] sieht vor, das Metamodell unverändert zu lassen und stattdessen die Elemente des UML-Modells mit Stichwörtern zu versehen. Damit ist dies die leichtgewichtigste der vier Varianten bezogen auf das Maß an Metamodellierung. Der Nachteil ist hier, dass die Stichwörter weder strukturiert sind noch in Beziehung zueinander stehen, sodass sich keine Strukturinformationen über die Domäne ausdrücken lassen. Die Erstellung eines domänenspezifischen Editors ist bei diesem Ansatz ebenfalls ausgeschlossen, da die Stichwörter nicht Teil des Metamodells sind, der Editor allerdings auf diesem basiert. Mittelgewichtige Erweiterung Der vierte Ansatz ist die mittelgewichtige Erweiterung [Hus07, S ]. Die Domäne bekommt dabei ein eigenes Metamodell, welches das UML-Metamodell durch Spezialisierung erweitert. Das bedeutet, dass die Metamodellklassen von den Klassen des UML- Metamodells erben und ihre domänenspezifischen Merkmale durch zusätzliche Attribute oder Spezialisierung der Attribute der Oberklassen ausdrücken 5. Abbildung 3.6 verdeutlicht dies an einem Beispiel. Der mittelgewichtige Ansatz gewährt mehr Freiheiten bei der Metamodellierung als der leichtgewichtige, ohne dabei die Nachteile eines komplett neuen Metamodells bei der schwergewichtigen Erweiterung in Kauf nehmen zu müssen. 3.4 Software Factories Nachfolgend soll der Begriff der Software Factory (SF, Softwarefabrik) erläutert und die Verbindung zur MDA hergestellt werden. 5 Die Spezialisierungskonstrukte für Attribute sind in [UML07a, Kap. 11.3] definiert und werden in [AP05] ausführlich erläutert. 27

40 3 Modellgetriebene Softwareentwicklung 3.4 Software Factories Abbildung 3.6: Die Klassen des Domänen-Metamodells erben von UML-Metamodell- Klassen; das Referenzattribut entities der Klasse Module spezialisiert das geerbte Referenzattribut packagedelement Der Begriff in der Literatur In der Literatur finden sich sehr unterschiedliche Ansichten darüber, was eine Software Factory ist. So sehen Aaen et al. [ABM97] den Terminus als eine Beschreibung der Organisation innerhalb eines Unternehmens, in dem Software entwickelt wird. Demnach gibt eine Software Factory vor, welche Softwareentwicklungsprozesse zur Anwendung kommen, wie Softwareprojekte verwaltet werden und legt fest, welche Methoden und Werkzeuge den Entwicklern zur Verfügung stehen. Ziel ist dabei, die Produktivität der Entwicklung und die Qualität der Produkte zu erhöhen. Eine andere Bedeutung erhält der Begriff in Microsofts Software-Factory-Initiative (mehr dazu in Abschnitt 4.7), deren theoretische Grundlagen von Greenfield et al. in [GS + 06] beschrieben sind. Die Autoren definieren darin eine Software Factory als eine Software- Produktlinie, die erweiterbare Werkzeuge, Prozesse und Inhalte... konfiguriert,..., um die Entwicklung und Wartung von Varianten eines archetypischen Produkts zu automatisieren.... Die Kernaussage dieses Ansatzes ist, dass ähnliche Softwareprodukte in einer einheitlichen Entwicklungsumgebung hergestellt werden, die dynamisch an die Besonderheiten der einzelnen Produkte angepasst werden kann. Der Anwendungsbereich 28

41 3 Modellgetriebene Softwareentwicklung 3.4 Software Factories der Produktfamilie 6 muss klar abgegrenzt, sodass sich die Architektur der Anwendungen samt ihrer Variabilitäten formal in Modellen beschreiben lässt. Daraus werden automatisiert, unter Einbeziehung von Templates, Frameworks und Entwurfsmustern, Artefakte des zu entwickelnden Produktes generiert. Das von den Autoren erarbeitete Konzept zielt vor allem auf eine schnellere und produktivere Erstellung von Softwareprodukten innerhalb einer Produktlinie ab Eigene Interpretation Für die Beschreibung der Software Factory für Java-Enterprise-Anwendungen, die Gegenstand dieser Arbeit ist (siehe Kapitel 5), soll eine eigene Auslegung des Software- Factory-Begriffs den Weg bereiten. Der von Greenfield et al. dargestellte Ansatz dient dafür als Vorlage. Eine Software Factory bezweckt die Systematisierung der Entwicklung von Softwareprodukten einer Software-Produktlinie. Das sind Anwendungen oder Anwendungskomponenten mit wesentlichen gemeinsamen Eigenschaften, die fachlicher oder technologischer Natur sind [SVEH07, S. 238]. Das gemeinsame Konzept der Produktfamilie ist in einer Domäne zusammengefasst. Darüber hinaus existieren Unterschiede zwischen den Familienmitgliedern, die diese innerhalb der Produktfamilie einzigartig machen. Diese Idee ist unter dem Begriff Product Line Engineering (PLE) 7 zusammengefasst und wird u. a. in [vdlsr07] und [SPL] eingehend erläutert. Die Festlegung einer abgeschlossenen Domäne und definierter Punkte, an denen sich die Produkte unterscheiden, ebnet den Weg für eine systematische Entwicklung von ähnlichen Softwareprodukten, was durch die Ausschöpfung des Potenzials der modellgetriebenen Softwareentwicklung erreicht wird. So kommt die MDSD zum Einsatz, indem ein Generator aus dem Modell der gemeinsamen Domäne einheitlich für alle Familienmitglieder die Artefakte der Zielplattform erstellt; das bedeutet, dass die Generatortemplates systematisch wiederverwendet werden. Die variablen Eigenschaften werden in Bausteinen gekapselt, die das Wissen über diese von der Domäne nicht erfassten Merkmale in Form von DSLs und Templates enthalten. Bei der Entwicklung eines Produkts der Produktfamilie muss festgelegt werden, welche variablen Attribute verwendet werden. Dabei kann der Zeitpunkt dieser Entscheidung variieren (vgl. [SVEH07, S. 243]). 6 Produktlinie und Produktfamilie werden gleichbedeutend gebraucht. 7 Im Gebiet der Softwareentwicklung spezieller Software Product Line Engineering (SPLE). 29

42 3 Modellgetriebene Softwareentwicklung 3.4 Software Factories Eine Software Factory stellt die Infrastruktur für die Entwicklung von Software im Sinne von SPLE zur Verfügung. Sie bezieht sich auf eine vorgegebene Domäne und ermöglicht die Entwicklung von Softwareprodukten, die auf den Konzepten dieser Domäne basieren. Idealerweise stellt sie eine Entwicklungsumgebung zur Verfügung, die den gesamten Erstellungsprozess der Produkte umfasst. Über definierte Erweiterungspunkte lässt sich die Software Factory mit Bausteinen für bestimmte, von der Domäne nicht modellierte, Merkmale ergänzen. Mit Hilfe dieser Schnittstellen können die Bausteine miteinander kommunizieren. Der Zeitpunkt der Entscheidung, welche variablen Eigenschaften ein konkretes Produkt der Software-Produktfamilie verwendet, wird von der Software Factory vorgegeben. Durch die Verwendung der MDSD wird der Erstellungsprozess automatisiert, was die Entwicklungsgeschwindigkeit erhöht und zu robusterer Software führt. Dies wird dadurch unterstützt, dass das Domänenwissen in formalen Modellen vorliegt. Diese dienen als Eingabe für Generatoren, welche die Anwendungsartefakte erzeugen Rollenverteilung Bei der Betrachtung des Konzeptes der Software Factory ist zu beachten, dass unabhängig von den Produkten der Produktfamilie auch die Software Factory einem stetigen Veränderungsprozess unterliegt. Die Entwicklung der Anwendung und die Entwicklung der Software Factory werden getrennt betrachtet. Dies führt zu zwei verschiedenen Rollen, die nicht zwangsläufig von derselben Person oder Personengruppe ausgefüllt werden. Der Software-Factory-Entwickler beschäftigt sich mit der Instandhaltung und Weiterentwicklung der Software Factory. Dies beinhaltet auch die fortwährende Überprüfung des Domänenmodells hinsichtlich der korrekten Wiedergabe der Domäne, des Problemraums, für den die Software Factory existiert. Er legt die Variabilitätspunkte fest, die durch spezielle Bausteine erweitert werden können. Auf der anderen Seite steht der Anwendungsentwickler, der die Software Factory nutzt. Er modelliert die Anwendung mit den Ausdrucksmitteln (vor allem DSLs), die von der Software Factory zur Verfügung gestellt werden, und profitiert dabei von der zu diesem Zweck bereitgestellten Entwicklungsumgebung. Er stößt die Generatoren an, die aus den von ihm erstellten Modellen die Zielartefakte erzeugen. Eine regelmäßige Kommunikation zwischen beiden Rollen stellt sicher, dass die Software 30

43 3 Modellgetriebene Softwareentwicklung 3.4 Software Factories Factory auch den Zweck erfüllt, den sie beabsichtigt, und sich im praktischen Einsatz bewährt. Kapitel 5 greift die Rollenverteilung im Zuge der Beschreibung der Software Factory für Java-Enterprise-Anwendungen noch einmal auf Software Factories und MDA Nachdem die Model-Driven Architecture und die Software Factories erläutert wurden, soll abschließend geklärt werden, welche Verbindung zwischen diesen beiden Konzepten besteht. Software Factories zielen ausdrücklich auf den Einsatz im Product Line Engineering ab, d. h., mit einer Software Factory soll die Entwicklung von Produkten einer Produktfamilie systematisiert und automatisiert werden. Die Model-Driven Architecture macht keine Aussagen darüber, in welchem Kontext sie gebraucht werden soll. Ein Anwendungsfall ist jedoch, die MDA als Umsetzung der MDSD-Komponente einer Software Factory zu verwenden. Damit wird festgelegt, dass eine solche MDA-basierte Software Factory z. B. mit den MDA-Konzepten Plattformunabhängiges Modell und Plattformmodell arbeitet und diese Modelle mit MOF-Sprachen wie UML umgesetzt werden. Der Software-Factory- Ansatz gibt per se nicht vor, ob und welche Standards zum Einsatz kommen sollen. So lehnen etwa die Entwickler der Microsoft Software Factories die UML für die Erstellung domänenspezifischer Sprachen gänzlich ab [GS + 06, S. 453]. In diesem Zusammenhang sind oft auch die verfolgten Ziele ausschlaggebend. Während die MDA durch Standardisierung eine bestmögliche Interoperabilität und Portabilität anstrebt, muss dies für eine Software Factory nicht der Fall sein. Hier können andere Zielgrößen vorrangig sein (z. B. eine nahtlose Integration in ein bestehendes Softwaresystem), für die die Nutzung der teils sehr komplexen MDA-Standards eher hinderlich wäre. 31

44 4 Technologien und Werkzeuge der MDSD In diesem Kapitel sollen bedeutende Technologien, Frameworks und Werkzeuge der modellgetriebenen Softwareentwicklung vorgestellt werden. Dabei reicht der Überblick von einfachen Frameworks zur Erstellung von Metamodellen bis hin zu kompletten MDSD- Produkten und Software Factories. 4.1 Eclipse Obwohl die Eclipse-Plattform kein MDSD-spezifisches Werkzeug ist, soll sie trotzdem in diesem Kapitel vorgestellt werden, da sie in der im Rahmen der Diplomarbeit erstellten Software Factory eine grundsätzliche Rolle spielt und einige der hier genannten Technologien auf Eclipse beruhen. Eclipse [Ecl] ist eine Integrierte Entwicklungsumgebung (Integrated Development Environment, IDE). Sie wurde im November 2001 von IBM, OTI und acht weiteren Unternehmen ins Leben gerufen und hat sich seitdem zu einer der meist genutzten IDEs entwickelt. Eclipse ist Open-Source-Software und wird unter der Eclipse Public License (EPL) angeboten. Diese Lizenz erlaubt die kostenfreie, kommerzielle und nichtkommerzielle Nutzung sowie die Verbreitung des Quelltextes. Die Software versteht sich nicht als Entwicklungswerkzeug. Vielmehr wird eine einheitliche Plattform zur Verfügung gestellt, für die Werkzeuge entwickelt werden können, die als Plugins in die Eclipse-Plattform einbinden lassen. Die Eclipse-Software selbst enthält zunächst nur wenige Plugins. Darunter befinden sich eine komplette Entwicklungsumgebung für Java (Java Development Tools, JDT), für Eclipse-Plugins (Plugin Development Environment, PDE) sowie Unterstützung für das Versionsverwaltungssystem CVS (Concurrent Versions System). 32

45 4 Technologien und Werkzeuge der MDSD 4.1 Eclipse Weitere Plugins werden vom Eclipse-Projekt sowie von Drittanbietern zum Download bereitgestellt. Speziell für die verschiedenen Aspekte des Entwicklungsprozesses existieren Plugins für Programmiersprachen, Modellierung, Versionierung, Tests, Deployment sowie Datenbankverwaltung. Die Erstellung von Java-Enterprise-Anwendungen wird durch Projekte wie das Web Tools Project (WTP) und durch Plugins für Frameworks (z. B. Spring IDE [Sprb]) und Anwendungsserver (z. B. JBoss Tools [JBo]) umfassend unterstützt Plugin-Mechanismus Die Idee, der Plattform durch die Erweiterung mittels Plugins zusätzliche Funktionalität zu verleihen, ist das herausragende Merkmal der Eclipse-Software. Der technologische Kern dieses Konzepts sind die Extension Points (Erweiterungspunkte): Ein Plugin bietet die Möglichkeit, von anderen Plugins erweitert zu werden, indem es eine Erweiterungsschnittstelle, also einen Extension Point, zur Verfügung stellt. Die anderen Plugins wiederum definieren eine Extension (Erweiterung) zu diesem Extension Point und füllen diese mit eigener Implementierung. Über ein Pluginverzeichnis werden zur Laufzeit alle aktiven Extensions eines Extension Points ermittelt und deren Implementierung ausgeführt. Abbildung 4.1 zeigt exemplarisch die Definition und Erweiterung eines Extension Points. Eine ausführliche Beschreibung des Mechanismus findet sich in [SDF + 03]. (a) Extension Point org.eclipse.ui. ide.projectnatureimages (b) Erweiterung des Extension Points org.eclipse.ui. ide.projectnatureimages Abbildung 4.1: Definition und Erweiterung eines Extension Points 33

46 4 Technologien und Werkzeuge der MDSD 4.2 Eclipse Modeling Framework 4.2 Eclipse Modeling Framework Das Eclipse Modeling Framework (EMF) [EMF] ist ein Modellierungsframework zur Erstellung von strukturierten Datenmodellen. Es bietet Werkzeuge und Laufzeitunterstützung, um aus einem Modell Java-Quellcode zu erzeugen, mit dem das Modell durch Editoren und Generatoren bearbeitet werden kann. Das EMF gibt es seit 2002 und ist derzeit in der Version 2.3 verfügbar Das Ecore-Metamodell EMF spezifiziert ein eigenes Metamodell Ecore, das eine vereinfachte Untermenge der MOF darstellt. MOF ist das von der OMG erarbeitete Metamodell, das in der MDA als Grundlage für Metamodelle der Stufe M2 wie UML oder CWM dient (siehe Abschnitt 3.3.4). Ecore soll die Komplexität der MOF vermeiden und stattdessen den Fokus auf Werkzeugintegration setzen. Wie auch bei MOF gibt es oberhalb des Ecore-Metamodells kein weiteres Metamodell. Ecore ist ebenfalls ein EMF-Modell und beschreibt sich somit selbst; ein Metamodell auf Ebene M4 ist nicht nötig [B + 03, S. 15]. Abbildung 4.2 zeigt die Ecore- Modellklassenhierarchie und verdeutlicht die Ähnlichkeit des Ecore-Metamodells zum objektorientierten Klassenmodell der MOF/UML. EMF-Modelle können auf vielfältige Weise erzeugt werden: Zum einen bringt das EMF- Framework einen Modelleditor mit, der das Modell in einer Baumstruktur anzeigt und die Bearbeitung des Modells ermöglicht. Eine andere Möglichkeit ist das Importieren eines Modells aus annotierten Java-Schnittstellen, XML Schemata (XSD) oder UML- Werkzeugen. Man kann dies als eine Abstraktion über die konkrete Syntax des Modells betrachten; die abstrakte Syntax definiert Ecore. EMF serialisiert Ecore-basierte Modelle in XMI-Dateien und ermöglicht damit ebenso wie MOF das Weiterreichen von Modellen entlang einer Werkzeugkette, wobei EMF die Integration in die Eclipse-Plattform in den Vordergrund stellt. 34

47 4 Technologien und Werkzeuge der MDSD 4.2 Eclipse Modeling Framework Abbildung 4.2: Ecore-Klassenhierarchie Codegenerierung Das Eclipse Modeling Framework generiert aus EMF-Modellen Java-Quellcode, der von Editoren sowie Transformatoren und Codegeneratoren genutzt werden kann. Zuvor erweitert EMF das Ecore-basierte Modell (.ecore) in ein Generierungsmodell (.genmodel), das zusätzliche zur Codegenerierung nötige Informationen enthält. Die Generierung erfolgt immer von diesem Generierungsmodell aus und umfasst die folgenden Teilschritte 1 : Model Erzeugt Schnittstellen- und Implementierungsklassen für alle Klassen im Modell. Edit Erstellt Implementierungsklassen, die die Modellklassen für die Bearbeitung und Visualisierung anpassen. Editor Erstellt einen (baum-)strukturierten Editor für Instanzen des Modells. Test Generiert Unittests für die Modellklassen. 1 Dabei müssen nicht alle Teilschritte durchgeführt werden. Je nach Anwendungsfall reicht z. B. auch die Erstellung der Modellklassen aus. 35

48 4 Technologien und Werkzeuge der MDSD 4.2 Eclipse Modeling Framework Erstellung grafischer Editoren Die Erstellung und Bearbeitung von EMF-Modellinstanzen kann mit dem generierten Baumeditor erfolgen. Diese Art der Visualisierung ist aber nicht immer von Vorteil, vor allem da die Beziehungen zwischen Elemente nicht ausreichend darstellbar sind. Daher gibt es die Möglichkeit, mit Hilfe der Frameworks GEF und GMF einen grafischen Modelleditor zu erstellen, der den speziellen Anforderungen an die Darstellung des Modells gerecht wird. Graphical Editing Framework Das Graphical Editing Framework (GEF) [GEF] ist ein Framework zur Erstellung grafischer Editoren und gehört ebenfalls zum Eclipse Modeling Project. Es stellt u. a. folgende Funktionen zur Verfügung: Figuren und Formen, die sich miteinander verbinden lassen Ein Überblicksfenster zur schnellen Navigation Eine Werkzeugleiste für die Erstellung und Markierung von Figuren Grafische und hierarchische Visualisierung Druckerausgabe Graphical Modeling Framework Das Graphical Modeling Framework (GMF) [GMF] stellt eine Brücke zwischen EMF und GEF dar. Mit Hilfe von Wizards und hierarchischen Editoren lassen sich so aus EMF- Modellen grafische Editoren erzeugen. Der Erstellungsprozess umfasst mehrere Schritte und wird im Eclipse-View GMF Dashboard dargestellt (Abbildung 4.3). In jedem Prozessschritt wird ein bestimmtes Modell erstellt, das über einen hierarchischen Editor angesehen und bearbeitet werden kann. Prozessschritte: 36

49 4 Technologien und Werkzeuge der MDSD 4.2 Eclipse Modeling Framework Abbildung 4.3: GMF Dashboard 1. Das EMF-Modell und das für die Generierung angepasste EMF-Generierungsmodell (siehe Abschnitt 4.2) müssen vorhanden sein. Sie bilden die Grundlage für die Erstellung des grafischen Editors. 2. Klassen aus dem EMF-Modell werden dann auf grafische Figuren abgebildet. Die Mapping-Informationen werden im Grafikdefinitionsmodell gespeichert. Damit ist festgelegt, welche Informationen des Modells der Editor anzeigen und bearbeiten kann. 3. Wie im vorigen Abschnitt erwähnt, bietet das GEF die Möglichkeit, eine Werkzeugleiste anzuzeigen, welche Schaltflächen beinhaltet, mit denen neue Formen und Verbindungen auf der Editoroberfläche hinzugefügt werden können. Das Mapping zwischen Klassen und Attributen des Modells und Schaltflächen dieser Werkzeugleiste wird im Werkzeugdefinitionsmodell gespeichert. 4. Im nächsten Schritt werden diese beiden Modelle zusammengefasst und um das EMF-Modell ergänzt. Dieses dreiteilige Modell heißt Mapping-Modell. 5. Das Mapping-Modell wird dann in ein Generatormodell transformiert, das für die Generierung des Editor-Quellcodes angepasst ist. 6. Zuletzt wird aus dem Generatormodell der Quellcode erzeugt. Der Editor ist fertig und kann z. B. als Eclipse-Plugin zur Verfügung gestellt werden. 37

50 4 Technologien und Werkzeuge der MDSD 4.3 openarchitectureware Die Bearbeitung des grafischen EMF-Modells mit dem erstellten Editor bewirkt immer eine Bearbeitung des eigentlichen EMF-Modells. Das heißt, das EMF-Modell und seine grafische Repräsentation werden vom Framework stets synchron gehalten Anwendungsgebiete Das Eclipse Modeling Framework wird vor allem im Umfeld von Eclipse und Java immer häufiger zur Definition von (Meta-)Modellen verwendet. Zahlreiche Metamodelle wurden in das Ecore-Format übertragen, so zum Beispiel das Java-Metamodell 2. Das UML2-Projekt der Model Development Tools (MDT) [UML] hat die wichtigsten UML- Metamodelle in EMF implementiert, sodass auch mit EMF-Mitteln UML-Modelle erstellt werden können. Das Generatorframework openarchitectureware, das im nächsten Abschnitt vorgestellt wird, kann EMF-basierte Modelle lesen und zur Modelltransformation verwenden. Mittlerweile sind auch einige Modellierungswerkzeuge, wie beispielsweise MagicDraw [NM], in der Lage, EMF-Modelle zu importieren und exportieren. Die Nutzung von EMF in der modellgetriebenen Softwareentwicklung als Alternative zu den OMG-Standards ist damit ein gangbarer Weg, zumal derzeit keine weiteren MOF-Implementierungen existieren. 4.3 openarchitectureware openarchitectureware (oaw) [OAW] ist ein Open-Source-Framework für modellgetriebene Softwareentwicklung. Es hat sich aus dem b+m Generator Framework der b+m Informatik AG entwickelt und ist mittlerweile ein Unterprojekt der Generative Modeling Technologies (GMT) [GMT]. oaw versteht sich als eine Werkzeugsuite, die auf einem in Java implementierten Generatorframework basiert [Vö07] und zum Ziel hat, eine Infrastruktur zur Entwicklung von Generatoren bereitzustellen 3. Da es sich um ein Framework handelt, sind die einzelnen Komponenten anpassbar: So können z. B. beliebige Modellformate, Metamodelle und Ausgabeformate durch oaw verarbeitet werden. Das Projekt legt die Betonung deutlich auf den Frameworkcharakter. Vorgefertigte DSLs oder Transformationsvorlagen für bestimmte Zielarchitekturen werder daher nicht angeboten. Die 2 Das Java EMF Model (JEM) ist Teil des Visual-Editor-Projektes [VE]. 3 a tool for building MDSD/MDA tools [Vö07, S. 1] 38

51 4 Technologien und Werkzeuge der MDSD 4.3 openarchitectureware Open-Source-Plattform Fornax Platform [For] entwickelt solche Komponenten (Cartridges) speziell für die Nutzung mit openarchitectureware Bestandteile Im Folgenden werden die Bestandteile von oaw vorgestellt und anschließend wird ein typischer Generatorlauf skizziert. Workflow-Engine Die Ausführung eines oaw-basierte Generators wird über die Workflow Engine gesteuert [EV]. Sie ermöglicht die sequenzielle Abarbeitung vordefinierter Komponenten wie Modellinstanziierung, -validierung und -transformation. Der Workflow wird in einer XML- Datei festgelegt und benutzt eine ähnliche Syntax wie das Erstellungswerkzeug Apache Ant [Ant]. Konzepte wie das Definieren von Eigenschaften (Properties) und das Referenzieren weitere Workflow-Dateien sind ebenfalls aus Ant bekannt. Die Ausführung eines oaw-workflows kann über das Workflow-API (Application Programming Interface), einen Ant-Task, die Eclipse-Oberfläche oder über einen Kommandozeilenaufruf angestoßen werden. Typsystem und Expression Language openarchitectureware bringt ein eigenes Typsystem mit eine Abstraktionsschicht über die verschiedenen Metamodelle, die als Eingabe für eine Generierung verwendet werden können. Bei der Instanziierung eines Metamodells wird dieses in das Typsystem umgesetzt. Im Umfang der oaw-distribution sind bereits Adaptionen für einige Metamodelle, darunter Java, EMF und UML-Profile, vorhanden. Das Typsystem beinhaltet einfache Datentypen wie int, boolean und String sowie Datenstrukturen (Listen, Mengen,... ). Es ist Teil des Expression Frameworks [Effb], einer OCL-ähnlichen Sprache, die Ausdrücke für den Zugriff auf Modellelemente definiert. Da die oaw-spezifischen Sprachen das Expressions Framework benutzen, ist die Verarbeitung von Modellelementen einheitlich und die Verwendung der konkreten Metamodelle vollkommen transparent. 39

52 4 Technologien und Werkzeuge der MDSD 4.3 openarchitectureware Templatesprache Xpand Mit der Templatesprache Xpand lassen sich Modelltransformationen beschreiben [EK]. Dabei sind Xpand-Templates besonders für M2C 4 -Transformationen geeignet. Der Zugriff auf die Modellelemente geschieht vollständig über die Expression Language, sodass Modelldaten aus unabhängig voneinander instanziierten Modellen für die Erstellung von Ausgabecode einheitlich zur Verfügung stehen. Zusätzlich können Xtend-Erweiterungen eingebunden werden (siehe nächster Abschnitt zu Xtend). Xpand stellt auch Mittel zur aspektorientierten Programmierung (AOP) bereit [EK, S. 12f.]. So sind bereits definierte Templates nicht-invasiv erweiterbar, was vor allem hilfreich ist, wenn allgemeine Transformationen durch zieltechnologiespezifische Implementierungen ergänzt werden sollen. Erweiterungssprache Xtend Die Erweiterungssprache Xtend hat mehrere Anwendungsfälle [Effc]: Zum einen können die in Form des oaw-eigenen Typsystems vorliegenden Modelle durch in Xtend definierte Metamodell-Extensions dynamisch um zieltechnologiespezifische Inhalte angereichert werden. Diese Informationen möchte man im Allgemeinen nicht im Metamodell unterbringen, da sie nicht Gegenstand des Domänenwissens sind. Extensions können durch Ausdrücke der Expression Language formuliert werden. Darüber hinaus besteht auch die Möglichkeit, die Erweiterungen durch Java-Methoden zu implementieren. Dies zeigt die Mächtigkeit des Extension-Mechanismus in openarchitectureware. Die Verwendung der MM-Extensions ist aus den oaw-sprachen Xpand und Check heraus sowie über eine Xtend-Komponente im Workflow möglich. Die MM-Extensions sind nicht als Modell-zu-Modell-Transformationen (M2M) anzusehen, sondern ein pragmatischer Ansatz, um Modelle im Generierungsprozess mit nützlichen Zusatzinformationen zu versehen (vgl. [VK06, Abschnitt 3.9]). Wirkliche M2M- Transformationen lassen sich aber ebenso mit Xtend durch Create Extensions realisieren [Effc, S. 7 9]. In diesem Fall wird ein neues Modell aus Inhalten anderer Modelle aufgebaut und in einem Slot abgelegt, aus dem nachfolgende Workflow-Komponenten lesen können. Die Transformationen werden dabei ausschließlich mit imperativen Sprachkon- 4 Modell-zu-Code, oft auch allgemeiner Modell-zu-Text (M2T), wenn jegliche Art von Textdateien gemeint ist. 40

53 4 Technologien und Werkzeuge der MDSD 4.3 openarchitectureware strukten ausgedrückt. Xtend bietet damit weniger Ausdrucksmöglichkeiten als QVTbasierte Sprachen wie die ATL (vgl. die Ausführungen zu QVT auf S. 24 und ATL auf S. 44). Validierungssprache Check Um die Regeln für die Prüfung der statischen Semantik von Modellinstanzen zu beschreiben, stellt oaw die Validierungssprache Check [Effa] bereit. Auch sie arbeitet mit dem oaw-typsystem und kann auf Xtend-MM-Erweiterungen zugreifen. Die Sprache ist eine Erweiterung der Expression Language und stellt damit ähnlich der OCL umfangreiche sprachliche Mittel zur Formulierung von Validierungsregeln zur Verfügung. Check ist nützlich, um noch vor Ausführung von Modelltransformationen und Codeerstellung die Semantik der Modelle zu validieren und gegebenenfalls den Workflow mit einer Fehlermeldung abzubrechen. Oftmals ist es besser, die Zusicherungen bereits zur Modellierungszeit zu überprüfen, da eventuelle Fehler schon frühzeitig bemerkt werden. Das oaw-framework enthält für diesen Zweck einen GMF-Adapter, mit dem in Check formulierte Prüfregeln direkt auf GMF-visualisierte Modelle angewendet werden können [OAW07, Kap. 10]. Dies geschieht entweder während der Bearbeitung der grafischen Modelle (Live Constraints) oder auf Verlangen (Batch Constraints). Textuelle DSLs mit Xtext Domänenwissen lässt sich mitunter mit textuellen domänenspezifischen Sprachen besser darstellen als mit grafischen Modellen, vor allem dann, wenn die Modellelemente viel Text enthalten. oaw ermöglicht die Erstellung einer textuellen DSL durch das Xtext- Framework [Effd]. Ausgehend von einer Grammatik für die zu erstellende Sprache generiert Xtext einen Modellparser, ein EMF-Metamodell sowie einen Eclipse-Modelleditor. Parser und Metamodell bilden die Voraussetzung, um innerhalb eines Workflows ein in der generierten DSL formuliertes Modell zu instanziieren und somit für die Verarbeitung mit Xpand etc. bereitzustellen. 41

54 4 Technologien und Werkzeuge der MDSD 4.3 openarchitectureware Beispiel eines Generatorlaufs Ein typischer oaw-workflow führt die folgenden Komponenten aus: Der Workflow wird konfiguriert. Eigenschaften werden gesetzt und Metamodelle bekannt gemacht. Ein Modell wird in den Speicher geladen und ist somit für weitere Workflowkomponenten nutzbar. Das Modell wird dann mit Hilfe von Check-Zusicherungen validiert. Ist das Modell ungültig, wird der Workflow abgebrochen. Dann wird das Modell transformiert, beispielsweise indem es mit zieltechnologiespezifischen Informationen angereichert wird. Der Generator erstellt Zielartefakte, indem er Xpand-Templates auf die Modellelemente anwendet. Zuletzt wird das im Speicher gehaltene und transformierte Modell in eine Datei geschrieben Integration in Eclipse Das openarchitectureware-framework ist gänzlich unabhängig von Eclipse verwendbar. Jedoch bietet die Laufzeitunterstützung von oaw in Eclipse erhebliche Vorteile. Für die oaw-eigenen Sprachen stellt das Framework Editoren sowie weitere von Eclipse bekannte Funktionen wie automatische Vervollständigung, Fehlermarkierung und Assistenten (Wizards) bereit, die die Arbeit für den Entwickler vereinfachen. In der hier beschriebenen Version laufen jedoch nicht alle Komponenten fehlerfrei und sind auch noch nicht vollständig zur derzeitigen Eclipse-Version 3.3 kompatibel. Ein weiterer Bestandteil von openarchitectureware, der eng mit Eclipse verknüpft ist, ist das Recipe-Framework [Vö]. Es bietet Unterstützung bei der Integration von generiertem und manuellem Code. Dem Entwickler steht bei der Benutzung des oaw-basierten Frameworks eine Hilfestellung zur Verfügung, das ihm die auferlegten Architekturzusiche- 42

55 4 Technologien und Werkzeuge der MDSD 4.3 openarchitectureware rungen in einem Eclipse-View veranschaulicht und auf etwaige Fehler hinweist. Derartige Zusicherungen können in Java implementiert und ihre Prüfung über eine Workflowkomponente angestoßen werden. Dabei handelt es sich im Unterschied zur Validierungssprache Check nicht um die Prüfung der statischen Semantik. Ein häufiger Anwendungsfall ist beispielsweise, dass generierte Java-Schnittstellen durch manuell zu erstellende Klassen implementiert werden müssen, die einer bestimmten Namenskonvention unterliegen Zusammenfassung openarchitectureware ist ein sehr ausgereiftes und umfassendes MDSD-Framework, das für einen Großteil der Anforderungen im Bereich der Modellgetriebenenen Softwareentwicklung (wie z. B. Modellvalidierung, -transformation, Generierung) Sprachen und Werkzeuge bereitstellt. Es stellt kein fertiges, sofort einsetzbares MDSD/MDA-Produkt dar, sondern bietet vielmehr die Grundlage für die Erstellung individueller problemspezifischer Generatoren. Demzufolge bringt oaw auch keine vorgefertigten DSLs und Cartridges, wie dies etwa bei dem im Abschnitt 4.5 beschriebenen Framework AndroMDA der Fall ist. Für den schnellen Einsatz out of the box im Projekt ist oaw somit nicht geeignet. Ausblick Das openarchitectureware-projekt wird fortwährend weiterentwickelt und berücksichtigt dabei die Anforderungen und Erfahrungen der MDSD-Entwicklergemeinschaft. Die im September 2007 erschienene Version 4.2, die volle Kompatibilität zu Eclipse 3.3 gewährleistet, bietet eine Reihe von Verbesserungen und Neuerungen. So wird etwa das Gebiet des Produktlinien-Engineering adressiert, indem Workflows durch Featuremodelle gesteuert werden können. Zusätzlich finden sich Workflowkomponenten, um Variabilität in Modellen umzusetzen. Features lassen sich damit in Modelle einweben bzw. aus ihnen herauslösen. Für nachfolgende Versionen sind überdies eine verbesserte Unterstützung für Tracing also das Festhalten der Informationen, aus welchen Modellelementen welche Artefakte generiert wurden sowie die Vereinigung der verschiedenen oaw-sprachen geplant. 43

56 4 Technologien und Werkzeuge der MDSD 4.4 Atlas Transformation Language 4.4 Atlas Transformation Language Die Atlas Transformation Language (ATL) [ATL] ist eine Transformationssprache, die den in Abschnitt behandelten QVT-Standard in Teilen implementiert 5. Sie wird von der ATLAS-Forschungsgruppe 6 entwickelt und ist inzwischen ein Unterprojekt des Eclipse Modeling Projects. ATL weist sowohl deklarative als auch imperative Sprachkonstrukte auf, wobei auch hier die deklarative Schreibweise bevorzugt wird [ATL06, S. 1]. Mit ATL lassen sich bislang nur unidirektionale Transformationen umsetzen, d. h., das Quellmodell wird während des Transformationsprozesses nicht verändert. Die Atlas Transformation Language gliedert sich in drei Teile: ATL modules beschreibt Modelltransformationen. ATL queries unterstützt die Anwendung von Anfragen (Queries) auf Modelle. ATL libraries bietet die Möglichkeit, ATL-Code in Bibliotheken (Libraries) zu kapseln und diese anderen ATL-Programmeinheiten zugänglich zu machen. Die Sprache basiert auf den Ausdrücken der Object Constraint Language, erweitert um einige ATL-spezifische Konstrukte. Ähnlich der oaw-sprache Xtend bietet auch ATL die hilfreiche Funktionalität, Implementierung in Java-Methoden auszulagern (vgl. Abschnitt auf S. 40). Die Transformationen werden in Form von Regeln definiert, welche Elemente des Quellmetamodells mit Elementen des Zielmetamodells in Verbindung setzen. Als Metametamodelle werden hierbei die Meta Object Facility und EMF Ecore unterstützt. Um die Entwicklung und Ausführung von ATL-Transformationen zu vereinfachen, gibt es die ATL Development Tools (ADT) [ATL]. Diese beinhalten u. a. einen speziellen Editor mit Syntaxhervorhebung, Fehlermarkierung und Assistenten. Leider sind diese Hilfen in der derzeitigen Version noch nicht ausgereift und auch nicht sehr intuitiv bedienbar. 5 Genauer gesagt implementiert ATL nicht den aktuellen QVT-Standard, sondern den Request for Proposal (RFP) aus dem Jahre 2002 [QVT02]

57 4 Technologien und Werkzeuge der MDSD 4.5 AndroMDA 4.5 AndroMDA AndroMDA 7 [And] ist ein Framework für modellgetriebene Softwareentwicklung gemäß dem MDA-Paradigma. Es ist in Java implementiert, frei verfügbar und quelloffen. Die neueste stabile Version von AndroMDA ist 3.2, allerdings stehen im Ausblick auf die Nachfolgeversion 4.0 umfangreiche Neuerungen bevor. Die nachfolgenden Erläuterungen beziehen sich, wenn nicht anders angegeben, auf Version 3.2. AndroMDA ermöglicht die Erstellung von Quellcode aus Plattformunabhängigen Modellen (PIM), wobei als Modellierungssprache nur die UML unterstützt wird. Darüber hinaus sind Modell-zu-Modell-Transformationen bislang nicht möglich, d. h. aus einem PIM wird direkt die Implementierung (PSI) erzeugt. Die Ablaufsteuerung lässt sich über Konfigurationsdateien beeinflussen. Der Generatorprozess wird vorwiegend über Maven-Plugins [Mav] gesteuert Architektur AndroMDA besteht aus einer Reihe von Plugins, die über eine Kernkomponente (Andro- MDA Core) gesteuert werden. Es werden Standardimplementierungen dieser Plugins mitgeliefert, die jedoch ausgetauscht werden können [PM06, S. 180]. Die AndroMDA- Architektur umfasst die folgenden Komponenten: AndroMDA Core Der Kern von AndroMDA ist eine Engine, die die Steuerung der Plugins übernimmt. Konfiguriert wird dies über eine XML-Konfigurationsdatei [And06, Abschnitt Configuration]. Die Engine ist per Kommandozeile, aus einer IDE heraus oder über Buildwerkzeuge wie Ant aufrufbar. Es werden jedoch bereits Maven-Plugins mitgeliefert, die die Arbeit mit den AndroMDA-Services vereinfachen. Die Verwendung von Maven wird daher vom AndroMDA-Team empfohlen. 7 gesprochen: Andromeda 45

58 4 Technologien und Werkzeuge der MDSD 4.5 AndroMDA Meta Data Repositories Die Meta Data Repositories (MDR) sind dafür verantwortlich, Anwendungsmodelle zu instanziieren, um sie für den Generator zur Laufzeit verfügbar zu machen. AndroMDA verwendet standardmäßig das Meta Data Repository von Netbeans [SM], jedoch kann dieses nur XMI-Dokumente bis zur Version 1.2 lesen. Aus diesem Grund können in AndroMDA keine UML2-Modelle als Quelle genutzt werden, da deren Seralisierungsformat XMI 1.4 ist. Ein EMF- sowie ein EMF-UML2-Repository sind in Planung. Cartridges und Metafassaden Cartridges umfassen die eigentliche Generatorfunktionalität. Eine Cartridge enthält die Elemente, die für die automatische Codeerzeugung aus Modellen nötig sind: Zunächst ist in ihr das UML-Profil festgelegt, das die UML an die Domäne der Cartridge anpasst (vgl. leichtgewichtige Erweiterung auf S. 26). Weiterhin enthält sie die Transformationstemplates, die aus dem Quellmodell die Zielartefakte erzeugen. Als Transformationssprachen kommen hauptsächlich Apache Velocity [Vel] und Freemarker [Fre] zum Einsatz. Der Zugriff auf die Modellelemente wird durch definierte Schnittstellen, die sogenannten Metafassaden, vereinfacht. Das sind Java-Klassen, die mit dem UML-Profil umgehen können und für die Templates nützliche Zugriffsfunktionen bereitstellen. Das MDR allein kann diese Rolle nicht übernehmen, da es das UML-Profil nicht kennt (vgl. [PM06, S. 181f.]). Die Metafassaden sind also analog zu den Extensions in openarchitectureware (siehe Abschnitt auf S. 40) ein Mittel zur dynamischen Erweiterung von Metamodellelementen um Informationen, die nicht zum Domänenwissen gehören. Hervorzuheben ist, dass AndroMDA eine Vielzahl fertiger Cartridges zur Verfügung stellt. Diese überspannen insbesondere den Bereich der Entwicklung von Java-Enterprise- Anwendungen. So gibt es etwa eine Hibernate-Cartridge für die Modellierung der Persistenzschicht und eine Spring-Cartridge zur Generierung von Komponenten für das Spring- Framework [Spra]. Eine Übersicht über die erhältlichen Cartridges findet sich auf der AndroMDA-Webseite [And] oder in [PM06, S. 184]. Die Cartridges haben den Vorteil, dass sie sofort verwendet werden können und lauffähigen Code erzeugen 8. Allerdings ist man auf das von der Cartridge vorgegebene UML-Profil und die mitgelieferten Templa- 8 the always 100 % approach [Boh06a] 46

59 4 Technologien und Werkzeuge der MDSD 4.5 AndroMDA tes festgelegt. Einfach Modifizierungen sind nicht ohne Weiteres möglich und können nur erreicht werden, indem eine eigene Cartridge implementiert wird [Sch06, S. 55]. Translation Libraries Die Translation Libraries haben die Aufgabe, OCL-Ausdrücke, die als Tagged Values in Modellelementen vorkommen, in plattformspezifische Ausdrücke umzuwandeln. Dies können zum Beispiel Datenbankabfragen für Entitäten sein, die dann in SQL-Code übersetzt werden Ausblick auf Version 4.0 Das AndroMDA-Framework steuert gegenwärtig auf eine Versionsänderung zu, die zahlreiche Neuerungen mit sich bringen wird. Der Mangel an Möglichkeiten, Modelle in andere Modelle zu transformieren und damit einen der wichtigsten MDA-Aspekte umzusetzen (vgl. Abschnitt 3.3.2) wird in Version 4.0 dadurch behoben, dass die Atlas Transformation Language als Implementation des QVT-Standards unterstützt wird. Ferner soll es auch möglich sein, andere Transformationssprachen einzubinden [Boh06a]. Ein weiteres Ziel ist es, die Ausführung des Frameworks flexibler zu gestalten und dem Entwickler mehr Möglichkeiten zur Anpassung zu geben. Zu diesem Zweck können in AndroMDA 4.0 Workflows im Form von Code der Skriptsprache Groovy [Gro] spezifiziert werden. Die wichtigste Neuerung wird sein, den Zwang zur Nutzung von UML aufzuheben und die Verwendung individueller DSLs zu ermöglichen. In Version 4.0 wird dafür das EMF- Metamodell vollständig unterstützt werden. An einer bisher noch nicht vorhandenden Integration in IDEs wird derzeit gearbeitet. Ein Eclipse-Plugin soll dann Domänenarchitekten und Anwendungsentwickler gleichermaßen bei der Arbeit mit AndroMDA unterstützen. 47

60 4 Technologien und Werkzeuge der MDSD 4.6 OptimalJ 4.6 OptimalJ OptimalJ ist ein kommerzielles MDA-Produkt der Firma Compuware [Com], das sich auf die Entwicklung J2EE-basierter Anwendungen konzentriert. Anders als Frameworks wie openarchitectureware oder AndroMDA stellt OptimalJ eine umfängliche Werkzeugsuite dar. Es beinhaltet daher Domänenmodelle, Plattformbeschreibungen, Modelltransformationen und auch eine auf Eclipse aufbauende Benutzeroberfläche. OptimalJ setzt den MDA-Gedanken um, indem es Domainmodell (PIM), Applikationsmodell (PSM) und Codemodell (PSM/PSI) trennt und M2M-Transformationen bereitstellt. Diese werden in Form einer proprietären Template-Plattern-Sprache beschrieben. Aus dem Codemodell werden dann ebenfalls durch einen patternbasierten Generator die Codeartefakte wie Javaklassen und SQL-Code erstellt. Abbildung 4.4 verdeutlich dies. Abbildung 4.4: MDA in OptimalJ ([Opt]) Das Domainmodell setzt sich aus Modellen für Anwendungsfälle, Entitäten, Services und Prozesse (Abfolge von Services) zusammen. Aus diesen rein fachlichen Informationen wird das Applikationsmodell erstellt. Es umfasst Konzepte wie Datenbankschemata, Datenzugriffskomponenten (DAO) sowie Patterns und Frameworks für die Präsentationsschicht 9. Das Codemodell vereint die aus dem Applikationsmodell generierte Implementierung mit statischen Frameworkbibliotheken und manuellen Codeergänzungen. Interessant ist, dass die Zuordnung der Applikationsmodellelemente zu den generierten 9 OptimalJ nutzt zur Umsetzung des Patterns Model View Controller (MVC) das Webframework Struts [Str]. 48

61 4 Technologien und Werkzeuge der MDSD 4.7 MS Software Factories und DSL-Tools Codeartefakten in einem sogenannten Model-Code Repository (MCR) festgehalten wird. Dadurch kann der Generator einfache Modelländerungen sofort im Code aktualisieren und muss nicht die gesamte Erstellung erneut ausführen [Opt]. Obwohl OptimalJ auf die J2EE-Architektur zugeschnitten ist und u. a. auch Suns Core J2EE Patterns umsetzt, ist es nach Herzig [Her04, S. 4] auch möglich, OptimalJ durch Erweiterung von Patterns und Modellen anzupassen, um so eine spezifische Software Factory aufzubauen. Das Programm verfügt über eine Benutzeroberfläche mit umfassenden Bedienmöglichkeiten. Die Modelle lassen sich grafisch präsentieren und bearbeiten; die Generierung lässt sich über Schaltflächen steuern. Da OptimalJ auf der Eclipse Rich Client Platform (RCP) basiert, erfordert das Arbeiten mit der IDE keine größere Einarbeitung. In die Suite integriert sind auch ein Web- und ein Anwendungsserver sowie ein Database Management System (DBMS). Das heißt, die erstellte Anwendung kann direkt aus der IDE ausgeführt und getestet werden. 4.7 Microsoft Software Factories und Domain-Specific Language Tools Das Unternehmen Microsoft, das bereits generative Ansätze in der Entwicklungsumgebung Visual Studio integrierte, so z. B. zur Erstellung von Code für Benutzeroberflächen, hat den Wert der modellgetriebenen Softwareentwicklung erkannt und investiert verstärkt in die Umsetzung dieser Technologie. Besonders interessant sind hierbei die Software Factories und die Domain-Specific Language-Tools. Beide sollen in diesem Abschnitt kurz vorgestellt werden Software Factories Die Software Factories von Microsoft [Mic07b] basieren auf den Ideen von Greenfield et al. [GS + 06] und werden auch durch diese Personen maßgeblich vorangebracht. Aus organisatorischer Sicht sind die Microsoft Software Factories Teil der Microsoft 49

62 4 Technologien und Werkzeuge der MDSD 4.7 MS Software Factories und DSL-Tools Patterns & Practices, welche gebräuchliche Entwurfsmuster und Erfolgsmethoden (best practices) für Microsoft-basierte Applikationen zusammenfassen. Die Software Factories machen Gebrauch von diesen Mustern, Templates und Codebausteinen und integrieren diese zu einem anpassbaren Produkt. In Tabelle 4.1 sind die Bestandteile der Microsoft Software Factories dargestellt. Bestandteil Application Blocks & Libraries Recipes Templates Patterns QuickStarts How-to topics Referenzimplementierung Beschreibung Wiederverwendbare Codebausteine und Bibliotheken, meist für querschnittliche Belange wie Ausnahmebehandlung, Logging, Caching Unterstützung für die Anpassung der Visual-Studio-IDE durch Menüs und Assistenten Vorlagen mit Platzhaltern zur Generierung von Artefakten wie Projekt- und Solutionstrukturen Typische Entwurfsmuster, die für die Implementierung von Produkten der Software Factory häufig benutzt werden Kurzeinführungen in Schlüsselfunktionen der Software Factory Schritt-für-Schritt-Anleitungen Beispiel einer realistischen Anwendung, die mit der Software Factory erstellt werden kann Tabelle 4.1: Bestandteile der Microsoft Software Factories Derzeit bietet Microsoft vier Software Factories an, die allesamt frei erhältlich und auf den Einsatz mit Visual Studio und der.net-plattform ausgerichtet sind. Im Einzelnen sind dies: Smart Client Software Factory Web Client Software Factory Web Service Software Factory Mobile Client Software Factory Hervorzuheben ist, dass diese Software Factories zum jetzigen Zeitpunkt noch nicht die DSL-Tools verwenden und damit eine grafische Modellierung von Domänenwissen (beispielsweise eines Services in der Web Service Software Factory) noch nicht möglich ist. Microsoft sieht jedoch die Integration der DSL-Tools in nachfolgenden Version vor. 50

63 4 Technologien und Werkzeuge der MDSD 4.7 MS Software Factories und DSL-Tools Domain-Specific Language Tools Die Domain-Specific Language Tools [Mic07a] sind Teil des Microsoft Visual Studio 2005 Source Development Kits (SDK) und ermöglichen die Spezifikation einer domänenspezifischen Sprache. Die konkrete Syntax der DSL ist dabei immer ein grafisches Modell, textuelle DSLs werden noch nicht unterstützt [CJKW07, S. 20]. Damit sind die DSL- Tools vergleichbar mit einer Suite aus den Eclipse-Frameworks EMF, GEF und GMF (vgl. Abschnitt 4.2) Modellelemente und deren Beziehungen zueinander sowie die grafische Abbildung des Modells werden in einem einheitlichen Werkzeug spezifiziert. Dies geschieht wiederum über ein grafisches Werkzeug. Aus dem Modell wird ein grafischer Editor für die DSL generiert. Der Generierungsvorgang wird über Templates und Patterns gesteuert, die in den DSL-Tools enthalten sind. Der Editor kann in einer weiteren Instanz von Visual Studio gestartet und zur Modellierung einer Modellinstanz verwendet werden. Abbildung 4.5a zeigt die Definition einer DSL in den DSL-Tools. Auf der linken Seite befindet sich das Metamodell, während auf der rechten Seite die Elemente für die grafische Syntax definiert werden. In Abbildung 4.5b ist ein mit dieser DSL formuliertes Modell zu sehen. Das Metamodell, die grafische Repräsentation sowie Modellinstanzen werden in separate XML-Dateien serialisiert, wobei zu beachten ist, dass es sich hierbei nicht um das XMI-Format, sondern um ein proprietäres, anpassbares Format handelt. Die XMI- Unterstützung ist jedoch für kommende Versionen vorgesehen, sodass Modelle, die mit den DSL-Tools erstellt wurden, auch mit anderen Werkzeugen verarbeitet werden können. Zusammenfassend ist zu sagen, dass die Microsoft DSL-Tools ein geeignetes Werkzeug sind, um effektiv domänenspezifische Sprachen zu modellieren. Besonders in Verbindung mit Microsoft Software Factories werden sie zukünftig eine bedeutende Rolle spielen. Für die Nutzung in einer Werkzeugkette über Microsoft Visual Studio hinaus sind die DSL-Tools wegen ihrer fehlenden Kompatibilität zu Industriestandards jedoch noch nicht brauchbar. 51

64 4 Technologien und Werkzeuge der MDSD 4.7 MS Software Factories und DSL-Tools (a) Definition einer DSL im DSL-Tools-Editor (b) Modellinstanz im generierten Editor Abbildung 4.5: Definition und Anwendung einer DSL 52

65 5 Die Software Factory Nachdem die Grundlagen, Werkzeuge und Technologien modellgetriebener Softwareentwicklung beschrieben wurden, beschäftigt sich dieses Kapitel mit der Software Factory für Java-Enterprise-Anwendungen. Zuerst werden die Anforderungen an die Software Factory zusammengefasst. Daran schließt sich eine Erläuterung des erarbeiteten Konzeptes. Die darauffolgenden Abschnitte gehen näher auf die Kernbestandteile der Software Factory ein, dabei werden auch die im Rahmen der Diplomarbeit erstellten exemplarischen Cartridges beschrieben. Innerhalb dieser Abschnitte wird jeweils auch eine Aufwandsabschätzung vorgenommen, die besonders für die spätere Weiterentwicklung der Softwarekomponenten nützlich ist. Das Kapitel schließt mit Hinweisen zur Installation und Bedienung der Software Factory. 5.1 Anforderungen Im Folgenden sind die Anforderungen an die Software Factory noch einmal zusammengetragen: Ziel des Softwaresystems ist es, die Entwicklung von Java-Enterprise-Anwendungen hinsichtlich Entwicklungsgeschwindigkeit, Fehleranfälligkeit, Wartbarkeit und Erweiterbarkeit der Anwendungen zu optimieren. Dazu soll dem Entwickler die Möglichkeit geboten werden, die fachlichen Belange in einer Sprache zu beschreiben, die sich an die Architektur von Java-EE-Anwendungen anlehnt. Zieltechnologien wie Plattformen oder Frameworks sollen für ein konkretes Projekt individuell auswählbar sein und zieltechnologiespezifische Artefakte aus dem fachlichen Modell generiert werden. Die Erweiterung der Software Factory um neue Generierungs-Cartridges soll mit geringem Aufwand möglich sein, so dass sie auch mit zukünftigen Technologien verwendet werden kann. Um die Nutzung der Software Factory zu demonstrieren, sind exemplarische Cartridges zu 53

66 5 Die Software Factory 5.2 Überblick erstellen. Da viele Aspekte der Entwicklung von Java-EE-Anwendungen bereits durch Eclipse-Plugins abgedeckt werden, ist eine Integration der Software Factory in diese Entwicklungsumgebung erstrebenswert. Spezielle Editoren, Assistenten und Werkzeuge unterstützen dabei den Entwickler bei der Arbeit. 5.2 Überblick Konzept Die gestellten Anforderungen werden durch eine Software Factory umgesetzt, die auf den in Abschnitt dargelegten theoretischen Konzepten basiert. Das gemeinsame Merkmal der Produkte, die mit der Software Factory erstellt werden, liegt darin, dass sie (Java-)Enterprise-Anwendungen sind (vgl. Kapitel 2). Das heißt, es handelt sich um verteilte Anwendungen, in denen Daten verarbeitet und gespeichert werden, und die in der Regel eine Benutzerschnittstelle anbieten. Daraus ergibt sich die Domäne der Software Factory: die Architektur von Java-Enterprise-Anwendungen. Die Eigenschaften der Domäne sind in einer domänenspezifischen Sprache formuliert, welche vom Anwendungsentwickler genutzt wird, um das Domänenwissen einer Anwendung zu formulieren. Sie ist in Abschnitt 5.3 beschrieben. Den Gemeinsamkeiten, die in dieser architekturzentrierten DSL formuliert sind, stehen die Unterschiede zwischen den Softwareprodukten gegenüber. Sie liegen in der Fachlichkeit sowie in der Wahl der Technologie, mit der sie implementiert werden. Dabei dient die Java-Enterprise-Plattform als Basis. Die weiteren für eine Software verwendeten Technologien sind jedoch meist durch projektspezifische Rahmenbedingungen bestimmt und somit nicht für alle Produkte der Software Factory gleich. Wie in Abschnitt erläutert, sind diese variablen Eigenschaften in Bausteinen, im Weiteren Cartridges genannt, zusammengefasst. Die Software Factory stellt eine Entwicklungsumgebung zur Verfügung, indem sie die IDE Eclipse durch Plugins erweitert. Dadurch muss kein weiteres Werkzeug in den Softwareentwicklungsprozess eingebunden werden. Die Cartridges werden ebenfalls als Eclipse- Plugins in die Software Factory integriert. 54

67 5 Die Software Factory 5.2 Überblick Abbildung 5.1 skizziert das grundlegende Konzept der Software Factory für Java-Enterprise-Anwendungen: Ein Kern-Plugin (Core) stellt die Basis des Systems dar und über- Abbildung 5.1: Konzept der Software Factory nimmt die Rolle der Steuerungskomponente. Es spezifiziert Erweiterungspunkte in Form von Eclipse-Extension-Points (vgl. Abschnitt 4.1.1), an die sich die Cartridges andocken um in der Software Factory registriert zu werden. Die GUI 1 -Komponente realisiert die Integration in die Benutzeroberfläche der Eclipse-Umgebung. Eine weitere Komponente beinhaltet die DSL Domain, das heißt, das Metamodell und die konkrete(n) Syntax(en) zur Modellierung des Domänenwissens. Die Cartridges sind die Bestandteile der Software Factory, die das Wissen über die Erstellung der Zielartefakte aus den formalen Modellen umfassen. Sie registrieren sich am SF-Kern und werden von diesem aktiviert. Die Ablaufsteuerung einer Cartridge wird über einen Workflow konfiguriert. Dieser legt ei- 1 Graphical User Interface 55

68 5 Die Software Factory 5.2 Überblick ne Ablaufreihenfolge von Workflowkomponenten fest. Bei der Anwendung der Cartridge auf ein Domain-Modell wird der Workflow und damit die spezifizierten Komponenten ausgeführt. Der darin enthaltene Code verarbeitet die Informationen des Domain-Modells anhand der zugrunde liegenden Elemente des Domain-Metamodells. Hauptsächlich handelt es sich dabei um die Prüfung der Zusicherungen und um Modelltransformationen. Die Überprüfung des Domain-Modells stellt sicher, dass die Transformationen nur ausgeführt werden, wenn das Modell gültig ist. Bezüglich der Transformationen werden M2Mund M2T-Transformationen unterschieden. Die M2M-Transformationen modifizieren das Modell, indem sie Elemente dynamisch hinzufügen, löschen oder verändern. Es werden dadurch keine Zielartefakte erzeugt. Dies ist Aufgabe der M2T-Transformationen, die mittels Templates aus den Domain-Elementen zieltechnologiespezifischen Code und weitere Artefakte generieren. Eine Sonderstellung kommt den Metamodell-Extensions zu. Sie definieren zusätzliche Eigenschaften und Hilfsmethoden für Metamodellelemente und bilden eine Programmierschnittstelle für die anderen Codebestandteile, sodass mehrfach gebrauchter Code zentral gehalten wird und allgemein verfügbar ist. Dies ist auch insofern wichtig, als Cartridges meist auf die Funktionalität anderer Cartridges angewiesen sind (in Abbildung 5.1 als use gekennzeichnet). Die MM-Extensions fungieren hierbei als Schnittstelle zwischen den Cartridges. Eine weitere Beziehung zwischen Cartridges ist die zeitliche Abhängigkeit (in Abbildung 5.1 requires). Damit wird ausgedrückt, dass eine Cartridge vor der anderen ausgeführt werden muss, was vor allem wichtig ist, wenn sie Modelltransformationen vornimmt oder Artefakte erstellt, die der nachfolgenden Cartridge als Eingabe dienen. Oftmals kommt es vor, dass eine Cartridge zusätzliche Informationen in ein Artefakt generieren möchte, das eine vorherige Cartridge bereits erstellt hat. Für dieses Problem reicht die Festlegung einer zeitlichen Abhängigkeit nicht aus. Stattdessen wird der Code der ersten Cartridge mit hinzugewebten Aspekten der zweiten Cartridge ausgeführt. Dies ist in der Abbildung durch die advise-beziehung illustriert. Die Aspekte befinden sich dabei auf der Ebene der Generierungstemplates. Das bedeutet, dass in diesem Fall die Templates eine Schnittstelle zwischen Cartridges darstellen. In Abschnitt wird das Schnittstellenkonzept umfassend betrachtet. Die farblichen Abhebungen in Abbildung 5.1 sollen den eigentlichen Kern der Software Factory (Core und GUI, grün hinterlegt) gegenüber den variablen Teilen (die Cartridges, rot) abgrenzen. Die gelb gezeichneten DSLs sind prinzipiell auch Kernbestandteil der Software Factory, es spricht jedoch nichts dagegen, dass Cartridges eigene DSLs zur 56

69 5 Die Software Factory 5.2 Überblick Modellierung ihres technologiespezifischen Wissens mitbringen. Ausführung der Cartridges Die Ausführung der Cartridges, die beispielhaft in Abbildung 5.2 dargestellt ist, wird wie eingangs erwähnt vom Kern-Plugin gesteuert. Der Kern ruft die registrierten und aktivierten Cartridges nacheinander auf und bringt ihre Workflows zur Ausführung. Die aufgerufene Cartridge liest das zu verarbeitende Domain-Modell ein und generiert daraus die Artefakte der Zieltechnologie. Darüber hinaus kann sie auch Modellvalidierungen (Schritt 1.2 in Abbildung 5.2) oder M2M-Transformationen ausführen (siehe nächster Abschnitt). Nachdem der Cartridge-Workflow abgearbeitet ist, kommt die nächste Cartridge zur Ausführung. Abbildung 5.2: Ausführung der Cartridges Modell-zu-Modell-Transformationen Wie beschrieben sieht das Konzept der Software Factory für Java-Enterprise-Anwendungen auch die Verwendung von M2M-Transformationen vor. Anders als bei M2T- Transformationen, bei denen aus den Modellen mittels Generierungstemplates Textartefakte erstellt werden, ist der Sinn von M2M die Transformation der Modelle, wobei 57

70 5 Die Software Factory 5.2 Überblick es sich dabei hauptsächlich um das Hinzufügen von Informationen in die Modelle handelt. So ist es sinnvoll, für die vom Anwendungsentwickler nicht modellierten Daten automatisch Standardwerte in das Modell hinein zu generieren. Damit wird erreicht, dass Informationen, die auf der zieltechnologieunabhängigen Modellierungsebene nicht relevant sind, jedoch auf Technologieebene gebraucht werden, mit in den Generierungsprozess einbezogen werden 2. Beispielsweise könnte eine unbenannte Referenz zwischen zwei Modellelementen durch eine M2M-Transformation einen Namen erhalten, der sich aus dem Namen des referenzierten Elements ableitet. Dies ist notwendig, wenn die Referenz z. B. als Feld einer Java-Klasse umgesetzt werden soll, da in Java jedes Feld einen Bezeichner haben muss. Die M2M-Transformationen werden auf das Modell angewandt, das sich gerade im Build befindet und an die Cartridges übergeben wird. Die Gültigkeitsdauer einer solchen Modelländerung ist entweder auf die Ausführung einer Cartridge oder des gesamten Buildprozesses beschränkt. Dies hängt davon ab, ob die Cartridge die Änderungen in die Modelldatei speichert oder nicht. Sind die Transformationen nur innerhalb der Cartridge als Voraussetzung für eine Artefaktgenerierung nötig, so wird das veränderte Modell nicht gespeichert. Handelt es sich hingegen um Transformationen, die über die Cartridge hinaus wirksam sein sollen, dann muss die Cartridge diese Änderungen festhalten, indem sie das modifizierte Modell in die Datei zurückschreibt. Alle nachfolgenden Cartridges im Buildprozess arbeiten dann auf diesem veränderten Modell. Dies ist in Abbildung 5.3 dargestellt. Cartridge C1 modifiziert das Domain-Modell und speichert die Änderungen (Schritt 1.3). Danach generiert sie basierend auf dem veränderten Modell zwei Artefakte. Die anschließend ausgeführte Cartridge C2 liest dieses Modell ein (Schritt 2.1) und nutzt es als Eingabe für die Generierung des Artefaktes A Technologiewahl Anknüpfend an die Betrachtung des Konzeptes der Software Factory für Java-Enterprise- Anwendungen soll gezeigt werden, welche Technologien bei der praktischen Umsetzung zum Einsatz kommen und warum diese dafür geeignet sind. 2 Der Ansatz, dass Informationen Standardwerte haben und nur angegeben werden müssen, wenn sie von diesen abweichen, wird auch als Configuration by Exception bezeichnet [SVEH07, S. 116]. 58

71 5 Die Software Factory 5.2 Überblick Abbildung 5.3: Build mit M2M-Transformationen Die Software Factory ist in die Entwicklungsumgebung Eclipse eingebettet. Dies ergibt sich direkt aus der Anforderung, die Anwendungsentwicklung zentral in einer IDE zu halten. Da bereits eine Vielzahl von Eclipse-Plugins erhältlich ist, die die Softwareerstellung im Bereich Java EE unterstützen, ist die Implementierung der Software Factory auf Basis von Eclipse ein logischer Schritt. Zudem ist die Eclipse-Plattform quelloffen und frei verfügbar. Die Erweiterung durch Plugins ist unkompliziert und gut dokumentiert. Die Installation und Aktualisierung von Plugins wird durch den Update Manager erleichtert, was gerade für die Einbindung von Cartridges in die IDE des Anwendungsentwicklers sehr nützlich ist. Der Pluginmechanismus von Eclipse erlaubt auch die Definition eigener Erweiterungspunkte. Dies dient als Grundlage für das Cartridge-System der Software Factory. Für die Erstellung der domänenspezifischen Sprache kommen ebenfalls freie und quelloffene Frameworks zum Einsatz, die zudem Eclipse-Unterprojekte sind und sich somit nahtlos in diese Plattform integrieren lassen. Das Metamodell wird mit dem Eclipse Modeling Framework basierend auf dem Metametamodell Ecore erstellt (vgl. Abschnitt 4.2). Ecore als vereinfachte Form der MOF ist durch seine Überschaubarkeit zweckmäßig und ausreichend für die formale Beschreibung des Domain-Metamodells. Eine umfassende MOF-Implementierung zu nutzen ist nicht nötig und auch nicht möglich, da derzeit keine vollständige MOF-Implementierung auf dem Markt ist. Abschnitt geht noch 59

72 5 Die Software Factory 5.2 Überblick ausführlicher auf die Beschreibung des Metamodells Domain mit EMF ein. Das Graphical Modeling Framework wird verwendet, um die grafische Syntax der DSL festzulegen und einen Editor dafür zu generieren. GMF ist speziell auf EMF-Metamodelle ausgerichtet und das einzige Framework, das eine Editorerstellung durch einfache grafische Mappingdefinitionen ermöglicht. Es erspart die mühsame Arbeit einer manuellen Erstellung eines solchen Editors. Implementierung der Cartridges Die Implementierung der Cartridges stützt sich auf das in Abschnitt 4.3 vorgestellte MDSD-Framework openarchitectureware. Es umfasst Sprachen und Werkzeugunterstützung für Modellvalidierung, -transformation und Artefaktgenerierung und ist um weitere Komponenten erweiterbar. oaw kann EMF-basierte Metamodellinstanzen verarbeiten und bietet zudem einen GMF-Adapter zur Integration der Validierung in den Editor. Die Unterstützung dieser beiden Frameworks prädestinieren oaw für die Verwendung in den Software-Factory-Cartridges. Darüber hinaus ist es beliebig anpassbar und schränkt die Cartridges damit nicht in ihren Möglichkeiten ein. Das Konzept der Schnittstellen zwischen Cartridges über Metamodell-Extensions und AOP lässt sich mit oaw hervorragend implementieren. Die oaw-extensions (vgl. Abschnitt auf S. 40) sind zur Definition von Metamodellerweiterung verwendbar und die aspektorientierte Programmierung wird gleich auf mehreren Ebenen angeboten: in den Templates, in den Workflows sowie in den oaw-extensions. Die für oaw-extensions bestimmte Sprache Xtend ist überdies für die Beschreibung von M2M-Transformationen einsetzbar. Diese Vielfalt an Funktionalität zeichnet openarchitectureware gegenüber dem MDA- Framework AndroMDA für die Verwendung in der Software Factory aus. AndroMDA bietet aktuell weder M2M-Unterstützung noch Konzepte wie AOP um eine flexible Schnittstellenarchitektur für Cartridges umzusetzen. Des Weiteren ist die Entwicklung von AndroMDA-Cartridges durch die fehlende Hilfestellung einer IDE erheblich aufwändiger. Zu guter Letzt sei erwähnt, dass die Fortentwicklung des oaw-frameworks wesentlich schneller voranschreitet und aktuelle Tendenzen der MDSD einbezieht, als dies bei AndroMDA der Fall ist. 60

73 5 Die Software Factory 5.2 Überblick Software-Factory- und Anwendungsentwicklung In Abschnitt wurde bereits auf die zwei Entwicklungsebenen eingegangen, die im Kontext einer Software Factory existieren. Zum einen ist dies die Entwicklung von Anwendungen (hier Java-Enterprise-Anwendungen) mit Hilfe der Software Factory, zum anderen ist es die Fortentwicklung der Software Factory selbst. Im Folgenden sollen diese vergleichend dargestellt werden, um sie besser voneinander abzugrenzen. Produkte Software-Factory-Entwicklung Anwendungsentwicklung Java-EE-Anwendungen Entwickler SF-Entwickler, Cartridge-Entwickler Java-EE-Entwickler Nutzer Java-EE-Entwickler Kunde SF-Kernkomponenten, DSLs, Cartridges Entwicklungsumgebung Eclipse mit EMF, GMF, oaw Eclipse mit EMF, GMF, oaw und installierter Software Factory, weitere Plugins Tabelle 5.1: Gegenüberstellung Software-Factory- und Anwendungsentwicklung Entwickelte Produkte Das Ziel der Anwendungsentwicklung ist die Erstellung von Java-Enterprise-Applikationen. Diese umfassen hauptsächlich Java-Quellcode, aber auch weitere Artefakte wie Konfigurationsdateien, Deployment-Deskriptoren und Ressourcen. Um die Anwendungskomponenten ausführbar zu machen, werden die Artefakte in Archive gepackt und am Anwendungsserver angemeldet. Die Software-Factory-Entwicklung zielt hingegen auf die Realisierung eines Werkzeugs ab, mit dem Java-EE-Anwendungen schneller, fehlerfreier und günstiger erstellt werden können. Die Produkte dieser Arbeit sind die Kernkomponenten der Software Factory inklusive der GUI, die DSLs, mit denen der Java-EE-Entwickler später Teile der Anwendung modellieren soll, sowie die Cartridges, die aus diesen Modellen dann die Zielartefakte generieren. 61

74 5 Die Software Factory 5.2 Überblick Beteiligte Rollen Die Software Factory wird vom Software-Factory-Entwickler realisiert. Dies umfasst vor allem die Erstellung und Fortentwicklung der Kernkomponenten sowie der domänenspezifischen Sprache. Die Cartridge-Entwicklung kann als eine separate Aufgabe angesehen werden, weshalb hier die Rolle des Cartridge-Entwicklers eingeführt wird. Nichtsdestotrotz können beide Rollen von derselben Person oder Personengruppe eingenommen werden. An sie sind die folgenden Anforderungen gestellt: Der SF-Entwickler muss hauptsächlich Kenntnisse im Umgang mit der Eclipse-API haben. Sofern er für die Entwicklung der DSL zuständig ist, muss er neben dem Wissen über Implementierungstechnologie (z. B. EMF und GMF) eine ausreichende Sachkenntnis der zugrundeliegenden Domäne mitbringen, um deren Konzept bestmöglich in der DSL abzubilden. Dies gilt auch für den Cartridge-Entwickler, der die Modelltransformationen und Generierungstemplates für die Elemente der DSL schreibt. Um daraus adäquate Artefakte zu generieren, ist es unerlässlich, dass er hinreichende Kenntnisse der Zieltechnologie (Java EE, Frameworks etc.) besitzt. Darüber hinaus muss er in der Lage sein, die Cartridge mit einer MDSD-tauglichen Sprache wie oaw zu implementieren. Die von diesen Rollen erarbeitete Software Factory wird vom Java-EE-Entwickler zur Erstellung von Enterprise-Anwendungen verwendet. Er sollte mit der Bedienung der Software Factory vertraut sein, um damit effektiv entwickeln zu können. Zusätzlich kommt ihm die Aufgabe zu, mit den SF-Entwicklern in Rücksprache zu treten, um sie auf Probleme aufmerksam zu machen, die im produktiven Einsatz zu Tage getreten sind. Neben Unzulänglichkeiten in der Bedienung der Software können dies vor allem eine unzweckmäßige Konzeption der DSL sowie eine unzureichende Qualität und Eignung der generierten Artefakte sein. Entwicklungsumgebung In Abbildung 5.4 sind die Entwicklungsumgebungen für die Erstellung der Software Factory und von Java-Enterprise-Anwendungen vergleichend dargestellt. In beiden Fällen ist dies eine um zusätzliche Plugins erweiterte Eclipse. Abbildung 5.4a zeigt, dass in der IDE für die SF-Entwicklung die Plugins installiert sind, die für die Erstellung der DSL und der Cartridges benötigt werden. Im Workspace liegen die Eclipse-Pluginprojekte für die 62

75 5 Die Software Factory 5.2 Überblick Bestandteile der Software Factory 3. Diese werden in die IDE des Anwendungsentwicklers installiert, wie in Abbildung 5.4b zu sehen ist. Dabei sind auch die Plugins einzubinden, die für die Lauffähigkeit der Software Factory erforderlich sind. Darüber hinaus können in dieser Entwicklungsumgebung weitere Plugins, die dem Entwickler bei der Erstellung von Java-Enterprise-Applikationen assistieren, installiert sein. Beispielsweise bietet sich bei Verwendung des Spring-Frameworks das SpringIDE-Plugin an, um die Verdrahtung der Beans grafisch zu visualisieren. Der Workspace enthält ein Software-Factory-Projekt, welches das Wurzelelement für eine Java-Enterprise-Anwendung darstellt. In diesem Projekt werden die Domain-Modelle angelegt. Die Software Factory erstellt daraus weitere Projekte, in die die Artefakte generiert werden. Für jedes Modul (siehe nächster Abschnitt) ist dabei ein eigenes Projekt vorgesehen. (a) Software Factory (b) Java-EE-Anwendung Abbildung 5.4: Die Entwicklungsumgebungen im Vergleich 3 Das für die Pluginerstellung benötigte PDE ist in den Abbildungen 5.4a und 5.4b nicht dargestellt, da es eine Eclipse-Kernkomponente ist (vgl. Abschnitt 4.1 auf S. 32). 63

76 5 Die Software Factory 5.3 Modellierung des Problemraums 5.3 Modellierung des Problemraums Das Metamodell Domain Um mit der Software Factory modellgetrieben entwickeln zu können, ist eine Modellierungssprache nötig, welche die Konzepte des Problemraums (Domäne) verwendet. Die Domäne der Software Factory ist die Architektur von Java-Enterprise-Anwendungen bzw. von Enterprise-Anwendungen, da die grundlegenden Konzepte von der Zielplattform weitgehend unabhängig sind. In Abschnitt wurden zweckmäßige Muster erläutert, die sich zur Beschreibung einer solchen Architektur eignen. Die für die Software Factory entwickelte DSL Domain setzt wesentliche dieser Elemente in ihrem Metamodell um. Mit ihr lässt sich Fachwissen im Kontext einer Java-Enterprise-Anwendung ausdrücken. Abbildung 5.5: Das Metamodell Domain Abbildung 5.5 zeigt das Domain-Metamodell im Überblick. Es verwendet die Entität als Muster um Objekte mit eindeutiger Identität darzustellen. Eine Entität enthält eine Menge von Attributen, deren Typen die Standarddatentypen wie String und int oder ein Aufzählungstyp (Enum) sein können. Ein Aufzählungstyp ist eine Menge von Literalen. Die Beziehungen zwischen Entitäten werden durch Referenzen ausgedrückt. Attribute und Referenzen sind unter einer gemeinsamen Oberklasse Entity Feature zu- 64

77 5 Die Software Factory 5.3 Modellierung des Problemraums sammengefasst. Dies drückt aus, dass beide Merkmale der Entität darstellen, was konzeptionell zunächst nur geringe Bedeutung hat. Der Vorteil zeigt sich erst bei den Gene- rierungstemplates, bei denen Templatecode zusammengefasst werden kann, der sowohl auf Attribute als auch auf Referenzen anwendbar ist. Entitäten können auch Operationen enthalten, jedoch sollten diese sich nicht über den Bereich der Entität hinaus auswirken. Alle anderen Operationen sind in Services auszulagern (vgl. Abschnitt 2.4.1, S. 10). Ein weiterer Bestandteil von Entitäten im Metamodell Domain sind Abfragen (Queries). Sie bieten die Möglichkeit, Suchkriterien zu definieren, anhand derer Entitäten abgefragt werden können. Diese könnten beispielsweise an ein Repository gestellt werden, um Entitäten aus einer Datenbank zu holen (vgl. Abschnitt 2.4.1, S. 12). Die Suchkriterien sind eine und-verknüpfte Menge an Attributen der Entität, für die der Genauigkeitsgrad der Übereinstimmung (MatchType) angegeben werden kann. Eine solche Möglichkeit der Spezifizierung von Abfragen wird u. a. auch in dem MDA-Werkzeug OptimalJ verwendet. Zwischen den Entitäten können Vererbungsbeziehungen bestehen, so wie es z. B. aus der UML für Klassen bekannt ist. Jedoch können die Entitäten jeweils nur eine Entität erweitern, Mehrfachvererbung wird nicht angeboten. Die Domänenlogik ist in den Operationen der Services zu implementieren. Die Services sind damit Schnittstellen, über die aus der Präsentationsschicht heraus auf die Anwendungslogik zugegriffen werden kann. Die Parameter und Rückgabewerte der Operationen können Entitäten, Standarddatentypen oder Aufzählungstypen sein. Die Anwendungslogik wird meist das Lesen oder Verändern von Daten beinhalten, die in den Entitäten stecken. Die Services müssen somit eine Möglichkeit haben, auf diese Entitäten zuzugreifen. Das Domain-Metamodell definiert dafür das Element Managed Dependency, das eine Referenz von einem Service auf eine Entität darstellt. Auch zwischen den Services bestehen meist Abhängigkeiten. Das ist dann der Fall, wenn Serviceoperationen die Funktionalität weiterer Services benötigen. Dies wird durch Servicereferenzen ausgedrückt. Analog zu den Entitätsmerkmalen ist auch für die Servicemerkmale eine gemeinsame Oberklasse definiert. Um die Komplexität großer Anwendungen beherrschbar zu machen, muss das Domänenmodell in kleinere und lose zusammenhängende Teilmodelle zerlegt werden können. Das Domain-Metamodell trägt dem Rechnung, indem es das Modul einführt. Ein Domain- Modell kann beliebig viele dieser Module enthalten. Ein Modul gruppiert logisch zusammenhängende Entitäten, Services und Aufzählungstypen. Die Verbindungen zwischen Modulen werden nicht expliziert modelliert, sondern ergeben sich daraus, dass die Ele- 65

78 5 Die Software Factory 5.3 Modellierung des Problemraums mente eines Moduls die Elemente eines anderen Moduls referenzieren können. Mit dem in Abbildung 5.5 skizzierten Metamodell Domain lassen sich die grundlegenden Inhalte in einer Java-Enterprise-Anwendung beschreiben. Es sollte in jedem Fall noch um ein Konstrukt für Werteobjekte (siehe Abschnitt auf S. 9) erweitert werden, damit neben den Standarddatentypen auch eigene Datentypen angelegt werden können. Weniger essenziell, jedoch eine Überlegung wert ist die Ergänzung um Aggregate. Damit lässt sich schon auf Modellebene ausdrücken, welche Objekte bezüglich ihres Lebenszyklus miteinander gekoppelt sind. Da bei Programmiersprachen wie Java das Aggregat als Konzept nicht integriert ist, lohnt es sich, die Aggregate bereits im Domänenmodell festzuhalten. Bei der Codegenerierung können dann entsprechende Entwurfsmuster oder Frameworks zum Einsatz kommen, die Aggregate mit den Mitteln der Programmiersprache umsetzen [HP07, S. 79]. Zu guter Letzt sollte bei der Fortentwicklung des Domain-Metamodells die Verschachtelbarkeit der Module in Betracht gezogen werden. Das bedeutet, dass ein Modul wiederum Module enthalten kann. Dies ermöglicht eine feinere Strukturierung der Domain-Modelle, birgt jedoch auch die Gefahr einer zu starken Gliederung zu Lasten der Übersichtlichkeit. Um das Metamodell möglichst einfach zu halten und aufgrund der Schwierigkeit der technischen Umsetzung wurde im Rahmen der Diplomarbeit auf die Schachtelung verzichtet. Statische Semantik Die oben erläuterten Metamodellelemente und ihre Beziehungen zueinander stellen die abstrakte Syntax des Metamodells Domain dar. Darüber hinaus benötigt das Metamodell auch eine statische Semantik. Diese beinhaltet Zusicherungen, die für ein Modell gelten müssen, damit es als gültig angesehen werden kann. Beispielsweise muss festgelegt sein, dass eine Entität nicht von sich selbst erben kann. Diese Informationen sind im Metamodell in Abbildung 5.5 nicht dargestellt. Sie sind in Tabelle A.1 auf S. 115 zusammengefasst Die DSL Domain als EMF-Modell Das Domain-Metamodell auf Ebene M2 ist mit den Mitteln des Eclipse Modeling Frameworks realisiert, d. h., das Metamodell von Domain ist Ecore. Es bieten sich meh- 66

79 5 Die Software Factory 5.3 Modellierung des Problemraums rere Möglichkeiten an, das oben beschriebene Domain-Metamodell EMF-basiert umzusetzen: Zunächst stellt sich die Frage, ob das Metamodell direkt auf Ecore oder der EMF-basierten UML2-Implementation (siehe Abschnitt 4.2.4) aufsetzen soll. UML2 ermöglicht die Erweiterung durch Profile (siehe Abschnitt 3.3.5). Die Konzepte des UML- Klassendiagrammes (z. B. Klassen, bidirektionale Assoziationen) sind bereits implementiert und es muss auch kein Editor erstellt werden. Das Anlegen und Verwenden eines Profils mit dem mitgelieferten Editor ist jedoch nicht sehr intuitiv, die Menüstruktur des Editors sehr überladen. Eine Anpassung ist nur begrenzt möglich. Ein Vorteil ist zweifelsohne die Möglichkeit, Domain-Modelle aus anderen Werkzeugen, die UML- Diagramme EMF-konform serialisieren können, zu importieren. Doch da zunehmend auch Ecore-basierte EMF-Modelle durch Werkzeuge unterstützt werden und der Fokus der Software Factory vielmehr auf einer ganzheitlichen Integration in Eclipse liegt, ist die Verwendung von Ecore gegenüber UML2 vorteilhafter. Des Weiteren ist zu überlegen, ob alle Elemente des Metamodells Domain von Grund auf vollständig modelliert werden, oder ob nicht Elemente des übergeordneten Ecore-Modells wiederverwendet werden können. Mit dem in der Software Factory vorliegenden Domain- Metamodell wird der zweite Weg eingeschlagen. Klassen aus dem auf Modellebene M3 gelegenen Ecore-Metamodell kommen damit auch auf M2 zum Einsatz. Es bieten sich dabei folgende Vorteile: Grundlegende Konzepte eines (Klassen-)Diagrammes wie Klassen, Referenzen und Attribute müssen nicht neu modelliert werden, Ecore bringt sie schon mit. Die für Ecore geltenden Zusicherungen, die die statische Semantik festlegen, lassen sich auch für Domain-Modelle überprüfen. Sie sind in Java-Code implementiert und ihre Nachprogrammierung bzw. Duplizierung aufwändig. Ferner sind vorhandene GMF- Mappings für die Erstellung einer grafischen Syntax wiederverwendbar. Nicht zuletzt sind in Ecore die Standarddatentypen wie String und int enthalten, deren Nachahmung überflüssig wird. Jedoch bringt die Wiederverwendung von Ecore-Elementen auch eine Reihe von Nachteilen mit sich: Das Metamodell geht eine Abhängigkeit zum Ecore-Metamodell ein, d. h., Änderungen in Ecore können das abhängige Metamodell ungültig werden lassen 4. Darüber hinaus leidet die Übersichtlichkeit von Beziehungen zwischen den Elementen, wenn sie von Ecore-Klassen erben, da die Beziehungen bereits in Ecore definiert sind und im darunterliegenden Metamodell nicht mehr auftauchen. 4 In einem Newsgroupbeitrag rät EMF-Projektleiter Ed Merks ausdrücklich davon ab, Elemente von Ecore-Elementen abzuleiten, da keine Rückwärtskompatibilität zukünftiger Ecore-Versionen gewährleistet wird. 67

80 5 Die Software Factory 5.3 Modellierung des Problemraums Abbildung 5.6 zeigt beispielhaft, wie Domain-Elemente von Ecore-Elementen erben. Die in Abbildung 5.5 angedeutete Referenz zwischen Entity und Attribute wird de facto durch die Referenz zwischen EClass und EAttribute umgesetzt. Die statische Semantik der Oberklasse gilt durch die Vererbungsbeziehung auch für die Unterklasse. Dies ist natürlich nicht ausreichend. Beispielsweise sollen Entitäten in Domain-Modellinstanzen nur von Entitäten erben können und nicht von beliebigen EClass-Objekten, so wie es EClass spezifiziert. Da Ecore keine direkte Spezialisierung im Metamodell anbietet, so wie es bei MOF/UML der Fall ist (vgl. Abschnitt auf S. 27), ist nach der Generierung des Modellcodes eine Anpassung der Edit-Klassen erforderlich (vgl. Abschnitt auf S. 35), um diese Zusicherungen umzusetzen. Hierbei ist darauf zu achten, die veränderten Methoden als manuellen Code zu markieren, damit die Änderungen bei erneuter Generierung nicht überschrieben werden. Eine weitere Möglichkeit wäre die Nutzung von generischen Typen als Mittel der Spezialisierung, doch bislang setzt der EMF-Codegenerator dies nicht hinreichend in entsprechenden Modellcode um, sodass ebenfalls manuelle Ergänzungen erforderlich wären. Zu beachten ist, dass die hier zu implementierenden Zusicherungen nicht Teil der Zusicherungen des Domain-Metamodells sind (vgl. Tabelle A.1 auf S. 115). Sie sind lediglich ein Mittel, um die abstrakte Syntax des Metamodells mittels Spezialisierung des Metamodells Ecore zu implementieren. Abbildung 5.6: Vererbungsbeziehungen zwischen Domain und Ecore (Ausschnitt) Aufwandsabschätzung Die Implementierung des Metamodells mit EMF setzt ausreichende Kenntnisse dieses Frameworks voraus. Während es eher unkompliziert ist, über den Baumeditor die Modellelemente zu definieren und ihre Beziehungen zueinander auszudrücken, gestaltet sich die Implementierung der Zusicherungen durch die Anpassung der generierten Edit-Klassen 68

81 5 Die Software Factory 5.3 Modellierung des Problemraums schon schwieriger. Hier ist ein hinreichendes Verständnis des erstellten Edit-Codes nötig. Im Übrigen muss auf die Kennzeichnung des veränderten Codes als manuell geachtet werden. Diese potenzielle Fehlerquelle kann zu unnötigem Mehraufwand führen, wenn die Änderungen durch einen erneuten Generierungslauf verworfen werden. Für den Entwurf und die Umsetzung des Metamodells mit dem Eclipse Modeling Framework wird ein Aufwand von etwa 11 Personentagen abgeschätzt Grafische Syntax mit GMF Nach der Generierung des Javacodes aus dem Domain-Metamodell steht ein baumartiger Editor zur Verfügung, mit dem Domain-Modelle erstellt und bearbeitet werden können. Wesentlich übersichtlicher ist hingegen eine grafische Syntax ähnlich einem Klassendiagramm. Die Software Factory enthält einen solchen grafischen Editor, der wie in Abschnitt beschrieben erstellt worden ist. Hervorzuheben ist hier, dass nicht alle dafür nötigen Definitionsmodelle von Grund auf neu erstellt, sondern Teile aus anderen Definitionsmodellen übernommen worden sind. So enthält das Graphical Modeling Framework bereits ein Grafikdefinitionsmodell für Klassendiagramme. Die darin definierten grafischen Elemente werden hier zur Darstellung der Elemente des Domain-Metamodells wiederverwendet. Die erstellten Definitionsmodelle sind im Anhang A.2 auf S. 116ff abgebildet. Eine interessante Funktion des grafischen Editors ist die Möglichkeit, innerhalb eines Moduls Shortcuts auf Elemente einer anderen Modelldatei anzulegen. Abbildung 5.7 verdeutlicht dies. Dadurch ist sichergestellt, dass Entitäten und Services auch über Modulgrenzen hinweg Referenzen besitzen können (vgl. Abschnitt 5.3.1). Eine weitere wichtige Eigenschaft des grafischen Modells ist die automatische Validierung. Sie gewährleistet, dass das Modell den Gültigkeitsregeln (Zusicherungen) entspricht, die in Tabelle A.1 auf S. 115 aufgeführt sind. Diese sind in der Validierungssprache Check formuliert und über den GMF-Adapter in den Editor eingebunden sind (vgl. Abschnitt auf S. 41). Listing 5.1 zeigt beispielhaft die Definition der Zusicherung, dass die Attribute einer Entität unterschiedliche Namen haben. Abbildung 5.8 stellt die automatische Validierung eines Modells dar, bei dem diese Zusicherung nicht gilt. 69

82 5 Die Software Factory 5.3 Modellierung des Problemraums Abbildung 5.7: Die Entität sales.account wird durch einen Shortcut in Modul customer eingebunden. Die Entität customer.client referenziert auf Account. import domain ; extension com :: saxsys :: sf :: dsl :: domain :: oaw :: extensions :: entity ; context Entity ERROR " The Entity " + name + " must have unique attributes." : e. eattributes. forall ( a1 e. eallattributes. notexists ( a2 a1!= a2 && a1. name == a2. name )); Listing 5.1: Definition einer Zusicherung in Check Abbildung 5.8: Der Editor zeigt an, dass die Zusicherung nicht erfüllt ist. 70

83 5 Die Software Factory 5.4 Cartridges Aufwandsabschätzung Die Erstellung der grafischen Syntax für Domain-Modelle mit GMF ist trotz der hervorragenden Kompatibilität zu EMF nicht trivial. Kaum Probleme bereitet das Konstruieren des Werkzeugdefinitionsmodells, das in Abbildung A.1 auf S. 116 dargestellt ist. Schwieriger ist schon das Grafikdefinitionsmodell (Abbildung A.2, S. 117), in dem die grafischen Elemente des Editors festgelegt werden. Hier gibt es viele Einstellungsmöglichkeiten und es ist oft nicht klar, was diese bewirken, zumal die Dokumentation des Frameworks diesbezüglich mangelhaft ist. Es ist daher zu empfehlen, sich aus anderen grafischen Editoren (wie z. B. dem GMF Sample Ecore Editor) Anregungen zu holen oder, wie oben beschrieben, bereits existierende Grafikdefinitionsmodelle wiederzuverwenden. Gleiches gilt für das Mappingmodell (Abbildung A.2, S. 119), das die Abbildung der Elemente des Domain-Modells auf die Diagrammelemente bestimmt. Auch hier ist ein Referenzmodell als Hilfestellung ratsam. Die Einbindung der in Check formulierten Zusicherungen für Domain-Modelle (vgl. Tabelle A.1 auf S. 115) in den Editor funktioniert hingegen problemlos. Dies ist auch für die Generierung des Editors aus den Definitionsmodellen festzustellen. Insgesamt sind etwa 10 Personentage nötig, um einen derartigen grafischen Editor für Domain-Modelle zu erstellen. 5.4 Cartridges die Brücke zwischen Modell und Technologie Mit den Werkzeugen zur Erstellung von Domain-Modellen hat der Entwickler von Java- Enterprise-Anwendungen ein Mittel, um die Fachlichkeit der Anwendung unabhängig von den Technologien, die zum Einsatz kommen sollen, auszudrücken. Die Auswahl der Technologien (Plattformen, Frameworks, usw.) erfolgt durch die Selektion von Cartridges, die das Wissen über die Transformation von Modellelementen zu technologiespezifischen Artefakten beinhalten. Sie werden vom Cartridge-Ersteller als Eclipse-Plugins zur Verfügung gestellt und müssen in der IDE des Anwendungsentwicklers installiert werden. Damit sind sie für ein mit der Software Factory verwaltetes Java-Projekt auswählbar. Wie beschrieben, stellen die Cartridges die Verbindung zwischen den technologieunabhängigen Modellen und der eingesetzten Technologie dar. Der Umfang und die Abgren- 71

84 5 Die Software Factory 5.4 Cartridges zung der Aufgaben der Cartridges sind in diesem Zusammenhang nicht festgelegt. So kann eine Cartridge sämtliche Artefakte einer Zieltechnologie erstellen, eine andere hingegen führt nur eine einfache Modelltransformation aus. Es obliegt prinzipiell der Entscheidung des Cartridge-Erstellers, inwieweit er Funktionalität auf mehrere Cartridges verteilen möchte. Jedoch sollte im Sinne der Verständlichkeit darauf geachtet werden, dass die Cartridges der Software Factory im Umfang nicht allzu sehr voneinander abweichen. Auch sollten sie nicht zu klein geschnitten sein. Einerseits, um das Geflecht an Abhängigkeiten zwischen den Cartridges übersichtlich zu halten und andererseits, um den Anwendungsentwickler nicht mit dem Anwählen vieler kleiner Cartridges abzulenken, welche zusammen die Technologie umsetzen, die er im Projekt verwenden möchte Aufbau Eine Cartridge im Sinne der Software Factory ist ein Eclipse-Plugin, das den Extension Point com.saxsys.sf.cartridge erweitert, der vom Software-Factory-Kern bereitgestellt wird. Dieser Extension Point verlangt die Deklaration einer Cartridge-ID und die Angabe einer oaw-workflowdatei, die den Ablauf der Komponenten festlegt. Neben zusätzlichen optionalen Feldern wie Name und Version, besteht auch die Möglichkeit, erforderliche (requires) und eingeschlossene (advices) Cartridges anzugeben. Erforderliche Cartridges sind solche, die in der Reihenfolge der Cartridge-Anwendung vor dieser ausgeführt werden müssen, wohingegen eingeschlossene Cartridges während der Ausführung der Cartridge von ihr aufgerufen werden (vgl. Abschnitt 5.2.1). Diese Informationen werden vom Kern-Plugin der Software Factory verwendet, um eine gültige Reihenfolge der Cartridges festzulegen. Abbildung 5.9 zeigt die Struktur des Extension Points im Eclipse Plugin-Manifest Editor. In Abbildung 5.10 sind zwei Extensions zu sehen, die diesen Extension Point erweitern. Darüber hinaus stellt die Software Factory zwei weitere Extension Points bereit, die von den Cartridge-Plugins erweitert werden können. Der Extension Point com.saxsys.sf. core.projectcontributions (Abbildung 5.11) bietet die Möglichkeit, Eclipse Builders und Natures festzulegen, die für die Anzeige und weitere Bearbeitung der von der Cartridge generierten Artefakte hilfreich sind 5. So könnte beispielsweise eine Cartridge, die Spring-Konfigurationsdateien erstellt, die Nature der SpringIDE [Sprb] angeben. Das Feld projectgenerator stellt einen Bezug zu der Cartridge her, die das Java-Projekt er- 5 Builders und Natures sind in [SDF + 03, Kap. 16] beschrieben. 72

85 5 Die Software Factory 5.4 Cartridges Abbildung 5.9: Extension Point com.saxsys.sf.cartridge Abbildung 5.10: Erweiterung des Extension Points com.saxsys.sf.cartridge 73

86 5 Die Software Factory 5.4 Cartridges stellt, welchem die Builders und Natures zugewiesen werden sollen. Der Extension Point com.saxsys.sf.core.classpathcontributions (Abbildung 5.12) hat zum Zweck, Ressourcen anzugeben, die in den Klassenpfad der generierten Artefakte übernommen werden sollen. Dies sind hauptsächlich Klassenbibliotheken, die von generierten Java-Klassen verwendet werden. Die Ressourcen müssen sich im Plugin der Cartridge befinden und werden über eine Pfadangabe im Extension Point referenziert. Es liegt also in der Verantwortung des Cartridge-Entwicklers, die Bibliotheken der Zieltechnologie, die zur Lauffähigkeit der erzeugten Artefakten notwendig sind, mit der Cartridge mitzuliefern. Sind aktualisierte Versionen dieser Bibliotheken vorhanden, so sind diese in der Cartridge auszutauschen und die aktualisierte Cartridge für den Anwendungsentwickler zur Verfügung zu stellen. Die Aufgabe der Verwaltung und Einbindung von Klassenbibliotheken wird dem Anwendungsentwickler damit weitestgehend abgenommen. Abbildung 5.11: Extension Point com.saxsys.sf.- core.projectcontributions Abbildung 5.12: Extension Point com.saxsys.sf.- core.classpathcontributions Wie beschrieben, wird im Extension Point cartridge der Pfad zu einer Workflowdatei angegeben. Dieser oaw-workflow spezifiziert eine Reihe von Workflowkomponenten und wird bei der Ausführung der Cartridge abgearbeitet. Die Komponenten können vielfältiger Natur sein. Das Framework openarchitectureware bringt bereits oft benötigte Komponenten mit, die im Workflow nur noch parametrisiert werden. Die Erstellung eigener Komponenten ist auch möglich [OAW07, S. 55]. Häufig gebraucht werden Komponenten zur Validierung und Transformation von Modellen sowie zur Generierung der Artefakte. Die dafür benötigten Transformierungsvorschriften, Validierungsregeln und Codebausteine sind ebenfalls in den Cartridge-Plugins untergebracht. 74

87 5 Die Software Factory 5.4 Cartridges Wenn die Cartridge entsprechend den vorhergehenden Ausführungen aufgebaut ist, kann sie dem Anwendungsentwickler zur Verfügung gestellt werden. Dies geschieht durch einfaches Kopieren des Plugins in den Pluginordner der Eclipse-Installation, mit welcher der Anwender arbeitet. Eine bessere Variante ist das Bereitstellen über den Eclipse Update Manager, der eine bequeme Installation, Deinstallation und Aktualisierung von Plugins gewährt. Abschnitt geht darauf näher ein Schnittstellen Eine Cartridge wird selten völlig eigenständig arbeiten. Vielmehr steht sie in Beziehung zu anderen Cartridges. Dies ist zum Beispiel der Fall, wenn sie Artefakte erstellt, die auf den generierten Artefakten anderer Cartridges basieren. Oft ist es dabei nötig, dass sie auf das Wissen dieser Cartridges zugreifen kann. Das bedeutet, zwischen den Cartridges müssen Schnittstellen existieren, über die dieses Wissen ausgetauscht werden kann. Die Software Factory für Java-Enterprise-Anwendungen verwendet verschiedene Ansätze, um solche Schnittstellen auszudrücken. MM-Extensions Ein Mittel sind die Metamodell-Extensions, die bereits in Abschnitt vorgestellt wurden (siehe Abbildung 5.1 auf S. 55). Sie definieren zusätzliche Eigenschaften und Hilfsmethoden ( Erweiterungen ) für die Elemente des Metamodells. Das in der Software Factory verwendete Framework openarchitectureware ermöglicht die Implementierung von MM-Extensions über die Erweiterungsprache Xtend. Diese MM-Extensions können sowohl von anderen MM-Extensions als auch von der Validierungssprache Check und der Templatesprache Xpand benutzt werden. Mit Hilfe der MM-Extensions lassen sich die Metamodellelemente um artefaktspezifische Details ergänzen. So kann z. B. festgelegt werden, wie sich der Name eines zu erstellenden Artefaktes aus einem Domain-Element ableitet. Dieses Wissen dient einer darauffolgenden Cartridge, um ein anderes Artefakt zu generieren, das mit dem zuvor erstellten in Beziehung steht. Listing 5.2 zeigt beispielhaft eine MM-Extension, die den Namen der Implementierungsklasse festlegt, welche für einen Service generiert wird. Das Template in Listing 5.3 nutzt diese Information, um ein anderes Artefakt, eine Spring-Bean für diesen Service, zu erstellen. Dafür muss der vollständige Name der Implementierungsklasse bekannt sein. 75

88 5 Die Software Factory 5.4 Cartridges // com. saxsys.sf.gen. entities / extensions / java / service. ext import domain ;... String packageimpl ( Service s ) :... ; String classnameimpl ( Service s ) : s. name (). tofirstupper (); String fullclassnameimpl ( Service s ) : packageimpl ( s) + "." + classnameimpl ( s); Listing 5.2: MM-Extension für den Namen einer Service-Implementierungsklasse «REM» com. saxsys.sf.gen. spring / templates / services. xpt «ENDREM» «IMPORT domain» «EXTENSION com :: saxsys :: sf :: gen :: entities :: extensions :: java :: service»... «DEFINE ServiceBean FOR Service» <bean id ="«beanid ()»" class ="«fullclassnameimpl ()»" > «EXPAND Properties -» </bean > «ENDDEFINE» Listing 5.3: Template für die Bean-Definition von Services in Spring Um die Möglichkeiten der MM-Extension-Schnittstellen auszuschöpfen, sollten alle Generierungsinformationen, bei denen abzusehen ist, dass sie an anderer Stelle wiederverwendet werden, aus den Templates extrahiert und in MM-Extensions augelagert werden. Dies betrifft vor allem Namen und Bezeichner, denn diese stellen ein Mittel dar, um auf bereits erstellte Artefakte Bezug zu nehmen. Alle anderen Templatebestandteile, die keinen Wiederverwendungswert haben, sollten hingegen in den Templates bleiben. Dadurch bleibt die Aussagekraft der Templates gewahrt. Die MM-Extensions sind als Schnittstelle zwischen Cartridges sehr gewissenhaft zu verwenden. Es gibt bislang im Framework openarchitectureware keine ausreichende Möglichkeit der Trennung von Schnittstelle und Implementierung. Das bedeutet, dass MM- Extensions, die als Cartridge-Schnittstelle dienen, nicht von den MM-Extensions abgegrenzt werden können, die nur Cartridge-intern zum Einsatz kommen. Das Verbergen der Implementierung ist zwar im Eclipse-Pluginkonzept dadurch umgesetzt, dass Schnittstellen explizit angegeben werden müssen [Ecl07, PDE-Guide], jedoch übergeht openarchitectureware diese Restriktionen 6. Es obliegt also dem Cartridge-Entwickler, die Trennung von Schnittstellen und Implementierung deutlich zu machen, etwa indem für die Implementierung ein gesondertes Verzeichnis verwendet wird. Des Weiteren 6 Laut oaw-entwicklerteam soll sich dies in zukünftigen Versionen ändern. 76

89 5 Die Software Factory 5.4 Cartridges ist zu beachten, dass die ausgiebige Verwendung von MM-Extensions über Cartridgegrenzen hinweg zu unüberschaubaren Abhängigkeiten führt. Das Ändern einer MM- Extension kann dann schnell zu Fehlern in weiteren Cartridges führen, besonders wenn der Cartridge-Entwickler sich der Abhängigkeiten zu dieser MM-Extension nicht bewusst ist. Eine mögliche Lösung des Problems ist die Verwendung von Tracing-Modellen, in denen festgehalten wird, aus welchen Modellelementen welche Artefakte generiert wurden [VG07, Abschn. 2.4]. Damit erübrigt sich der Zugriff auf MM-Extensions, die die Namen und Bezeichner generierter Artefakte zurückgeben. Diese Informationen sind dann im Tracing-Modell abrufbar. Aufgrund der eingeschränkten Tracing-Unterstützung in oaw setzt die im Rahmen dieser Arbeit entwickelte Software Factory diesen Ansatz nicht um. AOP in Templates Eine weitere Art der Schnittstellen zwischen Cartridges sind aspektorientierte Templates. Oftmals kommt es vor, dass eine Cartridge zusätzliche Informationen in ein Artefakt generieren möchte, das bereits von einer anderen Cartridge erstellt wird. Dies ist nur möglich, wenn beide Cartridges gleichzeitig zur Ausführung kommen, oder genauer, wenn die erste Cartridge mit den Aspekten der zweiten Cartridge ausgeführt wird. Unter der Prämisse, die ursprüngliche Cartridge zu diesem Zweck nicht ändern zu müssen, ist die Verwendung von aspektorientierter Programmierung das Mittel der Wahl. Dazu werden Aspekttemplates definiert, die die Ausgangstemplates nicht-invasiv erweitern. Die oaw-templatesprache Xpand stellt einen derartigen AOP-Mechanismus zur Verfügung. Das folgende Beispiel soll verdeutlichen, wie dieser zur Generierung eines Artefakts aus verschiedenen Cartridges heraus verwendet werden kann: Listing 5.4 zeigt auszugsweise eine Templatedatei, die aus einer Entität eine Javaklasse generiert. Die Templatedefinition Class ist für die Generierung des Klassenrumpfes verantwortlich. In Listing 5.5 ist eine Templatedatei aus einer anderen Cartridge zu sehen, die die erstellte Klasse mit Persistenzannotationen versehen soll. Dazu enthält sie einen Around- Advice, der die Templatedefinition Class umhüllt und an deren Stelle ausgeführt wird. Der Advice schreibt JPA-spezifische Annotationen in das Artefakt und ruft dann mittels «targetdef.proceed()» das eigentliche Template Class auf. Die erstellte Datei enthält dann sowohl die Annotationen als auch die Klassenspezifikation. Das Ausführen der JPA-Cartridge als aspektorientierte Cartridge muss zuvor im oaw-workflow konfiguriert worden sein (siehe [OAW07, S. 100]). Darüber hinaus ist im Extension Point 77

90 5 Die Software Factory 5.4 Cartridges cartridge anzugeben, dass die Cartridge eine andere umschließt (siehe Abschnitt auf S. 72). «REM» com. saxsys.sf.gen. entities / templates / java / entitybaseclass. xpt «ENDREM» «IMPORT domain»... «DEFINE BaseClassFile FOR Entity» «FILE fullfilenamebase () java -» package «packagebase ()»; «EXPAND Class» «ENDFILE» «ENDDEFINE» «DEFINE Class FOR Entity» public «EXPAND Abstract» class «classnamebase ()» «EXPAND SuperTypes» { «EXPAND Impl» } «ENDDEFINE»... Listing 5.4: Template für eine Entityklasse «REM» com. saxsys.sf.gen. persistence. jpa / templates / annotations. xpt «ENDREM» «IMPORT domain»... «AROUND com :: saxsys :: sf :: gen :: entities :: templates :: java :: entitybaseclass :: Class FOR persistence. persistence. Table ( name ="«tablename ()»")... «targetdef. proceed ()» «ENDAROUND»... Listing 5.5: Template für JPA-Annotationen an eine Entityklasse Ein Advice bezieht sich stets auf eine Templatedefinition («DEFINE»), die er umschließt. In der AOP bezeichnet man diese Erweiterungspunkte als Join Points. Bei der Cartridge- Entwicklung ist folglich zu beachten, dass Templateteile, die erweiterbar sein sollen, auch als Templatedefinition vorliegen müssen. Beispielsweise ließe sich das Listing 5.4 auch so umformen, dass der Klassenrumpf direkt im Template BaseClassFile erstellt würde. Das Class-Template fiele also weg. Dies hätte zur Folge, dass der Around-Advice in Listing 5.5 keine Möglichkeit mehr hätte, Annotationen direkt über den Klassenrumpf zu schreiben, weil der erforderliche Join Point fehlte. Die Templates sollten aus diesem Grund also fein gegliedert sein. 78

91 5 Die Software Factory 5.4 Cartridges Template-AOP lässt sich in Cartridges auch verwenden, um Erweiterungspunkte für Informationen zur Verfügung zu stellen, die die Cartridge selbst nicht liefern kann. Dafür wird eine leere Templatedefinition als Join Point bereitgestellt, die dann durch einen Around Advice einer Aspektcartridge mit Implementierung gefüllt wird. Listing 5.6 zeigt einen Ausschnitt aus dem Template zur Generierung der persistence.xml des JPA- Frameworks (vgl. [JPA06, S. 135]). Die JPA-Cartridge weiß nicht, welcher Persistenzprovider letztendlich das objektrelationale Mapping ausführt. Deshalb wird eine leere Templatedefinition als Join Point bereitgestellt. Das Template in Listing 5.7 stellt dar, wie eine Hibernate-Cartridge diesen Join Point erweitern könnte, um die entsprechende Hibernate-Klasse als Persistenzprovider einzutragen. «REM» com. saxsys.sf.gen. persistence. jpa / templates / descriptor. xpt «ENDREM» «IMPORT domain»... «DEFINE Root FOR Module» «FILE filename () descriptor» < persistence... > «EXPAND PersistenceUnit» </ persistence > «ENDFILE» «ENDDEFINE» «DEFINE PersistenceUnit FOR Module» < persistence - unit name ="«name ()»" transaction - type =" JTA "> <!-- service provider --> <provider >«EXPAND ServiceProviderClass» </ provider > <!-- persistable classes --> «EXPAND Entity FOREACH econtents. typeselect ( Entity )»... </ persistence -unit > «ENDDEFINE» «DEFINE ServiceProviderClass FOR Module»«ENDDEFINE» Listing 5.6: Template für eine persistence.xml in JPA «IMPORT domain» «AROUND com :: saxsys :: sf :: gen :: persistence :: jpa :: templates :: descriptor :: ServiceProviderClass FOR Module» org. hibernate. ejb. HibernatePersistence «ENDAROUND» Listing 5.7: Template für Hibernate als Persistenzprovider Der Ansatz der aspektorientierten Templates ermöglicht eine unkomplizierte Erweiterung von Cartridges, ohne diese ändern zu müssen. Jedoch bringt er auch einen entscheiden- 79

92 5 Die Software Factory 5.4 Cartridges den Nachteil mit sich: Eine Cartridge innerhalb der Software Factory kann effektiv nur von einer Aspektcartridge umschlossen werden. Der Grund hierfür liegt darin, dass die Aspektcartridge an die Stelle der ursprünglichen Cartridge tritt und deren Ausführung auslöst. Eine weitere Aspektcartridge, die ebenso verfahren würde, riefe abermals die umschlossene Cartridge auf, sodass das Artefakt erneut erstellt würde, jedoch ohne die Aspekte der ersten Aspektcartridge. Eine Lösung dieses Problems sollte Ziel weiterer Arbeiten zur Software Factory für Java-Enterprise-Anwendungen sein. Java-Code Prinzipiell kann auch Java-Code als Schnittstelle zwischen Cartridges benutzt werden. Dies ist der Fall, wenn eine Cartridge Java-Code einer anderen Cartridge referenziert. Jedoch ist dies eher selten, da in den Cartridges hauptsächlich MDSD-Sprachen wie Xpand und Xtend zum Einsatz kommen. Ein Anwendungsfall ist die Einbindung von (in Java implementierten) Workflowkomponenten in den Workflow einer anderen Cartridge. Die Software Factory nutzt diese Möglichkeit, um in den Generierungscartridges einen generischen Codeformatierer (Beautifier) einzubinden. Anders als bei den MM-Extensions (vgl. Abschnitt auf S. 75) ist hierbei auf die Sichtbarkeit des Java-Codes zu achten, d. h., nur als öffentliche Schnittstellen markierte Javaklassen (vgl. [Ecl07, PDE-Guide]) können über Cartridge-Grenzen hinweg referenziert werden. Eigenschaften (Properties) Wie in Abschnitt erwähnt, enthält jede Cartridge der Software Factory einen Workflow, der eine Folge von Workflowkomponenten festlegt. Diese Komponenten müssen parametrisiert werden. Zum Beispiel muss einer Generatorkomponente mitgeteilt werden, in welchen Ausgabeverzeichnissen sie die Artefakte ablegen soll. Zu diesem Zweck können oaw-workflows Eigenschaften (Properties) aus einfachen Textdateien laden und mit diesen die Komponenten konfigurieren (vgl. [OAW07, S. 57]). Mitunter ist es nötig, dass verschiedene Cartridges dafür die gleichen Eigenschaften benutzen, d. h., diese Informationen müssen zwischen Cartridges ausgetauscht werden können. Die MM-Extensions kommen dafür nicht in Frage, da sie nur in den oaw-sprachen, nicht jedoch in den Workflows verwendbar sind. Demzufolge werden die Eigenschaftendateien als Schnittstelle eingesetzt, um auf diese Informationen zuzugreifen. Listing 5.8 zeigt eine solche 80

93 5 Die Software Factory 5.4 Cartridges Datei. In ihr werden die Ausgabeverzeichnisse für generierten Code und andere Artefakte festgelegt. Diese Eigenschaften werden im Workflow einer anderen Cartridge (Listing 5.9) geladen und an die Generatorkomponente weitergereicht. # com. saxsys.sf.gen. module / workflows / outdir. properties out. dir. gen. java = src - gen / main / java out. dir. gen. resources = src - gen / main / resources out. dir. once. java = src - once / main / java out. dir. once. resources = src - once / main / resources out. dir. man = src Listing 5.8: Eigenschaftendatei mit Ausgabeverzeichnissen <! -- com. saxsys.sf.gen. entities / workflows / pojo. oaw --> < workflow > < property file =" com / saxsys /sf/gen / entities / workflows / workflow. properties " /> < property file =" com / saxsys /sf/gen / module / workflows / outdirs. properties " />... <! -- generate --> < component id=" pojogenerator " class =" org. openarchitectureware. xpand2. Generator ">... <! -- outlet paths --> < outlet path ="${ out. dir. default }" /> < outlet name =" java " path ="${ basedir }/${ out. dir. gen. java }" /> < outlet name =" manjava " path ="${ basedir }/${ out. dir. once. java }" overwrite =" false " /> </ component >... </ workflow > Listing 5.9: Workflow mit Generatorkomponente Die in den Textdateien gespeicherten Eigenschaften sind einfache Schlüssel-Wert-Paare gemäß den Properties in Java (siehe [Jav06]), wobei sowohl die Schlüssel als auch ihre Werte Zeichenketten sind. Dies beschränkt den Anwendungsbereich auf einfache Einstellungen, im Gegensatz zu den MM-Extensions, die auch Datentypen und Objekte transportieren können. Das Schlüssel-Wert-Paar-Format ist für Konfigurationsdateien sehr gebräuchlich. Demnach ist es auch vorstellbar, nicht nur die Eigenschaften aus statischen Cartridge-internen Eigenschaftendateien zu lesen, sondern Informationen auch aus anderen Quellen zur Konfiguration der Workflowkomponenten zu benutzen. Beispielsweise werden die Einstellungen, die in der Benutzeroberfläche von Eclipse festgelegt werden können, in solchen Textdateien gespeichert (vgl. [SDF + 03, S. 286]). Dies könnte in zukünftigen Versionen der Software Factory verwendet werden, um dem Anwendungsentwickler die Konfiguration der Cartridges über die Benutzeroberfläche zu 81

94 5 Die Software Factory 5.4 Cartridges ermöglichen. Weitere Schnittstellen Die zuvor beschriebenen Schnittstellen kommen in den Cartridges der Software Factory für Java-Enterprise-Anwendungen bereits zum Einsatz. Darüber hinaus existieren weitere Verbindungspunkte, die als Cartridge-Schnittstellen genutzt werden könnten. So ist es analog zu den MM-Extensions auch möglich, über Cartridgegrenzen hinweg aus den Templates andere Templates zu referenzieren. Dies ist u. a. geeignet, um generische und abstrakte Templates in eine eigene Cartridge auszulagern und aus den Templates einer spezifischen Cartridge aufzurufen. Aspektorientierte Programmierung kann auch auf der Ebene der MM-Extensions angewendet werden. Statt einer Erweiterung der Templates, wie sie auf Seite 77 beschrieben ist, werden hier die in Xtend definierten MM-Extensions erweitert. Dies ist vor allem im Bereich der Modell-zu-Modell-Transformationen interessant. Die durch MM-Extensions beschriebenen M2M-Transformationen einer Cartridge könnten so durch eine Aspektcartridge um weitere Informationen ergänzt werden. Bei allen Schnittstellenansätzen, die auf den oaw-sprachen aufbauen, ist stets auf eine klare und offensichtliche Aufteilung in Schnittstellen- und Implementierungscode zu achten, da oaw aktuell dafür keine Möglichkeiten bereitstellt (siehe Abschnitt auf S. 76) Leitlinien für die Cartridgeentwicklung Bei der Entwicklung der exemplarischen Cartridges im Zuge der Diplomarbeit haben sich nützliche Vorgehensweisen und Erfolgsmethoden herauskristallisiert, die hier als Leitlinien für die Entwicklung weiterer Software-Factory-Cartridges dienen sollen. Manuelle und generierte Artefakte trennen Eine mit Hilfe der Software Factory entwickelte Java-EE-Anwendung setzt sich aus generierten Artefakten und vom Anwendungsentwickler manuell erstellten Artefakten zusammen. Die generierten Anteile dürfen von ihm niemals nachträglich verändert werden, da sie sonst nicht mehr synchron zu den Ausgangsmodellen sind. Sie werden auch nicht mit versioniert, denn sie stellen keine Quellartefakte dar und lassen sich jederzeit aus 82

95 5 Die Software Factory 5.4 Cartridges den Modellen generieren. Zu diesem Zweck sollte manueller und generierter Code stets in verschiedenen Dateien und zusätzlich in verschiedenen Verzeichnissen gehalten werden. Die Versionsverwaltung wird so erheblich vereinfacht. Diese Trennung hat auch noch einen weiteren wichtigen Grund: Enthält eine Datei der Zieltechnologie sowohl generierten als auch manuellen Code, so besteht das Problem, dass die Software Factory bei einem erneuten Build die manuellen Anteile überschreibt. Dies lässt sich nur verhindern, indem in den Generatortemplates geschützte Bereiche definiert werden, innerhalb derer die Zielartefakte manuell geändert werden können. Der Generator lässt diese Bereiche bei einer wiederholten Generierung unberührt, so dass die Änderungen nicht verloren gehen. Listing 5.10 zeigt, wie eine generierte Klasse mit geschütztem Bereich für die Entität in Abbildung 5.13 aussehen könnte. Dieser Ansatz löst jedoch nicht das Problem der Versionierung und sollte deshalb nur angewendet werden, wenn keine anderen Mittel zur Trennung von generiertem und manuellem Code in Betracht gezogen werden können. Ein Beispiel für den Anwendungsbereich von geschützten Bereichen sind Java-EE-Deployment-Deskriptoren, die sich nicht in mehrere Dateien aufspalten lassen. Abbildung 5.13: Ausgangsmodellelement für Generierung Ein Zusammensetzen von Artefakten aus mehreren Dateien ist eine sehr geeignete Möglichkeit, um dem oben genannten Problem zu entgegnen. Beispielsweise lässt sich die Konfiguration des Applikationskontextes im Spring-Framework auf mehrere Dateien verteilen. Auf der Ebene von Programmiersprachen ist dies vor allem durch das Mittel der partiellen Klassen möglich, wie sie im.net-framework üblich sind. Damit kann sich eine Klasse aus einer generierten Datei und einer von Anwendungsentwickler erstellten Datei zusammensetzen. Leider bietet Java diese Funktionalität nicht, sodass hier andere Lösungen benötigt werden. Eine Möglichkeit ist die Nutzung einer Vererbungshierarchie. Dabei erstellt der Generator für ein Modellelement eine abstrakte Basisklasse, die bereits jegliche Informationen 83

96 5 Die Software Factory 5.4 Cartridges // com. example /src - gen / com / example / entities / Car. java package com. example. entities ; public class Car { private int kw; // Konstruktoren, Getter / Setter... } // Operation public int getps () { /* PROTECTED REGION ID( getps ) ENABLED START */ // Implementierung der Operation... /* PROTECTED REGION END */ } Listing 5.10: Generierte Klasse mit geschütztem Bereich aus dem Element enthält, die keiner manuellen Anpassung bedürfen. Der Anwendungsentwickler schreibt seine manuellen Anteile in eine Implementierungsklasse, die von der generierten Basisklasse erbt. Die Implementierungsklasse kann auch von der Cartridge einmalig generiert werden ( one-shot ), um dem Entwickler eine Vorlage bereit zu stellen. Listing 5.11 zeigt beispielhaft die abstrakte Basisklasse, die für die Entität in Ab- bildung 5.13 generiert wurde. Die Implementierung der Methode getps() muss vom Anwendungsentwickler vorgenommen werden. Dies geschieht in der Implementierungsklasse in Listing Obgleich dieser Ansatz die Versionierungsprobleme der geschützten Bereiche bewältigt, bringt er eine wesentliche Einschränkung mit sich: Die zugrundeliegenden Modellelemente dürfen nicht selbst in einer Vererbungshierarchie strukturiert sein. Denn eine Vererbung aus fachlicher Sicht und aus Sicht der Trennung der Artefakte würde erfordern, dass die Zielprogrammiersprache Mehrfachvererbung unterstützt. Dies ist bei Java allerdings nicht der Fall 7. Der Ansatz ist somit beispielsweise für die Entitäten des Domain-Metamodells (siehe Abbildung 5.5 auf S. 64) nicht umsetzbar. Um auch für Modellelemente, die in einer Vererbungsbeziehung stehen, eine Trennung von generierten und manuellen Codeteilen zu ermöglichen, wird stattdessen Aspektorientierte Programmierung (AOP) verwendet. Der Generator erstellt hierbei eine (nicht abstrakte) Basisklasse und der Anwendungsentwickler fügt seine manuellen Anteile in 7 Die Mehrfachimplementierung von Schnittstellen hilft hier auch nicht weiter, denn die abstrakten Basisklassen können nicht durch Schnittstellen ersetzen werden können, da sie Implementierung enthalten. 84

97 5 Die Software Factory 5.4 Cartridges // com. example /src - gen / com / example / entities / Car. java package com. example. entities ; public abstract class Car { private int kw; } // Konstruktoren, Getter / Setter... // Operation public abstract int getps (); Listing 5.11: Generierte abstrakte Basisklasse // com. example / src / com / example / entities / impl / CarImpl. java package com. example. entities. impl ; import com. example. entities. Car ; public class CarImpl extends Car public int getps () { // Implementierung der Operation... } } Listing 5.12: Manuell erstellte Implementierungsklasse einen Implementierungsaspekt ein. Für die Zielsprache Java bietet sich dabei die aspektorientierte Sprache AspectJ an [AJ]. Der Aspekt wird so zur Übersetzungszeit vom AspectJ-Compiler in den Bytecode der Basisklasse eingewebt. Auch hier ist es ratsam, per One-Shot-Generierung den Implementierungsaspekt bereits zu erstellen, damit der Entwickler eine Vorlage vorfindet, in die er seine Änderungen nur noch einzupflegen braucht. In Listing 5.13 und 5.14 sind die Artefakte zu sehen, die aus der Entität in Abbildung 5.13 auf S. 83 generiert werden. Die Nachteile, die bei der Verwendung dieses Ansatzes entstehen, liegen darin, dass eine weitere Programmiersprache eingebunden werden muss und nicht jeder Entwickler von Java-Enterprise-Anwendungen zwangsläufig mit deren Syntax und Wirkungsweise vertraut ist. Die im Rahmen der Diplomarbeit erstellten Cartridges, die im Abschnitt 5.5 ab S. 88 beschrieben werden, verwenden hauptsächlich Vererbung und AOP zur Kombination der manuellen und generierten Artefakte. Geschützte Bereiche kommen aufgrund der zuvor genannten Nachteile nicht zum Einsatz. Verständlichen Code generieren Der Code, den eine Software-Factory-Cartridge generiert, sollte verständlich und aussagekräftig sein. Auch wenn der Java-EE-Entwickler den Code nicht verändert, ist es oftmals nötig, dass er sich mit diesem auseinandersetzen muss. Vor allem dann, wenn der Programmcode getestet und debuggt wird. Bei der Generierung wird eine gute Les- 85

98 5 Die Software Factory 5.4 Cartridges // com. example /src - gen / com / example / entities / Car. java package com. example. entities ; public class Car { private int kw; // com. example /src - once / com / example / entities / impl / CarImpl.aj package com. example. entities. impl ; import com. example. entities. Car ; } // Konstruktoren, Getter / Setter... // Operation public int getps () { throw new UnsupportedOperationException ( " Method Car. getps () has no implementation."); } Listing 5.13: Generierte Basisklasse public aspect CarImpl { int around ( Car obj ) : this ( obj ) && args () && execution ( public int Car. getps ()) { // Implementierung der Operation... } Listing 5.14: Manuell erstellter Implementierungsaspekt barkeit des Codes erreicht, wenn Formatierungsregeln, wie zum Beispiel Einrückungen, beachtet werden. Dazu können die Generierungstemplates entsprechend gestaltet werden, was allerdings wiederum zu einer schlechteren Lesbarkeit der Templates führt. Besser ist es, die Templates ansprechend und verständlich zu strukturieren und die Artefakte unformatiert zu generieren. Im Anschluss sorgt ein Codeformatierer (Beautifier, Pretty Printer) für eine übersichtliche Formatierung der Zielartefakte. Ein weiteres Kriterium für die Lesbarkeit des erstellten Codes ist die Verwendung von Typ-Importen in Java. Statt an jeder Stelle den vollen qualifizierten Namen eines Typs zu schreiben, wird dieser durch eine import-anweisung bekannt gemacht. Damit wird der Code schlanker und übersichtlicher. In Listing 5.14 wird ein solcher Import beispielsweise für die Klasse Car angelegt. Da es sehr umständlich ist, die Imports zu generieren, und dies zu komplizierten Generierungstemplates führen würde, ist auch für diese Aufgabe der nachgelagerte Codeformatierer zuständig. Der Hybridlabs Beautifier [Hyb] kann derartige Importanweisungen automatisch generieren und den (Java-)Code unter Verwendung des Formatierungswerkzeuges Jalopy [Jal] formatieren. Er kommt daher auch in den exemplarischen Cartridges der Software Factory zum Einsatz. Verständliche und aussagekräftige Artefakte zu generieren, bedeutet nicht nur, eine ansprechende Formatierung zu erzeugen. Vielmehr sollen sie auch Informationen enthalten, die dem Anwendungsentwickler die Nutzung der Artefakte erleichtern. Dazu gehören 86

99 5 Die Software Factory 5.4 Cartridges Kommentare, die sich aus den Modellelementen ableiten lassen, der Zeitstempel der Generierung oder Informationen über die verwendete Cartridge. Modelle validieren Bevor eine Cartridge aus einem Modell Zielartefakte generiert, muss sichergestellt sein, dass das Modell gültig ist. Das heißt, es müssen die Zusicherungen erfüllt sein, die mit dem zugrundeliegenden Metamodell festgelegt sind (siehe z. B. die Zusicherungen des Domain-Metamodells auf S. 115). Eine Generierung aus einem ungültigen Modell erzeugt auch ungültige Artefakte und ist demnach überflüssig. Auch wenn die Zusicherungen bereits im grafischen Editor geprüft werden, ist es wichtig, dass dies auch noch einmal im Buildprozess geschieht. Wird dann ein ungültiges Modell erkannt, bricht der Build ab und es wird eine entsprechende Fehlermeldung ausgegeben. Es ist nicht nötig, dass jede Cartridge der Software Factory die Zusicherungen erneut prüft. Es bietet sich an, die Validierung in eine eigene Cartridge zu packen und diese als erste auszuführen. In diesem Schritt werden alle Zusicherungen geprüft, wobei ein ungültiges Modell zum Abbruch des Builds führt und keine weitere Cartridge ausgeführt wird. Alternativ können die Validierungen auch in den Cartridges als Vorstufe der Generierung durchgeführt werden. Dabei werden aber jeweils nur die Gültigkeitsregeln geprüft, die für einen fehlerfreien Ablauf der Cartridge erforderlich sind. Beispielsweise muss eine Cartridge, die JPA-Persistenzannotationen generiert, nicht prüfen, ob die Beziehungen zwischen Services stimmig sind. Generell empfiehlt es sich jedoch, dem Cartridge-Entwickler die Validierungspflicht abzunehmen und, wie zuvor genannt, die Zusicherungen in einer vorgeschalteten Validierungscartridge zu überprüfen. Damit kann der Entwickler sicher sein, dass seiner Cartridge nur gültige Modelle zugeführt werden. Schnittstellen zweckmäßig konzipieren Im Abschnitt wurde bereits dargelegt, was bei der Konzeption der Cartridge- Schnittstellen zu beachten ist. Mit Verweis auf diesen Abschnitt sollen diese Hinweise hier nur noch einmal kurz zusammengefasst werden. Bei der Verwendung von Metamodell-Extensions als Schnittstelle ist zu beachten, dass 87

100 5 Die Software Factory 5.5 Exemplarische Cartridges die tatsächlichen Schnittstellen der Cartridge von der internen Implementierung abgegrenzt werden, um anzuzeigen, welche MM-Extensions für andere Cartridges zur Verfügung stehen und welche nicht öffentlich sind. Dafür ist der Cartridge-Entwickler verantwortlich, da es in oaw Xtend keine ausreichenden Ausdrucksmittel dafür gibt (siehe S. 76). Wenn aspektorientierte Programmierung auf Templateebene zum Einsatz kommen soll, so müssen die Templates der zu umschließenden Cartridge so feingranular in Templatedefinitionen gegliedert sein, dass eine Aspektcartridge genügend Join Points vorfindet, für die sie Aspekte definieren kann (siehe S. 78). Referenzmodell und -implementierung erstellen Eine Cartridge hat hauptsächlich zum Zweck, aus den in einer DSL modellierten Elementen Artefakte für eine konkrete Zielplattform zu erstellen. Welche genauen Zielartefakte dabei umgesetzt werden sollen und wie diese auszusehen haben, muss in einer geeigneten Form spezifiziert werden. Dafür bietet es sich an, eine Referenzimplementierung zu erstellen. Diese umfasst alle Artefakte, die die Cartridge später auch generieren können soll. Sie dient somit als Dokumentation darüber, was die Cartridge zu erstellen vermag. Danach beginnt der Cartridge-Entwickler, die Generierungstemplates zu erstellen, und zwar so, dass sich aus einem mit der DSL formulierten Referenzmodell die Referenzimplementierung ergibt. Damit ist sichergestellt, dass die Cartridge auch wirklich die Artefakte generiert, die sie laut Spezifikation generieren soll. Um dies zu testen, werden die tatsächlich generierten Artefakte mit denen der Referenzimplementierung verglichen. Diese Arbeit kann auch durch Unit-Tests unterstützt werden. Dabei werden die für die Referenzimplementierung erstellten (und für diese auch fehlerfrei durchlaufenden) Unit- Tests für die tatsächlich vom Generator erzeugte Implementierung durchgeführt [Haa06, S. 90]. 5.5 Exemplarische Cartridges Nachdem im vorigen Abschnitt das Konzept der Cartridges in die Software Factory eingeordnet und der Aufbau der Cartridges erläutert wurde, beschäftigt sich dieser Abschnitt 88

101 5 Die Software Factory 5.5 Exemplarische Cartridges mit den Cartridges, die im Rahmen dieser Diplomarbeit entstanden sind. Sie veranschaulichen die theoretischen Ausführungen durch ihre Anwendung in der erstellten Software Factory. Bevor sie im Einzelnen betrachtet werden, seien zuvor noch zwei Plugins erwähnt, die zwar keine Cartridge darstellen, jedoch von den erstellten Cartridges verwendet werden: Das Plugin com.saxsys.sf.dsl.domain.oaw enthält die in Check formulierten Validierungsregeln für Domain-Modelle, die in Tabelle A.1 auf Seite 115 verzeichnet sind. Diese werden im grafischen Editor (siehe Abschnitt 5.3.3, S. 69) und aus der POJO-Creator- Cartridge (siehe Abschnitt 5.5.2) heraus geprüft. Damit wird sichergestellt, dass die Ausführung von zeitaufwändigen Generatorläufen nur bei gültigen Modellen veranlasst wird. Des Weiteren sind im Plugin nützliche oaw-metamodell-extensions definiert, die die Arbeit mit dem Metamodell Domain in den oaw-sprachen erleichtert. Ein weiteres wichtiges Plugin ist com.saxsys.sf.gen.util. Es enthält allgemein nützliche, vom Domain-Modell unabhängige oaw-extensions und Workflowkomponenten. Die Beschreibungen der erstellten exemplarischen Cartridges legen dar, welchen Zweck die Cartridges erfüllen und welche Zieltechnologie sie umsetzen. Für den Nutzer ist vor allem wichtig zu wissen, wie die Informationen in den Quellmodellen in Zielartefakte abgebildet werden. Dagegen ist für den Cartridge-Entwicklung interessant, welche Abhängigkeiten zwischen den Cartridges bestehen und wie hoch der geschätzte Aufwand für die Realisierung der Cartridge ist Module Project Creator Der Module Project Creator (com.saxsys.sf.gen.module) ist eine Cartridge zur Erstellung von Projekten im Eclipse-Workspace. Für jedes Domain-Modul erzeugt er ein Java-Projekt 8, in das nachfolgende Cartridges ihre Artefakte speichern können. In dieses Projekt werden Unterverzeichnisse für manuelle und generierte Artefakte angelegt und in den Klassenpfad eingetragen. Darüber hinaus erhält das Java-Projekt alle Builders und Natures, die durch die installierten Cartridges über den Extension Point projectcontributions (siehe Abschnitt auf S. 72) festgelegt wurden. Zusätzlich erstellt der Module Project Creator ein weiteres Java-Projekt, welches alle Bibliotheken 8 Genauer gesagt erstellt die Cartridge ein AJDT-Projekt. Die AspectJ Development Tools (AJDT) [AJD] erweitern die JDT um Unterstützung für AspectJ [AJ]. 89

102 5 Die Software Factory 5.5 Exemplarische Cartridges aus Cartridges beinhaltet, die im Extension Point classpathcontributions (siehe Abschnitt auf S. 74) angegeben wurden. Das modulspezifische Java-Projekt erhält eine Projektabhängigkeit zu diesem gemeinsam genutzten Bibliotheken-Projekt. Bevor die Generierung ausgeführt wird, prüft die Cartridge die Zusicherungen für das Modul (Zeilen (6) und (15) in Tabelle A.1 auf S. 115) und bricht ab, wenn diese nicht erfüllt sind. Die von dieser Cartridge generierten Eclipse-Projekte werden auch nur dann generiert, wenn sie noch nicht vorhanden sind ( One-Shot-Generierung, vgl. Abschnitt auf S. 83), da anderenfalls bei jedem Cartridge-Durchlauf alle im Projekt befindlichen Dateien gelöscht würden. Der Nachteil hierbei ist, dass auch die zuvor genannten Abhängigkeiten zum Bibliotheken-Projekt nur einmal gesetzt werden, was insbesondere problematisch ist, wenn sich der Name dieses Projektes ändert und die Referenz bricht. Dieses Problem könnte durch eine entsprechende Refactoring-Unterstützung behoben werden. Abschnitt auf S. 111 geht darauf noch detaillierter ein. Beispiel Abbildung 5.14 zeigt den Eclipse-Workspace, nachdem die Cartridge ausgeführt worden ist. Für das Modul customer wurde ein Projekt angelegt. Das S im Icon weist darauf hin, dass das Projekt die SpringIDE-Nature erhalten hat. Dies wurde durch die Spring- Cartridge, die im Abschnitt vorgestellt wird, im Extension Point projectcontributions festgelegt. Des Weiteren ist zu sehen, dass in diesem Projekt Quellverzeichnisse für generierten und manuellen Code angelegt worden sind. Außerdem hat die Cartridge ein Bibliotheken-Projekt (.dependencies) erstellt, das alle Klassenbibliotheken enthält, die von anderen Cartridges mitgeliefert wurden. Aktueller Stand Der Module Project Creator erfüllt seinen Zweck der Erstellung von Projekten für die Domain-Module. Die Einbeziehung der Builders, Natures und Bibliotheken über die Extension Points classpathcontributions und projectcontributions funktioniert. Es bleibt jedoch noch unberücksichtigt, ob die Cartridges, die derartige Angaben machen, aktiviert sind oder nicht. 90

103 5 Die Software Factory 5.5 Exemplarische Cartridges Abbildung 5.14: Eclipse-Workspace nach Ausführung des Module Project Generators Aufwandsabschätzung Der Module Project Creator ist die aufwändigste der erstellten Beispielcartridges. Dies resultiert vor allem daraus, dass für die Erstellung von Eclipse-Projekten eine reine Artefaktgenerierung nicht ausreicht. So müssen die Projekte z. B. zusätzlich in den Workspace des Anwenders importiert und bei Änderungen aktualisiert werden. Dazu sind Workflowkomponenten zu implementieren, die mit den Eclipse APIs arbeiten. Der benötigte Aufwand für die Entwicklung des Module Project Creators wird auf 20 Personentage (PT) geschätzt. 91

104 5 Die Software Factory 5.5 Exemplarische Cartridges POJO Creator for Domain Objects Diese Cartridge (com.saxsys.sf.gen.entities.pojo) erzeugt Java-Klassen und AspectJ-Aspekte für die Elemente eines Domain-Modells. Die generierten Klassen sind gewöhnliche Java-Klassen (sogenannte Plain Old Java Objects, POJOs), d. h., sie besitzen keine Abhängigkeiten zu weiteren Klassenbibliotheken oder Frameworks. Zuerst prüft die Cartridge die Gültigkeit des Modells gemäß den Zusicherungen in Tabelle A.1 auf S Danach modifiziert sie das Modell. Dabei werden die Entitäten um ID-Attribute ergänzt, sofern noch keine vorhanden sind (vgl. Abschnitt zu Entitäten). Die Modelldatei wird mit den Änderungen gespeichert, damit diese auch für nachfolgend ausgeführte Cartridges sichtbar sind. Als nächstes führt die Cartridge die Generierung der Code-Artefakte aus den Domain-Elementen durch. Dabei kommen die Regeln in Tabelle 5.2 zur Anwendung. Modellelement Codeelement Hinweis 1 Entity Klasse 2 Attribute Feld mit Getter und Setter bei höherer Multiplizität (d. h. größer 1) als List 3 Reference Feld mit Getter und Setter bei höherere Multiplizität als List (wenn geordnet) oder als Set (wenn ungeordnet) 4 Operation Methode ohne Implementation 5 Entity Aspekt One-Shot 6 Operation Around-Advice für (4) Implementierung durch Entwickler 7 Service Interface 8 Operation Methode 9 Service abstrakte Klasse implementiert (7) 10 ServiceReference Feld mit Getter und Setter 11 Operation abstrakte Methode für (8) 12 Service Klasse erbt von (9), One-Shot 13 Operation Methode für (8/11) Implementierung durch Entwickler 14 Enum Enum 15 EnumLiteral Konstante Tabelle 5.2: POJO Creator: Mapping von Domain-Modell zu Java/AspectJ Die mit One-Shot annotierten Artefakte werden nur einmal generiert, da sie die Platzhalter für Implementierungen durch den Anwendungsentwickler darstellen. Um die Neu- generierung einer solchen Datei zu erzwingen, muss sie zuvor gelöscht werden. Zu beachten ist, dass die generierten und manuellen Artefakte in getrennte Verzeichnisstrukturen 92

105 5 Die Software Factory 5.5 Exemplarische Cartridges geschrieben werden (vgl. Abschnitt 5.4.3). Abhängigkeiten Der POJO Creator nutzt die Validierungsregeln, die im Plugin com.saxsys.sf.dsl. domain.oaw liegen, zur Gültigkeitsprüfung des Modells. Des Weiteren besteht eine Abhängigkeit zum Module Project Creator, da dort die Ausgabeverzeichnisse in einer Properties-Datei festlegt sind. Sie wird vom Workflow des POJO Creators eingebunden. Ferner werden oaw-extensions aus com.saxsys.sf.gen.util genutzt, u. a. Javaund Ecore-spezifische Hilfsmethoden. Aktueller Stand Die Cartridge ist in ihrer aktuellen Fassung einsetzbar und bedarf keiner weiteren Änderungen. Sie ist jedoch auf die Elemente des Domain-Metamodells festgelegt, d. h., sie generiert die POJOs speziell für Instanzen dieser Elemente. Für zukünftige Versionen wäre es zu überlegen, einen generischeren Ansatz zu verfolgen und beispielsweise die zugrundeliegenden Klassen des Ecore-Metamodells wie EClass und EAttribute (vgl. Abbildung 4.2 auf Seite 35) statt den Elementen Entity und Attribute als Eingabe für die Generierungstemplates zu verwenden. Somit wäre die Cartridge auch über das Metamodell Domain hinaus ohne größeren Anpassungsaufwand nutzbar. Im Zuge der Diplomarbeit wurde darauf verzichtet, da die generierten Codeartefakte teils sehr differieren, obwohl die Ausgangselemente gleichen Ursprungs sind. Zu sehen ist dies z. B. in Tabelle 5.2 für die Elemente Entity und Service, die beide von EClass erben, für die jedoch unterschiedliche Artefakte erzeugt werden. Aufwandsabschätzung Der POJO Creator ist umfangreicher als die nachfolgend erläuterten Cartridges, da er Java-Klassen für verschiedene Modellelemente generiert und darüber hinaus Modell-zu- Modell-Transformationen enthält. Die besondere Herausforderung bei der Entwicklung dieser Cartridge besteht darin, die Schnittstellen deutlich zu machen, da sie Ausgangspunkt für viele weitere Cartridges ist, die mit den von von ihr erstellten Artefakten 93

106 5 Die Software Factory 5.5 Exemplarische Cartridges arbeiten. Für die Realisierung des POJO Creators wurden etwa 16 Personentage aufgewendet JPA Annotation Creator Der JPA Annotation Creator (com.saxsys.sf.gen.persistence.jpa) generiert Artefakte für das Persistenzframework JPA [JPA06], welches Teil der EJB3-Spezifikation der Java Enterprise Edition 5 ist (vgl. Abschnitt 2.2, S. 6). Es stellt eine einheitliche Schnittstelle für die Verwendung von objektrelationalen Mappern (OR-Mapper) wie Hibernate [Hib] oder TopLink [Top] bereit, d. h., die Entscheidung für einen konkreten Mapper schlägt sich nicht im Code nieder, sondern wird allein durch Konfiguration des Frameworks bestimmt. Die Persistenzinformationen können durch Annotieren der Entity- Klassen [JPA06, Kap. 8-9] oder in XML-Mappingdateien [JPA06, Kap. 10] formuliert werden. Die Konfiguration des Frameworks wird jeweils für einen Persistenzkontext in einer persistence.xml vorgenommen. Der JPA Annotation Creator generiert für jedes Domain-Modul eine solche persistence.xml, welche die Mappingdateien auflistet, die für die im Modul enthaltenen Entitäten erstellt werden. Da der Cartridge nicht bekannt ist, welcher OR-Mapper letztendlich verwendet wird, kann sie diese Informationen nicht in die persistence.xml hineingenerieren. Der Anwendungsentwickler muss die Datei um diese Inhalte ergänzen, was auch der Grund ist, warum sie nur einmal ( One-Shot ) in das Verzeichnis für manuelle Artefakte generiert wird. Aber auch ein anderer Ansatz ließe sich umsetzen: Das Template für die persistence.xml definiert Erweiterungspunkte, die eine zusätzliche Cartridge (etwa ein Hibernate JPA Annotation Creator ) durch aspektorientierte Xpand-Statements um mapperspezifische Einstellungen ergänzen könnte (vgl. Abschnitt auf S. 77). So ließe sich auch die Beschränkung auf eine One-Shot-Generierung umgehen. Wie bereits angedeutet, erstellt der JPA Annotation Creator für jede Entität eine XML- Mappingdatei. Sie dient ebenfalls als Platzhalter für manuelle Eintragungen, die eigentlichen Mapping-Informationen erscheinen als Annotationen in der Entity-Klasse. Der Anwendungsentwickler hat jedoch die Möglichkeit, die Mappings anzupassen, indem er sie in der Mappingdatei spezifiziert. Diese Informationen überschreiben laut Spezifikation die in den Annotationen getroffenen Festlegungen [JPA06, S. 209ff]. Hieraus wird ersichtlich, welchen Nutzen die Cartridge bietet: automatische Generierung von Standard-Mapping- 94

107 5 Die Software Factory 5.5 Exemplarische Cartridges Informationen bei vollständiger Anpassbarkeit durch den Anwendungsentwickler. Die Annotationen werden vom JPA Annotation Creator in die vom POJO Creator erstellten Entity-Klassen (vgl. Tabelle 5.2 auf S. 92) hineingeneriert. Hierbei kommt AOP auf Templateebene zum Einsatz [Vö05, S. 6-9], d. h., die Cartridge definiert Around-Advices für die POJO-Templates und ruft zur Ausführungszeit den POJO Creator inklusive der eingewebten Around-Advices auf. Dies wird auch im Extension Point cartridge des JPA Annotation Creators ausgedrückt, indem das Feld advices die Cartridge-ID des POJO Creators enthält. Eine andere Möglichkeit wäre die Nutzung von AOP auf Codeebene, wie sie z. B. im DAO Generator zur Anwendung kommt (siehe nächster Abschnitt). Die Generierung der Annotationen aus dem Domain-Modell unterliegt den Regeln, die in Tabelle 5.3 zusammengefasst sind. Zu (6) und (7) ist anzumerken, dass Abfragen (Queries) nur dann als NamedQuery annotiert werden, wenn sie auch Abfrageattribute enthalten. Aus den Attributen wird die eigentliche Abfrage in der Java Persistence Query Language [JPA06, Kap. 4], einer SQL-ähnlichen Abfragesprache, erzeugt. Sind dagegen keine Attribute spezifiziert, so erstellt die Cartridge einen Platzhalter in der XML-Mapping- Datei. Der Anwendungsentwickler hat dann die Aufgabe, die Abfrage dort eigenhändig zu formulieren. Modellelement Codeelement Hinweise 1 an (1) in Tab an Getter von (2) in Tab. = wenn ID-Attribut GenerationType.AUTO) @ManyToOne, je nach 5 Parameter mappedby wenn Opposite festgelegt 6 an (1) in Tab. 5.2, nur wenn die Query Attribute enthält 7 QueryAttribute Parameter in Query Statement Tabelle 5.3: JPA Annotation Creator: Mapping von Domain-Modell zu Java/XML Abhängigkeiten Der JPA Annotation Creator benötigt die im Plugin des Module Project Creators festgelegten Ausgabeverzeichnisse. Darüber hinaus verwendet er oaw-extensions aus dem 95

108 5 Die Software Factory 5.5 Exemplarische Cartridges POJO Creator, in denen vor allem die Regeln für Namen und Bezeichner der vom PO- JO Creator erstellten Artefakte definiert sind. Ohne diese Informationen könnte der JPA Annotation Generator z. B. keine Mappingdateien erstellen, denn es fehlte das Wissen, wie die Entity-Klassen heißen (vgl. Abschnitt auf Seite 75). Der JPA Annotation Creator nutzt außerdem noch oaw-extensions aus dem Plugin com.saxsys.sf.gen. util. Aktueller Stand Die Cartridge liegt in einer Version vor, die ohne Weiteres für die Generierung der JPAspezifischen Persistenzinformationen verwendet werden kann. Jedoch ist zu beachten, dass es sich hier um eine Aspektcartridge handelt, die den im vorigen Abschnitt beschriebenen POJO Creator umschließt. Eine weitere Cartridge mit diesem Merkmal im gleichen Projekt zu verwenden, ist momentan nicht möglich (siehe Abschnitt auf S. 79). Aufwandsabschätzung Der JPA Annotation Creator ist weniger umfangreich als der zuvor beschriebene POJO Creator. Es sind etwa 7 Personentage für die Planung und Umsetzung erforderlich Data Access Object Generator Eine weitere im Zuge der Diplomarbeit realisierte Cartridge ist der Data Access Object Generator (com.saxsys.sf.gen.entities.dao). DAO ist ein Muster aus den J2EE Core Patterns [ACM03], das die Persistenzimplementation vom Rest der Anwendung entkoppelt. Es übernimmt damit die Rolle eines Repositories (vgl. Abschnitt auf S. 8). Der Zugriff auf persistente Objekte erfolgt dabei über einheitliche Datenzugriffsschnittstellen, die für den jeweiligen Persistenzmechanismus ausimplementiert werden müssen. Die Cartridge erstellt diese Schnittstellen für alle Entitäten des Domain-Moduls und macht sie für die Service-Klassen zugänglich. Tabelle 5.4 stellt die Abbildung von Domain-Elementen auf DAO-spezifische Code-Artefakte dar. Die in (1) erwähnten CRUD- Methoden sind die grundlegenden Persistenzoperationen Create, Read, Update, Delete. 96

109 5 Die Software Factory 5.5 Exemplarische Cartridges Besonders beachtenswert ist der AspectJ-Aspekt, der für einen Service generiert wird (4). Er definiert sogenannte Inter-Type-Deklarationen, d. h. Erweiterungen von Java-Klassen und -Interfaces um Felder und Methoden. Diese werden zur Übersetzungszeit durch den AspectJ-Compiler in den Java-Bytecode eingewebt. In (5) wird das Service-Interface um Zugriffsmethoden für die verwendeten DAOs erweitert; in (6) geschieht dasselbe für die abstrakte Service-Klasse, ergänzt um ein privates Feld. Die Cartridge macht sich hiermit die aspektorientierte Programmierung auf Codeebene zunutze. Eine andere Möglichkeit wäre die Anwendung von AOP in den Generatortemplates, wie es im JPA Annotation Creator der Fall ist. Gegenwärtig besteht jedoch das Problem, dass eine Cartridge hier der POJO Creator effektiv nur von einer Cartridge umschlossen werden kann, wie im Abschnitt auf Seite 79 erläutert wurde. Modellelement Codeelement Hinweise 1 Entity DAO-Interface mit CRUD-Methoden 2 Query Methode 3 QueryAttribute Parameter 4 Service Aspekt 5 ManagedDependency Getter und Setter auf (1) für (7) in Tabelle ManagedDependency Feld mit Getter und Setter auf (1) für (9) in Tabelle 5.2 Tabelle 5.4: DAO Generator: Mapping von Domain-Modell zu Java/AspectJ Abhängigkeiten Der DAO Generator schreibt in die Ausgabeverzeichnisse, die im Module Project Creator Plugin festgelegt sind. Zusätzlich benötigt er die Informationen über Namen und Bezeichner der vom POJO Creator erstellten Artefakte (vgl. die Ausführungen in Abschnitt auf S. 95). Der DAO Generator nutzt überdies noch oaw-extensions aus dem Plugin com.saxsys.sf.gen.util. Aktueller Stand Die Cartridge ist voll funktionsfähig. Im Hinblick auf die zukünftige Erweiterung der Spring-Cartridge, die in Abschnitt beschrieben wird, sollte auch über eine Modifikation des DAO Generators nachgedacht werden. Zur Verwirklichung einer generischeren Spring-Cartridge, die nicht auf eine DAO-Cartridge angewiesen ist, wäre fol- 97

110 5 Die Software Factory 5.5 Exemplarische Cartridges gendes denkbar: Anstatt der direkten Codegenerierung führt der DAO Generator M2M- Transformationen durch. Dabei wird aus den Informationen einer Managed Dependency ein Service erstellt, in das Domain-Modell eingefügt und als DAO markiert (vgl. [Vö06, S ]). Dies könnte über die Verwendung von Namenskonventionen oder über ein für diesen Zweck angepasstes Domain-Metamodell geschehen. Die Spring-Cartridge kann dann Services und DAOs verdrahten, ohne zu wissen, dass es sich tatsächlich um DAOs handelt. Ebenso kann der POJO Generator die DAO-Referenzen in den Services über die Servicereferenz-Beziehung setzen (siehe (10) in Tabelle 5.2 auf S. 92). Aufwandsabschätzung Der Aufwand für die Erstellung des DAO Generators in seiner aktuellen Version wird auf 5 Personentage geschätzt. Wie oben beschrieben, muss sich der Cartridge-Entwickler vor allem damit auseinandersetzen, wie die DAO-Klassen mit den Services verbunden werden können JPA Data Access Object Generator Während der DAO Generator eine einheitliche Schnittstelle zwischen Anwendung und Persistenzimplementierung schafft, ist der JPA DAO Generator (com.saxsys.sf.gen. persistence.jpa.dao) für die Erstellung einer Implementation dieser Schnittstelle verantwortlich. Zieltechnologie ist hier das OR-Mapping-Framework JPA, das seinerseits eine Schnittstelle für verschiedene OR-Mapper darstellt 9. JPA wurde bereits im Abschnitt zum JPA Annotation Creator beschrieben. Die generierten JPA-DAO- Klassen implementieren die vom DAO Generator erstellten DAO-Interfaces. Die Implementierung ist unproblematisch: Die CRUD-Methoden (vgl. (1) in Tabelle 5.4) und Abfragemethoden (vgl. (2) in Tabelle 5.4) leiten den Aufruf an Methoden aus dem Java Persistence API weiter. Bei der Nutzung der Abfragemethoden ist darauf zu achten, dass die Benannten Abfragen auch tatsächlich formuliert sind sei es automatisch durch den JPA Annotation Creator oder manuell durch den Entwickler. 9 Adam Bien regt die Diskussion an, ob mit Erscheinen der Java Persistence API das DAO-Muster überflüssig geworden ist [Bie07]. 98

111 5 Die Software Factory 5.5 Exemplarische Cartridges Abhängigkeiten Auch diese Cartridge nutzt die Ausgabeverzeichnisse des Project Module Creators, die Namensinformationen des POJO Creators und nützliche Erweiterungen aus dem Util- Plugin. Zudem sind die Namensregeln für die vom DAO Generator erstellten DAO- Schnittstellen erforderlich. Aktueller Stand Die Cartridge in der aktuellen Version generiert die JPA-DAO-Implementierungsklassen ohne Probleme und benötigt keine weitere Bearbeitung. Aufwandsabschätzung Der benötigte Aufwand für die Erstellung des JPA DAO Generators hält sich mit zirka 4 Personentagen im Rahmen. Hier sind lediglich die vom DAO Generator erstellten Persistenzmethoden an das JPA-Framework weiterzuleiten Spring 2.0 Service Beans Generator Diese Cartridge erstellt Artefakte für das Spring-Framework [Spra]. Spring ermöglicht die Komposition von Komponenten einer Java-Anwendungen über Konfigurationsdateien. Objekte müssen ihre Abhängigkeiten zu anderen Objekten nicht selbst verwalten, sondern werden von außen konfiguriert (verdrahtet). Dieses Prinzip wird als Inversion of Control (IoC) oder Dependency Injection (DI) bezeichnet [Fow04]. Der Vorteil bei dieser Herangehensweise ist, dass die Abhängigkeiten nicht schon zur Übersetzungszeit gesetzt werden müssen. Darüber hinaus können sie bequem ausgetauscht werden, ohne Quellcode ändern zu müssen. Im Spring 2.0 Service Beans Generator wird dies ausgenutzt, um einerseits die Services miteinander zu verdrahten und andererseits die Services mit der zugrundeliegenden DAO-Implementierung, also den vom JPA DAO Generator erstellten Data Access Objects, zu konfigurieren. Dazu werden zwei Konfigurationsdateien generiert, in denen 99

112 5 Die Software Factory 5.5 Exemplarische Cartridges die Objekte (Beans) eingerichtet werden. In der Datei spring-dao.xml werden die JPA- DAOs als zu verwendende DAO-Implementierung eingestellt, während die Datei springservices.xml die Verdrahtung der Services mit ihren Service- und DAO-Referenzen regelt. Tabelle 5.5 zeigt, nach welchem Muster die Spring-Artefakte aus dem Domain- Modell generiert werden. Modellelement Spring-Artefakt Hinweise 1 Service 2 ManagedDependency Bean in spring-dao.xml 3 Service Bean in spring-services.xml 4 ServiceReference Property 5 ManagedDependency Property auf (2) Tabelle 5.5: Spring Beans Generator: Mapping von Services zu Spring Beispiel Das Domain-Modell in Abbildung 5.15 definiert eine Entität Customer, einen Service CustomerService, der diese Entität nutzt, und einen Service SalesService, der auf die Dienste des CustomerService angewiesen ist. Der Spring 2.0 Service Beans Generator erzeugt aus diesem Modell eine spring-dao.xml, in der das DAO für die Kunden-Entität konfiguriert wird (Listing 5.15), und eine spring-services.xml. In dieser werden die Services verdrahtet, und die Referenz vom CustomerService zum CustomerDao hergestellt (Listing 5.16). Abbildung 5.15: Das Ausgangsmodell 100

113 5 Die Software Factory 5.5 Exemplarische Cartridges <? xml version =" 1.0 " encoding ="UTF -8" standalone ="no"?> <beans... > <bean class =" com. example. app. foo. dao. impl. CustomerDaoJpa " id=" customerdao "> </ bean > </ beans > Listing 5.15: Aus dem Modell generierte spring-dao.xml <? xml version =" 1.0 " encoding ="UTF -8" standalone ="no"?> <beans... > <bean class =" com. example. app. foo. services. impl. CustomerServiceImpl " id=" customerservice " > < property name =" customerdao " ref =" customerdao "/ > </ bean > <bean class =" com. example. app. foo. services. impl. SalesServiceImpl " id=" salesservice " > < property name =" customerservice " ref =" customerservice "/ > </ bean > </ beans > Listing 5.16: Aus dem Modell generierte spring-services.xml Abhängigkeiten Die Cartridge greift auf oaw-extensions in den POJO- und DAO-Cartridges zu, um Informationen über die von diesen Cartridges erstellten Codeelemente zu erhalten. Aktueller Stand Der Spring 2.0 Service Beans Generator liegt in einer ersten Version vor, die direkt auf die Verwendung mit den DAO-Cartridges zugeschnitten ist. Eine Weiterentwicklung der Cartridge sollte die Abhängigkeiten vermindern und einen generischeren Verdrahtungsmechanismus anbieten. Dafür wird es nötig sein, Tracing-Modelle und M2M- Transformationen einzubeziehen. Des Weiteren könnte außer der reinen Verdrahtung durch Dependency Injection weitere Spring-Funktionalität angeboten werden, so z. B. die Transaktionssteuerung von Services. 101

114 5 Die Software Factory 5.6 Kern- und GUI-Komponente Aufwandsabschätzung Für die Erstellung der Cartridge wurden 3 Personentage aufgewendet. Die Weiterentwicklung, besonders im Hinblick auf die Abkopplung von den DAO-Cartridges und die Einführung von M2M-Transformationen wird voraussichtlich mindestens 2 weitere Personenwochen in Anspruch nehmen. 5.6 Kern- und GUI-Komponente Nachdem das Domänenmodell und die erstellten Cartridges erläutert wurden, sollen im Folgenden die Kern- und die GUI-Komponente der Software Factory beschrieben werden. Auch hier soll die für die Entwicklung der Komponenten aufgewendete Zeit abgeschätzt werden, um damit einen Anhaltspunkt für die Planung weiterer Entwicklungsschritte zu erhalten Der Kern Wie in Abschnitt bereits erwähnt wurde, wirkt die Kern-Komponente als Steuerungskomponente (Engine) für den Buildprozess. Das bedeutet, sie ist dafür verantwortlich, dass die Cartridges der Software Factory auf die Domain-Modelle angewendet und somit die Zielartefakte erstellt werden 10. Dazu führt sie alle über den Extension Point com.saxsys.sf.core.cartridge (siehe Abbildung 5.9 auf S. 73) registrierten und aktivierten Cartridges in der vom Nutzer angegebenen Reihenfolge (siehe GUI-Komponente) für ein Domain-Modell aus. Der Buildvorgang kann für eine Domainmodell-Datei über die Benutzeroberfläche ausgelöst werden. Der Software-Factory-Kern stellt jedoch auch einen inkrementellen Builder zur Verfügung (siehe [SDF + 03, S. 414]). Dieser startet den Erstellprozess für alle seit dem letzten Build geänderten Domainmodell-Dateien. Der oben genannte Extension Point cartridge ist im Kern-Plugin der Software Factory definiert. Ebenso sind die Extension Points projectcontributions und classpathcontributions (Abbildungen 5.11 u auf S. 74) Bestandteil dieser Komponente. 10 Dies ist nicht zu verwechseln mit dem anschließenden Buildprozess für die erstellten Artefakte (z. B. die Kompilierung des generierten Javacodes), für den (bislang) der Anwendungsentwickler Sorge trägt. 102

115 5 Die Software Factory 5.6 Kern- und GUI-Komponente Aufwandsabschätzung In die Konzeption und Umsetzung des Kerns ist ein beachtlicher Teil des gesamten für die Software Factory benötigten Aufwandes zu investieren. Dies ist vor allem dadurch begründet, dass der Kern die Schnittstelle bereitstellt, über die sich Cartridges in der Software Factory registrieren. Diese Schnittstelle muss gut durchdacht sein und die besonderen Anforderungen wie z. B. die einfache Austauschbarkeit der Cartridges berücksichtigen. Der Entwurf und die Realisierung der Schnittstelle über Eclipse Extension Points nimmt etwa 11 Personentage in Anspruch. Weitere 13 PT fallen für die Entwicklung der Engine an. Diese muss einen reibungslosen Ablauf des Buildprozess ermöglichen, bei dem die registrierten Cartridges nacheinander ausgeführt werden. Für die Umsetzung des inkrementellen Builders sind etwa 4 Personentage einzurechnen, sodass für die gesamte Kernkomponente ein geschätzter Aufwand von 28 PT anfällt Die GUI-Komponente Die Integration der Software Factory in die Entwicklungsumgebung Eclipse wird durch die GUI-Komponente realisiert. Sie definiert einen neuen Projekttyp (Nature) für Software- Factory-Projekte und einen Assistenten (Wizard), mit dem ein solches Projekt vom Anwendungsentwickler angelegt werden kann. Ein Software-Factory-Projekt stellt den Ausgangspunkt für eine Java-Enterprise-Anwendung dar. Darin werden die Modelldateien gespeichert, aus denen die Cartridges die Zielartefakte erzeugen. Im Unterschied zu den generierten Eclipse-Projekten für Domain-Module (siehe Abschnitt auf S. 89) ist ein Software-Factory-Projekt ein Quellprojekt, d. h. ein Container für Quellartefakte. Wie eingangs erwähnt, kann der Build automatisch durch den inkrementellen Builder oder manuell ausgelöst werden. Die manuelle Variante wird durch die GUI-Komponente umgesetzt, indem sie im Kontextmenü für Domainmodell-Dateien einen entsprechenden Menüeintrag bereitstellt. Durch Klick auf diesen Eintrag wird die Steuerungskomponente beauftragt, den Buildprozess für die selektierte Datei zu starten. Die GUI-Komponente bietet überdies die Möglichkeit, die Software Factory zu konfigurieren. Zu diesem Zweck enthält sie einen Einstellungen-Dialog, in dem der Anwendungsentwickler die für sein Projekt benötigten Cartridges aktivieren kann. 103

116 5 Die Software Factory 5.7 Installation und Bedienung Aufwandsabschätzung Um die Einbettung der Software Factory in die IDE Eclipse zu realisieren, werden ausreichende Kenntnisse der GUI-Programmierung mit den Eclipse-APIs und den zugrunde liegenden GUI-Frameworks benötigt. Überdies ist es dank der Pluginarchitektur der Eclipse-Plattform in vielen Fällen auch möglich, die Benutzeroberfläche über Extension Points zu erweitern. Dadurch hält sich der Implementierungsaufwand in Grenzen. Für die Entwicklung der Nature und des Assistenten für Software-Factory-Projekte sind zirka 6 Personentage erforderlich. Weitere 7 PT werden für die Menüerweiterung veranschlagt, durch die der Build für eine Domainmodell-Datei manuell in Gang gebracht wird. Etwas aufwändiger ist die Implementierung des Einstellungen-Dialoges. Hier sind etwa 11 PT erforderlich, sodass für die gesamte GUI-Komponente ein Zeitaufwand von 25 Personentagen abzuschätzen ist. 5.7 Installation und Bedienung Nachdem das Domänenmodell und die erstellten Cartridges erläutert wurden, soll im Folgenden die Benutzung der Software Factory beschrieben werden Installation Die Installation der Software Factory ist wahlweise durch einfaches Kopieren der Plugins in das Pluginverzeichnis der Eclipse-Installation oder durch Verwendung des Eclipse Update Managers möglich. Der Update Manager bietet den Vorteil, dass erforderliche Plugins wie EMF und GMF gleich mit installiert werden können. Außerdem lassen sich die Software Factory Features (Tabelle 5.6) separat installieren, aktualisieren und deinstallieren. Die Installation neu erstellter Cartridges funktioniert analog. 104

117 5 Die Software Factory 5.7 Installation und Bedienung Feature Beschreibung 1 Core Feature Kernimplementierung und Benutzeroberfläche 2 Domain Model Feature Domain-Metamodell 3 Graphical Domain Model Feature Grafische Repräsentation des Domain-Modells 4 Default Cartridges Feature Exemplarische Cartridges Tabelle 5.6: Software Factory Eclipse Features Bedienung Um eine Java-Enterpise-Anwendung mit Hilfe der Software Factory in Eclipse zu erstellen, muss im Workspace über den entsprechenden Wizard ein Software Factory Project angelegt werden. Es enthält ein Unterverzeichnis model, das als Speicherort für die Domain-Modelle dient. Es ist wichtig, dass die Modelle dort abgelegt werden, da sie nur dann in den Buildprozess integriert werden. Für das Anlegen eines Domain-Modells sind zwei Wizards vorhanden: Zum einen für das eigentliche Modell und zum anderen für die grafische Repräsentation dessen, wobei im zweiten Fall auch das Modell erstellt wird. Das Verarbeiten des Modells durch die Cartridges, der sogenannte Build, wird entweder manuell durch Selektion des entsprechenden Eintrags im Kontextmenü der Modelldatei oder automatisch durch den inkrementellen Builder angestoßen (vgl. Abschnitt auf S. 102). Dieser wird immer dann aktiv, wenn sich die Modelldatei ändert. Voraussetzung dafür ist, dass für das Projekt die Option Automatischer Build angewählt ist. Wird hingegen der Build für das Projekt manuell über die Benutzeroberfläche ausgelöst, so werden dabei alle seit dem letzten Build veränderten Modelldateien einbezogen. Welche Cartridges beim Build angewandt werden, ist in den Software-Factory-Einstellungen festgelegt, die für den gesamten Workspace, aber auch projektspezifisch vereinbart werden können (vgl. Abschnitt auf S. 103). Abbildung 5.16 zeigt diesen Einstellungen- Dialog. Die Cartridges lassen sich einzeln an- und abwählen. Die letzte Spalte gibt Informationen darüber, welche Cartridges Aspektcartridges sind ( ) und welche durch Aspektcartridges umschlossen sind ( ). Dies ist einerseits nützlich, um solche umschlossenene Cartridges abzuwählen, damit sie nicht zweimal ausgeführt werden. Andererseits wird durch die Übersicht deutlich, wenn zwei Aspektcartridges die gleiche Cartridge umschließen. Der Nutzer muss sich dann für eine dieser Aspektcartridges entscheiden (siehe Abschnitt auf S. 79). 105

118 5 Die Software Factory 5.7 Installation und Bedienung Abbildung 5.16: Software-Factory-Einstellungen 106

119 6 Zusammenfassung und Ausblick 6.1 Zusammenfassung In der vorliegenden Arbeit wurde eine Software Factory für Java-Enterprise-Anwendungen konzipiert und entwickelt. Diese ermöglicht es, Unternehmensanwendungen schneller, qualitativer und kostengünstiger zu entwickeln. Dem Entwickler wird hier ein Werkzeug bereitgestellt, mit dem er die fachlichen Inhalte der Anwendung unabhängig von der Zieltechnologie modellieren und daraus anschließend automatisiert technologiespezifische Artefakte generieren lassen kann. Als Grundlage dafür wurde eine Betrachtung der Java-Enterprise-Plattform vorgenommen, mit dem Ziel Muster zu identifizieren, die von der Architektur von Java-EE- Anwendungen abstrahieren und sich daher als Basiselemente für eine entsprechende Modellierungssprache eignen. Im Anschluss wurden die theoretischen Grundlagen und aktuelle Ausprägungen der Modellgetriebenen Softwareentwicklung erläutert. Dabei wurde auch auf das Prinzip der Metamodellierung eingegangen und aufgezeigt, auf welche Weise diese zur Erstellung einer domänenspezifischen Sprache verwendet werden kann. Im Weiteren wurden aktuelle Technologien und Werkzeuge im Bereich der Modellgetriebenen Softwareentwicklung betrachtet, wobei sich der Blickpunkt vornehmlich auf die Technologien richtete, die für die Implementierung einer Eclipse-basierten Software Factory infrage kommen. Aufbauend auf den theoretischen Grundlagen und der Untersuchung der technologischen Möglichkeiten wurde anschließend die Software Factory für Java-Enterprise-Anwendungen erstellt. Dafür wurde ein Grundkonzept erarbeitet und softwaretechnisch umgesetzt. Mit der Implementierung exemplarischer Cartridges für ausgewählte Zieltechnologien konnte der Nachweis für die praktische Verwendbarkeit der Software Factory erbracht werden. Die Software Factory liegt in einer Version vor, die unter Beachtung einiger Einschrän- 107

120 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten kungen produktiv verwendet werden kann. Der nachfolgende Abschnitt dokumentiert die derzeitig noch vorhandenen Defizite und leitet daraus mögliche Aufgaben für weitere Arbeiten ab. Die Software Factory lässt sich problemlos für neue Java-Enterprise-Projekte einsetzen, sie kann aber auch bei Projekten zum Einsatz kommen, die sich bereits in der Entwicklungsphase befinden. Vorausgesetzt, in diesen Projekten werden bereits Modelle verwendet (wenn auch nicht im Sinne der MDSD), so kann die Software Factory integriert werden, indem ein M2M-Transformator entwickelt wird, der aus den Ausgangsmodellen (meist UML-Klassendiagramme) Domain-Modelle erstellt. Der Einsatz in einem solchen Projekt ist auch empfehlenswert, um die Software Factory anhand realer Daten zu testen und konzeptionelle sowie implementationstechnische Unzulänglichkeiten zu entdecken. 6.2 Zukünftige Arbeiten Abschließend soll diskutiert werden, wie die Software Factory für Java-Enterprise-Anwendungen in zukünftigen Arbeiten weiterentwickelt werden könnte. Dabei sollen auch Anregungen für zweckmäßige Änderungen auf konzeptioneller Ebene unterbreitet werden Erweiterung der DSL Domain Die domänenspezifische Sprache Domain wurde im Rahmen dieser Diplomarbeit so weit entwickelt, dass sie die grundlegenden Muster zur Modellierung der Architektur einer Java-Enterprise-Anwendung bereitstellt. Sie sollte weiter ausgebaut und vor allem um Werteobjekte und Aggregate ergänzt werden (siehe Abschnitt 2.3). Ferner sollte untersucht werden, ob auch die Möglichkeit der Modellierung von Zusicherungen angeboten werden kann. So könnte der Anwendungsentwickler beispielsweise eine Entität Person mit dem Attribut age : int anlegen und den Wertebereich dieses Attributes mit der Zusicherung age > 0 and age < 120 eingrenzen. Zusicherungen werden in Ecore bereits verwendet und über Modellannotationen festgelegt [Dam07]. Interessant wäre, wie dies im grafischen GMF-Editor abgebildet werden könnte, um dem Java-EE-Entwickler ein einfaches Instrument zur Constraintformulierung bereitzustellen 1. 1 Es sollte dem Anwendungsentwickler erspart bleiben, im EMF-Baumeditor händisch Annotationen hinzufügen zu müssen. 108

121 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten Ein ähnlich gelagertes Problem sind die Operationen in Entitäten und Services. Sie können bislang nicht im GMF-Editor vollständig spezifiziert werden, da es keine grafische Darstellung für die Parameter gibt. Diese müssen daher im Baumeditor des EMF-Modells festgelegt werden. Es ist zu überlegen, wie die Parameter auch im grafischen Editor modelliert werden könnten, beispielsweise über eine Art In-Place-Editor, der einen gesamten Methodenrumpf parst und in ein Operationen-Element umwandelt Entwicklung weiterer Cartridges Die im Zuge der Diplomarbeit erstellte Software Factory enthält einige Cartridges für ausgewählte Zieltechnologien. Diese sollten weiterentwickelt und um Cartridges für andere Zieltechnologien ergänzt werden. In Bezug auf die schon vorhandenen Cartridges ist zu untersuchen, ob diese modularer gestaltet werden können. So ist es denkbar, dass eine allgemeinere POJO-Cartridge Templates für die Erstellung von Javaklassen aus Modellelementen bereitstellt, und diese von untergeordneten Cartridges wie dem POJO Creator for Domain Objects (vgl. Abschnitt auf S. 92) oder dem DAO Generator (vgl. Abschnitt auf S. 96) benutzt und erweitert werden. Gleichermaßen sollte der Spring Beans Generator aufgeteilt werden, sodass die reine Beanerstellung und -verdrahtung in einer übergeordneten Spring-Cartridge vorgenommen wird und weitere Spring-Funktionalität in spezialisierteren Cartridges enthalten ist (siehe auch die Hinweise zum aktuellen Stand des Spring Beans Generators auf S. 101). Weitere Cartridges sollten nicht nur entwickelt werden, um andere Zieltechnologien abzudecken. Auch andere Artefakte lassen sich aus den Domain-Modellen generieren, so z. B. Tests, Buildskripte oder Dokumentation. Ein wichtiger Aspekt von Java-Enterprise- Anwendungen, der bisher außer Acht gelassen wurde die Präsentationsschicht sollte in die Software Factory integriert werden. Dafür wird es nötig sein, eine weitere DSL zu entwerfen, die entsprechende Ausdrucksmittel bereitstellt. Alternativ ist es auch vorstellbar, bereits vorhandene Editoren für GUIs und Page Flows wie Spring Webflow [Sprc] zu integrieren. Als Zieltechnologie bieten sich Frameworks wie JSF [JSF06] oder Spring MVC 3 [Spra] an. 2 Die GMF-Entwickler arbeiten ihrerseits an einer Lösung für dieses Problem [Sha07]. Bislang wurde jedoch noch keine entsprechend aktualisierte Version veröffentlicht. 3 Model View Controller 109

122 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten Konzeptionelle Überlegungen Lösung des Template-AOP-Problems Es ist möglich, die Templates in einer Cartridge nicht-invasiv zu erweitern, indem die Cartridge von einer Aspektcartridge umschlossen wird (siehe Abschnitt auf S. 77). Das Problem bei diesem Mechanismus ist, dass er effektiv das Umschließen einer Cartridge durch nur eine Aspektcartridge gestattet (siehe S. 79). Im Rahmen weiterer Arbeiten sollte eine Lösung für dieses Problem gefunden werden. Konfigurierbare Cartridges Das Cartridgekonzept der Software Factory sieht bislang keine Möglichkeit vor, Cartridges für den Gebrauch in einem Java-Enterprise-Projekt zu konfigurieren. Für zukünftige Versionen wäre dies wünschenswert, um die Cartridges an die konkreten Rahmenbedingungen des Projektes anpassen zu können. Solche Rahmenbedingungen könnten z. B. vorgeben, wie die Ausgabeverzeichnisse heißen, in die die Codedateien generiert werden oder welche Namenskonventionen für Javaklassen und -schnittstellen gelten. Diese Informationen sind bisher in den Cartridges hartcodiert. Es ist zu untersuchen, ob die Cartridgekonfiguration durch den Anwendungsentwickler möglich ist, beispielsweise über die Benutzeroberfläche. Hier könnten sich Properties-Dateien als mögliches Medium zum Speichern der Einstellungen eignen (vgl. Abschnitt zu Properties als Cartridge-Schnittstelle auf S. 80). Tracing-Modelle und M2M-Transformationen Die Cartridges generieren in der Regel Artefakte, die mit den Artefakten anderer Cartridges in Beziehung stehen. Dafür müssen sie jedoch über Informationen zu diesen Artefakten, wie etwa Namen und Bezeichner, verfügen. In Abschnitt auf S. 76 wurden bereits die Nachteile der Verwendung von Metamodell-Extensions für diesen Zweck diskutiert. Wesentlich hilfreicher sind sogenannte Tracing-Modelle, in denen der Generierungsprozess aufgezeichnet wird. Das heißt, in ihnen wird festgehalten, aus welchen Modellelementen welche Zielartefakte generiert wurden. Diese Informationen dienen dann 110

123 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten den nachfolgenden Cartridges, um weitere darauf aufbauende Artefakte zu erzeugen [VG07, Abschn. 2.4]. Die Nutzung solcher Tracing-Modelle hilft auch, die Abhängigkeiten zwischen Cartridges zu verringern, da ein Tracing-Modell eine Vielzahl von MM- Extensions als Cartridge-Schnittstelle ersetzen kann. Das in der Software Factory verwendete MDSD-Framework oaw bietet mittlerweile Unterstützung für Tracing-Modelle [VG07], allerdings werden dazu in der Dokumentation keine Angaben gemacht. In jedem Fall ist es für die Erstellung eines Tracing-Modells nötig, Informationen über Zielartefakte modellieren zu können. Hier lohnt es sich zu schauen, ob derartige Metamodelle bereits existieren (wie z. B. das Java-Metamodell Java EMF Model (JEM) [VE]), und inwiefern sie sich für die Beschreibung der Zielartefakte eignen 4. Sind die Zielartefakte erst einmal modellierbar, so ist auch zu analysieren, ob statt direkter Codegenerierung aus dem Quellmodell als Zwischenschritt eine M2M-Transformation vom Quellmodell zum Zielmodell sinnvoll ist. So bleiben die Informationen möglichst lang auf Modellebene und werden erst in einer abschließenden M2T-Transformation in die Zielartefakte umgesetzt. Refactoring Bei der Verwendung der Software Factory kann es vorkommen, dass Referenzen zwischen Artefakten mit der Zeit brechen, d. h., sie zeigen auf ein Artefakt, das mittlerweile nicht mehr existiert oder umbenannt wurde. Dies gilt vor allem für Referenzen, die in manuellen oder einmalgenerierten Artefakten definiert sind. Diese Artefakte werden bei einem nachfolgenden Generierungslauf nicht verändert, sodass ihre Synchronität mit dem Modell nicht mehr gewährleistet ist. Dies wird in Abbildung 6.1 an einem Beispiel verdeutlicht. Um diesem Problem zu begegnen und damit auch zur Akzeptanz der Software Factory beizutragen, sollten Refactoring-Maßnahmen integriert werden, die dabei helfen, die Artefakte synchron zu halten. Solche Refactorings sind bereits aus zahlreichen Eclipse- Plugins bekannt, etwa das Umbenennen einer Javaklasse in JDT, das automatisch die Referenzen zu dieser Klasse aktualisiert. 4 Eine Vielzahl von Eclipse-Plugins im Bereich Java EE arbeitet bereits intern mit EMF-basierten Modellen, sodass ein Blick in die Pluginquellen oft erfolgversprechend ist. 111

124 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten (a) Das einmalgenerierte Artefakt A1 hält eine Referenz auf A2. (b) Das Modellelement M2 wurde verändert und heißt jetzt M2. Die Änderungen spiegeln sich auch im Artefakt A2 wider. Das Artefakt A2 existiert nicht mehr, die Referenz in A1 zeigt ins Leere. Abbildung 6.1: Ungültige Referenz bei einem einmalgenerierten Artefakt Featuremodelle Die variablen Eigenschaften der Produkte der Software Factory werden durch Cartridges umgesetzt. Der Anwendungsentwickler hat die Möglichkeit, Cartridges für ein Produkt (eine Java-Enterprise-Anwendung) an- und abzuwählen. Dieser Cartridge-Mechanismus ist eine einfache Variante um die Variabilität der Software-Factory-Produkte auszudrücken. Allerdings gibt es kaum Mittel, um Beziehungen zwischen Cartridges zu formulieren oder die obligatorischen Merkmale eines Produktes festzulegen. Eine gute Möglichkeit, die fixen und variablen Eigenschaften differenziert zu beschreiben, stellen die Featuremodelle dar. Dabei handelt es sich um hierarchische Strukturen, die die Features der Produkte einer Produktfamilie enthalten [SVEH07, S. 240]. Diese Features können verpflichtend, optional, alternativ oder n-aus-m ( or ) sein. Zwischen den Features können Beziehung bestehen, die als Zusicherungen für das Featuremodell wirken. Die gebräuchlichsten Beziehungen sind: requires (benötigt), excludes (schließt aus), recommends (empfiehlt) und discourages (rät ab) (vgl. [SVEH07, S. 241]). Mit diesen Mitteln lassen sich die Merkmale der Produktfamilie Java-Enterprise-Anwendungen sehr umfassend spezifizieren. Abbildung 6.2 zeigt ein prototypisches Featuremodell für diese Produktfamilie. Es wurde mit dem Eclipse-basierten Featuremodellierungswerkzeug pure::variants [PS] erstellt. Bei der Weiterentwicklung der Software Factory sollte die Verwendung von Featuremodellierung evaluiert werden. Möglicherweise lässt sich dafür 112

125 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten auch das eben genannte Werkzeug integrieren 5. Abbildung 6.2: Featuremodell für Java-Enterprise-Anwendungen Buildwerkzeug vs. Entwicklungsumgebung Der Aufgabenstellung folgend ist die Software Factory in die Entwicklungsumgebung Eclipse eingebettet. Auf diese Weise kann die Anwendungsentwicklung weitestgehend zentral in einem Werkzeug gehalten werden. Außerdem sind die meisten Technologien und Werkzeuge im MDSD-Umfeld sehr auf Eclipse ausgerichtet, so z. B. auch die in der Software Factory verwendeten Frameworks EMF, GMF und oaw, sodass sich die Ausrichtung der Software Facotry auf diese IDE anbietet. Im Softwareentwicklungsprozess ist die Wahl der IDE jedoch meist nicht vordergründig. Je nach vorhandenen Werkzeugen und persönlichen Präferenzen kommen bei verschiedenen Entwicklern und Teams unterschiedliche Entwicklungsumgebungen zum Einsatz. Entscheidend ist vielmehr ein definierter Buildprozess, der in der Regel über ein Buildwerkzeug wie Ant oder Maven 5 Die neueste Version bringt einen Adapter für openarchitectureware mit, sodass oaw-workflows über pure::variants-featuremodelle gesteuert werden können. 113

126 6 Zusammenfassung und Ausblick 6.2 Zukünftige Arbeiten gesteuert wird. Dieser Buildprozess ist nicht an eine IDE gebunden und lässt sich durch das Buildwerkzeug ausführen. Es stellt sich die Frage, ob auch die Software Factory IDE-unabhängig konzipiert und stattdessen auf ein Buildwerkzeug ausgerichtet werden sollte. Sämtliche Buildfunktionalität der Software Factory, die derzeit über die Entwicklungsumgebung gesteuert wird, würde dann über die Targets (Goals) 6 des Buildwerkzeugs ausgeführt. Interessant ist hier vor allem Maven 2, das bereits eine Menge vorgefertigter Goals mitbringt, die große Teile des Buildprozesses abdecken. Diese müssten um Software-Factory-spezifische Goals ergänzt werden. Die Cartridges könnten als Maven-Plugins umgesetzt werden. Die Vorzüge, die sich aus diesem buildzentrierten Ansatz ergeben, sollten dem nötigen Aufwand für diese wesentliche Änderung der Software Factory gegenübergestellt werden. Es ist auch zu untersuchen, inwieweit das Loslösen von der Eclipse-Plattform zweckmäßig ist, da die eingesetzten MDSD-Frameworks ohnehin Eclipse-basiert sind, beziehungsweise wäre zu prüfen, in welchem Umfang sich diese auch außerhalb von Eclipse verwenden lassen. 6 in Maven auch MOJOs genannt 114

127 A Anhang A.1 Zusicherungen des Metamodells Domain Benamung Zusicherung 1 Eine Entität hat einen Namen. 2 Ein Attribut hat einen Namen. 3 Eine Referenz hat einen Namen. 4 Eine Enumeration hat einen Namen. 5 Ein Literal hat einen Namen. 6 Ein Modul hat einen Namen. 7 Eine Query hat einen Namen. 8 Ein Service hat einen Namen. 9 Eine Servicereferenz hat einen Namen. weitere 10 Eine Entität erbt weder von sich selbst noch von einer Unterklasse (Vererbungszyklus). 11 Eine Entität hat keine Attribute oder Referenzen mit demselben Namen. 12 Eine Entität hat keine Queries mit demselben Namen. 13 Eine Entität hat keine Operationen mit demselben Namen und denselben Parametertypen. 14 Eine Enumeration hat keine Literale mit demselben Namen. 15 Der Namespace eines Moduls ist gesetzt. 16 Eine Query hat keine Query-Attribute, die auf dasselbe Attribut der Entität zeigen. 17 Ein Service hat keine Operationen mit demselben Namen und denselben Parametertypen. 18 Ein Service referenziert sich nicht selbst. 19 Ein Service hat keine Managed Dependencies, die auf dieselbe Entität zeigen. Tabelle A.1: Zusicherungen für Domain-Modelle 115

128 A Anhang A.2 GMF-Definitionsmodelle für die DSL Domain A.2 GMF-Definitionsmodelle für die DSL Domain Die nachfolgenden Abbildungen zeigen die Definitionsmodelle für die Erstellung des grafischen Editors der DSL Domain. Abbildung A.1: Werkzeugdefinitionsmodell der grafischen DSL Domain 116

129 A Anhang A.2 GMF-Definitionsmodelle für die DSL Domain Abbildung A.2: Grafikdefinitionsmodell der grafischen DSL Domain 117

130 A Anhang A.2 GMF-Definitionsmodelle für die DSL Domain 118