Skip to Content

Wiki source code of Softwareentwicklung

Version 3.1 by Marco Grawunder on 2026/08/25 14:54
Hide last authors
Marco Grawunder 1.1 1 [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2
3 {{toc/}}
4
5 = Anforderungen: Spielumsetzung =
6
7 * Client-Server-Umsetzung (Spiellogik auf Server!)
8 ** Der Server muss komplett Java-basiert sein
9 ** Der Client kann in Java sein, muss es aber nicht. Es ist auch erlaubt, hier z.B. Web-Frameworks wie Angular oder React zu verwenden. ACHTUNG! Das kann zu einem deutlich höherem Aufwand führen, man spart sich aber JavaFX ;-)
10 * Aus didaktischen Gründen (nicht optional!):
11 ** „beliebig“ viele registrierte Nutzer
12 ** mehrere Spielrunden gleichzeitig im Server
13 ** Spieler können **vom selben Client aus** an mehreren Spielen teilnehmen (also nicht mehrere Clients starten und dann teilnehmen)
14 * Chat 
15 ** globaler Chat im Hauptmenü
16 ** Lobby und Spielechats
17 * Nutzerverwaltung
18 ** 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.
19 ** relationales DBMS
20 ** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
21 * KI (je nach Spiel, siehe Start-Folien)
22 ** Das Spiel muss die Integration einer KI unterstützen
23 ** Es muss eine einfache (z.B. zufallsbasierte) KI umgesetzt werden
24 * Ansatz muss Model-View-Presenter Anforderungen erfüllen
25 * Muss mit möglichst wenig Aufwand möglich sein, andere Client-Arten anzubinden (z.B. Console)  u.a. Spiellogik auf Server
26 * Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
27 * Achtung!
28 ** Wichtig ist guter, erweiterbarer und wartbarer Code und eine gute Benutzerführung
29 ** Wenn das Spiel dann zusätzlich noch optisch gut aussieht, um so besser.
30
31 {{info}}
32 **Wichtig!**
33
34 * Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
35 * Lieber etwas weniger sehr gut umsetzen, als vieles schlecht! Qualität vor Quantität!
36 * Bedienbarkeit ist wichtig! Optisches Design weniger!
37 * „KISS: Keep it simple stupid“
38 * Fokus auf das Wichtige! Es gibt keine Zusatzpunkte für Dinge wie
39 ** Freundeslisten
40 ** privaten Chat
41 ** 3D
42 * Sie dürfen die Regeln vereinfachen/verändern! Je nach Veränderung kann diese natürlich auch zu einer Reduktion der Komplexität und damit auch zu einer schlechteren Bewertung führen.
43 * Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
44 {{/info}}
45
46 = Anforderungen: Die vordefinierten Meilensteine =
47
48 Um gut in das SWP zu starten, gibt es drei **vordefinierte** Meilensteine.
49
50 * Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht.
Marco Grawunder 2.1 51 * Für den zweiten Meilenstein (s.u.) gibt es eine [[Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]]. Das ist die erste Präsentation bei mir.
Marco Grawunder 1.1 52 * Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
53 * Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
54
55 == Meilenstein 1: Basisarchitektur mit UserManagement (Vertikaler Durchstich, wird gemeinsam gemacht) ==
56
57 * Hier geht es darum, die Basisarchitektur des SWP kennen zu lernen und gemeinsam in das SWP hineinzufinden.
58 * 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)
59 * Neue Nutzer sollen sich für das Spiel registrieren können.
60 * Registrierte Nutzer sollen sich am Spiel anmelden können.
61 * Die Nutzer sollen nach dem Einloggen in das Hauptmenü gelangen und dort alle Nutzer sehen, die auch eingeloggt sind.
62 * Es soll eine Liste aller verfügbaren Lobbies angezeigt werden.
63 * Man soll neue Lobbies mit einem Namen anlegen können
64 * Man soll existierenden Lobbies beitreten können (ohne die Lobbies selber anzuzeigen)
65
66 {{success}}
67 **Hinweis:**
68
69 Hinweis: Dieser Meilenstein wird gemeinsam als Einführung für das Software Projekt durchgeführt und wird vor allem durch die Übungsblätter abgedeckt. Es findet am Ende also keine Präsentation statt.
70 {{/success}}
71
72 == Meilenstein 2: Hauptmenü, Chat, Spiel-Ansätze ==
73
74 * Die Nutzer im Hauptmenü, in der Lobby und im Spielfenster sollen jeweils untereinander Nachrichten in einem Chat versenden können.
75 * Es soll kein Refresh-Button verwendet werden, um die Nutzerliste im Hauptmenue (bzw. der Lobby) zu aktualisieren oder um neue Chat-Nachrichten abzurufen.
76 * 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.
77 * 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!
78
79 == Meilensteine 3 - (X-1) ==
80
81 Es ist notwendig, **zusätzliche eigene Meilensteine zu definieren (mindestens 2-3)**, 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!**
82
83 == Meilenstein X "Prototyp" ==
84
85 * 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(n), die den Datenbankzugriff regeln, darf niemand wissen, auf welche Weise die Daten gespeichert sind.
86 * Hier soll es eine erste, möglichst vollständige Version des Spiels geben (Feature-Complete).
87 * Es dürfen noch Fehler drin sein und die Bedienbarkeit muss noch nicht ganz ausgereift sein.
88 * Es dürfen danach noch Änderungen und Erweiterungen gemacht werden.
89
90 {{success}}
91 **Hinweis:**
92
93 * Die Anforderungen sind die **Minimalanforderungen**.
94 * Es darf ruhig zum jeweiligen Zeitpunkt schon mehr realisiert werden.
95 * Aber: Fokus auf das Wichtige!
96 ** Keine Freundeslisten
97 ** Keinen privaten Chat
98 ** kein 3D etc.
99 ** Die Spielanleitung kann als PDF zur Verfügung gestellt werden.
100 * Im Zweifelsfall ist es wichtiger, **eine gute Basis** zu haben und nicht so weit zu sein wie es der Meilenstein verlangt. Auf keinen Fall sollte man aus Gründen der Meilensteinerreichung Dinge einfach "runterhacken" um sie hinterher wieder aufzuräumen. Das wäre dann unnötige Arbeit!
101 {{/success}}
102
103 = Anforderungen: Nutzung von KI Tools =
104
105 Die Verwendung von KI-Tools wie ChatGPT, Copilot oder Google Gemini ist inzwischen auch in der Software Entwicklung angekommen. Auch im SWP ist die Verwendung von KI-Tools in gewissem Rahmen erlaubt und möglich.
106
107 **~1. Transparenzpflicht:**
108 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
109
110 |~/~/ Generated with ChatGPT at 31.03.2025
111
112 **Ausnahme**: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
113
114 Jede nicht dokumentierte Verwendung muss leider einem Plagiat (wie Copy/Paste aus Stackoverflow ohne Referenz) gleichgestellt werden und hat die üblichen Konsequenzen.
115
116 **2. Keine vollständige Automatisierung:**
117 KI-Tools dürfen zur Inspiration, Ideenfindung oder zum Debugging genutzt werden, aber keine kompletten Programmteile (z.B. ganze Klassen oder Module) dürfen automatisiert generiert und ungeprüft übernommen werden. Die Endverantwortung für die Funktionsweise und das Verständnis liegt bei den Studierenden!
118
119 **3. Lernen steht im Vordergrund:**
120 KI darf nicht verwendet werden, um Aufgaben automatisiert zu lösen, sondern nur als ergänzende Unterstützung bei Verständnisproblemen oder als Hilfsmittel beim Lernen.
121
122 **4. Individuelle Lösungspflicht:**
123 Alle wesentlichen Design- und Architekturentscheidungen (z.B. Datenmodell, Hauptlogik, Schnittstellen) müssen selbstständig ohne KI-Tools durch die Studierenden getroffen werden.
124
125 = Teilaufgabe 4: Implementierung und Test =
126
127 * Implementieren Sie Ihr Produkt basierend auf dem Entwurf (passen Sie den Entwurf ggf. an)
128 * Projektname muss Gruppenname enthalten!
129 * (((
130 Maven:
131
132 * Das Produkt muss sich mit Hilfe von **maven** bauen lassen.
133 * Das Bauen muss **ohne** mvn install funktionieren.
134 * Die Tests müssen über **maven** ausgeführt werden.
135 * **GUI-Tests** müssen sich ausschalten lassen.
136 * Andere Build-Tools wie Gradle sind nicht (mehr) erlaubt dürfen maximal ergänzend verwendet werden. Maven muss aber funktionsfähig vorhanden sein.
137 )))
138 * (((
139 Sinnvoll: (echtes) Pairprogramming (mit Tauschen der Rollen!): [[Hinweise zum Pairprogramming>>url:https://developer.atlassian.com/blog/2015/05/try-pair-programming/?utm_source=facebook&utm_medium=social&utm_campaign=atlassian_try-pair-programming]]
140
141 * Es gibt ein Plugin für IntelliJ, mit dem man gemeinsam am Code arbeiten kann (habe ich allerdings noch nicht getestet) 
142 ** 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>>url:https://www.heise.de/news/Entwicklungsumgebung-JetBrains-veroeffentlicht-Plug-in-fuer-Pair-Programming-4915934.html?wt_mc=nl.red.ho.ho-nl-daily.2020-10-01.link.link]])
143 )))
144 * Sinnvoll: längere Programmiersitzungen
145 * (((
146 Erstellen Sie dabei die nötigen Systemunterlagen (tw. erst zum Ende des Projektes)
147
148 * Benutzerhandbuch,
149 * Testunterlagen,
150 * Installationshandbuch etc.
151 )))
152 * (((
153 [[Vorlesungsvideos u.a. zu Testen>>doc:Main.Organisatorisches.WebHome||anchor="HVorlesungsvideos"]]. Testen Sie die wichtigen Klassen mit JUnit, nicht erst am ENDE!
154
155 * Hilfreich: Dependency Injection (z.B. Google Guice)
156 * TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
157 * Beachten Sie, dass die GUI-Tests normalerweise nicht mit ausgeführt werden sollen, damit die Tests problemlos auch auf einem Build-Server (wie bamboo) ausgeführt werden können.
158 * Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
159 )))
160 * Führen Sie Integrations- und Endtests durch
Marco Grawunder 2.1 161 * [[Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch>>doc:Main.Projektarbeit.WebHome||anchor="HGruppenweitesCodeReview28Team-Review29"]]
Marco Grawunder 1.1 162 * Nutzen Sie Tools wie FindBugs, Checkstyle oder SonarLint
163 * (((
164 **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!)**
165
166 [[image:Main.Aufgabenstellung.WebHome@Warnung.png||alt="Warnung"]]
167 )))
168 * In Scrum muss ein Produktinkrement getestet und lauffähig sein.
169 * Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
170 * Das MVP sollte "von Hand" erstellt werden und sich nicht auf Tools wie AfterburnerFX abstützen. Die Erfahrung zeigt, dass dies sonst im Laufe der Zeit viele Dinge (insbesondere Tests) unnötig verkompliziert.
Marco Grawunder 2.1 171 * Beachten Sie auch die Hinweise zur [[Verwendung von KI>>doc:Main.Softwareentwicklung.WebHome||anchor="HAnforderungen:NutzungvonKITools"]]
Marco Grawunder 1.1 172