summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2008-08-13 17:19:05 +0000
committerPaul Buetow <paul@buetow.org>2008-08-13 17:19:05 +0000
commit82f1965397411e0bbd1d59b8e657b0592dd472d3 (patch)
tree05a819126b4024c012ce97d5f68b6e065a3af7bb
parentefff967bb744b0697592e6108cb227baa58e9885 (diff)
foo
-rw-r--r--LaTeX/chapters/implementierung.tex76
-rw-r--r--LaTeX/diplomarbeit.pdf4492
2 files changed, 2257 insertions, 2311 deletions
diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex
index 083fb4c..fe68809 100644
--- a/LaTeX/chapters/implementierung.tex
+++ b/LaTeX/chapters/implementierung.tex
@@ -26,15 +26,15 @@ In diesem Kapitel wird auf die Implementierung des Simulators eingegangen. Der S
\label{tb:Pakete}
\end{table}
-Da es sonst den Rahmen sprengen wrde, soll im Folgenden der komplette Quelltext nicht bis in das letzte Detail behandelt werden. Der Quelltext erstreckt sich nmlich, einschlielich Kommentare, auf ber 15.000 Zeilen und ber 61 Dateien. Zudem ist die generierte Quelltext-Dokumentation (Javadoc) ber 2MB gro. Alle folgenden UML-Diagramme stellen aufgrund der bersichtlichkeit lediglich die wesentlichen Dinge dar. Alle Details lassen sich im Quelltext und der dazugehrigen Dokumentation einsehen. Die Paketstruktur des Quelltextes ist in Tabelle \ref{tb:Pakete}. in alphanumerischer Reihenfolge aufgefhrt.
+Im Folgenden wird der Quelltext auszugsweise behandelt. Der Quelltext erstreckt sich, einschlielich Kommentare, auf ca. 15.000 Zeilen Text und 61 Dateien. Der Umfang der generierten Quelltext-Dokumentationen im Javadoc-Format ist ca. 2MB gro. Alle folgenden UML-Diagramme stellen zwecks bersichtlichkeit lediglich die wesentlichen Sachverhalte dar. Alle weiteren Details k\"{o}nnen im Quelltext und der dazugehrigen Dokumentation eingesehen werden. Die Paketstruktur des Quelltextes ist in Tabelle \ref{tb:Pakete}. in alphanumerischer Reihenfolge aufgefhrt.
\section{Einstellungen und Editoren}
-Eine Simulation ist von einer Vielzahl von Einstellungen abhngig. Da auf diese Einstellungen in den weiteren Teilkapitel stets zurckgegriffen wird, macht es Sinn, die dazugehrigen Klassen zuerst zu betrachten.
+Der Verlauf einer Simulation ist von einer Vielzahl von Einstellungen abhngig. Da auf diese Einstellungen in Weiteren stets zurckgegriffen wird, werden die dazugeh\"{o}rigen Klassen zuerst betrachtet.
\subsubsection{Einstellungsobjekte}
-In Abbildung \ref{fig:PackagePrefs}. ist der Aufbau des Pakets \textit{prefs} zu sehen. In einer Instanz der Klasse \textit{VSPrefs} lassen sich viele verschiedene Daten als Variablen fr eine sptere Verwendung dynamisch ablegen und stellt somit einen Container fr diese Daten dar. In einem \textit{VSPrefs}-Objekt speichert der Simulator alle seine Einstellungen ab. Zudem besitzt jedes Prozessobjekt und jedes Ereignisobjekt fr lokale Einstellungen seine eigene Instanz von \textit{VSPrefs}. Spter wird noch erklrt, dass Protokollobjekte auch als Ereignisse eingesetzt werden, womit Protokolleinstellungen auch in einem \textit{VSPrefs}-Objekt abgespeichert werden k\"{o}nnen. Selbst Nachrichtenobjekte besitzt hiervon eine eigene Instanz, wobei hier die zu verschickenden Daten abgelegt werden.
+In Abbildung \ref{fig:PackagePrefs}. ist der Aufbau des Pakets \textit{prefs} zu sehen. In einer Instanz der Klasse \textit{VSPrefs} lassen sich viele verschiedene Daten als Variablen fr eine sptere Verwendung dynamisch ablegen, damit stellt somit einen Container fr diese Daten dar. In einem \textit{VSPrefs}-Objekt speichert der Simulator alle Einstellungen ab. Zudem besitzt jedes Prozessobjekt und jedes Ereignisobjekt fr lokale Einstellungen seine eigene Instanz von \textit{VSPrefs}. Spter wird gezeigt, wie Protokollobjekte auch als Ereignisse eingesetzt werden, womit Protokolleinstellungen auch in einem \textit{VSPrefs}-Objekt abgespeichert werden k\"{o}nnen. Auch Nachrichtenobjekte besitzt hiervon eine eigene Instanz dieser Klasse, um die zu verschickenden Daten zwischen zu speichern.
\begin{figure}[h]
\centering
@@ -43,11 +43,11 @@ In Abbildung \ref{fig:PackagePrefs}. ist der Aufbau des Pakets \textit{prefs} zu
\label{fig:PackagePrefs}
\end{figure}
-Jede Variable besteht aus einen Datentypen, einen Variablennamen und einer optionalen Beschreibung sowie einen Wert. Einige Datentypen untersttzen auch die Angabe von Minimal- und Maximalwerten (zum Beispiel besteht eine Prozentangabe aus einen Integerwert zwischen \textit{0} und \textit{100}), was mit Hilfe der \textit{VSPrefsRestriction}-Klasse implementiert wird. Da der Anwender beispielsweise bei Prozent ein \textit{\%} und bei Millisekunden ein \textit{ms} hinter der Variable sehen mchte, kann fr jede Variable auch ein optionaler Einheiten-String abgespeichert werden.
+Jede Variable hat einen Datentypen, einen Variablennamen, eine optionale Beschreibung sowie einen Variablenwert. Einige Datentypen untersttzen auch die Angabe von Minimal- und Maximalwerten (zum Beispiel besteht eine Prozentangabe aus einen Integerwert zwischen \textit{0} und \textit{100}), was mit Hilfe der Klasse \textit{VSPrefsRestriction} implementiert wird. Da der Anwender beispielsweise bei Prozent ein \textit{\%} und bei Millisekunden ein \textit{ms} hinter der Variable sehen mchte, kann fr jede Variable auch ein optionaler Einheiten-String abgespeichert werden.
-Eine Variablenbeschreibung wird fr die Darstellung im GUI verwendet, whrend der Variablenname eher fr die interne Verwendung vom Simulator verwendet wird. Zum Beispiel hat die Variable \textit{message.prob.outage} (Verlustwahrscheinlichkeit einer Nachricht) als Variablenbeschreibung ``Nachrichtenverlustw'keit''. Wenn fr eine Variable keine Beschreibung existiert so wird, wie in Abbildung \ref{fig:SimulationseinstellungenExperten}. anhand der Farbvariablen schon gesehen wurde, fr die Anzeige einer Variable der Datentyp und der Variablenname verwendet. Variablennamen verwenden die in Tabelle \ref{tb:VariablenPraefixe}. angegebenen Prfixkonventionen. Alle verfgbaren Typen wurden bereits in Tabelle \ref{tb:VariablenDatentypen}. aufgelistet. \textit{VSPrefs} stellt fr alle Variablentypen entsprechende Zugriffsmethoden zur Verfgung.
+Eine Variablenbeschreibung wird fr die Darstellung im GUI verwendet, whrend der Variablenname fr die interne Verwendung vom Simulator verwendet wird. Zum Beispiel hat die Variable \textit{message.prob.outage} (Verlustwahrscheinlichkeit einer Nachricht) als Variablenbeschreibung ``Nachrichtenverlustw'keit''. Wenn fr eine Variable keine Beschreibung existiert so werden f\"{u}r die Anzeige einer Variable der Datentyp und der Variablenname verwendet. Variablennamen verwenden die in Tabelle \ref{tb:VariablenPraefixe}. angegebenen Prfixkonventionen. Alle verfgbaren Datentypen wurden bereits in Tabelle \ref{tb:VariablenDatentypen}. aufgelistet. Die Klasse \textit{VSPrefs} stellt fr alle Variablentypen entsprechende Selektoren zur Verfgung.
-Im Folgenden werden nicht alle existierenden Methoden aufgelistet, da diese auch in der Quelltext-Dokumentation eingesehen werden knnen. Stattdessen werden die Methoden nur anhand des Integer-Datentyps verdeutlicht. Fr alle anderen Typen gilt fast alles analog. Fr Integer stehen in \textit{VSPrefs} folgende Methoden zur Verfgung:
+Im Folgenden werden einige der existierenden Methoden aufgelistet, eine komplette Liste kann in der Quelltext-Dokumentation eingesehen werden. Die Methoden werden anhand des Integer-Datentyps verdeutlicht. Fr Integer stehen in \textit{VSPrefs} folgende Methoden zur Verfgung:
\begin{itemize}
\setlength{\itemsep}{-2mm}
@@ -80,27 +80,27 @@ Im Folgenden werden nicht alle existierenden Methoden aufgelistet, da diese auch
\textit{sim} & Allgemeine Simulationsvariablen & \textit{Integer: sim.process.num = 3}\\
\end{tabular}
}
- \caption{Konventionen fr Variablennamen-Prfixe in \textit{VSDefautPrefs}}
+ \caption{Konventionen f\"{u}r Prfixe von Variablennamen}
\label{tb:VariablenPraefixe}
\end{table}
-Hierbei stellt \textit{key} den Variablennamen- und \textit{val} den Variablenwert dar. \textit{descr} ist eine optionale Variablenbeschreibung. Es knnen sowohl Java's Integer-Objekte, als auch Java's primitiver Integer-Typ \textit{int} verwendet werden. Ein \textit{int}-Wert wird intern allerdings als Integer-Objekt abgespeichert (fr eine sptere Serialisierung, mehr dazu aber spter) und macht somit keinen groen Unterschied. Die Methode \textit{getIntegerKeySet} gibt alle vorhandenen Integer-Variablennamen (\textit{key}s) als \textit{Set} zurck.
+Hierbei steht \textit{key} f\"{u}r den Variablennamen- und \textit{val} f\"{u}r den Variablenwert. \textit{descr} ist die optionale Variablenbeschreibung. Es knnen sowohl Java's Integer-Objekte, als auch Java's primitiver Integer-Typ \textit{int} verwendet werden. Ein \textit{int}-Wert wird intern zwecks Serialisierbarkeit als Integer-Objekt abgespeichert. Die Methode \textit{getIntegerKeySet} gibt alle vorhandenen Integer-Variablennamen (\textit{key}s) als \textit{Set} TODO zurck.
-\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} 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.
-\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 alle \textit{HashMap}-Objekte 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 Methoden eines \textit{HashMap}-Objektes synchronisiert sind, knnen alle Methoden von \textit{VSPrefs} aus verschiednenen Threads gleichzeitig verwendet werden.
-\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{VSSerializablePrefs} implementiert das Interface \textit{VSSerializable} und kann somit durch Serialisierung alle enthaltenen Daten in eine Datei abspeichern beziehungsweise wieder in den Speicher laden.
-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 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 bedeutet und fr jede neu programmierte Textausgabe nicht stndig \textit{VSDefaultPrefs.java} editiert werden muss.
+Die Klasse \textit{VSDefaultPrefs} erweitert \textit{VSSerializablePrefs} und initialisiert bei ihrer Instantiierung automatisch alle verfgbaren Simulationsvariablen mit Standardwerten. Hier sind auch alle Spracheinstellungen abgelegt. M\"{o}chte man den Simulator in eine andere Sprache (z.B. Englisch) bersetzen wollen, so muss lediglich diese Datei und die Protokoll-Klassen editiert werden. Die Spracheinstellungen sind einem referenzierten \textit{VSPrefs}-Objekt als versteckte String-Variablen abgespeichert. Spracheinstellungen fr Protokolle wurden in den Protokollklassen direkt angegeben, da dies mehr Komfort fr Protokollentwickler bedeutet und damit fr jede neu programmierte Textausgabe nicht \textit{VSDefaultPrefs.java} editiert werden muss.
-Alle Variablen die als Prfix \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.
+Alle Variablen die als Prfix \textit{lang}, \textit{keyevent}, \textit{div} oder \textit{col} im Variablennamen 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. Im Expertenmodus lassen sich so weitere Variablen vom Anwender editieren.
\subsubsection{Editorobjekte}
-Wie Variablen intern abgespeichert werden, ist bereits bekannt. Fr das Editieren der Variablen werden Editor-Objekte verwendet. In Abbildung \ref{fig:PackagePrefsEditors}. ist die Klassenstruktur des dazugehrigen Paketes \textit{prefs.editors} angegeben.
+Wie Variablen intern abgespeichert werden, ist nun bekannt. Fr das Editieren von Variablen werden Editor-Objekte verwendet. In Abbildung \ref{fig:PackagePrefsEditors}. ist die Klassenstruktur des dazugehrigen Paketes \textit{prefs.editors} angegeben.
-Die Basis eines Editors stellt die abstrakte Klasse \textit{VSAbstractEditor} dar, dem ein \textit{VSPrefs} Objekt zum Editieren bergeben wird. Ein Editor stellt alle verfgbaren nicht-versteckten Variablen des \textit{VSPrefs}-Objektes im GUI dar und bietet gleichzeitig die Mglichkeit, alle Variablen darber zu editieren. Fr das Editieren von Farbwerten wird auf \textit{VSColorChooser} zurckgegriffen. Die Klasse \textit{VSEditorTable} ist fr das \textit{JTable}-Objekt aus Java's Swing-Bibliothek (vgl. \cite{Swing}) zustndig, welches bei der graphischen Darstellung aller Variablen eingesetzt wird. Die abstrakte Klasse \textit{VSAbstractBetterEditor} wurde, wegen der bersicht, als Zwischenschritt eingefgt.
+Die Basis eines solchen Editors ist die abstrakte Klasse \textit{VSAbstractEditor}. Jedem Objekt dieser Klasse wird jeweils ein \textit{VSPrefs}-Objekt zum Editieren bergeben. Ein Editor stellt alle verfgbaren nicht-versteckten Variablen des \textit{VSPrefs}-Objektes im GUI dar und bietet die Mglichkeit diese Variablen zu editieren. Fr das Editieren von Farbwerten wird auf die Klasse \textit{VSColorChooser} zurckgegriffen. Die Klasse \textit{VSEditorTable} ist fr das \textit{JTable}-Objekt aus Java's Swing-Bibliothek (s. \cite{Swing}) zustndig, welches zur graphischen Darstellung aller Variablen eingesetzt wird. Die abstrakte Klasse \textit{VSAbstractBetterEditor} wurde zur Verbesserung der Wartbarkeit des Quelltextes als Zwischenklasse eingef\"{u}hrt.
\begin{figure}[h]
\centering
@@ -109,21 +109,22 @@ Die Basis eines Editors stellt die abstrakte Klasse \textit{VSAbstractEditor} da
\label{fig:PackagePrefsEditors}
\end{figure}
-Die Klasse \textit{VSSimulatorEditor} dient fr das Editieren der globalen Simulationseinstellungen und \textit{VSProcessEditor} fr das Editieren der Prozesseinstellungen sowie der dazugehrigen Protokollvariablen. Da diese beiden Klassen von \textit{VSAbstractBetterEditor} erben, knnen sie mit Hilfe von \textit{VSEditorFrame} in einem separaten Fenster angezeigt werden. Alternativ knnen die Editoren auch in der Sidebar im Tab ``Variablen'' angezeigt werden. In Abbildung \ref{fig:Simulationseinstellungen}. wurde bereits ein \textit{VSEditorFrame} in Aktion gesehen. In Abbildung \ref{fig:NeueSimulationVariablen}. wurde hingegen ein Prozesseditor in der Sidebar geffnet. Fr Protokolle gibt es keine separate Editor-Klasse, da sie bereits vom Prozesseditor aus editiert werden knnen. Dabei iteriert der Prozesseditor ber alle fr den jeweiligen Prozess verfgbaren Protokollobjekte und fgt deren Variablen in den Prozesseditor zustzlich ein. Somit erscheinen die Prozess- und die dazugehrigen Protokollvariablen im selben Editor und bieten dem Benutzer so eine bessere bersicht.
+Die Klasse \textit{VSSimulatorEditor} erlaubt das Editieren der globalen Simulationseinstellungen und der \textit{VSProcessEditor} das Editieren der Prozesseinstellungen sowie der dazugehrigen Protokollvariablen. Da diese beiden Klassen die abstrakte Klasse \textit{VSAbstractBetterEditor} erweitern, knnen sie mit Hilfe von \textit{VSEditorFrame} in einem separaten Fenster angezeigt werden. Alternativ knnen die Editoren auch in der Sidebar im Tab ``Variablen'' angezeigt werden. In Abbildung \ref{fig:Simulationseinstellungen}. wurde bereits ein \textit{VSEditorFrame} in Aktion gesehen. In Abbildung \ref{fig:NeueSimulationVariablen}. hingegen wurde ein Prozesseditor in der Sidebar geffnet. Fr Protokolle gibt es keine separate Editor-Klasse, da diese bereits im Prozesseditor editiert werden knnen. Hierbei iteriert der Prozesseditor ber alle dem jeweiligen Prozess verfgbaren Protokollobjekte und fgt deren Variablen in den Prozesseditor ein. Somit erscheinen die Prozess- und die dazugehrigen Protokollvariablen im selben Editor und bieten dem Benutzer eine bessere bersicht.
\section{Ereignisse}
-Fr jedes Ereignis existiert eine dazugehrige Klasse, welche die auszufhrenden Aktionen implementiert. Eine Instanz davon wird fr eine sptere Ausfhrung dem Task-Manager bergeben. Auf den Task-Manager wird spter noch genauer eingegangen.
-Jedes programmierbare Ereignis muss, bevor es vom Simulator verwendet werden kann, in der statischen Klasse \textit{VSRegisteredEvents} registriert werden. Der Simulator bezieht alle verf\"{u}gbaren Ereignisse aus \textit{VSRegisterEvents}, womit der Entwickler bei jeder Entwicklung eines neuen Ereignisses keine andere Stelle mehr im Quelltext des gesamten Simulators \"{a}ndern muss. 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.
+Fr jedes Ereignis existiert eine dazugehrige Klasse, welche die auszufhrenden Aktionen implementiert. Eine Instanz einer solchen Klasse wird fr eine sptere Ausfhrung dem Task-Manager bergeben.
+
+Jedes programmierbare Ereignis muss, bevor es vom Simulator verwendet werden kann, in der statischen Klasse \textit{VSRegisteredEvents} registriert werden. Der Simulator bezieht die Liste aller verf\"{u}gbaren Ereignisse aus \textit{VSRegisterEvents}, wodurch der Entwickler bei der Entwicklung eines neuen Ereignisses keine andere Stelle im Quelltext des Simulators \"{a}ndern muss. 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 statisch. Wenn beispielsweise eigene Ereignisse implementiert werden, dann mssen alle neuen Ereignisse per Hand in der Quelltext-Datei \textit{VSRegisteredEvents.java} bernommen werden, und der Simulator muss neu kompiliert werden.
\begin{figure}[h]
\centering
\includegraphics[width=13.5cm]{images/events}
- \caption{Die Pakete \textit{events} und \textit{events.*}}
+ \caption{Das Paket \textit{events.*}}
\label{fig:PackageEvents}
\end{figure}
-In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschieden, die jeweils in verschiedenen Paketen liegen (s. Abbildung \ref{fig:PackageEvents}.):
+In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschieden, die jeweils in einem unterschiedlichen Paket liegen (s. Abbildung \ref{fig:PackageEvents}.):
\begin{enumerate}
\item \textit{events.implementations}: In diesem Paket befinden sich alle Ereignisse, die ohne weitere Spezialbehandlung vom Simulator eingesetzt werden knnen und vom Benutzer direkt im Ereigniseditor programmierbar sind.
@@ -134,43 +135,43 @@ In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschied
\item \textit{events.internal}: In diesem Paket befinden sich alle Ereignisse, die vom Simulator intern verwendet werden.
\begin{itemize}
- \item \textit{VSAbstractInternalEvent}: Diese Klasse stellt weitere Methoden zur Verfgung, die von allen internen Ereignissen bentigt werden. Derzeit betrifft dies nur Methoden zur Serialisierung der gegebenen Objekte.
- \item \textit{VSMessageReceiveEvent}: Diese Klasse wird fr die Ankunft einer Nachricht bei einem Empfngerprozess bentigt. Sie kapselt die eigentliche Nachricht und berprft, ob der Empfngerprozess das zur Nachricht dazugehrige Protokoll versteht. Diese Klasse berprft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Logfenster bercksichtigt werden soll oder nicht.
- \item \textit{VSProtocolEvent}: Diese Klasse implementiert gleichzeitig vier verschiedene Ereignisse: Das Aktivieren/Deaktivieren eines Servers/Clients eines gegebenen Protokolls. Der Ereigniseditor berechnet anhand der verfgbaren Protokolle automatisch alle mglichen Kombinationen und bietet sie dem Anwender in seiner Auswahl an. Fr alle dieser vier Ereignisse wird jeweils ein Objekt von \textit{VSProtocolEvent} verwendet, jedoch mit jeweils anderen Attributwerten.
- \item \textit{VSProtocolScheduleEvent}: Diese Klasse wird fr die Wecker-Ereignisse bentigt. Wecker-Ereignisse knnen nur von Protokollen (mehr dazu spter) erstellt werden. \textit{VSProtocolScheduleEvent} besitzt eine Referenz auf das gegebene Protokoll und ruft bei Ereigniseintrittszeit entweder die Methode \textit{onServerScheduleStart} bei einem Server- oder \textit{onClientScheduleStart} bei einem Clientprotokoll auf.
+ \item \textit{VSAbstractInternalEvent}: Diese Klasse stellt weitere Methoden zur Verfgung, die von allen internen Ereignissen zur Serialisierung bentigt werden.
+ \item \textit{VSMessageReceiveEvent}: Diese Klasse wird fr die Ankunft einer Nachricht bei einem Empfngerprozess bentigt. Sie kapselt die eigentliche Nachricht und berprft, ob der Empfngerprozess das zur Nachricht gehrige Protokoll versteht. Diese Klasse berprft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Logfenster bercksichtigt werden soll oder nicht.
+ \item \textit{VSProtocolEvent}: Diese Klasse implementiert gleichzeitig vier verschiedene Ereignisse: Das Aktivieren beziehungsweise Deaktivieren eines Servers oder Clients eines gegebenen Protokolls. Der Ereigniseditor berechnet anhand der verfgbaren Protokolle automatisch alle mglichen Kombinationen und bietet sie dem Anwender in seiner Auswahl an. Fr alle dieser vier Ereignisse wird jeweils ein Objekt von \textit{VSProtocolEvent} verwendet, jeweils mit individuellen Attributwerten.
+ \item \textit{VSProtocolScheduleEvent}: Diese Klasse wird fr die Wecker-Ereignisse bentigt. Wecker-Ereignisse knnen nur von Protokollen erstellt werden. \textit{VSProtocolScheduleEvent} besitzt eine Referenz auf das verwendete Protokoll und ruft bei Ereigniseintrittszeit entweder die Methode \textit{onServerScheduleStart} bei einem Server- oder \textit{onClientScheduleStart} bei einem Clientprotokoll auf.
\end{itemize}
- \item \textit{protocols.implementations}: In diesem Paket befinden sich alle Protokollimplementierung. Jedes Protokoll besitzt hier seine eigene Klasse. Alle Protokolle erben hierbei von der in Abbildung \ref{fig:PackageEvents}. zu sehenden Klasse \textit{protocols.VSAbstractProtocol}. Da \textit{protocols.VSAbstractProtocol} von \textit{events.VSAbstractEvent} erbt, kann ein Protokollobjekt auch als Ereignis eingesetzt werden. Ein solches Ereignis ruft bei Eintritt entweder die Methode \textit{onServerStart} oder die Methode \textit{onClientStart} des Protokolls auf, was einer Server- beziehungsweise einer Clientanfrage entspricht (s. Kapitel 4.4.4.).
+ \item \textit{protocols.implementations}: In diesem Paket befinden sich alle Protokollimplementierung. Jedes Protokoll besitzt seine eigene Klasse. Alle Protokolle erben hierbei von der in Abbildung \ref{fig:PackageEvents}. zu sehenden Klasse \textit{protocols.VSAbstractProtocol}. Da \textit{protocols.VSAbstractProtocol} von \textit{events.VSAbstractEvent} erbt, kann ein Protokollobjekt auch als Ereignis eingesetzt werden. Ein solches Ereignis ruft bei Eintritt entweder die Methode \textit{onServerStart} oder die Methode \textit{onClientStart} des Protokolls auf, was einer Server- beziehungsweise einer Clientanfrage entspricht (s. Kapitel 4.4.4.).
\end{enumerate}
-Alle Ereignisse, die das Interface \textit{VSCopyableEvent} implementieren, knnen vom Anwender im Ereigniseditor mit einem Rechtsklick kopiert werden und mssen die Methode \textit{initCopy(VSAbstractEvent copy)} implementieren. Dort werden dann alle relevanten Attribute in das neue Ereignis \textit{copy} kopiert.
+Alle Ereignisse, die das Interface \textit{VSCopyableEvent} implementieren, knnen vom Anwender im Ereigniseditor mit einem Rechtsklick kopiert werden, des Weiteren mssen sie die Methode \textit{initCopy(VSAbstractEvent copy)} implementieren. Es werden dann alle relevanten Attribute in das neue Ereignis \textit{copy} kopiert.
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, 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 onInit()}: Bevor ein Ereignisobjekt vom Simulator verwendet werden kann, muss es initialisiert werden. Je nach Ereignis knnen verschiedene Werte initialisiert werden. Diese Methode wird pro Ereignisobjekt nach dessen Erzeugung 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}
-Des Weiteren werden folgende nicht-abstrakte Methoden von \textit{VSAbstractEvent} vererbt:
+Des Weiteren werden folgende nicht-abstrakte Methoden der Klasse \textit{VSAbstractEvent} geerbt:
\begin{itemize}
\item \textit{public void log(String message)}: Diese Methode schreibt eine Lognachricht in das Simulationslogfenster.
- \item \textit{public VSAbstractEvent getCopy()}: Diese Methode erstellt vom aktuellen Ereignis eine Kopie, worauf eine Referenz zurckgegeben wird. Alle Ereignisse, die kopiert werden knnen, mssen auch das Interface \textit{VSCopyableEvent} implementieren. Wenn ein Ereignis dies nicht tut und \textit{getCopy()} aufgerufen wird, dann wird die Ausnahme \textit{exceptions.VSEventNotCopyable} geworfen.
- \item \textit{public VSAbstractEvent getCopy(VSInternalProcess process)}: Diese Methode erstellt vom aktuellen Ereignis ebenso eine Kopie, jedoch mit dem Unterschied, dass das Ereignis einem anderen Prozess zugewiesen wird.
+ \item \textit{public VSAbstractEvent getCopy()}: Diese Methode erstellt vom aktuellen Ereignis eine Kopie, auf die eine Referenz zurckgegeben wird. Alle Ereignisse, die kopiert werden knnen, mssen auch das Interface \textit{VSCopyableEvent} implementieren. Wenn ein Ereignis dies nicht tut und \textit{getCopy()} aufgerufen wird, wird die Ausnahme \textit{exceptions.VSEventNotCopyable} ausgel\"{o}st.
+ \item \textit{public VSAbstractEvent getCopy(VSInternalProcess process)}: Diese Methode erstellt vom aktuellen Ereignis ebenfalls eine Kopie, mit dem Unterschied, dass das Ereignis einem anderen Prozess zugewiesen wird.
\end{itemize}
-Jede Ereignisklasse hat auerdem Zugriff auf folgende Attribute, die von \textit{VSAbstractEvent} vererbt werden:
+Jede Ereignisklasse hat auerdem Zugriff auf folgende Attribute, welche von \textit{VSAbstractEvent} geerbt werden:
\begin{itemize}
- \item \textit{protected VSPrefs prefs}: Eine Referenz auf das Simulationseinstellungsobjekt. Hierber lassen sich alle Simulationseinstellungen beziehen.
+ \item \textit{protected VSPrefs prefs}: Eine Referenz auf das Simulationseinstellungsobjekt. Hierber lassen sich alle Simulationseinstellungen abfragen.
\item \textit{protected VSAbstractProcess process}: Eine Referenz auf das Prozessobjekt des jeweiligen Prozesses, auf welches das Ereignis angewendet wird.
\end{itemize}
-Da \textit{VSAbstractEvent} die Klasse \textit{VSSerializablePrefs} erweitert, knnen alle Ereignisse mit allen ihren Variablen serialisiert werden.
+Da \textit{VSAbstractEvent} die Klasse \textit{VSSerializablePrefs} erweitert, sind alle Ereignisse mit allen ihren Variablen serialisierbar.
\subsubsection{Beispielimplementierung eines Ereignisses}
-Im Folgenden wird als Beispiel die Implementierung des Prozessabsturzereignisses \textit{VSProcessCrashEvent} behandelt. Da die dazugehrige Klasse keine Attribute besitzt, verbleibt hier auch die \textit{initCopy}-Methode mit leerem Rumpf. Wegen der Serializierung und Deserialisierung von Ereignisobjektten muss jede Ereignisklasse in \textit{onInit()} mit \textit{setClassname} den eigenen Klassennamen mitteilen. Bei der Deserialisierung von Ereignissen werden n\"{a}mlich Objekte anhand der Klassennamen dynamisch neu erstellt, wo der Klassenname stets bekannt sein muss. In \textit{onStart()} wird das eigentliche Ereignis ausgefhrt. Hier wird berprft, ob der Prozess bereits abgestrzt (hier eigentlich nicht notwendig, verbessert hier aber die Lesbarkeit) ist und gegebenenfalls wird der Prozess dann zum Absturz bewegt.
+Im Folgenden wird als Beispiel die Implementierung des Prozessabsturzereignisses \textit{VSProcessCrashEvent} behandelt. Da die dazugehrige Klasse keine Attribute besitzt, verbleibt auch hier die \textit{initCopy}-Methode mit leerem Klassenrumpf. Aufgrund der Serializierbarkeit von Ereignisobjektten muss jede Ereignisklasse in \textit{onInit()} mit \textit{setClassname} den eigenen Klassennamen mitteilen. Bei der Deserialisierung von Ereignissen werden n\"{a}mlich Objekte anhand der Klassennamen dynamisch neu erstellt, wobei der Klassenname stets bekannt sein muss. In \textit{onStart()} wird das eigentliche Ereignis ausgefhrt. Hier wird berprft, ob der Prozess bereits abgestrzt ist und gegebenenfalls zum Absturz gebracht.
\begin{code}
package events.implementations;
@@ -193,7 +194,8 @@ extends VSAbstractEvent implements VSCopyableEvent {
}
}
\end{code}
-Der Task-Manager berprft bereits, ob der Prozess abgestrzt ist oder nicht. Das heit, dass ein Ereignis bei einem abgestrztem Prozess gar nicht erst ausgefhrt wird. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches vom Task-Manager ausgefhrt wird, auch wenn der Prozess abgestrzt ist. Mit \textit{log} wird eine Nachricht (die ber \textit{prefs} bezogen wird) in das Logfenster geschrieben.
+
+Der Task-Manager berprft bereits, ob der Prozess abgestrzt ist oder nicht. Das f\"{u}hrt dazu, dass ein Ereignis bei einem abgestrztem Prozess gar nicht erst ausgefhrt wird. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches auch dann ausgefhrt wird, auch wenn der Prozess abgestrzt ist. Mit \textit{log} wird eine Nachricht (die ber \textit{prefs} bezogen wird) in das Logfenster geschrieben.
In der Datei \textit{events/VSRegisteredEvents.java} muss in der \textit{init}-Methode fr jedes Ereignis ein Eintrag existieren. Die \textit{init}-Methode wird einmal beim Starten des Simulators ausgefhrt:
@@ -210,8 +212,6 @@ public static void init(VSPrefs prefs_) {
}
\end{code}
-Als Resultat kann das Prozessabsturzereignis nach Belieben via GUI programmiert- und eingesetzt werden.
-
\section{Zeitformate, Prozesse, Nachrichten sowie Task-Manager}
Das Paket \textit{core.time} in Abbildung \ref{fig:PackageCoreTime}. stellt lediglich die Klassen fr die Vektor- und Lamport-Zeitstempel zur Verfgung. Fr die normale lokale Prozesszeit wird, aus Performance-Grnden, keine eigene Klasse, sondern ein einfaches \textit{long}-Attribut des Prozessobjektes verwendet.
@@ -223,7 +223,7 @@ Das Paket \textit{core.time} in Abbildung \ref{fig:PackageCoreTime}. stellt ledi
\label{fig:PackageCoreTime}
\end{figure}
-In Abbildung \ref{fig:PackageCore}. ist, stark vereinfacht, das Paket \textit{core} dargestellt. Fr jedes auszufhrende Ereignis wird eine Instanz von \textit{VSTask} bentigt, welche die Ereigniseintrittszeit als Attribut abgespeichert hat sowie eine Referenz auf das Objekt des auszufhrenden Ereignisses (\textit{VSAbstractEvent}) und dem Prozessobjekt (\textit{VSInternalProcess}) besitzt. Ein \textit{VSTask} merkt sich auch, ob es sich um ein globales oder ein lokales Ereignis handelt. Geplante \textit{VSTask}-Instanzen werden fr eine sptere Ausfhrung dem Task-Manager bergeben.
+In Abbildung \ref{fig:PackageCore}. ist das Paket \textit{core} dargestellt. Fr jedes auszufhrende Ereignis wird eine Instanz von \textit{VSTask} bentigt, welche die Ereigniseintrittszeit als Attribut abgespeichert hat. Die Instanz besitzt ebenso eine Referenz auf das Ereignisobjekt (\textit{VSAbstractEvent}) und das Prozessobjekt (\textit{VSInternalProcess}). Geplante \textit{VSTask}-Instanzen werden fr eine sptere Ausfhrung dem Task-Manager bergeben.
Die Kapselung eines \textit{VSAbstractEvent}-Objektes in einem \textit{VSTask}-Objekt erlaubt es, dass die selbe \textit{VSAbstractEvent}-Instanz mehrmals auf einmal im Task-Manager geplant werden kann. Ohne dieser Kapselung gbe es fr jedes Ereignis lediglich nur eine einzige mgliche Eintrittszeit. Von dieser Mglichkeit wird zum Beispiel bei den Server- und Clientanfragen eines Protokollobjektes Gebrauch gemacht. Fr jedes Protokoll kann der Anwender in einer Simulation beliebig viele Anfragen programmieren, wobei fr jede Anfrage stets das selbe Protokollobjekt als Ereignis verwendet wird.
diff --git a/LaTeX/diplomarbeit.pdf b/LaTeX/diplomarbeit.pdf
index 771ae91..73ccf01 100644
--- a/LaTeX/diplomarbeit.pdf
+++ b/LaTeX/diplomarbeit.pdf
@@ -755,11 +755,10 @@ endobj
>>
stream
x[oF)xR= s{̪6iu_
-pV3ː]GUTlsg
-ӿƷ; X+[˃|JfE(aKۤfAD
-2өdLñV!xD1O9$
-yIlEZdY|w= y?\?T֮lJ$_Rwzt0̂ijz.@"'4ܷ_Oֿ~Epx*=cZ,-ٯ+DO9EJ18Ό;V+LC޳Dz
-PJ "X;n/j=#sԿW]Kë7j^<>Q ى^W[y0<ɍ:%bh
+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.{
endobj
234 0 obj <<
/Type /Page
@@ -1089,17 +1088,17 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
309 0 obj <<
-/Length 1653
+/Length 1633
/Filter /FlateDecode
>>
stream
-xKo6:XDZE
-Q3V)pT(PĽ&-S?W[Tee6b9N~gB@F {/|{jdi2\pI*Ψez6߯5^ٻxuvgaj&#RXrzވURHUP[+O
-E]TIPFΨ%ybyUq<{owklm|CDHr)0xfv fs$R, T,)DBQDRG6O>Ү$7䨞%Mybڪè'vbZȵDdYP\i;23=Ri .(oX[N F]RpĈ(a;#7x%7/")&Z vV3cحhϔ$ԐԠбZiIPCQV PwFjA] qFxK]3&C5o7.P9le}|oOPd 3?ZHoP y {kn!<un37_VǓm)*x&6llfz4$ؐؠ౷twF]6 pFl , 0fo3rۘaҗ%? ?֐dCQ0?7cÍyoɖ-ٯ]~_]e U 5׶,[;Ѳ0,S[o
-:nm;]3៸}ػj5IeJi[(Ǥ@LOA  1<[qzu F]Rrp
-FbOT "T'go`n dHF1wHe$ppZ8>
-."^P$ xu)iqεݱ?/KuD
-x5/njC!#_ g(:-injΨE{Pi
+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
endobj
308 0 obj <<
/Type /Page
@@ -1154,7 +1153,7 @@ endobj
317 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [86.8628 641.0711 233.9432 649.6359]
+/Rect [86.8628 641.0711 185.3282 649.6359]
/Subtype /Link
/A << /S /GoTo /D (figure.4.3) >>
>> endobj
@@ -1236,13 +1235,15 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
347 0 obj <<
-/Length 1865
+/Length 1834
/Filter /FlateDecode
>>
stream
-x[o6)h3]!h>lك(PG.d[GJLSwIS &^aC2Fd0lq{i5KąTYwyfBAhFsT/.Ξ2so̲. iPUvqbd>_rS^MgOb17eu٫}C PTĚ.(aД6DV-3MC+d3ID idEDEMg며vS'bqOgTzʬ*/dW.TLeZM|۷vUmzk/$1(4 -DS8e\#́WgTA^~=X#m-wqkQI4g alB@(B\B؉i ;7WחLy![d?zU<*˽T9 1p``YnN5a6뱁;`VLY[I2 z$ !Iv00E~1N~²B ؈
-"֋(K
-hsr$eדhd .(Lc#>¾d ^qkQ ׫fl`h&āNjh8ד#IF^$cJUeoLY -ƭ}`vy(\zuyY I'o7AtK"ͱȂ^z"8W
+x[o6)h3;vm솠 e8Bͧ)2eGN%M1/<_x9fHIGg"Q3OIg8Yk?VùD\He^ \w1-Th$8VWT& H'a\\5H5-u^>]:'x<ܔ6◳]2-"4A ј$j=ZY2D N$;ЉFܺhUȚt.JSK)MΩҳuʌ*/2l_S*fyq^mRs5n}y<ci>kޙGaL!J1M| T#N׈ȫ5*U {NK?g, ΄-wakAI4g aLBUPd
+qN@H[ڿd-* aU_U3\oSeAn`[4<Q@&Kp<tW Ku&ތ1 f$ngQ&^daReHHa&a yQnwf7_15)ЩF"&"axpzD`{y[yg<,Xj
+(^gSN%CevL(q`{dBNg
+&Ӊ2W!~}~_n+5Ҙď4$֩F $vf-=bTB6F%$*jV%`*HjZ.R "X٪F>~X %ΣL\Z}uJ)Tr3xh[CD D*ƻ}!*] /\ƨ|rF?-x1XfgGzcNpe}O>n]oWXބ,VG%ܖ>Ob$,s"8kWK=Bq{Aqmٸ9cj ')L{Np&xm䖍slڴ՟ͭmxafeuN5Q=orCZ$# :IZL6"T2YEWic4kÌ#>:\olUs_JzL!xuT" D D 'kƈi?ps]g xY [!q^'A5t¬]w0Si*o'6A[퉌>ϋ"_2m6~!N5b)w%0|@DA<@wak5j* Xf *u+rKA|:WQt|ȔDius<45W y=׏YbmmK,`S&Y:Qi--r~+N*)RkE#STTQLy,
+[Y[^'(8rE'jY:_w ?BZՈ3DѤ'eF(G`lD,:F&46"#L%7bxj&^!QF(qS8iZM:8$jdD-qYI84} 9ZՈ]&͠v(yE<bZM^: 5KEԫ̋=gxM=yݵ_=G ^iE:pԫu'? %
endobj
346 0 obj <<
/Type /Page
@@ -1381,7 +1382,7 @@ endobj
368 0 obj <<
/Type /Annot
/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [86.8628 271.6208 345.4789 280.3918]
+/Rect [86.8628 271.6208 290.4531 280.3918]
/Subtype /Link
/A << /S /GoTo /D (table.4.2) >>
>> endobj
@@ -1392,7 +1393,7 @@ endobj
/D [346 0 R /XYZ 74.4095 643.0739 null]
>> endobj
345 0 obj <<
-/Font << /F26 170 0 R /F28 173 0 R /F63 220 0 R >>
+/Font << /F26 170 0 R /F28 173 0 R >>
/ProcSet [ /PDF /Text ]
>> endobj
390 0 obj <<
@@ -1532,15 +1533,17 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
411 0 obj <<
-/Length 1358
+/Length 1357
/Filter /FlateDecode
>>
stream
-xڍWo6_G X"EioŰtك1kYN-GɲEx<7Gßb:2eGk{;}EMGt.ś<
-V湊" GIRiX$՜ǯ]X:ɘy.3rtnT
-煙K/o3T2?D#vDjuyG]Bf?k&E~K~I8u&iVum㡩z k*cۡg! Y A$pjLd HFy't@]M?
-#}?Tlip s\B^k"֖󒖻Io(Y<5{*dD[kFҥ>5K0% %l~];G_GDaD,y%n&Op) |kZO$]
-?
+xڍWo6_G X"EioŰtك1kYN-GɲEx;Hßb:2eGk{;}EMGt.ś<
+V湊" GIRiX$՜ǯ]X:əy..2rtnT
+煙K/o3TS2?D#}vDjuyG[Bf?k&EqKqI8u&iVum㡩z k*cag) Y A$5H GH4 hzkbq`'" BЎsܹvLx{K&Keg@5u1`
+7d^ =Q {wIna( IMP-H,^*bkV+[׸uoIYڮ#onm ֌S
+-@Ȭ] -"T"/`/6<sI? ӝmVd\mւTe|]Ҷ677Yr6Ȍl* RV|تZS Ҷ Vh<AgbPO%hݭ-BKFcI|yB7\|M]q5Aߢ%W=`ft6ǹɟ;&C("ح6x>9m{rL
+#}?Tlip s\B^k"֖󒖻n(y<u{*TD[cFJ̈HUe% %~8];Gc\GDaD,E%nn&S !V0v]~trJ4
+8+x4RD&8|zQtivk:q%Pm008'WmipC u'0 ay<4DDvn2Tes.̱2(72OzN|K&HH ="L#@G>^DȨ&Uc{;Kb ..3U/&'-`9{f& G7'Įm_¥0Gs,_$wԢd?Y=zq=ZH7cB06
endobj
410 0 obj <<
/Type /Page
@@ -1609,18 +1612,16 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
420 0 obj <<
-/Length 1753
+/Length 1698
/Filter /FlateDecode
>>
stream
-xڍXKo8W(1KQ%M-X49fHeУwCJ-7EhHřoH "Yda?E k<j'-2K/^"I<l GݩzilJ8zS.{eP2)ůYǒʼnL+2)t=c4`$9KTXKV]Z:,D T%yDQU/Cu郡j;Uu8Hoiv"ЦS`) ny{Ҹ0 0R$̶֛ʭhU+C0FJGh~p
-c0\U\3c
-WFqܶá ٭ƙk\ǣ7չ6޸bv}C#+< >-r u΁/z'@=!tͮ8ٹd{80kҪzm _- |34[+|ַQhyV-232?LgZb%Ey<7="KmAh5m!ƚ3%ǂ
-=]Fc -TQd%?G)m@a<sP<C>7MmQlSdxN- J8 Ƽ 0kDoK[!^#tUck2hv&}fJ ZD=.AV$|oVƚ@UU@YF$`1
-mвLe76E봝ѝ\G
-EAĝbD[V'dW f|t#25N [G UfˈA"2Vj7PVƱ.L͜BB]*j+-
-C7,f.38$hЇQ(-?k- =E㒠kNxGF8 pOZc״0a5`T
-VBigUV
+xڍXK8 W
+ZZ
+4aÓy:@< PNy!Xc7Hf8>UVU
+A 6["ihWd͟.U)Ӭ4G /K5df|~ <ɦ;:֐kIAT\porn)Ms6eDuh+@~$CBkw؈?!*XeQŗ hI( rܝgp pLfK8L<-L&J8 Ƽ 0faQb)yj~p"<tg15АdhVe],ȉ$b =߯&p "\#~+k
+=:*kX$&9m j!Jr-=NzKG\D놅Fw?3" qu3hV=`kPVDZ.SL-"ݡ\
+nU R~QE0'm1kTjM0ݰkJ(m95SOlw "<N#i `̀XrVu8/ h1km(8 =`,܅_xP< Z;Aw) z`p1؎:e4uG tUƩuR_'l(΂G&v>;
endobj
419 0 obj <<
/Type /Page
@@ -2690,20 +2691,22 @@ endobj
/ProcSet [ /PDF /Text /ImageC ]
>> endobj
515 0 obj <<
-/Length 2256
+/Length 2236
/Filter /FlateDecode
>>
stream
-xڵr>_Guwn3ffؒb=$_ gwoR!
-Wm' ^~ClJ!5JoZÞ&E'ʼ){
-=!A>.HҵB}OKȝ8~~X&ۨ 9
-eA\׼"nrAB> Q1Q/If~
-L}?+<4c; =i
-Iگ{d@وܐJt(dОC<t͆8+FƲar+IùCPu(qEQhstCd[fbZ
-*3ѳ-?MݟŮˁ8MǏۮR%
-P
-$)+8Si|$
-2)~24] I3|0
+xڵْ6}rUKHylN*}mZҶ$OW$uN6
+'"&Dނ=o}2UZ#!8^&ꚾE^F tbbqU!bD5Maal&ڃl0D"'a<-w[M+j Vd~ao:+Bk_
+q`k)v[ (0+z$vJwg[ SP
+u!(J/#%Mҹy$:؂f(n|}fv;"uU_XQ=Ȑ!yIK!/li!܇V
+ &*⥷M,
+gY
+B ÈΖ }Y2MA@wTu_1#҉.jZv:kYH'L-")̧6^5DLg Y}I<8U<3L'<q<mZX-LI5nYkj,rMUiJ>~(+#2aiT#wYiPqQU=~<8DfE]bh k"aO<b;M>iYvF<)ne+r*1f2`.f @)99NO)D|:/}l6E="@UShX2+8Kzyy
++ֹR'$Won
+-Ն}]-L'Q{A~|de$sbǃ0 óEs h׵jI=\Oξ
+5
+nyq@"vZv(ϼ@sDA&O&-E1̂@4[<[b.H2#`f
+ԭ.?8E4ӗTP#z
endobj
514 0 obj <<
/Type /Page
@@ -2716,10 +2719,10 @@ endobj
/D [514 0 R /XYZ 74.4095 793.4011 null]
>> endobj
517 0 obj <<
-/D [514 0 R /XYZ 74.4095 603.3618 null]
+/D [514 0 R /XYZ 74.4095 600.6816 null]
>> endobj
518 0 obj <<
-/D [514 0 R /XYZ 74.4095 197.6163 null]
+/D [514 0 R /XYZ 74.4095 198.8037 null]
>> endobj
513 0 obj <<
/Font << /F63 220 0 R /F28 173 0 R /F26 170 0 R /F35 193 0 R >>
@@ -5712,20 +5715,25 @@ endobj
/ProcSet [ /PDF /Text ]
>> endobj
704 0 obj <<
-/Length 2230
-/Filter /FlateDecode
->>
-stream
-xڽZ[6~_} T "O&-3+elyj4~!E.3AE"?|<NXB?dHjUY ƒM0C4kb͇sC2Yŏw˔gf!2U.~9aةƫyw8%Fk<Rj"Β3b 9a %"]'M6 }J<_ WLկBZ"D
-ʚf;,eB8OR1蹎IC:ɔ!\w͋ڟ{辂#eDA2@ LsP:0[CQY/o__Bf(|YOm]2;
- V9ΌTNr ְ
-禹:S't=ǸP&V:#መjXéYY,6)0Gy38Z,Fٙc"r)R:%m o93璖!V<#R azbiCsSXJ+VQ
-eU Vl穥:gě2vEvH^eБ3 Tk_4&FgX,i+ +5kޙ~_
-JR H͵|Yo 2 azUTwh!t`< [Mv:˧27[kY;ZEaXa;&8?J8a#rPݭ|
-o}S<BgȌXx⋲m=-}VRw6" AkG
-_s P[rs*պS6߮-nC.-WhnK$$SCri13ps ?<0zm0)?仱]I+V]lpbFEn)|s+䖆fK"WU=HZjJuq-&3H 
-C/M^@ye_.uS lS=߉f8:S-)pp}heҕFsn7i].і-*x> 6\SAd8J1A9