@@ -1227,12 +1227,12 @@ Es werden alle Daten und Befehle vom Frontend (Interface/View) ins Backend weite
%sollte er explizit erklärt werden. Auch für diese Sicht muss die Entstehung
%anhand der Strategien erläutert werden.}
In diesem Kapitel werden die Module des Systems detailliert modelliert. Hier haben wir (fast) jede Komponente aus der konzeptionellen Sicht als einzelnes Modul angesehen. Daraus ergeben sich: Controller, View, Persistence, und Communication sowohl für den Server als auch für den Client. Da wir die H2-Datenbank verwenden (Strategie 3.1), ist die Komponente nicht von uns implementiert und im Folgenden nicht aufgeführt. Model ist hier nicht aufgeführt, da dies bereits unter dem Kapitel Datensicht erläutert wird. \\
Die Modularisierung ergibt sich aus Strategie 25.1.\\
In diesem Kapitel werden die Module des Systems detailliert modelliert. Hier haben wir (fast) jede Komponente aus der konzeptionellen Sicht als einzelnes Modul angesehen. Daraus ergeben sich: Controller, View, Persistence, und Communication sowohl für den Server als auch für den Client. Da wir die H2-Datenbank verwenden (Strategie 3.1)\ref{strategie:3.1}, ist die Komponente nicht von uns implementiert und im Folgenden nicht aufgeführt. Model ist hier nicht aufgeführt, da dies bereits unter dem Kapitel \ref{sec:datensicht}Datensicht erläutert wird. \\
Die Modularisierung ergibt sich aus Strategie 6.1 (\ref{strategie:6.1}).\\
\subsection{Controller}
Der Controller ist auf der Clientseite für die Kommunikation zwischen Views und Model sowie Communication (Kommunikation mit Server) zuständig und kontrolliert den Spielfluss. Somit gehen alle Informationen von und für die Views durch diese Controller. Sie nehmen ebenfalls eine erste Überprüfung von Spielzügen vor (hinsichtlich der Frage, ob diese überhaupt möglich sind aktuell), und übermitteln diese über Communication an den Server, der prüft, ob die Änderungen an den Objekten auch den Spielregeln entsprechen (Strategie 7.3); zum Beispiel würde der Client dem Spieler auf der Karte nur erlauben, einen tatsächlichen existierenden Ort auszuwählen, und der Server überprüft, ob Fuel reicht und eine Verbindung zwischen dem aktuellen Ort und dem ausgewählten existiert. \\
Der Controller ist auf der Clientseite für die Kommunikation zwischen Views und Model sowie Communication (Kommunikation mit Server) zuständig und kontrolliert den Spielfluss. Somit gehen alle Informationen von und für die Views durch diese Controller. Sie nehmen ebenfalls eine erste Überprüfung von Spielzügen vor (hinsichtlich der Frage, ob diese aktuell überhaupt möglich sind), und übermitteln diese über Communication an den Server, der prüft, ob die Änderungen an den Objekten auch den Spielregeln entsprechen (Strategie 7.3\ref{strategie:7.3}); zum Beispiel würde der Client dem Spieler auf der Karte nur erlauben, einen tatsächlichen existierenden Ort auszuwählen, und der Server überprüft, ob Fuel reicht und eine Verbindung zwischen dem aktuellen Ort und dem ausgewählten existiert. \\
Zunächst gibt es eine abstrakte Controller Klasse, von der alle anderen Controller erben. Diese hat einen ClientControllerCommunicator, über den die Kommunikation mit dem Server läuft. \\
Zusätzlich gibt es sechs weitere Klassen. Diese sind für die unterschiedlichen möglichen Situationen, in den ein Spieler sich befinden kann, zuständig: Battle, Travel, Trader, und Hangar. Battle ist für die Ausführung von Kämpfen zuständig, Trader für die Shops, die man eventuell auf Planeten findet, Travel für die Reisen zwischen Planeten, und Hangar für die Auswahl des Schiffmodells am Anfang des Spieles (Strategie 4.1). Des weiteren gibt es einen Controller für die Crew eines Schiffes, und einen für die Systeme eines Schiffes. \\
Die Controller werden von den Views aufgerufen, um Eingaben weiterzureichen, sowie von den Communication Klassen, um Informationen vom Server weiterzureichen (was zum Beipsiel die Bestätigung eines Spielzuges sein kann.). \\
