Broken Wings – eReservation-System: Lösung der praktischen Übung

1.01 Anforderungen und Architekturziele

Funktionale Anforderungen

ID	Anforderung	Art
F-1	Flüge (eine Linie München–Timbuktu und zurück, ein Flugzeugtyp, mehrmals täglich) verwalten; Flug identifiziert über Flugnummer, eindeutig je Tag.	Muss
F-2	Passagiere reservieren einen Flug; das System vergibt und bestätigt eine Reservierungsnummer.	Muss
F-3	Eine Reservierung wird durch Ticketkauf zur festen Buchung.	Muss
F-4	Sitzplatzreservierung bei der Reservierung oder nachträglich.	Muss
F-5	Flüge einem Flugsteig zuordnen.	Muss
F-6	Check-in vor Abflug inkl. Aufgabe von Gepäckstücken; Bordkarte ausstellen.	Muss
F-7	Vielfliegerprogramm: geflogene Kilometer je Teilnehmer führen und gutschreiben.	Muss
F-8	Reservierung stornieren, Ticket erstatten.	Kann
F-9	Benachrichtigung per E-Mail/SMS (Bestätigung, Gate-Änderung).	Kann
F-10	Online-Check-in über Web/App; Meilenstand und Prämien einsehen.	Kann
F-11	Warteliste bei ausgebuchtem Flug.	Kann

Nicht-funktionale Anforderungen / Qualitätsziele

ID	Qualitätsmerkmal (ISO 25010)	Szenario / Messgröße	Art
Q-1	Funktionale Korrektheit	Kein Sitzplatz wird doppelt vergeben, keine Reservierungsnummer doppelt; auch bei parallelen Zugriffen.	Muss
Q-2	Zuverlässigkeit / Verfügbarkeit	Reservierung und Check-in rund um die Uhr, ≥ 99,5 % im Monat; Wiederanlauf (RTO) ≤ 30 min, kein Datenverlust bestätigter Buchungen (RPO ≈ 0).	Muss
Q-3	Performance	Reservierung und Check-in: 95 % der Anfragen < 2 s bei 100 gleichzeitigen Nutzern.	Muss
Q-4	Sicherheit / Datenschutz	Authentifizierte Mitarbeiter, TLS-Transport, DSGVO-konforme Personendaten, keine Kartendaten im System (Tokenisierung beim Zahlungsdienst).	Muss
Q-5	Benutzbarkeit	Reservierung in ≤ 5 Interaktionsschritten; Check-in-Bedienung ohne Schulung.	Muss
Q-6	Änderbarkeit / Wartbarkeit	Neuer Zahlungsdienst oder neues Flughafensystem ohne Änderung der Domäne anbindbar (≤ 5 Personentage).	Muss
Q-7	Interoperabilität	Standardformate der Luftfahrt (IATA) für Gepäck- und Flugdaten.	Kann
Q-8	Skalierbarkeit	Erweiterung auf mehrere Linien/Flugzeugtypen ohne Neuentwurf.	Kann

Abgrenzungskriterien (Nicht-Ziele)

Keine Flugzeug- oder Crewplanung, keine Wartung, kein Bordbetrieb.
Kein Zahlungsverkehr im Haus: Abwicklung beim externen Zahlungsdienst, keine Speicherung von Kartendaten.
Keine Gepäcksortierung/-verfolgung: nur Übergabe der Gepäckdaten an das Gepäcksystem.
Keine Mehrstrecken- und Umsteigebuchung, kein Codeshare, keine Mehrwährungs- und Steuerlogik.
Kein Revenue-Management (dynamische Preise); Preis kommt aus einer festen Preisliste.
Keine hochskalierte Mehr-Regionen-Architektur (eine Linie, überschaubare Last).

Architekturziele

Konsistenz vor Verfügbarkeit bei Buchungen (Q-1): keine Doppelvergabe, transaktionale Sicherheit.
Hohe Verfügbarkeit und Datensicherheit (Q-2, Q-4).
Einfachheit und Angemessenheit: eine Linie rechtfertigt keinen Microservice-Zoo.
Austauschbarkeit der Nachbarsysteme über klare Schnittstellen (Q-6).

Randbedingungen (Annahmen)

Betrieb im eigenen/gemieteten Rechenzentrum, Java/Spring-Know-how im Team, Anbindung an vorhandene Flughafensysteme über vorgegebene Schnittstellen (Standardprotokolle), Einhaltung DSGVO.

1.02 Einsatz

Anwendungsbereiche und Zielgruppe

Fluggesellschaft „Broken Wings“: Buchung, Sitzplatzvergabe, Abfertigung (Check-in, Gepäck) und Vielfliegerverwaltung für die Linie München–Timbuktu. Zielgruppen: Passagiere (Endkunden), Check-in-Personal am Flughafen, Flugdisposition/Verwaltung der Airline, Vielflieger-Teilnehmer.

Betriebsbedingungen

Aspekt	Ausprägung
Physikalische Umgebung	Server im Rechenzentrum (klimatisierter Serverraum); Client-Seite: Büro/Call-Center, Flughafenhalle (Check-in-Schalter, Kiosk, belebt, wechselnde Beleuchtung), Endgeräte der Passagiere unterwegs (Smartphone, Browser).
Betriebszeit	Server 24×7 (Buchungen aus allen Zeitzonen); Check-in-Schalter während der Abfertigungszeiten (ca. 3 h vor jedem Abflug); Wartungsfenster nachts mit Ankündigung.
Beaufsichtigung	Server unbeaufsichtigt mit automatischem Monitoring und Alarmierung (Bereitschaft); Schalter beaufsichtigt durch Personal; Kiosk-Terminals teilbeaufsichtigt (Fernwartung).
Netz	Internet (Passagiere), VPN/Standleitung zu Flughäfen; Verbindungsabbruch am Schalter muss überbrückbar sein (Retry).

Beteiligte Rollen

Rolle	Typ	Aufgaben / Interesse
Passagier	Benutzer	Reservieren, Ticket kaufen, Sitzplatz wählen, Check-in, Stornieren
Vielflieger	Benutzer (Spezialisierung)	Zusätzlich: Meilenstand einsehen, Meilen erhalten
Check-in-Mitarbeiter	Benutzer	Check-in durchführen, Gepäck annehmen, Bordkarte ausgeben
Flugdisponent	Benutzer	Flüge anlegen, Flugsteige zuweisen, Flug abschließen
Systemadministrator / Betrieb	Betreiber	Betrieb, Backup, Monitoring, Rollen- und Rechtevergabe
Zahlungsdienst, Flughafen-Betriebssystem, Gepäcksystem, Mail-/SMS-Gateway	Nachbarsysteme	siehe Kontextsicht 1.05
Geschäftsleitung / Product Owner	Stakeholder	Kosten, Nutzen, Kundenzufriedenheit
Datenschutzbeauftragter	Stakeholder	DSGVO-Konformität der Passagierdaten
Entwicklungsteam / Architekt	Stakeholder	Verständlichkeit, Änderbarkeit

1.03 OOA-Modell

(a) Use Cases

Aus den Leistungsmerkmalen ergeben sich elf Use Cases, auf zwei Diagramme verteilt (Passagier-/Buchungssicht, Abfertigungs-/Betriebssicht).

Use-Case-Diagramm Passagier: Flug reservieren, Ticket kaufen, Sitzplatz reservieren, Reservierung stornieren, Meilenstand einsehen — Abb. 1: Use Cases Passagier und Vielflieger · auf MZP öffnen

Use-Case-Diagramm Abfertigung: Check-in, Gepäck, Flug planen, Flugsteig zuweisen, Flug abschließen, Meilen gutschreiben — Abb. 2: Use Cases Abfertigung und Flugbetrieb · auf MZP öffnen

UC	Name	Akteur	Kurzbeschreibung
UC-1	Flug reservieren	Passagier	Flug wählen, Reservierungsnummer erhalten
UC-2	Ticket kaufen	Passagier, Zahlungsdienst	Reservierung wird zur festen Buchung (include: Zahlung)
UC-3	Sitzplatz reservieren	Passagier	Extend zu UC-1, auch nachträglich möglich
UC-4	Reservierung stornieren	Passagier	Freigabe von Platz und Sitz
UC-5	Meilenstand einsehen	Vielflieger	Gesamtkilometer anzeigen
UC-6	Check-in durchführen	Passagier, Mitarbeiter	Ticket prüfen, Bordkarte ausstellen
UC-7	Gepäck aufgeben	Passagier, Mitarbeiter	Extend zu UC-6, Gepäckstücke erfassen
UC-8	Flug planen	Flugdisponent	Flug mit eindeutiger Flugnummer je Tag anlegen
UC-9	Flugsteig zuweisen	Flugdisponent	Flug einem Flugsteig zuordnen
UC-10	Flug abschließen	Flugdisponent	Flug als durchgeführt markieren (include UC-11)
UC-11	Meilen gutschreiben	System	Streckenkilometer allen eingecheckten Vielfliegern gutschreiben

(b) Klassendiagramm mit Design Patterns

Das Klassenmodell ist wegen der Lesbarkeit in drei Diagramme geteilt: Domänenkern, Check-in/Gepäck und Pattern-Sicht.

Klassendiagramm Kern: Flug, Flugsteig, Passagier, Vielflieger, Reservierung, Ticket, Sitzplatzreservierung — Abb. 3: Domänenkern · auf MZP öffnen

Klassendiagramm Check-in: Passagier, Ticket, CheckIn, Bordkarte, Gepäckstück, Flug — Abb. 4: Check-in und Gepäck · auf MZP öffnen

Klassendiagramm Patterns: Facade, State, Repository — Abb. 5: Design Patterns · auf MZP öffnen

Gewählte Patterns und Begründung

Pattern	Einsatz	Begründung
State	`Reservierung` mit `Reserviert`, `Gebucht`, `Storniert`	Die Reservierung hat einen Lebenszyklus mit statusabhängigem Verhalten (Ticketkauf nur bei „reserviert“). Statt `if/switch`-Kaskaden sind Übergänge lokal und erweiterbar.
Facade	`ReservierungsService`	Einheitlicher Einstieg für UI/API, versteckt Domänenobjekte, Transaktionsgrenze, geringe Kopplung.
Repository (DAO)	`ReservierungRepository` + SQL-Implementierung	Entkoppelt Domäne von der Datenbank (siehe 1.07), Testbarkeit mit In-Memory-Variante.
Observer / Domain Events	Ereignis `FlugAbgeschlossen` löst Meilengutschrift (UC-11) und Benachrichtigung aus	Lose Kopplung zwischen Flugbetrieb, Vielfliegerprogramm und Benachrichtigung; neue Reaktionen ohne Änderung des Senders.
Strategy	Meilenberechnung (Streckenkilometer, ggf. Statusbonus)	Regeln des Vielfliegerprogramms ändern sich häufig und sind austauschbar.
Generalisierung	`Vielflieger` als Spezialisierung von `Passagier`	Nur Teilnehmer führen ein Kilometerkonto. Alternative Rolle/Komposition ist denkbar, hier wegen Einfachheit gewählt.

1.04 Datenmodellierung

Beschreibungstechnik: relationales Schema in ER-Notation (Tabellen mit PK/FK/UQ, Fremdschlüsselkanten mit Löschregel).

Begründung: Die Daten sind stark strukturiert und beziehungsreich (Flug – Reservierung – Ticket – Check-in – Gepäck). Das ER-/relationale Modell macht Schlüssel, Kardinalitäten und Integritätsbedingungen (z. B. eindeutige Flugnummer je Datum, eindeutiger Sitz je Flug) explizit und ist direkt in DDL überführbar. Es ergänzt das UML-Klassenmodell um die persistenzrelevanten Details (Schlüssel, Constraints), die dort bewusst fehlen.

Datenmodell Teil 1: FLUGSTEIG, FLUG, RESERVIERUNG, PASSAGIER, VIELFLIEGER — Abb. 6: Datenmodell, Stammdaten und Reservierung · auf MZP öffnen

Datenmodell Teil 2: RESERVIERUNG, SITZPLATZ_RESERVIERUNG, TICKET, CHECKIN, GEPAECKSTUECK — Abb. 7: Datenmodell, Buchung, Check-in, Gepäck · auf MZP öffnen

Wesentliche Integritätsregeln

FLUG: UNIQUE(flugnummer, datum) – Flugnummer ist nur je Tag eindeutig.
SITZPLATZ_RESERVIERUNG: UNIQUE(flug_id, reihe, platz) verhindert Doppelvergabe; flug_id ist hier bewusst redundant zur Reservierung (Constraint-Zweck), per Trigger/Composite-FK konsistent zu halten.
TICKET.reservierung_id ist UNIQUE: höchstens ein Ticket je Reservierung.
VIELFLIEGER teilt den Primärschlüssel mit PASSAGIER (Spezialisierung, „Tabelle je Subklasse“).
Meilenkonto: gesamt_km wird nur über UC-11 fortgeschrieben (idempotent je Flug und Passagier, zusätzliche Buchungstabelle empfehlenswert).

1.05 Systemüberblick: Kontextsicht

Vier Nachbarsysteme sind angenommen: Zahlungsdienst (PSP), Flughafen-Betriebssystem (Gate, Flugstatus), Gepäcksystem (BHS) und Mail-/SMS-Gateway. Die Wahl der Diagramme: Logischer Kontext als C4-Kontextdiagramm (System als Black Box, Akteure und Datenflüsse), physischer Kontext als Komponenten-/Architekturdiagramm mit Format und Protokoll an jeder Kante, Verteilungskontext als UML-Verteilungsdiagramm mit Zonen und Kanälen.

Logischer Kontext

Begründung: Ein Kontextdiagramm zeigt das System als Black Box und lenkt den Blick auf welche fachlichen Daten mit wem ausgetauscht werden; jede Kante trägt die logischen Daten, Technik bleibt außen vor.

Physischer Kontext

Schnittstelle	Was	Format	Protokoll / Medium
Passagier-Client	Reservierung, Ticket, Sitz, Online-Check-in	JSON (OpenAPI-spezifiziert)	HTTPS/REST über Internet
Check-in-Terminal	Check-in, Gepäck, Bordkarte (Barcode IATA BCBP)	JSON	HTTPS/REST, mTLS, VPN
Admin-UI Disposition	Flüge, Flugsteige	JSON	HTTPS/REST, OIDC-Token
Zahlungsdienst	Zahlungsauftrag/-bestätigung	JSON, Kartendaten nur als Token	HTTPS/REST, TLS 1.2+
Flughafen-Betriebssystem	Flugsteig, Flugstatus, geflogene km	XML (IATA AIDX)	AMQP über TLS, Message-Queue
Gepäcksystem	Gepäckdaten je Gepäckstück	IATA Baggage Service Message (Type B)	Message-Queue/MQ
Mail-/SMS-Gateway	Bestätigung, Gate-Änderung	MIME / JSON	SMTP bzw. HTTPS

Verteilungskontext

Begründung: Das Verteilungsdiagramm zeigt Standorte, Netzgrenzen und Kanäle (Internet, VPN) und macht Vertrauensgrenzen sichtbar; dort sind Sicherheits- und Verfügbarkeitsmaßnahmen (TLS, VPN, Standby-Datenbank) verankert. Mail-/SMS-Gateway ist aus Platzgründen im Diagramm weggelassen (Standard-Ausgangskanal HTTPS/SMTP).

1.06 Softwarearchitektur

Schichtenarchitektur mit Ports und Adaptern — Abb. 11: Schichten und Ports/Adapters · auf MZP öffnen

Architekturstil

Modularer Monolith in Schichten, Domänenkern nach Ports-and-Adapters (Hexagonal). Ein Deployment-Artefakt, intern nach fachlichen Modulen geschnitten (Flugplan, Reservierung/Buchung, Abfertigung, Vielflieger).

Entscheidung	Begründung	Alternative und Verwerfungsgrund
Modularer Monolith	Eine Linie, überschaubare Last und kleines Team (Architekturziel „Einfachheit“). Transaktionale Konsistenz ohne verteilte Transaktionen (Q-1). Einfacher Betrieb.	Microservices: hoher Betriebs- und Konsistenzaufwand ohne Skalierungsbedarf.
Schichten (Präsentation, Anwendung, Domäne, Infrastruktur)	Bekannt, verständlich, trennt Verantwortlichkeiten; Abhängigkeiten laufen nur nach unten, Domäne bleibt UI-frei.	Reine MVC-Struktur: Fachlogik würde in Controllern verstreut.
Ports and Adapters	Domäne definiert Ports (Repository, Zahlung, Gate); Datenbank, PSP, AODB, BHS sind austauschbare Adapter (Q-6, Testbarkeit mit Mocks). Dependency Inversion.	Direkte Aufrufe externer APIs aus der Domäne: starke Kopplung.
Facade / Application Service	Eine Transaktions- und Sicherheitsgrenze je Use Case.	–
State, Strategy, Observer/Events	siehe 1.03, für Lebenszyklus, Meilenregeln und lose Kopplung.	–
Querschnittskonzepte	Optimistisches Locking plus Unique-Constraint (Sitzvergabe), Idempotenz bei Zahlung und Meilen, Fehlerbehandlung mit Retry und Outbox für Nachrichten an Nachbarsysteme, Authentifizierung per OIDC, rollenbasierte Autorisierung, strukturiertes Logging, Monitoring.	–

Die Verteilung orientiert sich am Verteilungskontext (Abb. 10): zwei Application-Server hinter einem Load Balancer, Datenbank mit Standby. Ein Wechsel auf eine Aufteilung in Services bleibt über die Modulgrenzen später möglich.

1.07 Persistenz

Empfehlung: relationale Datenbank (z. B. PostgreSQL) mit Zugriff über Repository/DAO, JPA/Hibernate als OR-Mapper, Schemaverwaltung mit Flyway/Liquibase.

Kriterium	Relationale DB (gewählt)	Dokumenten-DB / NoSQL	Dateien / In-Memory
Konsistenz (Q-1)	ACID-Transaktionen, Unique-Constraints und FK sichern Sitz- und Nummernvergabe	Meist schwächere Mehrdokument-Transaktionen	Nicht tragfähig
Datenstruktur	Stark vernetzt, fest strukturiert → passt	Eher für variable Strukturen	–
Abfragen	Ad-hoc-SQL (Freie Plätze, Meilen, Auswertungen)	Je nach Modell aufwändig	–
Verfügbarkeit (Q-2)	Streaming-Replikation, Standby, PITR-Backup, bekannte Betriebsmuster	Gut skalierbar, hier nicht nötig	–
Skalierung (Q-3, Q-8)	Datenmenge klein bis mittel (eine Linie) → problemlos vertikal	Vorteil erst bei sehr hohen Lasten	–
Kosten / Know-how	Weit verbreitet, Open Source, geringe Lizenzkosten	Zusätzliches Know-how	–

Entkopplung: Domäne kennt nur das Repository-Interface (Port), nicht JDBC/JPA.
Gleichzeitigkeit: Sitz über UNIQUE(flug_id, reihe, platz), Reservierungen mit Versionsspalte (optimistisches Locking), Zahlungs- und Meilenvorgänge idempotent.
Datenschutz/Sicherheit: Verschlüsselung at rest, Backups verschlüsselt, Löschkonzept für Passagierdaten, keine Kartendaten.
Wahrnehmung: Falls später sehr hohe Leselast entsteht, kann eine Read-Replica oder ein Cache (z. B. für Flugplan und freie Plätze) ergänzt werden, ohne die Schreibseite zu ändern.