Merge branch 'Sequenzdiagramm'

core/src/com/galaxytrucker/galaxytruckerreloaded/Communication/Client.java

@@ -8,6 +8,9 @@ public class Client {
 
     private ClientControllerCommunicator clientControllerCommunicator;
 
+    /**
+     * - Request and Response from and to the server.
+     * */
     public String sendAndReceive(){
         // View clicks something
         // Controller issues a request
@@ -19,7 +22,9 @@ public class Client {
         return null;
     }
 
-    /** Constructor */
+    /** Constructor
+     *  Loop for receiving Data
+     * */
     public Client(){
         clientControllerCommunicator = new ClientControllerCommunicator();
         // Connect to server

doc/Architekturbeschreibung.tex

@@ -1257,6 +1257,21 @@ jenes der Anforderungsspezifikation enthalten, allerdings mit
 implementierungsspezifischen Änderungen und Erweiterungen. Siehe die gesonderten
 Hinweise.}
 
+\textcolor{red}{TEXT}
+
+Alle Spiel-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.1} sowie die Strategien \textit{4.1} und \textit{4.2}.
+
+Ein Raum kann wiederum unterschiedliche Systeme beherbergen, wie z.B. Schilde, Hüllen oder Antriebskomponenten, womit wir Strategie \textit{20.1-3} 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-3} abdecken.
+
+Des weiteren kann jeder \textit{Room}, bis zu 4 Crew Mitglieder 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.
+
+\begin{figure}[H]
+\begin{center}
+  \includegraphics[width=\linewidth]{UML/Datenmodell.pdf}
+    \caption{Das Datenmodell}
+\end{center}
+\end{figure}
+
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Ausführungssicht} \label{sec:ausfuehrung}
@@ -1297,6 +1312,18 @@ Der Controller erstellt ein neues Request welches dann an den ClientControllerCo
 
 Dieses Diagramm beschreibt nun eine Attack-Sequenz basierend auf dem vorherigem abstrakten Diagramm. In diesem Fall wird in der WeaponUI eine Waffe durch Mausclick ausgewählt, und dann der Raum auf dem Gegnerschiff welcher angegriffen werden soll. Dann wird dieses als Attack-Request weitergegeben an den ClientControllerCommunicator, welcher es wiederrum an die Netzwerkschnittstelle des Clients weiterleitet. Das Request wird dann durch diese Schnittstelle an den Server geschickt. Der Server empfängt das Request und gibt es an seinen ServerServiceCommunicator, welcher dann den AttackService wählt und ihm das Request weiterleitet. Dieser überprüft dann mittels ValidMove ob das Angriffskommando valide ist oder nicht. Wenn es das ist, so wird die Logik ausgeführt, und das Gegnerschiff in der Datenbank aktualisiert. Dann wird der jetzige Spieler weitergesetzt (wer dran ist). Dann wird ein Response als neue Schiffsobjekte an den ServerServiceCommunicator gegeben, welcher es wieder an die Servernetzwerkschnittstelle gibt. Das Response wird dann zum Client übertragen, und dort an den ClientControllerCommunicator gegeben. Dieser teilt das Ergebnis dem Controller mit (gleiche Methode, da diese noch auf den Response wartet). Dann werden dort die lokalen Daten durch die vom Server bekommenen Daten ersetzt. Der View wartete bis jetzt noch auf ein Ergebnis welches er nun bekommt, wodurch auch er sich aktualisiert.
 
+
+\subsection{Login}
+
+\begin{figure}[H]
+\begin{center}
+  \includegraphics[width=\linewidth]{UML/Sequenz-Client-login.pdf}
+\end{center}
+\end{figure}
+
+Das hier gezeigte Diagramm zeigt den Login eines Spielers, dabei wird im View erstmals der \textit{LoginButton()} durch einen Mausklick ausgewählt und durch den Controller wird eine Request an den \textit{ClientControllerCommunicator} gesendet, dieser wiederum führt die Methode \textit{login()} aus, welche dann einen LoginRequest über die Methode \textit{receiveAndSendData} an den Server sendet. Auf der Server Seite wird nun die Methode \textit{getResponse()} aufgerufen, welche im \textit{UserService} die Logik und die Verifizierung des Logins mithilfe des \textit{usernames} ausführt. Wenn nun der Login genehmigt wurde durch den Service, so wird der Request verifiziert und die \textit{UserDao} wird geupdated. Nun geht die \textit{Response} über die gleichnamigen Methoden zurück zum Client welcher die Response weitergibt an den Controller. Der Controller updated die Lokalen Daten und übergibt die aktualisierten Daten an den View. Nun ist der User eingeloggt und kann der Session beitreten.
+
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Evolution} \label{sec:evolution}
 

doc/UML/Sequenz-Client-login.drawio

+<mxfile host="app.diagrams.net" modified="2020-05-30T15:27:04.664Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" etag="u4MAO24UQc2d3n8jc4Fq" version="13.1.7" type="device"><diagram name="Page-1" id="13e1069c-82ec-6db2-03f1-153e76fe0fe0">7VxJd6M4EP41fm/mYD8JsR5jp5dDZrrf5E1P91HGss00Rm6M43h+/QgjNonNDtB0gg8JKrRSX5VKVQUTtNg9f/DxfvsHXRF3ooDV8wTdTxRFASZk/0LKOaJoih4RNr6zikgwJTw6/xFOBJx6dFbkkKsYUOoGzj5PtKnnETvI0bDv01O+2pq6+VH3eEMkwqONXZn6j7MKtpwKAUhvfCTOZsuHNjV+Y4nt7xufHj0+3kRB68svur3DcV+8/mGLV/SUIaF3E7TwKQ2iq93zgrjhs40fW9TufcndZN4+8YImDYwlXmJoq0tbMdbqEkyVqIcn7B75s5igu4XrsP4W1At86rrEX9Dd7ug5Ng6oz9cRnONnx5a0Dy+PO/fBWRPX8Vhpvie+syMB8dkdl5M/p7T5aesE5HGP7bDpiaGK0bbBzmUlyC4ZowPMmvhJ2XXx/uAsL6MCRvGJffQPzhP5ixwiPIVUegzCkRYJTi5VQ/6QFe8qYQG49LtzbH7t4iVx5wlDF9Sl4fAevSzowJ7F9wQdYUdrNsf3eOe4Iei/EH+FPczJHOGQPcw5dp2Nxwo2e6SXpcs842x8In5AnjMkzsMPhLLH5p9ZlfhujCcubyYvnlLwKjF2txncanFFzAVmk3SdgoZdcNwUY8hzP1pfHxbvf1if//3z4fTt073+aWrIOBKBkmHvnjpecJmCNp9o9wJeqB9s6YZ62M0iJuUiGCYXS2WrMVstLcdVS+YqLGAqgi0wVZo8KlcMowoYgApAaq0KgP2qAHNUAaVS1Jital4FQNhMByhtcFWavVqkAx6Jz5Yz6oAB6ACt3gzoTgdIaNHK0RL+dWwy2pEDA5Bu1API6g1A0Bp3kFKpam5E5lkK1YY7iNYFS/UinfD3IdEIoxYYgBYwzaGZkgVeiTevCPRr2Sqakk0VQSfHyQL/QKQI7u8+jUpgAEoAAjg0LVDggnjzWsC4lq+CFki2+RotoHehBAo8BOgudTOPeuBn6oFBnCHHE0C51Nwq8kYziVc7EXkob/xMvAgTrjtv9Ui81T0O8G+/V3E5XLhjY/eOP7slDQK6YzdY67sw+BfSXGp/r2VbQyaR1YY88qkQd0lP71LC/EJgN+JZXebBntLXEDgzoCkx4VtEQEZMuH/m2IpK52wpg9ALsVSQA+xvSFCxaXIJCtdQiRWfuDhgbMj1XsR63vRzKGsZ97MQq0ginHEXB3r0bcJbpQBiDMPnTDUuwpka0lCaBqqHip6JNNQFq8mKb4NvPFQGvmwoti/sqXcgvzhuG4Gs1EtTizDOPjCDSOGm3AtBpwnuKkVtBjqpIwMJHSGrEaTK0Vs8jq4XTzhFaNSj0Drunq7XB9I6pmFsE6SYPjBI/kV+HMkhaA/TqVrMqcTBoT0CTbVB0rU6VQRPfuJ1vRbZChRO/aKZ1qGyhHK8yKUbx3t7kOoeLsLuC8AMZX/GbehBptwvyPxgV1gqNGVkPdUynH6OtfjsBF/5ZMNrbieaJi+nZmJYOGcKjY3ESo0W79+1lqTSD5YNS9ojW8GyBWuMhZb2eFO0Jar2+LZEQ46rMIQ563Prm3g7IlIgBRmpSQ/qWdGxj/5T4lm5XdNyLk2ZGWoqZitmqCVyXDw5N4aokMOjWNYMWBl9izpBrCWe3XRQNGzprMXmxbPu08atOgm/ZV/S9RklusDbpvlHbUSPi40A2QoY2VibAyBqqB69/sVcVCQuHvcrHLwJF0pVcKtr68pCeg4J6FaXCQSCGw6hbuwpS3DyoD7sKXhdrLEJLumesFvzFT5sEzOG3eZoMwfgrDbZRp5zVhsw8V7346zu6Ygh2lnI6Ai6wu6JdGummVcZU3KTMgMqlcvSHuqEvDXpkVM/fe4if6VSVAr5zk/LgnZUQUenWrV4nDIcmyXzagZi0V6RVtU1gIuilG8TwEMJMOpAgETDqN/VIRoRuOIblKIAlsyrGdANvWZVXQNdTsEZgV79PlPXQFdFQHVkV6uGVjhOadgdVNavAbroSJBW1TXQZe/PKwd6HFeYghmAei64YMXFlmMLVWJTK15GP+KliKaFZs1QszjWtRKGTGmoKySmrHVfElOQ6vLKJeZ2jBsyxn9W5oBoUHR0tBW/OBCPU+ou0irr18iCAmtW1bUsFL75+sUhJ0kUxhzl/t3b0wbfv+j7jaWCt18rtOarDFNUi9Kt6cuxIVkTukjM1fZfQ5E3xpG1t7FW2BSS99frUtM7e8NIDi5GYalQ1Q8tNPXiJIok82gGgZU7IDApa+GEUAmSWpsqFrP6yBloaFklCchKssckKeRR8aW2lzqzjDyiGx5zm3SlmzNNTbMqlG7sOsH7oNV4BaT62jV2nWDWTYU1dZcLosgJUw9hLuH8yKT2l88ozL5/oudDegCYrYb0asU4NoSGcDaa6vn0VVUTk6OtmaZYKoSGzo4YmqnfJrxCrERK3r5aVluH/xjfuCbbvz5urfUG4ByyOjvdC0rdqt4EpmL9muCgVriI0iT0yuo1O4xaPLPeHAfjR9BuSDoUQF54mp9Ip4LuzvJy7CA6FTxQplyG+MLqIPKrmdpAeeGbtGJkixIt9NDYwhYNXasP81p4HYvpoxkbOf3plXOWml8m3UQdvsSkZsX0i8RR9fSzz+jd/w==</diagram></mxfile>
\ No newline at end of file