From 9b9326f547f9386879468aeb655874746398731c Mon Sep 17 00:00:00 2001
From: samuel <samnej@uni-bremen.de>
Date: Sun, 31 May 2020 18:55:14 +0200
Subject: [PATCH] 4.2, 4.3, 4.4 + referenzen
---
doc/Architekturbeschreibung.tex | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/Architekturbeschreibung.tex b/doc/Architekturbeschreibung.tex
index 82d50223..2b26a675 100644
--- a/doc/Architekturbeschreibung.tex
+++ b/doc/Architekturbeschreibung.tex
@@ -1234,7 +1234,7 @@ Die Modularisierung ergibt sich aus Strategie 6.1 (\ref{strategie:6.1}).\\
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. \\
+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 \ref{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.). \\
\begin{figure}[H]
@@ -1246,12 +1246,12 @@ Die Controller werden von den Views aufgerufen, um Eingaben weiterzureichen, sow
\subsection{View}
-Im View werden alle User-Interfaces realisiert. Es setzt sich zusammen aus den drei Packages \textit{Screen}, \textit{UI} und \textit{Buttons}. Im Package \textit{Screen} werden alle Klassen realisiert, die bildschirmfüllend sind und die Grundlage für alle darauf aufbauenden Popup-Fenster graphischen Informationsträgern über das Schiff oder die Crew sind. Im Package "Button" befinden sich alle alles Klassen, die auf Anklicken reagieren und somit eine Interaktion mit dem User-Interface \textit{UI} und den verschiedenen Screens ermöglicht. Ohne diese Buttons wäre kein Wechsel zwischen verschiedenen Menüs, keine Navigation auf der Karte oder Interaktion mit anderen Spielern, wie Kämpfe, und deren Schiffen möglich.
+Im View werden alle User-Interfaces realisiert. Es setzt sich zusammen aus den drei Packages \textit{Screen}, \textit{UI} und \textit{Buttons}. Im Package \textit{Screen} werden alle Klassen realisiert, die bildschirmfüllend sind und die Grundlage für alle darauf aufbauenden Popup-Fenster, graphischen Informationsträgern über das Schiff oder die Crew sind. Im Package \textit{Button} befinden sich alle alles Klassen, die auf Anklicken reagieren und somit eine Interaktion mit dem User-Interface \textit{UI} und den verschiedenen Screens ermöglicht. Ohne diese Buttons wäre kein Wechsel zwischen verschiedenen Menüs, keine Navigation auf der Karte oder Interaktion mit anderen Spielern, wie Kämpfe, und deren Schiffen möglich.
\subsubsection{Konkretisierung Buttons}
-Das Modul \textit{Buttons} ergibt sich zwangsläufig aus der Notwendigkeit Stuerelemente für den User bereitszustellen. Das Modul \textit{Buttons} gliedert sich in die zwei Submodule \textit{MenuButtons} und \textit{InGameButtons}.
+Das Modul \textit{Buttons} ergibt sich zwangsläufig aus der Notwendigkeit, Stuerelemente für den User bereitszustellen. Das Modul \textit{Buttons} gliedert sich in die zwei Submodule \textit{MenuButtons} und \textit{InGameButtons}.
\begin{figure}[H]
\begin{center}
@@ -1264,7 +1264,7 @@ Das Modul \textit{Buttons} ergibt sich zwangsläufig aus der Notwendigkeit Stuer
\newpage
\subsubsection{MenuButtons}
-Das Submodul Die \textit{MenuButtons} bilden die Schnittstelle zum Modul \textit{Screen} und enthält die Steuerelemente des Menüs und des Loginscreens.
+Das Submodul \textit{MenuButtons} bilden die Schnittstelle zum Modul \textit{Screen} und enthalten die Steuerelemente des Menüs und des Loginscreens.
\begin{figure}[H]
@@ -1276,8 +1276,8 @@ Das Submodul Die \textit{MenuButtons} bilden die Schnittstelle zum Modul \texti
\end{figure}
-\subsubsection{IngameButtons}
-Das Submodul \textit{InGameButtons} bildet die Schnittstelle zum Modul \textit{UI}. Im Submodul \textit{UI} sammeln sich alle Ausprägungen der \textit{Screens}. Diese sind ihrerseits wieder unterteilst in die Submodule \textit{Ship}, welches die graphische Repräsentation der Klasse \textit{Ship} darstellt, so wie und \textit{Shipinformation}, welches eine graphische Repräsentation aller Informationen des Schiffes, wie Sektionen, Systeme, Waffen, Crewmitgliedern, Hüllenenergie, Schildenergie darstellt und dem User eine Interaktion mit diesen Klassen ermöglicht. Ebenfalls enthalten ist die graphische Darstellung der Karte und des Menüs, über das das Spiel beendet werden kann. Und zu guter letzte das Submodul \textit{Events} in dem die graphischen Darstellungen zu Events gesteuert werden.
+\subsubsection{InGameButtons}
+Das Submodul \textit{InGameButtons} bildet die Schnittstelle zum Modul \textit{UI}. Im Submodul \textit{UI} sammeln sich alle Ausprägungen der \textit{Screens}. Diese sind ihrerseits wieder unterteilst in die Submodule \textit{Ship}, welches die graphische Repräsentation der Klasse \textit{Ship} darstellt, so wie und \textit{Shipinformation}, welches eine graphische Repräsentation aller Informationen des Schiffes, wie Sektionen, Systeme, Waffen, Crewmitgliedern, Hüllenenergie, Schildenergie darstellt und dem User eine Interaktion mit diesen Klassen ermöglicht. Ebenfalls enthalten ist die graphische Darstellung der Karte und des Menüs, über das das Spiel beendet werden kann. Und zu guter Letzt das Submodul \textit{Events} in dem die graphischen Darstellungen von Events gesteuert werden.
\begin{figure}[H]
\begin{center}
@@ -1289,8 +1289,8 @@ Das Submodul \textit{InGameButtons} bildet die Schnittstelle zum Modul \textit{U
\subsection{Client-Controller-Communication}
-Das folgende Diagramm beschreibt das Modul Client-Controller-Communication. Wenn ein Controller im Client einen Spielschritt ausführen möchte, muss dieser erst an den Server gelangen um bestätigt zu werden. Der Controller erstellt ein neues Request welches dann an den ClientControllerCommunicator gegeben wird (eine Schnittstelle zwischen der Netzwerk Schnittstelle und der Logik). Dieser ClientControllerCommunicator leitet das Request von dem jeweiligem Controller weiter an den Client, welcher es an den Server schickt, und wartet auf ein Response. Sobald er das Response erhält, gibt er dieses weiter an den ClientControllerCommunicator, welcher es dann an den korrekten Controller weiterleitet.
-Dieses Modul dient als Realisierung der Strategie 5.1 (Multiplayer) und teilweise Strategie 7.3 (Zugüberprüfung).
+Das folgende Diagramm beschreibt das Modul Client-Controller-Communication. Wenn ein Controller im Client einen Spielschritt ausführen möchte, muss dieser erst an den Server gelangen, um bestätigt zu werden. Der Controller erstellt ein neues Request, welches dann an den ClientControllerCommunicator gegeben wird (eine Schnittstelle zwischen der Netzwerk Schnittstelle und der Logik). Dieser ClientControllerCommunicator leitet das Request von dem jeweiligem Controller weiter an den Client, welcher es an den Server schickt, und auf ein Response wartet. Sobald er das Response erhält, gibt er dieses weiter an den ClientControllerCommunicator, welcher es dann an den korrekten Controller weiterleitet.
+Dieses Modul dient als Realisierung der Strategie 5.1 (Multiplayer \ref{strategie:5.1}) und teilweise Strategie 7.3 (Zugüberprüfung \ref{strategie:7.3}).
\begin{figure}[H]
\begin{center}
\includegraphics[width=\linewidth]{../GT_Modulsicht/src/CommClient.png}
--
GitLab