[thesis] Fixed mistakes, added examples for latex/doxygen. fixed style related issues
authorDaniel G <daniel@giritzer.eu>
Sun, 19 Aug 2018 20:45:11 +0000 (22:45 +0200)
committerDaniel G <daniel@giritzer.eu>
Sun, 19 Aug 2018 20:45:11 +0000 (22:45 +0200)
43 files changed:
doc/thesis/back/anhang_b.tex
doc/thesis/chapters/anforderungen.tex
doc/thesis/chapters/einleitung.tex
doc/thesis/chapters/konzept.tex
doc/thesis/chapters/projektumsetzung.tex
doc/thesis/chapters/softwaredokumentationen.tex
doc/thesis/chapters/tests.tex
doc/thesis/chapters/zusammenfassung.tex
doc/thesis/examples/doxygen/doxyfile [new file with mode: 0644]
doc/thesis/examples/doxygen/exmpl_add_doxy.cpp [new file with mode: 0644]
doc/thesis/examples/json.json [new file with mode: 0644]
doc/thesis/examples/latex/docu.tex [new file with mode: 0644]
doc/thesis/examples/latex/exmpl_add_latex.cpp [new file with mode: 0644]
doc/thesis/examples/xml.xml [new file with mode: 0644]
doc/thesis/front/abstract.tex
doc/thesis/front/kurzfassung.tex
doc/thesis/images/doc_tool_num.png [new file with mode: 0644]
doc/thesis/images/doxy_html.png [new file with mode: 0644]
doc/thesis/images/doxy_latex.png [new file with mode: 0644]
doc/thesis/images/fluid.png
doc/thesis/images/full.png [new file with mode: 0644]
doc/thesis/images/mvc_uml.png [new file with mode: 0644]
doc/thesis/images/observer.png
doc/thesis/images/simple_factory.png
doc/thesis/images/use_case_doc_tool.png
doc/thesis/images/use_case_template_generator.png
doc/thesis/main.tex
doc/thesis/references.bib
doc/thesis/uml/author.png [new file with mode: 0644]
doc/thesis/uml/full.dot [new file with mode: 0644]
doc/thesis/uml/full.png [new file with mode: 0644]
doc/thesis/uml/mvc.dot [new file with mode: 0644]
doc/thesis/uml/mvc.png [new file with mode: 0644]
doc/thesis/uml/mvc_uml.png [new file with mode: 0644]
doc/thesis/uml/observer.dot
doc/thesis/uml/observer.png [new file with mode: 0644]
doc/thesis/uml/simple_factory.dot
doc/thesis/uml/simple_factory.png [new file with mode: 0644]
doc/thesis/uml/use_case_doc_tool.png [new file with mode: 0644]
doc/thesis/uml/use_case_template_generator.png [new file with mode: 0644]
doc/thesis/uml/view.dot [new file with mode: 0644]
doc/thesis/uml/view.png [new file with mode: 0644]
src/doc_tool.depend

index 86b61f3..2396f71 100644 (file)
@@ -7,9 +7,9 @@ verwendet.
 \par
 Der Inhalt dieser CD-ROM gliedert sich in folgende Verzeichnisse:
 \begin{itemize}
-\item \textbf{doc:} In dem Verzeichnis doc ist der \latex Quellcode dieser Arbeit abgelegt.
+\item \textbf{doc:} In dem Verzeichnis doc ist der \textit{\latex} Quellcode dieser Arbeit abgelegt.
 \item \textbf{management:} In diesem Verzeichnis befindet sich der ursprünglich ausgearbeitete Projektzeitplan.
-\item \textbf{packages:} Hier sind folgende externen Komponenten abgelegt: \textit{fltk} Quellcode, \textit{tinyxml2} Quellcode, \textit{Doxygen} für Windows und die \textit{Texlive} Installationsroutine.
+\item \textbf{packages:} Hier sind folgende externen Komponenten abgelegt: \textit{fltk} Quellcode, \textit{tinyxml2} Quellcode, \textit{Doxygen} für \textit{Windows} und die \textit{Texlive} Installationsroutine.
 \item \textbf{scripts:} Das Verzeichnis scripts beinhaltet Hilfsskripte zum Erstellen der Prototypen Installationsroutinen.
 \item \textbf{src:} Dieser Ordner beinhaltet den Quellcode des Prototyps und die Dateien für den Prototypentest.
 \end{itemize}
index 148d94b..1c6a042 100644 (file)
@@ -6,26 +6,32 @@ der Software Übungsabgaben im Übungsbetrieb des Studiengangs Hardware-Software
 dass diese Anforderungen auf eine Breite Masse an Software Projekten zutrifft und der Prototyp auch für andere Projekte eingesetzt werden kann.
 
 \section{Plattformunabhängigkeit}
-Um eine breite Masse von Windows und Linux Systemen abzudecken, soll sich die Prozessorarchitektur des kompilierten Programmes auf i386 beschränken, da
-diese von allen modernen PCs und Laptops und auch allen gängigen Linux und Windows Systemen unterstützt wird.
+Um eine breite Masse von \textit{Windows} und Linux-Systemen abzudecken, soll sich die Prozessorarchitektur des kompilierten Programmes auf i386 beschränken, da
+diese von allen modernen PCs und Laptops und allen gängigen \textit{Linux} und Windows-Systemen unterstützt wird.
 Außerdem muss gewährleistet sein, dass die vom Dokumentationswerkzeug erstellten Vorlagedateien ein einheitliches Format aufweisen und
-auch zwischen den Betriebssystemen austauschbar sind.
+zwischen den Betriebssystemen austauschbar sind.
 
 \section{Anwendungsfälle}
 
-\begin{figure}[H] \centering \includegraphics[width=\textwidth]{use_case_doc_tool} \caption{Dieses Use Case Diagramm stellt die Anwendungsfälle grafisch dar.}\label{fig:UseCaseFull} \end{figure}
+\begin{figure}[H] \centering \includegraphics[width=0.8\textwidth]{use_case_doc_tool} \caption{Dieses Anwendungsfalldiagramm stellt die Anwendungsfälle für alle Anwendertypen grafisch dar.}\label{fig:UseCaseFull} \end{figure}
 
 Das Programm ist, wie im Use Case Diagramm Abb.~\ref{fig:UseCaseFull} gezeigt, für zwei Anwendertypen gedacht.
 \newline
 \par
 Der erste Anwendertyp repräsentiert einen Softwareentwickler, der auf Basis einer vorher definierten Vorlage, eine Dokumentation erstellt.
-Das Programm soll dem Entwickler die Funktionalität bieten, Dokumentation im PDF und im \latex Format zu erstellen. Da spezielle Problemstellungen
-unvorhersehbare Änderungen in der Dokumentation zur Folge haben können, muss der Entwickler die Möglichkeit besitzen, eine vorher definierte
-Vorlage an die gegebene Problemstellung anzupassen.
+Bevor eine Dokumentation erstellt werden kann, ist es nötig wichtige Parameter wie zum Beispiel den Ausgabepfad für die Dateien zu konfigurieren.
+In Abb.~\ref{fig:UseCaseFull} wird dies durch \textit{Parameter konfigurieren} ausgedrückt.
+Das Programm soll dem Entwickler die Funktionalität bieten, Dokumentation im \textit{PDF} und im \textit{\latex} Format zu erstellen. Dies wird
+in Abb.~\ref{fig:UseCaseFull} durch den Anwendungsfall \textit{Dokumentation exportieren} dargestellt.
+Da spezielle Problemstellungen unvorhersehbare Änderungen in der Dokumentation zur Folge haben können, muss der Entwickler wie in Abb.~\ref{fig:UseCaseFull}
+unter \textit{bestehende Vorlage bearbeiten} gezeigt, die Möglichkeit besitzen, eine vorher definierte Vorlage an die gegebene
+Problemstellung anzupassen.
 \newline
 \par
 Der zweite Anwendertyp repräsentiert
 einen Projektleiter, der eine Dokumentationsvorlage erstellt und somit allen Entwicklern eine einheitliche Konvention vorgibt.
+Diese Vorlagen müssen an sich ändernde Projektanforderungen angepasst werden können, daher ist der in Abb.~\ref{fig:UseCaseFull} gezeigte
+Anwendungsfall \textit{bestehende Vorlage bearbeiten} auch für Projektleiter gültig.
 
 
 \subsection{Schreiben von Dokumentationen}
@@ -34,25 +40,25 @@ Eine Möglichkeit, jederzeit zu einem vorherigen Schritt zurückzugelangen ist z
 \newline
 \par
 Der Entwickler soll außerdem einzelne
-Schritte als abgeschlossen markieren können. Optional kann auch eine Funktion bereitgestellt werden, die es ermöglicht,
+Schritte als abgeschlossen markieren können. Optional kann eine Funktion bereitgestellt werden, die es ermöglicht,
 alle Schritte auf einmal als abgeschlossen zu markieren. Auf Basis dieser Markierungen ist während des gesamten Dokumentationsprozesses eine Rückmeldung
 über den Gesamtfortschritt der Dokumentation anzuzeigen.
 
 \subsection{Erstellen einer Dokumentationsvorlage}
-\begin{figure}[H] \centering \includegraphics[width=0.60\textwidth]{use_case_template_generator} \caption{Dieses Use Case Diagramm stellt das Erstellen einer Dokumentationsvorlage grafisch dar.}\label{fig:UseCaseTemplate} \end{figure}
+\begin{figure}[H] \centering \includegraphics[width=0.8\textwidth]{use_case_template_generator} \caption{Dieses Anwendungsfalldiagramm stellt das Erstellen und Bearbeiten einer Dokumentationsvorlage grafisch dar.}\label{fig:UseCaseTemplate} \end{figure}
 
 
 Wie in Abb.~\ref{fig:UseCaseTemplate} gezeigt, soll ein Projektleiter die Möglichkeit besitzen, für einen Dokumentationstyp
-benötigte Kapitel und Überschriften in einer Vorlage zu definieren. Hierbei soll zwischen drei Kapiteltypen gewählt werden können:
+benötigte Kapitel und Überschriften in einer Vorlage zu definieren. Hierbei müssen folgende drei Kapiteltypen gewählt werden können:
 
 \begin{itemize}
 \item \textbf{Klassen/Schnittstellendokumentation:} Dieses Kapitel soll eine aus dem Quellcode generierte Schnittstellendokumentation beinhalten.
 Hiermit wird das Konzept \emph{Literate Programming} \ref{ssec:LiterateProgramming} für Programmklassen und Schnittstellen unterstüzt.
-\item \textbf{Quellcode:} Hiermit wird das automatische Einbinden des gesamten Quellcodes als Kapitel ermöglicht.
-\item \textbf{Text:} Ermöglicht das Schreiben eines Textkapitels mithilfe von \latex. Über \latex ist auch das
+\item \textbf{Quellcode:} Dieser Kapiteltyp ermöglicht automatisches Einbinden des gesamten Quellcodes.
+\item \textbf{Text:} Ermöglicht das Schreiben eines Textkapitels mithilfe von \textit{\latex}. Über \textit{\latex} ist das
 Einbinden und Kommentieren von Codesegmenten möglich, somit wird \emph{Elucidative Programming} \ref{ssec:ElucidativeProgramming} unterstüzt.
 \end{itemize}
-Diese Einstellungen sollen dann als Vorlagedatei exportiert und an Entwickler weitergegeben werden können.
+Eine Vorlagedatei speichert diese Einstellungen und kann an andere Entwickler weitergegeben werden.
 
 
 \section{Qualitätsanforderungen}
@@ -72,18 +78,19 @@ muss transparent und nachvollziehbar sein, das bedeutet, dass der Anwender zu je
 
 Um eine einfache Bedienung der Anwendung zu gewährleisten, ist es nötig, dass sich die grafische Oberfläche auf ein Fenster beschränkt. Auf umfangreiche
 Konfigurationsmenüs soll verzichtet werden. Auftretende Hinweismeldungen sind als einfache Textboxen darzustellen.
-Bei der Gestaltung der Menüleiste ist es nötig sich an etablierte Standards von Windows und Linux zu orientieren, dies bedeutet von links nach rechts sollen folgende
-Menüeinträge existieren: Datei, Einstellungen und Hilfe. Außerdem soll die Anwendung sowohl auf Windows als auch auf Linux gleich aussehen.
+Bei der Gestaltung der Menüleiste ist es nötig sich an etablierte Standards von \textit{Windows} und \textit{Linux} zu orientieren, dies bedeutet von links nach rechts sollen folgende
+Menüeinträge existieren: Datei, Einstellungen und Hilfe. Außerdem soll die Anwendung sowohl auf \textit{Windows} als auch auf \textit{Linux} gleich aussehen.
 
 \subsection{Wartbarkeit}
 
-Das Dokumentationsprogramm muss, ohne bestehende Komponenten anpassen zu müssen, erweiterbar sein. Vorlagedateien sollen auch ohne
+Das Dokumentationsprogramm muss erweiterbar sein, ohne bestehende Komponenten anpassen zu müssen. Vorlagedateien sollen ohne
 Dokumentationsprogramm leicht les- und editierbar sein. Um die Einarbeitungszeit für andere Entwickler zu verkürzen sind Kommentarblöcke
 im Quellcode nötig. Außerdem muss dem Entwickler eine technische Dokumentation zur Verfügung stehen.
 
 \subsection{Zuverlässigkeit}
 Der Anwender soll sich darauf verlassen können, dass das Programm zuverlässig läuft und eventuell auftretende Bedienungsfehler seitens des
 Anwenders zu keinem Datenverlust führen. Dazu müssen alle Dateien, bevor sie geladen werden, auf deren Existenz und Richtigkeit geprüft
-werden. Für von einem Benutzer erstellte Dateien ist es nötig, dass diese regelmäßig zwischengespeichert werden und vor der Erzeugung
-der Dateien alle Pfade auf Richtigkeit geprüft werden. Bei einem technischen oder einem Anwenderfehler muss der Anwender in jedem Fall
-über den Fehler informiert werden.
+werden. Außerdem ist es wichtig, dass vor der Erzeugung neuer Dateien alle Pfade auf Richtigkeit geprüft werden und
+erstellte Dateien regelmäßig zwischengespeichert werden.
+Die Anwendung informiert den Benutzer bei einem technischen oder einem Anwenderfehler.
+Als Beispiel für einen technischen Fehler kann man das Fehlschlagen von Speichern aufgrund fehlender Dateisystemberechtigung anführen.
index 73e4649..d39cccc 100644 (file)
@@ -5,7 +5,7 @@ In diesem Kapitel wird die behandelte Problemstellung und Motivation der vorlieg
 Außerdem wird auf die Gliederung dieser Arbeit eingegangen und der Inhalt der einzelnen Kapitel kurz erläutert.
 
 \section{Problemstellung und Motivation}
-Da die Entwicklung von Software viel Zeit in Anspruch nimmt, und unter oft großem Zeitdruck entwickelt wird,
+Da die Entwicklung von Software viel Zeit in Anspruch nimmt, und oft großem Zeitdruck entwickelt wird,
 rückt die Dokumentation dieser meist in den Hintergrund. Das erschwert nicht nur die Einarbeitung neuer Entwickler
 in bestehende Projekte, sondern auch die Wartung und Erweiterung von Programmcodes.
 \newline
@@ -20,7 +20,7 @@ viele können nicht plattformunabhängig eingesetzt werden. Daher wird kaum Zeit
 \newline
 \par
 Zusammenfassend kann man sagen, dass gute Dokumentationen helfen Zeit und Geld zu sparen, da sie die Einarbeitungszeit in ein Projekt verkürzen.
-Außerdem sind sie auch für Endanwender von großem Nutzen, da sie Unklarheiten beseitigen und Hemmschwellen einer neuen Anwendung gegenüber abbauen.
+Außerdem sind sie für Endanwender von großem Nutzen, da sie Unklarheiten beseitigen und Hemmschwellen einer neuen Anwendung gegenüber abbauen.
 Deshalb befasst sich diese Arbeit mit Konzepten zur Software Dokumentation, mit Programmen, die diese Konzepte zum Teil bereits umsetzten
 und der Zusammenführung dieser Programme in einen plattformunabhängigen Prototyp, der den Dokumentationsprozess vereinfachen soll.
 Der Prototyp selbst wird so allgemein wie möglich konzipiert, damit er für verschiedene Typen von Software Projekten eingesetzt werden kann.
@@ -31,13 +31,13 @@ Fachhochschule Hagenberg herangezogen.
 
 
 Ziel dieser Arbeit ist es Dokumentationskonzepte zu beleuchten und auf Basis dieser, eine einfach zu bedienende grafische Benutzeroberfläche für
-Linux und Windows zu entwickeln, die den Anwender beim Schreiben von Software Dokumentationen unterstützt,
+\textit{Linux} und \textit{Windows} zu entwickeln, die den Anwender beim Schreiben von Software Dokumentationen unterstützt,
 indem sie verschiedene Arbeitsschritte für bestehende plattformunabhängige Kommandozeilenprogramme automatisiert.
 \newline
 \par
 Damit sich ein Anwender nicht um Abhängigkeiten kümmern muss, müssen für diesen Prototyp die
 Kommandozeilenprogramme in eine Programmumgebung zusammengefasst werden. Diese Programmumgebung soll zusammen mit dem Prototyp einfach
-auf einem beliebigen Windows oder Linux Zielrechner eingerichtet werden können.
+auf einem beliebigen \textit{Windows} oder \textit{Linux} Zielrechner eingerichtet werden können.
 \newline
 \par
 Des Weiteren soll diese Software vom Anwender auswählbare, vordefinierte Dokumentationsvorlagen besitzen. Eine solche Vorlage definiert den
index 7567ce0..6f80d70 100644 (file)
@@ -7,48 +7,75 @@ genommen.
 
 \section{Struktur des Programms}
 
-\begin{figure} \centering \includegraphics[width=\textwidth]{program_overview} \caption{Dieses Übersichtsbild stellt das Zusammenspiel der einzelnen Komponenten dar.}\label{fig:ProgramOverview} \end{figure}
-Abb.~\ref{fig:ProgramOverview} Beschreibung der Komponenten:
-
-\begin{itemize}
-\item \textbf{Programmumgebung:} Stellt eine Sammlung von bestehenden Programmen und deren Abhängigkeiten dar. Beinhaltet auch eine Designvorlage, auf Basis
-                                 dieser die Dokumentation generiert wird.
-\item \textbf{Quellcode:} Programmquellcode, der in die Dokumentation eingebunden, oder aus dem eine Schnittstellendokumentation generiert werden soll.
-\item \textbf{Dokumentationsprofil:} Ist eine Vorlage die den Aufbau und die Kapitel einer zu erzeugenden Dokumentation definiert.
-\item \textbf{Benutzereingabe:} Hiermit ist die Benutzerinteraktion mit dem Werkzeug gemeint.
-\item \textbf{Dokumentation:} Damit ist die vom Werkzeug erzeugte Dokumentation gemeint. Diese wird auf Basis aller anderen Komponenten erzeugt.
-\item \textbf{Werkzeug:} Das Werkzeug steht stellvertretend für die grafische Benutzeroberfläche.
-\end{itemize}
+\begin{figure} \centering \includegraphics[width=0.7\textwidth]{program_overview} \caption{Dieses Übersichtsbild stellt das Zusammenspiel der einzelnen Komponenten dar.}\label{fig:ProgramOverview} \end{figure}
+
+Wie in Abb.~\ref{fig:ProgramOverview} gezeigt interagiert das \textit{Werkzeug} mit verschiedenen Komponenten um eine \textit{Dokumentation} erstellen zu können.
+Die erste Komponente ist das \textit{Dokumentationsprofil}. Dieses ist eine Vorlage die den Aufbau und die Kapitel einer zu erzeugenden Dokumentation definiert
+und somit dem Benutzer die durchzuführenden Schritte vorgibt. Die nächste Komponente ist der \textit{Quellcode}, der wenn laut Dokumentationsprofil gefordert
+vom Benutzer angegeben werden muss. Dieser \textit{Quellcode} wird dann je nach Vorgabe im \textit{Dokumentationsprofil} entweder in die Dokumentation
+eingebunden oder es wird daraus eine Schnittstellendokumentation generiert. Zum Generieren der \textit{Dokumentation} greift das Werkzeug auf
+eine \textit{Programmumgebung} zurück. Diese stellt eine Sammlung von bestehenden Programmen und deren Abhängigkeiten dar. Außerdem beinhaltet diese
+auch eine Designvorlage, auf deren Basis die Dokumentation erstellt wird. Als \textit{Benutzereingabe} kann jede Interaktion des Anwenders mit der
+grafischen Oberfläche des \textit{Werkzeuges} verstanden werden.
 
 \subsection{Programmumgebung}
 
-Die Programmumgebung beinhaltet Hilfsprogramme die dazu da sind um die in \autoref{cha:Anforderungen} aufgestellten Anforderungen erfüllen zu können.
-Gemeint sind \textit{Doxygen} und \latex, da mithilfe dieser Programme
+Die \textit{Programmumgebung} beinhaltet Hilfsprogramme die dazu da sind um die in \autoref{cha:Anforderungen} aufgestellten Anforderungen erfüllen zu können.
+Gemeint sind \textit{Doxygen} und \textit{\latex}, da mithilfe dieser Programme
 \textit{Literate Programming} \ref{ssec:LiterateProgramming} und
 \textit{Elucidative Programming} \ref{ssec:ElucidativeProgramming} möglich ist.
 
 \subsubsection{Designvorlage}
 
-Als Grundgerüst für die zu generierenden Dokumentationen soll sich eine Designvorlage innerhalb der Programmumgebung befinden. Diese Vorlage
-kann man sich als in \latex geschriebenes Grundgerüst vorstellen. Das Dokumentationswerkzeug füllt die Benutzereingaben in diese Vorlage ein
-und erstellt daraus die Dokumentation.
+Als Grundgerüst für die zu generierenden Dokumentationen dient eine \latex-Vorlage. Das Dokumentationswerkzeug füllt die Benutzereingaben in
+diese Vorlage ein und erstellt daraus die Dokumentation.
 
 \subsection{Dokumentationsprofil}
 Das Dokumentationsprofil ist die Vorlage, die von einem Projektmanager erstellt wird, um den Softwareentwicklern eine einheitliche
 Dokumentationskonvention vorzugeben. Diese soll in einem einheitlichen, von Menschen lesbarem Format als Datei exportiert
-werden können. Es gibt viele Dateiformate, mit denen es möglich ist, Daten strukturiert abzuspeichern. Für die Umsetzung des Prototyps
+werden können. Es gibt viele Dateiformate mit denen es möglich ist, Daten strukturiert abzuspeichern. Für die Umsetzung des Prototyps
 wurden die \textit{JavaScript Object Notation (JSON)} und \textit{Extensible Markup Language (XML)} in Betracht gezogen.
 
 \subsubsection{JavaScript Object Notation}
 
 Das JSON-Format wurde als eine von Menschen leicht lesbare und von Computern leicht zu verarbeitende Sprache entwickelt. Eine der
-Hauptanwendungen ist der Austausch von Daten. Diese werden im JSON Format immer als Schlüsselwort-Wert-Zeichenkette repräsentiert.
+Hauptanwendungen ist der Austausch von Daten. Diese werden im JSON-Format immer als Schlüsselwort-Wert-Zeichenkette repräsentiert.
+Hier ein Beispiel für eine einfache JSON-Struktur, die eine einfache Textnachricht beschreibt:
+\newpage
+\begin{lstlisting}[caption={\textit{JSON} Beispiel}]
+{
+    "senderinfo" :  {
+                        "to" : "Daniel",
+                        "from" : "Kevin"
+                    },
+    "message" : {
+                    "heading" : "Erinnerung",
+                    "body" : "Vergiss den Schlüssel nicht!"
+                }
+}
+\end{lstlisting}
+
+Schlüsselwort und Wert können vom Anwender definiert werden. Wie im Beispiel gezeigt kann ein Wert wiederum eine JSON-Struktur beinhalten.
 
 \subsubsection{Extensible Markup Language}
 
 Das XML-Format ist aufgrund des universellen Repräsentationsformates eine sehr mächtige Auszeichnungssprache. Eine der Hauptanwendungen von
-XML ist das Serialisieren von Objekten, damit Daten zwischen verschiedenen Applikationen ausgetauscht werden können. Diese Auszeichnungssprache
-besitzt keine vordefinierten Tags, somit können vom Anwender eigene definiert werden.
+\textit{XML} ist das Serialisieren von Objekten, damit Daten zwischen verschiedenen Applikationen ausgetauscht werden können. Diese Auszeichnungssprache
+besitzt keine vordefinierten Tags, somit können vom Anwender eigene definiert werden. Im folgenden ein Beispiel für eine XML-Struktur, die eine
+einfache Textnachricht beschreibt:
+
+\begin{lstlisting}[caption={\textit{XML} Beispiel}]
+<note>
+    <senderinfo>
+        <to>Daniel</to>
+        <from>Kevin</from>
+    </senderinfo>
+    <message>
+        <heading>Erinnerung</heading>
+        <body>Vergiss den Schlüssel nicht!</body>
+    </message>
+</note>
+\end{lstlisting}
 
 \subsubsection{Fazit}
 
@@ -57,51 +84,99 @@ Ein entschiedener Nachteil des JSON-Formates gegenüber dem XML-Format ist, das
 \subsubsection{Aufbau der Vorlage}
 
 Aufgrund der oben erläuterten Vorteile wird zum Speichern der Vorlagedateien das XML-Format verwendet. Der Aufbau der XML-Struktur die
-eine Vorlage repräsentieren soll, ist in der Folgenden \textit{Erweiterte Backus-Naur-Form (EBNF)} beschrieben:
+eine Vorlage repräsentieren soll, ist in der folgenden \textit{Erweiterte Backus-Naur-Form (EBNF)} beschrieben:
+
 
+\begin{tcolorbox}[enhanced,breakable,colback=white,colframe=black,coltitle=black,title={\refstepcounter{figure}
+       \textbf{Abbildung \thefigure:} Diese Abbildung zeigt den Aufbau der XML-Struktur.
+       \label{fig:ebnf}},
+       attach boxed title to bottom left,
+       boxed title style={
+       enhanced, colback=white, colframe=white
+      }]
+
+\begin{tcolorbox}[breakable,title={Im Folgenden finden sich allgemeine Definitionen für die häufig verwendeten Strukturen Wort, Zahl und Bool.}]
 \begin{verbatim}
+Buchstabe =    "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
+            "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
+            "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
+            "y" | "z".
 Wort = Buchstabe {Buchstabe}.
-Buchstabe =    "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
-            "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
-            "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z".
 
+Ziffer = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" |
+         "9".
 Zahl = Ziffer {Ziffer}.
-Ziffer = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9".
 
 Bool = "true" | "false".
+\end{verbatim}
+\end{tcolorbox}
 
-Koordinaten = X_Koordinate Y_Koordinate.
+\begin{tcolorbox}[breakable,title={In diesem Abschnitt wird der Aufbau der Koordinatenstruktur beschrieben. Diese Koordinaten werden benötigt,
+um Benutzereingaben in das Deckblatt eintragen zu können.}]
+\begin{verbatim}
 X_Koordinate = "<x_coor>" Zahl "</x_coor>".
 Y_Koordinate = "<y_coor>" Zahl "</y_coor>".
+Koordinaten = X_Koordinate Y_Koordinate.
+\end{verbatim}
+\end{tcolorbox}
+
 
+\begin{tcolorbox}[breakable,title={Hier wird beschrieben, wie die konfigurierten Dateiendungen für die
+Quellcodedateien in der Vorlage abgelegt werden.}]
+\begin{verbatim}
+Header = "<header>" Wort "</header>".
+Source = "<source>" Wort"</source>".
+Dateiendungen = "<fileextensions>"
+                Header Source
+                "</fileextensions>".
+\end{verbatim}
+\end{tcolorbox}
+
+\begin{tcolorbox}[breakable,title={Der Aufbau des Inhaltsverzeichnisses findet sich hier.}]
+\begin{verbatim}
+Aktiv = "<enabled>" Bool "</enabled>".
+Nummerierungstiefe = "<depth>" Ziffer "</depth>".
+Inhaltsverzeichnis = "<toc>" Aktiv Nummerierungstiefe "</toc>".
+\end{verbatim}
+\end{tcolorbox}
+
+\begin{tcolorbox}[breakable,title={Dokumentenname, Ort, Deckblatt, Titelblatt und Gruppe werden durch diese Strukturen beschrieben.}]
+\begin{verbatim}
 Dokumentenname =  "<subjectname>" Wort "</subjectname>".
 Ort = "<location>" Wort "</location>".
 Deckblatt = "<cover_sheet>" Bool "</cover_sheet>".
 Titelblatt = "<title_page>" Bool "</title_page>".
-Inhaltsverzeichnis = "<toc>" Aktiv Nummerierungstiefe "</toc>".
-Aktiv = "<enabled>" Bool "</enabled>".
-Nummerierungstiefe = "<depth>" Ziffer "</depth>".
-Dateiendungen = "<fileextensions>" Header Source "</fileextensions>".
-Header = "<header>" Wort "</header>".
-Source = "<source>" Wort"</source>".
 Gruppe = "<department>" Koordinaten "<department>".
+\end{verbatim}
+\end{tcolorbox}
 
-Autoren = "<authors>" Autor {Autor} "</authors>".
-Autor = "<author>" Nummer Koordinaten Geschäzte_Zeit
-        ID Verbrauchte_Zeit "</author>".
+\begin{tcolorbox}[breakable,title={Die Konfiguration der Autoren wird wie im folgenden Abschnitt gezeigt in der Vorlage abgelegt.}]
+\begin{verbatim}
 Nummer = "<num>" Zahl "</num>".
+Geschäzte_Zeit = "<time_estimated>"
+                 Koordinaten
+                 "</time_estimated>".
 ID = "<id>" Koordinaten "</id>".
 Verbrauchte_Zeit = "<time_spent>" Koordinaten "</time_spent>".
-Geschäzte_Zeit = "<time_estimated>" Koordinaten "</time_estimated>".
 
+Autor = "<author>" Nummer Koordinaten Geschäzte_Zeit
+                   ID Verbrauchte_Zeit "</author>".
+Autoren = "<authors>" Autor {Autor} "</authors>".
+\end{verbatim}
+\end{tcolorbox}
+
+\begin{tcolorbox}[breakable,title={Die Dokumenteinstellungen fassen Dokumentenname, Ort, Deckblatt, Titelblatt, Inhaltsverzeichnis, Dateiendungen
+Gruppe und Autoren zusammen.}]
+\begin{verbatim}
 Dokumenteneinstellung = "<docsettings>" Dokumentenname
                         Ort Deckblatt Titelblatt
-                                               Inhaltsverzeichnis Dateiendungen
+                        Inhaltsverzeichnis Dateiendungen
                         Gruppe Autoren "</docsettings>".
+\end{verbatim}
+\end{tcolorbox}
 
-Mehrere_Kapitel = "<chapters>" Kapitel {Kapitel} "</chapters>".
-Kapitel = "<chapter>" Kapitelname Nummer Dateiname
-          Inhalt Typ Überschrift </chapter>.
+\begin{tcolorbox}[breakable,title={Hier wird die Struktur der Kapitel beschrieben.}]
+\begin{verbatim}
 Kapitelname = "<prettyName>" Wort "</prettyName>".
 Dateiname = "<filename>" Wort "</filename>".
 Inhalt = "<content>" Text "</content>".
@@ -110,9 +185,20 @@ Kapiteltypen = "Text" | "Doxygen" | "Sourcecode".
 Überschrift = "<hierachy>" Überschriften "</hierachy>".
 Überschriften = "chapter" | "section" | "subsection".
 
-Vorlage = Dokumenteneinstellung Mehrere_Kapitel.
+Kapitel = "<chapter>" Kapitelname Nummer Dateiname
+                      Inhalt Typ Überschrift </chapter>.
+Mehrere_Kapitel = "<chapters>" Kapitel {Kapitel} "</chapters>".
+\end{verbatim}
+\end{tcolorbox}
 
+\begin{tcolorbox}[breakable,title={Die gesamte Vorlage umfasst die Dokumenteinstellungen und alle Kapitel.}]
+\begin{verbatim}
+Vorlage = Dokumenteneinstellung Mehrere_Kapitel.
 \end{verbatim}
+\end{tcolorbox}
+\end{tcolorbox}
+
+Die in Abb.~\ref{fig:ebnf} gezeigte \textit{EBNF} wird von oben nach unten immer Allgemeiner und beschreibt den genauen Aufbau des zu verwendenden XML-Formates.
 
 \section{Sicherstellen der Plattformunabhängigkeit}
 
@@ -120,16 +206,16 @@ In diesem Abschnitt wird Schritt für Schritt, durch Vergleichen verschiedener O
 
 \subsection{Programmiersprachen}
 
-Damit der Prototyp auf Linux und Windows Systemen ausgeführt werden kann, muss eine Programmiersprache gewählt werden mit der Anwendungen
+Damit der Prototyp auf \textit{Linux} und Windows-Systemen ausgeführt werden kann, muss eine Programmiersprache gewählt werden mit der Anwendungen
 für diese Betriebssysteme erstellt werden können. Hier werden drei gängige Programmiersprachen verglichen und danach ein Fazit gezogen.
 
 \subsubsection{Java}
 
 \textit{Java} ist eine objektorientierte Programmiersprache, die mithilfe eines speziellen Java-Compilers aus dem Quellcode binären Programmcode
-erzeugt wird. Dieser sogenannte Bytecode wird nicht direkt auf dem Prozessor ausgeführt, sonder in einer virtuellen Maschine. Diese virtuelle
-Maschine wird \textit{Java Virtual Machine (JVM)} genannt. Diese \textit{JVM} ist für Linux und Windows verfügbar, somit kann man in
-\textit{Java} geschriebene Programme sowohl auf Windows als auch auf Linux ausführen und dies ohne, dass man sie für das jeweilige System
-Compilieren muss.
+erzeugt wird. Dieser sogenannte Bytecode wird nicht direkt auf dem Prozessor ausgeführt, sondern in einer virtuellen Maschine. Diese virtuelle
+Maschine wird \textit{Java Virtual Machine (JVM)} genannt. Diese \textit{JVM} ist für \textit{Linux} und \textit{Windows} verfügbar, somit kann man in
+\textit{Java} geschriebene Programme sowohl auf \textit{Windows} als auch auf \textit{Linux} ausführen und dies ohne, dass man sie für das jeweilige System
+kompilieren muss.
 
 \subsubsection{C++}
 
@@ -141,11 +227,11 @@ werden für diese es kompiliert wurde.
 \subsubsection{Python}
 \textit{Python} ist eine interpretierte, interaktive und objektorientierte Programmiersprache. Das bedeutet Python Programme
 müssen nicht kompiliert werden da die Befehle zur Laufzeit von einem Interpreter ausgeführt werden. Es gibt Python Interpreter
-für Windows und Linux somit kann für diese Zielsysteme entwickelt werden.
+für \textit{Windows} und \textit{Linux} somit kann für diese Zielsysteme entwickelt werden.
 
 
 \subsubsection{Fazit}
-Da um \textit{Java} Applikationen ausführen zu können auf den Zielsystemen eine Java-Laufzeitumgebung vorhanden sein muss und dies eine
+Um Java-Applikationen ausführen zu können, muss auf dem Zielsystem eine Java-Laufzeitumgebung vorhanden sein. Da dies eine
 zusätzliche Abhängigkeit bedeutet ist diese Programmiersprache für die Entwicklung des Prototyps eher unpraktisch.
 Ähnliches gilt für \textit{Python}, da hier ein entsprechender Interpreter benötigt wird. Somit wird für die
 Entwicklung des Prototyps \textit{C++} als Programmiersprache gewählt.
@@ -153,16 +239,13 @@ Entwicklung des Prototyps \textit{C++} als Programmiersprache gewählt.
 \subsection{Compiler}
 
 Um den Portierungsaufwand so gering wie möglich zu halten, macht es Sinn den Prototypen auf einer Plattform zu entwickeln und dann
-für alle Zielplattformen zu Crosskompilieren. Um dies ohne großen Portierungsaufwand durchführen zu können, sollten alle Compiler
+für alle Zielplattformen zu cross-kompilieren. Unter cross-kompilieren versteht man das Kompilieren eines Programmes für ein fremdes Zielsystem.
+Für den Prototypen bedeutet dies, dass dieser auf einem Linux-Hostsystem für \textit{Windows} kompiliert werden muss. Dazu wird ein entsprechender Compiler
+benötigt der diese Operation unterstützt. Um den Portierungsaufwand so gering wie möglich zu halten, sollten alle Compiler
 von derselben Compilerfamilie sein. Daher wurde die \textit{GNU Compiler Collection (GCC)} zum Erstellen der Linuxanwendung und der \textit{mingw-w64}
-Compiler zum Erstellen der Windowsanwendung gewählt.
-
-\subsubsection{GCC}
-Die GCC ist der Standardcompiler aller namhaften Linuxdistributionen.
-
-\subsubsection{mingw-w64}
-Das \textit{mingw-w64} ist eine vollständige Portierung der \textit{GCC} für Windows. Dieser Compiler ist aber auch unter Linux verfügbar.
-Somit ist es möglich, Windows Applikationen auf Linux zu kompilieren.
+Compiler zum Erstellen der Windowsanwendung gewählt. Die GCC ist der Standardcompiler aller namhaften Linuxdistributionen.
+Das \textit{mingw-w64} ist eine vollständige Portierung der \textit{GCC} für \textit{Windows}. Dieser Compiler ist aber auch unter allen gängigen Linuxdistributionen
+verfügbar, somit ist es möglich, Windows-Applikationen auf \textit{Linux} zu kompilieren (cross-kompilieren).
 
 \subsection{Linken externer Bibliotheken}
 Im folgenden Abschnitt wird erklärt, wie ein Programm mit externen Bibliotheken umgehen kann. Die verschiedenen Möglichkeiten
@@ -186,27 +269,27 @@ unabhängig bleibt.
 \subsection{Grafikbiliotheken}
 
 Um eine plattformunabhängige grafische Oberfläche erstellen zu können, wird eine entsprechende Programmbibliothek benötigt.
-Im nachfolgenden Abschnitt werden drei solcher Bibliotheken analysiert und gegenübergestellt. Es wird ein besonderes Augenmerk
+Im nachfolgenden Abschnitt werden drei solcher Bibliotheken analysiert und gegenübergestellt. Es wird besonderes Augenmerk
 auf statische Linkbarkeit und das verwendete Lizenzmodell gelegt.
 
 \subsubsection{Qt Framework}
 Das \textit{Qt Framework} ist eine sehr mächtige Bibliothek zum Erstellen von plattformunabhängigen Anwendungen. Mit dem Programm
-\textit{Qt Creator} besitzt dieses Framework sogar eine eigene Entwicklungsumgebung.
+\textit{Qt Creator} besitzt dieses Framework eine eigene Entwicklungsumgebung.
 Diese Bibliothek ist unter einer dualen Lizenz lizenziert, die statisches Linken dieser Bibliothek nur gegen Bezahlung einer Gebühr
 erlaubt.
 
 \subsubsection{wxWidgets}
-\textit{wxWidgets} ist ein quelloffenes C++ Programmiergerüst, welches erstellen von
-plattformunabhängigen grafischen Oberflächen ermöglicht. Diese haben ein systemnatives Aussehen, da diese Programmbibliothek die Systemschnittstellen des Zielsystems zum Visualisieren verwendet.
+\textit{wxWidgets} ist ein quelloffenes C++ Programmiergerüst zum Erstellen von
+plattformunabhängigen grafischen Oberflächen. Diese haben ein systemnatives Aussehen, da diese Programmbibliothek die Systemschnittstellen des Zielsystems zum Visualisieren verwendet.
 Dieses Programmiergerüst ist unter der \textit{wxWindows Library Licence} lizenziert. Diese Lizenz erlaubt eine freie Verwendung in
-privaten und kommerziellen Programmen. Ein statisches Linken von \textit{wxWidgets} ist zwar möglich, gestaltet sich aber vor allem unter Linux schwierig,
+privaten und kommerziellen Programmen. Ein statisches Linken von \textit{wxWidgets} ist zwar möglich, gestaltet sich aber vor allem unter \textit{Linux} schwierig,
 da dieses Programmiergerüst von vielen Systembibliotheken abhängt.
 
 \subsubsection{Fast Light Toolkit (FLTK)}
 Das \textit{Fast Light Toolkit} ist ebenfalls ein C++ Programmiergerüst zum Erstellen von grafischen Benutzeroberflächen.
 Es wird von UNIX, Microsoft Windows und Apple OS X unterstützt und unterscheidet sich von den anderen beiden Bibliotheken, indem
-es dafür konzipiert wurde, statisch gelinkt zu werden. Was \textit{FLTK} auszeichnet, ist, dass es kaum Speicherplatz
-benötigt. Lizensiert ist diese Bibliothek unter der \textit{GNU Library General Public License} mit der Ausnahme, dass sie auch
+es dafür konzipiert wurde, statisch gelinkt zu werden. Ein weiteres Merkmal von \textit{FLTK} ist, dass es kaum Speicherplatz benötigt.
+Lizenziert ist diese Bibliothek unter der \textit{GNU Library General Public License} mit der Ausnahme, dass sie auch
 in kommerziellen Programmen statisch gelinkt werden darf.
 
 
@@ -215,7 +298,7 @@ Das \textit{Qt Framework} kann für den Prototyp leider nicht verwendet werden,
 \newline
 \par
 Ein Verwenden von \textit{wxWidgets} wäre lizenztechnisch zwar möglich, leider muss aber davon ausgegangen werden, dass es beim statischen Linken zu Komplikationen
-kommen kann. Außerdem würden die erstellten grafischen Oberflächen auf unter Linux und Windows unterschiedlich aussehen, da diese Bibliothek
+kommen kann. Außerdem würden die erstellten grafischen Oberflächen unter \textit{Linux} und \textit{Windows} unterschiedlich aussehen, da diese Bibliothek
 die Visualisierungen mithilfe der Systemschnittstellen des Zielsystems zeichnet. Dies würde dann den in \autoref{cha:Anforderungen} definierten
 Anforderungen widersprechen.
 \newline
@@ -226,11 +309,11 @@ des Prototypen \textit{FLTK} verwendet.
 
 \section{Aufbau der Benutzeroberfläche}
 \label{sc:aufbauGui}
-\begin{figure}[H] \centering \includegraphics[width=0.7\textwidth]{gui_aufbau} \caption{In dieser Skizze wird der angestrebte Aufbau der Benutzeroberfläche dargestellt.}\label{fig:guiDesign} \end{figure}
+\begin{figure}[H] \centering \includegraphics[width=0.5\textwidth]{gui_aufbau} \caption{In dieser Skizze wird der angestrebte Aufbau der Benutzeroberfläche dargestellt.}\label{fig:guiDesign} \end{figure}
 
 Die Benutzeroberfläche soll wie in der Skizze Abb.~\ref{fig:guiDesign} gezeigt folgende Elemente besitzen:
 \begin{enumerate}
-\item ein Startmenü nach etablierten Standards von Windows und Linux
+\item ein Startmenü nach etablierten Standards von \textit{Windows} und \textit{Linux}
 \item eine Liste in der das zu editierende Kapitel ausgewählt werden kann
 \item hier sollen sich Elemente zum definieren der Autoren befinden
 \item Textfeld zum schreiben des aktuell ausgewählten Kapitels
@@ -242,23 +325,24 @@ Die Benutzeroberfläche soll wie in der Skizze Abb.~\ref{fig:guiDesign} gezeigt
 \end{enumerate}
 
 \subsection{Separieren von grafischer Bedienoberfläche und Funktionalität}
+Um gut strukturierten Programmcode zu schreiben, macht es Sinn die grafische Oberfläche von der Programmlogik strikt voneinander zu trennen. Dies kann erreicht werden
+indem man sich an das in Abb.~\ref{fig:MVCImage} dargestellte \textit{Model-View-Controller (MVC)} Konzept hält.
 
 \begin{figure}[!htbp] \centering \includegraphics[width=\textwidth]{mvc} \caption{Hier wird ein Übersichtsbild des Model-View-Controller Konzepts dargestellt.\cite{mvcImage}}\label{fig:MVCImage} \end{figure}
 
-Um gut strukturierten Programmcode zu schreiben, macht es Sinn die grafische Oberfläche von der Programmlogik strikt voneinander zu trennen. Dies kann erreicht werden
-indem man sich an das in Abb.~\ref{fig:MVCImage} dargestellte \textit{Model-View-Controller (MVC)} Konzept hält. Hierbei wird das Programm in Model, View und Controller unterteilt. Hält man sich an dieses Konzept
-erhält man, nicht nur gut strukturierten, sondern auch einen viel modulareren Code und kann flexibler auf sich ändernde Anforderungen reagieren.
+Hierbei wird das Programm in \textit{Model}, \textit{View} und \textit{Controller} unterteilt. Hält man sich an dieses Konzept,
+erhält man gut strukturierten, modularen Code und kann flexibel auf sich ändernde Anforderungen reagieren.
 
 \subsubsection{Model}
-Das Model ist für das Verwalten und halten der Daten zuständig. Außerdem wird im Model auch die Programmfunktionalität umgesetzt.
+Das \textit{Model} ist für das Verwalten und halten der Daten zuständig. Außerdem wird im \textit{Model} auch die Programmfunktionalität umgesetzt.
 
 \subsubsection{View}
-Die View ist für die Präsentation der im Model enthaltenen Daten zuständig und ist somit die Schnittstelle für Benutzerinteraktionen.
-Bei Änderungen der Daten im Model wird die View benachrichtigt, damit sich diese neu zeichnen kann.
+Die \textit{View} ist für die Präsentation der im \textit{Model} enthaltenen Daten zuständig und ist somit die Schnittstelle für Benutzerinteraktionen.
+Bei Änderungen der Daten im \textit{Model} wird die \textit{View} benachrichtigt, damit sich diese neu zeichnen kann.
 
 \subsubsection{Controller}
-Der Controller gibt Benutzerinteraktionen von der View an das Model weiter. Oft stellt der Controller nur wenig Funktionalitäten zur Verfügung
-und könnte eigentlich weggelassen werden. Dies ist auch der Grund warum in Abb.~\ref{fig:MVCImage} View und Controller als Tool
+Der \textit{Controller} gibt Benutzerinteraktionen von der \textit{View} an das \textit{Model} weiter. Oft stellt der \textit{Controller} nur wenig Funktionalitäten zur Verfügung
+und könnte eigentlich weggelassen werden. Dies ist auch der Grund warum in Abb.~\ref{fig:MVCImage} \textit{View} und \textit{Controller} als Tool
 zusammengefasst dargestellt werden. Dennoch sollte man auf die Implementierung eines Controllers nicht verzichten, da er eine Abstraktionsschicht
-zwischen Model und View darstellt. Bei strukturellen Änderungen im Model kann im Controller darauf eingegangen werden, somit muss die View nicht
+zwischen \textit{Model} und \textit{View} darstellt. Bei strukturellen Änderungen im \textit{Model} kann im \textit{Controller} darauf eingegangen werden, somit muss die \textit{View} nicht
 angepasst werden.
index cf3a88d..c99ac92 100644 (file)
@@ -1,68 +1,82 @@
-\chapter{Projektumsetzung}
+\chapter{Prototyp-Entwicklung}
 \label{cha:Projektumsetzung}
 
 In diesem Kapitel wird die Implementierung des Prototyps anhand des im letzten Kapitel aufgezeigten Konzeptes erläutert.
-Als Entwicklungssystem wird ein Rechner mit der Linuxdistribution \textit{Debian 9} (64Bit) verwendet. Im Folgendem wird Bezug
+Als Entwicklungssystem wird ein Rechner mit der Linuxdistribution \textit{Debian 9} (64Bit) verwendet. Im folgenden wird Bezug
 auf die Quellen \cite{mvc}, \cite{observer}, \cite{johnson1998anwendungen}, \cite{CrossDevWorkflow}, \cite{LinuxCert}, \cite{wine} und \cite{fltkMan} genommen.
 
 \section{Implementierung des Prototypen}
 
 Im kommenden Abschnitt wird die Umsetzung der einzelnen Komponenten des Prototyps beschrieben. Da der Prototyp im Wesentlichen
-aus den drei Komponenten des MVC Konzepts besteht, ist der folgende Abschnitt in die Implementierung dieser gegliedert.
+aus den drei Komponenten des MVC-Konzepts besteht, ist der folgende Abschnitt in die Implementierung dieser gegliedert.
 
 \subsection{Implementierung des Models}
-Das Model hält alle Daten und ist für das Laden und Speichern der XML-Vorlagedateien verantwortlich. Außerdem beinhaltet es die Programmlogik
+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
 zum Generieren der Dokumentationen.
-Das Parsen der XML-Dateien übernimmt hierbei die Programmbibliothek \textit{tinyxml2}. Per Vorlage geladene oder neu erstellte Kapitel und Autoren
+Das Parsen der XML-Dateien übernimmt die Programmbibliothek \textit{tinyxml2}. Per Vorlage geladene oder neu erstellte Kapitel und Autoren
 werden innerhalb des Models als Listen spezieller Autor- und Kapitelobjekte abgelegt.
 
 \subsubsection{Author Objekte}
-\begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{author} \caption{Hier wird der Aufbau der Autor Klasse dargestellt.}\label{fig:Author} \end{figure}
+\begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{author} \caption{Hier wird der Aufbau der Autor-Klasse dargestellt.}\label{fig:Author} \end{figure}
 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
 zu speichern.
 
 \subsubsection{Kapitel Objekte}
 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.
-Das Model besitzt die Möglichkeit, diese verschiedenen Kapiteltypen mithilfe einer sogenannten Simple-Factory-Klasse zu erzeugen.
-\begin{figure}[H] \centering \includegraphics[width=\textwidth]{simple_factory} \caption{Dises UML Diagramm zeigt die Funktionsweise der \textit{ChapterFactory}-Klasse.}\label{fig:ChaptFact} \end{figure}
-Abb.~\ref{fig:ChaptFact} zeigt die Funktionsweise dieser Simple-Factory-Klasse. Die \textit{createChapter} Funktionen erlauben das erzeugen von verschiedenen
-Kapitel Objekten. Über diese Klasse kann auch eine Liste der verfügbaren Kapiteltypen angefordert werden.
-
-\subsubsection{FSHelper Klasse}
-Funktionen, die plattformabhängige Operationen, wie zum Beispiel Dateisystemzugriffe, zur Verfügung stellen, werden in einer eigenen FSHelper
-Klasse gekapselt. Die Funktionen sind jeweils für Linux und für Windows implementiert, und über Präprozessor Makros wird der passende
+Das \textit{Model} besitzt die Möglichkeit, diese verschiedenen Kapiteltypen mithilfe einer sogenannten Simple-Factory-Klasse zu erzeugen.
+\begin{figure}[] \centering \includegraphics[width=\textwidth]{simple_factory} \caption{Dises UML Diagramm zeigt die Funktionsweise der ChapterFactory-Klasse.}\label{fig:ChaptFact} \end{figure}
+Abb.~\ref{fig:ChaptFact} zeigt die Funktionsweise dieser Simple-Factory-Klasse. Die \textit{createChapter} Funktionen erlauben das Erzeugen von verschiedenen
+Kapitelobjekten. Über diese Klasse kann auch eine Liste der verfügbaren Kapiteltypen angefordert werden.
+
+\subsubsection{FSHelper-Klasse}
+Funktionen, die plattformabhängige Operationen, wie zum Beispiel Dateisystemzugriffe, zur Verfügung stellen, werden in einer eigenen FSHelper-Klasse
+gekapselt. Die Funktionen sind jeweils für \textit{Linux} und für \textit{Windows} implementiert, und über Präprozessor Makros wird der passende
 Code in die Funktionen kompiliert.
 
 \subsubsection{Benachrichtigung der View}
-\begin{figure}[H] \centering \includegraphics[width=\textwidth]{observer} \caption{Dieses UML Diagramm zeigt das wie das Model mit der View über das Observer Entwurfsmuster interagiert.}\label{fig:Observer} \end{figure}
-Finden Änderungen im Model statt, muss laut MVC Konzept zumindest die View darüber informiert werden. Dies kann mithilfe des Observer Entwurfsmuster umgesetzt werden. Wie man in Abb.~\ref{fig:Observer} erkennen kann, leitet die View von einer abstrakten Object Klasse ab und muss die Funktion
-\textit{updatedBySubject} implementieren. Das Model leitet von Subject ab, somit kann die View über die Funktion \textit{notifyObservers} über Änderungen benachrichtigt werden.
+\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}
+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,
+leitet die \textit{View} von einer abstrakten Object-Klasse ab und muss die Funktion
+\textit{updatedBySubject} implementieren. Das \textit{Model} leitet von Subject ab, somit kann die \textit{View} über die Funktion \textit{notifyObservers} über Änderungen benachrichtigt werden.
 
 
 
 \subsection{Implementierung der View}
 
-\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}
+\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}
 
-Die View Klasse repräsentiert den Teil des Prototyps, mit dem der Benutzer interagiert. Das Benutzerinterface wird mit der plattformunabhängigen
+Die View-Klasse repräsentiert den Teil des Prototyps, mit dem der Benutzer interagiert. Das Benutzerinterface wird mit der plattformunabhängigen
 Programmbibliothek \textit{FLTK} erstellt. Dieses bietet die Möglichkeit mithilfe des Programms
-\textit{FLUID} grafische Oberflächen zu designen.
+\textit{FLUID} grafische Oberflächen zu entwerfen.
 \newline
 \par
 Hierbei werden die einzelnen Grafikobjekte, wie in Abb.~\ref{fig:fluid} dargestellt, mithilfe von Drag \& Drop zusammengefügt. Aus diesem
-Design lässt sich dann eine Basisklasse generieren, von der die wirkliche View Klasse abgeleitet werden kann. In der abgeleiteten Klasse kann dann die
-Funktionalität über Callbackfunktionen, die von den einzelnen Grafikobjekten ausgelöst werden, implementiert werden. Über diese Funktionen
-werden Anfragen über den Controller an das Model weitergeleitet.
+Design lässt sich dann eine Basisklasse generieren, von der die wirkliche View-Klasse abgeleitet werden kann. In der abgeleiteten Klasse kann
+die Funktionalität über Callbackfunktionen, die von den einzelnen Grafikobjekten ausgelöst werden, implementiert werden. Über diese Funktionen
+werden Anfragen über den \textit{Controller} an das \textit{Model} weitergeleitet.
 
 \subsection{Implementierung des Controllers}
 
-Der Controller gibt Anfragen der View an das Model weiter und gibt diesem die Anweisung die View über Änderungen zu benachrichtigen.
-Er bietet außerdem eine Zwischenschicht, um bei strukturellen Änderungen im Model die Aufrufe der View zu konvertieren.
+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}
+über Änderungen zu benachrichtigen. Er bietet außerdem eine Zwischenschicht, um bei strukturellen Änderungen im
+\textit{Model} die Aufrufe der \textit{View} zu konvertieren.
+
+\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}
+
+\subsection{Übersichtsklassendiagramm}
+
+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
+von der Model-Klasse verwendet, da diese die Programmlogik beinhaltet.
+
+\begin{figure}[H] \centering \includegraphics[width=\textwidth]{full} \caption{Dieses UML-Diagramm veranschaulicht wie alle Komponenten miteinander interagieren.}\label{fig:full} \end{figure}
+
+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
+eingeführt wurde. Diese Interface-Klassen sollen die \textit{View} komplett von \textit{Model} und \textit{Controller} entkoppeln.
 
 \section{Kompilieren und Linken}
 
-Um so wenig Abhängigkeiten, wie möglich zu erhalten wird auf Linux und auf Windows versucht so viel
-wie möglich statisch in die Programme zu linken. Damit dies möglich ist, müssen aber zuerst die externen Programmbibliotheken
+Um so wenig Abhängigkeiten wie möglich zu erhalten, wird auf \textit{Linux} und auf \textit{Windows} versucht so viel
+wie möglich statisch in die Programme zu linken. Damit dies möglich ist, müssen zuerst die externen Programmbibliotheken
 kompiliert werden.
 
 \subsection{Installieren der Abhängigkeiten}
@@ -75,17 +89,17 @@ $ sudo mv /usr/lib/llvm-3.9/lib/libclang-3.9.so.1 /usr/lib/llvm-3.9/lib/libclang
 $ 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
 \end{lstlisting}
 Dies installiert benötigte Programmbibliotheken und die passenden Compiler.
-Um auf Linux für Windows Crosskompilieren zu können, benötigt man den \textit{mingw-w64} Compiler. Dieser ist weitgehend mit dem GNU Compiler für Linux kompatibel.
+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.
 Als Crosskompilieren versteht man das Bauen eines Programmes für ein fremdes Zielsystem.
 \newline
 \par
-Damit die \textit{FLTK} Unittest beim Crosskompilieren für Windows nicht fehlschlagen, muss auch \textit{Wine} installiert werden. Dies geschieht
+Damit die FLTK-Unittests beim cross-kompilieren für \textit{Windows} nicht fehlschlagen, muss \textit{Wine} installiert werden. Dies geschieht
 wie folgt über den Paketmanager:
 \begin{lstlisting}[language=bash]
 $ sudo apt install -y wine wine32 wine64 libwine libwine:i386 fonts-wine wine-binfmt
 $ sudo update-binfmts --import /usr/share/binfmts/wine
 \end{lstlisting}
-\textit{Wine} kann als eine Windowskompatibilitätsschicht verstanden werden, die es ermöglicht Windows Programme auf Linux Systemen auszuführen.
+\textit{Wine} kann als eine Windowskompatibilitätsschicht verstanden werden, die es ermöglicht Windows-Programme auf Linux-Systemen auszuführen.
 
 \subsection{Linux}
 
@@ -93,7 +107,7 @@ $ sudo update-binfmts --import /usr/share/binfmts/wine
 
 Mithilfe des im FLTK-Quellcode bereitgestellten Konfigurationsskripts muss die Prozessorarchitektur angegeben werden. Außerdem müssen alle nicht
 benötigten Abhängigkeiten deaktiviert werden.
-Mit dem Befehl \textit{make} wird dann der Buildprozess gestartet und die statische Programmbibliothek erzeugt.
+Mit dem Befehl \textit{make} wird der Buildprozess gestartet und die statische Programmbibliothek erzeugt.
 \begin{lstlisting}[language=bash]
 $ ./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
 $ make
@@ -111,7 +125,7 @@ $ ar rvs libtinyxml2.a tinyxml2.o
 \subsubsection{Prototyp}
 \label{ssc:LinkingLinux}
 
-Der Prototyp muss unter Linux mit folgenden Linker Parametern gelinkt werden:
+Der Prototyp muss unter \textit{Linux} mit folgenden Linker-Parametern gelinkt werden:
 
 \begin{lstlisting}
 -static-libstdc++
@@ -123,27 +137,27 @@ Der Prototyp muss unter Linux mit folgenden Linker Parametern gelinkt werden:
 -lX11
 \end{lstlisting}
 
-Leider ist es nicht möglich alle Programmbibliotheken statisch in ein Programm zu linken, da Linux Systeme komplett auf dynamische
+Leider ist es nicht möglich alle Programmbibliotheken statisch in ein Programm zu linken, da Linux-Systeme komplett auf dynamische
 Bibliotheken aufgebaut sind. Es ist vor allem nicht möglich, die Standard C Bibliothek des Betriebssystems statisch zu linken.
 \newline
 \par
-Eine Plattformunabhängigkeit zwischen verschiedenen Linux Derivaten herzustellen erweist sich somit als ziemlich schwierig,
+Eine Plattformunabhängigkeit zwischen verschiedenen Linux-Derivaten herzustellen erweist sich somit als ziemlich schwierig,
 da nicht alle Systeme eine einheitliche Version der Standard C Bibliothek besitzen. Dieses Problem kann umgangen werden, indem alle
-benötigten dynamischen Bibliotheken in der Programmumgebung mitgeliefert werden. Das Programm muss dann über ein Bash-Startskript
+benötigten dynamischen Bibliotheken in der Programmumgebung mitgeliefert werden. Das Programm muss über ein Bash-Startskript
 mit dem gleichen dynamischen Lader, mit dem auch das Programm gelinkt wurde, gestartet werden.
 \newline
 \par
-Es müssen dann aber auch alle externen Programme mit demselben Lader gestartet werden.
-Diese Funktion übernimmt die \textit{FSHelper} Klasse. Externe Programme können aber nicht wie bei Windows mit
-mit dem POSIX konformen \textit{system} Befehl gestartet werden, da dies eine Shell mit dem dynamischen Lader des Betriebssystems
-erzeugen würde. Es müssen daher externe Programme mithilfe von \textit{fork} und textit{exec} aufgerufen werden.
+Es müssen ebenfalls alle externen Programme mit demselben Lader gestartet werden.
+Diese Funktion übernimmt die FSHelper-Klasse. Externe Programme können aber nicht wie bei \textit{Windows} mit
+dem POSIX konformen system-Befehl gestartet werden, da dies eine Shell mit dem dynamischen Lader des Betriebssystems
+erzeugen würde. Es müssen daher externe Programme mithilfe von \textit{fork} und \textit{exec} aufgerufen werden.
 
 \subsection{Windows}
 
 \subsubsection{FLTK}
 
-Unter Windows muss zum Kompilieren der statischen \textit{FLTK} Programmbibliothek neben der Prozessorarchitektur auch noch
-der zu verwendende \textit{mingw-w64} Compiler angegeben werden.
+Unter \textit{Windows} muss zum Kompilieren der statischen FLTK-Programmbibliothek neben der Prozessorarchitektur der zu verwendende
+\textit{mingw-w64} Compiler angegeben werden.
 
 \begin{lstlisting}[language=bash]
 $ ./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
@@ -152,7 +166,7 @@ $ make
 
 \subsubsection{tinyxml2}
 
-Die statische \textit{tinyxml2} Programmbibliothek wird analog wie bei Linux erstellt, nur dass der \textit{mingw-w64} Compiler verwendet wird.
+Die statische \textit{tinyxml2} Programmbibliothek wird analog wie bei \textit{Linux} erstellt, nur dass der \textit{mingw-w64} Compiler verwendet wird.
 
 \begin{lstlisting}[language=bash]
 $ i686-w64-mingw32-g++ -c -o tinyxml2.o tinyxml2.cpp
@@ -161,7 +175,7 @@ $ i686-w64-mingw32-ar rvs libtinyxml2.a tinyxml2.o
 
 \subsubsection{Prototyp}
 
-Unter Windows muss der Prototyp mit diesen Parametern gelinkt werden:
+Unter \textit{Windows} muss der Prototyp mit diesen Parametern gelinkt werden:
 
 \begin{lstlisting}
 -mwindows
@@ -174,7 +188,7 @@ Unter Windows muss der Prototyp mit diesen Parametern gelinkt werden:
 -lcomctl32
 \end{lstlisting}
 
-Für Windows können alle Komponenten in ein einziges ausführbares Programm gelinkt werden.
+Für \textit{Windows} können alle Komponenten in ein einziges ausführbares Programm gelinkt werden.
 
 \section{Programmumgebung}
 
@@ -185,14 +199,14 @@ Programmumgebung gepackt werden. Diese Programmumgebung gliedert sich in folgend
 \item \textbf{bin:} Dieses Verzeichnis beinhaltet das kompilierte Dokumentationswerkzeug und die \textit{Doxygen} Anwendung.
 \item \textbf{lib:} Im Unterordner \textit{lib} werden etwaige Abhängigkeiten abgelegt. Dies ist vor allem für die Linuxumgebung relevant um
                     Programmbibliotheken, die man nicht statisch linken kann mit in die Programmumgebung zu packen.
-\item \textbf{etc:} In diesem Verzeichnis ist die \latex Designvorlage gespeichert.
+\item \textbf{etc:} In diesem Verzeichnis ist die \latex-Designvorlage gespeichert.
 \item \textbf{texlive\_windows/texlive\_linux:} Die Namensgebung dieses Ordners ist abhängig vom Betriebssystem. Hier wird die vollständige
-\textit{Texlive} Installation abgelegt.
+Texlive-Installation abgelegt.
 \end{itemize}
-Der Inhalt dieser Verzeichnisse muss an das jeweilige Betriebssystem angepasst werden, da sonst die Programme nicht ausführbar wären.
+Der Inhalt dieser Verzeichnisse muss an das jeweilige Betriebssystem angepasst werden, da sonst die Programme nicht ausführbar sind.
 
 \subsection{Programmumgebung Linux}
-\textit{Texlive} wird mithilfe der Offiziellen Installationsroutine \cite{texlive} als portable Version in das Unterverzeichnis \textit{texlive\_linux}
+\textit{Texlive} wird mithilfe der offiziellen Installationsroutine \cite{texlive} als portable Version in das Unterverzeichnis \textit{texlive\_linux}
 installiert.
 \newline
 \par
@@ -254,17 +268,17 @@ Dokumentationswerkzeug indirekt über den dynamischen Lader \textit{ld-linux.so.
 
 \subsection{Programmumgebung Windows}
 
-\textit{Texlive} für Windows wird auch mit der Offiziellen Installationsroutine auf dem Linux System erstellt. Damit dies funktioniert, muss
-die Windows Installationsroutine auf dem Linux System mithilfe von \textit{Wine} ausgeführt werden. Es wird hier auch
+\textit{Texlive} für \textit{Windows} wird mit der offiziellen Installationsroutine auf dem Linux-System erstellt. Damit dies funktioniert, muss
+die \textit{Windows} Installationsroutine auf dem Linux-System mithilfe von \textit{Wine} ausgeführt werden. Es wird
 die portable Version von \textit{Texlive} in das Unterverzeichnis \textit{texlive\_windows} installiert.
 \newline
 \par
-Um \textit{Doxygen} in dem Unterverzeichnis \textit{bin} bereitzustellen, werden direkt die von der Offiziellen Doxygen Website zur Verfügung
-gestellten Windows Programmdateien verwendet \cite{doxywin}.
+Um \textit{Doxygen} in dem Unterverzeichnis \textit{bin} bereitzustellen, werden direkt die von der offiziellen Doxygen Website zur Verfügung
+gestellten \textit{Windows} Programmdateien verwendet \cite{doxywin}.
 
 \subsubsection{Start Skript}
 
-Wie unter Linux muss auch hier die Programmumgebung mithilfe eines Startskriptes initialisiert werden.
+Wie unter \textit{Linux} muss hier die Programmumgebung mithilfe eines Startskriptes initialisiert werden.
 
 \begin{lstlisting}[caption={Batch Start Skript}]
 @echo off
@@ -272,19 +286,18 @@ set path=%CD%\texlive_windows\2018\bin\win32;%CD%\bin;%PATH%
 start doc_tool
 \end{lstlisting}
 
-Auch hier erweitert das Skript den Systempfad um die Pfade der Programmumgebung um Zugriff auf \textit{Doxygen} und \textit{Texlive} zu ermöglichen.
+Das Skript erweitert den Systempfad um die Pfade der Programmumgebung um Zugriff auf \textit{Doxygen} und \textit{Texlive} zu ermöglichen.
 
 
 \section{Pakete Erstellen}
 
-Um das Dokumentationsprogramm mit all seinen Abhängigkeiten leicht weitergeben und auf verschiedenen Systemen einrichten zu können,
+Um das Dokumentationsprogramm mit all seinen Abhängigkeiten weitergeben und auf verschiedenen Systemen einrichten zu können,
 ist es nötig, die gesamte Programmumgebung in ein komprimiertes Paket zusammenzufassen.
 
 \subsection{Linux}
-Unter Linux ist \textit{.tar.gz} eines der gängigsten Kompressionsformate. Daher kann davon ausgegangen werden, dass alle Linuxsysteme
+Unter \textit{Linux} ist \textit{.tar.gz} eines der gängigsten Kompressionsformate. Daher kann davon ausgegangen werden, dass alle Linuxsysteme
 ein Entpacken solcher Archive unterstützten. Um ein \textit{.tar.gz} Archiv in ein selbstextrahierendes Archiv umzuwandeln, kann man
-in den Anfang der Archivdatei ein Shellskript einfügen. Dieses Shellskript muss dann das komprimierte Paket, das sich
-in derselben Datei befindet, entpacken.
+in den Anfang der Archivdatei ein Shellskript einfügen. Dieses Shellskript muss das komprimierte Paket am Ende der Datei entpacken.
 \newline
 \par
 Es wurde ein Hilfsprogramm geschrieben, das \textit{.tar.gz} Pakete mithilfe der gerade aufgezeigten Methode
@@ -390,12 +403,43 @@ chmod a+x $SELF_EXTRACTABLE
 \end{lstlisting}
 
 \subsection{Windows}
-Das gängigste Kompressionsformat unter Windows ist \textit{zip}. Daher wird auch dieses
-als zum Packen der gesamten Programmumgebung gewählt. Mithilfe des Programmes \textit{7zip} kann unter Linux ein selbstextrahierendes Programm erzeugt werden, das eine Fortschrittsanzeige
-besitzt und sich unter Windows ausführen lässt.
+Das gängigste Kompressionsformat unter \textit{Windows} ist \textit{zip}, daher wurde dieses Format zum Packen der gesamten Programmumgebung gewählt.
+Mithilfe des Programmes \textit{7zip} kann unter \textit{Linux} ein selbstextrahierendes Programm
+erzeugt werden, das eine Fortschrittsanzeige besitzt und sich unter \textit{Windows} ausführen lässt.
 
 \section{Resultat}
-
-\begin{figure}[H] \centering \includegraphics[width=0.8\textwidth]{doc_tool} \caption{Diese Abbildung zeigt die resultierende Benutzeroberfläche}\label{fig:doc_tool} \end{figure}
-Abb.~\ref{fig:doc_tool} Zeigt die Benutzeroberfläche des in diesem Kapitel entwickelten Prototypen. Die Grafische Oberfläche besitzt alle in \ref{sc:aufbauGui}
-gezeiten Merkmale. Es das Programm wurde unter Berücksichtigung der unter \autoref{cha:Anforderungen} definierten Anforderungen erstellt.
+In diesem Abschnitt werden der resultierende Prototyp und dessen Funktionen beleuchtet.
+
+\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}
+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}
+gezeiten Merkmale. Es das Programm wurde unter Berücksichtigung der unter \autoref{cha:Anforderungen} definierten Anforderungen erstellt und besitzt folgende Elemente:
+
+\begin{enumerate}
+\item ein Startmenü nach etablierten Standards von \textit{Windows} und \textit{Linux}
+\item eine Liste in der das zu editierende Kapitel ausgewählt werden kann
+\item Elemente zum bearbeiten und definieren der Autoren
+\item Textfeld zum schreiben des aktuell ausgewählten Kapitels
+\item Anzeige des Aktuell ausgewählten Kapitels
+\item Elemente mit denen die allgemeine Dokumenteinstellgen Dokumentname, Gruppe und Deckblatt konfiguriert werden können
+\item klickbarer Knopf mit dem man zum nächsten Kapitel springen kann
+\item Auswahlboxen mit denen der Bearbeitungsstatus des aktuellen, oder aller Kapitel geändert werden kann
+\item Statusanzeige, die den Fortschritt des Dokumentationsprozesses angibt
+\end{enumerate}
+
+Neue Vorlagedateien erstellen oder bestehende Vorlagedateien laden kann man über die Startmenüeinträge \textit{File > New document} und
+\textit{File > Open document template}. Eine Vorlage lässt sich als Vorlagedatei über den Startmenüeintrag \textit{Edit > Save as template} exportieren.
+Allgemeine Dokumenteinstellungen finden sich unter \textit{Edit > Settings}.
+\newline
+\par
+Elemente zum Editieren einer Vorlage wurden als Rechtsklickmenüs implementiert. Somit scheinen sie in der grafischen Oberfläche
+nicht direkt auf und Stören den Dokumentationsprozess nicht. In Abb.~\ref{fig:doc_tool_num} befinden sich unter folgenden Steuerelementen
+Rechtsklickmenüs zum Bearbeiten einer Vorlage:
+
+\begin{enumerate}
+ \addtocounter{enumi}{1}
+ \item Optionen zum bearbeiten, löschen und hinzufügen von Kapiteln
+ \item Einstellungen zum hinzufügen, löschen und ändern der Deckblattkoordinaten eines Authors \addtocounter{enumi}{2}
+ \item Unter \textit{Group/Department} befindet sich ein Rechtsklickmenü mit dem die Deckblattkoordinaten der Gruppe konfiguriert werden können.
+\end{enumerate}
+
+Die Deckblattkoordinaten werden benötigt, damit das Werkzeug die Benutzereingaben in das Deckblatt eintragen kann.
index 6267b90..bd74b1e 100644 (file)
@@ -9,7 +9,7 @@ diese Konzepte zum Teil umsetzten, und somit bei der Erstellung von Dokumentatio
 \section{Allgemeine Eigenschaften}
 
 Der Begriff Softwaredokumentation ist in der Literatur nicht einheitlich definiert, generell kann man aber Dokumentationstypen daran unterscheiden, für
-welche Zielgruppe sie gedacht sind. Zwei wichtige Typen sind hierbei die Benutzerdokumentation und die Systemdokumentation.
+welche Zielgruppe sie gedacht sind. Zwei wichtige Typen sind die Benutzerdokumentation und die Systemdokumentation.
 
 \subsection{Benutzerdokumentation}
 
@@ -25,15 +25,15 @@ späteren Zeitpunk besser nachvollziehen können und um anderen einen leichteren
 \section{Dokumentationskonzepte}
 
 Aufgrund der Schnelllebigkeit von Programmen und Zeitdruck in der Entwicklung wird oft schlecht bis gar nicht dokumentiert.
-Dies ist vor allem im Bereich der Systemdokumentation sehr ausgeprägtes Problem. Als Beispiel kann man
+Dies ist vor allem im Bereich der Systemdokumentation ein sehr ausgeprägtes Problem. Als Beispiel kann man
 hier, die von vielen Entwicklern vertretene Meinung, dass der Programmcode selbst Dokumentation genug sei anführen.
 Um diesem Problem entgegenzuwirken, gibt es verschiedene Ansätze und Konzepte. Zwei bekannte Konzepte nennen sich
-Literate Programming und Elucidative Programming.
+\textit{Literate Programming} und \textit{Elucidative Programming}.
 
 
 \subsection{Literate Programming}
 \label{ssec:LiterateProgramming}
-Unter Literate Programming versteht man den Versuch, nicht mehr einen Computer anzuweisen was er zu tun hat, sondern Menschen zu erklären was
+Unter \textit{Literate Programming} versteht man den Versuch, nicht mehr einen Computer anzuweisen was er zu tun hat, sondern Menschen zu erklären was
 von einem Computer gefordert wird. Dies geschieht unter anderem durch Wahl passender Variablennamen und der Erklärung von Codesegmenten
 direkt im Quellcode mithilfe von speziellen Quellcodekommentaren. Später kann dann aus dem Programmcode mithilfe dieser Kommentare
 ein Dokument in verschiedenen Ausgabeformaten erzeugt werden. Somit erhält man eine Dokumentation und einen nachvollziehbar lesbaren
@@ -41,10 +41,10 @@ Programmcode \cite{LiterateProgramming}.
 
 \subsection{Elucidative Programming}
 \label{ssec:ElucidativeProgramming}
-Elucidative Programming kann als Variante des Literate Programming verstanden werden und verfolgt die Strategie bestehenden Programmcode in ein
+\textit{Elucidative Programming} kann als Variante des \textit{Literate Programming} verstanden werden und verfolgt die Strategie bestehenden Programmcode in ein
 Dokument einzubinden. Programmcode und Dokumentation sind hier getrennt. Änderungen im Code werden direkt in das Dokument übernommen.
 Dies hat den Vorteil, dass man die Dokumentation nicht an zwei Stellen warten muss und dass das Quellprogramm ohne eingebetteter
-Dokumentation intakt bleibt. Auch hier kann dann eine Dokumentation in verschiedenen Ausgabeformaten generiert werden \cite{ElucidativeProgramming}.
+Dokumentation intakt bleibt. Auch hier kann eine Dokumentation in verschiedenen Ausgabeformaten generiert werden \cite{ElucidativeProgramming}.
 
 \section{Unterstützende Programme}
 
@@ -54,15 +54,111 @@ werden im folgenden Abschnitt genauer erläutert.
 
 \subsection{\latex}
 \label{ssec:Latex}
-\latex ist ein Formatierungsprogramm, das über eine Auszeichnungssprache die Formatierung von in einem gewöhnlichen Editor geschriebenem Text
-ermöglicht. Diese Textformatierung erfolgt hierbei über Steuerbefehle. Somit zwingt es den Anwender sich rein auf den Inhalt zu
+\textit{\latex} ist ein Formatierungsprogramm, das über eine Auszeichnungssprache die Formatierung von in einem gewöhnlichen Editor geschriebenem Text
+ermöglicht. Diese Textformatierung erfolgt über Steuerbefehle. Somit zwingt es den Anwender sich rein auf den Inhalt zu
 konzentrieren und nicht auf die Formatierung selbst \cite[Kapitel 1]{LatexEinfuehrung} \cite[Seite 8]{LatexFriends}.
-\latex eignet sich sehr gut für \emph{Elucidative Programming} \ref{ssec:ElucidativeProgramming}, da Programmcodes einfach mithilfe von bestehenden Makros eingebunden und beschrieben
+\textit{\latex} eignet sich sehr gut für \emph{Elucidative Programming} \ref{ssec:ElucidativeProgramming}, da Programmcodes einfach mithilfe von bestehenden Makros eingebunden und beschrieben
 werden kann.
 
+\subsubsection{Beispiel}
+
+In diesem Beispiel wird gezeigt, wie man Teile einer Quellcodedatei mithilfe von \textit{\latex} in ein Dokument einbindet und eine Dokumentation
+generiert. Zur Veranschaulichung wurde folgender Programmcode herangezogen:
+\lstinputlisting[language=C++,caption={einfaches C++ Beispielprogramm}]{examples/latex/exmpl_add_latex.cpp}
+
+Um die Funktion \textit{add} beschreiben zu können, soll diese in ein Dokument eingefügt werden. Wie dies zu bewerkstelligen ist, kann
+aus folgendem \latex-Dokument entnommen werden:
+
+\lstinputlisting[caption={Einbinden von Quellcode in \textit{\latex}}]{examples/latex/docu.tex}
+Die Funktionalität zum Einbinden von Quellcodedateien wird von dem \latex-Paket \textit{listings} bereitgestellt. Dieses Paket stellt
+den Befehl \textit{lstinputlisting} zur Verfügung, der in diesem Beispiel mit folgenden Konfigurationsparametern verwendet wurde:
+\begin{itemize}
+\item \textbf{numbers:} Gibt an, wo sich die Zeilennummerierung für das eingebundene Dokument befindet.
+\item \textbf{language:} Mithilfe dieses Parameters lässt sich eine Syntaxhervorhebung für verschiedene Programmiersprachen einstellen.
+\item \textbf{firstnumber:} \textit{Firstnumber} konfiguriert, mit welcher Zahl die Zeilennummerierung im generierten Dokument startet.
+\item \textbf{firstline:} Dieser Parameter bestimmt, ab welcher Zeile das Einbinden der Quellcodedatei gestartet wird.
+\item \textbf{lastline:} Gibt an, bis zu welcher Zeile die Quellcodedatei einzubinden ist.
+\end{itemize}
+Eine umfangreiche Dokumentation des \textit{listings} \latex-Paketes findet sich in \cite{listingsDoc}.
+\newline
+\par
+Um aus dem \latex-Quellcode ein PDF-Dokument zu generieren, muss das Kommandozeilenprogramm \textit{pdflatex} mit dem \latex-Dokument
+als Parameter ausgeführt werden. Folgender Befehl führt diese Operation aus:
+
+\begin{lstlisting}
+$ pdflatex docu.tex
+\end{lstlisting}
+
+Das generierte PDF-Dokument mit der eingebundenen \textit{add}-Funktion wird in Abb.~\ref{fig:latexExample} dargestellt.
+
+\begin{tcolorbox}[enhanced,colback=white,colframe=black,coltitle=black,title={\refstepcounter{figure}
+       \textbf{Abbildung \thefigure:} Diese Abbildung zeigt die generierte PDF-Dokumentation.
+       \label{fig:latexExample}},
+       attach boxed title to bottom left,
+       boxed title style={
+       enhanced, colback=white, colframe=white
+      }]
+\subsubsection{Addieren}
+Diese C++ Funktion gibt die Summe zweier Zahlen retour.
+
+    % Befehl zum Einbinden
+    \lstinputlisting[numbers=left,
+                    language=C++,
+                    firstnumber=3,
+                    firstline=3,
+                    lastline=6]{examples/latex/exmpl_add_latex.cpp}
+\end{tcolorbox}
+
 \subsection{Doxygen}
 \label{ssec:Doxygen}
-Doxygen ist ein Programm zum Generieren von Dokumentationen aus einem Programmquellcode.
+\textit{Doxygen} ist ein Programm zum Generieren von Dokumentationen aus einem Programmquellcode.
 Es ist möglich mithilfe von definierten Steuerbefehlen in den Kommentarblöcken Schnittstellen und Klassen zu beschreiben.
 Mithilfe von diesen Kommentaren kann man Dokumentationen in verschiedenen Ausgabeformaten erzeugen \cite{DoxyGen}. Dies bedeutet, dass das
 Konzept von \emph{Literate Programming} \ref{ssec:LiterateProgramming} für Schnittstellen und Klassen umgesetzt wird.
+
+\subsubsection{Beispiel}
+
+Dieses Beispiel zeigt, wie die Doxygen-Steuerbefehle funktionieren und wie man mithilfe von \textit{Doxygen} eine Schnittstellendokumentation
+erstellen kann. Zur veranschaulichung der Funktionsweise wurde folgender Quellcode mit einem Doxygen-Kommentarblock für die Funktion
+\textit{add} erstellt:
+
+\lstinputlisting[language=C++,caption={Beispielprogramm mit Doxygen-Kommentarblock}]{examples/doxygen/exmpl_add_doxy.cpp}
+
+Im Beispielprogramm wurden folgende Steuerbefehle verwendet:
+\begin{itemize}
+\item \textbf{brief:} Mit diesem Befehl ist es möglich, eine allgemeine Funktionsbeschreibung anzugeben.
+\item \textbf{param:} Mithilfe von param kann man die einzelnen Übergabeparameter einer Funktion beschreiben.
+\item \textbf{return:} Der Steuerbefehl return erlaubt das Beschreiben des Rückgabewertes.
+\end{itemize}
+Weitere Steuerbefehle finden sich in \cite{DoxyGen}.
+\newline
+\par
+Damit \textit{Doxygen} die Quellcodedatei verarbeiten kann, wird eine Konfigurationsdatei benötigt. Eine solche Datei wird in der Regel mit
+dem Namen \textit{doxyfile} abgespeichert. Wie eine solche Konfigurationsdatei auszusehen hat, kann aus folgendem Beispiel entnommen
+werden:
+
+\lstinputlisting[caption={Minimale Doxygen Konfigurationsdatei}]{examples/doxygen/doxyfile}
+Diese Datei zeigt nur die grobe Funktionsweise der Konfiguration. Eine umfangreiche Beschreibung aller möglichen Konfigurationsparameter
+findet sich in \cite{DoxyGen}.
+\newline
+\par
+Um eine Dokumentation zu generieren, muss man \textit{Doxygen} mit der entsprechenden Konfigurationsdatei als Parameter von der
+Kommandozeile aus ausführen. Dies geschieht mit folgendem Befehl:
+
+\begin{lstlisting}
+$ doxygen doxyfile
+\end{lstlisting}
+
+Mit \textit{Doxygen} kann man Dokumentationen in verschiedenen Ausgabeformaten erzeugen. Wird in der Konfigurationsdatei kein Ausgabeformat
+angegeben, wird die Dokumentation standardmäßig im \textit{html} und im \latex-Format erstellt.
+Die generierte Schnittstellendokumentation der Funktion \textit{add} wird in Abb.~\ref{fig:doxyExample} dargestellt.
+
+\begin{figure}[H]%
+    \centering
+    \subfloat[Ausgabe in \textit{html}]{{\includegraphics[width=0.4\textwidth]{doxy_html} }}%
+    \qquad
+    \subfloat[Ausgabe in \textit{\latex}]{{\includegraphics[width=0.4\textwidth]{doxy_latex} }}%
+    \caption{Diese Abbildung zeigt die generierten Dokumentationen im \textit{html} und \textit{\latex} Format.}%
+    \label{fig:doxyExample}%
+\end{figure}
+
index dabc450..cca3a41 100644 (file)
@@ -6,9 +6,9 @@ In diesem Kapitel wird zunächst der Testablauf des Prototypentests beschrieben,
 \label{sec:Ausgangssituation}
 
 Die Abgaben von Softwareübungen im Studiengang Hardware-Software-Design bestehen im generellen aus einem Deckblatt, einer theoretischen
-Ausarbeitung und den ausgearbeiteten Quelltextdateien. Übungsabgaben in Software Entwicklung 1 und Software Entwicklung 2 beinhalten außerdem
+Ausarbeitung und den ausgearbeiteten Quelltextdateien. Übungsabgaben in Software Entwicklung 1 und Software Entwicklung 2 beinhalten zusätzlich
 eine Lösungsidee. Im dritten Semester erweitert sich die Abgabe in Software Design Patterns 3 um ein Klassendiagramm und einer Beschreibung der
-einzelnen Klassen. In Mikroprozessortechnik 3, Parallele Software System 4 und Kommunikationstechnik 4 bestehen die Übungsabgaben aus Ausarbeitung,
+einzelnen Klassen. In Mikroprozessortechnik 3, Parallele Software Systeme 4 und Kommunikationstechnik 4 bestehen die Übungsabgaben aus Ausarbeitung,
 Quelltextdateien und Funktionsbeschreibungen.
 \newline
 \par
@@ -17,19 +17,19 @@ jeweils eine Dokumentationsvorlage erstellt. Diese Vorlagen dienen dazu um das G
 
 \section{Testsysteme}
 Die Tests wurden auf vier verschiedenen Testsystemen mit unterschiedlichen Betriebssystemen durchgeführt.
-Um eine breite Masse an Systemen abzudecken, wurde jeweils zwei verschiedene Windows Versionen mit unterschiedlicher Prozessorarchitektur
-Unterstützung und zwei verschiedene Linux Systeme ebenfalls mit unterschiedlicher Prozessorarchitektur Unterstützung getestet.
+Um eine breite Masse an Systemen abzudecken, wurde jeweils zwei verschiedene Windows-Versionen mit unterschiedlicher Prozessorarchitektur
+ zwei verschiedene Linux-Systeme ebenfalls mit unterschiedlicher Prozessorarchitektur getestet.
 \newline
 \par
-Für die Tests auf Linux Systemen wurden zwei verschiedene Distributionen gewählt, die jeweils stellvertretend für eine Gruppe von Linux
-Distributionen gesehen werden können. Diese zwei Gruppen unterscheiden sich vor allem in der Paketverwaltung. Gruppe eins verwendet das \emph{.deb}
-Format für die Programmpakete und das Programm \emph{apt} als Paketmanager. Als Repräsentant für alle \emph{.deb} basierenden Linux Systeme
+Für die Tests auf Linux-Systemen wurden zwei verschiedene Distributionen gewählt, die jeweils stellvertretend für eine Gruppe von
+Linuxdistributionen gesehen werden können. Diese zwei Gruppen unterscheiden sich vor allem in der Paketverwaltung. Gruppe eins verwendet das \emph{.deb}
+Format für die Programmpakete und das Programm \emph{apt} als Paketmanager. Als Repräsentant für alle \emph{.deb} basierenden Linux-Systeme
 wurde \emph{Debian 9} (64 Bit) gewählt. Die zweite Gruppe verwendet das \emph{.rpm} Format und verwendet einen Paketmanager mit dem
-Namen \emph{yum}. Als Testdistribution für alle Linux Derivate mit dem \emph{.rpm} Format wurde \emph{Fedora 27} (32 Bit) gewählt.
+Namen \emph{yum}. Als Testdistribution für alle Linux-Derivate mit dem \emph{.rpm} Format wurde \emph{Fedora 27} (32 Bit) gewählt.
 Mehr über die Pakettypen \emph{.rpm} und \emph{.deb} findet sich in \cite{DebRpm}.
 \newline
 \par
-Für die Tests auf Windows Systemen wurde zum einen, \emph{Windows 7} (32 Bit) gewählt um eine Abwärtskompatibilität zumindest bis zu dieser
+Für die Tests auf Windows-Systemen wurde zum einen, \emph{Windows 7} (32 Bit) gewählt um eine Abwärtskompatibilität zumindest bis zu dieser
 Version zu testen, und zum anderen \emph{Windows 10} (64 Bit) gewählt, da es die derzeit aktuellste Version ist.
 
 \section{Testablauf}
@@ -39,10 +39,10 @@ Im ersten Schritt wurde der Prototyp mit der erzeugten Installationsroutine auf
 \newline
 \par
 Danach wurde versucht eine neue Vorlage, die alle drei Kapiteltypen beinhaltet
-zu erstellen. Die Ergebnisse dieses Tests befinden sich Tabelle \ref{tab:Ergebnisse} unter \textit{Vorlage erzeugen}.
+zu erstellen. Die Ergebnisse dieses Tests befinden sich in Tabelle \ref{tab:Ergebnisse} unter \textit{Vorlage erzeugen}.
 \newline
 \par
-Diese Vorlage wurde nun neu geladen, jede Einstellung einmal abgeändert und erneut exportiert. In der Ergebnistabelle \ref{tab:Ergebnisse}
+Diese Vorlage wurde neu geladen, jede Einstellung einmal abgeändert und erneut exportiert. In der Ergebnistabelle \ref{tab:Ergebnisse}
 findet man das Resultat unter \textit{Vorlage bearbeiten}.
 \newline
 \par
@@ -70,9 +70,18 @@ Fedora 27 (32 Bit)  & \ding{51}             & \ding{51}                      & \
 In der Tabelle \ref{tab:Ergebnisse} werden die Ergebnisse der Testabläufe auf den 4 Testsystemen gegenübergestellt. Ein \ding{51} bedeutet der
 Test war erfolgreich und ein \ding{55} gibt an, dass der Test fehlgeschlagen ist. Wie man erkennen kann, wurden alle Tests positiv abgeschlossen
 und der Prototyp funktioniert auf allen Testumgebungen standardmäßig.
+\newline
+\par
+
+\begin{figure}[H]%
+    \centering
+    \subfloat[grafische Oberfläche unter \textit{Windows}]{{\includegraphics[width=0.46\textwidth]{doc_tool_win} }}%
+    \qquad
+    \subfloat[grafische Oberfläche unter \textit{Linux}]{{\includegraphics[width=0.46\textwidth]{doc_tool} }}%
+    \caption{Diese Abbildungen zeigen die grafische Oberfläche unter \textit{Windows} und \textit{Linux}.}%
+    \label{fig:doc_tool_win_lin}%
+\end{figure}
 
-\begin{figure} \centering \includegraphics[width=\textwidth]{doc_tool_win} \caption{Diese Abbildung zeigt die Grafische Oberfläche unter Windows}\label{fig:doc_tool_win} \end{figure}
-\begin{figure} \centering \includegraphics[width=\textwidth]{doc_tool} \caption{Diese Abbildung zeigt die Grafische Oberfläche unter Linux}\label{fig:doc_tool_lin} \end{figure}
 Der einzige Unterschied, der zwischen den Testsystemen festgestellt werden
-konnte ist, dass die Texte der grafischen Benutzeroberfläche auf den verschiedenen Testsystemen leicht unterschiedlich angezeigt werden. Wenn man Abb.~\ref{fig:doc_tool_lin} mit Abb.~\ref{fig:doc_tool_win} vergleicht,
-kann man erkennen, dass die Schrift auf dem Linux Testsystem leicht verzerrt dargestellt wird.
+konnte ist, dass die Texte der grafischen Benutzeroberfläche auf den verschiedenen Testsystemen leicht unterschiedlich angezeigt werden. Wenn man die Bilder von
+Abb.~\ref{fig:doc_tool_win_lin} vergleicht, kann man erkennen, dass die Schrift auf dem Linux-Testsystem leicht verzerrt dargestellt wird.
index 91305a4..4266f15 100644 (file)
@@ -1,19 +1,35 @@
 \chapter{Zusammenfassung und Ausblick}
 \label{cha:Zusammenfassung}
 
-\section{Zusmmenfassung}
-
-Vor dem dem Ausblick werden im folgenden Abschnitt die Erkenntnisse aus den letzten Kapiteln zusammengefasst.
+Im Rahmen dieser Arbeit wurde ein plattformunabhängiges Werkzeug zum Erstellen von Dokumentationen für Software-Projekte sowohl konzipiert als
+auch implementiert. Ausgehend von den Anforderungen der Software Übungsabgaben im Übungsbetrieb des Studiengangs Hardware-Software-Design an
+der Fachhochschule Hagenberg wurden verschiedene Dokumentationskonzepte betrachtet und auf Basis der gewonnenen Erkenntnisse die Anforderungen
+an das Werkzeug abgeleitet. Unter Berücksichtigung der Anforderungen wurde dann durch Betrachten verschiedener Umsetzungsmöglichkeiten ein Konzept
+für eine individuelle plattformunabhängige Softwarelösung erarbeitet. Während der Prototyp-Entwicklung ist ein Werkzeug entstanden, dass ein
+einfaches Dokumentieren von Software-Projekten ermöglicht.
 \newline
 \par
-In \autoref{cha:Softwaredokumentationen} wurde durch Analysieren bestehender Konzepte die Grundlage für den Entwurf eines plattformunabhängigen Dokumentationswerkzeuges
-geschaffen. Im Folgenden \autoref{cha:Anforderungen} wurden die Anforderungen an solch ein Werkzeug, auf Basis der in \autoref{cha:Softwaredokumentationen}
-gewonnenen Erkenntnisse und der im Übungsbetrieb an der Fachhochschule Hagenberg gesammelten Erfahrungen, zusammengetragen und definiert. Ein detailliertes
-Umsetzungskonzept wurde in \autoref{cha:Konzept} ausgearbeitet und in \autoref{cha:Projektumsetzung} im Zuge eines Prototypen umgesetzt.
-Dabei konnten einige Erkenntnisse gewonnen werden, wie zum Beispiel dass es unter Linux nicht möglich alle Abhängigkeiten komplett statisch zu linken.
-In \autoref{cha:Tests} wurde der Prototyp getestet und es konnte eine korrekte Funktionsweise nachgewiesen werden.
+Während der folgende Abschnitt dieses Kapitels die Ergebnisse dieser Bachelorarbeit zusammenfasst, folgt im letzten Abschnitt ein Ausblick auf
+mögliche Verbesserungen und Erweiterungen dieses Werkzeugs.
+
+\section{Zusammenfassung}
+
+In \autoref{cha:Softwaredokumentationen} wurde durch Analysieren bestehender Konzepte die Grundlage für den Entwurf eines plattformunabhängigen
+Dokumentationswerkzeuges geschaffen. Es konnte erkannt werden, dass bereits mächtige Kommandozeilenprogramme existieren, die den
+Dokumentationsprozess deutlich vereinfachen können. Leider sind diese sehr umständlich in der Handhabung, somit wurden im
+Folgenden \autoref{cha:Anforderungen} die Anforderungen an das Dokumentationswerkzeug, auf Basis der in \autoref{cha:Softwaredokumentationen}
+gewonnenen Erkenntnisse und der im Übungsbetrieb an der Fachhochschule Hagenberg gesammelten Erfahrungen, zusammengetragen und definiert.
+Ein detailliertes Umsetzungskonzept konnte in \autoref{cha:Konzept} durch vergleichen von verschiedenen Programmiersprachen, Grafikbiliotheken
+und Umsetzungsmöglichkeiten ausgearbeitet werden. In \autoref{cha:Projektumsetzung} wurde dieses Konzept im Zuge eines Prototypen umgesetzt. Es
+wurde ein plattformunabhängiges Werkzeug entwickelt und eine Programmumgebung geschaffen mit der dieses Werkzeug interagieren kann, um
+Software-Dokumentationen zu erzeugen. Bei der Umsetzung konnte herausgefunden werden, dass es unter \textit{Linux} nicht möglich ist, alle
+Abhängigkeiten komplett statisch zu linken. Als Alternative wurden jene Abhängigkeiten, die sich nicht statisch linken lassen mit in die
+Programmumgebung gepackt. In \autoref{cha:Tests} wurde der Prototyp auf den Betriebsystemen \textit{Fedora 27 (32 Bit)},
+\textit{Debian 9 (64 Bit)}, \textit{Windows 7 (32 Bit)} und \textit{Windows 10 (64 Bit)} getestet und die korrekte Funktionsweise nachgewiesen.
 
 \section{Ausblick}
 Im Laufe dieser Arbeit wurde der \textit{C++18} Standard veröffentlicht. Dieser bietet Funktionen die Operationen auf das Dateisystem und
 ein Ausführen von externen Programmen ermöglichen. Um die Softwarequalität zu erhöhen, würde es Sinn machen, den Prototypen an die
-neuen Gegebenheiten anzupassen. Eine weitere sinnvolle Erweiterungen wären eine \latex Syntaxhervorhebung im Prototypen Texteditorfenster.
+neuen Gegebenheiten anzupassen. Weitere sinnvolle Erweiterungen wären eine \textit{\latex} Syntaxhervorhebung im Prototypen Texteditorfenster.
+Da sich die Programme die in der erstellten Programmumgebung befinden laufend weiterentwickeln ist es wichtig die Programmumgebung zu warten
+und zu erweitern, um immer auf dem aktuellen Stand der Technik zu bleiben.
diff --git a/doc/thesis/examples/doxygen/doxyfile b/doc/thesis/examples/doxygen/doxyfile
new file mode 100644 (file)
index 0000000..49e280b
--- /dev/null
@@ -0,0 +1,14 @@
+# Projektname
+PROJECT_NAME           = Doxygen Example
+
+# Ausgabeverzeichnis für die generierten Dateien
+OUTPUT_DIRECTORY       = ./generated
+
+# Ausgabesprache
+OUTPUT_LANGUAGE        = German
+
+# Dokumentation für alle Schnittstellen generieren
+EXTRACT_ALL            = YES
+
+# Zu verwendende Quellcodedatei(en)
+INPUT                  = ./exmpl_add_doxy.cpp
\ No newline at end of file
diff --git a/doc/thesis/examples/doxygen/exmpl_add_doxy.cpp b/doc/thesis/examples/doxygen/exmpl_add_doxy.cpp
new file mode 100644 (file)
index 0000000..b366889
--- /dev/null
@@ -0,0 +1,18 @@
+#include <iostream>
+
+/////////////////////////////////////////////////
+/// \brief Diese Funktion addiert zwei Zahlen.
+/// \param a erster Summand
+/// \param b zweiter Summand
+/// \return int, die Summe aus a und b.
+/////////////////////////////////////////////////
+int add(int a, int b)
+{
+    return a + b;
+}
+
+int main()
+{
+    std::cout << add(3, 4) << std::endl;
+    return 0;
+}
\ No newline at end of file
diff --git a/doc/thesis/examples/json.json b/doc/thesis/examples/json.json
new file mode 100644 (file)
index 0000000..2935875
--- /dev/null
@@ -0,0 +1,6 @@
+{
+       "to" : "Daniel",
+       "from" : "Kevin",
+       "heading" : "Erinnerung",
+       "body" : "Vergiss den Schlüssel nicht!"
+}
\ No newline at end of file
diff --git a/doc/thesis/examples/latex/docu.tex b/doc/thesis/examples/latex/docu.tex
new file mode 100644 (file)
index 0000000..8eec04d
--- /dev/null
@@ -0,0 +1,18 @@
+\documentclass[a4paper]{scrreprt}
+
+% Dieses Paket ermöglicht Einbinden von Quellcode Dateien
+\usepackage{listings}
+
+\begin{document}
+
+       \subsubsection{Addieren}
+       Diese C++ Funktion gibt die Summe zweier Zahlen retour.
+
+               % Befehl zum Einbinden
+               \lstinputlisting[numbers=left,
+                                               language=C++,
+                                               firstnumber=3,
+                                               firstline=3,
+                                               lastline=6]{exmpl_add_latex.cpp}
+
+\end{document}
diff --git a/doc/thesis/examples/latex/exmpl_add_latex.cpp b/doc/thesis/examples/latex/exmpl_add_latex.cpp
new file mode 100644 (file)
index 0000000..320e0c3
--- /dev/null
@@ -0,0 +1,12 @@
+#include <iostream>
+
+int add(int a, int b)
+{
+    return a + b;
+}
+
+int main()
+{
+    std::cout << add(3, 4) << std::endl;
+    return 0;
+}
\ No newline at end of file
diff --git a/doc/thesis/examples/xml.xml b/doc/thesis/examples/xml.xml
new file mode 100644 (file)
index 0000000..aad8caf
--- /dev/null
@@ -0,0 +1,6 @@
+<note>
+       <to>Daniel</to>
+       <from>Kevin</from>
+       <heading>Erinnerung</heading>
+       <body>Vergiss den Schlüssel nicht!</body>
+</note>
\ No newline at end of file
index 27caa04..1ffc34a 100644 (file)
@@ -4,14 +4,14 @@
 \begin{english} %switch to English language rules
 Due to lack of time and apparent unproductivity, little attention is paid to documentation in software projects.
 Existing utility programs are often awkward to use, so software is often only poorly documented, or not documented at all.
-As an example, one can call a large part of the open source and free software.
+As an example, one can name a large part of the open source and free software.
 \newline
 \par
-This work should give an overview of various documentation concepts. On base of these concepts an easy to use prototype for Linux and Windows is imlemented. This prototype should help to
-simplify the creation of software documentations
+This thesis should give an overview of various documentation concepts. On base of these concepts an easy to use prototype for \textit{Linux} and \textit{Windows} is imlemented. This prototype should help to
+simplify the creation of software documentations.
 \newline
 \par
-For this prototype to work, Linux and Windows require a
+For this prototype to work, \textit{Linux} and \textit{Windows} require a
 program environment that contains important command line programs plus their configuration. This thesis describes the creation and construction
 of such an environment. It also explains the implementation of an platform-independent graphical user interface, which is designed to guide the user
 through the documentation process.
index fa959f1..5a3e0a6 100644 (file)
@@ -6,10 +6,10 @@ gar nicht dokumentiert. Als Beispiel hierfür kann man einen Großteil der quell
 \newline
 \par
 Diese Arbeit gibt einen Überblick über verschiedene Dokumentationskonzepte und versucht auf Basis dieser eine einfach zu bedienende grafische
-Benutzeroberfläche für Linux und Windows als Prototyp zu entwickeln, um somit das Schreiben von Dokumentationen zu vereinfachen.
+Benutzeroberfläche für \textit{Linux} und \textit{Windows} als Prototyp zu entwickeln, um somit das Schreiben von Dokumentationen zu vereinfachen.
 \newline
 \par
-Für diesen Prototyp wird jeweils für Linux und Windows eine Programmumgebung
+Für diesen Prototyp wird jeweils für \textit{Linux} und \textit{Windows} eine Programmumgebung
 benötigt, die wichtige Kommandozeilenprogramme und deren Konfiguration beinhaltet. In dieser Arbeit wird die Erstellung und der Aufbau einer
 solchen Umgebung beschrieben. Danach wird die Implementierung einer plattformunabhängigen
 grafischen Benutzeroberfläche erläutert, die den Anwender durch den Dokumentationsprozess führen soll.
diff --git a/doc/thesis/images/doc_tool_num.png b/doc/thesis/images/doc_tool_num.png
new file mode 100644 (file)
index 0000000..4385fce
Binary files /dev/null and b/doc/thesis/images/doc_tool_num.png differ
diff --git a/doc/thesis/images/doxy_html.png b/doc/thesis/images/doxy_html.png
new file mode 100644 (file)
index 0000000..9fe9707
Binary files /dev/null and b/doc/thesis/images/doxy_html.png differ
diff --git a/doc/thesis/images/doxy_latex.png b/doc/thesis/images/doxy_latex.png
new file mode 100644 (file)
index 0000000..ee17b69
Binary files /dev/null and b/doc/thesis/images/doxy_latex.png differ
index b765630..0dc4f41 100644 (file)
Binary files a/doc/thesis/images/fluid.png and b/doc/thesis/images/fluid.png differ
diff --git a/doc/thesis/images/full.png b/doc/thesis/images/full.png
new file mode 100644 (file)
index 0000000..9e93c87
Binary files /dev/null and b/doc/thesis/images/full.png differ
diff --git a/doc/thesis/images/mvc_uml.png b/doc/thesis/images/mvc_uml.png
new file mode 100644 (file)
index 0000000..53e1f91
Binary files /dev/null and b/doc/thesis/images/mvc_uml.png differ
index da6b7df..ac69056 100644 (file)
Binary files a/doc/thesis/images/observer.png and b/doc/thesis/images/observer.png differ
index d58b3f1..d48d3c4 100644 (file)
Binary files a/doc/thesis/images/simple_factory.png and b/doc/thesis/images/simple_factory.png differ
index 30cc396..648ee58 100644 (file)
Binary files a/doc/thesis/images/use_case_doc_tool.png and b/doc/thesis/images/use_case_doc_tool.png differ
index a3c93ab..b9d644d 100644 (file)
Binary files a/doc/thesis/images/use_case_template_generator.png and b/doc/thesis/images/use_case_template_generator.png differ
index 0813e12..7cc3b96 100644 (file)
@@ -14,7 +14,9 @@
 %%%----------------------------------------------------------
 \usepackage{makecell}
 \usepackage{float}
+\usepackage[many]{tcolorbox}
 \usepackage{pifont}
+\usepackage{subfig}
 \RequirePackage[utf8]{inputenc}                % bei der Verw. von lualatex oder xelatex entfernen!
 
 \graphicspath{{images/}}    % Verzeichnis mit Bildern und Grafiken
@@ -37,7 +39,7 @@
 % (A = 1. Bachelorarbeit)
 \semester{Sommersemester 2017}
 \coursetitle{Software Design Patterns}
-\advisor{FH-Prof. DI (FH) Franz Leopold Wiesinger }
+\advisor{FH-Prof. Dipl.-Ing (FH) Franz Wiesinger}
 
 %%% Restriktive Lizenformel anstatt CC (nur für Typ master) -
 %\strictlicense
@@ -52,7 +54,8 @@
 
 \maketitle
 \tableofcontents
-
+\listoffigures
+\setlength{\parindent}{0pt}
 %\include{front/vorwort} % Optional. Ggf. weglassen
 \include{front/kurzfassung}
 \include{front/abstract}
@@ -60,7 +63,6 @@
 %%%----------------------------------------------------------
 \mainmatter          % Hauptteil (ab hier arab. Seitenzahlen)
 %%%----------------------------------------------------------
-
 \include{chapters/einleitung}
 \include{chapters/softwaredokumentationen}
 \include{chapters/anforderungen}
@@ -77,7 +79,7 @@
 %\include{back/anhang_a}       % Technische Ergänzungen
 \include{back/anhang_b}        % Inhalt der CD-ROM/DVD
 %\include{back/anhang_c}       % Chronologische Liste der Änderungen
-\include{back/anhang_d}        % Quelltext dieses Dokuments
+%\include{back/anhang_d}       % Quelltext dieses Dokuments
 
 %%%----------------------------------------------------------
 \MakeBibliography                        % Quellenverzeichnis
index 323dc91..f66f1c8 100644 (file)
@@ -386,6 +386,16 @@ CD/DVD Die beiliegende DVD-ROM bietet das vollständige Buch als HTML-Fassung, a
        hyphenation={german}
 }
 
+@manual{listingsDoc,
+       author={Jobst Hoffmann},
+       title={The Listings Package},
+       year={2005},
+       month={6},
+       version={1.6},
+       url={http://texdoc.net/texmf-dist/doc/latex/listings/listings.pdf},
+       hyphenation={english}
+}
+
 @techreport{Drake1948,
        author={Drake, Huber M. and McLaughlin, Milton D. and Goodman, Harold R.},
        title={Results obtained during accelerated transonic tests of the {Bell}
diff --git a/doc/thesis/uml/author.png b/doc/thesis/uml/author.png
new file mode 100644 (file)
index 0000000..e69de29
diff --git a/doc/thesis/uml/full.dot b/doc/thesis/uml/full.dot
new file mode 100644 (file)
index 0000000..a599903
--- /dev/null
@@ -0,0 +1,30 @@
+digraph doxygraph
+{
+graph [ rankdir="RL" , splines="ortho"]
+"class_model"
+"class_fshelper" [ label="FSHelper\n|" shape="record" pos="9,-1!"]
+"class_author" [ label="Author\n|" shape="record" pos="9,-5!"]
+"class_chapterfactory" [ label="ChapterFactory\n|" shape="record" pos="8,-5!"]
+"class_model" [ label="Model\n|+actionButtonPressed ( ) : void\l+buttonState ( ) : void" shape="record" pos="9,-3!"]
+"class_modelif" [ label="ModelIF\n«abstract»\n|+buttonState ( ) : void \{pure-virtual\}" shape="record" pos="5,-5!"]
+"class_controller" [ label="Controller\n|+actionButtonPressed ( )" shape="record" pos="5,-3!"]
+"class_controllerif" [ label="ControllerIF\n«abstract»\n|+actionButtonPressed ( ) : void \{pure-virtual\}" shape="record" pos="5,-1!"]
+"class_subject"
+"class_observer" [ label="SubjectObserver\n«abstract»\n|+subscribeSubject ( s : SubjectToObserve * ) : void\l+unsubscribeSubject ( s : SubjectToObserve * ) : void\l+updateObserver ( s : SubjectToObserve * ) : void\l+updatedBySubject ( s : SubjectToObserve * ) : void \{pure-virtual\}\l+~SubjectObserver (  ) \{virtual\}\l#SubjectObserver (  )\l|#mSubjects : std::list\< SubjectToObserve * \>\l" shape="record" pos="0,0!"]
+"class_observer" -> "class_subject" [ arrowtail="odiamond" dir="back" ]
+"class_subject" [ label="SubjectToObserve\n|+notifyObservers (  ) : void \{virtual\}\l+subscribeObserver ( o : SubjectObserver * ) : void \{virtual\}\l+unsubscribeObserver ( o : SunjectObserver * ) : void \{virtual\}\l#SubjectToObserve (  )\l|-mObservers : std::list\< SubjectObserver * \>\l" shape="record" pos="6,0!" ]
+"class_subject" -> "class_observer" [ arrowtail="odiamond" dir="back" ]
+"class_model" -> "class_subject" [ arrowhead="empty" style="bold" ]
+"class_viewfluid" [ label="ViewFluid\n|#ViewFluid (  )\l|#button : Fl_Button *" shape="record" pos="0,-5!"]
+"class_view" [ label="View\n|+updatedBySubject ( s : SubjectToObserve * ) : void \l-button_callback( btn : Fl_Button *, view : void * ) : void \{static\}" shape="record" pos="0,-3!"]
+"class_view" -> "class_viewfluid" [ arrowhead="empty" style="bold" ]
+"class_view" -> "class_observer" [ arrowhead="empty" style="bold,dashed" ]
+"class_view" -> "class_controllerif"  [ arrowtail="odiamond" dir="back" ]
+"class_controller" -> "class_model" [ arrowtail="odiamond" dir="back" ]
+"class_view" -> "class_modelif" [ arrowtail="odiamond" dir="back" ]
+"class_model" -> "class_modelif"  [ arrowhead="empty" style="bold,dashed" ]
+"class_controller" -> "class_controllerif"  [ arrowhead="empty" style="bold,dashed" ]
+"class_model" -> "class_fshelper" [ arrowtail="odiamond" dir="back" ]
+"class_model" -> "class_author" [ arrowtail="odiamond" dir="back" ]
+"class_model" -> "class_chapterfactory" [ arrowtail="odiamond" dir="back" ]
+}
diff --git a/doc/thesis/uml/full.png b/doc/thesis/uml/full.png
new file mode 100644 (file)
index 0000000..9e93c87
Binary files /dev/null and b/doc/thesis/uml/full.png differ
diff --git a/doc/thesis/uml/mvc.dot b/doc/thesis/uml/mvc.dot
new file mode 100644 (file)
index 0000000..272c24d
--- /dev/null
@@ -0,0 +1,20 @@
+digraph doxygraph
+{
+graph [ rankdir="RL" , splines="ortho"]
+"class_model"
+"class_model" [ label="Model\n|+actionButtonPressed ( ) : void" shape="record" pos="9,-3!"]
+"class_controller" [ label="Controller\n|+actionButtonPressed ( ) : void" shape="record" pos="5,-3!"]
+"class_subject"
+"class_observer" [ label="SubjectObserver\n«abstract»\n|+subscribeSubject ( s : SubjectToObserve * ) : void\l+unsubscribeSubject ( s : SubjectToObserve * ) : void\l+updateObserver ( s : SubjectToObserve * ) : void\l+updatedBySubject ( s : SubjectToObserve * ) : void \{pure-virtual\}\l+~SubjectObserver (  ) \{virtual\}\l#SubjectObserver (  )\l|#mSubjects : std::list\< SubjectToObserve * \>\l" shape="record" pos="0,0!"]
+"class_observer" -> "class_subject" [ arrowtail="odiamond" dir="back" ]
+"class_subject" [ label="SubjectToObserve\n|+notifyObservers (  ) : void \{virtual\}\l+subscribeObserver ( o : SubjectObserver * ) : void \{virtual\}\l+unsubscribeObserver ( o : SunjectObserver * ) : void \{virtual\}\l#SubjectToObserve (  )\l|-mObservers : std::list\< SubjectObserver * \>\l" shape="record" pos="6,0!" ]
+"class_subject" -> "class_observer" [ arrowtail="odiamond" dir="back" ]
+"class_model" -> "class_subject" [ arrowhead="empty" style="bold" ]
+"class_viewfluid" [ label="ViewFluid\n|#ViewFluid (  )\l|#button : Fl_Button *" shape="record" pos="0,-6!"]
+"class_view" [ label="View\n|+updatedBySubject ( s : SubjectToObserve * ) : void \l-button_callback( btn : Fl_Button *, view : void * ) : void \{static\}" shape="record" pos="0,-3!"]
+"class_view" -> "class_viewfluid" [ arrowhead="empty" style="bold" ]
+"class_view" -> "class_observer" [ arrowhead="empty" style="bold,dashed" ]
+"class_view" -> "class_controller"  [ arrowtail="odiamond" dir="back" ]
+"class_controller" -> "class_model" [ arrowtail="odiamond" dir="back" ]
+"class_view" -> "class_model" [ arrowtail="odiamond" dir="back" ]
+}
diff --git a/doc/thesis/uml/mvc.png b/doc/thesis/uml/mvc.png
new file mode 100644 (file)
index 0000000..53e1f91
Binary files /dev/null and b/doc/thesis/uml/mvc.png differ
diff --git a/doc/thesis/uml/mvc_uml.png b/doc/thesis/uml/mvc_uml.png
new file mode 100644 (file)
index 0000000..53e1f91
Binary files /dev/null and b/doc/thesis/uml/mvc_uml.png differ
index ff8bf11..0b14de8 100644 (file)
@@ -2,13 +2,13 @@ digraph doxygraph
 {
 graph [ rankdir="RL" , splines="ortho"]
 "class_model"
-"class_model" [ label="Model\n|" shape="record"]
+"class_model" [ label="Model\n|" shape="record" pos="6,-3!"]
 "class_subject"
-"class_observer" [ label="Observer\n«abstract»\n|+subscribeSubject ( s : Subject * ) : void\l+unsubscribeSubject ( s : Subject * ) : void\l+updateObserver ( s : Subject * ) : void\l+updatedBySubject ( s : Subject * ) : void \{pure-virtual\}\l+~Observer (  ) \{virtual\}\l#Observer (  )\l|#mSubjects : std::list\< Subject * \>\l" shape="record" ]
+"class_observer" [ label="SubjectObserver\n«abstract»\n|+subscribeSubject ( s : SubjectToObserve * ) : void\l+unsubscribeSubject ( s : SubjectToObserve * ) : void\l+updateObserver ( s : SubjectToObserve * ) : void\l+updatedBySubject ( s : SubjectToObserve * ) : void \{pure-virtual\}\l+~SubjectObserver (  ) \{virtual\}\l#SubjectObserver (  )\l|#mSubjects : std::list\< SubjectToObserve * \>\l" shape="record" pos="0,0!"]
 "class_observer" -> "class_subject" [ arrowtail="odiamond" dir="back" ]
-"class_subject" [ label="Subject\n|+notifyObservers (  ) : void \{virtual\}\l+subscribeObserver ( o : Observer * ) : void \{virtual\}\l+unsubscribeObserver ( o : Observer * ) : void \{virtual\}\l#Subject (  )\l|-mObservers : std::list\< Observer * \>\l" shape="record" ]
+"class_subject" [ label="SubjectToObserve\n|+notifyObservers (  ) : void \{virtual\}\l+subscribeObserver ( o : SubjectObserver * ) : void \{virtual\}\l+unsubscribeObserver ( o : SunjectObserver * ) : void \{virtual\}\l#SubjectToObserve (  )\l|-mObservers : std::list\< SubjectObserver * \>\l" shape="record" pos="6,0!" ]
 "class_subject" -> "class_observer" [ arrowtail="odiamond" dir="back" ]
 "class_model" -> "class_subject" [ arrowhead="empty" style="bold" ]
-"class_view" [ label="View\n|+updatedBySubject ( s : Subject * ) : void" shape="record"]
+"class_view" [ label="View\n|+updatedBySubject ( s : SubjectToObserve * ) : void" shape="record" pos="0,-3!"]
 "class_view" -> "class_observer" [ arrowhead="empty" style="bold,dashed" ]
 }
diff --git a/doc/thesis/uml/observer.png b/doc/thesis/uml/observer.png
new file mode 100644 (file)
index 0000000..ac69056
Binary files /dev/null and b/doc/thesis/uml/observer.png differ
index b31c48f..69aff21 100644 (file)
@@ -9,7 +9,7 @@ graph [ rankdir="RL" , splines="ortho"]
 "class_source_chapter" -> "class_chapter_i_f" [ arrowhead="empty" style="bold,dashed" ]
 "class_text_chapter" [ label="TextChapter\n|/+GetType (  ) : std::string \{virtual\}\l+TextChapter ( type : const std::string & )\l/+WriteFile ( model : ModelIF * ) : void \{virtual\}\l+~TextChapter (  ) \{virtual\}\l|-mType : std::string\l" shape="record" ]
 "class_text_chapter" -> "class_chapter_i_f" [ arrowhead="empty" style="bold,dashed" ]
-"class_chapter_factory" ->"class_text_chapter" [ arrowtail="odiamond" dir="back" ]
-"class_chapter_factory" ->"class_source_chapter"[ arrowtail="odiamond" dir="back" ]
-"class_chapter_factory" ->"class_doxygen_chapter"[ arrowtail="odiamond" dir="back" ]
+"class_chapter_factory" ->"class_text_chapter" [ arrowhead="ovee" style="dashed" label="«creates»" ]
+"class_chapter_factory" ->"class_source_chapter"[ arrowhead="ovee" style="dashed" label="«creates»"  ]
+"class_chapter_factory" ->"class_doxygen_chapter"[arrowhead="ovee" style="dashed" label="«creates»"  ]
 }
diff --git a/doc/thesis/uml/simple_factory.png b/doc/thesis/uml/simple_factory.png
new file mode 100644 (file)
index 0000000..d48d3c4
Binary files /dev/null and b/doc/thesis/uml/simple_factory.png differ
diff --git a/doc/thesis/uml/use_case_doc_tool.png b/doc/thesis/uml/use_case_doc_tool.png
new file mode 100644 (file)
index 0000000..30cc396
Binary files /dev/null and b/doc/thesis/uml/use_case_doc_tool.png differ
diff --git a/doc/thesis/uml/use_case_template_generator.png b/doc/thesis/uml/use_case_template_generator.png
new file mode 100644 (file)
index 0000000..a3c93ab
Binary files /dev/null and b/doc/thesis/uml/use_case_template_generator.png differ
diff --git a/doc/thesis/uml/view.dot b/doc/thesis/uml/view.dot
new file mode 100644 (file)
index 0000000..7b5a977
--- /dev/null
@@ -0,0 +1,8 @@
+digraph doxygraph
+{
+graph [ rankdir="RL" , splines="ortho"]
+"class_view" [ label="View\n|+View ( contr : ControllerIF::SPtr, model : ModelIF::SPtr )\l+loadAuthorContent (  ) : void\l+loadAuthorList (  ) : void\l+loadChapterContent (  ) : void\l+loadChapterList (  ) : void\l+loadGeneralGUIElements (  ) : void\l+loadSettings (  ) : void\l+saveBuffer (  ) : void\l+show (  ) : void\l/+updatedBySubject ( s : Subject * ) : void \{virtual\}\l+~View (  )\l-activate (  ) : void\l-br_chapters_cb ( br : Fl_Browser *, view : void * ) : void \{static\}\l-btn_chapt_save_cb ( cb : Fl_Button *, view : void * ) : void \{static\}\l-btn_down_chpt_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-btn_generate_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-btn_next_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-btn_ok_author_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-btn_ok_depart_cb ( cb : Fl_Button *, view : void * ) : void \{static\}\l-btn_save_author_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-btn_save_settings_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-btn_up_chpt_cb ( btn : Fl_Button *, view : void * ) : void \{static\}\l-cb_author_cb ( cb : Fl_Choice *, view : void * ) : void \{static\}\l-chb_all_finished_cb ( chb : Fl_Check_Button *, view : void * ) : void \{static\}\l-chb_finished_cb ( chb : Fl_Check_Button *, view : void * ) : void \{static\}\l-menu_author_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_chapter_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_department_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_editor_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_gen_templ_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_new_templ_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_open_template_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_out_dir_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-menu_settings_cb ( menu : Fl_Menu_ *, view : void * ) : void \{static\}\l-ot_cov_sheet_cb ( out : Fl_Output *, view : void * ) : void \{static\}\l-ot_src_dir_cb ( out : Fl_Output *, view : void * ) : void \{static\}\l-ti_department_cb ( in : Fl_Input *, view : void * ) : void \{static\}\l-ti_doc_name_cb ( in : Fl_Input *, view : void * ) : void \{static\}\l-win_close_cb ( win : Fl_Window *,  : void * ) : void \{static\}\l|-mController : ControllerIF::SPtr\l-mEditorChapterLabel : char *\l-mFSHelp : FSHelper\l-mLogBuf : Fl_Text_Buffer *\l-mModel : ModelIF::SPtr\l-mSelectSourceLabel : char *\l-mTextBuf : Fl_Text_Buffer *\l" shape="record" ]
+"class_view_fluid"
+"class_view" -> "class_view_fluid" [ arrowhead="empty" style="bold" ]
+"class_view_fluid" [ label="ViewFluid\n|#ViewFluid (  )\l-cb_menu_open_about_dialog (  : Fl_Menu_ *,  : void * ) : void \{static\}\l-cb_menu_open_about_dialog_i (  : Fl_Menu_ *,  : void * ) : void\l|#add_chapt_chaptname : Fl_Input *\l#add_chapt_fname : Fl_Input *\l#border_src : Fl_Box *\l#br_chapters : Fl_Browser *\l#btn_chapt_save : Fl_Button *\l#btn_down_chpt : Fl_Button *\l#btn_generate : Fl_Button *\l#btn_next : Fl_Button *\l#btn_ok_author : Fl_Return_Button *\l#btn_ok_depart : Fl_Return_Button *\l#btn_open_cov_sheet : Fl_Button *\l#btn_open_src_dir : Fl_Button *\l#btn_save_author : Fl_Button *\l#btn_save_settings : Fl_Return_Button *\l#btn_up_chpt : Fl_Button *\l#cb_author : Fl_Choice *\l#chb_add_covpage : Fl_Check_Button *\l#chb_add_titlepage : Fl_Check_Button *\l#chb_add_toc : Fl_Check_Button *\l#chb_all_finished : Fl_Check_Button *\l#chb_chapt_finished : Fl_Check_Button *\l#choice_chapt_type : Fl_Choice *\l#lb_type : Fl_Box *\l#menu_add_author : Fl_Menu_Item * \{static\}\l#menu_add_chapter : Fl_Menu_Item * \{static\}\l#menu_author : Fl_Menu_Button *\l#menu_bar : Fl_Menu_Bar *\l#menu_chapter : Fl_Menu_Button *\l#menu_coor_author : Fl_Menu_Item * \{static\}\l#menu_department : Fl_Menu_Button *\l#menu_department_coord : Fl_Menu_Item * \{static\}\l#menu_edit : Fl_Menu_Item * \{static\}\l#menu_edit_chapter : Fl_Menu_Item * \{static\}\l#menu_editor : Fl_Menu_Button *\l#menu_exit : Fl_Menu_Item * \{static\}\l#menu_file : Fl_Menu_Item * \{static\}\l#menu_gen_templ : Fl_Menu_Item * \{static\}\l#menu_help : Fl_Menu_Item * \{static\}\l#menu_menu_author : Fl_Menu_Item \{static\}\l#menu_menu_bar : Fl_Menu_Item \{static\}\l#menu_menu_chapter : Fl_Menu_Item \{static\}\l#menu_menu_department : Fl_Menu_Item \{static\}\l#menu_menu_editor : Fl_Menu_Item \{static\}\l#menu_new_templ : Fl_Menu_Item * \{static\}\l#menu_open_about_dialog : Fl_Menu_Item * \{static\}\l#menu_open_template : Fl_Menu_Item * \{static\}\l#menu_out_dir : Fl_Menu_Item * \{static\}\l#menu_rclck_bold : Fl_Menu_Item * \{static\}\l#menu_rclck_center : Fl_Menu_Item * \{static\}\l#menu_rclck_equ : Fl_Menu_Item * \{static\}\l#menu_rclck_equation : Fl_Menu_Item * \{static\}\l#menu_rclck_format : Fl_Menu_Item * \{static\}\l#menu_rclck_frac : Fl_Menu_Item * \{static\}\l#menu_rclck_headl : Fl_Menu_Item * \{static\}\l#menu_rclck_headl1 : Fl_Menu_Item * \{static\}\l#menu_rclck_headl2 : Fl_Menu_Item * \{static\}\l#menu_rclck_headl3 : Fl_Menu_Item * \{static\}\l#menu_rclck_insert : Fl_Menu_Item * \{static\}\l#menu_rclck_insert_pic : Fl_Menu_Item * \{static\}\l#menu_rclck_insert_txt : Fl_Menu_Item * \{static\}\l#menu_rclck_intext_equ : Fl_Menu_Item * \{static\}\l#menu_rclck_italic : Fl_Menu_Item * \{static\}\l#menu_rclck_list : Fl_Menu_Item * \{static\}\l#menu_rclck_newline : Fl_Menu_Item * \{static\}\l#menu_rclck_newpage : Fl_Menu_Item * \{static\}\l#menu_rclck_normal_equ : Fl_Menu_Item * \{static\}\l#menu_rclck_pow : Fl_Menu_Item * \{static\}\l#menu_rclck_underline : Fl_Menu_Item * \{static\}\l#menu_rclck_unit : Fl_Menu_Item * \{static\}\l#menu_rm_author : Fl_Menu_Item * \{static\}\l#menu_rm_chapter : Fl_Menu_Item * \{static\}\l#menu_settings : Fl_Menu_Item * \{static\}\l#ot_cov_sheet : Fl_Output *\l#ot_src_dir : Fl_Output *\l#pb_progress : Fl_Progress *\l#spin_hierachy : Fl_Spinner *\l#spin_toc_depth : Fl_Spinner *\l#tb_editor : Fl_Text_Editor *\l#td_log_view : Fl_Text_Display *\l#ti_ID : Fl_Input *\l#ti_department : Fl_Input *\l#ti_doc_name : Fl_Input *\l#ti_est_time : Fl_Input *\l#ti_header_ext : Fl_Input *\l#ti_location : Fl_Input *\l#ti_name : Fl_Input *\l#ti_needed_time : Fl_Input *\l#ti_settings_subject_name : Fl_Input *\l#ti_src_ext : Fl_Input *\l#vi_authname_x : Fl_Value_Input *\l#vi_authname_y : Fl_Value_Input *\l#vi_depart_x : Fl_Value_Input *\l#vi_depart_y : Fl_Value_Input *\l#vi_esttime_x : Fl_Value_Input *\l#vi_esttime_y : Fl_Value_Input *\l#vi_id_x : Fl_Value_Input *\l#vi_id_y : Fl_Value_Input *\l#vi_spenttime_x : Fl_Value_Input *\l#vi_spenttime_y : Fl_Value_Input *\l#win_auth_coord : Fl_Double_Window *\l#win_chapt : Fl_Double_Window *\l#win_depart_coord : Fl_Double_Window *\l#win_doctool : Fl_Double_Window *\l#win_log_view : Fl_Double_Window *\l#win_settings : Fl_Double_Window *\l" shape="record" ]
+}
diff --git a/doc/thesis/uml/view.png b/doc/thesis/uml/view.png
new file mode 100644 (file)
index 0000000..f0924d1
Binary files /dev/null and b/doc/thesis/uml/view.png differ
index ba6499d..17d1cec 100644 (file)
 1524517363 /home/giri/workspace/hsd_doku_tool/src/ViewIF.h
        "Observer.h"
 
-1531917061 source:/home/giri/workspace/hsd_doku_tool/src/Controller.cxx
+1531921866 source:/home/giri/workspace/hsd_doku_tool/src/Controller.cxx
        "Controller.h"
        "View.h"
        "Author.h"
        "Subject.h"
        <algorithm>
 
-1532975315 /home/giri/workspace/hsd_doku_tool/src/ViewFluid.h
+1534680565 /home/giri/workspace/hsd_doku_tool/src/ViewFluid.h
        <FL/Fl.H>
        <FL/Fl_Double_Window.H>
        <FL/Fl_Menu_Bar.H>
 1526164599 source:/home/giri/workspace/hsd_doku_tool/src/ChapterFactory.cpp
        "ChapterFactory.h"
 
-1531919629 source:/home/giri/workspace/hsd_doku_tool/src/ChapterFactory.cxx
+1531921866 source:/home/giri/workspace/hsd_doku_tool/src/ChapterFactory.cxx
        "ChapterFactory.h"