Skip to content
Snippets Groups Projects
Commit 5f9ce04f authored by Rasmus Burwitz's avatar Rasmus Burwitz
Browse files

Ausführungssicht korregiert

parent 602a90b3
No related branches found
No related tags found
No related merge requests found
......@@ -1419,7 +1419,7 @@ Der Controller erstellt ein neues Request, welches dann an den ClientControllerC
\end{center}
\end{figure}
Dieses Diagramm beschreibt nun eine Attack-Sequenz basierend auf dem vorherigen abstrakten Diagramm. In diesem Fall wird in dem WeaponUI eine Waffe durch Mausklick ausgewählt, und dann der Raum auf dem Gegnerschiff, der 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.
Dieses Diagramm beschreibt nun eine Attack-Sequenz basierend auf dem vorherigen abstrakten Diagramm. In diesem Fall wird in dem \textit{WeaponUI} eine Waffe durch Mausklick und dann der Raum auf dem Gegnerschiff, der angegriffen werden soll ausgewählt. Dann wird dieses als Attack-Request weitergegeben an den \textit{ClientControllerCommunicator}, welcher es wiederum an die Netzwerkschnittstelle des \textit{Clients} weiterleitet. Der Request wird dann durch diese Schnittstelle an den \textit{Server} geschickt. Der \textit{Server} empfängt den Request und gibt es an seinen \textit{ServerServiceCommunicator}, welcher dann den \textit{AttackService} auswählt und ihm denRequest weiterleitet. Dieser überprüft dann mittels \textit{validMove()}, ob das Angriffskommando valide ist oder nicht. Wenn es valide ist, wird die Logik ausgeführt, und das gegnerische Schiff in der Datenbank aktualisiert. Dann wird der aktualisiert welcher Spieler am Zug ist. Danach wird ein Response als neue \textit{Ship-Objekte} an den \textit{ServerServiceCommunicator} gegeben, welcher das \textit{Ship} wieder an die Servernetzwerkschnittstelle gibt. Der Response wird dann zum \textit{Client} übertragen und dort an den \textit{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 \textit{View} wartete bis jetzt noch auf ein Ergebnis welches er nun bekommt, wodurch auch er sich aktualisiert.
\subsection{Login}
......@@ -1430,7 +1430,7 @@ Dieses Diagramm beschreibt nun eine Attack-Sequenz basierend auf dem vorherigen
\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 ein 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 die View. Nun ist der User eingeloggt und kann der Session beitreten.
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 ein 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 die \textit{View}. Nun ist der User eingeloggt und kann der Session beitreten.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment