diff --git a/doc/Architekturbeschreibung.tex b/doc/Architekturbeschreibung.tex
index 63bf44c5a490376f115282c9cc3e32c14355e26d..a909916ca9a1f32788796aaaec956b807558c08f 100644
--- a/doc/Architekturbeschreibung.tex
+++ b/doc/Architekturbeschreibung.tex
@@ -1325,8 +1325,8 @@ Somit ist die Strategie 7.3 (Zugüberprüfung \ref{strategie:7.3}) realisiert, u
 
 \subsection{Persistenz}
 
-Das folgende Diagramm beschreibt unsere Persistenz. Persistenz Klassen werden dazu genutzt Daten in der Datenbank zu speichern, verändern und löschen. Zu jedem im Spiel vorkommenden Objekt, bzw zu der Klasse aus dem das Objekt stammt, muss es ein so genanntes Data Access Object geben (kurz DAO), um diese in der Datenbank verwalten zu können.
-Da viele von den DAOs die gleichen Funktionen haben, werden sie alle von einer Oberklasse ObjectDAO erben. ObjectDAO hat in sich drin auch eine Variable, welche die Verbindung zur Datenbank herstellt. Hiermit können so auch alle anderen DAOs auf die Datenbank zugreifen. Da wir ORMLite benutzen, wird auch jede Unterklasse eine Variable des Typs Dao haben, welche zur Abspeicherung der Daten verwendet wird. Um Daten abzuspeichern, wird die Methode persist(T) benutzt. Um Daten zu löschen remove(T). Da manche Objekte in der Datenbank nicht verändert werden müssen (z.B. die Weltkarte), wird es keine Methode in der Oberklasse zum Updaten der Daten geben, sondern in jeder Unterklasse welche diese benötigt.
+Das folgende Diagramm beschreibt unsere Persistenz. Persistenz Klassen werden dazu genutzt, Daten in der Datenbank zu speichern, verändern und löschen. Zu jedem im Spiel vorkommenden Objekt, bzw zu der Klasse aus dem das Objekt stammt, muss es ein so genanntes Data Access Object geben (kurz DAO), um diese in der Datenbank verwalten zu können.
+Da viele von den DAOs die gleichen Funktionen haben, erben sie alle von einer Oberklasse ObjectDAO. ObjectDAO hat eine Variable, welche die Verbindung zur Datenbank herstellt. Hiermit können so auch alle anderen DAOs auf die Datenbank zugreifen. Da wir ORMLite benutzen, wird auch jede Unterklasse eine Variable des Typs Dao haben, welche zur Abspeicherung der Daten verwendet wird. Um Daten abzuspeichern wird die Methode persist(T) benutzt, um Daten zu löschen remove(T). Da manche Objekte in der Datenbank nicht verändert werden müssen (z.B. die Weltkarte), wird es keine Methode in der Oberklasse zum Updaten der Daten geben, sondern in jeder Unterklasse, welche diese benötigt.
 
 Dieses Modul realisiert somit die Strategie 3.1 (Abspeicherung des Spielstands).
 
@@ -1340,19 +1340,19 @@ Dieses Modul realisiert somit die Strategie 3.1 (Abspeicherung des Spielstands).
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Datensicht} \label{sec:datensicht}
 
+In diesem Abschnitt beschreiben wir die Datenstrukturen, die in unserem Spiel benutzt werden, und wie diese zueinenader in Beziehung stehen. \\
 
+Alle Spieler-relevanten Attribute sind in unserem Datenmodell in \textit{Ship} enthalten. Ein Schiff besteht aus mehreren Räumen, welche zum Teil leer sein können, aber auch wichtige Systeme beinhalten können. Damit realisieren wir die Strategie \textit{12.2} sowie die Strategien \textit{4.1}.
 
-Alle Spieler-relevanten Attribute sind in unserem Datenmodell in \textit{Ship} enthalten. Ein Schiff besteht aus mehreren Räumen , welche zum Teil leer sein können, aber auch wichtige Systeme beinhalten können. Damit realisieren wir die Strategie \textit{12.2} sowie die Strategien \textit{4.1}.
+Ein Raum kann wiederum unterschiedliche Systeme beherbergen, wie z.B. Schilde, Hüllen oder Antriebskomponenten, womit wir Strategie \textit{20.2} umsetzen können. Zusätzlich zu den oben genannten Systemen gibt es noch eine Komponente \textit{WeaponSystem}, welche wiederum die \textit{abstract class Weapon} erweitert. Diese wiederum beinhaltet alle freischaltbaren Waffensysteme, womit wir die Strategien \textit{10.1-2} abdecken. Jede Waffe hat eine ID, ein Waffenlevel, welches im Laufe des Spiels erhöht werden kann, und Werte für Schaden, Cooldown, Energie, Raketen-Kosten, eine Trefferchance, die \textit{drop-chance} einer bestimmten Waffe nach besonderen Ereignissen, Schild-Penetration, die Chance einen Hüllenbruch zu verursachen, den Schaden an Crewmitgliedern, und die Anzahl der Projektile pro Salve.
 
-Ein Raum kann wiederum unterschiedliche Systeme beherbergen, wie z.B. Schilde, Hüllen oder Antriebskomponenten, womit wir Strategie \textit{20.2} umsetzen können. Zusätzlich zu den oben genannten Systemen, gibt es noch eine Komponente \textit{WeaponSystem}, welche wiederum die \textit{abstract class Weapon} erweitert. Diese wiederum beinhaltet alle frei-schaltbaren Waffensysteme, womit wir die Strategien \textit{10.1-2} abdecken. Jede Waffe hat eine ID, ein Waffenlevel, welches im Laufe des Spiels erhöht werden kann und Werte für Schaden, Cooldown, Energie, Raketen-Kosten, eine Trefferchance, die \textit{drop-chance} einer bestimmten Waffe nach besonderen Ereignissen, Schild-Penetration, die Chance einen Hüllenbruch zu verursachen, den Schaden an Crewmitgliedern und die Anzahl der Projektile pro Salve.
-
-Des Weiteren kann jeder \textit{Room}, bis zu 4 Crewmitglieder gleichzeitig beherbergen. Womit wir die Strategie \textit{15.3} umsetzen. Zudem kann es vorkommen, dass im Falle eines Angriffes/Zerstörung eines Raumes Crewmitglieder mit einer gewissen Prozent-Chance Schaden nehmen, oder sterben, womit wir die Strategien \textit{21.1 u. 21.2} erfüllen.
+Des Weiteren kann jeder \textit{Room}, bis zu 4 Crewmitglieder gleichzeitig beherbergen, womit wir die Strategie \textit{15.3} umsetzen. Zudem kann es vorkommen, dass im Falle eines Angriffes/Zerstörung eines Raumes Crewmitglieder mit einer gewissen Prozent-Chance Schaden nehmen, oder sterben, womit wir die Strategien \textit{21.1 u. 21.2} erfüllen.
 
 Es gibt eine \textit{User class}, welche den Namen des Spielers, seine ID, sein Schiff, sowie seinen Login-Status beinhaltet. Dies ist zudem essentiell für die Multiplayer-Funktion, womit wir die Strategie \textit{5.1} umsetzen.
 
 Bei jeder neuen Runde wird eine \textit{Overworld} generiert, welche die komplette Sternenkarte als Liste von Planeten beinhaltet(Map). Diese werden anhand der verknüpften Koordinaten in der View des Spielers gerendert. Ein solcher Planet besteht aus einem Namen, einer X und Y Position, sowie einem zugeordneten Ereignis aus der \textit{Enum PlanetEvent}. Ein besuchter Planet bekommt zudem den Status \textit{discovered}. Der Spieler kann zwischen diesen Planeten hin- und her reisen, das Schiff befindet sich dabei immer an genau einem Planeten. Damit erfüllen wir die Strategie \textit{9.2} (Reisen).
 
-Auf bestimmten Planeten, besteht die Chance auf einen \textit{Händler} zu treffen, dieser wird durch die Klasse \textit{Trader} repräsentiert. Dieser bietet dem Spieler eine Auswahl von Waffen, Raketen, Crewmitgliedern, sowie Treibstoff zum Verkauf an.
+Auf bestimmten Planeten besteht die Chance, auf einen \textit{Händler} zu treffen, dieser wird durch die Klasse \textit{Trader} repräsentiert. Dieser bietet dem Spieler eine Auswahl von Waffen, Raketen, Crewmitgliedern, sowie Treibstoff zum Verkauf an.
 
 \begin{figure}[H]
 \begin{center}