\section{Appendix}
\lstinputlisting[label={lst:grammar},caption={Xtext grammar}]%
{../../dsl/xtend/src/robots/missions/TaskDSL.xtext}
+
+\newpage
+\lstinputlisting[label={lst:inst},caption={DSL instance}]%
+ {../../dsl/runtime/specs/wander.tdsl}
+
+\newpage
\lstinputlisting[label={lst:gen},caption={Xtend code generation}]
{../../dsl/xtend/src/robots/missions/generator/TaskDSLGenerator.xtend}
+
+\newpage
\lstinputlisting[label={lst:val},caption={Xtend code validation}]
{../../dsl/xtend/src/robots/missions/validation/TaskDSLValidator.xtend}
required a lot of computing power. But when everything was set up correctly it
worked like a charm.
-Creating our solution was a bit difficult at the beginning due to extra works
-designing the DSL to accomodate the robot's missions and behaviours. However when
-the DSL was created appropriately the generation of different missions and
+Creating our solution was a bit difficult at the beginning due to extra works
+designing the DSL to accomodate the robot's missions and behaviours. However
+when the DSL was created appropriately the generation of different missions and
behaviours for the robot became very easy.
\paragraph{General lessons learned}
never got it stable but with more time we could make it stable. Another option
is to try to get more requirements. For example the mapping and internal
representation of the locations of the lakes. This problem is not trivial at
-all and because of the lack of time we could unfortunately not spend time on it.
+all and because of the lack of time we could unfortunately not spend time on
+it.
A domain-specific language (DSL) is a programming language or executable
specification language that offers, through appropriate notations and
abstractions, expressive power focused on, and usually restricted to, a
-particular problem domain~\cite{van2002domain}. The DSL for the robot is designed so that the
-robot is able to perform multiple missions consisting of behaviours. A mission
-is basically a set of behaviours operating following the subsumption
-architecture assisted by a special purpose behaviour that shuts down the
-runtime to make room for a new mission. The complete grammar of the DSL can be
-found in \autoref{lst:grammar}.
+particular problem domain~\cite{van2002domain}. The DSL for the robot is
+designed so that the robot is able to perform multiple missions consisting of
+behaviours. A mission is basically a set of behaviours operating following the
+subsumption architecture assisted by a special purpose behaviour that shuts
+down the runtime to make room for a new mission. The complete grammar of the
+DSL can be found in \autoref{lst:grammar}.
\autoref{fig:dsl} describes the hierarchy of the grammar. A \emph{Robot} is a
set of constants combined with a list of \emph{Behaviour}s and a list of
all times can be a valid design but when there are two with that property, only
one will be used. To avoid such situations the IDE will warn the user when this
is the case. The full code for the code validation can be found in
-\autoref{lst:val}.
+\autoref{lst:val}. The full DSL instance used in the demonstration can be found
+in \autoref{lst:inst}.
\subsection{Code Structure}
The complete code generation code can be found in \autoref{lst:gen}. The