Protokoll vom 11.11.2024 hinzugefügt

Protokolle/Präsentationen/11.11.2024.md

@@ -0,0 +1,74 @@
+**Uhrzeit:** 15:00 - 16:00
+
+**Teilnehmer:** Gruppe, vollzählig; Hambrügge, Fietkau
+
+**Ort:** Online über BigBlueButton
+
+<br>
+
+### **Fragen der Gruppe:**
+
+<br>
+
+### **Präsentation:**
+
+**1. Was haben wir letzte Woche gemacht?**
+
+* Bearbeitung der Artefakte nach vorher besprochener Aufgabenverteilung
+* Behebung verschiedener Fehler in den Diagrammen
+
+**2. Was hat uns an der Arbeit gehindet?**
+
+* Versionierungsfehler bei den Flussdiagrammen
+* Import von Server/Client Struktur von Battleship bereitete Probleme
+
+**3. Was werden wir nächste Woche machen?**
+
+* Beginn der Bearbeitung der Implementierungsphase
+    * Aufgaben verteilen und bearbeiten (Gruppentreffen 12.11.2024)
+
+<br>
+
+### **Fragen, Empfehlungen und Anmerkungen durch den Betreuer für die einzelnen Artefakte**
+
+**1. Klassendiagramme (Schmelz)**
+
+* Sehr viel Leerraum zwischen den einzelnen Klassen im Diagramm, welche ggf. noch gefüllt werden können
+* Für Präsentation übersichtlicher und kompakter gestalten
+
+**2. Flussdiagramme (Wilkening, Schmidt)**
+
+* keine besonderen Anmerkungen zu "Spielzug_V2.1" und "Spielende_V2.1"
+
+* Diagramm ist zu detailliert und zu nah an der tatsächlichen Implementierung für die Analysephase
+    * Klassendiagramme sollten bisher nur die notwendigsten Attribute enthalten
+    * Es der Fokus hätte auf den existierenden Objekten als solche liegen müssen und wie diese miteinander Interagieren, weniger auf die Attribute der einzelnen Objekte
+
+**3. Sequenzdiagramme (Malkmus)**
+
+* Deutliche Verbesserung der Syntax und der Qualität der Sequenzdiagramme
+
+**Aber**
+
+* Es muss auf den Abstraktionsgrad geachtet werden, diese sollten nicht durcheinandergebracht werden
+* Man sollte Interaktionen von GUI Objekten/Client/Server auf der einen Seite und Klassenobjekten auf der anderen Seite zur besseren Übersichtlichkeit trennen.
+    * Beispiel Grundstück kaufen: Start bei Figur auf Feld (Startaktion), kaufen Button (Nutzerinteraktion). Es muss klar sein, dass Aktion 2 und 4/5 auf verschiedenen Ebenen sind. Weitere Iteration jetzt in Designphase nicht notwendig.
+
+**4. Testhandbuch (Szepielewicz)**
+
+* Derzeit verhältnismäßig viele händische Tests
+    * Beachtung der Notwendigkeit, diese Nach jedem Commit auch händisch zu testen, was sehr zeitaufwendig sein kann
+    * Händische Tests sollten daher soweit wie es geht reduziert werden
+* Soundlogik sollte vom tatsächlichen Abspielen der Sound entkoppelt werden. Dadurch kann man Soundtests vom händischen Tests lösen
+
+<br>
+
+### **Allgemeines Feedback durch den Betreuer**
+
+* Die Implementierungsphase darf begonnen werden
+* Es gibt in Implementierungsphase die Möglichkeit, von Ideen der Designphase abzuweichen. Dies kann man in Texten erläutern
+* Empfehlung Zielsetzung:
+    * Es ist riskant zu planen, dass man nach 3 Wochen erst ein spielbares Spiel hat Woche 1: Minimum viable Product: Spiel, wo man Ablauf im großen und Ganzen durchlaufen kann. Natürlich gibt es noch nicht alle Aktionen; aber die gröbsten Aktionen
+    * Woche 2: ALLE Use Cases der höchsten Priorität.
+    * Woche 3: Bug Fixes und Polishing
+    * Was im Main Branch liegt, sollte kompilierbar sein. Probleme und Spielabstürze intern kommunizieren.

Protokolle/Präsentationen/28.10.2024.md

@@ -8,8 +8,6 @@
 
 ### **Fragen der Gruppe:**
 
-<br>
-
 ### **Präsentation:**
 
 **1. Was haben wir letzte Woche gemacht?**
@@ -29,35 +27,28 @@
 * Beginn der Bearbeitung der Designphase
   * Aufgaben verteilen und bearbeiten (Gruppentreffen 29.10.2024)
 
-<br>
-
 ### **Fragen, Empfehlungen und Anmerkungen durch den Betreuer für die einzelnen Artefakte**
 
 **1. Rückmeldung Use-Cases (Müller)**
 
 Konkretes:
 
-* Serverbeitritt wurde als einen Use Case abgebildet. Nun sind diese in zwei einzelne Fälle
-  gesplittet.
+* Serverbeitritt wurde als einen Use Case abgebildet. Nun sind diese in zwei einzelne Fälle gesplittet.
   * Feedback: nicht Zielführend, die Anmeldung in 2 Cases zu splitten.
-* Unterschied zwischen 6 und 7? 
-  * Hier sollte der genaue Ablauf von Serverstart, Einloggen der Spieler und Einstellungen des
-    Spiels eingeügt werden
+* Unterschied zwischen 6 und 7?
+  * Hier sollte der genaue Ablauf von Serverstart, Einloggen der Spieler und Einstellungen des Spiels eingeügt werden
 * UC-game-11: Empfehlung auf dynamische, redundante Server zu verzichten, da dieser sehr aufwendig in der Implementierung ist
   * Das Spiel wird bei jeglicher Störung für alle Spieler beendet
 
 Grundsätzliches:
 
-* Sinn von Use-Case: Wir listen auf, was man alles so machen will. Dienen dazu „fachliche Aktionen“ dazustellen. NICHT, mehrmals UIs
-  dazustellen.
+* Sinn von Use-Case: Wir listen auf, was man alles so machen will. Dienen dazu „fachliche Aktionen“ dazustellen. NICHT, mehrmals UIs dazustellen.
 * Testhandbuch, Use-Cases und Use-Case-Beschreibung müssen einheitlich sein.
   * Wir reichen die Use-Cases bis Donnerstag nach
     * Mag den Abstraktionsgrad der Gameplay Use Cases
     * Handelsmenü und Karten vernünftig abgebildet
     * Sound im im Wesentlichen gut
-    * Feedback: Unglücklich, dass Use Case Liste und Beschreibungen nicht
-    übereinstimmen. Testhandbuch, Use Cases und Use Case Beschreibung
-    müssen einheitlich sein.
+    * Feedback: Unglücklich, dass Use Case Liste und Beschreibungen nicht übereinstimmen. Testhandbuch, Use Cases und Use Case Beschreibung müssen einheitlich sein.
 
 **2. Rückmeldung Testhandbuch (Schmidt)**
 
@@ -79,27 +70,23 @@ Grundsätzliches:
   * Start soll schwarzer Kreis sein. Schwarz/weiß ist ENDzustand
   * Ansonsten keine inhaltlichen Probleme.
 
-*Feedback PlayerState
-  * Man kann sehr gut Grenzen eines Zustandsdiagramm sehen, da dieses unübersichtlich wirkt
-    * In solchen Fällen ist ein hierarchisches Zustandsdiagramm empfehlenswert
-  * Settings Screen immer aufrufbar. 
-    * Wenn man von irgendwo auf Setting geht und wieder rausgeht, ist nicht offensichtlich, welches Menü gerade aktiv ist
+Feedback PlayerState 
+* Man kann sehr gut Grenzen eines Zustandsdiagramm sehen, da dieses unübersichtlich wirkt
+* In solchen Fällen ist ein hierarchisches Zustandsdiagramm empfehlenswert
+* Settings Screen immer aufrufbar.
+  * Wenn man von irgendwo auf Setting geht und wieder rausgeht, ist nicht offensichtlich, welches Menü gerade aktiv ist
+* Korrektur der Zustandadiagramme
+* Korrektur der Klassendiagramme
 
-Korrektur der Zustandadiagramme
-Korrektur der Klassendiagramme
-
-**5. Benutzerhandbuch (Wilkening)**
+5. Benutzerhandbuch (Wilkening)
 
 * Zustandsdiagramme als Platzhalter möglich
 * Handbuch sollte am Ende der Implementierungsphase Screenshots aus dem tatsächlichen Spiel enthalten
 
-<br>
-
 ### **Allgemeines Feedback durch den Betreuer**
 
 * Die Designphase darf begonnen werden
 * Die Use-Cases und das Testhandbuch müssen in eine kohärente Form gebracht werden (Abgabe am Donnerstag)
   * keine Abweichungen in den IDs
 * Die Diagramme werden ebenfalls korrigiert
-  * Das Klassendiagramm wurde für die Analysephase etwas vereinfacht, kann aber in der Designphase weiterverwendet werden
-  
+* Das Klassendiagramm wurde für die Analysephase etwas vereinfacht, kann aber in der Designphase weiterverwendet werden