written

3 files changed, 24 insertions, 3 deletions

diff --git a/LaTeX/chapters/appendix-a.tex b/LaTeX/chapters/appendix-a.tex
index 341258b..d386b3d 100644
--- a/LaTeX/chapters/appendix-a.tex
+++ b/LaTeX/chapters/appendix-a.tex
@@ -1,4 +1,5 @@
-\chapter{Akronyms}

+\chapter{Akronyme}

+

 \begin{acronym}

 \acro{API}{Application Programming Interface}

 \acro{BSD}{Berkeley Software Distribution}

diff --git a/LaTeX/chapters/conclusion.tex b/LaTeX/chapters/conclusion.tex
index 86656fd..6854d44 100644
--- a/LaTeX/chapters/conclusion.tex
+++ b/LaTeX/chapters/conclusion.tex
@@ -1,2 +1,20 @@
 \chapter{Ausblick}

 

+Es wurde erfolgreich ein Simulator f\"{u}r die Simulation verteilter Systeme entwickelt. Der Simulatur hat bereits 10 implementierte Protokolle zur Auswahl eingebaut. Zudem steht dem Gebraucher ein sehr komfortables Protokoll-API zur Verf\"{u}gung, womit der Entwicklung neuer Protokolle quasi keine Grenzen gesetzt sind.

+

+Dar\"{u}ber hinaus verf\"{u}gt der Simulator \"{u}ber eine Vielzahl von sehr flexiblen Einstellungsm\"{o}glichkeiten. F\"{u}r jede Simulation lassen sich somit komplett andere Konfigurationen verwenden. Jeder beteiligte Prozess hat wiederum eingene lokale Einstellungen, wo sich auch jedes Protokoll f\"{u}r jeden Prozess separat einstellen l\"{a}ßt. Die Anzahl und Flexibilit\"{a}t der M\"{o}glichen Szenarien wird dadurch um einen sehr großen Faktor vergr\"{o}ßert.

+

+Mit dem Ereigniseditor gibt es eine komfortable M\"{o}glichkeit eigene Szenarien zu programmieren und zu Simulieren. Hierbei kann entweder auf die bereits enthaltenen Protokolle- oder auf selbst implementierte Protokolle zugegriffen werden. Alle Dazugeh\"{o}rigen Einstellungen und programmierten Ereignisse lassen sich vom Gebraucher f\"{u}r eine sp\"{a}tere Wiederverwendung platformunabh\"{a}ngig abspeichern. Somit k\"{o}nnen auch abgespeicherte Szenarien beispielsweise an Komilitonen weitergegeben werden oder f\"{u}r eine sp\"{a}tere Pr\"{a}sentierung zwischengespeichert werden. Mit dem Loggfilter lassen sich mithilfe von regul\"{a}ren Ausdr\"{u}cken nur die relevanten Loggnachrichten anzeigen, was die Analyse einer Simulation erheblich vereinfacht. Weitere Funktionalit\"{a}ten wie Lamport- und Vektor-Zeitstempel sowie Anti-Aliasing ruden den Simulator ab. 

+

+Durch den objektorientierten Aufbau ist der Simulator relativ einfach erweiterbar, was nicht nur f\"{u}r das Protokoll-API betrifft. H\"{a}tte f\"{u}r diese Diplomarbeit noch mehr Zeit zur Verf\"{u}gung gestanden, dann k\"{o}nnten einige der folgenden Funktionen (hier in alphanumerisch sortierten Reihenfolge aufgelistet) auch eingebaut worden sein:

+

+\begin{itemize}

+	\setlength{\itemsep}{-2mm}

+	\item Die Simulationsdauer beliebig lang machen k\"{o}nnen. Dazu m\"{u}sste \textit{VSSimulatorVisualisation} entlang der Zeitachse scrollbar gemacht werden, sodass der Benutzer f\"{u}r eine nachtr\"{a}gliche Betrachtung des Simulationsverlaufes zu jeder beliebigen Position zur\"{u}ckspringen kann.

+	\item Eine Zoomfunktion f\"{u}r die Simulationsvisualisierung.

+	\item Im Ereigniseditor selbst auch periodische Ereignisse programmierbar machen. Bisher kann nur jedes Ereignis separat programmiert werden oder auf Protokoll-Interne Wecker zur\"{u}ckgegriffen werden.

+	\item Lamport- und Vektor-Zeitstempel f\"{u}r Ereigniseintrittskriterien verwenden.

+	\item Weitere Funktionalit\"{a}ten wie zum Beispiel das Anklicken einer Nachrichtenlinie, was zu einer Nachicht alle verf\"{u}gbaren Informationen anzeigt und diese gegebenenfalls vom Benutzer editiert werden k\"{o}nnen.

+\end{itemize}

+

+Da der Simulator h\"{o}chstwahrscheinlich unter einer Open Source Lizenz freigegeben wird, und ich mich selbst sehr f\"{u}r die Entwicklung und Anwendung von Open Source Software interessiere, werden die einen oder anderen Funktionen nachtr\"{a}glich eingebaut werden. Komilitonen werden auch herzlich dazu eingeladen werden sich an diesem Software-Projekt zu beteiligen. Als Vorbild sei hier der CPU-Simulator M32, der von Prof. Ossmann an der Fachhochschule Aachen entwickelt wurde, genannt. Hier existieren bereits einige Erweiterungen Verbesserungen, die von den Studenten angefertigt wurden. F\"{u}r die Entwicklung/Erweiterung wurde keine properit\"{a}re Software verwendet, sodass jeder kostenlosen Zugriff auf die dazugeh\"{o}rigen Tools h\"{a}tte.

diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex
index 1350f45..dafe28b 100644
--- a/LaTeX/chapters/implementierung.tex
+++ b/LaTeX/chapters/implementierung.tex
@@ -190,7 +190,7 @@ Jede Ereiginsklasse hat zudem Zugriff auf folgende Attribute, die von \textit{VS
 

 \subsection{Beispielimplementierung eines Ereignisses}

 

-Im Folgenden wird als Beispiel die Implementierung des Prozessabsturzereignisses \textit{VSProcessCrashEvent} behandelt. Da die dazugeh\"{o}rige Klasse keine Attribute besitzt, verbleibt hier auch die \textit{initCopy}-Methode mit leerem Rumpf. Jede Ereignisklasse muss in \textit{onInit()} mit \textit{setClassname} den eigenen Klassennamen mitteilen TODO. In \textit{onStart()} wird das eigentliche Ereignis ausgef\"{u}hrt. Hier wird obligatorisch \"{u}berpr\"{u}ft, ob der Prozess bereits abgest\"{u}rzt (hier eigentlich nicht Notwendig, verbessert aber die Lesbarkeit der Logik) ist und gegebenenfalls wird der Prozess dann zum Absturz bewegt. Der Task-Manager \"{u}berpr\"{u}ft bereits, ob der Prozess abgest\"{u}rzt ist oder nicht, d.h. ein Ereignis wird bei einem abgest\"{u}rztem Prozess gar nicht erst ausgef\"{u}hrt. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches vom Task-Manager ausgef\"{u}hrt wird, auch wenn der Prozess abgest\"{u}rzt ist. Mit \textit{logg} wird eine Nachricht in das Loggfenster geschrieben, welche ueber das \textit{VSPrefs}-Objekt \textit{prefs} bezogen wird:

+Im Folgenden wird als Beispiel die Implementierung des Prozessabsturzereignisses \textit{VSProcessCrashEvent} behandelt. Da die dazugeh\"{o}rige Klasse keine Attribute besitzt, verbleibt hier auch die \textit{initCopy}-Methode mit leerem Rumpf. Jede Ereignisklasse muss in \textit{onInit()} mit \textit{setClassname} den eigenen Klassennamen mitteilen. In \textit{onStart()} wird das eigentliche Ereignis ausgef\"{u}hrt. Hier wird obligatorisch \"{u}berpr\"{u}ft, ob der Prozess bereits abgest\"{u}rzt (hier eigentlich nicht Notwendig, verbessert aber die Lesbarkeit der Logik) ist und gegebenenfalls wird der Prozess dann zum Absturz bewegt. Der Task-Manager \"{u}berpr\"{u}ft bereits, ob der Prozess abgest\"{u}rzt ist oder nicht, d.h. ein Ereignis wird bei einem abgest\"{u}rztem Prozess gar nicht erst ausgef\"{u}hrt. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches vom Task-Manager ausgef\"{u}hrt wird, auch wenn der Prozess abgest\"{u}rzt ist. Mit \textit{logg} wird eine Nachricht in das Loggfenster geschrieben, welche ueber das \textit{VSPrefs}-Objekt \textit{prefs} bezogen wird:

 \begin{code}

 package events.implementations;

 

@@ -281,7 +281,9 @@ In diesem Beispiel wurden zwei Ereignisse (Absturz- und Wiederbelebung eines geg
 	\label{fig:PackageProtocols}

 \end{figure}

 

-In diesem Abschnitt wird auf die Implementierung der Protokolle eingegangen. Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche f\"{u}r die Protokollimplementierungen zust\"{a}ndig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verf\"{u}gung, die von allen Protokollen verwendet werden k\"{o}nnen. Jedes Protokoll hat im Paket \textit{protocols.implementations} seine eigene Klasse, die von \textit{VSAbstractProtocol} erbt. Im Prinzip besitzt jedes Prozessobjekt von jedem Protokoll seine eigene Instanz. Bei \textit{10} Protokollen und \textit{3} beteiligten Prozessen werden also \textit{30} Protokollobjekte verwendet. Jedes Protokollobjekt verwaltet sowohl die Server- als auch die Clientseite eines Protokolls auf einmal. Dabei merkt sich \textit{VSAbstractProtocol} anhand eines Flags ob der aktuelle Kontext server- oder clientbezogen ist und f\"{u}hrt dementsprechen beim Eintreffen von Ereignissen die Server- beziehungsweise Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} \"{u}berpr\"{u}ft auch, ob Client oder Server \"{u}berhaupt aktiviert ist. Nur wenn der Server oder Client aktiviert ist, reagiert der Server beziehungsweise der Cleint wenn f\"{u}r sie ein Ereignis eintritt.

+In diesem Abschnitt wird auf die Implementierung der Protokolle und das Protokoll-API eingegangen. Im Protokoll-API wird in der Regel nicht direkt auf den Task-Manager und auf die explizite instanzierung von Ereignisobjekten zur\"{u}ckgegriffen. Das wird alles vom API automatisch gemacht.

+

+Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche f\"{u}r die Protokollimplementierungen zust\"{a}ndig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verf\"{u}gung, die von allen Protokollen verwendet werden k\"{o}nnen. Jedes Protokoll hat im Paket \textit{protocols.implementations} seine eigene Klasse, die von \textit{VSAbstractProtocol} erbt. Im Prinzip besitzt jedes Prozessobjekt von jedem Protokoll seine eigene Instanz. Bei \textit{10} Protokollen und \textit{3} beteiligten Prozessen werden also \textit{30} Protokollobjekte verwendet. Jedes Protokollobjekt verwaltet sowohl die Server- als auch die Clientseite eines Protokolls auf einmal. Dabei merkt sich \textit{VSAbstractProtocol} anhand eines Flags ob der aktuelle Kontext server- oder clientbezogen ist und f\"{u}hrt dementsprechen beim Eintreffen von Ereignissen die Server- beziehungsweise Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} \"{u}berpr\"{u}ft auch, ob Client oder Server \"{u}berhaupt aktiviert ist. Nur wenn der Server oder Client aktiviert ist, reagiert der Server beziehungsweise der Cleint wenn f\"{u}r sie ein Ereignis eintritt.

 

 \begin{figure}[h]

 	\centering