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.main
parent
5bc65144b6
commit
412d7badbe
|
|
@ -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
|
||||
> **vom System generiert** (nicht durch den Anwender eingegeben). Sie werden als
|
||||
> `String` geführt, **nicht** als `int`, weil die Nummern ein festes Format mit
|
||||
> Präfix und führenden Nullen besitzen (z. B. `K-000017`); ein ganzzahliger Typ
|
||||
> würde führende Nullen verlieren. Die Nummer wird fortlaufend auf Basis der höchsten
|
||||
> bisher vergebenen Nummer ermittelt und ist nach der Vergabe **unveränderlich**.
|
||||
> Anders als bei Rechnungsnummern (GR-01, Gruppe A) besteht keine
|
||||
> Lückenlosigkeits-Pflicht.
|
||||
> **Hinweis (Erläuterung, keine eigenständige Anforderung) — Kundennummern:** Dieser
|
||||
> Kasten erläutert das gemeinsame Verständnis der Kundennummern; die **bindenden
|
||||
> Anforderungen** sind **F-02** (Vergabe einer eindeutigen, vom System generierten,
|
||||
> fortlaufenden Nummer mit Präfix `K-` und führenden Nullen, z. B. `K-000017`) sowie
|
||||
> **F-07** (Unveränderlichkeit nach der Vergabe). Die Nummer wird auf Basis der höchsten
|
||||
> bisher vergebenen Nummer ermittelt; anders als bei Rechnungsnummern (GR-01, Gruppe A)
|
||||
> besteht **keine** Lückenlosigkeits-Pflicht. Zur Begründung der Führung als `String`
|
||||
> (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 |
|
||||
|-------|---------------------------|-------|
|
||||
| IF-01 | Lokales Dateisystem | Persistenz der Kundenstammdaten |
|
||||
| IF-04 | Datenexport-Schnittstelle | Export der Kundenstammdaten als CSV (F-15, Q-08) |
|
||||
| ID | Schnittstelle | Zweck |
|
||||
|-------|---------------------|-------|
|
||||
| IF-01 | Lokales Dateisystem | Persistenz der Kundenstammdaten |
|
||||
| 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
|
||||
// Von Gruppe C IMPLEMENTIERT, von Gruppe A genutzt (lesender Zugriff)
|
||||
public interface KundenService {
|
||||
Kunde findeKunde(String kundennummer); // null, wenn nicht vorhanden
|
||||
}
|
||||
**IF-01:** Das System MUSS eine Schnittstelle zum lokalen Dateisystem bereitstellen, die es
|
||||
ERMÖGLICHT, die Kundenstammdaten dauerhaft zu speichern und wieder zu laden.
|
||||
|
||||
// Von Gruppe A BEREITGESTELLT, von Gruppe C genutzt (Löschsperre GR-04, F-10)
|
||||
public interface KundenReferenzPruefung {
|
||||
// Anzahl aktiver und archivierter Dokumente, die den Kunden referenzieren
|
||||
int anzahlVerknuepfterDokumente(String kundennummer);
|
||||
}
|
||||
```
|
||||
**IF-04:** Das System MUSS eine Export-Schnittstelle bereitstellen, die es der Anwender:in
|
||||
ERMÖGLICHT, alle Kundenstammdaten in einem offenen Format (CSV, UTF-8, Semikolon-getrennt,
|
||||
mit Kopfzeile) in das lokale Dateisystem zu exportieren (F-15, Q-08).
|
||||
|
||||
**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
|
||||
public interface KundennummernGenerator {
|
||||
// liefert die nächste fortlaufende Kundennummer, z. B. "K-000017"
|
||||
String naechsteNummer();
|
||||
}
|
||||
*Genutzte Schnittstellen (Komponente C ruft auf):*
|
||||
|
||||
public interface KundenRepository {
|
||||
Kunde speichere(Kunde kunde);
|
||||
void loesche(String kundennummer);
|
||||
List<Kunde> alleSortiertNachName();
|
||||
List<Kunde> suche(String suchbegriff); // Name ODER Kundennummer
|
||||
}
|
||||
```
|
||||
| Schnittstelle | Partner | Richtung | Fachlicher Zweck |
|
||||
|------------------------|----------|----------|------------------|
|
||||
| Referenzprüfung Kunden | Gruppe A | A → C | Anzahl aktiver und archivierter Belege, die einen Kunden referenzieren (Löschsperre GR-04, F-09/F-10) |
|
||||
|
||||
> IF-Satzschablone (Beispiel IF-04): *Das System MUSS eine Export-Schnittstelle
|
||||
> 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.*
|
||||
*Bereitgestellte Schnittstellen (Komponente C wird aufgerufen):*
|
||||
|
||||
---
|
||||
| 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
|
||||
Komponente das Interface `KundenService`. Kunden werden über das `KundenRepository` im
|
||||
lokalen Dateisystem persistiert (realisiert als JSON-Ablage). Nach jeder schreibenden
|
||||
und `KundenReferenzPruefung` (Gruppe A) nutzt. Gegenüber Gruppe A implementiert die Klasse
|
||||
`KundenVerwaltungsService` das Interface `KundenService`. Kunden werden über das
|
||||
`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,
|
||||
Ändern, Löschen und Suche: er nutzt den `KundennummernGenerator` (Vergabe eindeutiger
|
||||
Kundennummern, F-02), das `KundenRepository` (Persistenz, IF-01) und die von Gruppe A
|
||||
bereitgestellte Schnittstelle `KundenReferenzPruefung` (Löschsperre GR-04, F-09/F-10).
|
||||
Zusätzlich realisiert der `KundenVerwaltungsService` das Interface `KundenService`
|
||||
(lesender Zugriff für Gruppe A, F-14) und meldet Datenänderungen über den `EreignisBus`
|
||||
(Observer-Muster) an die abonnierte Kundenansicht der Gruppe D. Dokumente (Gruppe A)
|
||||
referenzieren einen `Kunde` ausschließlich über die Kundennummer (lose Kopplung).
|
||||
mit ihren Attributen (Kapitel 6.1). Die Klasse `KundenVerwaltungsService` orchestriert
|
||||
Anlegen, Ändern, Löschen und Suche und **realisiert** das Interface `KundenService`
|
||||
(lesender Zugriff für Gruppe A und D, F-14). Die komponenteninternen Interfaces besitzen
|
||||
jeweils eine **konkrete Implementierung**: `JsonKundenRepository` realisiert
|
||||
`KundenRepository` (Persistenz, IF-01) und `EinfacherKundennummernGenerator` realisiert
|
||||
`KundennummernGenerator` (Vergabe eindeutiger Kundennummern, F-02). Die Schnittstelle
|
||||
`KundenReferenzPruefung` (Löschsperre GR-04, F-09/F-10) wird **von Gruppe A bereitgestellt**
|
||||
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).
|
||||
|
||||
|
||||
|
||||
### 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
|
||||
Anwender:in an (F-08) und löscht den Kunden anschließend über
|
||||
`KundenRepository.loesche(kundennummer)` dauerhaft aus dem lokalen Datenbestand.
|
||||
GUI zurückgegeben (F-09, GR-04). Ist die Anzahl 0, löscht das System den Kunden nach
|
||||
Bestätigung der Anwender:in (F-08) über `KundenRepository.loesche(kundennummer)` dauerhaft
|
||||
aus dem lokalen Datenbestand und meldet die Änderung über den `EreignisBus`
|
||||
(`melde(DatenBereich.KUNDEN)`) an die abonnierte Kundenansicht der Gruppe D.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 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
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 112 KiB |
|
|
@ -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
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
|
|
@ -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
|
||||
Loading…
Reference in New Issue