Add UML sequence diagram for customer deletion with lock (GR-04)

This commit introduces a new PlantUML sequence diagram that illustrates the process of deleting a customer with a deletion lock, as specified in the requirements for Group C. The diagram details the interactions between the GUI, customer management service, reference check, repository, and event bus, including handling of deletion requests and associated exceptions.

dokumentation/anforderungen/Pflichtenheft_GruppeC.md

@@ -3,7 +3,7 @@ title: "Pflichtenheft"
 subtitle: "Desktop-Fakturierungsanwendung — Gruppe C: Verwaltung von Kunden"
 author:
   - Team 1 – Gruppe C
-version: "1.0"
+version: "1.1"
 lang: de-DE
 toc: true
 toc-depth: 3
@@ -22,10 +22,17 @@ header-includes: |
   \fancyhf{}
   \fancyhead[L]{Team 1 – Gruppe C}
   \fancyhead[C]{Pflichtenheft}
-  \fancyhead[R]{Version 1.0}
+  \fancyhead[R]{Version 1.1}
   \fancyfoot[C]{\thepage\ /\ \pageref{LastPage}}
   \renewcommand{\headrulewidth}{0.4pt}
   \renewcommand{\footrulewidth}{0pt}
+  \makeatletter
+  \def\brk@scan#1{\ifx\brk@end#1\else#1\allowbreak\expandafter\brk@scan\fi}
+  \newcommand{\brk}[1]{\brk@scan#1\brk@end}
+  \let\origtexttt\texttt
+  \renewcommand{\texttt}[1]{\origtexttt{\brk{#1}}}
+  \makeatother
+  \AtBeginEnvironment{longtable}{\small}
 ---
 
 \newpage
@@ -51,6 +58,7 @@ und den Modultest der Komponente *Verwaltung von Kunden*.
 | Version | Datum      | Autor                                      | Grund der Änderung  |
 |---------|------------|--------------------------------------------|---------------------|
 | 1.0     | 10.06.2026 | Mahsuna Ahadyar, Kübra Kilic, Mara Weidmann | Initiale Erstellung |
+| 1.1     | 25.06.2026 | Mahsuna Ahadyar, Kübra Kilic, Mara Weidmann | Einarbeitung Modulleiter-Feedback: Referenzen bereinigt, Abgrenzung gestrafft, UML-Bezug entfernt, Kundennummern-Hinweis als Erläuterung gekennzeichnet, Schnittstellen fachlich beschrieben, UML-Diagramme ergänzt |
 
 \newpage
 
@@ -100,9 +108,6 @@ siehe Kapitel 11.
 - Pflichtenheft Gruppe A „Prozess / Dokumentenzyklus", Version 1.0, 09.06.2026
 - DSGVO — EU-Verordnung 2016/679 (personenbezogene Kundendaten)
 - GoBD — Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern
-- Vorlesungsunterlagen Software Engineering 1 (SoSe 2026), Foliensatz „Lasten- und Pflichtenheft"
-
----
 
 ## 2. Systemüberblick
 
@@ -131,23 +136,12 @@ der Export der Kundenstammdaten in einem offenen Format.
 
 **Nicht im Umfang dieser Komponente:**
 
-- Erstellung und Statusführung von Belegen, Übernahme der Kundendaten in Belege (Gruppe A)
-- Verwaltung von Produkten (Gruppe B)
-- Aufbau und Layout der GUI (Gruppe D)
 - Mahnwesen, Buchhaltung, Kundenportale (LH-Nichtziele)
 
 ### 2.3 Grobe Systemfunktionen
 Erfassen eines Kunden → Validieren der Eingaben → Vergeben der Kundennummer →
 Persistieren → Suchen/Auflisten → Ändern → Löschen (mit Referenzprüfung, GR-04) → Export.
 
-### 2.4 UML-Bezug
-Ein gemeinsames Use-Case-Diagramm aller Gruppen gibt den Überblick über die Akteure und
-Ziele. Die für Gruppe C relevanten Use Cases sind: *Kunde anlegen*, *Kundendaten ändern*,
-*Kunde löschen* und *Kunden suchen und auflisten*. 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:
@@ -160,22 +154,21 @@ intern die Komponenten Dokumentenzyklus (A, lesender Konsument der Kundendaten)
 Programmoberfläche (D). Da Kundendaten **personenbezogene Daten** im Sinne der DSGVO
 sind, gilt die lokale Datenhaltung (Q-06) für diese Komponente in besonderem Maße.
 
----
-
 ## 4. Funktionale Anforderungen
 
 Die Anforderungen sind nach CRUD-Operationen gruppiert und mit den Satzschablonen des
 Foliensatzes formuliert. Jede Anforderung ist eindeutig, vollständig, widerspruchsfrei und
 verifizierbar.
 
-> **Kundennummern (übergreifend):** Kundennummern sind **eindeutig** und werden
+> **Hinweis (Erläuterung, keine eigenständige Anforderung) — Kundennummern:** Dieser
-> **vom System generiert** (nicht durch den Anwender eingegeben). Sie werden als
+> Kasten erläutert das gemeinsame Verständnis der Kundennummern; die **bindenden
-> `String` geführt, **nicht** als `int`, weil die Nummern ein festes Format mit
+> Anforderungen** sind **F-02** (Vergabe einer eindeutigen, vom System generierten,
-> Präfix und führenden Nullen besitzen (z. B. `K-000017`); ein ganzzahliger Typ
+> fortlaufenden Nummer mit Präfix `K-` und führenden Nullen, z. B. `K-000017`) sowie
-> würde führende Nullen verlieren. Die Nummer wird fortlaufend auf Basis der höchsten
+> **F-07** (Unveränderlichkeit nach der Vergabe). Die Nummer wird auf Basis der höchsten
-> bisher vergebenen Nummer ermittelt und ist nach der Vergabe **unveränderlich**.
+> bisher vergebenen Nummer ermittelt; anders als bei Rechnungsnummern (GR-01, Gruppe A)
-> Anders als bei Rechnungsnummern (GR-01, Gruppe A) besteht keine
+> besteht **keine** Lückenlosigkeits-Pflicht. Zur Begründung der Führung als `String`
-> Lückenlosigkeits-Pflicht.
+> (statt `int`, wegen Präfix und führender Nullen) siehe die Designgrundsätze in
+> Kapitel 6.1.
 
 ### 4.1 Kunde anlegen (aus BA-01)
 
@@ -243,8 +236,6 @@ Nummer, MUSS `null` zurückgegeben werden.
 alle Kundenstammdaten vollständig in ein offenes, dokumentiertes Format (CSV, UTF-8,
 Semikolon-getrennt, mit Kopfzeile) in das lokale Dateisystem zu exportieren.
 
----
-
 ## 5. Nicht-funktionale Anforderungen
 
 **NF-PERF-01 (aus Q-01/Q-02):** Das System MUSS Such- und Auflistungsergebnisse der
@@ -265,8 +256,6 @@ Kundendaten ausschließlich lokal auf dem Anwender-PC ablegen; eine Übertragung
 Dienste findet NICHT statt (Nachweis durch Netzwerk-Monitoring während eines
 repräsentativen Nutzungslaufs).
 
----
-
 ## 6. Daten und Schnittstellen
 
 Dieses Kapitel ist direkter Input für den Modultestplan (Kapitel 10). Datentypen werden
@@ -299,57 +288,62 @@ bereits als Java-Typen angegeben.
 
 **Externe Schnittstellen:**
 
-| ID    | Schnittstelle             | Zweck |
+| ID    | Schnittstelle       | Zweck |
-|-------|---------------------------|-------|
+|-------|---------------------|-------|
-| IF-01 | Lokales Dateisystem       | Persistenz der Kundenstammdaten |
+| IF-01 | Lokales Dateisystem | Persistenz der Kundenstammdaten |
-| IF-04 | Datenexport-Schnittstelle | Export der Kundenstammdaten als CSV (F-15, Q-08) |
+| IF-04 | Datenexport (CSV)   | Export der Kundenstammdaten als CSV (F-15, Q-08) |
 
-**Interne Schnittstellen (zu anderen Komponenten), als Java-Interfaces skizziert:**
+**Anforderungen an die externen Schnittstellen**
 
-```java
+**IF-01:** Das System MUSS eine Schnittstelle zum lokalen Dateisystem bereitstellen, die es
-// Von Gruppe C IMPLEMENTIERT, von Gruppe A genutzt (lesender Zugriff)
+ERMÖGLICHT, die Kundenstammdaten dauerhaft zu speichern und wieder zu laden.
-public interface KundenService {
-    Kunde findeKunde(String kundennummer);   // null, wenn nicht vorhanden
-}
 
-// Von Gruppe A BEREITGESTELLT, von Gruppe C genutzt (Löschsperre GR-04, F-10)
+**IF-04:** Das System MUSS eine Export-Schnittstelle bereitstellen, die es der Anwender:in
-public interface KundenReferenzPruefung {
+ERMÖGLICHT, alle Kundenstammdaten in einem offenen Format (CSV, UTF-8, Semikolon-getrennt,
-    // Anzahl aktiver und archivierter Dokumente, die den Kunden referenzieren
+mit Kopfzeile) in das lokale Dateisystem zu exportieren (F-15, Q-08).
-    int anzahlVerknuepfterDokumente(String kundennummer);
-}
-```
 
-**Komponenteninterne Dienste:**
+**Interne Schnittstellen:** Die Schnittstellen werden hier **fachlich** beschrieben (Zweck,
+ausgetauschte Daten, Richtung); konkrete Methodensignaturen und Datentypen sind dem
+Komponentenentwurf bzw. dem Modultestplan (Kapitel 10) vorbehalten.
 
-```java
+*Genutzte Schnittstellen (Komponente C ruft auf):*
-public interface KundennummernGenerator {
-    // liefert die nächste fortlaufende Kundennummer, z. B. "K-000017"
-    String naechsteNummer();
-}
 
-public interface KundenRepository {
+| Schnittstelle          | Partner  | Richtung | Fachlicher Zweck |
-    Kunde speichere(Kunde kunde);
+|------------------------|----------|----------|------------------|
-    void loesche(String kundennummer);
+| Referenzprüfung Kunden | Gruppe A | A → C    | Anzahl aktiver und archivierter Belege, die einen Kunden referenzieren (Löschsperre GR-04, F-09/F-10) |
-    List<Kunde> alleSortiertNachName();
-    List<Kunde> suche(String suchbegriff);   // Name ODER Kundennummer
-}
-```
 
-> IF-Satzschablone (Beispiel IF-04): *Das System MUSS eine Export-Schnittstelle
+*Bereitgestellte Schnittstellen (Komponente C wird aufgerufen):*
-> bereitstellen, die es der Anwender:in ERMÖGLICHT, alle Kundenstammdaten als
-> CSV-Datei (UTF-8, Semikolon-getrennt) in das lokale Dateisystem
-> (`java.nio.file.Path`) zu exportieren.*
 
----
+| Schnittstelle          | Partner     | Richtung     | Fachlicher Zweck |
+|------------------------|-------------|--------------|------------------|
+| Kundenzugriff (lesend) | Gruppe A, D | C → A, C → D | Kunde per Kundennummer abrufen (F-14); Kundensuche über Name oder Kundennummer (F-12) |
+
+> Liefert die Kundenabfrage keinen Treffer, wird dies dem Aufrufer eindeutig signalisiert
+> (die Abfrage per Kundennummer liefert „kein Treffer").
+
+**Komponenteninterne Dienste (rein C-intern, fachlich beschrieben):**
+
+- **Kundennummernvergabe (F-02):** liefert die nächste fortlaufende Kundennummer im festen
+  Format mit Präfix und führenden Nullen (z. B. `K-000017`) auf Basis der höchsten bisher
+  vergebenen Nummer; ohne Lückenlosigkeits-Pflicht. (Realisierung: `EinfacherKundennummernGenerator`)
+- **Kundenpersistenz (IF-01):** speichert Kunden im lokalen Dateisystem und liefert einen
+  Kunden zur Kundennummer, alle Kunden sortiert nach Name sowie Suchergebnisse (Name/Nr.).
+  (Realisierung: `JsonKundenRepository`, JSON-Ablage)
+- **Datenexport (IF-04):** exportiert alle Kundenstammdaten als CSV in das lokale Dateisystem
+  (F-15). (Realisierung: `KundenCsvExport`)
+- **Ereignisbenachrichtigung (Observer, Paket `gemeinsam`):** meldet Datenänderungen am
+  Kundenbestand (`melde(DatenBereich.KUNDEN)`) an die abonnierten Modulansichten (Gruppe D).
 
 ## 7. Systemarchitektur (logisch, grob)
 
 Die Komponente folgt einer einfachen Schichtung: die GUI (Gruppe D) ruft den
 `KundenVerwaltungsService` auf, der die Fachlogik (Validierung, Nummernvergabe,
 Löschsperre GR-04) kapselt und die Dienste `KundennummernGenerator`, `KundenRepository`
-und `KundenReferenzPruefung` (Gruppe A) nutzt. Gegenüber Gruppe A implementiert die
+und `KundenReferenzPruefung` (Gruppe A) nutzt. Gegenüber Gruppe A implementiert die Klasse
-Komponente das Interface `KundenService`. Kunden werden über das `KundenRepository` im
+`KundenVerwaltungsService` das Interface `KundenService`. Kunden werden über das
-lokalen Dateisystem persistiert (realisiert als JSON-Ablage). Nach jeder schreibenden
+`KundenRepository` (konkrete Implementierung `JsonKundenRepository`) im lokalen Dateisystem
+persistiert (JSON-Ablage); die fortlaufenden Kundennummern erzeugt der
+`EinfacherKundennummernGenerator` (Implementierung von `KundennummernGenerator`). Nach jeder schreibenden
 Operation (Anlegen, Ändern, Löschen) meldet der `KundenVerwaltungsService` die Änderung
 über einen **`EreignisBus`** (Observer-Muster, Paket `gemeinsam`;
 `melde(DatenBereich.KUNDEN)`), den die Kundenansicht der Gruppe D abonniert und sich
@@ -357,37 +351,38 @@ daraufhin automatisch aktualisiert.
 
 ### 7.1 Klassendiagramm
 
-<!-- TODO: UML-Klassendiagramm hier einfügen (Abbildung 1) -->
-
-![Abbildung 1: UML-Klassendiagramm Kundenverwaltung (Gruppe C)]
-
 **Beschreibung zu Abbildung 1:** Das Klassendiagramm zeigt die Entitätsklasse `Kunde`
-mit ihren Attributen (Kapitel 6.1). Der `KundenVerwaltungsService` orchestriert Anlegen,
+mit ihren Attributen (Kapitel 6.1). Die Klasse `KundenVerwaltungsService` orchestriert
-Ändern, Löschen und Suche: er nutzt den `KundennummernGenerator` (Vergabe eindeutiger
+Anlegen, Ändern, Löschen und Suche und **realisiert** das Interface `KundenService`
-Kundennummern, F-02), das `KundenRepository` (Persistenz, IF-01) und die von Gruppe A
+(lesender Zugriff für Gruppe A und D, F-14). Die komponenteninternen Interfaces besitzen
-bereitgestellte Schnittstelle `KundenReferenzPruefung` (Löschsperre GR-04, F-09/F-10).
+jeweils eine **konkrete Implementierung**: `JsonKundenRepository` realisiert
-Zusätzlich realisiert der `KundenVerwaltungsService` das Interface `KundenService`
+`KundenRepository` (Persistenz, IF-01) und `EinfacherKundennummernGenerator` realisiert
-(lesender Zugriff für Gruppe A, F-14) und meldet Datenänderungen über den `EreignisBus`
+`KundennummernGenerator` (Vergabe eindeutiger Kundennummern, F-02). Die Schnittstelle
-(Observer-Muster) an die abonnierte Kundenansicht der Gruppe D. Dokumente (Gruppe A)
+`KundenReferenzPruefung` (Löschsperre GR-04, F-09/F-10) wird **von Gruppe A bereitgestellt**
-referenzieren einen `Kunde` ausschließlich über die Kundennummer (lose Kopplung).
+und ist daher als extern dargestellt (ihre Implementierung liegt in Gruppe A). Der
+`KundenVerwaltungsService` **nutzt** diese Dienste sowie den `EreignisBus` (Observer-Muster)
+und meldet Datenänderungen an die abonnierte Kundenansicht der Gruppe D. Der Zugriff auf
+`Kunde` ist eine **Nutzungs-/Abhängigkeitsbeziehung** — das `KundenRepository` liefert und
+speichert `Kunde`-Objekte —, **keine** 1:n-Aggregation oder -Komposition; ein Interface
+hält somit keinen „Container" von Entitäten. Dokumente (Gruppe A) referenzieren einen
+`Kunde` ausschließlich über die Kundennummer (lose Kopplung).
+
+![UML-Klassendiagramm Kundenverwaltung (Gruppe C)](diagramme/klassendiagramm_kundenverwaltung_gruppeC.png)
 
 ### 7.2 Sequenzdiagramm
 
-<!-- TODO: UML-Sequenzdiagramm hier einfügen (Abbildung 2) -->
-
-![Abbildung 2: UML-Sequenzdiagramm „Kunde löschen mit Löschsperre (GR-04)" (Gruppe C)]
-
 **Beschreibung zu Abbildung 2:** Das Sequenzdiagramm stellt den Ablauf *Kunde löschen*
 dar. Die Anwender:in löst über die GUI (Gruppe D) `loescheKunde(kundennummer)` am
 `KundenVerwaltungsService` aus. Dieser ermittelt zuerst über
 `KundenReferenzPruefung.anzahlVerknuepfterDokumente(kundennummer)` (Gruppe A) die Anzahl
 der Dokumente, die den Kunden referenzieren. Ist die Anzahl größer als 0, wird der
 Löschvorgang abgelehnt und ein Hinweis mit der Anzahl der verknüpften Dokumente an die
-GUI zurückgegeben (F-09, GR-04). Ist die Anzahl 0, fordert das System die Bestätigung der
+GUI zurückgegeben (F-09, GR-04). Ist die Anzahl 0, löscht das System den Kunden nach
-Anwender:in an (F-08) und löscht den Kunden anschließend über
+Bestätigung der Anwender:in (F-08) über `KundenRepository.loesche(kundennummer)` dauerhaft
-`KundenRepository.loesche(kundennummer)` dauerhaft aus dem lokalen Datenbestand.
+aus dem lokalen Datenbestand und meldet die Änderung über den `EreignisBus`
+(`melde(DatenBereich.KUNDEN)`) an die abonnierte Kundenansicht der Gruppe D.
 
----
+![UML-Sequenzdiagramm „Kunde löschen mit Löschsperre (GR-04)" (Gruppe C)](diagramme/sequenz_kunde_loeschen_gruppeC.png)
 
 ## 8. Testbare Abnahmekriterien
 
@@ -435,8 +430,6 @@ Erwartet: Eine CSV-Datei (UTF-8, Semikolon-getrennt, mit Kopfzeile) mit allen Ku
 allen Attributen liegt im gewählten Zielordner; der Export dauert ≤ 30 Sekunden; das
 Monitoring zeigt keine Datenübertragung an externe Dienste.
 
----
-
 ## 9. Traceability LH ↔ PH
 
 Jede für Gruppe C relevante Lastenheft-Anforderung ist mindestens einer
@@ -461,8 +454,6 @@ Pflichtenheft-Anforderung zugeordnet.
 > Datenstand über `KundenService`. PZ-01 (CRUD-Verwaltung der Kundenstammdaten) wird
 > durch BA-01–BA-04 vollständig abgedeckt.
 
----
-
 ## 10. Modultestplan
 
 Die folgenden Testfälle sind deterministisch (feste Ein-/Ausgaben) und mit JUnit 5
@@ -470,7 +461,7 @@ umsetzbar. Die Schnittstelle `KundenReferenzPruefung` (Gruppe A) wird im Modulte
 einen Stub/Mock ersetzt.
 
 | TC    | Abgedeckte PH-Anf. | Vorbedingung | Eingabe | Erwartetes Ergebnis |
-|-------|--------------------|--------------|---------|---------------------|
+|---------|------------|------------------------|----------------------|----------------------------|
 | TC-01 | F-01, F-02         | Höchste Kundennummer `K-000016` | Kunde („Muster GmbH", „Hauptstr. 1", „68163", „Mannheim") speichern | Kunde persistiert; Kundennummer = `K-000017` |
 | TC-02 | F-02 (Format)      | Zähler = 7   | `naechsteNummer()` | liefert `K-000007` (führende Nullen, `String`) |
 | TC-03 | F-03, NF-USE-01    | Kunde ohne Ort | `speichere()` | Speichern abgelehnt; Validierungsfehler benennt „Ort" |
@@ -490,8 +481,6 @@ Damit sind 14 Testfälle (> 10) spezifiziert, die alle funktionalen Kernregeln (
 F-03, F-04, F-07, F-09, F-12, F-14, F-15) sowie die zentrale Geschäftsregel GR-04 und
 die Qualitätsvorgaben (Q-02, Q-08, Q-09) abdecken.
 
----
-
 ## 11. Anhänge
 
 ### 11.1 Abkürzungen

dokumentation/diagramme/klassendiagramm_kundenverwaltung_gruppeC.puml

@@ -0,0 +1,102 @@
+@startuml klassendiagramm_kundenverwaltung_gruppeC
+' UML-Klassendiagramm Kundenverwaltung (Pflichtenheft Gruppe C, Abschnitt 7.1)
+' Layout-Engine Smetana -> kein Graphviz erforderlich.
+!pragma layout smetana
+
+skinparam shadowing false
+skinparam classAttributeIconSize 0
+skinparam linetype ortho
+hide empty members
+
+title UML-Klassendiagramm — Kundenverwaltung (Gruppe C)
+
+' ===================== Domänenmodell =====================
+
+class Kunde {
+  - kundennummer : String
+  - name : String
+  - strasse : String
+  - plz : String
+  - ort : String
+  - eMail : String
+  - telefon : String
+  - ustIdNr : String
+  + anschrift() : String
+}
+
+' ===================== Service-Schicht =====================
+
+interface KundenService <<interface>> {
+  + findeKunde(kundennummer : String) : Kunde
+  + suche(suchbegriff : String) : List<Kunde>
+}
+
+class KundenVerwaltungsService {
+  + legeAn(kunde : Kunde) : Kunde
+  + aendere(kunde : Kunde) : Kunde
+  + loescheKunde(kundennummer : String)
+  + alleSortiertNachName() : List<Kunde>
+  + suche(suchbegriff : String) : List<Kunde>
+  + findeKunde(kundennummer : String) : Kunde
+}
+
+interface KundennummernGenerator <<interface>> {
+  + naechsteNummer() : String
+}
+
+class EinfacherKundennummernGenerator {
+  + naechsteNummer() : String
+}
+
+interface KundenRepository <<interface>> {
+  + speichere(kunde : Kunde) : Kunde
+  + loesche(kundennummer : String)
+  + findeNachNummer(kundennummer : String) : Kunde
+  + alleSortiertNachName() : List<Kunde>
+  + suche(suchbegriff : String) : List<Kunde>
+}
+
+class JsonKundenRepository {
+}
+
+class KundenCsvExport {
+  + exportiere(kunden : List<Kunde>, zielDatei : Path)
+}
+
+class EreignisBus {
+  + abonniere(bereich : DatenBereich, beobachter : Runnable)
+  + melde(bereich : DatenBereich)
+}
+
+enum DatenBereich {
+  KUNDEN
+  PRODUKTE
+  DOKUMENTE
+}
+
+' ===================== Externe Komponente (lose Kopplung) =====================
+
+interface KundenReferenzPruefung <<extern (Gruppe A)>> {
+  + anzahlVerknuepfterDokumente(kundennummer : String) : int
+}
+
+' ===================== Realisierungen (konkrete Implementierungen) =====================
+
+KundenService <|.. KundenVerwaltungsService
+KundenRepository <|.. JsonKundenRepository
+KundennummernGenerator <|.. EinfacherKundennummernGenerator
+
+' ===================== Nutzungs-/Abhängigkeitsbeziehungen =====================
+
+KundenVerwaltungsService ..> KundenRepository
+KundenVerwaltungsService ..> KundennummernGenerator
+KundenVerwaltungsService ..> KundenReferenzPruefung
+KundenVerwaltungsService ..> EreignisBus
+EreignisBus ..> DatenBereich
+
+' Zugriff auf Kunde = Abhängigkeit (liefert/speichert), KEIN 1:n-Container
+KundenVerwaltungsService ..> Kunde : verwaltet
+KundenRepository ..> Kunde : liefert / speichert
+KundenCsvExport ..> Kunde : exportiert
+
+@enduml

dokumentation/diagramme/sequenz_kunde_loeschen_gruppeC.puml

@@ -0,0 +1,43 @@
+@startuml sequenz_kunde_loeschen_gruppeC
+' UML-Sequenzdiagramm "Kunde löschen mit Löschsperre (GR-04)" (Pflichtenheft Gruppe C, Abschnitt 7.2)
+' Ablauf gemäß KundenVerwaltungsService.loescheKunde(kundennummer).
+
+skinparam shadowing false
+skinparam sequenceMessageAlign center
+hide footbox
+
+title UML-Sequenzdiagramm — „Kunde löschen mit Löschsperre (GR-04)" (Gruppe C)
+
+participant "GUI\n(Gruppe D)" as GUI
+participant "kundenService :\nKundenVerwaltungsService" as KVS
+participant "referenzPruefung :\nKundenReferenzPruefung\n(Gruppe A)" as RP
+participant "repository :\nKundenRepository" as REPO
+participant "ereignisBus :\nEreignisBus" as EB
+
+GUI -> KVS : loescheKunde(kundennummer)
+activate KVS
+
+KVS -> RP : anzahlVerknuepfterDokumente(kundennummer)
+activate RP
+RP --> KVS : anzahl
+deactivate RP
+
+alt anzahl > 0 (Löschsperre GR-04, F-09)
+  KVS --> GUI : LoeschAbgelehntException\n(Hinweis mit Anzahl verknüpfter Dokumente)
+else anzahl == 0
+  note over GUI, KVS : Bestätigungsabfrage der Anwender:in (F-08)
+  KVS -> REPO : loesche(kundennummer)
+  activate REPO
+  REPO --> KVS
+  deactivate REPO
+  KVS -> EB : melde(DatenBereich.KUNDEN)
+  activate EB
+  note right of EB : benachrichtigt die abonnierte\nKundenansicht (Observer-Muster)
+  EB --> KVS
+  deactivate EB
+  KVS --> GUI : Kunde gelöscht
+end
+
+deactivate KVS
+
+@enduml