Unterlagen Update: Verbesserung Pflichtenheft, Abb5 & Upload Fahrplan Kundenverwaltung Gruppe H

Unterlagen/Fahrplan_Kundenverwaltung_GruppeH/Fahrplan_Kundenverwaltung_GruppeH_1.0.md

@@ -0,0 +1,207 @@
+# Fahrplan – Modul Kundenverwaltung (Gruppe H)
+
+**Projekt:** Fakturierungssystem · SE1 Team 2 – Hochschule Mannheim
+**Modul / Gruppe:** Kundenverwaltung (Gruppe H) · Package `de.hsmannheim.faktura.kunde`
+**Verantwortlich (dieses Dokument):** Christopher Lampert [3027248]
+**Gruppe H:** Oleg Akimenko [3028868] (Gruppenleiter), Christopher Lampert [3027248], Kenan Pekarovic [3027541]
+**Stand:** 25.06.2026
+**Bezug:** Lastenheft v1.1, Pflichtenheft v1.0, Project Charter v1.1, Modultestplan (KV-Teil)
+
+> **Harte Deadline:** Montag, **29.06.2026, 09:00 Uhr** – Abgabe der Artefakte pro Team.
+> **Präsentation:** Montag, 29.06.2026 im regulären Vorlesungsblock (20–25 Min/Team, 4 Vortragende, je Gruppe ein Vertreter).
+> **Projektphase laut Charter:** M7 „Puffer & Abnahme" (27.–30.06.2026).
+
+---
+
+## 0. So benutzt du diesen Fahrplan
+
+Jeder Schritt hat einen Status. Aktualisiere ihn, dann kannst du mir jederzeit sagen „ich bin bei P4-3" und ich habe sofort den Kontext.
+
+**Statuslegende:**
+`[ ]` offen · `[~]` in Arbeit · `[x]` fertig · `[!]` blockiert / offener Punkt
+
+**Aktuelle Position:** _Phase 0 (Setup) – noch nicht begonnen_
+*(Diese Zeile bei jeder Session aktualisieren.)*
+
+---
+
+## 1. Ziel & Abgrenzung
+
+**Im Scope (nur Gruppe H):** Anlegen, Bearbeiten, Suchen und Löschen von Kunden samt Validierung, Persistenz und Modultests – also die fachlichen Anforderungen **F-KV-01 bis F-KV-04** (Herkunft BA-KV-01…04) sowie die mitwirkenden Regeln **GR-05** (Stammdatenschutz) und **NF-ARCH-01** (Persistenz).
+
+**Nicht im Scope (andere Gruppen):** Produktverwaltung (G), Dokumentenprozess (F), GUI (E). Diese werden hier **nur über die Schnittstellen** berührt (siehe Abschnitt 2).
+
+**Leitprinzip:** Alles richtet sich nach den vier Projektdokumenten. Abweichungen werden **nicht still aufgelöst**, sondern als offener Punkt in Abschnitt 8 markiert.
+
+---
+
+## 2. Kompatibilitätsvertrag mit den anderen Modulen
+
+Damit die Kundenverwaltung sauber mit den Teilen der anderen Teilnehmer zusammenspielt, müssen diese vier Berührungspunkte exakt eingehalten werden. **Bevor implementiert wird, sollten diese Signaturen mit Gruppe E und F gegengeprüft sein.**
+
+| # | Wer braucht es | Was die Kundenverwaltung liefern muss | Quelle |
+|---|----------------|----------------------------------------|--------|
+| K1 | **GUI (Gruppe E)** über IF-01 | `KundeService` mit `anlegen(Kunde): long`, `bearbeiten(Kunde): void`, `suchen(String): List<Kunde>`, `loeschen(long): void` | Pflichtenheft Klassendiagramm (Kap. 7.2), Komponentendiagramm (Kap. 7.1: `KundeAnsicht → KundeService`) |
+| K2 | **Datenhaltung** über IF-02 | `KundeRepository`-Interface (speichern/findeById/findeAlle/loeschen), JSON-Persistenz dahinter gekapselt | IF-02, NF-ARCH-01/02 |
+| K3 | **Dokumentenprozess (Gruppe F)** | Kunde ist über `kundeId` (long) referenzierbar; F nutzt `FakeCustomerLookup` und `isCustomerReferenced(...)` in seinen Tests (MT-DP-16). KV muss einen Kunden per ID auflösbar machen. | Modultestplan DP (MT-DP-01, MT-DP-16); Pflichtenheft Datenobjekte (kundeId als Referenz in allen Belegen) |
+| K4 | **Löschsperre GR-05** | Vor dem Löschen prüft `KundeService`, ob der Kunde in einem Beleg referenziert ist → Abfrage gegen `BelegRepository` (Gruppe F). Bei Referenz: Löschen ablehnen. | GR-05; F-KV-04; MT-KV-11 |
+
+**Daten-Kontrakt „Kunde" (Pflichtenheft Kap. 6.1.2) – verbindlich:**
+
+| Attribut | Java-Typ | Pflicht | Constraint |
+|----------|----------|---------|------------|
+| kundeId | `long` | Pflicht | Fortlaufender, eindeutiger Primärschlüssel |
+| firmenname | `String` | Pflicht\* | Pflicht, sofern kein Nachname |
+| nachname | `String` | Pflicht\* | Pflicht, sofern kein Firmenname |
+| vorname | `String` | Optional | – |
+| strasse | `String` | Pflicht | Straße + Hausnummer |
+| plz | `String` | Pflicht | String (führende Nullen erhalten) |
+| ort | `String` | Pflicht | – |
+| telefon | `String` | Optional | – |
+| email | `String` | Optional | Formatvalidierung, falls angegeben |
+| ustIdNr | `String` | Optional | USt-IdNr. |
+| lieferadresse | `String` | Optional | abweichende Lieferadresse |
+| ansprechpartner | `String` | Optional | – |
+
+\* **Constraint:** `firmenname != null || nachname != null` (mindestens eines befüllt).
+
+---
+
+## 3. Technische Vorgaben (aus Pflichtenheft Kap. 2.3)
+
+- **Sprache:** Java LTS ≥ 17
+- **Persistenz:** lokale **JSON-Datei** (z. B. Jackson), hinter `KundeRepository` gekapselt → austauschbar (NF-ARCH-02)
+- **Tests:** **JUnit 5 (Jupiter)** – GUI-unabhängige Logiktests (NF-TEST-02)
+- **Architektur:** 3-Schichten (ui → service → repository); KV berührt nur `service` + `repository`
+- **Versionierung:** Git / Gitty, Code-Review je Merge (NF-VER-02)
+- **Relevante NF-Ziele:** NF-USE-01 (Kunde anlegen < 2 min), NF-PERF-01 (Aktion < 1 s bei 1.000 Kunden), NF-PERF-02 (Liste < 2 s), NF-SEC-01 (kein Klartext von außen), NF-SEC-02 (DSGVO-Löschen)
+
+---
+
+## 4. Die Phasen (Schritt für Schritt)
+
+### Phase 0 – Setup & Abstimmung
+- `[ ]` **P0-1** Git/Gitty: Branch für Gruppe H anlegen; Paketstruktur `de.hsmannheim.faktura.kunde` (Unterpakete `model`, `service`, `repository`)
+- `[ ]` **P0-2** Build-Setup: Java ≥ 17, JUnit 5, JSON-Lib (Jackson) als Abhängigkeit eintragen
+- `[ ]` **P0-3** Schnittstellen K1–K4 (Abschnitt 2) mit Gruppe E (GUI) und Gruppe F (Belege) gegenprüfen und bestätigen
+- `[ ]` **P0-4** Offenen Punkt OP-1 (BelegRepository vs. ProduktRepository, siehe Abschnitt 8) mit Team klären
+
+### Phase 1 – Datenmodell
+- `[ ]` **P1-1** Klasse `Kunde` mit allen 12 Attributen aus dem Daten-Kontrakt (Abschnitt 2), Typen exakt wie spezifiziert (`plz` als `String`!)
+- `[ ]` **P1-2** Konstruktor/Builder + Getter/Setter; `equals`/`hashCode` über `kundeId`
+- `[ ]` **P1-3** JSON-Serialisierbarkeit sicherstellen (Jackson-Annotationen falls nötig)
+
+### Phase 2 – Persistenz (IF-02 / NF-ARCH-01/02)
+- `[ ]` **P2-1** Interface `KundeRepository`: `speichern(Kunde): long`, `findeById(long): Optional<Kunde>`, `findeAlle(): List<Kunde>`, `loeschen(long): void`
+- `[ ]` **P2-2** JSON-Implementierung `KundeRepositoryJson`: Laden/Speichern aus lokaler Datei
+- `[ ]` **P2-3** Fortlaufende ID-Vergabe (`kundeId`) – eindeutig, kein Reuse
+- `[ ]` **P2-4** Persistenz-Roundtrip prüfen (speichern → neu laden → identisch) → Grundlage für MT-KV-06
+
+### Phase 3 – Validierung
+- `[ ]` **P3-1** Pflichtfeldprüfung: `strasse`, `plz`, `ort` vorhanden
+- `[ ]` **P3-2** Constraint `firmenname != null || nachname != null`
+- `[ ]` **P3-3** E-Mail-Formatprüfung (nur falls `email` angegeben)
+- `[ ]` **P3-4** Aussagekräftige Fehlermeldung/Exception bei Verstoß (keine Speicherung)
+
+### Phase 4 – Logik: `KundeService` (F-KV-01…04)
+- `[ ]` **P4-1** `anlegen(Kunde): long` → validiert, vergibt ID, persistiert · **F-KV-01 / BA-KV-01**
+- `[ ]` **P4-2** `bearbeiten(Kunde): void` → lädt, validiert, persistiert · **F-KV-02 / BA-KV-02**
+- `[ ]` **P4-3** `suchen(String): List<Kunde>` → Treffer über Name (firmenname/nachname) **und** Kundennummer · **F-KV-03 / BA-KV-03**
+- `[ ]` **P4-4** `loeschen(long): void` → Sicherheitsabfrage, **GR-05-Referenzprüfung** über `BelegRepository`, nur bei zulässiger Löschung entfernen · **F-KV-04 / BA-KV-04**
+- `[ ]` **P4-5** NF-SEC-02: Löschen nur ohne aktive Aufbewahrungspflicht (z. B. keine aktive Rechnung)
+
+### Phase 5 – Schnittstelle zum Dokumentenprozess (K3)
+- `[ ]` **P5-1** Kunden-Auflösung per `kundeId` bereitstellen (was Gruppe F im Echtbetrieb statt `FakeCustomerLookup` nutzt)
+- `[ ]` **P5-2** Mit Gruppe F abstimmen, wie `isCustomerReferenced(kundeId)` aufgerufen wird (Richtung: KV fragt BelegRepository – siehe OP-1)
+
+### Phase 6 – Modultests (JUnit 5, MT-KV-01…11)
+Jeder Test bildet exakt einen Eintrag aus dem Modultestplan ab:
+
+- `[ ]` **P6-01** MT-KV-01 Kunde mit allen Pflichtattributen anlegen → gespeichert · BA-KV-01
+- `[ ]` **P6-02** MT-KV-02 ohne Firmenname/Nachname → abgelehnt · BA-KV-01
+- `[ ]` **P6-03** MT-KV-03 ohne Straße → abgelehnt · BA-KV-01
+- `[ ]` **P6-04** MT-KV-04 ungültige E-Mail „kunde@" → abgelehnt · BA-KV-01
+- `[ ]` **P6-05** MT-KV-05 Telefonnummer ändern → gespeichert · BA-KV-02
+- `[ ]` **P6-06** MT-KV-06 Persistenz nach Neuladen → unverändert · BA-KV-02, NF-ARCH-01
+- `[ ]` **P6-07** MT-KV-07 Suche über Namen „Muster" → gefunden · BA-KV-03
+- `[ ]` **P6-08** MT-KV-08 Suche über Kundennummer → gefunden · BA-KV-03
+- `[ ]` **P6-09** MT-KV-09 Suche ohne Treffer → leeres Ergebnis/Hinweis · BA-KV-03
+- `[ ]` **P6-10** MT-KV-10 nicht referenzierten Kunden löschen → entfernt · BA-KV-04
+- `[ ]` **P6-11** MT-KV-11 referenzierten Kunden löschen → abgewiesen · BA-KV-04, GR-05
+- `[ ]` **P6-12** Alle 11 Tests grün; Coverage-Schwelle (NF-TEST-03: 60 %) für `kunde`-Paket erreicht
+
+### Phase 7 – Abgabe-Artefakt: Modultestbericht
+- `[ ]` **P7-1** Testlauf dokumentieren: je MT-KV-Fall **Ergebnis (bestanden/fehlgeschlagen)**, Datum, Tester
+- `[ ]` **P7-2** Abdeckungsübersicht aus dem Modultestplan (BA-KV-01→MT-KV-01…04 usw.) als Nachweis übernehmen
+- `[ ]` **P7-3** Mit Team klären: **max. 4 Dateien** insgesamt → KV-Bericht entweder eigene Datei **oder** in gemeinsame Test-Datei integriert (Koordination mit G/F/E)
+
+### Phase 8 – Integration mit anderen Modulen
+- `[ ]` **P8-1** GUI (E): `KundeAnsicht` ruft `KundeService` – Smoke-Test Anlegen/Suchen/Löschen aus der Oberfläche
+- `[ ]` **P8-2** Belege (F): echter Kunde im Angebot referenzierbar; GR-05-Löschsperre greift im integrierten System (MT-DP-16 ↔ MT-KV-11)
+- `[ ]` **P8-3** Gesamtsystem startet, KV-CRUD lauffähig (AK-02 Charter)
+
+### Phase 9 – Präsentation (KV-Anteil)
+Pflichtinhalte laut Aufgabenstellung – als KV-Vertreter (1 Person je Gruppe) vorbereiten:
+- `[ ]` **P9-1** Demo-Anteil: Kunde anlegen → suchen → bearbeiten → Löschsperre zeigen (referenzierter Kunde)
+- `[ ]` **P9-2** **KI-Einsatz:** wo eingesetzt, wie gut hat es funktioniert (konkrete KV-Beispiele)
+- `[ ]` **P9-3** **Was nächstes Mal anders:** ehrliche Lessons learned aus der KV-Umsetzung
+- `[ ]` **P9-4** **Modultestplan-Ergebnisse** der KV präsentieren (Abdeckung + Pass-Quote)
+- `[ ]` **P9-5** **Traceability-Stichprobe vorbereiten:** Kette **BA-KV-0x → F-KV-0x → MT-KV-xx → AT-KV-xx** auswendig/griffbereit (Prof prüft stichprobenartig)
+
+### Phase 10 – Abgabe & Generalprobe
+- `[ ]` **P10-1** Code gemergt, Reviews abgeschlossen (NF-VER-02), Tests grün im Hauptbranch
+- `[ ]` **P10-2** Testbericht + Folien im Team konsolidiert (max. 4 Test-Dateien, genau 1 Foliendatei)
+- `[ ]` **P10-3** **Abgabe bis Mo 29.06. 09:00 Uhr**
+- `[ ]` **P10-4** Generalprobe Vortrag + Zeitmessung (20–25 Min Team-Budget)
+
+---
+
+## 5. Traceability-Matrix Kundenverwaltung (für die Stichprobenprüfung)
+
+| Anforderung (LH) | Pflichtenheft | Modultests | Akzeptanztest (LH) |
+|------------------|---------------|------------|--------------------|
+| BA-KV-01 Kunde anlegen | F-KV-01 | MT-KV-01 … MT-KV-04 | AT-KV-01, AT-KV-02 |
+| BA-KV-02 Kunde bearbeiten | F-KV-02 | MT-KV-05, MT-KV-06 | AT-KV-03, AT-KV-04 |
+| BA-KV-03 Kunde suchen | F-KV-03 | MT-KV-07 … MT-KV-09 | AT-KV-05, AT-KV-06 |
+| BA-KV-04 Kunde löschen | F-KV-04 | MT-KV-10, MT-KV-11 | AT-KV-07, AT-KV-08 |
+| GR-05 Stammdatenschutz | F-KV-04 (i.V.m. GR-05) | MT-KV-11 | – |
+| NF-ARCH-01 Persistenz | NF-ARCH-01 | MT-KV-06 | AT-NF-… |
+
+---
+
+## 6. Zeitplan bis Montag (Vorschlag)
+
+| Tag | Fokus |
+|-----|-------|
+| **Do 25.06** | Phase 0 + Phase 1 (Setup, Schnittstellen abstimmen, Datenmodell) |
+| **Fr 26.06** | Phase 2 + Phase 3 + Phase 4 (Persistenz, Validierung, Service-Logik) |
+| **Sa 27.06** | Phase 5 + Phase 6 (DP-Schnittstelle, alle 11 Modultests grün) |
+| **So 28.06** | Phase 7 + Phase 8 + Phase 9 (Testbericht, Integration, Folien) |
+| **Mo 29.06 vor 09:00** | Phase 10 (Konsolidierung, Abgabe, Generalprobe) |
+
+---
+
+## 7. Definition of Done (Kundenverwaltung)
+
+- `[ ]` F-KV-01 bis F-KV-04 implementiert und über `KundeService` aufrufbar (K1)
+- `[ ]` Persistenz über `KundeRepository`/JSON, Daten überleben Neustart (NF-ARCH-01)
+- `[ ]` Validierung greift (Pflichtfelder, firmenname||nachname, E-Mail-Format)
+- `[ ]` GR-05-Löschsperre funktioniert im integrierten System
+- `[ ]` MT-KV-01…11 alle grün, Coverage ≥ 60 % im `kunde`-Paket
+- `[ ]` Modultestbericht erstellt und ins Team-Artefakt integriert
+- `[ ]` Traceability BA→F→MT→AT lückenlos und vorführbar
+- `[ ]` In Gesamtsystem integriert (GUI + Belege), Code gereviewt und gemergt
+
+---
+
+## 8. Offene Punkte (nicht still aufgelöst)
+
+| ID | Dokument / Stelle | Beschreibung | Vorschlag |
+|----|-------------------|--------------|-----------|
+| OP-1 | Pflichtenheft Klassendiagramm (Kap. 7.2) vs. GR-05 | Diagramm zeigt `KundeService ..> ProduktRepository`; GR-05-Text fordert Referenzprüfung über `BelegRepository`. Für die Löschsperre F-KV-04/MT-KV-11 ist das **BelegRepository** maßgeblich. | Im Code gegen `BelegRepository` prüfen; Diagramm-Abhängigkeit als Doku-Inkonsistenz an Team/Prüfer melden. |
+| OP-2 | Abgabe-Format | „max. 4 Dateien" für Testberichte bei 4 Modulen → Aufteilung 1 Datei/Modul **oder** 1 Sammeldatei? | Team-Entscheidung vor So 28.06; KV-Bericht entsprechend zuschneiden. |
+| OP-3 | Schnittstelle K3 (Lookup-Richtung) | Genaue Aufrufrichtung zwischen KV und Gruppe F für `isCustomerReferenced` final festzurren. | In P0-3 mit Gruppe F bestätigen. |
+
+---
+
+*Aktualisiere bei jeder Session die Zeile „Aktuelle Position" in Abschnitt 0 und die Status-Marker. Damit kann der Fortschritt jederzeit punktgenau aufgegriffen werden.*

Unterlagen/Fahrplan_Kundenverwaltung_GruppeH/Fahrplan_Kundenverwaltung_GruppeH_1.1.md

@@ -0,0 +1,226 @@
+# Fahrplan – Modul Kundenverwaltung (Gruppe H) Ver. 1.1
+
+**Projekt:** Fakturierungssystem · SE1 Team 2 – Hochschule Mannheim[cite: 2]
+**Modul / Gruppe:** Kundenverwaltung (Gruppe H) · Package `de.hsmannheim.faktura.kunde`[cite: 2]
+**Verantwortlich (dieses Dokument):** Christopher Lampert [3027248][cite: 2]
+**Gruppe H:** Oleg Akimenko [3028868] (Gruppenleiter), Christopher Lampert [3027248], Kenan Pekarovic [3027541][cite: 2]
+**Stand:** 25.06.2026[cite: 2]
+**Bezug:** Lastenheft v1.1, Pflichtenheft v1.0, Project Charter v1.1, Modultestplan (KV-Teil)[cite: 2]
+
+> **Harte Deadline:** Montag, **29.06.2026, 09:00 Uhr** – Abgabe der Artefakte pro Team.[cite: 2]
+> **Präsentation:** Montag, 29.06.2026 im regulären Vorlesungsblock (20–25 Min/Team, 4 Vortragende, je Gruppe ein Vertreter).[cite: 2]
+> **Projektphase laut Charter:** M7 „Puffer & Abnahme" (27.–30.06.2026).[cite: 2]
+
+---
+
+## 0. So benutzt du diesen Fahrplan
+
+Jeder Schritt hat einen Status.[cite: 2] Aktualisiere ihn, dann kannst du mir jederzeit sagen „ich bin bei P4-3" und ich habe sofort den Kontext.[cite: 2]
+
+**Statuslegende:**
+`[ ]` offen · `[~]` in Arbeit · `[x]` fertig · `[!]` blockiert / offener Punkt[cite: 2]
+
+**Aktuelle Position:** *Phase 6 (Modultests konsolidieren) – Nächster Schritt*[cite: 1]
+
+### 🚀 Aktueller Umsetzungsstand (für den neuen Chat-Kontext)
+Wir haben die **Phasen 0 bis 5** der Kundenverwaltung erfolgreich umgesetzt und die Artefakte bereits über einen Merge Request auf den `main`-Branch hochgeladen.[cite: 1] Alle entwickelten Klassen sind funktionsfähig und durch JUnit-5-Tests abgedeckt.[cite: 1]
+
+#### 📁 Erstellte Dateien & Paketstruktur (`de.hsmannheim.faktura.kunde`)
+* **Wurzelverzeichnis:** `pom.xml` (Maven-Setup für Java 17, JUnit 5 und Jackson) sowie `.gitignore` erweitert (ignoriert jetzt `target/` und `.idea/`).[cite: 1]
+* **`model`:** `Kunde.java` (Spezifikationskonformes POJO mit allen 12 Feldern, PLZ als `String`).[cite: 1]
+* **`repository`:**
+  * `KundeRepository.java` (Interface für Datenhaltung).[cite: 1]
+  * `KundeContainer.java` (Hilfsklasse für JSON-Bündelung).[cite: 1]
+  * `KundeRepositoryJson.java` (Jackson-Implementierung mit fortlaufendem ID-Zähler gegen ID-Wiederverwendung).[cite: 1]
+* **`service`:**
+  * `KundeService.java` (Zentrale Logik für CRUD-Operationen, inklusive der neuen Methode `finde(long)` für die Beleg-Schnittstelle).[cite: 1]
+  * `KundeValidator.java` (Prüfung von Pflichtfeldern, E-Mail-Format und der Bedingung `firmenname || nachname`).[cite: 1]
+  * `BelegReferenzPruefer.java` (Funktionales Interface zur Entkopplung der GR-05-Löschsperre von Gruppe F).[cite: 1]
+  * `ValidierungsException.java` & `LoeschsperreException.java` (Unchecked Exceptions für Fehlermeldungen).[cite: 1]
+* **`src/test/java`:**
+  * `KundeRepositoryJsonTest.java` (Persistenz-Roundtrip-Test).[cite: 1]
+  * `KundeValidatorTest.java` (Validierungs-Tests).[cite: 1]
+  * `KundeServiceTest.java` (8 grüne Logik-Tests inklusive simulierter Löschsperre).[cite: 1]
+
+---
+
+## 1. Ziel & Abgrenzung
+
+**Im Scope (nur Gruppe H):** Anlegen, Bearbeiten, Suchen und Löschen von Kunden samt Validierung, Persistenz und Modultests – also die fachlichen Anforderungen **F-KV-01 bis F-KV-04** (Herkunft BA-KV-01…04) sowie die mitwirkenden Regeln **GR-05** (Stammdatenschutz) und **NF-ARCH-01** (Persistenz).[cite: 2]
+
+**Nicht im Scope (andere Gruppen):** Produktverwaltung (G), Dokumentenprozess (F), GUI (E).[cite: 2] Diese werden hier **nur über die Schnittstellen** berührt (siehe Abschnitt 2).[cite: 2]
+
+**Leitprinzip:** Alles richtet sich nach den vier Projektdokumenten.[cite: 2] Abweichungen werden **nicht still aufgelöst**, sondern als offener Punkt in Abschnitt 8 markiert.[cite: 2]
+
+---
+
+## 2. Kompatibilitätsvertrag mit den anderen Modulen
+
+Damit die Kundenverwaltung sauber mit den Teilen der anderen Teilnehmer zusammenspielt, müssen diese vier Berührungspunkte exakt eingehalten werden.[cite: 2] **Bevor implementiert wird, sollten diese Signaturen mit Gruppe E und F gegengeprüft sein.**[cite: 2]
+
+| # | Wer braucht es | Was die Kundenverwaltung liefern muss | Quelle |
+|---|----------------|----------------------------------------|--------|
+| K1 | **GUI (Gruppe E)** über IF-01 | `KundeService` mit `anlegen(Kunde): long`, `bearbeiten(Kunde): void`, `suchen(String): List<Kunde>`, `loeschen(long): void` | Pflichtenheft Klassendiagramm (Kap. 7.2), Komponentendiagramm (Kap. 7.1: `KundeAnsicht → KundeService`)[cite: 2] |
+| K2 | **Datenhaltung** über IF-02 | `KundeRepository`-Interface (speichern/findeById/findeAlle/loeschen), JSON-Persistenz dahinter gekapselt | IF-02, NF-ARCH-01/02[cite: 2] |
+| K3 | **Dokumentenprozess (Gruppe F)** | Kunde ist über `kundeId` (long) referenzierbar; F nutzt `FakeCustomerLookup` und `isCustomerReferenced(...)` in seinen Tests (MT-DP-16).[cite: 2] KV muss einen Kunden per ID auflösbar machen.[cite: 2] | Modultestplan DP (MT-DP-01, MT-DP-16); Pflichtenheft Datenobjekte (kundeId als Referenz in allen Belegen)[cite: 2] |
+| K4 | **Löschsperre GR-05** | Vor dem Löschen prüft `KundeService`, ob der Kunde in einem Beleg referenziert ist → Abfrage gegen `BelegRepository` (Gruppe F).[cite: 2] Bei Referenz: Löschen ablehnen.[cite: 2] | GR-05; F-KV-04; MT-KV-11[cite: 2] |
+
+**Daten-Kontrakt „Kunde" (Pflichtenheft Kap. 6.1.2) – verbindlich:**[cite: 2]
+
+| Attribut | Java-Typ | Pflicht | Constraint |
+|----------|----------|---------|------------|
+| kundeId | `long` | Pflicht | Fortlaufender, eindeutiger Primärschlüssel[cite: 2] |
+| firmenname | `String` | Pflicht\* | Pflicht, sofern kein Nachname[cite: 2] |
+| nachname | `String` | Pflicht\* | Pflicht, sofern kein Firmenname[cite: 2] |
+| vorname | `String` | Optional | –[cite: 2] |
+| strasse | `String` | Pflicht | Straße + Hausnummer[cite: 2] |
+| plz | `String` | Pflicht | String (führende Nullen erhalten)[cite: 2] |
+| ort | `String` | Pflicht | –[cite: 2] |
+| telefon | `String` | Optional | –[cite: 2] |
+| email | `String` | Optional | Formatvalidierung, falls angegeben[cite: 2] |
+| ustIdNr | `String` | Optional | USt-IdNr.[cite: 2] |
+| lieferadresse | `String` | Optional | abweichende Lieferadresse[cite: 2] |
+| ansprechpartner | `String` | Optional | –[cite: 2] |
+
+\* **Constraint:** `firmenname != null || nachname != null` (mindestens eines befüllt).[cite: 2]
+
+---
+
+## 3. Technische Vorgaben (aus Pflichtenheft Kap. 2.3)
+
+- **Sprache:** Java LTS ≥ 17[cite: 2]
+- **Persistenz:** lokale **JSON-Datei** (z. B. Jackson), hinter `KundeRepository` gekapselt → austauschbar (NF-ARCH-02)[cite: 2]
+- **Tests:** **JUnit 5 (Jupiter)** – GUI-unabhängige Logiktests (NF-TEST-02)[cite: 2]
+- **Architektur:** 3-Schichten (ui → service → repository); KV berührt nur `service` + `repository`[cite: 2]
+- **Versionierung:** Git / Gitty, Code-Review je Merge (NF-VER-02)[cite: 2]
+- **Relevante NF-Ziele:** NF-USE-01 (Kunde anlegen < 2 min), NF-PERF-01 (Aktion < 1 s bei 1.000 Kunden), NF-PERF-02 (Liste < 2 s), NF-SEC-01 (kein Klartext von außen), NF-SEC-02 (DSGVO-Löschen)[cite: 2]
+
+---
+
+## 4. Die Phasen (Schritt für Schritt)
+
+### Phase 0 – Setup & Abstimmung
+- `[x]` **P0-1** Git/Gitty: Branch für Gruppe H angelegt und Paketstruktur erstellt.[cite: 1]
+- `[x]` **P0-2** Build-Setup: Maven mit Java 17, JUnit 5 und Jackson in `pom.xml` aufgesetzt.[cite: 1]
+- `[ ]` **P0-3** Schnittstellen K1–K4 mit Gruppe E und F gegenprüfen *(vom User aufgeschoben, wird bei Integration relevant)*.[cite: 1]
+- `[ ]` **P0-4** Offenen Punkt OP-1 mit Team klären *(vom User aufgeschoben, Code ist durch Interface entkoppelt)*.[cite: 1]
+
+### Phase 1 – Datenmodell
+- `[x]` **P1-1** Klasse `Kunde` mit allen 12 Attributen erstellt (`plz` als `String`).[cite: 1]
+- `[x]` **P1-2** Getter/Setter und `equals`/`hashCode` über `kundeId` implementiert.[cite: 1]
+- `[x]` **P1-3** JSON-Serialisierbarkeit via Jackson durch leeren Konstruktor sichergestellt.[cite: 1]
+
+### Phase 2 – Persistenz (IF-02 / NF-ARCH-01/02)
+- `[x]` **P2-1** Interface `KundeRepository` mit CRUD-Signaturen definiert.[cite: 1]
+- `[x]` **P2-2** `KundeRepositoryJson` lädt/speichert lokale JSON-Datei via Jackson.[cite: 1]
+- `[x]` **P2-3** Fortlaufende ID-Vergabe über mitgespeicherten Zähler gelöst (kein ID-Reuse nach Löschung).[cite: 1]
+- `[x]` **P2-4** Persistenz-Roundtrip im `KundeRepositoryJsonTest` erfolgreich geprüft.[cite: 1]
+
+### Phase 3 – Validierung
+- `[x]` **P3-1** Pflichtfeldprüfung für `strasse`, `plz`, `ort` in `KundeValidator` eingebaut.[cite: 1]
+- `[x]` **P3-2** Constraint `firmenname != null || nachname != null` umgesetzt.[cite: 1]
+- `[x]` **P3-3** E-Mail-Formatprüfung per Regex integriert.[cite: 1]
+- `[x]` **P3-4** `ValidierungsException` erstellt; wird vor dem Speichern geworfen, um ungültige Daten zu blockieren.[cite: 1]
+
+### Phase 4 – Logik: `KundeService` (F-KV-01…04)
+- `[x]` **P4-1** `anlegen(Kunde)` validiert, erzwingt ID-Vergabe und persistiert.[cite: 1] · **F-KV-01 / BA-KV-01**[cite: 2]
+- `[x]` **P4-2** `bearbeiten(Kunde)` prüft Existenz, validiert und speichert.[cite: 1] · **F-KV-02 / BA-KV-02**[cite: 2]
+- `[x]` **P4-3** `suchen(String)` filtert über Name (case-insensitive) und Kundennummer.[cite: 1] · **F-KV-03 / BA-KV-03**[cite: 2]
+- `[x]` **P4-4** `loeschen(long)` prüft Existenz und wirft bei aktiver Referenz eine `LoeschsperreException`.[cite: 1] · **F-KV-04 / BA-KV-04**[cite: 2]
+- `[x]` **P4-5** GR-05-Löschsperre über das Interface `BelegReferenzPruefer` vollständig vorbereitet und isoliert getestet.[cite: 1]
+
+### Phase 5 – Schnittstelle zum Dokumentenprozess (K3)
+- `[x]` **P5-1** `KundeService.finde(long): Optional<Kunde>` als Schnittstelle für Gruppe F bereitgestellt.[cite: 1]
+- `[ ]` **P5-2** Mit Gruppe F genaue Aufrufrichtung für `isCustomerReferenced` abstimmen *(offen/aufgeschoben)*.[cite: 1]
+
+### Phase 6 – Modultests (JUnit 5, MT-KV-01…11)
+*Die fachliche Logik ist durch die 8 Tests in `KundeServiceTest` bereits abgedeckt.[cite: 1] In dieser Phase müssen die bestehenden Tests kopiert, verfeinert und exakt in die 11 im Modultestplan geforderten Testmethoden-Namen überführt werden:*[cite: 1]
+
+- `[ ]` **P6-01** MT-KV-01 Kunde mit allen Pflichtattributen anlegen → gespeichert · BA-KV-01[cite: 1]
+- `[ ]` **P6-02** MT-KV-02 ohne Firmenname/Nachname → abgelehnt · BA-KV-01[cite: 1]
+- `[ ]` **P6-03** MT-KV-03 ohne Straße → abgelehnt · BA-KV-01[cite: 1]
+- `[ ]` **P6-04** MT-KV-04 ungültige E-Mail „kunde@" → abgelehnt · BA-KV-01[cite: 1]
+- `[ ]` **P6-05** MT-KV-05 Telefonnummer ändern → gespeichert · BA-KV-02[cite: 1]
+- `[ ]` **P6-06** MT-KV-06 Persistenz nach Neuladen → unverändert · BA-KV-02, NF-ARCH-01[cite: 1]
+- `[ ]` **P6-07** MT-KV-07 Suche über Namen „Muster" → gefunden · BA-KV-03[cite: 1]
+- `[ ]` **P6-08** MT-KV-08 Suche über Kundennummer → gefunden · BA-KV-03[cite: 1]
+- `[ ]` **P6-09** MT-KV-09 Suche ohne Treffer → leeres Ergebnis/Hinweis · BA-KV-03[cite: 1]
+- `[ ]` **P6-10** MT-KV-10 nicht referenzierten Kunden löschen → entfernt · BA-KV-04[cite: 1]
+- `[ ]` **P6-11** MT-KV-11 referenzierten Kunden löschen → abgewiesen · BA-KV-04, GR-05[cite: 1]
+- `[ ]` **P6-12** Alle 11 Tests grün; Coverage-Schwelle (NF-TEST-03: 60 %) für `kunde`-Paket im IntelliJ-Coverage-Tool nachweisen.[cite: 1]
+
+### Phase 7 – Abgabe-Artefakt: Modultestbericht
+- `[ ]` **P7-1** Testlauf dokumentieren: je MT-KV-Fall **Ergebnis (bestanden/fehlgeschlagen)**, Datum, Tester[cite: 2]
+- `[ ]` **P7-2** Abdeckungsübersicht aus dem Modultestplan (BA-KV-01→MT-KV-01…04 usw.) als Nachweis übernehmen[cite: 2]
+- `[ ]` **P7-3** Mit Team klären: **max. 4 Dateien** insgesamt → KV-Bericht entweder eigene Datei **oder** in gemeinsame Test-Datei integriert (Koordination mit G/F/E)[cite: 2]
+
+### Phase 8 – Integration mit anderen Modulen
+- `[ ]` **P8-1** GUI (E): `KundeAnsicht` ruft `KundeService` – Smoke-Test Anlegen/Suchen/Löschen aus der Oberfläche[cite: 2]
+- `[ ]` **P8-2** Belege (F): echter Kunde im Angebot referenzierbar; GR-05-Löschsperre greift im integrierten System (MT-DP-16 ↔ MT-KV-11)[cite: 2]
+- `[ ]` **P8-3** Gesamtsystem startet, KV-CRUD lauffähig (AK-02 Charter)[cite: 2]
+
+### Phase 9 – Präsentation (KV-Anteil)
+Pflichtinhalte laut Aufgabenstellung – als KV-Vertreter (1 Person je Gruppe) vorbereiten:[cite: 2]
+- `[ ]` **P9-1** Demo-Anteil: Kunde anlegen → suchen → bearbeiten → Löschsperre zeigen (referenzierter Kunde)[cite: 2]
+- `[ ]` **P9-2** **KI-Einsatz:** wo eingesetzt, wie gut hat es funktioniert (konkrete KV-Beispiele)[cite: 2]
+- `[ ]` **P9-3** **Was nächstes Mal anders:** ehrliche Lessons learned aus der KV-Umsetzung[cite: 2]
+- `[ ]` **P9-4** **Modultestplan-Ergebnisse** der KV präsentieren (Abdeckung + Pass-Quote)[cite: 2]
+- `[ ]` **P9-5** **Traceability-Stichprobe vorbereiten:** Kette **BA-KV-0x → F-KV-0x → MT-KV-xx → AT-KV-xx** auswendig/griffbereit (Prof prüft stichprobenartig)[cite: 2]
+
+### Phase 10 – Abgabe & Generalprobe
+- `[ ]` **P10-1** Code gemergt, Reviews abgeschlossen (NF-VER-02), Tests grün im Hauptbranch[cite: 2]
+- `[ ]` **P10-2** Testbericht + Folien im Team konsolidiert (max. 4 Test-Dateien, genau 1 Foliendatei)[cite: 2]
+- `[ ]` **P10-3** **Abgabe bis Mo 29.06. 09:00 Uhr**[cite: 2]
+- `[ ]` **P10-4** Generalprobe Vortrag + Zeitmessung (20–25 Min Team-Budget)[cite: 2]
+
+---
+
+## 5. Traceability-Matrix Kundenverwaltung (für die Stichprobenprüfung)
+
+| Anforderung (LH) | Pflichtenheft | Modultests | Akzeptanztest (LH) |
+|------------------|---------------|------------|--------------------|
+| BA-KV-01 Kunde anlegen | F-KV-01 | MT-KV-01 … MT-KV-04 | AT-KV-01, AT-KV-02[cite: 2] |
+| BA-KV-02 Kunde bearbeiten | F-KV-02 | MT-KV-05, MT-KV-06 | AT-KV-03, AT-KV-04[cite: 2] |
+| BA-KV-03 Kunde suchen | F-KV-03 | MT-KV-07 … MT-KV-09 | AT-KV-05, AT-KV-06[cite: 2] |
+| BA-KV-04 Kunde löschen | F-KV-04 | MT-KV-10, MT-KV-11 | AT-KV-07, AT-KV-08[cite: 2] |
+| GR-05 Stammdatenschutz | F-KV-04 (i.V.m. GR-05) | MT-KV-11 | –[cite: 2] |
+| NF-ARCH-01 Persistenz | NF-ARCH-01 | MT-KV-06 | AT-NF-…[cite: 2] |
+
+---
+
+## 6. Zeitplan bis Montag (Vorschlag)
+
+| Tag | Fokus |
+|-----|-------|
+| **Do 25.06** | Phase 0 + Phase 1 (Setup, Schnittstellen abstimmen, Datenmodell)[cite: 2] |
+| **Fr 26.06** | Phase 2 + Phase 3 + Phase 4 (Persistenz, Validierung, Service-Logik)[cite: 2] |
+| **Sa 27.06** | Phase 5 + Phase 6 (DP-Schnittstelle, alle 11 Modultests grün)[cite: 2] |
+| **So 28.06** | Phase 7 + Phase 8 + Phase 9 (Testbericht, Integration, Folien)[cite: 2] |
+| **Mo 29.06 vor 09:00** | Phase 10 (Konsolidierung, Abgabe, Generalprobe)[cite: 2] |
+
+---
+
+## 7. Definition of Done (Kundenverwaltung)
+
+- `[ ]` F-KV-01 bis F-KV-04 implementiert und über `KundeService` aufrufbar (K1)[cite: 2]
+- `[ ]` Persistenz über `KundeRepository`/JSON, Daten überleben Neustart (NF-ARCH-01)[cite: 2]
+- `[ ]` Validierung greift (Pflichtfelder, firmenname||nachname, E-Mail-Format)[cite: 2]
+- `[ ]` GR-05-Löschsperre funktioniert im integrierten System[cite: 2]
+- `[ ]` MT-KV-01…11 alle grün, Coverage ≥ 60 % im `kunde`-Paket[cite: 2]
+- `[ ]` Modultestbericht erstellt und ins Team-Artefakt integriert[cite: 2]
+- `[ ]` Traceability BA→F→MT→AT lückenlos und vorführbar[cite: 2]
+- `[ ]` In Gesamtsystem integriert (GUI + Belege), Code gereviewt und gemergt[cite: 2]
+
+---
+
+## 8. Offene Punkte (nicht still aufgelöst)
+
+| ID | Dokument / Stelle | Beschreibung | Vorschlag |
+|----|-------------------|--------------|-----------|
+| OP-1 | Pflichtenheft Klassendiagramm (Kap. 7.2) vs. GR-05 | Diagramm zeigt `KundeService ..> ProduktRepository`; GR-05-Text fordert Referenzprüfung über `BelegRepository`.[cite: 2] Für die Löschsperre F-KV-04/MT-KV-11 ist das **BelegRepository** maßgeblich.[cite: 2] | Im Code gegen `BelegRepository` prüfen; Diagramm-Abhängigkeit als Doku-Inkonsistenz an Team/Prüfer melden.[cite: 2] |
+| OP-2 | Abgabe-Format | „max. 4 Dateien" für Testberichte bei 4 Modulen → Aufteilung 1 Datei/Modul **oder** 1 Sammeldatei?[cite: 2] | Team-Entscheidung vor So 28.06; KV-Bericht entsprechend zuschneiden.[cite: 2] |
+| OP-3 | Schnittstelle K3 (Lookup-Richtung) | Genaue Aufrufrichtung zwischen KV und Gruppe F für `isCustomerReferenced` final festzurren.[cite: 2] | In P0-3 mit Gruppe F bestätigen.[cite: 2] |
+
+---
+
+*Aktualisiere bei jeder Session die Zeile „Aktuelle Position" in Abschnitt 0 und die Status-Marker.[cite: 2] Damit kann der Fortschritt jederzeit punktgenau aufgegriffen werden.*[cite: 2]

Unterlagen/Pflichtenheft-GruppeH/Pflichtenheft_v1_1.md

@@ -41,7 +41,7 @@ Dieses Pflichtenheft (System Requirements Specification, SRS) ist das Antwortdok
 
 | Funktion     | Name                       | Rolle / Gruppe                     | Datum      |
 |--------------|----------------------------|------------------------------------|------------|
-| Ersteller    | Christopher Lampert        | Autor, Gruppe H (Kundenverwaltung) | 11.06.2026 |
+| Ersteller    | Christopher Lampert        | Autor, Gruppe H (Kundenverwaltung) | 25.06.2026 |
 | Prüfer       | Prof. Dr. Gerd Marmitt     | Auftraggeber / Gutachter           | _(offen)_  |
 | Freigebender | SE1 Team 2 (Gruppenleiter) | Projektleitung / Freigabe          | _(offen)_  |
 
@@ -52,7 +52,7 @@ Dieses Pflichtenheft (System Requirements Specification, SRS) ist das Antwortdok
 | Version | Datum      | Autor               | Änderung                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
 |---------|------------|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | 1.0     | 11.06.2026 | Christopher Lampert | Initiale Erstellung des Pflichtenhefts auf Basis Lastenheft v1.0 und Project Charter v1.1: funktionale Anforderungen F-PV/F-KV/F-DP/F-GUI mit Satzschablone; nicht-funktionale Anforderungen mit messbaren Kriterien; Datenobjekte mit Java-Datentypen; Schnittstellen IF-01 bis IF-03; Geschäftsregeln GR-01 bis GR-06 mit Java-Umsetzungshinweisen; UML-Diagramme (Use-Case, Kontext, Klassen, Komponenten, Sequenz); testbare Abnahmekriterien (Testfälle TC-*); vollständige Traceability-Matrix LH ↔ PH. |
-| 1.0     | 24.06.2026 | Christopher Lampert | Redaktionelle Überarbeitung (Review-Einarbeitung) ohne Versionserhöhung: Freigabeübersicht um Rolle und Datum ergänzt; sechs UML-Diagramme als generierte PNG-Grafiken eingebunden, PlantUML-Quellen nach Anhang 9.5 verschoben; organisatorische Gruppenaufteilung aus Kap. 3.1 entfernt (gehört in den Project-Charter), Modul-Package-Zuordnung beibehalten; Abweichungshinweis zu BA-PV/KV-05…08 in Kap. 4 und Kap. 9.4 bereinigt; Begründung zur BigDecimal-Wahl in Kap. 6.1 ergänzt.                    |
+| 1.1     | 24.06.2026 | Christopher Lampert | Redaktionelle Überarbeitung (Review-Einarbeitung) ohne Versionserhöhung: Freigabeübersicht um Rolle und Datum ergänzt; sechs UML-Diagramme als generierte PNG-Grafiken eingebunden, PlantUML-Quellen nach Anhang 9.5 verschoben; organisatorische Gruppenaufteilung aus Kap. 3.1 entfernt (gehört in den Project-Charter), Modul-Package-Zuordnung beibehalten; Abweichungshinweis zu BA-PV/KV-05…08 in Kap. 4 und Kap. 9.4 bereinigt; Begründung zur BigDecimal-Wahl in Kap. 6.1 ergänzt.                    |
 ---
 
 ## 1. Einleitung
@@ -83,9 +83,8 @@ sowie deren Zusammenspiel über die in Kapitel 6.2 definierten Schnittstellen.
 
 - **[1]** `Lastenheft_v1_0.md` – Lastenheft Fakturierungssystem, Version 1.0, 15.05.2026
 - **[2]** `project-charter_v1_1.md` – Project Charter Fakturierungssystem, Version 1.1, 15.05.2026
-- **[3]** `week7slides.pdf` – Vorlesung Software Engineering 1, Woche 7: Pflichtenheft, Anforderungen und Traceability
+- **[3]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen
-- **[4]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen
+- **[4]** DSGVO – Verordnung (EU) 2016/679
-- **[5]** DSGVO – Verordnung (EU) 2016/679
 
 ### 1.4 Abgrenzung (Nicht-Bestandteil)
 
@@ -133,7 +132,7 @@ Das Fakturierungssystem wird als **lokal installierte Java-Desktop-Anwendung** f
 
 Abbildung 1 zeigt den einzigen Akteur **Anwender** und die Hauptanwendungsfälle des Systems. Die Belegerzeugung folgt der festen Dokumentenkette (GR-01): Eine Auftragsbestätigung setzt ein angenommenes Angebot voraus, ein Lieferschein eine bestätigte Auftragsbestätigung und eine Rechnung einen gelieferten Lieferschein.
 
-![Abbildung 1: Use-Case-Diagramm des Fakturierungssystems mit Akteur „Anwender".](../../../Desktop/Pflichtenheft%201.0/sources/abb1.png)
+![Abbildung 1: Use-Case-Diagramm des Fakturierungssystems mit Akteur „Anwender".](sources/abb1.png)
 
 ---
 
@@ -164,7 +163,7 @@ Das System kennt – wie im Lastenheft Kap. 3.2 festgelegt – ausschließlich d
 
 Abbildung 2 grenzt das System gegen seine Umgebung ab. Das System interagiert mit dem Anwender über die GUI, mit dem lokalen Dateisystem zur Persistenz und mit einer PDF-Bibliothek zur Erzeugung druckbarer Belege. Externe System- oder Netzanbindungen bestehen nicht (vgl. Nicht-Ziele).
 
-![Abbildung 2: Systemkontextdiagramm – Abgrenzung System gegen Umgebung.](../../../Desktop/Pflichtenheft%201.0/sources/abb2.png)
+![Abbildung 2: Systemkontextdiagramm – Abgrenzung System gegen Umgebung.](sources/abb2.png)
 
 ---
 
@@ -234,7 +233,7 @@ Das System MUSS es dem Anwender ermöglichen, nach Kunden zu suchen, indem es di
 
 - **Priorität:** Muss
 - **Herkunft:** BA-KV-03
-- **Akzeptanzkriterium:** Kunden werden über Namen oder Kundennummer gefunden. Bei ungültiger Eingabe erscheint der Hinweis „Kein Kunde gefunden".
+- **Akzeptanzkriterium:** Kunden werden über Namen oder kundeId gefunden. Bei ungültiger Eingabe erscheint der Hinweis „Kein Kunde gefunden".
 
 **F-KV-04 – Kunde löschen (Muss)**
 
@@ -451,7 +450,7 @@ Die nicht-funktionalen Anforderungen werden 1:1 aus Lastenheft Kap. 5 übernomme
 
 Für jedes Datenobjekt aus Lastenheft Kap. 6.1 wird die technische Realisierung mit konkreten Java-Datentypen festgelegt. Geldbeträge und Steuersätze werden ausnahmslos als `BigDecimal` modelliert (niemals `double`/`float`), Datumsangaben als `LocalDate`, Statusfelder als eigene `enum`-Klassen.
 
-BigDecimal wird trotz der in der Vorlesung genannten Nachteile gewählt: höhere Ausführlichkeit (keine arithmetischen Operatoren – Berechnungen über `add()`, `multiply()`, `compareTo()`), höherer Rechen- und Speicheraufwand gegenüber primitiven Typen sowie die bekannte Falle, dass `equals()` die Skala mitvergleicht (Vergleiche daher über `compareTo()`). Diese Nachteile sind hier vertretbar, weil exakte Dezimalarithmetik bei Geldbeträgen Vorrang vor Performance hat (Rundungsfehler von `double`/`float` sind ausgeschlossen), die Datenmengen klein sind (Einzelplatz, wenige Positionen je Beleg) und das Vorgehen den Vorlesungsbeispielen sowie GR-06 entspricht. Die Alternative – Beträge als `long` in Cent – wurde verworfen, da sie Steuersätze und Prozentrechnung (z. B. 0.19) sowie mehrstufige Rundung umständlicher abbildet.
+BigDecimal wird trotz der in der Vorlesung genannten Nachteile gewählt: höhere Ausführlichkeit (keine arithmetischen Operatoren – Berechnungen über `add()`, `multiply()`, `compareTo()`), höherer Rechen- und Speicheraufwand gegenüber primitiven Typen sowie die bekannte Falle, dass `equals()` die Skala mitvergleicht (Vergleiche daher über `compareTo()`). Diese Nachteile sind hier vertretbar, weil exakte Dezimalarithmetik bei Geldbeträgen Vorrang vor Performance hat (Rundungsfehler von `double`/`float` sind ausgeschlossen), die Datenmengen klein sind (Einzelplatz, wenige Positionen je Beleg) und das Vorgehen den Vorlesungsbeispielen sowie GR-06 entspricht. Die Alternative – Beträge als `long` in Cent – wurde verworfen, da sie Steuersätze und Prozentrechnung (z. B. 0.19) sowie mehrstufige Rundung umständlicher abbildet.Die Entscheidung für BigDecimal wurde daher bewusst getroffen, da die fachliche Korrektheit von Geldbeträgen im Fakturierungsprozess Vorrang vor einer maximalen Rechenleistung besitzt.
 
 #### 6.1.1 Produkt
 
@@ -558,7 +557,7 @@ BigDecimal wird trotz der in der Vorlesung genannten Nachteile gewählt: höhere
 
 Abbildung 3 zeigt die Datenobjekte mit ihren Java-Typen und Beziehungen. Ein Kunde besitzt beliebig viele Angebote; jeder Beleg besteht aus mindestens einer Belegposition; jede Position verweist auf genau ein Produkt. Die Belege bilden die Dokumentenkette Angebot → Auftragsbestätigung → Lieferschein → Rechnung mit Multiplizität 1:0..1 (jeder Vorgänger hat höchstens einen Nachfolger).
 
-![Abbildung 3: UML-Klassendiagramm der Datenobjekte mit Java-Typen und Multiplizitäten.](../../../Desktop/Pflichtenheft%201.0/sources/abb3.png)
+![Abbildung 3: UML-Klassendiagramm der Datenobjekte mit Java-Typen und Multiplizitäten.](sources/abb3.png)
 
 ### 6.2 Schnittstellen
 
@@ -608,19 +607,23 @@ Das System folgt gemäß NF-MAINT-03 und NF-ARCH-01/02 einer dokumentierten, dre
 
 Die Schichten kommunizieren ausschließlich über die in Kap. 6.2 definierten Schnittstellen (IF-01 GUI ↔ Logik, IF-02 Logik ↔ Datenhaltung, IF-03 Logik ↔ PDF-Bibliothek). Abbildung 4 zeigt die vier fachlichen Module als Komponenten innerhalb der drei Schichten.
 
-![Abbildung 4: Komponentendiagramm – vier Module in der dreischichtigen Architektur.](../../../Desktop/Pflichtenheft%201.0/sources/abb4.png)
+![Abbildung 4: Komponentendiagramm – vier Module in der dreischichtigen Architektur.](sources/abb4.png) 
+Das Komponentendiagramm verdeutlicht die Trennung zwischen Präsentations-, Logik- und Datenhaltungsschicht. Die Kommunikation erfolgt ausschließlich über definierte Schnittstellen. Dadurch wird eine geringe Kopplung der Komponenten sowie eine bessere Wartbarkeit und Testbarkeit des Systems erreicht.
+
+
 
 ### 7.2 UML-Klassendiagramm der Kernklassen
 
 Abbildung 5 zeigt die Kernklassen der Logik- und Datenhaltungsschicht mit Methodensignaturen (Parameter- und Rückgabetypen) sowie deren Beziehungen. Die Services bilden die Logikschicht, das `ProduktRepository` steht stellvertretend für die als Interface modellierte Persistenzabstraktion (IF-02, NF-ARCH-02).
 
-![Abbildung 5: Detailliertes UML-Klassendiagramm der Kernklassen mit Methodensignaturen.](../../../Desktop/Pflichtenheft%201.0/sources/abb5.png)
+![Abbildung 5: Detailliertes UML-Klassendiagramm der Kernklassen mit Methodensignaturen.](sources/abb5.png)
 
 ### 7.3 UML-Sequenzdiagramm „Angebot → Rechnung"
 
 Abbildung 6 zeigt den Hauptprozess von der Statusänderung eines angenommenen Angebots bis zur Erzeugung der Rechnung. Der Anwender stößt die Aktionen über die GUI an; die Services kapseln die Geschäftslogik (Statusprüfung GR-01, Nummernvergabe GR-02, Summenberechnung GR-06), die Repositories übernehmen die Persistenz.
 
-![Abbildung 6: UML-Sequenzdiagramm des Hauptprozesses „Angebot → Rechnung".](../../../Desktop/Pflichtenheft%201.0/sources/abb6.png)
+![Abbildung 6: UML-Sequenzdiagramm des Hauptprozesses „Angebot → Rechnung".](sources/abb6.png)
+Das Sequenzdiagramm beschreibt den Ablauf der Rechnungserstellung einschließlich Statusprüfung, Nummernvergabe und Persistierung. Die dargestellte Reihenfolge stellt sicher, dass ausschließlich fachlich gültige Geschäftsvorgänge in Rechnungen überführt werden können.
 
 ---
 
@@ -755,9 +758,8 @@ Für jede Muss-Anforderung ist mindestens ein Testfall definiert. Jeder Testfall
 
 - **[1]** Lastenheft v1.0 (`Lastenheft_v1_0.md`), 15.05.2026
 - **[2]** Project Charter v1.1 (`project-charter_v1_1.md`), 15.05.2026
-- **[3]** `week7slides.pdf` – Vorlesung Software Engineering 1, Woche 7
+- **[3]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen
-- **[4]** § 14 UStG – Umsatzsteuergesetz, Pflichtangaben in Rechnungen
+- **[4]** DSGVO – Verordnung (EU) 2016/679
-- **[5]** DSGVO – Verordnung (EU) 2016/679
 
 ### 9.4 Traceability-Matrix LH ↔ PH