[thesis] Fixed mistakes, added examples for latex/doxygen. fixed style related issues
[hsd_doku_tool.git] / doc / thesis / chapters / projektumsetzung.tex
1 \chapter{Prototyp-Entwicklung}
2 \label{cha:Projektumsetzung}
3
4 In diesem Kapitel wird die Implementierung des Prototyps anhand des im letzten Kapitel aufgezeigten Konzeptes erläutert.
5 Als Entwicklungssystem wird ein Rechner mit der Linuxdistribution \textit{Debian 9} (64Bit) verwendet. Im folgenden wird Bezug
6 auf die Quellen \cite{mvc}, \cite{observer}, \cite{johnson1998anwendungen}, \cite{CrossDevWorkflow}, \cite{LinuxCert}, \cite{wine} und \cite{fltkMan} genommen.
7
8 \section{Implementierung des Prototypen}
9
10 Im kommenden Abschnitt wird die Umsetzung der einzelnen Komponenten des Prototyps beschrieben. Da der Prototyp im Wesentlichen
11 aus den drei Komponenten des MVC-Konzepts besteht, ist der folgende Abschnitt in die Implementierung dieser gegliedert.
12
13 \subsection{Implementierung des Models}
14 Das \textit{Model} hält alle Daten und ist für das Laden und Speichern der XML-Vorlagedateien verantwortlich. Außerdem beinhaltet es die Programmlogik
15 zum Generieren der Dokumentationen.
16 Das Parsen der XML-Dateien übernimmt die Programmbibliothek \textit{tinyxml2}. Per Vorlage geladene oder neu erstellte Kapitel und Autoren
17 werden innerhalb des Models als Listen spezieller Autor- und Kapitelobjekte abgelegt.
18
19 \subsubsection{Author Objekte}
20 \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{author} \caption{Hier wird der Aufbau der Autor-Klasse dargestellt.}\label{fig:Author} \end{figure}
21 Wie man in Abb.~\ref{fig:Author} sehen kann, sind Autor Objekte sehr einfach gehalten und dienen nur dazu die einzelnen Attribute mithilfe von Zugriffsfunktionen
22 zu speichern.
23
24 \subsubsection{Kapitel Objekte}
25 Da es drei verschiedene Kapitelarten gibt, kann hier nicht derselbe Ansatz wie bei den Kapiteln gewählt werden. Der Grundaufbau eines Kapitels wird durch eine Interfaceklasse definiert. Auf Basis dieses Interface ist es möglich, die drei Kapiteltypen als eigene Klassen umzusetzen.
26 Das \textit{Model} besitzt die Möglichkeit, diese verschiedenen Kapiteltypen mithilfe einer sogenannten Simple-Factory-Klasse zu erzeugen.
27 \begin{figure}[] \centering \includegraphics[width=\textwidth]{simple_factory} \caption{Dises UML Diagramm zeigt die Funktionsweise der ChapterFactory-Klasse.}\label{fig:ChaptFact} \end{figure}
28 Abb.~\ref{fig:ChaptFact} zeigt die Funktionsweise dieser Simple-Factory-Klasse. Die \textit{createChapter} Funktionen erlauben das Erzeugen von verschiedenen
29 Kapitelobjekten. Über diese Klasse kann auch eine Liste der verfügbaren Kapiteltypen angefordert werden.
30
31 \subsubsection{FSHelper-Klasse}
32 Funktionen, die plattformabhängige Operationen, wie zum Beispiel Dateisystemzugriffe, zur Verfügung stellen, werden in einer eigenen FSHelper-Klasse
33 gekapselt. Die Funktionen sind jeweils für \textit{Linux} und für \textit{Windows} implementiert, und über Präprozessor Makros wird der passende
34 Code in die Funktionen kompiliert.
35
36 \subsubsection{Benachrichtigung der View}
37 \begin{figure}[H] \centering \includegraphics[width=\textwidth]{observer} \caption{Dieses UML-Diagramm zeigt, wie \textit{Model} und \textit{View} über das Observer-Entwurfsmuster interagieren.}\label{fig:Observer} \end{figure}
38 Finden Änderungen im \textit{Model} statt, muss laut MVC-Konzept zumindest die \textit{View} darüber informiert werden. Dies kann mithilfe des Observer-Entwurfsmuster umgesetzt werden. Wie man in Abb.~\ref{fig:Observer} erkennen kann,
39 leitet die \textit{View} von einer abstrakten Object-Klasse ab und muss die Funktion
40 \textit{updatedBySubject} implementieren. Das \textit{Model} leitet von Subject ab, somit kann die \textit{View} über die Funktion \textit{notifyObservers} über Änderungen benachrichtigt werden.
41
42
43
44 \subsection{Implementierung der View}
45
46 \begin{figure}[H] \centering \includegraphics[width=\textwidth]{fluid} \caption{Hier wird das Design der Grafischen Oberfläche mit \textit{FLUID} dargestellt.}\label{fig:fluid} \end{figure}
47
48 Die View-Klasse repräsentiert den Teil des Prototyps, mit dem der Benutzer interagiert. Das Benutzerinterface wird mit der plattformunabhängigen
49 Programmbibliothek \textit{FLTK} erstellt. Dieses bietet die Möglichkeit mithilfe des Programms
50 \textit{FLUID} grafische Oberflächen zu entwerfen.
51 \newline
52 \par
53 Hierbei werden die einzelnen Grafikobjekte, wie in Abb.~\ref{fig:fluid} dargestellt, mithilfe von Drag \& Drop zusammengefügt. Aus diesem
54 Design lässt sich dann eine Basisklasse generieren, von der die wirkliche View-Klasse abgeleitet werden kann. In der abgeleiteten Klasse kann
55 die Funktionalität über Callbackfunktionen, die von den einzelnen Grafikobjekten ausgelöst werden, implementiert werden. Über diese Funktionen
56 werden Anfragen über den \textit{Controller} an das \textit{Model} weitergeleitet.
57
58 \subsection{Implementierung des Controllers}
59
60 Wie in Abb.~\ref{fig:mvc_uml} gezeigt gibt der \textit{Controller} Anfragen der \textit{View} an das \textit{Model} weiter und gibt diesem die Anweisung die \textit{View}
61 über Änderungen zu benachrichtigen. Er bietet außerdem eine Zwischenschicht, um bei strukturellen Änderungen im
62 \textit{Model} die Aufrufe der \textit{View} zu konvertieren.
63
64 \begin{figure}[H] \centering \includegraphics[width=\textwidth]{mvc_uml} \caption{Diese Grafik zeigt das Zusammenspiel von \textit{Model}, \textit{View} und \textit{Controller}.}\label{fig:mvc_uml} \end{figure}
65
66 \subsection{Übersichtsklassendiagramm}
67
68 Das in Abb.~\ref{fig:full} dargestellte Übersichtsklassendiagramm zeigt wie alle Klassen miteinander Interagieren. Die Klassen \textit{FSHelper}, \textit{Author} und \textit{ChapterFactory} werden nur
69 von der Model-Klasse verwendet, da diese die Programmlogik beinhaltet.
70
71 \begin{figure}[H] \centering \includegraphics[width=\textwidth]{full} \caption{Dieses UML-Diagramm veranschaulicht wie alle Komponenten miteinander interagieren.}\label{fig:full} \end{figure}
72
73 Man kann in Abb.~\ref{fig:full} erkennen, dass zwischen der View-Klasse und der Model-Klasse beziehungsweise zwischen der View-Klasse und der Controller-Klasse jeweils eine Interface-Klasse
74 eingeführt wurde. Diese Interface-Klassen sollen die \textit{View} komplett von \textit{Model} und \textit{Controller} entkoppeln.
75
76 \section{Kompilieren und Linken}
77
78 Um so wenig Abhängigkeiten wie möglich zu erhalten, wird auf \textit{Linux} und auf \textit{Windows} versucht so viel
79 wie möglich statisch in die Programme zu linken. Damit dies möglich ist, müssen zuerst die externen Programmbibliotheken
80 kompiliert werden.
81
82 \subsection{Installieren der Abhängigkeiten}
83
84 Folgende Abhängigkeiten müssen auf dem Entwicklungssystem mithilfe des Paketmanagers installiert werden:
85 \begin{lstlisting}[language=bash]
86 $ sudo dpkg --add-architecture i386
87 $ sudo apt update
88 $ sudo mv /usr/lib/llvm-3.9/lib/libclang-3.9.so.1 /usr/lib/llvm-3.9/lib/libclang-3.9.so.1.bak
89 $ sudo apt install -y build-essential libfltk1.3-dev libasound-dev:i386 xserver-xorg-dev:i386 gcc-multilib g++-multilib mingw-w64 binutils-mingw-w64 p7zip-full doxygen:i386
90 \end{lstlisting}
91 Dies installiert benötigte Programmbibliotheken und die passenden Compiler.
92 Um auf \textit{Linux} für \textit{Windows} cross-kompilieren zu können, benötigt man den \textit{mingw-w64} Compiler. Dieser ist weitgehend mit dem GNU Compiler für \textit{Linux} kompatibel.
93 Als Crosskompilieren versteht man das Bauen eines Programmes für ein fremdes Zielsystem.
94 \newline
95 \par
96 Damit die FLTK-Unittests beim cross-kompilieren für \textit{Windows} nicht fehlschlagen, muss \textit{Wine} installiert werden. Dies geschieht
97 wie folgt über den Paketmanager:
98 \begin{lstlisting}[language=bash]
99 $ sudo apt install -y wine wine32 wine64 libwine libwine:i386 fonts-wine wine-binfmt
100 $ sudo update-binfmts --import /usr/share/binfmts/wine
101 \end{lstlisting}
102 \textit{Wine} kann als eine Windowskompatibilitätsschicht verstanden werden, die es ermöglicht Windows-Programme auf Linux-Systemen auszuführen.
103
104 \subsection{Linux}
105
106 \subsubsection{FLTK}
107
108 Mithilfe des im FLTK-Quellcode bereitgestellten Konfigurationsskripts muss die Prozessorarchitektur angegeben werden. Außerdem müssen alle nicht
109 benötigten Abhängigkeiten deaktiviert werden.
110 Mit dem Befehl \textit{make} wird der Buildprozess gestartet und die statische Programmbibliothek erzeugt.
111 \begin{lstlisting}[language=bash]
112 $ ./configure "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32" --enable-localjpeg --enable-localzlib --enable-localpng --enable-x11=no --disable-xcursor --disable-xinerama --disable-xft --disable-xdbe --disable-xrender --disable-xfixes --disable-threads
113 $ make
114 \end{lstlisting}
115
116 \subsubsection{tinyxml2}
117
118 \textit{tinyxml2} wird mit dem GNU C++ Compiler \textit{gcc} kompiliert und danach mit dem Befehl \textit{ar} in eine statische Bibliothek umgewandelt.
119
120 \begin{lstlisting}[language=bash]
121 $ g++ -m32 -c -o tinyxml2.o tinyxml2.cpp
122 $ ar rvs libtinyxml2.a tinyxml2.o
123 \end{lstlisting}
124
125 \subsubsection{Prototyp}
126 \label{ssc:LinkingLinux}
127
128 Der Prototyp muss unter \textit{Linux} mit folgenden Linker-Parametern gelinkt werden:
129
130 \begin{lstlisting}
131 -static-libstdc++
132 -static-libgcc
133 ./libfltk.a
134 ./libtinyxml2.a
135 -ldl
136 -lm
137 -lX11
138 \end{lstlisting}
139
140 Leider ist es nicht möglich alle Programmbibliotheken statisch in ein Programm zu linken, da Linux-Systeme komplett auf dynamische
141 Bibliotheken aufgebaut sind. Es ist vor allem nicht möglich, die Standard C Bibliothek des Betriebssystems statisch zu linken.
142 \newline
143 \par
144 Eine Plattformunabhängigkeit zwischen verschiedenen Linux-Derivaten herzustellen erweist sich somit als ziemlich schwierig,
145 da nicht alle Systeme eine einheitliche Version der Standard C Bibliothek besitzen. Dieses Problem kann umgangen werden, indem alle
146 benötigten dynamischen Bibliotheken in der Programmumgebung mitgeliefert werden. Das Programm muss über ein Bash-Startskript
147 mit dem gleichen dynamischen Lader, mit dem auch das Programm gelinkt wurde, gestartet werden.
148 \newline
149 \par
150 Es müssen ebenfalls alle externen Programme mit demselben Lader gestartet werden.
151 Diese Funktion übernimmt die FSHelper-Klasse. Externe Programme können aber nicht wie bei \textit{Windows} mit
152 dem POSIX konformen system-Befehl gestartet werden, da dies eine Shell mit dem dynamischen Lader des Betriebssystems
153 erzeugen würde. Es müssen daher externe Programme mithilfe von \textit{fork} und \textit{exec} aufgerufen werden.
154
155 \subsection{Windows}
156
157 \subsubsection{FLTK}
158
159 Unter \textit{Windows} muss zum Kompilieren der statischen FLTK-Programmbibliothek neben der Prozessorarchitektur der zu verwendende
160 \textit{mingw-w64} Compiler angegeben werden.
161
162 \begin{lstlisting}[language=bash]
163 $ ./configure LDFLAGS="-static-libgcc -static-libstdc++" --enable-cygwin --enable-threads --enable-localjpeg --enable-localzlib --enable-localpng --enable-x11 --disable-xcursor --disable-xinerama --disable-xft --disable-xdbe --disable-xrender --disable-xfixes --disable-threads --host=i686-w64-mingw32
164 $ make
165 \end{lstlisting}
166
167 \subsubsection{tinyxml2}
168
169 Die statische \textit{tinyxml2} Programmbibliothek wird analog wie bei \textit{Linux} erstellt, nur dass der \textit{mingw-w64} Compiler verwendet wird.
170
171 \begin{lstlisting}[language=bash]
172 $ i686-w64-mingw32-g++ -c -o tinyxml2.o tinyxml2.cpp
173 $ i686-w64-mingw32-ar rvs libtinyxml2.a tinyxml2.o
174 \end{lstlisting}
175
176 \subsubsection{Prototyp}
177
178 Unter \textit{Windows} muss der Prototyp mit diesen Parametern gelinkt werden:
179
180 \begin{lstlisting}
181 -mwindows
182 -static-libgcc
183 -static-libstdc++
184 ./libfltk.a
185 ./libtinyxml2.a
186 -lole32
187 -luuid
188 -lcomctl32
189 \end{lstlisting}
190
191 Für \textit{Windows} können alle Komponenten in ein einziges ausführbares Programm gelinkt werden.
192
193 \section{Programmumgebung}
194
195 Damit das Dokumentationswerkzeug die externen Programme \textit{Doxygen} und \textit{Texlive} verwenden kann, müssen diese in eine
196 Programmumgebung gepackt werden. Diese Programmumgebung gliedert sich in folgende Verzeichnisse:
197
198 \begin{itemize}
199 \item \textbf{bin:} Dieses Verzeichnis beinhaltet das kompilierte Dokumentationswerkzeug und die \textit{Doxygen} Anwendung.
200 \item \textbf{lib:} Im Unterordner \textit{lib} werden etwaige Abhängigkeiten abgelegt. Dies ist vor allem für die Linuxumgebung relevant um
201                     Programmbibliotheken, die man nicht statisch linken kann mit in die Programmumgebung zu packen.
202 \item \textbf{etc:} In diesem Verzeichnis ist die \latex-Designvorlage gespeichert.
203 \item \textbf{texlive\_windows/texlive\_linux:} Die Namensgebung dieses Ordners ist abhängig vom Betriebssystem. Hier wird die vollständige
204 Texlive-Installation abgelegt.
205 \end{itemize}
206 Der Inhalt dieser Verzeichnisse muss an das jeweilige Betriebssystem angepasst werden, da sonst die Programme nicht ausführbar sind.
207
208 \subsection{Programmumgebung Linux}
209 \textit{Texlive} wird mithilfe der offiziellen Installationsroutine \cite{texlive} als portable Version in das Unterverzeichnis \textit{texlive\_linux}
210 installiert.
211 \newline
212 \par
213 \textit{Doxygen} und dessen Abhängigkeiten werden direkt aus den Paketquellen \cite{DebRpm} des Entwicklungssystems bezogen und nach \textit{bin} kopiert.
214 Um die Abhängigkeiten leicht kopieren zu können, kann folgendes Bash-Skript verwendet werden:
215
216 \begin{lstlisting}[language=bash,caption={Bash-Skript zum kopieren von Abhängigkeiten}]
217 #!/bin/bash
218
219 function useage()
220 {
221     cat << EOU
222 Useage: bash $0 <path to the binary> <path to copy the dependencies>
223 EOU
224 exit 1
225 }
226
227 #Validate the inputs
228 [[ $# < 2 ]] && useage
229
230 #Check if the paths are vaild
231 [[ ! -e $1 ]] && echo "Not a vaild input $1" && exit 1
232 [[ -d $2 ]] || echo "No such directory $2 creating..."&& mkdir -p "$2"
233
234 #Get the library dependencies
235 echo "Collecting the shared library dependencies for $1..."
236 deps=$(ldd $1 | awk 'BEGIN{ORS=" "}$1\
237 ~/^\//{print $1}$3~/^\//{print $3}'\
238  | sed 's/,$/\n/')
239 echo "Copying the dependencies to $2"
240
241 #Copy the deps
242 for dep in $deps
243 do
244     echo "Copying $dep to $2"
245     cp "$dep" "$2"
246 done
247
248 echo "Done!"
249 \end{lstlisting}
250
251 Dieses Skript ermittelt mithilfe des Programmes \textit{ldd} alle von einer Anwendung benötigten Programmbibliotheken und kopiert diese in das
252 angegebene Verzeichnis.
253
254 \subsubsection{Start Script}
255
256 Um das Dokumentationswerkzeug innerhalb dieser Programmumgebung ausführen zu können, wird folgendes Skript benötigt, das die Umgebung initialisiert:
257
258 \begin{lstlisting}[language=bash,caption={Bash Start Skript}]
259 DIR=$(pwd)
260 export PATH=$DIR/texlive_linux/2018/bin/i386-linux:$DIR/bin:$PATH
261 export LD_LIBRARY_PATH=$DIR/lib
262 $LD_LIBRARY_PATH/ld-linux.so.2 --library-path $LD_LIBRARY_PATH $DIR/bin/doc_tool
263 \end{lstlisting}
264
265 Dieses Bash-Skript erweitert den Systempfad um die Pfade der Programmumgebung und ermöglicht somit das Starten des Dokumentationsprogramms
266 mit Zugriff auf \textit{Doxygen} und \textit{Texlive}. Wie man erkennen kann, wird wie unter \ref{ssc:LinkingLinux} erwähnt das
267 Dokumentationswerkzeug indirekt über den dynamischen Lader \textit{ld-linux.so.2} aufgerufen.
268
269 \subsection{Programmumgebung Windows}
270
271 \textit{Texlive} für \textit{Windows} wird mit der offiziellen Installationsroutine auf dem Linux-System erstellt. Damit dies funktioniert, muss
272 die \textit{Windows} Installationsroutine auf dem Linux-System mithilfe von \textit{Wine} ausgeführt werden. Es wird
273 die portable Version von \textit{Texlive} in das Unterverzeichnis \textit{texlive\_windows} installiert.
274 \newline
275 \par
276 Um \textit{Doxygen} in dem Unterverzeichnis \textit{bin} bereitzustellen, werden direkt die von der offiziellen Doxygen Website zur Verfügung
277 gestellten \textit{Windows} Programmdateien verwendet \cite{doxywin}.
278
279 \subsubsection{Start Skript}
280
281 Wie unter \textit{Linux} muss hier die Programmumgebung mithilfe eines Startskriptes initialisiert werden.
282
283 \begin{lstlisting}[caption={Batch Start Skript}]
284 @echo off
285 set path=%CD%\texlive_windows\2018\bin\win32;%CD%\bin;%PATH%
286 start doc_tool
287 \end{lstlisting}
288
289 Das Skript erweitert den Systempfad um die Pfade der Programmumgebung um Zugriff auf \textit{Doxygen} und \textit{Texlive} zu ermöglichen.
290
291
292 \section{Pakete Erstellen}
293
294 Um das Dokumentationsprogramm mit all seinen Abhängigkeiten weitergeben und auf verschiedenen Systemen einrichten zu können,
295 ist es nötig, die gesamte Programmumgebung in ein komprimiertes Paket zusammenzufassen.
296
297 \subsection{Linux}
298 Unter \textit{Linux} ist \textit{.tar.gz} eines der gängigsten Kompressionsformate. Daher kann davon ausgegangen werden, dass alle Linuxsysteme
299 ein Entpacken solcher Archive unterstützten. Um ein \textit{.tar.gz} Archiv in ein selbstextrahierendes Archiv umzuwandeln, kann man
300 in den Anfang der Archivdatei ein Shellskript einfügen. Dieses Shellskript muss das komprimierte Paket am Ende der Datei entpacken.
301 \newline
302 \par
303 Es wurde ein Hilfsprogramm geschrieben, das \textit{.tar.gz} Pakete mithilfe der gerade aufgezeigten Methode
304 in ein selbstextrahierendes Archiv umwandeln kann:
305 \begin{lstlisting}[language=bash]
306 #!/bin/sh
307 #Script that creates self extracting executable script from tar.gz file.
308 if [ $# -eq 0 ] || [ ! -f $1 ]; then
309         echo "This script creates self extractable executable"
310         echo Usage: $0 [/path/to/*.tar.gz]
311         exit;
312 fi
313 if [ $# -gt 0 ]; then
314         TAR_FILE=$1
315 fi
316 EXIT_COMMAND=exit
317 if [ $# -gt 1 ]; then
318         EXIT_COMMAND="exec $2"
319 fi
320 FILECOUNT=$(tar -tzf $TAR_FILE | wc -l)
321 SELF_EXTRACTABLE="$TAR_FILE.run"
322
323 cat > ${SELF_EXTRACTABLE} << EOL
324 #!/bin/bash
325 if [ -f '/usr/bin/xmessage' ] || [ -f '/usr/bin/gxmessage' ]; then
326     XMESSAGE=\$(which gxmessage) || XMESSAGE=xmessage
327     PWD=\$(pwd)
328     ans=\$(\$XMESSAGE -nearmouse -title 'Extract?' -buttons yes,no Extract to: [ \$PWD ] ? -print)
329 else
330     ans=yes
331 fi
332 if [ "\$ans" == "yes" ]; then
333     TOSKIP=\$(awk '/^#----- ARCHIVE STARTS HERE -----#/ {print NR + 1; exit 0; }' \$0)
334     COUNT=$FILECOUNT
335     echo "Installing Doc Tool: "&
336     PID=\$!
337     LINE="                                                  "
338     LINENUM=0
339
340     # Extract
341     tail -n+\$TOSKIP \$0  | tar -xzvp 2>&1 |
342     while read line; do
343         x=\$((x+1))
344
345         # calculate percentage
346         PERCENTAGE_NUM=\$(((x*100)/COUNT))
347         PERCENTAGE=\$(printf '%03d' \$PERCENTAGE_NUM)
348
349         # create gauge line
350         if [ "\$PERCENTAGE_NUM" -ge "\$LINENUM" ]; then
351                 LINE=\${LINE/ />}
352
353                 if [ "\$PERCENTAGE_NUM" -ge "100" ]; then
354                         LINE=\${LINE// />}
355                 fi
356         fi
357
358         # display gauge line
359         if [ -z \${XMESSAGE+x} ]; then
360               echo -en "[\$LINE] \$x / \$COUNT extracted (\$PERCENTAGE%)\r"
361                 if [ "\$PERCENTAGE_NUM" -ge "\$LINENUM" ]; then
362                       LINENUM=\$((PERCENTAGE_NUM+2))
363                 fi
364         else
365                if [ "\$PERCENTAGE_NUM" -ge "\$LINENUM" ]; then
366                       LINENUM=\$((PERCENTAGE_NUM+2))
367                       if ps -p \$PID > /dev/null
368                       then
369                             kill \$PID 2> /dev/null
370                        fi
371                       \$XMESSAGE -center -title 'Progress' "[\$LINE] \$x / \$COUNT extracted! (\$PERCENTAGE%)" &
372                        PID=\$!
373                fi
374         fi
375     done
376
377     # check if untar was successful
378     if [ "\${PIPESTATUS[1]}" != "0" ]; then
379         if [ -z \${XMESSAGE+x} ]; then
380             echo 'Failed to extract package!'
381         else
382              \$XMESSAGE -nearmouse -title 'Error!' 'Failed to extract package!'
383         fi
384         exit 1
385     fi
386
387     # display success message
388     if [ -z \${XMESSAGE+x} ]; then
389         echo ''
390         echo 'Finished extracting!'
391     else
392         \$XMESSAGE -nearmouse -title 'Success' 'Finished extracting!'
393     fi
394    exit
395 else
396    exit
397 fi
398 #----- ARCHIVE STARTS HERE -----#
399 EOL
400
401 cat $TAR_FILE >> $SELF_EXTRACTABLE
402 chmod a+x $SELF_EXTRACTABLE
403 \end{lstlisting}
404
405 \subsection{Windows}
406 Das gängigste Kompressionsformat unter \textit{Windows} ist \textit{zip}, daher wurde dieses Format zum Packen der gesamten Programmumgebung gewählt.
407 Mithilfe des Programmes \textit{7zip} kann unter \textit{Linux} ein selbstextrahierendes Programm
408 erzeugt werden, das eine Fortschrittsanzeige besitzt und sich unter \textit{Windows} ausführen lässt.
409
410 \section{Resultat}
411 In diesem Abschnitt werden der resultierende Prototyp und dessen Funktionen beleuchtet.
412
413 \begin{figure}[H] \centering \includegraphics[width=0.8\textwidth]{doc_tool_num} \caption{Diese Abbildung zeigt die resultierende Benutzeroberfläche.}\label{fig:doc_tool_num} \end{figure}
414 Abb.~\ref{fig:doc_tool_num} Zeigt die Benutzeroberfläche des in diesem Kapitel entwickelten Prototypen. Die Grafische Oberfläche besitzt alle in \ref{sc:aufbauGui}
415 gezeiten Merkmale. Es das Programm wurde unter Berücksichtigung der unter \autoref{cha:Anforderungen} definierten Anforderungen erstellt und besitzt folgende Elemente:
416
417 \begin{enumerate}
418 \item ein Startmenü nach etablierten Standards von \textit{Windows} und \textit{Linux}
419 \item eine Liste in der das zu editierende Kapitel ausgewählt werden kann
420 \item Elemente zum bearbeiten und definieren der Autoren
421 \item Textfeld zum schreiben des aktuell ausgewählten Kapitels
422 \item Anzeige des Aktuell ausgewählten Kapitels
423 \item Elemente mit denen die allgemeine Dokumenteinstellgen Dokumentname, Gruppe und Deckblatt konfiguriert werden können
424 \item klickbarer Knopf mit dem man zum nächsten Kapitel springen kann
425 \item Auswahlboxen mit denen der Bearbeitungsstatus des aktuellen, oder aller Kapitel geändert werden kann
426 \item Statusanzeige, die den Fortschritt des Dokumentationsprozesses angibt
427 \end{enumerate}
428
429 Neue Vorlagedateien erstellen oder bestehende Vorlagedateien laden kann man über die Startmenüeinträge \textit{File > New document} und
430 \textit{File > Open document template}. Eine Vorlage lässt sich als Vorlagedatei über den Startmenüeintrag \textit{Edit > Save as template} exportieren.
431 Allgemeine Dokumenteinstellungen finden sich unter \textit{Edit > Settings}.
432 \newline
433 \par
434 Elemente zum Editieren einer Vorlage wurden als Rechtsklickmenüs implementiert. Somit scheinen sie in der grafischen Oberfläche
435 nicht direkt auf und Stören den Dokumentationsprozess nicht. In Abb.~\ref{fig:doc_tool_num} befinden sich unter folgenden Steuerelementen
436 Rechtsklickmenüs zum Bearbeiten einer Vorlage:
437
438 \begin{enumerate}
439  \addtocounter{enumi}{1}
440  \item Optionen zum bearbeiten, löschen und hinzufügen von Kapiteln
441  \item Einstellungen zum hinzufügen, löschen und ändern der Deckblattkoordinaten eines Authors \addtocounter{enumi}{2}
442  \item Unter \textit{Group/Department} befindet sich ein Rechtsklickmenü mit dem die Deckblattkoordinaten der Gruppe konfiguriert werden können.
443 \end{enumerate}
444
445 Die Deckblattkoordinaten werden benötigt, damit das Werkzeug die Benutzereingaben in das Deckblatt eintragen kann.