diff --git a/dokumentation/anforderungen/Pflichtenheft_GruppeD.md b/dokumentation/anforderungen/Pflichtenheft_GruppeD.md index f0158e6..37ba2c3 100644 --- a/dokumentation/anforderungen/Pflichtenheft_GruppeD.md +++ b/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) -- Dokumentliste mit Statusanzeige und Belegaktionen (PDF-Export, Druck, E-Mail) der Gruppe A +- Listen-, Such- und Formularansichten für Kunden und Produkte +- 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 -Foliensatzes formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei und -verifizierbar. Alle fachlichen Operationen werden an die Komponenten A–C delegiert; die -Anforderungen dieses Kapitels betreffen ausschließlich Darstellung und Dialogführung. +Die Anforderungen sind nach Oberflächenbereichen gruppiert und mit einheitlichen +Satzschablonen formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei +und verifizierbar. Alle fachlichen Operationen werden an die Komponenten A–C delegiert; +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 -nimmt die drei Modulansichten (`KundenPanel`, `ProduktPanel`, `DokumentListenPanel`) -entgegen und schaltet sie über ein `CardLayout` um. Der `StammdatenController` bedient -Listen-, Such- und Formularansichten für Kunden und Produkte und nutzt dazu `KundenService` -(Gruppe C) und `ProduktService` (Gruppe B). Der `RechnungsWizardController` führt die -Schrittfolge des Enums `WizardSchritt` über das `RechnungsWizardModel` (Komposition) und -delegiert das Speichern an den `DokumentService` (Gruppe A). Der `DokumentListenController` -stellt die Dokumentliste mit Statusfilter dar und bietet die Belegaktionen an (F-06–F-08, -F-14, F-15). Die Modulansichten abonnieren den gemeinsamen `EreignisBus` (Observer-Muster) -und aktualisieren sich nach Datenänderungen selbsttätig. Fehler- und Erfolgsmeldungen werden -einheitlich über die Klasse `Meldung` dargestellt (F-16, F-17). +der Oberfläche. Das `HauptFenster` (ein `JFrame`) enthält jeweils genau eine Kunden-, +Produkt- und Dokumentansicht und schaltet diese über ein `CardLayout` um (F-01, F-02). +Der `StammdatenController` bedient die Ansichten für Kunden und Produkte und nutzt die +Schnittstellen `KundenService` und `ProduktService`. Der `RechnungsWizardController` führt +die Schrittfolge des Enums `WizardSchritt` über das `RechnungsWizardModel` und delegiert +Summenberechnung und Speicherung an den `DokumentService`. Der +`DokumentListenController` stellt die Dokumentliste mit Statusfilter dar und bietet die +Belegaktionen an (F-06–F-08, F-14, F-15). Die drei Service-Schnittstellen werden durch die +im Diagramm gezeigten Fachkomponenten `StandardDokumentService`, +`KundenVerwaltungsService` und `ProduktVerwaltungsService` realisiert. Die Modulansichten +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 | F-09 | Wizard neu gestartet | `aktuellerSchritt` lesen | `KUNDE_WAEHLEN` (erster Schritt) | -| TC-02 | F-09 | Schritt 1 mit gewähltem Kunden | `weiter()` 4-mal mit gültigen Eingaben | Schrittfolge: `POSITIONEN_ERFASSEN` → `DATEN_BESTAETIGEN` → `ZUSAMMENFASSUNG` → `SPEICHERN` | -| TC-03 | F-10 | Schritt 1, kein Kunde gewählt (`kundenNr = null`) | `weiter()` | Wechsel verhindert; `Meldung(FEHLER, "Kunde", …)` erzeugt | -| 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-06 | F-11 | Schritt 3 erreicht; Kunde `K-000017`, 1 Position erfasst | `zurueck()` bis Schritt 1 | `kundenNr` und `positionen` unverändert erhalten | -| 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 | -| TC-08 | F-13 | Schritt 5; gültiges Modell | `speichern()` | genau **ein** Aufruf `erstelleRechnung(...)` am Mock; Erfolgsmeldung enthält gelieferte Rechnungsnummer | -| TC-09 | F-13 (Fehlerfall) | Stub `erstelleRechnung` wirft Validierungsfehler „Rechnungsdatum" | `speichern()` | keine Erfolgsmeldung; `Meldung(FEHLER, "Rechnungsdatum", …)` dargestellt (F-05/F-16) | -| TC-10 | F-14 | Dokumentliste mit Rechnungen in `OFFEN`, `VERSENDET`, `STORNIERT` | verfügbare Aktionen je Rechnung ermitteln | *Stornieren* nur bei Status `OFFEN` aktiviert | -| 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-13 | F-06 | Belege mit Status `OFFEN` (2×) und `STORNIERT` (1×) | Statusfilter `OFFEN` anwenden | Liste enthält genau die 2 offenen Belege | -| 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 | +**TC-01 — Wizard startet im ersten Schritt** +Abgedeckte PH-Anforderung: F-09. +Vorbedingung: Wizard neu gestartet. +Eingabe: `aktuellerSchritt` lesen. +Erwartetes Ergebnis: `KUNDE_WAEHLEN` ist der erste Schritt. + +**TC-02 — Vollständige Schrittfolge** +Abgedeckte PH-Anforderung: F-09. +Vorbedingung: Schritt 1 mit gewähltem Kunden. +Eingabe: `weiter()` viermal mit gültigen Eingaben. +Erwartetes Ergebnis: Schrittfolge `POSITIONEN_ERFASSEN` -> `DATEN_BESTAETIGEN` -> +`ZUSAMMENFASSUNG` -> `SPEICHERN`. + +**TC-03 — Wechsel ohne Kundenauswahl** +Abgedeckte PH-Anforderung: F-10. +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, diff --git a/dokumentation/anforderungen/Pflichtenheft_GruppeD.pdf b/dokumentation/anforderungen/Pflichtenheft_GruppeD.pdf index fbe1b3b..c8b05c1 100644 Binary files a/dokumentation/anforderungen/Pflichtenheft_GruppeD.pdf and b/dokumentation/anforderungen/Pflichtenheft_GruppeD.pdf differ diff --git a/dokumentation/diagramme/klassendiagramm_programmoberflaeche.png b/dokumentation/diagramme/klassendiagramm_programmoberflaeche.png index 84a5512..778695f 100644 Binary files a/dokumentation/diagramme/klassendiagramm_programmoberflaeche.png and b/dokumentation/diagramme/klassendiagramm_programmoberflaeche.png differ diff --git a/dokumentation/diagramme/klassendiagramm_programmoberflaeche.puml b/dokumentation/diagramme/klassendiagramm_programmoberflaeche.puml index dc68a07..67ff4a9 100644 --- a/dokumentation/diagramme/klassendiagramm_programmoberflaeche.puml +++ b/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 -ModulPanel <|.. ProduktPanel -ModulPanel <|.. DokumentListenPanel - -HauptFenster *-- KundenPanel -HauptFenster *-- ProduktPanel -HauptFenster *-- DokumentListenPanel +HauptFenster "1" *-- "1" KundenPanel +HauptFenster "1" *-- "1" ProduktPanel +HauptFenster "1" *-- "1" DokumentListenPanel KundenPanel --> StammdatenController ProduktPanel --> StammdatenController DokumentListenPanel --> DokumentListenController RechnungsWizardDialog --> RechnungsWizardController -StammdatenController --> KundenService -StammdatenController --> ProduktService -DokumentListenController --> DokumentService -RechnungsWizardController --> DokumentService -RechnungsWizardController --> KundenService -RechnungsWizardController --> ProduktService +StammdatenController ..> KundenService : nutzt +StammdatenController ..> ProduktService : nutzt +DokumentListenController ..> DokumentService : nutzt +RechnungsWizardController ..> DokumentService : nutzt +RechnungsWizardController ..> KundenService : nutzt +RechnungsWizardController ..> ProduktService : nutzt + +DokumentService <|.. StandardDokumentService +ProduktService <|.. ProduktVerwaltungsService +KundenService <|.. KundenVerwaltungsService RechnungsWizardController *-- RechnungsWizardModel RechnungsWizardModel --> WizardSchritt