• Technische und funktionale Anforderungen
• Allgemeine Regeln zur Brettspieladaption
• Vorgegebene Meilensteine
  • Meilenstein 1: Basisarchitektur mit UserManagement (Vertikaler Durchstich, wird gemeinsam gemacht)
  • Meilenstein 2: Hauptmenü, Chat, Spiel-Ansätze
  • Meilensteine 3 - (X-1)
  • Meilenstein X "Prototyp"
• Nutzung generativer KI-Werkzeuge
• Implementierung, Test und Qualitätssicherung
• Siehe auch

Technische und funktionale Anforderungen

• Client-Server-Umsetzung; die zentrale Spiellogik liegt auf dem Server.
  • Der Server muss vollständig Java-basiert sein.
  • Der Client kann ebenfalls in Java umgesetzt werden, muss dies aber nicht. Alternativ können z. B. Web-Frameworks wie Angular oder React verwendet werden. Dabei ist zu berücksichtigen, dass eine zusätzliche Web-Technologie insbesondere zu Beginn einen höheren Integrations- und Einarbeitungsaufwand verursachen kann.
• Aus didaktischen Gründen (nicht optional!):
  • „beliebig“ viele registrierte Nutzer
  • mehrere Spielrunden gleichzeitig im Server
  • Spieler können vom selben Client aus an mehreren Spielen teilnehmen (also nicht mehrere Clients starten und dann teilnehmen)
• Chat 
  • globaler Chat im Hauptmenü
  • Lobby und Spielechats
• Nutzerverwaltung
  • gekapselter Zugriff, d.h. es darf für die Verwendung nicht sichtbar sein, wie die Daten wirklich verwaltet werden. Initial wird hier beispielsweise mit einer hauptspeicherbasierten Struktur gearbeitet.
  • relationales DBMS 
  • einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
• Computergesteuerte Spieler (je nach aktueller Spielaufgabe)
  • Das Spiel muss die Integration eines computergesteuerten Spielers unterstützen.
  • Es muss mindestens eine einfache Strategie, z. B. eine zufallsbasierte Strategie, umgesetzt werden.
• Bei einem JavaFX-Client muss die Struktur die Anforderungen des Model-View-Presenter-Ansatzes (MVP) erfüllen.
• Andere Client-Arten, z. B. ein Konsolenclient, sollen mit möglichst geringem Aufwand angebunden werden können. Dies ist ein weiterer Grund dafür, die Spiellogik auf dem Server zu halten.
• Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
• Qualität und Bedienbarkeit haben Vorrang vor visuellen Zusatzfunktionen.
  • Wichtig sind insbesondere verständlicher, erweiterbarer und wartbarer Code sowie eine gute Benutzerführung.
  • Eine ansprechende optische Gestaltung ist willkommen, sofern sie nicht zulasten der Kernfunktionalität geht.

Allgemeine Regeln zur Brettspieladaption

• keine Originalgrafiken ohne Freigabe veröffentlichen,
• Regeln dürfen vereinfacht/angepasst werden,
• Spielspaß soll erhalten bleiben,
• Aktionen anderer Spieler müssen nachvollziehbar sein,
• Zusatzdienste nur sinnvoll einsetzen.

Vorgegebene Meilensteine

Für den Einstieg und zur Orientierung im Projektverlauf gibt es mehrere vorgegebene Meilensteine. Zusätzlich definiert jede Gruppe eigene fachliche Meilensteine.

• Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht. 
• Für den zweiten Meilenstein gibt es eine Zwischenpräsentation. 
• Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
• Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.

Meilenstein 1: Basisarchitektur mit UserManagement (Vertikaler Durchstich, wird gemeinsam gemacht)

• Hier geht es darum, die Basisarchitektur des SWP kennen zu lernen und gemeinsam in das SWP hineinzufinden.
• Die Speicherung der Nutzer erfolgt im Hauptspeicher, d.h. nach einem Neustart, sind keine Nutzer mehr vorhanden (es gibt allerdings vordefinierte Nutzer, die später wieder entfernt werden müssen)
• Neue Nutzer sollen sich für das Spiel registrieren können.
• Registrierte Nutzer sollen sich am Spiel anmelden können.
• Die Nutzer sollen nach dem Einloggen in das Hauptmenü gelangen und dort alle Nutzer sehen, die auch eingeloggt sind.
• Es soll eine Liste aller verfügbaren Lobbies angezeigt werden.
• Man soll neue Lobbies mit einem Namen anlegen können
• Man soll existierenden Lobbies beitreten können (ohne die Lobbies selber anzuzeigen)

Meilenstein 2: Hauptmenü, Chat, Spiel-Ansätze

• Die Nutzer im Hauptmenü, in der Lobby und im Spielfenster sollen jeweils untereinander Nachrichten in einem Chat versenden können.
• Es soll kein Refresh-Button verwendet werden, um die Nutzerliste im Hauptmenue (bzw. der Lobby) zu aktualisieren oder um neue Chat-Nachrichten abzurufen.
• Es soll ein einfaches Modell des Spielmodells vorliegen, d.h. es sollten das statische Modell (Klassendiagramm) und einige dynamische Modelle (Aktivitätsdiagramm, ggf. auch Zustandsdiagramm oder Sequenzdiagramm) vorliegen.
• Idealerweise kann man z.B. mit Hilfe der Console (oder eine einfachen GUI) schon ein wenig mit dem Spiel interagieren, das ist aber nicht zwingend notwendig!

Meilensteine 3 - (X-1)

Es ist notwendig, zusätzliche eigene Meilensteine zu definieren (mindestens 3-4), die sich an die erste Präsentation anschließen. Der Meilenstein für den Prototypen darf nicht der dritte Meilenstein sein! Die Meilensteine repräsentieren dabei wichtige Zwischenziele, die erreicht worden sind und sollten sich konkret auf das Spiel beziehen. Meilensteine müssen natürlich auch ein Datum haben!

Meilenstein X "Prototyp"

• Es soll das UserManagement mit Hilfe einer relationalen Datenbank realisiert werden. Dazu soll das Schema für die Nutzerinformationen modelliert und über Java zugreifbar sein. Der Zugriff soll grundsätzlich auf beliebige per JDBC ansprechbare Datenbanken erfolgen und mit möglichst wenig Aufwand austauschbar sein (maximal eine neue Klasse). Außerhalb der Klasse, die den Datenbankzugriff regeln, darf niemand wissen, auf welche Weise die Daten gespeichert sind.
• Hier soll es eine erste, möglichst vollständige Version des Spiels geben (Feature-Complete).
• Es dürfen noch Fehler drin sein und die Bedienbarkeit muss noch nicht ganz ausgereift sein.
• Es dürfen danach noch Änderungen und Erweiterungen gemacht werden.

Nutzung generativer KI-Werkzeuge

Generative KI-Werkzeuge wie ChatGPT, Copilot oder Gemini können im Softwareprojekt unterstützend eingesetzt werden. Dabei gelten die folgenden Regeln. Für mit KI-Unterstützung erzeugten Code und Text trägt die Gruppe dieselbe Verantwortung wie für vollständig selbst erstellte Inhalte.

• • 1. Transparenzpflicht:
       Alle von KI-Tools generierten Code- oder Textpassagen müssen im Code oder in den Abgaben klar als solche gekennzeichnet werden. Zum Beispiel durch Kommentare wie

Ausnahme: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.

Nicht dokumentierte weitergehende KI-Nutzung wird wie die ungekennzeichnete Übernahme fremder Inhalte behandelt und kann entsprechende Konsequenzen haben.

2. Keine vollständige Automatisierung:
KI-Werkzeuge dürfen z. B. zur Ideenfindung, zum Erklären, beim Debugging oder für Vorschläge genutzt werden. Größere generierte Programmteile dürfen nicht ungeprüft übernommen werden. Die Studierenden müssen verwendeten Code verstehen, prüfen und fachlich vertreten können.

3. Lernen steht im Vordergrund:
KI-Unterstützung darf den eigenen Lern- und Entwicklungsprozess nicht ersetzen. Insbesondere müssen die Beteiligten die resultierende Lösung verstehen und selbstständig weiterentwickeln können.

4. Individuelle Lösungspflicht:
Wesentliche Design- und Architekturentscheidungen – z. B. Datenmodell, zentrale Spiellogik und Schnittstellen – müssen von der Gruppe selbst getroffen, verstanden und begründet werden. KI kann dabei als Diskussions- oder Reflexionshilfe dienen, nicht als verantwortliche Entscheidungsinstanz.

Implementierung, Test und Qualitätssicherung

• Implementieren Sie das Produkt auf Grundlage des Entwurfs. Wenn sich während der Implementierung Änderungen ergeben, muss der Entwurf entsprechend nachgeführt werden.
• Projektname muss Gruppenname enthalten!

• Maven:

  • Das Produkt muss sich mit Hilfe von maven bauen lassen.
  • Der Build muss ohne vorheriges lokales `mvn install` funktionieren.
  • Die Tests müssen über maven ausgeführt werden.
  • GUI-Tests müssen sich ausschalten lassen.
  • Andere Build-Werkzeuge wie Gradle dürfen höchstens ergänzend eingesetzt werden. Der Maven-Build muss vollständig funktionsfähig bleiben.

• Sinnvoll: (echtes) Pairprogramming (mit Tauschen der Rollen!): Hinweise zum Pairprogramming

  • Es gibt ein Plugin für IntelliJ, mit dem man gemeinsam am Code arbeiten kann (habe ich allerdings noch nicht getestet) 
    • Code With Me: "Das kostenlose Plug-in lässt sich direkt aus der Entwicklungsumgebung heraus über Preferences / Settings | Plugins | Marketplace installieren" (https://www.heise.de/news/Entwicklungsumgebung-JetBrains-veroeffentlicht-Plug-in-fuer-Pair-Programming-4915934.html)
• Sinnvoll: längere Programmiersitzungen

• Erstellen Sie dabei die nötigen Systemunterlagen (tw. erst zum Ende des Projektes)

  • Benutzerhandbuch,
  • Testunterlagen,
  • Installationshandbuch etc.

• Videos und Materialien u. a. zum Testen. Testen Sie wichtige Klassen kontinuierlich mit JUnit und nicht erst am Projektende.

  • Nutzen Sie Dependency Injection konsequent; auf der Serverseite insbesondere über Spring.
  • TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
  • GUI-Tests müssen separat deaktivierbar sein, damit der normale Testlauf auch auf einem CI-/Build-Server ohne grafische Umgebung ausgeführt werden kann.
  • Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
• Führen Sie Integrations- und Endtests durch
• Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch
• Nutzen Sie Werkzeuge zur statischen Analyse und Qualitätssicherung, z. B. SpotBugs, Checkstyle, SonarLint oder SonarQube.

• Es ist grundsätzlich nicht erlaubt, Warnungen zu unterdrücken (Wenn Warnungen unterdrückt werden, dann muss es einen sehr guten Grund geben! Jede zusätzliche Warnung muss dokumentiert und begründet sein!)

  

• In Scrum muss ein Produktinkrement getestet und lauffähig sein.
• Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
• Bei einem JavaFX-Client soll die MVP-Struktur nachvollziehbar selbst umgesetzt werden. Zusätzliche Frameworks, die diese Struktur stark automatisieren, sollten nur eingesetzt werden, wenn ihre Auswirkungen auf Testbarkeit und Wartbarkeit verstanden und begründet werden können.
• Beachten Sie auch die Hinweise zur Verwendung von KI

Siehe auch

• Stichwortverzeichnis
• Glossar