From 8606454ddc9d2bf1eb61d0d3cbe689d7c10c57db Mon Sep 17 00:00:00 2001
From: Paul Buetow <paul@buetow.org>
Date: Wed, 13 Aug 2008 23:44:50 +0000
Subject: update

---
 LaTeX/chapters/implementierung.tex |   87 +-
 LaTeX/diplomarbeit.pdf             | 1558 ++++++++++++++++++------------------
 2 files changed, 817 insertions(+), 828 deletions(-)

diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex
index 90fd713..29e451b 100644
--- a/LaTeX/chapters/implementierung.tex
+++ b/LaTeX/chapters/implementierung.tex
@@ -229,6 +229,8 @@ Die Kapselung eines \textit{VSAbstractEvent}-Objektes in einem \textit{VSTask}-O
 
 Jede Simulation besitzt genau eine Instanz von \textit{VSTaskManager}. Eine Instanz dieser Klasse stellt den Task-Manager dar. Er verwaltet alle \textit{VSTask}-Instanzen und �berpr�ft periodisch, ob es auszuf�hrende Ereignisse gibt. Der Task-Manager unterscheidet zwischen globalen und lokalen Ereignissen. Hierbei werden alle globalen Ereignisse (gekapselt in einem \textit{VSTask}-Objekt) in einer Priorit�ts-Warteschlange (vgl. \cite{Algorithms}, \cite{AlgorithmsC}) abgelegt. Die Priorit�ts-Warteschlange stellt hierbei die korrekte Ereigniseintrittsreihenfolge sicher. Da sich die lokalen Zeiten aller beteiligten Prozesse voneinander unterscheiden k�nnen, muss f�r jeden Prozess eine separate lokale Priorit�ts-Warteschlange verwendet werden, auf die jedes Prozessobjekt seine eigene Referenz hat. In den lokalen Warteschlangen sind die geplanten lokalen Ereignisse (auch gekapselt in einem \textit{VSTask}-Objekt) abgelegt. Der Task-Manager greift �ber eine \textit{java.util.ArrayList} auf alle Prozessobjekte zu und kann somit auch auf alle lokalen Warteschlangen zugreifen und diese verwalten.
 
+Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Prozess verschickt wird. Da \textit{VSMessage} von \textit{VSPrefs} erbt, k�nnen zwischen zwei Prozessen beliebige Datentypen (s. Tabelle \ref{tb:VariablenDatentypen}.) �ber eine Nachricht verschickt werden. Anschlie�end wird f�r jeden Empf�ngerprozess ein neues Ereignisobjekt der Klasse \textit{VSMessageReceiveEvent} angelegt, welches eine Referenz der verschickten Nachricht besitzt (s. Abb. \ref{fig:Wrapping}.). Danach wird ein \textit{VSTask}-Objekt instantiiert, in dem die Referenz auf das Ereignisobjekt und das dazugeh�rige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager �bergeben, der das dazugeh�rige Ereignis ausf�hrt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird hier das \textit{VSMessageReceiveEvent}-Objekt in ein \textit{VSAbstractEvent} umgewandelt und so in \textit{VSTask} abgelegt. 
+
 \begin{figure}[h]
 	\centering
 	\includegraphics[width=10.0cm]{images/core}
@@ -236,7 +238,9 @@ Jede Simulation besitzt genau eine Instanz von \textit{VSTaskManager}. Eine Inst
 	\label{fig:PackageCore}
 \end{figure}
 
-Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Prozess verschickt wird. Da \textit{VSMessage} von \textit{VSPrefs} erbt, k�nnen zwischen zwei Prozessen beliebige Datentypen (s. Tabelle \ref{tb:VariablenDatentypen}.) �ber eine Nachricht verschickt werden. Anschlie�end wird f�r jeden Empf�ngerprozess ein neues Ereignisobjekt der Klasse \textit{VSMessageReceiveEvent} angelegt, welches eine Referenz der verschickten Nachricht besitzt (s. Abb. \ref{fig:Wrapping}.). Danach wird ein \textit{VSTask}-Objekt instantiiert, in dem die Referenz auf das Ereignisobjekt und das dazugeh�rige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager �bergeben, der das dazugeh�rige Ereignis ausf�hrt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird hier das \textit{VSMessageReceiveEvent}-Objekt in ein \textit{VSAbstractEvent} umgewandelt und so in \textit{VSTask} abgelegt. 
+Erw�hnenswert ist auch die Klasse \textit{VSMessageStub}, welche ein \textit{VSMessage} kapselt. Ihr Zweck ist das Verstecken einiger Methoden vor dem Protokoll-API, welches f�r die Erstellung eigener Protokolle dient. Der Protokoll-Entwickler soll m�glichst nichts falsch machen k�nnen und deswegen soll dem Protokoll-API ein eingeschr�nkter Funktionsumfang zur Verf�gung gestellt werden. Da sich \textit{VSMessageStub} im selben Paket wie \textit{VSMessage} befindet, kann \textit{VSMessageStub} auf paket-private Methoden von \textit{VSMessage} zugreifen. Protokolle hingegen werden in einem anderen Paket implementiert und haben somit keinen Zugriff auf diese paket-privaten Methoden. Zwar kann der Protokollentwickler ein eigenes \textit{VSMessageStub}-Objekt anlegen, jedoch kann er auf diese Weise besser unterscheiden, auf welche Methoden er zugreifen sollte, und auf welche nicht. 
+
+Der Task-Manager speichert anschlie�end die Nachrichtenempfangsereignisse in seiner globalen Warteschlange. Die Nachricht kommt bei einem Empf�ngerprozess an, sobald das Ereignis f�r den Empfang eintritt. F�r die korrekte Implementierung der Lamport- und Vektor-Zeitstempel wird jeder Nachricht automatisch eine Referenz auf die Lamport- sowie auf die Vektor-Zeitstempel des sendenden Prozesses als Attribut beigef�gt. F�r die �berpr�fung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert.
 
 \begin{figure}[h]
 	\centering
@@ -245,10 +249,6 @@ Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Pro
 	\label{fig:Wrapping}
 \end{figure}
 
-Erw�hnenswert ist auch die Klasse \textit{VSMessageStub}, welche ein \textit{VSMessage} kapselt. Ihr Zweck ist das Verstecken einiger Methoden vor dem Protokoll-API, welches f�r die Erstellung eigener Protokolle dient. Der Protokoll-Entwickler soll m�glichst nichts falsch machen k�nnen und deswegen soll dem Protokoll-API ein eingeschr�nkter Funktionsumfang zur Verf�gung gestellt werden. Da sich \textit{VSMessageStub} im selben Paket wie \textit{VSMessage} befindet, kann \textit{VSMessageStub} auf paket-private Methoden von \textit{VSMessage} zugreifen. Protokolle hingegen werden in einem anderen Paket implementiert und haben somit keinen Zugriff auf diese paket-privaten Methoden. Zwar kann der Protokollentwickler ein eigenes \textit{VSMessageStub}-Objekt anlegen, jedoch kann er auf diese Weise besser unterscheiden, auf welche Methoden er zugreifen sollte, und auf welche nicht. 
-
-Der Task-Manager speichert anschlie�end die Nachrichtenempfangsereignisse in seiner globalen Warteschlange. Die Nachricht kommt bei einem Empf�ngerprozess an, sobald das Ereignis f�r den Empfang eintritt. F�r die korrekte Implementierung der Lamport- und Vektor-Zeitstempel wird jeder Nachricht automatisch eine Referenz auf die Lamport- sowie auf die Vektor-Zeitstempel des sendenden Prozesses als Attribut beigef�gt. F�r die �berpr�fung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert.
-
 Eine Instanz von \textit{VSInternalProcess} repr�sentiert einen simulierten Prozess. Ein \textit{VSInternalProcess} stellt alle vom Simulator intern verwendeten Methoden zur Verf�gung, w�hrend ein \textit{VSAbstractProcess} lediglich Methoden hat, die der Protokollentwickler f�r die Erstellung eigener Protokolle verwenden darf. Da \textit{VSAbstractProcess} abstrakt ist und hiervon keine Instanz gebildet werden darf, muss f�r einen neuen Prozesses stets ein \textit{VSInternalProcess}-Objekt erstellt werden. Via Polymorphie wird dieses Objekt nach \textit{VSAbstractProcess} umgewandelt und so dem Protokoll-API zur Verf�gung gestellt. Beispielsweise darf mit \textit{getTasks()} nur vom Simulator intern auf die Priorit�ts-Warteschlangen zugegriffen werden, w�hrend man im Protokoll-API selbiges vermeiden sollte und dies auch gar nicht direkt m�glich ist. Hier w�re auch ein Stub-Objekt \textit{VSProcessStub} denkbar gewesen. Da aber fast jede Millisekunde auf die Methoden von \textit{VSInternalProcess} zugegriffen wird, wurde hier aus Performance-Gr�nden der Weg �ber eine Vererbungsstufe preferiert. 
 
 Alle einstellbaren Prozessvariablen werden von der Klasse \textit{VSPrefs} geerbt. Damit bei Neuberechnungen die Variablen nicht dauernd �ber eine \textit{HashMap} von \textit{VSPrefs} zugegriffen werden muss, speichert \textit{VSInternalProcess} aus Performance-Gr�nden einige Variablen als lokale Kopie ab. Zum Beispiel wird f�r die lokale Prozesszeit nicht auf das \textit{HashMap<String,Long>}-Objekt von \textit{VSPrefs}, sondern auf das Klassenattribut \textit{private long localTime} zugegriffen. Vor und nach dem Editieren �ber den Prozesseditor werden die \textit{VSPrefs}, bzw. die lokalen Kopien, auf den neuesten Stand gebracht. Selbiges gilt f�r weitere Variablen, wie z.B. der Uhrabweichung eines Prozesses.
@@ -277,6 +277,8 @@ In diesem Beispiel wurden zwei Ereignisse (Absturz- und Wiederbelebung eines geg
 
 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 Instantiierung von Ereignisobjekten zur�ckgegriffen, da dies vom API automatisch durchgef\"{u}hrt wird.
 
+In Abbildung \ref{fig:PackageProtocols}. sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche f�r die Protokollimplementierungen zust�ndig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verf�gung, die von allen Protokollen verwendet werden k�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 einer Flagge, ob der aktuelle Kontext server- oder clientbezogen ist, und f�hrt dementsprechend beim Eintreffen von Ereignissen die Server- bzw. Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} �berpr�ft auch, ob ein Client oder ein Server �berhaupt aktiviert ist. 
+
 \begin{figure}[h]
 	\centering
 	\includegraphics[width=12cm]{images/protocols}
@@ -284,8 +286,6 @@ In diesem Abschnitt wird auf die Implementierung der Protokolle und das Protokol
 	\label{fig:PackageProtocols}
 \end{figure}
 
-In Abbildung \ref{fig:PackageProtocols}. sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche f�r die Protokollimplementierungen zust�ndig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verf�gung, die von allen Protokollen verwendet werden k�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 einer Flagge, ob der aktuelle Kontext server- oder clientbezogen ist, und f�hrt dementsprechend beim Eintreffen von Ereignissen die Server- bzw. Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} �berpr�ft auch, ob ein Client oder ein Server �berhaupt aktiviert ist. 
-
 \begin{figure}[h]
 	\centering
 	\includegraphics[width=10cm]{images/ss-protokollvariablen}
@@ -534,9 +534,9 @@ Wenn eine Simulatorversion versucht eine abgespeicherte Simulation eines nicht i
 
 \section{GUI sowie Simulationsvisualisierung}
 
-Das Paket \textit{simulator} (s. Abb. \ref{fig:PackageProtocols}.) implementiert die graphische Benutzeroberfl�che des Simulators. Ausnahmen stellen die Editorklassen in \textit{prefs.editors} sowie die Klasse \textit{utils.VSFrame} dar. 
+Das Paket \textit{simulator} (s. Abb. \ref{fig:PackageProtocols}.) enth�lt die Implementierung der graphischen Benutzeroberfl�che des Simulators. Einzigste Ausnahmen sind die Editorklassen in \textit{prefs.editors} sowie die Klasse \textit{utils.VSFrame} dar. 
 
-Beim Starten des Simulators wird auf \textit{main}-Methode, welche sich in \textit{VSMain} befindet, aufgerufen. Sie instantiiert ein \textit{VSDefaultPrefs}-Objekt, worin alle Standardeinstellungen des Simulators abgelegt sind. Anschlie�end wird ein \textit{VSSimulatorFrame} erzeugt, welches ein Simulatorfenster (s. Abb. \ref{fig:NeuesFenster}.) implementiert. Das Simulatorfenster erstellt f�r jede neue Simulation jeweils ein Objekt der Klasse \textit{VSSimulator}, wobei jede Simulation im Simulationsfenster einen eigenen Tab besitzt (s. Abb. \ref{fig:NeuErstellteSimulation}., unten links). Jede Simulation besitzt dabei eine eigene Simulationsnummer. Jedes \textit{VSSimulator}-Objekt greift auf die Klasse \textit{VSSimulatorVisualization} zur�ck, welche die Simulationsvisualisierung (s. Abb. \ref{fig:Visualisierung}.) implementiert. 
+Beim Starten des Simulators wird die \textit{main}-Methode, welche sich in \textit{VSMain} befindet, aufgerufen. Sie instantiiert ein \textit{VSDefaultPrefs}-Objekt, in welchem alle Standardeinstellungen des Simulators definiert sind. Anschlie�end wird ein \textit{VSSimulatorFrame} erzeugt, welches ein Simulatorfenster (s. Abb. \ref{fig:NeuesFenster}.) implementiert. Das Simulatorfenster erstellt f�r jede neue Simulation jeweils  ein Objekt der Klasse \textit{VSSimulator}, wobei jede Simulation im Simulationsfenster einen eigenen Tab besitzt (s. Abb. \ref{fig:NeuErstellteSimulation}., unten links). Jede Simulation besitzt dabei eine eigene Simulationsnummer. Jedes \textit{VSSimulator}-Objekt greift auf die Klasse \textit{VSSimulatorVisualization} zur�ck, welche die Visualisierung der Simulation realisiert (s. Abb. \ref{fig:Visualisierung}.) . 
 
 \begin{figure}[h]
 	\centering
@@ -545,27 +545,27 @@ Beim Starten des Simulators wird auf \textit{main}-Methode, welche sich in \text
 	\label{fig:PackageProtocols}
 \end{figure}
 
-\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D (siehe \cite{Java2d}, \cite{Java2DAPI}, \cite{Games}) zur�ck und ist aus Performance-Gr�nden mit dem Simulationsverlauf stark verzahnt. Klassenattribute, die von Simulationseinstellungen und den Fenstergr\"{o}�en abh�ngigig sind, werden nur wenn es n�tig ist neu berechnet. 
+\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D (siehe \cite{Java2d}, \cite{Java2DAPI}, \cite{Games}) zu und ist zur Optimierung der Performance mit dem Simulationsverlauf stark verzahnt. Klassenattribute, die von Simulationseinstellungen und den Fenstergr\"{o}�en abh�ngigig sind, werden so nur dann neu neu berechnet wenn dies erforderlich ist.
 
-Die Klasse \textit{VSMenuItemStates} wird f�r die Synchronisierung des Simulationsstatusses verwendet. Abh�ngig davon kann der Benutzer bestimmte Aktionen durchf�hren oder nicht. Zum Beispiel kann eine Simulation nur pausiert werden, wenn sie aktuell abgespielt wird. Alle hier m�glichen Aktionen sind bereits aus Kapitel 2.1. bekannt. 
+Die Klasse \textit{VSMenuItemStates} wird f�r die Synchronisierung der graphischen Elemente des GUI's mit dem Status der Simulation verwendet. Abh�ngig vom Simulationsstatus kann der Benutzer bestimmte Aktionen entweder durchf�hren oder nicht. Zum Beispiel kann eine Simulation nur pausiert werden, w�rend sie abgespielt wird. Alle hier m�glichen Aktionen sind bereits aus Kapitel 2.1. bekannt. 
 
-Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereigniseditor (s. Abb. \ref{fig:SidebarMitEreignissen}.) wird in der Klasse \textit{VSSimulator} implementiert. Hinter jeder Ereignisauswahl verbirgt sich ein \textit{VSCreateTask}-Objekt, welches angibt wie das ein Ereignis anzulegen ist.
+Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereigniseditor (s. Abb. \ref{fig:SidebarMitEreignissen}.) wird in der Klasse \textit{VSSimulator} implementiert. Hinter jeder Ereignisauswahl verbirgt sich ein \textit{VSCreateTask}-Objekt, welches vorgibt wie das ein Ereignis anzulegen ist.
 
-Die Klasse \textit{VSLogging} kapselt f\"{u}r das Loggen von Nachrichten ein \textit{JTextArea}-Objekt ein. In dieser Klasse werden alle Logfunktionen implementiert. Die \textit{JTextArea} wird f\"{u}r die Darstellung dem Simulationsobjekt \textit{VSSimulator} \"{u}bergeben. F�r den Logfilter wird auf das Java-Standardpaket \textit{java.util.regex} (s. \cite{Regexp}) zugegriffen, womit anhand von regul�ren Ausdr�cken in Java-Syntax die Logs gefiltert werden k�nnen (s. Kap. 2.2.2. im Abschnitt Logfilter).
+Die Klasse \textit{VSLogging} kapselt f\"{u}r das Loggen von Nachrichten die Attribute eines \textit{JTextArea}-Objektes. In dieser Klasse werden alle Logfunktionen implementiert. Die \textit{JTextArea} wird f\"{u}r die Darstellung dem Simulationsobjekt \textit{VSSimulator} \"{u}bergeben. F�r den Logfilter wird auf das Java-Standardpaket \textit{java.util.regex} (s. \cite{Regexp}) zugegriffen. Dadurch k�nnen anhand von regul�ren Ausdr�cken in Java-Syntax die Logs gefiltert werden (s. Kap. 2.2.2.).
 
 \subsubsection{Threads und Zeitsynchronisierung}
 
-Der Simulator soll auf jede Millisekunde genau simulieren k\"{o}nnen und jede simulierte Sekunde soll dabei relativ zur echten Zeit fortschreiten. Die Simulationsabspielgeschwindigkeit l�sst sich bei den Simulationseinstellungen unter ``Abspielgeschwindigkeit der Simulation'' (Float: \textit{sim.clock.speed}) einstellen (s. Kap. 2.4.2.). Hierf\"{u}r muss folgendes ber�cksichtigt werden:
+Der Simulator soll auf die Millisekunde genau simulieren k\"{o}nnen und dabei soll jede simulierte Sekunde relativ zur echten Zeit fortschreiten. Die Simulationsabspielgeschwindigkeit l�sst sich bei den Simulationseinstellungen unter ``Abspielgeschwindigkeit der Simulation'' (Float: \textit{sim.clock.speed}) einstellen (s. Kap. 2.4.2.). Hierf\"{u}r muss folgendes ber�cksichtigt werden:
 
 \begin{itemize}
-	\item Das Zeichnen der Visualisierung ben�tigt pro Aktualisierung einige Millisekunden. Hier werden st�ndig mathematische Berechnungen (z.B. die Berechnung einer Nachrichtenlinie, die automatische Skalierung des Diagramms, u.s.w.) durchgef\"{u}hrt.
-	\item Das Neuberechnen der Simulation ben�tigt pro Aktualisierung einige Millisekunden. Hier wird insbesondere der Task-Manager beansprucht, welcher �berpr�ft, ob Ereignisse auszuf�hren sind.
-	\item Jeder simulierte Prozess sollte mit der selben Geschwindigkeit fortschreiten, und dies auf jedem Betriebssystem und auf jeder Architektur. Da Java-Threads nicht komplett plattformunabh�ngig sind (Threads sind im Betriebssystem implementiert), k\"{o}nnte das Verhalten auf verschiedenen Betriebssystemen oder Architekturen variieren. Au�erdem �bernimmt das Betriebssystem die Entscheidung, wann welcher Thread arbeiten darf. Au�er man synchronisiert Threads manuell so, dass sie den eigenen Anspr�chen entsprechen. Letzteres bedeutet aber auch mehr Programmieraufwand.
-	\item Die Simulationszeit ist stets in Millisekunden angegeben und sie wird intern in einer \textit{long}-Variable abgespeichert. Somit kann eine Simulationszeit immer nur den Wert einer ganze Zahl betragen. Berechnungsrundungsfehler wegen \textit{sim.clock.speed} (s. Kap. 2.4.2.) m�ssen ber�cksichtigt werden.
-	\item Der Simulator soll nicht st�ndig die komplette CPU des Anwender-Computers voll auslasten.
+	\item Das Zeichnen der Visualisierung ben�tigt pro Aktualisierung einige Millisekunden. Hier werden st�ndig mathematische Berechnungen wie z.B. die Berechnung einer Nachrichtenlinie oder die automatische Skalierung des Diagramms durchgef\"{u}hrt.
+	\item Das Neuberechnen der Simulation ben�tigt pro Aktualisierung einige Millisekunden. Hier arbeitet insbesondere der Task-Manager, welcher �berpr�ft, ob Ereignisse auszuf�hren sind.
+	\item Jeder simulierte Prozess sollte mit der selben Geschwindigkeit fortschreiten, und dies auf jedem Betriebssystem und auf jeder Architektur. Da Threads auf Betriebssystemebene implementiert sind sind Java-Threads nicht komplett plattformunabh�ngig. Dadurch kann das Verhalten auf je nach Betriebssystem und Architekturen variieren. Insbesondere �bernimmt das Betriebssystem die Entscheidung, wann welcher Thread arbeiten darf.
+	\item Die Simulationszeit wird stets in Millisekunden angegeben und sie wird intern in einer \textit{long}-Variable abgespeichert. Somit kann eine Simulationszeit immer nur den Wert einer ganze Zahl betragen. Berechnungsrundungsfehler durch \textit{sim.clock.speed} (s. Kap. 2.4.2.) m�ssen ber�cksichtigt werden.
+	\item Der Simulator soll die komplette CPU des Anwender-Computers nicht konstant auslasten.
 \end{itemize}
 
-Es wurde eine L�sung gew�hlt, bei der lediglich ein einziger Thread f�r die Visualisierung und die Berechnung der Simulation zust�ndig ist. Der Algorithmus verl�uft in leicht vereinfachter Form wie folgt ab:
+Es wurde eine L�sung gew�hlt, bei der lediglich ein einziger Thread f�r die Visualisierung und die Berechnung der Simulation zust�ndig ist. Der Algorithmus verl�uft in vereinfachter Form wie folgt ab:
 
 \begin{enumerate}
 	\item Die aktuelle simulierte globale Zeit sei $t$ und die globale Zeit wo die Simulation endet sei $e$.
@@ -581,13 +581,13 @@ for (i = t; i < t + v + p && i < e; i++)
 	\item Bei Punkt 2 mit neuer Startzeit $t := t + v + p$ weitermachen.
 \end{enumerate}
 
-Zus\"{a}tzlich muss noch die Simulationsvariable \textit{sim.clock.speed} ber\"{u}cksichtigt werden. Sie wurde wegen der �bersicht im obigen Algorithmus nicht ber\"{u}cksichtigt. Intern hat der Simulator jeweils die echte Zeit und die Simulationszeit abgespeichert. Es werden st�ndig die verstrichenen echten Zeiten gemessen und anschlie�end anhand von \textit{sim.clock.speed} die neuen tats�chlichen Simulationszeiten berechnet. Die Rundungsfehler werden pro Durchgang in eine \textit{double}-Variable (Flie�kommazahl doppelter Genauigkeit) abgespeichert. Wenn der Betrag der Rundungsfehler $>= 1$ ist, dann wird davon der ganze Werteanteil in der Simulationszeit ber�cksichtigt. F\"{u}r jede lokale Prozesszeit sowie der dazugeh\"{o}rigen lokalen Uhrabweichung wird \"{a}hnlich verfahren.
+Zus\"{a}tzlich muss noch die Simulationsvariable \textit{sim.clock.speed} ber\"{u}cksichtigt werden. Sie wurde zur verbesserten �bersicht im obigen Algorithmus nicht extra angegeben. Intern speichert der Simulator jeweils die echte Zeit und die Simulationszeit. Die verstrichenen echten Zeiten werden dabei st�ndig gemessen und anschlie�end mit \textit{sim.clock.speed} die neuen tats�chlichen Simulationszeiten berechnet. Die Rundungsfehler werden pro Durchgang in einer \textit{double}-Variable (Flie�kommazahl doppelter Genauigkeit) abgespeichert. Wenn der Betrag der Rundungsfehler $>= 1$ ist, dann wird davon der gesamte Werteanteil in der Simulationszeit ber�cksichtigt. F\"{u}r jede lokale Prozesszeit sowie der dazugeh\"{o}rigen lokalen Uhrabweichung wird \"{a}hnlich verfahren.
 
-Jede Simulation besitzt somit seinen eigenen Simulationsthread. Des Weiteren gibt es noch den Java Swing-Thread (s. \cite{Swing}), der f�r die GUI und somit auch f\"{u}r die Anwenderinteraktion zust�ndig ist. Der Anwender kann zu jedem Zeitpunkt in die Simulation eingreifen, weshalb alle Anwendereingriffe synchronisiert werden. 
+Jede Simulation besitzt somit seinen eigenen Simulationsthread. Des Weiteren gibt es noch den Java Swing-Thread (s. \cite{Swing}), der f�r das GUI und f\"{u}r die Anwenderinteraktion zust�ndig ist. Der Anwender kann zu jedem Zeitpunkt in die Simulation eingreifen, weswegen die Behandlund derAnwendereingriffe synchronisiert wurde.
 
 \section{Serialisierung und Deserialisierung von Simulationen}
 
-Der Anwender kann eine erstellte Simulation im Datei-Men� speichern oder eine bereits abgespeicherte Simulation laden. Hierbei wird von der aus Java angebotenen M�glichkeit Objekte zu Serialisieren Gebrauch gemacht. Im Paket \textit{serialize} (s. Abb. \ref{fig:PackageSerialize}.) befinden sich Helfer, die bei der Serialisierung einer Simulation unterst\"{u}tzend sind. 
+Der Anwender kann eine erstellte Simulation im Datei-Men� speichern oder eine bereits abgespeicherte Simulation laden. Hierbei wird von der aus Java angebotenen M�glichkeit Objekte zu Serialisieren Gebrauch gemacht. Im Paket \textit{serialize} (s. Abb. \ref{fig:PackageSerialize}.) befinden sich Hilfsklassen, die die Serialisierung einer Simulation unterst\"{u}tzen.
 
 Da nicht alle Daten f\"{u}r die Speicherung einer Simulation relevant sind, wird nur eine Auswahl von Klassenattributen serialisiert. Zum Beispiel werden alle Simulationseinstellungen serialisiert, nicht jedoch GUI-Objekte. Alle serialisierbaren Klassen implementieren das Interface \textit{VSSerializable} mit folgenden zwei Methoden:
 
@@ -596,7 +596,7 @@ Da nicht alle Daten f\"{u}r die Speicherung einer Simulation relevant sind, wird
 	\item \textit{public void deserialize(VSSerialize serialize, ObjectInputStream ois)}: Diese Methode wird bei jedem Deserialisierungsvorgang aufgerufen (Laden einer Simulation).
 \end{itemize}
 
-Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einem Dateistream auch ein \textit{VSSerialize}-Objekt als \"{U}bergabeparameter. F�r jeden Serialisierungsvorgang wird zuerst ein Objekt der Klasse \textit{VSSerialize} erstellt. Eine zu serialisierende Simulation besteht aus vielen voneinander abh�ngigen Objekten. Jedes Objekt kann dabei Referenzen auf andere Objekte besitzen. W�rde jedes Objekt komplett serialisiert werden, so w�rden Objekte, auf denen mehrere Referenzen existierten, in mehrfacher Ausf�hrung behandelt werden. Bei Kreisverweisen (Objekt A hat eine Referenz auf Objekt B und Objekt B hat eine Referenz auf Objekt A als Attribut gespeichert) w�rde die Serialisierung sogar in einer Endlosschleife enden. \textit{VSSerialize} hilft hierbei dies zu vermeiden und merkt sich Informationen von allen bereits serialisierten Objekten, so dass jedes Objekt genau einmal serialisiert wird. Bei der Deserialisierung hilft eine Instanz von \textit{VSSerialize} dabei, alle Objekte wieder mit den richtigen Referenzen auszustatten. 
+Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einem Dateistream auch ein \textit{VSSerialize}-Objekt als \"{U}bergabeparameter. F�r jeden Serialisierungsvorgang wird zuerst ein Objekt der Klasse \textit{VSSerialize} erstellt. Eine zu serialisierende Simulation besteht aus einer Vielzahl von einander abh�ngigen Objekten. Jedes Objekt kann dabei Referenzen auf andere Objekte besitzen. W�rde jedes Objekt komplett serialisiert werden, so w�rden Objekte, auf denen mehrere Referenzen existierten, in mehrfacher Ausf�hrung behandelt werden. Bei Kreisverweisen (Objekt A referenziert Objekt B welches ebenfalls eine Referenz auf Objetkt A besitzt)  w�rde die Serialisierung sogar in einer Endlosschleife enden. \textit{VSSerialize} hilft hierbei dies zu vermeiden und merkt sich Informationen von allen bereits serialisierten Objekten, so dass jedes Objekt genau einmal serialisiert wird. Bei der Deserialisierung hilft eine die Klasse \textit{VSSerialize} dabei, alle Objekte wieder mit den richtigen Referenzen auszustatten. 
 
 \begin{figure}[h]
 	\centering
@@ -607,7 +607,7 @@ Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einem Da
 
 Alle Klassen, die \textit{VSSerializePrefs} erweitern, k�nnen komfortabel s�mtliche Einstellungen serialisieren. Beispielsweise speichert der Simulator alle seine globalen Simulationseinstellungen bei einer Serialisierung automatisch ab. Bei den Prozessen und den Ereignissen (und somit auch Protokollen) gilt selbiges analog. 
 
-Abgespeicherte Simulationen sollen auch mit zuk�nftigen Versionen des Simulators kompatibel bleiben. Deshalb werden alle Objekte aller Klassen, die \textit{VSSerializable} implementieren, nicht komplett serialisiert. Bei der Serialisierung werden nur relevante Klassenattribute, die der Simulationsprogrammierung, und nicht beispielsweise GUI-Komponenten angeh�ren, serialisiert. Eine Erweiterung des GUIs muss somit nicht bei den Serialisierungen ber\"{u}cksichtigt werden.
+Abgespeicherte Simulationen sollen auch mit zuk�nftigen Versionen des Simulators kompatibel bleiben. Deshalb werden alle Objekte aller Klassen, die \textit{VSSerializable} implementieren, nicht komplett serialisiert. Bei der Serialisierung werden nur relevante Klassenattribute, die der Simulationsprogrammierung, und nicht z.B. der GUI-Komponenten angeh�ren, serialisiert. Eine Erweiterung des GUIs muss somit nicht bei den Serialisierungen ber\"{u}cksichtigt werden.
 
 \subsubsection{Beispielimplementierung einer \textit{serialize}-Methode}
 
@@ -627,13 +627,12 @@ Der folgende Quelltext-Ausschnitt zeigt eine Beispielimplementierung von \textit
     }
 \end{code}
 
-Vor und nach der eigentlichen Objektserialisierung wird jeweils eine boolesche Flagge mit dem Standardwert \textit{false} serialisiert. Sobald in einer sp\"{a}teren Simulator-Versionen weitere zu serialisierenden Klassenattribute hinzukommen, dann kann bei der Deserialisierung diese Flagge abgefragt und separat behandelt werden. Somit bleiben �ltere bereits abgespeicherte Simulationen stets zur neusten Version des Simulators kompatibel. Wenn eine Flagge auf \textit{true} gesetzt wird, dann kann unter den neuen Attributserialisierungen eine weitere Flagge gesetzt werden, wodurch beliebig viele Erweiterungen in die Serialisierung sukzessiv einbaubar sind.
+Vor und nach der eigentlichen Objektserialisierung wird jeweils eine boolesche Flagge mit dem Standardwert \textit{false} serialisiert. Sobald in einer sp\"{a}teren Simulator-Versionen weitere zu serialisierenden Klassenattribute hinzukommen, dann kann bei der Deserialisierung diese Flagge abgefragt und separat behandelt werden. Somit bleiben �ltere bereits abgespeicherte Simulationen stets zu neueren Version des Simulators kompatibel. Wenn eine Flagge auf \textit{true} gesetzt wird, dann kann unter den neuen Attributserialisierungen eine weitere Flagge gesetzt werden, wodurch beliebig viele Erweiterungen in die Serialisierung sukzessiv einbaubar sind.
 
-Das zu serialisierende Objekt besitzt hier lediglich zwei zu serialisierende Attribute. Mit \textit{serialize.setObject} speichert \textit{serialize} eine Referenz auf das aktuelle Objekt ab, worauf folgende Objektserialisierungen zur�ckgreifen k�nnen. Danach wird ein \textit{process} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung folgt genau in der umgekehrten Reihenfolge, wobei ein Objekt von \textit{VSSerialize} hierbei hilft die Referenzen auf andere Objekte korrekt zu setzen.
+Das zu serialisierende Objekt besitzt hier lediglich zwei zu serialisierende Attribute. Mit \textit{serialize.setObject} speichert \textit{serialize} eine Referenz auf das aktuelle Objekt ab, worauf folgende Objektserialisierungen zur�ckgreifen k�nnen. Danach wird ein \textit{process} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung erfolgt genau in umgekehrter Reihenfolge, wobei ein Objekt von \textit{VSSerialize} hilft die Referenzen auf andere Objekte korrekt zu setzen.
 
 In Abbildung \ref{fig:SequenceSerialize} ist die komplette Sequenz f\"{u}r die Serialisierung (das Abspeichern) einer Simulation angegeben. Zuerst wird \textit{serialize} auf die globalen Simulationseinstellungen (\textit{VSPrefs}) und dem Simulatorobjekt (\textit{VSSimulator}) ausgef�hrt. Das Simulator-Objekt f�hrt \textit{serialize} wiederum auf das \textit{VSSimulatorVisualization}-Objekt aus. Dort wird jeder Prozess inklusive alle Protokollobjekte serialisiert. Anschlie�end folgt der Task-Manager mit allen programmierten Ereignissen. 
 
-
 \section{Helferklassen und Klassen f�r Ausnahmebehandlungen}
 
 Es wurden noch nicht die Klassen der Pakete \textit{utils} (s. Abb. \ref{fig:PackageUtils}.) sowie \textit{exceptions} (s. Abb. \ref{fig:PackageExceptions}.) vorgestellt. \textit{utils} fasst lediglich einige Helferklassen zusammen, die vom restlichen Quelltext verwendet werden.
@@ -646,14 +645,14 @@ Es wurden noch nicht die Klassen der Pakete \textit{utils} (s. Abb. \ref{fig:Pac
 \end{figure}
 
 \begin{itemize}
-	\item \textit{VSFrame}: Alle Objekte, die ein eigenes Swing-Fenster besitzen, erben von der Klasse \textit{VSFrame}. Sie stellt sicher, dass neue Fenster an der richtigen Position der Bildfl�che platziert werden und dass Unterfenster (Fenster, die aus einem anderen Fenster heraus ge�ffnet wurden) automatisch mit geschlossen werden, sobald eines ihrer ``Erzeugerfenster'' geschlossen wird. 
+	\item \textit{VSFrame}: Alle Objekte, die ein eigenes Swing-Fenster besitzen, erben von der Klasse \textit{VSFrame}. Sie stellt sicher, dass neue Fenster an der richtigen Position der Bildfl�che platziert werden und dass Unterfenster (Fenster, die aus einem anderen Fenster heraus ge�ffnet wurden) automatisch mit geschlossen werden, sobald ihr jeweiliges ``Erzeugerfenster'' geschlossen wird. 
 	\item \textit{VSAboutFrame}: Dieses Fenster implementiert die ``About-Anzeige'' die im Simulator �ber das Datei-Men� aufgerufen werden kann.
 	\item \textit{VSInfoArea}: Ist f�r die Textanzeige in \textit{VSAboutFrame} zust�ndig.
-	\item \textit{VSClassLoader}: Diese Klasse wird f�r die automatische Instantiierung von Ereignisobjekten ben�tigt, wenn dem Simulator lediglich die Klassennamen (aus \textit{events.VSRegisteredEvents}) bekannt sind.
-	\item \textit{VSHelper}: In dieser Klasse befinden sich statische Helfermethoden, die in keine andere Klasse passen.
+	\item \textit{VSClassLoader}: Diese Klasse wird f�r die automatische Instanzierung von Ereignisobjekten ben�tigt, wenn dem Simulator lediglich die Klassennamen (aus \textit{events.VSRegisteredEvents}) bekannt sind.
+	\item \textit{VSHelper}: In dieser Klasse befinden sich statische Helfermethoden, die in keine andere Klasse geh�ren.
 	\item \textit{VSPriorityQueue}: Diese Klasse wird f�r das Verwalten von \textit{core.VSTask}-Objekte im Task-Manager ben�tigt. \textit{VSPriorityQueue} passt die Priorit�ts-Warteschlange aus der Java-Standardbibliothek den Anforderungen des Simulators an.
 	\item \textit{VSRandom}: Wird f�r Zufallsereignisse ben�tigt. Jedes Prozessobjekt besitzt einen solchen eigenen Pseudozufallsgenerator. Diese Klasse setzt gleichzeitig einen eigenen Seed basierend auf der lokalen Systemzeit und anderer Berechnungen fest. 
-	\item \textit{VSTupel}: Diese Klasse ist eine Implementierung eines sehr einfach aufgebauten 3-Tupel Datentyps. Alle 3 Elemente k�nnen von einem anderen Typ sein, was mit Hilfe der Java-Generics verwirklicht wurde. \textit{VSTupel} wird von den Editorklassen f�r die Generierung von GUI-Elementen ben�tigt.
+	\item \textit{VSTupel}: Diese Klasse ist eine Implementierung eines einfach aufgebauten 3-Tupel Datentyps. Alle 3 Elemente k�nnen von einem anderen Typ sein, was mit Hilfe der Java-Generics verwirklicht wurde. \textit{VSTupel} wird von den Editorklassen f�r die Generierung von GUI-Elementen ben�tigt.
 \end{itemize}
 
 \begin{figure}[h]
@@ -663,7 +662,7 @@ Es wurden noch nicht die Klassen der Pakete \textit{utils} (s. Abb. \ref{fig:Pac
 	\label{fig:PackageExceptions}
 \end{figure}
 
-Im Paket \textit{exceptions} befinden sich lediglich einige Klassen, die f�r Ausnahmebehandlungen verwendet werden. \textit{VSNotCopyableException} wird w�hrend eines Kopierversuch eines nicht-kopierbaren Ereignisses geworfen. \textit{VSNegatieNumberException} wird geworfen, wenn negative Zahlen dort auftreten, wo sie es nicht sollten. Wenn ein Editorobjekt die Benutzereingabe einer Integer-Vektor-Variable nicht parsen kann, so greifen es auf \textit{VSParseIntegerVectorException} zur�ck. 
+Im Paket \textit{exceptions} befinden sich Klassen, die f�r Ausnahmebehandlungen verwendet werden. \textit{VSNotCopyableException} wird w�hrend eines Kopierversuch eines nicht-kopierbaren Ereignisses geworfen. \textit{VSNegatieNumberException} wird geworfen, wenn negative Zahlen dort auftreten, wo sie es nicht sollten. Wenn ein Editorobjekt die Benutzereingabe einer Integer-Vektor-Variable nicht parsen kann, so greift es auf \textit{VSParseIntegerVectorException} zur�ck. 
 
 \begin{figure}
 	\centering
@@ -676,37 +675,37 @@ Im Paket \textit{exceptions} befinden sich lediglich einige Klassen, die f
 
 \section{Programmierrichtlinien}
 
-Die Programmierrichtlinien entsprechen in den meisten F�llen denen aus \cite{OOS} (siehe auch \cite{Richtlinien}).
+Die Programmierrichtlinien entsprechen idr. denen aus \cite{OOS} (vgl. auch \cite{Richtlinien}).
 
 Die \textit{main}-Methode befindet sich in der Klasse \textit{simulator.VSMain}. 
 \begin{itemize}
 	\item Es wird kein Gebrauch vom Java-Standardpaket gemacht. Alle Klassen befinden sich somit in explizit angegebenen Paketen (z.B. \textit{events.implementations}).
-	\item Alle Klassen- und Interfacenamen beginnen mit gro�en Buchstaben, w�hrend alle Variablen-, Methoden- und Attributnamen mit kleinen Buchstaben beginnen. Namen finaler Variablen und Attribute sind komplett in Gro�buchstaben gehalten.
+	\item Alle Namen von Klassen und Interfaces beginnen mit gro�en Buchstaben, w�hrend alle Variablen-, Methoden- und Attributnamen mit kleinen Buchstaben beginnen. Namen finaler Variablen und Attribute bzw. Konstanten sind komplett in Gro�buchstaben gehalten.
 	\item Alle Quelltext-Dateien besitzen einen Header, der Informationen der verwendeten Lizenz angibt.
-	\item Alle Quelltext-Dateien werden vollst�ndig mit Javadoc dokumentiert. 
+	\item Alle Quelltext-Dateien sind vollst�ndig mit Javadoc dokumentiert. 
 	\item Der komplette Quelltext inklusive Dokumentation wird in englischer Sprache verfasst. 
-	\item Eine Quelltext-Datei hat eine maximale Zeilenl�nge von 80 Zeichen, was der Standardbreite eines UNIX-Terminals entspricht. Eine Ausnahme stellt die Klasse \textit{prefs.VSDefaultPrefs} dar, denn hier befinden sich auch l�ngere Texte die in Strings abgespeichert werden und wo manuelle Zeilenumbr�che wenig Sinn ergeben. 
+	\item Eine Quelltext-Datei hat eine maximale Zeilenl�nge von 80 Zeichen, was der Standardbreite eines UNIX-Terminals entspricht. Eine Ausnahme stellt die Klasse \textit{prefs.VSDefaultPrefs} dar, denn hier befinden sich auch l�ngere Texte die in Strings abgespeichert werden m�ssen.
 	\item Es werden zuerst Klassen aus der Java-Standardbibliothek importiert, bevor Klassen aus dem VS-Simulator selbst importiert werden.
 	\item F�r die Einr�ckung des Quelltextes wird das Tool \textit{astyle} mit den Aufrufparametern \textit{--style=java --mode=java} verwendet. Hierbei wird eine Einr�ckungsl�nge von 4 Zeichen verwendet.
-	\item Namen aller Klassen und Interfaces tragen als Pr�fix stets \textit{VS}, was f�r Verteilte Systeme steht. 
+	\item Namen aller Klassen und Interfaces tragen als Pr�fix stets \textit{VS}. Die Abk�rzung VS steht hierbei f�r Verteilte Systeme.
 	\item Namen abstrakter Klassen tragen als Pr�fix stets \textit{VSAbstract}.
 	\item Namen aller Protokollklassen tragen als Postfix \textit{Protocol} (z.B. \textit{VSPingPongProtocol}).
 	\item Namen aller Ereignisklassen die keine Protokolle implementieren, tragen als Postfix \textit{Event} (z.B. \textit{VSProcessCrashEvent}).
 	\item Namen aller dejenigen Klassen die ein Fenster implementieren, tragen als Postfix \textit{Frame} (z.B. \textit{VSSimulatorFrame}).
-	\item �berall wo es Sinn ergibt werden Java-Generic-Datentypen verwendet (z.B. \textit{java.util.Vector<Integer>} anstelle von \textit{java.util.Vector}).
+	\item �berall wo es erforderlich ist werden Java-Generic-Datentypen verwendet (z.B. \textit{java.util.Vector<Integer>} anstelle von \textit{java.util.Vector}).
 \end{itemize}
 
 \section{Entwicklungsumgebung}
 
-In diesem Teilkapitel soll ein kleiner Einblick in die Umgebung, in der der Simulator entwickelt wurde, gew�hrt werden. F�r diese Diplomarbeit wurde ausschlie�lich Open Source Software verwendet. Die einzige Ausnahme stellt Microsoft Windows XP dar, worauf der Simulator zus�tzlich getestet wurde. Der Simulator wurde jedoch haupts�chlich unter dem Betriebssystem FreeBSD 7.0, was ein Open Source Unix-Derivat ist, programmiert. 
+In diesem Teilkapitel soll ein kleiner Einblick in die Umgebung, in der der Simulator entwickelt wurde, gew�hrt werden. F�r diese Diplomarbeit wurde ausschlie�lich Open Source Software verwendet. Die einzige Ausnahme stellt das Betriebssystem Microsoft Windows XP dar, auf welchem der Simulator zus�tzlich getestet wurde. Der Simulator wurde jedoch haupts�chlich unter dem Betriebssystem FreeBSD 7.0, einem Open Source Unix-Derivat, programmiert. 
 
-Wie bereits bekannt ist, wurde Sun's Java, was mittlerweile auch Open Source Software ist, in der Version 6 (1.6) als die Implementierungssprache gew�hlt und f�r die Quelltextdokumentation kam Javadoc, f�r die automatische Quelltexteinr�ckung astyle und als Java-Referenz kam \cite{Javadoc} zum Einsatz. Als Built-Tool wurde hier auf Apache Ant (s. \cite{AntManual} und \cite{AntIntro}) zur\"{u}ckgegriffen. 
+Wie bereits bekannt ist, wurde die Programmiersprache Java von Sun Microsystems in der Version 6 (1.6) als Implementierungssprache f�r den Simulator gew�hlt. F�r die Quelltextdokumentation wurde Javadoc, f�r die automatische Quelltexteinr�ckung astyle und als Java-Referenz kam \cite{Javadoc} zum Einsatz. Als Built-Tool wurde hier auf Apache Ant (s. \cite{AntManual} und \cite{AntIntro}) zur\"{u}ckgegriffen. 
 
-Als Versionierungssystem wurde SVN (Subversion) verwendet. F�r den Zugriff auf das SVN-Repository mittels HTTPS (Hypertext Transfer Protocol Secure) wurde der Apache-Webserver mit WebDAV-Plugin verwendet. Zudem kam WebSVN als Webschnittstelle des SVN-Repository zum Einsatz. Mozilla Firefox diente f�r das Betrachten der Javadocs und der WebSVN-Oberfl�che.
+Als Versionierungssystem wurde SVN (Subversion) verwendet. F�r den Zugriff auf das SVN-Repository mittels HTTPS (Hypertext Transfer Protocol Secure) wurde der Apache-Webserver mit WebDAV-Plugin verwendet. Zudem kam WebSVN als Webschnittstelle des SVN-Repository zum Einsatz. Mozilla Firefox diente dabei dem Betrachten der Javadocs und dem Bedienen der WebSVN-Oberfl�che.
 
-F�r das Schreiben von Java-Quelltext wurde GVim (Graphical Vi IMproved) sowie Eclipse verwendet. Eclipse unterst�tzt bessere Code-Refactoring-Methoden, w�hrend GVim mit seiner Flexibilit�t und schnelleren Editierm�glichkeiten und mit Vim-Script, der eigenen Script-Engine, gl�nzt. Es wurden au�erdem das JAutoDoc- (f�r die Erstellung von Javadoc-Kommentare) und das Subversion-Eclipse-Plugin verwendet. Je nach Zweck wurde zwischen diesen beiden Umgebungen gewechselt. F�r das Verfassen des LaTeX-Dokumentes wurde GVim verwendet.
+F�r das Schreiben des Java-Quelltextes wurde  Graphical Vi IMproved (GVim) sowie die Entwickungsumgebung Eclipse verwendet. Eclipse bietete bessere Code-Refactoring-Methoden, w�hrend GVim mit seiner Flexibilit�t und schnelleren Editierm�glichkeiten in Verbindung mit seiner Script Engine Vim-Script besonders effektiv ist. Es wurden au�erdem das JAutoDoc zur Erstellung von Javadoc-Kommentaren und f�r die Konnektivit�t mit dem SVN Server das Subversion-Eclipse-Plugin verwendet. Je nach Anforderung wurde zwischen diesen beiden Umgebungen gewechselt. F�r das Verfassen des LaTeX-Dokumentes wurde ebenfalls GVim verwendet.
 
-F�r die Erstellung dieses PDF-Dokumentes wurde LaTeX in Verbindung mit dem Built-Tool GNU Make und Rubber verwendet. Eine Rechtschreib�berpr�fung wurde mit aspell sowie OpenOffice.org durchgef�hrt. xPDF diente als PDF-Anzeigeprogramm.
+F�r die Erstellung dieses PDF-Dokumentes wurde LaTeX in Verbindung mit dem Built-Tool GNU Make und Rubber verwendet. Eine Rechtschreib�berpr�fung wurde mit aspell sowie OpenOffice.org durchgef�hrt. xPDF diente dabei als PDF-Anzeigeprogramm.
 
 S�mtliche UML-Diagramme wurden mit ArgoUML angefertigt und die Screenshots mit The GIMP (GNU Image Manipulation Program) sowie ImageMagick nachbearbeitet. Mit dem zip-Programm wurden alle VS-Simulator Distributionen verpackt.
 
diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf
index 41687b9..52996ce 100644
--- a/LaTeX/diplomarbeit.pdf
+++ b/LaTeX/diplomarbeit.pdf
@@ -1482,8 +1482,8 @@ endobj
 404 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002410Z00'00')
-/ModDate (D:20080814002410Z00'00')
+/CreationDate (D:20080814014212Z00'00')
+/ModDate (D:20080814014212Z00'00')
 >>
 endobj
 405 0 obj
@@ -1576,8 +1576,8 @@ endobj
 414 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002409Z00'00')
-/ModDate (D:20080814002409Z00'00')
+/CreationDate (D:20080814014211Z00'00')
+/ModDate (D:20080814014211Z00'00')
 >>
 endobj
 415 0 obj
@@ -6413,8 +6413,8 @@ endobj
 748 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002409Z00'00')
-/ModDate (D:20080814002409Z00'00')
+/CreationDate (D:20080814014211Z00'00')
+/ModDate (D:20080814014211Z00'00')
 >>
 endobj
 749 0 obj
@@ -6600,8 +6600,8 @@ endobj
 773 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002408Z00'00')
-/ModDate (D:20080814002408Z00'00')
+/CreationDate (D:20080814014210Z00'00')
+/ModDate (D:20080814014210Z00'00')
 >>
 endobj
 774 0 obj
@@ -6719,8 +6719,8 @@ endobj
 787 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002410Z00'00')
-/ModDate (D:20080814002410Z00'00')
+/CreationDate (D:20080814014212Z00'00')
+/ModDate (D:20080814014212Z00'00')
 >>
 endobj
 788 0 obj
@@ -6871,7 +6871,7 @@ endobj
 /Font << /F63 220 0 R /F88 719 0 R /F28 173 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-811 0 obj <<
+810 0 obj <<
 /Length 2539      
 /Filter /FlateDecode
 >>
@@ -6885,13 +6885,13 @@ mC
 �����ƥ7fK��CJi����+�)�Š���D"�3��r �kxG����9�{�-|����-o
����s�ȫ?U;,����	,�е%R���W��.h���Zk�tl*9U�#������&K3��-LK6tp@���M���Y�8��*��Cژ�qV)�4$����8y��y�R��%��@�fI�{}8�*|����Վ�O�c�R'�񱮰:���$��XHbC�hv��,�X^�����rQ�A���3��C��[\��>U�?���n �.mT���o�/����_j��@�{����
���TV[j����xV���R��`=MAdH� ���K-��g��B;0���EM3P8�� �����Y(����a��g��cؕ��=��!�G����+̓�'�q���}��K�2��'|W�N����;��>�آ���m�'W�0*d�r�ǧ�f4�c��
���^(�<�/h<��i˲����Z~�v1_�"��>`����<��$��ϋ��V9K��Җ���'����.����i��W��<��$��Ƀ����V��Ų��YU�:��c�۽�[��C,���7
 �*�L��T�Gƶ�R�0ܣ���Z��
Ԇ:��&�8-����H��TQ(����"p�h�5��jh�i�~NUr�
@���r�Q����~���il��sJ�X��l�?�D�ܦI�I��
F�9TJ��>P�oc�ց2�j���g[xX�#���j���;5��/#���R�[(��~3�[�i`c�
�?7$��vn��|�$_���2<��ul�?e�d
A����cN�i�6=���0N���l�>i	�39�сq�ϑL5���P�����]�j%Tp�z�X`D[�)�q�jvّw���'�����Yv�,B�7�������H�$���rx�v_95\�aGӣ���PN�lV�L={΁P��j�iٕa����.l���!�X�౿�'�	s��z.X�E2��%铿?s�
Ռ��endstream
 endobj
-810 0 obj <<
+809 0 obj <<
 /Type /Page
-/Contents 811 0 R
-/Resources 809 0 R
+/Contents 810 0 R
+/Resources 808 0 R
 /MediaBox [0 0 595.2757 841.8898]
-/Parent 817 0 R
-/Annots [ 813 0 R 814 0 R 815 0 R 816 0 R ]
+/Parent 816 0 R
+/Annots [ 812 0 R 813 0 R 814 0 R 815 0 R ]
 >> endobj
 807 0 obj <<
 /Type /XObject
@@ -6899,123 +6899,126 @@ endobj
 /FormType 1
 /PTEX.FileName (/usr/home/buetow/svn/vs/trunk/LaTeX/images/core-time.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 818 0 R 
+/PTEX.InfoDict 817 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 283.00000000 176.00000000]
 /Resources <<
 /ProcSet [ /PDF /Text ]
 /ExtGState <<
-/R7 819 0 R
->>/Font << /R8 820 0 R >>
+/R7 818 0 R
+>>/Font << /R8 819 0 R >>
 >>
-/Length 821 0 R
+/Length 820 0 R
 /Filter /FlateDecode
 >>
 stream
 x����O�0���+zT�WڵM���p!��a"s����m���l������ڱ�b\��Y���p:�5S����KI'!x�����Y=�O����m챧r:�%+�C�N��t�s��[;��&ە����m��S6�i418�	y��``����NR�g�L�,�,�F����@_
 �45��F��G���e���-��!�q�m�� k��,�?L�p�!S��Ⱦ͂>��r�E�D$��*��"����]�Rq�<���ܕU�R�ky�j��g�e��[����:\�(�v<�<�ve����ྠ͍���� ���-�!���S�;�U���k��	CL��7;W�vɦ���~ӗ�r���o����9^P�i݋a�����
�>�@R�Uz�uܸ�����7endstream
 endobj
-818 0 obj
+817 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002410Z00'00')
-/ModDate (D:20080814002410Z00'00')
+/CreationDate (D:20080814014212Z00'00')
+/ModDate (D:20080814014212Z00'00')
 >>
 endobj
-819 0 obj
+818 0 obj
 <<
 /Type /ExtGState
 /OPM 1
 >>
 endobj
-820 0 obj
+819 0 obj
 <<
 /BaseFont /Helvetica
 /Type /Font
 /Subtype /Type1
 >>
 endobj
-821 0 obj
+820 0 obj
 417
 endobj
-813 0 obj <<
+812 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [213.5029 720.8502 227.9585 731.4325]
 /Subtype /Link
 /A << /S /GoTo /D (figure.4.4) >>
 >> endobj
-814 0 obj <<
+813 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [126.1158 490.6786 140.5714 501.2609]
 /Subtype /Link
 /A << /S /GoTo /D (figure.4.5) >>
 >> endobj
-815 0 obj <<
+814 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 0]
 /Rect [413.7311 244.9899 440.1388 253.761]
 /Subtype /Link
 /A << /S /GoTo /D (cite.Algorithms) >>
 >> endobj
-816 0 obj <<
+815 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 0]
 /Rect [448.6037 244.9899 476.5177 253.761]
 /Subtype /Link
 /A << /S /GoTo /D (cite.AlgorithmsC) >>
 >> endobj
-812 0 obj <<
-/D [810 0 R /XYZ 74.4095 793.4011 null]
+811 0 obj <<
+/D [809 0 R /XYZ 74.4095 793.4011 null]
 >> endobj
 122 0 obj <<
-/D [810 0 R /XYZ 74.4095 771.7323 null]
+/D [809 0 R /XYZ 74.4095 771.7323 null]
 >> endobj
 335 0 obj <<
-/D [810 0 R /XYZ 288.6243 539.3332 null]
+/D [809 0 R /XYZ 288.6243 539.3332 null]
 >> endobj
-809 0 obj <<
+808 0 obj <<
 /Font << /F63 220 0 R /F26 170 0 R /F28 173 0 R >>
 /XObject << /Im35 807 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-827 0 obj <<
-/Length 2100      
+826 0 obj <<
+/Length 2186      
 /Filter /FlateDecode
 >>
 stream
-xڥX�o�6�_�G�Y~S����b��m�z{r��jd9�����f8�-Kʮ���3���o�3���i�yaf�P�b����5��q�+"�"1/�����G�f9+�ճ��ԊI��I�������k��z��.�4�/������[�t����d�f=���OWw�G�Fr�[+/�Qk˴�n���Y��>w��Ӆn�
-X��4�sƙu֨��_�������V����ꗫ�/'ɜ	]� }��)[G6Ke7F��'��Jɣce�wl�;��co�s��eU��yѽ��m�GY�L:9�����g�Pr[���a�yV��%�|�f�C	�:���n*S0)��4vlt�Y.8x]��0�;��$�\,�i'O�{W5~�PFe�Mە�;~��si�]3qAǙ�Z�~���o�r��L��$-drERw��G�2�g���ꨞ6��*�só��U�s������߽�A�A�����Ӧz�8�D�o�~�hy[N�L:�U₫-$���p��t�#{
��s'�=��s;!�@6����^��Wem���>��*�����W���GbX����j������zM����0���\��J8U��Wb��3m4�N���)f�_���s�ҙE��8ADz��ɑJ
X��C�L\�S;��jxED�(���蜔�b��`#�ə�z*/�	-��_A Dp>��4�������*2B��E����i��'����(Z7�`'�^Ϫ�czD��|ܻ��j�T�n��G����Q��u	4q0�Iۯ�]�H��WT�PD�����w���&����i����S�5��6����oq��X ��+��GCZ����G�!e>xl�۪{_���6�I�Qp����pAa�3�����F�hfGF������aa$��I;Ft�mـc�b���p�����P��I�-�+����}�G
V���ŬE�Uh^]UQԳ���Ȫ��+�<�>��-ϑ�li1��:4�
ת|?��:fSZ�=Aq��c�Ź�N������J�\��M
/vQK׵$��g˺��M�x���.
-Y���C�''�	�m�3)����"����ʦ!�Btp�(3��#�s!���dᜲ	��~�k�"S.�w�C��W�*m�M/�T�6)��c@��
y����.J�ڎ��K�p�YZ���+�`��
��]��v!~��S��M(�[MQH�
-�u��Bx:$ϋQ`Aa�/`�t�Ck���I�Ͳ��[˧�

0�����&C��4+_G�*Q;�O�fl��a�(���TV��<OiI���$����q�޿a+����b�c}���Rc�q� �>�V�*����
-�Ü2O��	��e.�)Rפ��AI��R���\2�K�d�Lz)_[�#]���`�;i��;��P��2��I���],��s��Iu$E�Ǫ���w��*�h�$���.����������Ϧ�H�V8J
w���hP��MR&�O6�\�N2.�������R�S{C~cp��l]��#����5�4L-�mKz+ ���@�
,V����ĝ4��}�5r�i�t�@�>��0l�ϯG��
Hծi[������n"O	��>$2�N�H1�\H�w] �M%��,����
-*X�r��-��_�;�Xq/�"��=����s��`
Hc8�W�%� �)@��f��
6����[K�n��e��k.^c���F����շ�Ҳܨ�\����84p�6���F)���`��1�WV�,��@�Eq�e
��`�>�b]`J���#
<�hJ�Ŧ\&	�n[E2���D�=^�<����0���r�!�J�`Q2���"|�
L�G���{s�A��u|�3����҄s���F#����k�
���i@9��,�L�Gg��)U�����$��im��CӅ���V������y�w/�#H����P+��
�~(?@:K��	�~����?.�Fb��������g��i��/a���5�2x���6�BA-��ѐu�[�����B�D���Y��������E?����~���i�"�W6��7�oh��#�endstream
+xڥ]o��=�2������H�����{�u� Ō��,�,����w�Cʲ�l
�3���0b��G,�4��"�,�X<m����?�����j���ǫ�>�j��,����y!�b�(q"���w�K��:[/W2I#͖+�yt���vk�����J��ؔ��<�|u�س5��4��e2��S!e:����X�$��xW5v�RFE�M���~��Ki�]�����pfb-�5���g۶yi	�,Τ�-h��Le���iCj��6��Kãk�U�s�z
+[�8�ޖ@� �C���iS=-%�^<���f���gn&zT₫�T�2!2�X��e�+�}�
�B�����V1�Y����D��M�q�؆>�^+���k)8������+[T���ۼ��k�߸�-a��ǥ��p��c���l&�x�`��2rM�afq(a�e�������A��Q�ɉJ1n�X�Q\�X��PC��"�~T��VTN�]1�]��¤,�z�/�	���vX�!�S>��4����Tb��Gׅ4�e�3
+s���O���� Z7���G�������G����*����-ʄ����s�_�B3��x'+�~:�>��d+���i��OR��D{�9\��%��WW
����@���T�K�a��*���q��c�m��#�a`��M�K�ag�1d��ǐ 
�2c.	�pf5<4�ڨ���?�o�H�q`���N����r�7�Co{�X��2�ٞ<Wr��3)�E�d�/��Ӿ�%G���C]��{-�\�ꪊ������j��j�C9�#�A����q���@�c�a��ci7���7�D��T���jT�(<��KS���(%~�i����;ϥ�Z�^��y���8z���DJ��-�zPa����ۼ���6��?�r�(����!��up������d<#��^GyN�!9����5mQ
+S�7�̛ A���[�`7/R!񠴎�s!5oH�C� �K�v��p�J�v�V_+׍���n�3�.�_.���v�_۝O����m\��zֈBB$c��8�g�5�<�&������qn ���ߛ���Z��
r�����&]��4k[{�.*�;�O�f*��a
+�Y�}�ʊ%<MCE*�"M�h�c]o
+p&��,��*�wH�?�,�Il�/�5@������*^��~�Z�z�̙�Y
+�Q�����2 ����h��%�z��x=j��ª^��G��6V��N]z�c*�G�H�1-��c��u9A���\ߢ�qp���a��*����jVةЩf��u��q�b����
����h�x�D�c����m��o1s�<R���.$.(�n�e'�z�:{NƜߺc1��qr������ԉ�wb^Am?��%S2
"���"��{��a�q�&nt��q��2E%������fԏv���|,���+WT���6�u�X�AT���;��#�������5�u��ZvwڥlX��@L��ؗ�	��H��d�*���,�꼊Pr�k�W����T�=F�%�h����%@E"��V�%��W�T�k!l��̉��@� ʿ�Xہ��
;pL��`k�>�Ә���	�n����0W$?
T���%iQ�J$����H�C8#����=B�: ��h+�n�/2�|�\AK!�x�jK,����q�r`���S�T�4���E%q�,l��G
�s	����_3ΐ6����[K�I�nbo���ᚫ�o���q-������G*2f�Q���D��:����u��#Ɠ����23�֝.ef|�M��Cd�,�Q9X�?�u�.!�� %xѴ
�M^
+�n[y0�����_�4�����rHk��޷�'�<ej�f���y�$��\��$3�n��o�W�9�B�K.an6iM%�F3^�l��z�R@N���Se�,\��<�r��*�i���@&L�x4��ν8�jMl!��$=+��=pyL�>IO����!V�ף��.}��Y0�p����5�� G��ED�'�S8h�H���T���}�ˠ2�Z��"��{A�zW����]�x�X�Y�y`i���ѭF���2�'�[�Y�WSqzP����#w�&�jQ�5mҰ	�����;D��R�Š\���4��{|�O�+�;G
+�:�E�� ϵג�������w�;�����p~endstream
 endobj
-826 0 obj <<
+825 0 obj <<
 /Type /Page
-/Contents 827 0 R
-/Resources 825 0 R
+/Contents 826 0 R
+/Resources 824 0 R
 /MediaBox [0 0 595.2757 841.8898]
-/Parent 817 0 R
-/Annots [ 829 0 R 830 0 R ]
+/Parent 816 0 R
+/Annots [ 828 0 R 829 0 R ]
 >> endobj
-808 0 obj <<
+823 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (/usr/home/buetow/svn/vs/trunk/LaTeX/images/core.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 831 0 R 
+/PTEX.InfoDict 830 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 419.00000000 354.00000000]
 /Resources <<
 /ProcSet [ /PDF /Text ]
 /ExtGState <<
-/R7 832 0 R
->>/Font << /R8 833 0 R /R9 834 0 R >>
+/R7 831 0 R
+>>/Font << /R8 832 0 R /R9 833 0 R >>
 >>
-/Length 835 0 R
+/Length 834 0 R
 /Filter /FlateDecode
 >>
 stream
@@ -7024,88 +7027,85 @@ x
 
'�� 
���So���b2�6˯D$Ň�!|J
�i����p
%|/�O�q�ho
 ���v�C�n���]��ż}��˧�����揕!z�LG\	dA}\��-�ՠ4�Q�R��c��׏W_�G��9��Ü�?������CO'���ȟ��C1��8y]�ş˦���6wEE.,�Ou�脁��D��0��OR+�i�E��I�pN�ɘ��C?��<��B1����
eT��`9���L����L\��E
Y��8�a�
�����}
�_����O���:6��:��я����uj��O���E����%�>L�5���8�i���i��;�GԊ�|��ws��Κ3Rƌl� Q��a���?�`�xE_\靌ؙ�h��1���Q}��™����T1�.���;����Sf�r3^*�|z�����њ
wRX�\!qZ)�# ��v��qb)�)g�2WW��Щ$��X�j4!�j4��wj_,�1;P,�.�z�p�K�w-5v����A�{]qT��E���ZPyػBȩ�e���-�na��r.ʊ��s��ިg@�O�zYT˿�]U����ň����z9n A
&i����,M�@�0�ֱз,�C�����m�X�w�c�����(P�endstream
 endobj
-831 0 obj
+830 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002409Z00'00')
-/ModDate (D:20080814002409Z00'00')
+/CreationDate (D:20080814014211Z00'00')
+/ModDate (D:20080814014211Z00'00')
 >>
 endobj
-832 0 obj
+831 0 obj
 <<
 /Type /ExtGState
 /OPM 1
 >>
 endobj
-833 0 obj
+832 0 obj
 <<
 /BaseFont /Helvetica
 /Type /Font
 /Subtype /Type1
 >>
 endobj
-834 0 obj
+833 0 obj
 <<
 /BaseFont /Helvetica-Oblique
 /Type /Font
 /Subtype /Type1
 >>
 endobj
-835 0 obj
+834 0 obj
 1031
 endobj
-829 0 obj <<
+828 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [419.5946 451.0827 434.0502 461.6649]
+/Rect [419.5946 738.8587 434.0502 749.441]
 /Subtype /Link
 /A << /S /GoTo /D (table.2.2) >>
 >> endobj
-830 0 obj <<
+829 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [464.8944 415.2282 479.3499 425.8105]
+/Rect [464.8944 703.0042 479.3499 713.5865]
 /Subtype /Link
 /A << /S /GoTo /D (figure.4.6) >>
 >> endobj
-828 0 obj <<
-/D [826 0 R /XYZ 74.4095 793.4011 null]
+827 0 obj <<
+/D [825 0 R /XYZ 74.4095 793.4011 null]
 >> endobj
 336 0 obj <<
-/D [826 0 R /XYZ 298.272 522.2791 null]
+/D [825 0 R /XYZ 298.272 352.2293 null]
 >> endobj
-825 0 obj <<
+824 0 obj <<
 /Font << /F63 220 0 R /F28 173 0 R >>
-/XObject << /Im36 808 0 R >>
+/XObject << /Im36 823 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
 838 0 obj <<
-/Length 2328      
+/Length 2247      
 /Filter /FlateDecode
 >>
 stream
-xڥYm�۶�~�B���[��{|q��'wufR�$�(����Toz���X�"%^l��8���]�>��W���D1ųh�da���W|U����7t�/��J������X�R�űZ�?���LD2<mz��3x��`��F$i��zq�և�ԦJӭ7a�b����_�܏�F��4����T�T'��Y��T�K�	�B��M�F,��B�?V�%*�2+5m���b7��m-�՛�ꗫ�/�`�T
-GW�ђ�*�J���r�L�8�
-:��:ʍb��W�uȃmY��;�ݘ��܍��,M�\M��e���.���.oͣ>���~*a���P�x����.��l�(d\��I���faȲH����ٙ��k�~�aa��+�y�U����l�s�����g����Lbf��X���1}�(cJ�/�֋E�])au?Av@��PoJ�
��w{ʛr�h�q-x�ֵ�nMI��lLMc7����iS`�I���/��n�iU�nu��`�{��LY4�����9�88b
;k�I�����08;�W� /m$��6a�2���dM�����R-C����QׇڊÆ��MN����[�m~7���> *��S���g3nv�c�ǡ��P��=
�si���m:�</�����5�\[��[��'/q�fɊu�
-�D�62Mn����{���i����g�>?4�S{�^�k�'�Fa�	ܰ5�fn��6:\�@�+�4@���+�*7�v�{�N�Я�l����#^m���U�l]���<����O�������ee��0���I���*θt���ҷM?h�y۱�6�zBԏ�u�V�(ht��0/�@&�7hYgбJ�>P?:㱡f�	��Q�f�4��
[��6�L�I��iqZUNE]Uf�&���P�#!�Is�m�f��8D�x>�?�h�ѽBȓ� ���6���cG�B�6��5�?�G���9�͢;�4W�T�^m{H8Z��B�p�U��ˢ*m�����z�v��8��TN5�;��y�BH<�;�<V$�'@���t�RDaӽ�+�[�ع����,�1��^�`*�ɷ{-��V�q
�l��O$�<f�ށ��~����t��祝��~c�����0ȫ�0"F]���������ށ��7������'�3�c�����Гq���o�D�d�9�sPu��s�9:��
-¡�9���
|,55>�#��ԭc{`�����1g����})ǀwejb�WG�$Ǝu��>2�o
-ek-ig<)�T�o�o�Tؼ�pWN�q'4
-�ú�Q��)�Ci��ȱ�x2��Ru9,�C&Xp�3�0��:ut������;����_{cԩ�q�v�!V�C,A]m�WT�[O�=��E�����30�m�[�Z��H�'���)P���)7{�?L�4��5��I�5�.]�e[Șzp�f��M��{X���G
-2��M
-�h��5DR�aUgC^q8Ⓦc��8`Ũ��+�1��Z@�0��m�
���g�a|�\DgQ$O	�.D
-p�8#<��N�bB�z��8
-o��T����3I��,aB�yF�/�
-��܊P��_ؠ�U�Tq�e>��	x�}3(�L�������ǮI��c�Uv5�*�S�B���к����l�ZlK&yEX�=C_b����͞���r�g\���C�go����6	:�!�^���>%�"��-W� �~%�i����ݎ�
��IN�$n6�[�X�P��R�*��XN��<,���Z�`�Hbd"���+���9��nO0H�c�*}��Ps ��W�q��{m	�>���룏��FN�;���2b)�����{}XBr�p�h�'��(�ɗ�A�e����ϩ?����3i1G%�o�ld�����!���}]��`���t�8g�ĸ�ju��ê�Jׅ%ʒ]��~����;����F�	�h�8�L��~��?�}�)�j���2�Ύ�ÈpT��O|x���6��ܝ)��?�oc���cN%,�\|9�K�ԇ�5m۷M>%�q�>9�{�닏K	%��(��@��rدj��ak����6��e�9���+lBm$U"�����2M;w���p7�^���
-5$4}#��'g��t�l
K�(@�/Ã���:�Qn5*S��uJ�ya)�����=p���=�zz�	dF[G�<���[�Cw��Y҅������� ���r�_�J��R��5θ�(a�{�a�������4����7�����cn��^|�?�L���g^�P/�z5�^�W�?9��<���endstream
+xڥks�6��>J3
+ H�t:�L�4MӦ��δ�H�)����yο�v�EJT�܍��]`�8�q��f�b�g�,�$�h��^�Y
{��o�a�
x9�~u��wZ�R�i�f�3�$�������ߚ}��j�I:Wl��9����+��uW�f�����.��pu{�_�R�����C�)�
�=�qƒ$��Dž��]����.�R�iaG�s\@��v�����nIK�:���E��pڮY�aˮ��v�2������O�?�'���E�z�њ9t����v��[֖0�	74�~F���Q�2�2�x4�K�qJ-�� �q��XDsR�I�� [����ov�x�m�a���n�γ�B�:�_ٲ�e�����w8k�MDQ4�bX�f9�Y:��
b<8E	�<y0z��������􀓲���O��k怊��=����um�H���K?Y��
	�pW_&Ƭ
+��-�d��ة3�ՙbq���/�0)DRIc�f�B���3��ř��a���/|�f+�ٷ��_�f����eR��R ��r�3���bZ�d�T�b"��=\�ʼY��Ve��>]���_�r\�4�r6�䌖�Z�OCZ^�G�om�
n?	z*a�Rp
B~�{Fo
+8:;�B{�r;qV�,�g�j׶��B�C�ҧ�&Ώ�b���G_����{*/s�y6)�3��D�(����gJ�}nP���aWɌ��օ3A����@$s�㮞���H@zSw��ym*p�5lB2����أ5�Rm��ot3�ך�-(�P� �#��
?���L)4�L�I��Qq��<����PLΌ@S��b!�I�.�`:��"������4�SlCq
+B8�	��l���a�|h�RBC�\���P��F9���8X
W"��q�j!��f�]�F���e���eQ�.���6�����.�E���)�F�8�I<�k�<V��>!p�~�8�PQ���1>��N�\�M�9��fBj���2�r�E�<��q(&��FPc��I�l}�s����|�<@��/ݶc���0
+�q�v}�E�!�nn ��״BV��d�;�!a���A
+���<���I��D&�=Q
�LCP���BW%�ش|�]J�����Q�>���1��;�~�q�HT���8�QC�2�cb�0���2��ö�K<7`��*p���:"�LE<e�
+˛�o@�*���Z�jȉ����-�}i�Z�}Eբ�Ɍ�Am�nJ2a����_D@�iۏ<��M��A��3POr��nrb�i�����VW�*TY�����ٵ޺�"�b옿/𨐋�%�LMEe*@��-��u~�h�pi4���5���wJm�5Ъ,�hi�G5��֖y��4�p|��!���@I
M�/5݊k�j��+W|�Z�؏{����iZo�%��1*��]wX-����b8�cyt �4�8a)P�褷����xR�A�:��U���kVDr<w�2�g�oY„<I��ʪ��b�HS�/Pv�,x̉�|���T
���8(�L���e���1�]UO�&��s�#��������[���v�ڵu.e�T����=�#�.�ww�osv|����:���.ڶ;��oBM<��24V�1%b�ȍK�J�t�X��*��O4�j@��r�'�>��ı�P�pN�-�Q����S��xx,-BpN$�21���
+	+i��=��zCa���#���B�
c[�E���u)��an��rZ9jM�c�t%���o��7���OEr����4�5O^�_֗��i�>�X��5-���I�Ѓ}y��(%���P���<��-!]R)�'D�v���o1k�����r�.N�8li�;ͨ���B%��y8�xz2t.�R	p�0�M)��a��vB�1�0"��w��
+ڝwu�̈́�3f��O��vW]�9���s��	��i0�k:������虓�9�⟧�٣۔CA�%�Q������p^��
GkSݗ[;izq��v����A)�,J%*`�U�n���ۻ�Klܭ/����
�4�>g#��%�D,�2(
��Q�����Y�����*�'��W��.��h8SA�yҷ:DAmPKM��P�'(؀��W�W7�ҝ+�\х�{C����;+!�XZ�v�k¤�b�zf�p�_Dv��m���?v���^�ۊ�dܿ�7���i�=���?N�'^�2
�.��R��ſ9�����a��endstream
 endobj
 837 0 obj <<
 /Type /Page
 /Contents 838 0 R
 /Resources 836 0 R
 /MediaBox [0 0 595.2757 841.8898]
-/Parent 817 0 R
+/Parent 816 0 R
 >> endobj
-824 0 obj <<
+835 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
@@ -7131,8 +7131,8 @@ endobj
 840 0 obj
 <<
 /Producer (GPL Ghostscript 8.61)
-/CreationDate (D:20080814002410Z00'00')
-/ModDate (D:20080814002410Z00'00')
+/CreationDate (D:20080814014212Z00'00')
+/ModDate (D:20080814014212Z00'00')
 >>
 endobj
 841 0 obj
@@ -7155,14 +7155,14 @@ endobj
 /D [837 0 R /XYZ 74.4095 793.4011 null]
 >> endobj
 337 0 obj <<
-/D [837 0 R /XYZ 206.8833 575.8724 null]
+/D [837 0 R /XYZ 206.8833 498.7269 null]
 >> endobj
 836 0 obj <<
 /Font << /F63 220 0 R /F28 173 0 R >>
-/XObject << /Im37 824 0 R >>
+/XObject << /Im37 835 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-847 0 obj <<
+846 0 obj <<
 /Length 2211      
 /Filter /FlateDecode
 >>
@@ -7181,62 +7181,53 @@ T*
 ��eg,\S�z�.3�C�T���Ƣ3;����ۇ��=��t��?1��9ec��
 �+H�y�gmGt8
���q�M5�x)!�E֨q���qc'��XE��D�F�1D��||7�[� ;<�j[9��xx�G����$((Lx����o���D�a���?h9򷑼��P��1~2ݥ#�w)
��܅��[,����S9�0����Q��֏Ki���´���/�,���U+�
�X���y�*[j�:��
|�}��JJ���b���р$�t����h���^x���
4��'endstream
 endobj
-846 0 obj <<
+845 0 obj <<
 /Type /Page
-/Contents 847 0 R
-/Resources 845 0 R
+/Contents 846 0 R
+/Resources 844 0 R
 /MediaBox [0 0 595.2757 841.8898]
-/Parent 817 0 R
-/Annots [ 850 0 R ]
+/Parent 816 0 R
+/Annots [ 849 0 R ]
 >> endobj
-850 0 obj <<
+849 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [128.9946 243.1787 143.4501 253.761]
 /Subtype /Link
 /A << /S /GoTo /D (figure.4.9) >>
 >> endobj
-848 0 obj <<
-/D [846 0 R /XYZ 74.4095 793.4011 null]
+847 0 obj <<
+/D [845 0 R /XYZ 74.4095 793.4011 null]
 >> endobj
-849 0 obj <<
-/D [846 0 R /XYZ 74.4095 750.7482 null]
+848 0 obj <<
+/D [845 0 R /XYZ 74.4095 750.7482 null]
 >> endobj
 126 0 obj <<
-/D [846 0 R /XYZ 74.4095 375.5382 null]
+/D [845 0 R /XYZ 74.4095 375.5382 null]
 >> endobj
-845 0 obj <<
+844 0 obj <<
 /Font << /F63 220 0 R /F26 170 0 R /F28 173 0 R /F88 719 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
 854 0 obj <<
-/Length 1938      
+/Length 1945      
 /Filter /FlateDecode
 >>
 stream
-xڭXAs�6��W�(�<�$EJT��lҝ�әt�y��׃36Yr-��ɯ_� eɖ�w���	�|��q��\1�=ˋB̞�W|�ٿ��"�.��b�}�t��OY:3��25{z�I�2�Sq��i���r�:[�27�b��<���*��u��~�:9����O?_�=�f���d��>�ʘ�Y>[H����C�~˔	Ud�#3Z�-g�8�%�
-�5���~q���~���ms����^Xhf���1TFO�z沔)K�FZJ����q�fר׫a\��s����V�ݜ�xFi4�E�φF�}�Z��r��r[����\�|�K��=9� $Z�e�}�5�M��

�����`�0٤��'(r�L
#��BO��2bK���!��2�����f�PM�I�+�]�wt�Yۚ�]�}�Q��"�W4~���j+!0)�<����>o,�diݖFw�����e�B���%�
-w{�ֵk�(]9K������~�~�g<a��/���.0����Y!�����1qW�de!��,�L��iSU-	˃��M�X���$}�^���Z>w!�nu#�܄e�e8�n�_/]4���B�5K��.�L�BJ�P|��6�aV�����W&�4��B�P�%���s�(��\��;�&G92H/$��K�Z�5��Ve�G���QdoҾr]��i���r���sUW.q�
-3�ʛr����,�k[3��-'2��(�0�2IZ�j��\J���P@h��	e�0l�Q�nb(\*����[�M���B�?�]�ֳ��ˮ�q��ޕG�[�������%��z����5?��
-;+��{��a�yC0��[(
uV�t\
-�>^��b