\chapter{Modellgetriebene Softwareentwicklung} \label{chap_mdd} Thema dieser Diplomarbeit ist die modellgetriebene Softwareentwicklung. Hierbei wird aus Modellen automatisch Software erzeugt. Laut Brockhaus ist ein Modell \textquote[\cite{Brockhaus}, S. 588]{ein vereinfachtes Abbild der Wirklichkeit}. Unter der ``Wirklichkeit'' wird im Rahmen der modellgetriebenen Softwareentwicklung dabei ein System verstanden. Dieses System besteht aus Hardware- und Software-Komponenten. Abbildung \ref{img_mdd} zeigt das Prinzip der \mddn. \begin{figure}[h] \centering \includegraphics[width=0.7\textwidth]{images/mdsd.png} \caption{Modellgetriebene Softwareentwicklung} \label{img_mdd} \end{figure} \par Ziele der modellgetriebenen Softwareentwicklung sind die Steigerung der Softwarequalität und die Steigerung der Effizienz bei der Entwicklung von Software. Dies soll mittels des Prinzips der \newWord{Abstraktion} erreicht werden. Abstraktion ist \textquote[\cite{Petrasch06}, S. 45]{das Weglassen von irrelevanten Details}. Für die \mdd\ bedeutet dies, dass auf einer höheren Abstraktionsebene programmiert wird als es bei der Programmierung mit einer \newWord{höheren Programmiersprache} möglich ist. \mycite[Kap. 2.2]{Stahl07} \par Unter einer höheren Programmiersprache (\newWord{Hochsprache}) wird hier eine Programmiersprache verstanden, \textquote[\cite{Brockhaus}, S. 731]{deren Programme unabhängig von Prozessoreigenschaften formuliert \textnormal{[...]} werden können. Programme in höheren \textnormal{[Pro\-gram\-mier-]} Sprachen werden vor der Ausführung in einen Maschinencode gleicher Bedeutung übersetzt.} Der Maschinencode, auch als \newWord{Maschinensprache} bezeichnet, ist dabei prozessorabhängig. Hochsprachen sind dagegen, da sie erst nach der Übersetzung in Maschinencode prozessorabhängige Eigenschaften beinhalten, prozessorunabhängig. Ein Programm, das in einer Hochsprache geschrieben ist, wird somit nur einmal erstellt. Mittels geeigneter Übersetzer wird es dann für die unterschiedlichen Prozessoren in Maschinencode überführt. Ein Programm, das in Maschinensprache geschrieben ist, muss dagegen für jeden Prozessor neu entwickelt werden. Hochsprachen stehen daher, da bei ihrer Verwendung die prozessorabhängigen Details weggelassen werden, auf einer höheren Abstraktionsebene als Maschinencode. Des Weiteren ist der Quelltext eines in einer Hochsprache geschriebenen Computerprogramms leichter lesbar als ein Quelltext, der in Maschinencode geschrieben ist. Dies ist darin begründet, dass Hochsprachen der natürlichen Sprache ähnlicher sind als Maschinencode. Die Entwicklung eines Computerprogramms mittels einer Hochsprache ist daher einfacher als die Entwicklung eines Computerprogramms in Maschinensprache. \mycite[S. 730f.]{Brockhaus} \par Hochsprachen wie Java oder C\# abstrahieren darüber hinaus von einem konkreten Betriebssystem. Bei der Programmierung mit Java beispielsweise wird durch den \newWord{Java \gls{glos:compiler}} aus dem Quelltext \newWord{Java \gls{glos:bytecode}} erzeugt. Unter Bytecode wird hier \textquote[\cite{Brockhaus}, S. 143]{die Kodierung eines Computerprogramms \textnormal{[\ldots]} in einer abstrakten, prozessorunabhängigen Form \textnormal{[\ldots]}} verstanden. Der Java Bytecode wird bei der Ausführung des Programms durch die \newWord{\gls{glos:jvm}} interpretiert. Dasselbe Java-Programm kann somit, wenn die Java Virtual Machine installiert ist, auf verschiedenen Betriebssystemen ausgeführt werden. \mycite[S. 486f.]{Brockhaus} \par \begin{floatingfigure}[v]{4cm} \includegraphics[width=3.4cm]{images/abstraktion.png} \caption{Abs\-trak\-tions\-stu\-fen} \label{img_abstraktion} \end{floatingfigure} Bei der modellgetriebenen Softwareentwicklung wird, wie in Abbildung \ref{img_abstraktion} dargestellt, durch das Modell von der konkreten (höheren) Programmiersprache abstrahiert. Im Modell werden dazu implementierungsspezifische Details weggelassen. Der Entwickler konzentriert sich auf die Funktionalität der zu entwickelnden Anwendung \mycite{MDD03}. Die Software kann somit \newWord{\gls{glos:plattformunabhängig}} entwickelt werden. Plattformunabhängig bedeutet in diesem Zusammenhang, dass die Anwendungslogik weder auf eine Programmiersprache oder ein Framework, noch auf ein bestimmtes Betriebssystem festgelegt ist. Des Weiteren werden Routinearbeiten bei der Implementierung dem Entwickler abgenommen und automatisch ausgeführt. Es können beispielsweise automatisch Tests für die Software generiert werden. Dies kann zu einer Zeitersparnis gegenüber der Softwareentwicklung ohne modellgetriebenen Ansatz führen. Darüber hinaus werden Fehler minimiert, da nur getesteter und dokumentierter Quellcode automatisch erzeugt wird \mycite[Kap. 2.2]{Stahl07}. \par In diesem Kapitel werden zunächst die relevanten Begriffe und Konzepte der modellgetriebenen Softwareentwicklung erläutert. Im Anschluss wird auf \useacronym{MDA}, eine spezielle Ausprägung von modellgetriebener Softwareentwicklung eingegangen. \section{Model Driven Development} \label{MDD} Modellgetriebene Softwareentwicklung wird als \useacronym{MDD} oder \useacronym{MDSD} bezeichnet. \mycite[S. 12]{Tromp07} \begin{displayquote} \textquote[\cite{Stahl07}, S. 11]{Modellgetriebene Softwareentwicklung (Model Driven Software Development, MDSD) ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen.} \end{displayquote} Zunächst muss für das Verständnis dieser Definition geklärt werden, was ein \newWord{Modell} ist. Im Anschluss daran werden die Konzepte der Erstellung von Modellen, der sogenannten \newWord{Modellierung}, erläutert. Schließlich wird die Erzeugung von lauffähiger Software aus einem Modell dargestellt. Dieser Prozess wird als \newWord{Generierung} bezeichnet. \section{Modell} \textquote[\cite{Petrasch06}, S. 42]{Ein \gls{glos:modell} stellt ein Abbild eines realen oder abstrakten Systems dar \textnormal{[\ldots]}.} Im Rahmen dieser Diplomarbeit wird die Software-Komponente dieses Systems betrachtet. Im Folgenden werden dabei die Begriffe ``System'' oder ``Software'' für die Software-Komponente synonym verwendet. Ein Modell wird hier als Vorbild aufgefasst, das der Beschreibung des Systems dient \mycite{erkenntnis}. Die Problematik der unterschiedlichen Auffassungen des Modellbegriffs bezüglich der Rolle des Modells als Vor- oder Nachbild eines Systems wird von Schefe \mycite{erkenntnis} ausführlich diskutiert. Modelle gibt es in unterschiedlichen Ausprägungen. Ein Modell kann beispielsweise eine Skizze sein, ein UML-Diagramm oder es kann in textueller Form vorliegen. Es kann menschen- und/oder maschinenlesbar sein. \mycite[Kap. 2.2]{Petrasch06} \par Für die modellgetriebene Softwareentwicklung muss ein Modell \newWord{\gls{glos:formal}} sein. ``Formal'' bedeutet, dass sich das Modell an ein Regelwerk hält, \textquote[\cite{Petrasch06}, S. 42]{das mathematisch exakt, widerspruchsfrei und vollständig definiert} ist. Ein formales Modell beschreibt einen Teil einer Software vollständig. Dieser Teil kann technisch oder fachlich sein. Ein technischer Teil wäre beispielsweise die Architektur der Software. Ein fachlicher Teil bezieht sich hingegen auf die Fachlogik der Anwendung. \mycite[Kap. 2.1]{Stahl07} \par Zweck eines Modells ist bei der \mddn\ nicht nur die Dokumentation und Beschreibung der Software. Aus einem Modell wird hierbei auch automatisch die ausführbare Anwendung erzeugt \mycite[Kap. 1.3]{Tromp07}. Darüber hinaus ist das Ziel bei der Erstellung eines Modells, die Komplexität des Modells gegenüber der Komplexität der Software zu reduzieren, um deren Entwicklung zu vereinfachen. Eigenschaften, die nicht zu dem durch das Modell abgebildeten Teil der Software gehören, werden dafür weggelassen \mycite[Kap. 2.2]{Petrasch06}. \par Im Zusammenhang mit dem Modellbegriff stehen weitere Begriffe, die in Abbildung \ref{img_begriffe} dargestellt sind. Im Folgenden werden diese Begriffe erläutert. \begin{figure}[H] \centering \includegraphics[width=0.92\textwidth]{images/begriffe_mdd.png} \caption{Begriffe der MDD, Quelle: \mycite[S. 28]{Stahl07}} \label{img_begriffe} \end{figure} \subsection{Domäne} Eine \newWord{\gls{glos:domäne}} ist ein begrenztes Wissens- oder Interessengebiet. Sie kann technisch oder fachlich sein. Eine technische Domäne bezieht sich auf den technischen Teil einer Software. Eine fachliche Domäne bezieht sich auf den fachlichen Teil einer Software. Eine Domäne kann aus Subdomänen bestehen. Eine Subdomäne ist eine Teilmenge der Domäne. Subdomänen sind beispielsweise sinnvoll für den Umgang mit sehr komplexen Domänen, um die Überschaubarkeit der Domäne zu gewährleisten. \mycite[Kap. 3.1]{Stahl07} \subsection{Domänenspezifische Sprachen} Eine \newWord{domänenspezifische Sprache} wird als \useacronym{DSL} bezeichnet. Sie ist eine speziell auf eine Domäne abgestimmte Sprache \mycite[Kap. 3.1]{Stahl07}. Die Sprachelemente der \DSL\ werden von Mensch und Maschine verstanden. Des Weiteren wird mittels der \DSL\ ein formales Modell erstellt. Der Mensch kann somit den Sachverhalt einer Domäne maschinenverständlich abbilden \mycite[Kap. 3.6]{Tromp07}. Im Wesentlichen umfasst eine \acrsh{DSL} ein \newWord{\gls{glos:mm}} sowie eine \newWord{\useGlosentry{glos:abstSyn}{abstrakte}} und eine \newWord{\useGlosentry{glos:konkrSyn}{konkrete Syntax}}. Das Metamodell und die abstrakte Syntax dienen hierbei der Abbildung der Struktur der durch die DSL beschriebenen Domäne. Die konkrete Syntax hingegen legt die Art der Darstellung der DSL fest. \mycite[Kap. 3.1]{Stahl07}. \subsection{Metamodell} \label{metamodell} Ein Metamodell macht Aussagen über die mögliche Struktur eines Modells. Es ist die formale Beschreibung einer Domäne \mycite[Kap. 3.1]{Stahl07}. Die Vorsilbe ``meta'' bedeutet hier soviel wie ``über'' oder ``übergeordnet''. Die einzelnen Elemente eines Modells sind dabei Instanzen der Modell\-elemente des Metamodells. Das heißt, das Metamodell steht auf einer höheren Ebene als das Modell \mycite[Kap. 2.2]{Petrasch06}. Zur Veranschaulichung der Beziehung zwischen Domäne, Modell und Metamodell siehe Abbildung \ref{img_metamodell}. \begin{figure}[h] \centering \includegraphics[width=0.8\textwidth]{images/metamodell.png} \caption{(Meta-)Modellebenen, Quelle: angelehnt an \mycite[S. 60]{Stahl07} und \mycite[S. 49]{Petrasch06}} \label{img_metamodell} \end{figure} Neben dem Metamodell gibt es das \newWord{\gls{glos:dm}}. Im Rahmen der UML definiert Larman den Begriff ``Domänenmodell'' wie folgt: \begin{displayquote} \textquote[\cite{domainModel}, Kap. 10.1]{A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest.} \end{displayquote} Darüber hinaus bildet ein Domänenmodell die Beziehungen der Elemente der Domäne untereinander ab. Das Domänenmodell beschreibt also ähnlich wie das Metamodell die Domäne einer Anwendung. \par In der Literatur zur \mddn\ wird das Verhältnis beziehungsweise der Unterschied zwischen Metamodell und Domänenmodell nicht definiert. Im Rahmen dieser Diplomarbeit wird das Domänenmodell als die Beschreibung der Domäne entsprechend der Definition von Larman aufgefasst. Des Weiteren wird davon ausgegangen, dass das Metamodell auf Basis des Domänenmodells durch ein geeignetes Werkzeug im Kontext der \mddn\ erstellt wird. Dabei weist es die oben beschriebenen Eigenschaften auf. \subsection{Metametamodell} Ein \newWord{\gls{glos:mmm}} ist das Metamodell eines Metamodells. Die Modellelemente des Metamodells sind also Instanzen der Modellelemente des Metametamodells. In der Theorie kann es beliebig viele Meta-Ebenen für ein Modell geben. In der Praxis sind drei Ebenen in den meisten Fällen ausreichend: Modell, Metamodell und Metametamodell. Das Metametamodell beschreibt sich dabei meist selbst. Ein weit verbreitetes Metametamodell ist die \useacronym{MOF}, ein Standard der \useacronym{OMG}. \mycite[Kap. 3.1]{Stahl07} Die Bezeichnungen ``Metamodell'' und ``Metametamodell'' sind nicht absolut. Ein Metametamodell bezogen auf ein Modell ist gleichzeitig das Metamodell des Metamodells des Modells. Das Metamodell des Modells wiederum ist selbst ein Modell bezogen auf das Metametamodell. Die \acrsh{MOF} beispielsweise ist unter anderem das Metamodell der \useacronym{UML} und das Metametamodell der Modelle, die mittels der UML erstellt werden. \mycite[Kap. 5.1]{Stahl07} \subsection{Abstrakte und konkrete Syntax} Eine \useacronym{DSL} hat zwei Syntaxen. Die abstrakte Syntax und die konkrete Syntax. Die abstrakte Syntax beschreibt die Metamodellelemente und ihre Beziehungen untereinander \mycite[Kap. 3.1]{Stahl07}. Allgemeiner ausgedrückt definiert die abstrakte Syntax die syntaktischen Elemente, zum Beispiel Buchstaben, und legt fest, wie daraus Konstrukte, zum Beispiel Wörter, gebildet werden. Ein Konstrukt ist dabei eine Kombination von syntaktischen Elementen. \mycite[Kap. 1.3]{Petrasch06}. Die abstrakte Syntax der Programmiersprache Java beispielsweise legt fest, dass es Klassen gibt, die einen Namen haben und die Methoden haben können. \mycite[Kap. 3.1]{Stahl07}. \par Die konkrete Syntax hingegen legt fest, wie ein Modell oder allgemein gesagt ein Konstrukt konkret beschrieben wird. Sie legt die \textquote[\cite{Petrasch06}, S. 19]{Ausdrucksmittel (Darstellungsform, Notation)} der \DSL\ fest. Für die Programmiersprache Java legt die konkrete Syntax beispielsweise fest, dass eine Klasse mit dem Schlüsselwort ``class'' beginnt. Des Weiteren definiert sie, dass die Implementierung eines Interface durch eine Klasse mittels des Schlüsselworts ``implements'' gekennzeichnet ist. \mycite[Kap. 3.1]{Stahl07} Eine konkrete Syntax kann graphisch oder textuell sein. Ein Beispiel für eine graphische konkrete Syntax ist die UML-Notation. Eine textuelle konkrete Syntax ist die Notation in XML. Entsprechend der Art der konkreten Syntax wird ein Parser benötigt. Dieser liest ein Modell ein und wandelt es hinsichtlich der abstrakten Syntax in ein anderes Format um. Das andere Format dient dabei der Verarbeitung des Modells. Der Parser kann beispielsweise ein Modell, das mit XML als konkreter Syntax erstellt wurde, auf miteinander verbundene Java-Objekte abbilden. Die abstrakte Syntax würde hierbei unter anderem durch die entsprechenden Java-Klassen beschrieben werden. \mycite[Kap. 3.1]{Stahl07} Petrasch et al. machen darüber hinaus die folgende Aussage zur konkreten und abstrakten Syntax. \begin{displayquote} \textquote[\cite{Petrasch06}, S. 50]{Modelle und Metamodelle können dieselbe konkrete Syntax verwenden, besitzen jedoch eine unterschiedliche abstrakte Syntax bzw. Semantik.} \end{displayquote} Diese Aussage berücksichtigt jedoch nicht den Fall, dass ein Modell sich selbst beschreibt. Die MOF beispielsweise ist, da sie sich selbst beschreibt, ihr eigenes Metamodell. Modell und Metamodell haben in diesem Fall daher dieselbe konkrete Syntax und dieselbe abstrakte Syntax. \subsection{Statische und dynamische Semantik} Die \newWord{\useGlosentry{glos:statSem}{statische Semantik}} legt die Bedingungen fest, die ein Modell erfüllen muss, um \gls{glos:wohlgeformt} zu sein. Ein Modell, das wohlgeformt ist, wird auch als \useGlosentry{glos:wohlgeformt}{valide} bezeichnet. Die Bedingungen der statischen Semantik werden \newWord{\gls{glos:Constraints}} genannt \mycite[Kap. 3.1]{Stahl07}. Allgemein gesagt, legt die statische Semantik fest, wie ein Konstrukt mit einem anderen verbunden ist, um eine Bedeutung zu erhalten. Die statische Semantik der booleschen Algebra beispielsweise legt fest, dass ein boolescher Ausdruck der Form ``boolescher Wert, boolescher Operator, boolescher Wert'' einen booleschen Wert zurückliefert \mycite[Kap. 1.3]{Petrasch06}. Bei statisch getypten Programmiersprachen sind die Bedingungen, die vom Compiler geprüft werden, die statische Semantik. Diese legen beispielsweise fest, dass Variablen deklariert sein müssen \mycite[Kap. 3.1]{Stahl07}. \par Die \newWord{\useGlosentry{glos:dynSem}{dynamische Semantik}} hingegen legt die erlaubten Ausführungen des durch die statische Semantik definierten Konstrukts fest. Nur wenn ein Konstrukt wohlgeformt ist, definiert die dynamische Semantik dabei eine Bedeutung. Die dynamische Semantik legt beispielsweise fest, dass ein boolescher Ausdruck der Form ``boolescher Wert, boolescher Operator, boolescher Wert'' bezogen auf den UND-Operator nur dann zu ``true'' evaluiert, wenn beide booleschen Werte ``true'' sind, sonst evaluiert er zu ``false'' \mycite[Kap. 1.3]{Petrasch06}. Wird bei der Programmierung gegen die dynamische Semantik verstoßen, wird dies erst zur Laufzeit erkannt. Das folgende Beispiel verdeutlicht dies. \begin{lstlisting}[frame=single, numbers=left, caption={Dynamische Semantik, Quelle: angelehnt an (\cite{WebFehlerKlassif}, Kap. 10.1.3})] float i = x; i = i - 1; i = 1/i; \end{lstlisting} Die potentielle Division durch Null wird erst zur Laufzeit erkannt. Da eine Division durch Null gegen die dynamische Semantik verstößt, kommt es für den Fall, dass x den Wert 1 hat, zu einem Fehler. \mycite{WebFehlerKlassif} \section{Modellierung} Bei der Anwendung des Ansatzes der \mddn\ muss, da die Elemente eines Modells Instanzen der Elemente des Metamodells sind, mit der Definition des Metamodells begonnen werden. Das Metamodell bildet die Grundlage für die Modellierung. Die Schwierigkeit bei der Definition des Metamodells besteht darin, es vollständig zu definieren. Die Vollständigkeit des Metamodells ist für die Modellierung von Bedeutung, da ein Modell die gesamten relevanten Eigenschaften des abzubildenden Teils eines Systems umfassen können muss. Zu diesem Zweck sollten mehrere konkrete Szenarien bezüglich der Eigenschaften des Systems vor und während der Erstellung des Metamodells durchdacht werden. \mycite[Kap. 5.5]{Stahl07} Ein Metamodell, das alle relevanten Eigenschaften eines Systems beschreibt, kann sehr umfangreich und dadurch sehr unübersichtlich werden. Es bietet sich daher an, ein solches Metamodell auf mehrere Metamodelle aufzuteilen. Der Bereich, den jedes Metamodell dabei beschreibt, ist eindeutig abgegrenzt. Es kann beispielsweise ein Metamodell geben, das die Geschäftslogik der einen Komponente des Systems abbildet und ein zweites, das die Geschäftslogik einer anderen Komponente beschreibt. Das Metamodell des gesamten Systems besteht dann aus einer Reihe von einzelnen Metamodellen. Ein solches Metamodell wird als \newWord{\useGlosentry{glos:modmm}{modulares Metamodell}} bezeichnet. \mycite[Kap. 5.3]{Stahl07} \par Für die Erstellung von Modellen auf Basis des Metamodells wird eine konkrete Syntax benötigt. Die konkrete Syntax ist für die Verarbeitung eines Modells, zum Beispiel bei der Generierung, weitgehend irrelevant. Sie ist jedoch die Schnittstelle zum Modellierer. Ihre Qualität ist damit entscheidend für die Lesbarkeit eines Modells. Es ist dabei durchaus möglich, dass es mehrere konkrete Syntaxen, zum Beispiel eine graphische und eine textuelle, für ein Modell gibt. \mycite[Kap. 5.1]{Stahl07} \subsection{Modellvalidierung} Bei der Modellierung besonders von komplexen Modellen kommt es häufig zu \newWord{\useGlosentry{glos:modfehler}{Modellierungsfehlern}}. Modellierungsfehler sind Verstöße gegen die abstrakte Syntax oder gegen die durch die statische Semantik festgelegten \gls{glos:Constraints}. Je später diese Verstöße erkannt werden, desto höher ist in der Regel der Aufwand sie zu beheben \mycite[Kap. 3.7]{Tromp07}. Teil der modellgetriebenen Softwareentwicklung ist daher die \newWord{\gls{glos:validierung}} (\newWord{Validierung}). Bei der Modellvalidierung wird geprüft, ob die abstrakte Syntax und die Constraints vom Modell eingehalten werden. Die Software oder der Teil der Software, der die Validierung durchführt, wird dabei als \newWord{\gls{glos:validator}} bezeichnet. \mycite[Kap. 5.1]{Stahl07}. \par Das Zusammenspiel von Modellierung und Validierung ist ein iterativer Prozess. Durch die Validierung entdeckte Fehler werden durch erneute Modellierung behoben \mycite[Kap. 3.7]{Tromp07}. Abbildung \ref{img_validierung} verdeutlicht den Modellierungs- und Validierungsprozess. \begin{figure}[h] \centering \includegraphics[width=0.6\textwidth]{images/validierung.png} \caption{Modellierung und Validierung, Quelle: \mycite[S. 67]{Tromp07}} \label{img_validierung} \end{figure} Bei der Generierung wird meistens vorausgesetzt, dass das Modell \useGlosentry{glos:wohlgeformt}{valide} ist. Ist das Modell nicht valide, kann es zur Generierung von fehlerhaftem Quelltext kommen. Die Modellvalidierung sollte daher mindestens direkt vor der Generierung ausgeführt werden. Darüber hinaus kann die Validierung beispielsweise während der Eingabe des Modells stattfinden. Der Zeitpunkt der Eingabe ist der frühestmögliche Zeitpunkt für die Validierung. Sie wird dabei vom Editor durchgeführt. Diese Technik der ``Validierung während der Eingabe'' ist weit verbreitet und in den meisten modernen integrierten Entwicklungsumgebungen, den sogenannten \newWord{\IDElong s} (\unsetacronym{IDE}\IDE), umgesetzt. Bei der Validierung im Editor und bei der Validierung direkt vor der Codegenerierung sollte auf die gleiche Implementierung der Constraints zurückgegriffen werden, um die Konsistenz in der Validierung zu gewährleisten. \mycite[Kap. 5.1]{Stahl07} %\newpage \subsection{Konzepte von domänenspezifischen Sprachen} Domänenspezifische Sprachen können nach unterschiedlichen Kriterien kategorisiert werden. Sie können in interne und externe \acrsh{DSL}s oder in graphische und textuelle \acrsh{DSL}s eingeteilt werden. Die Wahl der DSL und damit der konkreten Syntax ist von Bedeutung, da von ihr unter anderem die Wahl des Modellierungswerkzeugs und die Lesbarkeit des Modells abhängen. \mycite[Kap. 6]{Stahl07} Martin Fowler hat die Begriffe der \newWord{internen \acrsh{DSL}}, auch \newWord{embedded \acrsh{DSL}}, und \newWord{externen \acrsh{DSL}} geprägt \mycite{FowlerDSL}. Eine interne \acrsh{DSL} ist eine \acrsh{DSL}, die in eine andere Programmiersprache, die sogenannte \newWord{Hostsprache}, eingebettet ist, daher der Begriff der embedded \acrsh{DSL}. Die Hostsprache ist meist eine dynamisch getypte Sprache wie zum Beispiel \newWord{\gls{glos:Ruby}}. Hierbei werden beispielsweise neue Sprachkonstrukte mit den Mitteln der Hostsprache definiert. Mit diesen kann dann domänenspezifisch programmiert werden. Eine externe \acrsh{DSL} wird dagegen von Grund auf neu konzipiert. Für sie wird ein spezieller Parser benötigt, der die Information der \acrsh{DSL} einliest und zur Generierung bereitstellt. \mycite[Kap. 6.1]{Stahl07} \par Eine interne \acrsh{DSL} hat verschiedene Nachteile. Zum einen kann eine interne \acrsh{DSL} immer nur eine textuelle konkrete Syntax haben. Des Weiteren ist die Entwicklung spezieller Modellierungswerkzeuge für die \acrsh{DSL} mit hohem Aufwand verbunden, da die DSL nur durch die Hostsprache begrenzt wird. Insbesondere bei der Verwendung einer dynamisch getypten Programmiersprache ist darüber hinaus die Entwicklung eines statischen Validators für die DSL schwer möglich, da dabei die Typzuweisung einer Variablen erst zur Laufzeit geschieht. Modellierungsfehler werden somit erst spät oder gar nicht erkannt \mycite[Kap. 6.1]{Stahl07}. Ein weiterer Nachteil ist, dass dem Entwickler, der mit der \acrsh{DSL} ein Modell erstellen möchte, mehr Möglichkeiten zur Verfügung stehen als für die Modellierung gebraucht werden. Dies erschwert die Modellierung besonders dann, wenn der Entwickler die Hostsprache nicht beherrscht. Vorteil einer internen \acrsh{DSL} ist, dass ein Entwickler, der die Hostsprache dagegen gut kennt, die volle Mächtigkeit der Hostsprache ausnutzen kann \mycite{FowlerDSL}. \par Nachteil externer \acrsh{DSL}s ist, dass der Editor und Parser für die \acrsh{DSL} zusätzlich zur \acrsh{DSL} entwickelt werden muss. Darin liegt jedoch auch gleichzeitig der Vorteil. Es kann beispielsweise ein graphischer Editor für die DSL entwickelt werden. Des Weiteren kann ein solcher Editor so implementiert werden, dass er im Gegensatz zu einem Editor einer internen DSL nur die Funktionalität bereitstellt, die zur Erstellung des Modells benötigt wird. \mycite{FowlerDSL} Ein ausführlicher Vergleich von internen und externen DSLs findet sich bei Fowler in dem Abschnitt ``Pros and Cons of language oriented programming'' \mycite{FowlerDSL}. Ein Beispiel für die Entwicklung einer internen DSL unter Verwendung von Ruby findet sich bei Cuadrado et al. \mycite{DSL07}. \par Eine weitere Kategorisierung von \DSL s ist deren Unterteilung in graphische und textuelle \acrsh{DSL}s. Eine graphische DSL besitzt eine graphische konkrete Syntax. Bei Modellen mit einer graphischen \acrsh{DSL} werden die Modellelemente graphisch dargestellt. Solche Modelle geben meist einen guten Überblick über ihre Struktur. Sie sind damit in der Regel als Diskussionsgrundlage gut geeignet. Dabei muss jedoch beachtet werden, nicht zu viele Elemente oder Konzepte im Modell abzubilden, um die Übersichtlichkeit beizubehalten. Textuelle \acrsh{DSL}s besitzen eine textuelle konkrete Syntax. Modelle mit einer textuellen DSL sind in der Regel weniger übersichtlich als Modelle mit einer graphischen DSL. Dies kann durch entsprechende Hilfsmittel des benutzten Editors, wie zum Beispiel Syntax-Highlighting, verbessert werden. Als Diskussionsgrundlage sind sie jedoch in der Regel ungeeignet. \mycite[Kap. 6.1]{Stahl07} \section{Transformation} Bei einer Transformation wird \textquote[\cite{Stahl07}, S. 33]{aus einem formalen Modell etwas anderes erzeugt}. Durch die Transformation kann Text erzeugt werden wie zum Beispiel Quelltext oder Dokumentationsdateien, oder es kann ein weiteres Modell erzeugt werden. Wird aus einem Modell Text erzeugt, spricht man von einer \MTC. Wird aus einem Modell ein Modell erzeugt, wird dies \MTM\ genannt. \mycite[Kap. 3.1]{Stahl07} Für die Durchführung einer Transformation wird eine spezielle Software benötigt. Diese wird als \newWord{Codegenerator} oder \newWord{\gls{glos:generator}} bezeichnet. Ein Generator liest ein oder mehrere Modelle ein, validiert sie gegebenenfalls und führt dann eine oder mehrere Transformationen durch. Dieser Vorgang wird \newWord{\gls{glos:genprozess}} oder \newWord{Transformationsprozess} genannt. Hierfür muss ein Generator die folgenden drei grundlegenden Funktionen unterstützen. \begin{itemize} \item Er ermöglichst das Schreiben von Text in Dateien. \item Er ermöglichst die Abfrage von Werten aus einem eingegebenen Modell. \item Die \gls{glos:konkat} von statischem Text, das heißt statischen Informationen, und Informationen aus dem Modell wird unterstützt. \end{itemize} Ein Generator, der im Rahmen der \mddn\ angewandt wird, unterscheidet darüber hinaus zwischen zwei Arten von Informationen: variable Informationen und statische Informationen. Variable Informationen werden durch das Modell festgelegt und sind je nach Modell unterschiedlich. Statische Informationen werden durch das oder die zu verarbeitenden Modelle nicht beeinflusst. Sie sind die sogenannten \newWord{Generatorvorschriften}. Die Generatorvorschriften sind für die Modellierung irrelevant und werden erst bei der oder den Transformationen hinzugezogen \mycite[Kap. 8.3]{Stahl07}. Des Weiteren definieren Stahl et al. für einen Generator innerhalb der \mddn\ die folgenden Merkmale (siehe hierzu \mycite[S. 145]{Stahl07}): \begin{itemize} \item Die variablen Informationen (das Modell) sind von den statischen Informationen (die Generatorvorschriften) getrennt. \item Die Generatorvorschriften basieren auf dem Metamodell. %\item Aus einem Modell können beliebig viele Artefakte erzeugt werden. \item Der Generierungsprozess kann beliebig oft für ein Modell durchgeführt werden. \item Ein Generator kann für beliebig viele Modelle verwendet werden. Die Modelle müssen jedoch alle dem Metamodell entsprechen, auf dem die Generatorvorschriften basieren. \end{itemize} \subsection{Modell-zu-Code-Transformation} \label{codegenerierung} Bei der \MTC\ werden aus Modellen Quelltexte und weitere Dateien erzeugt. Diese weiteren Dateien sind in der Regel Dateien, die zur Ausführung der zu generierenden Software erforderlich sind. Sie können beispielsweise Konfigurationsdateien oder Datenbankskripte sein. Bei der \MTC\ können jedoch auch nicht zur Ausführung der Software notwendige Dateien, zum Beispiel Dokumentationsdateien, generiert werden. Die M2C"=Transformation wird daher auch als \newWord{Modell-zu-Text-Trans\-for\-ma\-tion} bezeichnet. Eine weitere Bezeichnung ist \newWord{Codegenerierung}, kurz \newWord{Generierung}. Diese setzt ebenso wie der Begriff ``\MTC '' den Schwerpunkt auf die Erzeugung von Quelltext. Die unterschiedlichen Bezeichnungen für die \MTC\ werden in der Literatur weitgehend synonym verwendet. Im Folgenden wird hauptsächlich der Begriff ``Codegenerierung'' beziehungsweise ``Generierung'' verwendet. Abbildung \ref{img_codegenerierung} zeigt eine schematische Darstellung der \MTC . \begin{figure}[h] \centering \includegraphics[width=0.7\textwidth]{images/codegeneration.png} \caption{Modell-zu-Code-Transformation} \label{img_codegenerierung} \end{figure} \par Der durch eine \MTC\ erzeugte Quelltext ist spezifisch für eine \newWord{\gls{glos:plattform}}. Unter einer Plattform werden hier zum einen die Hardware- und Software-Komponenten eines Rechners verstanden. Zum anderen umfasst der Begriff ``Plattform'' Programmbibliotheken und \gls{glos:Middleware} wie beispielsweise \gls{glos:J2EE} oder \unsetacronym{CORBA}\CORBA\ (\CORBAlong). Bei einer \MTC\ können beispielsweise Java-Klassen und spezielle Konfigurationsdateien erzeugt werden, die spezifisch für eine \gls{glos:J2EE}-Anwendung sind. Die Plattform, für die die Dateien erzeugt werden, wird dabei als \newWord{\gls{glos:zielplattform}} oder \newWord{Zielsystem} bezeichnet. \par Für die Codegenerierung gibt es unterschiedliche Techniken. Diese setzen unterschiedliche Schwerpunkte bezüglich beispielsweise der Konkatenation von statischem Text und Informationen aus dem Modell. Im Folgenden werden zwei mögliche Techniken der Codegenerierung vorgestellt. Zunächst wird die Codegenerierung mit Hilfe von Templates erläutert. Im Anschluss wird auf die Codegenerierung mittels einer Programmiersprache eingegangen. \par Die Codegenerierung mittels Templates ist sinnvoll, wenn viel statischer Text generiert werden soll. Der Generator verwendet hierbei eine \newWord{\gls{glos:templateengine}}. Eine Template-Engine ist eine Software, die Dateien anhand von Vorlagen, sogenannten \newWord{\useGlosentry{glos:template}{Templates}}, erstellt. Ein Template besteht aus beliebigem Text, der \newWord{\useGlosentry{glos:tag}{Tags}} beinhaltet. Ein Tag ist dabei ein Platzhalter in einer speziellen Notation, der während des Generierungsprozesses von der Template-Engine durch einen entsprechenden Wert ersetzt wird. Die Notation der Tags wird durch die \newWord{\gls{glos:templatesprache}} spezifiziert. Die Template-Sprache legt beispielsweise fest, wie ein Template aufgebaut ist oder wie ein Tag notiert wird. Ein Tag enthält einen Ausdruck, der durch die Template-Engine ausgewertet wird. Das Ergebnis der Auswertung wird an die Stelle des Tags gesetzt. Ein Ausdruck kann zum einen dazu dienen, Informationen aus dem Modell abzufragen. Zum anderen kann er den Ablauf der Verarbeitung des Templates durch die Template-Engine mittels Bedingungen oder Schleifen steuern. Er dient in diesem Fall als Kontrollstruktur. Mit Hilfe eines Tags, das eine solche Kontrollstruktur enthält, kann zum Beispiel eine Datei generiert werden, die eine Liste enthält, deren Länge durch das Modell festgelegt wird. Die Form eines Ausdrucks ist ebenso wie die Notation der Tags von der Template-Sprache abhängig. Template-Sprachen sind beispielsweise \JSP\ oder aus dem \unsetacronym{XML}\XML-Umfeld \unsetacronym{XSLT}\XSLT. Die Technik der Codegenerierung mittels Templates ist spezialisiert auf die Konkatenation von statischem Text und Modellinformationen. \mycite[Kap. 8.4.1]{Stahl07} \par Bei der Codegenerierung mittels einer Programmiersprache wird der Generator mit Hilfe einer Programmiersprache wie beispielsweise Java oder C\# entwickelt. Meistens werden dabei Klassen erstellt, die bestimmte Konzepte der \newWord{Zielsprache} repräsentieren. Unter Zielsprache wird hier die Programmiersprache, beispielsweise Java, oder Auszeichnungssprache, beispielsweise XML, verstanden, in der die zu generierenden Dateien verfasst sind. Bei dieser Art der Codegenerierung würde beispielsweise eine Klasse das Klassen-Konzept in Java repräsentieren. Eine solche Klasse befindet sich in Anhang \ref{anhang_javaClass_codegen}. Sie wäre für die Generierung von Java-Klassen verantwortlich. Diese Klasse enthielte zum Beispiel eine Methode, wie sie in Listing \ref{listing_JavaMethod} gezeigt wird. Diese Methode erzeugt den Quelltext für eine Java-Klasse, der bei der Codegenerierung in eine Datei geschrieben wird. \begin{lstlisting}[frame=single, label=listing_JavaMethod, language=Java, caption={Methode zur Erstellung von Java-Klassen, Quelle: (\cite{Stahl07}, S. 150})] public String toString() { String buff = "package " + packageName + ";\n" + "\n" + "public class " + name + " {\n"; /* ... */ return buff; } \end{lstlisting} Bei dieser Technik der Codegenerierung fließen die Eigenheiten der gewählten Programmiersprache in die Entwicklung des Generators mit ein, was unter Umständen zu Problemen führen kann. In Listing \ref{listing_JavaMethod} wird beispielsweise mit Strings in Java gearbeitet, was Nachteile mit sich bringt. Es gibt zum Beispiel in Java keine mehrzeiligen Strings. Zeilenumbrüche müssen in Java mit Escape-Sequenzen, beispielsweise ``\textbackslash n'', beschrieben werden. Des Weiteren können Strings im Quelltext nicht über mehrere Zeilen gehen, sie müssen mit ``+'' konkateniert werden. Diese Eigenschaften von Java machen den Quelltext, wenn viel statischer Text erzeugt wird, schnell unübersichtlich. Der Vorteil der Codegenerierung mittels einer Programmiersprache ist, dass die volle Unterstützung der meist sehr leistungsstarken IDEs, wie beispielsweise Syntax-Highlighting und Debugging-Funktionen, für die Entwicklung des Generators genutzt werden kann. \mycite[Kap. 8.4.2]{Stahl07} \subsection{Modell-zu-Modell-Transformation} \label{modell2modell} In der \textquote[\cite{Stahl07}, S. 196]{'klassischen' \MDSD} folgt nach der Modellierung und Validierung des Modells die Codegenerierung. Das bedeutet, dass es zwei Abstraktionsebenen gibt: die Ebene des Modells und die Ebene des Quelltextes. In den meisten Fällen ist dies ausreichend. Unter Umständen wird der Codegenerator bei diesem Ansatz jedoch sehr komplex, da er bei der Codegenerierung die gesamten Abstraktionen des Modells konkretisieren muss. Insbesondere bei Modellen, die sehr stark vom Code abstrahieren, kann die Erzeugung des Codes dabei sehr umfangreich sein. Dieses Problem soll durch das folgende Beispiel verdeutlicht werden. Für jedes Modellelement A soll eine entsprechende Klasse Ai erzeugt werden, wobei i einen Wert zwischen 1 und 9 einnimmt. Des Weiteren soll eine Klasse B generiert werden, die für jede Klasse Ai eine Methode zur Erzeugung dieser Klasse Ai besitzt. Diese Aufgaben können entweder durch den Modellierer gelöst werden oder durch den Codegenerator. Im ersten Fall würde der Modellierer zum einen in den Elementen des Modells, die vom Typ A sind, die Namen der zu generierenden Klassen angeben. Zum anderen würde er im Modell ein Element B erstellen und die erforderlichen Methoden hinzufügen. Würden die Aufgaben durch den Codegenerator gelöst werden, würde dieser entsprechend komplexer werden, da er um die dafür erforderliche Logik erweitert werden müsste. \mycite[Kap. 10.1]{Stahl07} Ein weiteres Problem besteht darin, dass bei der Generierung dasselbe Metamodell wie bei der Modellierung verwendet wird. Die für die Generierung notwendigen Konzepte müssen somit in das Metamodell mit aufgenommen werden, wodurch das Metamodell möglicherweise zu sehr ``aufgebläht'' wird. Das zuvor angeführte Beispiel verdeutlicht auch dieses Problem. Element B gehört unter Umständen zum technischen Teil der zu generierenden Software. Element A hingegen gehört zum fachlogischen Teil. Das Element B müsste in das Metamodell aufgenommen werden, um modelliert werden zu können. Dies sollte jedoch insbesondere im Hinblick auf die unterschiedlichen Aspekte der Software, die die Elemente beschreiben, vermieden werden. \mycite[Kap. 10.1]{Stahl07} Auf Grund dieser Probleme ist daher ein weiterer Schritt erforderlich, der in der Regel zwischen der Modellierung und der Codegenerierung liegt: die Modell-zu-Modell-Transformation. In diesem Schritt wird das Modell für die Codegenerierung ``aufbereitet''. Diese Aufbereitung ist eine Anreicherung des Modells mit zusätzlichen Informationen (die \newWord{Modellmodifikation}) oder die Überführung des Modells in ein anderes Modell (die \newWord{Modelltransformation}). \mycite[Kap. 10.1]{Stahl07} \par Bei der Modellmodifikation wird das Ausgangsmodell modifiziert. Das Ausgangsmodell ist das Modell, auf welches die Transformation angewandt wird. Abbildung \ref{img_mmodifikation} verdeutlicht diese Art der Modell-zu-Modell-Transformation. \begin{figure}[h] \centering \includegraphics[width=0.57\textwidth]{images/modellmodifikation.png} \caption{Modellmodifikation, Quelle: \mycite[S. 199]{Stahl07}} \label{img_mmodifikation} \end{figure} Das Modell wird dabei mit Informationen angereichert. Hierfür werden basierend auf den Metamodellelementen Regeln definiert, wie die Modellelemente mit Informationen anzureichern sind \mycite[Kap. 3.8.1]{Tromp07}. Das so entstandene Modell hat weiterhin dasselbe Metamodell wie das Ausgangsmodell. In der Abbildung ist dies durch die gleiche geometrische Form der Modellelemente beider Modelle dargestellt. Dem Ausgangsmodell werden neue Instanzen der Metamodellelemente hinzugefügt und bestehende verändert. In der Abbildung ist dies durch eine andere Färbung verdeutlicht \mycite[Kap. 10.2]{Stahl07}. Als einen Spezialfall der Modellmodifikation führen Stahl et al. das sogenannte \newWord{Modell-Weaving} (\newWord{Linking}) an. In manchen Fällen ist es notwendig, nicht alle Informationen in einem Modell zu speichern. Die Informationen sind dann auf mehrere Modelle verteilt. In diesem Fall müssen die Modelle vor der Codegenerierung miteinander in Verbindung gebracht werden. Dies wird als \newWord{verlinken} bezeichnet. Die Modellelemente des Ausgangsmodells werden dafür mit den Verlinkungen zu den Modellelementen des anderen Modells angereichert. Die Modelle, die miteinander verlinkt werden, müssen dabei nicht Instanzen desselben Metamodells sein. Abbildung \ref{img_mweaving} verdeutlicht das Modell-Weaving. Die Verlinkungen sind hierbei durch die gepunkteten Linien dargestellt. \mycite[Kap. 10.2]{Stahl07} \begin{figure}[h] \centering \includegraphics[width=0.8\textwidth]{images/modellweaving.png} \caption{Modell-Weaving, Quelle: \mycite[S. 200]{Stahl07}} \label{img_mweaving} \end{figure} Bei der Modelltransformation wird im Gegensatz zur Modellmodifikation das Ausgangsmodell nicht verändert. Es besteht außerdem die Möglichkeit, mehrere Ausgangsmodelle zu einem Modell zusammenzuführen. Diese Form der Transformation wird beispielsweise angewandt, wenn das Ausgangsmodell ein anderes Metamodell hat als das Modell, in das es transformiert werden soll. Abbildung \ref{img_mtransformation} zeigt diese Form der Modell-zu-Modell-Transformation. Die verschiedenen Metamodelle werden dabei durch die unterschiedlichen geometrischen Formen der Modellelemente der beiden Modelle dargestellt. \mycite[Kap. 10.2]{Stahl07} \begin{figure}[h] \centering \includegraphics[width=0.6\textwidth]{images/modelltransformation.png} \caption{Modelltransformation, Quelle: \mycite[S. 200]{Stahl07}} \label{img_mtransformation} \end{figure} Für die Durchführung einer Transformation gibt es unterschiedliche Ansätze. Ähnlich der \MTC\ kann eine Transformation beispielsweise mittels einer Programmiersprache umgesetzt werden \mycite[Kap. 3.3]{Petrasch06}. Diese Vorgehensweise ist jedoch insbesondere bei umfangreichen Transformationen sehr komplex \mycite[Kap. 10.3]{Stahl07}. Darüber hinaus gibt es daher spezielle Werkzeuge, die im Folgenden als \newWord{\useGlosentry{glos:transwerkzeug}{Transformationswerkzeuge}} bezeichnet werden. Diese Werkzeuge nutzen eine \newWord{\gls{glos:transsprache}} zur Beschreibung der Transformation \mycite[Kap. 10.3]{Stahl07}. Diese Transformationssprachen folgen in der Regel dem Konzept des \newWord{Mappings}. Bei einem Mapping werden \newWord{Mapping-Funktionen} definiert. Diese legen anhand von \newWord{Mapping-Regeln} fest, wie ein Modell transformiert wird. Die Mapping-Regeln werden hierfür auf Grund des Metamodells erstellt. Eine Mapping-Regel kann beispielsweise festlegen, dass jedes Modellelement, das Instanz eines speziellen Metamodellelements ist, durch die Transformation ein zusätzliches Attribut erhält. Eine Transformationssprache, die die Definition von Mappings ermöglicht, ist beispielsweise \QVT. QVT ist der Standard der OMG für Modelltransformationen \mycite[Kap. 5]{MDAdistilled}. Bei der Konzeption eines Transformationswerkzeugs müssen unterschiedliche Punkte durchdacht werden. Eine Schwierigkeit besteht beispielsweise im Umgang mit bidirektionalen Verweisen und Zyklen innerhalb eines Modells. Bei einem Zyklus verweist beispielsweise Element A auf Element B, Element B auf Element C und Element C auf Element A. Zwischen Element A und Element C können dabei beliebig viele Elemente liegen. Ein bidirektionaler Verweis ist ein Zyklus bei dem es nur zwei Elemente gibt. Bei einer Transformation können hierbei, für den Fall, dass die Transformation eines Elements erst abgeschlossen wird, wenn die Transformation seines Nachfolgers abgeschlossen wurde, Endlosschleifen entstehen. Transformationswerkzeuge müssen daher solche Eigenschaften eines Modells erkennen und entsprechend behandeln. \mycite[Kap. 10.3]{Stahl07} \subsection{Cartridges} Aktuelle Generator-Frameworks erlauben das Modularisieren von Teilen des Generierungsprozesses zu sogenannten \newWord{\useGlosentry{glos:cartridge}{Cartridges}}. Der Begriff ``Cartridge'' wird dabei im Rahmen der \mddn\ mit ``Steckmodul'' übersetzt. Ziel einer Cartridge ist es, die Erzeugung von speziellen Teilen des Zielsystems zusammenzufassen, um sie in verschiedenen Projekten wiederverwenden zu können. \mycite[Kap. 10.1]{Stahl07} \par Cartridges kapseln in der Regel spezielle Teile oder plattformspezifische Komponenten eines Softwaresystems. Beispielsweise kann die Schnittstelle zu einer Datenbank automatisch umgesetzt werden, indem beim Transformationsprozess eine Cartridge für ein \newWord{OR-Mapping Framework}\footnote{Ein OR-Mapping (Object-Relational-Mapping) Framework ermöglicht dem Entwickler die automatische Persistierung von Objekten in einer Datenbank. Bei der Verwendung eines OR-Mapping Frameworks wird von der konkreten Datenbank abstrahiert. Der Entwickler nutzt die Funktionalität des Frameworks, anstatt direkt über einen Datenbanktreiber auf die Datenbank zuzugreifen. \mycite[Kap. 1.4]{ORM}} verwendet wird. Bei der Generierung einer \gls{glos:J2EE}-Anwendung könnte eine Cartridge hingegen die Erzeugung der plattformspezifischen Teile des Zielsystems, wie Konfigurationsdateien, übernehmen. Durch die Verwendung von Cartridges wird ein Generator weniger komplex. Dies wird dadurch erreicht, dass der Generator, wie in Abbildung \ref{img_cartridge} dargestellt, anstelle von mehreren Aufrufen an die durch die Cartridge gekapselten Komponenten, nur einmal die Cartridge aufruft. \mycite[Kap. 8.1]{Stahl07} \begin{figure}[h] \centering \includegraphics[width=0.9\textwidth]{images/cartridges.png} \caption{Cartridges, Quelle: \mycite[S. 140]{Stahl07}} \label{img_cartridge} \end{figure} \subsection{Erneute Codegenerierung} Wichtiger Bestandteil der modellgetriebenen Softwareentwicklung ist das Zusammenspiel von Modellierung/Validierung und Generierung. Ähnlich wie bei der Modellierung und Validierung ist dies ein iterativer Prozess. Nach der ersten Codegenerierung werden typischerweise Änderungen am Modell vorgenommen. Diesen Änderungen folgt eine erneute Codegenerierung. \mycite[Kap. 2.2]{Stahl07} \newcommand{\FE}{Forward Engineering} \newcommand{\RE}{Reverse Engineering} \newcommand{\RTE}{Roundtrip Engineering} \par Die Codegenerierung ist kein spezielles Verfahren der \mddn . Sie wird auch bei anderen Ansätzen der Softwareentwicklung angewandt. Beispiel hierfür ist die Codegenerierung aus UML-Modellen. UML-Modelle stellen die Klassen eines Programms und die Beziehungen der Klassen untereinander dar. Abbildung \ref{img_codeGenTypes} zeigt, wie die Codegenerierung bei \MDD\ innerhalb der gängigen Codegenerierungsverfahren einzuordnen ist. \begin{figure}[h] \centering \includegraphics[width=0.9\textwidth]{images/codeGenTypes.png} \caption{Codegenerierungsverfahren, Quelle: \mycite[S. 45]{Stahl07}} \label{img_codeGenTypes} \end{figure} Neben der Codegenerierung bei \MDD\ gibt es das \newWord{\FE}, das \newWord{\RE} und das \newWord{\RTE}. Bei der Codegenerierung aus \UML-Modellen werden diese Codegenerierungsverfahren in der Regel angewandt. Beim \FE\ werden Änderungen am Modell vollzogen. Diese Änderungen werden dann automatisch in den Quelltext übertragen. Beim \RE\ werden die Änderungen dagegen am Quelltext vorgenommen. Das Modell wird dabei automatisch an den Quelltext angepasst. Beim \FE\ und \RE\ besteht folglich eine unidirektionale Beziehung zwischen Modell und Quelltext. Das \RTE\ vereint \FE\ und \RE. Änderungen können am Modell oder am Quelltext vorgenommen werden und der jeweils andere Teil wird entsprechend angepasst. Beim \RTE\ besteht somit eine bidirektionale Verbindung zwischen Modell und Quelltext. \mycite[Kap. 3.3]{Stahl07} \par Beim \FE, \RE\ und \RTE\ haben Modell und Quelltext typischerweise dasselbe Abstraktionsniveau. Das bedeutet, dass das Modell genau das abbildet, was generiert wird. Sollen beispielsweise Klassen und deren Methoden generiert werden, sind diese komplett im Modell enthalten. Andernfalls wären das \RE\ und damit auch das \RTE\ nicht möglich. Bei modellgetriebener Softwareentwicklung hingegen steht das Modell auf einer höheren Abstraktionsebene als der Quelltext. Modell und Code stehen daher nur in einer unidirektionalen Beziehung zueinander. Änderungen am Quelltext können nicht automatisch in das Modell aufgenommen werden. \mycite[Kap. 3.3]{Stahl07} \par Die erste Generierung von Quelltext aus einem Modell ist meistens unproblematisch. Es entstehen Quell\-text-Da\-tei\-en. Sehr häufig muss jedoch Code manuell hinzugefügt werden. Selten lässt sich eine Anwendung bei \useacronym{MDD} zu 100\% generieren. Der manuell hinzugefügte Code würde jedoch bei einer erneuten Generierung überschrieben werden. Um dieses Problem zu handhaben, existieren unterschiedliche Lösungsansätze. Zwei davon, die Verwendung von \newWord{\useGlosentry{glos:protReg}{Protected Regions}} und die Trennung von generiertem und handgeschriebenem Code in unterschiedliche Dateien, werden im Folgenden erläutert. \mycite[Kap. 3.3]{Petrasch06} \par Protected Regions sind geschützte Bereiche im Quelltext. Diese geschützten Bereiche werden bei einer erneuten Codegenerierung nicht mit generiertem Code überschrieben. Anfang und Ende einer Protected Region werden hierfür mit entsprechenden Kommentaren ausgezeichnet. Der folgende Pseudocode in Listing \ref{listing_protectedRegion} zeigt das Schema einer Protected Region \mycite[Kap. 5.4]{Tromp07}. \newpage \begin{lstlisting}[frame=single, tabsize=3, language=Java, label=listing_protectedRegion, caption={Beispiel einer Protected Region, Quelle: (\cite{Tromp07}, S. 177f.)}] public class Person { ... String name = null; // anfang protected region // hierhin kommt der manuell geschriebene Quelltext // ende protected region ... } \end{lstlisting} Protected Regions haben unterschiedliche Nachteile. Zum einen gibt es keine klare Trennung zwischen generiertem und manuell erstelltem Quelltext, da sich generierter und handgeschriebener Code innerhalb einer Datei vermischen. Des Weiteren kann der Entwickler nur innerhalb einer Protected Region Änderungen am Code vornehmen. Er kann nicht wie bei manuell erstelltem Code, alle Code-Teile beliebig ändern \mycite[Kap. 3.3]{Petrasch06}. Ein weiteres Problem besteht darin, dass generierter Code, der manuell verändert wurde, unter Versionskontrolle gestellt werden muss. Dies ist erforderlich, um die Änderungen zu verwalten und sie, wenn das Entwicklerteam aus mehreren Personen besteht, jedem Entwickler zur Verfügung zu stellen. Generell sollte generierter Code jedoch nicht in einem \newWord{\gls{glos:vks}} erfasst werden. Dies hat den Grund, dass bei der \mddn\ das Modell die Rolle des Quelltexts einnimmt. Die generierten Quelltexte sind nur eine Art Zwischenprodukt, ähnlich den Class-Dateien bei Java-Programmen \mycite[Kap. 2.2]{Stahl07}. Weiterhin wird der Generator bei der Verwendung von Protected Regions unter Umständen sehr komplex, da er die geschützten Bereiche verwalten, erkennen und erhalten muss. Schließlich kommt noch hinzu, dass der Entwickler bei Protected Regions den generierten Code zumindest zum Teil verstehen muss. Dies ist notwendig, um sinnvolle Änderungen und Erweiterungen am Quelltext vornehmen zu können. Generierter Code ist jedoch nicht immer einfach zu verstehen \mycite[Kap. 8.5]{Stahl07}. Die Vorteile von Protected Regions sind dagegen, dass der Generator die Kontrolle über die generierten Dateien behält. Wird beispielsweise ein Element im Modell gelöscht, kann der Generator die zugehörigen generierten Dateien ebenfalls löschen. Ein weiterer Vorteil ist, dass die vom Modell vorgegebene Architektur eingehalten wird \mycite[Kap. 5.4]{Tromp07}. Für die Trennung von generiertem und manuell erstelltem Code in separate Dateien gibt es unterschiedliche Vorgehensweisen. Ein möglicher Ansatz ist die \newWord{dreistufige Vererbung}. Hierfür ist es erforderlich, dass der Quelltext, der generiert wird, in einer objekt-orientierten Programmiersprache verfasst ist. Des Weiteren wird vorausgesetzt, dass die Teile des zu generierenden Systems drei unterschiedliche Arten von Funktionalität besitzen. Diese sind bei Stahl et al. \mycite[S. 161]{Stahl07} wie folgt definiert: \begin{itemize} \item Es gibt Funktionalität, die für alle Teile eines Typs gleich ist. \item Es gibt Funktionalität, die für jedes Teil unterschiedlich ist. Sie lässt sich jedoch aus den Informationen, die im Modell erfasst sind, generieren. \item Es gibt Funktionalität, die für jedes Teil unterschiedlich ist und vom Entwickler manuell implementiert werden muss. \end{itemize} Auf diesen Grundvoraussetzungen baut die dreistufige Vererbung auf. Zunächst wird dabei die Funktionalität implementiert, die für alle Teile eines Typs gleich ist. Diese Implementierung wird Teil der Plattform. Sie kann dem generierten Code beispielsweise über Programmbibliotheken zur Verfügung gestellt werden. Bei der Codegenerierung werden dann abstrakte Klassen erzeugt, die von den zuvor implementierten Klassen erben. Diese abstrakten Klassen setzen die Funktionalität um, die aus den Informationen im Modell generiert werden kann. Schließlich werden nicht-abstrakte Klassen manuell implementiert. Diese Klassen erben von den generierten, abstrakten Klassen und setzen die Funktionalität um, die nicht aus den Informationen des Modells generiert werden kann. Die manuell erstellten Klassen werden dann im System verwendet. \mycite[Kap. 8.5]{Stahl07} Neben der dreistufigen Vererbung gibt es weitere Ansätze zur Trennung von generiertem und manuell erstelltem Code. Diese basieren in der Regel auf \newWord{\useGlosentry{glos:pattern}{Entwurfsmustern}} und werden daher von Stahl et al. als \newWord{Entwurfsmuster-basierte Integration} bezeichnet. Ein Entwurfsmuster, auch \newWord{Pattern} genannt, \textquote[\cite{BalzertUML}, S. 74]{gibt eine bewährte, generische Lösung für ein immer wiederkehrendes Entwurfsproblem an, das in bestimmten Situationen auftritt}. Die Entwurfsmuster-basierte Integration legt dabei keine konkreten Vorgehensweisen fest, sondern umfasst unterschiedliche Konzepte. Diese Konzepte beschreiben, auf welche Art generierter und manuell implementierter Code zusammengebracht werden können. Der generierte Code kann zum Beispiel den manuell erstellten Code aufrufen oder umgekehrt. \mycite[Kap. 8.5]{Stahl07} \par Bei der Trennung von generiertem Code und manuell erstelltem Code in separate Dateien ergeben sich gegenüber der Verwendung von Protected Regions andere Probleme. Zunächst muss hierbei abhängig vom Typ der zu generierenden Dateien, beispielsweise Java-Dateien, Properties-Dateien oder XML-Dateien, eine andere Strategie entwickelt werden, um generierten Code und handgeschriebenen Code zusammenzuführen. Bei objektorientierten Sprachen kann beispielsweise mit Vererbung oder Delegation gearbeitet werden. Bei nicht objektorientierten Sprachen können \newWord{Includes} verwendet werden. Unter Includes werden hier Anweisungen verstanden, die den Code aus anderen Dateien ausführen \mycite[Kap. 3.3]{Petrasch06}. Ein weiterer Nachteil ist, dass der Generator nicht die Kontrolle über alle Dateien behält. Bei strukturellen Änderungen beispielsweise werden die generierten Dateien vom Generator angepasst. Die manuell erstellten Dateien müssen jedoch per Hand geändert werden. Der Vorteil dieser Technik liegt hingegen darin, dass es eine klare Trennung von generiertem und handgeschriebenem Code gibt. Die generierten Artefakte müssen somit nicht in ein Versionskontrollsystem gestellt werden. \mycite[Kap. 5.4]{Tromp07}. \section{Interpreter} Neben dem Ansatz der Generierung von Quelltext aus Modellen gibt es einen weiteren Ansatz zur Verarbeitung von Modellen: sogenannte \newWord{\gls{glos:interpreter}}. Ein Interpreter ist eine Software oder ein Teil einer Software, der Modelle zur Laufzeit auswertet. Der Interpreter führt dabei Aktionen aus, die durch das Modell beschrieben werden. Im Gegensatz dazu erzeugt ein Generator auf einem Modell basierend Quelltext, der später unabhängig vom Generator ausgeführt werden kann. Die Eigenschaften eines Interpreters sind zum großen Teil dieselben wie die eines Codegenerators. Beide Ansätze setzen beispielsweise ein formales Modell voraus und sind spezifisch für eine Plattform. \mycite[Kap. 9.1]{Stahl07} Das Konzept von Interpretern und Generatoren wird zum Beispiel bei Programmiersprachen angewandt. Das Modell wäre hierbei der Quelltext des Programms. Interpretierte Programmiersprachen, wie beispielsweise Ruby, werden direkt durch den Interpreter ausgeführt. Programmiersprachen wie C++ dagegen werden zunächst von einem \newWord{Compiler} in Maschinencode übersetzt, der dann unabhängig vom Compiler ausgeführt wird. Interpreter und Generatoren sind keine sich gegenseitig ausschließenden Konzepte. Es gibt beispielsweise einen weiteren Ansatz zur Verarbeitung von Modellen, der eine Kombination von Generatoren und Interpretern ist. Ein Generator überführt hierbei die Modelle in ein Zwischenformat, das anschließend von einem Interpreter ausgeführt wird. Dieses Konzept wird ebenfalls bei Programmiersprachen wie zum Beispiel Java angewandt. Weitere Informationen zu Interpretern finden sich bei \mycite[Kap. 9]{Stahl07}. In dieser Arbeit wird auf dieses Thema nicht näher eingegangen, da Interpreter bei der Konzeption und Umsetzung des im Rahmen dieser Diplomarbeit zu entwickelnden Prototyps nicht angewandt wurden. \section{Model Driven Architecture} \resetacronym{MDA}\useacronym{MDA} ist eine Spezifikation der \resetacronym{OMG}\OMG\ im Rahmen der \mddn . Stahl et al. äußern sich im Bezug zur Einordnung der MDA im Kontext von MDD wie folgt. \begin{displayquote} \textquote[\cite{Stahl07}, S. 377]{Wir sehen die MDA als die Standardisierungsinitiative der OMG zum Thema MDSD an. Da die MDA jedoch (bisher) nicht das gesamte MDSD-Spektrum abdeckt, kann man die MDA auch als eine MDSD-Ausprägung respektive Interpretation auffassen.} \end{displayquote} Die \OMG\ wurde 1989 gegründet. Sie ist ein internationales Konsortium aus etwa 800 Firmen weltweit. Die \OMG\ erstellt herstellerunabhängige Spezifikationen zur Interoperabilität und Portabilität von Softwaresystemen. Interoperabilität ist \textquote[\cite{Brockhaus}, S. 472]{die Fähigkeit verschiedener Geräte oder Software, direkt miteinander zu kommunizieren.} Unter Portabilität wird hier die Modifizierung einer Anwendung verstanden, so dass sie in einer anderen Umgebung, zum Beispiel auf einem anderen Betriebssystem, in gleicher Weise arbeitet \mycite[S. 720]{Brockhaus}. Die beiden primären Motivationen bei MDA sind daher Interoperabilität und Portabilität. Weitere bekannte Spezifikationen der OMG sind beispielsweise \unsetacronym{CORBA}\CORBA\ oder \UML. \mycite[Anhang A.1]{Stahl07} \par Bei MDA wird die \MOF\ als Metametamodell verwendet. Metamodelle sind somit Instanzen der \MOF. Die \MOF\ ist das Metamodell der \UML, daher wird bei MDA oft die UML als Metamodell verwendet. Für den Austausch von Modellen zwischen verschiedenen MDA-Werkzeugen wird \XMI\ eingesetzt. \XMI\ ist ein Austauschformat für Modelle, die die \MOF\ als Metametamodell verwenden, und durch die \OMG\ standardisiert. \mycite[Anhang A.2]{Stahl07} \par Die MDA arbeitet mit drei zentralen Modellen: das \PIM, das \PDM\ und das \PSM. Diese dienen dazu, die Anwendungslogik unabhängig von der Plattform zu entwickeln. Das \PIM\ beschreibt dabei die Anwendungslogik. Plattformspezifische Details werden hierfür bei diesem Modell weggelassen. Das \PDM, auch \newWord{Platform Model} (PM) genannt, ist hingegen das Metamodell der Zielplattform. Es beschreibt die Struktur der Zielplattform. Das PDM für eine Datenbank enthält beispielsweise ein Element für Tabellen, welches aus Elementen für Spalten aufgebaut ist. Das \PSM\ ist schließlich plattformspezifisch. Es enthält die mit zielplattformspezifischen Implementierungsdetails angereicherte Anwendungslogik. Das \PSM\ kann beispielsweise Implementierungsdetails enthalten, die spezifisch für \gls{glos:J2EE}-Anwendungen sind. \mycite[Anhang A.2]{Stahl07} \par Bei MDA beginnt der Entwicklungsprozess mit der Modellierung des \PIM s und des \PDM s. Diese beiden Modelle dienen als Ausgangsmodelle für Modelltransformationen. Durch die Modelltransformation entsteht das \PSM. Abbildung \ref{img_mda_models} stellt den MDA-Entwicklungsprozess schematisch dar. \mycite[Kap. 2.5]{Petrasch06} \begin{figure}[h] \centering \includegraphics[width=0.5\textwidth]{images/mda_models.png} \caption{Codegenerierungsverfahren, Quelle: \mycite[S. 107]{Petrasch06}} \label{img_mda_models} \end{figure} Aus dem \PSM\ wird der Quelltext generiert. Vor der Codegenerierung können jedoch zuvor mehrmals Transformationen auf dem \PSM\ ausgeführt werden. Bei jeder Transformation wird das Modell dabei mit Implementierungsdetails angereichert. Diese sind bei jeder Transformation spezifischer für die Zielplattform als bei der vorhergehenden Transformation. Das aus der ersten Transformation hervorgehende \PSM\ kann beispielsweise spezifisch für \gls{glos:J2EE} sein. Es sagt jedoch noch nichts darüber aus, für welchen Applikationsserver es optimiert ist. Erst nach einer weiteren Transformation ist das \PSM\ spezifisch für einen Applikationsserver (zum Beispiel für \gls{glos:JBoss}). \mycite[Anhang A.2]{Stahl07} In dieser Arbeit wird des Weiteren nicht näher auf MDA eingegangen, da dieser Standard für die Konzeption und Umsetzung des zu entwickelnden Prototyps nicht angewandt wird. Eine detaillierte Betrachtung von MDA findet sich bei Stahl et al. \mycite[Anhang A.2]{Stahl07} und Petrasch et al. \mycite{Petrasch06}.