Ueberarbeite Pflichtenheft Gruppe D nach Feedback

dokumentation/anforderungen/Pflichtenheft_GruppeD.md

@@ -3,7 +3,7 @@ title: "Pflichtenheft"
 subtitle: "Desktop-Fakturierungsanwendung — Gruppe D: Programmoberfläche"
 author:
   - Team 1 – Gruppe D
-version: "1.1"
+version: "1.2"
 lang: de-DE
 toc: true
 toc-depth: 3
@@ -22,7 +22,7 @@ header-includes: |
   \fancyhf{}
   \fancyhead[L]{Team 1 – Gruppe D}
   \fancyhead[C]{Pflichtenheft}
-  \fancyhead[R]{Version 1.1}
+  \fancyhead[R]{Version 1.2}
   \fancyfoot[C]{\thepage\ /\ \pageref{LastPage}}
   \renewcommand{\headrulewidth}{0.4pt}
   \renewcommand{\footrulewidth}{0pt}
@@ -39,7 +39,7 @@ header-includes: |
 +-----------------------------+-------------------------+-------------------------+
 | Gruppe D (Oberfläche)       | Modulverantwortlicher   | Modulverantwortlicher   |
 +-----------------------------+-------------------------+-------------------------+
-| 13.06.2026                  | 13.06.2026              | 13.06.2026              |
+| 24.06.2026                  | 24.06.2026              | 24.06.2026              |
 +-----------------------------+-------------------------+-------------------------+
 
 **Freigabevermerk:** Dieses Dokument ist nach Prüfung und Freigabe durch den
@@ -52,6 +52,7 @@ und den Modultest der Komponente *Programmoberfläche*.
 |---------|------------|----------------------------------------------|---------------------|
 | 1.0     | 10.06.2026 | Mirkan Güngör, Moritz König, Mohammed Bouhki | Initiale Erstellung |
 | 1.1     | 13.06.2026 | Mirkan Güngör, Moritz König, Mohammed Bouhki | Einfügen der UML-Diagramme und Aktualisierung der Referenzen |
+| 1.2     | 24.06.2026 | Mirkan Güngör, Moritz König, Mohammed Bouhki | Überarbeitung nach Prüferfeedback: Referenzen, Abgrenzung und Klassendiagramm |
 
 \newpage
 
@@ -104,7 +105,6 @@ Kapitel 11.
 - Pflichtenheft Gruppe A „Prozess / Dokumentenzyklus", Version 1.1, 13.06.2026
 - Pflichtenheft Gruppe B „Verwaltung von Produkten", Version 1.0, 10.06.2026
 - Pflichtenheft Gruppe C „Verwaltung von Kunden", Version 1.0, 10.06.2026
-- Vorlesungsunterlagen Software Engineering 1 (SoSe 2026), Foliensatz „Lasten- und Pflichtenheft"
 
 ---
 
@@ -122,39 +122,22 @@ Das GUI-Framework wird gemäß dem im Project Charter dokumentierten Technologie
 gewählt; dieses Pflichtenheft spezifiziert die Oberfläche framework-neutral, die
 Controller-Logik jedoch bereits mit Java-Typen (Kapitel 6).
 
-### 2.2 Abgrenzung (Was gehört dazu / was nicht)
+### 2.2 Abgrenzung der Komponente
 **Im Umfang dieser Komponente:**
 
 - Hauptfenster mit Navigation zu den Modulen Kunden, Produkte und Dokumente
-- Listen-, Such- und Formularansichten für Kunden (Gruppe C) und Produkte (Gruppe B)
+- Listen-, Such- und Formularansichten für Kunden und Produkte
-- Dokumentliste mit Statusanzeige und Belegaktionen (PDF-Export, Druck, E-Mail) der Gruppe A
+- Dokumentliste mit Statusanzeige und Belegaktionen (PDF-Export, Druck, E-Mail)
 - Geführte Rechnungserstellung als Wizard mit 5 Schritten inkl. Zusammenfassung (BA-13, UI-Sicht)
 - Stornierung einer Rechnung mit Bestätigungsdialog (BA-14, UI-Sicht)
 - Einheitliche Pflichtfeld-Markierung, Fehler- und Erfolgsmeldungen (Q-09)
 - Startverhalten der Anwendung (Q-04)
 
-**Nicht im Umfang dieser Komponente:**
-
-- Fachlogik des Dokumentenzyklus: Belegerzeugung, Summenberechnung, Nummernvergabe,
-  Statusführung, Storno-Logik, PDF-Erzeugung (Gruppe A)
-- Fachlogik und Persistenz der Stammdaten: Validierungsregeln, Nummernvergabe,
-  Löschsperren (Gruppen B und C)
-- E-Rechnungsformate, Mahnwesen, Buchhaltung, mobile Clients (LH-Nichtziele)
-
 ### 2.3 Grobe Systemfunktionen
 Anwendung starten → Hauptfenster anzeigen → Modul wählen → Liste/Suche anzeigen →
 Formular oder Wizard bedienen → Eingaben an die Fachkomponenten delegieren → Ergebnis,
 Fehler- oder Erfolgsmeldung anzeigen.
 
-### 2.4 UML-Bezug
-Ein gemeinsames Use-Case-Diagramm aller Gruppen gibt den Überblick über die Akteure und
-Ziele. Die für Gruppe D relevanten Use Cases sind: *Rechnung erstellen (geführt)* und
-*Rechnung stornieren* (jeweils Dialogführung) sowie der Bedienzugang zu allen Use Cases
-der Gruppen A–C. Die detaillierte logische Architektur dieser Komponente folgt in
-Kapitel 7.
-
----
-
 ## 3. Stakeholder und Kontext
 Stakeholder und Systemkontext sind im Lastenheft (§ 2, § 3) beschrieben und gelten
 unverändert. Für diese Komponente ist der maßgebliche Akteur:
@@ -171,10 +154,11 @@ Drucker und Standard-E-Mail-Client (optional).
 
 ## 4. Funktionale Anforderungen
 
-Die Anforderungen sind nach Oberflächenbereichen gruppiert und mit den Satzschablonen des
+Die Anforderungen sind nach Oberflächenbereichen gruppiert und mit einheitlichen
-Foliensatzes formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei und
+Satzschablonen formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei
-verifizierbar. Alle fachlichen Operationen werden an die Komponenten A–C delegiert; die
+und verifizierbar. Alle fachlichen Operationen werden an die Komponenten A–C delegiert;
-Anforderungen dieses Kapitels betreffen ausschließlich Darstellung und Dialogführung.
+die Anforderungen dieses Kapitels betreffen ausschließlich Darstellung und
+Dialogführung.
 
 ### 4.1 Hauptfenster und Navigation
 
@@ -336,6 +320,8 @@ skizziert:**
 
 Hinweis: `PositionsEingabe` ist das UI-interne Modell der Gruppe D und wird im
 Controller vor dem Aufruf der Gruppe-A-Schnittstelle in `Positionsangabe` umgewandelt.
+Die Java-nahen Signaturen konkretisieren Datentypen und Operationen für die in Kapitel 10
+beschriebenen JUnit-Tests; sie legen keine konkrete Implementierung der Dienste fest.
 
 ```java
 // Gruppe A — Dokumentenzyklus (genutzt von F-06 bis F-15)
@@ -383,24 +369,26 @@ von GUI-Framework-Klassen und damit im Modultest ohne Oberfläche prüfbar.
 
 ### 7.1 Klassendiagramm
 
-![UML-Klassendiagramm Programmoberfläche (Gruppe D)](diagramme/klassendiagramm_programmoberflaeche.png)
+![UML-Klassendiagramm Programmoberfläche (Gruppe D)](../diagramme/klassendiagramm_programmoberflaeche.png)
 
 **Beschreibung zu Abbildung 1:** Das Klassendiagramm zeigt die View- und Controller-Schicht
-der Oberfläche. Das `HauptFenster` (ein `JFrame`) verwaltet die Navigation (F-01, F-02): es
+der Oberfläche. Das `HauptFenster` (ein `JFrame`) enthält jeweils genau eine Kunden-,
-nimmt die drei Modulansichten (`KundenPanel`, `ProduktPanel`, `DokumentListenPanel`)
+Produkt- und Dokumentansicht und schaltet diese über ein `CardLayout` um (F-01, F-02).
-entgegen und schaltet sie über ein `CardLayout` um. Der `StammdatenController` bedient
+Der `StammdatenController` bedient die Ansichten für Kunden und Produkte und nutzt die
-Listen-, Such- und Formularansichten für Kunden und Produkte und nutzt dazu `KundenService`
+Schnittstellen `KundenService` und `ProduktService`. Der `RechnungsWizardController` führt
-(Gruppe C) und `ProduktService` (Gruppe B). Der `RechnungsWizardController` führt die
+die Schrittfolge des Enums `WizardSchritt` über das `RechnungsWizardModel` und delegiert
-Schrittfolge des Enums `WizardSchritt` über das `RechnungsWizardModel` (Komposition) und
+Summenberechnung und Speicherung an den `DokumentService`. Der
-delegiert das Speichern an den `DokumentService` (Gruppe A). Der `DokumentListenController`
+`DokumentListenController` stellt die Dokumentliste mit Statusfilter dar und bietet die
-stellt die Dokumentliste mit Statusfilter dar und bietet die Belegaktionen an (F-06–F-08,
+Belegaktionen an (F-06–F-08, F-14, F-15). Die drei Service-Schnittstellen werden durch die
-F-14, F-15). Die Modulansichten abonnieren den gemeinsamen `EreignisBus` (Observer-Muster)
+im Diagramm gezeigten Fachkomponenten `StandardDokumentService`,
-und aktualisieren sich nach Datenänderungen selbsttätig. Fehler- und Erfolgsmeldungen werden
+`KundenVerwaltungsService` und `ProduktVerwaltungsService` realisiert. Die Modulansichten
-einheitlich über die Klasse `Meldung` dargestellt (F-16, F-17).
+abonnieren den gemeinsamen `EreignisBus` und aktualisieren sich nach Datenänderungen.
+Fehler- und Erfolgsmeldungen werden einheitlich über die Klasse `Meldung` dargestellt
+(F-16, F-17).
 
 ### 7.2 Sequenzdiagramm
 
-![UML-Sequenzdiagramm Rechnungserstellung (Gruppe D)](diagramme/sequenz_rechnungserstellung_wizard_gruppeD.png)
+![UML-Sequenzdiagramm Rechnungserstellung (Gruppe D)](../diagramme/sequenz_rechnungserstellung_wizard_gruppeD.png)
 
 **Beschreibung zu Abbildung 2:** Das Sequenzdiagramm stellt die Dialogfolge *geführte
 Rechnungserstellung* dar. Die Anwender:in startet den Wizard; der
@@ -499,22 +487,97 @@ die Service-Schnittstellen der Gruppen A–C werden durch Stubs/Mocks ersetzt. D
 Usability-Nachweise (NF-USE-01/02) erfolgen ergänzend durch manuelle Usability-Tests
 (Kapitel 8) und sind nicht Teil des automatisierten Modultests.
 
-| TC    | Abgedeckte PH-Anf. | Vorbedingung | Eingabe | Erwartetes Ergebnis |
+**TC-01 — Wizard startet im ersten Schritt**
-|-------|--------------------|--------------|---------|---------------------|
+Abgedeckte PH-Anforderung: F-09.
-| TC-01 | F-09               | Wizard neu gestartet | `aktuellerSchritt` lesen | `KUNDE_WAEHLEN` (erster Schritt) |
+Vorbedingung: Wizard neu gestartet.
-| TC-02 | F-09               | Schritt 1 mit gewähltem Kunden | `weiter()` 4-mal mit gültigen Eingaben | Schrittfolge: `POSITIONEN_ERFASSEN` → `DATEN_BESTAETIGEN` → `ZUSAMMENFASSUNG` → `SPEICHERN` |
+Eingabe: `aktuellerSchritt` lesen.
-| TC-03 | F-10               | Schritt 1, kein Kunde gewählt (`kundenNr = null`) | `weiter()` | Wechsel verhindert; `Meldung(FEHLER, "Kunde", …)` erzeugt |
+Erwartetes Ergebnis: `KUNDE_WAEHLEN` ist der erste Schritt.
-| TC-04 | F-10               | Schritt 2, leere Positionsliste | `weiter()` | Wechsel verhindert; Meldung benennt „Position" |
+
-| TC-05 | F-10               | Schritt 2, Position mit `menge = 0` | `weiter()` | Wechsel verhindert; Meldung benennt „Menge" |
+**TC-02 — Vollständige Schrittfolge**
-| TC-06 | F-11               | Schritt 3 erreicht; Kunde `K-000017`, 1 Position erfasst | `zurueck()` bis Schritt 1 | `kundenNr` und `positionen` unverändert erhalten |
+Abgedeckte PH-Anforderung: F-09.
-| TC-07 | F-12               | Schritt 4; Stub `DokumentService` liefert Summen 200.00/38.00/238.00 | Zusammenfassung erzeugen | Zusammenfassung enthält Kunde, Positionen, Mengen, 200.00/38.00/238.00, Rechnungsdatum, Zahlungsziel |
+Vorbedingung: Schritt 1 mit gewähltem Kunden.
-| TC-08 | F-13               | Schritt 5; gültiges Modell | `speichern()` | genau **ein** Aufruf `erstelleRechnung(...)` am Mock; Erfolgsmeldung enthält gelieferte Rechnungsnummer |
+Eingabe: `weiter()` viermal mit gültigen Eingaben.
-| TC-09 | F-13 (Fehlerfall)  | Stub `erstelleRechnung` wirft Validierungsfehler „Rechnungsdatum" | `speichern()` | keine Erfolgsmeldung; `Meldung(FEHLER, "Rechnungsdatum", …)` dargestellt (F-05/F-16) |
+Erwartetes Ergebnis: Schrittfolge `POSITIONEN_ERFASSEN` -> `DATEN_BESTAETIGEN` ->
-| TC-10 | F-14               | Dokumentliste mit Rechnungen in `OFFEN`, `VERSENDET`, `STORNIERT` | verfügbare Aktionen je Rechnung ermitteln | *Stornieren* nur bei Status `OFFEN` aktiviert |
+`ZUSAMMENFASSUNG` -> `SPEICHERN`.
-| TC-11 | F-15               | Rechnung `R-2026-000124` im Status `OFFEN` | `storniere()` ohne Bestätigung; danach mit Bestätigung | ohne Bestätigung: kein Service-Aufruf; mit Bestätigung: genau ein Aufruf `storniere("R-2026-000124")` |
+
-| TC-12 | F-08               | Beleg im Status `VERSENDET` | Änderungsaktionen ermitteln | alle inhaltlichen Änderungsaktionen deaktiviert; PDF-Export aktiviert |
+**TC-03 — Wechsel ohne Kundenauswahl**
-| TC-13 | F-06               | Belege mit Status `OFFEN` (2×) und `STORNIERT` (1×) | Statusfilter `OFFEN` anwenden | Liste enthält genau die 2 offenen Belege |
+Abgedeckte PH-Anforderung: F-10.
-| TC-14 | F-03               | Stub `KundenService.suche("Muster")` liefert 1 Treffer | Suchbegriff „Muster" eingeben | Controller delegiert an `KundenService.suche(...)`; Trefferliste enthält genau diesen Kunden |
+Vorbedingung: Schritt 1, kein Kunde gewählt (`kundenNr = null`).
+Eingabe: `weiter()`.
+Erwartetes Ergebnis: Wechsel verhindert; `Meldung(FEHLER, "Kunde", ...)` erzeugt.
+
+**TC-04 — Wechsel ohne Position**
+Abgedeckte PH-Anforderung: F-10.
+Vorbedingung: Schritt 2, leere Positionsliste.
+Eingabe: `weiter()`.
+Erwartetes Ergebnis: Wechsel verhindert; Meldung benennt „Position".
+
+**TC-05 — Ungültige Positionsmenge**
+Abgedeckte PH-Anforderung: F-10.
+Vorbedingung: Schritt 2, Position mit `menge = 0`.
+Eingabe: `weiter()`.
+Erwartetes Ergebnis: Wechsel verhindert; Meldung benennt „Menge".
+
+**TC-06 — Zurück ohne Datenverlust**
+Abgedeckte PH-Anforderung: F-11.
+Vorbedingung: Schritt 3 erreicht; Kunde `K-000017`, eine Position erfasst.
+Eingabe: `zurueck()` bis Schritt 1.
+Erwartetes Ergebnis: `kundenNr` und `positionen` bleiben unverändert erhalten.
+
+**TC-07 — Zusammenfassung mit Summen**
+Abgedeckte PH-Anforderung: F-12.
+Vorbedingung: Schritt 4; Stub `DokumentService` liefert Summen
+200.00/38.00/238.00.
+Eingabe: Zusammenfassung erzeugen.
+Erwartetes Ergebnis: Zusammenfassung enthält Kunde, Positionen, Mengen,
+200.00/38.00/238.00, Rechnungsdatum und Zahlungsziel.
+
+**TC-08 — Rechnung speichern**
+Abgedeckte PH-Anforderung: F-13.
+Vorbedingung: Schritt 5; gültiges Modell.
+Eingabe: `speichern()`.
+Erwartetes Ergebnis: genau ein Aufruf `erstelleRechnung(...)` am Mock;
+Erfolgsmeldung enthält die gelieferte Rechnungsnummer.
+
+**TC-09 — Fachlicher Fehler beim Speichern**
+Abgedeckte PH-Anforderung: F-13 (Fehlerfall).
+Vorbedingung: Stub `erstelleRechnung` wirft Validierungsfehler „Rechnungsdatum".
+Eingabe: `speichern()`.
+Erwartetes Ergebnis: keine Erfolgsmeldung; `Meldung(FEHLER, "Rechnungsdatum", ...)`
+wird dargestellt (F-05/F-16).
+
+**TC-10 — Storno-Aktion nur für offene Rechnungen**
+Abgedeckte PH-Anforderung: F-14.
+Vorbedingung: Dokumentliste mit Rechnungen in `OFFEN`, `VERSENDET`, `STORNIERT`.
+Eingabe: verfügbare Aktionen je Rechnung ermitteln.
+Erwartetes Ergebnis: *Stornieren* ist nur bei Status `OFFEN` aktiviert.
+
+**TC-11 — Stornierung nur nach Bestätigung**
+Abgedeckte PH-Anforderung: F-15.
+Vorbedingung: Rechnung `R-2026-000124` im Status `OFFEN`.
+Eingabe: `storniere()` ohne Bestätigung; danach mit Bestätigung.
+Erwartetes Ergebnis: ohne Bestätigung kein Service-Aufruf; mit Bestätigung genau ein
+Aufruf `storniere("R-2026-000124")`.
+
+**TC-12 — Änderungsaktionen deaktivieren**
+Abgedeckte PH-Anforderung: F-08.
+Vorbedingung: Beleg im Status `VERSENDET`.
+Eingabe: Änderungsaktionen ermitteln.
+Erwartetes Ergebnis: alle inhaltlichen Änderungsaktionen deaktiviert; PDF-Export
+aktiviert.
+
+**TC-13 — Statusfilter der Dokumentliste**
+Abgedeckte PH-Anforderung: F-06.
+Vorbedingung: Belege mit Status `OFFEN` (2x) und `STORNIERT` (1x).
+Eingabe: Statusfilter `OFFEN` anwenden.
+Erwartetes Ergebnis: Liste enthält genau die zwei offenen Belege.
+
+**TC-14 — Stammdatensuche delegieren**
+Abgedeckte PH-Anforderung: F-03.
+Vorbedingung: Stub `KundenService.suche("Muster")` liefert einen Treffer.
+Eingabe: Suchbegriff „Muster" eingeben.
+Erwartetes Ergebnis: Controller delegiert an `KundenService.suche(...)`;
+Trefferliste enthält genau diesen Kunden.
 
 Damit sind 14 Testfälle (> 10) spezifiziert, die alle funktionalen Kernregeln der
 Dialogführung (F-09–F-15) sowie die übergreifenden Darstellungsregeln (F-03, F-06, F-08,

dokumentation/diagramme/klassendiagramm_programmoberflaeche.puml

@@ -10,11 +10,6 @@ package "gui" {
     - wechsleZu(String)
   }
 
-  interface ModulPanel {
-    + aktualisiere()
-    + hatUngespeicherteAenderungen() : boolean
-  }
-
   class KundenPanel
   class ProduktPanel
   class DokumentListenPanel
@@ -64,35 +59,44 @@ package "gui" {
   class PositionsEingabe
 }
 
-package "Schnittstellen Gruppen A-C" {
+package "Gruppe A: Dokumentenzyklus" {
   interface DokumentService
-  interface KundenService
+  class StandardDokumentService
+}
+
+package "Gruppe B: Produktverwaltung" {
   interface ProduktService
+  class ProduktVerwaltungsService
+}
+
+package "Gruppe C: Kundenverwaltung" {
+  interface KundenService
+  class KundenVerwaltungsService
 }
 
 package "gemeinsam" {
   class EreignisBus
 }
 
-ModulPanel <|.. KundenPanel
+HauptFenster "1" *-- "1" KundenPanel
-ModulPanel <|.. ProduktPanel
+HauptFenster "1" *-- "1" ProduktPanel
-ModulPanel <|.. DokumentListenPanel
+HauptFenster "1" *-- "1" DokumentListenPanel
-
-HauptFenster *-- KundenPanel
-HauptFenster *-- ProduktPanel
-HauptFenster *-- DokumentListenPanel
 
 KundenPanel --> StammdatenController
 ProduktPanel --> StammdatenController
 DokumentListenPanel --> DokumentListenController
 RechnungsWizardDialog --> RechnungsWizardController
 
-StammdatenController --> KundenService
+StammdatenController ..> KundenService : nutzt
-StammdatenController --> ProduktService
+StammdatenController ..> ProduktService : nutzt
-DokumentListenController --> DokumentService
+DokumentListenController ..> DokumentService : nutzt
-RechnungsWizardController --> DokumentService
+RechnungsWizardController ..> DokumentService : nutzt
-RechnungsWizardController --> KundenService
+RechnungsWizardController ..> KundenService : nutzt
-RechnungsWizardController --> ProduktService
+RechnungsWizardController ..> ProduktService : nutzt
+
+DokumentService <|.. StandardDokumentService
+ProduktService <|.. ProduktVerwaltungsService
+KundenService <|.. KundenVerwaltungsService
 
 RechnungsWizardController *-- RechnungsWizardModel
 RechnungsWizardModel --> WizardSchritt