summaryrefslogtreecommitdiff
path: root/LaTeX
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2008-08-13 19:38:05 +0000
committerPaul Buetow <paul@buetow.org>2008-08-13 19:38:05 +0000
commit179fb18a72050772b2df9fd0065c642ef39aec5a (patch)
tree8806d0e3bb240c0eb6ba32a881e2a419bbeaa8ff /LaTeX
parent82f1965397411e0bbd1d59b8e657b0592dd472d3 (diff)
correct
Diffstat (limited to 'LaTeX')
-rw-r--r--LaTeX/chapters/implementierung.tex56
-rw-r--r--LaTeX/chapters/protokolle.tex2
-rw-r--r--LaTeX/chapters/titlepage.tex1
-rw-r--r--LaTeX/diplomarbeit.pdf3027
4 files changed, 1560 insertions, 1526 deletions
diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex
index fe68809..73a37d3 100644
--- a/LaTeX/chapters/implementierung.tex
+++ b/LaTeX/chapters/implementierung.tex
@@ -88,7 +88,7 @@ Hierbei steht \textit{key} f\"{u}r den Variablennamen- und \textit{val} f\"{u}r
Die Klasse \textit{VSPrefs} bietet auch eine Reihe von \textit{initInteger}-Methoden an, welche sich von den \textit{setInteger}-Methoden dadurch unterscheiden, dass sie einer Variable nur einen Wert zuweisen, wenn sie vorher noch nicht initialisiert wurde, was durch \textit{setInteger} oder \textit{initInteger} selbst geschehen sein kann. Eine komplette bersicht aller Methoden (auch fr andere Datentypen) gibt es in der Quelltext-Dokumentation.
-Die Klasse \textit{VSPrefs} speichert alle Integervariablen in einem \textit{HashMap<String,Integer>}-Objekt ab, wobei der String-Wert den Variablennamen \textit{key} angibt. Fr die Beschreibung \textit{descr}, den Einheiten-String \textit{unit} sowie mglichen Minimal- und Maximalwerte werden separate Instanzen von \textit{HashMap} verwendet. Da die Methoden eines \textit{HashMap}-Objektes synchronisiert sind, knnen alle Methoden von \textit{VSPrefs} aus verschiednenen Threads gleichzeitig verwendet werden.
+Die Klasse \textit{VSPrefs} speichert alle Integervariablen in einem \textit{HashMap<String,Integer>}-Objekt ab, wobei der String-Wert den Variablennamen \textit{key} angibt. Fr die Beschreibung \textit{descr}, den Einheiten-String \textit{unit} sowie mglichen Minimal- und Maximalwerte werden separate Instanzen von \textit{HashMap} verwendet. Da die Selektoren von \textit{VSPrefs} synchronisiert sind, knnen alle \textit{HashMap}s aus verschiednenen Threads gleichzeitig verwendet werden.
Die Klasse \textit{VSSerializablePrefs} implementiert das Interface \textit{VSSerializable} und kann somit durch Serialisierung alle enthaltenen Daten in eine Datei abspeichern beziehungsweise wieder in den Speicher laden.
@@ -534,9 +534,9 @@ Wenn eine Simulatorversion versucht eine abgespeicherte Simulation eines nicht i
\section{GUI sowie Simulationsvisualisierung}
-Das Paket \textit{simulator} (s. Abbildung \ref{fig:PackageProtocols}.) implementiert die eigentliche graphische Benutzeroberflche des Simulators. Ausnahmen stellen die Editorklassen in \textit{prefs.editors} sowie \textit{utils.VSFrame} dar.
+Das Paket \textit{simulator} (s. Abbildung \ref{fig:PackageProtocols}.) implementiert die graphische Benutzeroberflche des Simulators. Ausnahmen stellen die Editorklassen in \textit{prefs.editors} sowie die Klasse \textit{utils.VSFrame} dar.
-Beim Starten des Simulators wird auf die \textit{main}-Methode, welche sich in \textit{VSMain} befindet, aufgerufen. Sie instantiiert ein \textit{VSDefaultPrefs}-Objekt, wo alle Standardeinstellungen des Simulators abgelegt sind. Anschlieend wird ein \textit{VSSimulatorFrame} erzeugt, welches ein Simulatorfenster (vgl. Abbildung \ref{fig:NeuesFenster}.) implementiert. Das Simulatorfenster erstellt fr jede neue Simulation jeweils ein Objekt von \textit{VSSimulator}, wobei jede Simulation im Simulationsfenster einen eigenen Tab besitzt. In Abbildung \ref{fig:NeuErstellteSimulation}. wurde bereits eine neue Simulation erstellt, wo auch unten links der dazugehrige Tab mit der Beschriftung ``Simulator 1'' zu sehen ist. Jede Simulation besitzt dabei eine eigene Simulationsnummer, die bei jeder neuen Simulation um eins inkrementiert wird. Jedes \textit{VSSimulator}-Objekt greift auf \textit{VSSimulatorVisualization} zurck, was die Simulationsvisualisierung (s. Abbildung \ref{fig:Visualisierung}.) implementiert.
+Beim Starten des Simulators wird auf die \textit{main}-Methode, welche sich in \textit{VSMain} befindet, aufgerufen. Sie instantiiert ein \textit{VSDefaultPrefs}-Objekt, wo alle Standardeinstellungen des Simulators abgelegt sind. Anschlieend wird ein \textit{VSSimulatorFrame} erzeugt, welches ein Simulatorfenster (s. Abbildung \ref{fig:NeuesFenster}.) implementiert. Das Simulatorfenster erstellt fr jede neue Simulation jeweils ein Objekt von \textit{VSSimulator}, wobei jede Simulation im Simulationsfenster einen eigenen Tab besitzt (s. Abbildung \ref{fig:NeuErstellteSimulation}., unten links). Jede Simulation besitzt dabei eine eigene Simulationsnummer. Jedes \textit{VSSimulator}-Objekt greift auf die Klasse \textit{VSSimulatorVisualization} zurck, welche die Simulationsvisualisierung (s. Abbildung \ref{fig:Visualisierung}.) implementiert.
\begin{figure}[h]
\centering
@@ -545,34 +545,34 @@ Beim Starten des Simulators wird auf die \textit{main}-Methode, welche sich in \
\label{fig:PackageProtocols}
\end{figure}
-\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D (siehe \cite{Java2d} und \cite{Java2DAPI}) zurck und ist, aus Performance-Grnden, mit dem Simulationsverlauf stark verzahnt \cite{Games}. Klassenattribute, dessen Wert sich nie ndert, wurden stets als \textit{final} deklariert. Attribute, die von Konfigurationen oder Einstellungen abhngig sind, die sich nur nach Konfigurationsnderung oder Vergrern beziehungsweise Verkleinern des Simulationsfensters ndern (Werte, die fr die Berechnung des Sekunden-Gatters notwendig sind), werden nur wenn es ntig ist neu berechnet.
+\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D (siehe \cite{Java2d}, \cite{Java2DAPI}, \cite{Games}) zurck und ist aus Performance-Grnden mit dem Simulationsverlauf stark verzahnt. Klassenattribute, die von Simulationseinstellungen und den Fenstergr\"{o}en abhngigig sind, werden nur wenn es ntig ist neu berechnet.
-Die Klasse \textit{VSMenuItemStates} wird fr die Synchronisierung des Simulationsstatusses, der Toolbar und des Simulations-Mens (beide Letztere auf Abbildung \ref{fig:Toolbar}. zu sehen) verwendet. Abhngig davon kann der Benutzer bestimmte Aktionen durchfhren oder nicht (beispielsweise kann eine Simulation nur pausiert werden, wenn sie aktuell abgespielt wird). Alle hier mglichen Aktionen wurden bereits in Kapitel 2.1. im Abschnitt ``Die Toolbar'' behandelt.
+Die Klasse \textit{VSMenuItemStates} wird fr die Synchronisierung des Simulationsstatusses verwendet. Abhngig davon kann der Benutzer bestimmte Aktionen durchfhren oder nicht. Zum Beispiel kann eine Simulation nur pausiert werden, wenn sie aktuell abgespielt wird. Alle hier mglichen Aktionen sind bereits aus Kapitel 2.1. bekannt.
-Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereigniseditor (s. Abbildung \ref{fig:SidebarMitEreignissen}.) wird in der Klasse \textit{VSSimulator} implementiert. Hinter jeder Ereignisauswahl verbirgt sich intern ein \textit{VSCreateTask}-Objekt, welches definiert, wie das jeweilige Ereignis anzulegen ist.
+Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereigniseditor (s. Abbildung \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.
-\textit{VSLogging} kapselt ein \textit{javax.swing.JTextArea}-Objekt, wo alle Nachrichten gelogt werden. Hier werden alle Logfunktionen (inklusive Logfilter sowie temporre Deaktivierung des Loggen) implementiert. Die \textit{JTextArea} wird dem \textit{VSSimulator}-Objekt bergeben um dort dargestellt zu werden. Fr den Logfilter wird intern auf das Java-Standardpaket \textit{java.util.regex} (s. \cite{Regexp}) zugegriffen, womit anhand von regulren Ausdrcken in Java-Syntax die Logs gefiltert werden knnen.
+Die Klasse \textit{VSLogging} kapselt f\"{u}r das Loggen von Nachrichten ein \textit{JTextArea}-Objekt. In dieser Klasse werden alle Logfunktionen implementiert. Die \textit{JTextArea} wird f\"{u}r die Darstellung dem Simulationsobjekt \textit{VSSimulator} \"{u}bergeben. Fr den Logfilter wird auf das Java-Standardpaket \textit{java.util.regex} (s. \cite{Regexp}) zugegriffen, womit anhand von regulren Ausdrcken in Java-Syntax die Logs gefiltert werden knnen (s. Kapitel 2.2.2. im Abschnitt Logfilter).
\subsubsection{Threads und Zeitsynchronisierung}
-Der Simulator soll im Stande sein, bis auf jede Millisekunde genau zu simulieren. Jede simulierte Sekunde soll dabei relativ zur echten Zeit fortschreiten. Die Simulationsabspielgeschwindigkeit lsst sich bei den Simulationseinstellungen unter ``Abspielgeschwindigkeit der Simulation'' (Float: \textit{sim.clock.speed}) einstellen. Damit dies gewhrleistet wird, muss folgendes bercksichtigt werden:
+Der Simulator soll auf jede Millisekunde genau simulieren k\"{o}nnen und jede simulierte Sekunde soll dabei relativ zur echten Zeit fortschreiten. Die Simulationsabspielgeschwindigkeit lsst sich bei den Simulationseinstellungen unter ``Abspielgeschwindigkeit der Simulation'' (Float: \textit{sim.clock.speed}) einstellen (s. Kapitel 2.4.2.). Hierf\"{u}r muss folgendes bercksichtigt werden:
\begin{itemize}
- \item Das Zeichnen der Visualisierung bentigt pro Aktualisierung einige Millisekunden. Dies ist der rechen-intensivste Teil des Simulators. Hier werden stndig mathematische Berechnungen (wie zum Beispiel die Gerade einer Nachrichtenlinie, die automatische Skalierung des Diagramms die sich automatisch an die Fenstergre und der Simulationsdauer anpasst und vieles mehr).
- \item Das Neuberechnen der Simulation bentigt pro Aktualisierung einige Millisekunden. Hier wird insbesondere der Task-Manager beansprucht, welcher berprft, ob Ereignisse auszufhren sind, und sie gegebenenfalls dann auch ausfhrt.
- \item Jeder simulierte Prozess sollte mit selber Geschwindigkeit fortschreiten, und dies auf jedem Rechner wo der Simulator ausgefhrt wird. Da Java-Threads nicht komplett plattformunabhngig sind (Threads sind im Betriebssystem implementiert), k\"{o}nnte das Verhalten auf verschiedenen Betriebssystemen oder Architekturen variieren. Auerdem bernimmt das Betriebssystem die Entscheidung, wann welcher Thread arbeiten darf. Auer man synchronisiert Threads manuell so, dass sie den eigenen Ansprchen entsprechen. Letzteres bedeutet aber auch mehr Programmieraufwand.
- \item Die Simulationszeit ist stets in Millisekunden angegeben, welche in einer \textit{long}-Variable abgespeichert wird. Somit kann eine Simulationszeit immer nur eine ganze Zahl sein. Berechnungsrundungsfehler wegen \textit{sim.clock.speed} mssen bercksichtigt werden.
- \item Der Simulator soll nicht stndig die komplette CPU des Anwender-Computers voll beanspruchen.
+ \item Das Zeichnen der Visualisierung bentigt pro Aktualisierung einige Millisekunden. Hier werden stndig mathematische Berechnungen (z.B. die Berechnung einer Nachrichtenlinie, die automatische Skalierung des Diagramms, u.s.w.) durchgef\"{u}hrt.
+ \item Das Neuberechnen der Simulation bentigt pro Aktualisierung einige Millisekunden. Hier wird insbesondere der Task-Manager beansprucht, welcher berprft ob Ereignisse auszufhren sind.
+ \item Jeder simulierte Prozess sollte mit selber Geschwindigkeit fortschreiten, und dies auf jedem Betriebssystem und auf jeder Architektur. Da Java-Threads nicht komplett plattformunabhngig sind (Threads sind im Betriebssystem implementiert), k\"{o}nnte das Verhalten auf verschiedenen Betriebssystemen oder Architekturen variieren. Auerdem bernimmt das Betriebssystem die Entscheidung, wann welcher Thread arbeiten darf. Auer man synchronisiert Threads manuell so, dass sie den eigenen Ansprchen 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. Kapitel 2.4.2.) mssen bercksichtigt werden.
+ \item Der Simulator soll nicht stndig die komplette CPU des Anwender-Computers voll auslasten.
\end{itemize}
-Es wurde eine Lsung gewhlt, bei der lediglich ein einziger Thread fr die Visualisierung und die Berechnung der Simulation zustndig ist (alle Zeitangaben sind in Millisekunden angegeben). Der Algorithmus verluft leicht vereinfacht in folgender Form ab:
+Es wurde eine Lsung gewhlt, bei der lediglich ein einziger Thread fr die Visualisierung und die Berechnung der Simulation zustndig ist. Der Algorithmus verluft in leicht vereinfachter Form wie folgt ab:
\begin{enumerate}
\item Die aktuelle simulierte globale Zeit sei $t$ und die globale Zeit wo die Simulation aufhrt sei $e$.
\item Wenn $t > e$, dann $t := e$ setzen.
\item Neuberechnen und Zeichnen der Visualisierung zum Zeitpunkt $t$. Die dabei verstrichene Zeit sei $v$.
\item Wenn $t = e$, dann Simulation beenden.
- \item Fr einige Millisekunden den Thread pausieren (schlafen lassen). Hierbei sei $p$ die beim Schlafen verstrichene Zeit.
+ \item Fr einige Millisekunden den Thread pausieren. Hierbei sei $p$ die beim Schlafen verstrichene Zeit.
\item
\begin{verbatim}
for (i = t; i < t + v + p && i < e; i++)
@@ -581,22 +581,22 @@ for (i = t; i < t + v + p && i < e; i++)
\item Bei Punkt 2 mit neuer Startzeit $t := t + v + p$ weitermachen.
\end{enumerate}
-Hinzu kommt noch die Bercksichtigung der Simulationsvariable \textit{sim.clock.speed}, die wegen der bersicht im Algorithmus nicht dargestellt wurde. Intern hat der Simulator die echte Zeit und die Simulationszeit abgespeichert. Es werden stndig die verstrichenen echten Zeiten gemessen und anschlieend anhand von \textit{sim.clock.speed} die neuen tatschlichen Simulationszeiten berechnet. Rundungsfehler werden pro Durchgang in eine \textit{double}-Variable (Fliekommazahl doppelter Genauigkeit) abgespeichert und wenn der Betrag der Rundungsfehler $>= 1$ ist, dann werden davon die ganzen Wertanteile in der Simulationszeit bercksichtigt. F\"{u}r jede lokale Prozesszeit sowie der dazugeh\"{o}rigen lokalen Uhrabweichung und den lokale Ereignisse wird \"{a}hnlich verfahren.
+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 stndig die verstrichenen echten Zeiten gemessen und anschlieend anhand von \textit{sim.clock.speed} die neuen tatschlichen Simulationszeiten berechnet. Die Rundungsfehler werden pro Durchgang in eine \textit{double}-Variable (Fliekommazahl doppelter Genauigkeit) abgespeichert. Wenn der Betrag der Rundungsfehler $>= 1$ ist, dann wird davon der ganze Werteanteile in der Simulationszeit bercksichtigt. F\"{u}r jede lokale Prozesszeit sowie der dazugeh\"{o}rigen lokalen Uhrabweichungen wird \"{a}hnlich verfahren.
-Jede Simulation besitzt somit seinen eigenen Simulationsthread. Bei mehreren parallel laufenden Simulationen laufen auch mehrere parallele voneinander unabhngige Threads. Des Weiteren gibt es noch den Java Swing-Thread, der fr die GUI und der Anwenderinteraktion zustndig ist. Der Anwender kann zu jedem Zeitpunkt in die Simulation eingreifen. Anwendereingriffe werden deswegen synchronisiert, da es ansonsten zu zeitgleichen Zugriffen/nderungen gleicher Objekte kommen kann und somit eine Java-Ausnahme geworfen wird die das Stoppen eines Threads verursacht.
+Jede Simulation besitzt somit seinen eigenen Simulationsthread. Des Weiteren gibt es noch den Java Swing-Thread (s. \cite{Swing}), der fr die GUI und somit auch f\"{u}r die Anwenderinteraktion zustndig ist. Der Anwender kann zu jedem Zeitpunkt in die Simulation eingreifen, weshalb alle Anwendereingriffe synchronisiert werden.
\section{Serialisierung und Deserialisierung von Simulationen}
-Der Anwender kann eine erstellte Simulation im Datei-Men speichern und/oder eine bereits abgespeicherte Simulation laden. Hierbei wird von der aus Java angebotenen Mglichkeit Objekte zu Serialisieren Gebrauch gemacht. Im Paket \textit{serialize} (s. Abbildung \ref{fig:PackageSerialize}.) befinden sich Helfer, die bei einer Serialisierung und einer Deserialisierung einer Simulation unter die Arme greifen.
+Der Anwender kann eine erstellte Simulation im Datei-Men speichern oder eine bereits abgespeicherte Simulation laden. Hierbei wird von der aus Java angebotenen Mglichkeit Objekte zu Serialisieren Gebrauch gemacht. Im Paket \textit{serialize} (s. Abbildung \ref{fig:PackageSerialize}.) befinden sich Helfer, die bei der Serialisierung einer Simulation unter die Arme greifen.
-Der Simulator serialisiert nur notwendige Daten, und nicht jedes existierende Objekt. Alle Serialisierbaren Klassen implementieren das Interface \textit{VSSerializable} mit folgenden zwei Methoden:
+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:
\begin{itemize}
- \item \textit{public void serialize(VSSerialize serialize, ObjectOutputStream oos)}: Diese Methode wird bei jedem Serialisierungsvorgang aufgerufen (beim Speichern einer Simulation).
- \item \textit{public void deserialize(VSSerialize serialize, ObjectInputStream ois)}: Diese Methode wird bei jedem Deserialisierungsvorgang aufgerufen (beim Laden einer Simulation).
+ \item \textit{public void serialize(VSSerialize serialize, ObjectOutputStream oos)}: Diese Methode wird bei jedem Serialisierungsvorgang aufgerufen (Speichern einer Simulation).
+ \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 einen Dateistream auch ein \textit{VSSerialize}-Objekt. Fr jeden (De)serialisierungsvorgang wird ein \textit{VSSerialize}-Objekt erzeugt, welches dabei Hilft, die bentigten Aktionen durchzufhren. Eine zu serialisierende Simulation besteht aus vielen voneinander abhngigen Objekten. Jedes Objekt kann dabei Referenzen auf andere Objekte besitzen. Wrde jedes Objekt komplett serialisiert werden, so wrden Objekte, auf denen mehrere Referenzen existierten, in mehrfacher Ausfhrung behandelt (in eine Datei abgespeichert) werden. Bei Kreisverweisen (Objekt A hat eine Referenz auf Objekt B und Objekt B hat eine Referenz auf Objekt A als Attribut gespeichert) wrde 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 nur genau einmal serialisiert wird. Bei der Deserialisierung werden alle Objekte wieder automatisch mit den richtigen Referenzen ausgestattet, wobei kein Objekt doppelt deserialisiert wird.
+Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einen Dateistream auch ein \textit{VSSerialize}-Objekt als \"{U}bergabeparameter. Fr jeden Serialisierungsvorgang wird zuerst ein Objekt der Klasse \textit{VSSerialize} erstellt. Eine zu serialisierende Simulation besteht aus vielen voneinander abhngigen Objekten. Jedes Objekt kann dabei Referenzen auf andere Objekte besitzen. Wrde jedes Objekt komplett serialisiert werden, so wrden Objekte, auf denen mehrere Referenzen existierten, in mehrfacher Ausfhrung behandelt werden. Bei Kreisverweisen (Objekt A hat eine Referenz auf Objekt B und Objekt B hat eine Referenz auf Objekt A als Attribut gespeichert) wrde 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.
\begin{figure}[h]
\centering
@@ -605,9 +605,9 @@ Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einen Da
\label{fig:PackageSerialize}
\end{figure}
-Alle Klassen, die \textit{VSSerializePrefs} erweitern, knnen automatisch smtliche Einstellungen komfortabel serialisieren und deserialiseren. 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.
+Alle Klassen, die \textit{VSSerializePrefs} erweitern, knnen komfortabel smtliche 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 zuknftigen 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 angehren, serialisiert.
+Abgespeicherte Simulationen sollen auch mit zuknftigen 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 angehren, serialisiert. Eine Erweiterung des GUIs muss somit nicht bei den Serialisierungen ber\"{u}cksichtigt werden.
\subsubsection{Beispielimplementierung einer \textit{serialize}-Methode}
@@ -621,17 +621,17 @@ Der folgende Quelltext-Ausschnitt zeigt eine Beispielimplementierung von \textit
oss.writeObject(attributeOne);
oss.writeObject(ottributeTwo);
serialize.setObject("sampleObject", this);
- prefs.serialize(serialize, oos);
+ process.serialize(serialize, oos);
someOtherSerializableObject.serialize(serialize, oos);
oss.writeObject(new Boolean(false)); // flag
}
\end{code}
-Vor- und nach der eigentlichen Objektserialisierung wird jeweils eine boolesche Flagge serialisiert, welche auf \textit{true} gesetzt wird, sobald in spteren Simulator-Versionen (was relativ unwahrscheinlich, aber mglich ist) weitere zu serialisierenden Klassenattribute hinzukommen. Eine Deserialisierung kann die Flaggen dann abfragen und separat behandeln. 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. Somit knnen beliebig viele Erweiterungen in die Serialisierung Einzug halten.
+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.
-Das zu serialisierende Objekt besitzt hier lediglich zwei Attribute, die serialisiert werden sollen. Alle anderen Klassenattribute knnen vernachlssigt werden. Mit \textit{serialize.setObject} speichert \textit{serialize} eine Referenz auf das aktuelle Objekt ab, worauf andere Objekte bei der Serialisierung zurckgreifen knnen. Danach wird ein \textit{prefs} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung folgt genau den Umgekehrten weg. \textit{VSSerialize} hilft auch hier dabei mehrere Referenzen auf das selbe Objekt korrekt zu behandeln.
+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 zurckgreifen knnen. Danach wird ein \textit{process} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung folgt genau der umgekehrten Reihenfolge, wobei ein Objekt von \textit{VSSerialize} hierbei hilft die Referenzen auf andere Objekte korrekt zu setzen.
-Wenn der Anwender \textit{Datei $\rightarrow$ Simulation speichern} whlt, dann wird zunchst ein \textit{VSSerialize}-Objekt erstellt. Ausgehend davon wird \textit{serialize} auf \textit{VSPrefs} und \textit{VSSimulator} ausgefhrt (siehe Serialisierungssequenz in Abbildung \ref{fig:SequenceSerialize}.). Das Simulator-Objekt fhrt \textit{serialize} wiederum auf das \textit{VSSimulatorVisualization}-Objekt aus. Dort wird jeder Prozess inklusive alle Protokollobjekte serialisiert. Anschlieend folgt der Task-Manager inklusive allen programmierten Ereignissen.
+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}) ausgefhrt. Das Simulator-Objekt fhrt \textit{serialize} wiederum auf das \textit{VSSimulatorVisualization}-Objekt aus. Dort wird jeder Prozess inklusive alle Protokollobjekte serialisiert. Anschlieend folgt der Task-Manager inklusive allen programmierten Ereignissen.
\section{Helferklassen und Klassen fr Ausnahmebehandlungen}
diff --git a/LaTeX/chapters/protokolle.tex b/LaTeX/chapters/protokolle.tex
index 13f5ef4..a4bddc7 100644
--- a/LaTeX/chapters/protokolle.tex
+++ b/LaTeX/chapters/protokolle.tex
@@ -26,7 +26,7 @@ Bei dem Ping-Pong Protokoll (s. Abbildung \ref{fig:PingPongProto}.) werden zwisc
\label{fig:PingPongSturmProto}
\end{figure}
-Wichtig ist, dass Prozess 1 seinen Ping-Pong Client aktiviert, bevor er eine Ping-Pong Clientanfrage startet. Wenn die Eintrittszeiten fr die Aktivierung des Protokolls und das Starten der Anfrage identisch sind, ordnet der Task-Manager (siehe Kapitel 4.4.3.) diese Ereignisse automatisch in der richtigen Reihenfolge an. Bei nicht-aktiviertem Ping-Pong Client kann P1 keine Ping-Pong Anfrage starten. Bevor ein Prozess eine Anfrage starten kann, muss er das dazugehrige Protokoll aktiviert haben. Entsprechend gilt dies auch fr alle anderen Protokolle. Anhand dieses Beispiels ist erkennbar, dass die noch nicht ausgelieferte Nachrichte grn eingefrbt ist whrend alle ausgelieferten Nachrichten bereits die Farbe Blau tragen (s. Tabelle \ref{tb:Farben}.).
+Wichtig ist, dass Prozess 1 seinen Ping-Pong Client aktiviert, bevor er eine Ping-Pong Clientanfrage startet. Wenn die Eintrittszeiten fr die Aktivierung des Protokolls und das Starten der Anfrage identisch sind, ordnet der Task-Manager (siehe Kapitel 4.4.3.) diese Ereignisse automatisch in der richtigen Reihenfolge an. Bei nicht aktiviertem Ping-Pong Client kann P1 keine Ping-Pong Anfrage starten. Bevor ein Prozess eine Anfrage starten kann, muss er das dazugehrige Protokoll aktiviert haben. Entsprechend gilt dies auch fr alle anderen Protokolle. Anhand dieses Beispiels ist erkennbar, dass die noch nicht ausgelieferte Nachrichte grn eingefrbt ist whrend alle ausgelieferten Nachrichten bereits die Farbe Blau tragen (s. Tabelle \ref{tb:Farben}.).
Werden die Ereignisse wie in Tabelle \ref{tb:PingPongSturmTasks}. vorgegeben, so lsst sich ein Ping-Pong Sturm realisieren. Hier wird ein neuer Prozess P3 eingefhrt, der als zustzlicher Ping-Pong Server agiert. Da auf jede Clientnachricht stets zwei Serverantworten folgen, verdoppelt sich bei jedem Ping-Pong Durchgang die Anzahl der Nachrichten. In Abbildung \ref{fig:PingPongSturmProto}. ist der dazugehrige Simulationsverlauf bis zum Zeitpunkt \textit{12676ms} dargestellt.
diff --git a/LaTeX/chapters/titlepage.tex b/LaTeX/chapters/titlepage.tex
index 9530e85..4cbae22 100644
--- a/LaTeX/chapters/titlepage.tex
+++ b/LaTeX/chapters/titlepage.tex
@@ -95,7 +95,6 @@ Ohne die Hilfe folgender Personen w\"{a}re die Anfertigung dieser Diplomarbeit i
\begin{itemize}
\item Prof. Omann als 1. Pr\"{u}fer sowie Prof. Fassbender als 2. Pr\"{u}fer
- \item Albena Angelova
\item Andre Herbst
\item Carrie Callahan
\item Claudia Steudter
diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf
index 73ccf01..405c83a 100644
--- a/LaTeX/diplomarbeit.pdf
+++ b/LaTeX/diplomarbeit.pdf
@@ -489,14 +489,16 @@ endobj
/ProcSet [ /PDF ]
>> endobj
189 0 obj <<
-/Length 917
+/Length 872
/Filter /FlateDecode
>>
stream
-xڕWMo8Wpiڋ:fFѮi6q=[v`4!\ 8"4
-m@a@{Bi;$2ᶶ`þ;Ⱥ1}V6l_T٢u>$éjO;SG%mhZ1ŝ@y`h@Nem6F/*unDtѤ",zm\9g#>*QFIvI1
-S?zU8&qJYܓ>Jփ
-|U| w<P?zuK{Fr"AďU>֋9xlӗ+Vz]tnN"3wA\a.X/.Y\pYGY \ p0+^qae\ W4oa G+wP>#lU|κeGu|IJ0
+xڕVMs0WpZEHH|4dIf[݃l)
+!qi{!)=.{*0K)C4fU(a,V7뫯p`[ ܌s$:O#cV`2~݉ ՛Co8bL$ݶCUB?:Yn]{U6 庩J@Bi#ui6mfN֓56]W*kjVUO!lwh 98^G V:1"u7D
+
+]Ν' "Č",
+mA13=HJ`PoB̧$jAgCR=Z앐yc ܯP|j
+$ArRUpTΨ0f}
endobj
188 0 obj <<
/Type /Page
@@ -755,10 +757,10 @@ endobj
>>
stream
x[oF)xR= s{̪6iu_
-pV3ː]GUT=??
-i!`sPAQZn>.ΪqEyIowyZxqp>-1eUw*+E:n ?6M5eRYgUBzW쓼Jo%nqV '`4.Q%֨5H3$R\)*'VJ**2)Wk*Ux:
- &YiQJS'Qt_=ͯܿa@wx]4 dMD/"2~&Z*$Bw*їc<wת ܴ-%Ox5~mYr}a{Nƫs"<C kU!P@3>siCs6o@oչ <ɧ4i^nV0.ֿyM3 j&R-`LZ1 ZV{rDoj<(BX(%Y(jIԪ
-9d<$(sPZ*K}2޳У? jt,ިg <m5 ד}_Jy8KK91SNRN2Պ)Sd::I, }2Ig'8ZQãhy|i;5}^a ?S,Z( RnU ai/Y}>80z}f|PtG_Գxd~1eIVO-`Y pG&94=y'7.{
+pV3ː]GUTl=?? ?EX@j lowjVvo6~/X"
+6ECx*WIϊ[zrNjMSiIE!% ְ!(ӮSX)q_C<(mL-
+:2UFhBdU|;,4pCL84p9g,TMF GY/%F`OQ9)V8EWWi^VIOIZSc~l\ݥաPHO0ɂ>ȾN͌Rͭމ2l_~#iNuu4>?D/"2 ~&Z*$Bw*1b Z൪,7mK<^ _v\>qjf2ϯ/`%chÚ/tU+jf-$iub8<LyĜviZМ ׿Ʒ;pvlC.F)M8ˇ/qob 2p 9өdLöV![xD1O/9$
+yIlEvZdY|w=5 y<T֮lJ($Rw/x]=7Y$"~r[M.o}d{W,C^>1sNLSこxb"T0$No=K5Hkk҃'Y4N)?V(Z߷CNKJ?S,/Q(2HnSU-S-O+|βx5モ8#S<d0LrdT4ۗ2w&]{`H Ոq,& + '5a[Üj5s<sg1G+0LZQÜɭiXy{nJ "X;/j!=#s4W:]3kxW>ϫ/9r@#b?BvWmo$է\<V|1 X 8j!/J(D^sz-[<^FT"#J,= ۵S2:U}u=Mߘ~$:,!USg̭j!U7hYDS T*FP9-*S%X1/nHn^ޏo13XEƘȺU-鬝f9턶,9a vZ)Mkiqu4s
endobj
234 0 obj <<
/Type /Page
@@ -1092,13 +1094,13 @@ endobj
/Filter /FlateDecode
>>
stream
-xo6W`<nXW`[ afZ;a_?JeJO hkrt;~HBqı2]R{v7WϾ^B##%/T0D%gW7^.75+{z&~(oW?<{~Շ#-%}Zn1]Hʌv?H"\
-iapAJgpYF`"7JV Uzn^>rjX{~<N8qLiĨl]R*!ߞǎh#,fo5fQS<P3D!C]|zNi{p<7/?؄Ab‚8I̅$_f  (=Ԓd㍹d%e`2Q&l]kw0/P)j&#RXrWbW#ybߔMv[_t]'DKY ~i(6|'uHHHP[K E=IA|H)vݤ Q%G.=wn߶-1zr.rd%6Qmt'V`57QaG_*|? ˟zkYK
-9w0xӏ[Y"{S"AbhԉKon]GBIB A
-zk$5uI+oE2 u0PeP5+mr=_Ͳ h7+{A`AAzk!yȡ*7ut;iyȃ/|w<))*x'6wg5ߪУ\v+&O`;n0"DHxע7`
-年Ng
-+Xw}53P:-5KMHgF1wHy,ppF8?."^P$ 'l<}piqgn(WI9gETf0SB *#_][//ҙB.)Wiu%hj^yML"pe84w4(x\53E7u.~>kjExHHwm٪t~o]-?$uܡږ"gZ;5[[w@Q"AURo-0KXF#Y:"r!J1f_v5? ˟zkYK:1j ݝM7]w{>4y7%q7%EyM.ه8f@eHWKr~
-NKڴ&9u(F @y>3nDǜ<nf2)S`:9:֒Ir.EeʭO{_k -3s I#oendstream
+xMoF<Jc #=e-KHE~}\.rNH"`z53pKR`E
+F0bw wi7A^={
+zWPL^zM<nToCY>i)j!-6xB83Z!-[0H)ٰt^,!zmPW^)^.w۪:]q2bE\E 25tXTJOOǎh#lfq3ָ)pT(PA4B9q/`>x:?O ǫz-몶6a9OR~#Qb>c,y#:ǑZ2Y|1C}* ؤͷkW>@2uSE*3f*"$/ѹN
+
+Fkyy^:)vʈ^Dof.i 6{۽>]fIR"ɥ,~P<@>:K$XD$X%R扄 m>dJiRH^TQsyWkw߶#5fr.sd%6Qmtvڠ(0ӣ/vOx,`% WJ;<cvޔnHP *wT3kh_(Y!#AhӒ䡆.{%w[
+^ąMݩf*h`CG`Z7uX"f$|עyG
+6endstream
endobj
308 0 obj <<
/Type /Page
@@ -3901,19 +3903,25 @@ endobj
/ProcSet [ /PDF /Text /ImageC ]
>> endobj
589 0 obj <<
-/Length 2979
-/Filter /FlateDecode
->>
-stream
-xڽZs۸~_GiB$׹6ƽL/@[X\:],HA$E95s3X,>.v?T1X=IU2Y_y7XO?9ɘ5FMLXhyPzuz6i6l6I2mL$zhl_.qpǫ--#ކZ)Ô6d.83&KcF'4ef2OF][2Yǫ ֊JiUӳtVc2Ÿh^BfȎ9$x.HRS[ Y[L$R늚,9ɦI,AR 4P:nUc}Bi;>0$0Ps˲8yfA80!ȳ7,Km:KF<I0&p0kd8ƆA
-'܈i%淼(&>}_5zZu:]b?LOAaʻ=Z{s/^*=f|cv 8vEϪ(f~iSdIG^b+=Wn,$`*
-,nYlP8Dز`oߗus,uV,|죖P۞)ηʅ^'
->R7!Di ,EWOvI%͜y<ʊUp>-'Թe{pYM\K-7~K? lIx)Bc°,"!s&/
-L fyDsyB\sML'E Iݼ ]FBv._:0Oy8R(̹Qwu|C2fݼ$ 4?UpjI`LaկkR[l*,۔H6
-GidՃ5`i0s5fPҗF, 
-Nчf DѮ `v{\-s ߕj:=HGFʡ{]<7dpe*Y"sΙǓ.='!1TDNH[-CLN\IeF'Ȭ} TPSCܓ) ME•$!s@$5@ORc.̂ L'ys|7.=` $_~W]gt] ¶"?Ě".XXp5BoLr&CEoK%vK*I\%B0uܧ\߾$ȢYse*n)eţp |MC%Y Hݍ QFʾk hM2pK=z At,7m~3STh~txHAGId 1nH",to "k< {5 _ QJ/ Wm[2S6W>Cqr
-O}\m7c W9eK̍~/tE`˸gy} w|hӏ@vGPUУy*Ӿ͟;e:x=
-m˵+|LJ,|ؖ4ڃQvS47g0횚~,CrAO']hHE@Ɨ-:L-s+6o!y<C!dVܲ=mR izb\ ȾP3xӆ6tRhC'QH |/H6axU H4>2Щ̞:HY1$"s2+a-Y\L[8>zD3h9]&`^fBy)8
+/Length 2977
+/Filter /FlateDecode
+>>
+stream
+xڽZߏ۸~߿6fştsmR^kV֖|)Ӓlo78BǙG$$WLeVOr+asM0_dQxJx󧟌&?O(XiyPqSպl.b*ll~m3M뵣}kW5O>yE
+cP+e&gy*xfASa&I[hͯeȾ _#cZ13#=74fQk?e+4i쩚B,g<W0Lr]0!%Yjɢ2m?TH2!4,eAs >N<9-ݼۻFc\cTy c.5G\ xQ,q͊4*NY09XK& uęv66*GiP uv|_ts
+}U/iHT/`m{vƽɇ%rX.,#<*a=BqCxpy)Sv̦τbN# 眂l/!<8<R֟w3MeM[T6m1$ w+Xvغ.0ʙT#m ʹT0QwrZE*]G$σPlI
+XY6?$1-18I48+@Lo"yFTqԖ<C@#yW% Cr;xmc5I^ 3p논PnjL@]ى3u:vEWG]D@6)ʯD9_HE+"<<$zۇ
+tU$:98D J5SSR?)W%߉s.$ru9/:$`)>>s} /ȡ!(˘w!Xf.?yl!N7;N#rWk w
+ύȐ˂&WgXYE~bQL+400E0雪n5Ӫm4Bϟd|
+S^g"ػp 5^CyRe0DzZ}6Uv] !ǹOl 'oe W&k*ryxL{ õ=
+s>VۋH
+(Zj -[b!-(m`4Q*4 yBV@6D&_`n<4U1,5P uiف6o`2VHKtxn@͖]ihSQ!BIhΕF)ǾV;J9sne@Őv{*E?IjN- ,r<Y-u5/C^˲KٌJ&/nᨋ`}6Hi];ZSbzB,f"۴fbuF,OO 
+Nh0z=%}r$t#F_.)]Mf
+82,99I#׃ +Rh S~K8w8߶nA_PjӾ~lqy@{weariH8[[E%de}[
+Š|jbb`] [<3 ˙ A-ᶺ-,sIA¼btqsz}"B+ʴUQ+[G ˊ
+"_%33^.T}i>d88b{|9h
+?%B(b^5G/7*9qBr* 65 ,|=04`T-M a15=+^?,pE$pRg S
+KHs7gN&ơ qH zٸ@[w+!ƪTl^} =B/Tt")Ct Io :8 9z!$cվ
endobj
588 0 obj <<
/Type /Page
@@ -6459,22 +6467,23 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
756 0 obj <<
-/Length 3193
+/Length 3187
/Filter /FlateDecode
>>
stream
-xڭZ~>v$_pɇ8((ȋHŏ3;|ԝ[@Gwg7oR,8H3 !_l?_ix٧/[Yb^XH4Jto~~>MV,e_kv4_?>+<;,>ۛo5Z<L-R0kObəJb77
-#,/wUQˊ_CTVآac{_߳ÈTxĽ7X ~ycUPuF?T?Dkx=tۗudl
-l"f$'14 H٢?еda_ҭXGo
-
-
- kr\/qAՂLD>ƢBJ?l5,bB$i
-qPea*{\u @mG_lר 5-+ġ6+wi/!ay{=Бn!x`Ǣ5Vl"sS\~7:a "a9!͏kjK#NM
-v6o?+Kz/]]>Qu4eA-=l@CNZhJK8CbB ҅6+m|_XS!KJWJx/J(</t/[m iMU}M&;$©Av͎69zqY!:қ
-FME{Q,YJA._ÝY,p'ɨ$uo8w60C1Y?#S)&t,Gi:xTt)M*vPμ6sϣ wF7Fzՙ)oX n_<vDWJaY ٖ+tRC}bG Tuh۸]6sҡpcG}'@M2;CEo*\|FʕmɥtMD%|*9ib|*V! C0~7-0tF
-FTJ܋[
-V r6ч''%eg8:UTV>KO@fܿ3hjbn)xNͦzC&%w'(᭩rD:}cuuUqy >5DKBi{6X^Xr4i4=ó&l| XF-'Y@'p1_k14'"X*]~n=C*P)RWϻ/3z?eG*|p<7JxN?jv7tm
-xt}ly dWv] #0 µk6`Bm$g<SS'p/GL|'9~p1ˌR1/?] 3C NF5'L@6~e5EzؓX*.|U*ͷJMrW"rf;l&<taRi&DR(c[ZdߩHft#IP*hQE:
+xڭZ~>JiO>_p·8((HU_ߙ]Dέ`Zwg7;q'fff
+B>³4]ze_~,bqǙԊIDiX0kX<ݧER.~H΢ Qi,Klə#s|n'c9h0.3/ݥkL/F/rX Wt o hh[ GAB1)"%<-8J&fQdp Ţ8V<0M4Yr]y ˴Z#ۻc
+$ :QT<26aλk^0 iB&aU$/=[D+}+}D%뚜aRNAcZ >dN &իYs 27!,>&띣YSq}L?~D/|5A;0')\p,WxYyqIL$@ËkXghP{$apM;k^
+zB$մEb6t"
+2¹$ɛZ
+Q`"l̀HNn;]n`O{qD!ٶj[v;Ӓ(@iUL{[C/x[Ho}D}Nb
+H nbe2;`tG[S%Qd23#|jniiTb;.^ (9LL>6|cd[̅U
+bKlq񞥕c`OP՚TT KJ|I Xݐ(
+(4*=>K[s3U*dKaˑKP ?{W c#['iqqWBɣ e/1XL3Q 6%gG8xyǰ:Abb |X9O݌f]]4,j딩6`/,
+iK
+*j&q71rDwd|_T8ó_7Rw) *`O>Z/76ם(0eiݨ{'ll؁O,lآ
+u7pjPZ ˨ۉo$Ϳv 1RJ:ھ-u ?^t(Hi8.=}fF˭.UZ
+0VW0
endobj
755 0 obj <<
/Type /Page
@@ -7608,22 +7617,22 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
901 0 obj <<
-/Length 2970
+/Length 2853
/Filter /FlateDecode
>>
stream
-xڭr8_JU kʱI&3l!e!cTRn4@=jb }78b?1i,.lgoۿ".# 7,K=m&b(q"ie!+W.ҦsKt;W5;,̏fןZFr&|Z'LΖ2e\u+g*K'Ld.ZS^\]pa2&iZaIf@JIfm΀M|&[&RҪI.Vi:e<o!*S}pnP57aoe͊)U>_}p 0K2 K6_jJv;Gii˲*~s;BD|@WwQz}8ĆkgI&_݊TΖU҂ȫRƗi'2`U2kP j$,BϺF,##,W,Zy~,RΰKm-|[@4T=z^( <bօ#ku>Wᾆ}W-ͼr#Ț;x,0)aGr5n&RIF W]~r B̛!嵏<HgeJO`!"0_kk6o \A?ÚV$nZǚȐѕ0th7۪tw΁p}RQ48R[PïѺV_\n]xqraO:Ov nUTF-CԚG@PF(=<,OAm "빾G.]_BI'{mcV[7b<rKþ+Y hp¬,Q}D"(rYl1 ÌQa |rG[C$q6C|q!]qL%h5-%V"O"B' !i <E|^Ss&GL1Cz^V0Q)]>GfK?
-e S"׷J”+!om\Y>ΆXypw(A4T0BW "$;lQǼ,j0D7)tP҂=I | '`h0 .DTTn3ꡕ9#c 9ƦFM0bb\O[
-ܤ_-3;lfqZei1m2\6B*0
-1~ 5d˰%
-2?ՆJa]5Zi"NOᶤ*2ܨ~+܏w-L.:p@-
-һ?Pأ7ZOEbA]/`Hkc~֗Ow
-Zd<0#fi0aP]<p=gT{d$^>B+
-CeįjDz{XD0jw/W؞9x;#|Dك ,@QMB]TkF4k,t8!4a\25T
-Tk,H<הL˟1|PQTȸ MM!( 74wv  Y<1&R"[S
- ~-e2εgLKE
-DZ#$,(]WF#"~LG+WC-~HwA7W{L@ n,Hc&7W#!\(9b-clGԼ2~kG4+8`6 F/$i o%2,XEu[ӒMp7n/Ttұ3QA84G ۂDp2[m fFީq5҃mhyH%Q~K끿S3%,ZZdxeD/_#
- 25:@j{]py;?QSo'-K}L[1kX\/aنoE+w{ļ| jJ\̅0j:Y8‘g(j+aV$k~Y'iOxi:dҒ_0k "endstream
+xڭZ[ۺ~_a6fx%O riӜnM ی,o%9_)-d)jn#e1Ob4OY*1[l ^]eǫ%,5F>~I8 <-K'sˈ]alr[-"ǷW/?j#Yb|Z#ϖ2a\s+mg*MOxLZ&?S\\`ReY~H@,M2}qٕ3gJ"mݝ$3YSB1R5kߕuc?_xğU>5˃۳&?5tk܀Y*Q\9O~-=[mlM'P5Hq3O#H0]/ݱ
+F6q<3dZ7V<JlyQ*d/
+ƹI8۽I'RЫ"taC1Kг@s^XyX(8P|nb+КA@fwYׇ]^X); 1lrK _T9lciK<lhVH3%] [Hdk8C*&/9T]V$X*.!xt
+TɣXH>$
+0I[/4v 02L4@&t-`lqgHg<0UX߁oB
+x52"U "@uIH kƱl1Ҏ*=ѡ7Łߡ#HX|`Jؚ;&P!шz R<:#p>t~g!l BO!F6Bƕ-D{rXaQX#&zH,+B!zsi/T慻88
+24ݙIEYv&t$"üTԎu{xI xC9 `+u_p[ s= JM^@wWHTfgo}</Bn݁?A
+ H5hQ]?^?
+ _pEs+ܦ,,h.0v
+:J~)#tG1G=S.!P]R>@ig]k9k ok|d\iᾔ8$
+:<*|_DvxRns/Av=pD}YW_ p'h]JKEӡGt$:,z=Y;uM~ n$PK8)xCr堷;\({!ޚ$ /1,t$
+R2e 
endobj
900 0 obj <<
/Type /Page
@@ -7636,49 +7645,49 @@ endobj
905 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [210.4555 440.6738 224.9111 451.2561]
+/Rect [214.7767 434.7787 229.2323 445.361]
/Subtype /Link
/A << /S /GoTo /D (figure.4.9) >>
>> endobj
906 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [407.5969 359.8535 422.0524 370.4358]
+/Rect [378.5231 352.9848 392.9787 363.5671]
/Subtype /Link
/A << /S /GoTo /D (figure.2.1) >>
>> endobj
907 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [312.673 323.999 327.1286 334.5813]
+/Rect [279.7042 317.1304 294.1597 327.7126]
/Subtype /Link
/A << /S /GoTo /D (figure.2.3) >>
>> endobj
908 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [501.9286 270.2173 516.3841 280.7996]
+/Rect [231.1925 281.2759 245.6481 291.8582]
/Subtype /Link
/A << /S /GoTo /D (figure.2.5) >>
>> endobj
909 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[0 1 0]
-/Rect [371.3659 227.0627 391.4347 235.6275]
+/Rect [372.1582 255.0749 392.2269 263.6397]
/Subtype /Link
/A << /S /GoTo /D (cite.Java2d) >>
>> endobj
910 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[0 1 0]
-/Rect [415.9027 227.0627 436.2493 235.6275]
+/Rect [401.086 255.0749 421.4326 263.6397]
/Subtype /Link
/A << /S /GoTo /D (cite.Java2DAPI) >>
>> endobj
911 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[0 1 0]
-/Rect [345.6599 209.1355 371.4848 217.7003]
+/Rect [430.2917 255.0749 456.1165 263.6397]
/Subtype /Link
/A << /S /GoTo /D (cite.Games) >>
>> endobj
@@ -7689,33 +7698,32 @@ endobj
/D [900 0 R /XYZ 74.4095 692.0192 null]
>> endobj
904 0 obj <<
-/D [900 0 R /XYZ 74.4095 627.1312 null]
+/D [900 0 R /XYZ 74.4095 626.1576 null]
>> endobj
130 0 obj <<
-/D [900 0 R /XYZ 74.4095 516.0508 null]
+/D [900 0 R /XYZ 74.4095 512.2293 null]
>> endobj
899 0 obj <<
/Font << /F63 220 0 R /F88 715 0 R /F28 173 0 R /F26 170 0 R >>
/ProcSet [ /PDF /Text ]
>> endobj
918 0 obj <<
-/Length 2090
+/Length 2192
/Filter /FlateDecode
>>