Wiki source code of Softwareentwicklung

Version 8.1 by Marco Grawunder on 2026/08/26 09:04

Manage
- Copy
Actions
- Export
- Print Preview
Viewers
- Source
- Children
- Content
- Comments
- Attachments (1)
- History
- Information
- Likes

version	line-number	content
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
5.1	3	{{info}}
	4	Diese Seite enthält die allgemeinen technischen Anforderungen an die Softwareentwicklung im Softwareprojekt. Die konkrete Spielaufgabe und jahrgangsspezifische Vorgaben stehen im geschützten Bereich Aktuelles.
	5	{{/info}}
	6
1.1	7	{{toc/}}
	8
5.1	9	= Technische und funktionale Anforderungen =
1.1	10
5.1	11	* Client-Server-Umsetzung; die zentrale Spiellogik liegt auf dem Server.
	12	** Der Server muss vollständig Java-basiert sein.
	13	** 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.
1.1	14	* Aus didaktischen Gründen (nicht optional!):
	15	** „beliebig“ viele registrierte Nutzer
	16	** mehrere Spielrunden gleichzeitig im Server
	17	Spieler können vom selben Client aus** an mehreren Spielen teilnehmen (also nicht mehrere Clients starten und dann teilnehmen)
	18	* Chat
	19	** globaler Chat im Hauptmenü
	20	** Lobby und Spielechats
	21	* Nutzerverwaltung
	22	** 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.
	23	** relationales DBMS
	24	** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
5.1	25	* Computergesteuerte Spieler (je nach aktueller Spielaufgabe)
	26	** Das Spiel muss die Integration eines computergesteuerten Spielers unterstützen.
	27	** Es muss mindestens eine einfache Strategie, z. B. eine zufallsbasierte Strategie, umgesetzt werden.
	28	* Bei einem JavaFX-Client muss die Struktur die Anforderungen des Model-View-Presenter-Ansatzes (MVP) erfüllen.
	29	* 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.
1.1	30	* Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
5.1	31	* Qualität und Bedienbarkeit haben Vorrang vor visuellen Zusatzfunktionen.
	32	** Wichtig sind insbesondere verständlicher, erweiterbarer und wartbarer Code sowie eine gute Benutzerführung.
	33	** Eine ansprechende optische Gestaltung ist willkommen, sofern sie nicht zulasten der Kernfunktionalität geht.
1.1	34
	35	{{info}}
	36	Wichtig!
	37
	38	* Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
	39	* Lieber etwas weniger sehr gut umsetzen, als vieles schlecht! Qualität vor Quantität!
	40	* Bedienbarkeit ist wichtig! Optisches Design weniger!
5.1	41	* KISS: Lösungen möglichst einfach und nachvollziehbar halten.
1.1	42	* Fokus auf das Wichtige! Es gibt keine Zusatzpunkte für Dinge wie
	43	** Freundeslisten
	44	** privaten Chat
	45	** 3D
	46	* 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.
	47	* Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
	48	{{/info}}
	49
8.1	50	= Allgemeine Regeln zur Brettspieladaption =
	51
	52	* keine Originalgrafiken ohne Freigabe veröffentlichen,
	53	* Regeln dürfen vereinfacht/angepasst werden,
	54	* Spielspaß soll erhalten bleiben,
	55	* Aktionen anderer Spieler müssen nachvollziehbar sein,
	56	* Zusatzdienste nur sinnvoll einsetzen.
	57
5.1	58	= Vorgegebene Meilensteine =
1.1	59
5.1	60	Für den Einstieg und zur Orientierung im Projektverlauf gibt es mehrere vorgegebene Meilensteine. Zusätzlich definiert jede Gruppe eigene fachliche Meilensteine.
1.1	61
	62	* Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht.
5.1	63	* Für den zweiten Meilenstein gibt es eine [[Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]].
1.1	64	* Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
	65	* Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
	66
	67	== Meilenstein 1: Basisarchitektur mit UserManagement (Vertikaler Durchstich, wird gemeinsam gemacht) ==
	68
	69	* Hier geht es darum, die Basisarchitektur des SWP kennen zu lernen und gemeinsam in das SWP hineinzufinden.
	70	* 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)
	71	* Neue Nutzer sollen sich für das Spiel registrieren können.
	72	* Registrierte Nutzer sollen sich am Spiel anmelden können.
	73	* Die Nutzer sollen nach dem Einloggen in das Hauptmenü gelangen und dort alle Nutzer sehen, die auch eingeloggt sind.
	74	* Es soll eine Liste aller verfügbaren Lobbies angezeigt werden.
	75	* Man soll neue Lobbies mit einem Namen anlegen können
	76	* Man soll existierenden Lobbies beitreten können (ohne die Lobbies selber anzuzeigen)
	77
	78	{{success}}
	79	Hinweis:
	80
	81	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.
	82	{{/success}}
	83
	84	== Meilenstein 2: Hauptmenü, Chat, Spiel-Ansätze ==
	85
	86	* Die Nutzer im Hauptmenü, in der Lobby und im Spielfenster sollen jeweils untereinander Nachrichten in einem Chat versenden können.
	87	* Es soll kein Refresh-Button verwendet werden, um die Nutzerliste im Hauptmenue (bzw. der Lobby) zu aktualisieren oder um neue Chat-Nachrichten abzurufen.
	88	* 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.
	89	* 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!
	90
	91	== Meilensteine 3 - (X-1) ==
	92
7.1	93	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!
1.1	94
	95	== Meilenstein X "Prototyp" ==
	96
	97	* 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.
	98	* Hier soll es eine erste, möglichst vollständige Version des Spiels geben (Feature-Complete).
	99	* Es dürfen noch Fehler drin sein und die Bedienbarkeit muss noch nicht ganz ausgereift sein.
	100	* Es dürfen danach noch Änderungen und Erweiterungen gemacht werden.
	101
	102	{{success}}
	103	Hinweis:
	104
	105	* Die Anforderungen sind die Minimalanforderungen.
	106	* Es darf ruhig zum jeweiligen Zeitpunkt schon mehr realisiert werden.
	107	* Aber: Fokus auf das Wichtige!
	108	** Keine Freundeslisten
	109	** Keinen privaten Chat
	110	** kein 3D etc.
	111	** Die Spielanleitung kann als PDF zur Verfügung gestellt werden.
	112	* 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!
	113	{{/success}}
	114
5.1	115	= Nutzung generativer KI-Werkzeuge =
1.1	116
5.1	117	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.1	118
8.1	119	*
	120	**
7.1	121	**1. Transparenzpflicht:
	122	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
1.1	123
	124	\|~/~/ Generated with ChatGPT at 31.03.2025
	125
	126	Ausnahme: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
	127
5.1	128	Nicht dokumentierte weitergehende KI-Nutzung wird wie die ungekennzeichnete Übernahme fremder Inhalte behandelt und kann entsprechende Konsequenzen haben.
1.1	129
	130	2. Keine vollständige Automatisierung:
5.1	131	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.
1.1	132
	133	3. Lernen steht im Vordergrund:
5.1	134	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.
1.1	135
	136	4. Individuelle Lösungspflicht:
5.1	137	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.
1.1	138
5.1	139	= Implementierung, Test und Qualitätssicherung =
1.1	140
5.1	141	* Implementieren Sie das Produkt auf Grundlage des Entwurfs. Wenn sich während der Implementierung Änderungen ergeben, muss der Entwurf entsprechend nachgeführt werden.
1.1	142	* Projektname muss Gruppenname enthalten!
	143	* (((
	144	Maven:
	145
	146	* Das Produkt muss sich mit Hilfe von maven bauen lassen.
5.1	147	* Der Build muss ohne vorheriges lokales `mvn install` funktionieren.
1.1	148	* Die Tests müssen über maven ausgeführt werden.
	149	* GUI-Tests müssen sich ausschalten lassen.
5.1	150	* Andere Build-Werkzeuge wie Gradle dürfen höchstens ergänzend eingesetzt werden. Der Maven-Build muss vollständig funktionsfähig bleiben.
1.1	151	)))
	152	* (((
	153	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]]
	154
	155	* Es gibt ein Plugin für IntelliJ, mit dem man gemeinsam am Code arbeiten kann (habe ich allerdings noch nicht getestet)
	156	** 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]])
	157	)))
	158	* Sinnvoll: längere Programmiersitzungen
	159	* (((
	160	Erstellen Sie dabei die nötigen Systemunterlagen (tw. erst zum Ende des Projektes)
	161
	162	* Benutzerhandbuch,
	163	* Testunterlagen,
	164	* Installationshandbuch etc.
	165	)))
	166	* (((
5.1	167	[[Videos und Materialien u. a. zum Testen>>doc:Main.Videos.WebHome]]. Testen Sie wichtige Klassen kontinuierlich mit JUnit und nicht erst am Projektende.
1.1	168
5.1	169	* Nutzen Sie Dependency Injection konsequent; auf der Serverseite insbesondere über Spring.
1.1	170	* TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
5.1	171	* GUI-Tests müssen separat deaktivierbar sein, damit der normale Testlauf auch auf einem CI-/Build-Server ohne grafische Umgebung ausgeführt werden kann.
1.1	172	* Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
	173	)))
	174	* Führen Sie Integrations- und Endtests durch
6.1	175	* [[Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch>>doc:Main.Projektarbeit.WebHome\|\|anchor="HGruppenweitesCode-Review28Team-Review29"]]
5.1	176	* Nutzen Sie Werkzeuge zur statischen Analyse und Qualitätssicherung, z. B. SpotBugs, Checkstyle, SonarLint oder SonarQube.
1.1	177	* (((
	178	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!)
	179
4.1	180	[[image:Warnung.png\|\|alt="Warnung"]]
1.1	181	)))
	182	* In Scrum muss ein Produktinkrement getestet und lauffähig sein.
	183	* Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
5.1	184	* 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.
	185	* Beachten Sie auch die Hinweise zur [[Verwendung von KI>>doc:Main.Softwareentwicklung.WebHome\|\|anchor="HNutzunggenerativerKI-Werkzeuge"]]

Wiki source code of Softwareentwicklung

Applications

Navigation