Architekturzentrierte Modellgetriebene Softwareentwicklung

TU Wien
Business Informatics Group
Institut für Softwaretechnik und Interaktive Systeme
Benedikt Weismann
Architekturzentrierte
Modellgetriebene Softwareentwicklung
- Fallbeispiel und Evaluierung
Magisterarbeit zur Erlangung des akademischen Grades
eines Magister der Sozial- und Wirtschaftswissenschaften
Eingereicht bei: o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel
Betreuender Assistent: Univ.-Ass. Dipl.-Ing. Dr. Gerhard Kramler
Wien, 15. September 2006

Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die
den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht habe.
Wien, 15. September 2006 Benedikt Weismann
ii

Danksagung
Ich möchte mich bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel und Univ.
-Ass. Dipl.-Ing. Dr. Gerhard Kramler für die Anregung zu dieser Magisterarbeit
und für die fachliche Unterstützung bei der Erstellung der Arbeit bedanken.
Mein besonderer Dank gilt meinen Eltern Margit und Christian Weismann, die
mir mein Studium und somit auch vorliegende Arbeit ermöglichten. Des Weiteren
möchte ich mich bei meinen Korrekturleserinnen Katharina Müller und Margit
Weismann für ihre wertvollen Hinweise herzlich bedanken.
iii

Kurzfassung
In den vergangenen zwei Jahrzehnten hat Software eine immer stärkere Be-
deutung in zahlreichen Geschäftsprozessen und alltäglichen Informationsflüssen
erlangt. Sie stellt gewissermaßen das Fundament für diese Abläufe dar. Software
ist somit zu einem bedeutenden Bestandteil vieler Unternehmen geworden. Als
Folge dessen wird nach immer neuen Methoden im Bereich des Software Engi-
neering gesucht, um die Entwicklungskosten zu senken, die Entwicklungszyklen
zu verkürzen und die Qualität des Endprodukts zu erhöhen.
Einer dieser Ansätze ist die Modellgetriebene Software Entwicklung (eng: Model
Driven Software Development, kurz MDSD). Bei MDSD wird - basierend auf
einem in den meisten Fällen graphischen Modell - durch Transformationen
ein lauffähiger Sourcecode erzeugt. Anders als bei bisherigen Vorgangsweisen,
haben Modelle im Rahmen von MDSD nicht vorrangig dokumentarischen Wert,
sondern sind gleichbedeutend mit Sourcecode. MDSD versucht neben den bereits
genannten Zielen auch den Grad an Wiederverwendung von Software zu steigern
und Expertenwissen zu bündeln.
Stahl und Völter beschreiben in ihrem Buch ” Modellgetriebene Software Ent-
wicklung“ einen pragmatischen Ansatz, um mit Hilfe von MDSD und bereits
heute verfügbaren Techniken den Infrastrukturcode einer Applikation bzw.
einer ganzen Software-Systemfamilie zu generieren. Diesen Ansatz bezeichnen
sie als architekturzentrierte-MDSD (eng: Architecture Centric MDSD, kurz
AC-MDSD), weil es sich bei der adressierten Domäne um den Bereich der
” Softwarearchitektur“ handelt. Es wird dabei versucht den Infrastrukturcode
einer definierten Software-Systemfamilie möglichst vollständig zu generieren.
Ziel dieser Magisterarbeit ist, AC-MDSD und den zur Umsetzung der Metho-
dik zur Verfügung stehenden Toolkit ” openArchitectureWare“ kennen zu lernen,
sowie die Praxistauglichkeit an Hand eines Fallbeispiels zu evaluieren. Als Fallbei-
spiel wird die Domäne ” Softwarearchitektur für E-Businesssysteme“ behandelt,
in deren Rahmen auf der Basis von Techniken aus dem J2EE-Bereich eine On-
linebuchhandlung realisiert wird. Neben diesen praktischen Aspekten, sollen die
für das Verständnis nötigen theoretischen Konzepte dargelegt werden und eine
Abgrenzung zu verwandten Methoden wie MDA erfolgen.
iv

Abstract
During the last two decades the importance of software to support business
processes and daily information flow raised continuously. Software is the basis
for these procedures and therefore it is an essential part in every day life and
business. Research on new methods of engineering software which offers lower
development costs, shorter development cycles and software solutions with higher
quality is the consequence of this trend.
Model Driven Software Development (MDSD) is one of these approaches. It is
based on the idea of generating executable source code from a mainly graphical
model. Contrary to traditional methods MDSD related models are equal to
source code and not just a medium for documentation. Besides of the already
named targets MDSD tries to enhance the reuse of existing software components
and to concentrate expert knowledge.
Stahl and Völter describe in their book ” Modellgetriebene Software Entwicklung“
( ” Model Driven Software Development“) a pragmatic way of generating the
infrastructure code of an application with the help of MDSD in combination
with already existing technologies. They call this approach architecture centric
MDSD (AC-MDSD) because the addressed domain is software architecture. It
is the aim to generate the complete infrastructure code of a family of software
systems with AC-MDSD.
The intention of this master thesis is to describe the ideas of AC-MDSD and to
evaluate the method as well as the supporting toolkit ” openArchitectureWare“ on
the basis of a case study. The case study implements with the help of technologies
taken from the J2EE area an online book store. The addressed domain is called
” software architecture for e-business systems“. Besides of these technical aspects
the theoretical background of MDSD, which is necessary for understanding the
approach, is explained. Additionally the differences and similarities with related
methods, e.g., MDA are discussed.
v

Inhaltsverzeichnis
1 Einleitung 3
2 MDSD, AC-MDSD und Begriffsdefinitionen 6
2.1 Der MDSD-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Die MDSD-Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Terminologie und Allgemeine Konzepte . . . . . . . . . . . . . . . 10
2.4 AC-MDSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Vorurteile gegenüber Modellgetriebenen Entwicklungsansätzen . . 18
3 Vergleich mit verwandten Methodiken 20
3.1 MDSD vs. MDA - Gemeinsamkeiten und Unterschiede . . . . . . 20
3.2 MDSD vs. Software Product Line Engineering - Mögliche Syner-
gieeffekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 MDSD vs. Agile Software Development - Ist eine Kombination
möglich? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Entwicklungsprozess, Vorgehensweise und Best Practices 30
4.1 Iterative, zweigleisige Entwicklung . . . . . . . . . . . . . . . . . . 30
4.2 Architektur-Entwicklungsstrang . . . . . . . . . . . . . . . . . . . 31
4.3 Anwendungs-Entwicklungsstrang . . . . . . . . . . . . . . . . . . 35
5 Einführung in openArchitectureWare 37
5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Funktionsweise des Generators . . . . . . . . . . . . . . . . . . . . 38
5.3 Eclipse Plugin: Installation und erste Schritte . . . . . . . . . . . 39
5.4 Ablaufsteuerung mittels des Workflow Konzepts . . . . . . . . . . 45
5.5 Modellierung und Metamodellentwicklung mit Hilfe von UML . . 46
5.6 Templateentwicklung mittels Xpand . . . . . . . . . . . . . . . . . 51
5.7 Expressions Framework . . . . . . . . . . . . . . . . . . . . . . . . 56
5.8 Extend Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1

Inhaltsverzeichnis 2
5.9 Constraint Checking . . . . . . . . . . . . . . . . . . . . . . . . . 58
6 Fallbeispiel 60
6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Das Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . 61
6.3 Domäne und Technologien . . . . . . . . . . . . . . . . . . . . . . 64
6.4 Domänenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5 Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6 Transformationsvorschriften - Xpand . . . . . . . . . . . . . . . . 89
6.7 Ablaufsteuerung - Workflow . . . . . . . . . . . . . . . . . . . . . 93
6.8 Erweiterungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . 96
6.9 Vorgangsweise, Herausforderungen und Codeanalyse . . . . . . . . 98
7 Evaluierung 104
7.1 Wann ist MDSD sinnvoll? . . . . . . . . . . . . . . . . . . . . . . 104
7.2 Vorteile und betriebswirtschaftliche Auswirkungen . . . . . . . . . 106
7.3 Nötige Investitionen . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.4 Mögliche Hindernisse für eine Verbreitung . . . . . . . . . . . . . 111
8 Zusammenfassung und Ausblick 113
Abbildungsverzeichnis 116
Tabellenverzeichnis 118
Listings 119
Literaturverzeichnis 120

1 Einleitung
In den vergangenen zwei Jahrzehnten hat Software eine immer stärkere Be-
deutung in zahlreichen Geschäftsprozessen und alltäglichen Informationsflüssen
erlangt. Sie stellt gewissermaßen, das Fundament für diese Abläufe dar. Software
ist somit zu einem bedeutenden Bestandteil vieler Unternehmen geworden.
Dem gegenüber steht eine Vielzahl an Projekten bei denen sowohl die Budgets
überschritten als auch die Designziele verfehlt werden. Viele Hersteller sind
so mit ständig wechselnden Implementierungstechnologien beschäftigt, dass
keine Zeit für Produktivitätsüberlegungen und Risikominimierung bleibt. Weder
schwergewichtige dokumentenlastige Entwicklungsprozesse noch CASE-Tools 1
können/konnten Abhilfe schaffen.
In den letzten Jahren rückten aus diesen Gründen sowohl agile Entwicklungs-
prozesse als auch die Bedeutung von Modellen für das Software Engineering
vermehrt ins Zentrum des Interesses. Die steigende Bedeutung von Modellen ist
nicht zuletzt auf die Definition und Verbreitung der Unified Modeling Language
kurz UML zurückzuführen. Es gibt mittlerweile eine Vielzahl an Modellierungs-
tools, die in der Lage sind aus dem Modell einer Anwendung Teile der späteren
Implementierung zu generieren. Problematisch in diesem Zusammenhang ist
der Umstand, dass die Domäne in der die Anwendung angesiedelt ist, keinerlei
Auswirkung auf den generierten Sourcecode hat. Es wird auf Basis eines ” One-
Size-Fits-All!“-Ansatzes gearbeitet. Der generierte Code muss somit für alle
Eventualitäten und Einsatzbereiche geeignet sein. Das führt leider oft zu einer
Unzulänglichkeit des Generats und erfordert viel manuelle Zusatzarbeit um die
Lücke zwischen Generat und Zielplattform zu schließen. Zudem sind die meisten
dieser Tools nicht in der Lage Designänderungen iterativ auf einen bestehenden
Quellcode zu übertragen. Letzten Endes nehmen die Modelle hier nur den Status
einer Dokumentation ein und fallen auf Grund der rein gedanklichen Verbindung
zwischen Modell und Sourcecode oftmals dem Zeitdruck zum Opfer.
Einen anderen Weg gehen modellgetriebene Ansätze wie Model Driven Software
Development kurz MDSD oder Model Driven Architecture kurz MDA. Hier
1 Computer Aided Software Engineering-Tools unterstützen Softwareentwickler bei Planung
Design und Umsetzung einer Anwendung (siehe auch [cas06]).
3

1 Einleitung 4
haben Modelle den selben Stellenwert wie Sourcecode, da ein Großteil der
Implementierung aus ihnen generiert wird. Der Generierungsfaktor liegt bei
diesen Techniken deutlich höher, da streng domänenspezifisch gearbeitet wird.
Modellgetriebene Ansätze versuchen einen Großteil der Implementierungsarbeit
auf die gegenüber dem Quellcode abstraktere Ebene formaler domänenorien-
tierter Modelle zu verlagern. So werden die zentralen Konstruktionsparadigmen
einer Anwendung in unverschleierter Form bewahrt, was auf dem detaillierten
Niveau von Quellcode nicht mehr möglich ist.
Den Ausgangspunkt dieser Arbeit bildet das Buch Modellgetriebene Softwareent-
wicklung - Techniken, Engineering, Management von Thomas Stahl und Markus
Völter ( [SV05]) in dem ein pragmatischer modellgetriebener Ansatz, die so
genannte Architekurzentrierte-MDSD, vorgestellt wird. Dieser Ansatz fokussiert
auf die Domäne ” Softwarearchitektur“ und arbeitet mit technisch motivierten
Modellen. Ziel ist es anhand eines Fallbeispiels die Praxistauglichkeit der Metho-
dik und des dazu passenden Open Source MDSD-Tools openArchitectureWare
kurz oAW ( [oaw05]) festzustellen.
Die Arbeit gliedert sich in drei Bereiche. Der erste Teil (Kapitel 2 bis 4) gibt
eine Einführung in die theoretischen Grundlagen, die dem besseren Verständnis
des zweiten praxisorientierten Abschnitts (Kapitel 5 bis 6) dienen. Der dritte
Teil(Kapitel 7) beschließt die Arbeit mit einer Evaluierung auf Basis betriebs-
wirtschaftlicher Kriterien.
Kapitel 2 erklärt den Ansatz von MDSD im Allgemeinen und von AC-MDSD im
Speziellen. Des Weiteren werden die zentralen Begriffe der Methodik definiert.
Kapitel 3 vergleicht MDSD mit verwandten Ansätzen wie MDA beziehungs-
weise mit stark beeinflussenden wie Software Product Line Engineering und
Agile Software Development. In Kapitel 4 wird beschrieben welche Tätigkeiten
ein Entwicklungsprozess mit MDSD umfasst, und wie er koordiniert werden kann.
Der praktische Teil der Arbeit wird mit Kapitel 5 eingeleitet, das eine Einführung
in das benutzte Tool openArchitectureWare gibt. Im folgenden Kapitel wird
das Fallbeispiel und dessen Umsetzung mit Hilfe von oAW geschildert. Es wird
explizit auf die verwendeten Technologien, die Softwarearchitektur und das
beschreibende Metamodell eingegangen. Abgeschlossen wird das Kapitel mit
einer Beschreibung der Vorgangsweise, den Herausforderungen und einer Analyse
des Quellcodes hinsichtlich des erzielten Generierungsfaktors.

1 Einleitung 5
Im dritten Teil erfolgt die Evaluierung in Hinblick auf die Methodik aus dem
betriebswirtschaftlicher Sicht. Es wird gezeigt welche Vorteile MDSD für eine
Organisation im Gesamten mit sich bringen kann, und wodurch der einzel-
ne Entwickler profitiert. Des Weiteren werden nötige Investitionen, die die
Einführung der Methodik mit sich bringt, erörtert und die Frage nach sinnvollen
Einsatzgebieten gestellt. Darüber hinaus werden mögliche Hindernisse für eine
Verbreitung aus heutiger Sicht diskutiert.
Sämtliche Daten zum Fallbeipiel aus Kapitel 6 befinden sich auch auf der der
Arbeit beiliegenden CD-ROM in Form eines Eclipse Workspaces.

2 MDSD, AC-MDSD und
Begriffsdefinitionen
2.1 Der MDSD-Ansatz
Jede Anwendung besteht aus einer Reihe von Konstruktionsparadigmen, deren
Art der Implementierung eine direkte Auswirkung auf Qualitätsmerkmale wie
Wiederverwendbarkeit, Wartbarkeit, Performance, etc. hat. Auf Ebene des
Quellcodes sind diese Muster nicht mehr klar erkennbar, da sie auf Grund des
geringen Abstraktionsniveaus von zahlreichen Details verschleiert werden. Aber
gerade diese Ideen hinter einer Software, in die ein Großteil des intellektuellen
Aufwands während der Entwicklung einfließt, sind der wertvollste weil langle-
bigste Bestandteil.
Aus eben genannten Gründen wird in vielen Projekten versucht, die interne
Struktur in Modellen zu dokumentieren um sie fassbar zu machen. Problematisch
ist in diesem Zusammenhang, dass zwischen Modell und Code nur eine gedank-
liche Verbindung besteht, die später von einem Entwickler manuell umgesetzt
werden muss. Das Modell stellt also nur eine Form der Dokumentation dar. Diese
Arbeitsweise nennt man modellbasiert.
Auf Grund des für die Projektbeteiligten nicht klar erkennbaren Zusatznutzen
der Modelle, fallen diese meist dem Zeitdruck zum Opfer, oder sind nicht
auf dem aktuellen Stand, da sie als reiner Overhead betrachtet werden. Auch
so genannte Round-trip Engineering Tools 1 schaffen meist keine Abhilfe, da
es mit ihnen nicht möglich ist echte Abstraktion zu schaffen. Die von diesen
Tools erzeugten Modelle liegen auf dem selben Abstraktionsniveau, wie der
Programmcode. Echte Abstraktion hingegen ist eine intellektuelle Tätigkeit, die
einen Informationsgewinn darstellt und daher manuell durchgeführt werden muss.
1 Round-trip Engineering Tools führen eine Synchronisation zwischen einem Modell und dem
zugehörigen Quellcode durch. Das Abstraktionsniveau des Modells rutscht dabei allerdings
auf jenes des Quellcodes ab.
6

2 MDSD, AC-MDSD und Begriffsdefinitionen 7
Einen anderen Weg beschreitet die modellgetriebene Vorgangsweise, bei der die
entworfenen Modelle den selben Stellenwert wie der Quellcode einnehmen, da
sie gleichbedeutend mit ihm sind. Der Übergang vom Modell zum Code wird
automatisiert mit Hilfe eines Generators und einer Reihe definierter Transfor-
mationsvorschriften vorgenommen. Diesen Ansatz nennt man Modellgetriebene
Softwareentwicklung oder Model Driven Software Development kurz MDSD.
Bei MDSD werden Modelle als abstrakt und formal zugleich angesehen. Sie
sind abstrakt, da implementierungsspezifische Details weggelassen werden.
Die Modelle zeigen ausschließlich Eigenschaften, die das Verständnis für die
Problemstellung fördern. Formal sind diese Modelle, da sie sich an einer Domain
Specific Language (DSL) orientieren.
Bei MDSD stehen die benutzten Modelle immer im Kontext eines abgegrenzten
Problemraums, der Domäne. Die Konzepte dieser Domäne werden mit einer
für sie spezifischen Sprache beschrieben, der DSL. Eine DSL kann zum Beispiel
durch ein UML-Profil abgebildet werden.
Ein Hauptbestandteil der DSL ist das Metamodell der Domäne (siehe Abschnitt
2.3.1). Es ist auch dem Generator bekannt. Auf diese Weise kann aus dem Modell
bedeutend mehr ” herausgeholt“ werden, als es mit einem allgemeinen domänenu-
nabhängigen Generator der Fall ist. Der MDSD-Ansatz unterscheidet sich somit
auch auf Seite der Generatoren von aktuellen CASE-Tools, bei denen zumeist
ein ” One Size fits all!“-Ansatz verfolgt wird. Hier wird nicht auf den spezifischen
Einsatzzweck einer Software geachtet, sondern das Generat folgt stets den selben
Designparadigmen. Dadurch ist einerseits der erzielbare Generierungsfaktor
niedriger als bei einem domänenspezifischen Ansatz und andererseits wird mit
hoher Wahrscheinlichkeit den geforderten Qualitätskriterien nicht Genüge getan.
Um die Generierung zu vereinfachen und den erzeugten Quellcode nicht auf der
” nackten“ Programmiersprache aufbauen zu müssen, werden domänenspezifische
Plattformen eingesetzt. Sie bilden den zweiten Eckpfeiler von MDSD. Eine Platt-
form setzt sich aus Komponenten und Frameworks zusammen. Diese Bestandteile
sind für alle Anwendungen einer Domäne gleich. Der Einsatz höherwertiger APIs
erleichtert den Entwurf der nötigen Transformationsvorschriften ungemein, da
dem Generat ein Stück des Weges entgegengekommen wird.
Abbildung 2.1 stellt die Zusammenhänge bei der Entwicklung mit MDSD dar.
Betrachtet man den Quellcode eines beliebigen Mitglieds einer Softwaresys-

2 MDSD, AC-MDSD und Begriffsdefinitionen 8
Abbildung 2.1: Grundidee Modellgetriebener Softwareentwicklung (Quelle:
[SV05] Seite 17)
temfamilie (siehe Abschnitt 2.3.3) handelt es sich dabei auf den ersten Blick
um ein Unikat. Strukturiert man den Code allerdings um und kategorisiert
ihn, ergeben sich drei Bereiche. Zum einen existiert ein generischer Codeanteil,
der über alle Anwendungen der Systemfamilie gleich ist. Zum anderen verfügt
jedes ” Familienmitglied“ über einen Quellcode, der sich schematisch wiederholt
und bestimmten Designmustern folgt. Der dritte Bereich wird durch einen
individuellen Codeanteil gebildet. Dieser ist von Anwendung zu Anwendung
unterschiedlich und folgt keinen durchgängigen Schemata.
Es ist nun nahe liegend den gemeinsamen, generischen Codeanteil auszulagern.
Das heißt, ihn nur einmal zu implementieren und anschließend wiederzuverwen-
den. Diese Komponenten bilden zusammen die domänenspezifische Plattform.
Die Implementierung des schematischen Codes ist in vielen Fällen eine reine ” Co-
py & Paste“ Arbeit mit anschließender Nachbearbeitung. Diese Arbeitsschritte
können durch einen Generator automatisiert werden. Der Generator benötigt für
ein effizientes Arbeiten drei Dinge: erstens ein Modell der Applikation, zweitens
eine DSL an der sich auch die Modelle orientieren und drittens eine Reihe von
Transformationsvorschriften zur Ausgabesteuerung. Der individuelle Codeanteil,
zum Beispiel fachspezifische Logik, muss manuell von einem Entwickler ergänzt
werden.
Zusammengefasst ist das Ziel von MDSD die automatisierte Erstellung von
schematischen Codeanteilen der Applikationen einer Software-Systemfamilie,

2 MDSD, AC-MDSD und Begriffsdefinitionen 9
aufbauend auf einer domänenspezifischen Plattform. Eine eingehende Behand-
lung, der Ziele die mit MDSD verfolgt werden, nimmt Abschnitt 2.2 vor.
Jorn Bettin, eine der treibenden Kräfte hinter der MDSD-Initiative, formuliert
in [Bet06d] Seite 8 die im Folgenden frei zitierten Themenkreise, die von MDSD
angeschnitten werden:
• Domänenanalyse
• Metamodellierung
• Modellgetriebene Generierung
• Templatesprachen
• Domänengetriebene Framework-Entwicklung
• Prinzipien agiler Softwareentwicklung
• Entwicklung und Nutzung von Open Source Infrastruktur
2.2 Die MDSD-Ziele
Stahl und Völter beschreiben in [SV05] Abschnitt 2.2 die von MDSD verfolgten
Ziele. Sie weisen explizit darauf hin, dass diese nicht neu sind, sondern ” so etwas
wie den >> heiligenGral

2 MDSD, AC-MDSD und Begriffsdefinitionen 10
• Zentrale Fehlerbehebung: Fehler, die im schematischen Codeanteil auf-
treten, können an einer Stelle - den Transformationsvorschriften - behoben
werden. Danach sind sie in allen generierten Codeteilen beseitigt und treten
auch in zukünftigen Anwendungen nicht mehr auf. Darüber hinaus bieten
die Transformationsvorschriften Gelegenheit querschnittlich verteilte Imple-
mentierungsaspekte gebündelt umzusetzen.
• Steigerung der Wiederverwendung: Architektur, DSL und Transfor-
mationsvorschriften werden einmal erstellt und anschließend laufend ver-
bessert. Diese Artefakte werden, ähnlich einer Produktionsstraße in der
industriellen Fertigung, zur Erstellung beliebig vieler Anwendungen her-
angezogen. Durch diese Vorgangsweise kommt es auch zu einer Bündelung
von Expertenwissen.
• Handhabbarkeit von Komplexität durch Abstraktion: Problemori-
entierte Modellierungssprachen sind weit abstrakter als Programmierspra-
chen. Dadurch bleibt viel implementierungsspezifische Komplexität verbor-
gen.
Stahl und Völter halten abschließend fest, dass die zwei Ziele Interoperabilität und
Portabilität des sehr verwandten MDA-Ansatzes (siehe 3.1) erst durch die von der
Object Managment Group (OMG) angestrebten Standardisierungen ermöglicht
werden. Zur Zeit fallen sie einem durchaus angebrachten Pragmatismus zum Op-
fer (siehe Abschnitt 3.1.2).
2.3 Terminologie und Allgemeine Konzepte
Die in MDSD genutzte Terminologie ist dem sehr verwandten Ansatz Model
Driven Architecture kurz MDA entliehen. Dieser Ansatz wurde von der OMG
entwickelt und standardisiert. Auf MDA wird im Rahmen eines Vergleiches in
Abschnitt 3.1 näher eingegangen.
Die hier enthaltenen Informationen stammen aus [SV05] Kapitel 2 und 4,
[mda06a] und [Fra03].
2.3.1 Modellierung
Domäne
Eine Domäne stellt ein begrenztes Wissensgebiet dar. Sie spiegelt den zu bear-
beitenden Problemraum wieder und ist somit der Startpunkt der Modellierung.

2 MDSD, AC-MDSD und Begriffsdefinitionen 11
Bevor ein Metamodell bzw. eine DSL zur Beschreibung der Konzepte einer
Domäne entworfen werden kann, muss diese abgegrenzt sein. Diesen Vorgang
nennt man Domain Scoping (siehe [PBL05] Seite 188 bzw. Abschnitt 3.2).
Eine Domäne kann sowohl fachlich als auch technisch motiviert sein. Eine
fachliche Domäne ist beispielsweise der Bereich ” Bankwesen“. Darin enthaltene
Konzepte sind ” Konto“, ” Kredit“, ” Sparbuch“, ” Bankomat“, etc. Eine technisch
motivierte Domäne ” Softwarearchitektur für E-Business-Systeme“ wird im
Fallbeispiel in Kapitel 6 behandelt. Im Metamodell, dass die Domänenkonzepte
beschreibt sind Konstrukte enthalten wie ” Presentation“, ” EntityObject“, ” Ac-
titvityController“, etc.
Ab einer gewissen Größe ist es sinnvoll eine Domäne in Subdomänen zu zertei-
len, was zu klareren Modellen führt und die Komplexität verringert. Technische
Subdomänen sind typischerweise Aspekte wie graphische Oberflächen oder Per-
sistenz der Datenhaltung. In obigem Bankenbeispiel kann man Subdomänen wie
” Privatkunden“ und Firmenkunden“ einführen.
”
Metamodell
Ein Metamodell formalisiert die Strukturen einer Domäne und definiert somit
jene Konstrukte die später im Rahmen der Anwendungsmodelle zum Einsatz
kommen. Es bildet daher die Grundlage für eine Automatisierung im Rahmen
der Entwicklung.
Wie der Name mit der griechischen Vorsilbe ” meta“ - dt: über - zum Ausdruck
bringt, sagt ein Metamodell etwas über andere Modelle aus. In diesem Zusam-
menhang zu beachten ist, dass dieses ” über“ relativ vom Betrachter aus gesehen
ist. Je nach Betrachtungsebene kann ein Metamodell auch ” nur“ ein Modell
verkörpern. Beispielsweise ist das UML-Metamodell ein Modell der Meta Object
Facility kurz MOF (vgl. [Fra03] Kapitel 5). Umgekehrt muss ein Modell eines
Modells nicht zwangsweise ein Metamodell sein, sondern kann durchaus auch
nur einen Ausschnitt oder eine Aggregation darstellen (siehe [HKKR05]).
In einem Metamodell ist nicht nur die abstrakte Syntax einer DSL enthalten
sondern auch deren Wohlgeformtheitskriterien, die statische Semantik. Das heißt,
es wird zum Ausdruck gebracht wie die Sprachkonzepte in einem konkreten
Modell zu verwenden sind. Bei einem UML-Profil beispielsweise wären die
Stereotypdefinitionen Teil der abstrakten Syntax, wohingegen die definierten

2 MDSD, AC-MDSD und Begriffsdefinitionen 12
Constraints die statische Semantik bilden.
Die Vorteile der Verwendung von Metamodellen werden in [HKKR05] zusammen-
gefasst:
• Metamodelle erlauben eine präzisere und vor allem eindeutigere Definition
von Konstrukten, als es mit einer natürlichen sprachlichen Beschreibung
der Fall ist.
• Alle Instanzen eines Metamodells haben ein einheitliches Austauschformat,
das Metamodell.
• Modelle werden durch die Verwendung eines Metamodells computergestützt
überprüfbar, da es einen vorgegebenen Regelsatz gibt.
• Metamodelle sind nicht endgültig sondern können jederzeit verändert und
erweitert werden. Sie gestalten eine Sprache auf diese Weise flexibel.
Domänenspezifische Sprache
Eine Domänenspezifische Sprache oder Domain Specific Language kurz DSL
benötigt neben einem Metamodell noch eine Definition der (dynamischen) Se-
mantik. Mit anderen Worten der Modellierer muss die Konstrukte der Sprache
verstehen. Dazu gibt es zwei Möglichkeiten: entweder ist die Bedeutung eines
Konstrukts intuitiv verständlich oder es existiert eine natürliche sprachliche Be-
schreibung.
Modell vs .Formales Modell
Eine Auswahl an Definitionen für den Begriffe ” Modell“ im Zusammenhang mit
Softwareentwicklung:
Ein Modell ist eine abstrakte Repräsentation von Struktur, Funktion
oder Verhalten eines Systems. [SV05] Seite 20
Ein Modell ... beschreibt einen Aspekt eines konkret zu entwickeln-
den Systems. [HK99] Seite 67
A model of a system is a description of that system and its envi-
ronment for some certain purpose. [mda06a] Seite 2-2

2 MDSD, AC-MDSD und Begriffsdefinitionen 13
Modelle sind in einer bestimmten Modellierungssprache abgefasst. In vielen Fällen
ist das auf Grund ihrer weiten Verbreitung und Verständlichkeit die Unified Mo-
delling Language kurz UML. UML Modelle sind aber nicht per se formale Modelle.
Formale Modelle sind immer die Instanz eines Metamodells und orientieren sich
an den dort beschriebenen Konstrukten. Formal sind sie, da die Bedeutung der
verwendeten Konstrukte definiert ist, sie also festgelegten Formalismen folgen.
2.3.2 Plattform
Das Konzept der Plattform stammt aus der industriellen Fertigung und erlaubt
die kostengünstige Produktion kundenspezifischer Produkte, auf einer gemeinsa-
men Basis, im großen Rahmen. In einer Plattform sind jene Technologien ver-
einigt, die sich durch alle Produkte einer Produktfamilie ziehen. Gleichzeitig
wird bei Erstellung der Plattform darauf geachtet, dass die einzelnen Baustei-
ne flexibel genug sind, um über mehrere Produkte hinweg eingesetzt werden zu
können. [PBL05] definiert den Begriff ” Plattform“ folgendermaßen (siehe Seite
6):
A platform is any base of technologies on which other technologies
or processes are built.
Legt man diesen Gedanken auf Softwaresysteme um führt das zu folgender Defi-
nition:
A software platform is a set of software subsystems and interfaces
that form a common structure from which a set of derivative products
can be efficiently developed and produced. ( [PBL05] Seite 15)
MDSD hat das Konzept der Plattform dem Software Product Line Engineering
entliehen auf das in Abschnitt 3.2 näher eingegangen wird.
MDSD setzt reichhaltige domänenspezifische Plattformen bestehend aus Bi-
bliotheken, Frameworks, Basisklassen, etc. ein. Diese verringern den Abstand
zwischen den Konzepten einer Domäne und der Zielplattform, auf der die zu
entwickelnden Anwendungen laufen sollen. Je ausgereifter die Plattform desto
einfacher gestalten sich die nötigen Transformationen zur Codegenerierung.
Abbildung 2.2 zeigt den schichtförmigen Aufbau einer domänenspezifischen
Plattform und wie sie den Abstand zwischen technischer Plattform und gene-
riertem Code verringert.

2 MDSD, AC-MDSD und Begriffsdefinitionen 14
Abbildung 2.2: Anwendungen basierend auf einer domänspezifischen Plattform
(Quelle [Bet06d] Seite 43)
Im Laufe einer MDSD-Entwicklung wächst die Mächtigkeit der Plattform mit
dem Verständnis der Domäne, die Transformationen vereinfachen sich und der
manuell zu ergänzende Codeanteil verringert sich. Allerdings sollte die Platt-
formentwicklung nicht über strapaziert werden, da man sonst zur traditionellen
Entwicklung zurückkehrt und die Vorteile modellgetriebener Entwicklung verlo-
ren gehen. Applikationsspezifische Codeanteile und Logik sollten auch weiterhin
so weit wie möglich mit Hilfe der DSL modelliert und anschließend generiert
werden.
Jorn Bettin empfiehlt in [Bet06d] domänenspezifische Plattformen iterativ in-
krementell umzusetzen. Versuche ausgereifte Frameworks vorab mit einmaligem
Aufwand zu entwerfen, sind von vornherein zum Scheitern verurteilt. Stattdessen
ist es ratsam mit einem kleinen Framework zu starten und dieses schrittweise
je nach Bedarf weiterzuentwickeln. In den meisten Fällen ergibt sich der Bedarf
an Verbesserungen von selbst sobald die Umsetzung der Transformationen sich
schwierig gestaltet. Umgekehrt sind generative Ansätze oft eine elegante Lösung,
falls sich die Umsetzung von bestimmen Plattformkomponenten als zu umständ-
lich herausstellt.

2 MDSD, AC-MDSD und Begriffsdefinitionen 15
2.3.3 Software-Systemfamilien
Der Begriff der Software-Systemfamilie ist dem in Abschnitt 3.2 beschriebe-
nen Konzept des Software Product Line Engineering entliehen. Als Software-
Systemfamilie bezeichnet man alle jene Anwendungen, die auf einer gemeinsamen
Domänenarchitektur aufbauen.
Eine Domänenarchitektur setzt sich aus dem Metamodell einer Domäne, einer
zugehörigen Plattform und den nötigen Transformationen um die Konzepte des
Metamodells auf die Plattform zu übertragen, zusammen. Die Domänenarchitek-
tur ist somit das zentrale Konzept von MDSD.
Eine Domänenarchitektur legt fest welche Konzepte formal unterstützt und wie
sie auf die jeweilige Plattform übertragen werden. Sie ist immer relativ zur jewei-
ligen Plattform zu sehen. Von der Domänenarchitektur wird des Weiteren eine
hinreichende Flexibilität gefordert, um die Unterschiede zwischen den einzelnen
Mitgliedern der Software-Systemfamilie abbilden zu können.
2.4 AC-MDSD
Architekturzentrierte-Modellgetriebene Softwareentwicklung oder Architecture-
Centric MDSD kurz AC-MDSD ist eine MDSD-Ausprägung bei der das
Abstraktionsniveau der DSL auf Ebene der Softwarearchitektur liegt. Man
spricht daher auch von architekturzentriertem Design. Mit anderen Worten: ” Die
Domäne von AC-MDSD lautet >> Softwarearchitektur

2 MDSD, AC-MDSD und Begriffsdefinitionen 16
Abbildung 2.3: Prinzip architekturzentrierter MDSD (Quelle: [SV05] Seite 27)
ander nichts wissen. Aus diesem Grund liegt der Generierungsfaktor hier weit
unter den Möglichkeiten, die ein ganzheitlicher architekturzentrierter Ansatz bie-
ten kann. Zusammengefasst lautet das Ziel von AC-MDSD daher:
” Ganzheitliche Automation bei der Erstellung von Infrastrukturcode
bzw. Minimierung von redundantem, technischen Code in der Anwen-
dungsentwicklung.“( [SV05] Seite 25)
Die Grundlage für eine ganzheitliche Automatisierung bildet eine durchgängig
ausgearbeitete und formalisierte Softwarearchitektur. Je besser diese ausgearbei-
tet ist desto schematischer gestaltet sich der Sourcecode der darauf aufbauenden
Anwendungen und desto mehr Code kann mit Hilfe eines Generators erzeugt
werden.
Abbildung 2.3 verdeutlicht die Zusammenhänge bei der Entwicklung mit AC-
MDSD. Als Eingabe wird ein fachliches Modell der Anwendung benötigt, das
formal auf einer Architekturzentrierten DSL basiert. Als Ausgabe wird der ge-
samte Infrastrukturcode erzeugt, der bei modernen E-Businessanwendungen bis
zu 70% ausmachen kann (siehe [SV05] Seite 25). Die Modell-zu-Code Transfor-
mationen werden durch eine Reihe von Generator Templates festgelegt. Da der
generierte Code technisch motiviert ist, bleibt eine semantische Lücke, die von
einem Entwickler manuell mit fachspezifsicher Anwendungslogik aufzufüllen ist.
2.4.1 Merkmale
Im Folgenden werden bisher noch nicht genannte Merkmale von AC-MDSD auf-
gelistet und erklärt.

2 MDSD, AC-MDSD und Begriffsdefinitionen 17
• AC-MDSD unterstützt individuelle architektonische Anforde-
rungen. Die Ausgangsbasis für die Ableitung der Transformationsvor-
schriften bildet eine Referenzimplementierung. Das heißt, es wird nichts ge-
neriert, was nicht zuvor getestet und mittels der Referenzimplementierung
verifiziert werden konnte. Der generierte Sourcecode besitzt exakt dieselbe
Qualität wie die Referenzimplementierung.
• Softwaresystemfamilien statt Unikate: AC-MDSD zielt nicht nur auf
die Verbesserung des Entwicklungsprozesses einzelner Anwendungen ab,
sondern fördert auch die Wiederverwendung von einmal erstellten Arte-
fakten durch die Verwendung eines Generators und der Schaffung einer
Plattform.
• Keine 100% Generierung: Im Normalfall ist es nicht möglich bzw. sin-
voll eine Anwendung komplett zu generieren. Der Fokus der Domänenar-
chitektur ist in diesem Fall so schmal, dass sie nur eine Anwendung tragen
könnte, was den MDSD-Ansatz ad absurdum führen würde.
AC-MDSD ermöglicht in der Regel eine Generierung von 60-80% des Quell-
codes einer Applikation. Der Rest besteht aus fachlichen Aspekten die auf
Grund der technisch motivierten Domäne nicht modelliert werden können.
2.4.2 Einsatz
Markus Völter einer der geistigen Väter von AC-MDSD hält in einem Interview
mit Code Generation Network (siehe [Net06]) fest, dass AC-MDSD einen günsti-
gen Einstiegspunkt für den Aufbau einer Software-Systemfamilie mit MDSD bzw.
den Umstieg auf diese Entwicklungsmethodik bietet. Die primäre Konzentration
auf architektonische Aspekte ist aus mehreren Gründen sinnvoll. Erstens entfällt
durch die automatisierte Umstellung für die Entwickler die mühsame Implemen-
tierung des Infrastrukturcodes. Zweitens ist der technisch motivierte Code in den
meisten Fälle jener der am häufigsten wiederverwendet wird. Dadurch macht sich
eine automatisierte Erstellung bereits sehr früh positiv bemerkbar. Drittens sind
die Entwickler zugleich die Domänenexperten und die Einbindung eines richtigen
Kunden kann entfallen.
Sobald eine stabile automatisierte Basis besteht können nach und nach fachspe-
zifische Aspekte ergänzt und eine Umstellung auf eine fachliche Domäne vorge-
nommen werden.

2 MDSD, AC-MDSD und Begriffsdefinitionen 18
2.5 Vorurteile gegenüber Modellgetriebenen
Entwicklungsansätzen
An dieser Stelle werden einige Vorurteile gegenüber Modellgetriebenen Entwick-
lungsansätzen behandelt und erklärt warum sie auf MDSD nicht zutreffen, basie-
rend auf [Bet06d] Kapitel 4.
1. Modellierung bedeutet stets die Darstellung aller Spezifikationsdetails in
Form von visuellen Modellen. Diese Modelle besitzen denselben Abstrahie-
rungsgrad wie der implementierte Quellcode.
Der Einsatz einer umfangreichen domänspezifischen Plattform führt zu Spe-
zifikationen, deren Abstraktionsniveau bedeutend höher liegt als jenes von
” herkömmlichem Quellcode“. Modelle und die durch sie repräsentierten
Spezifikationen werden mit Hilfe von Konzepten aus der Problemdomäne
und nicht der Lösungsdomäne dargestellt.
Round-trip Engineering Tools führten zu diesem falschen Bild, da sie nicht
in der Lage sind echte Abstraktion zu schaffen.
2. Generierter Code ist in der Regel schlecht strukturiert und für Entwickler
nur schwer lesbar.
Eine der Grundregeln bei der Codegenerierung mit MDSD ist die Generie-
rung ” gut aussehenden“ Quellcodes. Dieser Zustand wird durch den Ein-
satz von so genannten Code-Beautifiers sichergestellt, die den Quellcode
nachträglich formatieren. Darüber hinaus wird bei MDSD nur Code gene-
riert, der zuerst anhand einer Referenzimplementierung verifiziert werden
konnte. Der generierte Code hat dieselbe Qualität wie diese.
3. Generierter Code besitzt eine geringere Performance gegenüber manuell ver-
fasstem.
Auch hier ist die Referenzimplementierung und deren Verifizierbarkeit das
ausschlaggebende Gegenargument. Des Weiteren besitzen die beteiligten
Designer die Möglichkeit die Architektur auf Basis der Referenzimplemen-
tierung laufend zu verbessern. Auf Grund des generativen Ansatzes ist es
sehr einfach diese Verbesserungen auf den bestehenden Quellcode einer An-
wendung zu übertragen, was bei einer rein manuellen Vorgangsweise schwie-
riger wäre.
4. Die wiederholte Generierung von bereits bestehenden Komponenten ist prak-
tisch nicht durchführbar. Außerdem sind Modell und Code zwangsläufig ab
einem gewissen Punkt nicht mehr synchron.

2 MDSD, AC-MDSD und Begriffsdefinitionen 19
Grundvorrausetzung ist die vollständige Automatisierung bei der Erstellung
von generierten Codeanteilen. Es darf keinerlei manuelle Nachbearbeitung
geben. Zudem muss generierter und manuell erstellter Code streng getrennt
werden, beispielsweise durch die Generierung von Basisklassen und deren
Erweiterung via manuell implementierten Klassen. Ist eines von beiden nicht
gegeben, ist die Wahrscheinlichkeit groß, das eben beschriebenes Szenario
eintritt.
5. Die Anpassung eines Generators benötigt mehr Zeit als die komplette An-
wendung händisch zu implementieren.
Praktische Erfahrungen haben gezeigt, dass die Ableitung der Transforma-
tionen aus einer Referenzimplementierung circa 20-25% des Zeitaufwands
erfordert, der für eine manuelle Implementierung erforderlich ist. Die Ent-
wicklung einer Referenzimplementierung kann nicht zwangsläufig als Mehr-
aufwand gesehen werden, da sie mit der in den meisten Fällen erforderlichen
Implementierung eines Prototypen vergleichbar ist.
6. Die Anpassung des Generators an Änderungen nimmt mehr Zeit in An-
spruch als die manuelle Abänderung des generierten Codes.
Solange generierter und manuell implementierter Code sauber von einander
getrennt sind, und die Transformationsvorschriften auf dem adaptierten Ar-
chitekturprototypen basieren, wird der MDSD-Ansatz immer schneller und
bei weitem weniger fehleranfällig sein, als die manuelle Anpassung unzähli-
ger Instanzen eines Design Patterns.

3 Vergleich mit verwandten
Methodiken
MDSD ist nur einer von zahlreichen Softwareentwicklungsansätzen der letzen
Jahre. So rückten zum einen auf Seiten der technischen Methoden generative mo-
dellgestützte Ansätze, wie Generative Programming (siehe [CE00]) oder MDA,
in das Zentrum des Interesses. Zum anderen kam es auf Seiten der Prozesse zu
einem Trend, der sich weg von schwergewichtigen behäbigen Strukturen hin zu
agilen kurzfristig planenden Methodiken bewegte.
In diesem Kapitel soll aufgezeigt werden, wie sich MDSD in dieses Bild einfügt.
Abschnitt 3.1 stellt die Verwandtschaft zwischen MDSD und Model Driven Ar-
chitecture vor. Der nächste Abschnitt(3.2) betrachtet das Konzept des Software
Product Line Engineering, dessen Ideen MDSD stark beeinflussten. Abschließend
wird in Abschnitt 3.3 erläutert wie mit Hilfe von MDSD die Vorgangsweisen des
Agile Software Development unterstützt werden können.
3.1 MDSD vs. MDA - Gemeinsamkeiten und
Unterschiede
Model Driven Architecture kurz MDA ist ein von der Object Managment Group
(OMG) spezifizierter Standard, der sich mit der weit verbreiteten und seit
langem existierenden Idee beschäftigt, die Spezifikation der Funktionen einer
Anwendung von den plattformabhängigen Implementierungsdetails zu trennen.
Die Spezifikation erfolgt dabei auf Basis von UML Modellen, die über mehrere
Transformationsschritte hinweg in Sourcecode umgewandelt werden.
Der MDA Standard soll Werkzeuge ermöglichen, die zu Folgendem in der Lage
sind (vgl. [mda06a] Punkt 2.1.2):
• Spezifikation einer Anwendung unabhängig von der Zielplattform
• Spezifikation von Plattformen
20

• Auswahl einer Zielplattform
3 Vergleich mit verwandten Methodiken 21
• Anpassung der Spezifikation an die Zielplattform
Der MDA Standard ist in erster Linie für Toolhersteller gedacht und soll die
Interoperablität zwischen den verschiedenen Werkzeugen gewährleisten. Neben
der Interoperabilität sind Portabilität und Wiederverwendbarkeit die erklärten
Primärziele. Diese Punkte sind essenziell für die Langlebigkeit einer Software, da
sich sowohl die Technologien als auch die Fachlogik rasch aber getrennt von ein-
ander entwickeln.
MDA beschäftigt sich somit nicht wie MDSD vorrangig mit der Erstellung von
Softwaresystemfamilien, der Bündelung von Expertenwissen und einer Steige-
rung der Agilität von Softwareentwicklungsprozessen (siehe Abschnitt 3.3 und
Abschnitt 4).
3.1.1 Grundkonzepte
Da MDSD die MDA-Terminologie übernommen hat, wurde ein Großteil, der im
Zusammenhang mit MDA auftauchenden Begriffe, bereits unter Punkt 2.3 be-
handelt. An dieser Stelle wird auf die für das Verständnis des Ansatzes noch
fehlenden Konzepte eingegangen.
Platform Independet Model (PIM)
Ein plattformunabhängiges Modell konzentriert sich auf die Funktionalität einer
Anwendung, während alle implementierungsspezifischen Details weggelassen wer-
den. Ein PIM zeigt also jenen Teil einer Spezifikation, der sich beim Wechsel von
einer technologischen Plattform auf eine andere nicht ändert. Mit anderen Wor-
ten: ein PIM stellt die Geschäftslogik in Reinform dar. Die große Stärke eines
PIMs ist die Resistenz gegenüber technologischen Veränderungen.
Platform Model (PM)
Ein Plattformmodell beschreibt die Konzepte einer bestimmten Plattform. Es
zeigt sowohl die einzelnen Bestandteile der Plattform als auch die von ihr an-
gebotenen Dienste. Daneben beinhaltet ein PM die nötigen Definitionen um ein
PIM in ein PSM zu überführen. Von Seiten der OMG werden UML-Profile für
diverse Technologien zur Verfügung gestellt, die diese Rolle übernehmen (sie-
he [mda06b]).

Platform Specific Model (PSM)
3 Vergleich mit verwandten Methodiken 22
Ein plattformspezifisches Modell kombiniert die Inhalte eines PIMs mit der Sicht-
weise auf eine bestimmte technologische Plattform. Es spezifiziert also wie ein be-
stimmtes System die Eigenschaften einer Plattform konkret nutzt. Erzeugt wird
es aus einem PIM mit Hilfe von Modelltransformationen. Dabei kann es zu ei-
ner Folge von Transformationen kommen, in deren Verlauf die technologischen
Aspekte immer konkreter zu Tage treten und an deren Ende die Generierung von
Quellcode steht.
An diesem Punkt zeigt sich, dass ein MDA-Modell nicht zwingend als PIM oder
PSM eingeordnet werden kann. Ein PSM kann je nach Sichtweise auch ein PIM für
ein daraus abgeleitetes PSM darstellen. So kann beispielsweise ein PSM, das die
Umsetzung der Geschäftslogik mit Hilfe eines beliebigen Middlewaresystems dar-
stellt, ein PIM zu einem PSM sein, das die Umsetzung der selben Fachlogik mittels
Microsoft .NET ( [.ne06]) darstellt. Das heißt, was als Plattform zählt ist relativ
in Bezug auf die Intentionen des Modellierers. Für die meisten MDA-Benutzer ist
die Plattform ein Middlewaresystem. Für einen Middlewareentwickler hingegen
übernimmt diese Rolle das Betriebssystem.
3.1.2 Gegenüberstellung
MDSD und MDA sind zwei sehr verwandte Ansätze. Bei beiden wird aus Model-
len, die sich formal an den in Metamodellen definierten Konzepten orientieren,
Code generiert, der sich auf eine entsprechende Plattform stützt. Stahl und
Völter gehen in [SV05] soweit ” MDA als die Standardisierunginitiative der OMG
zum Thema MDSD“ zu bezeichnen (siehe Seite 373).
Beide Methodiken weisen allerdings zum Teil große Unterschiede auf. Erstens
ist MDA ein Ansatz, der von einem Industriekonsortium, der OMG, spezifiziert
und gefördert wird, wohingegen MDSD von einer Gruppe von ” Praktikern“
definiert wurde (siehe [Bet06d] Seite 10). Durch seinen Ursprung ist MDSD
auch pragmatischer in seinen Ansätzen und verzichtet bewusst auf die Punkte
Interoperabilität und Portabilität, da hier zum einen noch die Standards fehlen
und zum anderen auch die benötigten Tools. Des Weiteren spielen Modell-
zu-Modelltransformationen bei MDSD nur eine nebensächliche Rolle, da wie
in [SV05] aufgezeigt, derzeit die nötigen Modell-Transformationswerkzeuge, die
mehrstufige Transaktionen in der Größenordnung realer Systeme unterstützen,
nicht existieren. MDSD und im speziellen AC-MDSD erzeugt aus diesem Grund
Sourcecode direkt aus dem PIM und verzichtet auf ein PSM.
Zweitens fokussiert MDA bei der Modellierung auf UML, was MDSD nicht

3 Vergleich mit verwandten Methodiken 23
tut. Hier ist prinzipiell jede Modellierungssprache möglich. Einschränkungen
diesbezüglich werden nicht gemacht.
Abschließend ist zu erwähnen, dass der MDA-Standard keinen durchgehenden
Satz an Methoden definiert, die die Umsetzung eines modellgetriebenen An-
satzes in der Praxis erlaubt. MDSD tut dies durch seine praktisch orientierte
Ausrichtung sehr wohl (vgl. [Bet06d] Seite 11).
Für weitere Informationen zu MDA wird auf die Quellen [Fra03] und [mda06a]
verwiesen.
3.2 MDSD vs. Software Product Line Engineering -
Mögliche Synergieeffekte
Bei hardwarelastigen Produkten vom Fahrrad bis zum Fernsehapparat existiert
der Produktlinien-Ansatz bereits seit Jahrzehnten. In der Sofwareentwicklung
nähert man sich ihm nur sehr langsam an. [PBG04] definiert den Begriff der
Softwareproduktlinie wie folgt (siehe Seite 262):
Eine Menge von softwarelastigen Systemen, die einen gemeinsamen
kontrollierten Satz von Produkteigenschaften teilen, die auf die spezi-
fischen Bedürfnisse eines einzelnen Marktsegments ausgerichtet sind
und die ausgehend von einem gemeinsamen Vorrat an Softwaregütern
auf eine vorgeschriebene Art und Weise entwickelt werden.
Die treibende Kraft hinter dieser Bestrebung ist es den Grad an Wiederver-
wendung zu steigern und die Entwicklungskosten einer einzelnen Applikation
zu minimieren. Product Line Engineering beschäftigt sich vorrangig mit der
systematischen Analyse von Domänen bis zur Umsetzung von Software-
Produktionsstraßen, die auf diesen Ergebnissen aufbauen.
Stahl und Völter geben in [SV05] an, dass Product Line Engineering für zahlreiche
Tätigkeiten, die im Rahmen eines MDSD-Entwicklungsprozesses auftreten (siehe
Kapitel 4) das methodische Grundgerüst liefert. Zu diesen Tätigkeiten zählen:
• Definition und Begrenzung der Domäne
• Definition der Kernkonzepte der Domäne
• Trennung von Anwendung und Domänenarchitektur

3 Vergleich mit verwandten Methodiken 24
• Entwicklung der Basiskomponenten einer Plattform
Von diesem Standpunkt aus kann MDSD entweder als Realisierungmechanismus
für Product Line Engineering gesehen werden oder umgekehrt Product Line
Engineering als Analysemethode für MDSD (vgl. [SV05] Seite 244).
Im Folgenden wird die grundlegende Methodik des Product Line Engineering
dargestellt und gezeigt wie sich beide Ansätze miteinander kombinieren lassen
bzw. ergänzen. Für weitere Informationen zu diesem Abschnitt wird auf die Quel-
len [SV05] Kapitel 14, [PBG04] Kapitel 10, [CE00] Part I und [PBL05] verwiesen.
3.2.1 Aktivitäten
Software Product Line Engineering unterscheidet zwei Prozesse, der eine, das Do-
main Engineering, ist die Schaffung einer gemeinsamen Plattform für alle Mit-
glieder der Software-Systemfamilie, der andere, das Application Engineering hat
die Ableitung der einzelnen Anwendungen zum Ziel.
Der Vorteil dieser Trennung liegt in der Ausgliederung unterschiedlicher Belange
in eigene Prozesse. Die Schaffung einer robusten langlebigen Plattform erfordert
eine andere Herangehensweise als die Entwicklung kundenspezifischer Applikatio-
nen in möglichst kurzer Zeit. Zugleich muss auch eine Abstimmung der beiden
Teilprozesse aufeinander berücksichtigt werden. Ein Beispiel dafür ist die in Ka-
pitel 4 vorgestellte iterative, zweigleisige Entwicklung.
Ein zweiter Grund für diese Trennung ist die Sicherstellung der nötigen Variabi-
lität der Plattform in Hinblick auf die Tauglichkeit über mehrere Anwendungen
hinweg. Bei der Plattformentwicklung muss stets darauf Wert gelegt werden, dass
ein und dieselbe Plattform für unterschiedliche aber doch ähnliche Anwendungen
geeignet ist.
Domain Engineering
Der Prozess des Domain Engineering ist verantwortlich für die Schaffung einer
wiederverwendbaren Plattform und somit auch für die Festlegung der Gemein-
samkeiten und Unterschiede zwischen den einzelnen Produkten. Die Plattform
besteht aus verschiedenen Artefakten und reicht von den Anforderungen über
das Design, die Realisierung bis hin zu den Tests.
Der Prozess des Domain Engineering gliedert sich in drei Teilaufgaben, die
wiederum mehrere Tätigkeiten erfordern. Zu Beginn wird eine Domänenanalyse

3 Vergleich mit verwandten Methodiken 25
durchgeführt, danach erfolgt das Design und abschließend die Implementierung.
Der erste Schritt der Domänenanalyse umfasst deren Abgrenzung. Es werden die
Grenzen der Domänen definiert und festgelegt was sich innerhalb der Domäne
und was außerhalb befindet. Man nennt diesen Vorgang auch Domain Scoping.
Domain Scoping ist aus zwei Gründen wichtig. Zum einen ist eine konsistente
Realisierung nur möglich, wenn zwischen den Familienmitgliedern genügend
Synergieeffekte bestehen. Ist der Fokus zu schmal wird die Produktlinie so
klein, dass nur wenige Produkte von der Wiederverwendung profitieren. Ist der
Fokus zu breit, ist die Anzahl der möglichen Produkte groß, das Wiederverwen-
dungspotential wird allerdings im gleichen Maße minimiert. Beide Effekt sind
unwirtschaftlich und daher nicht erwünscht.
Zum anderen rufen unklare Anforderungen fortlaufend Diskussionen zwischen
den Beteiligten hervor. Aus genannten Gründen kann Domain Scoping auch im
Sinne einer Risikominimierung verstanden werden.
Eine mögliche Form der Domänenanalyse bietet das Konzept des Feature
Oriented Design Analysis(FODA) mit dem so genannten Feature Modelling.
Besonders geeignet ist diese Methodik, da die Notation nichts über die spätere
Implementierungstechnologie aussagt. Für weitere Informationen zu FODA
siehe [KCH + 90].
Im zweiten und dritten Schritt, dem Domänendesign und der Domänenimple-
mentierung wird damit begonnen die Softwarestruktur der Domäne festzulegen
bzw. die gemeinsamen Merkmale in einer Plattform zu implementieren. Krzysztof
Czarnecki definiert in [CE00] (siehe Seite 22) den Begriff des Domänendesign wie
folgt:
Developing a common architecture for the systems in the domain
and devising a production plan
Der Vorgang der Domänenimplementierung beinhaltet folgende Tätigkeiten:
Implementing the reusable assets, for example, reusable com-
ponents, domain-specific languages, generators, a reuse infrastructure,
and a production process
Betrachtet man beide Zitate zeigt sich, dass der Prozess des Domain Engineering
den in Abschnitt 4.2 beschriebenen Architektur-Entwicklungsstrang abbildet und
gleichzeitig ein methodisches Grundgerüst dafür liefert.

Application Engineering
3 Vergleich mit verwandten Methodiken 26
Das Application Engineering stellt den eigentlichen Produktionsprozess dar bei
dem aus einer Produktspezifikation ein Mitglied der Software-Systemfamilie ge-
schaffen wird. Übertragen auf MDSD ist dieser Schritt mit dem in Abschnitt 4.3
beschriebenen Anwendungs-Entwicklungsstrang vergleichbar. Hier wird versucht
so viele Bestandteile der Domänenarchitektur wiederzuverwenden wie möglich.
Dabei werden sowohl die Gemeinsamkeiten als auch Unterschiede zwischen den
einzelnen Produkten ausgenutzt.
Für die variablen Merkmale der verschiedenen Anwendungen gibt es diverse
Alternativen diese an die Plattform zu binden, die ganz individuelle Vor- und
Nachteile mit sich bringen. Eine Variante ist die Festlegung der optionalen Featu-
res auf Quellcodeebene, was zu performanten aber auch inflexiblen Programmen
führt. Das andere Extrem ist die Bindung zur Laufzeit über Polymorphismus
oder interpretierte Konfigurationsparameter. Für weitere Varianten siehe [SV05]
Seite 248ff und [PBG04] Seite 278.
MDSD kann hier als Möglichkeit herangezogen werden, um die diversen Alterna-
tiven umzusetzen. Ein Generator ist dazu das ideale Werkzeug. In Bezug auf die
Generierung von Quellcode mit unterschiedlichen festgebunden Features ist das
offensichtlich. Merkmale über die zur Linkzeit entschieden wird, können durch
die Erzeugung unterschiedlicher Bibliotheken und eines zugehörigen Makefiles
realisiert werden. Laufzeitentscheidungen können mit Hilfe der Generierung von
Konfigurationsdateien unterstützt werden.
3.2.2 Zusammenfassung
Abschließend ist festzuhalten, dass sich MDSD und Software Product Line En-
gineering hervorragend ergänzen. MDSD benötigt bewährte Methoden um die
Analysephase durchzuführen und den Aufbau einer Software-Systemfamilie zu
planen. Genau diese Methodiken bietet Software Product Line Engineering.
Umgekehrt ist Software Product Line Engineering auf eine flexible und mächtige
Methode zur Umsetzung der einzelnen Produkte angewiesen. Hier steuert MDSD
durch seine modellgetriebene generative Vorgangsweise ein enormes Potential bei.

3 Vergleich mit verwandten Methodiken 27
3.3 MDSD vs. Agile Software Development - Ist
eine Kombination möglich?
Auf Grund der Unzulänglichkeit schwergewichtiger dokumentenlastiger Prozesse
kam es in den letzten Jahren vermehrt zur Entstehung so genannter agiler
Softwareentwicklungsmethodiken. Diese arbeiten mit sehr kurzen Planungsho-
rizonten und reduzieren die geforderte Dokumentation meist auf ein Minimum.
In kleinen bis mittelgroßen Teams ist diese Vorgangsweise unter Beachtung
diverser Rahmenparameter sehr erfolgreich (siehe [Mar03]). In großen Projekten
mit einer Vielzahl an Mitarbeitern, die stark fluktuieren können, macht sich der
geringe Dokumentationsumfang allerdings negativ bemerkbar. Zudem kann die
Agilität leicht ins Unstrukturierte abgleiten. MDSD kann hier mit dem Anspruch
” das Modell ist zugleich Dokumentation und Code“ mehr Transparenz in die
Entwicklung bringen. Darüber hinaus wird der Vorgang des Refactoring, der
oft einen erheblichen Zeitaufwand bei agilen Projekten in Anspruch nimmt, bei
MDSD stark verkürzt. Änderungen können hier zentral in den Transformati-
onsvorschriften erfolgen und mittels Generator auf den bestehenden Quellcode
übertragen werden.
3.3.1 Das Agile Manifest und MDSD
Im Folgenden wird anhand der Kernaussagen des Agilen Manifests (siehe [agi06])
der Zusammenhang zwischen MDSD und Agile Software Development erläutert.
Für weitere Informationen zu Agile Development wird auf [Mar03] verwiesen.
Der Zusammenhang zwischen MDSD und Agile Development wird in [SV05] Ab-
schnitt 5.4 und [Bet06d] Abschnitt 2.4 beschrieben.
Individuals and interactions over processes and tools
Mit dieser Forderung wird die Wertschätzung und Bedeutung des Menschen in
der Softwareentwicklung zum Ausdruck gebracht. Die mitwirkenden Personen
sind der Schlüssel zum Erfolg. Ein guter Prozess kann ein Projekt nicht vor
dem Scheitern bewahren, falls ein Team keine kompetenten ” Spieler“ besitzt
aber ein schlechter Prozess kann selbst stark Mitspieler ineffizient werden lassen.
Neben kompetenten Einzelpersonen ist auch deren Zusammenspiel als Team
Grundvorraussetzung für einen erfolgreichen Projektabschluss.
Letztendlich ist es ratsamer keinen allzu formalen Prozess zu etablieren, der vom
Team nicht mitgetragen wird, sondern das Team sollte vielmehr einen eigenen,

3 Vergleich mit verwandten Methodiken 28
auf seine Anforderungen abgestimmten, Ablauf definieren.
MDSD selbst schreibt keinen fixen Prozess vor. Es existiert vielmehr ein in Ka-
pitel 4 beschriebener Vorschlag, der speziell in den Details auf die individuellen
Bedürfnisse angepasst werden kann. Auch in Bezug auf die verwendeten Tools
gibt es keine Einschränkungen, da diese an die zu bearbeitende Domäne ange-
passt werden müssen.
Working software over comprehensive documentation
Quellcode ist nicht das geeignete Medium um die Struktur eines Softwaresystems
und die Konzepte auf denen es aufbaut zum Ausdruck zu bringen. Verständli-
cher als maschinenlesbarer Quellcode sind Fließtextdokumente und graphische
Modelle, die einem Entwickler die Beweggründe für Entscheidungen verdeutli-
chen und die Struktur der Anwendung näherbringen. Problematisch in diesem
Zusammenhang ist der hohe Zeitaufwand der zur Erstellung und fortlaufenden
Aktualisierung der Dokumentation benötigt wird. Ist die Dokumentation nicht
auf dem aktuellen Stand wird sie wertlos und eine Quelle des Missverständnisses.
In der Projektpraxis ist es meist wichtiger pünktlich eine lauffähige Anwendung zu
liefern anstatt gut aussehender Dokumente. MDSD kann beide Punkte verbinden,
da die eingesetzten Modelle einerseits den gleichen Stellenwert wie Quellcode
einnehmen und andererseits als Dokumentation dienen. Ein positiver Nebeneffekt
ist die ständige Aktualität der Dokumentation (=Modelle), da große Teile der
Anwendung auf ihr beruhen.
Customer collaboration over contract negotiation
Software kann nicht wie ein beliebiger Gebrauchsgegenstand geordert werden.
Versuche sämtliche Anforderungen bereits zu Projektbeginn festzulegen sind, wie
die Vergangenheit gezeigt hat, zum Scheitern verurteilt. In den allermeisten Fällen
wünscht der Kunde während des Projektverlaufs Abweichungen vom ursprüngli-
chen Plan oder wird sich erst nach Implementierungsbeginn klar, was er wirklich
benötigt.
Agile Software Development fordert aus eben genanntem Grund eine sehr enge
Zusammenarbeit mit dem Kunden. MDSD kann diese Zusammenarbeit erleich-
tern, falls eine fachlich motivierte DSL zum Einsatz kommt, die sich zur Kommu-
nikation mit dem Kunden eignet. Stahl und Völter sehen diesen Punkt ansonsten
unabhängig von der Frage, ob modellgetrieben gearbeitet wird oder nicht (sie-

he [SV05]).
3 Vergleich mit verwandten Methodiken 29
Responding to change over following a plan
Diese Aussage ist eng mit der Forderung einer intensiven Kundenzusammenar-
beit verknüpft. Die Flexibilität in der Planung entscheidet in vielen Fällen über
Erfolg oder Misserfolg eines Projekts.
Während des Projektverlaufs kommt es möglicherweise zu Änderungen in den
Anforderungen eines Kunden. In solchen Situationen ist es wichtig flexibel rea-
gieren zu können, anstatt sich auf vorab festgelegte Anforderungen zu versteifen,
die möglicherweise nicht mehr relevant sind.
Ein modellgetriebenes Vorgang erleichtert die Umsetzung von Änderungen we-
sentlich. Ändern sich fachliche Anforderungen können diese durch die generative
Umsetzung schneller, als es bei einer manuellen Vorgangsweise der Fall wäre und
vor allem konsistent in die bestehenden Komponenten integriert werden. Das
liegt auch in dem Umstand begründet, dass Implementierungsaspekte, die in den
Transformationsvorschriften festgelegt sind, zentral geändert werden können.
3.3.2 Zusammenfassung
Zusammenfassend ist festzuhalten, dass MDSD in der Lage ist, durch eine expli-
zite Formalisierung von Domänenwissen und architektonischen Konzepten sowie
der Trennung von Domänenarchitekturentwicklung und aufbauenden Anwendun-
gen in unterschiedliche Prozesse, agile Techniken auch für große Projekte zu ska-
lieren. Darüber hinaus bekommen agile Methodiken mehr Struktur durch das
ständige Vorhandensein einer aktuellen Dokumentation (=Modelle). Letztend-
lich sinken auch die unvermeidlichen Refactoring-Aufwände um die entwickelte
Anwendung an die sich ändernden Anforderungen anzupassen.

4 Entwicklungsprozess,
Vorgehensweise und Best
Practices
4.1 Iterative, zweigleisige Entwicklung
Der Softwareentwicklungsprozess mit Hilfe von MDSD basiert auf einer klaren
Trennung von Domain Engineering und Application Engineering. Das Domain
Engineering beinhaltet die Erstellung der gemeinsamen Plattform bzw. Ar-
chitektur der Mitglieder einer Softwaresystemfamilie. Application Engineering
umschreibt die Entwicklung einzelner Anwendungen, die auf den Artefakten der
Domain Engineering-Phase aufbauen. Beide Begriffe stammen aus dem in Ab-
schnitt 3.2 beschriebenen Software Product Line Engineering. Diese Aufspaltung
des Entwicklungsprozesses ist notwendig um die gemeinsame Softwarearchitek-
tur, unabhängig von einer konkreten Anwendung zu formalisieren und generativ
zu unterstützen.
Aus der Sicht des Anforderungsmanagements nehmen die
Anwendungsentwicklungs-Teams gegenüber dem Infrastrukturentwicklungs-
Team die Kundenrolle ein. Das heißt, analog zum Verhältnis zwischen Kunde
und Anwendungsentwicklungs-Team, wo der Endkunde in die Entwicklung
miteinbezogen wird, ist es erforderlich Vertreter der Anwendungsentwicklung
vor Ort in die Entwicklung der gemeinsamen Infrastruktur einzubinden. Diese
Maßnahme soll dazu beitragen, die gemeinsame Plattform den Bedürfnissen der
Anwendungsentwickler entsprechend zu gestalten.
Stahl und Völter schlagen in [SV05] einen iterativen zweigleisigen Entwicklungs-
prozess vor, bei dem die Entwicklung von Domänenarchitektur und mindestens
einer darauf aufbauenden Anwendung in zwei virtuell von einander getrennten
Projekten stattfindet. Die Iterationen beider Projekte sind zeitlich aufeinander
abgestimmt und sollten eine konstante Dauer aufweisen. Um den Prozess agil
30

4 Entwicklungsprozess, Vorgehensweise und Best Practices 31
Abbildung 4.1: Iterative, zweigleisige Entwicklung (Quelle: [SV05] Seite 213)
zu gestalten, ist es empfehlenswert die Dauer auf maximal sechs Wochen zu
beschränken (siehe [VB06] Seite 8 und 10).
Die Zusammenhänge zwischen den beiden Projekten verdeutlicht Abbildung
4.1 aus der ersichtlich wird, dass die Entwicklung der Infrastruktur stets eine
Iteration vor der Anwendungsentwicklung liegt. Neue Versionen der Domänen-
architektur werden bei dieser Vorgangsweise immer zu Beginn einer Iteration in
die Anwendungsentwicklung übernommen, um den Aufwand für das Refactoring
überschaubar zu halten. Während der gesamten Entwicklungsdauer erhalten die
Infrastrukturentwickler Feedback von den Anwendungsentwicklern um Verbesse-
rungen an der Domänenarchitektur vornehmen zu können.
Im Folgenden wird näher auf die in den beiden Entwicklungssträngen anfallenden
Aktivitäten basierend auf [SV05], [VB06] und [Bet06c] eingegangen.
4.2 Architektur-Entwicklungsstrang
Im Rahmen des Architektur-Entwicklungsstranges wird die Domänenarchitektur
entworfen, umgesetzt und laufend verbessert. Die erklärten Ziele bei der Entwick-
lung sind zum einen die Ausweitung der Wiederverwendung von geschaffenen
Artefakten und zum anderen eine Qualitätssteigerung des Codes sowie eine
erhöhte Effizienz.
Zum Projektstart ist es sinnvoll den in Abbildung 4.2 schematisch dargestellten
Architektur-Entwicklungsstrang einmalig zu durchlaufen und erst danach mit der
eigentlichen Anwendungsentwicklung zu beginnen. Im Folgenden werden die Sta-

4 Entwicklungsprozess, Vorgehensweise und Best Practices 32
Abbildung 4.2: Erstellung einer Domänenarchitektur; Artefakte der Domänenarchitektur
(hellgrau), wichtige Zwischenergebnisse (dunkelgrau);
(Quelle: [SV05] Seite 204)
tionen des Prozesses und die mit ihnen verbundenen Tätigkeiten vorgestellt.
Prototyping
Zu Beginn einer MDSD-Entwicklung existiert meist eine technische Plattform auf
der die Domänenarchitektur aufbaut. Im Fallbeispiel in Kapitel 6 bilden Techni-
ken aus dem J2EE Bereich sowie das Java-Webframework Struts diese Plattform.
Sind diese Technologien für die Beteiligten noch neu, ist es sinnvoll sie im Rah-
men einer Prototyping Phase kennen zu lernen. Die hier erzielten Ergebnisse
können unter Umständen für die später zu erstellende Referenzimplementierung
als Grundlage herangezogen werden.
Plattformentwicklung
Das Ziel dieser Tätigkeit ist die Implementierung der gemeinsamen MDSD-
Plattform, also jener Komponenten die für alle Anwendungen der Domäne gleich
sind. Die Plattform nimmt eine enorm wichtige Rolle im Rahmen von MDSD

4 Entwicklungsprozess, Vorgehensweise und Best Practices 33
ein, da sie den generierten Code stützt und somit die Entwicklung der nötigen
Transformationen zur Codegenerierung erleichtert.
Zu beachten ist, dass dieser Schritt keine einmalige Maßnahme darstellt sondern
eine iterative Aktivität ist. Des Weiteren ist es durchaus üblich, dass sich die
Grenze zwischen Plattform und generiertem Code in die eine wie auch in die
andere Richtung verschiebt.
Referenzimplementierung erstellen
Die Referenzimplementierung kann die Weiterentwicklung eines bereits existie-
renden Prototypen sein, muss es aber nicht sein. Hier steht weniger der fachliche
Gehalt als vielmehr eine Überdeckung mit den Konstrukten der DSL im Vor-
dergrund. Das ist besonders wichtig, da die Referenzimplementierung zusammen
mit dem Referenzmodell die Anwendung der DSL-Konzepte beschreibt und für
die gewählte technische Plattform konkretisiert.
Die Referenzimplementierung ist zwar nur ein Zwischenergebnis aber aus eben
genannten Gründen ein sehr Wichtiges. Zusätzliche Bedeutung erlangt sie durch
den Umstand, dass aus ihr die für die Codegenerierung benötigten Transforma-
tionsvorschriften abgeleitet werden.
Bei einer Neuentwicklung wird die Referenzimplementierung zuerst von Hand
erstellt und nach und nach, sobald die Transformationsvorschriften vorliegen,
durch aus dem Referenzmodell heraus generierten Code ersetzt. Zusammen mit
der manuell ergänzten Fachlogik und den Komponenten der MDSD-Plattform
muss der generierte Code wieder zu einer lauffähigen Referenzanwendung führen.
Domänenanalyse/Design
Das Ziel der Domänenanalyse ist die Findung einer DSL, die die Konzepte der
Domäne beschreibt und formalisiert. Das Ergebnis kann zum Beispiel ein UML-
Profil sein oder ein XML-Schema. Stahl und Völter geben in [SV05] Seite 207 die
im Folgenden zitierten Ratschläge für die Beschaffenheit einer DSL:
Die DSL sollte möglichst frei von technischen Termini sein, die
ein Implementierungsdetail der MDSD-Plattform ... darstellen (z.B.
Verwendung von EntityObject statt EntityBean als Stereotyp).
Diese sprachliche Abstraktion von einer bestimmten Technologie erleichtert eine
mögliche Migration auf eine andere Plattform.

4 Entwicklungsprozess, Vorgehensweise und Best Practices 34
Die DSL sollte möglichst alle relevanten Konzepte der Domäne
durch Sprachelemente semantisch überdecken.
Hier wird eine Vollständigkeit der DSL gefordert. Sollten Konstrukte fehlen oder
unvollständig sein, wird dies üblicherweise von den Anwendungsentwicklern be-
merkt, da es für sie schwierig oder unmöglich ist gewisse Aspekte einer Anwen-
dung auf Basis der DSL zu formalisieren.
Die DSL sollte so kompakt wie möglich sein und keine Redundanzen
aufweisen
Das heißt, die DSL muss eindeutig sein, da es sonst zu fehlerhaften Modellen
kommen könnte bzw. die Ausdrucksstärke darunter leidet.
Die DSL muss die Wohlgeformtheit von Modellen überprüfbar ma-
chen.
Dieser Punkt ist besonders wichtig, falls die DSL eine Spezialisierung einer
Sprache darstellt, wie es bei einem UML-Profil der Fall ist. Hier müssen
Modellierungsvarianten, die in der allgemeinen Sprache zulässig sind, von der
Spezialisierung aber nicht unterstützt werden, gefiltert werden.
Nach Stahl und Völter besteht eine DSL im Rahmen der MDSD aus folgenden
Teilen:
• konkrete Syntax: z.B. ein UML-Profil oder ein XML-Schema
• statische Semantik: Validierungsregeln und Einschränkungen. Sie be-
schreiben die erlaubten und verbotenen Konstellationen.
• Semantik: Die Semantik dokumentiert die Bedeutung der DSL-Konstrukte
in textueller Form. Diese Information ist auch in den Transformationsvor-
schriften und der Referenzimplementierung gekapselt. Allerdings ist sie hier
bereits auf eine gewisse technische Plattform zugeschnitten.
Des Weiteren weisen sie darauf hin, dass die DSL Findung eine der forderndsten
Aufgaben im Rahmen einer MDSD-Entwicklung darstellt und entweder einiges
an Erfahrung oder eine vorhandene Basis zum Beispiel in Form eines Beispiels
nötig ist.

Referenzmodell
4 Entwicklungsprozess, Vorgehensweise und Best Practices 35
Das Referenzmodell verdeutlicht die DSL-Konzepte anhand eines Beispiels und
dient als Vorlage für die Referenzimplementierung. Zusammen mit dieser bietet
es eine detaillierte Beschreibung der Nutzung und des Zusammenspiels der DSL-
Konstrukte.
Transformationen ableiten
Die Transformationen formalisieren den Übergang von einem Modell auf die Kon-
strukte einer MDSD-Plattform. Sie transformieren ein Anwendungsmodell in eine
lauffähige Implementierung oder einen Implementierungsrahmen. Abgeleitet wer-
den sie aus der Referenzimplementierung.
Die Arbeiten zum Fallbeispiel in Kapitel 6 haben gezeigt, dass es quasi unmöglich
ist die Transformationen aus dem ” Nichts“ heraus zu erstellen, sondern immer
eine Vorlage benötigt wird, aus der sie abgeleitet werden können.
4.3 Anwendungs-Entwicklungsstrang
Der Anwendungs-Entwicklungsstrang nutzt die Ergebnisse des Architektur-
Entwicklunsstranges um auf dieser Basis ein individuelles Mitglied der
Softwaresystem-Familie zu implementieren. Abbildung 4.3 zeigt die Akti-
vitäten dieses Stranges und ihre Reihenfolge. In der Phase der Formalen
Modellierung werden die fachlichen Anforderungen mittels der DSL formalisiert.
Die Anwendungsentwickler orientieren sich hier besonders stark am Referenzmo-
dell und der Referzenimplementierung. In dieser Phase ist eine funktionierende
Kommunikation zwischen Architektur- und Anwendungsentwicklern besonders
wichtig, da vor allem zu Beginn Fehler und Verbesserungspotential in der
DSL festgestellt werden, die in der nächsten Überarbeitung der generativen
Architektur Eingang finden. Darüber hinaus ist es durchaus wahrscheinlich, dass
zusätzliches Generierungspotential aufgedeckt wird.
Im nächsten Schritt wird aus dem Anwendungsmodell mit Hilfe der Transforma-
tionsvorschriften Quellcode generiert, der um die individuelle Fachlogik manuell
ergänzt die lauffähige Anwendung ergibt.

4 Entwicklungsprozess, Vorgehensweise und Best Practices 36
Abbildung 4.3: Aktivitäten im Anwendungsentwicklungsstrang (Quelle: [SV05]
Seite 211)

5 Einführung in
openArchitectureWare
5.1 Einleitung
openArchitectureWare (kurz: oAW ) ist ein Werkzeugkasten bestehend aus ei-
nem Generator und verschiedenen unterstützenden Modulen, der Entwicklern die
Umsetzung von MDSD Projekten ermöglicht. oAW ist in Java implementiert und
streng modular aufgebaut. Es besteht daher die Möglichkeit existierende Kom-
ponenten selbständig zu ergänzen und neue hinzuzufügen.
Unterstützt werden von Seiten des Werkzeugs Modelle beliebigen Formats
und auch hinsichtlich des generierten Codes besteht keinerlei sprachliche Ein-
schränkung. Um die Bedienung zu vereinfachen liegt oAW in Form eines Eclipse
Plugins vor, das unter anderem Editoren, Modellbrowser und einen Debugger zur
Verfügung stellt. Einen Überblick über die Kernfunktionalität bietet die folgende
Auflistung:
• Das Metamodell der Domäne, in deren Rahmen Code generiert wird, liegt
explizit in Form von Java Klassen vor. Wie ein UML-Metamodell in oAW
eingebunden werden kann, wird in Abschnitt 5.5 beschrieben.
• Die zu verarbeitenden Modelle können in beliebigen Formaten vorliegen.
Es wird nur ein für das jeweilige Format passender Instantiator benötigt.
Derzeit werden standardmäßig UML, EMF, XML und Visio Modelle un-
terstützt.
• Die Workflow Engine ermöglicht eine Steuerung der Generatorabläufe
über XML Konfigurationsdateien (siehe 5.4).
• Der Generator erzeugt beliebigen textuellen Output basierend auf den in
der Templatesprache Xpand (siehe 5.6) definierten Transformationsvor-
schriften. Diese Sprache wurde im Rahmen des oAW Projekts definiert.
37

5 Einführung in openArchitectureWare 38
• Es besteht die Möglichkeit mittels einer deklarativen Constraint
Checking Language die Einhaltung diverser Modellierungsregeln zu über-
prüfen (siehe 5.9).
oAW wird im Rahmen eines Open Source Projektes (Homepage siehe [oaw05])
entwickelt und liegt derzeit in Version vier vor. Auf diese Version beziehen sich
die hier beschriebenen Vorgangsweisen.
Die oAW Dokumentation unterscheidet zwischen zwei unterschiedlichen Metho-
diken. Die erste Möglichkeit,die Modellierung mittels eines externen UML-Tools
durchzuführen, wird als ” classic style“ bezeichnet (siehe [Kad06b]). Die Bezeich-
nung ” klassisch“ rührt daher, dass diese Methode bereits in früheren Versionen
unterstützt wurde.
Die zweite Möglichkeit, die es erst seit Version vier gibt, besteht darin die Mo-
dellierung mittels des Eclipse Modeling Frameworks (EMF) vorzunehmen. Für
oAW macht es keinen Unterschied ob EMF oder UML als Modellierungssprache
zum Einsatz kommt. Beide Techniken werden vollwertig unterstützt.
Im Rahmen dieser Arbeit wird nur der klassische Weg mittels UML-Modellierung
beschritten. Diese Wahl liegt nicht in den Vor- oder Nachteilen der einen bzw.
anderen Technik begründet, sondern einzig und allein in dem Umstand, dass
die Arbeiten zum Fallbeispiel aus Kapitel 6 zum Zeitpunkt des Erscheinens von
Version vier zu weit fortgeschritten waren, als dass eine Abwägung noch sinnvoll
gewesen wäre.
Die folgenden Ausführungen stellen die Grundlage für das Verständnis des Fall-
beispiels in Kapitel 6 dar und sollen dem Leser die verschiedenen Teile von oAW
und deren Verwendung im Rahmen eines MDSD-Projekts näher bringen.
Einen guten Überblick über die unter [oaw06d] erhältliche Dokumentation bie-
tet [Völ06a].
5.2 Funktionsweise des Generators
Abbildung 5.1 zeigt die Funktionsweise des oAW Generators. Als Eingabe
benötigt der Generator ein beliebiges formales Modell, das der Semantik des vor-
ab konfigurierten Metamodells folgt. Dieses Modell wird im ersten Verarbeitungs-
schritt vom Parser eingelesen. Der Instantiator benutzt diese Informationen im

5 Einführung in openArchitectureWare 39
Abbildung 5.1: Funktionsweise des openArchitectureWare-Generators (Quelle:
[SV05] Seite 111)
nächsten Schritt, um für jedes Element eine Instanz der passenden Metaklasse 1 im
Speicher abzulegen. Auf diese Weise erhält man einen virtuellen Objektgraphen
im Speicher des Generators. Beispielsweise wird ein Element vom Typ UML-
Class durch eine Instanz von org.openarchitectureware.meta.uml.classifier.Class
repräsentiert. Die im Speicher befindlichen Objekte werden nun mittels der
bestehenden Validierungsregeln auf eine Einhaltung der Constraints geprüft.
Nach diesen vorbereitenden Schritten kann die eigentliche Codegenerierung
stattfinden. Dabei wendet der Codegenerator einen Satz von Transformations-
vorschriften (=Templates) auf die Elemente des im Speicher befindlichen Modells
an und erzeugt so den gewünschten Quellcode.
Die hier vorgestellten Abläufe wurden aus [Völ05c] Abschnitt 4, [Völ05a] und
[SV05] Abschnitt 6.9 entnommen.
5.3 Eclipse Plugin: Installation und erste Schritte
Eine der wichtigsten Eigenschaften des oAW-Werkzeugkastens stellt die Integra-
tion in die Entwicklungsumgebung Eclipse ( [ecl06]) dar. Die Integration wurde,
wie es bei Eclipse üblich ist, durch ein so genanntes Plugin realisiert. Dieses
stellt beispielsweise Editoren für Templates, Extensionfiles und Checkfiles zur
Verfügung. Des Weiteren wird die Möglichkeit geboten Generierungsvorgänge
per Mausklick auszuführen und nötigenfalls auch darin enthaltene Fehler mittels
des Eclipse Debuggers zu suchen.
Im Folgenden wird beschrieben wie man das Plugin installiert, die Funktiona-
1 Gemeint ist in diesem Fall eine Javaklasse, da wie in der Einleitung bereits erwähnt wurde,
das Metamodell dem Generator in Form von Javaklassen kenntlich gemacht wird. Diese
Klassen bezeichnet die Dokumentation von oAW in [Völ05c] auch als Metaklassen. Diese
Arbeit schließt sich der in der oAW-Dokumentation verwendeten Nomenklatur an.

5 Einführung in openArchitectureWare 40
Paket Inhalt Abhängigkeit
oaw-core Workflow Engine, EMF Integration, oaw-core
oaw-core-plugins
Xpand 2 Engine
Eclipse basierte IDE Unterstützung inkl
Editoren
oaw-core
oaw-classic Unterstützung der klassischen Vorgangsweise
inklusive Metamodellgenerator und
Instantiators
oaw-core
Tabelle 5.1: Für das Fallbeispiel benötigte oAW Komponenten und ihre
Abhängigkeiten (Quelle [Kad06a])
lität der einzelnen Komponenten nutzt und welche Schritte nötig sind, um einen
Eclipse Workspace für die Umsetzung eines MDSD Projekts vorzubereiten.
5.3.1 Installation
Sämtliche Teile des oAW Plugins können unter [oaw06b] als Zip File herunter-
geladen werden. Für die weiteren Schritte wird vorausgesetzt, dass Eclipse ab
Version 3.1 bereits installiert wurde. Für die Ausführung des Fallbeispiels von
Kapitel 6 werden die in Tabelle 5.1 beschriebenen Pakete benötigt.
Um das Plugin nach dem Download zu installieren, muss die Datei
oaw-core-plugins.zip in das Eclipse Stammverzeichnis extrahiert werden.
Die Struktur des Zip files wurde so gewählt, dass sich die darin enthaltenen
Dateien nach der Extraktion in den korrekten Verzeichnissen befinden.
Um den in Abschnitt 5.3.3 beschriebenen Dumpfile Browser nutzen zu können,
muss das Zip File /plugins/org.openarchitectureware.dump_4.0.0.zip aus
dem oaw-classic Paket ebenfalls in das Eclipse Stammverzeichnis exportiert
werden. Alle Installationen sind nach einem Neustart von Eclipse abgeschlossen.
Weitere Hinweise zur Installation von zusätzlichen Komponenten können
[Kad06a] entnommen werden.
5.3.2 Editoren
Einen Hauptbestandteil des oAW-Plugins machen die Editoren aus. Einer der
wichtigsten für die Entwicklung ist der in Abbildung 5.2 dargestellte Xpand-
Templateeditor. Er stellt neben Syntax Highlighting und Codecompleation auch
eine statische Fehlerüberprüfung zur Verfügung. Daneben gibt es noch Editoren
für die so genannten Extensions, die Klassen des Metamodells um zusätzliche in
den Templates nutzbare Eigenschaften erweitern und für die in den Checkfiles
enthaltenen Validierungsregeln.

5 Einführung in openArchitectureWare 41
Abbildung 5.2: Der Xpand Templateeditor
5.3.3 Auswertung von Dump Files
In der klassischen Vorgangsweise legt der oAW Generator nach einem erfolg-
reichen Durchlauf einen so genannten Dump an. Das ist im Wesentlichen eine
serialisierte Datenstruktur, die Informationen über den Aufbau des im letzten
Generatordurchlaufs instanzierten Modells enthält. Man kann daher Dumpfiles
mit Logfiles vergleichen.
Mit Hilfe des Eclipse Plugins ist es möglich deren Inhalt auszuwerten. Um den
Dump zu durchforsten, muss im Kontextmenü der Dumpdatei die Option Open
Dump gewählt werden. Falls das Modell keine Fehler hat, öffnet sich daraufhin die
Strukturansicht (siehe Abbildung 5.3) in der die Elemente des Modells und ihre
Attribute in einer Baumstruktur dargestellt werden. Dadurch ist der Entwickler
in der Lage Probleme, die während des Generatordurchlaufs auftraten und aus
der Modellierung heraus entstanden, ausfindig zu machen.
5.3.4 Eclispe-Workspace konfigurieren
Um einen Generator für die Modelle einer Domäne mittels oAW umsetzen zu
können, muss der verwendete Eclipse Workspace im Vorfeld konfiguriert werden.
Der Workspace setzt sich in der Regel aus drei Typen von Projekten zusammen.
Zum einen sind das Projekte die Bibliotheken und andere Bestandteile des oAW

5 Einführung in openArchitectureWare 42
Abbildung 5.3: Die Strukturansicht des Dump Browsers
Toolkits selbst enthalten. Zum anderen werden Projekte angelegt die gemeinsam
das Fundament der Softwaresystemfamilie, bestehend aus dem zu entwickelnden
Generator und den Plattformbestandteilen, bilden.
Die restlichen Projekte umfassen die mit Hilfe von Generator und Plattform
generierten Anwendungen und deren manuell verfasster Quellcode. Im Folgenden
wird beschrieben wie die oben genannten Projekte angelegt und Abhängigkeiten
aufgelöst werden.
Es wird darauf hingewiesen, dass die beschriebene Konfiguration keineswegs zwin-
gend erforderlich ist, um ein Projekt mittels oAW zu realisieren. Es handelt sich
dabei lediglich, um die in der Dokumentation empfohlene Vorgangsweise, die auch
im Rahmen des Fallbeispiels in Kapitel 6 angewandt wird. Beschrieben wird diese
Vorgangsweise in [Kad06a], [Kad06b] und [Tho06]
Projektstruktur
Im ersten Schritt wird über den Menüpunkt File - New - Project... ein neu-
es Javaprojekt für die benötigten oAW Module angelegt. Danach werden
in das soeben erstellte Projekt die in Tabelle 5.1 beschriebenen Zipdateien
oaw-core-4.0.0.zip und oaw-classic-4.0.0.zip entpackt.
Diese Schritte sind zwar nicht zwingend notwendig, allerdings erleichtert die
explizite Integration dieser Module die weitere Arbeit, da alle anderen Projekte
Abhängigkeiten zu den Bibliotheken des oAW-Toolkits aufweisen.
Im zweiten Schritt wird ein Projekt für den domänenspezifischen Generator, der
die Transformation von Modell zu Code vornehmen soll, angelegt. Innerhalb die-
ses Projekts erstellt man nun folgende Ordner und Source Folder 2 :
• src - Dieser Source Folder enthält die manuell verfassten Komponenten des
2 Eclipse bezeichnet Ordner, die Quellcode enthalten als Source Folder

5 Einführung in openArchitectureWare 43
Generators, wie zum Beispiel Templates, Erweiterungen der Metamodell-
klassen und Validierungsregeln.
• src-gen - Dieser Source Folder enthält die mittels des in Abschnitt 5.5.2
beschriebenen Metamodellgenerators automatisch erzeugten Metamodell-
klassen.
• metamodel - Dieser Ordner enthält die Metamodelle, mit denen die Kon-
zepte der Domäne abgebildet werden in ihren Ausgangsformaten.
• mappings - In diesen Ordner werden für den Generierungsvorgang nöti-
ge Mappingfiles abgelegt. Mappingfiles sind XML Dateien, die beschreiben
welchen Elementen des oAW Frameworks welche Metamodell Konzepte zu-
geordnet sind. Des Weiteren definieren sie eine Zuordnung zwischen den in
UML-Modellen verwendeten Stereotypen und den Metamodellklassen.
Die empfohlene Aufteilung des Quellcodes in generierte und manuell codierte
Bestandteile wird auf Dateisystemebene durch die Ordner src und src-gen
realisiert. Die Dokumentation von oAW rät generierten und nicht genierten Code
nur zu vermischen, wenn die Technologie keine andere Möglichkeit der Erweite-
rung bietet. Im objektorientierten Umfeld beispielsweise werden generierter und
manuell codierter Code mittels den Erweiterungsmechanismen der Vererbung
verknüpft.
Eine Einbindung von manuell entwickelten Teilen in generierten Code wird
durch die Verwendung von so genannten Protected Regions ermöglicht. Wie
das geht wird in Abschnitt [KE06] erklärt. Die Vermischung von Code hat
allerdings mehrere Nachteile. Zum einen ist die Versionierung komplizierter, da
auch generierter Code versioniert werden muss. Zum anderen besteht die Gefahr,
dass auf Grund eines Programmier- oder Modellierfehlers Quellcode innerhalb
eines geschützten Bereichs verloren geht.
Im dritten Schritt werden die Projekte angelegt, die gemeinsam die zu entwickeln-
de Applikation bilden. Auch hier sind wieder getrennte Ordner für manuellen und
generierten Code anzulegen.
Nach dieser Konfiguration sieht die Projektstruktur ähnlich dem in Abbildung
5.4 gezeigten Beispiel aus.
Konfiguration des Build Path
Nach dem Anlegen der einzelnen Projekte muss der so genannte Build Path ge-
setzt werden. Das heißt, der Entwicklungsumgebung muss bekannt gemacht wer-

5 Einführung in openArchitectureWare 44
Abbildung 5.4: Beispiel einer Projektstruktur für ein mit oAW 4 und Eclipse
realisiertes MDSD-Projekt
den, wo die benötigten Bibliotheken zu finden sind. Dies geschieht über den Ein-
trag Build Path - Configure Build Path ... des Kontextmenüs eines Projekts. Im
daraufhin erscheinenden Dialog können über den Reiter Libraries Bibliotheken
in Form von jar Dateien hinzugefügt werden.
Das Generatorprojekt selbst benötigt die in Tabelle 5.2 dargestellten Bibliothe-
ken des oAW Toolkits. Sämtliche Bibliotheken sollten sich in dem im vorigen
Abschnitt erstellten Projekt für oAW Module befinden.
Die Applikationsprojekte selbst müssen nur eine Abhängigkeit zu
oaw-core-4.0.0.jar und zum Generatorprojekt definieren. Abhängigkei-
oaw-classic-4.0.0.jar oaw-core-4.0.0.jar
ahclib-1.2.jar antlr-2.7.6.jar
beanutils-1.7.0.jar cli-1.0.jar
commons-lang-2.0.jar jalopy-1.5rc3.jar
jaxen-core-1.0.jar jaxen-jdom-1.0.jar
jdom.jar log4j-1.2.8.jar
logging-1.0.3.jar saxpath-1.0.jar
oro-2.0.6.jar
Tabelle 5.2: Vom Generatorprojekt benötigte jar Dateien aus dem oAW Toolkit

5 Einführung in openArchitectureWare 45
ten zwischen Projekten können auch über den Configure Build Path... Dialog
gesetzt werden.
5.4 Ablaufsteuerung mittels des Workflow Konzepts
Der Generierungsprozess wird über die deklarative und mittels einer einfa-
chen XML basierten Sprache konfigurierbare Workflow engine gesteuert. Work-
flows sind also ein Mechanismus, um eine Sequenz von Aktivitäten in ei-
ner benutzerdefinierten Reihenfolge abzuarbeiten. Ein Worfklow setzt sich da-
bei aus beliebig vielen WorkflowComponents zusammen. Solche Bestandtei-
le sind üblicherweise model parser, Validatoren, Modelltransformatoren und
Codegeneratoren. oAW4 enthält bereits alle für einen Generierungsablauf
nötigen Komponenten. Es ist aber problemlos möglich mittels des Interfa-
ces org.openarchitecutureware.workflow.WorkflowComponent eigene Kom-
ponenten zu entwickeln. Für die konkrete Vorgangsweise wird auf [EV06] verwie-
sen.
Die Reihenfolge des Aufrufs und die Konfiguration der einzelnen WorkflowCom-
ponents mittels Parametern, die beim Aufruf übergeben werden, wird in XML
Dateien mit der Endung .oaw abgespeichert. Es ist möglich die Konfiguration auf
mehrere Dateien aufzuteilen, ähnlich wie es bei dem Buildtool Ant (siehe [ant05])
der Fall ist. Listing 5.1 zeigt das Beispiel einer Workflowkonfiguration bei dem
zuerst ein model parser und anschließend ein Generator aufgerufen werden. Ein
ausführliches Beispiel einer Workflowkonfiguration ist in Kapitel 6 zu finden. Wei-
terführende Informationen zum Thema können [EV06] entnommen werden.
Listing 5.1: Beispiel einer Workflowkonfiguration (Quelle: [EV06] Seite 5)
< property name =’ genPath ’ value = ’/ home / user / target ’/ >
< property name =’ model ’ value = ’/ home / user / model .xmi ’/ >
< component class =’ oaw . emf . XmiReader ’>
< component class =’ oaw . xpand2 . Generator ’>

5 Einführung in openArchitectureWare 46
Abbildung 5.5: Option zum Starten eines oAW-Workflows
Die definierten Workflows werden über das Eclipse Plugin gestartet. Dazu muss
im Kontextmenü der Workflowdatei die Option Run As - oAW Workflow aus-
gewählt werden (siehe Abbildung 5.5). Danach startet die Verarbeitung. Sollte
es zu Fehlern kommen, kann der Workflow mittels der Option Debug As - debug
workflow im Debugmodus gestartet werden.
Alternativ ist auch eine Verarbeitung mittels Ant oder über die Commandline
möglich. Diese Vorgangsweisen bieten allerdings mehr Nach- als Vorteile. Aus
diesem Grund werden sie im Rahmen dieser Arbeit auch nicht näher behandelt.
5.5 Modellierung und Metamodellentwicklung mit
Hilfe von UML
Metamodelle bilden die Konzepte einer Domäne durch Modellierungselemente
ab und beschreiben wie sie im Rahmen des Modellierungsansatzes verwendet
werden können. Dieses Wissen ermöglicht erst eine effiziente Generierung von
Quellcode, da dem Generator durch das Metamodell die Bedeutung der zu ver-
arbeitenden Modelle bewusst gemacht wird. Anhand dieser Informationen kann
er entscheiden, welche Transformationsvorschriften (=Templates) auf welches
Modellelement anzuwenden sind. Darüber hinaus können die Eingabemodelle

5 Einführung in openArchitectureWare 47
gegen das Metamodell validiert werden, um Modellierungsfehler aufzudecken.
Im Rahmen von oAW kommt dem Metamodell noch weitere Bedeutung zu.
Durch die Repräsentation des Metamodells in Form von Javaklassen wird die
Komplexität der Eingabeformate vor den Transformationsvorschriften versteckt.
Damit kann die Struktur der Problemdomäne unabhängig von der konkreten
Modellsyntax dargestellt werden.
Des Weiteren bieten die Klassen des Metamodells die Möglichkeit in den Trans-
formationsvorschriften benötigte Logik zentral zu implementieren. Typische
Beispiele sind die Auswertung bestimmter Eigenschaften von Modellelementen
oder die Durchführung komplexer Suchvorgänge innerhalb der Modelle. Die
Templatesprache Xpand bietet zwar Konstrukte zum Traversieren des Modells,
für darüber hinausgehende Anweisungen ist eine Realisierung in Java oder als
Extension (siehe Abschnitt 5.8) allerdings unumgänglich.
Eine übliche Vorgangsweise in oAW ist es die Modellierung in UML mit einem
externen Modellierungstool durchzuführen. Das Modell wird dem Generator
anschließend im XML Metadata Interchange Format 3 (XMI siehe [omg06]), für
das oAW eigene Parser mitliefert, übergeben. Auch das Metamodell kann auf
diese Weise erstellt werden, da oAW über einen Metamodellgenerator verfügt,
der aus einem in UML vorliegenden Metamodell, die von oAW benötigten
Javaklassen generiert. Wie das geht zeigt Abschnitt 5.5.2.
Dieser Abschnitt zeigt wie man ein Metamodell sowie konkrete Modelle, die des-
sen Konzepten folgen, mit einem externen UML-Modellierungstool entwickelt und
in oAW einbindet. Weiterführende Informationen findet man in [Völ05c], [Völ05b]
und [Tho06].
5.5.1 Modellierungswerkzeuge
Für die Modellierung des Fallbeispiels wurde Poseidon for UML 3.2 Commu-
nity Edition ( [pos05]) von Gentleware gewählt. Poseidon ist ein in der Com-
munity Edition kostenloses UML-Modellierungsprogramm, dass den Export von
Modellen in das Format XMI 1.2 unterstützt. Ein weiterer wichtiger Grund für
die Wahl ist die sehr gute Unterstützung von Poseidon durch das oAW Fra-
mework. Wie bereits erwähnt spricht jedes Modellierungswerkzeug einen ande-
3 XMI bietet die Möglichkeit UML-Modelle in XML Dateien abzuspeichern. Problematisch in
diesem Zusammenhang ist die Tatsache, dass XMI nicht gleich XMI ist, da jedes Modellierungswerkezeuge
einen anderen XMI-Dialekt spricht.

5 Einführung in openArchitectureWare 48
Abbildung 5.6: Metamodell mit einer Anbindung an die übergeordneten Konzepte
der UML
ren XMI Dialekt, was dazu führt, dass von Seiten des Generators für jedes
Programm ein eigener Adapter benötigt wird, um die Modelle verarbeiten zu
können. Der zu verwendende Adapter muss explizit in der Workflowkonfigura-
tion bekannt gegeben werden. Wie das geht zeigt das Fallbeispiel in Kapitel
6. Eine Liste der unterstützten Tools kann derzeit nur dem Inhalt des Javapa-
kets org.openarchitectureware.core.frontends.xmi.toolsupport.uml ent-
nommen werden.
5.5.2 Metamodellentwicklung in UML mit dem
Modellierung
oAW-Metamodellgenerator
Metaklassen sind einfache Javaklassen. Man kann Eigene erstellen oder der Ein-
fachheit halber bestehende Metamodelle, wie das der UML durch Ableitung er-
weitern. Die Erweiterung des UML Metamodells geschieht beispielsweise durch
die Modellierung eines UML Profils. Das heißt, die Verwendung eines UML Ste-
reotyps ist vergleichbar mit der Ableitung der zugehörigen Metaklasse.
Ein Beispiel für diese Vorgangsweise wird in Abbildung 5.6 dargestellt. Die Klasse
data::DataObject ist eine Instanz von UML::Class und besitzt unter seinen At-
tributen genau eines vom Typ data::Key, das wiederum UML::Attribute ableitet.
Aus diesen Informationen könnte man zum Beispiel eine JavaBean erzeugen.
Konkrete Modelle, wie das in Abbildung 5.7, nutzen diese Konzepte durch die
Vergabe von Stereotypen, die den Klassen des Metamodell zugeordnet sind.
Um die Implementierung von UML basierten Metamodellen zu erleichtern,

5 Einführung in openArchitectureWare 49
Abbildung 5.7: Nutzung eines Metamodells mittels Stereotypen
stellt oAW mit dem Paket org.openarchitectureware.meta.uml bereits ei-
ne Umsetzung des UML Metamodells zur Verfügung. Mit dessen Hilfe würde
eine Implementierung der Klasse DataObject aus Abbildung 5.6 wie in Lis-
ting 5.2 dargestellt aussehen. Die Implementierung von Key sieht ähnlich
aus. Hier wird statt org.openarchitectureware.meta.uml.classifier.Class
org.openarchitectureware.meta.uml.classifier.Attribute erweitert.
package data ;
Listing 5.2: Implementierung der Metaklasse DataObject
import org . openarchitectureware . meta . uml . classifier . Class ;
public class DataObject extends Class {
}
private String keyType = "";
private Key key = null ;
public void setKey ( Key key ){
}
this . key = key ;
public Key Key (){
}
return this . key ;
public void setKeyType ( String keyType ){
}
this . keyType = keyType ;
public String KeyType (){
}
return this . keyType ();
Listing 5.2 zeigt, dass DataObject eine Spezialisierung von Class ist und somit
sämtliche Eigenschaften und Methoden erbt. Ein typisches Beispiel für eine
geerbte Methode ist Name(), die den Namen eines Objekts zurückgibt.

5 Einführung in openArchitectureWare 50
Die Attribute und Assoziationen der Metaklasse finden sich in den Getter- und
Setter-Methoden der jeweiligen Klassen wieder, wobei die Getter-Methode per
Konvention aus dem Namen des Attributs mit groß geschriebenem Anfangsbuch-
staben bestehen. Das sonst übliche Präfix get entfällt in diesem Fall.
Um den Wert zu setzen, wird ein UML tagged value benutzt, wobei der Name
des Eigenschaftswerts der Name des Attributs aus dem Metamodell ist.
Nach der Implementierung der Metaklasse muss noch ein weiterer Schritt er-
folgen, um es dem Instantiator zu ermöglichen eine Verbindung zwischen dem
Stereotyp > und der Klasse data.DataObject herzustellen. In
der Konfigurationsdatei metamappings.xml im Verzeichnis mappings (siehe Ab-
schnitt 5.3.4) muss eine Zuordnung von Stereotyp zu Metaklasse vorgenommen
werden. Den Eintrag für > zeigt Listing 5.3.
Listing 5.3: Zuordnung von Stereotypen zu Metaklassen via metamappings.xml
DataObject
data . DataObject
Metamodellgenerator
Da die händische Implementierung des Metamodells in Java eine mühevolle und
fehleranfällige Angelegenheit ist, liegt dem Modul oaw-classic-4.0.0.zip ein
Metamodellgenerator bei, der die Umwandlung eines Metamodells von UML zu
Java vornimmt. Diese Vorgangsweise ist ganz im Sinne von MDSD.
Prinzipiell sind Metamodelle nur UML-Modelle. Der Modellierer kann also sein
gesamtes UML-Fachwissen nutzen. Um den Metamodellgenerator verwenden
zu können, müssen allerdings gewisse Regeln beachtet werden. Die Wichtigsten
werden anhand des Beispiels aus Abbildung 5.6 beschrieben. Für weiter gehende
Informationen wird auf [Völ05b] verwiesen.
Abbildung 5.8 zeigt die für den Metamodellgenerator adaptierte Variante des
Beispiels. Die Anbindung an das Metamodell der UML erfolgt über die im Fra-
mework bereits existierenden Klassen Class und Attribute. Beide Klassen sind
mit dem Stereotyp > gekennzeichnet, das dem Generator anzeigt,

5 Einführung in openArchitectureWare 51
Abbildung 5.8: Angepasstes Metamodell für den Metamodellgenerator
dass diese Objekte bereits existieren und nicht mehr generiert werden müssen.
Diese Klassen werden nun durch DataObject und Key erweitert. Durch die Aus-
zeichnung mit dem Stereotyp > erzeugt der Metamodellgenera-
tor abstrakte Basisklassen, die vom Entwickler durch konkrete Klasse abgeleitet
werden müssen. Auf diese Weise ist es möglich die generierten Metaklassen durch
eigenen Code zu ergänzen.
Bei den Attributen der Metaklassen ist zu beachten, dass nur die folgenden drei
Datentypen verwendet werden dürfen:
• Strings: In diesem Fall werden einfache Setter und Getter generiert.
• boolean: In diesem Fall wird der Getter mit dem Präfix ” is“ gekennzeich-
net, und es existieren Setter sowohl für String als auch boolean Parameter.
• int: In diesem Fall existieren Setter für int und String Parameter.
Der Generatorlauf wird über ein dem Metamodellgenerator beiliegendes Work-
flowskript gestartet. Es muss vom Entwickler nur noch richtig parametrisiert
werden. Ein Beispiel dafür findet man in [oaw06c] bzw. in der Umsetzung des
Fallbeispiels aus Kapitel 6.
5.6 Templateentwicklung mittels Xpand
Das oAW Framework beinhaltet eine spezielle Templatesprache genannt Xpand
um die Ausgabeerzeugung der Generatorläufe zu steuern. Die mit Hilfe der Spra-

5 Einführung in openArchitectureWare 52
che erzeugten Templates werden in Dateien mit der Endung .xpt gespeichert.
Diese Dateien müssen im Classpath des Generatorprozesses liegen, um verarbei-
tet werden zu können.
Dieser Abschnitt beschreibt die gängigsten Konstrukte der Xpand Templatespra-
che. Für weitere Informationen wird auf [KE06] verwiesen.
5.6.1 Allgemeine Struktur von Template Files
Listing 5.4 zeigt ein Beispiel eines Templates mit dem der Code für ein JavaBean
erzeugt werden kann. Anhand dieses Beispiels werden im Weiteren die Konstrukte
der Sprache erklärt.
Listing 5.4: Beispiel für ein Xpand Template
≪IMPORT org :: openarchitectureware :: meta :: uml :: classifier≫
≪IMPORT data≫
≪EXTENSION templates :: Extensions≫
≪DEFINE JavaBean FOR DataObject≫
≪FILE StandardPath≫
package ≪JavaPackageName≫ ;
public class ≪ObjectName≫ {
≪EXPAND Variablen≫
}
public ≪ObjectName≫ (){
}
≪EXPAND GetterSetter FOREACH Attribute≫
≪ENDFILE≫
≪ENDDEFINE≫
≪DEFINE Variablen FOR DataObject≫
≪FOREACH Attribute AS a≫
private ≪a. Type .NameS≫ ≪a.NameS≫;
≪ENDFOREACH≫
≪ENDDEFINE≫
≪DEFINE GetterSetter FOR Attribute≫
public void set≪UpperCaseName ()≫( ≪Type.NameS≫ ≪NameS≫ ){
}
this . ≪NameS≫ = ≪NameS≫;
public ≪Type.NameS≫ get≪UpperCaseName ()≫(){

}
return this . ≪NameS≫;
≪ENDDEFINE≫
5 Einführung in openArchitectureWare 53
Das Beispiel zeigt, dass eine Templatedatei aus einer beliebigen Anzahl von IM-
PORT Anweisungen, gefolgt von einer beliebigen Anzahl an EXTENSION An-
weisungen und einem oder mehreren DEFINE Blöcken, besteht. Ein weiteres,
auffälliges Merkmal sind die Guillemotzeichen - ≪,≫ - , die Xpand-Anweisungen
auszeichnen. Text außerhalb dieser Zeichen wird nicht interpretiert, sondern eins
zu eins ausgegeben. Xpand-Schlüsselwörter werden groß geschrieben. Der restliche
Inhalt der Anweisungen setzt sich aus Aufrufen von Methoden der Metaklassen
und Extensions (siehe Abschnitt 5.8) zusammen.
Würde man die Transformationsvorschriften aus Listing 5.4 auf das DataObject
Student aus Abbildung 5.7 anwenden, erhielte man den Code aus Listing 5.5.
package example ;
public class Student {
}
Listing 5.5: Beispiel für ein Xpand Template
private String matrikelnummer ;
private String name ;
public Student (){
}
public void setMatrikelnummer ( String matrikelnummer ){
}
this . matrikelnummer = matrikelnummer ;
public String getMatrikelnummer (){
}
return this . matrikelnummer ;
public void setName ( String name ){
}
this . name = name ;
public String getName (){
}
return this . name ;

5 Einführung in openArchitectureWare 54
5.6.2 Anweisungen der Xpand Templatesprache
IMPORT
Um nicht immerzu den voll qualifizierten Namen von Metaklassen und Defini-
tionen schreiben zu müssen, kann mittels IMPORT ein Namespace importiert
werden. Danach können alle unter diesem Namespace liegenden Konstrukte mit
dem einfachen Namen aufgerufen werden. In Listing 5.4 geschieht das unter an-
derem mittels ≪IMPORT meta::data≫. Wäre diese Anweisung nicht vorhanden,
müsste jeder Aufruf von DataObject durch meta::data::DataObject ersetzt
werden.
EXTENSION
Metamodelle werden üblicherweise auf eine strukturelle Art und Weise be-
schrieben. Ein damit verbundener Nachteil ist eine erschwerte Definition von
zusätzlichem Verhalten, wie Suchoperationen, oder abgeleitete Eigenschaften.
Darüber hinaus ist es sinnvoll das Metamodell nicht mit Details der technischen
Plattform zu überfrachten, da es die Wiederverwendbarkeit schmälert.
Die Idee von Extensions ist es, einen Weg zu schaffen Metaklassen leicht um
zusätzliches Verhalten zu erweitern. Extensions werden mit Hilfe der oAW Spra-
che Extend in Dateien mit der Endung .ext definiert und mit der Anweisung
≪EXTENSION templates::Extensions≫ in Templatedateien eingebunden. Wie
die Definition von Extensions erfolgt zeigt Abschnitt 5.8. Wichtig ist, dass die
importierte Extensionsdatei im Classpath des Generatorprozesses liegt.
DEFINE
DEFINE Blöcke stellen die eigentlichen Templates dar und sind das zentrale Kon-
zept von Xpand. Das Tag besteht aus einem Namen, einer optionalen Parameter-
liste und dem Namen der Metaklasse, auf die es anzuwenden ist. Abgeschlossen
wird die Anweisung durch das Schlüsselwort ENDDEFINE (Syntax siehe Listing
5.6). Innerhalb des Blocks gilt für die aktuell behandelte Instanz der Metaklasse
ein implizites this.
Listing 5.6: Syntax des Xpand DEFINE-Blocks (Quelle [KE06])
≪DEFINE templateName ( formalCommaSeperatedParameterList )
FOR MetaClass≫
a sequence of statements
≪ENDDEFINE≫

5 Einführung in openArchitectureWare 55
Xpand Templates unterstützen einen parametrischen Polymorphismus. Das heißt,
gibt es zwei Templates mit demselben Namen für zwei Metaklassen, die von der
selben Superklasse erben, wendet Xpand das korrespondierende Template der
Subklasse an, falls das Template der Superklasse für die Subklasse aufgerufen
wird. Umgekehrt wird das Template der Superklasse aufgerufen, falls kein Sub-
klassentemplate vorhanden ist.
FILE
Die FILE Anweisung leitet die Ausgabe zwischen FILE und ENDFILE in die
spezifizierte Datei um. Die Pfadangabe ist immer relativ zum Zielverzeichnis des
aktuellen Generatorlaufs.
EXPAND
Mit Hilfe der EXPAND Anweisung wird ein anderer DEFINE Block aufgerufen
und dessen Ausgabe an der momentanen Stelle eingefügt. Anschließend fährt die
Verarbeitung mit der nächsten Anweisung fort. EXPAND ist vergleichbar mit
dem Aufruf einer Subroutine in anderen Programmiersprachen. EXPAND gibt es
in drei unterschiedlichen Varianten:
• ≪EXPAND templateName FOR ObjectName≫: Ruft das Template mit dem
angegebenen Namen für das spezifizierte Objekt auf. Das Objekt muss eine
Instanz der Metaklasse sein, für die das Template geschrieben wurde.
• ≪EXPAND templateName≫: Ruft das Template mit dem angegebenen Namen
für das aktuell verarbeitete Objekt auf. Die Anweisung ist äquivalent zu
≪EXPAND templateName FOR this≫.
• ≪EXPAND templateName FOREACH ElementOfAnCollection≫: Führt das
spezifizierte Template für jedes Element einer Datenstruktur aus, die das
Java Interface Collection implementiert.
FOREACH
Der FOREACH Ausdruck führt sämtliche Anweisungen zwischen FOREACH und
ENDFOREACH für alle Objekte einer spezifizierten Java Collection - ähnlich
der EXPAND-FOREACH Anweisung - aus. Das aktuell verarbeitete Element
wird über eine lokale Variable angesprochen. Zu beachten ist, dass innerhalb
eines FOREACH Blocks jede andere Anweisung erlaubt ist, d. h. auch weitere
FOREACH Anweisungen. Die konkrete Syntax zeigt Listing 5.7.

5 Einführung in openArchitectureWare 56
Listing 5.7: Syntax des Xpand-FOREACH Blocks (Quelle [KE06])
≪FOREACH ElementOfAnCollection AS variableName
[ SEPARATOR expression ]≫
a sequence of statements using variableName to access the
current element of the iteration
≪ENDFOREACH≫
IF
Die IF Anweisung hat wie in anderen Programmiersprachen die Funktion ei-
ne Entscheidung auf Grund einer spezifizierten Bedingung vorzunehmen. Es be-
steht die Möglichkeit IF Blöcke durch ELSE und ELSEIF zu erweitern, auch eine
Schachtelung ist erlaubt. Die konkrete Syntax zeigt Listing 5.8.
≪IF expression≫
Listing 5.8: Syntax des Xpand IF-Blocks (Quelle [KE06])
a sequence of statements
[ ≪ELSEIF expression≫
a sequence of statements ]
[ ≪ELSE expression≫
a sequence of statements ]
≪ENDIF≫
5.7 Expressions Framework
Das oAW4 Generator Framework stellt unterschiedliche textuelle Sprachen für un-
terschiedliche Anwendungszwecke zur Verfügung. Es gibt zum Beispiel die bereits
beschriebene Templatesprache Xpand (siehe Abschnitt 5.6) zur Codegenerierung,
die in Abschnitt 5.9 beschriebene Sprache Check zur Überprüfung von Modellie-
rungsvorschriften und die in Abschnitt 5.8 erklärte Sprache Extend zur Definition
zusätzlicher Funktionalität. Diese Sprachen haben eines gemeinsam, sie arbeiten
mit unterschiedlichen Meta- und Meta-Metamodellen (EMF, MOF etc.). Das Ex-
pressions Framework hat die Aufgabe von diesen zum Teil recht unterschiedlichen
Modellierungsformen zu abstrahieren und eine einheitliche Basis zu schaffen. Die
Abstraktionsschicht, auf API-Basis auch als type system bezeichnet, erlaubt den
den Zugriff auf die diversen built-in types und auf die registrierten Metamodellim-
plementierungen. Neben dem Typsystem bietet das Framework eine Subsprache
- Expressions -, die Konstrukte auf Basis des Typsystems zur Verfügung stellt,
die in den anderen Sprachen des oAW Generator Frameworks wiederverwendet

5 Einführung in openArchitectureWare 57
werden. So definiert Expressions beispielsweise die Syntax zum Vergleich von Ob-
jekten, erläutert wie man auf Eigenschaften und Methoden von Objekten zugreift,
beschreibt Operatoren zur Selektion von bestimmten Elementen einer Menge und
vieles mehr. Eine Auswahl an Beispielen, die [Eff06b] entnommen sind, zeigt Lis-
ting 5.9.
Für weitergehende Informationen zum Expressions Framework siehe [Eff06b] und
die Dokumentation der built-in types unter [oaw06a].
Listing 5.9: Beispiel für Konstrukte der Subsprache Expressions Quelle [Eff06b]
// Zugriff auf einen Eigenschaftswert :
myModelElement . name
// Zugriff auf eine Methode :
myModelElement . doStuff ()
// Boolsche Ausdrücke :
!( ’ text ’. startsWith (’t ’) && ! false )
// Selektiert alle Elemente die dem definierten
// Boolschen Ausdruck entsprechen :
collection . select ( v | boolean - expression -with -v )
//If - Anweisung :
condition ? thenExpression : elseExpression
5.8 Extend Language
Die Extend Language bietet die Möglichkeit Bibliotheken von unabhängigen
Operationen, basierend auf Javamethoden oder oAW Expressions zu schaffen.
Diese Bibliotheken - auch Extensions genannt - können von allen textuellen
Sprachen, die auf der Expressions Subsprache aufbauen, genutzt werden. Extend
Methoden sind vergleichbar mit statischen Javamethoden. Sie sind wie diese
zustandslos, man muss daher alle benötigen Informationen durch die Parameter-
liste übergeben. Man kann Extend-Methoden aber durchaus auf die Objekte des
gerade im Speicher befindlichen Modells anwenden.
Sind die von Extend zur Verfügung gestellten Konstrukte nicht ausreichend, ist
es möglich die nötige Logik in einer statischen Java Methode zu implementieren.
Diese statische Methode kann über eine Extend-Methode aufgerufen werden.
Man führt gewissermaßen ein Mapping auf die statische Javamethode durch.

5 Einführung in openArchitectureWare 58
Dieses Mapping ist nötig, da eine statische Javamethode in Sprachen wie XPAND
oder Checks nicht direkt aufgerufen werden kann.
Extendmethoden werden in Dateien mit der Endung .ext abgespeichert und
müssen im Classpath des Generators liegen. Listing 5.10 zeigt ein Beispiel
einer Extendbibliothek. Es ist zu erkennen, dass eine Extenddatei aus be-
liebig vielen Namespace- und Extensionimporten, gefolgt von einer beliebi-
gen Anzahl an Extendmethoden besteht. Eine Extendfunktion kann auf zwei
unterschiedlichen Arten aufgerufen werden. Zum einen wie eine Funktion -
funktionsname(element) - und zum anderen wie eine Objekteigenschaft mit-
tels - element.funktionsname(). Weitere Informationen und Beispiele kann
man [Eff06c] entnehmen.
Listing 5.10: Beispiel für eine Extendbibliothek (Quelle: [Eff06c])
import my: metamodel ;
extension other :: ExtensionFile ;
/**
* Documentation
*/
anExpressionExtension ( String stringParam ) :
;
/**
doingStuff ( with ( stringParam ))
* java extensions are just mappings
*/
String aJavaExtension ( String param ) :
;
JAVA my. JavaClass . staticMethod ( java . lang . String )
5.9 Constraint Checking
Die Validierung von Modellen gegen Metamodelle ist eine der wichtigsten Schritte
im Zuge der Codegnerierung, nur so kann ein korrekter Ablauf ermöglicht wer-
den. Da die Modellvalidierung derzeit von Modelleriungsprogrammen kaum un-
terstützt wird, muss diese Aufgabe vom Generator erfüllt werden. oAW stellt dem
Entwickler zu diesem Zweck die Check Sprache (siehe [Eff06a]) zur Verfügung.
Sie basiert auf dem in Abschnitt 5.7 beschriebenen Expression Framework.

5 Einführung in openArchitectureWare 59
Mit Check definierte Regeln werden in Dateien mit der Endung .chk hinterlegt.
Bei der Regeldefinition ist darauf zu achten, dass der korrekte Zustand und nicht
ein möglicher Fehlerzustand beschrieben wird. Listing 5.11 gibt die Syntax für
eine Check-Definition wieder. Listing 5.12 zeigt ein Beispiel.
Bei der Regeldefinition kann die volle Mächtigkeit der definierten Exendbibliothe-
ken, sowie alle Eigenschaften der Metaklassen genutzt werden, um die Korrektheit
der Modelle zu garantieren.
Listing 5.11: Syntax von Check-Regeln (Quelle: [Eff06a])
context TypeName ( ERROR | WARNING ) msg - expression - using - this :
;
/**
*/
constraint - expression - using - this
Listing 5.12: Beispiel für eine Check-Regel
* EBADataClass und seine Erben müssen unter ihren
* Attributen genau einen Schlüssel aufweisen .
* Die Metaklassen Methode " Key " gibt diesen zurück .
context EBADataClass ERROR Name + " -
;
Es muss genau ein Attribut mit dem Stereotyp
geben !" :
Key != null

6 Fallbeispiel
6.1 Einleitung
In Kapitel 5 wurde der Werkzeugkasten openArchitectureWare vorgestellt, der
die Umsetzung von MDSD-Projekten ermöglicht. An dieser Stelle soll nun
anhand eines praktischen Beispiels die Nutzung der Technologie gezeigt werden.
Dazu wird eine Onlinebuchhandlung basierend auf Techniken aus dem J2EE
Bereich entwickelt. Die bearbeitete Domäne lautet ” Softwarearchitektur für
E-Businesssysteme“.
Neben der Beschreibung, der diesem Beispiel zu Grunde liegenden Softwa-
rearchitektur, wird gezeigt, wie das daraus abgeleitete Metamodell bzw. die
für oAW angepasste Version inklusive der Validierungsregeln aussieht. Danach
wird der Aufbau der verwendeten Transformationsvorschriften analysiert und
ein ausführliches Beispiel zum Thema ” Ablaufsteuerung“ gegeben. Außerdem
werden Erweiterungsmöglichkeiten des Beispiels vorgestellt. Abschließend werden
die Entstehunggeschichte des Fallbeispiels und aufgetretene Probleme beleuchtet.
Zudem erfolgt ein Analyse des Verhältnisses zwischen generiertem und manuell
entwickeltem Code.
Das Fallbeispiel wurde mit oAW Version vier im Sinne der klassischen Vorgangs-
weise mit UML-Diagrammen umgesetzt und zeigt wie Sourcecode aus UML-
Klassendiagrammen erzeugt werden kann. Der Eclipse Workspace mit den Sour-
cen zum Fallbeispiel liegt der Arbeit bei. Die Nutzung ist nach der Installation der
in Abschnitt 5.3 beschriebenen Eclipse-Plugins möglich. Der Workspace besteht
aus folgenden Projekten:
• eba-Generator: Der Generator selbst mit dem Metamodell und allen
Transformationsvorschriften
• eba-BuecherwurmEJB: Anwendungsprojekt, das die Geschäftslogik-
und Datenhaltungsschicht realisiert
• eba-BuecherwurmWeb: Anwendungsprojekt mit dem Webfrontend der
Onlinebuchhandlung
60

6 Fallbeispiel 61
• oaw4: Von den anderen Projekten benötigte oAW Libraries
6.2 Das Anwendungsbeispiel
Als Anwendungsbeispiel und Referenzapplikation zur Veranschaulichung der
Domänenarchitektur dient die Onlinebuchhandlung ” Bücherwurm“, die es einem
Kunden ermöglicht Bücher über das Internet zu bestellen. Neben der Gruppe
der Kunden gibt es noch einen zweiten Benutzerkreis, die Administratoren. Die-
se haben die Möglichkeit, die Daten des Systems über eine Webschnittstelle zu
pflegen.
6.2.1 Anwendungsfälle des Actors Kunden
Kunden haben die Möglichkeit im Buchsortiment von ” Bücherwurm“ nach
Büchern zu suchen und sie anschließend online zu kaufen. Es ist möglich den
Buchbestand mittels der folgenden Kombinationen zu durchsuchen:
• ISBN
• Autor und Titel
• Kategorie
Eine Bestellung kann aus einem oder mehreren Büchern bestehen, um so Versand-
kosten zu sparen. Bevor eine Bestellung endgültig im System erfasst wird, muss
sich der Kunde mittels seiner Kundenkennung und dem dazugehörigen Passwort
identifizieren. Nur im angemeldeten Zustand kann eine Bestellung im System er-
fasst werden.
Um sich anmelden zu können, muss der Kunde zuvor einen Benutzeraccount
eröffnen, dabei werden verschiedene Daten zu seiner Person erfasst, ihm wird
eine Kundennummer zugewiesen und er wählt ein Passwort. Der Kunde hat je-
derzeit die Möglichkeit diese Daten zu bearbeiten, nachdem er sich im System
angemeldet hat. Sind alle Einkäufe getätigt und die nötigen Datenänderungen
durchgeführt, meldet sich der Kunde vom System ab.
Eine graphische Darstellung der Anwendungsfälle für Kunden zeigt Abbildung
6.1.
6.2.2 Anwendungsfälle des Actors Administrator
Ein Administrator hat die Möglichkeit die Daten des Systems über eine Web-
schnittstelle zu pflegen. Um einen Anwendungsfall ausführen zu können, muss

6 Fallbeispiel 62
Abbildung 6.1: Anwendungsfälle des Actors ” Kunde“
der Administrator am System angemeldet sein. Er hat die Möglichkeit weitere
Administratoren im System anzulegen und sein Passwort zu ändern.
Die Hauptaufgabe der Administratoren ist es, neue Bücher im System anzule-
gen, die Daten angebotener Bücher zu ändern und Bücher, die sich nicht mehr
länger im Sortiment befinden, aus dem System zu löschen. Um die zu bearbei-
tenden Bücher zu finden, stehen einem Administrator dieselben Suchroutinen zur
Verfügung wie einem Kunden.
Administratoren haben neben der Verwaltung von Büchern auch die Möglich-
keit Kunden aus dem System zu löschen. Zur Auffindung von Kunden stehen
Suchroutinen mit folgenden Eingabeparametern zur Verfügung:
• Kundennummer
• Vorname, Nachname
Abschließend loggt sich der Administrator aus, um die Sitzung zu beenden. Einen
Überblick, über die möglichen Anwendungsfälle bietet Abbildung 6.2.

6 Fallbeispiel 63
Abbildung 6.2: Anwendungsfälle des Actors ” Administrator“

6.3 Domäne und Technologien
6 Fallbeispiel 64
Die Domäne des Anwendungsbeispiels kann mit Softwarearchitektur für E-
Businesssysteme umschrieben werden. E-Businesssysteme sind Softwaresysteme
die Geschäftsdaten auf elektronischem Wege verarbeiten. In vielen Fällen ist das
System mit einer Webschnittstelle ausgestattet, um die Interaktion mit externen
Benutzern oder die Verwaltung des selbigen zu ermöglichen. E-Businesssysteme
werden mit dem Ziel entwickelt Geschäftstransaktionen via Internet mit einem
externen Partner zu unterstützen. Technisch gesehen besitzen diese Systeme
zumeist eine komponentenbasierte, verteilte Architektur.
In den letzten Jahren haben sich besonders zwei Technologien zur Umsetzung
solcher Anwendungen hervorgetan. Zum einen ist das Microsofts .Net Frame-
work [.ne06] und zum anderen Suns Java Enterprise Edition (vormals Java 2
Enterprise Edition; kurz: J2EE) [j2e05].
Zur Umsetzung des Fallbeispiels wurden Technologien aus dem J2EE Bereich
gewählt. Diese Wahl hat mehrere Gründe. Erstens ist J2EE komplett mit Open
Source Produkten nutzbar, d. h. die für die Umsetzung nötige Software ist frei
zugänglich. Des Weiteren existiert auch eine Vielzahl an frei verfügbaren Infor-
mationsquellen (z.B. [BA04] und [JBo05b]), die das Erlernen der Technologie
vereinfachen. Zweitens existiert in [SV05] Kapitel 3 ein auf J2EE basierendes
Beispiel, das als Ausgangspunkt für das in diesem Kapitel vorgestellte Fallbeispiel
dient.
Im Folgenden werden jene Technologien aus dem J2EE Bereich, auf denen die
Domänenarchitektur (siehe Abschnitt 6.4) des Fallbeispiels aufbaut, näher be-
schrieben.
6.3.1 J2EE als Rahmenarchitektur
J2EE ist eine Plattform für verteilte mehrschichtige Applikationen. Die Anwen-
dungslogik ist dabei in Komponenten aufgeteilt, die auf unterschiedlichen Geräten
betrieben werden können. Eine J2EE-Komponente ist eine eigenständige funk-
tionelle Softwareeinheit, die mit ihren Klassen und benötigten Dateien zu einer
J2EE-Anwendung zusammengesetzt wird. Diese Komponenten können unterein-
ander kommunizieren und bieten ihre Dienste anderen Komponenten an bzw. neh-
men Dienste in Anspruch. J2EE-Komponenten sind im Grunde genommen wohl
geformte Javaklassen, das heißt sie entsprechen der J2EE Spezifikation. Diese
Komponenten laufen innerhalb eines J2EE Servers und werden von diesem ver-

6 Fallbeispiel 65
waltet. Die J2EE-Spezifikation definiert die folgenden Komponenten (vgl. [BA04]
Seite 3):
• Client-Applikationen und Applets,
• JavaServer Pages und Java Servlets
• Enterprise JavaBeans
Für das Fallbeispiel kommt J2EE in Version 1.4 zum Einsatz. Als Java 2 Platform,
Standard Edition wird Version 1.4.2 benutzt.
6.3.2 Enterprise JavaBeans
Enterprise JavaBeans (EJBs) sind ein von Sun Microsystems in Zusammenarbeit
mit der Java Community verabschiedeter Standard zur Entwicklung serversei-
tiger Komponenten für verteilte Applikationen. Mit Hilfe von EJBs können
sowohl Datenobjekte, wie zum Beispiel Kunden, Warenbestände etc. als auch
Prozessobjekte realisiert werden. Da es sich um verteilte Applikationen handelt,
müssen diese Objekte auch nicht auf ein und demselben Applikationsserver
existieren, sondern können verteilt durch mehrere Server realisiert werden. Im
Fallbeispiel wird JBoss 4.0.3 SP1 ( [jbo05a]) als Applikationsserver verwendet.
Man unterscheidet drei verschieden Arten von EJBs: Entity Beans für die Da-
tenhaltung, Session Beans und Message-driven Beans zur Implementierung von
Anwendungslogik. Message-driven Beans werden für die Umsetzung des Fallbei-
spiels nicht weiter benötigt und daher auch nicht erläutert.
Im Folgenden soll näher auf die Besonderheiten von Entity und Session Beans
eingegangen werden. Die EJBs des Fallbeispiels halten sich an die Regeln des
EJB Standards in Version 2.1 (siehe [ejb06]).
Allgemeines
Jede EJB, egal welcher Art, setzt sich aus einer Reihe von Interfaces und einer
abstrakten Klasse - der so genannten Beandefintion - zusammen, die vom Ap-
plikationsserver automatisch mit Hilfe mehrere Konfigurationsdateien zu einem
konkreten Objekt verbunden werden. Unterschieden wird zwischen Remote
Interfaces, die zum Einsatz kommen falls auf eine EJB von einer anderen Java
Virtual Machine (JVM) aus zugegriffen wird und Local Interfaces die verwendet
werden um eine EJB innerhalb derselben JVM ressourcenschonend zu benutzen.
Diese Interfaces definieren den angebotenen Funktionsumfang einer EJB durch

6 Fallbeispiel 66
die Auflistung der zur Verfügung stehenden Methoden. Die Implementierung
dieser Methoden erfolgt in der abstrakten Beanklasse. Zusätzlich gibt es noch
so genannte Home Interface Definitionen mit Methoden zur Instanzierung einer
EJB. Will ein Client die Funktionalität einer EJB nutzen tut er das über diese
Interfaces.
Für weiterführende Informationen zu Enterprise JavaBeans wird auf [BA04] und
[MH04] verwiesen.
Entity Beans
Entity Beans werden genutzt, um die Entitäten einer Applikation abzubilden.
Es handelt sich dabei um Dinge die in menschlichen Sprachen durch Nomen
ausgedrückt werden. Entity Beans repräsentieren die Daten einer Datenbank.
Änderungen an einer Entity Bean wirken sich direkt auf die Datenbank aus. Die
Hauptaufgabe dieser Beans ist es, den Zugriff und die Änderung von Daten für
J2EE Applikationen zu vereinfachen.
Auf die Eigenschaften dieser Entitäten wird durch Getter und Setter Methoden
zugegriffen. Des Weiteren bieten Enitiy Beans Operationen zum Suchen, Erstellen
und Löschen von Daten. Es ist zu vermeiden Entity Beans mit Logik zu überlas-
ten, für diese Aufgaben sind Session Beans zuständig.
Entity Beans bieten die Möglichkeit Container-Managed Persistence(CMP) zu
nutzen. Bei dieser Vorgangsweise verwaltet der Applikationsserver die Datenbank-
zugriffe selbst. Für den Entwickler ist es nicht mehr nötig SQL Statements oder
Stored Procedures zu verfassen. Alternativ dazu kann speziell bei der Integrati-
on von Legacy Systemen auch Bean-Managed Persistence eingesetzt werden. Bei
dieser Variante muss der Entwickler die nötige Persistenzlogik selbst verfassen.
Session Beans
Session Beans bilden die Logik einer Domäne ab. Sie können in vielen Fällen
durch Verben beschrieben werden. Es gibt zwei Arten von Session Beans: State-
ful und Stateless Session Beans.
Stateful Session Beans merken sich, wie der Name bereits andeutet, Information
über den Zustand der Interaktion mit dem Client. Stateless Session Beans tun das
nicht. Aus diesem Grund sind sie auch effizienter in der Verarbeitung und belas-
ten den Applikationsserver in geringerem Ausmaß. Die Methoden einer Stateless
Session Bean kann man mit statischen Methoden aus konventionellen Javaklassen
vergleichen.

Enterprise JavaBeans vs JavaBeans
6 Fallbeispiel 67
Sowohl Enterprise JavaBeans als auch JavaBeans sind ein Komponentenmodell.
In diesem Kontext definiert ein Komponentenmodell eine Reihe von Verträgen
zwischen einem Komponentenentwickler und der Laufzeitumgebung der Kom-
ponente. Die Verträge legen dabei fest, wie die Komponente auszusehen und in
welchem Format sie vorzuliegen hat.
Die einzige Gemeinsamkeit zwischen den beiden Modellen ist der Name. EJBs
sind im Gegensatz zu JavaBeans ein serverseitiges Komponentenmodell, das
die Umsetzung von verteilten Komponenten spezifiziert. Der Haupteinsatzzweck
von JavaBeans ist hingegen die Entwicklung von Clients durch die Verbin-
dung von visuellen und nicht-visuellen Widgets. Somit kann man JavaBeans
als Intraprozesskomponenten beschreiben, wohingegen Enterprise JavaBeans In-
terprozesskomponenten darstellen (vgl. [MH04] Seite 8 und 9).
JavaBeans kommen im Rahmen des Fallbeispiels im Sinne des Data Transfer
Object Pattern zum Einsatz (siehe Abschnitt 6.4.2).
JBoss Application Server
Als J2EE Applikationsserver wird im Rahmen des Fallbeispiels der als Open Sour-
ce erhältliche JBoss Application server in Version 4.0.3 SP1 eingesetzt. JBoss im-
plementiert den kompletten Umfang an J2EE Services und ist in Java geschrieben.
Für weitere Informationen zu JBoss siehe [jbo05a] und [JBo05b].
6.3.3 Struts Webframework
Um die Präsentationsschicht - die Webanwendung - des Fallbeispiels zu realisie-
ren, wurde das Apache Struts Webframework eingesetzt. Struts nutzt die Java-
technologien Servlet 1 und Java Server Pages (kurz JSP) 2 , um Entwickler insbe-
sondere in folgenden Punkten Hilfestellung zu bieten (siehe [Weß05] Seite 2):
• Überprüfen von Formulardaten auf deren Gültigkeit
• Steuerung des Kontrollflusses
• Integration von mehrsprachigen Texten
1 Servlets könnte man als die CGIs der Java Welt bezeichnen. Die API erlaubt es einen HTTP-
Request zu verarbeiten und die HTML-Ausgabe ähnlich wie bei CGI mittels Printkommandos
in einen Ausgabestrom zu schreiben.
2 Java Server Pages ermöglichen es Javacode in HTML-Code einzubetten. Dadurch wird die
mit Servlets mühsame Erzeugung von HTML-Seiten entschieden vereinfacht.

6 Fallbeispiel 68
Abbildung 6.3: Das Model 2 für Java Webanwendungen (Quelle [Weß05] Seite 13)
Aus architektonischer Sicht realisiert Struts durch die Verknüpfung von JSPs
und Servlets den Model 2-Ansatz, der eine Variante des bekannten Model-View-
Controller Paradigmas (kurz MVC) für Webanwendungen darstellt. MVC teilt
die Benutzerschnittstelle einer Applikation in drei Teile auf: das Model bildet die
Daten ab, die View stellt die graphische Ausgabe zur Verfügung und der Control-
ler kümmert sich um die Ablaufsteuerung. Die Model 2 Architektur ähnelt diesem
Paradigma sehr stark, unterscheidet sich aber auch in manchen Details. Für eine
Erläuterung des Unterschieds zwischen Model 2 und MVC siehe [Weß05] Seite 14.
Abbildung 6.3 zeigt das Model 2 für Java Webanwendungen, dabei wird eine JSP
zur Darstellung des Inhalt verwendet (View), ein zugehöriges Servlet übernimmt
die Rolle des Controllers und die Daten werden durch eine JavaBean - das Model
- abgebildet.
Anfragen eines Webbrowsers werden durch ein Servlet ausgewertet. Es entschei-
det auf Basis des HTTP-Requests welche JavaBeans erzeugt werden müssen
und welche JSP für die Darstellung verwendet wird. Benötigte Daten laden die
JavaBeans aus einem externen Informationssystem.
Das Servlet als zentrales Steuerelement gewährleistet die im MVC Paradigma
vorgeschriebene strenge Trennung von Daten, Darstellung und Kontrollfluss.
Die Architektur des Strutsframeworks zeigt Abbildung 6.4. Der Controller wird
dabei durch die Klasse ActionServlet repräsentiert. Diese Klasse wird mit
einer XML Datei konfiguriert und ist somit unabhängig von der konkreten
Anwendung in der sie zum Einsatz kommt. Zum Controller werden auch die
Actionklassen gezählt. Actionklassen sind normale Javaklassen, die durch den
Anwendungsentwickler implementiert werden müssen, die Klasse ActionServlet

6 Fallbeispiel 69
Abbildung 6.4: Die Architetektur des Struts Frameworks (Quelle: [Weß05] Seite
17)
ist im Gegensatz dazu Bestandteil des Frameworks. Bei der Entwicklung einer
Actionklasse leitet der Entwickler die Klasse Action ab und fügt den anwen-
dungsspezifischen Code ein.
Als View-Komponeneten werden im Normalfall JSP-Dateien in Verbindung
mit Struts-spezifischen Taglibs verwendet. Zusätzlich zu diesen Komponenten
bietet Struts eine spezielle JavaBean-Klasse, die ActionForm, an, von der die so
genannten FormBeans, die die Validierung erleichtern, abgeleitet werden können.
Das Model ist nicht genau spezifiziert und es bestehen keine Abhängigkeiten zu
bestimmten Technologien. Wie im Fallbeispiel können zum Beispiel Enterprise
JavaBeans in Kombination mit JavaBeans benutzt werden.
Das Fallbeispiel basiert auf dem Struts Framework in Version 1.2.8. Für weiter
gehende Informationen siehe [Weß05] und [str05].
Als Webserver kam ein eigenständiger Apache Tomcat Server Version 5.5 (
[tom05]) zum Einsatz. Aus Gründen der einfacheren Bedienbarkeit wurde auf
die Nutzung des in JBoss integrierten Apache Tomcat Webservers verzichtet.
6.4 Domänenarchitektur
Die Architektur des Fallbeispiels - die Onlinebuchhandlung ” Bücherwurm“ -
beruht auf einem dreischichtigen Ansatz. Bei diesem weit verbreiteten Aufbau
gliedert sich eine Applikation in die Teile Präsentation, Geschäftslogik und

6 Fallbeispiel 70
Abbildung 6.5: Schichtenarchitektur der Domäne ” E-Business Systeme“
Datenhaltung. Die Kommunikation zwischen diesen Schichten ist von der kon-
kreten Implementierung klar zu regeln, mit dem Ziel zyklische Abhängigkeiten
zu verhindern. Um solche Abhängigkeiten zu vermeiden, dürfen obere Schichten
die Funktionalität darunter liegender Schichten aufrufen, aber nicht umgekehrt.
Die Aufrufe sind dabei nicht auf die direkt darunter liegende Schicht beschränkt.
In der Praxis erfolgen die Aufrufe zum Teil über mehrere Schichten hinweg. Für
weitere Informationen siehe [Fow03] Seite 19 bis 22.
Abbildung 6.5 zeigt den dreischichtigen Aufbau der Fallbeispielarchitektur, die
im Folgenden zusammen mit den auf der jeweiligen Schicht vorkommenden Kon-
strukten erklärt wird. Geschäftslogik- und Datenhaltungsschicht werden durch
den Einsatz von EJBs und dem JBoss Application Server realisiert (siehe 6.3.2).
Die Präsentationsschicht wird durch eine Webapplikation, die auf dem Struts
Framework basiert und auf einem Apache Tomcat Webserver läuft, umgesetzt.
6.4.1 Datenhaltungsschicht
Die Datenhaltungsschicht hat die Aufgabe mit externen Datenquellen zu kom-
munizieren. Im Fallbeispiel ist diese externe Datenquelle der in JBoss integrierte
Hypersonic SQL Server in dem die Daten der Online Buchhandlung lagern. Der
Zugriff auf die Datenbank ist durch Entity Beans gekapselt. Sie führen sämtliche
CRUD-Operationen 3 auf der Datenbank für die Anwendung aus. Daneben bieten
3 Das Kürzel CRUD umschreibt die Standard DB-Operationen: Create-Read-Update-Delete

6 Fallbeispiel 71
die eingesetzten Entity Beans einfache Suchroutine über EJB-find (siehe [MH04])
Methoden an.
Entity Beans können von den Clients (= Präsentationsschicht) nicht direkt ange-
sprochen werden, da sie nur über Local Interfaces verfügen. Alle Zugriffe werden
über die im nächsten Abschnitt beschriebenen Session Beans im Sinne des Session
Facade Patterns gekapselt.
6.4.2 Geschäftslogikschicht
Die Geschäftslogik setzt sich aus Session Beans und JavaBeans, die im Sinne des
unten erklärten Data Transfer Object Pattern genutzt werden, zusammen. Sessi-
on Beans erfüllen unterschiedliche Aufgaben im Rahmen des Fallbeispiels. Zum
einen werden Stateless Session Beans genutzt um das J2EE Session Facade Pat-
tern (siehe unten) für die Architektur des Fallbeispiel umzusetzen. Zum anderen
baut die Domänenarchitektur auf Stateful Session Beans auf, um fachspezifische
Aspekte wie den ” Warenkorb“ der Onlinebuchhandlung zu implementieren.
Stateless Session Beans als Session Facades
In einem objektorientierten Umfeld ist es üblich kleine Objekte mit kurzen
Methoden zu designen. Auf diese Art und Weise wird die Kontrolle über den
Ablauf vereinfacht und einzelne Einheiten können leichter ersetzt werden. Eine
Konsequenz dieser fein granulierten Strukturen sind zahlreiche Interaktionen
zwischen den Objekten bzw. Methodenaufrufe. Solange sich alle Objekte im
selben Adressraum befinden, stellt dieser Umstand kein Problem dar. Befinden
sich die Objekte allerdings in den Adressräumen unterschiedlicher Rechner, die
über ein Netzwerk miteinander kommunizieren, kann dieses Design zu einem
Ressourcenproblem führen und die Performance darunter leiden.
Dieses Problem wird vom Session Facade Pattern (siehe [ses06]), das eine
große Ähnlichkeit mit dem in [Fow03] Seite 388ff beschriebenen Remote Facade
Pattern aufweist, adressiert. Bei diesem Pattern wird von den darunter liegenden
feingranulierten Objekten abstrahiert und ein ” grobkörniges“ aber Ressourcen
schonendes Interface zur Verfügung gestellt. Die Session Facade verwaltet die
Interaktionen zwischen den Geschäftsdaten und den Geschäftsobjekten, die in
einem Workflow vorkommen. Des Weiteren kapselt sie die für diese Vorgänge
nötige Geschäftslogik. Eine effiziente Form der Implementierung für Session
Facades stellen die in Abschnitt 6.3.2 vorgestellten Stateless Session Beans dar.
Eine mögliche Vorgangsweise, um die für eine Anwendung nötigen Session Facades

6 Fallbeispiel 72
zu bestimmen, ist es die Anwendungsfälle zu analysieren und die sich daraus
ergebenden Session Facades logisch zu gruppieren und zusammenzufassen.
JavaBeans als Data Transfer Objects
Um die Arbeit der im vorigen Abschnitt beschriebenen Session Facades zu
erleichtern, ist es wichtig mit einem Methodenaufruf möglichst viele Daten zu
transportieren. Diese Aufgabe kommt den in [Fow03] Seite 401ff erläuterten Data
Transfer Objects zu. Diese Objekte bestehen in der Regel nur aus einer beliebigen
Anzahl von Variablendefinitionen und zugehörigen Getter- und Settermethoden.
Wann immer eine Session Bean Daten mit einem Client austauscht, geschieht dies
auf Basis eines Data Transfer Objects. Im Regelfall werden dabei mehr Daten
als für die Bearbeitung einer Aufgabe nötig sind transportiert. Dieser Overhead
an Daten ist gegenüber der Latenzzeit der Remote Calls meist das geringere Übel.
Data Transfer Objects setzen sich oft aus mehreren anderen Data Transfer
Objects zusammen. Die sich aus den Beziehungen ergebende Struktur stellt
immer einen einfachen Graphen dar. Für weitere Informationen wird auf [dat06]
verwiesen.
Im Rahmen der Domänenarchitektur des Fallbeispiels läuft die gesamte Kom-
munikation zwischen den EJBs und dem Webclient der Präsentationsschicht auf
Basis von JavaBeans ab, die im Sinne des Data Transfer Object Patterns genutzt
werden.
6.4.3 Präsentationsschicht
Die Hauptaufgabe der Präsentationsschicht ist es, dem Benutzer Informationen
anzuzeigen und Eingaben in Aktionen auf die Objekte der Geschäftslogik und Da-
tenhaltungsschicht umzuwandeln. Im Rahmen des Fallbeispiels übernimmt diese
Aufgaben ein auf dem Struts Framework (siehe Abschnitt 6.3.3) basierender Web-
client. Mit Hilfe dieser Technologie wurde die an das MVC Pattern angelehnte
Servlet Model 2 - Architektur umgesetzt, bei der ein Controller (ActionServlet
und Actionklassen) die Ablaufsteuerung übernimmt, die gewünschten Operatio-
nen auf das Datenmodell (JavaBean) ausführt und eine Antwortseite (JSP) gene-
riert. Durch diesen Aufbau erfolgt auch auf Ebene der Präsentationsschicht eine
Aufgabenteilung.
Im Rahmen des Fallbeispiels wurden diverse bei der Arbeit mit dem Struts Fra-
mework übliche Patterns und Techniken genutzt, die im Folgenden beschrieben

werden.
BaseAction Pattern und Rechteverwaltung
6 Fallbeispiel 73
Die Actionklassen einer Struts-Webapplikation müssen vor der Durchführung der
eigentlichen Aufgabe in vielen Fällen die gleichen bzw. sehr ähnliche vorbereiten-
de Schritte durchführen. So müssen beispielsweise benötigte Objekte instanziert,
Verbindungen zu externen Systemen aufgebaut und die Zugriffsrechte überprüft
werden. Es ist daher nahe liegend diese Aufgaben in eine abstrakte Basisklasse
auszulagern. Diese abstrakte Basisklasse nennt man BaseAction(vgl. [Weß05]
Seite 237).
Bei ” Bücherwurm“ wird in der BaseAction die Zugriffskontrolle vorgenommen.
Dabei wird dem so genannten Gatekepper aus dem Paket com.buecherwurm.web
der Typ des aktuellen Benutzers und der Kontext (= Actionpath) des Aufrufs
übergeben. Auf Basis einer internen Tabelle entscheidet der Gatekepper über
die Genehmigung des Zugriffs.
Die für die Entscheidung nötigen Informationen liegen außerhalb des Ge-
nerierungsfokus des Fallbeispiels und müssen vom Entwickler händisch
ergänzt werden. Der für das Fallbeispiel erzeugte Code baut auf den Klassen
com.buecherwurm.web.Gatekepper und com.buecherwurm.web.BaseAction
auf. Aus diesem Grund kann man beide als Bestandteil der Plattform betrachten.
Kapselung von JSPs mittels ActionFirst Pattern
Sämtliche HTML-Seiten, die der Benutzer erhält, basieren auf Java Server Pa-
ges. Um sicherzugehen, dass alle von der JSP zum Anzeigen der Seite benötigten
Informationen in der Anfrage(Request) oder Sitzung (Session) vorhanden sind,
ist es empfehlenswert, die JSP über eine Actionklasse aufzurufen. Diese Action-
klasse prüft das Vorhandensein aller benötigten Informationen und lädt eventuell
fehlende Elemente. Um ein Umgehen dieser Vorschrift zu verhindern, müssen alle
JSPs der Anwendung unterhalb des Verzeichnisses WEB-INF liegen. Der Inhalt die-
ses Ordners kann von einem Client nicht direkt aufgerufen werden, sondern nur
indirekt über eine Webapplikation. Diese Vorgangsweise wird auch ActionFirst
Pattern genannt (siehe [Weß05] Seite 238).
Gestaltung von JSP-Seiten mit der Struts Tiles Template-Engine
Die Webseiten einer Webapplikation bestehen aus verschiedenen Bereichen, wie
zum Beispiel primären und sekundären Navigationselementen, dem Seiteninhalt

6 Fallbeispiel 74
Abbildung 6.6: Schematischer Aufbau der Webseiten des Fallbeispiels
und einem Seitenfuß. Ein Teil dieser Elemente ist für alle Seiten gleich. Aus diesem
Grund ist es nahe liegend eine Vorlage zu erstellen, die mit den jeweils aktuellen
Elementen ausgefüllt wird.
Eine Möglichkeit um diese Vorlagen zu definieren, ist die zu Struts gehörige
Template-Engine Tiles (siehe [Weß05] Kapitel 8). Sie bietet einfache Konstrukte,
um die Teilbereiche einer auf JSP basierenden Webseite modular zu erstellen.
Der Webdesigner erstellt dabei eine Layoutdefinition, die auch weiter vererbt
und spezialisiert werden kann. In der Konfigurationsdatei tiles-def.xml wer-
den anschließend die Kombinationen von JSP-Dateien festgelegt aus denen sich
die Seiten der Webanwendung zusammensetzen.
Abbildung 6.6 zeigt den schematischen Aufbau der ” Bücherwurm“ Webseiten.
Die Seite ist eingeteilt in die Bereiche ” Primäre und Sekundäre Navigation“,
” Footer“ und ” Seiteninhalt“. Generiert wird der Bereich Seiteninhalt“. Die übri-
”
gen Bereiche sind händisch von einem Webdesigner zu ergänzen, bzw. über al-
le Seiten identisch. Die Definition der Layoutvorlage erfolgt im Fallbeispiel se-
parat für jede Benutzergruppe. Das Seitenlayout für Administratoren wird in
jsp/admin/index.jsp festgelegt. Für Kunden erfolgt die Definition analog in
jsp/kunde/index.jsp.

6 Fallbeispiel 75
Abbildung 6.7: Metamodell der Domäne
” Softwarearchitektur für E-
Businesssysteme“ als UML-Profil
6.5 Metamodell
6.5.1 Metamodell in UML-Profil-Form
Ziel dieses Abschnitts ist es, die einzelnen Elemente des Metamodells, dargestellt
in Abbildung 6.7 als UML-Profil, näher zu beschreiben, ihre Bedeutung im Rah-
men der Architektur zu erklären und Einschränkungen sowie Zusammenhänge
zwischen den Elementen aufzuzeigen. Des Weiteren werden die aus den einzelnen
Stereotypen heraus generierten Codeteile skizziert.
EntityObject
Das Stereotyp > ist eine Spezialisierung von UML::Class. Es
werden damit jene Klassen gekennzeichnet, die die Entity Beans (siehe 6.3.2) des
Systems beschreiben. EntityObjects sind architektonisch auf Ebene der Daten-
schicht angesiedelt und kapseln die Zugriffe der Anwendung auf eine Datenbank.
Im Zuge der Generierung wird für jedes EntityObject eine Entity Bean mit Local
Interfaces, einer Beanklasse sowie den nötigen Konfigurationsdateien generiert.
Für jedes Attribut werden die nötigen Getter- und Setter-Methoden erstellt.
Als einzige Methoden sind find-Methoden, mit denen gezielt nach Entity Beans

gesucht werden kann, vorgesehen.
6 Fallbeispiel 76
Bei der Modellierung dieser Datenobjekte sind mehrere Regeln zu beachten. Zum
einen ist es nötig, dass jedes EntityObject genau ein Attribut - ausgezeichnet
mit dem Stereotyp > - besitzt. Zum anderen muss der Eigenschafts-
wert KeyType des Stereotyp > entweder den Wert USER
oder SYSTEM aufweisen. Mit > wird der eindeutige Schlüssel zur
Identifizierung einer Entity Bean definiert. Der Eigenschaftswert KeyType gibt
an wer - ob Benutzer oder System - diesen Schlüsselwert setzt.
Neben KeyType gibt es noch den Eigenschaftswert RangeOfValues der anzeigt,
dass ein EntityObject eine Wertemenge abbildet, die als gegeben angesehen
wird. Im Fallbeispiel sind das Entitäten wie ” Kreditkartenfirma“ oder ” Verlag“.
Per Konvention dürfen EntityObjects nur mit EntityObjects assoziiert werden.
Diese Maßnahme ist im Sinne der schichtenorientierten Domänenarchitektur not-
wendig, um tiefere Schichten unabhängig von höheren zu halten. Da EntityOb-
jects in der Datenschicht angesiedelt sind, die die Tiefste des Systems darstellt,
dürfen sie nur mit ihresgleichen assoziiert werden.
Eine weitere Regel der EntityObjects genügen müssen, ist der Umstand, dass es
keine bidirektionalen Assoziationen zwischen ihnen geben darf, bei der auf bei-
den Seiten die untere Schranke der Kardinalität eins ist. Wäre das der Fall, hätte
man ein typisches ” Henne-Ei-Problem“, konstruiert. Beide assoziierten Partner
brauchen sich von Anfang an, um bestehen zu können.
Key
Das Stereotyp > ist eine Spezialisierung eines UML::Attribute und
kennzeichnet Attribute, die einen eindeutigen Schlüssel für die Instanzen einer
Klasse darstellen. Angewandt wird das Stereotyp auf die Attribute von EntityOb-
ject und DataObject, wobei nur jeweils eines der Attribute mit diesem Stereotyp
ausgezeichnet werden kann.
DataObject
Das Stereotyp > zeichnet Klassen aus, die das in Abschnitt
6.4.2 beschriebene Data Transfer Object Pattern implementieren. Um dieses De-
signmuster umzusetzen, wird für jedes EntityObject ein DataObject modelliert,
das eine exakte Kopie des EntityObjects darstellt.
Auf Codeebene wird für jedes DataObject eine Javaklasse generiert die den

6 Fallbeispiel 77
Konventionen des JavaBean Komponentenmodells folgt (siehe 6.3.2). Die Über-
einstimmung zwischen einem EntityObject und dem zugehörigen DataObject
wird vor der Generierung überprüft. Besonderes Augenmerk wird dabei auf
Attribute und Methoden geworfen. Die Zuordnung erfolgt auf Basis des Klassen-
namens.
Architektonisch sind DataObjects zusammen mit den im nächsten Abschnitt be-
schriebenen ProcessObjects auf Ebene der Geschäftslogikschicht angesiedelt.
ProcessObject
Das Stereotyp > ist eine Spezialisierung von UML::Class
und realisiert das in Abschnitt 6.4.2 beschriebene Session Facade Pattern für
die Domänenarchitektur. Aus Sicht der Architektur sind ProcessObjects Teil
der Geschäftslogik. Auf Codeebene handelt es sich dabei um eine Reihe von
Stateless Session Beans, die im Namen des Clients alle Operationen auf die
Entity Beans des Systems durchführen. Im Konkreten sind das so genannte
CRUD-Operationen, sowie diverse Suchmethoden 4 . Als Datenaustauschformat
zwischen einem ProcessObject und einem Client dienen die bereits beschriebenen
DataObjects in Form von JavaBeans. Diese Vorgangsweise unterstützt eine
verbesserte Trennung zwischen den einzelnen Schichten der Architektur und
erlaubt einem Client einen einfacheren Zugriff auf die Entity Beans.
Zwischen einem ProcessObject und den von ihm betreuten EntityObjects, die
in Beziehung stehen und gemeinsam einen Sachverhalt abbilden, besteht eine
Abhängigkeitsbeziehung, die von ProcessObject zu EntityObject führt. Um den
Transformationsvorschriften einen Einstiegspunkt zu bieten und explizit auszu-
drücken, welcher Typ von DataObject zwischen einem ProcessObject und einem
Client ausgetauscht wird, existiert weiters eine Abhängigkeit vom modellierten
ProcessObject zu genau einem DataObject. Es handelt sich dabei um jenes
DataObject, dessen EntityObject im modellierten Sachverhalt eine zentrale
Rolle einnimmt. Ein Beispiel zeigt Abbildung 6.8, die die Kundenverwaltung
des Fallbeispiels darstellt. Hier werden die Entitäten ” Kunde“, ” Kreditkarte“
und ” Adresse“ von einem ProcessObject namens ” Kundenverwaltung“ betreut.
Eine zentrale Stellung nimmt der Kunde in diesem Sachverhalt ein, da ohne
4 Die Domänenarchitektur unterscheidet zwei Varianten von Suchmethoden. Variante eins besitzt
das Präfix search und meint Suchmethoden, die auf von einem Entwickler zur Verfügung
gestellten SQL-Select-Statement aufbauen. Variante zwei besteht aus EJB-find-Methoden,
die das Präfix find besitzen. Hier wird von Seiten des ProcessObject nur ein Mapping auf
eine find-Methode eines EntityObject durchgeführt.

6 Fallbeispiel 78
Abbildung 6.8: Die Kundenverwaltung von ” Bücherwurm“
ihn die Entitäten ” Kreditkarte“ und ” Adresse“ keine Bedeutung hätten. Um
diese Bedeutung zu unterstreichen und anzuzeigen welchen Typ die mit einem
Client ausgetauschten DataObjects aufweisen müssen, wird zusätzlich eine
Abhängigkeit von Kundenverwaltung zu DataObject ” Kunde“ modelliert.
Betrachtet man Abbildung 6.5 und ordnet die besprochenen Stereotypen den
einzelnen Schichten der Architektur zu, stellt man fest, dass zwischen diesen und
den im Folgenden beschriebenen eine logische Trennung existiert. Alle bisherigen
Stereotypen, mit Ausnahme der DataObjects, die zum Datenaustausch benutzt
werden, sind durch Komponenten realisiert, die serverseitig betrieben werden. Im
konkreten Fall laufen sie auf einem JBoss Application Server.
Die nun beschriebenen Controller und Presentation Elemente sind Teil der
Präsentationsschicht und im Falle der vorliegenden Domänenarchitektur der Cli-
entseite, realisiert mit Hilfe des Struts Frameworks, zuzuordnen.

ActivityController und seine Erben
6 Fallbeispiel 79
Das Stereotyp > zeichnet Klassen aus, die auf Co-
deebene durch Struts Actions realisiert werden. Da die Erzeugung von Struts
Actionklassen ohne Einbeziehung einer funktionalen Sichtweise nur einen sehr
beschränkten Generierungsfaktor zulässt, wird ActivityController von zwei wei-
teren Stereotypen SearchController und AdministrativeController spezialisiert.
Bei beiden Varianten steht die Erfüllung von konkreten Aufgaben (Suche und
Datenverwaltung) im Vordergrund.
Alle drei Controllervarianten sind Teil der Präsentationsschicht und bilden die
Controller der Servlet-Model2 Architektur (siehe 6.3.3) ab.
Bei der Modellierung von Controller Elementen sind diverse Regeln zu beachten.
Zum einen muss ein Controller eine Abhängigkeit zu genau einer Presentation und
eine Assoziation zu genau einem ProcessObject aufweisen. Zum anderen muss ei-
ne Abhängigkeit zum selben DataObject, wie dam assoziierten ProcessObject,
existieren. Die Abhängigkeit zu einem DataObject wird aus dem selben Grund
wie bei einem ProcessObject benötigt, da der Controller explizit wissen muss
welcher Typ von DataObject als Datenaustauchformat herangezogen wird.
Durch diese Modellierung wird die Semantik der Servlet-Model2 Architektur im
Metamodell ausgedrückt, wobei Presentation Elemente den Bereich View reali-
sieren und ProcessObjects sowie DataObjects das Model repräsentieren.
AdministrativeController
Das Stereotyp > stellt eine Spezialisierung des
bereits beschriebenen Stereotyps > dar. Dieses Element
hat die Aufgabe die Eingaben von neuen Daten und die Abänderung von beste-
henden Daten zu koordinieren. Außerdem ermöglichen AdministrativeController
das Löschen von Daten.
Im Allgemeinen betreut ein AdministrativeController den selben Datenbe-
reich wie der durch die Entitäten des assoziierten ProcessObject abgebilde-
te. Ein AdministrativeController muss von einer Presentation des Typs > abhängig sein.
Die korrekte Modellierung eines AdministrativeControllers zeigt Abbildung 6.9
anhand der Kundenverwaltung.

6 Fallbeispiel 80
Abbildung 6.9: Die Modellierung einer Webschnittstelle zur Datenverwaltung

SearchController
6 Fallbeispiel 81
Abbildung 6.10: Die Modellierung einer Suche
> stellt ebenfalls eine Spezialisierung von > dar und erlaubt die Suche nach den vom assoziierten
ProcessObject verwalteten Entitäten. Die Suchergebnisse werden in Form von
DataObjects zurückgegeben. Ein SearchController muss von einer Presentation
des Typs > abhängig sein.
Die korrekte Modellierung eines SearchControllers zeigt Abbildung 6.10 anhand
der Kundensuche.
Presentation
Aus dem Stereotyp > werden die User Interface Komponen-
ten der Anwendung generiert. Im Konkreten sind das Java Server Pages und die
zugehörigen FormBeans, um die eingegebenen Daten zwischenzuspeichern. Die
Attribute der Presentation spiegeln sich in den Eingabefeldern der JSP wider-
spiegeln. Aus den Methoden wird der HTML Code für Buttons generiert. Alle
Attribute einer Presentation sind mit dem weiter unten beschriebenen Stereotyp
> gekennzeichnet. Die Einhaltung dieser Konvention wird vor
dem Generierungsvorgang überprüft. Da der für das User Interface benötigte Co-
de nicht in allen Situationen dem selben Schema folgt, wird >
durch > und > spezialisiert.

UIAttribute
6 Fallbeispiel 82
Das Stereotyp > ist eine Ableitung von UML::Attribute und
kann nur auf die Attribute einer Presentation angewandt werden. UIAttribute
führt mit dem Eigenschaftswert MappedToAttribute ein Mapping auf ein Attri-
but eines DataObject durch. Mit Hilfe dieser Zuordnung ist ein Controller in der
Lage aus den Attributen einer Presentation die nötigen DataObjects zu erzeugen.
Neben diesem Mapping kann mit den Eigenschaftswerten des Stereotyps ein At-
tribut als Passwort oder Hiddenfield im Sinne von HTML gekennzeichnet werden.
AdministrativeMask
Eine > realisiert das User Interface für die Eingabe
von Daten und ist die Spezialisierung einer Presentation. Sie muss alle nötigen
Eingabefelder definieren, um die Entitäten des durch den abhängigen Adminis-
trativeControllers betreuten Sachverhalts erzeugen und ändern zu können.
Für AdministrativeMask werden im direkten Vergleich mit Presentation im JSP
zusätzliche HTML- Hiddenfields generiert, die den Status - ” Bearbeiten“ oder
” Neu“ speichern und im Falle einer Bearbeitung auch die unique IDs der bearbeiteten
DataObjects.
SearchMask
Aus einer Klasse mit dem Stereotyp > wird das User Interface
für die Suche im Datenbestand generiert. Um die Eingabefelder in der JSP-Datei
besser gruppieren zu können und dem SearchController den Aufruf der korrekten
Suchmethode zu ermöglichen, ist es per Konvention erforderlich ein Attribut der
SearchMask so zu benennen wie den korrespondierenden Parameter der Suchme-
thode.
6.5.2 Integration des Metamodells in openArchitectureWare
In Abschnitt 6.5.1 werden die Konzepte des Metamodells anhand eines UML
Profils beschrieben. Um dem oAW Generator dieses Metamodell bekannt zu
machen, muss eine Umwandlung in Javaklassen vorgenommen werden. Dieser
Schritt ist wie in Kapitel 5 erklärt erforderlich, um die Transformationsvorschrif-
ten vor der Komplexität der Eingabeformate, in denen die Modelle zum Teil
vorliegen, abzukapseln. Des Weiteren wird die Nutzung verschiedenster Formate
ermöglicht, da der Generator durch die Repräsentation mit Hilfe von Javaklassen
auf einer einheitlichen Schnittstelle aufbauen kann.

6 Fallbeispiel 83
Neben der Vereinheitlichung der Eingabeformate hat der Einsatz eines Me-
tamodells auf Basis von Javaklassen noch einen weiteren Zusatznutzen. Die
Metamodellklassen bieten neben den in 5.8 erwähnten Extensions eine Möglich-
keit in den Transfomationsvorschriften benötigte Logik zu implementieren. Eine
” Kostprobe“ von typischen Funktionen, die in einer Metamodellklasse integriert
werden, wird weiter unten in diesem Abschnitt gegeben. Für weitere Beispiele
wird auf den beiliegenden Sourcecode zum Fallbeispiel verwiesen.
Die Umwandlung eines Metamodells von UML in Java Metamodellklassen muss
nicht händisch vorgenommen werden, sondern kann mit Hilfe eines Metamodell-
generators, der Teil des oAW Toolkits ist, durchgeführt werden. Der Generator
wird über ein beiliegendes Workflowskript, das korrekt parametrisiert werden
muss, gestartet. Die Parametrisierung erfolgt durch ein Propertiesfile. Die kon-
kreten Werte für das Fallbeispiel zeigt Listing 6.1, generate.properties liegt
im Verzeichnis eba-Generator/metamodel.
Listing 6.1: Propertiesfile zur Parametrisierung des Metamodellgenerators
modelFile = ebaMetamodel . zuml
# Mappingfile um das XMI des Modellierungstool
# korrekt zu verarbeiten
xmlMapFile = org / openarchitectureware / core / frontends / xmi /
toolsupport / uml / poseidon / poseidon31_xmi12_all . xml
# Modellierungstoolspezifischer Adapter
# zum Einlesen des XMI
toolAdapterClassname = org . openarchitectureware . core .
frontends . xmi . toolsupport . uml . poseidon . PoseidonAdapter
# Jede Metaklasse erhält ein Prefix
classPrefix = EBA
modelModifierClassname =
MODELMOD . FILE =
# Die folgenden Variablen basieren auf dem
# Projektverzeichnis
# e.g. genPath mündet in eba - Generator /src - gen
# Mögliche Definition eines Oberverzeichnisses für sämtliche
# Ausgaben .
# Inhalt wird vor der Generierung gelöscht !
genPath = src - gen
# Das Dumpfile des Generatorlaufs

dumpfile = metamodel / mmgen . dump
6 Fallbeispiel 84
# Das Verzeichnis in dem der generierte Code gespeichert
# wird .
srcPath = src - gen
# Verzeichnis für die Javadoc
HTMLOUTPUT . DIR = html - gen
Adaption des UML-Metamodells für den Metamodellgenerator
Abbildung 6.7 zeigt das Metamodell der Domäne ” Softwarearchitektur für
E-Businesssystem“ in Form eines UML-Profils. Dieses Modell kann nicht wie
in Abschnitt 5.5.2 erwähnt ohne vorherige Anpassung mit dem Metamodell-
generator verarbeitet werden. Zum einen muss eine Anbindung an die bereits
bestehende UML-Metamodellklassen des Frameworks vorgenommen werden.
Zum anderen müssen die extensions-Beziehungen des Profils gegen Vererbungs-
beziehungen ausgetauscht werden. Das adaptierte Metamodell zeigt Abbildung
6.12 für die Erben von UML::Class und Abbildung 6.11 für die Erben von
UML::Attribute.
Die Tatsache, dass die Metamodellelemente nicht direkt von
org.openarchitectureware.meta.uml.classifier.Class abgeleitet sind
sondern indirekt über eba.meta.base.EBAClass 5 , das eine Ableitung der Fra-
meworkklasse durchführt, ist gesondert hervorzuheben. Dieser Zwischenschritt
erlaubt die Implementierung von modellweit benötigter Funktionalität, wie
Extraktion aller navigierbaren Assoziationen, Ausgabe des Klassennamen in
einem bestimmten Format, Suchmethoden etc.. Ähnlich verhält es sich bei den
Attributen, hier wurde mit eba.meta.base.EBAAttribute eine Spezialisierung
von org.openarchitectureware.meta.uml.classifier.Attribute vorgenom-
men.
Die Taktik, gemeinsam genutzte Funktionalität in einer abstrakten Ba-
sisklasse zu bündeln, wurde auch bei den inhaltlich verwandten Klassen
eba.meta.data.EBAEntityObject und eba.meta.data.EBAEntityObject
angewandt. Beide erben von eba.meta.data.EBADataClass.
5 Aus historischen Gründe werden alle Java Metamodellklassen mit einem eindeutigen definierten
Präfix versehen (siehe Listing 6.1). Dieses Präfix wird im UML-Metamodell nicht
verwendet. Der Grund dafür ist, dass vor oAW4 in den Templates das Namespacekonzept
nicht genutzt werden konnte. Um die einzelnen Metamodellklassen dennoch zu unterscheiden
wurde ein eindeutiges Präfix eingeführt.

6 Fallbeispiel 85
Abbildung 6.11: Adaptiertes Metamodell der Erben von UML::Attribute
Modellvalidierung mit Check
Bei der Beschreibung der Metamodellkonzepte in Abschnitt 6.5.1 wurde immer
wieder auf diverse Regeln hingewiesen, denen die Modelle genügen müssen.
Die Einhaltung dieser Regeln wird in oAW mit Hilfe der in Abschnitt 5.9
erklärten Sprache Check überprüft. Die Definitionen finden sich in den Dateien
ebaChecks.chk und eba-Web-Checks.chk des eba-Generator Projekts.
Im Fallbeispiel nehmen die Regeldefinitionen eine zusätzliche Funktion ein: Sie
drücken nicht in den Stereotypen bzw. Metamodellklassen enthaltene Seman-
tik aus. So ist beispielsweise durch das UML Profil aus Abbildung 6.7 nicht
festgelegt, dass ein EntityObject genau ein Attribut des Typs Key aufweisen
muss. Dieser Constraint wird erst durch eine Validierungsregel festgelegt. Im
Fallbeispiel sind Checkdefinitionen ein wichtiger Teil des Metamodells.
Wie ein Teil dieser Semantik in das Metamodell, gebildet durch Stereotypen oder
Metamodellklassen, verlagert werden kann, zeigt eine alternative Darstellung des
Metamodells in Abschnitt 6.8.
Beispiele für Funktionalität in Metamodellklassen
Dieser Abschnitt zeigt typische Beispiele von Methoden, die in den Metamodell-
klassen zu finden sind. Sämtliche Beispiele sind dem Sourcecode zum Fallbeispiel

6 Fallbeispiel 86
Abbildung 6.12: Adaptiertes Metamodell der Erben von UML::Class

6 Fallbeispiel 87
entnommen. Die Listings sollen eine Eindruck vermitteln wie mit Hilfe des oAW
Frameworks Information, die in den Transformationsvorschriften genutzt wird,
aus einem Modell extrahiert wird. Weitere Informationen können dem auf der
Beilagen-CD befindlichen Sourcecode des Fallbeispiels entnommen werden.
Listing 6.2 zeigt die Methode Key der Klasse eba.meta.base.EBADataClass mit
deren Hilfe der eindeutige Schlüssel eines ” Datenobjekts“, den EntityObjects und
DataObjects definieren müssen, aus der Menge der Attribute extrahiert wird. Um
das entsprechende Attribut zu finden wird einer Klasse Filter, die vom oAW
Framework zur Verfügung gestellt wird, die Menge der Attribute übergeben und
ein Filter, der überprüft ob ein Element vom Typ EBAKey ist. Im Anschluss wird
festgestellt, ob genau ein Element in der Ergebnismenge enthalten ist. Ist das
nicht der Fall wird null zurückgegeben, sonst der Schlüssel dieses Datenobjekts.
/**
Listing 6.2: Die Methode Key() der Klasse EBADataClass
* Die Methode filtert die Menge der Attribute und
* liefert den Schlüssel zurück .
* @return Der eindeutige Schlüssel des
* Datenobjekts
*/
public EBAKey Key (){
}
ElementSet keys = Filters . filter ( this . Attribute () ,
new TypeFilter ( EBAKey . class ));
// Es muss einen Schlüssel geben !
if( keys . isEmpty ())
return null ;
// Es muss genau einen Schlüssel geben
else if( keys . size () >1)
else
return null ;
return ( EBAKey ) keys . iterator (). next ();
Die Methode isUserDefinedKey() der Klasse eba.meta.data.EBAEntityObject
aus Listing 6.3 prüft, ob der Wert des eindeutigen Schlüssels vom Benutzer gesetzt
wird. Um das zu bestimmen, ist im Stereotyp EntityObject der Eigenschaftswert
KeyType vorgesehen. Dieser kann vom Modellierer entweder mit dem Wert
USER oder SYSTEM belegt werden. Bei der Instanzierung wird dieser Wert
ausgelesen und die korrespondierende Variable in der Metamodellklasse En-
tityObject instanziert. Die Methode KeyType() gibt diesen Wert zurück. Weist

6 Fallbeispiel 88
die Variable den Wert USER auf, wird true zurückgegeben.
Listing 6.3: Die Methode isUserDefinedKey() der Klasse EBAEntityObject
/**
* Prüft ob der Typ des Schlüssel Benutzer definiert ist .
* @return True falls die Annahme zutrifft
*/
public boolean isUserDefinedKey (){
}
if( this . KeyType (). toUpperCase (). equals (
else
EBAEntityObject . USER_KEYTYPE ))
return true ;
return false ;
Die Methode UIAttribute() der Klasse eba.meta.presentation.
EBAPresentation aus Listing 6.4 selektiert alle Attribute einer Presentati-
on, die vom Typ EBAUIAttribute sind, und ein Mapping auf ein Attribut eines
DataObjects aufweisen.
/**
Listing 6.4: Die Methode UIAttribute() der Klasse EBAPresentation
* Die Methode retouniert alle Attribute die vom Type
* EBAUIAttribute sind und ein Mapping auf
* ein Attribut eines Datenobjekts besitzen .
* @return
*/
public ElementSet UIAttribute (){
this . uiAttributes = new ElementSet ();
// Selektiere aus der Menge der Attribute
// alle EBAUIAttribute
this . uiAttributes . addAll (
this . Attribute (). filter ( EBAUIAttribute . class ));
Iterator it = this . uiAttributes . iterator ();
// Prüfe das Mapping auf das Attribut eines
// Datenobjekts
while (it. hasNext ()){
EBAUIAttribute att = ( EBAUIAttribute )it. next ();
if(att . AttributeMappedTo () == null ||
att . PointsToDataObject () == null )
this . uiAttributes . remove ( att );

}
}
return this . uiAttributes ;
6 Fallbeispiel 89
6.6 Transformationsvorschriften - Xpand
Die Transformationsvorschriften oder Templates zur Erzeugung des Codes aus
einem Modell heraus werden in openArchitectureWare in der Sprache Xpand
definiert. Die Konstrukte und der Aufbau von Xpand wurden bereits in Abschnitt
5.6 vorgestellt. An dieser Stelle wird anhand des Fallbeispiels gezeigt, wie man
Templates strukturieren kann und welche Möglichkeiten es zur Trennung von
generiertem und nicht generiertem Code gibt.
6.6.1 Strukturierung von Xpand-Templates
Xpand Templates besitzen eine baumähnliche Strutur. Ein Template - be-
stehend aus einem DEFINE-Block - ist ein Blatt des Baumes. Die Wurzel
- das Starttemplate - wird dem oAW-Generator in einem Workflowskript
per Konfigurationsparameter bekannt gegeben (siehe Abschnitt 6.7.3). Die
Summe aller Templates eines Generators kann aus beliebig vielen Bäumen beste-
hen, wobei anzumerken ist, dass ein Blatt in mehreren Bäumen vorkommen kann.
Der Generator zur Domäne ” Softwarearchitektur für E-Businesssysteme“ des Fall-
beispiels umfasst zwei Templatebäume. Baum eins, steuert die Ausgabeerzeugung
für die Geschäftslogik und Datenhaltungsschicht. Das heißt, mit seiner Hilfe wer-
den die Enterprise JavaBeans des Systems generiert. Die Wurzel bildet das Tem-
plate eba::templates::EJBRoot::Root aus dem Sourcefolder des Generatorpro-
jekts.
Baum zwei ist für die Codeausgabe des Webfrontends zuständig. Mit seiner Hilfe
werden die benötigten Struts Actionklassen, FormBeans und Java Server Pages
generiert. Die Wurzel bildet das Template eba::templates::WebRoot::Root,
das ebenfalls im Sourcefolder des Generatorprojekts liegt.
Wurzeltemplate und Metaumgebung
oAW bezeichnet den Bereich, in dem sämtliche Elemente eines soeben instanzier-
ten Modells liegen, als Metaumgebung (siehe [Völ05c] Seite 19). Um die Transfor-
mationsvorschriften auf das instanzierte Modell anwenden zu können, benötigt

6 Fallbeispiel 90
der Generator neben einem Wurzeltemplate auch einen Einstiegspunkt in die
Metaumgebung. Das heißt, dem Wurzeltemplate muss kenntlich gemacht werden,
mit welchen Elementen der Templatebaum zu durchlaufen ist. Im Fallbeispiel
übernimmt diese Aufgabe die Klasse eba.meta.EBATop, die mit ihren Methoden
Elemente der Metaumgebung selektiert und den Wurzeltemplates zur Verfügung
stellt. EBATop kann als ein ” Pseudoelement“ beschrieben werden, dessen einzi-
ger Zweck es ist, einen Einstiegspunkt für die Codegenerierung zu bilden. Ein
Ausschnitt des Quellcodes zu EBATop ist in Listing 6.5 zu sehen.
Listing 6.5: Der Einstiegspunkt für Templates zur Codegenerierung
public class EBATop extends CustomModelElement {
}
...
/**
* Die Methode sucht sämtliche Objekte vom Typ
* EBADataObject heraus .
* @return Ein ElementSet mit EBADataObjects
*/
public ElementSet EBADataObject (){
}
/**
ElementSet dataObjects = MMUtil . findAllInstances (
EBADataObject . class );
return dataObjects ;
* Die Methode sucht sämtliche Objekte vom Typ
* EBAEntityObject heraus .
* @return Ein ElementSet mit EBAEntityObjects
*/
public ElementSet EBAEntityObject (){
}
...
ElementSet entityObjects = MMUtil . findAllInstances (
EBAEntityObject . class );
return entityObjects ;
Die Methoden von EBATop werden nun beispielsweise vom Wurzeltemplate
eba::templates::EJBRoot::Root (siehe Listing 6.6) genutzt. Wie aus dem Tem-
plate ersichtlich wird EBATop wie eine Metaklasse behandelt, auf die das Templa-
te mit Namen Root angewandt wird. Innerhalb des DEFINE-Blocks werden die

6 Fallbeispiel 91
Methoden von EBATop aufgerufen und auf die zurückgegebenen Modellelemente
weiterführende Transformationsvorschriften angewandt.
Listing 6.6: Ausschnitt aus dem Template EJBRoot::Root
≪IMPORT eba :: templates :: data≫
...
≪DEFINE Root FOR eba :: meta :: EBATop≫
≪EXPAND DOJavaBean :: Root FOREACH EBADataObject≫
≪EXPAND EOEntityBean :: Root FOREACH EBAEntityObject≫
...
≪ENDDEFINE≫
6.6.2 Trennung von generiertem und nicht generiertem Code
Ein wichtiger Aspekt bei der Codegenerierung ist die Trennung von generiertem
und nicht generiertem Code. In den allermeisten Fällen kann nicht der gesamte
Quellcode einer Software automatisch erzeugt werden. Das heißt, ein Entwickler
muss händisch Ergänzungen vornehmen. Da bei einem Generierungsdurchlauf
alle Artefakte eines früheren Durchlaufs überschrieben bzw. gelöscht werden, ist
es nötig händisch entwickelte Artefakte an einem anderen Ort zu speichern oder
zumindest zu schützen. Dazu kann man entweder Erweiterungsmöglichkeiten der
verwendeten Technologie oder das Konzept der Protected Regions nutzen. Beide
Vorgangsweisen werden im Folgenden besprochen.
Trennung durch Erweiterungstechniken
Automatisch erzeugter Code kann mit händisch entwickeltem verknüpft werden,
indem Erweiterungsmöglichkeiten, die die Technologie selbst bietet, genutzt
werden. Das kann beispielsweise die Generierung einer abstrakten Basisklasse
sein, die ein Entwickler ableitet und um individuellen Code ergänzt. Skriptspra-
chen zum Beispiel bieten in vielen Fällen die Möglichkeit andere Skripte mittels
Include-Befehlen einzubinden.
Im Rahmen des Fallbeispiels wird für jede Javaklasse, die erweitert werden muss,
eine abstrakte Basisklasse generiert. Diese wird anschließend händisch um nöti-
ge Logik ergänzt. Beispielsweise besteht bei den generierten Struts FormBeans
die Möglichkeit Validierungsregeln händisch in einer konkreten Ableitung zu
ergänzen, da die nötige Information nicht im Modell vorhanden ist.

6 Fallbeispiel 92
Bei Java Server Pages erfolgt eine Trennung des Codes mit Hilfe der Struts Ti-
les Template Engine, die eine Aufgliederung einer JSP-Seite in mehrere Dateien
ermöglicht. So wird zum Beispiel der Inhalt einer HTML-Form automatisch aus
den Informationen eines Presentation Elements erstellt. Das Form-Tag mit der
Pfadangabe muss vom Entwickler händisch in einer weiteren JSP Datei, die den
generierten Inhalt einbettet, ergänzt werden.
Geschützte Bereiche
Bietet die Technologie selbst keine Möglichkeit der Erweiterung bestehenden
Codes an, können in den Templates so genannte Protected Regions definiert
werden. Diese erlauben die Integration von manuell erstelltem Code in gene-
riertem. Diese Vorgangsweise hat allerdings einige Nachteile und sollte nur als
letzte Möglichkeit in Betracht gezogen werden. Zum einen erhöhen Protected
Regions den Versionierungsaufwand, da nun auch generierter Code versioniert
werden muss, weil er individuelle Codeteile enthält. Ohne deren Einsatz ist es
nur erforderlich den Generator und die Modelle zu versionieren, der generierte
Quellcode kann aus diesen Artefakten per Knopfdruck erzeugt werden. Speziell
bei der Arbeit in größeren Teams dürfte es hier zu Problemen kommen.
Zum anderen bleiben Protected Regions nur erhalten so lange das Modellelement
existiert, zu dem der Bereich gehört. Sollte auf Grund eines Modellier- oder
Programmierfehlers bei der Generatorentwicklung das Modellelement verloren
gehen oder im Generierungsvorgang nicht bearbeitet werden, wird auch die Proc-
ted Region entfernt. Aus diesem Grund ist Quellcode innerhalb von Protected
Regions potentiell gefährdet.
Im Fallbeispiel werden Protected Regions nur für die Erweiterung von JBoss
Konufigurationsdateien benutzt. Listing 6.7 zeigt ein Beispiel für die Integration
von EJB-Query Language Code für EJB-find-Methoden, sowie ein Beispiel, das
mit Hilfe der Anweisung generiert wurde.
Listing 6.7: Beispiel für eine Protected Region
≪PROTECT CSTART " "
ID nameWithoutSuffix + "_"+ find .NameS≫
≪ENDPROTECT≫
wird bspw . zu

SELECT
OBJECT (c) FROM Buch AS c
WHERE
6 Fallbeispiel 93
c. kategorie . bezeichnung = ?1 ORDER BY c. titel
6.7 Ablaufsteuerung - Workflow
Der Generierungsvorgang wird im oAW Toolkit, wie in Abschnitt 5.4 erwähnt,
mit Hilfe so genannter Workflowskripts gesteuert. Ein Workflow setzt sich dabei
aus beliebig vielen WorkflowComponents zusammen. Solche Bestandteile sind
üblicherweise Model Parser, Validatoren, Modelltransformatoren und Code-
generatoren. oAW4 enthält bereits alle für einen Generierungsablauf nötigen
Komponenten. Diese Komponenten müssen vom Entwickler nur noch in der
richtigen Reihenfolge mit den jeweils passenden Parametern aufgerufen werden.
Wie das geht, wird in diesem Abschnitt anhand des Workflowsskripts zur
Generierung der Enterprise JavaBeans und JavaBeans gezeigt.
Um nicht bei jedem Durchlauf den Sourcecode des gesamten Projekts neu zu
generieren, ist die Ablaufsteuerung der Generierung für das Fallbeispiel auf
zwei Workflowskripte, die im Generatorprojekt liegen, aufgeteilt. Skript eins,
eba-ejb-workflow.oaw, das an dieser Stelle als Beispiel herangezogen wird, steu-
ert die Generierung der Artefakte der Geschäftslogik- und Datenschicht. Skript
zwei - eba-web-workflow.oaw - steuert die Generierung der Präsentationsschicht
(Webclient). Die Parametrisierung der Skripte erfolgt in separaten Workflowdefi-
nitionen, die in den jeweiligen Anwendungsprojekten liegen. Listing 6.8 zeigt ein
Beispiel dafür.
6.7.1 Einbindung anderer Workflows
Um die in Workflowskripten enthaltene Funktionalität wieder zu verwenden, ist
es möglich aus einem Skript heraus ein anderes aufzurufen. Diese inkludierten
Skripts werden auch als Cartridges bezeichnet. Das Beispiel in Listing 6.8 zeigt
die Syntax des Aufrufs.
Listing 6.8: Einbinden eines anderen Workflows
< cartridge file =" eba /eba -ejb - workflow . oaw ">
< projectroot value ="../ eba - BuecherwurmEJB "/ >

genroot value ="../ eba - Generator "/ >
< dumpfile value =
6 Fallbeispiel 94
"../ eba - BuecherwurmEJB / buecherwurm . dump "/ >
< appProjectName value =" eba - BuecherwurmEJB "/ >
6.7.2 Die Komponente als Grundbaustein der
Workflowdefinition
In der Einleitung wurde erwähnt, dass sich eine Workflowdefinition aus
einer beliebigen Anzahl von Workflowcomponent-Aufrufen zusammen-
setzt. Eine WorkflowComponent ist eine Javaklasse, die das Interface
org.openarchitectureware.workflow.WorkflowComponent implementiert.
Listing 6.9 zeigt ein Beispiel bei dem ein Instantiator zum Parsen und Insta-
nizieren eines Modells aufgerufen wird. Neben diversen Parametern wird der
Komponente auch ein so genannter Slot übergeben. Slots ermöglichen es Work-
flowComponents untereinander zu kommunizieren. Um Daten auszutauschen
einigen sich zwei Komponenten auf einen Slot, identifiziert durch den gleichen
Namen. Die erste Komponente kann nun etwas in diesen Einschub hineinstellen
und die zweite Komponente kann es anschließend entnehmen.
Listing 6.9: Aufruf einer WorkflowComponent
< component class =" org . openarchitectureware . core .
frontends . xmi . workflow . XMIInstantiator ">
< instantiatorEnvironmentSlot value =" ie "/ >
< modelFile value ="${ projectroot }/${ model . xmi }"/ >
< xmlMapFile value ="${ genroot }/${ xmlMapFile }"/ >
< metaMapFile value ="${ genroot }/${ metaMapFile }"/ >
< toolAdapterClassname value ="${ toolAdapterClassname }"/ >
Slots sind neben Komponenten eines der zentralen Konstrukte von Work-
flowdefinitionen. Zwei im Rahmen der klassischen Vorgangsweise zwingend
zu definierende Slots sind instantiatorEnvironmentSlot und metaEnvironment-
Slot. Beide müssen vor anderen Arbeitsschritten wie Modellinstanzierung, -
validierung und Codegenerierung, der von Seiten des oAW Frameworks zur
Verfügung gestellten Cartridge classicstart.oaw, bekannt gegeben werden
(siehe Listing 6.10). Diese Cartridge erstellt die grundlegenden Strukturen,

6 Fallbeispiel 95
um die Informationen aus den Modellen im Speicher abzulegen. Mit dem Be-
fehl wird dabei ein Objekt vom Typ
MetaEnvironment angelegt, dass in der Workflowdefinition mittels dem Schlüssel
me angesprochen werden kann. Dieses Objekt stellt die Metaumgebung dar, die
alle Elemente aus den Modellen enthält und in den Templatedefinitionen ” durch-
forstet“ wird. erstellt ein Ob-
jekt der Klasse ClassicOAWInstantiatorEnvironment, das den Instantiators die
Möglichkeit bietet die gewonnen Informationen zur Weiterverarbeitung durch an-
dere Komponenten abzulegen.
Listing 6.10: Aufruf der Cartridge classicstart
< cartridge file =" org / openarchitectureware / workflow /
oawclassic / classicstart . oaw ">
< log4jConfigFile value ="${ genroot }/${ log4jConfigFile }"/ >
< metaEnvironmentSlot value =" me "/ >
< instantiatorEnvironmentSlot value =" ie "/ >
6.7.3 Generatoraufruf
Wie in Abschnitt 6.6 beschrieben benötigen Xpand-Templates zur Codege-
nerierung einen Einstiegspunkt in das instanzierte Modell. Diesen Einstiegs-
punkt liefern die Methoden des CustomModelElements eba.meta.EBATop,
die von den Root-Templates aufgerufen werden. Die WorkflowComponent
eba.plugin.TopBuilder stellt einen Wrapper für EBATop dar, um es in eine
Workflowdefinition integrieren zu können.
In Listing 6.11 wird zuerst die Komponente topbuilder konfiguriert und ein
Slot namens model bekannt gegeben, über den auf eine Instanz der Klas-
se eba.meta.EBATop in der Workflowdefintion zugegriffen werden kann. Auf
diesen Slot wird im Zuge der Generatorkonfiguration mit dem Komman-
do verwie-
sen. Dieses Kommando gibt gleichzeitig die Wurzel des Templatebaums an, bei
der die Codegnerierung gestartet werden soll.
In den Anweisungen zuvor wird das zu Grunde liegende Metamodell definiert. Es
ist dabei anzugeben, um welchen Typ es sich handelt und welche Verarbeitungs-
strategie anzuwenden ist. Im Fallbeispiel handelt es sich um ein Java Metamodell,
das auf ” klassische Art und Weise“ (siehe Abschnitt 5.1) verarbeitet werden soll.
Abschließend werden Ausgabeverzeichnisse und Beautifier zur Formatierung des

Codes definiert.
6 Fallbeispiel 96
Listing 6.11: Aufruf der Generatorkomponente
< component id =" topbuilder " class =" eba . plugin . TopBuilder ">
< metaEnvironmentSlot value =" me "/ >
< modelSlot value =" model "/ >
< component id =" generator "
class =" org . openarchitectureware . xpand2 . Generator ">
< fileEncoding value =" ISO -8859 -1"/ >
< metaModel class =
" org . openarchitectureware . type . impl . java . JavaMetaModel ">
< typeStrategy class =
" org . openarchitectureware . type . impl . oawclassic .
OAWClassicStrategy "
convertPropertiesToLowerCase =" false "/ >
< expand value =" eba :: templates :: EJBRoot :: Root FOR model "/ >
< genPath value ="${ srcGenPath }"/ >
< srcPath value ="${ srcGenPath }"/ >
< prSrcPathes value ="${ srcGenPath }/ resources "/ >
< beautifier class =
" org . openarchitectureware . xpand2 . output . JavaBeautifier "/ >
< beautifier class =
" org . openarchitectureware . xpand2 . output . XmlBeautifier "/ >
Für weitere Beispiele wird auf den beiliegenden Sourcecode zum Fallbeispiel und
auf [EV06] verwiesen.
6.8 Erweiterungsmöglichkeiten
Im Laufe der Arbeiten zum Fallbeispiel und während der Dokumentationsphase
kristallisierten sich diverse Bereiche heraus, die entweder im Rahmen dieser Ar-
beit nicht adressiert werden konnten oder Potential zur Weiterentwicklung auf-
wiesen. Einige dieser Punkte werden in diesem Abschnitt vorgestellt und sollen

6 Fallbeispiel 97
Abbildung 6.13: Metamodell mit erweiterter Semantik
Erweiterungsmöglichkeiten und Anknüpfungspunkte an die Thematik aufzeigen.
6.8.1 Metamodell
Der Entwurf eines aussagekräftigen Metamodells ist mit Sicherheit eine der
schwierigsten Herausforderungen bei der Entwicklung eines oAW-Generators.
Aus genanntem Grund bietet dieser Bereich auch ein großes Veränderungspoten-
tial.
Das in Abschnitt 6.5.1 behandelte Metamodell besitzt eine sehr einfache Struk-
tur. Es definiert eine Reihe von Stereotypen, die untereinander bis auf extensions-
Beziehungen nicht in Verbindung stehen. Wesentliche Teile der Semantik werden
in den Constraints zum Ausdruck gebracht.
In der Nachberarbeitungs- und Dokumentationsphase des Fallbeispiels entstand
eine weiterentwickelte Variante des Metamodells, bei der ein Großteil dieser Se-
mantik aus den Validierungsregeln bereits im Modell zum Ausdruck kommt. Diese
Variante wird in Abbildung 6.13 dargestellt.
Bei der Weiterentwicklung des Metamodells wäre es sinnvoll die Datenhal-
tungsschicht um eine Persistenzlogik zu erweitern. Das könnte beispielsweise
über die Einführung eines Stereotyps > analog zu
> realisiert werden. Dieses Stereotyp könnte aus SQL ent-

6 Fallbeispiel 98
lehnte Eigenschaftswerte wie ” notNull“ oder ” unique“ aufweisen.
Der nächste logische Schritt wäre die Aufspaltung des Modells auf mehrere Teilm-
odelle. Sinnvoll wäre es, die Präsentationssicht in einem separaten Modell darzu-
stellen und Geschäftslogik und Datenhaltung gemeinsam zu modellieren. Wie die
Verwendung mehrerer Modelle technisch realisiert wird zeigt [Völ05c] Seite 39ff.
6.8.2 Ablaufsteuerung
openArchitectureWare verfügt über die in der Projektdokumentation zum Verfas-
sungszeitpunkt nicht adressierte Möglichkeit UML-Actitvity-Diagramme zu ver-
arbeiten. Dieser Umstand wird durch das Beispiel in [SV05] Kapitel 3 und das
Vorhandensein des Pakets org.openarchitectureware.meta.uml.activity be-
legt. Diese Funktionalität könnte genutzt werden, um die auf Seiten des Webcli-
ents benötigte Ablaufsteuerung automatisch aus einem Aktivitätsdiagramm her-
aus zu generieren. Die erstellten Artefakte wären Teile der Struts-Konfiguration,
der Rechteverwaltung sowie der in den JSPs enthaltenen HTML-Forms.
6.8.3 Recipes
Um Code, der mit oAW generiert wurde, zu erweitern, ist zum Teil viel Wissen
über dessen Beschaffenheit notwendig. In Version vier des Generatorframeworks
wurde eine neue Technologie eingeführt, die es ermöglicht dem Anwendungsent-
wickler anzuzeigen, wo eine manuelle Ergänzung generierter Artefakte nötig ist.
Dazu muss der Generatorentwickler ein so genanntes Recipe verfassen. Ein Recipe
ist eine Javaklasse die eine Regel implementiert. Überprüft wird dabei beispiels-
weise, ob eine abstrakte Basisklasse abgeleitet wurde oder ob ein bestimmter
Ausdruck in einer Datei vorkommt. Diese Recipes können von einem Eclipse
Plugin geladen und validiert werden. Regelverstöße werden von diesem Plugin,
ähnlich wie es Eclipse mit Problems und Warnings tut, in einem separaten Tab
angezeigt. Für weitere Informationen siehe die oAW Dokumentation zu Recipes
unter [Völ06b].
6.9 Vorgangsweise, Herausforderungen und
Codeanalyse
Am Beginn der Arbeiten zum Fallbeispiel stand die Domänenfindung und
die Wahl der zur Umsetzung benötigten bzw. geeigneten Technologien. Hier
stand die Frage im Raum, ob eine technisch oder fachlich motivierte Domäne

6 Fallbeispiel 99
herangezogen wird. Bei fachlichen Domänen bestand die Ungewissheit, ob
oAW diese ausreichend unterstützt, da sämtliche verfügbaren Beispiele in einer
technischen Domäne angesiedelt sind. Darüber hinaus unterstützte oAW mit der
zum damaligen Zeitpunkt aktuellen Version (Version drei) hauptsächlich UML
Modelle, die für die Darstellung fachlicher Aspekte nur wenig geeignet sind. (Die
Unterstützung von EMF-Modellen wurde erst in Version vier realisiert.)
Markus Völter, ein Mitwirkender am oAW Projekt, hält in Bezug auf die
Behandlung von fachlichen Domänen in einem im April erschienen Interview
(siehe [Net06]) fest, dass fachliche Domänen durchaus realisierbar sind. Zu
Beginn sei es aber einfacher technologisch motivierten Code zu generieren,
da hier ein hohes Automatisierungspotential bestehe und dieser Bereich den
Entwicklern vertraut sei.
Auf Grund der Unsicherheiten in Bezug auf die Natur der Domäne, der Leis-
tungsfähigkeit von oAW und der Beschaffenheit einzusetzender Technologien fiel
die Entscheidung auf Basis des in [SV05] Kapitel drei vorgestellten Beispiels, das
vorliegende Fallbeispiel zu konstruieren und eine technische Domäne umzusetzen.
Nach der Domänenfindung wurde ein Technologieprotoyp der Onlinebuchhand-
lung ” Bücherwurm“ angefertigt. Auf diese Weise war es möglich, die Techniken
zu erlernen und architektonische Konzepte auf ihre Tauglichkeit zu überprüfen.
So fand beispielsweise das in Abschnitt 6.4.2 beschriebene Konzept der Session
Facades erst später Einzug in die Architektur, nachdem sich ein direkter Zugriff
auf die Entity Beans als unzulänglich herausgestellt hatte. Im Anschluss an
die Prototypisierung fanden erste Gehversuche mit oAW Version drei statt.
Experimentiert wurde mit der Erzeugung der sehr einfach strukturierten Data
Transfer Objects(siehe 6.4.2).
Diese Einarbeitungsphase war sicher eine der schwierigsten bei der Arbeit mit
oAW, da zu diesem Zeitpunkt nur eine unzureichende Dokumentation existierte
und das Diskussionsforum auf der damaligen Projektseite nur wenig frequentiert
war. Zum Teil musste der Sourcecode zum oAW-Toolkit selbst als Informations-
quelle genutzt werden. Außerdem war ein hohes Maß an Wissen und Verständnis
für die internen Zusammenhänge notwendig, um die Software nutzen zu können.
Zeitgleich mit Beginn der Arbeiten an der Referenzimplementierung für die
Domänenarchitektur erschien Ende Jänner 2006 Release Candidate 1 von oAW
Version vier. Diese Version brachte zahlreiche Neuerungen mit sich, wie eine
verbesserte Integration in Eclipse, neue Sprachen, eine Erweiterung der un-
terstützten Modellpalette, umfangreichere Dokumentation, zusätzliche Tutorials
und eine rege Teilnahme der oAW Entwickler im Forum der Projektseite. Aus

6 Fallbeispiel 100
diesen Gründen fiel die Entscheidung oAW Version vier für die Umsetzung des
Fallbeispiels zu nutzen.
Nach einer Einarbeitungsphase und dem Entwurf der Domänenarchitektur
mussten deren Konzepte in einem Metamodell modelliert werden. Hier stellte
sich die Frage, auf welcher Ebene die Konzepte des Metamodells anzusiedeln
sind. Sollten die Konzepte auf Ebene der technischen Plattform liegen oder
höher angesiedelt werden? Das heißt, sollte das Metamodell die Konzepte von
J2EE und Struts oder Konstrukte wie Session Facades und Data Transfer
Objects abbilden. Variante eins führt zu einer sehr breiten Domäne mit geringem
Generierungspotential. Variante zwei schmälert durch die Einschränkung auf
eine bestimmte Architektur die Domäne, aber erhöht in gleichem Maße das
Potential an generierbarem Code. Den Ratschlägen von [SV05] Seite 137 und
dem Metamodell des Beispiels aus Kapitel drei des selben Buchs folgend wurde
das Metamodell auf einer höheren Ebene angesiedelt und die architektonischen
Konzepte dargestellt.
Im Anschluss an die Phase der Domänenanalyse erfolgte die Modellierung der
Referenzimplementierung mit Hilfe der Konstrukte des Metamodells. Vor der
Entwicklung der Transformationsvorschriften musste dieses Referenzmodell
händisch umgesetzt werden, um eine Vorlage für den zu generierenden Code zu
besitzen. Der Sourcecode des Prototypen war dafür zu uneinheitlich und zu wenig
ausgereift. Aus diesem Grund wurden Teile des Prototypen neu entwickelt und
auf ein Referenzniveau gebracht. Besonders wichtig war es, den Sourcecode der
Instanzen eines Metamodellelements mit den gleichen Schemata zu entwickeln
um ein und dieselben Templates darauf anwenden zu können. Es wurde dabei
nicht die gesamte Referenzimplementierung händisch entwickelt sondern es fand
ein schrittweiser Übergang zur Generierung statt.
Der Ablauf war dabei wie folgt: Zuerst wurden ausgewählte Instanzen eines
Metamodellelements händisch implementiert. Danach wurden aus dem händisch
verfassten Sourcecode die Transformationsvorschriften abgeleitet und versucht
die Instanzen eines Metamodellelements zu generieren. Bei der Auswahl der
händisch zu implementierenden Instanzen war besonders darauf zu achten
ein möglichst breites Spektrum an Variationen zu einem Metamodellelement
abzudecken. So sind zum Beispiel ” KundenverwaltungPO“ (Abbildung 6.8) und
” BuchverwaltungPO“ - zur Verwaltung von Entitäten zum Thema Buch“ -
”
beides Ausprägungen des Stereotyps >, auf Codeebene
bestehen dennoch gewisse Unterschiede.

6 Fallbeispiel 101
Oft wurde nach der Generierung festgestellt, dass gewisse Aspekte eines Meta-
modellelements mit den manuell implementierten Beispielen nicht erfasst wurden
und somit Fehler und Unzulänglichkeiten im erzeugten Code zu finden waren.
In den allermeisten Fällen war es nötig diese fehlenden Aspekte zuerst händisch
zu implementieren, um anschließend wieder Transformationsvorschriften daraus
abzuleiten. Die manuelle Implementierung war notwendig, da eine Templateent-
wicklung ohne Vorlage sehr komplex und fehlerbehaftet war.
Nach der Fertigstellung aller generierbaren Teile wurden die individuellen Code-
teile, wie der Warenkorb, ergänzt.
Die soeben beschriebenen Phasen der Domänenanalyse und Referenzimplemen-
tierung sind nicht starr sondern gehen fließend ineinander über. Oftmals war
während der Arbeiten an der Referenzanwendung eine Änderung bzw. Erweite-
rung des Metamodells notwendig. Es handelt sich also nicht um eine Vorgangswei-
se im Sinne des ” Wasserfallmodells“ sondern sie ist vielmehr iterativ inkrementell.
6.9.1 Herausforderungen bei der Umsetzung
Neben den bereits beschriebenen Unsicherheiten bei der Domänenfindung und
der anfänglichen Unzugänglichkeit von oAW war der Bereich der Modellierung
eine der größten Herausforderungen bei der Umsetzung. Speziell zu Beginn war
es auf Grund mangelnder Erfahrung oft schwierig abzuschätzen inwieweit Me-
tamodell und Modell die Sachverhalte in geeigneter Art und Weise ausdrücken.
Die Eignung zeigte sich jedoch in den allermeisten Fällen sehr bald bei der
Templateentwicklung und der Implementierung von Logik im Metamodell. War
beispielsweise kaum Generierungspotential auszumachen war eine Spezialisierung
eines Stereotyps oft hilfreich.
Zu diesen großen Herausforderungen kamen viele kleine bei der täglichen Arbeit
mit oAW, wie die Extraktion von Information, die über mehrere Modellelemente
verstreut war. Schwierig war es auch die Logik zur Schachtelung der einzelnen
Data Transfer Objects in den Templates zur Generierung der Session facades
abzubilden. Hier musste intensiv mit rekursiver Programmierung gearbeitet wer-
den. Herausfordernd war auch die Navigation durch das instanzierte Modell, da
in manchen Templates Information über den Pfad von Modellelement A zu Mo-
dellelement B benötigt wurde. Hier kamen graphentheoretische Algorithmen zum
Einsatz.

6.9.2 Codeanalyse
6 Fallbeispiel 102
Abschließend wird diskutiert wie das Verhältnis von generierten zu manuell co-
dierten Codeteilen aussieht. Als Maßzahl dient Lines of Code (LOC). Tabelle 6.1 6
stellt die manuell und automatisch erzeugten LOC der einzelnen Komponenten
gegenüber. Es zeigt sich dabei, dass 70,8% des Fallbeispiels automatisch erzeugt
werden können. Dies ist laut [SV05] Seite 32 im üblichen Bereich des bei AC-
MDSD generierbaren Codeanteils von 60-80%.
Besonders hohes Generierungspotential befindet sich auf Seiten des EJB basierten
Backends, bei dem auf Grund der ausgeprägten Strukturierung und des hohen
Schematisierungsgrades 93% des Javacodes und der XML-Konfiguration gene-
riert werden konnte. Bei der Entwicklung des Webfrontends sinkt dieser Faktor
auf 45,2% des Codes. Dieses Absinken ist durch einen hohen individuellen Co-
deanteil und die nicht aus Klassendiagrammen generierbare Ablaufsteuerung zu
erklären.
6 Die Werte wurden mit dem Programm Lines of Code Counter ( [loc06]), das die Zeilenanzahl
innerhalb einer Textdatei minus Leerzeilen und Zeilen mit weniger als drei Zeichen ausgibt,
erstellt. Codeanteil der auf Protected Regions entfällt wurde händisch subtrahiert.

6 Fallbeispiel 103
Herstellung Web-Frontend EJB-Backend Gesamt
JSP Actions und Konfiguration Gesamt EJB Konfiguration Gesamt
FormBeans
Generiert 416 44% 1033 55,6% 0 0% 1449 45,2% 2091 90,4% 1319 97,7% 3410 93% 4859 70,8%
Manuell 528 56% 826 54,4% 400 100% 1754 54,8% 223 9,6% 31 2,3% 254 7% 2008 29,2%
Gesamt 944 1859 400 3203 46,7% 2314 1350 3664 53,3% 6867 100%
Tabelle 6.1: Gegenüberstellung der Anzahl manuell codierter LOC und generierter LOC

7 Evaluierung
Bisher wurden nur die technischen und prozessualen Aspekte von MDSD
betrachtet, wirtschaftliche Belange wurden außer Acht gelassen. Aber gerade
hier sind die Auswirkungen modellgetriebener Softwareentwicklung in Form von
Kostenersparnissen bei qualitativ höherwertiger Software besonders zu spüren.
Um die Methodik zu etablieren sind allerdings einige Anfangsinvestitionen
nötig, die von der Schaffung einer generativen Umgebung, über den Aufbau
einer entsprechenden domänenspezifischen Plattform bis hin zur Schulung der
Mitarbeiter reichen.
Ziel dieses Kapitels ist es das betriebswirtschaftliche Potential des MDSD-
Ansatzes aufzuzeigen, sinnvolle Einsatzgebiete darzustellen und die nötigen In-
vestitionen aufzulisten. Abschließend wird auf derzeit bestehende Probleme auf-
merksam gemacht. Die kritische Betrachtung der Methodik basiert auf folgenden
Quellen: [SV05] Kapitel 17, [Bet06b], [Net06], [PBG04] Kapitel 10 und [CN04].
7.1 Wann ist MDSD sinnvoll?
MDSD zeichnet sich durch eine enge Verwandtschaft mit Software-Produktlinien
aus. In Abschnitt 3.2 wurde bereits auf den Umstand hingewiesen, dass MDSD
zur Realisierung von Software Product Lines genutzt werden kann. Aus dieser
Überlegung folgt, dass beide Methodiken unter ähnlichen Bedingungen sinnvoll
einzusetzen sind.
Software Product Lines haben das Ziel eine Menge von ähnlichen Systemen
umzusetzen. Durch die Planung über mehrere Systeme hinweg wird versucht,
Einsparungspotential gegenüber der Entwicklung singulärer Systeme zu nutzen.
Je ähnlicher die Systeme sind, desto mehr Komponenten lassen sich wiederver-
wenden. Gemeinsame Basis aller Familienmitglieder ist die domänenspezifische
Plattform. Ähnlich verhält es sich bei MDSD, wo die Überlappung von Ei-
genschaften der zu entwickelnden Anwendungen nicht nur in Bezug auf die
Wiederverwendung von Plattformbestandteilen eine Rolle spielt, sondern auch
104
für die Transformationsvorschriften. Es ist nur sinnvoll in diesen Vorschriften

7 Evaluierung 105
Aspekte zu beschreiben, die sich schematisch wiederholen. In allen anderen
Fällen ist eine manuelle Umsetzung effizienter (siehe Abschnitt 2.1).
Aus eben genannten Gründen folgt, dass MDSD besonders in Unternehmen Sinn
macht, die eine Menge gleicher Software-Produkte herstellen. Profitieren können
auch IT-Dienstleister im projektorientierten Bereich, die sich in einer fachspe-
zifischen Domäne spezialisieren, was wiederum zu einer Menge an ähnlichen
Produkten führt. Bezieht man in diese Überlegungen nicht nur die Entwick-
lungskosten sondern auch den anfallenden Wartungsaufwand mit ein, kann sich
MDSD bereits im Rahmen einer Anwendung als Gewinn herausstellen. Ein
Großteil der Wartungsaufgaben kann Zentral in den Transformationsvorschriften
vorgenommen und mit Hilfe des Generators gleichmäßig auf die bestehende
Codebasis übertragen werden.
Als groben Anhaltspunkt, ab welchem Zeitpunkt sich der MDSD-Einsatz in
einem Projekt für die unmittelbar beteiligten Entwickler positiv bemerkbar
machen sollte, gibt Markus Völter in [Net06] den Zeitraum von vier Wochen
nach Einführung der Methodik an.
Zum erfolgreichen Einsatz von MDSD müssen, wie [PBG04] darlegt (siehe Seite
266), mehrere Rahmenbedingungen gegeben sein:
• Die einzelnen Systeme müssen genügend Gemeinsamkeiten ha-
ben.
• Die Anforderungen müssen verhandelbar sein.
• Das Eigentum an den entwickelten Gütern ... darf nicht an den
Kunden übergehen.
Punkt zwei bedarf einer näheren Betrachtung. Sind die Anforderungen an ein
Softwaresystem nicht verhandelbar, ist es möglich, dass die Kundenwünsche nicht
im Rahmen der Domänenarchitektur umzusetzen sind. Das führt zu einem Unikat,
wie es aus der traditionellen Entwicklung bekannt ist. MDSD ist also nur dann
sinnvoll, wenn die Anforderungen der einzelnen Systeme soweit verhandelbar sind,
dass man auf Basis der Gemeinsamkeiten eine Software-Systemfamilie gründen
kann.

7 Evaluierung 106
Abbildung 7.1: Aufwand bei traditioneller Softwareentwicklung (Quelle: [SV05]
Seite 318)
7.2 Vorteile und betriebswirtschaftliche
Auswirkungen
7.2.1 Automation und Wiederverwendung
Ein wesentliches Merkmal modellgetriebener Softwareentwicklung ist die automa-
tisierte Erstellung von sich schematisch wiederholendem Code durch einen Gene-
rator, in Verbindung mit der Wiederverwendung von Komponenten auf Basis ei-
ner domänenspezifischen Plattform. Diese Techniken verkürzen die Entwicklungs-
zeit neuer Produkte und folglich auch die so genannte Time-To-Market Phase,
also jene Zeit die von der Idee bis zum Markteintritt vergeht, was zu entschei-
denden Wettbewerbsvorteilen führen kann 1 . Zudem ist der Zeit- und Personalbe-
darf pro Projekt geringer, als bei einer traditionellen rein manuellen Entwicklung.
Das führt zu kostengünstigeren Produkten, da die Arbeitszeit den entscheidenden
Kostenfaktor bei der Softwareentwicklung darstellt.
Reduziert man den Prozess der Softwareentwicklung auf die beiden Faktoren ” In-
formationsgewinnung über die Domäne“ und ” Detaillierungsgrad der Implemen-
tierung“ führt der Weg zum fertigen Produkt über Analysemodell, Design bis hin
1 Im Hochtechnologiesektor wird durch einen frühen Markteintritt der Umstand genutzt, dass
die Gruppe der Early Adopters bereit ist, sehr hohe Preise für ein Produkt zu bezahlen.

7 Evaluierung 107
Abbildung 7.2: Aufwand bei modellgetriebener Softwareentwicklung mit teilweise
manueller Kodierung (Quelle [SV05] Seite 319)
zur fertigen Anwendung. Dabei zeigt sich, dass zu Beginn der Informationsgehalt
überproportional zum Detaillierungsgrad steigt. Je weiter die Implementierung
voranschreitet desto mehr kehrt sich dieses Verhältnis um.
Stahl und Völter führen hier als Vergleich die Skizze eines GUIs mit der fertigen
Ausarbeitung in Form einer JSP Seite an ( [SV05]). Beide Artefakte enthalten
denselben Informationsgehalt, der Unterschied liegt im Detaillierungsgrad. Aus
der Sicht der enthaltenen Information ist die Ausarbeitung somit eine reine Fleiß-
aufgabe, um sie in eine computergestützte Form zu bringen. Diese ” Fleißarbeit“
übernimmt bei MDSD ein Generator. Abbildung 7.1 und 7.2 verdeutlichen das
Einsparungspotential durch den beschriebenen Sachverhalt.
Neben der automatisierten Codeerstellung ist die Wiederverwendung der zweite
Motor zur Kostensenkung, da einmal entwickelte Artefakte in mehreren Anwen-
dungen genutzt werden. Die Entwicklungskosten für eine Komponente verteilen
sich somit auf mehrere Projekte.
7.2.2 Sicherstellung von Anwendungsqualität
MDSD bewirkt eine Steigerung der Anwendungsqualität durch mehrere
Umstände. Erstens verfügen Anwendungen, die mit Hilfe von MDSD entwickelt
wurden, zwingend über eine wohldefinierte Architektur. Sie ist eine Vorausset-

7 Evaluierung 108
zung für die spätere Codegenerierung. Bei der Codegenierung wird ein Regelsatz
auf Modellelemente angewandt, um daraus den Quellcode einer Anwendung zu
erstellen. Es ist also unumgänglich diese Regeln vorab zu definieren und sich da-
durch sehr genau mit der Architektur der Anwendung auseinander zu setzen.
Zweitens ist die Architektur durch die automatisierte Umsetzung gleichförmig
mit ein und derselben Qualität in der gesamten Anwendung wiederzufinden. Sie
schwankt also nicht mit den Fähigkeiten eines einzelnen Entwicklers. Das heißt,
MDSD unterstützt die Bündelung von fachlichem und technischem Wissen in den
Bestandteilen der Domänenarchitektur. Technische Experten bilden ihr Wissen
in den Transformationen und der Plattform ab. Fachliche Experten halten die
Geschäftslogik in den (hoffentlich) weitestgehend technologieunabhängigen Mo-
dellen fest.
Drittens müssen Plattform und Transformationsvorschriften ihre Funktionalität
in mehreren Produkten unter Beweis stellen. Diese umfangreiche Qualitätssiche-
rung erhöht die Chance einen Fehler zu finden signifikant. Wird ein Fehler ent-
deckt und behoben, steigert das die Qualität aller auf dem jeweiligen Artefakt
aufbauenden Anwendungen.
7.2.3 Technologiewechsel
Bei einer modellgetriebenen Entwicklung, wie sie im Rahmen dieser Arbeit vorge-
stellt wird, besteht eine klare Trennung von Infrastruktur und fachlichem Code,
was einen Technologiewandel erleichtert. Sind die Anwendungsmodelle techno-
logieunabhängig gehalten, beschränken sich die nötigen Änderungen auf Trans-
formationen und Plattform. Somit müssen Anbindungen an neue Technologien
nur einmal zentral implementiert werden und können anschließend mit Hilfe des
Generators auf bestehende Anwendungen umgelegt werden. Das heißt, MDSD
unterstützt die Bestrebung den Anwendungslebenszyklus vom Technologielebens-
zyklus zu entkoppeln.
7.2.4 Auswirkungen auf den Einzelnen
Bisher wurden nur die Auswirkungen von MDSD auf eine Organisation im Gan-
zen betrachtet. Clements und Northrop haben bei ihren Untersuchungen von
Software Product Lines zahlreiche Interviews mit Entwicklern durchgeführt um
herauszufinden wie sich die Methodik auf deren tägliche Arbeit auswirkt. Einige
der in [CN04] gelisteten Punkte (siehe Seite 21) lassen sich auf MDSD übertragen
und werden hier frei wiedergegeben.
• Anstatt den größten Teil der Entwicklungszeit mit grundlegenden Arbeiten

7 Evaluierung 109
zu verbringen, ist es den Entwicklern möglich sich auf die individuellen
Aspekte einer Anwendung zu konzentrieren.
• Die in vielen Projekten mühevolle Anfangsphase entfällt, da man auf einer
erprobten Architektur aufbaut.
• Innerhalb eines Unternehmens besteht ein größerer Einsatzbereich, da das
Wissen des Einzelnen eine globalere Gültigkeit besitzt.
• Es bleibt mehr Zeit sich mit neuen Technologien auseinander zu setzen.
7.3 Nötige Investitionen
Um die Vorteile einer MDSD-Entwicklung nutzen zu können sind vorab eini-
ge Investitionen nötig. Erstens müssen die organisatorischen Strukturen auf ei-
ne modellgetriebene Softwareentwicklung abgestimmt werden. Zweitens muss ei-
ne entsprechende Domänenarchitektur bestehend aus DSL, Transformationsvor-
schriften und Plattform aufgebaut werden und drittens muss die eigentliche An-
wendung mittels der Artefakte der Domänenarchitektur, ergänzt um individuelle
Komponenten, erstellt werden.
Zu beachten ist, dass die im Folgenden beschriebenen Kosten nicht wasserfallar-
tig nacheinander anfallen sondern sich entsprechend der iterativ inkrementellen
Vorgangsweise über den gesamten Entwicklungszyklus verteilen.
7.3.1 Organisatorische Kosten
Organisatorische Kosten sind alle jene die anfallen, um den Softwareentwicklungs-
prozess einer Organisation (unabhängig von deren Größe) an den MDSD-Ansatz
anzupassen. Darunter fallen Punkte wie Training der Mitarbeiter, Einführung agi-
ler Methodiken, Etablierung eines iterativ inkrementellen Vorgehens bei der Pro-
jektabwicklung, Einschulung in die benötigten Tools etc.. Diese Kosten sind stark
vom aktuellen Organisationszustand sowie dem Wissensstand und den Fähigkei-
ten der Mitarbeiter abhängig.
7.3.2 Kosten für die Entwicklung einer Domänenarchitektur
Eine Domänenarchitektur setzt sich aus einer Plattform, einer DSL und den da-
zu passenden Transformationen zusammen. All diese Dinge müssen zum Teil vor
bzw. während der Entwicklung darauf aufbauender Anwendungen entworfen wer-
den. Besonders zu berücksichtigen ist der Umstand, dass diese Artefakte nicht für

7 Evaluierung 110
eine einzelne Anwendung sondern für viele entwickelt werden, das bringt zusätz-
liche Komplexität sowohl bei der Abstimmung als auch beim Design mit sich. Es
darf darüber hinaus nicht außer Acht gelassen werden, dass auch die Artefakte
der Domänenarchitektur einer fortlaufenden Pflege und Wartung bedürfen, was
zu entsprechenden Kosten führt.
Im Folgenden wird eine Auswahl an Punkten gegeben, die im Vergleich zur Ent-
wicklung singulärer Systeme zu erhöhten Aufwendungen führen:
• Domänenanalyse/DSL: Die Anforderungen werden für eine Gruppe von
Systemen festgelegt. Anforderungen einzelner Systeme stellen entweder ei-
ne Abweichung oder Weiterentwicklung dar. Die Schwierigkeit liegt hier in
der Erhebung der Gemeinsamkeiten und der Findung geeigneter Variations-
punkte. Voraussetzung ist in jedem Falle eine detaillierte Domänenanalyse
und möglicherweise sind intensive Besprechungen zur Abstimmung nötig.
Die Ergebnisse der Anforderungsanalyse haben letztendlich auch eine direk-
te Auswirkung auf die DSL, da sie die zu bearbeitende Domäne beschreiben.
In Folgeprojekten kann der Aufwand für die Anforderungsanalyse durch die
Wiederverwendung und Anpassung bestehender Anforderungsanalysen ge-
senkt werden.
Mit Hilfe der in der Anforderungsanalyse gewonnenen Ergebnisse wird eine
DSL, und hier insbesondere ein Metamodell, zur Beschreibung der Konzepte
einer Domäne entworfen. Diese Tätigkeit ist eine der Forderndsten im Zu-
sammenhang mit MDSD und wird speziell zu Beginn bei noch mangelnder
Erfahrung einiges an Aufwand benötigen.
• Architektur/Design: Eine Softwarearchitektur muss im Zusammenhang
mit MDSD nicht nur einer einzigen Anwendung genügen, sondern zusätzlich
in der Lage sein eine Reihe ähnlicher Applikationen zu tragen. Sie bildet
also nicht nur die Gemeinsamkeiten ab, sondern muss auch die Unterschiede
zwischen den Anwendungen ermöglichen. Das ist eine zusätzliche Anforde-
rung, die ein mitunter großes Geschick beim Design erfordert. Ein großer
Vorteil ist der Umstand, dass der wichtigste Designschritt für die aufbau-
enden Anwendungsentwicklungen bereits durchgeführt, und die Ergebnisse
anhand einer Referenzimplementierung validiert werden konnten. Die Ab-
leitung der Transformationen aus der Referenzimplementierung wird in der
Literatur auf 25% des Aufwands für die manuelle Codierung der Referenz-
implementierung geschätzt (siehe [Net06], [SV05] und [Bet06a]).
• Plattformkomponenten: Die Plattformkomponenten bilden das Funda-
ment sowohl für den generierten als auch manuell entwickelten Quellco-

7 Evaluierung 111
de. Sie werden bei der Entwicklung der einzelnen Mitglieder der Software-
Systemfamilie laufend wiederverwendet. Daraus ergibt sich eine höhere An-
forderung hinsichtlich Qualität und Design dieser Komponenten. Sie müssen
sowohl robust als auch erweiterbar sein, so dass eine Erweiterung bzw. der
Einsatz in mehreren Applikationen möglich ist. In vielen Fällen sind diese
Komponenten generell designt, dürfen gleichzeitig aber keine Einbußen bzgl.
der Performance bewirken. Dadurch sind wiederverwendbare Komponenten
in der Herstellung im Vergleich zu Unikaten auch teurer.
7.3.3 Kosten der Anwendungsentwicklung
Die Kosten für die eigentliche Anwendungsentwicklung fallen bei MDSD durch
die Nutzung von Artefakten der Domänenarchitektur wesentlich geringer aus als
bei einer traditionellen Vorgangsweise. Sie werden im wesentlichen durch die Er-
stellung individueller Anwendungsteile, sowie der Anwendungsmodellierung ver-
ursacht. Hinzu kommen Aufwendungen die durch die Abstimmung mit dem Ar-
chitekturentwicklungsteam entstehen (siehe Entwicklungsprozess Kapitel 4).
7.4 Mögliche Hindernisse für eine Verbreitung
Modellgetriebene Ansätze, wie MDA oder MDSD, die sich in manchen Details
stark von einer traditionellen Softwareentwicklung unterscheiden, werden von
der in Bezug auf neue Methodiken eher konservativ eingestellten Softwareent-
wicklergemeinde mit einer gewissen Skepsis betrachtet. Diese Skepsis liegt in den
nicht haltbaren Heilsversprechungen früherer Ansätze, wie beispielsweise den
so genannten CASE-Tools begründet. Auch der intensiven Wiederverwendung
bestehender Artefakte über mehrere Projekte hinweg stehen Softwareentwickler
oft kritisch gegenüber, da sie zum ” Not invented Here!“-Syndrom neigen.
Zu dieser skeptischen Grundhaltung kommt zum Teil fehlendes Know-how
hinzu. MDSD erfordert fortgeschrittene Kenntnisse im Bereich der Modellierung,
um zum Beispiel eine DSL zu entwerfen bzw. diese entsprechend einsetzen zu
können. In Modellen zu denken ist derzeit nicht etabliert. Außerdem werden
hohe Anforderungen an die Rolle des Softwarearchitekten gestellt.
Neben diesen Punkten haben die verfügbaren Tools zur Realisierung der Metho-
dik noch einige Kinderkrankheiten. Die Entwicklung ist hier sicherlich noch nicht
abgeschlossen. Diese Situation bessert sich aber immer mehr wie die Fallstudie
in Kapitel 6 zeigt. So stellt beispielsweise die Uneinheitlichkeit der erzeugten

7 Evaluierung 112
XMI-Ausgaben der UML-Modellierungstools und deren Anbindung an einen
Generator nach wie vor ein Problem dar. Des Weiteren ist der Entwurf eines
Editors zu einer DSL ein mühsamer Prozess, der mittlerweile durch das Eclipse
GMF Projekt ( [gmf06]) erleichtert wird (vgl. [Net06]).
Ein Umstand der in Bezug auf Tools nicht außer Acht gelassen werden darf, ist
der zum Teil signifikante Aufwand zum Erlernen. MDSD-Tools wie openArchi-
tectureWare sind sehr mächtig und haben einen breiten Funktionsumfang, was
allerdings auch einen entsprechenden Zeitaufwand für das Erlernen zur Folge
hat. Zahlreiche Userkommentare im Diskussionsforum von oAW belegen diesen
Umstand.
Abschließend sind auch die nötigen organisatorischen Umstrukturierungen als
Hindernis anzuführen. Sowohl der etablierte Softwareentwicklungsprozess als auch
die existierenden Teamstrukturen müssen an MDSD angepasst werden, was in
bestehenden Organisationen durchaus auf Widerstand stoßen kann.

8 Zusammenfassung und Ausblick
Der in dieser Arbeit vorgestellte Model Driven Software Development-Ansatz
verspricht eine pragmatische Möglichkeit um den Entwicklungsprozess von
Softwaresystemen hinsichtlich Wiederverwendbarkeit, Steigerung der Entwick-
lungsgeschwindigkeit und erzielter Qualität zu verbessern. Dabei wird, wie
der Vergleich mit verwandten Ansätzen zeigt, nicht versucht ” das Rad neu zu
erfinden“ sondern auf bestehende Ansätze zurückgegriffen. MDA liefert MDSD
die Nomenklatur und Impulse für die Modellierung. Software Product Line En-
gineering steuert zum einen Methodiken beispielsweise für die Analysephase und
zum andern das Konzept der Plattform, die ein wieder verwendbares Fundament
bildet, bei. Der Entwicklungsprozess selbst wird stark von den Ideen des Agile
Software Development beeinflusst.
Die hier vorgestellten Ideen zu modellgetriebener Softwareentwicklung sind
geprägt davon, die angestrebten Ziele durch eine Vielzahl kleiner Schritte zu
erreichen. Auf große Revolutionen, die mit heute verfügbaren Standards und
Technologien nur schwer oder noch gar nicht umgesetzt werden können, wird
bewusst verzichtet (siehe Probleme bei der Umsetzung von echter Portabilität
im Rahmen von MDA).
Ein Beispiel für die Strategie der ” kleinen Schritte“ ist der bevorzugte Einstieg
in MDSD über die architekturzentrierte Ausprägung, bei der nur technische
Artefakte erzeugt werden. Eine technische Domäne hat den Vorteil, dass sie
den Entwicklern vertraut ist, und ihre tägliche Arbeit erleichtert. Die positiven
Auswirkungen sind hier am schnellsten zu spüren. Später kann schrittweise
der Übergang zu einer fachlichen Domäne erfolgen, womit auch der Umfang
des automatisch erzeugten bzw. wieder verwendeten Codes mehr und mehr steigt.
Neben diesem Pragmatismus sind die hier vorgestellten Ansätze im Gegensatz
beispielsweise zu MDA unabhängig von den Standardisierungsarbeiten eines
Gremiums. Zudem wird eine Unterstützung durch Open Source Programme
angestrebt und die Anwendung der Methodik ist vollkommen individualisier-
113
bar. Das untersuchte Tool openArchitectureWare liefert zum Beispiel keinerlei

8 Zusammenfassung und Ausblick 114
vordefinierte Domain Specific Languages oder domänenspezifische Plattformen
mit. Diese Artefakte müssen vom Anwender selbst geschaffen werden. Das
erschwert zwar einerseits den Einstieg, erlaubt andererseits aber den Einsatz der
Methodik unabhängig von äußeren Einflüssen. Darüber hinaus kommt man nicht
in die Situation gegen das Tool arbeiten zu müssen um eigene Vorstellungen
zu realisieren. Die Strategie der ” kleinen Schritte“ und die Unabhängigkeit von
einem Industriekonsortium ermöglicht es mit Hilfe von MDSD Zielen, die von
Softwareentwicklern seit jeher verfolgt wurden, wie eine effizientere Entwicklung
bei höherer Qualität, schon jetzt ein Stückchen näher zu kommen. Der Anspruch
mit MDSD die ultimative Lösung zu besitzen wird nicht erhoben.
Das in Kapitel 6 mit Hilfe des Open Source Tool openArchitectureWare
durchgeführte Fallbeispiel zeigt, dass auf Seiten der Werkzeuge ausreichend Un-
terstützung besteht, um eine MDSD basierte Entwicklung umzusetzen. Es gibt
sowohl Möglichkeiten Modellvalidierungen vorzunehmen, Transformationsvor-
schriften festzulegen, als auch bei der Generierung benötigte Logik umzusetzen.
Zu dem wird keine Beschränkung hinsichtlich der Modellierungssprache vorge-
nommen. Die gängigsten sind UML, EMF und XML.
Vor dem Einsatz von oAW muss allerdings ein beträchtlicher Lernaufwand in
Kauf genommen werden, da die Dokumentation zwar ständig wächst, aber in
Bezug auf die Mächtigkeit des Tools immer noch lückenhaft ist. Anzumerken ist,
dass diese Situation durch ein, auch von Seiten der Entwickler frequentiertes,
Diskussionsforum gemildert wird. Ein weiteres Problem bei der Arbeit mit
oAW stellt die Anbindung von externen UML-Modellierungstools dar. Durch
die Uneinheitlichkeit der diversen XMI-Dialekte kann es beim Importieren von
Modellen in oAW immer wieder zu Problemen kommen.
Abschließend ist zu bemerken, dass MDSD einen viel versprechenden Ansatz
darstellt, der allerdings auch Anfangsinvestitionen beziehungsweise neue Fähig-
keiten erfordert. So müssen Artefakte wie eine domänenspezifische Plattform
und eine DSL geschaffen werden. Speziell Letztere stellt hohe Anforderungen an
die Modellierungsfertigkeiten der beteiligten Entwickler. Dieses Wissen ist nicht
immer vorhanden sondern muss in vielen Fällen erst erworben werden.
MDSD stellt ein noch relativ junges Forschungsgebiet der Informatik dar, was
auch der geringe Umfang an verfügbarer Literatur belegt. Im Laufe der Arbeit
ergaben sich immer wieder Fragestellungen, deren Behandlung den Rahmen die-
ser Magisterarbeit gesprengt hätte, die aber Ausgangspunkte für weitere Unter-

8 Zusammenfassung und Ausblick 115
suchungen bieten. Im Folgenden werden einige gelistet.
• oAW bietet seit Version 4.0 die Möglichkeit EMF basierte Modelle zu ver-
arbeiten. Die Arbeiten zum Fallbeispiel waren zum Erscheinen von Version
4.0 allerdings bereits zu weit fortgeschritten, als dass eine Abwägung noch
sinnvoll gewesen wäre. Es wäre interessant einen Vergleich zwischen der
Nutzung von oAW mit Hilfe von UML Modellen und EMF basierten Mo-
dellen anzustellen. Des Weiteren kann in diesen Vergleich auf Seiten von
EMF, die Erzeugung eines domänenspezfischen Editors mit Hilfe des GMF
Projekts, mit einbezogen werden.
• In Rahmen des Fallbeispiels wurde sowohl auf die Nutzung von Aktivitäts-
diagrammen zur Generierung von Code zur Ablaufsteuerung verzichtet als
auch auf die Möglichkeit Modelle in Submodelle zu zerteilen um bestimmte
Aspekte wie die Persistenz besser herauszuarbeiten. Ein möglicher Ansatz-
punkt wäre es zu beschreiben, wie das mit oAW umgesetzt werden kann.
Diesbezüglich existiert auch keine Ablaufbeschreibung in der Dokumenta-
tion.
• In der Arbeit wurde nur ein Tool vorgestellt um den MDSD Ansatz zu
realisieren. Eine Evaluation und ein Vergleich weiterer Werkzeuge ist ein
logischer nächster Schritt.
• Die Arbeit adressiert nur die Umsetzung einer technischen Domäne. Eine
Möglichkeit der Weiterführung ist die Betrachtung der Umsetzung einer
fachlichen Domäne oder die Darstellung des Übergangs von technischer zu
fachlicher Domäne.
• Die vorliegende Arbeit untersucht MDSD von einem technischen Stand-
punkt aus, betriebswirtschaftliche Aspekte werden nur im Rahmen der Be-
wertung adressiert. Diese zu untersuchen ist ein möglicher Schritt um die
Effizienz des Ansatzes zu belegen.

Abbildungsverzeichnis
2.1 Grundidee Modellgetriebener Softwareentwicklung (Quelle: [SV05]
116
Seite 17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Anwendungen basierend auf einer domänspezifischen Plattform
(Quelle [Bet06d] Seite 43) . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Prinzip architekturzentrierter MDSD (Quelle: [SV05] Seite 27) . . 16
4.1 Iterative, zweigleisige Entwicklung (Quelle: [SV05] Seite 213) . . . 31
4.2 Erstellung einer Domänenarchitektur; Artefakte der Domänen-
architektur (hellgrau), wichtige Zwischenergebnisse (dunkelgrau);
(Quelle: [SV05] Seite 204) . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Aktivitäten im Anwendungsentwicklungsstrang (Quelle: [SV05]
Seite 211) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Funktionsweise des openArchitectureWare-Generators (Quelle:
[SV05] Seite 111) . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Der Xpand Templateeditor . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Die Strukturansicht des Dump Browsers . . . . . . . . . . . . . . 42
5.4 Beispiel einer Projektstruktur für ein mit oAW 4 und Eclipse rea-
lisiertes MDSD-Projekt . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Option zum Starten eines oAW-Workflows . . . . . . . . . . . . . 46
5.6 Metamodell mit einer Anbindung an die übergeordneten Konzepte
der UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Nutzung eines Metamodells mittels Stereotypen . . . . . . . . . . 49
5.8 Angepasstes Metamodell für den Metamodellgenerator . . . . . . 51
6.1 Anwendungsfälle des Actors ” Kunde“ . . . . . . . . . . . . . . . . 62
6.2 Anwendungsfälle des Actors ” Administrator“ . . . . . . . . . . . . 63
6.3 Das Model 2 für Java Webanwendungen (Quelle [Weß05] Seite 13) 68
6.4 Die Architetektur des Struts Frameworks (Quelle: [Weß05] Seite 17) 69
6.5 Schichtenarchitektur der Domäne ” E-Business Systeme“ . . . . . . 70

Abbildungsverzeichnis 117
6.6 Schematischer Aufbau der Webseiten des Fallbeispiels . . . . . . . 74
6.7 Metamodell der Domäne
” Softwarearchitektur für E-
Businesssysteme“ als UML-Profil . . . . . . . . . . . . . . . . . . 75
6.8 Die Kundenverwaltung von ” Bücherwurm“ . . . . . . . . . . . . . 78
6.9 Die Modellierung einer Webschnittstelle zur Datenverwaltung . . 80
6.10 Die Modellierung einer Suche . . . . . . . . . . . . . . . . . . . . 81
6.11 Adaptiertes Metamodell der Erben von UML::Attribute . . . . . . 85
6.12 Adaptiertes Metamodell der Erben von UML::Class . . . . . . . . 86
6.13 Metamodell mit erweiterter Semantik . . . . . . . . . . . . . . . . 97
7.1 Aufwand bei traditioneller Softwareentwicklung (Quelle: [SV05]
Seite 318) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.2 Aufwand bei modellgetriebener Softwareentwicklung mit teilweise
manueller Kodierung (Quelle [SV05] Seite 319) . . . . . . . . . . . 107

Tabellenverzeichnis
5.1 Für das Fallbeispiel benötigte oAW Komponenten und ihre
118
Abhängigkeiten (Quelle [Kad06a]) . . . . . . . . . . . . . . . . . . 40
5.2 Vom Generatorprojekt benötigte jar Dateien aus dem oAW Toolkit 44
6.1 Gegenüberstellung der Anzahl manuell codierter LOC und gene-
rierter LOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Listings
5.1 Beispiel einer Workflowkonfiguration (Quelle: [EV06] Seite 5) . . . 45
5.2 Implementierung der Metaklasse DataObject . . . . . . . . . . . . 49
5.3 Zuordnung von Stereotypen zu Metaklassen via metamappings.xml 50
5.4 Beispiel für ein Xpand Template . . . . . . . . . . . . . . . . . . . 52
5.5 Beispiel für ein Xpand Template . . . . . . . . . . . . . . . . . . . 53
5.6 Syntax des Xpand DEFINE-Blocks (Quelle [KE06]) . . . . . . . . 54
5.7 Syntax des Xpand-FOREACH Blocks (Quelle [KE06]) . . . . . . . 56
5.8 Syntax des Xpand IF-Blocks (Quelle [KE06]) . . . . . . . . . . . . 56
5.9 Beispiel für Konstrukte der Subsprache Expressions Quelle [Eff06b] 57
5.10 Beispiel für eine Extendbibliothek (Quelle: [Eff06c]) . . . . . . . . 58
5.11 Syntax von Check-Regeln (Quelle: [Eff06a]) . . . . . . . . . . . . . 59
5.12 Beispiel für eine Check-Regel . . . . . . . . . . . . . . . . . . . . . 59
6.1 Propertiesfile zur Parametrisierung des Metamodellgenerators . . 83
6.2 Die Methode Key() der Klasse EBADataClass . . . . . . . . . . . 87
6.3 Die Methode isUserDefinedKey() der Klasse EBAEntityObject . . 88
6.4 Die Methode UIAttribute() der Klasse EBAPresentation . . . . . 88
6.5 Der Einstiegspunkt für Templates zur Codegenerierung . . . . . . 90
6.6 Ausschnitt aus dem Template EJBRoot::Root . . . . . . . . . . . 91
6.7 Beispiel für eine Protected Region . . . . . . . . . . . . . . . . . . 92
6.8 Einbinden eines anderen Workflows . . . . . . . . . . . . . . . . . 93
6.9 Aufruf einer WorkflowComponent . . . . . . . . . . . . . . . . . . 94
6.10 Aufruf der Cartridge classicstart . . . . . . . . . . . . . . . . . . . 95
119
6.11 Aufruf der Generatorkomponente . . . . . . . . . . . . . . . . . . 96

Literaturverzeichnis
[agi06] Manifesto for Agile Software Development.
http://www.agilemanifesto.org/. Version: Juli 2006
[ant05] Apache Ant. http://ant.apache.org/. Version: Oktober 2005
[BA04] Bodoff, Stephanie ; Armstrong, Eric: The J2EE Tutorial.
Second Edition. Addison Wesley Publishing Company, 2004
[Bet06a] Bettin, Jorn: Best Practices for Component-Based Development
and Model-Driven Architecture. http://www.softmetaware.com/
publicwhitepapers/best-practices-for-cbd-and-mda.pdf.
Version: März 2006
[Bet06b] Bettin, Jorn: Model-Driven Architecture Implementation &
Metrics. http://www.softmetaware.com/publicwhitepapers/
mda-implementationandmetrics.pdf. Version: März 2006
[Bet06c] Bettin, Jorn: Model-Driven Software Development Activities: The
Process View of an MDSD Project.
120
http://www.softmetaware.com/mdsd-process.pdf. Version: März
2006
[Bet06d] Bettin, Jorn: Model-Driven Software Development: An emerging
paradigm for Industrialized Software Asset Development. http://
www.softmetaware.com/publicwhitepapers/mdsd-and-isad.pdf.
Version: März 2006
[cas06] Computer-Aided Software Engineering (CASE) Environments.
http://www.sei.cmu.edu/legacy/case/case_whatis.html.
Version: März 2006
[CE00] Czarnecki, Krzyszstof ; Eisenecker, Ulrich W.: Generative
Programming : Methods, Tools and Applications. First Edition.
Addison Wesley Publishing Company, 2000

Literaturverzeichnis 121
[CN04] Clements, Paul ; Northrop, Linda: Software Product Lines,
Practices and Patterns. 2. Auflage. Addison Wesley Publishing
Company, 2004
[dat06] Core J2EE Patterns - Transfer Object. http://java.sun.com/
blueprints/corej2eepatterns/Patterns/TransferObject.html.
Version: Jänner 2006
[ecl06] Eclipse.org home. http://www.eclipse.org. Version: April 2006
[Eff06a] Efftinge, Sven: Check - Validation Language. http:
//www.eclipse.org/gmt/oaw/doc/r30_checkReference.pdf.
Version: Jänner 2006
[Eff06b] Efftinge, Sven: Expressions Framework Reference. http://www.
eclipse.org/gmt/oaw/doc/r10_expressionsReference.pdf.
Version: Jänner 2006
[Eff06c] Efftinge, Sven: Extend Language Reference. http:
//www.eclipse.org/gmt/oaw/doc/r25_extendReference.pdf.
Version: Jänner 2006
[ejb06] Enterprise JavaBeans Specification 2.1.
http://java.sun.com/products/ejb/docs.html. Version: April
2006
[EV06] Efftinge, Sven ; Voelter, Markus: Workflow Engine Reference.
http:
//www.eclipse.org/gmt/oaw/doc/r05_workflowReference.pdf.
Version: Jänner 2006
[Fow03] Fowler, Martin: Patterns of Enterprise Application Architecture.
1. Auflage. Addison Wesley Publishing Company, 2003
[Fra03] Frankel, David S.: Model Driven Architecture, Applying MDA to
Enterprise Comptuing. Wiley Publishing, Inc., Indianaplois,
Indiana, 2003
[gmf06] Graphical Modeling Framework. http://www.eclipse.org/gmf/.
Version: August 2006
[HK99] Hitz, Martin ; Kappel, Gerti: UML@Work, Von der Analyse zur
Realisierung. 1. Auflage, korrigierter Nachdruck. dpunkt.verlag,
1999

Literaturverzeichnis 122
[HKKR05] Hitz, Martin ; Kappel, Gerti ; Kapsammer, Elisabeth ;
Retschitzegger, Werner: UML@Work, Objektorientierte
Modellierung mit UML 2. 3. aktualisierte und überarbeitete
Auflage. dpunkt.verlag, 2005
[j2e05] Java Platform, Enterprise Edition (Java EE).
http://java.sun.com/javaee/index.jsp. Version: Oktorber 2005
[jbo05a] JBoss Application Server.
http://www.jboss.com/products/jbossas. Version: November
2005
[JBo05b] JBoss, Inc. (Hrsg.): The JBoss 4 Application Server Guide. JBoss
AS 4.0.3. JBoss, Inc., 2004,2005
[Kad06a] Kadura, Clemens: oAW 4 Installation.
http://www.eclipse.org/gmt/oaw/doc/10_installation.pdf.
Version: April 2006
[Kad06b] Kadura, Clemens: oaW 4 Migration. http://www.eclipse.org/
gmt/oaw/doc/25_migrationAndOAWClassic.pdf. Version: Jänner
2006
[KCH + 90] Kang, K. ; Cohen, S. ; Hess, J. ; Novak, W. ; Peterson, A.:
Feature-Oriented Domain Analysis (FODA) Feasibility Study /
Software Engineering Institue, Carnegie Mellon University. 1990
(CMU/SEI-90-TR-21). – Forschungsbericht
[KE06] Kadura, Clemens ; Efftinge, Sven: Xpand Language Reference.
http:
//www.eclipse.org/gmt/oaw/doc/r20_xPandReference.pdf.
Version: Jänner 2006
[loc06] Lines of Code Counter.
http://www.csc.calpoly.edu/~jdalbey/SWE/PSP/LOChelp.html.
Version: Mai 2006
[Mar03] Martin, Robert C.: Agile Software Development : Principles,
Patterns and Practices. First Edition. Prentice Hall - Pearson
Education, Inc, 2003
[mda06a] MDA Guide Version 1.01.
http://www.omg.org/docs/omg/03-06-01.pdf. Version: März
2006

[mda06b] MDA Specifications, UML-Profiles.
Literaturverzeichnis 123
http://www.omg.org/mda/specs.htm#Profiles. Version: Juli 2006
[MH04] Monson-Haefel, Richard: Enterprise JavaBeans. Fourth Edition.
O’Reilly Media, Inc., 2004
[.ne06] Microsoft .Net Homepage.
http://www.microsoft.com/net/default.mspx. Version: April
2006
[Net06] Network, Code G.: Markus Voelter tells us about
openArchitectureWare. http://www.codegeneration.net/
tiki-read_article.php?articleId=80. Version: April 2006
[oaw05] openArchitectureWare. http://www.openarchitectureware.org/.
Version: Oktober 2005
[oaw06a] Built-in Types Documentation.
http://www.openarchitectureware.org/api/built-ins/.
Version: Jänner 2006
[oaw06b] openArchitectureWare. http://www.eclipse.org/gmt/oaw/.
Version: April 2006
[oaw06c] openArchitectureWare Classic Example.
http://www.eclipse.org/downloads/download.php?file=
/technology/gmt/oaw/40/oaw-sample-classic-4.0.0.zip.
Version: April 2006
[oaw06d] openArchitectureWare Documentation.
http://www.eclipse.org/gmt/oaw/doc/. Version: April 2006
[omg06] MOF 2.0/XMI Mapping Specification, v2.1.
http://www.omg.org/docs/formal/05-09-01.pdf. Version: April
2006
[PBG04] Posch, Torsten ; Birken, Klaus ; Gerdom, Michael: Basiswissen
Softwarearchitektur Verstehen, entwerfen, bewerten und
dokumentieren. 1. Auflage. dpunkt.verlag, 2004
[PBL05] Pohl, Klaus ; Böckle, Günter ; Linden, Frank van d.: Software
Product Line Engineering, Foundations, Principles, and Techniques.
Springer-Verlag Berlin Heidelberg, 2005

Literaturverzeichnis 124
[pos05] Gentleware Poseidon for UML 3.2 Community Edition.
http://www.gentleware.com/index.php?id=ce. Version: Oktober
2005
[ses06] Core J2EE Patterns - Session Facade. http://java.sun.com/
blueprints/corej2eepatterns/Patterns/SessionFacade.html.
Version: Jänner 2006
[str05] Apache Struts Project. http://struts.apache.org/.
Version: November 2005
[SV05] Stahl, Thomas ; Völter, Markus: Modellgetriebene
Softwareentwicklung: Techniken, Engineering, Management. 1.
Auflage. dpunkt.verlag, 2005
[Tho06] Thomas, Karsten: oAW Classic UML Example. http:
//www.eclipse.org/gmt/oaw/doc/55_umlClassicExample.pdf.
Version: März 2006
[tom05] Apache Tomcat. http://tomcat.apache.org/. Version: November
2005
[VB06] Völter, Markus ; Bettin, Jorn: Patterns for Model-Driven
Software-Development.
http://www.voelter.de/data/pub/MDDPatterns.pdf.
Version: März 2006
[Völ05a] Völter, Markus: Metamodellbasierte Codegenierierung in Java.
http:
//www.voelter.de/data/articles/MetaModelBasedCodeGen.pdf.
Version: Semptember 2005
[Völ05b] Völter, Markus: openArchitectureWare Metamodel Generator.
http:
//www.voelter.de/data/articles/MetaModelBasedCodeGen.pdf.
Version: Oktober 2005
[Völ05c] Völter, Markus: openArchitectureWare Tutorial.
http://prdownloads.sourceforge.net/architecturware/
exampleWorkspace-3.0-DocPack.zip?download. Version: Oktober
2005

Literaturverzeichnis 125
[Völ06a] Völter, Markus: oAW 4 Introduction and Overview. http://www.
eclipse.org/gmt/oaw/doc/05_IntroductionAndOverview.pdf.
Version: April 2006
[Völ06b] Völter, Markus: Recipe Framework Reference. http:
//www.eclipse.org/gmt/oaw/doc/r40_recipeReference.pdf.
Version: Mai 2006
[Weß05] Weßendorf, Matthias: Struts : Websites effizient entwickeln.
W3L Verlag Herdecke,Bochum, 2005