\chapter{Umsetzungsmöglichkeiten}
\label{chap_umsetzungsmoeg}
Für die Umsetzung von \mddr\ werden in der Regel unterschiedliche Werkzeuge in Kombination miteinander verwendet. Diese Werkzeuge decken dabei die folgenden Teilbereiche des modellgetriebenen Entwicklungsprozesses ab.
\begin{itemize}
  \item Es muss ein geeignetes Metamodell definiert werden.
  \item Es wird ein Werkzeug zur Modellierung benötigt.
  \item Es ist ein Generator für die Transformationen erforderlich.
\end{itemize}

Im Folgenden werden für diese Teilbereiche unterschiedliche Werkzeuge vorgestellt. Die Werkzeuge decken dabei oftmals nicht nur einen Teilbereich ab. Manche Werkzeuge zur Modellierung legen beispielsweise die Technik zur Erstellung des Metamodells oder den zu verwendenden Generator fest. Ebenso muss für die Anwendung mancher Generatoren das Modell in einem speziellen Format vorliegen. Bei der Wahl der Werkzeuge und Techniken muss dies bedacht werden.

\section{Metamodellierung}
\label{sec_metamodellierung}
Die Metamodellierung ist ein wesentlicher Teil der Entwicklung einer DSL. Es gibt unterschiedliche Metametamodelle, die hierfür verwendet werden können. Neben der \MOF , die bei der \MDA\ angewandt wird, gibt es beispielsweise die folgenden drei Möglichkeiten ein Metamodell zu definieren:
\begin{itemize}
  \item die Verwendung des Metametamodells \newWord{Ecore},
  \item die Erstellung eines Metamodells mittels Klassen einer Programmiersprache,
  \item die Beschreibung des Metamodells mittels XML.
\end{itemize}
Im Folgenden werden diese vier Techniken der Metamodellierung beschrieben.

\subsection{MOF und UML}
Die \OMG\ definiert 4 (Meta-) Ebenen zur Beschreibung eines Systems. Die Ebenen sind von M0 bis M3 durchnummeriert, wie in Abbildung \ref{img_metaebenen} dargestellt. Die \MOF\ ist dabei das Metametamodell und befindet sich auf Ebene M3. Die \MOF\ beschreibt sich selbst. Anhang \ref{anhang_mof} zeigt einen vereinfachten Ausschnitt der MOF. Auf Ebene M2 befindet sich die UML oder ein anders Metamodell, das eine Instanz der \MOF\ ist. Die hier betrachtete Version der UML ist die UML 2.0. Im Folgenden wird der Begriff ``UML'' ohne Versionsbezeichnung verwendet. Die Aussagen zur UML beziehen sich jedoch auf diese Version. \mycite[Kap. 5.2]{Stahl07}
\begin{figure}[h]
\centering
\includegraphics[width=0.7\textwidth]{images/metaebenen.png} 
\caption{Metaebenen, Quelle: \mycite[S. 62]{Stahl07}}
\label{img_metaebenen}
\end{figure}

Bei der Verwendung der MOF zur Metamodellierung kann die UML als Metamodell verwendet werden. Dies hat den Vorteil, dass die \UML\ zum einen durch die \OMG\ standardisiert ist. Zum anderen gibt es unterschiedliche Werkzeuge zur Erstellung und Bearbeitung von UML-Modellen. Bei der Bearbeitung von Modellen, die die UML als Metamodell verwenden, ist der Entwickler daher nicht auf ein spezifisches Werkzeug festgelegt. Des Weiteren können UML-Modelle von unterschiedlichen Systemen verarbeitet werden. Neben der Verwendung der UML als Metamodell besteht die Möglichkeit, mittels der \MOF\ ein Metamodell, das spezifisch für eine Domäne ist, zu entwickeln. Hierbei gehen jedoch die Vorteile der UML, wie zum Beispiel die Werkzeugunterstützung zur Modellierung, verloren. In den meisten Fällen ist daher ein anderes Metametamodell für diesen Zweck besser geeignet. \mycite[Kap. 5.2]{Stahl07}

\par
\textquote[\cite{Stahl07}, S. 65]{Die \UML\ ist ein allgemeines Metamodell \textnormal{[\ldots]}}, das der Beschreibung von Softwaresystemen dient. Bei der \mddn\ wird jedoch in der Regel ein Metamodell benötigt, das die speziellen Eigenschaften einer Domäne wiedergibt. Zu diesem Zweck kann die \UML\ erweitert werden. Diese Erweiterung kann durch die Definition von neuen UML-Elementen oder durch die Erstellung von \newWord{UML-Profilen} vorgenommen werden. \mycite[Kap. 5.2]{Stahl07}

\par
Bei der Erweiterung der \UML\ um neue Elemente erben die neuen Elemente von bereits existierenden UML-Elementen. Die neuen Elemente sind somit Instanzen von MOF-Elementen. Abbildung \ref{img_umlerweiterung} verdeutlicht diesen Ansatz. \mycite[Kap. 5.2]{Stahl07}
\begin{figure}[h]
\centering
\includegraphics[width=0.55\textwidth]{images/uml.png} 
\caption{Erweiterung der UML durch neue Metamodellelemente, Quelle: \mycite[S. 66]{Stahl07}}
\label{img_umlerweiterung}
\end{figure}

\par
Bei der Erstellung eines Modells unter Verwendung der so erweiterten UML können von den neuen UML-Elementen Instanzen erstellt werden. Die Darstellung der Instanzen hängt von dem gewählten UML-Werkzeug ab. Abbildung \ref{img_new_uml_elem} zeigt mögliche Darstellungsarten. In Version (a) in Abbildung \ref{img_new_uml_elem} wird die Instanzbeziehung zwischen \code{MetaClass1} und \code{NewMetaClass} in die Darstellung des neuen UML-Elements aufgenommen. Häufig wird das neue UML-Element auch als \newWord{Stereotyp} notiert, wie in Version (b) in Abbildung \ref{img_new_uml_elem} dargestellt \mycite[Kap. 5.2]{Stahl07}. Ein Stereotyp ist ein UML-Element, das dem Modellelement, auf das es angewandt wird, zusätzliche Eigenschaften hinzufügt \mycite[Kap. 4.6]{UMLSpec}.  In Version (c) wird das UML-Element als \newWord{Tagged Value} notiert. Ein Tagged Value ist ein Schlüssel-Werte-Paar, das zu jedem Modellelement hinzugefügt werden kann. Es wird in geschweiften Klammern notiert, beispielsweise \code{\{metaclass = newMetaClass\}} \mycite[Kap. 5.17]{UMLSpec}. Version (d) zeigt die Instanz des neuen UML-Elements in einer eigenen graphischen Notation.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\textwidth]{images/new_uml_element.png} 
\caption{Darstellung eines neuen UML-Elements, Quelle: \mycite[S. 67]{Stahl07}}
\label{img_new_uml_elem}
\end{figure}

\par
Die zweite Möglichkeit zur Erweiterung der UML sind  UML-Profile, im Folgenden als \newWord{Profil} bezeichnet. In einem UML-Profil sind UML-Erweiterungen zusammengefasst, mit dem Ziel, die UML an eine fachliche oder technische Domäne anzupassen. Ein Profil wird als ein UML-Paket mit dem Stereotyp \code{\flqq profile\frqq} dargestellt (siehe Abbildung \ref{img_profile}, Profildefinition). \mycite[Anhang B]{UMLLearning}

\par
Ein UML-Profil enthält Stereotypen, \newWord{Tag Definitions} und Constraints. Tag Definitions sind mögliche Eigenschaften eines Mo\-dell\-ele\-ments. Eine Tag Definition, die für ein Modellelement angegeben ist, wird über ein Tagged Value dargestellt. Ein Stereotyp definiert zum einen mittels der Tag Definitions Eigenschaften und zum anderen Constraints. Die Modellelemente, die mit dem Stereotyp versehen sind, erhalten die Eigenschaften und Constraints des Stereotyps, wie in Abbildung \ref{img_profile} im Teil ``Profilanwendung'' gezeigt \mycite[Kap. 4.6]{UMLSpec}. Der Typ der Modellelemente, auf die ein Stereotyp angewendet werden kann, wird bei einer Profildefinition über eine \newWord{Extension} festgelegt. Eine Extension ist ein Pfeil, dessen Pfeilspitze ausgefüllt ist. Sie verbindet den Stereotyp mit dem entsprechenden Metamodellelement, wie beispielsweise dem MOF-Element \code{Class}. Ein Metamodellelement wird hierbei mit dem Stereotyp \code{\flqq metaclass\frqq} gekennzeichnet \mycite[Kap. B.5]{UMLLearning}. Abbildung \ref{img_profile} zeigt die Definition und Anwendung eines Profils, wobei eine Extension verwendet wird.
\begin{figure}[h]
\centering
\includegraphics[width=0.75\textwidth]{images/uml_profile.png} 
\caption{Definition und Anwendung eines UML-Profils, Quelle: angelehnt an \mycite[S. 69]{Stahl07}}
\label{img_profile}
\end{figure}

\par
Wichtiger Bestandteil eines Metamodells sind Constraints. Sie sind erforderlich, um Modelle, die Instanzen dieses Metamodells sind, validieren zu können. Bei der Verwendung von UML können Constraints mit einer beliebigen Sprache definiert werden. Die \OMG\ hat zur Formulierung von Constraints die \OCL\ standardisiert. \OCL\ wurde von IBM entwickelt und ist Teil der UML-Spezifikation \mycite[Anhang A]{UMLLearning}. Ein Profil kann neue Constraints definieren. Es kann die bestehenden Constraints der UML jedoch nicht aufheben \mycite[Kap. 5.2]{Stahl07}.

\par
Zusammenfassend ist zur UML zu sagen, dass sie unterschiedliche Vorteile mit sich bringt. Dazu gehören die Auswahl an unterschiedlichen Modellierungswerkzeugen und die Standardisierung durch die OMG. Der Nachteil der \UML\ ist jedoch, dass sie zwar erweitert, aber nicht reduziert werden kann. UML-Werkzeuge stellen daher immer alle Modellierungsmöglichkeiten zur Verfügung. Dies kann zu einem Überangebot an Funktionalität führen, das unter Umständen nicht erwünscht ist. \mycite[Kap. 5.2]{Stahl07}


\subsection{Ecore und EMF}
\label{subsec_ecore}
Das \EMF\ wird im Rahmen des \newWord{Eclipse Modeling Projects}\footnote{Mehr Informationen zum Eclipse Modeling Project sind zu finden unter http://www.eclipse.org/modeling/.} der \newWord{Eclipse Foundation} entwickelt. Die Eclipse Foundation ist eine gemeinnützige Organisation, die die unterschiedlichen Projekte der Eclipse-Open-Source-Gemeinschaft leitet. Diese Projekte konzentrieren sich auf die Entwicklung und Erweiterung einer Open-Source-\IDE, genannt \newWord{Eclipse}, deren aktuelle Version zur Zeit der Anfertigung dieser Diplomarbeit \newWord{Eclipse Europa} ist. Die Funktionalität von Eclipse kann durch Komponenten, sogenannte \newWord{Plugins}, erweitert werden. \mycite{EclipseAbout}

\par
\EMF\ ist ein solches Plugin für Eclipse. Das Plugin stellt ein Java Framework bereit, das der Erzeugung von Modellierungswerkzeugen dient. Diese Modellierungswerkzeuge sind spezifisch für ein Metamodell. Das Metamodell kann dabei mit EMF definiert werden. EMF folgt dem Ansatz der \mddn. Ein Modellierungswerkzeug wird dazu aus dem Metamodell und einem weiteren Modell, das implementierungsspezifische Details enthält, automatisch generiert. Mittels dieser generierten Modellierungswerkzeuge können Modelle bearbeitet und persistiert werden. \mycite{EMFHelp} 

\par
EMF verwendet Ecore zur Metamodellierung. Ecore hat Ähnlichkeit mit der \EMOF, die eine reduzierte Version der \MOF\ ist \mycite[Kap. 5.2]{Stahl07}. Die Elemente der EMOF und ihre Hierarchie sind in Anhang \ref{anhang_emof} abgebildet. Ebenso wie die \MOF\ beschreibt sich Ecore selbst \mycite[Kap. 2.3]{EMFOnline}. Im Gegensatz zur MOF wird jedoch bei der Verwendung von Ecore das gesamte Metamodell definiert. Ein solches Metamodell wird dabei mit der Dateiendung ``.ecore'' im XMI-Format, einem XML-Format, gespeichert. \mycite[Kap. 5.2]{Stahl07}

\begin{figure}[h]
\centering
\includegraphics[width=0.95\textwidth]{images/tools/ecore.png} 
\caption{Metametamodell Ecore, Quelle: \mycite{EMFHelp}}
\label{img_ecore_mmm}
\end{figure}
Abbildung \ref{img_ecore_mmm} zeigt die Klassenhierarchie des Metametamodells Ecore. Abstrakte Klassen sind in der Abbildung blau gefärbt. Bei der Erstellung eines Metamodells mittels Ecore werden Instanzen der in der Abbildung gezeigten Elemente erstellt. Die Modellelemente eines Metamodells sind beispielsweise Instanzen der Unterklassen der abstrakten Klasse \code{EClassifer}.


\par
\begin{floatingfigure}[v]{0.4\textwidth}
\includegraphics[width=0.38\textwidth]{images/emf.png} 
\caption{EMF, Quelle: \mycite[Kap. 2.1]{EMFOnline}}
\label{img_emf}
\end{floatingfigure}
Für die Erstellung eines Metamodells mittels EMF gibt es mehrere Möglichkeiten. Es kann als Ecore-Modell, als XML Schema, als UML"=Diagramm oder als annotierte Java-Interfaces definiert werden. Aus dem Format, welches zur Definition verwendet wird, können die jeweils anderen Formate dann automatisch erzeugt werden. Dieses Prinzip ist in Abbildung \ref{img_emf} schematisch dargestellt. \mycite[Kap. 2.4]{EMFOnline}

\par
\textquote[\cite{EMFHelp}]{EMF consists of two fundamental frameworks: the core framework and EMF.Edit.} Das ``Kern"=Framework'' bietet grundlegende Unterstützung zur Generierung der Java-Klassen für ein Ecore-Modell. Hierfür wird der Codegenerator \JET\ verwendet \mycite[Kap. 11.1]{EMFOnline}. EMF.Edit erweitert das ``Kern"=Framework'' hauptsächlich um die folgenden Bestandteile: \mycite{EMFHelp}
\begin{itemize}
  \item Mittels EMF.Edit werden Adapter für die Klassen, die die Elemente des Metamodells repräsentieren, erstellt. Diese Adapter folgen dabei nicht dem klassischen \newWord{Adapter}-Pattern, wie es bei Erich Gamma definiert wird.\footnote{Vgl. hierzu das Entwurfsmuster ``Adapter'' bei Gamma et al. (\mycite[S. 139]{gamma}).} Stattdessen erweitern sie die Funktionalität einer Klasse. Sie dienen nicht, wie es das Adapter-Pattern bei Gamma vorsieht, der Übersetzung einer Schnittstelle in eine andere. Adapter bei Eclipse, wozu auch die generierten Adapter gehören, folgen dem \newWord{Extension Object}-Pattern\footnote{Siehe hierzu \mycite[Kap. 31]{EclipseBuch}}. \mycite[Kap. 31]{EclipseBuch}
  \par
  Die Adapter ermöglichen beispielsweise die Umsetzung des \newWord{Command}-Patterns. Bei der Verwendung des Command-Patterns werden Aktionen in Objekten gekapselt.\footnote{Vgl. hierzu das Entwurfsmuster ``Command'' bei Gamma et al. (\mycite[S. 233]{gamma})} Dadurch können unter anderem Änderungen an einem Modell mit Hilfe einer Undo-Funktion rückgängig gemacht werden. 
  \item Mit Hilfe des EMF.Edit-Frameworks kann ein einfacher Editor zum Bearbeiten der Modelle erstellt werden. Der Editor stellt die Modelle in einer Baumansicht dar.
\end{itemize}
   

\subsection{Metamodellierung mittels Klassen}
Bei der Metamodellierung mittels Klassen wird das Metamodell in einer beliebigen Programmiersprache implementiert. Hierfür wird für jedes Metamodellelement eine Klasse entwickelt. Modelle, die Instanzen eines solchen Metamodells sind, bestehen dann aus Objekten, die sich gegenseitig referenzieren. Die Informationen, die in einem Modell enthalten sind, sind in den Attributen der Objekte gespeichert. Das Metametamodell ist bei dieser Art des Metamodells die zugrunde liegende Programmiersprache. Zur Vereinfachung der Verarbeitung solcher Metamodelle, wird die verwendete Programmiersprache in der Regel durch geeignete Konventionen eingeschränkt. Eine Einschränkung der Programmiersprache Java könnte beispielsweise sein, dass jede Klasse einen \code{public}-Konstruktor haben muss. \mycite[Kap. 5.2]{Stahl07}

\par
Der Vorteil bei dieser Art der Metamodellierung ist die leichte Erweiterbarkeit der Funktionalität eines Metamodells. Benötigte Funktionen, wie beispielsweise die automatische Berechnung eines Werts A aus einem Wert B eines Modellelements, können dem Metamodell über das Erstellen einer geeigneten Methode in der entsprechenden Klasse hinzugefügt werden. Ein weiterer Vorteil ist, dass die Entwicklung des Metamodells durch die Verwendung einer leistungsstarken \IDE\ unterstützt werden kann. \mycite[Kap. 5.2]{Stahl07}

\par
Diese Art der Repräsentation eines Metamodells wird oft zusätzlich zu einer der anderen, hier vorgestellten Arten genutzt. \EMF\ beispielsweise bietet die Möglichkeit aus einem Ecore-Modell automatisch den Elementen entsprechende Java-Klassen zu generieren. Die meisten UML-Werkzeuge verwenden ebenfalls Klassen beziehungsweise von diesen erstellte Objekte für die interne Repräsentation eines Modells. Hierbei ist die Abstraktion bezüglich der Metaebenen eines Modells nicht mehr eindeutig. Solche Klassen repräsentieren abstrakt betrachtet ein UML-Metamodell beziehungsweise ein Ecore-Modell. Somit ist die MOF beziehungsweise Ecore das Metametamodell. Aus technischer Sicht sind diese Modelle jedoch als Instanzen einer Programmiersprache aufzufassen. Das Metametamodell ist aus dieser Sicht die jeweilige Programmiersprache. \mycite[Kap. 5.2]{Stahl07}

\subsection{XML/XSD}
Die vierte hier vorgestellte Möglichkeit der Metamodellierung ist die Metamodellierung mit XML. Hierbei wird das Metamodell mittels einer \XSD\ erstellt. Eine \XSD\ ist ein XML-Dokument, das eine Struktur für XML-Dokumente definiert. Sie legt unterschiedliche Regeln fest, die ein XML-Dokument, welches dem Schema folgt, einhalten muss, damit es valide ist. Das XML-Dokument ist hierbei das Modell. Eine \XSD\ folgt selbst einer \XSD. \XSD\ ist somit auch das Metametamodell. Der Vorteil bei der Verwendung von XML ist, dass es mehrere Werkzeuge und Programmbibliotheken zum editieren und \gls{glos:Parse} von XML-Dokumenten gibt.\footnote{Mehr Informationen zur Erstellung und Anwendung von XSD findet sich unter http://www.w3schools.com/schema/default.asp.} \mycite[Kap. 5.2]{Stahl07}

\newpage
\section{Modellierung}
Ein weiterer wesentlicher Bestandteil der modellgetriebenen Softwareentwicklung ist die Modellierung. Dafür werden Modellierungswerkzeuge benötigt. Diese basieren auf einem zuvor definierten Metamodell. Sie umfassen im Wesentlichen eine graphische Benutzeroberfläche und die konkrete Syntax der DSL.

Für die Modellierung gibt es unterschiedliche Möglichkeiten. Zunächst kann die UML oder XML dazu verwendet werden. Die Modellierung mit UML richtet sich dabei nach den Erweiterungen der UML im Metamodell. Das bedeutet zum einen, dass für das Metamodell definierte UML-Profile bei der Modellierung angewandt werden (vgl. Abbildung \ref{img_profile}). Zum anderen werden, wenn das Metamodell neu definierte UML-Elemente enthält, bei der Modellierung Instanzen von diesen erstellt (vgl. Abbildung \ref{img_new_uml_elem}). Eine ausführliche Beschreibung der Verwendung der UML findet sich in \mycite{UMLLearning}. Bei der Modellierung mit XML richtet sich die Erstellung des XML-Dokuments nach der zuvor definierten \XSD.

\par
Eine weitere Möglichkeit für die Modellierung sind die mit EMF automatisch generierbaren Modellierungswerkzeuge. EMF wurde in Abschnitt \ref{subsec_ecore} bereits vorgestellt. An dieser Stelle wird daher dieses Framework nicht eingehender beschrieben. Darüber hinaus gibt es jedoch weitere Technologien, die speziell für die Erstellung von Modellen oder die Erzeugung von Modellierungswerkzeugen konzipiert sind. Diese werden im Folgenden beschrieben.

\subsection{GMF}
Das \GMF\ ist ein Plugin für \gls{glos:Eclipse}. Es dient der Entwicklung von graphischen Editoren zur Erstellung und Persistierung von Modellen. \GMF\ verbindet das \resetacronym{EMF}\EMF\ und das \GEF\ \mycite{GMFHelp}. Hierbei ist GEF ein Framework zur graphischen Erstellung und Darstellung von Modellen \mycite{GEFHelp}. Bei GMF wird GEF für die Entwicklung der graphischen Editoren verwendet. Mittels \EMF\ werden die Modelle gespeichert und verwaltet \mycite{GMFHelp}. Abbildung \ref{img_gmf_aufbau} zeigt schematisch den Aufbau von GMF. 
\begin{figure}[h]
\centering
\includegraphics[width=0.65\textwidth]{images/tools/gmf.png} 
\caption{Aufbau von GMF}
\label{img_gmf_aufbau}
\end{figure}

\par
Ein mit \GMF\ erstellter Editor zur Modellierung wird im Folgenden als \newWord{GMF"=Modellierungstool} bezeichnet. Ein GMF"=Modellierungstool benötigt zwei Arten von Informationen zu einem Modell. Es benötigt semantische Informationen und graphische Informationen. Die semantischen Informationen sind das Modell selbst. Sie geben beispielsweise an, welche Elemente im Modell enthalten sind und wie sie miteinander in Verbindung stehen. Die graphischen Informationen werden für die Darstellung des Modells verwendet. Sie beschreiben zum Beispiel, wie die Elemente des Modells konkret angezeigt werden. Das Modell wird im XMI-Format gespeichert. Die graphischen Informationen werden ebenfalls getrennt von dem Modell im XMI-Format gespeichert. Diese Trennung von semantischen und graphischen Informationen ermöglicht es, ein Modell auf unterschiedliche Weise ohne erneute Modellierung darzustellen. Für eine andere Darstellung des Modells werden lediglich andere graphische Informationen benötigt. \mycite{GMFHelp}

\subsection{Xtext}
\newWord{\gls{glos:xtext}} ist ein Framework zur Definition von textuellen DSLs. Es ist Teil des \newWord{open\-Ar\-chi\-tec\-ture\-Ware}-Projekts.\footnote{Informationen zum openArchitectureWare-Projekt finden sich unter \mycite{OAW}.} Xtext ermöglicht die Beschreibung der konkreten und abstrakten Syntax einer DSL durch eine vereinfachte EBNF (Extended Backus-Naur-Form). Die EBNF ist eine \textquote[\cite{Brockhaus}, S. 91]{Notationsform \textnormal{[\ldots]} zur Definition der Syntax einer Programmiersprache}. 

Listing \ref{listing_xtextGram} zeigt eine Xtext-Grammatik. Zunächst wird in der Grammatik in Zeile 1 festgelegt, dass ein Modell aus einem oder mehreren Elementen, in der Grammatik als \code{Entity} bezeichnet, besteht. Diese Festlegung bezieht sich auf die abstrakte Syntax der DSL. Die Zeilen 2 bis 4 legen fest, wie ein Element beschrieben wird. Dies sind Angaben zur konkreten Syntax der DSL. Des Weiteren wird in Zeile 3 im Rahmen der abstrakten Syntax definiert, dass ein Element beliebig viele Attribute besitzen kann. Zeile 5 sagt über die konkrete Syntax schließlich aus, in welcher Weise ein Attribut angegeben wird. \mycite[Kap. 6.2]{Stahl07}
\vspace{5pt}
\lstdefinelanguage{Xtext} 
{morekeywords={Model,Entity,Attribute, String}, 
sensitive=true,  
morestring=[b]", 
}
\begin{lstlisting}[frame=single, tabsize=3, label=listing_xtextGram, language=Xtext, caption={Xtext-Grammatik, Quelle: (\cite{Stahl07}, S. 104)}]
Model	 	:	(entities+=Entity)+;
Entity	:	"Entity" name=ID "{"
					(attributes+=Attribute)*
				"}";
Attribute:	type=ID name=ID;
\end{lstlisting} 

Die angeführte Xtext-Grammatik beschreibt die in Listing \ref{listing_xtextDSL} folgende DSL. Diese DSL legt fest, dass es zwei Metamodellelemente gibt: \code{Kunde} und \code{Adresse}. Des Weiteren kann ein Modellelement des Typs \code{Kunde} auf ein Modellelement des Typs \code{Adresse} verweisen.
\newpage
\begin{lstlisting}[frame=single, tabsize=3, label=listing_xtextDSL, language=Xtext, caption={DSL in Xtext, Quelle: (\cite{Stahl07}, S. 104)}]
Entity Kunde {
	String name
	Adresse adresse
}

Entity Adresse {
	String strasse
	String plz
	String ort
}
\end{lstlisting}

Aus der Xtext-Grammatik können ein Parser, das Metamodell und ein Eclipse-basierter Editor zur Modellierung generiert werden. Der generierte Editor hat dabei DSL-spezifische Eigenschaften wie Syntax-Highlighting oder eine automatische Codevervollständigung. Das Metamodell wird als Ecore-Modell generiert. Xtext legt somit fest, dass Ecore als Metametamodell verwendet wird. \mycite[Kap. 6.2]{Stahl07}

\subsection{Weitere Modellierungswerkzeuge}
Neben GMF und Xtext gibt es eine Reihe von weiteren Modellierungswerkzeugen. Drei dieser Werkzeuge werden im Folgenden aufgeführt. Sie werden jedoch nicht ausführlich beschrieben, da sie entweder nur kommerziell nutzbar oder auf eine spezielle Ausprägung von modellgetriebener Softwareentwicklung spezialisiert sind.

\par
Ein kommerzielles Programm zur Modellierung und Generierung von Software ist \newWord{ArcStyler} von der Firma \name{Interactive Objects}\footnote{Siehe http://www.interactive-objects.com/}. Dieses Programm ist speziell für den Entwicklungsprozess im Rahmen der \MDA\ konzipiert. ArcStyler ist in Java implementiert. Es ist hauptsächlich auf die Erstellung von Software für J2EE oder .NET spezialisiert. Für die Modellierung wird dabei \UML\ verwendet. \mycite{ArcStyler}

\par
Ein weiteres kommerzielles Programm ist \newWord{Enterprise Architect} von der Firma \name{Sparx Systems}\footnote{Siehe http://www.sparxsystems.com/}. Enterprise Architect ist ein UML-Modellierungswerkzeug, das ebenfalls Unterstützung für den MDA-Entwicklungsprozess bietet. Das Programm ermöglicht dafür Template-basierte Transformationen. Diese dienen, wie es die MDA vorsieht, der Umwandlung von PIMs in PSMs und PSMs in Quelltext. \mycite{EnterpriseArchitect}

\par
Das \GME\ ist ein Programm zur Erstellung von domänenspezifischen Modellierungstools für das Betriebssystem \gls{glos:windows}. \GME\ ist ein Open-Source-Werkzeug, das am \name{Institut für Softwareintegrierte Systeme} (ISIS) der Universität von Vanderbilt\footnote{Siehe http://www.isis.vanderbilt.edu/} entwickelt wurde. \GME\ wurde dabei ursprünglich im Rahmen von \MIC\ entwickelt und eingesetzt.\footnote{Mehr Informationen zu GME siehe http://www.isis.vanderbilt.edu/projects/gme/index.html} \mycite[Kap. 6.2]{Stahl07}

\par
\MIC\ ist eine spezielle Ausprägung der \mddn. Es wurde im Umfeld von Echtzeitsystemen und eingebetteten Systemen entwickelt. Bei \MIC\ wird ein System durch mehrere Modelle abgebildet. Die Modelle beschreiben verschiedene Teile des Systems. An das System werden hohe Anforderungen in Bezug auf Zuverlässigkeit gestellt. Die Validierung der Modelle ist daher ein zentraler Bestandteil bei diesem Ansatz.\footnote{Mehr Informationen zu MIC siehe http://www.isis.vanderbilt.edu/research/mic.html} \mycite[Kap. 3.2]{Stahl07}


\section{Generatoren}
Den dritten Teilbereich der \mddn\ bilden die Generatoren. Hierfür gibt es eine Reihe von Open-Source- und kommerziellen Generatoren. Open-Source-Generatoren sind beispielsweise \newWord{JET}, \newWord{AndroMDA}, \newWord{openArchitecureWare} und \newWord{Mod Transf}. Kommerzielle Generatoren sind zum Beispiel \newWord{BITPlan smartGENERATOR} oder \newWord{Codagen Architect}. Im Folgenden werden drei Open-Source-Generatoren vorgestellt. 

\subsection{JET}
\resetacronym{JET}\JET\ ist ein Codegenerator, der im Rahmen des Eclipse Projektes \MTT\ entwickelt wird. \MTT\ ist ein Projekt, das sich der Generierung von Textdokumenten aus Modellen widmet. Hierfür werden unter anderem Werkzeuge für die \MTC\ entwickelt, die sich nach Industriestandards, wie die der OMG, richten. Die derzeit aktuelle Version von JET wird auch als \newWord{JET2} bezeichnet. Die folgenden Aussagen beziehen sich auf diese Version, wobei der Begriff ``JET'' synonym zu JET2 verwendet wird. \mycite{M2T}

\JET\ folgt bei der Codegenerierung einer Kombination von zwei Ansätzen: dem Template-basierten Ansatz und dem Ansatz der Generierung von Code mittels einer Programmiersprache. Der Entwickler erstellt dabei zunächst Templates. Aus diesen Templates werden dann durch JET Java-Klassen erzeugt. Diese Java-Klassen dienen der Erzeugung des zu generierenden Quelltextes. In Anhang \ref{anhang_jet_ansatz} befindet sich ein JET-Template und die dafür generierte Java-Klasse. \mycite{JETTutorial}

Ein Modell muss, um von JET verarbeitet werden zu können, im XML-Format vorliegen. Dies schließt auch EMF-Modelle ein. Bei der Verarbeitung kann dann aus dem Modell beliebiger Text erzeugt werden. \JET\ verwendet dabei, auf Grund des XML-Formats der Modelle, \gls{glos:XPath}, um Informationen aus einem Modell zu erhalten. \mycite{JETDevX}

\par
Ein \JET -Template besteht aus statischem Text und Tags. Es gibt vier Arten von JET-Tags:  \newWord{Control-Tags}, \newWord{Format-Tags}, \newWord{Java-Tags} und \newWord{Workspace-Tags}. Control-Tags dienen dem Zugriff auf die Informationen des Ausgangsmodells und kontrollieren die Ausführung des Templates. Das Tag \code{c:get} beispielsweise ist ein Control-Tag. Dieses Tag liest aus dem Ausgangsmodell einen Wert und schreibt diesen in den generierten Text. In Zeile 1 von Listing \ref{listing_jetTemplate1} wird beispielsweise ein \code{c:get}-Tag verwendet. Format-Tags wandeln Text nach vorgegebenen Regeln um. Das Format-Tag \code{f:formatNow} beispielsweise formatiert das aktuelle Datum und schreibt es in den generierten Text. Java-Tags sind spezielle Tags für die Generierung von Java-Quelltext. Workspace-Tags werden verwendet um Dateien zu erzeugen. Das Workspace-Tag \code{ws:copyFile} beispielsweise kopiert eine Datei. \mycite{JETHelp}

Listing \ref{listing_jetTemplate1} zeigt ein JET-Template, das eine Java-Klasse mit einer \code{main}-Methode erzeugt. Hierbei wird über das Tag \code{c:get} zunächst in Zeile 1  der Klassenname aus dem Modell ausgelesen. Der Ausdruck \code{/class/@name} greift dafür auf das Attribut \code{name} des XML-Elements \code{class} zu. Dieses Attribut enthält den Klassennamen. Im Anschluss wird der String, der durch die erzeugte Methode ausgegeben wird, in Zeile 3 ausgelesen. Dafür wird über den Ausdruck \code{/class/phrase} auf den Inhalt des XML-Elements \code{phrase} zugegriffen. Dieses Element muss sich unterhalb des XML-Elements \code{class} befinden. In Anhang \ref{anhang_jet} befindet sich ein Beispielmodell, das mit diesem Template verarbeitet werden kann und ein weiteres JET-Template, welches das Modell in eine Ruby-Klasse umwandelt. 
\vspace{5pt}
\lstdefinelanguage{Jet} 
{morekeywords={c,get,<,>,select,userRegion,initialCode}, 
sensitive=true
}
\begin{lstlisting}[frame=single, tabsize=3, label=listing_jetTemplate1, language=Jet, caption={Beispiel eines JET-Templates zur Erzeugung einer Java-Klasse, Quelle: \mycite{JETDevX}}]
public class <c:get select="/class/@name" /> {
	public static void main(String[] args) {
		System.out.println("<c:get select="/class/phrase" />");
	}
}
\end{lstlisting} 



\par
\JET\ nutzt für die Zusammenführung von handgeschriebenem und generiertem Text Protected Regions. Pro\-tec\-ted Re\-gions werden mit dem Control-Tag \code{c:userRegion} ausgezeichnet. Für die Erzeugung von initialem Text wird dabei das Tag \code{c:initialCode} verwendet, wie in Listing \ref{listing_jetPR} dargestellt. Hierbei ist zu beachten, dass der gesamte Text zwischen den Tags \code{<c:userRegion>} und \code{<c:initialCode>} beziehungsweise den entsprechenden schließenden Tags als Auszeichnung für die Protected Regions verwendet wird. Das bedeutet, dass in den generierten Quelltexten der Code, der zwischen \code{//BEGIN user code} und \code{//END user code} steht, nicht vom Codegenerator überschrieben wird. \mycite{JETFaqPR} 
\vspace{5pt}
\begin{lstlisting}[frame=single, tabsize=3, label=listing_jetPR, language=Jet, caption={Auszeichnung einer Protected Region in einem JET-Template, Quelle: \mycite{JETFaqPR}}]
<c:userRegion>//BEGIN user code<c:initialCode>
//todo insert your code here
</c:initialCode>//END user code</c:userRegion>
\end{lstlisting} 

\par
Speziell für die Generierung von Java-Quelltext kann \newWord{JMerge} für die erneute Codegenerierung verwendet werden. JMerge ist ein Werkzeug zum Zusammenführen von handgeschriebenem und generiertem Java-Quelltext. Es wurde im Rahmen von \EMF\ entwickelt \mycite{JETFaqJMerge}. JMerge ermöglicht es, Java-Elemente wie Klassen, Methoden oder Attribute als Protected Region auszuzeichnen. Die Auszeichnung erfolgt dabei über das Hinzufügen der Annotation \code{@generated} in einem JavaDoc-Kommentar \mycite{JETFaqUseJMerge}.


\subsection{openArchitectureWare}
\oAW\ ist ein MDD/MDA-Generator-Framework, das in Java implementiert ist. Es ermöglicht das Validieren und Transformieren von Modellen. Darüber hinaus erlaubt \oAW\ die Verwendung von unterschiedlichen Modellierungswerkzeugen zur Erzeugung des zu transformierenden Modells, wie beispielsweise EMF, GMF oder ein beliebiges UML-Werkzeug. \oAW\ kann dafür unter anderem EMF-Modelle, Modelle im XML-Format und UML-Modelle verarbeiten. \mycite{OAW}

\par
Für eine Transformation mit \oAW\ werden \newWord{Workflows} verwendet. Ein Workflow kontrolliert den Ablauf einer Transformation. Er legt dafür die Abschnitte eines Transformationsdurchlaufes fest, wie beispielsweise das Laden des Modells, die Modellvalidierung und die Transformation beziehungsweise Generierung. Für die Definition eines Workflows werden eine XML-Datei und eine Properties-Datei erstellt. \mycite{OAWDoc}

\par
\oAW\ arbeitet bei der Generierung mit Templates. Für die Definition der Templates wird dabei die Template-Sprache \newWord{Xpand} verwendet. Listing \ref{listing_oawTemplate} zeigt ein oAW-Template für ein EMF-Modell. Dieses Template generiert für jedes Modellelement \code{entity} eine Klasse. Für die Modellelemente \code{attribute} werden dabei private Felder erzeugt. \mycite{OAWDoc}
\vspace{5pt}
\lstdefinelanguage{oAW} 
{morekeywords={DEFINE, FOR, EXPAND, FOREACH, AS, ENDDEFINE, FILE, ENDFOREACH, ENDFILE}, 
sensitive=true,
moredelim=*[s][]{«}{»}
}
\begin{lstlisting}[frame=single, tabsize=3, label=listing_oawTemplate, language=oAW, caption={Beispiel eines oAW-Templates zur Erzeugung von Java-Klassen, Quelle: \mycite{OAWDoc}}]
«DEFINE Root FOR data::DataModel»
  «EXPAND Entity FOREACH entity»
«ENDDEFINE»

«DEFINE Entity FOR data::Entity»
	«FILE name + ".java"»
		public class «name» {
			«FOREACH attribute AS a»
				private «a.type» «a.name»;
			«ENDFOREACH»
		}
	«ENDFILE»
«ENDDEFINE» 
\end{lstlisting} 

Für die Validierung eines Modells stellt \oAW\ die Sprache \newWord{Check} bereit. Mittels Check können Constraints formuliert werden. Listing \ref{listing_oawCheck} zeigt ein mit Check formulierten Constraint. Dieser Constraint prüft, ob der Wert des Attributs \code{name} für jedes Modellelement \code{Attribute} länger als 1 Zeichen ist. Ist dies nicht der Fall, wird eine Fehlermeldung mit dem Text, der in Zeile 2 festgelegt ist, ausgegeben. \mycite{OAWDoc}
\lstdefinelanguage{check} 
{morekeywords={context, Attribute}, 
sensitive=true,
string=[b]"
}
\begin{lstlisting}[frame=single, tabsize=3, label=listing_oawCheck, language=check, caption={Beispiel eines Constraints, formuliert mit Check, Quelle: \mycite{OAWDoc}}]
context Attribute ERROR
	"Names have to be more than one character long." :
	name.length > 1;
\end{lstlisting} 

\subsection{AndroMDA}
\gls{glos:andromda} ist ein weiteres Open-Source-Generator-Framework. Es ist konzipiert für die Verwendung innerhalb des \MDA -Entwicklungsprozesses. AndroMDA kann dabei Modelle verarbeiten, deren Metametamodell die \MOF\ ist, beispielsweise UML-Modelle. Die Modelle können mittels AndroMDA validiert und transformiert werden. Die dafür erforderlichen Modell-zu-Modell-Transformationen können vom Entwickler in Java geschrieben werden. Für die Modell-zu-Code-Transformation stellt AndroMDA mehrere Cartridges zur Verfügung, beispielsweise für Hibernate oder EJB. Darüber hinaus kann AndroMDA durch eigene Cartridges erweitert werden. Abbildung \ref{img_androMDA} zeigt schematisch die Funktionsweise von AndroMDA. \mycite{AndroMDA_whatIs}

\begin{figure}[h]
\centering
\includegraphics[width=0.55\textwidth]{images/AndroMDA.jpg} 
\caption{AndroMDA, Quelle: \mycite{AndroMDA}}
\label{img_androMDA}
\end{figure}

\par
Cartridges arbeiten bei AndroMDA Template-basiert. Standardmäßig wird dabei die Template-Engine \newWord{Velocity} verwendet. Velocity ist eine Open-Source-Template-Engine und ist implementiert in Java\footnote{Mehr Informationen zu Velocity siehe http://velocity.apache.org/}. AndroMDA ermöglicht es jedoch auch, Velocity durch eine andere Template-Engine zu ersetzten. \mycite[Kap. 5.3]{Petrasch06}

