diff options
| author | Paul Buetow <paul@buetow.org> | 2008-08-13 21:41:59 +0000 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2008-08-13 21:41:59 +0000 |
| commit | 26f8727c2e2a60b0beb0d314fc78be660a458e4b (patch) | |
| tree | 23ac3543db72b25909186153f0f16f9fec1107d8 | |
| parent | 88e2633bf6c08876a6f640438f5eb0243bd10a2e (diff) | |
foo
| -rw-r--r-- | LaTeX/chapters/implementierung.tex | 44 | ||||
| -rw-r--r-- | LaTeX/diplomarbeit.pdf | 1632 |
2 files changed, 841 insertions, 835 deletions
diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex index 91bfdcf..120db0e 100644 --- a/LaTeX/chapters/implementierung.tex +++ b/LaTeX/chapters/implementierung.tex @@ -383,7 +383,7 @@ Wenn ber eine Nachricht Daten verschickt werden sollen, so werden die von \text Im Folgenden wird die Implementierung des zuverlssigen Multicast-Protokolls \textit{VSReliableMulticastProtocol.java} als Beispiel aufgefhrt. Die Funktionsweise des Protokolls wurde bereits in Kapitel 3.10. beschrieben. Client- und Serverseite werden in der selben Klasse implementiert.
-Im Konstruktor muss stets angegeben werden, ob beim gegebenen Protokoll der Client oder der Server die Anfragen startet. Mit \textit{VSAbstractProtocol.HAS\_ON\_CLIENT\_START} wird dem API mitgeteilt, dass der Client die Anfragen startet. Fr \textit{VSAbstractProtocol.HAS\_ON\_SERVER\_START} und Serveranfragen gilt Selbiges analog. Da ein Protokoll auch ein \textit{VSAbstractEvent} ist, muss auch hier mit \textit{setClassname} der Klassenname des aktuellen Protokolls angegeben werden:
+Im Konstruktor muss stets angegeben werden, ob beim gegebenen Protokoll der Client oder der Server die Anfragen startet. Mit \textit{VSAbstractProtocol.HAS\_ON\_CLIENT\_START} wird dem API mitgeteilt, dass der Client die Anfragen startet. Fr \textit{VSAbstractProtocol.HAS\_ON\_SERVER\_START} und Serveranfragen gilt selbiges analog. Da ein Protokoll auch ein \textit{VSAbstractEvent} ist, muss auch hier mit \textit{setClassname} der Klassenname des aktuellen Protokolls angegeben werden:
\begin{code}
package protocols.implementations;
@@ -536,7 +536,7 @@ Wenn eine Simulatorversion versucht eine abgespeicherte Simulation eines nicht i 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 (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.
+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. 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 der Klasse \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
@@ -551,7 +551,7 @@ Die Klasse \textit{VSMenuItemStates} wird fr die Synchronisierung des Simulatio 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.
-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. Kap. 2.2.2. im Abschnitt Logfilter).
+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. 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. Kap. 2.2.2. im Abschnitt Logfilter).
\subsubsection{Threads und Zeitsynchronisierung}
@@ -559,8 +559,8 @@ Der Simulator soll auf jede Millisekunde genau simulieren k\"{o}nnen und jede si \begin{itemize}
\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 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 der selben 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. Kap. 2.4.2.) mssen bercksichtigt werden.
\item Der Simulator soll nicht stndig die komplette CPU des Anwender-Computers voll auslasten.
\end{itemize}
@@ -568,7 +568,7 @@ Der Simulator soll auf jede Millisekunde genau simulieren k\"{o}nnen und jede si 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 Die aktuelle simulierte globale Zeit sei $t$ und die globale Zeit wo die Simulation endet 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.
@@ -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}
-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.
+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 Werteanteil in der Simulationszeit bercksichtigt. 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 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 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 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 unterst\"{u}tzend sind.
-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:
+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 (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 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.
+Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einem 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,7 +605,7 @@ Die Methoden \textit{serialize} und \textit{deserialize} erhalten neben einen Da \label{fig:PackageSerialize}
\end{figure}
-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.
+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. Eine Erweiterung des GUIs muss somit nicht bei den Serialisierungen ber\"{u}cksichtigt werden.
@@ -629,9 +629,9 @@ Der folgende Quelltext-Ausschnitt zeigt eine Beispielimplementierung von \textit 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 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.
+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 in der umgekehrten Reihenfolge, wobei ein Objekt von \textit{VSSerialize} hierbei 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}) 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.
+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 mit allen programmierten Ereignissen.
\section{Helferklassen und Klassen fr Ausnahmebehandlungen}
@@ -646,7 +646,7 @@ Es wurden noch nicht die Klassen der Pakete \textit{utils} (s. Abbildung \ref{fi \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 Bildflche platziert werden und dass Unterfenster (Fenster, die aus einem anderen Fenster aus geffnet 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 Bildflche platziert werden und dass Unterfenster (Fenster, die aus einem anderen Fenster heraus geffnet wurden) automatisch mit geschlossen werden, sobald eines ihrer ``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 fr die Textanzeige in \textit{VSAboutFrame} zustndig.
\item \textit{VSClassLoader}: Diese Klasse wird fr die automatische Instantiierung von Ereignisobjekten bentigt, wenn dem Simulator lediglich die Klassennamen (aus \textit{events.VSRegisteredEvents}) bekannt sind.
@@ -663,7 +663,7 @@ Es wurden noch nicht die Klassen der Pakete \textit{utils} (s. Abbildung \ref{fi \label{fig:PackageExceptions}
\end{figure}
-Im Paket \textit{exceptions} befinden sich lediglich einige Klassen, die fr Ausnahmebehandlungen verwendet werden. \textit{VSNotCopyableException} wird whrend einem Kopierversuch eines nicht-kopierbaren Ereignis 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} zurck.
+Im Paket \textit{exceptions} befinden sich lediglich einige Klassen, die fr Ausnahmebehandlungen verwendet werden. \textit{VSNotCopyableException} wird whrend 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} zurck.
\begin{figure}
\centering
@@ -684,28 +684,30 @@ Die \textit{main}-Methode befindet sich in der Klasse \textit{simulator.VSMain}. \item Alle Klassen- und Interfacenamen beginnen mit groen Buchstaben, whrend alle Variablen-, Methoden- und Attributnamen mit kleinen Buchstaben beginnen. Namen finaler Variablen und Attribute sind komplett in Grobuchstaben gehalten.
\item Alle Quelltext-Dateien besitzen einen Header, der Informationen der verwendeten Lizenz angibt.
\item Alle Quelltext-Dateien werden vollstndig mit Javadoc dokumentiert.
- \item Der komplette Quelltext inklusive Dokumentation werden in englischer Sprache verfasst.
- \item Eine Quelltext-Datei hat eine maximale Zeilenlnge von 80 Zeichen, was der Standardbreite eines UNIX-Terminals entspricht. Eine Ausnahme stellt die Klasse \textit{prefs.VSDefaultPrefs} dar, denn hier befinden sich auch lngere Texte die in Strings abgespeichert werden, wo manuelle Zeilenumbrche wenig Sinn ergeben.
+ \item Der komplette Quelltext inklusive Dokumentation wird in englischer Sprache verfasst.
+ \item Eine Quelltext-Datei hat eine maximale Zeilenlnge von 80 Zeichen, was der Standardbreite eines UNIX-Terminals entspricht. Eine Ausnahme stellt die Klasse \textit{prefs.VSDefaultPrefs} dar, denn hier befinden sich auch lngere Texte die in Strings abgespeichert werden und wo manuelle Zeilenumbrche wenig Sinn ergeben.
\item Es werden zuerst Klassen aus der Java-Standardbibliothek importiert, bevor Klassen aus dem VS-Simulator selbst importiert werden.
\item Fr die Einrckung des Quelltextes wird das Tool \textit{astyle} mit den Aufrufparametern \textit{--style=java --mode=java} verwendet. Hierbei wird eine Einrckungslnge von 4 Zeichen verwendet.
\item Namen aller Klassen und Interfaces tragen als Prfix stets \textit{VS}, was fr Verteilte Systeme steht.
\item Namen abstrakter Klassen tragen als Prfix 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 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}).
\end{itemize}
\section{Entwicklungsumgebung}
In diesem Teilkapitel soll ein kleiner Einblick in die Umgebung, in der der Simulator entwickelt wurde, gewhrt werden. Fr diese Diplomarbeit wurde ausschlielich Open Source Software verwendet. Die einzige Ausnahme stellt Microsoft Windows XP dar, worauf der Simulator zustzlich getestet wurde. Der Simulator wurde jedoch hauptschlich unter dem Betriebssystem FreeBSD 7.0, was ein Open Source Unix-Derivat ist, 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 gewhlt und fr die Quelltextdokumentation kam Javadoc, fr die automatische Quelltexteinrckung astyle und als Java-Referenz kam \cite{Javadoc} zum Einsatz. Als Built-Tool wurde hier auf Apache Ant (s. \cite{AntManual} und \cite{AntTutorial}) zur\"{u}ckgegriffen. Fr die Erstellung dieses PDF-Dokumentes wurde LaTeX in Verbindung mit dem Built-Tool GNU Make und Rubber verwendet. Eine Rechtschreibberprfung wurde mit aspell sowie OpenOffice.org durchgefhrt. xPDF diente als PDF-Anzeigeprogramm.
+Wie bereits bekannt ist, wurde Sun's Java, was mittlerweile auch Open Source Software ist, in der Version 6 (1.6) als die Implementierungssprache gewhlt und fr die Quelltextdokumentation kam Javadoc, fr die automatische Quelltexteinrckung 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. Fr 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 fr das Betrachten der Javadocs und der WebSVN-Oberflche.
Fr das Schreiben von Java-Quelltext wurde GVim (Graphical Vi IMproved) sowie Eclipse verwendet. Eclipse untersttzt bessere Code-Refactoring-Methoden, whrend GVim mit seiner Flexibilitt und schnelleren Editiermglichkeiten und mit Vim-Script, der eigenen Script-Engine, glnzt. Es wurden auerdem das JAutoDoc- (fr die Erstellung von Javadoc-Kommentare) und das Subversion-Eclipse-Plugin verwendet. Je nach Zweck wurde zwischen diesen beiden Umgebungen gewechselt. Fr das Verfassen des LaTeX-Dokumentes wurde GVim verwendet.
+Fr die Erstellung dieses PDF-Dokumentes wurde LaTeX in Verbindung mit dem Built-Tool GNU Make und Rubber verwendet. Eine Rechtschreibberprfung wurde mit aspell sowie OpenOffice.org durchgefhrt. xPDF diente als PDF-Anzeigeprogramm.
+
Smtliche 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.
\subsubsection{Linkliste der verwendeten Software}
diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf index 3bcc238..f398b5c 100644 --- a/LaTeX/diplomarbeit.pdf +++ b/LaTeX/diplomarbeit.pdf @@ -1485,8 +1485,8 @@ endobj 404 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230409Z00'00') -/ModDate (D:20080813230409Z00'00') +/CreationDate (D:20080813231100Z00'00') +/ModDate (D:20080813231100Z00'00') >> endobj 405 0 obj @@ -1579,8 +1579,8 @@ endobj 414 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230409Z00'00') -/ModDate (D:20080813230409Z00'00') +/CreationDate (D:20080813231100Z00'00') +/ModDate (D:20080813231100Z00'00') >> endobj 415 0 obj @@ -6382,8 +6382,8 @@ endobj 744 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230409Z00'00') -/ModDate (D:20080813230409Z00'00') +/CreationDate (D:20080813231059Z00'00') +/ModDate (D:20080813231059Z00'00') >> endobj 745 0 obj @@ -6574,8 +6574,8 @@ endobj 769 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230408Z00'00') -/ModDate (D:20080813230408Z00'00') +/CreationDate (D:20080813231059Z00'00') +/ModDate (D:20080813231059Z00'00') >> endobj 770 0 obj @@ -6691,8 +6691,8 @@ endobj 783 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230410Z00'00') -/ModDate (D:20080813230410Z00'00') +/CreationDate (D:20080813231100Z00'00') +/ModDate (D:20080813231100Z00'00') >> endobj 784 0 obj @@ -6897,8 +6897,8 @@ endobj 813 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230410Z00'00') -/ModDate (D:20080813230410Z00'00') +/CreationDate (D:20080813231100Z00'00') +/ModDate (D:20080813231100Z00'00') >> endobj 814 0 obj @@ -7011,8 +7011,8 @@ endobj 827 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230409Z00'00') -/ModDate (D:20080813230409Z00'00') +/CreationDate (D:20080813231059Z00'00') +/ModDate (D:20080813231059Z00'00') >> endobj 828 0 obj @@ -7111,8 +7111,8 @@ endobj 836 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230410Z00'00') -/ModDate (D:20080813230410Z00'00') +/CreationDate (D:20080813231100Z00'00') +/ModDate (D:20080813231100Z00'00') >> endobj 837 0 obj @@ -7235,8 +7235,8 @@ endobj 852 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230409Z00'00') -/ModDate (D:20080813230409Z00'00') +/CreationDate (D:20080813231059Z00'00') +/ModDate (D:20080813231059Z00'00') >> endobj 853 0 obj @@ -7456,18 +7456,14 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 872 0 obj << -/Length 2028 +/Length 2029 /Filter /FlateDecode >> stream -xY[~_Gsӭii.'gm-ٞ+K[InN?HdEG!ᐳOxf'% -Bx0}+e[^|s*/fIjoyI8]n~ߤOYc\Flp=fg&3l._lg,ZvjYl:d:#oJ; EvOĭ$Z^dž;"D,B{}yGZ[c GZ>W3<[*HECcsrkUٔ2u];s͵Zt´LCߒUC7 f -WS5
>+y9V@y5w*Զi휣Qc."HGk5ݩHȈ*3;<q/,,4"3}?V&=C8MK=P-ǿ;GR2)sqB]vuP7ZZUxܙrkS4\btSc8?@6h7ƆTLs,Hj1TgΪ# -K-Y,zX3Xk^1Ybݔ+XÙS -8SzAH{3fDmV#H`z,1OO54}E', -R-YHzX3k@J&,sgX@ۓhR!SzhA?X]%SZ0kh -e}%AqNVGu`37)^J:KGb,x.cNJQt0δז\|/߾zX_e k
ZGYs -o
|x
c@T,p%ޠcA~xϠ=V5zj/yξ@ Zk{M˪Jx +xY[۶~_GYta6m\N[+[KnN?f8,Z;@"Spf8p+Dh(,7<Xӆxڥn~u8>Z1)q`:_ɞLP4<|y*Ɩunw}2jފ$gi/Q(NR,tGN$lO@fHQ`ViВIHJRHjCt,g?ADԧb"yXTE&d,6U1xYdUUf{#͵LRaZs
!o&+[dfKdW6K
>wD>[>xu
~mTu9EiT$HG<(*S^#W,
aηaMDŏi`7OìP=쟦=k6GR2)sPB]CvuP7RZEUOX̙-rK[U +rӧ?@6ns3e{Zr <ju# +eײ==
ձML:5i^#N8L*r1xCCQ:LSᑁr_5{pxʕhzoZ:JMߞ 5f~>TɄA_x[PL3a6C).fi9rzwJFoQfEB@P$qz
✁ai +\
Z2dGʹX3wsvQ_3]vo`|:::ֵg7$};tICrԅK|8lj:cL٫vPO1HZvg~?08IU3_G3ԾеG@\h@1;)$^AP{*fKPOendstream endobj 871 0 obj << /Type /Page @@ -7628,22 +7624,24 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 901 0 obj << -/Length 2853 +/Length 2854 /Filter /FlateDecode >> stream -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
"@uIHkƱl1Ҏ*=ѡ7Łߡ#HX|`Jؚ;&P!шzR<:#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 +xڭZYۺ~_a60biCdiNM ی$O%9_sxHY,)bky.T@Ŧ{6Aǫ"HXEzBjdI.oM +d,5[!7]aJSWjˏPrD|ZGLQd¸ RW+THS(:&7S\\`RD">ܐ8(%YGʼngW"xD
b2Eڹ;I-b\jѡk˛/{?as({gm~'THrD|[Vp"ػ߳hkXh@yNQI'CaX8btNj(LfÊ\UB`kT{R-ZEOni)'jӜ'bQ@]*!J<7V/J,Z3=P!ZBC67Eq]mOT8a>k2dK,Z%B͔'vigRvF"S]aRE7y|y,PwYc P\B!fG | I +l;z5g GsX> +f^H>`T8jkfùW:?sWpiG"o`gIt(ܧNZk_` +-5|6ljߌwgܻ9ʂ@A0l,XSH\W-{1]H*mT:
L"G$
6?Mw'^
TnOԕ +SH=Ƞ1cM@R +:NI/[/]WE4 +fpWodf&BҐkpxgU 嘏m^O7V:au Sa5zk+J+ #scJ"7'\TьjvYd +)-e=;l)أi^;56>ɱh~r%:"ԑ
ġ^wKyN;x +aklwW@=ex02"~VAbCTl,A(&`4 kOdt3|)cxqg^XRƁWmjr;7DЯ^<TZ diG'3M+T6U211",K ̆F~GuIDZC|ʿsfi8f L-^~ÓSEE <?nfxt/)[hg +btCsפ̙D>|aCEF +tv7Q2e +uc(-3{ڿk"nltv:`Yx`_
[$[M8Wbp +lZYc<hnQ+0gZ1O<G<w endobj 900 0 obj << /Type /Page @@ -7663,7 +7661,7 @@ endobj 906 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [378.5231 352.9848 392.9787 363.5671] +/Rect [357.028 352.9848 371.4836 363.5671] /Subtype /Link /A << /S /GoTo /D (figure.2.1) >> >> endobj @@ -7719,23 +7717,21 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 918 0 obj << -/Length 2180 +/Length 2001 /Filter /FlateDecode >> stream -xڕY[s~ϯ4IQҾenwiO2}8M䘑T_ -XDV7ۉ>e>\~_LE;8*l̹b`\p -#ur:j㇁)-:Ϻ7e~I¤VCsS[LBC˞|xE3& -U},pYoЅ;_8!ԁeSyKMk./Mq
Hri7KRA -vJ*Ia6eU^lZ"5lfnJ+ubрPG -yX!cH-7H'jZY@R: +zOAf8j=[R}=@6<)Kǎ -9P{ U4 ~^ -KWuV37X3epoY -9>&p`<8umQf8<6`џ -, bIү0pӜgI|tvٓ3IN^-fbzr#AV]]LEKYђcI@R -]Jڱ5Q%8Rٿ3-IsKC -OBrBE3fjaWmۛ4O4!m RKXAw; uCWmi?]͗ -WQخCIЂs -V>!kGluXYv4jN)$<xRgӋZ{ʹ.h#'z{ՇWL:4VZL=Ɲb=ӖKE-0}tC{ :gO<i,"sa@I¹+_"^gGByc*dB4<3ϐxm_*vmvHU^$@]:$aT/1^:LE[)t_wxAendstream +xڕXYs6~#U5B 8oufg&fyDXq_8(IJn
(?e$O,@PmWI]w%ɥC',t]kCd:],S u$SnVk}[vAldߦTfњQ"܁Kf35U *WFG Ӱp/| xUE=JK̘$֠8\ȱo`C^oV47*y9y?#SFcx4߅HqŒXw N%c9}Utf49ID>>DK<]p +̤?%2!E߮x?c=\lL{k{Gi0sAynTʄ?~9v[H(\ +<ޙM3e(+%[QiiZH 8]]]$t_θCTUnhm5GoBvyTlA4)-<X]Ct|Aqg/4Ivk>rr>́ҹ?Ҏ3:l.C608CW)rZp9)(!xovTۣs܂JR9%D%F7;6,iHں p} +v@|\]튺,BscMutHfC\R!`NzVHL dj32v7qg\"a}3}&pmoр?^!ZBW]ŭt>u@WFi!S*,h=5 +۲A|m1l? <niOvv{.e]]mx$a?kit]cL
CN$i1\a"-TnUKGOޢ/܃Kн.\kaW|C3,O#aɴRa]cUMWLmh +G0K=iEO`Ҭ0[`yn<`=4-oܞ$+6l4V?[X +N0UgG/D.Ab>]4x6uiv.o@,k[/W}?:qB^wW03Ư/)ܴj8*%ucѽ_T@^gd[] 퓆#&9;}$ӬjPrˈ|wk?( +9!̐5RZp`!Søtf̡<-Éڋ8沉sJy +
$:]D&-t.up"3!R+*L.<h`Ee݀9;{M@p";0 6` ǭw +/š>OPz(ڍTYԽS,5ԮFk4잢SUnWӨj
zc +?`=Z/vy%JϢwڦ~_1M%]]@|Q endobj 917 0 obj << /Type /Page @@ -7772,8 +7768,8 @@ endobj 923 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080813230407Z00'00') -/ModDate (D:20080813230407Z00'00') +/CreationDate (D:20080813231058Z00'00') +/ModDate (D:20080813231058Z00'00') >> endobj 924 0 obj @@ -7795,14 +7791,14 @@ endobj 920 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [456.2811 530.1436 470.7367 540.7258] +/Rect [456.2811 529.0277 470.7367 539.6099] /Subtype /Link /A << /S /GoTo /D (figure.2.8) >> >> endobj 921 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[0 1 0] -/Rect [369.1915 434.6369 391.3401 443.2016] +/Rect [401.729 429.4758 423.8776 438.0406] /Subtype /Link /A << /S /GoTo /D (cite.Regexp) >> >> endobj @@ -7813,7 +7809,7 @@ endobj /D [917 0 R /XYZ 288.445 581.5827 null] >> endobj 922 0 obj << -/D [917 0 R /XYZ 74.4095 367.6536 null] +/D [917 0 R /XYZ 74.4095 337.3687 null] >> endobj 916 0 obj << /Font << /F63 220 0 R /F28 173 0 R /F26 170 0 R /F35 193 0 R >> @@ -7821,24 +7817,28 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 929 0 obj << -/Length 2821 -/Filter /FlateDecode ->> -stream -xڭn8}H+1YlvL,<ݴZcdHoՒ"X7<Wdҋ*4|u}[0v뀷}?U V@.oV\ -ƕM/e7[Fk6[y7ǻ\udl}>˷?l*(hlωQH,\*farCdvlEՍ gn<?UW"'5-I
}p]ׇLu 83A[];.-ξCs{تѷͩ2+<IhЮFOWB)qJr(`Q
:O'ˢl}JC_7 )<C~xaΓT;`>nlsxp8&V\V^`8|N:rO Nmjs:$up*dJψ-nKMh©
Nj_r<Qu,߳M9KMPƒZ>hJ")n3<ڕcq"e0|,E'MV=24&45(nS۱< !PR:;ׅj:6_jviY"b -C8;ҟƇ
@Ok9m]jUm+T(j\}39{M@q)sIq=l3>]&G3CNԚSa*z;+\ AS?r;,b(qΎ:/ 4'>^DZF
1o#gqZ0&Fɓ0kRMjż%Xrjɒ1Kc}$Ӿend+!eRP[dhqiЯ?Z o/ -1X}Vvertjcqh'z~EB;ذE;LjuDįH!o<jP\ - -҃ZP,de }ba!e8nA<:4e<g[VI!$,@ -?sh{vw[=݁šrG -2eeA-(Br^PvʰS>v Cc8gg26vsG\> ԂR%"NB}l HjndLlA6I
:=͘ -!Sq{7!sRk<ll=CծxJSD5 -ղ4Pl`VS(g˙tH̩o N"n0<\L3j>OwQ<ϗA>?<P<1\*1(paM} zZdpan: -iRcsJ?)cɁ7C-AYy/disg]MD'US{-ke%UPzODKNG8drX#8rA7JG?Qq sŽcB[S!2{+ksOv.^nk'' -m}[;[QN~o*ܭ+=Mғ%Rk+Pj1Ȱ WB;-Hr ~@#P^_[2(Ly -GUFa$⾻ߋ1f5dZCc(0,`KN/evZxs9wsmF^c< Gj^UI8ڱJk>?PRg|</>ݤe#L穔{\WY$0jS[ót5 -F`>ϭz45 ^cZ/yp1W f"gZYlXE_ޖcX}H->zb
mbTFx{%\S=ި|&<A%20gF-endstream +/Length 2985 +/Filter /FlateDecode +>> +stream +xڭko6{?66zfwޡh=`~cFV#ˁ$wÒ-b>9_Wb*HUJhpz8~r{:m6QVWBI&BɻMY+{.Z]n"N֊ma9>f77=P,"i4*1Fj+%L' SDZ's%J&+'x<&2Y"Z.? +֭ >li,,i2Xvnt
cQi#vЏO0<W{j_h2;?R7 HuUB-1K=]G0Boм@_\o`h.o:۾}CUphiyBls?/,&6Wp/"'p$a0@@(Aj[;k(ր
zQTU(MI@Z!AW4gsAp0B>^c붞 +p߬eh[^XFp^jGq-K:O'@ǨBE
}DϪ'%4`D|O'wFڨ9B:83Q95^!8j.KS[Ɯ `9 GoF( +)l
t҂\@έn0u~8Pv\J/;Xe}sR,X}yE_`wFBRt7kSՐEEc]ÍEY~PV:;5Ǣ]Zg6muQcLX1/O\LJ@۟7q9ۡ,]nUm+ÈI2rϺ C[0:Q("vz8 ށt\ipEmmYĖPRk.8&"@XЃqe)z'tCnE4 "e<= wM'$EhN|j<5jH6SL0ւW4
1 +MA`,O5j֒D2ˆZcu͌Pz+6>;'ޝ&KrY&M臾 Bv@V]z5@ۭ휉evnʬ1
a)Jf9t) +B$~9B95p(XG
+ +!a +j~D])*EsJm*o ȧ)Ձ|r@c/TZ;-b3Y>G+"(u +(+:ӃZ,tfe3}x{~1y(P;>WO",B^2t)8LL`^/CU"9fk}epPQ+NQv;b\)\)M$䠐p^BK(; -$&L$u`m~ՌOx{1!cIvzeFlwV2NY"eKi顐hVS(g+^$@Է'Do6ς_Ow~~ϧjݫWsjx75%< +RܻjU&z蟹jOXFLruM=;(<K</%LQv"|{|`.FUo`mfw_^<LN)RQC@9jr +~@F#mX+^ T-7+59.'oT}!-:Qf-[)uN#G5SDd*GЉZ +
nlLDȐoH?>2n +3G2tU
BnpdSU2OT@tv& HmCR2wuCA_wgVT +]2QܝtX!=\Qbkg@Kk$sla2§赯wOiSEH^;ՔOHFa$CߟriA:4_O{in!:T'
*]Jrae\NOC\
<=Zۃ>.,cWE}s}չk;?Hv֕>0YweeSPH~na& +|/q8MѾkN#8ɍpAó0&Mkn90 +qy𥁇acWC/uK5xg@\С$K%G_u
nWM2:4̠Thشosk?&@=~jc +jLjr&3pJ`7hyׅ*XsʝVXHX_OO|LH|j=K5`Q("%20᳟-`±endstream endobj 928 0 obj << /Type /Page @@ -7859,46 +7859,39 @@ endobj /D [928 0 R /XYZ 74.4095 793.4011 null] >> endobj 931 0 obj << -/D [928 0 R /XYZ 74.4095 557.3018 null] +/D [928 0 R /XYZ 74.4095 531.3748 null] >> endobj 932 0 obj << -/D [928 0 R /XYZ 74.4095 528.917 null] +/D [928 0 R /XYZ 74.4095 505.785 null] >> endobj 933 0 obj << -/D [928 0 R /XYZ 74.4095 501.2001 null] +/D [928 0 R /XYZ 74.4095 480.8633 null] >> endobj 934 0 obj << -/D [928 0 R /XYZ 74.4095 472.1472 null] +/D [928 0 R /XYZ 74.4095 454.6055 null] >> endobj 935 0 obj << -/D [928 0 R /XYZ 74.4095 444.4303 null] +/D [928 0 R /XYZ 74.4095 429.6837 null] >> endobj 936 0 obj << -/D [928 0 R /XYZ 74.4095 414.9336 null] +/D [928 0 R /XYZ 74.4095 402.9821 null] >> endobj 937 0 obj << -/D [928 0 R /XYZ 74.4095 369.2192 null] +/D [928 0 R /XYZ 74.4095 360.0629 null] >> endobj 927 0 obj << -/Font << /F63 220 0 R /F28 173 0 R /F35 193 0 R /F70 552 0 R /F69 561 0 R /F65 558 0 R /F74 555 0 R /F88 715 0 R >> +/Font << /F63 220 0 R /F35 193 0 R /F28 173 0 R /F70 552 0 R /F69 561 0 R /F65 558 0 R /F74 555 0 R /F88 715 0 R >> /ProcSet [ /PDF /Text ] >> endobj 942 0 obj << -/Length 2563 +/Length 2560 /Filter /FlateDecode >> stream -xڥ]o82H}Kl7[4]. njFIn7ʒ,; -43ηL?9KTDgI aNְ+v}wij4̌QY0ұ<zw).Z[Q*/[[}뻎DJPiI>M&qDf&0U:,L$r7Qaom]eр(ھZ6v}y$}Ů&̄үܥGEwI{ҝ%0U&sWyj4~̥lB)$Ee glŗ>oml8QtNl;_L,mm|J<1_@Yf$Q,W -
bi0^$N"}Cr\rZ|7|.A';巹J/{{6mğ.kZؐ -:P'"LPZĻ("#~M0Η.$_pc~3mjuA r8 -+] 4|SAOe4ۖտrt8x*8pe{(+h.ꂲY] 7D.%rش]xBa
GKn -%v"$EQF& -XwOHm"_J0'(@'ց0>3Q,+tV
ߡLu("rs+UޠL0Bj'OmE -sEDG -/FBj - -t<`:@c9*yvtctM´Jm(K$x{c8@ȝ9]btۜ+:Lgqq<ص>y+עxIɈUM$#?NKwxNe('T+!r?m0X\֪vd׃{(6׆Ptن:6bGNF&NU9PO
廉Ĩ+MCLs)'~zɢtGpit3I#Iendstream +xڭY_o8:R")iR4M{Mv=1c@E>p$N;hr&%*T"ӳ$a ~N0+w}gifHacyvsT/$
T8_h!Sij[Rj=wWݱ:ajLs2*eBM2[D24&M7IdđnLJWԣ0IDſuEңjjE1E#˼-vW?oL(]z\t*^2
Se2wHee<"Q9[TGuOXXP|ىO,@r?-_lu'؛'[ohw+/|K[ۢm/PeY/PqL,Jbw7'Al7x-㹨W41<?k@!'|s9Qjm9ؘu >"/܁/Gҙ^B]x|!εopޕ uL2L32nzga`i +繣vBj.m7c_NVm4d";Z\1z&%x ]&!a3r2%aIuTt|@RġI'%nzcϏ}N4غo߷Om%n8xd[:GGy
㙭[c7t[lul*wRE}.~|3cr3Vtdx$ @ubU; +NpN7~sKA{_K}o8dؚæ{Y(-
BO
`HM/t+zBNVL%iO:%mvܽwԇjU~Sڂ_j>'Q MQ>$¦$TuaΎ9ڂM<Dt< |
