[thesis] Finished first version of thesis.
authorDaniel G <daniel@giritzer.eu>
Tue, 31 Jul 2018 21:20:25 +0000 (23:20 +0200)
committerDaniel G <daniel@giritzer.eu>
Tue, 31 Jul 2018 21:20:25 +0000 (23:20 +0200)
29 files changed:
doc/exposee/exposee.odt
doc/exposee/exposee.pdf
doc/thesis/back/anhang_b.tex
doc/thesis/back/anhang_d.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/front/abstract.tex
doc/thesis/front/kurzfassung.tex
doc/thesis/images/author.png [new file with mode: 0644]
doc/thesis/images/doc_tool.png [new file with mode: 0644]
doc/thesis/images/doc_tool_win.png [new file with mode: 0644]
doc/thesis/images/fluid.png [new file with mode: 0644]
doc/thesis/images/gui_aufbau.png [new file with mode: 0644]
doc/thesis/images/mvc.png [new file with mode: 0644]
doc/thesis/images/observer.png [new file with mode: 0644]
doc/thesis/images/program_overview.png [new file with mode: 0644]
doc/thesis/images/simple_factory.png [new file with mode: 0644]
doc/thesis/main.tex
doc/thesis/references.bib
doc/thesis/thesis.cbp
doc/thesis/uml/author.dot [new file with mode: 0644]
doc/thesis/uml/observer.dot [new file with mode: 0644]
doc/thesis/uml/simple_factory.dot [new file with mode: 0644]
src/doc_tool.depend

index fa03806..5549f61 100644 (file)
Binary files a/doc/exposee/exposee.odt and b/doc/exposee/exposee.odt differ
index 7c827a7..18ba333 100644 (file)
Binary files a/doc/exposee/exposee.pdf and b/doc/exposee/exposee.pdf differ
index 7c26d81..86b61f3 100644 (file)
@@ -1,3 +1,17 @@
 \chapter{Inhalt der CD-ROM/DVD}
 \label{app:cdrom}
 
+Die CD-ROM beinhaltet das komplette Projektarchiv inklusive Versionskontrolle. Als Versionskontrollsystem wurde \textit{git} \cite{Git}
+verwendet.
+\newline
+\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{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{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}
+Das gesamte Projekt ist in einer für die Entwicklungsumgebung \textit{CodeBlocks} \cite{CodeBlocks} erstellten Arbeitsumgebung organisiert. Die Datei dieser
+Arbeitsumgebung trägt den Namen \textit{doc\_tool.workspace} und befindet sich im Wurzelverzeichnis dieser CD-ROM.
index 2c8f981..c5ecbf3 100644 (file)
@@ -1,3 +1,52 @@
-\chapter{\latex-Quellkode}
+\chapter{Prototypen C++ Quellkode}
 \label{app:Quellcode}
 
+
+% show the filename of files included with \lstinputlisting
+\lstset{
+  title={\protect\filename@parse{\lstname}\protect\filename@base\text{.}\protect\filename@ext}
+}
+
+% Add UTF8 Characters unknown to lstset
+\lstset{literate=
+  {á}{{\'a}}1 {é}{{\'e}}1 {í}{{\'i}}1 {ó}{{\'o}}1 {ú}{{\'u}}1
+  {Á}{{\'A}}1 {É}{{\'E}}1 {Í}{{\'I}}1 {Ó}{{\'O}}1 {Ú}{{\'U}}1
+  {à}{{\`a}}1 {è}{{\`e}}1 {ì}{{\`i}}1 {ò}{{\`o}}1 {ù}{{\`u}}1
+  {À}{{\`A}}1 {È}{{\'E}}1 {Ì}{{\`I}}1 {Ò}{{\`O}}1 {Ù}{{\`U}}1
+  {ä}{{\"a}}1 {ë}{{\"e}}1 {ï}{{\"i}}1 {ö}{{\"o}}1 {ü}{{\"u}}1
+  {Ä}{{\"A}}1 {Ë}{{\"E}}1 {Ï}{{\"I}}1 {Ö}{{\"O}}1 {Ü}{{\"U}}1
+  {â}{{\^a}}1 {ê}{{\^e}}1 {î}{{\^i}}1 {ô}{{\^o}}1 {û}{{\^u}}1
+  {Â}{{\^A}}1 {Ê}{{\^E}}1 {Î}{{\^I}}1 {Ô}{{\^O}}1 {Û}{{\^U}}1
+  {œ}{{\oe}}1 {Œ}{{\OE}}1 {æ}{{\ae}}1 {Æ}{{\AE}}1 {ß}{{\ss}}1
+  {ű}{{\H{u}}}1 {Ű}{{\H{U}}}1 {ő}{{\H{o}}}1 {Ő}{{\H{O}}}1
+  {ç}{{\c c}}1 {Ç}{{\c C}}1 {ø}{{\o}}1 {å}{{\r a}}1 {Å}{{\r A}}1
+  {€}{{\EUR}}1 {£}{{\pounds}}1 {↕}{{$\updownarrow$}}1 {↑}{{$\uparrow$}}1
+  {↓}{{$\downarrow$}}1
+}
+
+%source files
+\lstinputlisting[language=C++]{../../src/main.cxx}
+\lstinputlisting[language=C++]{../../src/ViewFluid.h}
+\lstinputlisting[language=C++]{../../src/ViewFluid.cxx}
+\lstinputlisting[language=C++]{../../src/View.h}
+\lstinputlisting[language=C++]{../../src/View.cxx}
+\lstinputlisting[language=C++]{../../src/TextChapter.h}
+\lstinputlisting[language=C++]{../../src/Subject.h}
+\lstinputlisting[language=C++]{../../src/Subject.cxx}
+\lstinputlisting[language=C++]{../../src/SourceChapter.h}
+\lstinputlisting[language=C++]{../../src/Observer.h}
+\lstinputlisting[language=C++]{../../src/Observer.cxx}
+\lstinputlisting[language=C++]{../../src/Object.h}
+\lstinputlisting[language=C++]{../../src/ModelIF.h}
+\lstinputlisting[language=C++]{../../src/Model.h}
+\lstinputlisting[language=C++]{../../src/Model.cxx}
+\lstinputlisting[language=C++]{../../src/FSHelper.h}
+\lstinputlisting[language=C++]{../../src/FSHelper.cxx}
+\lstinputlisting[language=C++]{../../src/DoxygenChapter.h}
+\lstinputlisting[language=C++]{../../src/ControllerIF.h}
+\lstinputlisting[language=C++]{../../src/Controller.h}
+\lstinputlisting[language=C++]{../../src/Controller.cxx}
+\lstinputlisting[language=C++]{../../src/ChapterIF.h}
+\lstinputlisting[language=C++]{../../src/ChapterFactory.h}
+\lstinputlisting[language=C++]{../../src/ChapterFactory.cxx}
+\lstinputlisting[language=C++]{../../src/Author.h}
index c46e58b..148d94b 100644 (file)
@@ -1,35 +1,58 @@
 \chapter{Anforderungen}
 \label{cha:Anforderungen}
-Im vorherigen Kapitel wurden verschiedene Dokumentationskonzepte in der Softwareentwicklung erläutert. Das Dokumentationswerkzeug soll es dem Anwender ermöglichen Dokumentationen
-auf Basis dieser Konzepte zu erstellen.
+Im vorherigen Kapitel wurden verschiedene Dokumentationskonzepte in der Softwareentwicklung erläutert. Das Dokumentationswerkzeug soll
+es Anwendern ermöglichen Dokumentationen auf Basis dieser Konzepte zu erstellen. Die definierten Funktionalitäten entsprechen den Anforderungen
+der Software Übungsabgaben im Übungsbetrieb des Studiengangs Hardware-Software-Design an der Fachhochschule Hagenberg. Es wird davon ausgegangen,
+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}
-Das Programm soll auf Linux sowie auch auf Windows Systemen einsetzbar sein. Die vom Dokumentationswerkzeug erstellten Vorlagedateien sollen ein einheitliches
-Format aufweisen und auch zwischen den Betriebssystemen ausgetauscht werden können.
+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.
+Außerdem muss gewährleistet sein, dass die vom Dokumentationswerkzeug erstellten Vorlagedateien ein einheitliches Format aufweisen und
+auch zwischen den Betriebssystemen austauschbar sind.
 
 \section{Anwendungsfälle}
 
-\begin{figure} \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=\textwidth]{use_case_doc_tool} \caption{Dieses Use Case Diagramm stellt die Anwendungsfälle 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. Der erste Anwendertyp repräsentiert einen Softwareentwickler, der auf Basis einer vorher definierten Vorlage eine Dokumentation erstellt.
-Der Entwickler soll je nach Bedarf die erstellte Dokumentation im PDF und im Latex Format erstellen können. Da spezielle Problemstellungen unvorhersehbare Änderungen in der Dokumentation
-zur Folge haben können, muss der Entwickler auch die Möglichkeit haben, eine vorher definierte Vorlage an die gegebene Problemstellung anpassen zu können. Der zweite Anwendertyp repräsentiert
-einen Projektleiter, der eine Dokumentationsvorlage erstellt, und somit allen Entwicklern eine einheitliche Konvention vorgibt.
+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.
+\newline
+\par
+Der zweite Anwendertyp repräsentiert
+einen Projektleiter, der eine Dokumentationsvorlage erstellt und somit allen Entwicklern eine einheitliche Konvention vorgibt.
 
 
 \subsection{Schreiben von Dokumentationen}
-
-Der Entwickler soll nach Auswahl einer Vorlagedatei für einen Dokumentationstyp Schritt für Schritt durch den Dokumentationsprozess geleitet werden. Es soll dem Entwickler jederzeit
-möglich sein zu einem vorherigen Schritt zurückzugelangen. Der Entwickler soll außerdem die Möglichkeit besitzen, einzelne Schritte als abgeschlossen zu markieren.
-Auf Basis dieser Markierungen soll während des gesamten Dokumentationsprozesses eine Rückmeldung über den Gesamtfortschritt der Dokumentation gegeben werden.
+Der Entwickler soll nach Auswahl einer Vorlagedatei für einen Dokumentationstyp Schritt für Schritt durch den Dokumentationsprozess geleitet werden.
+Eine Möglichkeit, jederzeit zu einem vorherigen Schritt zurückzugelangen ist zur Verfügung zu stellen.
+\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,
+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} \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.60\textwidth]{use_case_template_generator} \caption{Dieses Use Case Diagramm stellt das Erstellen 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:
 
-Wie in Abb.~\ref{fig:UseCaseTemplate} gezeigt, soll der Projektleiter die Möglichkeit Besitzen für einen Dokumentationstyp benötigte Kapitel und Überschriften in einer Vorlage zu definieren. Außerdem
-soll er für diesen Dokumentationstyp konfigurieren können, ob eine Schnittstellendokumentation generiert werden soll und ob Programmcode in die Dokumentation eingebunden werden soll.
-Diese Einstellungen sollen dann als Vorlagedatei exportiert 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
+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.
 
 
 \section{Qualitätsanforderungen}
@@ -40,22 +63,27 @@ Benutzbarkeit, Wartbarkeit und Zuverlässigkeit unterteilen.
 \subsection{Benutzbarkeit}
 
 \subsubsection{Installationsroutine}
-Das Programm soll so einfach wie möglich zu installieren sein. Damit ist gemeint, dass der Anwender sich nicht um etwaige Programmabhängigkeiten kümmern muss.
-Die Installation soll außerdem bis auf den Installationspfad keinerlei Konfiguration benötigen müssen. Der Installationsprozess muss transparent und nachvollziehbar sein, das bedeutet,
-dass der Anwender zu jeder Zeit wissen muss, welche Programmdateien wo abgelegt werden.
+
+Die Programminstallation ist so einfach wie möglich zu halten. Damit ist gemeint, dass der Anwender sich nicht um etwaige Programmabhängigkeiten
+kümmern muss. Die Installation soll außerdem bis auf den Installationspfad keinerlei Konfiguration benötigen müssen. Der Installationsprozess
+muss transparent und nachvollziehbar sein, das bedeutet, dass der Anwender zu jeder Zeit wissen muss, welche Programmdateien wo abgelegt werden.
 
 \subsubsection{Anwendung}
 
-Um eine einfache Bedienung der Anwendung zu gewährleisten, soll sich die grafische Oberfläche auf ein Fenster beschränken. Auf umfangreiche Konfigurationsmenüs soll verzichtet werden. Auftretende Hinweismeldungen sollen als einfache Textboxen erscheinen.
-Die Menüleiste soll sich an etablierte Standards von Windows und Linux orientieren, das 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.
+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.
 
 \subsection{Wartbarkeit}
 
-Das Dokumentationsprogramm muss, ohne bestehende Komponenten anpassen zu müssen, erweiterbar sein. Vorlagedateien sollen auch ohne Dokumentationsprogramm leicht les- und editierbar sein.
-Um die Einarbeitungszeit für andere Entwickler zu verkürzen, muss der Quellcode mit Kommentarblöcken versehen werden. Außerdem muss dem Entwickler eine technische Dokumentation zur Verfügung stehen.
+Das Dokumentationsprogramm muss, ohne bestehende Komponenten anpassen zu müssen, erweiterbar sein. Vorlagedateien sollen auch 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 auch eventuell auftretende Bedienungsfehler seitens des Anwenders zu keinem Datenverlust führt.
-Dazu müssen alle Dateien bevor sie geladen werden auf deren Existenz und Richtigkeit geprüft werden. Vom Benutzer erstellte Dateien müssen regelmäßig zwischengespeichert werden und vor der
-Erzeugung der Dateien müssen alle Pfade auf Richtigkeit geprüft werden. Bei einem Technischen- oder einem Anwenderfehler muss der Anwender in jedem Fall über den Fehler informiert werden.
+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.
index 1e95a7a..73e4649 100644 (file)
@@ -1,22 +1,74 @@
 \chapter{Einleitung}
 \label{cha:Einleitung}
 
-\section{Problemstellung und Motivation}
+In diesem Kapitel wird die behandelte Problemstellung und Motivation der vorliegenden Arbeit dargestellt und eine Zielsetzung definiert.
+Außerdem wird auf die Gliederung dieser Arbeit eingegangen und der Inhalt der einzelnen Kapitel kurz erläutert.
 
-Die Abgabe von Software-Übungen im Studiengang HSD besteht im generellen aus einem Deckblatt, der theoretischen Ausarbeitung und den ausgearbeiteten Quelltextdateien.
-Übungsabgaben in SEN1 und SEN2 beinhalten außerdem eine Lösungsidee. Im 3. Semester erweitert sich die Abgabe in SDP3 um eine Komponentenübersicht (inklusive Klassendiagramm)
-und einer Beschreibung der einzelnen Komponenten (Klassen). In MPT3, PSS4 und KOM4 bestehen die Übungsabgaben aus Ausarbeitung, Quelltextdateien und Funktionsbeschreibungen.
+\section{Problemstellung und Motivation}
+Da die Entwicklung von Software viel Zeit in Anspruch nimmt, und unter 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
+\par
+Dies ist auch ein allgegenwärtiges Problem im Übungsbetrieb des Studienganges Hardware-Software-Design an der Fachhochschule Hagenberg. Da für die
+Ausarbeitung der Softwareübungen keine einheitlichen Vorlagen verwendet werden und der Fokus meist nur auf die Umsetzung gelegt wird, leidet
+darunter die Qualität der Dokumentationen.
+\newline
+\par
+Es gibt zwar unterschiedliche Kommandozeilenprogramme, die den Dokumentationsprozess vereinfachen, die Handhabung dieser ist aber meist nicht trivial und
+viele können nicht plattformunabhängig eingesetzt werden. Daher wird kaum Zeit in das Erlernen und Verwenden dieser Programme gesteckt.
+\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.
+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.
+Als Grundlage hierfür werden die verschiedenen Softwareübungen im Übungsbetrieb des Studiengangs Hardware-Software-Design an der
+Fachhochschule Hagenberg herangezogen.
 
 \section{Zielsetzung}
 
-Ziel dieser Arbeit ist der Entwurf eines Werkzeuges, mit dem man
 
-\section{Aufgabenstellung}
+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,
+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.
+\newline
+\par
+Des Weiteren soll diese Software vom Anwender auswählbare, vordefinierte Dokumentationsvorlagen besitzen. Eine solche Vorlage definiert den
+Ablauf des Dokumentationsprozesses und den Aufbau der generierten Dokumentation. Diese Vorlagen soll ein Anwender auch bearbeiten, selbst erstellen
+und an andere Anwender weitergeben können.
 
-Das Ziel dieser Arbeit ist es ein Werkzeug zu erstellen, das das Erstellen von Software Dokumentationen unterstützt. Als Ergebnis wird eine druckbare PDF-Datei geliefert, die alle
-benötigten Teile einer Abgabe inklusive Deckblatt, textuelle Beschreibungen und den Quelltext enthält. Zusätzlich sollen aus den Kommentaren im Quelltext generierte
-Darstellungen (Doxygen) ebenfalls in die Abgabe mit eingebunden werden können.
+\section{Gliederung dieser Arbeit}
+
+Die vorliegende Arbeit ist in 7 verschiedene Kapitel gegliedert. Das erste \autoref{cha:Einleitung} umfasst die Motivation und Zielsetzung dieser
+Arbeit.
+\newline
+\par
+In \autoref{cha:Softwaredokumentationen} wird der Begriff der Dokumentation erläutert, wichtige Konzepte zum Dokumentieren in Software Projekten
+beleuchtet und Kommandozeilenprogramme präsentiert die diese Konzepte umsetzen.
+\newline
+\par
+Das \autoref{cha:Anforderungen} definiert den Funktionsumfang des Prototyps auf Basis der Konzepte aus \autoref{cha:Softwaredokumentationen} und
+der durch die Software Übungsabgaben des Studiengangs Hardware-Software-Design an der Fachhochschule Hagenberg gegebenen Anforderungen.
+\newline
+\par
+Der konzeptuelle Aufbau des Prototyps, das Zusammenspiel der einzelnen Komponenten und die Umsetzung der Plattformunabhängigkeit werden in
+\autoref{cha:Konzept} festgelegt.
+\newline
+\par
+Auf die Umsetzung des Prototyps mithilfe der festgelegten Konzepte aus \autoref{cha:Konzept} und die Lösung aller aufkommenden Probleme wird
+in \autoref{cha:Projektumsetzung} eingegangen.
+\newline
+\par
+In \autoref{cha:Tests} wird der Testablauf der verschiedenen Prototypentests erläutert. Außerdem beinhaltet dieses Kapitel eine Zusammenfassung
+und Evaluierung aller Testergebnisse.
 \newline
-Das Werkzeug selbst ist plattformunabhängig und läuft sowohl auf der Windows-, als auch auf der Linux-Plattform.
-Über eine graphische Benutzeroberfläche werden die Benutzer beim Erstellen Abgaben und eigenen Abgabe Vorlagen entsprechend unterstützt
-und durch den Dokumentationsprozess geführt.
+\par
+Das letzte \autoref{cha:Zusammenfassung} umfasst die Zusammenfassung der Erkenntnisse dieser Arbeit und ein Fazit aus der Prototypenentwicklung.
+Darüber hinaus werden in einem Ausblick Vorschläge für Verbesserungen und Erweiterungen des Prototyps formuliert.
index c1005e8..7567ce0 100644 (file)
 \chapter{Konzept}
 \label{cha:Konzept}
 
-Umsetzungskonzept des Programmes
+In diesem Kapitel wird ein Umsetzungskonzept für die im letzten Kapitel beschriebenen Anforderungen erarbeitet. Im Laufe dieses Kapitels wird Bezug
+auf \cite{wxWidgetsMan}, \cite{fltkMan}, \cite{python}, \cite{mvc}, \cite{johnson1998anwendungen},\cite{JavaInsel6}, \cite{CrossDevWorkflow}, \cite{LinuxCert}, \cite{mingw}, \cite{gcc} und \cite{xmlJson}
+genommen.
 
-\section{Sicherstellen der Platformunabhängigkeit}
+\section{Struktur des Programms}
 
-\subsection{Abhängigkeiten}
-Latex, Doxygen
-Systemweite Shared libraries vs. pakete mit eigenen abhängigkeiten + programmen
+\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:
 
-\subsection{Grafikbiliotheken}
-Kurzer vergleich gängiger Cross Platform Frameworks, warum fltk?
+\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}
+
+\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
+\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.
+
+\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
+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.
+
+\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.
+
+\subsubsection{Fazit}
+
+Ein entschiedener Nachteil des JSON-Formates gegenüber dem XML-Format ist, das dieses nicht erweiterbar ist. XML eignet sich besser, um Hierarchien und verschachtelte Objekte zu repräsentieren.
+
+\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:
+
+\begin{verbatim}
+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".
+
+Zahl = Ziffer {Ziffer}.
+Ziffer = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9".
+
+Bool = "true" | "false".
+
+Koordinaten = X_Koordinate Y_Koordinate.
+X_Koordinate = "<x_coor>" Zahl "</x_coor>".
+Y_Koordinate = "<y_coor>" Zahl "</y_coor>".
+
+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>".
+
+Autoren = "<authors>" Autor {Autor} "</authors>".
+Autor = "<author>" Nummer Koordinaten Geschäzte_Zeit
+        ID Verbrauchte_Zeit "</author>".
+Nummer = "<num>" Zahl "</num>".
+ID = "<id>" Koordinaten "</id>".
+Verbrauchte_Zeit = "<time_spent>" Koordinaten "</time_spent>".
+Geschäzte_Zeit = "<time_estimated>" Koordinaten "</time_estimated>".
+
+Dokumenteneinstellung = "<docsettings>" Dokumentenname
+                        Ort Deckblatt Titelblatt
+                                               Inhaltsverzeichnis Dateiendungen
+                        Gruppe Autoren "</docsettings>".
+
+Mehrere_Kapitel = "<chapters>" Kapitel {Kapitel} "</chapters>".
+Kapitel = "<chapter>" Kapitelname Nummer Dateiname
+          Inhalt Typ Überschrift </chapter>.
+Kapitelname = "<prettyName>" Wort "</prettyName>".
+Dateiname = "<filename>" Wort "</filename>".
+Inhalt = "<content>" Text "</content>".
+Typ = "<type>" Kapiteltypen "</type>".
+Kapiteltypen = "Text" | "Doxygen" | "Sourcecode".
+Überschrift = "<hierachy>" Überschriften "</hierachy>".
+Überschriften = "chapter" | "section" | "subsection".
+
+Vorlage = Dokumenteneinstellung Mehrere_Kapitel.
+
+\end{verbatim}
+
+\section{Sicherstellen der Plattformunabhängigkeit}
+
+In diesem Abschnitt wird Schritt für Schritt, durch Vergleichen verschiedener Optionen, ein Konzept ausgearbeitet nach diesem der Prototyp als plattformunabhängiges Programm umgesetzt werden kann.
+
+\subsection{Programmiersprachen}
+
+Damit der Prototyp auf 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.
+
+\subsubsection{C++}
+
+\textit{C++} ist ebenfalls eine objektorientierte Programmiersprache, deren Quellcode mithilfe eines Compilers in binären
+Programmcode umgewandelt werden muss, um eine ausführbare Datei zu erhalten. Die \textit{C++} Binärdateien werden aber direkt auf dem
+System ausgeführt und nicht in einer virtuellen Maschine. Somit kann ein \textit{C++} Programm nur auf Systemen ausgeführt
+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.
+
+
+\subsubsection{Fazit}
+Da um \textit{Java} Applikationen ausführen zu können auf den Zielsystemen eine Java-Laufzeitumgebung vorhanden sein muss und 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.
+
+\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
+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.
 
 \subsection{Linken externer Bibliotheken}
-Konzepte beschreiben, probleme satic linking vs. dynamic linking, etc
+Im folgenden Abschnitt wird erklärt, wie ein Programm mit externen Bibliotheken umgehen kann. Die verschiedenen Möglichkeiten
+werden dann abgewogen und in einem Fazit wird entschieden, welche Methode für den Prototyp verwendet wird.
+
+\subsubsection{Statisches Linken}
+Wird eine Bibliothek statisch gelinkt, dann werden die Funktionen dieser Bibliothek direkt in die ausführbare Datei kopiert.
+Voraussetzung dafür ist, dass die gelinkte Bibliothek selbst statisch ist. Dies bedeutet, dass mindestens eine Objektdatei mithilfe des
+Kommandozeilenprogrammes \textit{ar (archiver utility)} in ein Archiv umgewandelt wurde. \textit{Ar} fügt zu einem solchen Archiv eine Tabelle hinzu, in der vermerkt ist welche Symbole, wo im Archiv zu finden sind.
+
+\subsubsection{Dynamisches Linken}
+Beim dynamischen Linken werden die Funktionen einer dynamische Bibliothek in der ausführbaren Datei nur referenziert. Die dynamische
+Bibliothek wird erst dann geladen, wenn das Programm gestartet wird. Ein wesentlicher Vorteil von dynamischen Bibliotheken gegenüber statischen
+ist, dass der ausführbare Code für alle Prozesse, die diese Bibliothek benutzen nur einmal in den Speicher geladen wird.
+
+\subsubsection{Fazit}
+Da der Prototyp nur als einzelner Prozess laufen soll, ist durch die Verwendung von dynamischen Bibliotheken kein wirklicher Vorteil gegeben.
+Es macht daher mehr Sinn alle externen Bibliotheken statisch in die ausführbare Datei zu linken, da man somit von externen Bibliotheken
+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
+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.
+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.
+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,
+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
+in kommerziellen Programmen statisch gelinkt werden darf.
+
 
+\subsubsection{Fazit}
+Das \textit{Qt Framework} kann für den Prototyp leider nicht verwendet werden, da die Lizenz der kostenfreien Version ein statisches Linken unterbindet.
+\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
+die Visualisierungen mithilfe der Systemschnittstellen des Zielsystems zeichnet. Dies würde dann den in \autoref{cha:Anforderungen} definierten
+Anforderungen widersprechen.
+\newline
+\par
+Mit \textit{FLTK} entwickelte Programme haben hingegen auf allen Betriebssystemen das gleiche Aussehen. Außerdem lässt
+sich diese Bibliothek einfach statisch Linken und darf sogar in kommerziellen Projekten eingesetzt werden. Daher wird für die Entwicklung
+des Prototypen \textit{FLTK} verwendet.
 
-\section{Aufbau der Bedienoberfläche}
-Aufbau/design GUI etc. (BILD!)
+\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}
 
-\subsection{Seperieren von grafischer Bedienoberfläche und Programm}
-Vorteile erläutern
-anspielung auf MVC Konzept, beschreibung MVC + observer bei implementierung!
+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 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
+\item Anzeige des Aktuell ausgewählten Kapitels
+\item hier ist Platz für Elemente mit denen allgemeine Dokumenteinstellugen verändert werden können (z.B. Deckblatt)
+\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
+\end{enumerate}
 
-\section{Struktur des Programmes}
+\subsection{Separieren von grafischer Bedienoberfläche und Funktionalität}
 
-Überblicksbild aus präsentation! Beschreibung der komponenten
+\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}
 
-\subsection{Klassenstruktur}
-Klassendiagramm und beschreibung
+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.
 
-\subsection{Beziehungen}
-Beziehungsdiagramm und beschreibung
+\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.
 
+\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.
 
+\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
+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
+angepasst werden.
index ec9508d..cf3a88d 100644 (file)
 \chapter{Projektumsetzung}
 \label{cha:Projektumsetzung}
 
-\section{MVC Konzept}
-UML diagramm!
+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
+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.
 
 \subsection{Implementierung des Models}
-model -> controller Observer Pattern!
-hält daten
+Das 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
+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}
+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
+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.
+
+
+
+\subsection{Implementierung der View}
 
-\subsection{Implementierung des Views}
-guiklasse mid fluid erstellt
+\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
+Programmbibliothek \textit{FLTK} erstellt. Dieses bietet die Möglichkeit mithilfe des Programms
+\textit{FLUID} grafische Oberflächen zu designen.
+\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.
 
 \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.
+
 \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
+kompiliert werden.
+
+\subsection{Installieren der Abhängigkeiten}
+
+Folgende Abhängigkeiten müssen auf dem Entwicklungssystem mithilfe des Paketmanagers installiert werden:
+\begin{lstlisting}[language=bash]
+$ sudo dpkg --add-architecture i386
+$ sudo apt update
+$ sudo mv /usr/lib/llvm-3.9/lib/libclang-3.9.so.1 /usr/lib/llvm-3.9/lib/libclang-3.9.so.1.bak
+$ 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.
+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
+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.
+
 \subsection{Linux}
-GCC native compiling
-So viel wie geht statisch linken, restliche libs mitliefern
+
+\subsubsection{FLTK}
+
+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.
+\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
+\end{lstlisting}
+
+\subsubsection{tinyxml2}
+
+\textit{tinyxml2} wird mit dem GNU C++ Compiler \textit{gcc} kompiliert und danach mit dem Befehl \textit{ar} in eine statische Bibliothek umgewandelt.
+
+\begin{lstlisting}[language=bash]
+$ g++ -m32 -c -o tinyxml2.o tinyxml2.cpp
+$ ar rvs libtinyxml2.a tinyxml2.o
+\end{lstlisting}
+
+\subsubsection{Prototyp}
+\label{ssc:LinkingLinux}
+
+Der Prototyp muss unter Linux mit folgenden Linker Parametern gelinkt werden:
+
+\begin{lstlisting}
+-static-libstdc++
+-static-libgcc
+./libfltk.a
+./libtinyxml2.a
+-ldl
+-lm
+-lX11
+\end{lstlisting}
+
+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,
+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
+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.
 
 \subsection{Windows}
-MinGW Cross compiling
-Alles statisch gelinkt
+
+\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.
+
+\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
+$ make
+\end{lstlisting}
+
+\subsubsection{tinyxml2}
+
+Die statische \textit{tinyxml2} Programmbibliothek wird analog wie bei 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
+$ i686-w64-mingw32-ar rvs libtinyxml2.a tinyxml2.o
+\end{lstlisting}
+
+\subsubsection{Prototyp}
+
+Unter Windows muss der Prototyp mit diesen Parametern gelinkt werden:
+
+\begin{lstlisting}
+-mwindows
+-static-libgcc
+-static-libstdc++
+./libfltk.a
+./libtinyxml2.a
+-lole32
+-luuid
+-lcomctl32
+\end{lstlisting}
+
+Für Windows können alle Komponenten in ein einziges ausführbares Programm gelinkt werden.
 
 \section{Programmumgebung}
 
-\subsection{LaTex}
-TexLive installer fürs jeweilige OS
-\subsection{Doxygen}
-Binaries fürs jeweilige OS mitgeliefert
+Damit das Dokumentationswerkzeug die externen Programme \textit{Doxygen} und \textit{Texlive} verwenden kann, müssen diese in eine
+Programmumgebung gepackt werden. Diese Programmumgebung gliedert sich in folgende Verzeichnisse:
+
+\begin{itemize}
+\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{texlive\_windows/texlive\_linux:} Die Namensgebung dieses Ordners ist abhängig vom Betriebssystem. Hier wird die vollständige
+\textit{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.
+
+\subsection{Programmumgebung Linux}
+\textit{Texlive} wird mithilfe der Offiziellen Installationsroutine \cite{texlive} als portable Version in das Unterverzeichnis \textit{texlive\_linux}
+installiert.
+\newline
+\par
+\textit{Doxygen} und dessen Abhängigkeiten werden direkt aus den Paketquellen \cite{DebRpm} des Entwicklungssystems bezogen und nach \textit{bin} kopiert.
+Um die Abhängigkeiten leicht kopieren zu können, kann folgendes Bash-Skript verwendet werden:
+
+\begin{lstlisting}[language=bash,caption={Bash-Skript zum kopieren von Abhängigkeiten}]
+#!/bin/bash
+
+function useage()
+{
+    cat << EOU
+Useage: bash $0 <path to the binary> <path to copy the dependencies>
+EOU
+exit 1
+}
+
+#Validate the inputs
+[[ $# < 2 ]] && useage
+
+#Check if the paths are vaild
+[[ ! -e $1 ]] && echo "Not a vaild input $1" && exit 1
+[[ -d $2 ]] || echo "No such directory $2 creating..."&& mkdir -p "$2"
+
+#Get the library dependencies
+echo "Collecting the shared library dependencies for $1..."
+deps=$(ldd $1 | awk 'BEGIN{ORS=" "}$1\
+~/^\//{print $1}$3~/^\//{print $3}'\
+ | sed 's/,$/\n/')
+echo "Copying the dependencies to $2"
+
+#Copy the deps
+for dep in $deps
+do
+    echo "Copying $dep to $2"
+    cp "$dep" "$2"
+done
+
+echo "Done!"
+\end{lstlisting}
+
+Dieses Skript ermittelt mithilfe des Programmes \textit{ldd} alle von einer Anwendung benötigten Programmbibliotheken und kopiert diese in das
+angegebene Verzeichnis.
+
+\subsubsection{Start Script}
+
+Um das Dokumentationswerkzeug innerhalb dieser Programmumgebung ausführen zu können, wird folgendes Skript benötigt, das die Umgebung initialisiert:
+
+\begin{lstlisting}[language=bash,caption={Bash Start Skript}]
+DIR=$(pwd)
+export PATH=$DIR/texlive_linux/2018/bin/i386-linux:$DIR/bin:$PATH
+export LD_LIBRARY_PATH=$DIR/lib
+$LD_LIBRARY_PATH/ld-linux.so.2 --library-path $LD_LIBRARY_PATH $DIR/bin/doc_tool
+\end{lstlisting}
+
+Dieses Bash-Skript erweitert den Systempfad um die Pfade der Programmumgebung und ermöglicht somit das Starten des Dokumentationsprogramms
+mit Zugriff auf \textit{Doxygen} und \textit{Texlive}. Wie man erkennen kann, wird wie unter \ref{ssc:LinkingLinux} erwähnt das
+Dokumentationswerkzeug indirekt über den dynamischen Lader \textit{ld-linux.so.2} aufgerufen.
+
+\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
+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}.
+
+\subsubsection{Start Skript}
+
+Wie unter Linux muss auch hier die Programmumgebung mithilfe eines Startskriptes initialisiert werden.
+
+\begin{lstlisting}[caption={Batch Start Skript}]
+@echo off
+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.
+
 
 \section{Pakete Erstellen}
-Warum wurde welcher archivtyp gewählt (zitatquelle nicht vergessen!)
-Beide selbstextrahierend mit fortschrittsanzeige, einfach zu bedienen
+
+Um das Dokumentationsprogramm mit all seinen Abhängigkeiten leicht weitergeben und auf verschiedenen Systemen einrichten zu können,
+ist es nötig, die gesamte Programmumgebung in ein komprimiertes Paket zusammenzufassen.
+
 \subsection{Linux}
-tar.gz
+Unter 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.
+\newline
+\par
+Es wurde ein Hilfsprogramm geschrieben, das \textit{.tar.gz} Pakete mithilfe der gerade aufgezeigten Methode
+in ein selbstextrahierendes Archiv umwandeln kann:
+\begin{lstlisting}[language=bash]
+#!/bin/sh
+#Script that creates self extracting executable script from tar.gz file.
+if [ $# -eq 0 ] || [ ! -f $1 ]; then
+        echo "This script creates self extractable executable"
+        echo Usage: $0 [/path/to/*.tar.gz]
+        exit;
+fi
+if [ $# -gt 0 ]; then
+        TAR_FILE=$1
+fi
+EXIT_COMMAND=exit
+if [ $# -gt 1 ]; then
+        EXIT_COMMAND="exec $2"
+fi
+FILECOUNT=$(tar -tzf $TAR_FILE | wc -l)
+SELF_EXTRACTABLE="$TAR_FILE.run"
+
+cat > ${SELF_EXTRACTABLE} << EOL
+#!/bin/bash
+if [ -f '/usr/bin/xmessage' ] || [ -f '/usr/bin/gxmessage' ]; then
+    XMESSAGE=\$(which gxmessage) || XMESSAGE=xmessage
+    PWD=\$(pwd)
+    ans=\$(\$XMESSAGE -nearmouse -title 'Extract?' -buttons yes,no Extract to: [ \$PWD ] ? -print)
+else
+    ans=yes
+fi
+if [ "\$ans" == "yes" ]; then
+    TOSKIP=\$(awk '/^#----- ARCHIVE STARTS HERE -----#/ {print NR + 1; exit 0; }' \$0)
+    COUNT=$FILECOUNT
+    echo "Installing Doc Tool: "&
+    PID=\$!
+    LINE="                                                  "
+    LINENUM=0
+
+    # Extract
+    tail -n+\$TOSKIP \$0  | tar -xzvp 2>&1 |
+    while read line; do
+        x=\$((x+1))
+
+        # calculate percentage
+       PERCENTAGE_NUM=\$(((x*100)/COUNT))
+       PERCENTAGE=\$(printf '%03d' \$PERCENTAGE_NUM)
+
+        # create gauge line
+        if [ "\$PERCENTAGE_NUM" -ge "\$LINENUM" ]; then
+               LINE=\${LINE/ />}
+
+                if [ "\$PERCENTAGE_NUM" -ge "100" ]; then
+                        LINE=\${LINE// />}
+                fi
+       fi
+
+        # display gauge line
+        if [ -z \${XMESSAGE+x} ]; then
+              echo -en "[\$LINE] \$x / \$COUNT extracted (\$PERCENTAGE%)\r"
+                if [ "\$PERCENTAGE_NUM" -ge "\$LINENUM" ]; then
+                     LINENUM=\$((PERCENTAGE_NUM+2))
+               fi
+        else
+               if [ "\$PERCENTAGE_NUM" -ge "\$LINENUM" ]; then
+                     LINENUM=\$((PERCENTAGE_NUM+2))
+                      if ps -p \$PID > /dev/null
+                      then
+                            kill \$PID 2> /dev/null
+                      fi
+                      \$XMESSAGE -center -title 'Progress' "[\$LINE] \$x / \$COUNT extracted! (\$PERCENTAGE%)" &
+                       PID=\$!
+               fi
+        fi
+    done
+
+    # check if untar was successful
+    if [ "\${PIPESTATUS[1]}" != "0" ]; then
+        if [ -z \${XMESSAGE+x} ]; then
+            echo 'Failed to extract package!'
+        else
+             \$XMESSAGE -nearmouse -title 'Error!' 'Failed to extract package!'
+        fi
+        exit 1
+    fi
+
+    # display success message
+    if [ -z \${XMESSAGE+x} ]; then
+       echo ''
+        echo 'Finished extracting!'
+    else
+        \$XMESSAGE -nearmouse -title 'Success' 'Finished extracting!'
+    fi
+   exit
+else
+   exit
+fi
+#----- ARCHIVE STARTS HERE -----#
+EOL
+
+cat $TAR_FILE >> $SELF_EXTRACTABLE
+chmod a+x $SELF_EXTRACTABLE
+\end{lstlisting}
+
 \subsection{Windows}
-zip
+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.
+
+\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.
index dbc6a22..6267b90 100644 (file)
@@ -2,64 +2,67 @@
 \label{cha:Softwaredokumentationen}
 
 
-Im folgenden Kapitel wird allgemein das Thema Dokumentationen im Softwarebereich beleuchtet. Es wird auf allgemeine Probleme eingegangen
-und Konzepte vorgestellt, die diese Probleme lösen können.
+Im folgenden Kapitel wird allgemein das Thema Dokumentationen im Softwarebereich beleuchtet. Es wird auf die verschiedenen Dokumentationstypen
+eingegangen, allgemeine Probleme vorgestellt und Konzepte, die diese Probleme lösen können werden präsentiert. Außerdem werden Programme aufgezeigt, die
+diese Konzepte zum Teil umsetzten, und somit bei der Erstellung von Dokumentationen helfen können.
 
 \section{Allgemeine Eigenschaften}
 
-Der Begriff Softwaredokumentation ist in der Literatur nicht einheitlich definiert, generell kann man Dokumentationstypen daran unterscheiden, für
+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.
 
 \subsection{Benutzerdokumentation}
 
-Die Benutzerdokumentation ist für die Anwender eines Programmes gedacht und besitzt einen anleitenden Charakter. Hier wird beschrieben, wie das Programm zu handhaben ist, und welche Funktionen es
-bietet. In Benutzerdokumentationen wird weniger auf technische Details eingegangen, sondern die Handhabung von für Benutzer bestimmte grafische Programmoberflächen erläutert.
-\subsection{Systemdokumentation}
+Die Benutzerdokumentation ist für die Anwender eines Programmes gedacht und besitzt einen anleitenden Charakter. Hier wird beschrieben, wie das Programm zu handhaben ist und welche Funktionen es
+bietet. Es wird weniger auf technische Details eingegangen, sondern die Handhabung von für Benutzer bestimmte grafische Programmoberflächen erläutert \cite{Sommerville}.
 
+\subsection{Systemdokumentation}
 Als Systemdokumentation versteht man Quellcode und Schnittstellendokumentationen. Diese sind für Entwickler gedacht und helfen bei der Verwendung
 von Programmbibliotheken und Entwicklungswerkzeugen. Entwickler können deren Arbeit selbst dokumentieren, damit sie ihre Gedankengänge zu einem
-späteren Zeitpunk besser nachvollziehen können, und um anderen einen leichteren Einstieg mit der Handhabung von entworfenen Schnittstellen zu ermöglichen.
-
-\section{Probleme}
+späteren Zeitpunk besser nachvollziehen können und um anderen einen leichteren Einstieg mit der Handhabung von entworfenen Schnittstellen zu ermöglichen \cite{Sommerville}.
 
-Aufgrund der Schnelllebigkeit von Programmen und Zeitdruck in der Entwicklung wird oft schlecht, bis gar nicht dokumentiert.
-Dies ist vor allem ein im Bereich der Systemdokumentation sehr ausgeprägtes Problem. Als Beispiel kann man
-hier die von vielen Entwicklern vertretene Meinung, dass der Programmcode selbst Dokumentation genug sei, anführen.
 
 \section{Dokumentationskonzepte}
 
-Um diesem Problem entgegenzuwirken, gibt es verschiedene Ansätze und Konzepte. Zwei bekannte Konzepte nennen sich Literate Programming und Elucidative Programming.
+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
+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.
 
 
 \subsection{Literate Programming}
-
-Bei Literate Programming wird die Dokumentation direkt im Programmcode durchgeführt und später aus dem Programmcode ein Dokument erzeugt.
-Dies soll dazu führen, dass man den Programmcode selbst nachvollziehbar lesen kann.
+\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
+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
+Programmcode \cite{LiterateProgramming}.
 
 \subsection{Elucidative Programming}
-
-Elucidative Programming verfolgt die Strategie, bestehenden Programmcode in ein Dokument einzubinden. Programmcode und Dokumentation sind hier getrennt.
-Änderungen im Code direkt in das Dokument übernommen. Dies hat den Vorteil, dass man die Dokumentation nicht an zwei stellen warten muss.
+\label{ssec:ElucidativeProgramming}
+Elucidative Programming kann als Variante des 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}.
 
 \section{Unterstützende Programme}
 
-Um mit diesen Konzepten arbeiten zu können, gibt es verschiedene freie Programme. Eine Auswahl der Bekanntesten wird hier vorgestellt.
-
-\subsection{DocBook}
-Elucidative
-ähnlich latex, schreiben im XML format
+Um mit diesen Konzepten arbeiten zu können, gibt es verschiedene freie Programme. Als die Bekanntesten kann man \emph{Doxygen} \ref{ssec:Doxygen} und \emph{\latex} \ref{ssec:Latex} anführen. Diese
+werden im folgenden Abschnitt genauer erläutert.
 
-\subsection{Latex}
-Latex ist eine Auszeichnungssprache zum Erzeugen von Dokumenten. Dies Bedeutet, dass die Textformatierung über Steuerbefehle erfolgt.
-Latex eignet sich sehr gut für Elucidative Programming, da Programmcode einfach mithilfe von bestehenden Makros eingebunden werden kann
 
-\subsection{JavaDoc}
-Doxygen setzt das Konzept von Literate Programming zu einem großen Teil um. Es ist möglich mithilfe von definierten
-Steuerbefehlen in den Kommentarblöcken, Schnittstellen und Klassen zu beschreiben. Mithilfe von diesen Kommentarblöcken
-kann man Dokumentationen in verschiedenen Ausgabeformaten erzeugen.
+\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
+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
+werden kann.
 
 \subsection{Doxygen}
-Doxygen setzt das Konzept von Literate Programming zu einem großen Teil um. Es ist möglich mithilfe von definierten
-Steuerbefehlen in den Kommentarblöcken, Schnittstellen und Klassen zu beschreiben. Mithilfe von diesen Kommentarblöcken
-kann man Dokumentationen in verschiedenen Ausgabeformaten erzeugen. Doxygen bietet außerdem die Möglichkeit Klassenhierarchien
-grafisch darzustellen und kann auch Javadoc Steuerbefehle interpretieren.
+\label{ssec:Doxygen}
+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.
index d09a680..dabc450 100644 (file)
@@ -1,3 +1,78 @@
-\chapter{Testen des Testsystems}
+\chapter{Tests}
+\label{cha:Tests}
+In diesem Kapitel wird zunächst der Testablauf des Prototypentests beschrieben, danach die Ergebnisse auf den verschiedenen Testsystemen präsentiert.
+
+\section{Ausgangssituation}
+\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
+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,
+Quelltextdateien und Funktionsbeschreibungen.
+\newline
+\par
+Für diese sechs verschiedenen Abgabetypen wurde jeweils eine repräsentative Software Ausarbeitung für die Tests gewählt und mithilfe des Prototyps
+jeweils eine Dokumentationsvorlage erstellt. Diese Vorlagen dienen dazu um das Generieren verschiedener Dokumentationen zu testen.
+
+\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.
+\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
+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.
+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
+Version zu testen, und zum anderen \emph{Windows 10} (64 Bit) gewählt, da es die derzeit aktuellste Version ist.
+
+\section{Testablauf}
+
+Im ersten Schritt wurde der Prototyp mit der erzeugten Installationsroutine auf dem Testsystem installiert. Dieser Test wird in der Ergebnistabelle
+\ref{tab:Ergebnisse} in der Spalte \textit{Installation} angezeigt.
+\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}.
+\newline
+\par
+Diese Vorlage wurde nun 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
+Zu guter Letzt wurden mit allen in \textit{Ausgangssituation} \ref{sec:Ausgangssituation} erstellten Vorlagen Dokumente generiert.
+Diese Ergebnisse befinden sich in der letzten Spalte \textit{Generieren der Tests} in der Ergebnistabelle \ref{tab:Ergebnisse}.
 
 \section{Testergebnisse}
+
+\begin{table}[htbp]
+\caption{Testergebnisse im Überblick.}
+\label{tab:Ergebnisse}
+\centering
+\setlength{\tabcolsep}{3mm}
+\def\arraystretch{1.55}
+\begin{tabular}{|c|c|c|c|c|}
+\hline
+\textbf{\thead{Betriebsystem}}      & \textbf{\thead{Installation}} & \textbf{\thead{Vorlage \\ erzeugen}} & \textbf{\thead{Vorlage \\ bearbeiten}} & \textbf{\thead{Generieren \\ der \\ Tests}} \\ \hline
+Windows 7 (32 Bit)  & \ding{51}             & \ding{51}                        & \ding{51}                          & \ding{51} \\ \hline
+Windows 10 (64 Bit) & \ding{51}             & \ding{51}                       & \ding{51}                        & \ding{51}\\ \hline
+Debian 9 (64 Bit)   & \ding{51}             & \ding{51}                        & \ding{51}                         & \ding{51} \\ \hline
+Fedora 27 (32 Bit)  & \ding{51}             & \ding{51}                      & \ding{51}                        & \ding{51} \\ \hline
+\end{tabular}
+\end{table}
+
+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.
+
+\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.
index 4bc8f4f..91305a4 100644 (file)
@@ -1,6 +1,19 @@
 \chapter{Zusammenfassung und Ausblick}
+\label{cha:Zusammenfassung}
 
 \section{Zusmmenfassung}
 
+Vor dem dem Ausblick werden im folgenden Abschnitt die Erkenntnisse aus den letzten Kapiteln zusammengefasst.
+\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.
 
-\section{Ausblick}
\ No newline at end of file
+\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.
index 56b44ab..27caa04 100644 (file)
@@ -2,7 +2,22 @@
 
 
 \begin{english} %switch to English language rules
-This should be a 1-page (maximum) summary of your work in English.
-%und hier geht dann das Abstract weiter...
+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.
+\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
+\newline
+\par
+For this prototype to work, Linux and 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.
+\newline
+\par
+Finally, the created graphical documentation program is examined in practice, the platform independence is
+tested on different test systems and a conclusion is given.
 \end{english}
 
index 73725e2..fa959f1 100644 (file)
@@ -1,20 +1,19 @@
 \chapter{Kurzfassung}
 
-Da die Entwicklung von Software viel Zeit in Anspruch nimmt, rückt die Dokumentation dieser meist in den Hintergrund. 
-Es gibt zwar unterschiedliche Kommandozeilenprogramme, die den Dokumentationsprozess vereinfachen, die Handhabung 
-dieser ist meist aber nicht trivial und erfordert eine gewisse Einarbeitungszeit. Daher wird Software oft schlecht oder 
+Aufgrund von Mangel an Zeit und der scheinbaren Unproduktivität wird der Dokumentation in Software Projekten nur wenig Beachtung geschenkt.
+Bestehende Hilfsprogramme sind oft umständlich in der Bedienung, daher wird Software oft schlecht oder
 gar nicht dokumentiert. Als Beispiel hierfür kann man einen Großteil der quelloffenen und freien Software nennen.
-
-Ziel dieser Arbeit ist es eine einfach zu bedienende grafische Benutzeroberfläche für Linux und Windows zu entwickeln, 
-die den Anwender beim Schreiben von Software Dokumentationen unterstützt, indem sie verschiedene Arbeitsschritte 
-für bestehende Kommandozeilenprogramme automatisiert. Des Weiteren soll diese Software für verschiedene 
-Dokumentationstypen vom Anwender auswählbare, vordefinierte Profile besitzen. Ein solches Profil definiert den 
-Ablauf des Dokumentationsprozesses und den Aufbau der generierten Dokumentation. Diese Profile soll ein Anwender 
-auch bearbeiten und selbst erstellen können.
-
-Um das Generieren der Dokumentationen zu ermöglichen, wird jeweils für Linux und Windows eine Programmumgebung 
-erstellt, die alle wichtigen Kommandozeilenprogramme und deren Konfiguration beinhaltet. Danach wird eine plattformunabhängige 
-grafische Benutzeroberfläche erstellt, die den Anwender durch den Dokumentationsprozess führen soll.
-
-Abschließend wird das erstellte grafische Dokumentationsprogramm im praktischen Einsatz betrachtet und dessen 
-Vor- und Nachteile gegenüber traditionellen Methoden analysiert.
\ No newline at end of file
+\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.
+\newline
+\par
+Für diesen Prototyp wird jeweils für Linux und 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.
+\newline
+\par
+Abschließend wird das erstellte grafische Dokumentationsprogramm im praktischen Einsatz betrachtet, die Plattformunabhängigkeit auf
+verschiedenen Testsystemen überprüft und ein Fazit gegeben.
diff --git a/doc/thesis/images/author.png b/doc/thesis/images/author.png
new file mode 100644 (file)
index 0000000..e4677e9
Binary files /dev/null and b/doc/thesis/images/author.png differ
diff --git a/doc/thesis/images/doc_tool.png b/doc/thesis/images/doc_tool.png
new file mode 100644 (file)
index 0000000..aff870c
Binary files /dev/null and b/doc/thesis/images/doc_tool.png differ
diff --git a/doc/thesis/images/doc_tool_win.png b/doc/thesis/images/doc_tool_win.png
new file mode 100644 (file)
index 0000000..077a5ef
Binary files /dev/null and b/doc/thesis/images/doc_tool_win.png differ
diff --git a/doc/thesis/images/fluid.png b/doc/thesis/images/fluid.png
new file mode 100644 (file)
index 0000000..b765630
Binary files /dev/null and b/doc/thesis/images/fluid.png differ
diff --git a/doc/thesis/images/gui_aufbau.png b/doc/thesis/images/gui_aufbau.png
new file mode 100644 (file)
index 0000000..88f7ff9
Binary files /dev/null and b/doc/thesis/images/gui_aufbau.png differ
diff --git a/doc/thesis/images/mvc.png b/doc/thesis/images/mvc.png
new file mode 100644 (file)
index 0000000..5080fd7
Binary files /dev/null and b/doc/thesis/images/mvc.png differ
diff --git a/doc/thesis/images/observer.png b/doc/thesis/images/observer.png
new file mode 100644 (file)
index 0000000..da6b7df
Binary files /dev/null and b/doc/thesis/images/observer.png differ
diff --git a/doc/thesis/images/program_overview.png b/doc/thesis/images/program_overview.png
new file mode 100644 (file)
index 0000000..a3f53e3
Binary files /dev/null and b/doc/thesis/images/program_overview.png differ
diff --git a/doc/thesis/images/simple_factory.png b/doc/thesis/images/simple_factory.png
new file mode 100644 (file)
index 0000000..d58b3f1
Binary files /dev/null and b/doc/thesis/images/simple_factory.png differ
index b5e8b75..0813e12 100644 (file)
@@ -12,7 +12,9 @@
 %   Typ der Arbeit: diploma, master (default), bachelor, internship
 %   Hauptsprache: german (default), english
 %%%----------------------------------------------------------
-
+\usepackage{makecell}
+\usepackage{float}
+\usepackage{pifont}
 \RequirePackage[utf8]{inputenc}                % bei der Verw. von lualatex oder xelatex entfernen!
 
 \graphicspath{{images/}}    % Verzeichnis mit Bildern und Grafiken
@@ -26,9 +28,9 @@
 %%% Einträge für ALLE Arbeiten: -----------------------------
 \title{Plattformunabhängiges Werkzeug zur Generierung von Software-Dokumentationen}
 \author{Daniel Giritzer}
-\programname{Hardware Software Design}
+\programname{Hardware-Software-Design}
 \placeofstudy{Hagenberg}
-\dateofsubmission{2017}{02}{28}        % {YYYY}{MM}{DD}
+\dateofsubmission{2018}{08}{20}        % {YYYY}{MM}{DD}
 
 %%% Zusätzlich für eine Bachelorarbeit: ---------------------
 \thesisnumber{1510306010-A}   % Stud-ID, z.B. 1310238045-A
@@ -51,7 +53,7 @@
 \maketitle
 \tableofcontents
 
-\include{front/vorwort} % Optional. Ggf. weglassen
+%\include{front/vorwort} % Optional. Ggf. weglassen
 \include{front/kurzfassung}
 \include{front/abstract}
 
@@ -72,9 +74,9 @@
 \appendix                                            % Anhang
 %%%----------------------------------------------------------
 
-\include{back/anhang_a}        % Technische Ergänzungen
+%\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_c}       % Chronologische Liste der Änderungen
 \include{back/anhang_d}        % Quelltext dieses Dokuments
 
 %%%----------------------------------------------------------
index cd27921..323dc91 100644 (file)
+% Kompressionsverfahren
 @INPROCEEDINGS{CrossDevWorkflow,
        author={M. Wojtczyk and A. Knoll},
        booktitle={2008 The Third International Conference on Software Engineering Advances},
        title={A Cross Platform Development Workflow for C/C++ Applications},
        year={2008},
-       volume={},
-       number={},
        pages={224-229},
        keywords={ANSI standards;C++ language;ISO standards;Linux;operating systems (computers);project management;public domain software;workflow management software;American National Standards Institute;C languages;C++ languages;CMake;International Standards Organization;Linux;Mac OS X;OpenGL;Windows;cross platform development workflow;open source project;operating systems;source code project management;standard template library;ANSI standards;Code standards;Computer languages;ISO standards;Libraries;Linux;Operating systems;Project management;Standards development;Standards organizations;Cross Platform Development;Deployment and Maintenance;Workflow},
        doi={10.1109/ICSEA.2008.41},
-       ISSN={},
-       month={Oct},
+       month={10},
+}
+
+@book{Sommerville,
+ author = {Sommerville, Ian},
+ title = {Software Engineering},
+ year = {2001},
+ edition = {6th},
+ publisher = {Addison-Wesley Publishing Company},
+ address = {USA},
+}
+
+% static linking
+@Book{johnson1998anwendungen,
+ author = {Johnson, Michael K.},
+ title = {Anwendungen entwickeln unter Linux},
+ publisher = {Addison-Wesley-Longman},
+ year = {1998},
+ address = {Bonn Reading, Mass. u.a},
+ isbn = {9783827314499},
+ lang = {de},
+ sign = {11/00021},
+ gbv = {54.54},
+ rvk = {ST 261 U61},
+ url = {http://www.addison-wesley.de/3827314496.html},
+ thumb = {http://ecx.images-amazon.com/images/I/41QJQ8AKZHL._SS500_.jpg}
+}
+
+% MVC
+@misc{mvc,
+  author = {Reenskaug, Trygve},
+  description = {MVC XEROX PARC 1978-79},
+  keywords = {controller imported model mvc origin original pattern view},
+  title = {Model-View-Controller - Origins},
+  url = {http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html},
+  year = 1979
+}
+
+@book{JavaInsel6,
+  abstract = {Diese 6. Auflage des Java-Kultbuches wurde gründlich überarbeitet, aktualisiert und erweitert. Alle wichtigen Neuerungen zu Java 6 wurden aufgenommen. Besonders Einsteiger mit Programmierkenntnissen und Industrieprogrammierer profitieren von diesem umfassenden Werk. Tipps und Tricks aus den Java-FAQs werden regelmäßig mit in die Insel aufgenommen, um wirklich das abzudecken, was Sie im Alltag brauchen. Die Einführung in die Sprache Java ist anschaulich und immer praxisorientiert. Schnell geht es weiter mit fortgeschrittenen Themen wie Threads, Swing, Netzwerkprogrammierung, Java Beans, RMI, XML und Java, Servlets und Java Server Pages, JDBC und vielem mehr.
+
+CD/DVD Die beiliegende DVD-ROM bietet das vollständige Buch als HTML-Fassung, alle Beispiele und Lösungen, Software und Tools in aktuellen Versionen und eine Sammlung aktueller openbooks zu den Themen UNIX, C und C++.},
+  added-at = {2007-06-17T18:33:45.000+0200},
+  address = {Bonn},
+  author = {Ullenboom, Christian},
+  biburl = {https://www.bibsonomy.org/bibtex/21ddcb167bd21762ae15334d61baf4705/steff83},
+  edition = {6., aktualisierte und erweiterte Auflage},
+  interhash = {d9a05d639567c4f4ece487bd9c04646d},
+  intrahash = {1ddcb167bd21762ae15334d61baf4705},
+  keywords = {ebook java openbook programming web},
+  publisher = {Galileo Computing},
+  timestamp = {2007-08-08T10:39:21.000+0200},
+  title = {Java ist auch eine Insel},
+  url = {http://www.galileocomputing.de/openbook/javainsel6/},
+  year = 2007
+}
+
+
+
+@online{CodeBlocks,
+       url={http://www.codeblocks.org/},
+       title={CodeBlocks Homepage},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@online{wine,
+       url={https://wiki.winehq.org/Wine_User%27s_Guide},
+       title={Wine User Manual},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@online{Git,
+       url={https://git-scm.com/},
+       title={Git Homepage},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@online{texlive,
+       url={https://tug.org/texlive/acquire-netinstall.html},
+       title={Texlive Online Installer},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@online{mingw,
+       url={https://mingw-w64.org/doku.php},
+       title={mingw-w64 Homepage},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@online{gcc,
+       url={https://gcc.gnu.org/},
+       title={GCC Homepage},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@online{doxywin,
+       url={http://www.stack.nl/~dimitri/doxygen/download.html},
+       title={Doxygen Download},
+       year={2018},
+       urldate={2018-07-28}
+}
+
+@image{mvcImage,
+       author={Reenskaug, Trygve},
+       title={MVC XEROX PARC 1978-79},
+       note={Das Diagramm für den ursprünglichen MVC-Vorschlag.},
+       year={1979},
+       url={http://heim.ifi.uio.no/trygver/themes/mvc/mvc-index.html}
+}
+
+% Dyn Linker
+@book{LinuxCert,
+ author = {Pritchard, Steven and Pessanha, Bruno and Langfeldt, Nicolai and Stanger, James and Dean, Jeff},
+ title = {LPI Linux Certification in a Nutshell (In a Nutshell (O'Reilly))},
+ year = {2006},
+ isbn = {0596005288},
+ publisher = {O'Reilly Media, Inc.},
+}
+
+% Latex Grundlage
+@Book{LatexEinfuehrung,
+  Title = {LaTex, Band 1: Einführung},
+  Author = {Kopka, Helmut},
+  Keywords = {FUNDAMENTALS computer science},
+  Publisher = {Addison-Wesley},
+  Year = {2002},
+  month = {3}
+}
+
+% Latex Grundlage
+@Book{LatexFriends,
+  Title = {LaTeX and Friends},
+  Author = {M. R. C. van Dongen},
+  Publisher = {Springer Science \& Business Media},
+  Year = {2012},
+  month = {1}
+}
+
+% Theoretisches über SW Dokumentationen
+@thesis{DokSWDev,
+       author={Janert, Norman},
+       title={Dokumentation im Bereich der Softwareentwicklung},
+       type={Studienarbeit},
+       year={2004},
+       month={2},
+       institution={Institut für Theoretische und Technische Informatik der Technischen Universität Ilmenau},
+       location={Ilmenau, Germany},
+       url={http://www.theoinf.tu-ilmenau.de/~streitdf/TheHome/DA_SA/Data/SA_Janert_Norman.pdf},
+       hyphenation={german}
+}
+
+% ElucidativeProgramming
+@article{ElucidativeProgramming,
+ author = {N{\o}rmark, Kurt},
+ title = {Elucidative Programming},
+ journal = {Nordic J. of Computing},
+ issue_date = {Summer 2000},
+ volume = {7},
+ number = {2},
+ month = jun,
+ year = {2000},
+ issn = {1236-6064},
+ pages = {87--105},
+ numpages = {19},
+ url = {http://dl.acm.org/citation.cfm?id=643359.643362},
+ acmid = {643362},
+ publisher = {Publishing Association Nordic Journal of Computing},
+ address = {Finland},
+ keywords = {WWW program presentation, literate programming, program documentation, programming tools},
+}
+
+% Literate Programming
+@article{LiterateProgramming,
+ author = {Knuth, Donald E.},
+ title = {Literate Programming},
+ journal = {Comput. J.},
+ issue_date = {May 1984},
+ volume = {27},
+ number = {2},
+ month = may,
+ year = {1984},
+ issn = {0010-4620},
+ pages = {97--111},
+ numpages = {15},
+ url = {http://dx.doi.org/10.1093/comjnl/27.2.97},
+ doi = {10.1093/comjnl/27.2.97},
+ acmid = {479},
+ publisher = {Oxford University Press},
+ address = {Oxford, UK},
+}
+
+% Literate Programming
+@article{DebRpm,
+ author = {Kenlon, Seth},
+ title = {RPM vs. DEB},
+ pages = {13--16},
+ year = {2011},
+ numpages = {4},
+ url = {http://seth.kenlon.com/pflocal/TBOL_2011_1_RPM_DEM_US.pdf},
+ publisher = {OXY Press LLC}
+}
+
+%Doxygen
+@manual{DoxyGen,
+       author={Dimitri van Heesch},
+       title={doxygen, Manual for version 1.8.13},
+       year={2016},
+       url={http://doxygen.nl/download.html#latestman},
+       hyphenation={english}
+}
+
+%FLTK
+@manual{fltkMan,
+       author={B. Spitzak, and others},
+       title={FLTK 1.3.4 Programming Manual},
+       year={2016},
+    month={11},
+       hyphenation={english}
+}
+
+%wxWidgets
+@manual{wxWidgetsMan,
+       author={J. Smart, and others},
+       title={wxWidgets 3.0.4 User Manual},
+       year={2018},
+    month={8},
+       hyphenation={english}
+}
+
+@misc{xmlJson,
+  author = "{Nurzhan Nurseitov, Michael Paulson, Randall Reynolds, Clemente Izurieta}",
+  title  = "{Comparison of JSON and XML Data Interchange Formats: A Case Study}",
+  publisher = {Montana State University – Bozeman},
+  address = {Bozeman, Montana, 59715, USA},
+  hyphenation={english}
+}
+
+@manual{python,
+  author = "{Guido van Rossum, and others}",
+  title  = "{Python Frequently Asked Questions}",
+  year={2018},
+  month={7},
+  hyphenation={english}
+}
+
+@misc{observer,
+  author = "{Constantin Szallies}",
+  title  = "{On using the Oberver Design Pattern}",
+  year={1997},
+  month={8},
+  hyphenation={english}
 }
 
 %%% EXAMPLES %%%%
 
 @book{Duden1997,
        author={Friedrich, Christoph},
-       title={Schriftliche Arbeiten im technisch-natur\-wissen\-schaft\-lichen Studium}, 
+       title={Schriftliche Arbeiten im technisch-natur\-wissen\-schaft\-lichen Studium},
        subtitle={Ein Leitfaden zur effektiven Erstellung und zum Einsatz moderner Arbeitsmethoden},
        publisher={Bibliographisches Institut},
        series={Duden Taschenbücher},
 
 @misc{EuRichtlinie2000,
        author={{Europäische Union}},
-       title={Richtline 2000/14/EG des Europäischen Parlaments und des Rates vom 8.\ Mai 2000 zur 
-               Angleichung der Rechtsvorschriften der Mitgliedstaaten über umweltbelastende Geräuschemissionen 
+       title={Richtline 2000/14/EG des Europäischen Parlaments und des Rates vom 8.\ Mai 2000 zur
+               Angleichung der Rechtsvorschriften der Mitgliedstaaten über umweltbelastende Geräuschemissionen
                von zur Verwendung im Freien vorgesehenen Geräten und Maschinen},
        howpublished={Amtsblatt der Europäischen Gemeinschaften, L 162},
        url={http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2000L0014:20051227:de:PDF},
        title={Psycho},
        howpublished={Film},
        year={1960},
-       note={Regie: Alfred Hitchcock, 
+       note={Regie: Alfred Hitchcock,
                Drehbuch: Joseph Stefano.
-               Nach dem Roman von Robert Bloch. 
+               Nach dem Roman von Robert Bloch.
                Mit Anthony Perkins, Vera Miles, Janet Leigh.},
        hyphenation={english}
 }
index f8e6324..0c7b932 100644 (file)
@@ -76,6 +76,7 @@
                        <Option target="&lt;{~None~}&gt;" />
                </Unit>
                <Unit filename="main.tex" />
+               <Unit filename="references.bib" />
                <Extensions>
                        <envvars />
                        <code_completion />
diff --git a/doc/thesis/uml/author.dot b/doc/thesis/uml/author.dot
new file mode 100644 (file)
index 0000000..7a9017e
--- /dev/null
@@ -0,0 +1,5 @@
+digraph doxygraph
+{
+graph [ rankdir="RL" , splines="ortho"]
+"class_author" [ label="Author\n|+Author (  )\l+GetID (  ) : std::string\l+GetName (  ) : std::string\l+GetNum (  ) : unsigned int\l+GetTimeEstimated (  ) : std::string\l+GetTimeSpent (  ) : std::string\l+GetXNameCoordinate (  ) : unsigned int\l+GetXTimeEstimatedCoordinate (  ) : unsigned int\l+GetXTimeSpentCoordinate (  ) : unsigned int\l+GetXid (  ) : unsigned int\l+GetYNameCoordinate (  ) : unsigned int\l+GetYTimeEstimatedCoordinate (  ) : unsigned int\l+GetYTimeSpentCoordinate (  ) : unsigned int\l+GetYid (  ) : unsigned int\l+SetID ( val : const std::string & ) : void\l+SetName ( val : const std::string & ) : void\l+SetNum ( val : unsigned int ) : void\l+SetTimeEstimated ( val : const std::string & ) : void\l+SetTimeSpent ( val : const std::string & ) : void\l+SetXNameCoordinate ( val : unsigned int ) : void\l+SetXTimeEstimatedCoordinate ( val : unsigned int ) : void\l+SetXTimeSpentCoordinate ( val : unsigned int ) : void\l+SetXid ( val : unsigned int ) : void\l+SetYNameCoordinate ( val : unsigned int ) : void\l+SetYTimeEstimatedCoordinate ( val : unsigned int ) : void\l+SetYTimeSpentCoordinate ( val : unsigned int ) : void\l+SetYid ( val : unsigned int ) : void\l+~Author (  ) \{virtual\}\l|-mID : std::string\l-mName : std::string\l-mNum : unsigned int\l-mTimeEstimated : std::string\l-mTimeSpent : std::string\l-mXNameCoordinate : unsigned int\l-mXTimeEstimatedCoordinate : unsigned int\l-mXTimeSpentCoordinate : unsigned int\l-mXid : unsigned int\l-mYNameCoordinate : unsigned int\l-mYTimeEstimatedCoordinate : unsigned int\l-mYTimeSpentCoordinate : unsigned int\l-mYid : unsigned int\l" shape="record" ]
+}
diff --git a/doc/thesis/uml/observer.dot b/doc/thesis/uml/observer.dot
new file mode 100644 (file)
index 0000000..ff8bf11
--- /dev/null
@@ -0,0 +1,14 @@
+digraph doxygraph
+{
+graph [ rankdir="RL" , splines="ortho"]
+"class_model"
+"class_model" [ label="Model\n|" shape="record"]
+"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" -> "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" -> "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" -> "class_observer" [ arrowhead="empty" style="bold,dashed" ]
+}
diff --git a/doc/thesis/uml/simple_factory.dot b/doc/thesis/uml/simple_factory.dot
new file mode 100644 (file)
index 0000000..b31c48f
--- /dev/null
@@ -0,0 +1,15 @@
+digraph doxygraph
+{
+graph [ rankdir="RL" , splines="ortho"]
+"class_chapter_factory" [ label="ChapterFactory\n|+ChapterFactory (  )\l+createChapter ( type : const std::string & ) : ChapterIF::SPtr\l+createChapter ( type : int ) : ChapterIF::SPtr\l+getChapterTypes (  ) : std::vector\< std::string \>\l+~ChapterFactory (  ) \{virtual\}\l|-mChapterTypes : const std::vector\< std::string \>\l" shape="record" ]
+"class_chapter_i_f" [ label="ChapterIF\n«abstract»\n|+GetContent (  ) : std::string\l+GetDone (  ) : bool\l+GetHierachy (  ) : std::string\l+GetHierachyAsNum (  ) : int\l+GetNum (  ) : int\l+GetOutFileName (  ) : std::string\l+GetPrettyName (  ) : std::string\l+GetType (  ) : std::string \{pure-virtual\}\l+SetContent ( text : const std::string & ) : void\l+SetDone ( done : bool ) : void\l+SetHierachy ( val : const std::string & ) : void\l+SetHierachy ( val : unsigned int ) : void\l+SetNum ( val : int ) : void\l+SetOutFileName ( val : const std::string & ) : void\l+SetPrettyName ( val : const std::string & ) : void\l+WriteFile ( model : ModelIF * ) : void \{pure-virtual\}\l+~ChapterIF (  )\l#ChapterIF (  )\l|+mMaxHierachy : unsigned int\l#mContent : std::string\l#mDone : bool\l#mFSHelp : FSHelper\l#mHierachy : std::string\l#mNum : int\l#mOutFileName : std::string\l#mPrettyName : std::string\l" shape="record" ]
+"class_doxygen_chapter" [ label="DoxygenChapter\n|+DoxygenChapter ( type : const std::string & )\l/+GetType (  ) : std::string \{virtual\}\l/+WriteFile ( model : ModelIF * ) : void \{virtual\}\l+~DoxygenChapter (  ) \{virtual\}\l|-mType : std::string\l" shape="record" ]
+"class_doxygen_chapter" -> "class_chapter_i_f" [ arrowhead="empty" style="bold,dashed" ]
+"class_source_chapter" [ label="SourceChapter\n|/+GetType (  ) : std::string \{virtual\}\l+SourceChapter ( type : const std::string & )\l/+WriteFile ( model : ModelIF * ) : void \{virtual\}\l+~SourceChapter (  ) \{virtual\}\l|-mType : std::string\l" shape="record" ]
+"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" ]
+}
index c1e54ae..ba6499d 100644 (file)
        "ControllerIF.h"
        "ModelIF.h"
 
-1531915883 /home/giri/workspace/hsd_doku_tool/src/Controller.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/Controller.h
        <list>
        "ControllerIF.h"
        "Subject.h"
        "Model.h"
 
-1531916039 /home/giri/workspace/hsd_doku_tool/src/ControllerIF.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/ControllerIF.h
        <iostream>
        <memory>
 
-1531916726 /home/giri/workspace/hsd_doku_tool/src/ModelIF.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/ModelIF.h
        <memory>
        "Subject.h"
        "Author.h"
        <fstream>
        <sstream>
 
-1531919573 /home/giri/workspace/hsd_doku_tool/src/Model.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/Model.h
        "ModelIF.h"
        "tinyxml2.h"
        "ChapterIF.h"
        <iostream>
        <cstring>
 
-1531915104 /home/giri/workspace/hsd_doku_tool/src/View.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/View.h
        "ViewFluid.h"
        "Observer.h"
        "ModelIF.h"
        "Subject.h"
        <algorithm>
 
-1531921447 /home/giri/workspace/hsd_doku_tool/src/ViewFluid.h
+1532975315 /home/giri/workspace/hsd_doku_tool/src/ViewFluid.h
        <FL/Fl.H>
        <FL/Fl_Double_Window.H>
        <FL/Fl_Menu_Bar.H>
 1524417896 source:/home/giri/workspace/hsd_doku_tool/src/Chapter.cxx
        "Chapter.h"
 
-1531919398 /home/giri/workspace/hsd_doku_tool/src/Author.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/Author.h
        <iostream>
        "Object.h"
 
        <algorithm>
        <sys/wait.h>
 
-1531920698 /home/giri/workspace/hsd_doku_tool/src/FSHelper.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/FSHelper.h
        <iostream>
        <vector>
        "Object.h"
        "Fl_Valuator.H"
        "Fl_Input.H"
 
-1531918853 /home/giri/workspace/hsd_doku_tool/src/ChapterIF.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/ChapterIF.h
        <iostream>
        <fstream>
        <memory>
        "ModelIF.h"
        "FSHelper.h"
 
-1531919410 /home/giri/workspace/hsd_doku_tool/src/ChapterFactory.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/ChapterFactory.h
        "TextChapter.h"
        "DoxygenChapter.h"
        "SourceChapter.h"
 
-1531919346 /home/giri/workspace/hsd_doku_tool/src/TextChapter.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/TextChapter.h
        <iostream>
        "Object.h"
        "ChapterIF.h"
        <fstream>
 
-1531918885 /home/giri/workspace/hsd_doku_tool/src/DoxygenChapter.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/DoxygenChapter.h
        <iostream>
        "Object.h"
        <algorithm>
 
-1531919321 /home/giri/workspace/hsd_doku_tool/src/SourceChapter.h
+1531921866 /home/giri/workspace/hsd_doku_tool/src/SourceChapter.h
        <iostream>
        "Object.h"
        "ChapterIF.h"