Ueberarbeite Pflichtenheft Gruppe D nach Feedback

main
Mirkan Guengoer 2026-06-24 11:48:01 +02:00
parent 5bc65144b6
commit a2f9335449
4 changed files with 144 additions and 77 deletions

View File

@ -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 AC. 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 AC 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 AC 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-06F-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-06F-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 AC 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-09F-15) sowie die übergreifenden Darstellungsregeln (F-03, F-06, F-08,

Binary file not shown.

Before

Width:  |  Height:  |  Size: 137 KiB

After

Width:  |  Height:  |  Size: 144 KiB

View File

@ -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