# Software-Entwicklung 2: Ihr Projekt

## Ziele

In diesem Projekt entwickeln Sie als Team (2–4 Personen) eine Java-Anwendung mittlerer Komplexität, mit der Sie nachweisen, dass Sie:

* die Kernkonzepte objektorientierter Programmierung (OOP) verstanden haben und sinnvoll anwenden können,
* moderne Programmierparadigmen und Werkzeuge (z. B. Git, Tests, sauberes Design) beherrschen,
* sich im Team organisieren, Arbeit aufteilen und nachvollziehbar dokumentieren können,
* ein Softwareprojekt planen, umsetzen und reflektieren können.

Der Fokus liegt *nicht* auf möglichst viel Funktionalität, sondern auf gutem Design, Verständlichkeit und Nachvollziehbarkeit Ihres Codes.

## Rahmenbedingungen

* Deadline ist der *31. Juli* (SS) bzw. *28 Februar* (WS).
* Java (JDK 25) zur Programmierung, Git zur Versionsverwaltung (Pflicht)
* Gruppenarbeit (2–4 Personen), Einzelarbeiten sind nicht bewertbar
* Bewertung erfolgt grundsätzlich als Team, Einzelbewertung auf Wunsch oder bei Auffälligkeiten möglich. Beachten Sie den Bewertungsbogen.
* Abgabe erfolgt via Link oder ZIP in Moodle. Eine Abgabe ohne Git-Repository oder ohne erkennbare User-Commits sind nicht bewertbar

Ihre internen Kommunikationskanäle (WhatsApp, Discord, etc.) sind uns zunächst egal, aber stellen Sie sicher, dass sie protokolliert werden.

## Projektthema

Das Projektthema wählen Sie selbst. Ihr Projekt muss Themen aus der Vorlesung konkret implementieren. Sie übertragen die Konzepte aus der Vorlesung in eine eigene Anwendung. Es muss realistisch, umsetzbar und inhaltlich passend sein. Game Development ist deutlich aufwändiger als erwartet – wählen Sie Ihr Thema bewusst!

* To-Do- / Aufgabenverwaltung
* Kontakt-, Shop- oder Inventarverwaltung
* Stunden- oder Lernplan-Tool
* Bild- oder Medienkatalog (Metadaten, Tags, Suche)
* Einfaches Annotierungs-Tool (Text/Bild)
* Automatisierungs-Tool
* Mediensammlungs-Manager
* Rundenbasiertes Spiel (z. B. Karten-/Brettspiel, Schiffe-versenken)
* Textbasiertes Spiel / Zustandsautomat
* etc…

Bei vollständiger Ideenlosigkeit geben wir Ihnen eine Aufgabe. 

> **Hinweise:**
> * *Kommen Sie frühzeitig zu uns*: Idealerweise in Woche 1–4 besprechen Sie mit mir in den Übungen Ihr Projekt und klären Sie, ob es geeignet und realisierbar ist. Sie können gerne bisherige Projekte/Ideen weiterentwickeln. Auch die Tutoren beraten Sie gerne zur Projektauswahl in den Übungen.
> * *Übungen*: Setzen Sie die in der Vorlesungen besprochenen Themen in der dazugehörigen Übung um. Es hat sich gezeigt, dass dann der Lerneffekt am größten ist.
> * *Reviews*: Die Gruppen werden aufgerufen, einen Review ihres Projekts zu machen. Das bedeutet, die zentralen Konzepte zu erklären und die Implementation zu erklären. Die Gruppenmitglieder teilen sich die Erklärungen auf.
> * *Gruppenarbeit*: Jederzeit können Mitglieder der Gruppe aufgerufen werden, den Code des Projekts zu erklären. Wichtig: Damit ist der komplette Code gemeint. Sie müssen nicht an allen Klassen mitarbeiten, aber in der Lage sein, den Code zu erklären! Wenn wir feststellen, dass einzelne Mitglieder den Code nicht kennen, gehen wir davon aus, dass er nicht von ihnen verstanden wurde und die Zulassung zur Prüfung erlischt für Sie.

## Projektbewertung

### Pflichtanteil (60 %)

Diese Punkte sind verpflichtend und werten stark gewichtet.

* **Originalität**: Kein Plagiat, kein KI-generierter Code, eigenständige Lösungsidee und Umsetzung  
* **Teamwork**: Git-Repository mit nachvollziehbarer Commit-Historie. Alle Teammitglieder müssen regelmäßig beitragen, bewertet werden Commit-Anteile und Gini-Koeffizient. Halten Sie fest, wer was gemacht hat!  
* **Dokumentation**: Jedes Projekt muss über eine aussagekräftige `Readme.md` verfügen (Features, Build-/Startanleitung, UML-Diagramm, Zentrale Klassen und Beziehungen). Außerdem wird die sinnvolle Verwendung von Javadocs und Kommentare bewertet.  
* **OOP-Design**: Der wichtigste Punkt ist die sinnvolle Vererbung mit Klassen, Verträge mit Interfaces und eine Durchdachte Struktur und Verantwortlichkeiten.  
* **Testing**: JUnit-Tests für zentrale Softwarebestandteile. Tests müssen verständlich und sinnvoll sein.  
* **Clean Code**: Lesbarkeit, Wartbarkeit, Struktur. Keine unnötige Komplexität (Overengineering). Vermeidung typischer Code Smells.  

### Wahlpflichtanteil (40 %)

Ihr Projekt konzentriert sich auf mindestens 4 der folgenden Themen. Wenn Sie mehr umsetzen, werden nur die **4 zentralen Themen** bewertet.
- **Collections im Zusammenspiel mit Generics**: Einsatz geeigneter Collection-Typen (List, Set, Map etc.) zur Verwaltung von Objektmengen. Verwendung von Generics, um Typsicherheit zu gewährleisten, Casts zu vermeiden und klare, wiederverwendbare Datenstrukturen zu definieren.
- **Fehlerbehandlung mit Exception**: Gezielter Einsatz eigener Checked- und Unchecked-Exceptions zur Behandlung von Fehlerfällen (z. B. ungültige Eingaben, Datei-/Netzwerkzugriffe, inkonsistente Zustände).  
- **Betriebssystem-Logging**: Verwendung eines Logging-Mechanismus um ohne `System.out.println()` relevante Ereignisse der Anwendung zu protokollieren.
- **Nebenläufigkeit mit Threads**: Einsatz von Threads oder Thread-Pools zur parallelen Ausführung von performanter Aufgaben (z. B. Hintergrundberechnungen). „Alibi-Threads“ werden nicht bewertet. 
- **Funktionale Programmierung mit Streams** (Netzwerk-, Datenbank- oder Dateizugriff): Nutzung der Stream-API zur deklarativen Verarbeitung von Datenmengen (Filtern, Mappen, Aggregieren). Die Streams sollen auf realen Daten basieren, z. B. aus Dateien, Datenbanken oder Netzwerkquellen, und nicht nur auf künstlichen Beispiel-Listen.
- **GUI mit JavaFX**: Umsetzung einer grafischen Benutzeroberfläche mit JavaFX, die vollständig ohne Konsoleninteraktion auskommt. Die GUI muss grundlegende Interaktionen per Maus ermöglichen (z. B. Buttons, Listen, Eingabefelder). Gestaltung und Layout sind zweitrangig, entscheidend ist die saubere Anbindung an die Anwendungslogik.
- **Software Design Pattern**: Einsatz mindestens eines Design Patterns zur Lösung eines konkreten Entwurfsproblems (z. B. Factory zur Objekterzeugung). Das Pattern muss fachlich begründet, korrekt umgesetzt und im Projekt erkennbar sein. Reines „Pattern um des Patterns willen“ wird nicht bewertet.  

Die Themen müssen eine erkennbare Rolle in Ihrer Software spielen, nicht nur „formal eingebaut“ sein. Die Abgabe erfolgt in Moodle.