Konzeption und Entwicklung einer Software Factory …fritzsch/SF/sbley_diploma...Hochschule f¨ur...

Hochschule für Technik und Wirtschaft Dresden (FH)Fachbereich Informatik/MathematikFriedrich-List-Platz 101069 Dresden

Diplomarbeit

im Studiengang Informatik

Konzeption und Entwicklung einer

Software Factory fü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

Inhaltsverzeichnis

1 Einleitung 1

1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Java-Enterprise-Anwendungen 4

2.1 Verteilte Anwendungen und Middleware . . . . . . . . . . . . . . . . . . . 42.2 Der Java-Enterprise-Standard . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Muster und Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Konzepte und Muster einer Java-Enterprise-Architektur . . . . . . . . . . 7

2.4.1 Die Architektur des Domänenmodells . . . . . . . . . . . . . . . . 8

3 Modellgetriebene Softwareentwicklung 13

3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.1 Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Metamodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Model-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.2 MDA-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.3 Metamodellarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.4 Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.5 Domänenspezifische Modellerweiterung der UML . . . . . . . . . . 25

3.4 Software Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.1 Der Begriff in der Literatur . . . . . . . . . . . . . . . . . . . . . . 283.4.2 Eigene Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.3 Rollenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.4 Software Factories und MDA . . . . . . . . . . . . . . . . . . . . . 31

4 Technologien und Werkzeuge der MDSD 32

i

Inhaltsverzeichnis Inhaltsverzeichnis

4.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.1 Plugin-Mechanismus . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.1 Das Ecore-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.2 Codegenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.3 Erstellung grafischer Editoren . . . . . . . . . . . . . . . . . . . . . 364.2.4 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 openArchitectureWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1 Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.2 Integration in Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Atlas Transformation Language . . . . . . . . . . . . . . . . . . . . . . . . 444.5 AndroMDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.2 Ausblick auf Version 4.0 . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 OptimalJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.7 Microsoft Software Factories und DSL-Tools . . . . . . . . . . . . . . . . . 49

4.7.1 Software Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.7.2 Domain-Specific Language Tools . . . . . . . . . . . . . . . . . . . 51

5 Die Software Factory 53

5.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2.2 Technologiewahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.3 Software-Factory- und Anwendungsentwicklung . . . . . . . . . . . 61

5.3 Modellierung des Problemraums . . . . . . . . . . . . . . . . . . . . . . . 645.3.1 Das Metamodell Domain . . . . . . . . . . . . . . . . . . . . . . . 645.3.2 Die DSL Domain als EMF-Modell . . . . . . . . . . . . . . . . . . 665.3.3 Grafische Syntax mit GMF . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.4.2 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.4.3 Leitlinien für die Cartridgeentwicklung . . . . . . . . . . . . . . . . 82

5.5 Exemplarische Cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.5.1 Module Project Creator . . . . . . . . . . . . . . . . . . . . . . . . 89

ii

Inhaltsverzeichnis Inhaltsverzeichnis

5.5.2 POJO Creator for Domain Objects . . . . . . . . . . . . . . . . . . 925.5.3 JPA Annotation Creator . . . . . . . . . . . . . . . . . . . . . . . . 945.5.4 Data Access Object Generator . . . . . . . . . . . . . . . . . . . . 965.5.5 JPA Data Access Object Generator . . . . . . . . . . . . . . . . . 985.5.6 Spring 2.0 Service Beans Generator . . . . . . . . . . . . . . . . . . 99

5.6 Kern- und GUI-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . 1025.6.1 Der Kern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.6.2 Die GUI-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.7 Installation und Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.7.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.7.2 Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6 Zusammenfassung und Ausblick 107

6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.2 Zukünftige Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.2.1 Erweiterung der DSL Domain . . . . . . . . . . . . . . . . . . . . . 1086.2.2 Entwicklung weiterer Cartridges . . . . . . . . . . . . . . . . . . . 1096.2.3 Konzeptionelle Überlegungen . . . . . . . . . . . . . . . . . . . . . 110

A Anhang 115

A.1 Zusicherungen des Metamodells Domain . . . . . . . . . . . . . . . . . . . 115A.2 GMF-Definitionsmodelle für die DSL Domain . . . . . . . . . . . . . . . . 116A.3 Codebeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

iii

Abbildungsverzeichnis

2.1 Drei-Schicht-Architektur verteilter Anwendungen . . . . . . . . . . . . . . 52.2 Muster für Domänenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Beispiel für ein Domänenmodell einer Enterprise-Anwendung . . . . . . . 11

3.1 Metamodellarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Offizielles Symbol der MDA . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 MDA-Metamodellarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 QVT-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Definition und Anwendung eines Stereotyps . . . . . . . . . . . . . . . . . 263.6 Domänenspezifische Modellerweiterung durch Spezialisierung . . . . . . . 28

4.1 Definition und Erweiterung eines Extension Points . . . . . . . . . . . . . 334.2 Ecore-Klassenhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 GMF Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4 MDA in OptimalJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 Definition und Anwendung einer DSL mit den Visual Studio DSL Tools . 52

5.1 Konzept der Software Factory . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 Ausführung der Cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3 Build mit M2M-Transformationen . . . . . . . . . . . . . . . . . . . . . . 595.4 Entwicklungsumgebungen für SF und Java EE im Vergleich . . . . . . . . 635.5 Das Metamodell Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.6 Vererbungsbeziehungen zwischen Domain und Ecore . . . . . . . . . . . . 685.7 Shortcuts im grafischen Domain-Modell . . . . . . . . . . . . . . . . . . . 705.8 Validierung im grafischen Domain-Modell . . . . . . . . . . . . . . . . . . 705.9 Extension Point com.saxsys.sf.cartridge . . . . . . . . . . . . . . . . . 735.10 Erweiterung des Extension Points com.saxsys.sf.cartridge . . . . . . . 735.11 Extension Point com.saxsys.sf.core.projectContributions . . . . . . 745.12 Extension Point com.saxsys.sf.core.classpathContributions . . . . . 74

iv

Abbildungsverzeichnis Abbildungsverzeichnis

5.13 Ausgangsmodellelement für Generierung . . . . . . . . . . . . . . . . . . . 835.14 Eclipse-Workspace nach Ausführung des Module Project Generators . . . 915.15 Spring Beans Generator: Ausgangsmodell . . . . . . . . . . . . . . . . . . 1005.16 Software-Factory-Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . 106

6.1 Ungültige Referenz bei einem einmalgenerierten Artefakt . . . . . . . . . . 1126.2 Featuremodell für Java-Enterprise-Anwendungen . . . . . . . . . . . . . . 113

A.1 Werkzeugdefinitionsmodell der grafischen DSL Domain . . . . . . . . . . . 116A.2 Grafikdefinitionsmodell der grafischen DSL Domain . . . . . . . . . . . . . 117A.2 Mappingmodell der grafischen DSL Domain . . . . . . . . . . . . . . . . . 119

v

Tabellenverzeichnis

3.1 UML-Diagrammtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Bestandteile der Microsoft Software Factories . . . . . . . . . . . . . . . . 50

5.1 Gegenüberstellung Software-Factory- und Anwendungsentwicklung . . . . 615.2 POJO Creator: Mapping Domain-Modell – Java/AspectJ . . . . . . . . . 925.3 JPA Annotation Creator: Mapping Domain-Modell – Java/XML . . . . . 955.4 DAO Generator: Mapping Domain-Modell – Java/AspectJ . . . . . . . . . 975.5 Spring Beans Generator: Mapping Services – Spring . . . . . . . . . . . . 1005.6 Software Factory Eclipse Features . . . . . . . . . . . . . . . . . . . . . . . 105

A.1 Zusicherungen für Domain-Modelle . . . . . . . . . . . . . . . . . . . . . . 115

vi

Listings

3.1 UML-Modell als XMI-Dokument . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 Definition einer Zusicherung in Check . . . . . . . . . . . . . . . . . . . . 705.2 MM-Extension für den Namen einer Service-Implementierungsklasse . . . 765.3 Template für die Bean-Definition von Services in Spring . . . . . . . . . . 765.4 Template für eine Entityklasse . . . . . . . . . . . . . . . . . . . . . . . . 785.5 Template für JPA-Annotationen an eine Entityklasse . . . . . . . . . . . . 785.6 Template für eine persistence.xml in JPA . . . . . . . . . . . . . . . . . . 795.7 Template für Hibernate als Persistenzprovider . . . . . . . . . . . . . . . . 795.8 Eigenschaftendatei mit Ausgabeverzeichnissen . . . . . . . . . . . . . . . . 815.9 Workflow mit Generatorkomponente . . . . . . . . . . . . . . . . . . . . . 815.10 Generierte Klasse mit geschütztem Bereich . . . . . . . . . . . . . . . . . 845.11 Vererbung: generierte abstrakte Basisklasse . . . . . . . . . . . . . . . . . 855.12 Vererbung: manuell erstellte Implementierungsklasse . . . . . . . . . . . . 855.13 AOP: generierte Basisklasse . . . . . . . . . . . . . . . . . . . . . . . . . . 865.14 AOP: manuell erstellter Implementierungsaspekt . . . . . . . . . . . . . . 865.15 Spring Beans Generator: generierte spring-dao.xml . . . . . . . . . . . . 1015.16 Spring Beans Generator: generierte spring-services.xml . . . . . . . . . 101

A.1 plugin.xml des Plugins com.saxsys.sf.gen.persistence.jpa . . . . . 120A.2 Workflow der Cartridge com.saxsys.sf.gen.module . . . . . . . . . . . . 121A.3 Xpand-Template zur Generierung eines Service-Interfaces . . . . . . . . . 122A.4 Xtend-MM-Extensions für DAO-Artefakte . . . . . . . . . . . . . . . . . . 123A.5 Check-Datei mit Zusicherungen für Services . . . . . . . . . . . . . . . . . 124

vii

Abkürzungsverzeichnis

ADT ATL Development Tools

AJDT AspectJ Development Tools

AOP Aspektorientierte Programmierung

API Application Programming Interface

ATL Atlas Transformation Language

CIM Computation-Independent Model

CMOF Complete MOF

CORBA Common Object Request Broker Architecture

CRUD Create, Read, Update, Delete

CVS Concurrent Versions System

CWM Common Warehouse Metamodel

DAO Data Access Object

DBMS Database Management System

DDD Domain-Driven Design

DI Dependency Injection

viii

Abkürzungsverzeichnis Abkürzungsverzeichnis

DSL Domain-Specific Language

EJB Enterprise JavaBeans

EMF Eclipse Modeling Framework

EMOF Essential MOF

EPL Eclipse Public License

GEF Graphical Editing Framework

GMF Graphical Modeling Framework

GMT Generative Modeling Technologies

GUI Graphical User Interface

IDE Integrated Development Environment

IL Infrastructure Library

IoC Inversion of Control

J2EE Java 2 Enterprise Edition

Java EE Java Enterprise Edition

JDT Java Development Tools

JEM Java EMF Model

JPA Java Persistence API

JSF Java Server Faces

JTA Java Transaction API

MCR Model-Code Repository

ix


MDA Model-Driven Architecture

MDD Model-Driven Development

MDR Meta Data Repository

MDSD Model-Driven Software Development

MDT Model Development Tools

MM Metamodell

MOF Meta Object Facility

MVC Model View Controller

M2C Modell-zu-Code

M2M Modell-zu-Modell

M2T Modell-zu-Text

oAW openArchitectureWare

OCL Object Constraint Language

OMG Object Management Group

OR Object-Relational

PDE Plugin Development Environment

PIM Platform-Independent Model

PLE Product Line Engineering

PM Platform Model

POJO Plain Old Java Object

x


PSI Platform-Specific Implementation

PSM Platform-Specific Model

PT Personentag(e)

QVT Query/View/Transformation

RCP Rich Client Platform

RFP Request for Proposal

SDK Source Development Kit

SF Software Factory

SQL Structured Query Language

SPLE Software Product Line Engineering

UML Unified Modeling Language

VO Value Object

WTP Web Tools Project

XMI XML Metadata Interchange

XML Extensible Markup Language

XSD XML Schema Definition

xi

1 Einleitung

Die Softwareentwicklung ist heutzutage durchgehenden Veränderungen ausgesetzt. Kun-den erwarten ständig innovative Lösungen bei gleichzeitig hoher Qualität, schneller Fer-tigstellung und geringen Kosten. Um diesen Anforderungen gerecht zu werden, entstehenimmer komplexere Softwaresysteme mit neuartigen Technologien, Plattformen, Frame-works und Programmiersprachen. Der Entwickler ist somit gezwungen, sich immer wie-der mit technologischen Details auseinander zu setzen, wodurch wertvolle Zeit für dieeigentliche Betrachtung der Fachlichkeit verloren geht, die der Auftraggeber letztendlichumgesetzt haben möchte. Jacobson [Jac02] sieht den Anteil an solcher kreativer Arbeiteines Softwareentwicklers bei nicht mehr als 20 %.

Die hohe Komplexität der Anwendungen und Plattformen führt zu hoher Fehlerhäufig-keit, zumal die Fachlogik im Quellcode von Programmiersprachen verteilt ist und diesdie Fehlerfindung und -beseitigung erschwert. Mit der Einführung des Modellierungsstan-dards Unified Modeling Language (UML) gab es die Möglichkeit, grafische Modelle fürdie Fachlogik zu erstellen. Diese hatten aber nicht immer formalen Charakter und konn-ten demzufolge nicht für eine automatische Codeerstellung genutzt werden. Sie dientenals Dokumentation des Softwaresystems, nicht als primäres Quellartefakt.

Die Modellgetriebene Softwareentwicklung beschreibt einen Weg, den klassischen Pro-blemen der Anwendungsentwicklung zu begegnen, indem der fachliche Bereich in Formvon formalen Modellen zugänglich gemacht wird. Die Entwicklungsgeschwindigkeit undSoftwarequalität lassen sich durch automatisierte Transformationen dieser Modelle inArtefakte der Zieltechnologie erhöhen; die Produktivität steigt.

1

1 Einleitung 1.1 Problemstellung

1.1 Problemstellung

Zum Leistungsspektrum der Saxonia Systems AG1 gehört die Erstellung individuel-ler Softwarelösungen. In zahlreichen Projekten steht dabei die Entwicklung von Java-Enterprise-2Anwendungen im Mittelpunkt. Um die Produktivität bei der Entwicklungsolcher Anwendungen zu steigern, soll die modellgetriebene Softwareentwicklung in Formeiner Software Factory eingeführt werden.

Dazu sind die typischen Architekturmerkmale von Java-EE-Applikationen zu identifi-zieren und als Grundgerüst von der Software Factory bereitzustellen. Die Verwendungspezieller Plattformen und Frameworks (z. B. Enterprise Java Beans, Spring) muss va-riabel konfigurierbar sein, sodass auch Projekte, die unterschiedliche Technologien ver-wenden, die Software Factory zur Anwendungsentwicklung nutzen können. Die SoftwareFactory soll über Plugins (sogenannte Cartridges) für unterschiedliche Technologien er-weitert werden können. So ist sie von technologischen Neuerungen im Bereich von JavaEE unabhängig und durch die Entwicklung entsprechender Cartridges weiterhin einsetz-bar. Für ein konkretes Projekt muss es möglich sein, Cartridges zu bestimmen, die zurErstellung der Zielartefakte verwendet werden sollen. Um die praktische Eignung derSoftware Factory nachzuweisen, sind im Rahmen der Diplomarbeit für eine Auswahl anZieltechnologien exemplarische Cartridges zu entwickeln.

Die Entwicklungsplattform Eclipse bietet bereits zahlreiche Plugins zur Unterstützungbei der Erstellung von Java-Enterprise-Anwendungen an. Um die Entwicklung zentralin Eclipse halten zu können, wird eine bestmögliche Integration der Software Factoryin diese Entwicklungsumgebung angestrebt. Die Verwendung der Software Factory sollfür den Anwendungsentwickler intuitiv und verständlich sein. Hierzu sind zweckmäßigeund vertraute Mittel wie Editoren, Modellierungswerkzeuge und Assistenten (Wizards)bereitzustellen.

1vgl. www.saxsys.de für nähere Informationen zum Unternehmen2kurz: Java EE

2

http://www.saxsys.de

1 Einleitung 1.2 Aufbau der Arbeit

1.2 Aufbau der Arbeit

Die vorliegende Arbeit gliedert sich in sechs Kapitel. Nachdem im ersten Kapitel dasThema und Ziel der Arbeit vorgestellt wird, beschreibt Kapitel 2 die grundlegenden Ei-genschaften von Java-Enterprise-Anwendungen. Dabei werden Muster zusammengetra-gen, mit denen sich eine Java-Enterprise-Architektur beschreiben lässt und die später dieElemente einer Modellierungssprache für diese Architektur bilden sollen. Anschließendbeschäftigt sich Kapitel 3 mit den Grundlagen modellgetriebener Softwareentwicklung.Es erklärt das Prinzip der Metamodellierung und zeigt am Beispiel der UML, wie ei-ne Modellierungssprache für einen spezifischeren Problemraum erweitert werden kann.Danach wird der Begriff der Software Factory als Grundlage des in der Arbeit erstell-ten Softwaresystems erörtert. Nach der Vermittlung der theoretischen Voraussetzungenstellt Kapitel 4 dann aktuelle Technologien und Werkzeuge der modellgetriebenen Soft-wareentwicklung vor. Hierbei stehen vor allem die Technologien im Blickpunkt, die fürdie Erstellung einer Eclipse-basierten Software Factory von Interesse sind. Das Konzeptund die praktische Umsetzung der Software Factory sind Gegenstand des 5. Kapitels.Den Abschluss bildet das Kapitel 6, das die Ergebnisse der Arbeit noch einmal zusam-menfasst und auf offene Fragen eingeht. Dies umfasst auch die Angabe von Aufgaben,die im Rahmen zukünftiger Arbeiten zu erledigen sind.

3

2 Java-Enterprise-Anwendungen

Dieses Kapitel beschreibt die Grundlagen von Java-Enterprise-Anwendungen. An dieAusführungen zu verteilten Anwendungen und der Verwendung von Middleware in ver-teilten Systemen schließt sich eine Betrachtung des Java-Enterprise-Standards. Danachwerden Entwurfsmuster und Frameworks in den Kontext der Entwicklung von Java-Enterprise-Applikationen eingefügt. Abschließend werden wichtige Konzepte und Musterzusammengetragen, die sich als Vokabular zur Beschreibung einer Enterprise-Architektureignen.

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 unabhängigen Anwen-dungskomponenten, die an verschiedenen Stellen eines verteilten Systems liegen undmiteinander kommunizieren. Die typischen Aufgaben verteilter Anwendungen sind:

Präsentation Präsentation bedeutet die Bereitstellung einer interaktiven Benutzerschnitt-stelle zur Anwendung, z. B. über Webseiten.

Anwendungslogik Die Anwendungslogik enthält die Funktionalität, die die Anwendungfachlich bieten soll, d. h. der eigentliche Sinn der Anwendung.

Datenhaltung Datenhaltung ist die dauerhafte Speicherung der Daten.

Diese Aufgabenteilung führt zu einer oft verwendeten Aufteilung der Architektur inSchichten (engl. Tiers), die in Abbildung 2.1 dargestellt ist. Die Präsentationskompo-

4

2 Java-Enterprise-Anwendungen 2.1 Verteilte Anwendungen und Middleware

nente liegt auf der Client-Schicht, die Anwendungslogik auf der Mittelschicht und dieDatenhaltung auf der Server-Schicht.

Abbildung 2.1: 3-Schicht-Architektur nach [Ham05, S. 26]

Für die Kommunikation zwischen den Anwendungskomponenten existieren Middleware-Technologien, die von den Kommunikationsmitteln des verteilten Systems abstrahieren.Sie stellen eine Laufzeitumgebung (Container) und Dienste für die Anwendung bereit.Die Laufzeitumgebung verwaltet Ressourcen, ermöglicht die nebenläufige Nutzung derAnwendung und kümmert sich um Sicherheitsaspekte. Typische Dienste sind Sitzungs-verwaltung, Transaktionsmanagement und Persistenz. Die Aufteilung der Anwendung inKomponenten als wesentliches Merkmal verteilter Anwendungen wird durch die Midd-leware unterstützt, indem der Container den Lebenszyklus der Komponenten verwaltetund ihnen benötigte Dienste bereitstellt.

Ein Anwendungsserver (Application Server) stellt eine Middleware-Technologie für dieAnwendungslogik auf der Mittelschicht dar. Werden Anwendungen auf allen Schichtenunterstützt und auch die Anwendungsintegration adressiert, so spricht man von einerMiddleware-Plattform [Ham05, S. 60].

Die Java-Enterprise-Plattform ist ein Standard für Middleware-Plattformen. WeitereStandards dieser Art sind .NET und Common Object Request Broker Architecture(CORBA).

5

2 Java-Enterprise-Anwendungen 2.2 Der Java-Enterprise-Standard

2.2 Der Java-Enterprise-Standard

Der Java-Enterprise-Standard [JEE06] bietet eine Spezifikation für das Architekturmo-dell einer Java-EE-Middleware-Plattform. Das zum Standard gehörende Komponenten-modell Enterprise JavaBeans (EJB) ist von zentraler Bedeutung: Anwendungslogik istin EJB-Komponenten (Beans) gekapselt, die vom EJB-Container des Anwendungsser-vers auf der Mittelschicht verwaltet werden. Ein weiterer wichtiger Container ist derWeb-Container, der auf dem Webserver läuft und die Ausführung von Webanwendungenermöglicht.

Beans können über Schnittstellen miteinander kommunizieren. Dazu ist es nötig, dasssie im Container angemeldet sind. Das Anmelden (Deployment) erfolgt, indem ein De-ployment Descriptor für die Bean erstellt wird. Er definiert Namen und Beantyp und be-schreibt, welche Dienste benötigt werden1. Zusammen mit den kompilierten Java-Klassenwird er dann in ein Jar-Archiv gepackt und auf die Zielplattform kopiert. Alsdann istdie Anmeldung erfolgt und die Komponente verfügbar.

Die Java-Enterprise-Plattform stellt eine Reihe von Diensten bereit. Dazu gehören inder aktuellen Version Java EE 5 Dienste für Transaktionsmanagement (Java Transac-tion API) und Persistenz (Java Persistence API). Für die Präsentationsschicht stehenTechnologien wie Java Server Faces (JSF) und Servlets zur Verfügung.

2.3 Muster und Frameworks

Mit Java Enterprise existiert eine Plattform, die das Entwickeln verteilter Anwendungenmaßgeblich unterstützt. Dies ist jedoch nur die Basis für die Erstellung einer solchenApplikation. Die Anwendungslogik muss in die Formen gegossen werden, die Java EEin Form von Spezifikationen und Application Programming Interfaces (API) bereitstellt;eine aufwändige Arbeit, vor allem bei Verwendung der Java 2 Enterprise Edition (J2EE),dem Vorgänger von Java EE 5.

Im Laufe der Zeit haben sich für diese wiederkehrenden Aufgaben Entwurfsmuster (Pat-

1In Java EE 5 ist es gegenüber der Vorgängerversion J2EE möglich, diverse Einstellungen statt imDeployment Descriptor in Java-Annotationen festzulegen.

6

2 Java-Enterprise-Anwendungen 2.4 Konzepte und Muster

terns) herauskristallisiert, die auf Erfahrungen beruhen und allgemein anwendbar sind.Besonders populäre Kataloge, in denen diese Muster zusammengetragen wurden, sinddie Entwurfsmuster der Gang of Four [GHJV95], die Core J2EE Patterns [ACM03] sowiedie von Fowler zusammengetragenen Muster für Enterprise Application-Architekturen[Fow03]. Einige dieser Muster werden in Abschnitt 2.4 zur Beschreibung der wichtigstenKonzepte einer Java-Enterprise-Architektur verwendet.

Des Weiteren begegnete man der Komplexität der Standards und APIs durch die Ent-wicklung von Frameworks. Dabei handelt es sich um Programmiergerüste, die eine An-wendungsarchitektur oder Teile davon bereitstellen und durch eine Implementation er-gänzt werden müssen. Beispielsweise unterstützt das Persistenz-Framework Hibernate[Hib] die Datenhaltung durch die Abbildung von Java-Klassen auf Tabellen relationa-ler Datenbanken. Das Framework nimmt diese Mappings entgegen und kümmert sichselbstständig um das korrekte Lesen und Schreiben der Datenbanktabellen.

Eine bedeutsame Rolle kommt auch dem Spring-Framework [Spra] zu, das die An-wendungsentwicklung ganzheitlich vereinfacht, indem Komponenten zu einem hohenGrad entkoppelt werden. Dies geschieht basierend auf den Konzepten der Dependen-cy 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 Frameworksin den mit Java EE 5 eingeführten Technologien EJB3 und Java Persistence API (JPA)ü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 Aufteilungin Schichten. Dabei kommt meist eine Struktur mit drei oder mehr Schichten zum Ein-satz. Die Anwendungslogik auf der Mittelschicht enthält das fachliche Wissen der Soft-ware, d. h. die inhaltlichen Konzepte, für die die Software in Auftrag gegeben wurde.Für die Strukturierung dieses Konzeptraums, auch Domäne genannt, sind verschiedene

2Dependency Injection und deren Anwendung im Spring-Framework sind in [WB07] ausführlich be-schrieben.

7


Herangehensweisen möglich.

Fowler stellt in [Fow03] drei wesentliche Muster vor: Das Transaction Script organisiertdie Domänenlogik nach Prozeduren. Dabei führt eine Benutzeraktion, die über die Prä-sentationsschicht ausgelöst wird, zur Ausführung einer Prozedur. Diese umfasst einenvollständigen Ablauf, angefangen vom Entgegennehmen der Eingaben über die Durch-führung von Berechnungen bis zum Speichern von Daten in Datenbanken. Einen anderenWeg schlägt das Muster Domain Module ein. Statt Prozeduren stehen hier Objekte imMittelpunkt. Die Domäne wird durch Objekte beschrieben, die miteinander in Beziehungstehen und ihren Teil an der Domänenlogik tragen. Eine Benutzeraktion leitet somit denAufruf an Objekte entlang einer Kette weiter. Diese Entkopplung von Logik ermöglichteine einfachere Beherrschung komplexer Abläufe als das Transaction Script, bei dem diegesamte Logik einer Aktion in einem einzigen Script enthalten ist. Das dritte vorgeschla-gene Muster ist das Table Module. Es ist dem Domain Model sehr ähnlich, orientiertsich jedoch stärker an dem Konzept der Datenbanktabellen. Es ist im Bereich von Java-Enterprise-Anwendungen kaum verbreitet und kommt vorwiegend in Umgebungen zumEinsatz, die mit Record Sets arbeiten [Fow03, S. 553], wie zum Beispiel .NET.

2.4.1 Die Architektur des Domänenmodells

Ist die Entscheidung gefallen, die Anwendungslogik nach dem objektorientierten Ansatzdes Domain Models zu strukturieren, stellt sich die Frage, wie dieses Modell aufgebautist, d. h., aus welchen Kernelementen es besteht. Evans trägt in [Eva03] eine Reihe vonMustern zur Beschreibung des Domänenmodells einer Enterprise-Anwendung aus derSicht des Domain-Driven Designs (DDD) zusammen. Abbildung 2.2 zeigt die wichtigstendieser Muster in der Übersicht. Ein Domänenmodell kann demnach durch die nachfolgenderläuterten Muster charakterisiert werden.

Entitäten

Ein wesentlicher Bestandteil sind Entitäten. Sie repräsentieren Objekte einer Domäne.Um in einem Softwaresystem referenzierbar zu sein, haben sie eine eindeutige Identität,die unabhängig vom aktuellen Zustand diese Systems ist und für den gesamten Lebens-zyklus des Objekts gleich bleibt. Der Lebenszyklus ist dabei nicht auf die Laufzeit des

8


Abbildung 2.2: Muster für Domänenmodelle in Anlehnung an [MA06, S. 36]

Systems beschränkt. Die Entität kann auch darüber hinaus fortbestehen, etwa indemsie in eine Datenbank gespeichert wird, und zu einem späteren Zeitpunkt wieder in dielaufende Software geladen wird. Entitäten haben stets einen Zustand, der durch ihreAttribute ausgedrückt wird. Das identitätsstiftende Merkmal ist meist ein Attribut odereine Kombination von Attributen der Entität.

Werteobjekte

Es gibt Objekte, die in einer Anwendung nicht referenzierbar sein müssen und daherauch keine Objektidentität benötigen. Diese Werteobjekte (Value Objects, VO)3 stellenlediglich einen Container für Werte dar. Beispielsweise ist ein Datum ein Werteobjekt.Es speichert einen Datumswert, wobei es völlig unerheblich ist, ob das Objekt eindeutigreferenzierbar ist. Es ist nur der enthaltene Wert relevant. Werteobjekte sollten unver-änderlich sein, damit sie von mehreren Objekten referenziert werden können, um damitPerformancegewinne zu erzielen [MA06, S. 35]. Sie können nur geändert werden, indemsie neu erstellt werden. Ein Werteobjekt kann weitere Werteobjekte sowie Referenzen zuEntitäten enthalten.

3Auch Fowler beschreibt dieses Muster [Fow03, S. 530]. Es ist nicht mit dem Data Transfer Object derCore J2EE Patterns gleichzusetzen, das zuvor auch Value Object hieß [ACM03].

9


Services

Das Verhalten einer Domäne lässt sich gedanklich in Aktionen unterteilen. Einige die-ser Aktionen lassen sich den Objekten direkt zuordnet. Es gibt jedoch Aktionen, dienicht zu einem bestimmten Objekt gehören, sondern vielmehr domänenspezifisches Ver-halten repräsentieren. Dieses Verhalten wird von Services umgesetzt und in Form vonOperationen für das Softwaresystem verfügbar gemacht. Die Operationen dienen somitals Schnittstelle für den Zugriff auf Domänenlogik, beispielsweise aus der Präsentations-schicht heraus.

Module

Bei umfangreichen Anwendungen kann die hohe Anzahl an Domänenobjekten und Ser-vices schnell zu Unübersichtlichkeit führen. Daher wird die Domäne in Module unterteilt,die (hauptsächlich funktional) zusammenhängende Teile gruppieren. Durch diese Modu-larisierung wird die Komplexität der Domäne beherrschbar. Ein funktional kohärentesModul bietet den Vorteil, ohne Betrachtung weiterer Module einen für sich stehendenTeilaspekt der Domäne auszudrücken. Dies bedeutet nicht, dass Module voneinanderisoliert sind. Sie sind über Referenzen verbunden und repräsentieren in ihrer Gesamtheitdie Domäne. Während die Objekte und Services innerhalb eines Moduls einen engenBezug zueinander haben, sind die Module untereinander lose gekoppelt.

Diese vier Muster bilden die Grundlage für die Beschreibung eines Domänenmodellseiner Enterprise-Anwendung. Abbildung 2.3 veranschaulicht ihr Zusammenspiel an einemeinfachen Beispiel.

Darüber hinaus haben sich Muster etabliert, die sich mit der Lebenszyklusverwaltungvon Objekten befassen. Objekte durchlaufen in einem Softwaresystem einen bestimmtenLebenszyklus. Sie werden erstellt, verändert, möglicherweise persistiert, und gelöscht.Dabei muss die Datenintegrität bewahrt werden, ohne das Domänenmodell mit Kompo-nenten zu überladen, die sich um die Verwaltung des Lebenszyklus kümmern. Die MusterAggregat, Fabrik und Repository adressieren diese Problematik.

10


Abbildung 2.3: Beispiel für ein Domänenmodell einer Enterprise-Anwendung

Aggregate

Die Objekte einer Domäne stehen in Beziehung zueinander, d. h., sie sind voneinanderabhängig. Die Abhängigkeiten sollten generell so gering wie möglich gehalten werden.Das Geflecht an Beziehungen wird sonst unüberschaubar und schlecht wartbar, vor allemwenn Objekte gemeinsam gelöscht werden sollen. Diesem Problem kommt das Aggregatentgegen. Es gruppiert zusammenhängende Entitäten und Werteobjekte, wobei eine En-tität die Rolle des Wurzelelements im Aggregat einnimmt. Von außerhalb des Aggregatsdarf nur auf dieses Element referenziert werden. Es koordiniert den Zugriff auf die ande-ren enthaltenen Objekte und wenn es gelöscht wird, so wird stets das gesamte Aggregatgelöscht. Dadurch ist die Datenintegrität gewährleistet.

Fabriken

Die Erstellung von komplexen Objekten kann mitunter recht umfangreich sein, insbe-sondere wenn sie die Erstellung weiterer Objekte nach sich zieht, so wie es innerhalb vonAggregaten der Fall ist. Solch umfassende Erzeugungslogik wird in eigene Objekte, dieFabriken (Factories), ausgelagert. Eine Fabrik kann dabei für Erstellung einer Entität,

11


eines Werteobjekts oder eines Aggregats verantwortlich sein.

Repositories

Abschließend seien die Repositories erwähnt. Sie kapseln den Zugriff auf persistierteObjekte. Anstatt an jeder Stelle, an der ein Objekt angefordert wird, konkrete Daten-bankabfragen zu stellen, wird bei einem Repository angefragt. Dieses leitet die Abfragean die Datenbank weiter und gibt das gefundene Objekt zurück. Bei Aggregaten bietenRepositories nur Zugriff auf die Entität, die als Wurzelelement fungiert.

12

3 Modellgetriebene Softwareentwicklung

Dieses Kapitel befasst sich mit der Modellgetriebenen Softwareentwicklung (MDSD). Da-bei werden zu Beginn die Grundlagen und Ziele dieses Ansatzes beschrieben. Anschlie-ßend folgt eine Betrachtung der Metamodellierung, die in der Modellgetriebenen Soft-wareentwicklung eine bedeutende Rolle spielt. Im Weiteren wird die MDSD-AusprägungModel-Driven Architecture der Object Management Group (OMG) vorgestellt, bevordas Kapitel mit der Beschreibung der Software Factories schließt. Diese stellen den theo-retischen Hintergrund fü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 höherem Abstraktionsniveau als demvon Programmiersprachencode, Konfigurationsdateien und anderen Softwarebestandtei-len formal zu beschreiben und daraus automatisiert lauffähige Software zu erzeugen[SVEH07, S. 11]. Die Beschreibung erfolgt in Form von Modellen, die den Ausgangs-punkt für die Erstellung des Softwaresystems darstellen. Sind sie primäres Artefakt imEntwicklungsprozess.

Dies ist ein herausragendes Merkmal im Vergleich mit der konventionellen Verwendungvon Modellen als Mittel zur bloßen Dokumentation und Veranschaulichung von Softwa-re. Vor allem mit der Einführung des Notationsstandards Unified Modeling Language(UML) gewannen Modelle zunehmend an Bedeutung. Quellcode ließ sich mit Hilfe vonModellierungswerkzeugen grafisch darstellen (Reverse-Engineering) und wurde mitunterauch zur erneuten Erzeugung des Quellcodes verwendet (Roundtrip-Engineering), washäufig zu Konsistenzproblemen führte. Die Schwierigkeiten zogen in der Praxis meist die

1auch: Model-Driven Development, MDD

13

3 Modellgetriebene Softwareentwicklung 3.1 Grundlagen

Entscheidung nach sich, die Nutzung von Modellen aufzugeben [SV05, S. 15]. Der größteNachteil von Reverse- und Roundtrip-Engineering ist jedoch, dass das Abstraktionsni-veau nicht wesentlich über das von Programmiersprachen gehoben wird.

Die Modellgetriebene Softwareentwicklung zielt darauf ab, Software auf einer höherenEbene zu modellieren, d. h. mit den Konzepten eines abgegrenzten Problemraums (Do-mäne), der den Wirkungsbereich der Software beschreibt. Um aus diesen Modellen au-tomatisiert lauffähige Software zu erstellen, ist es erforderlich, dass die Modelle formalsind, damit sie von Transformatoren und Generatoren verabeitet werden können. ZurFormalisierung der Modelle wird eine Sprache benötigt, mit deren Vokabular sich dasdomänenspezifische Wissen ausdrücken lässt (Domänenspezifische Sprache, DSL). Dieformalen Modelle werden durch Transformationen sukzessiv an die Zielplattform her-angebracht. Der letzte Schritt in der Transformationskette ist dabei die Erstellung derZielartefakte wie z. B. Quellcode, Testskripte und Konfigurationsdateien.

3.1.1 Begriffe

Im Folgenden werden einige wichtige Begriffe erklärt, die zur Beschreibung des Konzeptesder Modellgetriebenen Softwareentwicklung benötigt werden.

Domäne

Eine Domäne bezeichnet einen abgegrenzten Problemraum, d. h. einen Interessenbereich,über den Wissen verfügbar ist. Die Anwendung von MDSD bezieht sich immer auf einesolche Domäne. Diese kann fachlicher Natur (z. B. Finanzen, Krankenkasse) oder techni-scher Natur (z. B. Persistenz, Workflow) sein. Domänen können auch in Unterdomänengegliedert sein. In der vorliegenden Arbeit ist die Domäne die Architektur von Java-Enterprise-Anwendungen.

Formale Sprachen

Eine Sprache ist dann formal, wenn ihre Syntax und ihre Semantik formal spezifiziertsind. Die Syntax legt die Struktur einer Sprache fest und die Semantik gibt dieser Struk-

14

3 Modellgetriebene Softwareentwicklung 3.1 Grundlagen

tur eine Bedeutung.

Es wird zwischen abstrakter und konkreter Syntax unterschieden: Die abstrakte Syntaxbestimmt, welche Elemente die Sprache enthält und wie diese aus anderen Elementengebildet werden. Die konkrete Syntax definiert die Ausdrucksmittel, mit der die ab-strakte Syntax formuliert werden kann. Dazu zählen grafische Darstellungsformen undNotationsregeln. Eine abstrakte Syntax lässt sich also durch unterschiedliche konkreteSyntaxformen darstellen und ist somit wiederverwendbar.

Die statische Semantik legt fest, wie Instanzen von Sprachkonstrukten miteinander ver-bunden werden müssen, um eine Bedeutung zu erhalten. Dies wird auch als Wohlge-formtheit bezeichnet. Die eigentliche Bedeutung des wohlgeformten Konstruktes wirddurch die dynamische Semantik bestimmt.

Domänenspezifische Sprachen

Eine domänenspezifische Sprache (Domain-Specific Language, DSL) hat die Aufgabe,eine formale Beschreibung wesentlicher Aspekte der Domäne zu ermöglichen. Sie enthältdie 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. Diedynamische Semantik der DSL leitet sich aus dem Domänenwissen ab.

3.1.2 Ziele

Der Ansatz der Modellgetriebenen Softwareentwicklung hat zum Ziel, den Anforderun-gen an moderne Softwaresysteme gerecht zu werden. Der Auftraggeber erwartet robusteSoftware in hoher Qualität, wobei die Entwicklungskosten sowie die Entwicklungszeitgering zu halten sind. MDSD versteht sich als ein weiterer Schritt in der Entwicklungder Softwaretechnologie, um diese Anforderungen bestmöglich zu erfüllen.

Im Besonderen werden mit dem modellgetriebenen Ansatz die folgenden Ziele erreicht(vgl. [SV05]):

15

3 Modellgetriebene Softwareentwicklung 3.2 Metamodellierung

• Durch die automatisierte Codeerstellung aus den Modellen wird eine Erhöhungder Entwicklungsgeschwindigkeit erreicht. Die zeitaufwändige manuelle Codierungwird eingedämmt und somit der Fokus des Entwicklers mehr auf die Umsetzungder fachlichen Anforderungen gelenkt.

• Die Qualität der Software wird erhöht, da die Zielartefakte aus formal definier-ten Modellen abgeleitet werden. Diese Modelle sind in einer domänenspezifischenSprache formuliert, wodurch die Fachlogik präziser beschrieben werden kann, alsz. B. mit Allzweckprogrammiersprachen.

• Der Einsatz von auf eine Domäne zugeschnittenen Sprachen fördert die Kommu-nikation zwischen IT-Fachleuten und Auftraggebern [LS06].

• Die Wiederverwendbarkeit wird gefördert, da einmal erstellte DSLs, Transforma-tions- und Generierungsvorschriften für die Erstellung aller Produkte der Problem-domäne genutzt werden können.

• Die Verbindung von fachlichen Anforderungen und nichtfunktionalen Anforderun-gen wird zentral in den Transformationsvorschriften gehalten. Dadurch erhöht sichdie Wartbarkeit der Software.

• Der fortwährende Technologiewandel wird beherrschbar, denn Domänenwissen undTechnologiespezifika werden in unterschiedlichen Modellen gehalten und erst durchTransformation und Generierung miteinander in Verbindung gebracht. Beim Aus-tausch der gewählten Technologie bleibt die Fachlichkeit unberührt.

• Nicht zuletzt wird mit den genannten Zielen auch die Reduzierung der Software-entwicklungskosten angestrebt.

3.2 Metamodellierung

Wie dargestellt, werden Modelle im Kontext der modellgetriebenen Softwareentwicklungmit Hilfe von domänenspezifischen Sprachen formuliert. Ein Metamodell (MM) legt diezur DSL gehörende abstrakte Syntax sowie die statische Semantik fest. Des Weiterenwerden Metamodelle für die Modellvalidierung, -transformation sowie zur Erstellung

16

3 Modellgetriebene Softwareentwicklung 3.3 Model-Driven Architecture

von Modellierungswerkzeugen benötigt (vgl. [SV05, S. 91]).

Ein Metamodell ist ein Modell, das die Syntax eines anderen Modells definiert. Aussagenüber die inhaltliche Bedeutung des Modells werden dabei nicht gemacht. Das Metamo-dell befindet sich auf einer höheren (Meta-)Ebene als das Modell, es ist jedoch möglich,dass beide Modelle dieselbe konkrete Syntax verwenden. Die abstrakte Syntax sowie dieSemantik des Metamodells sind aber unterschiedlich. Ein Modell wird als Instanz seinesMetamodells angesehen, somit sind alle Modellelemente Instanzen der Metamodellele-mente.

Um ein Metamodell zu beschreiben, wird ebenfalls ein (Meta-)Metamodell verwendet,welches wiederum durch ein Metamodell definiert ist. Dadurch ergibt sich eine Meta-modellarchitektur mit beliebig vielen Modellebenen. In der Praxis beschränkt man sichjedoch auf eine vierschichtige Architektur, wie sie durch die OMG in der Spezifikationder Meta Object Facility (MOF) in Version 1.4 beschrieben ist. Abbildung 3.1 zeigt siean einem Beispiel:

Das MOF-Modell auf Ebene M3 definiert ein Element Class. Dieses ermöglicht die Be-schreibung des UML-Metamodellelements Class auf Ebene M2. Mit Hilfe dieses Elementslässt sich eine Klasse in einem UML-Modell definieren, hier die Klasse Person. Zur Lauf-zeit wird dann eine Instanz dieser Klasse erzeugt, welches in der UML-Terminologie auchals Objekt bezeichnet wird. Im Beispiel in Abbildung 3.1 ist die Person David ein solchesObjekt.

3.3 Model-Driven Architecture

Die Model-Driven Architecture (MDA) ist ein Ansatz der modellgetriebenen Softwareent-wicklung, der von der Object Management Group (OMG), einem Konsortium, das Indus-triestandards für die Softwaretechnologie entwickelt, vorangetrieben wird [MDA]. Kern-bestandteile 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 derTechnologieplattform, auf der diese Fachlichkeit später ausgeführt werden soll. BeideAspekte werden erst durch Modelltransformationen zusammen gebracht, zuvor sind sieaber unabhängig voneinander und somit auch einzeln bearbeitbar und austauschbar.

17


Abbildung 3.1: Metamodellarchitektur nach [MOF05]

18


Abbildung 3.2: Offizielles Symbol der MDA

3.3.1 Ziele

Da die MDA eine Ausprägung der MDSD ist, verfolgt sie auch die in Abschnitt 3.1.2 aufS. 15 genannten Ziele. Darüber hinaus konzentriert sich die Model-Driven Architecturenach [SV05] auf zwei weitere Ziele für zukünftige Softwaresysteme:

• Interoperabilität, d. h. Herstellerunabhängigkeit durch Standardisierung

• Portabilität (Plattformunabhängigkeit)

Die MDA stellt dazu Richtlinien und Standards wie etwa MOF und UML bereit. Wenndie Hersteller von Werkzeugen und Editoren diese Standards umsetzen, kann eine leis-tungsfähige Werkzeugkette für die modellgetriebene Softwareentwicklung aufgebaut wer-den. Statt proprietärer und inkombatibler Formate verfügen die Werkzeuge über eine ein-heitliche Schnittstelle. MDA-konforme Modelle können dann zwischen den Werkzeugenüber Systemgrenzen hinweg (Portabilität) ausgetauscht werden.

19


3.3.2 MDA-Modelle

Um die zuvor genannte Trennung der fachlichen von der technischen Spezifikation zuermöglichen, werden in der MDA die folgenden Modelle definiert:

Plattformunabhängiges Modell In einem Plattformunabhängigen Modell (Platform-In-dependent Model, PIM) werden die fachlichen Aspekte definiert. Eine an die Do-mäne angepasste Modellierungssprache (DSL) legt dafür die Syntax fest. Tech-nologische Details kommen im PIM zu keiner Zeit vor. Das im PIM enthalteneFachwissen ist somit nicht an eine spezielle Plattform gebunden und demzufolgefür den Einsatz auf mehreren Plattformen vewendbar.

Plattformmodell Das Plattformmodell (Platform Model, PM) ist ein Modell, das dieStruktur und die Konzepte einer Zielplattform beschreibt. Es abstrahiert über dieImplementierung der Plattform, da die technologischen Details für das Verständnisder Funktionsweise der Plattform nicht notwendig sind. Das PM enthält keinefachlichen Informationen.

Plattformspezifisches Modell Durch automatisierte Modelltransformationen wird dasPIM in ein Plattformspezifisches Modell (Platform-Specific Model, PSM) über-führt. In diesem Transformationsschritt wird das Modell um die plattformspezifi-schen Konzepte eines PMs erweitert. Da der Begriff der Plattform relativ ist, kanndas PSM wiederum als PIM gegenüber der darunter liegenden Plattform angesehenwerden. Das heißt, das Fachmodell wird über mehrere Plattformen transformiert,wobei als letzter Transformationsschritt die Erzeugung der Zielartefakte wie z. B.Quellcode2 steht. Im einfachsten Fall ohne Zwischenmodelle besteht der Erstel-lungsprozess also aus einem Transformationsschritt.

Plattformspezifische Implementierung Die Plattformspezifische Implementierung (Plat-form-Specific Implementation, PSI) ist der Quellcode, der die fachliche Logik aufder Zielplattform letztendlich zur Ausführung bringt. Die PSI ist ein PSM, dasaus Quellcode besteht, eine Unterscheidung der beiden Modelle ist daher nichtzwingend nötig (vgl. [PM06, S. 106]).

2Die Bezeichnung Quellcode ist im Kontext der MDSD irreführend, da er ein Zielartefakt der Generie-rung darstellt. Erst zur Übersetzungszeit nimmt der Quellcode wieder die Rolle eines Quellartefaktesfür den Compiler ein.

20


Eine unbedeutendere Rolle spielt das Computation-Independent Model (CIM). Es be-schreibt das System aus einer noch abstrakteren Sicht als das PIM und muss nichtformal sein. Das CIM wird (nicht zwangsläufig automatisch) in das PIM überführt.

3.3.3 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 MOFauf Ebene M3, welche die oberste der vier Ebenen darstellt. Da es darüber keine weitereModellebene 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 sindvom Nutzer erstellte UML-Diagramme, in denen das Domänenwissen modelliert wird.Konkrete Ausprägungen der dort definierten Objekte zur Laufzeit sind in der DatenebeneM0.

21


3.3.4 Spezifikationen

Nachfolgend werden die wichtigsten der von der OMG spezifizierten MDA-Standardsvorgestellt:

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 zurBeschreibung von Metamodellsprachen wie UML oder CWM. Sie nutzt aus der UMLbekannte Konzepte wie Klassen und Vererbung3. MOF befindet sich auf der MetaebeneM3 und beschreibt sich selbst. Dies ist möglich, da sowohl MOF als auch UML die Infra-structure Library (IL) verwenden, welche grundsätzliche Konzepte für Metamodellspra-chen und einen Erweiterungsmechanismus bereithält. Die IL wird also auf den EbenenM2 und M3 verwendet. Folglich lassen sich mit M3-Modellen neben M2-Modellen auchM3-Modelle beschreiben. Ausfü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) bildetden Kern und spezifiziert Modellelemente, die in den meisten Fällen für die Definitiongeeigneter Metamodelle zur Beschreibung von Softwaresystemen ausreichen. Das Meta-modell Ecore des Eclipse Modeling Frameworks, das in Abschnitt 4.2.1 vorgestellt wird,verwendet EMOF als Vorlage [GPR06, S.292]. Um umfangreichere Metamodelle zu er-stellen, kann die Complete MOF (CMOF) verwendet werden. Sie ergänzt EMOF umReflection- und Erweiterungskomponenten.

XML Metadata Interchange

In Abschnitt 3.3.1 wurde erläutert, dass die Austauschbarkeit der Modelle über ver-schiedene Werkzeuge eines der Hauptziele der MDA darstellt. Die MOF-Spezifikati-on bringt dafür ein serialisierbares Modellformat mit, das XML Metadata Interchange(XMI) [XMI05]. Leider ist die Unterstützung des XMI-Formates durch die derzeit auf

3Die UML gab es schon vor der MOF. MOF wurde später als Grundlage für die formale Beschreibungder UML entwickelt [SV05, S. 96].

22


dem Markt erhältlichen Modellierungswerkzeuge teilweise noch mangelhaft (vgl. [SV05,S. 377]). Listing 3.1 zeigt beispielhaft eine UML-Klasse als XMI-Datei [XMI05, S. 16f.].

Listing 3.1: UML-Modell als XMI-Dokument

Unified Modeling Language

Die Unified Modeling Language (UML) [UML07a]/[UML07b] ist eine Modellierungs-sprache, mit der sich statische Strukturen und dynamisches Verhalten abbilden lassen.Obwohl sie hauptsächlich für die Beschreibung von Struktur und Verhalten von Software-systemen verwendet wird, lässt sich die UML prinzipiell für viele Arten von Daten nutzen,deren grafische Visualisierung das Verständnis ihrer Bedeutung fördert. So kommt dieUML auch häufig zur Geschäftsprozessmodellierung zum Einsatz. Das Metamodell derUML ist die MOF, wobei beide auch gemeinsame Komponenten nutzen (siehe Abschnitt3.3.4).

Die seit 2005 bestehende Version 2.0 definiert 13 Diagramme, mit denen ein Systemumfassend beschrieben werden kann. Tabelle 3.1 gibt einen Überblick über ausgewählteDiagramme und ihre Funktion.

Object Constraint Language

Ein weiterer OMG-Standard ist die Object Constraint Language (OCL) [OCL06]. Sie isteine formale, deklarative Sprache und ermöglicht es, die statische Semantik von Model-len (meist sind dies UML-Modelle) zu spezifizieren. Mit Hilfe der OCL lassen sich Vor-und Nachbedingungen sowie Klasseninvarianten in Form von logischen Ausdrücken for-mulieren. OCL-Ausdrücke sind aber z. B. auch für die Beschreibung von Modellabfragen(Queries) hilfreich.

23


Diagramm Verwendung

Strukturdiagramme

Klassendiagramm beschreibt die statischen Elemente (Klassen) und deren Bezie-hungen zueinander

Objektdiagramm zeigt aktuelle Ausprägungen dieser Klassen (Objekte)

Komponentendiagramm modelliert die Beziehungen und Abhängigkeiten der System-komponennten

Paketdiagramm visualisiert die Gruppierung von Klassen (Pakete) und derenBeziehungen

Verhaltensdiagramme

Anwendungsfalldiagramm beschreibt die Beziehungen zwischen den Anwendungsfällenund den Akteuren

Aktivitätsdiagramm stellt das Verhalten einer Klasse oder Komponente dar

Zustandsdiagramm modelliert Systemzustände, deren Übergänge und Ereignisse

Sequenzdiagramm veranschaulicht die zeitliche Abfolge von Interaktionen zwi-schen Objekten

Tabelle 3.1: UML-Diagrammtypen

MOF Query/View/Transformation

Für die im Abschnitt 3.3.2 beschriebenen Modelltransformationen bedarf es einer Trans-formationssprache. Die OMG hat einen Standard zur Definition solcher Sprachen aufden Weg gebracht, die Query/View/Transformation (QVT) [QVT07]. In Abbildung3.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


des Zielmetamodells definiert werden, die nach Ausführung der Transformation wahrsind. Diese Variante wird nach Bohlen [Boh06b, S. 1] von der OMG empfohlen. Opera-tional Mappings ermöglicht es hingegen, Transformation imperativ anzugeben, was fürEntwickler intuitiver anwendbar ist [Boh06b, S. 1]. Die Komponente Black Box sieht dieEinbindung von Transformationssprachen vor, die nicht auf QVT beruhen.

Der QVT-Standard ist bislang noch nicht endgültig verabschiedet worden. Allerdingsgibt es bereits Implementierungen, die Teile des Standards umsetzen. So z. B. mediniQVT [med] oder die Atlas Transformation Language (ATL), die in Abschnitt 4.4 vorge-stellt wird.

3.3.5 Domänenspezifische Modellerweiterung der UML

In Abschnitt 3.1.1 wurde darauf hingewiesen, dass sich die Modellgetriebene Software-entwicklung immer auf einen konkreten Problemraum, eine Domäne, bezieht. Um Wissenund Fachlogik aus einer solchen Domäne auszudrücken, ist eine domänenspezifische Spra-che von Vorteil. Die im Kontext der Model-Driven Architecture überwiegend eingesetzteUML allein ist aber eine Allzweckmodellierungssprache und muss erst an die konkreteDomäne angepasst werden.

UML und MOF in den aktuellen Spezifikationen stellen dafür zwei Erweiterungsmecha-nismen bereit: die schwer- und die leichtgewichtige Erweiterung. Ergänzt werden diesedurch den feder- und den mittelgewichtigen Ansatz, welche in [Hus07] beschrieben sind.

Schwergewichtige Erweiterung

Der schwergewichtige Ansatz ist, ein Metamodell zu erstellen, das den Anforderungen derDomäne gerecht wird und dieses mit Teilen des UML-Metamodells zu einem neuen Meta-modell zu vereinen. Dieser Erweiterungsmechanismus ist in der MOF 2.0 spezifiziert, undwird dort ebenfalls vielfacht angewandt [MOF06]. Der Nachteil dieser Herangehensweiseliegt in der Gefahr, sich von Standards zu entfernen und so die Verarbeitbarkeit durchWerkzeuge zu verlieren. Des Weiteren erfordert der Ansatz ausreichende Kenntnisse derMetamodellierung innerhalb der MOF.

25


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 Zusicherun-gen. Stereotypen sind Metamodellelemente, mit denen UML-Metamodellelemente durchsemantische Informationen angereichert werden können4. Bei der Definition eines Ste-reotyps muss festlegt werden, für welche Elemente er angewendet werden kann (z. B.Class, Property). Einem Element können beliebig viele Stereotypen zugeordnet werden.Stereotypen können zusätzliche Attribute enthalten, so genannte Tagged Values. Dabeihandelt es sich um einfache Schlüssel-Wert-Paare, mit denen weitere semantische Detailsausgedrückt werden können. Abbildung 3.5a zeigt die Vereinbarung eines Stereotyps miteinem Tagged Value. Dieser Stereotyp wird in Abbildung 3.5b einer Klasse zugeord-net. Eine weitere Möglichkeit der Beschreibung von Semantik mit UML-Profilen sindZusicherungen (Constraints). Das sind OCL-Ausdrücke, mit denen Bedingungen undInvarianten formuliert werden können (siehe Abschnitt 3.3.4 auf S. 23). Beispielsweisekönnte für die Klasse Entity in Abbildung 3.5a die Zusicherung tableName.length > 2festgelegt werden.

(a) Der Stereotyp Entity istauf Elemente vom TypClass anwendbar und ent-hält den Tagged Value ta-bleName.

(b) Anwendung des Stereotyps Entity aufdie Klasse Person. Dem Attribut ta-bleName wird ein Wert zugewiesen.

Abbildung 3.5: Definition und Anwendung eines Stereotyps

4Vielmehr ist der Profilmechanismus nicht nur für das UML-Metamodell, sondern generell für MOF-konforme Metamodelle anwendbar (vgl. [PM06, S. 74]).

26

3 Modellgetriebene Softwareentwicklung 3.4 Software Factories

Federgewichtige Erweiterung

Die federgewichtige Variante [Hus07, S. 48-53] sieht vor, das Metamodell unverändertzu lassen und stattdessen die Elemente des UML-Modells mit Stichwörtern zu versehen.Damit ist dies die ”leichtgewichtigste“ der vier Varianten bezogen auf das Maß an Meta-modellierung. Der Nachteil ist hier, dass die Stichwörter weder strukturiert sind noch inBeziehung zueinander stehen, sodass sich keine Strukturinformationen über die Domä-ne ausdrücken lassen. Die Erstellung eines domänenspezifischen Editors ist bei diesemAnsatz ebenfalls ausgeschlossen, da die Stichwörter nicht Teil des Metamodells sind, derEditor allerdings auf diesem basiert.

Mittelgewichtige Erweiterung

Der vierte Ansatz ist die mittelgewichtige Erweiterung [Hus07, S. 62-71]. Die Domänebekommt dabei ein eigenes Metamodell, welches das UML-Metamodell durch Speziali-sierung erweitert. Das bedeutet, dass die Metamodellklassen von den Klassen des UML-Metamodells erben und ihre domänenspezifischen Merkmale durch zusätzliche Attributeoder Spezialisierung der Attribute der Oberklassen ausdrücken5. Abbildung 3.6 verdeut-licht dies an einem Beispiel. Der mittelgewichtige Ansatz gewährt mehr Freiheiten beider Metamodellierung als der leichtgewichtige, ohne dabei die Nachteile eines komplettneuen Metamodells bei der schwergewichtigen Erweiterung in Kauf nehmen zu müssen.

3.4 Software Factories

Nachfolgend soll der Begriff der Software Factory (SF, Softwarefabrik) erläutert und dieVerbindung zur MDA hergestellt werden.

5Die Spezialisierungskonstrukte für Attribute sind in [UML07a, Kap. 11.3] definiert und werden in[AP05] ausführlich erläutert.

27


Abbildung 3.6: Die Klassen des Domänen-Metamodells erben von UML-Metamodell-Klassen; das Referenzattribut entities der Klasse Module spezialisiertdas geerbte Referenzattribut packagedElement.

3.4.1 Der Begriff in der Literatur

In der Literatur finden sich sehr unterschiedliche Ansichten darüber, was eine SoftwareFactory ist. So sehen Aaen et al. [ABM97] den Terminus als eine Beschreibung derOrganisation innerhalb eines Unternehmens, in dem Software entwickelt wird. Demnachgibt eine Software Factory vor, welche Softwareentwicklungsprozesse zur Anwendungkommen, wie Softwareprojekte verwaltet werden und legt fest, welche Methoden undWerkzeuge den Entwicklern zur Verfügung stehen. Ziel ist dabei, die Produktivität derEntwicklung und die Qualität der Produkte zu erhöhen.

Eine andere Bedeutung erhält der Begriff in Microsofts Software-Factory-Initiative (mehrdazu 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, . . . , umdie Entwicklung und Wartung von Varianten eines archetypischen Produkts zu auto-matisieren . . .“. Die Kernaussage dieses Ansatzes ist, dass ähnliche Softwareproduktein einer einheitlichen Entwicklungsumgebung hergestellt werden, die dynamisch an dieBesonderheiten der einzelnen Produkte angepasst werden kann. Der Anwendungsbereich

28


der Produktfamilie6 muss klar abgegrenzt, sodass sich die Architektur der Anwendungensamt ihrer Variabilitäten formal in Modellen beschreiben lässt. Daraus werden automati-siert, unter Einbeziehung von Templates, Frameworks und Entwurfsmustern, Artefaktedes zu entwickelnden Produktes generiert. Das von den Autoren erarbeitete Konzeptzielt vor allem auf eine schnellere und produktivere Erstellung von Softwareprodukteninnerhalb einer Produktlinie ab.

3.4.2 Eigene Interpretation

Für die Beschreibung der Software Factory für Java-Enterprise-Anwendungen, die Ge-genstand dieser Arbeit ist (siehe Kapitel 5), soll eine eigene Auslegung des Software-Factory-Begriffs den Weg bereiten. Der von Greenfield et al. dargestellte Ansatz dientdafür als Vorlage.

Eine Software Factory bezweckt die Systematisierung der Entwicklung von Softwarepro-dukten einer Software-Produktlinie. Das sind Anwendungen oder Anwendungskompo-nenten mit wesentlichen gemeinsamen Eigenschaften, die fachlicher oder technologischerNatur sind [SVEH07, S. 238]. Das gemeinsame Konzept der Produktfamilie ist in einerDomäne zusammengefasst. Darüber hinaus existieren Unterschiede zwischen den Fami-lienmitgliedern, die diese innerhalb der Produktfamilie einzigartig machen. Diese Idee istunter dem Begriff Product Line Engineering (PLE)7 zusammengefasst und wird u. a. in[vdLSR07] und [SPL] eingehend erläutert. Die Festlegung einer abgeschlossenen Domäneund definierter Punkte, an denen sich die Produkte unterscheiden, ebnet den Weg füreine systematische Entwicklung von ähnlichen Softwareprodukten, was durch die Aus-schöpfung des Potenzials der modellgetriebenen Softwareentwicklung erreicht wird. Sokommt die MDSD zum Einsatz, indem ein Generator aus dem Modell der gemeinsamenDomäne einheitlich für alle Familienmitglieder die Artefakte der Zielplattform erstellt;das bedeutet, dass die Generatortemplates systematisch wiederverwendet werden. Dievariablen Eigenschaften werden in Bausteinen gekapselt, die das Wissen über diese vonder Domäne nicht erfassten Merkmale in Form von DSLs und Templates enthalten.Bei der Entwicklung eines Produkts der Produktfamilie muss festgelegt werden, welchevariablen Attribute verwendet werden. Dabei kann der Zeitpunkt dieser Entscheidungvariieren (vgl. [SVEH07, S. 243]).

6Produktlinie und Produktfamilie werden gleichbedeutend gebraucht.7Im Gebiet der Softwareentwicklung spezieller Software Product Line Engineering (SPLE).

29


Eine Software Factory stellt die Infrastruktur für die Entwicklung von Software im Sinnevon SPLE zur Verfügung. Sie bezieht sich auf eine vorgegebene Domäne und ermöglichtdie Entwicklung von Softwareprodukten, die auf den Konzepten dieser Domäne basie-ren. Idealerweise stellt sie eine Entwicklungsumgebung zur Verfügung, die den gesamtenErstellungsprozess der Produkte umfasst. Über definierte Erweiterungspunkte lässt sichdie Software Factory mit Bausteinen für bestimmte, von der Domäne nicht modellierte,Merkmale ergänzen. Mit Hilfe dieser Schnittstellen können die Bausteine miteinanderkommunizieren. Der Zeitpunkt der Entscheidung, welche variablen Eigenschaften einkonkretes Produkt der Software-Produktfamilie verwendet, wird von der Software Fac-tory vorgegeben. Durch die Verwendung der MDSD wird der Erstellungsprozess auto-matisiert, was die Entwicklungsgeschwindigkeit erhöht und zu robusterer Software führt.Dies wird dadurch unterstützt, dass das Domänenwissen in formalen Modellen vorliegt.Diese dienen als Eingabe für Generatoren, welche die Anwendungsartefakte erzeugen.

3.4.3 Rollenverteilung

Bei der Betrachtung des Konzeptes der Software Factory ist zu beachten, dass unabhän-gig von den Produkten der Produktfamilie auch die Software Factory einem stetigen Ver-änderungsprozess unterliegt. Die Entwicklung der Anwendung und die Entwicklung derSoftware Factory werden getrennt betrachtet. Dies führt zu zwei verschiedenen Rollen,die nicht zwangsläufig von derselben Person oder Personengruppe ausgefüllt werden.

Der Software-Factory-Entwickler beschäftigt sich mit der Instandhaltung und Weiter-entwicklung der Software Factory. Dies beinhaltet auch die fortwährende Überprüfungdes Domänenmodells hinsichtlich der korrekten Wiedergabe der Domäne, des Problem-raums, für den die Software Factory existiert. Er legt die Variabilitätspunkte fest, diedurch spezielle Bausteine erweitert werden kö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 derSoftware Factory zur Verfügung gestellt werden, und profitiert dabei von der zu diesemZweck bereitgestellten Entwicklungsumgebung. Er stößt die Generatoren an, die aus denvon ihm erstellten Modellen die Zielartefakte erzeugen.

Eine regelmäßige Kommunikation zwischen beiden Rollen stellt sicher, dass die Software

30


Factory auch den Zweck erfüllt, den sie beabsichtigt, und sich im praktischen Einsatzbewährt. Kapitel 5 greift die Rollenverteilung im Zuge der Beschreibung der SoftwareFactory für Java-Enterprise-Anwendungen noch einmal auf.

3.4.4 Software Factories und MDA

Nachdem die Model-Driven Architecture und die Software Factories erläutert wurden,soll abschließend geklärt werden, welche Verbindung zwischen diesen beiden Konzeptenbesteht.

Software Factories zielen ausdrücklich auf den Einsatz im Product Line Engineering ab,d. h., mit einer Software Factory soll die Entwicklung von Produkten einer Produktfami-lie systematisiert und automatisiert werden. Die Model-Driven Architecture macht keineAussagen darüber, in welchem Kontext sie gebraucht werden soll. Ein Anwendungsfall istjedoch, die MDA als Umsetzung der MDSD-Komponente einer Software Factory zu ver-wenden. Damit wird festgelegt, dass eine solche MDA-basierte Software Factory z. B. mitden MDA-Konzepten Plattformunabhängiges Modell und Plattformmodell arbeitet unddiese 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. Solehnen etwa die Entwickler der Microsoft Software Factories die UML für die Erstellungdomänenspezifischer Sprachen gänzlich ab [GS+06, S. 453]. In diesem Zusammenhangsind oft auch die verfolgten Ziele ausschlaggebend. Während die MDA durch Standardi-sierung eine bestmögliche Interoperabilität und Portabilität anstrebt, muss dies für eineSoftware Factory nicht der Fall sein. Hier können andere Zielgrößen vorrangig sein (z. B.eine nahtlose Integration in ein bestehendes Softwaresystem), für die die Nutzung derteils sehr komplexen MDA-Standards eher hinderlich wäre.

31

4 Technologien und Werkzeuge der MDSD

In diesem Kapitel sollen bedeutende Technologien, Frameworks und Werkzeuge der mo-dellgetriebenen Softwareentwicklung vorgestellt werden. Dabei reicht der Überblick voneinfachen 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 trotzdemin diesem Kapitel vorgestellt werden, da sie in der im Rahmen der Diplomarbeit er-stellten Software Factory eine grundsätzliche Rolle spielt und einige der hier genanntenTechnologien auf Eclipse beruhen.

Eclipse [Ecl] ist eine Integrierte Entwicklungsumgebung (Integrated Development Envi-ronment, IDE). Sie wurde im November 2001 von IBM, OTI und acht weiteren Unterneh-men 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) ange-boten. Diese Lizenz erlaubt die kostenfreie, kommerzielle und nichtkommerzielle Nutzungsowie die Verbreitung des Quelltextes.

Die Software versteht sich nicht als Entwicklungswerkzeug. Vielmehr wird eine einheit-liche Plattform zur Verfügung gestellt, für die Werkzeuge entwickelt werden können, dieals Plugins in die Eclipse-Plattform einbinden lassen. Die Eclipse-Software selbst enthältzunächst nur wenige Plugins. Darunter befinden sich eine komplette Entwicklungsumge-bung für Java (Java Development Tools, JDT), für Eclipse-Plugins (Plugin DevelopmentEnvironment, PDE) sowie Unterstützung für das Versionsverwaltungssystem CVS (Con-current Versions System).

32

4 Technologien und Werkzeuge der MDSD 4.1 Eclipse

Weitere Plugins werden vom Eclipse-Projekt sowie von Drittanbietern zum Download be-reitgestellt. Speziell für die verschiedenen Aspekte des Entwicklungsprozesses existierenPlugins für Programmiersprachen, Modellierung, Versionierung, Tests, Deployment so-wie Datenbankverwaltung. Die Erstellung von Java-Enterprise-Anwendungen wird durchProjekte wie das Web Tools Project (WTP) und durch Plugins für Frameworks (z. B.Spring IDE [Sprb]) und Anwendungsserver (z. B. JBoss Tools [JBo]) umfassend unter-stützt.

4.1.1 Plugin-Mechanismus

Die Idee, der Plattform durch die Erweiterung mittels Plugins zusätzliche Funktionali-tät zu verleihen, ist das herausragende Merkmal der Eclipse-Software. Der technologi-sche Kern dieses Konzepts sind die Extension Points (Erweiterungspunkte): Ein Pluginbietet die Möglichkeit, von anderen Plugins erweitert zu werden, indem es eine Erweite-rungsschnittstelle, also einen Extension Point, zur Verfügung stellt. Die anderen Pluginswiederum definieren eine Extension (Erweiterung) zu diesem Extension Point und füllendiese mit eigener Implementierung. Über ein Pluginverzeichnis werden zur Laufzeit alleaktiven Extensions eines Extension Points ermittelt und deren Implementierung ausge-führt. Abbildung 4.1 zeigt exemplarisch die Definition und Erweiterung eines ExtensionPoints. Eine ausfü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

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 zurErstellung von strukturierten Datenmodellen. Es bietet Werkzeuge und Laufzeitunter-stützung, um aus einem Modell Java-Quellcode zu erzeugen, mit dem das Modell durchEditoren und Generatoren bearbeitet werden kann. Das EMF gibt es seit 2002 und istderzeit in der Version 2.3 verfügbar.

4.2.1 Das Ecore-Metamodell

EMF spezifiziert ein eigenes Metamodell Ecore, das eine vereinfachte Untermenge derMOF darstellt. MOF ist das von der OMG erarbeitete Metamodell, das in der MDAals Grundlage für Metamodelle der Stufe M2 wie UML oder CWM dient (siehe Ab-schnitt 3.3.4). Ecore soll die Komplexität der MOF vermeiden und stattdessen den Fokusauf Werkzeugintegration setzen.

Wie auch bei MOF gibt es oberhalb des Ecore-Metamodells kein weiteres Metamo-dell. Ecore ist ebenfalls ein EMF-Modell und beschreibt sich somit selbst; ein Meta-modell auf Ebene M4 ist nicht nötig [B+03, S. 15]. Abbildung 4.2 zeigt die Ecore-Modellklassenhierarchie und verdeutlicht die Ähnlichkeit des Ecore-Metamodells zumobjektorientierten Klassenmodell der MOF/UML.

EMF-Modelle können auf vielfältige Weise erzeugt werden: Zum einen bringt das EMF-Framework einen Modelleditor mit, der das Modell in einer Baumstruktur anzeigt unddie Bearbeitung des Modells ermöglicht. Eine andere Möglichkeit ist das Importiereneines Modells aus annotierten Java-Schnittstellen, XML Schemata (XSD) oder UML-Werkzeugen. Man kann dies als eine Abstraktion über die konkrete Syntax des Modellsbetrachten; die abstrakte Syntax definiert Ecore.

EMF serialisiert Ecore-basierte Modelle in XMI-Dateien und ermöglicht damit ebensowie MOF das Weiterreichen von Modellen entlang einer Werkzeugkette, wobei EMF dieIntegration in die Eclipse-Plattform in den Vordergrund stellt.

34


Abbildung 4.2: Ecore-Klassenhierarchie

4.2.2 Codegenerierung

Das Eclipse Modeling Framework generiert aus EMF-Modellen Java-Quellcode, der vonEditoren sowie Transformatoren und Codegeneratoren genutzt werden kann. Zuvor er-weitert EMF das Ecore-basierte Modell (.ecore) in ein Generierungsmodell (.genmodel),das zusätzliche zur Codegenerierung nötige Informationen enthält. Die Generierung er-folgt immer von diesem Generierungsmodell aus und umfasst die folgenden Teilschrit-te1:

Model Erzeugt Schnittstellen- und Implementierungsklassen für alle Klassen im Modell.

Edit Erstellt Implementierungsklassen, die die Modellklassen für die Bearbeitung undVisualisierung anpassen.

Editor Erstellt einen (baum-)strukturierten Editor für Instanzen des Modells.

Test Generiert Unittests für die Modellklassen.

1Dabei müssen nicht alle Teilschritte durchgeführt werden. Je nach Anwendungsfall reicht z. B. auchdie Erstellung der Modellklassen aus.

35


4.2.3 Erstellung grafischer Editoren

Die Erstellung und Bearbeitung von EMF-Modellinstanzen kann mit dem generiertenBaumeditor erfolgen. Diese Art der Visualisierung ist aber nicht immer von Vorteil, vorallem da die Beziehungen zwischen Elemente nicht ausreichend darstellbar sind. Dahergibt es die Möglichkeit, mit Hilfe der Frameworks GEF und GMF einen grafischen Mo-delleditor zu erstellen, der den speziellen Anforderungen an die Darstellung des Modellsgerecht wird.

Graphical Editing Framework

Das Graphical Editing Framework (GEF) [GEF] ist ein Framework zur Erstellung grafi-scher Editoren und gehört ebenfalls zum Eclipse Modeling Project. Es stellt u. a. folgendeFunktionen zur Verfügung:

• Figuren und Formen, die sich miteinander verbinden lassen

• Ein Überblicksfenster zur schnellen Navigation

• Eine Werkzeugleiste für die Erstellung und Markierung von Figuren

• Grafische und hierarchische Visualisierung

• Druckerausgabe

Graphical Modeling Framework

Das Graphical Modeling Framework (GMF) [GMF] stellt eine Brücke zwischen EMF undGEF dar. Mit Hilfe von Wizards und hierarchischen Editoren lassen sich so aus EMF-Modellen grafische Editoren erzeugen. Der Erstellungsprozess umfasst mehrere Schritteund wird im Eclipse-View GMF Dashboard dargestellt (Abbildung 4.3). In jedem Pro-zessschritt wird ein bestimmtes Modell erstellt, das über einen hierarchischen Editorangesehen und bearbeitet werden kann.

Prozessschritte:

36


Abbildung 4.3: GMF Dashboard

1. Das EMF-Modell und das für die Generierung angepasste EMF-Generierungsmo-dell (siehe Abschnitt 4.2) müssen vorhanden sein. Sie bilden die Grundlage für dieErstellung des grafischen Editors.

2. Klassen aus dem EMF-Modell werden dann auf grafische Figuren abgebildet. DieMapping-Informationen werden im Grafikdefinitionsmodell gespeichert. Damit istfestgelegt, welche Informationen des Modells der Editor anzeigen und bearbeitenkann.

3. Wie im vorigen Abschnitt 4.2.3 erwähnt, bietet das GEF die Möglichkeit, eineWerkzeugleiste anzuzeigen, welche Schaltflächen beinhaltet, mit denen neue For-men und Verbindungen auf der Editoroberfläche hinzugefügt werden können. DasMapping zwischen Klassen und Attributen des Modells und Schaltflächen dieserWerkzeugleiste wird im Werkzeugdefinitionsmodell gespeichert.

4. Im nächsten Schritt werden diese beiden Modelle zusammengefasst und um dasEMF-Modell ergänzt. Dieses dreiteilige Modell heißt Mapping-Modell.

5. Das Mapping-Modell wird dann in ein Generatormodell transformiert, das für dieGenerierung des Editor-Quellcodes angepasst ist.

6. Zuletzt wird aus dem Generatormodell der Quellcode erzeugt. Der Editor ist fertigund kann z. B. als Eclipse-Plugin zur Verfügung gestellt werden.

37

4 Technologien und Werkzeuge der MDSD 4.3 openArchitectureWare

Die Bearbeitung des grafischen EMF-Modells mit dem erstellten Editor bewirkt immereine Bearbeitung des eigentlichen EMF-Modells. Das heißt, das EMF-Modell und seinegrafische Repräsentation werden vom Framework stets synchron gehalten.

4.2.4 Anwendungsgebiete

Das Eclipse Modeling Framework wird vor allem im Umfeld von Eclipse und Java im-mer häufiger zur Definition von (Meta-)Modellen verwendet. Zahlreiche Metamodellewurden in das Ecore-Format übertragen, so zum Beispiel das Java-Metamodell2. DasUML2-Projekt der Model Development Tools (MDT) [UML] hat die wichtigsten UML-Metamodelle in EMF implementiert, sodass auch mit EMF-Mitteln UML-Modelle er-stellt werden können.

Das Generatorframework openArchitectureWare, das im nächsten Abschnitt vorgestelltwird, kann EMF-basierte Modelle lesen und zur Modelltransformation verwenden. Mitt-lerweile sind auch einige Modellierungswerkzeuge, wie beispielsweise MagicDraw [NM],in der Lage, EMF-Modelle zu importieren und exportieren. Die Nutzung von EMF in dermodellgetriebenen Softwareentwicklung als Alternative zu den OMG-Standards ist damitein gangbarer Weg, zumal derzeit keine weiteren MOF-Implementierungen existieren.

4.3 openArchitectureWare

openArchitectureWare (oAW) [OAW] ist ein Open-Source-Framework für modellgetrie-bene Softwareentwicklung. Es hat sich aus dem b+m Generator Framework der b+mInformatik AG entwickelt und ist mittlerweile ein Unterprojekt der Generative ModelingTechnologies (GMT) [GMT]. oAW versteht sich als eine Werkzeugsuite, die auf einem inJava implementierten Generatorframework basiert [Vö07] und zum Ziel hat, eine Infra-struktur zur Entwicklung von Generatoren bereitzustellen3. Da es sich um ein Frameworkhandelt, sind die einzelnen Komponenten anpassbar: So können z. B. beliebige Modell-formate, Metamodelle und Ausgabeformate durch oAW verarbeitet werden. Das Projektlegt die Betonung deutlich auf den Frameworkcharakter. Vorgefertigte DSLs oder Trans-formationsvorlagen für bestimmte Zielarchitekturen werder daher nicht angeboten. Die

2Das Java EMF Model (JEM) ist Teil des Visual-Editor-Projektes [VE].3

”a tool for building MDSD/MDA tools“ [Vö07, S. 1]

38


Open-Source-Plattform Fornax Platform [For] entwickelt solche Komponenten (Cart-ridges) speziell für die Nutzung mit openArchitectureWare.

4.3.1 Bestandteile

Im Folgenden werden die Bestandteile von oAW 4.1.2 vorgestellt und anschließend wirdein typischer Generatorlauf skizziert.

Workflow-Engine

Die Ausführung eines oAW-basierte Generators wird über die Workflow Engine gesteuert[EV]. Sie ermöglicht die sequenzielle Abarbeitung vordefinierter Komponenten wie Mo-dellinstanziierung, -validierung und -transformation. Der Workflow wird in einer XML-Datei festgelegt und benutzt eine ähnliche Syntax wie das Erstellungswerkzeug ApacheAnt [Ant]. Konzepte wie das Definieren von Eigenschaften (Properties) und das Refe-renzieren weitere Workflow-Dateien sind ebenfalls aus Ant bekannt. Die Ausführung ei-nes oAW-Workflows kann über das Workflow-API (Application Programming Interface),einen Ant-Task, die Eclipse-Oberfläche oder über einen Kommandozeilenaufruf angesto-ßen werden.

Typsystem und Expression Language

openArchitectureWare bringt ein eigenes Typsystem mit – eine Abstraktionsschicht überdie verschiedenen Metamodelle, die als Eingabe für eine Generierung verwendet werdenkönnen. Bei der Instanziierung eines Metamodells wird dieses in das Typsystem umge-setzt. Im Umfang der oAW-Distribution sind bereits Adaptionen für einige Metamodelle,darunter Java, EMF und UML-Profile, vorhanden. Das Typsystem beinhaltet einfacheDatentypen wie int, boolean und String sowie Datenstrukturen (Listen, Mengen, . . . ).Es ist Teil des Expression Frameworks [Effb], einer OCL-ähnlichen Sprache, die Aus-drücke für den Zugriff auf Modellelemente definiert. Da die oAW-spezifischen Sprachendas Expressions Framework benutzen, ist die Verarbeitung von Modellelementen einheit-lich und die Verwendung der konkreten Metamodelle vollkommen transparent.

39


Templatesprache Xpand

Mit der Templatesprache Xpand lassen sich Modelltransformationen beschreiben [EK].Dabei sind Xpand-Templates besonders für M2C4-Transformationen geeignet. Der Zu-griff auf die Modellelemente geschieht vollständig über die Expression Language, sodassModelldaten aus unabhängig voneinander instanziierten Modellen für die Erstellung vonAusgabecode einheitlich zur Verfügung stehen. Zusätzlich können Xtend-Erweiterungeneingebunden werden (siehe nächster Abschnitt zu Xtend). Xpand stellt auch Mittel zuraspektorientierten Programmierung (AOP) bereit [EK, S. 12f.]. So sind bereits defi-nierte Templates nicht-invasiv erweiterbar, was vor allem hilfreich ist, wenn allgemei-ne Transformationen durch zieltechnologiespezifische Implementierungen ergänzt werdensollen.

Erweiterungssprache Xtend

Die Erweiterungssprache Xtend hat mehrere Anwendungsfälle [Effc]: Zum einen könnendie in Form des oAW-eigenen Typsystems vorliegenden Modelle durch in Xtend definier-te Metamodell-Extensions dynamisch um zieltechnologiespezifische Inhalte angereichertwerden. Diese Informationen möchte man im Allgemeinen nicht im Metamodell unter-bringen, da sie nicht Gegenstand des Domänenwissens sind. Extensions können durchAusdrücke der Expression Language formuliert werden. Darüber hinaus besteht auch dieMöglichkeit, die Erweiterungen durch Java-Methoden zu implementieren. Dies zeigt dieMächtigkeit des Extension-Mechanismus in openArchitectureWare. Die Verwendung derMM-Extensions ist aus den oAW-Sprachen Xpand und Check heraus sowie über eineXtend-Komponente im Workflow möglich.

Die MM-Extensions sind nicht als Modell-zu-Modell-Transformationen (M2M) anzuse-hen, sondern ein pragmatischer Ansatz, um Modelle im Generierungsprozess mit nütz-lichen 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 aufge-baut und in einem Slot abgelegt, aus dem nachfolgende Workflow-Komponenten lesenkönnen. Die Transformationen werden dabei ausschließlich mit imperativen Sprachkon-

4Modell-zu-Code, oft auch allgemeiner Modell-zu-Text (M2T), wenn jegliche Art von Textdateien ge-meint ist.

40


strukten ausgedrückt. Xtend bietet damit weniger Ausdrucksmöglichkeiten als QVT-basierte Sprachen wie die ATL (vgl. die Ausführungen zu QVT auf S. 24 und ATL aufS. 44).

Validierungssprache Check

Um die Regeln für die Prüfung der statischen Semantik von Modellinstanzen zu be-schreiben, stellt oAW die Validierungssprache Check [Effa] bereit. Auch sie arbeitet mitdem oAW-Typsystem und kann auf Xtend-MM-Erweiterungen zugreifen. Die Spracheist eine Erweiterung der Expression Language und stellt damit ähnlich der OCL um-fangreiche sprachliche Mittel zur Formulierung von Validierungsregeln zur Verfügung.Check ist nützlich, um noch vor Ausführung von Modelltransformationen und Codeer-stellung die Semantik der Modelle zu validieren und gegebenenfalls den Workflow miteiner Fehlermeldung abzubrechen.

Oftmals ist es besser, die Zusicherungen bereits zur Modellierungszeit zu überprüfen,da eventuelle Fehler schon frühzeitig bemerkt werden. Das oAW-Framework enthält fürdiesen Zweck einen GMF-Adapter, mit dem in Check formulierte Prüfregeln direkt aufGMF-visualisierte Modelle angewendet werden können [OAW07, Kap. 10]. Dies geschiehtentweder während der Bearbeitung der grafischen Modelle (Live Constraints) oder aufVerlangen (Batch Constraints).

Textuelle DSLs mit Xtext

Domänenwissen lässt sich mitunter mit textuellen domänenspezifischen Sprachen besserdarstellen als mit grafischen Modellen, vor allem dann, wenn die Modellelemente vielText enthalten. oAW ermöglicht die Erstellung einer textuellen DSL durch das Xtext-Framework [Effd]. Ausgehend von einer Grammatik für die zu erstellende Sprache gene-riert Xtext einen Modellparser, ein EMF-Metamodell sowie einen Eclipse-Modelleditor.Parser und Metamodell bilden die Voraussetzung, um innerhalb eines Workflows ein inder generierten DSL formuliertes Modell zu instanziieren und somit für die Verarbeitungmit Xpand etc

Date post:	05-Apr-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Konzeption und Entwicklung einer Software Factory …fritzsch/SF/sbley_diploma...Hochschule f¨ur...

Documents