From 220ecbae0aa4e7f869c49099bd82697b5873124e Mon Sep 17 00:00:00 2001
From: Rasmus <rburwitz@uni-bremen.de>
Date: Sun, 31 May 2020 20:19:02 +0200
Subject: [PATCH] Konzept. korr

---
 doc/Architekturbeschreibung.tex | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/doc/Architekturbeschreibung.tex b/doc/Architekturbeschreibung.tex
index 48bf2136..c4985271 100644
--- a/doc/Architekturbeschreibung.tex
+++ b/doc/Architekturbeschreibung.tex
@@ -1114,35 +1114,35 @@ Hier setzen wir die .. Strategie um. \\
 \section{Konzeptionelle Sicht} \label{sec:konzeptionell}
 
 
-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.
+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 nutzt 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 Entscheidung zu der Datenbank geht aus Strategie 3.1 heraus.  
+Die Datenbanksoftware wird im \textit{Server} dazu genutzt, um unsere Spielstände zu persistieren. Unsere Datenbank kommuniziert über die \textit{ORM-Lite} Schnittstelle mit der im Server liegenden Persistenz. Die Entscheidung zu der Datenbank geht aus Strategie 3.1 heraus.  
 
 \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. 
+Die \textit{Persistence} stellt die Verbindung zwischen dem gesamten \textit{System} und der \textit{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 und beim nächsten Starten abrufbar sein. Zwischen der Persistenz und Service existiert die Daten- und Kontrollfluss Verbindung \textit{update}. Außerdem nutzt die Persistenz das \textit{Update} Interface von \textit{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 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. 
+Das \textit{Model} beschreibt die logische Struktur der Datenbank. Hiermit wird bestimmt, wie auf Daten zugegriffen werden kann. 
+In unserem Model sind Daten des \textit{Schiffs}, der \textit{Ausrüstung}, der \textit{Spielkarte} und der \textit{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 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. 
+\textit{Service} ist die Komponente, die die Spielzugsdaten übermittelt bekommt und dann überprüft, ob der Spielzug nach den \textit{Spielregeln} akzeptiert wird oder nicht. Hierzu nutzt Service ein \textit{Kontrollfluss} Interface von \textit{Model} und hat \textit{Datenfluss} und \textit{Kontrollfluss} mit \textit{Persistenz}, um Daten abzugleichen, zu geben und zu nehmen. Außerdem gibt es Daten und Kontrollaustausch mit \textit{Communication}, worüber die Spielzugdaten vom \textit{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. 
+Die \textit{Communication} Komponente des \textit{Servers} dient dazu, die vom Client geschickten Spielzugdaten zu entschlüsseln und sie \textit{Service} zur Verfügung zu stellen. Dies passiert über eine \textit{Data/Control} Schnittstelle. Außerdem sollen die geänderten Spielzugdaten von der Datenbank aktualisiert werden und dem Client zur Verfügung gestellt werden. \textit{Communication} (Server) hat eine \textit{TCP/Request/Response} Schnittstelle zu Communication im Client. 
 
 \textbf{Communication (Client):}
-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.
+Die \textit{Communication} Komponente im \textit{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 \textit{Server}. Über die Schnittstelle \textit{Update}, von \textit{Model} zur Verfügung gestellt, kann das \textit{Model} einmal von \textit{Communication}, als auch von \textit{Controller} geupdatet werden. Über die Schnittstelle \textit{Data}, von \textit{Communication} zur Verfügung gestellt, werden Daten dem \textit{Controller} zur Verfügung gestellt.
 
 \textbf{Model (Client):}
-Das Model im Client stellt die Datenstruktur unserer Datenbank dar. Es wird allgemein 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.
+Das \textit{Model} im \textit{Client} stellt die Datenstruktur unserer Datenbank dar. Es wird allgemein alles in ihm gespeichert, sodass es zum spielen genutzt werden kann. Model stellt ein Interface \textit{Update} zur Verfügung, worüber \textit{Controller} und \textit{Communication} das \textit{Model} updaten können. \textit{Model} stellt außerdem ein \textit{Control} Interface zur Verfügung, über welches \textit{Controller} die geforderten Daten aus \textit{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. 
+In \textit{Controller} passiert die gesamte Logik des \textit{Clients}. \textit{Controller} nutzt das \textit{Data} Interface von \textit{Communication}, um Daten zum \textit{Server} zu schicken, \textit{Update} von \textit{Model} um das Model zu updaten und \textit{Control} von \textit{Model}, um Daten von \textit{Model} zu empfangen. \textit{Controller} stellt ein Interface \textit{Instruct} zur Verfügung, über welches die \textit{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 \textit{Interface/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 \textit{View} enthalten. Um erforderliche Daten zu erhalten und zu Eingaben des Users weiterzuleiten, benutzt \textit{Interface/View} ein Interface \textit{Instruct} von \textit{Controller}. \\
 
 \textbf{Transitionen}
 
-- 
GitLab