diff --git a/doc/Architekturbeschreibung.tex b/doc/Architekturbeschreibung.tex
index e952ed3f71ec5a60f314e2cfb7e0755fd30a262a..1bbff04b68867eef5d2fa5e3a85c005863d933f6 100644
--- a/doc/Architekturbeschreibung.tex
+++ b/doc/Architekturbeschreibung.tex
@@ -13,7 +13,15 @@
 %
 \begin{document}
 \newcommand\documentTitle{Architekturbeschreibung}
-\swpdocument{Karsten Hölscher}{TT. Monat JJJJ}{1.1}%
+
+\begin{minipage}[H]{\textwidth}
+  \vfill
+  \centering
+  \includegraphics[scale=0.2]{Logo/Logo.png}
+  \end{minipage}
+  \vfill
+
+\swpdocument{Karsten Hölscher}{31. Mai 2020}{1.0}%
             {Fabian Kehlenbeck & fkehlenb@tzi.de}%
             {Leonard Haddad & s\_xsipo6@tzi.de}%
             {Luca Nittscher & lnittsch@tzi.de}%
@@ -30,9 +38,14 @@ identifizieren sein, hier und optimalerweise auf dem Titelblatt.}
 \begin{tabular}{ccl}
 Version & Datum & Änderungen \\
 \hline
-0.1 & TT.MM.JJJJ & Dokumentvorlage als initiale Fassung kopiert \\
-0.2 & TT.MM.JJJJ & \ldots \\
-\ldots
+0.1 & 10.05.2020 & Dokumentvorlage als initiale Fassung kopiert \\
+0.2 & 10.05.2020 & Einflussfaktoren \& Problemkarten \\
+0.3 & 14.05.2020 & Entwürfe für Modulsicht und Datenmodell\\
+0.4 & 22.05.2020 & Evolution\\
+\ldots\\
+0.8 & 29.05.2020 & Datenmodell fertiggestellt\\
+\ldots\\
+1.0 & 31.05.2020 & Abgabefassung\\
 \end{tabular}
 
 
@@ -1128,27 +1141,21 @@ Hier setzen wir die .. Strategie um. \\
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Konzeptionelle Sicht} \label{sec:konzeptionell}
 
-{\itshape Diese Sicht beschreibt das System auf einer hohen Abstraktionsebene,
-d.\,h. mit sehr starkem Bezug zur Anwendungsdomäne und den geforderten
-Produktfunktionen und "~attributen. Sie legt die Grobstruktur fest, ohne gleich 
-in die Details von spezifischen Technologien abzugleiten. Sie wird in den 
-nachfolgenden Sichten konkretisiert und verfeinert. Die konzeptionelle Sicht 
-wird mit {UML}-Komponentendiagrammen visualisiert.}
 
-In diesem Kapitel wird das zu entwerfende System in der Konzeptionellen Sicht nach Hofmeister dargestellt. Unser System ist ein Spiel, welches auf LibGDX basiert. Um unser System zu nutzen, stellen wir einen Client und einen Server zur Verfügung. Der Benutzer benutzt das Interface/View, um unsere Software zu steuern. Diese macht sich im Hintergrund bemerkbar, da unser Framework LibGDX über ein Model-View-Controller-System kommuniziert und die Logik im System ausführt. 
+In diesem Kapitel wird das zu entwerfende System in der Konzeptionellen Sicht nach Hofmeister dargestellt. Unser System ist ein Spiel, welches auf LibGDX basiert (Strategie 11.1). Um unser System zu nutzen, stellen wir einen Client und einen Server zur Verfügung. Der Benutzer benutzt das Interface/View, um unsere Software zu steuern. Diese macht sich im Hintergrund bemerkbar, da unser Framework LibGDX über ein Model-View-Controller-System kommuniziert und die Logik im System ausführt. Die gesamte Aufteilung in Module geht aus Strategie 6.1 hervor.
 
 \textbf{H2:} 
-Die Datenbanksoftware wird im Server dazu genutzt, um unsere Spielstände zu persistieren. Unsere Datenbank kommuniziert über die ORM-Lite Schnittstelle mit der im Server liegenden Persistenz. 
+Die Datenbanksoftware wird im Server dazu genutzt, um unsere Spielstände zu persistieren. Unsere Datenbank kommuniziert über die ORM-Lite Schnittstelle mit der im Server liegenden Persistenz. Die Entscheidung zu der Datenbank geht aus Strategie 3.1 heraus.  
 
-\textbf{Persistenz:}
-Die Persistenz stellt die Verbindung zwischen dem gesamten System und der Datenbank dar. Ihre Aufgabe liegt darin, dass sie die Datenbank auf dem aktuellsten Stand hält und den aktuellen Stand von der Datenbank lädt. Falls das Spiel terminiert, müssen alle Spielstände und alle Benutzerbezogenen Fortschritte gespeichert sein und beim nächsten Starten abrufbar sein. Die Persistenz stellt ein Interface für Service zur Verfügung, über welches Kontrollfluss und Datenfluss stattfindet (?).	\textcolor{red}{Diese Schnittstelle muss noch benannt werden!!!} Außerdem nutzt die Persistenz ein Interface von Model, über das Kontrollfluss läuft. 
+\textbf{Persistence:}
+Die Persistence stellt die Verbindung zwischen dem gesamten System und der Datenbank dar. Ihre Aufgabe liegt darin, dass sie die Datenbank auf dem aktuellsten Stand hält und den aktuellen Stand von der Datenbank lädt. Falls das Spiel terminiert, müssen alle Spielstände und alle Benutzerbezogenen Fortschritte gespeichert sein und beim nächsten Starten abrufbar sein. Zwischen der Persistenz und Service existiert eine Daten- und Kontrollfluss Verbindung update. Außerdem nutzt die Persistenz das Update Interface von Model, über das Kontrollfluss läuft. 
 
 \textbf{Model (Server):}
 Das Model beschreibt die logische Struktur der Datenbank. Hiermit wird bestimmt, wie auf Daten zugegriffen werden kann. 
-In unserem Model sind Daten des Schiffs, der Ausrüstung, der Spielkarte und der Gegner. Model stellt ein Kontrollfluss Interface zur Verfügung, welches von Persistenz benutzt wird und ein Kontrollfluss Interface (Controll), welches von Service benutzt wird. In Abschnitt \ref{sec:datensicht} unserer Architekturbeschreibung wird unser Datenmodell genauer beschrieben. 
+In unserem Model sind Daten des Schiffs, der Ausrüstung, der Spielkarte und der Gegner. Model stellt ein Kontrollfluss Interface Update zur Verfügung, welches von Persistenz benutzt wird und ein Daten- und Kontrollfluss Interface (Update), welches von Service benutzt wird. In Abschnitt \ref{sec:datensicht} unserer Architekturbeschreibung wird unser Datenmodell genauer beschrieben. 
 
 \textbf{Service:}
-Service ist die Komponente, die die Spielzugsdaten übermittelt bekommt und dann überprüft, ob der Spielzug nach den Spielregeln akzeptiert wird oder nicht. Hierzu nutzt Service ein Kontrollfluss Interface von Model und ein Datenfluss und Kontrollfluss Interface von Persistenz, um Daten abzugleichen. Außerdem gibt es Daten und Kontrollaustausch mit Communication, worüber die Spielzugdaten vom Client übermittelt werden. 
+Service ist die Komponente, die die Spielzugsdaten übermittelt bekommt und dann überprüft, ob der Spielzug nach den Spielregeln akzeptiert wird oder nicht. Hierzu nutzt Service ein Kontrollfluss Interface von Model und hat Datenfluss und Kontrollfluss mit Persistenz, um Daten abzugleichen, zu geben und zu nehmen. Außerdem gibt es Daten und Kontrollaustausch mit Communication, worüber die Spielzugdaten vom Client übermittelt werden. 
 
 \textbf{Communication (Server):}
 Die Communication Komponente des Servers dient dazu, die vom Client geschickten Spielzugdaten zu entschlüsseln und sie Service zur Verfügung zu stellen. Dies passiert über eine Data/Control Schnittstelle. Außerdem sollen die geänderten Spielzugdaten von der Datenbank aktualisiert werden und dem Client zur Verfügung gestellt werden. Communication (Server) hat eine TCP/Request/Response Schnittstelle zu Communication im Client. 
@@ -1157,15 +1164,46 @@ Die Communication Komponente des Servers dient dazu, die vom Client geschickten
 Die Communication Komponente im Client hat den Auftrag, Das Spiel zu updaten, also wenn jemand einen Zug gespielt hat, wird der dem Client auch angezeigt. Außerdem übermittelt er die Spielzugdaten dem Server. Über die Schnittstelle Update, von Model zur Verfügung gestellt, kann das Model einmal von Communication, als auch von Controller geupdatet werden. Über die Schnittstelle Data, von Communication zur Verfügung gestellt, werden Daten dem Controller zur Verfügung gestellt.
 
 \textbf{Model (Client):}
-Das Model im Client stellt die Datenstruktur unserer Datenbank dar. Es wird quasi alles in ihm gespeichert, sodass es zum spielen genutzt werden kann. Model stellt ein Interface Update zur Verfügung, worüber Controller und Communication das Model updaten können. Model stellt außerdem ein Control Interface zur Verfügung, über welches Controller Controller die geforderten Daten aus Model bekommen kann. 
+Das Model im Client stellt die Datenstruktur unserer Datenbank dar. Es wird quasi alles in ihm gespeichert, sodass es zum spielen genutzt werden kann. Model stellt ein Interface Update zur Verfügung, worüber Controller und Communication das Model updaten können. Model stellt außerdem ein Control Interface zur Verfügung, über welches Controller Controller die geforderten Daten aus Model bekommen kann. In Abschnitt \ref{sec:datensicht} unserer Architekturbeschreibung wird unser Datenmodell genauer beschrieben.
 
 \textbf{Controller:}
 In Controller passiert die gesamte Logik des Clients. Controller nutzt das Data Interface von Communication, um Daten zum Server zu schicken, Update von Model um das Model zu updaten und Control von Model, um Daten von Model zu empfangen. Controller stellt ein Interface Instruct zur verfügung, über welches die Interface/View die anzuzeigenden Daten bekommt. 
 
 \textbf{Interface/View:}
-Das Interface/die View stellt all das dar, was der User am ende sieht. Alle Grafiken werden hier gerendert, alle Knöpfe und Sachen, mit denen der User etwas machen kann, sind in der View enthalten. Um erforderliche Daten zu erhalten und zu eingaben des Users weiterzuleiten, benutzt Interface/View ein Interface Instruct von Controller. 
+Das Interface/die View stellt all das dar, was der User am ende sieht. Alle Grafiken werden hier gerendert, alle Knöpfe und Sachen, mit denen der User etwas machen kann, sind in der View enthalten. Um erforderliche Daten zu erhalten und zu eingaben des Users weiterzuleiten, benutzt Interface/View ein Interface Instruct von Controller. \\
+
+\textbf{Transitionen}
+
+\textbf{ORM-Lite (Datenbank $\leftrightarrow$ Persistence):}
+Hier werden alle Abfragen, Daten zu schicken und die Daten von und zur Datenbank gesendet.
+
+\textbf{Update (Persistence $\leftrightarrow$ Model):}
+Model stellt das Interface Update zu Verfügung, welches von Persistence genutzt wird. Es handelt sich hierbei um Kontrollfluss. Das Model bekommt den Befehl, zu updaten. 
+
+\textbf{Update (Model $\leftrightarrow$ Service):}
+Model stellt ein Inteface Update zur verfügung, welches von Service genutzt wird. Es fließen Daten zum updaten des Models. Außerdem kann der Befehl zum updaten auch vom Service kommen.
+
+\textbf{Update (Persistence $\leftrightarrow$ Service):}
+Hierbei handelt es sich um beidseitigen Datenfluss. Hier werden die geupdateten Daten an Service gegeben oder die zu updatenden Daten an Persistence gegeben. 
+
+\textbf{Data/Control (Service $\leftrightarrow$ Communication (Service)):}
+Hierüber werden alle Dateien geschickt, die in Communication angenommen werden, um in Service weiterverarbeitet zu werden. 
+
+\textbf{TCP/Request/Response (Communication (Server) $\leftrightarrow$ Communication (Client)):}
+Über diese Schnittstelle werden alle Daten und Befehle zwischen Server und Client übertragen, wie Zum Beispiel den Befehl zu updaten, die Abfrage, ob man sich ein Teil im Shop leisten kann oder ob im Kampf vom gegner eine Sektion des Schiffes beschädigt wurde. Außerdem können geänderte Dateien übertragen werden, die in der Datenbank aktualisiert werden müssen. 
+
+\textbf{Data (Communication (Client) $\leftrightarrow$ Controller):}
+Hierüber werden die Daten geschickt, welche in Communication vom Server ankommen und verarbeitet werden sollen oder die, die geändert wurden und persistiert werden müssen. 
+
+\textbf{Update (Model $\leftrightarrow$ Controller \& Communication):}
+Hier bekommt das Model den Befehl, upzudaten. Dieser kann entweder von Controller oder von Communication kommen. 
+
+\textbf{Control (Model $\leftrightarrow$ Controller):}
+Hier updatet sich das Model, wenn es den Befehl enthalten hat. Die neu erhaltenen Daten aus dem Controller werden ins Model übertragen. Außerdem bekommt der Controller seine Daten, die benötigt werden, aus dem Model. 
+
+\textbf{Instruct (Controller $\leftrightarrow$ Interface/View):}
+Es werden alle Daten und Befehle vom Frontend (Interface/View) ins Backend weitergeleitet. Außerdem werden alle Daten, die im Frontend gebraucht werden, hierüber übertragen.
 
-\textcolor{red}{Muss hier nochmal extra beschrieben werden, was jede Transition bedeutet oder reicht es, dass es da beschrieben ist, wo sie benutzt wird?}
 
 
 \newpage
@@ -1304,12 +1342,6 @@ Das hier gezeigte Diagramm zeigt den Login eines Spielers, dabei wird im View er
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Evolution} \label{sec:evolution}
 
-{\itshape Beschreibt in diesem Abschnitt, welche Änderungen Ihr vornehmen müsst,
-wenn sich Anforderungen oder Rahmenbedingungen ändern. Insbesondere würden 
-hierbei die in der Anforderungsspezifikation unter \glqq{}Ausblick\grqq{} 
-genannten Punkte behandelt werden.}
-
-\dots
 
 In folgendem Abschnitt behandeln wir mögliche Weiterentwicklungen für unsere Software. Es werden die Ideen und notwendige Veränderungen an der Architektur dargestellt.
 
@@ -1343,9 +1375,9 @@ An der Architektur muss soweit nichts großartig verändert werden, da man ein T
 
 }
 
-\subsection{COOP-Modus}
+\subsection{CO-OP-Modus}
 {
-Der COOP-Modus soll so wie der Einzelspielermodus sein. Das Ziel ist es, Ausrüstung zu sammeln, indem man computergesteuerte Raumschiffe zerstört oder die Zufallsereignisse absolviert. Mit dieser Ausrüstung kann man dann am Ende den Endboss besiegen. Der Unterschied zum Einzelspielermodus ist der, dass man zu zweit über einen ähnlich zum Mehrspielermodus aufgebauten Server spielen kann und alle Gegner zusammen angreifen und besiegen kann, aber nicht muss. Es soll auch möglich sein, dass die Spieler an unterschiedlichen Orten spielen. Außerdem könnte man einen Handel zwischen den beiden Spielern erlauben, sodass man die erkämpfte Ausrüstung untereinander tauschen kann.
+Der CO-OP-Modus soll so wie der Einzelspielermodus sein. Das Ziel ist es, Ausrüstung zu sammeln, indem man computergesteuerte Raumschiffe zerstört oder die Zufallsereignisse absolviert. Mit dieser Ausrüstung kann man dann am Ende den Endboss besiegen. Der Unterschied zum Einzelspielermodus ist der, dass man zu zweit über einen ähnlich zum Mehrspielermodus aufgebauten Server spielen kann und alle Gegner zusammen angreifen und besiegen kann, aber nicht muss. Es soll auch möglich sein, dass die Spieler an unterschiedlichen Orten spielen. Außerdem könnte man einen Handel zwischen den beiden Spielern erlauben, sodass man die erkämpfte Ausrüstung untereinander tauschen kann.
 
 In der Architektur muss ein neuer Modus für den Server erstellt werden, sodass kein PVP mehr möglich ist. Stattdessen müssen im Model Kämpfe mit drei Schiffen erlaubt werden. Außerdem müsste noch die Mechanik zum handeln/tauschen implementiert werden. Dies könnte ähnlich zum Shop implementiert werden.
 }
diff --git a/doc/Logo/Logo.PNG b/doc/Logo/Logo.PNG
new file mode 100644
index 0000000000000000000000000000000000000000..ce21cf1783acd5dfcb40f98491172b47fd0a9591
Binary files /dev/null and b/doc/Logo/Logo.PNG differ