\chapter{Konzeption und Umsetzung des Systems}
\label{chap_konzeption}
Im Folgenden werden die Konzeption und Umsetzung des im Rahmen dieser Diplomarbeit entwickelten Prototyps zur Erstellung von virtuellen Ausstellungen beschrieben. Die Projektbezeichnung für den Prototyp ist dabei \unsetacronym{JAT}\newWord{\JAT} (\newWord{\JATlong}). JAT ist ein rekursives Akronym. Ein rekursives Akronym ist ein Akronym, dessen Erklärung sich selbst enthält. Rekursive Akronyme treten meist bei Open-Source-Projekten auf. Der Name des Prototyps wurde in Anlehnung an die Technologie gewählt, mit der das Altsystem umgesetzt wurde. Diese war Zope, was für Z(ope) Object Publishing Environment steht.

Der Prototyp soll den im vorherigen Kapitel definierten Anforderungen entsprechen und wenn zeitlich möglich einige der in Anhang \ref{anhang_wunschkrit} festgelegten Wunschkriterien erfüllen. Im Hinblick darauf werden zunächst die Techniken für die Umsetzung der Ausstellungssoftware ausgewählt. Im Anschluss daran werden die ausgewählten Techniken kritisch betracht. In der folgenden Beschreibung der Konzeption und Umsetzung des Prototyps wird zunächst die Konstruktion des Domänenmodells und des Metamodells erläutert. Anschließend folgt eine Darstellung der Umsetzung des Modellierungstools und der Realisierung des Codegenerators. Schließlich wird auf einige Implementierungsdetails näher eingegangen. Zuletzt werden die eingesetzten Teststrategien kurz erläutert.

\section{Auswahl der Techniken}
Für die Wahl der Techniken zur Umsetzung des Prototyps gibt es drei grundlegende Bedingungen. 
\begin{itemize}
  \item In Absprache mit dem Projektleiter Robert Casties wurde als Programmiersprache Java ausgewählt. Dies hat den Grund, dass die verwendeten Programmiersprachen am \MPIWG\ hauptsächlich Java und Python sind.
  \item Die \MPG\ ist ein engagierter Vertreter der ``Open Access''-Politik\footnote{Mehr zur ``Open Access''-Politik der MPG siehe http://oa.mpg.de/openaccess-berlin/berlindeclaration.html}. Daher besteht die Bedingung, dass die eingesetzten Techniken frei und wenn möglich open-source verfügbar sind.
  \item Die zu entwickelnde Software muss auf dem Betriebsystem OS X von Apple lauffähig sein. Dies ist darin begründet, dass am \MPIWG\ fast ausschließlich mit diesem Betriebssystem gearbeitet wird.
\end{itemize}
   
\subsection{Modellierung}
Bei der Wahl des Modellierungswerkzeugs werden auf Grund der ``Open Access''-Politik des \MPIWG\ die kommerziellen Werkzeuge ArcStyler und Enterprise Architect nicht in den Auswahlprozess miteinbezogen. Das \acrln{GME} wird ebenfalls ausgeschlossen. Es ist zwar open-source verfügbar, es wurde jedoch für das Betriebssystem Windows entwickelt. Der Vergleich von \GMF\ und Xtext ergibt, dass beide Frameworks in Java implementiert und somit auf dem Betriebssystem OS X lauffähig sind. Bei der Verwendung von GMF kann dabei eine graphische DSL definiert werden. Xtext arbeitet dagegen mit textuellen DSLs. Eine graphische DSL ist für einen Benutzer ohne technisches Hintergrundwissen, wie beispielsweise das Beherrschen einer Programmiersprache, in der Regel einfacher zu verwenden als eine textuelle DSL. Die Wahl des Modellierungswerkzeugs fällt daher auf GMF.

Die Verwendung von GMF zur Modellierung legt \EMF\ als das Metamodellierungswerkzeug und Ecore als Metametamodell fest. Ecore ermöglicht die Erstellung von Metamodellen, die spezifisch für eine Domäne sind. Die Domäne einer virtuellen Ausstellung ist keine technische Domäne wie beispielsweise die Architektur einer Software. Es bietet sich daher an, nicht die \UML\ zu verwenden, sondern dem Ansatz von Ecore zu folgen. EMF ist somit für die Definition des Metamodells gut geeignet. 

Die Verwendung von GMF setzt bei der Entwicklung des Prototyps den Einsatz der IDE Eclipse voraus. Eclipse ist aus mehreren Ebenen aufgebaut. Die Kern-Komponente ist hierbei die \newWord{Eclipse Runtime Platform}. Sie stellt grundlegende Funktionen, wie beispielsweise die Plugin-Verwaltung oder die Verwaltung von Dateien und Verzeichnissen, bereit. Darauf aufbauend fügt, wie in Abbildung \ref{img_eclipse} dargestellt, die \newWord{Eclipse \IDElong} wesentliche Funktionen, die eine \IDE\ benötigt, hinzu. Zu diesen Funktionen gehören beispielsweise Suchfunktionen oder Debugging-Funktionen. Die \JDT\ erweitern Eclipse darüber hinaus um notwendige Funktionen zur Entwicklung von Java. Weitere Funktionalität wird über Plugins hinzugefügt. Diese Anreicherung der Funktionalität durch Plugins ist das Kernkonzept von Eclipse. Abbildung \ref{img_eclipse} zeigt die Architektur von Eclipse. \mycite[Kap. 1.1]{EclipseDistilled}
\begin{figure}[h]
\centering
\includegraphics[width=0.7\textwidth]{images/konzeption/eclipse.png} 
\caption{Architektur von Eclipse, Quelle: angelehnt an \mycite[Kap. 1.1]{EclipseDistilled}}
\label{img_eclipse}
\end{figure}

Neben der Verwendung und Erweiterung der Entwicklungsumgebung können auf Basis der Eclipse Runtime Platform Rich-Client-Anwendungen entwickelt werden. Eine solche Rich-Client-Anwendung wird als \RCP\ bezeichnet. \RCP s folgen ebenso wie die Entwicklungsumgebung dem Plugin-Konzept. Zusätzliche Funktionalität kann dem \RCP\ daher über Plugins hinzugefügt werden. \mycite[Kap. 1.1]{EclipseDistilled}

\par
Ein mit GMF erstelltes Modellierungstool kann als Plugin für Eclipse oder als \RCP\ erzeugt werden. Die Anwender der Ausstellungssoftware sind in der Regel Geschichtswissenschaftler, die keine Kenntnisse in der Verwendung einer IDE besitzen. Die Entwicklung des GMF-Modellierungstools als Plugin für Eclipse würde jedoch Kenntnisse im Umgang mit Eclipse voraussetzen. Darüber hinaus ständen bei der Nutzung von Eclipse ähnlich wie beim Altsystem mehr Funktionen zur Verfügung, als für die Erstellung einer virtuellen Ausstellung notwendig sind. Es wurde daher entschieden, das GMF-Modellierungstool als \RCP\ zu entwickeln. Die Ausstellungssoftware kann somit an die benötigte Funktionalität angepasst werden.


\subsection{Codegenerator}
In den Auswahlprozess des Codegenerators werden die Generatoren JET, openArchitectureWare und AndroMDA aufgenommen. Die drei Generatoren sind Open-Source-Frameworks und auf OS X lauffähig. AndroMDA ist für die Verwendung innerhalb eines MDA"=Entwicklungsprozesses konzipiert. Es existieren Cartridges für unterschiedliche Technologien, wie beispielsweise für die Generierung von Java-Klassen. Für die Erzeugung von HTML-Seiten bietet AndroMDA jedoch keine Unterstützung. Des Weiteren kann bei der Betrachtung der Übersicht über die zuletzt veröffentlichten Versionen von AndroMDA festgestellt werden, dass die letzte stabile Version 2006 herausgegeben wurde.\footnote{Siehe hierzu http://galaxy.andromda.org/docs/changes-report.html.} Dies führt zu der Annahme, dass die Entwicklung von AndroMDA stagniert oder eventuell ganz eingestellt wurde. Die Verwendung von AndroMDA könnte somit in Entwicklungsphasen, die auf den Prototyp folgen, dazu führen, dass auf einen anderen Codegenerator umgestellt werden muss. AndroMDA wird für die Umsetzung des Prototyps daher nicht verwendet.

\par
Im Gegensatz zu AndroMDA sind oAW und JET nicht auf MDA spezialisiert. oAW umfasst dabei neben der \MTC\ und \MTM\ auch die Möglichkeit der Erstellung von textuellen DSLs und einen Metamodell-Generator, der aus UML-Modellen Ecore-Modelle erstellt. Des Weiteren ermöglicht oAW das Validieren von Modellen und die Verwendung von unterschiedlichen Modellierungswerkzeugen. Die umfassende Funktionalität von oAW führt zu der Entscheidung, oAW nicht für die Umsetzung des Prototyps zu verwenden. Die Generierung der Webseiten für eine virtuelle Ausstellung würde nur einen kleinen Teil der Funktionalität von oAW nutzen.

\par
JET verfügt im Vergleich zu oAW über weit weniger Funktionalität. Dieser Codegenerator ist auf die Generierung von Java-Quelltext spezialisiert. Bei der Generierung von Java-Code kann beispielsweise JMerge bei der Zusammenführung von generiertem und handgeschriebenem Quelltext verwendet werden. Bei der Generierung von HTML hingegen müssen Protected Regions im Template explizit ausgezeichnet werden. Dieses Vorgehen ist fehleranfälliger und weniger komfortabel als die Verwendung von JMerge. Des Weiteren haben erste Tests ergeben, dass JET nicht ermöglicht, mehr Informationen in den Transformationsprozess einfließen zu lassen als im Modell verfügbar sind. Bei der Erzeugung der HTML-Seiten für eine virtuelle Ausstellung werden jedoch neben den Informationen aus dem Modell Informationen zur Darstellung von Modellelementen benötigt. Es werden beispielsweise Daten zur Positionierung von Scene Links und Exhibition Module Links benötigt. Diese Daten sind nicht im Modell gespeichert. Bei der Verwendung von JET müssten somit zusätzliche Daten zunächst im Modell verfügbar gemacht werden. JET wird daher zur Umsetzung des Prototyps ebenfalls ausgeschlossen.

\subsection{Überblick der ausgewählten Techniken}
Der Vergleich der Umsetzungsmöglichkeiten hat ergeben, dass der Prototyp mittels GMF entwickelt wird. Im Folgenden wird der Prototyp auch als \newWord{das Modellierungstool} bezeichnet. Im Gegensatz dazu wird der Begriff ``GMF-Modellierungstool'' verwendet, wenn eine Aussage für jedes mit GMF erstellte Modellierungstool gültig ist. Des Weiteren wird für die Entwicklung Ecore als Metametamodell verwendet. Der Vergleich der Codegeneratoren hat ergeben, dass weder AndroMDA, noch oAW oder JET für die Umsetzung des Prototyps geeignet sind. Der Codegenerator wird daher speziell für den Prototyp konzipiert und implementiert. Abbildung \ref{img_technologien} zeigt das Zusammenwirken der verwendeten Technologien.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\textwidth]{images/konzeption/technologien.png} 
\caption{Verwendete Technologien}
\label{img_technologien}
\end{figure}


\subsection{Kritische Betrachtung der Techniken}
Das Altsystem wird ausschließlich über das Internet mittels eines Webbrowsers verwendet. Dies hat den Vorteil, dass mehrere Wissenschaftler gleichzeitig und von unterschiedlichen Orten aus an einer virtuellen Ausstellung arbeiten können. Insbesondere bei der Erstellung der Exhibition Modules der virtuellen Einsteinausstellung wurde diese Möglichkeit genutzt. Ein GMF"=Modellierungstool ist im Gegensatz zum Altsystem eine lokale Anwendung. Die Zusammenarbeit von unterschiedlichen Personen ist dadurch zunächst nicht möglich. Bei der virtuellen Einsteinausstellung nachfolgenden Projekten, bei denen eine virtuelle Ausstellung erstellt wurde, arbeitete jedoch in der Regel nur eine Person an einer virtuellen Ausstellung. Eine lokale Anwendung ist daher in den meisten Fällen ausreichend. 

\par
Die Zusammenarbeit von unterschiedlichen Personen bei der Erstellung einer virtuellen Ausstellung könnte durch die Verwendung eines Versionskontrollsystems zur Speicherung der von dem Modellierungstool benötigten Dateien ermöglichen werden. Darüber hinaus könnte ein Redaktionsprozess durch den Einsatz eines Test- und eines Produktionssystems möglich gemacht werden. Änderungen an einer virtuellen Ausstellung würden dabei zunächst in das Testsystem eingepflegt werden. Erst durch die Freigabe des Projektleiters würden die Änderungen in das Produktionssystem übernommen werden.

\section{Entwicklungssystem}
Der Prototyp wurde unter Verwendung des Betriebssystems OS X von Apple und der IDE Eclipse entwickelt. Die verwendete Version des \JDK\ ist das JDK 5.\footnote{Weitere Informationen zu JDK 5 siehe http://java.sun.com/javase/downloads/index\_jdk5.jsp.} Für die Versionierung des Prototyps wurde \SVN\ genutzt. Subversion ist ein Open-Source-Versionskontrollsystem.\footnote{Weitere Informationen zu Subversion siehe http://subversion.tigris.org/.} Für das Projektmanagement wurde das Web-basierte Projektmanagement-Tool \newWord{Trac} verwendet.\footnote{Weitere Informationen zu Trac siehe http://trac.edgewall.org/.}
\newpage

\section{Produktivsystem}
Für den Einsatz des zu entwickelnden Systems wird das Betriebssystem OS X von Apple vorausgesetzt. Des Weiteren wird die \JRE\ in der Version 5.0 oder höher benötigt.\footnote{Weitere Informationen zu JRE 5 siehe http://java.sun.com/javase/downloads/index\_jdk5.jsp.}

\newcommand{\CC}{Crystal Clear}
\section{Vorgehensmodell}
Für die Entwicklung des Prototyps wurde das Vorgehensmodell \newWord{\CC} gewählt. \CC\ gehört zu einer Gruppe von Vorgehensmodellen, die \newWord{Crystal} genannt wird. Crystal wurde von Alistair Cockburn entwickelt. 

\par
Die Methoden der Crystal-Vorgehensmodelle sind für die unterschiedlichen Voraussetzungen, die für ein Projekt gelten können, konzipiert. \CC\ wurde dabei für den Einsatz bei Projekten mit einem Entwicklerteam, das bis zu sechs Personen umfasst, entwickelt. \CC\ legt die folgenden Prinzipien für die Softwareentwicklung fest. \mycite[Kap. 6]{AgileSE}
\begin{itemize}
  \item Die Entwickler befinden sich in einem Raum oder in angrenzenden Räumen. Dies dient der Förderung der Kommunikation zwischen den Entwicklern.
  \item Der Auftraggeber erhält regelmäßig, etwa alle zwei bis drei Monate, eine neue Version der zu entwickelnden Software.
  \item Der Auftraggeber bzw. der spätere Anwender der Software wird in den Entwicklungsprozess miteinbezogen.
  \item Jede ausgelieferte Version wird von dem späteren Anwender getestet.
  \item Zu Beginn und in der Mitte des Entwicklungszeitraumes einer Version werden Besprechungen zur Verbesserung der Software und der Vorgehensweise bei der Entwicklung abgehalten.
  \item Ein Versionskontrollsystem wird verwendet.
  \item Neben den ausgelieferten Versionen, dem Code, Software-Tests und Use-Case"=Diagrammen werden nur wenige Dokumente während der Entwicklung erstellt.
\end{itemize}

\par
Bei der Entwicklung des Prototyps bestand das Entwicklerteam aus einer Person. Ansprechpartner wie Fachexperten oder der Projektleiter befanden sich im gleichen Raum wie die Entwicklerin oder in sehr nahegelegenen Büroräumen. Des Weiteren wurden zu Beginn der Entwicklungsphase des Prototyps Besprechungen zur Anforderungsdefinition und zur Klärung von Fachfragen geführt. Ebenso wurden während der Entwicklung Sitzungen zur Beurteilung des Prototyps organisiert. Die räumliche Nähe zu den Fachexperten führte regelmäßig zu spontanen Besprechungen hinsichtlich der Konzeption und Bedienbarkeit des Prototyps.

\section{Metamodellierung}
Die Definition des Metamodells ist ein wesentlicher Bestandteil der \mddn. Die Struktur der Domäne muss dabei möglichst genau abgebildet werden. Änderungen, die nach der Metamodellierungsphase am Metamodell vorgenommen werden, führen insbesondere bei der Verwendung von GMF oftmals zu Schwierigkeiten. Der Grund dafür liegt darin, dass die Entwicklung eines GMF"=Modellierungstools auf dem mit EMF erstellten Metamodell aufbaut. 

\subsection{Definition des Domänenmodells}
Das Domänenmodell des Prototyps wurde auf dem Domänenmodell des Altsystems basierend entwickelt. Das Domänenmodell des Altsystems wurde hierfür unter Einbeziehung der Erfahrungen aus der Verwendung des Altsystems überarbeitet. Abbildung \ref{img_domainmodel} zeigt das Domänenmodell des Prototyps. Dieses wird im Folgenden erläutert. In Anhang \ref{anhang_domainmodel} befindet sich eine detailliertere Version des Domänenmodells.
\begin{figure}[h]
\centering
\includegraphics[width=0.85\textwidth]{images/konzeption/jat_domain_small.jpg} 
\caption{Domänenmodell des Prototyps}
\label{img_domainmodel}
\end{figure}

\par
Das Domänenmodell des Prototyps besteht zunächst aus den drei zentralen Elementen einer virtuellen Ausstellung: 
\begin{itemize}
  \item die Virtual Exhibition, abgebildet durch die Klasse \code{Exhibition},
  \item die Scene, abgebildet durch die Klasse \code{Scene},
  \item das Exhibition Module, abgebildet durch die Klasse \code{ExhibitionModule}.
\end{itemize}
Eine virtuelle Ausstellung wird dabei durch genau ein Objekt der Klasse \code{Exhibition} repräsentiert. Die Scenes und Exhibition Modules einer virtuellen Ausstellung sind in diesem Objekt enthalten. Des Weiteren gilt, dass beim Löschen einer virtuellen Ausstellung die enthaltenen Scenes und Exhibition Modules gleichermaßen gelöscht werden. Die Klasse \code{Exhibition} steht daher zu den Klassen \code{Scene} und \code{ExhibitionModule} durch eine Komposition in Beziehung.

\par
Die Klassen \code{SceneLink} und \code{ExhibitionModuleLink} bilden Scene Links und Exhibition Module Links ab. Sie werden dabei durch die Klasse \code{Link} generalisiert. Des Weiteren wird die Ausgangs-Scene eines Scene Links oder Exhibition Module Links durch das \code{Scene}-Objekt festgelegt, welches das entsprechende \code{Link}-Objekt enthält. Die Beziehung zwischen \code{Scene} und \code{Link} ist hierbei eine Komposition. Dies ist darin begründet, dass beim Löschen einer Scene die gesamten Scene Links oder Exhibition Module Links, bei denen die Scene Ausgangs-Scene ist, ebenfalls gelöscht werden sollen. 

\par
Bei der Verwendung des Altsystems hat sich gezeigt, dass zu Beginn der Erstellung eines Exhibition Modules die Struktur des Exhibition Modules meist noch nicht klar ist. Es ist zunächst notwendig, die Inhalte des Exhibition Modules zu erfassen. Nach der Erfassung können die Inhalte dann strukturiert werden. Beim Altsystem konnte ein Slide oder Branching Point nur innerhalb einer Sequence angelegt werden. Der Slide oder Branching Point war dann genau dieser Sequence zugeordnet. Er war dabei über eine Komposition mit der Sequence verbunden. Die Abhängigkeit der Slides und Branching Points von genau einer Sequence führte bei der Verwendung des Altsystems dazu, dass Sequences mit jeweils einem Slide oder Branching Point erstellt wurden. Die Meta-Sequences wurden dann dazu verwendet, die Reihenfolge der Slides und Branching Points festzulegen. Das Domänenmodell des Prototyps hat daher gegenüber dem Domänenmodell des Altsystems die folgenden Änderungen:
\begin{itemize}
  \item Slides und Branching Points existieren unabhängig von den Sequences. Sie sind nicht Teil einer Sequence. Die Sequences legen dabei die Reihenfolge der Slides und Branching Points durch Verweise auf diese fest. Slides und Branching Points können somit mehrfach innerhalb eines Exhibition Modules verwendet werden. Ein Slide oder Branching Point, auf den von keiner Sequence verwiesen wird, ist im Navigationsgraph des Exhibition Modules nicht erreichbar.
  \par
  Im Domänenmodell des Prototyps wird die beschriebene Änderung zum einen durch die Kompositions"=Beziehung zwischen der Klasse \code{ExhibitionModule} und der Klasse \code{Slide} deutlich. Die Klasse \code{Slide} repräsentiert dabei die Slides eines Exhibition Modules. Zum anderen führt diese Änderung zu der Aggregations-Beziehung zwischen der Klasse \code{Sequence} und der Klasse \code{Slide}.
  \item Es gibt keine Meta-Sequences mehr. 
\end{itemize}

\par
Branching Points, abgebildet durch die Klasse \code{BranchingPoint}, verfügen über die Eigenschaften eines Slides und enthalten darüber hinaus Branching Point Choices. Die Klasse \code{BranchingPoint} wird daher durch die Klasse \code{Slide} generalisiert. 

\par
Das Layout von Slides und Branching Points wird über Vorlagen, sogenannten \newWord{Slide Templates}, gesteuert. Ein Slide Template legt neben der Anordnung von Texten und Bildern die Anzahl der angezeigten Bilder und Texte fest. Einem Slide oder Branching Point können dabei mehr Bilder und Texte hinzugefügt werden als durch das Slide Template angezeigt werden. Im Domänenmodell werden die Slide Templates durch die Klasse \code{SlideTemplate} repräsentiert. Diese steht in Beziehung zu der Klasse \code{Slide}. Das System bietet eine Auswahl von Slide Templates, die auf Slides und Branching Points angewandt werden können. Wird ein Slide oder Branching Point gelöscht, wird das verwendete Slide Template jedoch nicht ebenfalls gelöscht. Daher steht die Klasse \code{Slide} zu der Klasse \code{Slide Template} in einer Aggregations-Beziehung.

\subsection{Definition des Metamodells}
Zur Definition des Metamodells wurde Java im Kontext von EMF benutzt. Dafür wurde zunächst ein Java Projekt in Eclipse erstellt. Entsprechend der Projektbezeichnung JAT wurde das Projekt \code{JAT} genannt. Mit Hilfe von EMF wurden daraufhin die folgenden Arbeitsschritte durchgeführt:
\begin{itemize}
  \item Definition des Metamodells mittels Java-Interfaces
  \item Erzeugung des Ecore-Modells
  \item Erzeugung der Java-Klassen für die Metamodellelemente und deren Adapter
\end{itemize}

\par
Für die Definition des Metamodells wurden zunächst Interfaces implementiert. Dabei entspricht ein Interface einem Metamodellelement. Des Weiteren wird ein Attribut eines Metamodellelements durch eine entsprechende getter-Methode definiert. Die Methode wird hierbei mit \code{@model} annotiert. Die Annotation muss sich innerhalb eines JavaDoc-Kommentares befinden. Listing \ref{listing_annotatedJava} zeigt ausschnittsweise das annotierte Java-Interface für das Metamodellelement \code{Exhibition}. Der Parameter \code{containment=``true''} in Zeile 14 legt dabei fest, dass es sich bei der Beziehung zwischen dem Metamodellelement und dem Attribut um eine Komposition handelt. 
\vspace{5pt}

\lstinputlisting[frame=single, numbers=left, tabsize=3, label=listing_annotatedJava, caption={Ausschnitt eines Interface zur Definition des Metamodells}, language=Java, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]{listings/lst_exhibition_mm}

\par
Im nächsten Schritt wurde das Ecore-Modell automatisch durch EMF erzeugt. Die generierte Ecore-Datei befindet sich in Anhang \ref{anhang_metamodell_ecore}. Für die Bearbeitung dieses Ecore-Modells stellt EMF einen Editor zur Verfügung. Ein Screenshot des Editors zeigt Anhang \ref{anhang_emf_editor}.

\par
Nach der Erzeugung des Ecore-Modells wurden die Java-Klassen für die Metamodellelemente und die Adapter für diese Klassen generiert. Für die Generierung benötigt EMF neben dem Ecore-Modell ein weiteres Modell, das \newWord{Genmodel}. Dieses enthält hierbei Informationen wie beispielsweise Paketnamen, Pfadangaben oder die zu verwendende Java Compiler Version. Bei der Generierung des Ecore-Modells aus den definierten Interfaces wird das Genmodel ebenfalls automatisch erzeugt. Änderungen am Genmodel bezüglich spezifischer Eigenschaften der zu generierenden Java-Klassen können dann manuell vorgenommen werden. Anhang \ref{anhang_emf_genmodel} zeigt das Genmodel von EMF für das definierte Metamodell.

\par
Bei der Generierung durch EMF wurden zum einen die Java-Klassen, die die Metamodellelemente repräsentieren, erstellt. Diese implementieren jeweils das entsprechende, zuvor definierte Interface. Zum anderen wurden einige Hilfsklassen, wie beispielsweise eine Klasse zum Erzeugen von Instanzen der Metamodellelemente\footnote{Vgl. das Entwurfsmuster ``Abstract Factory'' bei Gamma et al. \mycite{gamma}.}, und ein zweites Plugin erzeugt. Das generierte Plugin wurde mit Hilfe von EMF.Edit erstellt. Es enthält die Adapter für die Java-Klassen der Metamodellelemente.

\newcommand{\graphM}{Graphical Definition Model}
\newcommand{\toolM}{Tooling Definition Model}
\newcommand{\mapM}{Mapping Model}
\newcommand{\genM}{Generator Model}
\section{Entwicklung des GMF-Modellierungstools}
Die Entwicklung eines GMF"=Modellierungstools setzt ein mit EMF erzeugtes Metamodell und die dafür generierten Java-Klassen voraus. Darauf aufbauend werden mittels GMF drei weitere für die Erzeugung eines Modellierungstools notwendige Modelle erstellt: ein \newWord{\graphM}, ein \newWord{\toolM} und ein \newWord{\mapM}. Das \graphM\ enthält dabei graphische Informationen zu den Modellelementen, die im Modellierungstool dargestellt werden. Die graphischen Informationen werden jedoch unabhängig von den Metamodellelementen definiert. Ein \graphM\ kann so für verschiedene Metamodelle verwendet werden. Des Weiteren wird das \toolM\ für die Definition von beispielsweise Kontextmenüs und Toolbars benötigt. Das \mapM\ schließlich verbindet die Informationen aus dem \graphM\ und dem \toolM\ mit den Elementen des Metamodells. 

\par
Nachdem alle benötigten Modelle definiert sind, wird aus dem \mapM\ und dem Metamodell mittels GMF ein \newWord{\genM} erstellt. In diesem Modell können implementierungsspezifische Details festgelegt werden, wie beispielsweise die Menüeinträge, die für das Modellierungstool erzeugt werden. Aus dem \genM\ wird von \GMF\ das Modellierungstool generiert. \GMF\ folgt somit bei der Erstellung eines Modellierungstools selbst dem Ansatz der \mddn. Abbildung \ref{img_gmf} gibt einen Überblick über den Erstellungsprozess eines Modellierungstools mit GMF.
\mycite{GMFTutorial}

\begin{figure}[h]
\centering
\includegraphics[width=0.85\textwidth]{images/GMF_prozess.png} 
\caption{Erstellung eines Modellierungstools mit GMF, Quelle: angelehnt an \mycite[S. 106]{Stahl07}}
\label{img_gmf}
\end{figure}

\subsection{Entwicklung einer konkreten Syntax der DSL}
Im Rahmen der Entwicklung des Modellierungstools muss neben dem Metamodell die konkrete Syntax der DSL entwickelt werden. Soweit möglich soll die Erstellung eines Modells für eine virtuelle Ausstellung dem Prinzip \Wysi\ folgen. Das bedeutet, dass die graphische Darstellung der Modellelemente so weit wie möglich der Darstellung der Elemente in den durch die Ausstellungssoftware erzeugten Webseiten für eine virtuelle Ausstellung entspricht. Im Rahmen der Entwicklung einer konkreten Syntax der DSL wurden dabei die folgenden Punkte ausgearbeitet:
\begin{itemize}
  \item Darstellung einer Virtual Exhibition
  \item Darstellung von Scenes 
  \item Darstellung von Scene Links und Exhibition Module Links
  \item Darstellung von Exhibition Modules
  \item Darstellung von Slides und Branching Points
  \item Darstellung von Sequences
  \item Darstellung von Bildern und Texten
\end{itemize}
Eine Übersicht über die für die konkrete Syntax entwickelten graphischen Elemente befindet sich in Anhang \ref{anhang_konkrete_syntax}.

\par
%\begin{floatingfigure}[v]{3.5cm}
%\includegraphics[width=3.2cm]{images/konzeption/figures.png} 
%\caption{Geometrische Figuren von GMF}
%\label{img_figures}
%\end{floatingfigure}
Für die Definition der graphischen Darstellung der Modellelemente mittels des Graphical Definition Model gibt es zwei Möglichkeiten bei GMF. Zum einen können unterschiedliche geometrische Figuren, die GMF bereitstellt, wie beispielsweise Rechtecke oder Kreise, einzeln oder in Kombination miteinander, zur Darstellung genutzt werden. Zum anderen kann der Entwickler eigene Java-Klassen schreiben, die für die Darstellung verwendet werden. In Anhang \ref{anhang_gmfgraph} befindet sich ein Screenshot des Graphical Definition Models für das zu entwickelnde Modellierungstool.  %Abbildung \ref{img_figures} zeigt die Auswahl der geometrischen Figuren, die für die Darstellung der Instanz eines Metamodellelements verwendet werden können.
%\begin{figure}[h]
%\centering
%\includegraphics[width=0.3\textwidth]{images/konzeption/figures.png} 
%\caption{Geometrische Figuren von GMF}
%\label{img_figures}
%\end{figure}

GEF nutzt die Java-Bibliothek \newWord{Draw2d} zur graphischen Darstellung von Modellelementen. Für die Umsetzung der konkreten Syntax der DSL wird bei GMF daher Draw2d verwendet. Draw2d stellt unterschiedliche graphische Komponenten, sogenannte \newWord{Figures}, zur Verfügung. Figures können miteinander kombiniert werden, indem sie geschachtelt werden. Das bedeutet, dass eine Figure selbst wieder Figures enthalten kann. 

\par
Draw2d setzt auf dem \SWT\ auf. \SWT\ ist eine Klassenbibliothek von IBM, die es ermöglicht, Benutzeroberflächen zu entwickeln, die dem \newWord{\gls{glos:LAF}} des verwendeten Betriebssystems entsprechen. Dafür stellt SWT unterschiedliche \newWord{Widgets} zur Verfügung. Ein Widget ist eine Komponente einer Benutzeroberfläche, wie beispielsweise ein Button oder ein Textfeld.\footnote{Mehr Informationen zu SWT siehe \mycite{Eclipse}.} Draw2d verwendet SWT, indem es zur Darstellung der Elemente eine \code{SWT Canvas} nutzt. Eine \code{SWT Canvas} ist eine Klasse von \SWT. Sie kann andere SWT-Objekte enthalten oder als Zeichenfläche dienen, auf die mit geeigneten Operationen gezeichnet werden kann \mycite[Kap. 7]{Eclipse}. Eine Klasse von Draw2d, das \code{LightweightSystem}, verbindet die Figures mit der genutzten \code{SWT Canvas}. Abbildung \ref{img_draw2d} zeigt eine schematische Abbildung der Funktionsweise von Draw2d. \mycite{Draw2d}
%Draw2d wird als ``leichtgewichtig'' (\newWord{lightweight}) bezeichnet.%\textquote[\mycite{Draw2d}]{Lightweight means that a figure is simply a java object, with no corresponding resource in the operating system.} 
\begin{figure}[h]
\centering
\includegraphics[width=0.5\textwidth]{images/konzeption/draw2d.png} 
\caption{Draw2d, Quelle: angelehnt an \mycite{Draw2d}}
\label{img_draw2d}
\end{figure}

Bei der Entwicklung eines GMF"=Modellierungstools wird aus den Elementen des Metamodells ein  \newWord{Root-Element} ausgewählt. Das Root-Element hat keine graphische Darstellung. Im erzeugten Modellierungstool wird es durch die \newWord{Zeichenfläche} repräsentiert. Die Zeichenfläche ist der Teil des Modellierungstools, der der Modellierung dient. Auf der Zeichenfläche können hierbei Modellelemente erstellt und bearbeitet werden. Ein Modellelement kann bearbeitet werden, indem es beispielsweise vergrößert oder auf der Zeichenfläche verschoben wird. Im Metamodell des Prototyps ist das Root-Element die \code{Exhibition}. Für die Virtual Exhibition wird daher keine weitere graphische Darstellung benötigt.

\par
Die graphische Darstellung von Scenes wurde mittels Java-Klassen umgesetzt. Hierfür wurde eine Klasse implementiert, die von einer speziell für die Darstellung von Bildern konzipierten Klasse von Draw2d erbt. Eine Scene wird bei der Modellierung durch das für die Scene gewählte Hintergrundbild repräsentiert. Am oberen Rand des Elements befindet sich darüber hinaus ein Balken, in dem der Titel der Scene angezeigt wird.

\par
Scene Links und Exhibition Module Links wurden mittels einer durch GMF bereitgestellten geometrischen Figure umgesetzt. Hierfür wurde ein Rechteck gewählt, da die Scene Links und Exhibition Module Links in den Webseiten einer virtuellen Ausstellung durch schwarz-transparente Rechtecke dargestellt werden, die den Titel des entsprechenden Links enthalten. Bei der Modellierung können Scene Links und Exhibition Module Links auf dem Bild einer Scene hinzugefügt werden. Des Weiteren können sie innerhalb des Bildes verschoben oder in ihrer Größe verändert werden. Gemäß des \Wysi -Prinzips wird dabei die Darstellung der Scene Links und Exhibition Module Links in den generierten Webseiten entsprechend der Positionierung und Größe der Scene Links und Exhibition Module Links im Modell erstellt. Abbildung \ref{img_darstellung_scene} stellt diese Anwendung des \Wysi -Prinzips dar. Der linke Teil der Abbildung zeigt dabei Darstellung einer Scene, eines Scene Links und eines Exhibition Module Links im Modell. Der rechte Teil hingegen zeigt die Darstellung der Elemente in der für die Scene generierten Webseite.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{images/konzeption/darstellung_scene.png} 
\caption{Graphische Darstellung von Scenes, Scene Links und Exhibition Module Links}
\label{img_darstellung_scene}
\end{figure}

Die End-Scene für einen Scene Link oder das Exhibition Module für einen Exhibition Module Link wird durch das Erstellen einer Verbindung festgelegt. Die Verbindung wird dabei durch eine Linie, zwischen dem Rechteck, welches den Scene Link oder Exhibition Module Link abbildet, und dem entsprechenden Modellelement repräsentiert. Diese Art der Repräsentation wurde gewählt, um einen schnellen Überblick über die Navigation durch eine virtuelle Ausstellung zu ermöglichen. In Anhang \ref{anhang_navi} befindet sich ein Screenshot des Modellierungstools, in dem mehrere Scenes miteinander durch Scene Links verbunden sind.

\par
Für die Exhibition Modules wurde das Symbol eines Netzwerks gewählt. Dieses Symbol stellt das Netzwerk von Sequences eines Exhibition Modules dar. In Anhang \ref{anhang_konkrete_syntax} befindet sich eine Abbildung der Darstellung eines Exhibition Modules.

\par
Die Darstellung von Slides und Branching Points in den Webseiten einer virtuellen Ausstellung ist annähernd dieselbe. Einziger Unterschied sind die durch HTML-Links dargestellten Branching Point Choices eines Branching Points. Es wurde daher entschieden, dass Slides und Branching Points im Modell, abgesehen von den Branching Point Choices, ebenfalls auf dieselbe Art dargestellt werden. 

\par
Die Darstellung eines Slides setzt sich aus drei vertikal angeordneten Bereichen zusammen. Im obersten Bereich wird eine Vorschau der Webseite, die für den Slide generiert wird, angezeigt. Dies dient der Einhaltung des \Wysi -Prinzips. Darunter befindet sich jeweils ein Bereich, in dem die dem Slide hinzugefügten Bilder beziehungsweise Texte angezeigt werden. Für die Darstellung von Bildern und Texten wird dabei das entsprechende Bild oder der entsprechende Text verwendet. Branching Points werden auf dieselbe Art wie Slides dargestellt. Sie verfügen jedoch über einen zusätzlichen Bereich, in dem die Branching Point Choices angezeigt werden. Der mehrteilige Aufbau eines Slides oder Branching Points dient dazu, einen Überblick über die hinzugefügten Elemente zu geben. Es ist beispielsweise möglich, einem Slide zwei Bilder hinzuzufügen, gleichzeitig aber ein Slide Template auszuwählen, welches nur ein Bild darstellt. Der Bereich, in dem die Bilder angezeigt werden, ist daher notwendig, um eine Übersicht über alle hinzugefügten Bilder geben zu können. Abbildung \ref{img_darstellung_slide} zeigt die Darstellung eines Slides, der zwei Bilder und einen Text enthält.
\begin{figure}[H]
\centering
\includegraphics[width=0.58\textwidth]{images/konzeption/Slide.png} 
\caption{Graphische Darstellung eines Slides}
\label{img_darstellung_slide}
\end{figure}

Die Darstellung von Slides und Branching Points wurde mit Hilfe der geometrischen Figuren von GMF umgesetzt. Für die Darstellung wurde dabei ein Rechteck gewählt. Diesem Rechteck werden bei der Modellierung weitere Figures, beispielsweise zur Darstellung der dem Slide zugeordneten Bilder, hinzugefügt.

\par
Für die Darstellung von Sequences wurde ebenfalls ein Rechteck gewählt. Dieses Rechteck enthält eine Liste der Titel der Slides und Branching Points, die die Sequence enthält. Die Liste ist in der Reihenfolge sortiert, die die Sequence für die Slides und Branching Points festlegt. Bei der Entwicklung der Darstellung von Sequences wurde die Möglichkeit durchdacht, die Verweise einer Sequence auf Slides und Branching Points, ähnlich wie bei Scene Links,  über Linien darzustellen. Ein Exhibition Module kann jedoch eine sehr hohe Anzahl von Slides, Branching Points und Sequences enthalten. Exhibition Modules in der virtuellen Einsteinausstellung enthielten zum Teil bis zu 50 Slides und Branching Points. Würden die Verweise der Sequences durch Linien dargestellt werden, wäre die Struktur eines Exhibition Modules nicht mehr zu erkennen. Eine übersichtliche Anordnung von Slides, Branching Points und Sequences wäre dabei nicht möglich.


\subsection{Generierung des Modellierungstools}
Für die Generierung eines  GMF"=Modellierungstools muss neben dem \graphM\ das Tooling Definition Model erstellt werden. In diesem Modell wird unter anderem festgelegt, welche Funktionen in der \newWord{Palette} dargestellt werden. Die Palette befindet sich neben der Zeichenfläche für die Modellierung. Sie dient der Erstellung der Modellelemente. Abbildung \ref{img_palette} zeigt die Palette des entwickelten Modellierungstools. Das Tooling Definition Model des Prototyps befindet sich in Anhang \ref{anhang_gmftool}.

\begin{floatingfigure}[v]{3.7cm}
\centering
\includegraphics[width=3.4cm]{images/konzeption/palette.png} 
\caption{Palette des GMF"=Modellierungstools}
\label{img_palette}
\end{floatingfigure}
GMF erzeugt automatisch drei Funktionen für eine Palette. In die Palette wird zunächst ein durch einen weißen Pfeil repräsentiertes Auswahlwerkzeug eingefügt. Dieses Auswahlwerkzeug dient dazu, die Elemente des Modells auszuwählen, um sie beispielsweise zu bearbeiten oder zu bewegen. Des Weiteren wird der Palette eine Zoom-Funktion hinzugefügt, mit der die Ansicht des Modells vergrößert und verkleinert werden kann. Als drittes wird in die Palette eine Funktion zum Erzeugen von Notizen eingefügt. Diese Notizen entsprechen den Notizen in der UML.

\par
Nachdem das Tooling Definition Model und das Graphical Definition Model definiert wurden, ist der nächste Schritt in der Entwicklung eines GMF"=Modellierungstools die Erstellung des Mapping Models. Das Mapping Model legt beispielsweise fest, welches Modellelement durch welche Darstellung, die im Graphical Definition Model festgelegt ist, repräsentiert wird. Des Weiteren gibt es an durch welche Funktion der Palette, die im Tooling Definition Modell definiert ist, ein Modellelement erzeugt werden kann. Abbildung \ref{img_gmfmap} zeigt einen Ausschnitt des Mapping Models des Prototyps. In diesem Ausschnitt sind die folgenden drei Elemente eines Mapping Models enthalten: ein \code{Canvas Mapping}, eine \code{Top Node Reference} und ein \code{Node Mapping}.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{images/konzeption/mapping_model.png} 
\caption{Ausschnitt aus dem Mapping Model des Prototyps}
\label{img_gmfmap}
\end{figure}

Mit Hilfe des Elements \code{Canvas Mapping} wird festgelegt, welches Element des Metamodells als Root-Element verwendet wird. Eine \code{Top Node Reference} wird für Modellelemente verwendet, die direkt auf der Zeichenfläche des Modellierungstools erzeugt werden können. Das Element \code{Node Mapping} schließlich legt das Metamodellelement für die \code{Top Node Reference}, dessen Darstellung und die Funktion der Palette zur Erzeugung des Modellelements fest. Dieses Element verbindet somit das Metamodell mit dem \graphM\ und dem \toolM. Im rechten Teil von Abbildung \ref{img_gmfmap} sind die Eigenschaften des \code{Node Mapping} zu sehen. Die Eigenschaft \code{Element} legt dabei das Metamodellelement fest, die Eigenschaft \code{Diagram Node} die graphische Darstellung des Modellelements und die Eigenschaft \code{Tool} die Funktion zur Erzeugung des Modellelements.

\par
Aus dem Mapping Model und dem Metamodell wurde das Generator Model für den Prototyp erzeugt. Aus diesem wurde daraufhin ein Eclipse-Projekt generiert. Dieses Eclipse-Projekt enthält die Implementierung des Modellierungstools. In dem \genM\ wurde dabei unter anderem der Name des generierten Eclipse-Projektes, \code{org.jat.exhibition.diagram}, festgelegt. Dieses Projekt wurde zur Anpassung des Modellierungstools an die definierten Anforderungen um manuell geschriebenen Quelltext erweitert.

\subsection{Aufbau der Benutzeroberfläche}
Die Benutzeroberfläche des als Prototyp entwickelten Modellierungstools hat einen dreiteiligen Aufbau. Dieser setzt sich aus einem Teil für die Modellierung, einem Teil, in dem die Eigenschaften der ausgewählten Modellelemente angezeigt werden, und einer Baumansicht des aktuell im Modellierungstool zu bearbeitenden Modells zusammen. Anhang \ref{anhang_editor} enthält eine Abbildung, die den Aufbau des Modellierungstools darstellt. Des Weiteren verfügt der Prototyp über zwei unterschiedliche Menüleisten. Eine Menüleiste wird am oberen Bildschirmrand dargestellt. Diese ist das \newWord{Hauptmenü} der Anwendung. Hier befinden sich beispielsweise Funktionen zum Beenden des Programms oder zum Öffnen von Dateien. Das Hauptmenü wird dabei von der Eclipse RCP entsprechend dem \gls{glos:LAF} des Betriebssystems angepasst. Unter Windows beispielsweise wird diese Menüleiste im Gegensatz zu OS X nicht am oberen Bildschirmrand, sondern am oberen Rand des Anwendungsfensters, angezeigt. Dort wird unter OS X hingegen die zweite Menüleiste des Prototyps angezeigt. Diese wird als \newWord{\gls{glos:coolbar}} bezeichnet. Die Coolbar wird durch GMF automatisch mit Funktionen, beispielsweise zum Speichern der geöffneten Dateien, gefüllt. Der Hauptmenü- und der Coolbar-Mechanismus werden von der Eclipse RCP bereitgestellt. In Anhang \ref{anhang_menuleisten} befindet sich ein Screenshot, der den Prototyp mit beiden Menüleisten zeigt.

\par
Der Teil des Modellierungstools, der der Modellierung dient, besteht aus der Zeichenfläche und der Palette. Dieser Teil wird von GMF automatisch generiert. Er wird im Folgenden als \newWord{\gls{glos:editor}} bezeichnet. Die Darstellung eines Modells oder eines Teils eines Modells im Editor wird dabei als \newWord{\gls{glos:diagramm}} bezeichnet. Des Weiteren generiert GMF den Teil des Modellierungstools, in dem die Eigenschaften der Modellelemente angezeigt werden. Dieser Teil wird nachfolgend als \newWord{Properties-View} bezeichnet. Für die Anzeige der Eigenschaften eines Modellelements im Properties-View muss hierfür das Modellelement mittels des Auswahlwerkzeugs ausgewählt werden. Der dritte Teil der Benutzeroberfläche, die Baumansicht, wurde darüber hinaus speziell für den Prototyp entwickelt.

\par
Bei der Entwicklung des Prototyps wurde deutlich, dass das Diagramm schnell unübersichtlich wird, wenn das Modell mehr als zehn Elemente enthält. Daher wurde entschieden, die Modellierung der Scenes von der Modellierung der Exhibition Modules zu trennen. Für die Erstellung und Bearbeitung einer virtuellen Ausstellung werden daher mehrere Diagramme verwendet. Zunächst gibt es ein Diagramm zur Modellierung der Scenes und der Navigation durch die Scenes. Dieses Diagramm wird im Folgenden als \newWord{Hauptdiagramm} bezeichnet. Im Hauptdiagramm können Scenes, Exhibition Modules, Scene Links und Exhibition Module Links erstellt werden. Zur Modellierung der Inhalte eines Exhibition Modules wird darüber hinaus für jedes Exhibition Module ein weiteres Diagramm verwendet, ein \newWord{Unterdiagramm}. In diesem Unterdiagramm können Slides, Branching Points und Sequences erstellt werden. Ein Unterdiagramm wird durch einen Doppelklick auf das entsprechende Exhibition Module geöffnet. Der Editor passt sich dabei dem zu bearbeitenden Diagramm an. Das bedeutet zum einen, dass die Palette Diagramm-spezifische Funktionen bereitstellt. Zum anderen können sich die Einträge in der Menüleiste des Programms für das Hauptdiagramm von den Einträgen für das Unterdiagramm unterscheiden.

\par
GMF unterstützt die Erzeugung eines Modellierungstools, das mit Unterdiagrammen arbeitet. Zu diesem Zweck müssen zunächst ein zusätzliches Mapping Model, ein zusätzliches Graphical Definition Model und ein zusätzliches Tooling Definition Model für den Editor des Unterdiagramms erstellt werden. In diesen Modellen werden die Eigenschaften des Unterdiagramms spezifiziert. Im Mapping Model für das Unterdiagramm wird daraufhin für das \code{Canvas Mapping} das Metamodellelement festgelegt, welches die im Unterdiagramm zu modellierenden Metamodellelemente enthält. Bei dem entwickelten Prototyp war dieses Element das Metamodellelement \code{ExhibitionModule}. Im Anschluss daran wird im Mapping Model des Hauptdiagramms dasjenige \code{Node Mapping} ausgewählt, welches dem im Unterdiagramm als \code{Canvas Mapping} gesetzten Metamodellelement entspricht. Für dieses \code{Node Mapping} wird die Eigenschaft \code{Related Diagrams} auf das \code{Canvas Mapping} des Unterdiagramms gesetzt. Für das Mapping Model des Unterdiagramms wird ebenfalls ein Generator Model erstellt. Aus diesem Generator Model wird dann ein zweites Eclipse-Projekt erzeugt. Für den Prototyp wurde dabei ein Projekt namens \code{org.jat.mediastation.diagram} generiert. Dieses Projekt wurde als Plugin in das Eclipse-Projekt für das Hauptdiagramm eingebunden.

\par
Das Eclipse-Projekt für das Hauptdiagramm wird im Folgenden als \newWord{Hauptprojekt} des Prototyps bezeichnet. In diesem Projekt werden die Einstellungen für die \RCP -Anwendung wie beispielsweise die Anordnung von Editor, Properties-View und Baumansicht, vorgenommen. Das Hauptprojekt verwendet neben dem Plugin für das Unterdiagramm weitere speziell für den Prototyp entwickelte Plugins, die nachfolgend aufgeführt werden.

\begin{itemize}
  \item \code{org.jat.filehandler}
  \par
  Dieses Plugin unterstützt den projektübergreifenden Umgang mit Dateien.  
  \item \code{org.jat.templates}
  \par
  Dieses Plugin verwaltet die Templates des Modellierungstools wie beispielsweise die Slide Templates, die für die Slides und Branching Points verwendet werden.
  \item \code{org.jat.workspace}
  \par
  Für die Erstellung einer virtuellen Ausstellung wird ein \newWord{Projekt-Verzeichnis} angelegt. In diesem Verzeichnis werden die verwendeten Dateien, wie beispielsweise in der virtuellen Ausstellung verwendete Bilder, gespeichert. Darüber hinaus gibt es unterschiedliche temporäre Dateien, die in diesem Verzeichnis gespeichert werden. Dieses Plugin dient dabei der Verwaltung des Projekt-Verzeichnisses.
\end{itemize}

\subsection{Validierung des Modells}
Eine virtuelle Ausstellung besteht im Durchschnitt aus 20 bis 30 Scenes und etwa 10 bis 20 Exhibition Modules. Die Exhibition Modules enthalten dabei unterschiedlich viele Slides, Branching Points und Sequences. Je mehr Elemente das Modell einer virtuellen Ausstellung enthält, desto eher kommt es zu Modellierungsfehlern. Modellierungsfehler können beispielsweise Scenes sein, die nicht über einen Scene Link mit einer anderen Scene verbunden sind, oder Slides, auf die in keiner Sequence verwiesen wird. Solche Fehler führen dazu, dass es beispielsweise Elemente im Modell gibt, die in der Website der virtuellen Ausstellung nicht verwendet werden. Für den Prototyp wurde daher eine Funktionalität zur Validierung von Modellen entwickelt.

\par
Die Validierung eines Modells wird beim Prototyp durch den Anwender veranlasst. Die Ergebnisse der Validierung werden dabei in einer tabellarischen Übersicht angezeigt. Zusätzlich wird jedes Modellelement, welches gegen einen Constraint verstößt, durch ein Icon gekennzeichnet. Anhang \ref{anhang_validierung} zeigt einen Screenshot des Prototyps nach der Validierung des Modells. Die Validierungsergebnisse sind in drei Kategorien eingeteilt:
\begin{itemize}
 \item \textbf{Fehler}
 \par
 Validierungsergebnisse, die als Fehler eingestuft werden, kennzeichnen Modellierungsfehler, die in der generierten Website dazu führen, dass ein Besucher der Website Probleme feststellt. Solch ein Problem kann beispielsweise ein Exhibition Module Link sein, für den kein Exhibition Module angegeben wurde. Für den Exhibition Module Link wird hierbei ein HTML-Link generiert, dessen Anklicken keinen Effekt hat.
 \item \textbf{Warnungen}
 \par
 Validierungsergebnisse, die als Warnungen eingestuft werden, kennzeichnen Modellierungsfehler, die jedoch in den generierten Webseiten zu keinen Problemen führen, die von Besuchern der Website wahrgenommen werden. Warnungen dienen dazu, den Modellierer darauf aufmerksam zu machen, dass das Modell Mängel aufweist, wie beispielsweise Slides, auf die von keiner Sequence verwiesen wird.
 \item \textbf{Informationen}
 \par
 Validierungsergebnisse, die als Informationen eingestuft werden, kennzeichnen Modellierungsfehler, die zu keinen Problemen im Modell oder in der generierten Website führen. Informationen dienen ausschließlich dazu, den Modellierer auf Eigenschaften des Modells, die möglicherweise ungewollt sind, aufmerksam zu machen.
\end{itemize}

\par
Die Kategorisierung der Validierungsergebnisse wurde auf diese Art vorgenommen, um den Modellierer bei der Erstellung eines Modells so wenig wie möglich einzuschränken. Es gibt beispielsweise Modellierungsfehler die vom Modellierer gewollt sind. Eine erste veröffentlichte Version einer virtuellen Ausstellung kann zum Beispiel noch unvollständig sein. Das Modell wird zu einer zweiten Version ausgearbeitet. Die erste Version des Modells kann dabei bereits Inhalte, zum Beispiel in Form von Slides, umfassen, die jedoch noch nicht veröffentlicht werden. Solche Slides sind zu diesem Zweck in keiner Sequence enthalten und werden daher bei der Validierung durch eine Warnung gekennzeichnet.

\par
GMF unterstützt die Modellvalidierung durch die automatische Generierung eines Validierungsmechanismus. Hierfür werden im Mapping Model sogenannte \code{Audit Rules} definiert. Eine \code{Audit Rule} beinhaltet einen Constraint. Dieser Constraint kann mit OCL, mit Java oder mit \newWord{\useGlosentry{glos:regex}{Regulären Ausdrücken}} formuliert sein. Für die Definition der Constraints des Prototyps wurde Java gewählt. Bei der Generierung des Modellierungstools durch GMF wurde dann ein Klasse erzeugt, die für jede \code{Audit Rule} eine Methode bereitstellt. Diese Methoden wurden entsprechend der Constraints manuell implementiert. Listing \ref{listing_constraint} zeigt eine solche Methode zur Überprüfung, ob für einen Scene Link oder einen Exhibition Module Link eine End-Scene beziehungsweise ein Exhibition Module festgelegt wurde.
\lstinputlisting[frame=single, numbers=left, tabsize=3, label=listing_constraint, caption={Definition eines Constraints}, language=Java, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]{listings/lst_constraint}

\subsection{Entwicklung von Slide Templates}
Eine spätere Version der Ausstellungssoftware soll die Verwaltung der Slide Templates ermöglichen. Dazu gehört unter anderem das Hinzufügen und Bearbeiten von Slide Templates. Die Template-Sprache der Slide Templates soll daher möglichst einfach erlernbar sein. Im Hinblick auf das Format der durch den Codegenerator erzeugten Dateien wird \gls{glos:XHTML} in Verbindung mit CSS zur Definition der Slide Templates gewählt. XHTML ist eine Neuimplementierung von HTML auf Basis von XML. Der Vorteil von XHTML-Dokumenten ist dabei, dass sie mit XML-Werkzeugen angezeigt und bearbeitet werden können \mycite{xhtml}. Für die Erstellung eines Slide Templates wird eine Untermenge der XHTML-Elemente verwendet.

\par
Für die Definition eines Slide Templates werden zwei Dateien benötigt. In der ersten Datei wird unter Verwendung des XHTML-Elements \code{div} das Grundgerüst eines Slide Templates definiert. Diese Datei ist das \newWord{JAT Page Template}. In der zweiten Datei wird durch CSS-Angaben die Positionierung der \code{div}-Elemente der ersten Datei festgelegt. Ein JAT Page Template muss dabei einen XHTML-Kommentar enthalten. In diesem sind eine Id, ein Titel, eine Beschreibung und der Name der zugehörigen CSS-Datei angegeben. Des Weiteren haben JAT Page Templates die Dateiendung \code{.jatpt} und befinden sich in einem speziellen Verzeichnis innerhalb des Plugins \code{org.jat.templates}. Die zu den JAT Page Templates gehörenden CSS-Dateien befinden sich ebenfalls in einem speziellen Verzeichnis dieses Plugins. Die Quelltexte eines JAT Page Templates und der dazu gehörenden CSS-Datei befinden sich in Anhang \ref{anhang_slide_template}.

\par
Die so definierten Slide Templates werden dem Anwender bei der Bearbeitung eines Slides oder Branching Points im Prototyp zur Verfügung gestellt. 
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{images/konzeption/slide_templates.png} 
\caption{Klappmenü zur Auswahl des Slide Templates}
\label{img_slide_templates}
\end{figure}
Die in einem JAT Page Template angegebene Beschreibung erscheint dabei in einem Klappmenü im Properties-View des Modellierungstools. Abbildung \ref{img_slide_templates} zeigt die Eigenschaften eines Slides und das Klappmenü zur Auswahl des Slide Templates.

\subsection{Funktionsweise des Modellierungstools}
Der Arbeitsbereich des Prototyps innerhalb des Filesystems, im Folgenden auch als \newWord{Workspace} bezeichnet, ist das Projekt-Verzeichnis. In diesem Projekt-Verzeichnis werden hierbei die gesamten Dateien gespeichert, die für eine mit dem Prototyp erstellte virtuelle Ausstellung benötigt werden. Im Modell gespeicherte Pfade, wie beispielsweise die Pfadangaben für die verwendeten Bilder, sind relativ bezogen auf den Workspace. Der Grund hierfür liegt darin, dass der Austausch von virtuellen Ausstellungen zwischen unterschiedlichen Rechnern ermöglicht werden soll. Für die Bearbeitung eines Modells auf einem anderen Rechner müssen lediglich das Projekt-Verzeichnis und das Modellierungstool auf diesem Rechner zur Verfügung stehen. Damit soll die Möglichkeit geschaffen werden, dass mehrere Modellierer im Wechsel an einem Modell arbeiten können.

Bei der Erstellung einer neuen virtuellen Ausstellung wird zunächst ein Projekt-Verzeichnis angelegt. In diesem Verzeichnis werden die zwei Dateien gespeichert, mit denen ein GMF"=Modellierungstool arbeitet. Die zwei unterschiedlichen Dateien werden im Folgenden als \newWord{Modell-Datei} und \newWord{Diagramm-Datei} bezeichnet. Die Modell-Datei enthält die Informationen über das Modell. Die Diagramm-Datei enthält die Informationen zur graphischen Darstellung der Modellelemente. Das Hauptdiagramm und die Unterdiagramme des Modellierungstools verwenden dieselbe Modell-Datei und dieselbe Diagramm-Datei.

In einem GMF"=Modellierungstool können mehrere Editoren geöffnet sein. Jeder geöffnete Editor wird dabei über einen Reiter am oberen Rand des Teils eines GMF"=Modellierungstools angezeigt, in dem die Editoren dargestellt werden. Anhang \ref{anhang_tabs} enthält einen Screenshot des Prototyps mit mehreren geöffneten Editoren. Der Prototyp verfügt über zwei Arten von Editoren, einem Editor für das Hauptdiagramm und einem Editor für die Unterdiagramme. Die Editoren können mehrfach geöffnet sein und jeweils ein anderes Modell darstellen. 

Bei der Erstellung einer virtuellen Ausstellung sind in der Regel mehrere Editoren geöffnet. Ein Editor stellt dabei das Hauptdiagramm dar. Darüber hinaus ist der Editor für die Unterdiagramme unter Umständen für jedes Exhibition Module geöffnet. Der Editor eines GMF"=Modellierungstools verwaltet ein Modell intern über die sogenannte \newWord{Editing Domain}. Jeder geöffnete Editor des Prototyps bildet das Modell über eine eigene Editing Domain ab. Die Editing Domains sind hierbei identisch, da das Hauptdiagramm und die Unterdiagramme auf dieselben Dateien zugreifen. Wird in einem Editor das Modell geändert, bemerken die anderen Editoren dies jedoch erst, wenn sie aktiviert, das heißt erneut angezeigt, werden. Dies kann dann zu Problemen führen, wenn in einem Editor die Änderungen am Modell nicht gespeichert wurden. Die Editing Domains der Editoren sind in diesem Fall nicht mehr identisch. Bei der Entwicklung des Prototyps wurde über die Möglichkeit nachgedacht, das Modell automatisch zu speichern, wenn der Benutzer den Editor wechselt. Dies wurde jedoch nicht umgesetzt, um die Speicherung von ungewollten Änderungen zu vermeiden.

Wichtiger Bestandteil einer virtuellen Ausstellung sind Bilder. Bilder werden für Scenes, Slides und Branching Points verwendet. Ein Bild wird beim Hinzufügen zum Modell einer virtuellen Ausstellung in das Projekt-Verzeichnis kopiert. Dieses enthält hierfür zwei Verzeichnisse. In einem Verzeichnis sind die Bilder der Scenes gespeichert. In dem anderen Verzeichnis sind die Bilder, die in den Slides und Branching Points verwendet werden, gespeichert.

Der Prototyp ermöglicht es, die Bilder, die in den Slides und Branching Points verwendet werden, zu skalieren. Ein Bild hat dafür die Eigenschaften \code{width} und \code{height}. Die Größe eines Bildes wird dann verändert, wenn beide Eigenschaften nicht Null sind. Das Bild wird dabei so groß wie möglich proportional skaliert, ohne dass die neue Höhe und Breite des Bildes die angegebenen Werte überschreiten. Abbildung \ref{img_bild_scale} zeigt das Prinzip, das bei der Skalierung angewandt wird. Das Originalbild bleibt bei der Skalierung unverändert. Es wird lediglich eine skalierte Kopie des Originalbildes erstellt.
\begin{figure}[h]
\centering
\includegraphics[width=0.7\textwidth]{images/konzeption/bildskalierung2.png} 
\caption{Skalierung eines Bildes}
\label{img_bild_scale}
\end{figure}

\section{Entwicklung des Codegenerators}
Der im Rahmen der Entwicklung des Prototyps konzipierte und implementierte Codegenerator besteht aus zwei Eclipse-Plugins: \code{org.jat.generation.engine} und \code{org.jat.generation}. Er wurde speziell für die Generierung von HTML-Seiten entwickelt. Der Codegenerator arbeitet dabei mittels Templates. Zur Beschreibung der Templates wurde im Rahmen der Entwicklung des Generators eine Template-Sprache konzipiert. Die Template-Engine ist mittels des Plugins \code{org.jat.generation.engine} umgesetzt. Sie ist für das Parsen der Templates und die Generierung von Dateien anhand der Templates zuständig. Das Plugin \code{org.jat.generation} übernimmt darauf aufbauende Aufgaben, wie beispielsweise die Zuordnung der Templates zu den unterschiedlichen Elementen des Modells.

\subsection{Entwicklung einer Template-Sprache}
Die Template-Sprache, die für den Prototyp entwickelt wurde, schreibt vor, dass Templates aus beliebigem, statischem Text und Tags zusammengesetzt sind. Tags werden dabei ausgezeichnet, indem sie mit der Zeichenkombination \code{@\%} beginnen und mit \code{\%@} enden. Die Zeichen ``@'' und ``\%'' wurden für die Auszeichnung ausgewählt, da sie in Kombination miteinander sehr selten innerhalb einer HTML-Seite vorkommen. Eine Suchanfrage bei \newWord{\gls{glos:Google}} nach dieser Zeichenkombination lieferte beispielsweise keine Ergebnisse. Der Name des Tags, der zwischen \code{@\%} und \code{\%@} steht, kann beliebig gewählt werden. Ein Tag hat somit die Form \code{@\%tagname\%@}. Anhang \ref{anhang_template_jatgt} enthält ein Template zur Generierung von HTML-Seiten für die Exhibition Modules einer virtuellen Ausstellung. 

Die Template-Sprache wurde bewusst generisch entwickelt, um die Möglichkeit zu schaffen, den Codegenerator später um weitere Komponenten zu erweitern. Des Weiteren schränkt die Template-Sprache den Entwickler nur minimal ein. Die Templates können jeden beliebigen Text enthalten und sind bezüglich des Formats, das generiert werden kann, nicht festgelegt. Weitere Komponenten könnten somit beispielsweise statt HTML-Dateien SQL-Skripte erstellen. Mit Hilfe dieser Skripte würden in einer SQL-Datenbank entsprechend der Modellelemente Tabellen erstellt werden. Die im Modell enthaltenen Informationen würden des Weiteren durch diese Skripte in die Tabellen eingefügt werden. Mittels zum Beispiel JSF könnte eine virtuelle Ausstellung dann im Internet präsentiert werden.

\par
Die von dem entwickelten Codegenerator verarbeitbaren Templates werden im Folgenden als \newWord{JAT Generation Templates}, kurz \newWord{Generation Templates}, bezeichnet. Ein Generation Template hat die Dateiendung \code{.jatgt}. Des Weiteren muss es sich in dem Verzeichnis \code{templates} innerhalb der Template-Engine befinden.

\newpage
\subsection{Entwicklung der Template-Engine}
Die Template-Engine übernimmt innerhalb des Generierungsprozesses die folgenden drei Aufgaben.
\begin{itemize}
  \item Einlesen des Generation Templates
  \item Ersetzen der Tags innerhalb eines Templates durch entsprechende Zeichenketten
  \item Speicherung des daraus resultierenden Textes in einer Datei
\end{itemize}
Die Template-Engine wird dabei für jede zu generierende Datei separat aufgerufen. Dadurch wird der Prozess der Template-basierten Erzeugung einer Datei gekapselt. Diese Kapselung ermöglicht die Wiederverwendung der Template-Engine. Sie ist somit nicht ausschließlich auf die Verwendung innerhalb des entwickelten Codegenerators festgelegt. Die Template-Engine kann darüber hinaus auch in einem anderen System verwendet werden.

\par
Bei der Initialisierung wird der Template-Engine der Pfad des Verzeichnisses übergeben, in welchem die generierten Dateien gespeichert werden sollen. Dieses Verzeichnis wird im Folgenden als das \newWord{Hauptverzeichnis} bezeichnet. Durch die Festlegung eines Hauptverzeichnisses sollen Fehler vermieden werden, die dazu führen, dass die Dateien der Website einer virtuellen Ausstellung an unterschiedlichen Orten im Filesystem gespeichert werden. Mit Hilfe der Template-Engine können dabei Unterverzeichnisse des angegebenen Verzeichnisses erstellt werden. Das Hauptverzeichnis bleibt jedoch dasselbe. Bei Bedarf kann das Hauptverzeichnis über eine Methode der Template-Engine für alle folgenden Generierungen geändert werden. 

\par
Beim Aufruf der Funktion zur Generierung einer Datei werden der Template-Engine der Name der zu generierenden Datei, der Name des zu verwendenden Templates und eine \newWord{Map} der zu ersetzenden Variablen übergeben. Eine Map ist eine Datenstruktur, die aus Schlüssel-Werte-Paaren aufgebaut ist.\footnote{Mehr zu Maps bei Java siehe \mycite[Kap. 11.4]{Java}.} Die Schlüssel der Map sind dabei die Tags. Die Werte sind die für die Tags einzusetzenden Zeichenketten. Die Template-Engine liest das entsprechende Template ein, ersetzt die darin vorkommenden Tags durch die entsprechenden Werte in der Map und speichert das Ergebnis unter dem angegebenen Namen.

\par
Bei dem Ersetzungsprozess der Tags wird das Template Zeile für Zeile von der Template-Engine eingelesen. Für jede Zeile werden hierbei die in der Map übergebenen Tags durch die entsprechenden Werte der Reihe nach ersetzt. Tags, die nicht in der Map spezifiziert sind, werden aus dem Text gelöscht. Hierfür werden reguläre Ausdrücke verwendet. Abbildung \ref{img_aktivitaet_tags} zeigt das Aktivitätsdiagramm des Ersetzungsprozesses der Tags. In Anhang \ref{anhang_listing_regex} befindet sich der Quelltext zur Ersetzung der Tags. 
\begin{figure}[h]
\centering
\includegraphics[width=0.8\textwidth]{images/konzeption/aktivitaet_tags.png} 
\caption{Aktivitätsdiagramm zum Ersetzungsprozess der Tags}
\label{img_aktivitaet_tags}
\end{figure}

Die beschriebene Vorgehensweise beim Ersetzungsprozess ermöglicht es, Tags durch Zeichenketten zu ersetzen, die wiederum Tags enthalten. So eingesetzte Tags werden wie Tags behandelt, die im ursprünglichen Template vorhanden sind. Hierbei ist jedoch die Reihenfolge, die die Tags in der Map haben, wichtig. Wird für Tag \code{A} eine Zeichenkette eingesetzt die Tag \code{B} enthält, muss Tag \code{B} in der Reihenfolge der Tags in der Map nach Tag \code{A} kommen. Nur dann wird Tag \code{B} mit dem entsprechenden Wert ersetzt.


\subsection{Funktionsweise des Codegenerators}
Das Plugin \code{org.jat.generation} nutzt die Funktionalität der Template-Engine und baut darauf auf. Es hat dabei die folgenden Aufgaben:
\begin{itemize}
  \item Dynamisches Erstellen der JAT Generation Templates
  \item Zusammenstellen der erforderlichen Informationen für den Aufruf der Template-Engine
  \item Kopieren von Dateien, die für die Website einer virtuellen Ausstellung benötigt werden
\end{itemize}

Die Generation Templates werden vom Codegenerator zu Beginn des Generierungsprozesses dynamisch erstellt. Dies hat den Grund, dass der Prototyp in einer späteren Entwicklungsphase dahingehend erweitert werden soll, dass die Templates vom Anwender mit Hilfe der Ausstellungssoftware angepasst werden können. 

Für die Erzeugung eines Generation Templates wird ein sogenanntes \newWord{Master-Template} benötigt. Das Master-Template ist spezifisch für den Typ der Webseite, die erstellt werden soll. Für eine virtuelle Ausstellung gibt es zwei Master-Templates: ein Master-Template für Scenes und ein Master-Template für Exhibition Modules. Ein Master-Template ist hierbei eine \useGlosentry{glos:XHTML}{XHTML-Datei} mit der Dateiendung \code{.jatmt}. In das Master-Template werden von dem Codegenerator für das Master-Template spezifische Tags eingesetzt. Die einzusetzenden Tags werden dabei über eine XML-Datei festgelegt. Ein Eintrag in der XML-Datei hat die in Listing \ref{listing_tag_eintrag} gezeigte Form.
\newpage
\lstinputlisting[frame=single, numbers=left, tabsize=3, label=listing_tag_eintrag, caption={Definition eines einzusetzenden Tags}, language=XML, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]{listings/lst_tag_eintrag}
Das XML-Element \code{element} definiert hierbei das XHTML-Element des Master-Templates, das modifiziert werden soll. Die Attribute \code{name} und \code{id} dienen dazu, das XHTML-Element eindeutig zu bestimmen. Des Weiteren spezifiziert das XML-Element \code{attribute} ein Attribut, das in das XHTML-Element eingesetzt wird. Das XML-Element \code{content} hingegen spezifiziert den Inhalt, der in das XHTML-Element eingesetzt wird. Der Codegenerator erzeugt für den in Listing \ref{listing_tag_eintrag} gezeigten Eintrag, den in Listing \ref{listing_tag_code} dargestellten XHTML-Code.
\lstinputlisting[frame=single, numbers=left, tabsize=3, label=listing_tag_code, caption={In Master-Template eingesetzte Tags}, language=HTML, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]{listings/lst_tag_code}

Für jedes Master-Template gibt es eine Generator-Klasse, die die für die Generierung benötigten Daten zusammenstellt und aufbereitet. Diese Generator-Klassen werden durch eine abstrakte Klasse, den \code{AbstractGenerator}, generalisiert. Die Generator-Klassen werden von der Schnittstelle des Plugins \code{org.jat.generation}, dem \code{JatGenerationService}, aufgerufen und verwaltet. 

Die Schnittstelle der Template-Engine ist die Klasse \code{JatGenerationEngineFactory}.  Diese ist in Anlehnung an das \newWord{Abstract Factory}-Entwurfsmuster und das \newWord{Strategy}-Pattern entwickelt worden. Im Folgenden wird diese Klasse daher auch als \newWord{Factory} bezeichnet. Der \code{JatGenerationService} erhält über die Factory ein das Interface \code{JatGeneratorEngine} implementierendes Objekt. Dieses Objekt stellt eine Methode bereit, mit der Dateien eines spezifischen Formats, wie beispielsweise HTML-Dateien, generiert werden können. Das Format der zu generierenden Dateien wird dabei über einen Parameter festgelegt, der der Factory übergeben wird. Bei der Erzeugung der Generator-Klassen reicht der \code{JatGenerationService} die \code{JatGeneratorEngine} an die Generator-Klassen weiter. Abbildung \ref{img_generator_classes} zeigt das Zusammenwirken der Klassen des Codegenerators.

Die Generator-Klassen erzeugen die Generation Templates und erstellen die Map, die für den Aufruf der Template-Engine benötigt wird. In der Map werden dabei Informationen aus dem Modell und Daten zur Darstellung der Modellelemente gespeichert. Des Weiteren übernehmen die Generator-Klassen das Kopieren der für die Webseite benötigten Dateien wie beispielsweise Bilder und CSS-Dateien. 
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{images/konzeption/generators.png} 
\caption{Für die Generierung verantwortliche Klassen}
\label{img_generator_classes}
\end{figure}
Mit Hilfe der \code{JatGeneratorEngine} schließlich erzeugen die Generator-Klassen die Webseiten für die virtuelle Ausstellung, die durch das Modell abgebildet wird. Die generierten Webseiten werden dabei in einem Verzeichnis \code{html} im Projekt-Verzeichnis der virtuellen Ausstellung gespeichert.



\section{Verwendete Entwurfsmuster}
Bei der Entwicklung des Prototyps wurden hauptsächlich das \newWord{Plugin}-Pattern und das \newWord{Singleton}-Pattern umgesetzt. Darüber hinaus wurden wenige Entwurfsmuster verwendet. Dies ist darin begründet, dass der Hauptteil des Quelltextes des Prototyps durch GMF generiert wurde. Die manuell implementierten Teile des Prototyps erweitern dabei hauptsächlich den generierten Quelltext und setzen somit auf den bereits implementierten Entwurfsmustern auf.

Das Plugin-Konzept von Eclipse basiert auf dem \newWord{Plugin}-Pattern, wie es bei Fowler et al. zu finden ist.\footnote{Siehe hierzu \mycite[S. 499ff.]{fowlerPattern}} Gemäß diesem Konzept wurden spezielle Funktionalitäten des Prototyps, wie beispielsweise die Template-Verwaltung oder der Codegenerator, über Plugins zur Verfügung gestellt. Die Plugins trennen dabei einen ``öffentlichen Teil'' von einem ``internen Teil''. Im ``öffentlichen Teil'' des Plugins befinden sich die Klassen, die durch das Plugin zur Verfügung gestellt werden. Der ``interne Teil'' enthält nicht außerhalb des Plugins zur Verfügung stehende Klassen.

Bei der Umsetzung des Plugins \code{org.jat.workspace} wurde das Singleton-Pattern angewandt.\footnote{Vgl. hierzu das Entwurfsmuster ``Singleton'' bei Gamma et al. \mycite[S. 127]{gamma}.} Beim Singleton-Pattern wird sichergestellt, dass von einer Klasse nicht mehr als ein Objekt existiert. Der Prototyp verwendet das Singleton-Pattern, um von unterschiedlichen Klassen in zum Teil unterschiedlichen Plugins auf denselben Workspace zuzugreifen. Beim ersten Zugriff auf den Workspace wird dabei ein Objekt der Klasse, die das Singleton-Pattern umsetzt, erzeugt. Dieses Objekt hält die notwendigen Informationen über den Workspace. Weitere Zugriffe auf den Workspace erfolgen ausschließlich über dieses Objekt. In Anhang \ref{anhang_singleton} befindet sich ein Auszug des Quelltextes der Klasse, die das Singleton-Pattern umsetzt. Der vollständige Quelltext befindet sich auf der der Diplomarbeit beiliegenden CD.

\section{Implementierungsdetails}
Bei der Entwicklung des Prototyps erwies sich die Umsetzung einiger Details als komplizierter als erwartet. Dies war zum großen Teil bedingt durch GMF. Im Folgenden wird die Entwicklung von drei dieser Details ausführlicher beschrieben.

\subsection{Baumansicht des Modellierungstools}
Die Baumansicht des Modellierungstools, dargestellt in Abbildung \ref{img_baum}, wurde unter Verwendung eines \newWord{Tree Viewers} von \newWord{JFace} entwickelt. JFace basiert auf SWT und dient der Entwicklung von graphischen Benutzeroberflächen.\footnote{Mehr Informationen zu JFace und SWT siehe http://wiki.eclipse.org/The\_Official\_Eclipse\_FAQs\#JFace.} Ein Tree Viewer in JFace benötigt einen \newWord{Content Provider} und einen \newWord{Label Provider}. Der Content Provider verwaltet dabei die Objekte, die durch den Tree Viewer angezeigt werden, und deren Struktur. Der Label Provider hingegen dient der graphischen Darstellung der Objekte in dem Tree Viewer. 

\begin{floatingfigure}[v]{4.3cm}
\centering
\includegraphics[width=3.9cm]{images/konzeption/baumansicht.png} 
\caption{Baumansicht des Modellierungstools}
\label{img_baum}
\end{floatingfigure}
Zunächst wurde erwogen, den Content Provider und den Label Provider vollständig neu zu implementieren. Nach eingehender Recherche wurde jedoch entschieden, für die Implementierung des Content Providers und des Label Providers speziell für diesen Zweck konzipierte Klassen zu nutzen, die von EMF bereitgestellt werden. Dafür wurden eigene Klassen entwickelt, die von den EMF-Klassen erben. Durch die Verwendung der Klassen von EMF war die Hauptfunktionalität des Content Providers und des Label Providers bereits umgesetzt. Es wurden lediglich geringfügige Ergänzungen vorgenommen, wie beispielsweise das Hinzufügen einer zusätzlichen Ebene in der Baumansicht, wie in Abbildung \ref{img_baum} zu sehen, die die Scenes und Exhibition Modules getrennt voneinander darstellt.

Der nächste Schritt in der Entwicklung der Baumansicht war das Anzeigen der Eigenschaften eines Elements, das in der Baumansicht ausgewählt wurde, im Properties-View des Modellierungstools. Dafür musste zunächst der Tree Viewer bei der \newWord{Site} des \newWord{Views}, in dem sich der Tree Viewer befindet, registriert werden (siehe Listing \ref{listing_register}). 
%\vspace{5pt}
\begin{lstlisting}[frame=single, tabsize=3, label=listing_register, caption={Registrierung des Tree Viewers an der Site}, language=Java, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]
getSite().setSelectionProvider(viewer);
\end{lstlisting}

Ein View ist dabei ein Teil eines Fensters einer mit Eclipse erstellten Anwendung. Abbildung \ref{img_baum} zeigt beispielsweise den View, in dem sich die Baumansicht befindet. \textquote[\cite{views}]{The site is not a visible entity but simply an API mechanism to separate the methods that operate on the view from the methods that operate on controls and services outside the view.}\footnote{Weitere Informationen zum Aufbau und der Funktionsweise einer Anwendung, die mit Eclipse erstellt wurde, findet sich unter http://wiki.eclipse.org/The\_Official\_Eclipse\_FAQs.} Der Quelltext des Content Providers, des Label Providers und des Views der Baumansicht befinden sich auf der der Diplomarbeit beigefügten CD.

Zuletzt wurde in der \code{plugin.xml} des Hauptprojekts das Objekt, welches im Properties-View angezeigt werden soll, bekannt gemacht. Die \code{plugin.xml} enthält die Informationen, die für ein Plugin oder eine \RCP -Anwendung benötigt werden. Für die Bekanntmachung des Objekts, das im Properties-View angezeigt werden soll, wurde die Zeile \code{<input type=``org.eclipse.emf.ecore.EObject"/>} an entsprechender Stelle in die \code{plugin.xml} eingefügt. Listing \ref{listing_plugin} zeigt den hierfür relevanten Teil der \code{plugin.xml} mit dem in Zeile 7 eingefügten XML-Element. Der vollständige Quelltext der \code{plugin.xml} befindet sich in Anhang \ref{anhang_pluginxml}. Zur Bekanntmachung wurde die Klasse \code{EObject} gewählt, da alle im Tree Viewer angezeigten Objekte durch diese Klasse generalisiert werden.
\vspace{5pt}
\begin{lstlisting}[frame=single, tabsize=2, label=listing_plugin, caption={Anpassung der plugin.xml}, language=XML, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]
<propertySection
	id="property.section.domain" 
	tab="property.tab.domain"
	class="org.jat.exhibition.diagram.sheet.ExhibitionPropertySection">
		<input type="org.eclipse.gmf.runtime.notation.View"/>
		<input type="org.eclipse.gef.EditPart"/>
		<input type="org.eclipse.emf.ecore.EObject"/>
</propertySection>
\end{lstlisting} 

\subsection{Vorschaubilder in Slides und Branching Points}
Ein weiteres Detail, dessen Umsetzung mehr Zeit als erwartet in Anspruch nahm, war die Vorschau der generierten Webseiten für Slides und Branching Points. Hierbei war jedoch nicht die Umsetzung selbst zeitaufwendig, sondern die Entwicklung eines Lösungskonzepts für die Problemstellung. Die erste Überlegung diesbezüglich war die Verwendung eines \newWord{Browser Widgets}. Ein Browser Widget ist eine von SWT bereitgestellte Komponente, die das Anzeigen von HTML-Dokumenten ermöglicht. Problematisch bei dieser Art der Umsetzung war, dass Draw2d die Verwendung von SWT Widgets nicht zulässt. Es existieren zwar Hilfskonstruktionen, bei denen ein Bild eines Widgets erstellt wird, welches dann in einer Figure eingebunden wird. Für die vorliegende Problemstellung waren diese aber nicht anwendbar.

Eine umfassende Recherche führte zu der Entscheidung, den \newWord{\gls{glos:xhtmlrenderer}} \newWord{Flying Saucer} zu verwenden. Ein XHTML-Renderer wird für die Darstellung von XHTML-Dokumenten verwendet. Flying Saucer wurde unter der \newWord{\gls{glos:gnuLgpl}} veröffentlicht und ist in Java implementiert. Er ermöglicht das \gls{glos:Rendern} von XHTML-Dokumenten, in denen CSS-Angaben verwendet werden. Von der gerenderten XHTML-Seite liefert Flying Saucer dabei unter anderem ein Bild zurück.\footnote{Mehr Informationen zu Flying Saucer siehe https://xhtmlrenderer.dev.java.net/.}

Für die Erzeugung des Vorschaubildes für einen Slide oder Branching Point wird zunächst die Webseite generiert. Hierfür wird das Master-Template für Exhibition Modules verwendet und das für den Slide oder Branching Point ausgewählte Jat Page Template. Die erzeugte Webseite wird dabei temporär zwischengespeichert. Mit dem in Listing \ref{listing_vorschau} dargestellten Quelltext wird dann durch Flying Saucer ein Bild der Webseite erstellt, das in eine Figure eingebunden wird.
\lstinputlisting[frame=single, numbers=left, tabsize=3, label=listing_vorschau, caption={Erzeugung des Vorschaubildes durch Flying Saucer}, language=Java, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]{listings/lst_flyingsaucer}

\subsection{Erweiterung der Validierung}
Der von GMF generierte Validierungsmechanismus ermöglicht die Kennzeichnung eines Modellelements, das gegen einen Constraint verstößt, durch ein Icon. Für den Prototyp sollte jedoch darüber hinaus eine Tabelle implementiert werden, die die gesamten Validierungsergebnisse anzeigt. Zu einem Validierungsergebnis sollten dabei das Modellelement, die Kategorie des Validierungsergebnisses und der Text, der den Modellierungsfehler beschreibt, dargestellt werden. Abbildung \ref{img_validation_results} zeigt die Tabelle der Validierungsergebnisse des Prototyps.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{images/konzeption/validation_results.png} 
\caption{Tabelle der Validierungsergebnisse}
\label{img_validation_results}
\end{figure}

Bei dem von GMF generierten Validierungsmechanismus wird ein Validierungsergebnis durch ein Objekt der Klasse \code{ValidationMarker} repräsentiert. Dieses Objekt enthält die Kategorie des Validierungsergebnisses und den Text, der den Modellierungsfehler beschreibt. Es gibt des Weiteren darüber Auskunft, welchem Metamodellelement das validierte Modellelement entspricht. Das konkrete validierte Modellelement kann jedoch über das Objekt nicht erhalten werden. Für die Tabelle der Validierungsergebnisse wurde jedoch das validierte Modellelement benötigt, um beispielsweise den Titel des Modellelements in der Tabelle anzuzeigen. Für diesen Zweck wurde daher die Klasse \code{ValidationMarker} um einen zweiten Konstruktor erweitert. Diesem Konstruktor wird unter anderem das validierte Modellelement übergeben. Als Typ des Parameters für das übergebene Modellelement wurde die Klasse \code{EObject} gewählt, da alle Modellelemente durch diese Klasse generalisiert werden. Listing \ref{listing_validationMarker} zeigt den hinzugefügten Konstruktor. In Anhang \ref{anhang_validationmarker} befindet sich der vollständige Quelltext der Klasse.
\lstinputlisting[frame=single, numbers=left, tabsize=3, label=listing_validationMarker, caption={Hinzugefügter Konstruktor der Klasse ValidationMarker}, language=Java, keywordstyle=\color{darkred}, commentstyle=\color{darkgrey}, stringstyle=\color{darkblue}]{listings/lst_validationMarker}

Für die Anzeige des Modellelements in der Tabelle der Validierungsergebnisse wurde das Konzept der \newWord{Item Providers} von EMF genutzt. Item Provider dienen bei EMF unter anderem dazu, Funktionen für Content Provider und Label Provider bereitzustellen \mycite[Kap. 3.2]{EMFOnline}. Die Adapter, die EMF für die Modellelemente generiert, sind zusätzlich auch Item Provider. 

Bei der Anzeige eines Modellelements in der Tabelle der Validierungsergebnisse wird die Klasse \code{DelegatingWrapperItemProvider} von EMF genutzt. Der Label Provider der Tabelle wendet sich dabei an diese Klasse, um den Text und das Bild, die für ein konkretes Element in der Tabelle angezeigt werden, zu erhalten. Der \code{DelegatingWrapperItemProvider} delegiert die Anfragen an den entsprechenden Item Provider des Modellelements. In Anhang \ref{anhang_labelProvider} befindet sich der Quelltext des Label Providers. Abbildung \ref{img_itemprovider} zeigt ein Sequenzdiagramm zur Arbeitsweise des \code{DelegatingWrapperItemProvider}.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{images/konzeption/itemprovider.png} 
\caption{Sequenzdiagramm zur Arbeitsweise des \code{DelegatingWrapperItemProvider}}
\label{img_itemprovider}
\end{figure}

Der Label Provider übergibt dem \code{DelegatingWrapperItemProvider}, wie in Abbildung \ref{img_itemprovider} zu sehen, bei dessen Initialisierung das Modellelement, welches in der Tabelle der Validierungsergebnisse angezeigt werden soll. Der \code{DelegatingWrapperItemProvider} wendet sich daraufhin an eine \code{AdapterFactory}. Diese liefert für das übergebene Modellelement den entsprechenden Item Provider zurück. Eine Anfrage des Label Providers beispielsweise nach dem Text delegiert der \code{DelegatingWrapperItemProvider} dann an den so erhaltenen Item Provider. Das von dem Item Provider zurückgelieferte Ergebnis wird dabei an den Label Provider zurückgegeben.

\section{Teststrategien}
Zur Sicherung der Softwarequalität wurden im Rahmen dieser Diplomarbeit Anwendertests und Unit-Tests durchgeführt. Die Anwendertests dienten hauptsächlich der Bewertung des Prototyps bezüglich der Bedienbarkeit des Systems. Sie wurden jedoch teilweise auch zur Identifizierung von Softwarefehlern genutzt. 

Für die Implementierung der Unit-Tests wurde \newWord{\gls{glos:junit}} in der Version 4 verwendet. Der Prototyp wurde jedoch nicht vollständig durch Unit-Tests getestet, da ein großer Teil des Quelltextes generiert wurde. Mittels EMF lässt sich ein Gerüst von JUnit-Tests zum Testen der Metamodell-Klassen generieren. Mit Hilfe dieser Test-Klassen können jedoch nur die Methoden zum Setzen und Abfragen von Attributen getestet werden. Der manuell hinzugefügte Code beschränkt sich weitgehend auf die graphische Benutzeroberfläche, welche sich nur schlecht mit Unit-Tests testen lässt. Der Versuch, die graphische Benutzeroberfläche mit Hilfe des Eclipse Plugins \TPTP\ zu testen, scheiterte.\footnote{Mehr Informationen zu \TPTP\ siehe http://www.eclipse.org/tptp/.} Der Codegenerator wurde teilweise mit Unit-Tests getestet.  Die Testergebnisse befinden sich in Anhang \ref{anhang_junit}.