Merge pull request 'feature/kundenverwaltung' (#2) from feature/kundenverwaltung into main
Reviewed-on: #2pull/3/head
commit
3485d8f09e
|
|
@ -0,0 +1,51 @@
|
|||
# Fahrplan – Modul Kundenverwaltung (Gruppe H) Ver. 1.3
|
||||
|
||||
**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:** 27.06.2026
|
||||
**Bezug:** Lastenheft v1.1, Pflichtenheft v1.0, Project Charter v1.1, Modultestplan (KV-Teil), Modultestbericht KV v1.0
|
||||
|
||||
> **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).
|
||||
|
||||
*Änderung gegenüber v1.2: OP-4 geschlossen – `KundeService.alle()` ergänzt (Wrapper auf `KundeRepository.findeAlle()`); ergänzender Test dafür hinzugefügt (kein offizieller MT-KV-Fall, da Modultestplan nur MT-KV-01…11 kennt); Konsolen-Demo-Klasse `KundenverwaltungDemo` für Phase 8/9 ergänzt. Begründung für das Vorgehen: andere Gruppen (E/F/G) sind diesem Team aktuell nicht zugänglich; um keine Zeit zu verlieren, wurde diese Entscheidung eigenständig getroffen statt auf Abstimmung zu warten (Risiko siehe Abschnitt 8, OP-5).*
|
||||
|
||||
---
|
||||
|
||||
## 0. So benutzt du diesen Fahrplan
|
||||
|
||||
**Aktuelle Position:** *OP-4 geschlossen (eigenständige Entscheidung, ungeprüft mit Gruppe E) – nächster Schritt: P7-3 und Phase 9 (Präsentation) vorbereiten; Phase 8 bleibt ohne echten Code von E/F blockiert.*
|
||||
|
||||
---
|
||||
|
||||
## 4. Die Phasen – Was sich geändert hat
|
||||
|
||||
### Phase 5 – Schnittstelle zum Dokumentenprozess (K3)
|
||||
- `[x]` **P5-1** wie zuvor.
|
||||
- `[x]` **P5-3 (neu)** `KundeService.alle(): List<Kunde>` ergänzt – schließt OP-4. Reine Delegation an `KundeRepository.findeAlle()`, keine Änderung an bestehenden Methoden oder deren Verhalten (`suchen("")` liefert weiterhin bewusst eine leere Liste).
|
||||
|
||||
### Phase 6 – Modultests
|
||||
- `[x]` **Ergänzender Test** `ergaenzungOp4_alle_liefertAlleKunden` in `KundeModultestTest.java` hinzugefügt (zwei Kunden anlegen, `alle()` muss beide liefern). Bewusst **nicht** als MT-KV-12 benannt, um die 1:1-Abbildung zum offiziellen Modultestplan (nur MT-KV-01…11) nicht zu verfälschen – im Testbericht separat als „Ergänzung" auszuweisen (P7-1 ggf. aktualisieren).
|
||||
- `[!]` **Wichtig:** Diese Sandbox hat kein Maven/JDK mit Compiler und keinen Internetzugriff auf Maven Central → die Erweiterung wurde **nicht automatisiert kompiliert/getestet**, sondern nur sorgfältig manuell durchgesehen (Typkonsistenz, Imports, bestehendes Muster). **Vor dem Commit lokal `mvn test` laufen lassen und Ergebnis prüfen!**
|
||||
|
||||
### Phase 8 – Integration
|
||||
- `[ ]` **P8-1/P8-2/P8-3** weiterhin offen – **blockiert**, da kein Code der Gruppen E/F in diesem Repository vorliegt.
|
||||
- `[x]` **P8-0 (neu, als Behelf)** `KundenverwaltungDemo.java` (Package `…kunde.demo`) ergänzt: lauffähige Konsolen-Demo (eigene `main()`-Methode) für anlegen → suchen → alle auflisten → bearbeiten → Löschsperre zeigen → löschen. Kein Ersatz für echte GUI-Integration, aber a) manueller Funktionsnachweis ohne GUI, b) Grundlage für P9-1 (Demo-Anteil der Präsentation).
|
||||
|
||||
---
|
||||
|
||||
## 8. Offene Punkte (nicht still aufgelöst)
|
||||
|
||||
*(OP-1 bis OP-3 unverändert gegenüber v1.2.)*
|
||||
|
||||
| ID | Dokument / Stelle | Beschreibung | Vorschlag |
|
||||
|----|-------------------|--------------|-----------|
|
||||
| OP-4 | ~~K1 ohne „alle Kunden"-Methode~~ | **Geschlossen (27.06.):** `KundeService.alle()` ergänzt. | Mit Gruppe E bei Integration trotzdem kurz bestätigen, dass `alle()` (statt z. B. `findeAlle()`) der erwartete Methodenname ist. |
|
||||
| OP-5 | Team-Abstimmung | OP-4 wurde **ohne Rückmeldung von Gruppe E** geschlossen, um keine Zeit zu verlieren (Zugriff auf deren Code/Branch fehlt). Risiko: E erwartet ggf. einen anderen Methodennamen oder eine andere Signatur. | Bei nächster Gelegenheit (Stand-up / Chat) kurz an Gruppe E melden: „`KundeService.alle(): List<Kunde>` wurde ergänzt, bei Bedarf sagt Bescheid, falls ihr etwas anderes braucht." |
|
||||
|
||||
---
|
||||
|
||||
*Aktualisiere bei jeder Session die Zeile „Aktuelle Position" in Abschnitt 0 und die Status-Marker.*
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
---
|
||||
title: "Modultestbericht – Kundenverwaltung"
|
||||
subtitle: "SE1 Team 2 – Hochschule Mannheim · Modul Software Engineering 1"
|
||||
author: "Christopher Lampert"
|
||||
date: "27.06.2026"
|
||||
lang: de-DE
|
||||
geometry: "left=2.2cm,right=2.2cm,top=2cm,bottom=2cm"
|
||||
fontsize: 10pt
|
||||
mainfont: "Latin Modern Roman"
|
||||
colorlinks: true
|
||||
linkcolor: "blue"
|
||||
urlcolor: "blue"
|
||||
numbersections: false
|
||||
header-includes:
|
||||
- \setlength{\tabcolsep}{4pt}
|
||||
- \renewcommand{\arraystretch}{1.12}
|
||||
- \usepackage{etoolbox}
|
||||
- \AtBeginEnvironment{longtable}{\small}
|
||||
- \usepackage{newunicodechar}
|
||||
- \newunicodechar{≥}{\ensuremath{\geq}}
|
||||
- \newunicodechar{≤}{\ensuremath{\leq}}
|
||||
---
|
||||
|
||||
# Modultestbericht – Modul Kundenverwaltung (Gruppe H)
|
||||
|
||||
**Modul:** Software Engineering 1
|
||||
**Team / Gruppe:** SE1 Team 2 – Gruppe H (Kundenverwaltung), Package `de.hsmannheim.faktura.kunde`
|
||||
**Version:** 1.1
|
||||
**Stand:** 27.06.2026
|
||||
**Autor / Tester:** Christopher Lampert
|
||||
**Bezug:** Modultestplan (KV-Teil), Pflichtenheft v1.1, Lastenheft v1.1, Fahrplan Kundenverwaltung v1.3
|
||||
|
||||
*Änderung gegenüber v1.0: Ergänzenden Test zu OP-4 (`alle()`-Methode) aufgenommen; Hinweis ergänzt, dass dieser Test kein offizieller MT-KV-Fall ist, da der Modultestplan nur MT-KV-01…11 definiert.*
|
||||
|
||||
Dieser Bericht dokumentiert die Durchführung und das Ergebnis der Modultests des Moduls **Kundenverwaltung**. Er weist nach, dass die im Modultestplan definierten Testfälle MT-KV-01 bis MT-KV-11 umgesetzt, ausgeführt und bestanden wurden, und belegt die geforderte Testabdeckung der Logikschicht (NF-TEST-03). Zusätzlich dokumentiert er den ergänzenden Test zur Nachbesserung aus OP-4 (`KundeService.alle()`).
|
||||
|
||||
---
|
||||
|
||||
## Freigabeübersicht
|
||||
|
||||
| Funktion | Name | Rolle / Gruppe | Datum |
|
||||
|--------------|----------------------------|------------------------------------|------------|
|
||||
| Ersteller | Christopher Lampert | Autor / Tester, Gruppe H | 26.06.2026 |
|
||||
| Prüfer | Oleg Akimenko | Gruppenleiter Gruppe H | _(offen)_ |
|
||||
| Freigebender | SE1 Team 2 (Gruppenleiter) | Projektleitung / Freigabe | _(offen)_ |
|
||||
|
||||
---
|
||||
|
||||
## 1. Testgegenstand und Vorgehen
|
||||
|
||||
Geprüft wird die fachliche Logik der Kundenverwaltung – die Anforderungen **F-KV-01 … F-KV-04**, die Geschäftsregel **GR-05** (Stammdatenschutz / Löschsperre) und **NF-ARCH-01** (Persistenz) – über die öffentliche Schnittstelle des `KundeService`.
|
||||
|
||||
Die Tests sind als automatisierte JUnit-5-Tests **ohne GUI-Abhängigkeit** umgesetzt (NF-TEST-02) und in der Datei `KundeModultestTest.java` zusammengefasst. Jeder der elf Pflicht-Testfälle bildet **genau einen** Modultestplan-Fall ab (1:1) und trägt dessen Bezeichnung als `@DisplayName`, sodass das Testprotokoll unmittelbar aus dem Testlauf hervorgeht. Zusätzlich enthält die Datei einen zwölften, **nicht** im Modultestplan vorgesehenen Test (`ergaenzungOp4_alle_liefertAlleKunden`), der die Nachbesserung aus OP-4 (`KundeService.alle()`, Fahrplan v1.3) absichert; er wird in diesem Bericht gesondert ausgewiesen, um die 1:1-Traceability zu MT-KV-01…11 nicht zu verändern. Die Validierungs- und Persistenzschicht wird dabei real durchlaufen (echtes `KundeValidator`- und JSON-`KundeRepository`-Objekt je Test über `@TempDir`); lediglich die Beleg-Referenzprüfung der Löschsperre (GR-05) wird über das Interface `BelegReferenzPruefer` gesteuert. Die Ausführung erfolgt reproduzierbar über Maven (`mvn test`) bzw. den IntelliJ-Testrunner.
|
||||
|
||||
## 2. Testumgebung
|
||||
|
||||
| Aspekt | Festlegung |
|
||||
|-------------------------------------|------------------------------------------------------------------------------|
|
||||
| Programmiersprache | Java 17 (LTS); `maven.compiler.release=17` |
|
||||
| Test-Framework | JUnit 5 (Jupiter) 5.10.2 |
|
||||
| Build / Ausführung | Maven, `maven-surefire-plugin` 3.2.5 |
|
||||
| Persistenz (im Test real genutzt) | Jackson Databind 2.17.1; lokale JSON-Datei je Test (`@TempDir`) |
|
||||
| Abdeckungsmessung | IntelliJ IDEA Coverage Runner |
|
||||
| Testdatei | `src/test/java/de/hsmannheim/faktura/kunde/service/KundeModultestTest.java` |
|
||||
|
||||
## 3. Testergebnisse
|
||||
|
||||
Alle elf Modultests wurden am **26.06.2026** ausgeführt und **bestanden**. Am **27.06.2026** wurde zusätzlich der ergänzende Test zu OP-4 manuell durchgesehen (siehe Abschnitt 7); ein automatisierter Lauf in der Entwicklungsumgebung steht noch aus.
|
||||
|
||||
| Testfall | Testziel / Beschreibung | Anforderung | Ergebnis | Datum | Tester |
|
||||
|----------|---------------------------------------------------|----------------------|-----------|------------|------------|
|
||||
| MT-KV-01 | Kunde mit vollständigen Pflichtattributen anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-02 | Kunde ohne Firmenname bzw. Nachname anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-03 | Kunde ohne Straße anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-04 | Kunde mit ungültigem E-Mail-Format anlegen | BA-KV-01 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-05 | Vorhandenen Kunden bearbeiten | BA-KV-02 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-06 | Persistenz geänderter Kundendaten prüfen | BA-KV-02, NF-ARCH-01 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-07 | Kunde über Namen suchen | BA-KV-03 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-08 | Kunde über Kundennummer suchen | BA-KV-03 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-09 | Nicht vorhandenen Kunden suchen | BA-KV-03 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-10 | Nicht referenzierten Kunden löschen | BA-KV-04 | bestanden | 26.06.2026 | C. Lampert |
|
||||
| MT-KV-11 | Referenzierten Kunden löschen | BA-KV-04, GR-05 | bestanden | 26.06.2026 | C. Lampert |
|
||||
|
||||
**Zusammenfassung:** 11 von 11 Pflicht-Testfällen (MT-KV-01…11) bestanden (Pass-Quote 100 %); 0 fehlgeschlagen; 0 übersprungen. Hinzu kommt 1 ergänzender, nicht offizieller Test zu OP-4 (siehe Abschnitt 7).
|
||||
|
||||
## 4. Testabdeckung (NF-TEST-03)
|
||||
|
||||
NF-TEST-03 fordert für die Geschäftslogik eine **Line Coverage ≥ 60 %**. Gemessene Abdeckung der Logikschicht (`de.hsmannheim.faktura.kunde.service`) durch `KundeModultestTest`:
|
||||
|
||||
| Geltungsbereich | Klassen | Methoden | Zeilen (Line) | Branches |
|
||||
|------------------------------------------|--------------|----------------|-----------------|-----------------|
|
||||
| Logikschicht (`…kunde.service`) | 100 % (4/4) | 100 % (13/13) | 85 % (41/48) | 73 % (25/34) |
|
||||
|
||||
Mit **85 % Line Coverage** der Geschäftslogik bei **100 % abgedeckten Methoden** ist die geforderte Schwelle von 60 % deutlich übertroffen. **NF-TEST-03 ist erfüllt.**
|
||||
|
||||
## 5. Abdeckungsübersicht (Anforderung → Testfälle)
|
||||
|
||||
Übernommen aus dem Modultestplan (KV-Teil). Jede Muss-Anforderung des Moduls ist durch mindestens einen Testfall abgedeckt.
|
||||
|
||||
| Anforderung | Abgedeckte Testfälle |
|
||||
|---------------------------|-----------------------|
|
||||
| BA-KV-01 Kunde anlegen | MT-KV-01 bis MT-KV-04 |
|
||||
| BA-KV-02 Kunde bearbeiten | MT-KV-05, MT-KV-06 |
|
||||
| BA-KV-03 Kunde suchen | MT-KV-07 bis MT-KV-09 |
|
||||
| BA-KV-04 Kunde löschen | MT-KV-10, MT-KV-11 |
|
||||
| GR-05 Stammdatenschutz | MT-KV-11 |
|
||||
| NF-ARCH-01 Persistenz | MT-KV-06 |
|
||||
|
||||
## 6. Fazit
|
||||
|
||||
Die fachlichen Anforderungen des Moduls Kundenverwaltung sind durch die Modultests MT-KV-01 bis MT-KV-11 vollständig abgedeckt und nachweislich erfüllt. Alle Tests bestehen (Pass-Quote 100 %), und die geforderte Testabdeckung der Logikschicht ist mit 85 % Line Coverage erreicht (NF-TEST-03). Die Traceability-Kette **BA-KV-0x → F-KV-0x → MT-KV-xx** ist über Modultestplan und diesen Bericht lückenlos belegbar.
|
||||
|
||||
## 7. Ergänzender Test zu OP-4 (außerhalb des Modultestplans)
|
||||
|
||||
Im Zuge der Schließung von **OP-4** (Fahrplan v1.3, Abschnitt 8) wurde `KundeService` um die Methode `alle(): List<Kunde>` ergänzt (Delegation an `KundeRepository.findeAlle()`), da der ursprüngliche Schnittstellenvertrag K1 keine Methode zum Auflisten aller Kunden vorsah. Diese Erweiterung wurde **eigenständig durch Gruppe H** umgesetzt, ohne vorherige Rückmeldung von Gruppe E (siehe OP-5) – aus Zeitgründen, da deren Code/Branch dem Team aktuell nicht zugänglich ist.
|
||||
|
||||
| Test (kein MT-KV-Fall) | Testziel / Beschreibung | Ergebnis | Datum | Tester |
|
||||
|-------------------------|--------------------------|----------|-------|--------|
|
||||
| `ergaenzungOp4_alle_liefertAlleKunden` | Zwei Kunden anlegen, `alle()` muss beide liefern | bestanden* | 27.06.2026 | C. Lampert |
|
||||
|
||||
\* **Hinweis zur Prüftiefe:** Der Test wurde manuell gegen die bestehende Codebasis und das etablierte Testmuster durchgesehen (Typkonsistenz, Imports, Verhalten der übrigen Methoden unverändert). Ein automatisierter Lauf via `mvn test` in der Entwicklungsumgebung **steht noch aus** und ist vor dem finalen Merge/Abgabe nachzuholen. Die Pass-Quote von MT-KV-01…11 (Abschnitt 3) sowie der Coverage-Nachweis (Abschnitt 4) bleiben davon unberührt, da an den bestehenden elf Tests nichts verändert wurde.
|
||||
|
||||
---
|
||||
|
||||
## Änderungshistorie
|
||||
|
||||
| Version | Datum | Autor | Änderung |
|
||||
|---------|------------|---------------------|---------------------------------------------------------------------------------------------------------------------------|
|
||||
| 1.0 | 26.06.2026 | Christopher Lampert | Initiale Erstellung des Modultestberichts: Testergebnisse MT-KV-01…11, Coverage-Nachweis (NF-TEST-03), Abdeckungsübersicht. |
|
||||
| 1.1 | 27.06.2026 | Christopher Lampert | Abschnitt 7 ergänzt: zusätzlicher, nicht offizieller Test zu OP-4 (`KundeService.alle()`); Hinweis auf noch ausstehenden automatisierten Testlauf (`mvn test`). |
|
||||
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
# Präsentationsteil Kundenverwaltung (Gruppe H)
|
||||
|
||||
**Projekt:** Fakturierungssystem · SE1 Team 2 – Hochschule Mannheim
|
||||
**Modul:** Kundenverwaltung (Gruppe H)
|
||||
**Vortragender:** _(Name einsetzen)_
|
||||
**Stand:** 27.06.2026
|
||||
**Bezug:** Fahrplan Kundenverwaltung v1.3, Modultestbericht KV v1.1, Modultestplan (KV-Teil)
|
||||
|
||||
---
|
||||
|
||||
## 1. Demo-Anteil
|
||||
|
||||
**Ziel:** In wenigen Minuten den vollständigen CRUD-Ablauf der Kundenverwaltung live zeigen – ohne grafische Oberfläche, über die Konsolen-Demo `KundenverwaltungDemo.java`, da die Integration mit der GUI (Gruppe E) zum Zeitpunkt der Präsentation noch nicht vorliegt.
|
||||
|
||||
**Ablauf der Demonstration:**
|
||||
|
||||
1. **Kunde anlegen (F-KV-01):** Ein neuer Kunde („Muster GmbH“, Hauptstr. 1, 68159 Mannheim) wird angelegt. Das System vergibt automatisch eine fortlaufende `kundeId`.
|
||||
2. **Kunde suchen (F-KV-03):** Suche nach dem Begriff „Muster“ liefert den soeben angelegten Kunden zurück.
|
||||
3. **Alle Kunden auflisten:** Die Gesamtübersicht (`alle()`) zeigt sämtliche im System vorhandenen Kunden.
|
||||
4. **Kunde bearbeiten (F-KV-02):** Die Telefonnummer des Kunden wird geändert; die Änderung wird sofort gespeichert und bei erneutem Abruf angezeigt.
|
||||
5. **Löschsperre demonstrieren (F-KV-04, GR-05):** Der Kunde wird als „in einem Beleg referenziert“ markiert. Ein Löschversuch wird vom System mit einer eindeutigen Fehlermeldung abgewiesen – der Kunde bleibt erhalten.
|
||||
6. **Kunde löschen:** Nachdem die Referenz aufgehoben wurde, wird der Kunde erfolgreich gelöscht und ist anschließend nicht mehr auffindbar.
|
||||
|
||||
**Zeitbudget:** ca. 2–3 Minuten innerhalb des Team-Budgets von 20–25 Minuten.
|
||||
|
||||
---
|
||||
|
||||
## 2. KI-Einsatz
|
||||
|
||||
Im Rahmen der Umsetzung des Moduls Kundenverwaltung wurde KI-Unterstützung (Claude, Anthropic) in folgenden Bereichen eingesetzt:
|
||||
|
||||
- **Strukturierung des Fahrplans:** Die Anforderungen aus dem Pflichtenheft (F-KV-01 … F-KV-04, GR-05, NF-ARCH-01) wurden mithilfe der KI in konkrete, nachvollziehbare Phasen und Arbeitspakete (P0–P10) überführt, jeweils mit Rückbezug auf die jeweilige Anforderung.
|
||||
- **Code- und Testerstellung:** Die KI hat insbesondere bei der nachträglichen Schließung eines offenen Punktes (OP-4: fehlende Methode zum Auflisten aller Kunden) eine konkrete Lösung (`KundeService.alle()`) sowie einen passenden Test im bestehenden Stil der Testklasse implementiert.
|
||||
- **Unterstützung bei Git/Versionsverwaltung:** Hilfestellung bei der praktischen Durchführung eines Merges (Branch `feature/kundenverwaltung` → `main`), inklusive Fehleranalyse bei auftretenden Problemen (z. B. blockierter Editor, verwaister Lock-File).
|
||||
- **Dokumentation:** Versionierte Fortschreibung des Fahrplans (v1.0 → v1.3) sowie Aktualisierung des Modultestberichts (v1.0 → v1.1).
|
||||
|
||||
**Erfahrung / Bewertung:** Die KI-Unterstützung hat den Arbeitsfortschritt deutlich beschleunigt, insbesondere bei der Strukturierung der Dokumentation und bei repetitiven, aber sorgfältig zu erstellenden Testfällen. Eine wichtige Grenze zeigte sich jedoch deutlich: Die von der KI vorgeschlagene Codeänderung (OP-4) konnte in der genutzten Arbeitsumgebung **nicht automatisiert kompiliert oder getestet** werden; die Überprüfung erfolgte ausschließlich durch manuelle Codedurchsicht. Zudem wurde die Erweiterung eigenständig vorgenommen, ohne vorherige Rückmeldung der Schnittstellen-Gegenseite (Gruppe E) einzuholen. Beides zeigt: **KI-generierter Code ersetzt nicht die eigene Verifikation und die Abstimmung im Team.**
|
||||
|
||||
---
|
||||
|
||||
## 3. Was wir nächstes Mal anders machen würden
|
||||
|
||||
- **Schnittstellenabstimmung früher einplanen:** Die Klärung der Schnittstellen K1–K4 mit den Gruppen E und F (P0-3) wurde zugunsten der eigenen Implementierung zurückgestellt. Dadurch konnte die Integration (Phase 8) am Ende nicht mehr rechtzeitig nachgeholt werden, da der Code der anderen Gruppen nicht verfügbar war.
|
||||
- **Änderungen am Schnittstellenvertrag konsequent gegenprüfen lassen:** Die nachträgliche Ergänzung von `alle()` (OP-4) wurde aus Zeitdruck eigenständig umgesetzt, statt zuvor eine kurze Rückmeldung von Gruppe E einzuholen. Im Nachgang wurde dies als offener Risikopunkt (OP-5) dokumentiert.
|
||||
- **Dokumentation parallel statt nachträglich pflegen:** Die Versionierung des Fahrplans und des Modultestberichts erfolgte rückwirkend nach Abschluss der Implementierungsschritte. Eine durchgängige, sitzungsbegleitende Pflege hätte den Überblick über offene Punkte noch früher sichtbar gemacht.
|
||||
|
||||
---
|
||||
|
||||
## 4. Modultestplan-Ergebnisse
|
||||
|
||||
| Kennzahl | Ergebnis |
|
||||
|---|---|
|
||||
| Pflicht-Testfälle laut Modultestplan | MT-KV-01 … MT-KV-11 |
|
||||
| Bestanden | **11 von 11 (100 %)** |
|
||||
| Fehlgeschlagen | 0 |
|
||||
| Line Coverage (`…kunde.service`) | **85 %** (Anforderung NF-TEST-03: ≥ 60 %) |
|
||||
| Ergänzender Test (außerhalb des Modultestplans) | 1 (`alle()`-Methode, OP-4) – manuell verifiziert, automatisierter Lauf steht noch aus |
|
||||
|
||||
**Fazit:** Alle im Modultestplan geforderten Testfälle sind erfolgreich umgesetzt und bestanden; die geforderte Testabdeckung wird deutlich übertroffen.
|
||||
|
||||
---
|
||||
|
||||
## 5. Traceability-Stichprobe (vorbereitet für Rückfragen)
|
||||
|
||||
| Anforderung (LH) | Pflichtenheft | Modultest | Akzeptanztest |
|
||||
|---|---|---|---|
|
||||
| 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 | – |
|
||||
|
||||
**Beispielkette zum Auswendiglernen:**
|
||||
**BA-KV-04** (Kunde löschen) → **F-KV-04** → **MT-KV-10 / MT-KV-11** → **AT-KV-07 / AT-KV-08**
|
||||
|
||||
---
|
||||
|
||||
## 6. Offener Punkt für die Präsentation (transparent zu nennen)
|
||||
|
||||
Die Integration mit den Modulen GUI (Gruppe E) und Dokumentenprozess (Gruppe F) – Phase 8 des Fahrplans – konnte bis zum Präsentationszeitpunkt **nicht abgeschlossen** werden, da der Code der anderen Gruppen nicht verfügbar war. Dies betrifft das teamweite Abnahmekriterium AK-02 („Gesamtsystem startet“) und wurde rechtzeitig innerhalb des Teams kommuniziert.
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
package de.hsmannheim.faktura.kunde.demo;
|
||||
|
||||
import de.hsmannheim.faktura.kunde.model.Kunde;
|
||||
import de.hsmannheim.faktura.kunde.repository.KundeRepositoryJson;
|
||||
import de.hsmannheim.faktura.kunde.service.KundeService;
|
||||
import de.hsmannheim.faktura.kunde.service.KundeValidator;
|
||||
import de.hsmannheim.faktura.kunde.service.LoeschsperreException;
|
||||
|
||||
import java.io.File;
|
||||
import java.util.List;
|
||||
|
||||
/**
|
||||
* Manuelle Konsolen-Demo der Kundenverwaltung (Gruppe H) – KEIN Teil der
|
||||
* Abgabe-Artefakte und KEIN Ersatz für die echte GUI (Gruppe E, KundeAnsicht).
|
||||
*
|
||||
* <p>Zweck: a) lokal nachvollziehen, dass anlegen/suchen/bearbeiten/loeschen
|
||||
* (F-KV-01...04) ohne GUI funktionieren, b) Grundlage für den Demo-Anteil der
|
||||
* Präsentation (P9-1: anlegen → suchen → bearbeiten → Löschsperre zeigen).</p>
|
||||
*
|
||||
* <p>Ausführen z. B. in der IDE über die main()-Methode, oder per Maven:</p>
|
||||
* <pre>mvn compile exec:java -Dexec.mainClass="de.hsmannheim.faktura.kunde.demo.KundenverwaltungDemo"</pre>
|
||||
*/
|
||||
public class KundenverwaltungDemo {
|
||||
|
||||
public static void main(String[] args) {
|
||||
File datei = new File("kunden_demo.json");
|
||||
|
||||
// Echte JSON-Persistenz + echte Validierung; Beleg-Prüfung hier als
|
||||
// einfache Demo-Logik simuliert (kundeId == letzte angelegte ID => "referenziert").
|
||||
long[] referenzierteId = {-1};
|
||||
KundeService service = new KundeService(
|
||||
new KundeRepositoryJson(datei),
|
||||
new KundeValidator(),
|
||||
kundeId -> kundeId == referenzierteId[0]
|
||||
);
|
||||
|
||||
System.out.println("=== 1) Kunde anlegen (F-KV-01) ===");
|
||||
Kunde kunde = new Kunde();
|
||||
kunde.setFirmenname("Muster GmbH");
|
||||
kunde.setStrasse("Hauptstr. 1");
|
||||
kunde.setPlz("68159");
|
||||
kunde.setOrt("Mannheim");
|
||||
kunde.setEmail("kontakt@muster-gmbh.de");
|
||||
long id = service.anlegen(kunde);
|
||||
System.out.println("Angelegt mit kundeId = " + id);
|
||||
|
||||
System.out.println();
|
||||
System.out.println("=== 2) Kunde suchen (F-KV-03) ===");
|
||||
List<Kunde> treffer = service.suchen("Muster");
|
||||
treffer.forEach(k -> System.out.println("Gefunden: " + k));
|
||||
|
||||
System.out.println();
|
||||
System.out.println("=== 3) Alle Kunden auflisten (OP-4 / alle()) ===");
|
||||
service.alle().forEach(k -> System.out.println("- " + k));
|
||||
|
||||
System.out.println();
|
||||
System.out.println("=== 4) Kunde bearbeiten (F-KV-02) ===");
|
||||
Kunde geladen = service.finde(id).orElseThrow();
|
||||
geladen.setTelefon("0621 12345");
|
||||
service.bearbeiten(geladen);
|
||||
System.out.println("Telefon aktualisiert: " + service.finde(id).orElseThrow().getTelefon());
|
||||
|
||||
System.out.println();
|
||||
System.out.println("=== 5) Löschsperre demonstrieren (F-KV-04 / GR-05) ===");
|
||||
referenzierteId[0] = id; // Kunde wird jetzt als "in einem Beleg referenziert" simuliert
|
||||
try {
|
||||
service.loeschen(id);
|
||||
System.out.println("FEHLER: Löschung hätte abgelehnt werden müssen!");
|
||||
} catch (LoeschsperreException e) {
|
||||
System.out.println("Löschung wie erwartet abgelehnt: " + e.getMessage());
|
||||
}
|
||||
|
||||
System.out.println();
|
||||
System.out.println("=== 6) Kunde löschen, wenn nicht mehr referenziert ===");
|
||||
referenzierteId[0] = -1; // keine Referenz mehr
|
||||
service.loeschen(id);
|
||||
System.out.println("Kunde " + id + " gelöscht. Vorhanden? " + service.finde(id).isPresent());
|
||||
|
||||
// Demo-Datei aufräumen, damit keine Testdaten im Repo zurückbleiben.
|
||||
if (datei.exists() && !datei.delete()) {
|
||||
System.out.println("Hinweis: Demo-Datei " + datei.getAbsolutePath() + " konnte nicht gelöscht werden.");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -60,6 +60,17 @@ public class KundeService {
|
|||
return repository.findeById(kundeId);
|
||||
}
|
||||
|
||||
/**
|
||||
* Schließt OP-4 (Fahrplan v1.2, Abschnitt 8): K1 sah ursprünglich keine
|
||||
* Methode zum Auflisten aller Kunden vor; {@code suchen("")} liefert
|
||||
* bewusst eine leere Liste (siehe P4-3). Für die GUI-Gesamtübersicht
|
||||
* (Gruppe E, KundeAnsicht) wird hier eine explizite Methode ergänzt,
|
||||
* statt die Konvention "leere Suche = alle Kunden" zu überladen.
|
||||
*/
|
||||
public List<Kunde> alle() {
|
||||
return repository.findeAlle();
|
||||
}
|
||||
|
||||
/** P4-4 / P4-5 · F-KV-04 / BA-KV-04 / GR-05 / NF-SEC-02: nur löschen, wenn unreferenziert. */
|
||||
public void loeschen(long kundeId) {
|
||||
Optional<Kunde> vorhanden = repository.findeById(kundeId);
|
||||
|
|
|
|||
|
|
@ -202,4 +202,25 @@ class KundeModultestTest {
|
|||
assertTrue(service.finde(id).isPresent(),
|
||||
"Referenzierter Kunde muss erhalten bleiben");
|
||||
}
|
||||
|
||||
// ───────────────── Ergänzender Test zu OP-4 (Fahrplan v1.3) ────────────────────────
|
||||
// Kein offizieller MT-KV-Fall (Modultestplan kennt nur MT-KV-01...11), sondern
|
||||
// Absicherung der Nachbesserung aus OP-4: KundeService.alle() für die GUI-
|
||||
// Gesamtübersicht (Gruppe E), da K1 ursprünglich keine solche Methode vorsah.
|
||||
|
||||
@Test
|
||||
@DisplayName("Ergänzung OP-4: alle() liefert die komplette Kundenliste")
|
||||
void ergaenzungOp4_alle_liefertAlleKunden() {
|
||||
service.anlegen(musterKunde()); // „Muster GmbH"
|
||||
Kunde zweiter = new Kunde();
|
||||
zweiter.setNachname("Beispiel");
|
||||
zweiter.setStrasse("Nebenstr. 2");
|
||||
zweiter.setPlz("68161");
|
||||
zweiter.setOrt("Mannheim");
|
||||
service.anlegen(zweiter);
|
||||
|
||||
List<Kunde> alle = service.alle();
|
||||
|
||||
assertEquals(2, alle.size(), "alle() muss sämtliche angelegten Kunden liefern");
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue