From 2e7756e5245738b41413f3a2b91f126e04d3900a Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Mon, 11 Aug 2008 12:43:23 +0000 Subject: spelling typos. --- LaTeX/chapters/implementierung.tex | 44 +- LaTeX/chapters/simulator.tex | 10 +- LaTeX/chapters/titlepage.tex | 2 +- LaTeX/diplomarbeit.pdf | 4395 ++++++++++++++++++------------------ LaTeX/revision.tex | 2 +- 5 files changed, 2217 insertions(+), 2236 deletions(-) diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex index b385850..e811ff3 100644 --- a/LaTeX/chapters/implementierung.tex +++ b/LaTeX/chapters/implementierung.tex @@ -92,7 +92,7 @@ Hierbei stellt \textit{key} den Variablennamen- und \textit{val} den Variablenwe \textit{VSSerializablePrefs} implementiert das Interface \textit{VSSerializable} und kann somit alle enthaltenen Daten in eine Datei abspeichern beziehungsweise laden. Auf die Serialisierung und Deserialisierung von Simulationen wird spter genauer eingegangen. -Die Klasse \textit{VSDefaultPrefs} erweitert \textit{VSSerializablePrefs} und initialisiert bei Instantiierung automatisch alle verfgbaren Simulationsvariablen (bereits schon \"{u}ber 160) mit ihren Standardwerten. Dort sind auch alle Spracheinstellungen abgelegt. Sollte jemand den Simulator in eine andere Sprache, zum Beispiel ins Englische, bersetzen wollen, so mu er lediglich diese Datei und die Protokoll-Klassen (mehr dazu spter) editieren. Die Spracheinstellungen sind nmlich in einem \textit{VSPrefs}--Objekt als versteckte String-Variablen abgespeichert. Spracheinstellungen fr Protokolle wurden in den Protokollklassen direkt angegeben, da dies mehr Komfort fr den Protokollentwickler bietet und fr jede neue Textausgabe nicht stndig \textit{VSDefaultPrefs.java} editiert werden muss. +Die Klasse \textit{VSDefaultPrefs} erweitert \textit{VSSerializablePrefs} und initialisiert bei Instantiierung automatisch alle verfgbaren Simulationsvariablen (bereits schon \"{u}ber 160) mit ihren Standardwerten. Dort sind auch alle Spracheinstellungen abgelegt. Sollte jemand den Simulator in eine andere Sprache, zum Beispiel ins Englische, bersetzen wollen, so muss er lediglich diese Datei und die Protokoll-Klassen (mehr dazu spter) editieren. Die Spracheinstellungen sind nmlich in einem \textit{VSPrefs}--Objekt als versteckte String-Variablen abgespeichert. Spracheinstellungen fr Protokolle wurden in den Protokollklassen direkt angegeben, da dies mehr Komfort fr den Protokollentwickler bietet und fr jede neue Textausgabe nicht stndig \textit{VSDefaultPrefs.java} editiert werden muss. Alle Variablen die als Prefix \textit{lang}, \textit{keyevent}, \textit{div} oder \textit{col} im Namen tragen, sind versteckte Variablen und werden in einem Editor nicht angezeigt. Im Expertenmodus sind hingegen nur Variablen die mit \textit{lang} und \textit{keyevent} beginnen versteckt. Somit lassen sich im Expertenmodus weitere Variablen vom Anwender editieren. @@ -123,7 +123,7 @@ F \label{fig:PackageEvents} \end{figure} -Jedes programmierbare Ereignis mu, bevor es vom Simulator verwendet werden kann, in der statischen Klasse \textit{VSRegisteredEvents} registriert werden. Da sich die Anzahl der verfgbaren Ereignisklassen des Simulators bei Laufzeit nicht ndert, gibt es keine Instanzen von \textit{VSRegisteredEvents}. Alle Methoden und Klassenattribute sind hier statisch. Wenn beispielsweise eigene Ereignisse implementiert werden, dann mssen alle neuen Ereignisse per Hand in die Datei \textit{VSRegisteredEvents.java} bernommen- und der Simulator neu kompiliert werden. +Jedes programmierbare Ereignis muss, bevor es vom Simulator verwendet werden kann, in der statischen Klasse \textit{VSRegisteredEvents} registriert werden. Da sich die Anzahl der verfgbaren Ereignisklassen des Simulators bei Laufzeit nicht ndert, gibt es keine Instanzen von \textit{VSRegisteredEvents}. Alle Methoden und Klassenattribute sind hier statisch. Wenn beispielsweise eigene Ereignisse implementiert werden, dann mssen alle neuen Ereignisse per Hand in die Datei \textit{VSRegisteredEvents.java} bernommen- und der Simulator neu kompiliert werden. In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschieden, die jeweils in verschiedenen Paketen liegen (Abbildung \ref{fig:PackageEvents}): @@ -149,7 +149,7 @@ Alle Ereignisse, die das Interface \textit{VSCopyableEvent} implementieren, k Alle Ereignisklassen erweitern die abstrakte Klasse \textit{VSAbstractEvent} und mssen folgende abstrakten Methoden implementieren: \begin{itemize} - \item \textit{abstract public void onInit()}: Bevor ein Ereignisobjekt vom Simulator verwendet werden kann, mu es initialisiert werden. Je nach Ereignis knnen hier verschiedene Werte initialisiert werden. Diese Methode wird pro Ereignisobjekt nach Erstellung nur ein einziges Mal ausgefhrt. + \item \textit{abstract public void onInit()}: Bevor ein Ereignisobjekt vom Simulator verwendet werden kann, muss es initialisiert werden. Je nach Ereignis knnen hier verschiedene Werte initialisiert werden. Diese Methode wird pro Ereignisobjekt nach Erstellung nur ein einziges Mal ausgefhrt. \item \textit{abstract public void onStart()}: Diese Methode wird jedes Mal ausgefhrt, wenn das Ereignis eintritt. Sie stellt somit das Kernstck eines Ereignisses dar. \end{itemize} @@ -218,7 +218,7 @@ Als Resultat kann das Prozessabsturzereignis nach Belieben via GUI programmiert- \subsection{Funktionsweise} -Das Paket \textit{core.time} auf Abbildung \ref{fig:PackageCoreTime} stellt lediglich die Klassen fr die Vektor- und Lamportzeitstempel zur Verfgung. Fr die normale lokale Prozesszeit wird aus Performancegrnden keine eigene Klasse, sondern ein einfaches \textit{long}-Attribut des Prozessobjektes verwendet. +Das Paket \textit{core.time} auf Abbildung \ref{fig:PackageCoreTime} stellt lediglich die Klassen fr die Vektor- und Lamportzeitstempel zur Verfgung. Fr die normale lokale Prozesszeit wird aus Performance-grnden keine eigene Klasse, sondern ein einfaches \textit{long}-Attribut des Prozessobjektes verwendet. \begin{figure}[h] \centering @@ -253,13 +253,13 @@ Erw Der Task-Manager speichert anschlieend in der globalen Warteschlange die Nachrichtenempfangsereignisse. Die Nachricht kommt bei einem Empfngerprozess an, sobald das Ereignis fr den Empfang eintritt. Fr die korrekte Implementierung der Lamport- und Vektor-Zeitstempel wird jeder Nachricht automatisch eine Referenz auf die Lamport- sowie auf die Vektorzeit des sendenden Prozesses als Attribut beigefgt. Fr die berprfung des Protokolls wird in jeder Nachricht auch der Klassenname des jeweiligen Protokolls abgespeichert. -Eine Instanz von \textit{VSInternalProcess} reprsentiert einen simulierten Prozess. Ein \textit{VSInternalProcess} stellt alle vom Simulator intern verwendeten Methoden zur Verfgung, whrend ein \textit{VSAbstractProcess} lediglich Methoden hat, die der Protokollentwickler fr die Erstellung eigener Protokolle verwenden darf. Da \textit{VSAbstractProcess} abstrakt ist und hiervon keine Instanz gebildet werden darf, muss fr 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 Verfgung gestellt. Beispielsweise darf mit \textit{getTasks()} nur vom Simulator intern auf die Prioritts-Warteschlangen zugegriffen werden, whrend man im Protokoll-API selbiges vermeiden sollte und auch gar nicht direkt mglich ist. Hierfr htte man auch ein Stub-Objekt \textit{VSProcessStub} implementieren knnen. Da aber so gut wie alle paar Millisekunden auf die Methoden von \textit{VSInternalProcess} zugegriffen wird, wurde hier aus Performancegrnden der Weg ber eine Vererbungungsstufe preferiert. +Eine Instanz von \textit{VSInternalProcess} reprsentiert einen simulierten Prozess. Ein \textit{VSInternalProcess} stellt alle vom Simulator intern verwendeten Methoden zur Verfgung, whrend ein \textit{VSAbstractProcess} lediglich Methoden hat, die der Protokollentwickler fr die Erstellung eigener Protokolle verwenden darf. Da \textit{VSAbstractProcess} abstrakt ist und hiervon keine Instanz gebildet werden darf, muss fr 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 Verfgung gestellt. Beispielsweise darf mit \textit{getTasks()} nur vom Simulator intern auf die Prioritts-Warteschlangen zugegriffen werden, whrend man im Protokoll-API selbiges vermeiden sollte und auch gar nicht direkt mglich ist. Hierfr htte man auch ein Stub-Objekt \textit{VSProcessStub} implementieren knnen. Da aber so gut wie alle paar Millisekunden auf die Methoden von \textit{VSInternalProcess} zugegriffen wird, wurde hier aus Performance-grnden der Weg ber eine Vererbungungsstufe preferiert. -Alle einstellbaren Prozessvariablen werden von der Klasse \textit{VSPrefs} vererbt. Damit bei Neuberechnungen die Variablen nicht dauernd ber eine \textit{HashMap} von \textit{VSPrefs} zugegriffen werden mu, speichert \textit{VSInternalProcess} aus Performancegrnden einige Variablen als lokale Kopie ab. Zum Beispiel wird fr die lokale Prozesszeit nicht auf das \textit{HashMap}-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} beziehungsweise die lokalen Kopien auf den neusten Stand gebracht. Selbiges gilt fr weitere Variablen wie zum Beispiel der Uhrabweichung eines Prozesses. +Alle einstellbaren Prozessvariablen werden von der Klasse \textit{VSPrefs} vererbt. Damit bei Neuberechnungen die Variablen nicht dauernd ber eine \textit{HashMap} von \textit{VSPrefs} zugegriffen werden muss, speichert \textit{VSInternalProcess} aus Performance-grnden einige Variablen als lokale Kopie ab. Zum Beispiel wird fr die lokale Prozesszeit nicht auf das \textit{HashMap}-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} beziehungsweise die lokalen Kopien auf den neusten Stand gebracht. Selbiges gilt fr weitere Variablen wie zum Beispiel der Uhrabweichung eines Prozesses. \subsection{Beispiel fr die Erstellung von Prozessereignissen} -Anhand der Prozessabsturz- und Wiederbelebungsereignisse lt sich wie folgt sehr gut demonstrieren, wie intern Ereignisse angelegt werden knnen: +Anhand der Prozessabsturz- und Wiederbelebungsereignisse lsst sich wie folgt sehr gut demonstrieren, wie intern Ereignisse angelegt werden knnen: \begin{code} void createCrashAndRecoverExample(VSTaskManager taskManager, VSInternalProcess process) { @@ -290,7 +290,7 @@ 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 zurckgegriffen. Das wird alles vom API automatisch gemacht. -Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche fr die Protokollimplementierungen zustndig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verfgung, die von allen Protokollen verwendet werden knnen. Jedes Protokoll hat im Paket \textit{protocols.implementations} seine eigene Klasse, die von \textit{VSAbstractProtocol} erbt. Im Prinzip besitzt jedes Prozessobjekt von jedem Protokoll seine eigene Instanz. Bei \textit{10} Protokollen und \textit{3} beteiligten Prozessen werden also \textit{30} Protokollobjekte verwendet. Jedes Protokollobjekt verwaltet sowohl die Server- als auch die Clientseite eines Protokolls auf einmal. Dabei merkt sich \textit{VSAbstractProtocol} anhand eines Flags ob der aktuelle Kontext server- oder clientbezogen ist und fhrt dementsprechend beim Eintreffen von Ereignissen die Server- beziehungsweise Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} berprft auch, ob ein Client oder ein Server berhaupt aktiviert ist. +Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und \textit{protocols.implementations} dargestellt, welche fr die Protokollimplementierungen zustndig sind. \textit{VSAbstractProtocol} stellt lediglich gemeinsame Methoden und Attribute zur Verfgung, die von allen Protokollen verwendet werden knnen. 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 fhrt dementsprechend beim Eintreffen von Ereignissen die Server- beziehungsweise Clientmethoden des Protokolls auf. \textit{VSAbstractProtocol} berprft auch, ob ein Client oder ein Server berhaupt aktiviert ist. \begin{figure}[h] \centering @@ -301,12 +301,12 @@ Auf Abbildung \ref{fig:PackageProtocols} sind die Pakete \textit{protocols} und Es ist bereits bekannt, dass Protokolle im Prozesseditor editierbare Variablen haben knnen. Da \textit{VSAbstractProtocol} von \textit{VSAbstractEvent} erbt, was wiederum von \textit{VSSerializablePrefs} erbt (und \textit{VSSerializablePrefs} erweitert \textit{VSPrefs}), werden alle Protokollvariablen einfach in die Mutterklasse \textit{VSPrefs} abgelegt. Zum Beispiel kann mit \textit{super.setBoolean(``test'', true);} eine neue Protokollvariable \textit{test} mit dem Standardwert \textit{true} angelegt werden. Diese Variable erscheint dann automatisch im Prozesseditor und kann vom Anwender konfiguriert werden. -Da der Simulator dafr ausgelegt wurde eigene Protokolle zu implementieren, werden im Folgenden alle verfgbaren Protokoll-API-Methoden etwas ausfhrlicher als gewohnt beschrieben. Jede Protokollklasse mu die folgenden Methoden implementieren: +Da der Simulator dafr ausgelegt wurde eigene Protokolle zu implementieren, werden im Folgenden alle verfgbaren Protokoll-API-Methoden etwas ausfhrlicher als gewohnt beschrieben. Jede Protokollklasse muss die folgenden Methoden implementieren: \begin{itemize} \setlength{\itemsep}{-2mm} - \item Einen ffentlichen (\textit{public}) Konstruktor. Der Konstruktor mu angeben, ob bei dem gegebene Protokoll der Client oder der Server die Anfragen startet. - \item \textit{abstract public void onClientInit()}: Bevor das Protokollobjekt benutzt werden kann, mu es initialisiert werden. Diese Methode wird vor dem ersten Verwenden des Protokolls innerhalb einer Simulation ausgefhrt. In der Regel werden hier Protokollvariablen unter Verwendung von \textit{VSPrefs} und Attribute der Protokollklasse initialisiert. Die hier initialisierten Protokollvariablen lassen sich vom Benutzer im Prozesseditor des jeweiligen Prozesses editieren. + \item Einen ffentlichen (\textit{public}) Konstruktor. Der Konstruktor muss angeben, ob bei dem gegebene Protokoll der Client oder der Server die Anfragen startet. + \item \textit{abstract public void onClientInit()}: Bevor das Protokollobjekt benutzt werden kann, muss es initialisiert werden. Diese Methode wird vor dem ersten Verwenden des Protokolls innerhalb einer Simulation ausgefhrt. In der Regel werden hier Protokollvariablen unter Verwendung von \textit{VSPrefs} und Attribute der Protokollklasse initialisiert. Die hier initialisierten Protokollvariablen lassen sich vom Benutzer im Prozesseditor des jeweiligen Prozesses editieren. \item \textit{abstract public void onClientReset()}: Diese Methode wird jedes Mal ausgefhrt, wenn die Simulation zurckgesetzt wird. \item \textit{abstract public void onClientStart()}: Diese Methode wird nur bentigt, wenn der Client immer die Anfragen startet. Diese Methode generiert in der Regel immer eine Clientanfrage, die via \textit{VSMessage}-Objekt an alle anderen beteiligten Prozesse verschickt wird. \item \textit{abstract public void onClientRecv(VSMessage message)}: Diese Methode wird jedes Mal Ausgefhrt, wenn eine Servernachricht \textit{message} bei dem Client eintrifft. @@ -314,16 +314,16 @@ Da der Simulator daf \item \textit{public String toString()}: Diese Methode ist nur optional. Hiermit lassen sich die Loggnachrichten eines Protokolls anpassen. Wenn diese Methode in einer Protokollimplementierung ausgelassen wird, so wird stets die \textit{toString}-Methode der Mutterklasse \textit{VSAbstractProtocol} verwendet. \end{itemize} -Fr alle hier aufgelisteten Client-Methoden sind auch die korrespondierenden Server-Methoden anzugeben. Die Server-Methoden sind analog zu den Client-Methoden aufgebaut, wobei lediglich \textit{Client} durch \textit{Server} ausgetauscht werden mu. +Fr alle hier aufgelisteten Client-Methoden sind auch die korrespondierenden Server-Methoden anzugeben. Die Server-Methoden sind analog zu den Client-Methoden aufgebaut, wobei lediglich \textit{Client} durch \textit{Server} ausgetauscht werden muss. Jede Protokollklasse bekommt folgende Methoden von \textit{VSAbstractProtocol} vererbt, welche allesamt vom Protokollentwickler verwendet werden knnen: \begin{itemize} \setlength{\itemsep}{-2mm} \item \textit{pubic void sendMessage(VSMessage message)}: Hiermit verschickt das Protokoll eine Nachricht. - \item \textit{pubic final boolean hasOnServerStart()}: Hiermit lt sich bestimmen, ob der Server- oder der Client bei dem aktuellen Protokoll die Anfragen startet. - \item \textit{pubic final boolean isServer()}: Hiermit lt sich bestimmen, ob der aktuelle Prozess das aktuelle Protokoll serverseitig aktiviert hat. - \item \textit{pubic final boolean isClient()}: Hiermit lt sich bestimmen, ob der aktuelle Prozess das aktuelle Protokoll clientseitig aktiviert hat. + \item \textit{pubic final boolean hasOnServerStart()}: Hiermit lsst sich bestimmen, ob der Server- oder der Client bei dem aktuellen Protokoll die Anfragen startet. + \item \textit{pubic final boolean isServer()}: Hiermit lsst sich bestimmen, ob der aktuelle Prozess das aktuelle Protokoll serverseitig aktiviert hat. + \item \textit{pubic final boolean isClient()}: Hiermit lsst sich bestimmen, ob der aktuelle Prozess das aktuelle Protokoll clientseitig aktiviert hat. \item \textit{pubic final void scheduleAt(long time)}: Diese Methode stellt einen Wecker dar, der zur angegebenen lokalen Prozesszeit eintritt. Nach Ablauf des Weckers wird, abhngig ob der aktuelle Kontext client- oder serverseitig ist, \textit{onClientSchedue} beziehungsweise \textit{onServerSchedule} ausgefhrt. \item \textit{pubic final void removeSchedules()}: Entfernt alle gesetzten Wecker des aktuellen Kontextes (Server oder Client). \item \textit{pubic final int getNumProcesses()}: Gibt die totale Anzahl an der Simulation beteiligten Prozesse zurck. @@ -362,7 +362,7 @@ In der Regel werden in Protokollen auch Nachrichten (\textit{VSMessage}) verschi \setlength{\itemsep}{-2mm} \item \textit{public VSMessage()}: Der Standardkonstruktor fr die Erstellung einer neuen Nachricht. \item \textit{public int getMessageID()}: Gibt die Nachrichten-ID zurck. - \item \textit{public boolean equals(VSMessage message)}: Hiermit lt sich berprfen, ob eine weitere Nachricht die selbe NID besitzt (wobei es sich dann um die selbe Nachricht handeln wrde). + \item \textit{public boolean equals(VSMessage message)}: Hiermit lsst sich berprfen, ob eine weitere Nachricht die selbe NID besitzt (wobei es sich dann um die selbe Nachricht handeln wrde). \end{itemize} Folgende weitere Methoden von \textit{VSMessage} knnen bei Erhalt einer Nachricht verwendet werden: @@ -374,7 +374,7 @@ Folgende weitere Methoden von \textit{VSMessage} k \item \textit{public VSAbstractProcess getSendingProcess()}: Gibt eine Referenz auf den Senderprozess zurck. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig. \item \textit{public long getLamportTime()}: Gibt die Lamportzeit des Senderprozesses zurck. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig. \item \textit{public VSVectorTime getLamportTime()}: Gibt die Vektorzeit des Senderprozesses zurck. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig. - \item \textit{public boolean isServerMessage()}: Hiermit lt sich entscheiden, ob es sich um eine Server- oder eine Clientnachricht handelt. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig. + \item \textit{public boolean isServerMessage()}: Hiermit lsst sich entscheiden, ob es sich um eine Server- oder eine Clientnachricht handelt. Diese Methode funktioniert nur bei empfangenen Nachrichten richtig. \end{itemize} Wenn ber eine Nachricht Daten verschickt werden sollen, so werden die von \textit{VSPrefs} vererben Methoden verwendet. @@ -383,7 +383,7 @@ Wenn Im Folgenden wird die Implementierung des zuverlssigen Multicast-Protokolls \textit{VSReliableMulticastProtocol.java} als Beispiel aufgefhrt. Die Funktionsweise des Protokolls wurde bereits in Kapitel 2.5.10 beschrieben. Client- und Serverseite werden in der selben Klasse implementiert. -Im Konstruktor mu 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; @@ -547,7 +547,7 @@ Beim Starten des Simulators wird auf die Main-Methode, welche sich in \textit{VS \label{fig:PackageProtocols} \end{figure} -\textit{VSSimulatorVisualization} greift auf Java's Grafikbibliothek Java2D zurck und ist aus Performancegrnden 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 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. 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. @@ -557,7 +557,7 @@ Die Klasse \textit{VSCreateTask} wird vom Ereigniseditor verwendet. Der Ereignis \subsection{Threads und Zeitsynchronisierung} -Ziel vom Simulator ist es bis auf jede Millisekunde genau simulieren zu knnen. Jede simulierte Sekunde soll relativ zur echten Zeit fortschreiten. Die Simulationsabspielgeschwindigkeit lt sich bei den Simulationseinstellungen unter ``Abspielgeschwindigkeit der Simulation'' (Float: \textit{sim.clock.speed}) einstellen. Damit dies gewhrleistet wird, mu folgendes bercksichtigt werden: +Ziel vom Simulator ist es bis auf jede Millisekunde genau simulieren zu knnen. Jede simulierte Sekunde soll 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: \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). @@ -600,7 +600,7 @@ Der Simulator serialisiert nur notwendige Daten, und nicht jedes existierende Ob \item \textit{public void deserialize(VSSerialize serialize, ObjectInputStream ois)}: Diese Methode wird bei jedem Deserialisierungsvorgang aufgerufen (beim 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 existieren, in mehrfacher Ausfhrung behandelt (in eine Datei abgespeichert) werden. Bei Kreissverweisen (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, sodass 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. 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 existieren, 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, sodass 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. \begin{figure}[h] \centering @@ -631,7 +631,7 @@ Der folgende Quelltext-Ausschnitt zeigt eine Beispielimplementierung von \textit } \end{code} -Vor- und nach der eigentlichen Objektserialisierung wird jeweils ein boolesches Flag serialisiert, welches auf \textit{true} gesetzt wird, sobald in spteren Simulator-Versionen (was relativ unwahrscheinlich, aber mglich ist) weitere zu serialisierende Klassenattribute hinzukommen. Eine Deserialisierung kann die Flags dann abfragen und separat behandeln. Somit bleiben ltere bereits abgespeicherte Simulationen stets zur neusten Version des Simulators kompatibel. Wenn ein Flag auf \textit{true} gesetzt wird, dann kann unter den neuen Attributserialisierungen ein weiteres Flag gesetzt werden. Somit knnen beliebig viele Erweiterungen in die Serialisierung Einzug halten. +Vor- und nach der eigentlichen Objektserialisierung wird jeweils eine boolesche Flagge serialisiert, welches auf \textit{true} gesetzt wird, sobald in spteren Simulator-Versionen (was relativ unwahrscheinlich, aber mglich ist) weitere zu serialisierende 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. 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 Objektserialisierungen zurckgreifen knnen. Danach wird ein \textit{prefs} und \textit{someOtherSerializableObject} serialisiert. Die Deserialisierung folgt genau den Umgekehrten weg. Wobei hier zuerst die Instanzen der Klassen auf normalen Weg erstellt werden und dann nachtrglich die relevanten Attribute deserialisiert und den Objekten zugewiesen werden. Hierbei werden auch mithilfe von \textit{VSSerialize} mehrere Referenzen auf das selbe Objekt korrekt behandelt. diff --git a/LaTeX/chapters/simulator.tex b/LaTeX/chapters/simulator.tex index 7dd24f0..3c854b3 100644 --- a/LaTeX/chapters/simulator.tex +++ b/LaTeX/chapters/simulator.tex @@ -9,7 +9,7 @@ \label{fig:NeuesFenster} \end{figure} -Der Simulator lt sich mit dem Befehl \textit{java -jar VS-Sim.jar} starten und prsentiert sich danach wie auf Abbildung \ref{fig:NeuesFenster}. Fr die Erstellung einer neuen Simulation wird im Men ``Datei'' (Abbildung \ref{fig:DateiMenue}) der Punkt ``Neue Simulation'' ausgewhlt, wo anschlieend das Einstellungsfenster fr die neue Simulation erscheint. Auf die einzelnen Optionen wird spter genauer eingegangen und es werden nun nur die Standardeinstellungen bernommen. Die GUI mit einer frischen Simulation sieht aus wie auf Abbildung \ref{fig:NeuErstellteSimulation}. +Der Simulator lsst sich mit dem Befehl \textit{java -jar VS-Sim.jar} starten und prsentiert sich danach wie auf Abbildung \ref{fig:NeuesFenster}. Fr die Erstellung einer neuen Simulation wird im Men ``Datei'' (Abbildung \ref{fig:DateiMenue}) der Punkt ``Neue Simulation'' ausgewhlt, wo anschlieend das Einstellungsfenster fr die neue Simulation erscheint. Auf die einzelnen Optionen wird spter genauer eingegangen und es werden nun nur die Standardeinstellungen bernommen. Die GUI mit einer frischen Simulation sieht aus wie auf Abbildung \ref{fig:NeuErstellteSimulation}. \subsubsection{Die Menzeile} @@ -118,7 +118,7 @@ Farben helfen dabei die Vorg \label{fig:Sidebar} \end{figure} -Mithilfe der Sidebar lassen sich Prozessereignisse programmieren. Oben auf Abbildung \ref{fig:Sidebar} ist der zu verwaltende Prozess selektiert (hier mit der PID 1). In dieser Prozessauswahl gibt es auch die Mglichkeit ``Alle Prozesse'' auszuwhlen, womit die Ereignisse aller Prozesse gleichzeitig verwaltet werden knnen. Unter ``Lokale Ereignisse'' versteht man diejenigen Ereignisse, die auftreten, wenn eine bestimmte lokale Zeit des dazugehrigen Prozesses eingetreten ist. Die darunterliegende Ereignistabelle listet alle programmierten Ereignisse (hier noch keine vorhanden) mitsamt Eintrittszeiten sowie den PIDs auf. +Mithilfe der Sidebar lassen sich Prozessereignisse programmieren. Oben auf Abbildung \ref{fig:Sidebar} ist der zu verwaltende Prozess selektiert (hier mit der PID 1). In dieser Prozessauswahl gibt es auch die Mglichkeit ``Alle Prozesse'' auszuwhlen, womit die Ereignisse aller Prozesse gleichzeitig verwaltet werden knnen. Unter ``Lokale Ereignisse'' versteht man diejenigen Ereignisse, die auftreten, wenn eine bestimmte lokale Zeit des dazugehrigen Prozesses eingetreten ist. Die darunter liegende Ereignistabelle listet alle programmierten Ereignisse (hier noch keine vorhanden) mitsamt Eintrittszeiten sowie den PIDs auf. \begin{figure}[h] \centering @@ -151,7 +151,7 @@ In der Sidebar gibt es neben dem Ereignis-Tab einen weiteren Tab ``Variablen''. Das Loggfenster (Abbildung \ref{fig:NeuErstellteSimulation}, unten) protokolliert in chronologischer Reihenfolge alle eingetroffenen Ereignisse. Auf Abbildung \ref{fig:Loggfenster} ist das Loggfenster nach Erstellung der Demo-Simulation zu sehen, an welcher 3 Prozesse beteiligt sind. Am Anfang eines Loggeintrages wird stets die globale Zeit in Millisekunden protokolliert. Bei jedem Prozess werden ebenso seine lokale Zeiten sowie die Lamport- und die Vektor-Zeitstempel aufgefhrt. Hinter den Zeitangaben werden weitere Angaben, wie beispielsweise welche Nachricht mit welchem Inhalt verschickt wurde und welchem Protokoll sie angehrt, gemacht. Dies wird spter noch anhand von Beispielen demonstriert. -Mit dem Deaktivieren des Logging-Schalters lt sich das Loggen von Nachrichten temporr ausstellen. Mit deaktiviertem Loggen werden keine neuen Nachrichten mehr ins Loggfenster geschrieben. Nach Reaktivieren des Schalters werden alle ausgelassenen Nachrichten nachtrglich in das Fenster geschrieben. Ein deaktiviertes Loggen kann zu verbessertem Leistungsverhalten des Simulators fhren (z.B. kein Rucklen; ist vom verwendeten Computer, auf dem der Simulator luft, abhngig). Dieser Umstand ist der sehr langsamen Java-Implementierung der JTextArea-Klasse zu verdanken, die schnelle Updates nur sehr trge durchfhrt. +Mit dem Deaktivieren des Logging-Schalters lsst sich das Loggen von Nachrichten temporr ausstellen. Mit deaktiviertem Loggen werden keine neuen Nachrichten mehr ins Loggfenster geschrieben. Nach Reaktivieren des Schalters werden alle ausgelassenen Nachrichten nachtrglich in das Fenster geschrieben. Ein deaktiviertes Loggen kann zu verbessertem Leistungsverhalten des Simulators fhren (z.B. kein Rucklen; ist vom verwendeten Computer, auf dem der Simulator luft, abhngig). Dieser Umstand ist der sehr langsamen Java-Implementierung der JTextArea-Klasse zu verdanken, die schnelle Updates nur sehr trge durchfhrt. ber den Schalter ``Expertenmodus'' wird der Expertenmodus aktiviert beziehungsweise deaktiviert. @@ -164,7 +164,7 @@ Mit dem Deaktivieren des Logging-Schalters l \label{fig:SimulationExpertenmodus} \end{figure} -Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen einfachen- und einen Expertenmodus. Der Simulator startet standardmig im einfachen Modus, sodass sich der Anwender nicht mit der vollen Funktionalitt des Simulators auf einmal auseinandersetzen mu. Der einfache Modus ist bersichtlicher, bietet jedoch weniger Funktionen an. Der Expertenmodus eignet sich mehr fr erfahrene Anwender und bietet dementsprechend auch mehr Flexibilitt. Der Expertenmodus kann ber den gleichnamigen Schalter unterhalb des Loggfensters oder ber die Simulationseinstellungen aktiviert oder deaktiviert werden. Auf Abbildung \ref{fig:SimulationExpertenmodus} ist der Simulator im Expertenmodus zu sehen. Wenn der Expertenmodus mit dem normalen Modus verglichen wird, dann fallen einige Unterschiede auf: +Der Simulator kann in zwei verschiedenen Modi betrieben werden. Es gibt einen einfachen- und einen Expertenmodus. Der Simulator startet standardmig im einfachen Modus, sodass sich der Anwender nicht mit der vollen Funktionalitt des Simulators auf einmal auseinandersetzen muss. Der einfache Modus ist bersichtlicher, bietet jedoch weniger Funktionen an. Der Expertenmodus eignet sich mehr fr erfahrene Anwender und bietet dementsprechend auch mehr Flexibilitt. Der Expertenmodus kann ber den gleichnamigen Schalter unterhalb des Loggfensters oder ber die Simulationseinstellungen aktiviert oder deaktiviert werden. Auf Abbildung \ref{fig:SimulationExpertenmodus} ist der Simulator im Expertenmodus zu sehen. Wenn der Expertenmodus mit dem normalen Modus verglichen wird, dann fallen einige Unterschiede auf: \subsubsection{Neue Funktionen in der Sidebar} @@ -223,7 +223,7 @@ Ob sich das Ereignis f \subsubsection{Nachrichtenempfang sowie Antwortnachrichten (nicht-programmierbar)} -Nachdem ein Prozess eine Nachricht empfngt wird zuerst berprft, ob er das dazugehrige Protokoll untersttzt. Wenn der Prozess das Protokoll untersttzt wird geschaut, ob es sich um eine Client- oder eine Servernachricht handelt. Wenn es sich um eine Clientnachricht handelt, so mu der Empfngerprozess das Protokoll serverseitig untersttzen und virce versa. Wenn alles passt, dann fhrt der Empfngerprozess die vom Protokoll definierten Aktionen aus. In der Regel berechnet der Prozess einen bestimmten Wert und schickt ihn ber eine Antwortnachricht zurck. Es knnen aber auch beliebig andere Aktionen ausgefhrt werden. Welche dies sind hngt vom Protokoll ab. +Nachdem ein Prozess eine Nachricht empfngt wird zuerst berprft, ob er das dazugehrige Protokoll untersttzt. Wenn der Prozess das Protokoll untersttzt wird geschaut, ob es sich um eine Client- oder eine Servernachricht handelt. Wenn es sich um eine Clientnachricht handelt, so muss der Empfngerprozess das Protokoll serverseitig untersttzen und virce versa. Wenn alles passt, dann fhrt der Empfngerprozess die vom Protokoll definierten Aktionen aus. In der Regel berechnet der Prozess einen bestimmten Wert und schickt ihn ber eine Antwortnachricht zurck. Es knnen aber auch beliebig andere Aktionen ausgefhrt werden. Welche dies sind hngt vom Protokoll ab. \subsubsection{Callback-Ereignisse (nicht-programmierbar)} diff --git a/LaTeX/chapters/titlepage.tex b/LaTeX/chapters/titlepage.tex index 8bad886..677d83f 100644 --- a/LaTeX/chapters/titlepage.tex +++ b/LaTeX/chapters/titlepage.tex @@ -79,7 +79,7 @@ Aachen, \today \\ \textbf{\LARGE Geheimhaltung} \vspace*{1.5cm} -Diese Diplomarbeit darf weder vollst\"{a}nding noch auszugsweise ohne schriftliche Zustimmung des Autors, des betreuenden Referenzen bzw. der Fachhochschule Aachen vervielf\"{a}ltigt, ver\"{o}ffentlicht oder Dritten zug\"{a}nglich gemacht werden. +Diese Diplomarbeit darf weder vollst\"{a}ndig noch auszugsweise ohne schriftliche Zustimmung des Autors, des betreuenden Referenzen bzw. der Fachhochschule Aachen vervielf\"{a}ltigt, ver\"{o}ffentlicht oder Dritten zug\"{a}nglich gemacht werden. \newpage diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf index ad6ef63..693e180 100644 --- a/LaTeX/diplomarbeit.pdf +++ b/LaTeX/diplomarbeit.pdf @@ -523,13 +523,14 @@ endobj /ProcSet [ /PDF ] >> endobj 233 0 obj << -/Length 892 +/Length 891 /Filter /FlateDecode >> stream -xڍUn8+tF =H`)qR-@ƀ~YAX{=> / *)!ip`z_ʘe;^"K,:ǻ_2H5e{&gip쿄o)glY}=:,ICYe -"/t "'UjM"{kJ1#"-B)U7>,"466U/Q}WՓ-ʒ {kU>?H} a0C ?XY͊vQ~:dJ؄U2rkRnΎy1ێV,+H?ƅZ$Y[%ڀh$ -qPhb`=yEv$m+ŵxG[n˸k~謩, hShՒD`9BO϶e[Ndzo޿"ȸQ7PTڂ\fYT $wN",F%_-'f(@6}qOb@{^Q|=#{&Z=1 uXY~]mL$k%$4Բ ]S1 ꂔlrw( _A!kO#VqJϘYL)`1RXoPf᫧!KoN I{뻗LpjB7U?Fi1z]%'=]ɞrg4b?\G1[nV."qn_պ{ʙ>ԯi5 0+=m'[wS?4@endstream +xڍUn:+X$E]U,Z"JQH5@3JSߠ( 1guuB=>ly(ƭ]*4؝g!-$y].23{~2ETU\G2.r= .W桘< bAQ[Ru1$ճzE!&HPI %aws+%#TkXdQ1XYEw$R +}mN\ՍIZ!;OL]vr!A:顑Vh +_zhE.ŒbhZ15YI(7\I| > endobj 287 0 obj << -/Length 2231 +/Length 2229 /Filter /FlateDecode >> stream @@ -831,14 +832,10 @@ x կn^;2I:ڹҔ[ 0pZ!- :ubi$uȈ EyS^Ỗmq9ӃPde(|R6$4բPCZ~[jGOχ;"2T݇H58)ojV<Fl]E"*Rc3Pl$ƣ&"y0Z'i AC+qz3ƾLߗw)x S1)d+Rkf`NoD>֖yNcvl9JWBZ)Ϥ#L*$y TNWy}Z]cy^2$v/ƯzcSvǵH vQlx'$@pEc8LP0<>߿V"h,v\"0/<1팲Сh*7UfS`8pģp(<duVfQkܵ?[0ֶ´}Stq\jz,6oG'En|a]o-C<휉rkmOZ<:ǣU$i!3>">/4&r4ILiJJxE1w`}ҢrT(`RBV*,T<]u~a[>2\YI,twdlTY5K/;ǣUI@s [QMoer[ڬzEkD8xQ'm~` ~&gVQzQ͛h|3Q8{ݯ8_.ì+(Қ,t'N^J3ߣԜ -\%x -K CV-8:uE+h>p'4l^S?=P@wGK -Z׸pE$U.2/ov|=]st,ӎEh`ciT wۖ߭eC0*bPN3Yą@p -VT'!f>gPۊMHdq1U1j#GmWӛZ8_.M=,b\~˭BYR%is -tcE\c{! o'h -udG&vP&AQ\9|PUI&Mv~}pR{U.?FNu2(K|ɐ:RrSxiC*0^;UJCl22 mxݨt }1z2 Ÿiy`8vp2*7WM8S\ru/>۫8fpl 7~%\k͘:b&vՇDF|; 5n yUYLLXC5endstream +Q%\gX"'$zPTģUi 3ѣ)h +=/1agP!:0/j fW7mn~E4pCc*1ƶֽ<.'0 @#duX>~}2eST|7єft]qp_W cq9\YWP5YNv*5 )fxG9%K0ph),!Bn y46~`Oϩ獟`;P@ǣ%@k\p*[՗7Sޞ}fw:i"40ޱ4msֲ +CV1(B L8sx+MאU 3to3(mE&$q CiP8ģU@D(GcL n=He.P:a[_ݩ7h֗o ed3i޲!Գ/"g܊,;+U={=`;^@ǣUNxZɤ@LiFSj=Sqw 6km"Y`.vCzn}mN 7o4V&F0ّI/wP1WdrmUnb߻ev -#ih0¨^pi菑SD)C&_2 aNԫ^ڐ +/NՅ7 ƅB#^7+]8C_ '6H1pn/ṊMU\]Njj7ٱD1[DÍiE |3f*N&]!>΢p9EC@[C^Uu+S0}endstream endobj 286 0 obj << /Type /Page @@ -1276,7 +1273,8 @@ x '|erAPj T3V/>2꒱:v]_jY9Y)geFhlh4V3w .`S`*  My'{38$a61f&f0/Z6%~@6)&[LME]Dv L:wB:#O64de;eΦYYnﲑEs -eXySWMy;8.|iDZwV3ILھr=S%%jK*꒹CNzY< z:I0L 8J4!v4vRMhʐ55G4?4X3r߂Ǧ 4pڨ#זyV\ofyN~8RcK7hF N3>&E @&U(i:3f iͭQ2_)Ǎ;g0=j&eW xSx*i:u Yf$ޝQXw}MP*$BVb[ڳ^Ѥgico5;d%Ç)Hg^i0_ر: "W6tZA^J"R*GjDJS0tb>ֲT<- i]!p6/fzendstream +eXySWMy;8.|iDZwV3ILھr=S%%jK*꒹CNzY< z:I0L 8J4!v4vRMhʐ55G4?4X3r߂Ǧ 4pڨ#זyV\ofyN~8RcK7hF N3>&E @&U(OQuf@:Ӛ[eSSw&aB#{Lqc/ˮ&叽Ut2J)I;o埛UH̹Åp!ŜV3g +.g=IDBjwɨKeSVm;@76 ϲ`?T?q-cq%uD=l:L.)%D T|ՈNo%S!4`HDŔ}ﭭeytZ@ZU Bl_fyendstream endobj 375 0 obj << /Type /Page @@ -1416,7 +1414,8 @@ akTA .ViĢ"SWHl*2Bf*n+k-$4&g=|+N@%ZXQ`F~N?4Kr>_dmLޞPٿ}*avJkX TBr*#06<[ /؈X4yakT澸Cs˓-2sub76w6ڎ#NX hǝ|v/X&:J&U?XQ PIB 8QNJF3۴q 6SD'&ajk⤣/Nʼn/NШ009kBv=-8}R"I]#\CxƛXIDJe8sƨW~[Ť0Yu9û2k$4lʆpxX (FDXu4>"aPu7N?Cq)8s՜G?䇶 9PI]c5 X8QޕU ꉽ/jѨc@9~ơ5A :]l"T$L)FsK6PNuER;RJ׼h1ВHƦ&QGlў]xVH<naP4(θ?H# Q͙y,&wI!6Pڮ(:Z~ް;8a{o0Ԏ+֨|f}7' -ܴެ7AtK+J¸NpV':  {/Z؛FX1äakTS,< Ç].+fg !w@-B\!?e&߽Svsna\\r*X =)S=JqKhv`NLg%Tއ h^c3d+~wjmendstream +ܴެ7AtK+J¸NpV':  {/Z؛FX1äakTS,< Ç].+fg !w@-B\!?e&߽Svsna\\r*X =)S=JqKѨ$R=XKԽ8 +gWvmendstream endobj 411 0 obj << /Type /Page @@ -1652,15 +1651,15 @@ endobj /Filter /FlateDecode >> stream -xT=o0 +8\(iMQt+t(磈] ҿ_82|83H`@SiQܿ(vql԰!;;>i^&tYߟT6E Iu@ɞkNbRw~=p\1 cB*0KfAB[JυF -ªcGTl/.]/=荧Age]i1OexʠpqQ<=:KeCljeXlu aVH;8O-KiD-w2ǃkC8p ]Z뱵@Աb7i -{QB{7bw"C|ܥ|<[@_ۼO.~f-g/8撁4<냳( |`ԗtj>RvO%oXBǼ۟u^s |Q?۝ITL0 /?DZendstream +xTn0 +xl{p%RE[$F/A,E"N~Ejx0"g槮Ӣ>yTFc5P԰x,4/?l8-4{I$&uAGсq4dtq@TR'a:̵ e ?΃ߏbw'> endobj 470 0 obj @@ -1677,7 +1676,7 @@ endobj >> endobj 472 0 obj -460 +452 endobj 465 0 obj << /Type /Annot @@ -1745,14 +1744,17 @@ endobj /Filter /FlateDecode >> stream -xN0 y=4# u*Bˈ}4ZgF=4r~/T =ԋ_VHzQ)YocDJx)@/R]9$rAHQH/5a'i\$hU?4DZsYV;º*[>|PS/@,4d@ӋvpѼFWեu;E"-xcv3!_üŬ5,}Fj.bVW9<[mEUqomuPemb\ih2eC4{y]Te\{}\t^2)W/b5̯@zŨ8#G7 +8 )| +Y La- 7pD7[:pHp {-q*YA^6@K  +B|jZ%Tp'endstream endobj 479 0 obj << /Producer (GPL Ghostscript 8.61) -/CreationDate (D:20080811133908Z00'00') -/ModDate (D:20080811133908Z00'00') +/CreationDate (D:20080807105751+02'00') +/ModDate (D:20080807105751+02'00') >> endobj 480 0 obj @@ -1769,7 +1771,7 @@ endobj >> endobj 482 0 obj -548 +499 endobj 477 0 obj << /D [475 0 R /XYZ 74.4095 793.4011 null] @@ -1831,15 +1833,18 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 493 0 obj << -/Length 1161 +/Length 1163 /Filter /FlateDecode >> stream -xڭWKs6WH͔0ޏⱝI:m%ʁ6!)E9"Uw iJ鴣 -?I$u*1NXdggRʼnl8*Or2,QR*~]q"yXi &y(>?eyƍM9yϱrw9MUnw9}#L8qT0#eGei1ǎ(i1J+9ad)J|A)o挦km5.y_p <>{A}s~*gPu2_H2J!YfФ֏n0x '8wu$;)u r&F$lk-%@6p頌Q.aF&7[MFR&58 -l0.JRCvF';%ZhS.ʳµRX+ﱬ} +J"+2pamlhUOH~ kZ((i;GK9e/)-!I!3NlA%0F>*7* !LM|jSv[y r.`+t*{j%;{UGk>KΡX:f H~k x};` !*aTRFϺɉd#FsdgC>Ig60x '8)~ہ:u r&F$lk-%@6pA\F&7[MFR&58 +l0.JRCvF';%ZhS.ʳµRX+ﱬ} +J"+2pamlh@u\~~״WQ́Q)GK9e/)-!I!3NlA%0F> +=HNi)ǰڔd:ׁrssd]WwPףD+E4h{UGki>;Ρ0,L3pE\GW7̏-[pT=:'XnnMzFbr,Ĭx^UAu"8>*u|)wE<-7QE$.87yKX${0\.Zorы r3'J S4Twj_ D>>1x> endobj 533 0 obj << -/Length 1303 +/Length 1302 /Filter /FlateDecode >> stream -xڽ]o6ݿB2PI-C!݊umrȚ%ȯ)ɲ%' xb?hI$M@'ƂrA h? zh;%CdpspSvz~[[,#M2) /mrh/vW/޼_\ cNQJ)AQ1/-|j8!Zk\moڮ҉KJ|D#&pÃ9/|8/:(aIƒr#&ϋߎ%$yBHAXW "'1A"c)̸G. .w 68H!R7wFW%Iؕܘ(8sM4SPnfTn=vXz_e}hiX*X2p=cTlC(mY7vb9c'F nH1!CKԯM& -j !o7yq4D$n2ppE4BXM~؏qs|wfiYPOuE0{ǩ> A!t,8?a'_Fe*e61Bpb=5t\ϩcyӞ$qגCvZKjmFk;(7(B-Qa둷4kS]91/=r uzn -OU'v{_FN> -kP9U(D.8[!妰՛e3FÝN;Ws -kU"YaL1y 'HXxޢUzϿWm eM]#ٴv$ ˴xv瑓` ׏m 7ۼZ٦˲Eo09lni4,:v69,X׺Z`BȖ?"EJ)L,L@6lw|IJA(!iFiJ4J0bW}F$MiT-$HTryۑ O1ʱ0V,(Z[qwЪ1Y11݂26^WG;$S2 }I.0%t.'F\D0ARDCQ˦ʖƪ(:iGG uL \@JM}1<}՘"֬؆t4 [~ A}hR}`v6J5֬E)%ñx:CaQfmkjK-6~c{\8n{1ߚ]nYUP#ʋq2C}2ht"j(0IƗ^ʶn4`iOAZ! (9V[I?-)ynIbS9"x}'! +AƊqkJ ++XM>Xח I\T|]\iƃl|X7?ϋU/xO#'ny ]RRvQf qp8ߔ~LypsڥnQ +uOU~(rp)Ӎfm3߮Ժv5a׿]Pfe .g푍l;8X둑d W]'q[x_7Em<2mWTU/?\`lGdl`%h> :v6~a\uՂ8SOOli$wLqcX۶A+K{`M}b#[m"/C#3utj*O~2wm_u]`5AO5"LăF3) >@ Mulendstream endobj 532 0 obj << /Type /Page @@ -2433,18 +2438,23 @@ endobj /ProcSet [ /PDF /Text /ImageC ] >> endobj 550 0 obj << -/Length 2333 +/Length 2337 /Filter /FlateDecode >> stream -xڭYYsܸ~ׯ#ʃs$rbrR}YO7p쪤\F_A?xi` D\񠂵Mn=vꇷ -2'I=2ʙ8 + *ff+,l9L<<_Mǒ,IiE $ R$93g1.~o<(~ g"e\Ehx:J}sQY΢(NE8rCڑ\RLe -$˳,Ci`<1۳@U[J8rûFMQYcޙNtޢwx.GE@Rȵx/.`J$,JH20=w;SǶI*82e(q0?e2 i̛b >tUQ<0PbyT g)$`S̭GZ5jJY.cy) ər0 = f: X|C-!*'eϥ!nyxc~,c2P wUgN{MK}Qa"9\dJ\s}إ4<y؎ϡi#yյAE<մﻶ {؏ukՕ&΢Hc=薶TL,LIAoDBYJ(&/#DoR2Q - g*\qbơI̸燚a$O`JmuM@EAnTG1h+n틽K (b9K8NԦB2-1ș "]SFV[CmH -G-ʓ$1`舥4nWԚ~ɍ.|:vkh6$?ԍ5{C5tr緞GYw0IHU ,JbEsr[Z#hmb&vlҏ*33aif<49:BMۙ|C^ Bf8]nߠb0ޠ "˫w FѿA5+ɥPNj4Dy&D=0JWDt[Ѯ$F {E^e+q_xU5v$H9ul'VάBMnsޡb{Ƹ3}<D@vPu͙(#:^kGa̱%&];ڒ=;>~n2t*^f 4`t1 Al-/?k]}jvQȻC@ob9^dsmyeђ[RHVCY6[!wF.ݎ?/J -"^z$WfR?S>MWF0>yamľiS칷0y[k~:S!cKq O(q=㬒3~͜]N*[\$(!&fM4q#|ەzd PHBnf[ 'W+Yz ,6gK!& /Tj=ӑ_9Tg.@ϩROCۓ!WI.0]2|{l!RfM>\ :,"'bW]Rwgt#LΠ%ZD.+G팦P$1l# ˣTdXv[a^N k GkLfQύuOax$v -*cƬAv[0r*|[x(,SFdZ,M+ 0+[ZTۢ1'g;ZQ.:6G|yU|I3&fS݈V}.i `p>~D9~ LT +?-ٞ%.$biGeg*\򡱀CN h,Dps?Ǯ4b54^kD}`47DKIs"i9a-laSST;A-ٶ/c -%%u"gxW\q|œeG?͘׾|KqQ煓 wendstream +xڭrQx9ybO2fƓTz SIPKR-}EgA@wn<`ǃ4 +#AKXp<4,;ڍ'L]>AIwPƌޕ~*zPz#l%&flu:|͚ա.[vn8,̒D|QQF0ItJXa̳_ J xϰa!s4*õR_|UQs x%HXPf DgY܂(%,dma.B<,>4\-WD) SKx$r, ` \,{w!y~OF IbSdt#o`*?ȳ0XLo 㩾%̌ +s]$§ג5K 0EQ",8_ +H8Rc'2 sND'OΔJhiP֑Ldq^8 +#YNL>eH +]牸\9oXr YNT߸v $+̠ X}];OkVm]kZVjC5mVy~Vzw[W(v+M}tQtJWF4XR$TQZxmEHBGyӕP@A|P|Y=G63 ݽLgKW᭍awk.^FiTw*a360Gzʁ 0[Hv:iXnp ,NӠcȎP=0o{~:o—=tbU ^9cX_f@ 0Ң$݄k̰8}>[Mow0p  +8'W6-g(S}`4kCU` +w)jy@z5!+R7Kb1ZP.eI`T=l/8q#`8]0]Y)OqFPaTI_ +"v lskՑz0] XNa mfrXcz_SXYjHHR-˪cXm`U@aS4c~`Uit>9hjhuhpOljBr=/?28~[>&2X0>#əyqv>>.ND8#ۗ.=~UyE9~]> endobj 578 0 obj << -/Length 2192 +/Length 2187 /Filter /FlateDecode >> stream -xڵYs b3B}Kyv4s{3@Y\IDH}kwN2~X GiwŁ4ũ^lW__WF؞J|K4a=/?V'1AtR5{YmOcNEg(6K&fDZ,D9Eg/yo}{U =TD%߫B~+e΅^D2QlYbZ -Y{PࣙD?S0p(uYJQ6]NC*[x|9 xnAjZ聾Eƛo,!F`̽6e27^b-/eGY 3sq4BZ\%6u%f-$QwwѷQxšx \u^}*KPh:^+Q D- Q&HSw <6CjJc1*YQzU=aXd%vc%eLjLH:V:ryӷ>{8SCf~J`މ^Γ:Mԃ˄B8ʮhj:endstream +xڵr}b9U"M<]I9Ud1$-S$gUק pxLKn۹"$E v/w/㯧ymlO?>}b' Ct1?qxzM[rfQl1gok=Ȏ_z֩C}(8`!jxhz8Q1e.4 +ɾUgzUlbz(%1Ȳy/sI=SF&eI1k)3٥&޳:YMACfHs`#{kߑ_=xM^^$Lה/Š0H_ogS]F~Ȉ=-DN…7SCt**TtLsL/ Ǖ}?c5{5CY`+ėO4Mhբ">2J '%:mRcS8>A;G};DDM +Xl&Ԩ0L ߺ,Oޅ.d%סVja-