moved stuff

8 files changed, 0 insertions, 2305 deletions

diff --git a/LaTeX/chapters/anhang-a.tex b/LaTeX/chapters/anhang-a.tex
deleted file mode 100644
index e9222e0..0000000
--- a/LaTeX/chapters/anhang-a.tex
+++ /dev/null
@@ -1,22 +0,0 @@
-\chapter{Akronyme}

-

-\begin{acronym}

-\acro{API}{Application Programming Interface}

-\acro{BSD}{Berkeley Software Distribution}

-\acro{GIMP}{GNU Image Manipulation Program}

-\acro{GNU}{GNU's Not UNIX}

-\acro{GUI}{Graphical User Interface}

-\acro{GVim}{Graphical Vi IMproved}

-\acro{HTTPS}{Hypertext Transfer Protocol Secure}

-\acro{IP}{Internet Protocol}

-\acro{JRE}{Java Runtime Environment}

-\acro{NID}{Nachrichten-Identifikationsnummer}

-\acro{PDF}{Protable Document Format}

-\acro{PID}{Prozess-Identifikationsnummer}

-\acro{RTT}{Round Trip Time}

-\acro{SDK}{Software Development Kit}

-\acro{SVN}{Subversion}

-\acro{TCP}{Transmission Control Protocol}

-\acro{UDP}{User Datagram Protocol}

-\acro{VS}{Verteilte Systeme}

-\end{acronym}

diff --git a/LaTeX/chapters/ausblick.tex b/LaTeX/chapters/ausblick.tex
deleted file mode 100644
index 5959e7a..0000000
--- a/LaTeX/chapters/ausblick.tex
+++ /dev/null
@@ -1,23 +0,0 @@
-\chapter{Ausblick}

-

-Es wurde erfolgreich ein Simulator für die Simulation verteilter Systeme entwickelt. Der Simulator hat bereits 10 implementierte Protokolle zur Auswahl eingebaut. Zudem steht dem Anwender ein sehr komfortables Protokoll-API zur Verfügung, womit der Entwicklung neuer Protokolle quasi keine Grenzen gesetzt sind.

-

-Darüber hinaus verfügt der Simulator über eine Vielzahl von sehr flexiblen Einstellungsmöglichkeiten. Für jede Simulation lassen sich somit komplett andere Konfigurationen verwenden. Jeder beteiligte Prozess hat wiederum eigene lokale Einstellungen, wo sich auch jedes Protokoll für jeden Prozess separat einstellen lässt. Die Anzahl und Flexibilität der möglichen Szenarien wird dadurch um einen sehr großen Faktor erweitert.

-

-Mit dem Ereigniseditor gibt es eine komfortable Möglichkeit eigene Szenarien zu programmieren um sie anschließend zu Simulieren. Hierbei kann entweder auf die bereits enthaltenen Protokolle oder auf selbst implementierte Protokolle zugegriffen werden. Alle dazugehörigen Einstellungen und programmierten Ereignisse lassen sich vom Anwender für eine spätere Wiederverwendung plattformunabhängig abspeichern. Somit können auch abgespeicherte Szenarien beispielsweise an Kommilitonen weitergegeben werden oder für eine spätere Präsentierung zwischengespeichert werden. Durch den Logfilter lassen sich mit Hilfe von regulären Ausdrücken nur die relevanten Lognachrichten anzeigen, was die Analyse einer Simulation erheblich vereinfacht. Weitere Funktionen wie Lamport- und Vektor-Zeitstempel sowie Anti-Aliasing runden den Simulator ab. 

-

-Durch den objektorientierten Aufbau ist der Simulator relativ einfach erweiterbar, was nicht nur das Protokoll-API betrifft. Insgesamt wurde an den meisten Stellen darauf geachtet, dass zu einem sp\"{a}teren Zeitpunkt Erweiterungen einfließen k\"{o}nnten. Insbesondere soll die Serialisierung von Objekten r\"{u}ckw\"{a}rtskompatibel bleiben, da sonst bei jeder neuen Simulatorversion alle Simulationen erneut angelegt und abgespeichert werden m\"{u}ssten. 

-

-Hätte für diese Diplomarbeit noch mehr Zeit zur Verfügung gestanden, dann h\"{a}tten einige der folgenden Funktionen (hier in alphanumerisch sortierter Reihenfolge aufgelistet) auch Einzug halten k\"{o}nnen:

-

-\begin{itemize}

-	\item Die M\"{o}glichkeit Protokolle zu entwickeln ohne den kompletten Quelltext des Simulators vorliegen zu haben. Protokollklassen als separate Bibliothek einzubinden, die dynamisch geladen werden k\"{o}nnen.

-	\item Die Simulationsdauer beliebig lang machen zu können. Dazu müsste die Klasse \textit{VSSimulatorVisualisation} entlang der Zeitachse scrollbar gemacht werden, so dass der Benutzer für eine nachträgliche Betrachtung des Simulationsverlaufes zu jeder beliebigen Position zurückspringen kann.

-	\item Eine Zoomfunktion für die Simulationsvisualisierung einzubauen.

-	\item Im Ereigniseditor selbst auch periodische Ereignisse programmierbar zu machen. Bisher kann nur jeder Ereigniseintritt separat programmiert werden oder auf Protokoll-Interne Wecker zurückgegriffen werden.

-	\item Lamport- und Vektor-Zeitstempel als Ereigniseintrittskriterien verwenden zu können.

-	\item Tiefere Schichten des OSI-Referenzmodells simulieren können, wie z.B. TCP, UDP, IP, ...

-	\item Weitere Funktionen einzubauen, wie z.B. das Anklicken einer Nachrichtenlinie, was zu der jeweiligen Nachricht alle verfügbaren Informationen anzeigt und welche gegebenenfalls vom Benutzer editiert werden können.

-\end{itemize}

-

-Da der Simulator höchstwahrscheinlich unter einer Open Source Lizenz freigegeben wird, werden die einen oder anderen Funktionen nachträglich eingebaut werden. Kommilitonen werden auch herzlich dazu eingeladen sein sich an diesem Software-Projekt zu beteiligen. Als Vorbild sei hier der CPU-Simulator M32 \cite{M32}, der von Prof. Oßmann an der Fachhochschule Aachen entwickelt wurde, genannt. Hier existieren bereits einige Erweiterungen und Verbesserungen der Ursprungsversion, die von den Studenten angefertigt wurden. Für die Entwicklung des VS-Simulators wurde keine proprietäre Software verwendet, so dass jeder kostenlosen Zugriff auf die dazugehörigen Tools hat.

diff --git a/LaTeX/chapters/einleitung.tex b/LaTeX/chapters/einleitung.tex
deleted file mode 100644
index f7954a4..0000000
--- a/LaTeX/chapters/einleitung.tex
+++ /dev/null
@@ -1,68 +0,0 @@
-\newpage
-~
-\thispagestyle{empty}
-\newpage
-\chapter{Einleitung}
-
-\section{Motivation}
-
-In der Literatur findet man viele verschiedene Definitionen eines verteilten Systems. Vieler dieser Definitionen unterschieden sich untereinander, so dass es schwer fällt eine Definition zu finden, die als Alleinige als die Richtige gilt. Andrew Tanenbaum und Marten van Steen w\"{a}hlten für die Beschreibung eines verteilten Systems die folgende lockere Charakterisierung:
-
-\cite{Tanenbaum} \textit{``Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Anwender wie ein einzelnes, kohärentes System erscheinen''}
-
-Der Anwender muss sich nur mit dem lokalen, vor ihm befindlichen Computer auseinandersetzen, während die Software des lokalen Computers die reibungslose Kommunikation mit den anderen beteiligten Computern des verteilten Systems sicherstellt.
-
-Diese Diplomarbeit soll den Anwendern die Betrachtung von verteilten Systemen aus einer anderen Perspektive erleichtern. Hierbei wird nicht die Sichtweise eines Endbenutzers eingenommen, sondern es sollen die Funktionsweisen von Protokollen und deren Prozesse in verteilten Systemen begreifbar gemacht und gleichzeitig alle relevanten Ereignisse eines verteilten Systems transparent dargestellt werden. 
-
-Um dieses Ziel zu erreichen soll, insbesondere f\"{u}r Lehr- und Lernzwecke an der Fachhochschule Aachen, ein Simulator entwickelt werden. Mit dem Simulator sollen Protokolle aus den verteilten Systemen mit ihren wichtigsten Einflussfaktoren anhand von Simulationen nachgeblidet werden k\"{o}nnen. Gleichzeitig muss für eigene Experimente ein großer Spielraum zur Verfügung stehen, wobei es keine Beschränkung auf eine feste Anzahl von Protokollen geben darf. Es ist also wichtig, dass es dem Anwender ermöglicht wird eigene Protokolle zu entwerfen.
-
-\section{Grundlagen}
-
-Für das Grundverständnis werden im Folgenden einige Grundlagen erläutert. Eine Vertiefung findet erst in den späteren Kapiteln statt.
-
-\subsubsection{Client/Server Modell}
-
-\begin{figure}[htbp]
-	\centering
-	\fbox{\includegraphics{images/client-server}}
-	\caption{Client/Server Modell}
-	\label{fig:ClientServer}
-\end{figure}
-
-Der Simulator basiert auf dem Client/Server-Prinzip. Jede Simulation besteht in der Regel aus einen teilnehmenden Client und einen Server, die miteinander über Nachrichten kommunizieren (s. Abb. \ref{fig:ClientServer}.). Bei komplexen Simulationen können auch mehrere Clients und/oder Server mitwirken. 
-
-\subsubsection{Prozesse und deren Rollen}
-
-Ein verteiltes System wird anhand von Prozessen simuliert. Jeder Prozess nimmt hierbei eine oder mehrere Rollen ein. Beispielsweise kann ein Prozess die Rolle eines Clients einnehmen und ein weiterer Prozess die Rolle eines Servers. Die M\"{o}glichkeit einem Prozess die Client- und Serverrolle gleichzeitig zuzuweisen ist ebenso gegeben. Ein Prozess k\"{o}nnte auch die Rollen mehrerer Server und Clients gleichzeitig einnehmen. Um einen Prozess zu kennzeichnen, besitzt jeder eine \textbf{eindeutige} Prozess-Identifikationsnummer (PID). 
-
-\subsubsection{Nachrichten}
-
-In einem verteilten System müssen Nachrichten verschickt werden können. Eine Nachricht kann von einem Client- oder Serverprozess verschickt werden und kann beliebig viele Empfänger haben. Der Inhalt einer Nachricht hängt vom verwendeten Protokoll ab. Was unter einem Protokoll zu verstehen ist, wird später behandelt. Um eine Nachricht zu kennzeichnen, besitzt jede Nachricht eine \textbf{eindeutige} Nachrichten-Identifikationsnummer (NID).
-
-\subsubsection{Lokale und globale Uhren}
-
-In einer Simulation gibt es \textbf{genau eine} globale Uhr. Sie stellt die aktuelle und \textbf{immer korrekte} Zeit dar. Eine globale Uhr geht nie falsch.
-
-Zudem besitzt jeder beteiligte Prozess eine eigene lokale Uhr. Sie stellt die aktuelle Zeit des jeweiligen Prozesses dar. Im Gegensatz zu der globalen Uhr können lokale Uhren eine falsche Zeit anzeigen. Wenn die Prozesszeit nicht global-korrekt ist (nicht der globalen Zeit gleicht, bzw. eine falsche Zeit anzeigt), dann wurde sie entweder im Laufe einer Simulation neu gestellt, oder sie geht wegen einer Uhrabweichung falsch. Die Uhrabweichung gibt an, um welchen Faktor die Uhr falsch geht. Hierauf wird später genauer eingegangen. 
-
-\begin{figure}[htbp]
-	\centering
-	\includegraphics{images/client-server-protokolle}
-	\caption{Client/Server Protokolle}
-	\label{fig:ClientServerProtokolle}
-\end{figure}
-
-Neben den normalen Uhren sind auch die Vektor-Zeitstempel sowie die logischen Uhren von Lamport von Interesse. Für die Vektor- und Lamportzeiten gibt es hier, im Gegensatz zu der normalen Zeit, keine globalen Äquivalente. Konkrete Beispiele zu den Lamport- und Vektorzeiten werden später in Kapitel 3.11.1. behandelt.
-
-\subsubsection{Ereignisse}
-
-Eine Simulation besteht aus der Hintereinanderausführung von endlich vielen Ereignissen. Beispielsweise kann es ein Ereignis geben, welches einen Prozess eine Nachricht verschicken lässt. Denkbar wäre auch ein Prozessabsturzereignis. Jedes Ereignis tritt zu einem bestimmten Zeitpunkt ein. Ereignisse mit selber Eintrittszeit werden vom Simulator direkt hintereinander ausgeführt. Den Anwender des Simulators hindert dies jedoch nicht, da Ereignisse aus ihrer Sicht parallel ausgeführt werden.
-
-\subsubsection{Protokolle}
-
-Eine Simulation besteht auch aus der Anwendung von Protokollen. Es wurde bereits erwähnt, dass ein Prozess die Rollen von Servern und/oder Clients annehmen kann. Bei jeder Server- und Clientrolle muss zusätzlich das dazugehörige Protokoll spezifiziert werden. Ein Protokoll definiert, wie ein Client und ein Server Nachrichten verschickt, und wie bei Ankunft einer Nachricht reagiert wird. Ein Protokoll legt auch fest, welche Daten in einer Nachricht enthalten sind. Ein Prozess verarbeitet eine empfangene Nachricht nur, wenn er das jeweilige Protokoll versteht.
-
-In Abbildung \ref{fig:ClientServerProtokolle}. sind 3 Prozesse dargestellt. Prozess 1 unterstützt serverseitig das Protokoll ``A'' und clientseitig das Protokoll ``B''. Prozess 2 unterstützt clientseitig das Protokoll ``A'' und Prozess 3 serverseitig das Protokoll ``B''. Das heißt, dass Prozess 1 mit Prozess 2 via Protokoll ``A'' und mit Prozess 3 via Protokoll ``B'' kommunizieren kann. Die Prozesse 2 und 3 sind zueinander inkompatibel und können voneinander erhaltene Nachrichten nicht verarbeiten.
-
-Clients können nicht mit Clients, und Server nicht mit Servern kommunizieren. Für eine Kommunikation wird stets mindestens ein Client und ein Server benötigt. Diese Einschränkung kann aber umgangen werden, indem Prozesse ein gegebenes Protokoll sowohl server- als auch clientseitig unterstützen (vgl. Broadcast Protokoll in Kap. 3.3.). 
-
diff --git a/LaTeX/chapters/header.tex b/LaTeX/chapters/header.tex
deleted file mode 100644
index 5286aa9..0000000
--- a/LaTeX/chapters/header.tex
+++ /dev/null
@@ -1,212 +0,0 @@
-% %	Diploma thesis template 2005
-%
-%       author: lukas.silberbauer(at)gmx.at
-%       based upon  "Diplomarbeit mit LaTeX" by Tobias Erbsland
-%
-%       published under the terms of
-%
-%  ----------------------------------------------------------------------------
-%  "THE BEER-WARE LICENSE":
-%  <lukas.silberbauer(at)gmx.at> wrote this file. As long as you retain this 
-%	notice you can do whatever you want with this stuff. If we meet some day, 
-%	and you think this stuff is worth it, you can buy me a beer in return. 
-%  ----------------------------------------------------------------------------
-
-%
-% header.tex
-%
-\documentclass[%
-	pdftex,%              PDFTex verwenden
-	a4paper,%             A4 Papier
-	oneside,%             Einseitig
-	bibtotocnumbered,%    Literaturverzeichnis nummeriert einfügen
-	idxtotoc,%            Index ins Verzeichnis einfügen
-	halfparskip,%         Europäischer Satz mit abstand zwischen Absätzen
-	chapterprefix,%       Kapitel anschreiben als Kapitel
-	%headsepline,%         Linie nach Kopfzeile
-	%footsepline,%         Linie vor Fusszeile
-	12pt%                 Größere Schrift, besser lesbar am bildschrim
-]{scrbook}
-
-
-%
-% Paket für die Indexerstellung.
-%
-\usepackage{makeidx}
-
-%
-% Paket für Übersetzungen ins Deutsche
-%
-\usepackage[german, english]{babel}
-
-%
-% Pakete um Latin1 Zeichnensätze verwenden zu können und die dazu
-%  passenden Schriften.
-%
-\usepackage[latin1]{inputenc}
-\usepackage[T1]{fontenc}
-
-%
-% Paket zum Erweitern der Tabelleneigenschaften
-%
-\usepackage{array}
-
-%
-% Paket um Grafiken einbetten zu können
-%
-\usepackage{graphicx}
-
-%
-% Spezielle Schrift verwenden.
-%
-\renewcommand{\encodingdefault}{T1}
-%\renewcommand{\familydefault}{goudysans}
-\renewcommand{\familydefault}{\sfdefault}
-
-
-%
-% Zeilenabstand einstellen
-%
-\usepackage{setspace}
-\onehalfspacing
-%\doublespacing
-
-%\setlength{\baselineskip}{24pt}
-%\renewcommand{\baselinestretch}{1.5} 
-
-%
-% define variables
-%
-\def\maintitle#1{\gdef\maintitle{#1}}
-\def\subtitle#1{\gdef\subtitle{#1}}
-
-%
-% Zeilenumbruch bei Bildbeschreibungen.
-%
-\setcapindent{1em}
-
-%
-% kopf und fusszeilen
-%
-\pagestyle{headings}
-
-%
-% mathematische symbole aus dem AMS Paket.
-%
-\usepackage{amsmath}
-\usepackage{amssymb}
-
-%
-% Type 1 Fonts für bessere darstellung in PDF verwenden.
-%
-\usepackage{mathptmx}           % Times + passende Mathefonts
-\usepackage[scaled=.75]{helvet} % skalierte Helvetica als \sfdefault
-\usepackage{courier}            % Courier als \ttdefault
-
-%
-% Paket um Textteile drehen zu können
-%
-\usepackage{rotating}
-
-\usepackage{verbatim,framed}
-\usepackage{moreverb}
-
-%
-% Für Acronyme
-%
-\usepackage{acronym}
-
-%
-% Package für Farben im PDF
-%
-%\usepackage{color}
-\usepackage[dvipsnames]{color}
-\usepackage[dvipsnames,svgnames]{pstricks}
-
-% Fuer bilder am seitenrand
-%\usepackage{sidecap}
-%\usepackage{floatfit}
-%\usepackage{float}
-
-
-%
-% Paket für Links innerhalb des PDF Dokuments
-%
-\definecolor{LinkColor}{rgb}{0,0,0.5}
-
-\usepackage[%
-pdfauthor={Paul B\"{u}tow},
-bookmarks=true, % PDF bookmarks allowed. NB! The level depth of bookmarks is the same as in the TOC.
-unicode=true, % PDF bookmarks in Unicode.
-bookmarksnumbered=true, % Section numbers in PDF bookmarks.
-bookmarksopenlevel=1, % The open level in PDF bookmarks.
-hyperindex=true, % Hyperlinked index.
-colorlinks=true, % Links are marked as coloured text, not coloured box.
-linkcolor=linkc, % The colour for in-document links (e.g. in the table of contents).
-citecolor = citec, % The colour for bibliographic citations.
-urlcolor=urlc, % The colour for hyperlinks to the Net.
-pdfpagelayout=OneColumn % Continuous page scrolling.
-]{hyperref}
-\hypersetup{colorlinks=true,%
-	linkcolor=LinkColor,%
-	citecolor=LinkColor,%
-	filecolor=LinkColor,%
-	menucolor=LinkColor,%
-	pagecolor=LinkColor,%
-	urlcolor=LinkColor}
-
-%
-% Paket um Listings sauber zu formatieren.
-%
-\usepackage[savemem]{listings}
-\lstloadlanguages{TeX}
-
-%
-% ---------------------------------------------------------------------------
-% Listing Definationen für PHP Code
-%
-\definecolor{lbcolor}{rgb}{0.85,0.85,0.85}
-\lstset{language=[LaTeX]TeX,
-	numbers=left,
-	stepnumber=1,
-	numbersep=5pt,
-	numberstyle=\tiny,
-	breaklines=true,
-	breakautoindent=true,
-	postbreak=\space,
-	tabsize=2,
-	basicstyle=\ttfamily\footnotesize,
-	showspaces=false,
-	showstringspaces=false,
-	extendedchars=true,
-	backgroundcolor=\color{lbcolor}}
-
-% ---------------------------------------------------------------------------
-% Neue Umgebungen
-% ---------------------------------------------------------------------------
-
-\newenvironment{ListChanges}%
-	{\begin{list}{$\diamondsuit$}{}}%
-	{\end{list}}
-
-\newenvironment{code}%
-{%
-\definecolor{shadecolor}{named}{LightYellow}%
-\topsep=0ex\relax
-\framed
-\small
-\verbatim
-}%
-{%
-\endverbatim
-\endframed
-}%
-
-%
-% Index erzeucgen
-%
-\makeindex
-
-%
-% EOF
-%
diff --git a/LaTeX/chapters/implementierung.tex b/LaTeX/chapters/implementierung.tex
deleted file mode 100644
index 7e29634..0000000
--- a/LaTeX/chapters/implementierung.tex
+++ /dev/null
@@ -1,735 +0,0 @@
-\chapter{Implementierung}

-

-In diesem Kapitel wird auf die Implementierung des Simulators eingegangen. Der Simulator wurde in der Programmiersprache Java entwickelt. Bei der Betrachtung der Zielgruppe wird klar, dass Java für die gestellte Aufgabe die geeignetste Programmiersprache ist. Der Simulator ist somit auf jedem Betriebssystem ausf\"{u}hrbar, für das es eine JRE (Java Runtime Environment) gibt. Da an der Fachhochschule Aachen die Programmiersprache Java gelehrt wird, sollten die Studenten die M\"{o}glichkeit haben durch eigene Erweiterungen des Simulators Protokolle entwerfen zu k\"{o}nnen. Der Simulator wurde mit dem derzeit aktuellsten Java SDK (Software Development Kit) in der Version 6 (1.6) entwickelt.

-

-\begin{table}

-	\fbox{

-	\begin{tabular}{l|l}

-		\textbf{Paketname} & \textbf{Beschreibung} \\

-		\hline 

-		\textit{core} & Klassen für Prozesse und Nachrichten\\

-		\textit{core.time} & Klassen für Zeitformate\\

-		\textit{events} & Basisklassen für Ereignisse\\

-		\textit{events.implementations} & Implementierungen von Ereignissen\\

-		\textit{events.internal} & Implementierungen von internen Ereignissen\\

-		\textit{exceptions} & Klassen für Fehlerbehandlungen\\

-		\textit{prefs} & Klassen für die Einstellungen\\

-		\textit{prefs.editors} & Klassen für die Editoren\\

-		\textit{protocols} & Basisklassen für Protokolle\\

-		\textit{protocols.implementations} & Implementierungen von Protokollen\\

-		\textit{serialize} & Helferklassen für die Serialisierung von Simulationen\\

-		\textit{simulator} & Klassen für die GUI und die Visualisierung\\

-		\textit{utils} & Diverse Helferklassen\\

-	\end{tabular}

-	}

-	\caption{Die Paketstruktur}

-	\label{tb:Pakete}

-\end{table}

-

-Im Folgenden wird der Quelltext auszugsweise behandelt. Der Quelltext erstreckt sich, einschließlich 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 dazugehörigen Dokumentation eingesehen werden. Die Paketstruktur des Quelltextes ist in Tabelle \ref{tb:Pakete}. in alphanumerischer Reihenfolge aufgeführt.  

-

-\section{Einstellungen und Editoren}

-

-Der Verlauf einer Simulation ist von einer Vielzahl von Einstellungen abhängig. Da auf diese Einstellungen in Weiteren stets zurückgegriffen 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 für eine spätere Verwendung dynamisch ablegen, damit stellt eine solche Instanz einen Container für diese Daten dar. In einem \textit{VSPrefs}-Objekt speichert der Simulator alle Einstellungen ab. Zudem besitzt jedes Prozessobjekt und jedes Ereignisobjekt für lokale Einstellungen seine eigene Instanz von \textit{VSPrefs}. Später 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

-	\includegraphics[width=7cm]{images/prefs}

-	\caption{Das Paket \textit{prefs}}

-	\label{fig:PackagePrefs}

-\end{figure}

-

-Jede Variable hat einen Datentypen, einen Variablennamen, eine optionale Beschreibung sowie einen Variablenwert. Einige Datentypen unterstützen auch die Angabe von Minimal- und Maximalwerten (z.B. 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 möchte, kann für jede Variable auch ein optionaler Einheiten-String abgespeichert werden. 

-

-Eine Variablenbeschreibung wird für die Darstellung im GUI verwendet, während der Variablenname für die interne Verwendung vom Simulator verwendet wird. Zum Beispiel hat die Variable \textit{message.prob.outage} (Verlustwahrscheinlichkeit einer Nachricht) als Variablenbeschreibung ``Nachrichtenverlustw'keit''. Wenn für 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 Präfixkonventionen. Alle verfügbaren Datentypen wurden bereits in Tabelle \ref{tb:VariablenDatentypen}. aufgelistet. Die Klasse \textit{VSPrefs} stellt für alle Variablentypen entsprechende Selektoren zur Verfügung.  

-

-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. Für Integer stehen in \textit{VSPrefs} folgende Methoden zur Verfügung:

-

-\begin{itemize}

-	\setlength{\itemsep}{-2mm}

-	\item \textit{void setInteger(String key, Integer val)}

-	\item \textit{void setInteger(String key, Integer val, String descr)}

-	\item \textit{void setInteger(String key, int val)}

-	\item \textit{void setInteger(String key, int val, String descr)}

-	\item \textit{Integer getIntegerObj(String key)}

-	\item \textit{int getInteger(String key)}

-	\item \textit{java.util.Set<String> getIntegerKeySet()}

-	\item \textit{void initInteger(String key, int val) }

-	\item \textit{void initInteger(String key, int val, String descr) }

-	\item \textit{void initInteger(String key, int val, String descr, int minValue, int maxValue) }

-	\item \textit{void initInteger(String key, int val, String descr, int minValue, int maxValue, String unit) }

-	\item \textit{void initInteger(String key, int val, String descr, VSPrefsRestriction.VSIntegerPrefsRestriction r) }

-	\item \textit{void initInteger(String key, int val, String descr, VSPrefsRestriction.VSIntegerPrefsRestriction r, String unit) }

-\end{itemize}

-

-\begin{table}

-	\fbox{

-	\begin{tabular}{c|l|l}

-		\textbf{Variablen-Präfix} & \textbf{Beschreibung}  & \textbf{Beispiel}\\

-		\hline 

-		\textit{col} & Farbvariablen & \textit{Color: col.background = Color-Objekt}\\

-		\textit{div} & Diverse versteckte Variablen & \textit{Integer: div.window.logsize = 300} \\

-		\textit{keyevent} & Variablen, die Tastaturkürzel definieren & \textit{Integer: keyevent.close = KeyEvent.VK\_C} \\

-		\textit{lang} & Variablen, die Text beinhalten & \textit{String: lang.activate = aktivieren}\\

-		\textit{message} & Variablen, die Nachrichten betreffen & \textit{Integer: message.prob.outage = 0}\\

-		\textit{process} & Variablen, die Prozesse betreffen & \textit{Integer: process.prob.crash = 0}\\

-		\textit{sim} & Allgemeine Simulationsvariablen & \textit{Integer: sim.process.num = 3}\\

-	\end{tabular}

-	}

-	\caption{Konventionen f\"{u}r Präfixe von Variablennamen}

-	\label{tb:VariablenPraefixe}

-\end{table}

-

-Hierbei steht \textit{key} f\"{u}r den Variablennamen- und \textit{val} f\"{u}r den Variablenwert. \textit{descr} ist die optionale Variablenbeschreibung. Es können 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} (s. \cite{Javadoc}) zurück.

-

-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 für andere Datentypen) gibt es in der Quelltext-Dokumentation.

-

-Die Klasse \textit{VSPrefs} speichert alle Integervariablen in einem \textit{HashMap<String,Integer>}-Objekt ab, wobei der String-Wert den Variablennamen \textit{key} angibt. Für die Beschreibung \textit{descr}, den Einheiten-String \textit{unit} sowie möglichen Minimal- und Maximalwerte werden separate Instanzen von \textit{HashMap} verwendet. Da die Selektoren von \textit{VSPrefs} synchronisiert sind, können alle \textit{HashMap}s aus verschiednenen Threads gleichzeitig verwendet werden. 

-

-Die Klasse \textit{VSSerializablePrefs} implementiert das Interface \textit{VSSerializable} und kann somit durch Serialisierung alle enthaltenen Daten in eine Datei abspeichern bzw. wieder in den Speicher laden (s. Kap. 4.4.6.). 

-

-Die Klasse \textit{VSDefaultPrefs} erweitert \textit{VSSerializablePrefs} und initialisiert bei ihrer Instantiierung automatisch alle verfügbaren Simulationsvariablen mit Standardwerten. Hier sind auch alle Spracheinstellungen abgelegt. M\"{o}chte man den Simulator in eine andere Sprache (z.B. Englisch) übersetzen, 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 für Protokolle wurden in den Protokollklassen direkt angegeben, da dies mehr Komfort für Protokollentwickler bedeutet und damit für jede neu programmierte Textausgabe nicht \textit{VSDefaultPrefs.java} editiert werden muss. 

-

-Alle Variablen die als Präfix \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 nun bekannt. Für das Editieren von Variablen werden Editor-Objekte verwendet. In Abbildung \ref{fig:PackagePrefsEditors}. ist die Klassenstruktur des dazugehörigen Paketes \textit{prefs.editors} angegeben. 

-

-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 verfügbaren nicht-versteckten Variablen des \textit{VSPrefs}-Objektes im GUI dar und bietet die Möglichkeit diese Variablen zu editieren. Für das Editieren von Farbwerten wird auf die Klasse \textit{VSColorChooser} zurückgegriffen. Die Klasse \textit{VSEditorTable} ist für das \textit{JTable}-Objekt aus Java's Swing-Bibliothek (s. \cite{Swing}) zuständig, 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

-	\includegraphics[width=10.5cm]{images/prefs-editors}

-	\caption{Das Paket \textit{prefs.editors}}

-	\label{fig:PackagePrefsEditors}

-\end{figure}

-

-Die Klasse \textit{VSSimulatorEditor} erlaubt das Editieren der globalen Simulationseinstellungen und der \textit{VSProcessEditor} das Editieren der Prozesseinstellungen sowie der dazugehörigen Protokollvariablen. Da diese beiden Klassen die abstrakte Klasse \textit{VSAbstractBetterEditor} erweitern, können sie mit Hilfe von \textit{VSEditorFrame} in einem separaten Fenster angezeigt werden. Alternativ können 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 geöffnet. Für Protokolle gibt es keine separate Editor-Klasse, da diese bereits im Prozesseditor editiert werden können. Hierbei iteriert der Prozesseditor über alle dem jeweiligen Prozess verfügbaren Protokollobjekte und fügt deren Variablen in den Prozesseditor ein. Somit erscheinen die Prozess- und die dazugehörigen Protokollvariablen im selben Editor und bieten dem Benutzer eine bessere Übersicht.

-

-\section{Ereignisse}

-

-Für jedes Ereignis existiert eine dazugehörige Klasse, welche die auszuführenden Aktionen implementiert. Eine Instanz einer solchen Klasse wird für eine spätere Ausführung dem Task-Manager (s. Kap. 4.4.3.) ü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 verfügbaren 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 müssen 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{Das Paket \textit{events.*}}

-	\label{fig:PackageEvents}

-\end{figure}

-

-In der Implementierung wird zwischen drei Haupttypen von Ereignissen unterschieden, die jeweils in einem unterschiedlichen Paket liegen (s. Abb. \ref{fig:PackageEvents}.):

-

-\begin{enumerate}

-	\item \textit{events.implementations}: In diesem Paket befinden sich alle Ereignisse, die ohne weitere Spezialbehandlung vom Simulator eingesetzt werden können und vom Benutzer direkt im Ereigniseditor programmierbar sind. 

-		\begin{itemize}

-			\item \textit{VSProcessCrashEvent}: Dieses Ereignis lässt den dazugehörigen Prozess abstürzen.

-			\item \textit{VSProcessRecoverEvent}: Dieses Ereignis lässt den dazugehörigen Prozess wiederbeleben.

-		\end{itemize}

-

-	\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 Verfügung, die von allen internen Ereignissen zur Serialisierung benötigt werden. 

-			\item \textit{VSMessageReceiveEvent}: Diese Klasse wird für die Ankunft einer Nachricht bei einem Empfängerprozess benötigt. Sie kapselt die eigentliche Nachricht und überprüft, ob der Empfängerprozess das zur Nachricht gehörige Protokoll versteht. Diese Klasse überprüft auch die Simulationseinstellung ``Nur relevante Nachrichten anzeigen'' und entscheidet, ob die Nachricht nach Eintreffen in der Visualisierung und im Logfenster berücksichtigt werden soll oder nicht.

-			\item \textit{VSProtocolEvent}: Diese Klasse implementiert gleichzeitig vier verschiedene Ereignisse: Das Aktivieren bzw. Deaktivieren eines Servers oder Clients eines gegebenen Protokolls. Der Ereigniseditor berechnet anhand der verfügbaren Protokolle automatisch alle möglichen Kombinationen und bietet sie dem Anwender in seiner Auswahl an. Für alle dieser vier Ereignisse wird jeweils ein Objekt von \textit{VSProtocolEvent} verwendet, jeweils mit individuellen Attributwerten.  

-			\item \textit{VSProtocolScheduleEvent}: Diese Klasse wird für die Wecker-Ereignisse benötigt. Wecker-Ereignisse können 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 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- bzw. einer Clientanfrage entspricht (s. Kap. 4.4.4.). 

-\end{enumerate}

-

-Alle Ereignisse, die das Interface \textit{VSCopyableEvent} implementieren, können vom Anwender im Ereigniseditor mit einem Rechtsklick kopiert werden. Des Weiteren müssen 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 müssen folgende abstrakten Methoden implementieren:

-

-\begin{itemize}

-	\item \textit{abstract public void onInit()}: Bevor ein Ereignisobjekt vom Simulator verwendet werden kann, muss es initialisiert werden. Diese Methode wird pro Ereignisobjekt nach dessen Erzeugung nur ein einziges Mal ausgeführt. 

-	\item \textit{abstract public void onStart()}: Diese Methode wird jedes Mal ausgeführt, wenn das Ereignis eintritt. Sie stellt somit das Kernstück eines Ereignisses dar. 

-\end{itemize}

-

-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, auf die eine Referenz zurückgegeben wird. Alle Ereignisse, die kopiert werden können, müssen 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(VSAbstractProcess 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 außerdem Zugriff auf folgende Attribute, welche von \textit{VSAbstractEvent} geerbt werden:

-

-\begin{itemize}

-	\item \textit{protected VSPrefs prefs}: Eine Referenz auf das Simulationseinstellungsobjekt. Hierüber 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, 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 dazugehörige Klasse keine Attribute besitzt, verbleibt auch hier die \textit{initCopy}-Methode mit leerem Methodenrumpf. Aufgrund der Serializierbarkeit von Ereignisobjekten 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 ausgeführt. Hier wird überprüft, ob der Prozess bereits abgestürzt ist und ggf. zum Absturz gebracht. 

-\begin{code}

-package events.implementations;

-

-import events.*;

-

-public class VSProcessCrashEvent 

-extends VSAbstractEvent implements VSCopyableEvent {

-    public void initCopy(VSAbstractEvent copy) {

-    }

-

-    public void onInit() {

-        super.setClassname(super.getClass().toString());

-    }

-

-    public void onStart() {

-        if (!process.isCrashed()) {

-            process.isCrashed(true);

-            super.log(prefs.getString("lang.crashed"));

-        }

-    }

-}

-\end{code}

-

-Der Task-Manager (s. Kap. 4.4.3.) überprüft bereits, ob der Prozess abgestürzt ist oder nicht. Das f\"{u}hrt dazu, dass ein Ereignis bei einem abgestürztem Prozess gar nicht erst ausgeführt wird. Die einzige Ausnahme bildet ein Wiederbelebungsereignis (\text{VSProcessRecover}), welches auch dann ausgeführt wird, auch wenn der Prozess abgestürzt 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 für jedes Ereignis ein Eintrag existieren. Die \textit{init}-Methode wird einmal beim Starten des Simulators ausgeführt:

-

-\begin{code}

-public static void init(VSPrefs prefs_) {

-    .

-    .

-    .

-    registerEvent("events.implementations.VSProcessCrashEvent",

-                  "Prozessabsturz");

-    .

-    .

-    .

-}

-\end{code}

-

-\section{Zeitformate, Prozesse, Nachrichten sowie Task-Manager}

-

-Das Paket \textit{core.time} in Abbildung \ref{fig:PackageCoreTime}. stellt lediglich die Klassen für die Vektor- und Lamport-Zeitstempel zur Verfügung. Für die normale lokale Prozesszeit wird, aus Performance-Gründen, keine eigene Klasse, sondern ein einfaches \textit{long}-Attribut des Prozessobjektes verwendet.

-

-\begin{figure}[h]

-	\centering

-	\includegraphics[width=7cm]{images/core-time}

-	\caption{Das Paket \textit{core.time}}

-	\label{fig:PackageCoreTime}

-\end{figure}

-

-In Abbildung \ref{fig:PackageCore}. ist das Paket \textit{core} dargestellt. Für jedes auszuführende Ereignis wird eine Instanz von \textit{VSTask} benötigt, welche die Ereigniseintrittszeit als Attribut abgespeichert. Die Instanz besitzt eine Referenz auf das Ereignisobjekt (\textit{VSAbstractEvent}) sowie das Prozessobjekt (\textit{VSInternalProcess}). Geplante \textit{VSTask}-Instanzen werden dem Task-Manager für eine spätere Ausführung übergeben.

-

-Die Kapselung eines \textit{VSAbstractEvent}-Objektes in einem \textit{VSTask}-Objekt erlaubt es, dass die gleiche \textit{VSAbstractEvent}-Instanz mehrmals im Task-Manager geplant werden kann. Ohne dieser Kapselung gäbe es für jedes Ereignis nur eine einzige mögliche Eintrittszeit. Von dieser Möglichkeit wird z.B. bei den Server- und Clientanfragen eines Protokollobjektes Gebrauch gemacht. Für jedes Protokoll kann der Anwender in einer Simulation beliebig viele Anfragen programmieren, wobei für jede Anfrage stets das selbe Protokollobjekt als Ereignis verwendet wird.

-

-Jede Simulation besitzt genau eine Instanz von \textit{VSTaskManager}. Eine Instanz dieser Klasse stellt den Task-Manager dar. Er verwaltet alle \textit{VSTask}-Instanzen und überprüft periodisch, ob es auszuführende Ereignisse gibt. Der Task-Manager unterscheidet zwischen globalen und lokalen Ereignissen. Hierbei werden alle globalen Ereignisse (gekapselt in einem \textit{VSTask}-Objekt) in einer Prioritäts-Warteschlange (vgl. \cite{Algorithms}, \cite{AlgorithmsC}) abgelegt. Die Prioritäts-Warteschlange stellt hierbei die korrekte Ereigniseintrittsreihenfolge sicher. Da sich die lokalen Zeiten aller beteiligten Prozesse voneinander unterscheiden können, muss für jeden Prozess eine separate lokale Prioritäts-Warteschlange verwendet werden, auf die jedes Prozessobjekt seine eigene Referenz hat. In den lokalen Warteschlangen sind die geplanten lokalen Ereignisse (auch gekapselt in einem \textit{VSTask}-Objekt) abgelegt. Der Task-Manager greift über eine \textit{java.util.ArrayList} auf alle Prozessobjekte zu und kann somit auch auf alle lokalen Warteschlangen zugreifen und diese verwalten.

-

-Eine Instanz von \textit{VSMessage} stellt eine Nachricht dar, die von einem Prozess verschickt wird. Da \textit{VSMessage} von \textit{VSPrefs} erbt, können zwischen zwei Prozessen beliebige Datentypen (s. Tabelle \ref{tb:VariablenDatentypen}.) über eine Nachricht verschickt werden. Anschließend wird für jeden Empfängerprozess ein neues Ereignisobjekt der Klasse \textit{VSMessageReceiveEvent} angelegt, welches eine Referenz der verschickten Nachricht besitzt (s. Abb. \ref{fig:Wrapping}.). Danach wird ein \textit{VSTask}-Objekt instantiiert, in dem die Referenz auf das Ereignisobjekt und das dazugehörige Prozessobjekt sowie die Ereigniseintrittszeit als Attribute gespeichert werden. Das \textit{VSTask}-Objekt wird dann dem Task-Manager übergeben, der das dazugehörige Ereignis ausführt, wenn die Ereigniseintrittszeit eingetroffen ist. Via Java-Polymorphie wird