Stefan Mogeritsch
0aa1a1b9b7
- **Domain Enhancements:** - Introduced `PausenKonfiguration` and `BesichtigungsBlock` entities to handle automatic breaks and inspection scheduling. - Added `BesichtigungsTypE` enum for inspection types (`ZU_FUSS`, `ZU_PFERD`). - Updated `Bewerb` and `Abteilung` models to include pause and inspection type fields. - **Service Updates:** - Enhanced `StartlistenService` to calculate start times, accounting for breaks and inspection buffers. - Extended `BewerbService` to support patchable time scheduling via new `updateZeitplan` API. - **Persistence Changes:** - Updated tables (`BewerbTable`, `AbteilungTable`) to persist break configurations and inspection types. - Implemented repository mappings to include these new fields. - **Testing:** - Introduced `BewerbeZeitplanIntegrationTest` to validate new scheduling behaviors, including automatic pauses and inspection handling. - **Documentation:** - Added rulebook and conceptual documents for inspection and scheduling logic in `docs/01_Architecture/`.
77 lines
4.6 KiB
Markdown
77 lines
4.6 KiB
Markdown
# Konzept: Zeitplan-Optimierung (Drag & Drop Logik)
|
|
|
|
> **Status:** ENTWURF | **Datum:** 11. April 2026
|
|
> **Autor:** 🏗️ Lead Architect
|
|
> **Kontext:** Phase 9 — Zeitplan & Protokollierung
|
|
|
|
## 1. Vision & Zielsetzung
|
|
Die Zeitplan-Optimierung ist das zentrale Werkzeug für die Meldestelle, um den Turnierablauf dynamisch an die Gegebenheiten vor Ort anzupassen. Ziel ist eine intuitive, visuelle Oberfläche (Kalender-Ansicht), in der Bewerbe und Abteilungen per Drag & Drop verschoben werden können, wobei das System automatisch Auswirkungen auf Folge-Bewerbe berechnet und vor Konflikten warnt.
|
|
|
|
## 2. Fachliche Anforderungen (Use Cases)
|
|
|
|
### UC-1: Verschieben eines Bewerbs/einer Abteilung
|
|
- Ein Benutzer zieht einen Bewerb oder eine Abteilung auf eine neue Startzeit oder einen anderen Austragungsplatz.
|
|
- **System-Reaktion:**
|
|
- Neuberechnung der Endzeit basierend auf `reitdauerMinuten * starterAnzahl + besichtigungMinuten + umbauMinuten`.
|
|
- Prüfung auf Überschneidungen am selben Austragungsplatz.
|
|
- Warnung bei Konflikten (z.B. Richter-Doppelbelegung).
|
|
|
|
### UC-2: Dynamische Zeitplan-Anpassung („Anschließend“)
|
|
- Bewerbe können als `ANSCHLIESSEND` markiert werden (`beginnZeitTyp`).
|
|
- **System-Reaktion:** Wenn der vorangehende Bewerb verschoben wird oder länger dauert, verschiebt sich der anschließende Bewerb automatisch mit.
|
|
|
|
### UC-3: Drag & Drop in der Startliste
|
|
- Innerhalb einer Startliste können Teilnehmer per Drag & Drop umsortiert werden.
|
|
- **System-Reaktion:** Automatische Aktualisierung der Kopfnummern (Startnummern) und Neuberechnung der individuellen Startzeiten.
|
|
|
|
### UC-4: Protokollierung (Audit Log)
|
|
- Jede manuelle Änderung am Zeitplan oder der Startlisten-Reihenfolge muss protokolliert werden.
|
|
- **Grund:** Nachvollziehbarkeit bei Einsprüchen und Synchronisation zwischen verschiedenen Arbeitsplätzen (Meldestelle ↔ Richterturm).
|
|
|
|
## 3. Datenmodell-Erweiterungen & Logik
|
|
|
|
### 3.1 Erweiterung `Bewerb` & `Abteilung`
|
|
Das bestehende Modell in `entries-domain` deckt bereits viele Felder ab. Für die Optimierung präzisieren wir:
|
|
- **`Umbauzeit`:** Zeit zwischen zwei Abteilungen oder Bewerben.
|
|
- **`Pausen`:** Geplante Unterbrechungen (z.B. Mittagspause, Platzpflege) werden als spezielle „Blocker-Events“ im Zeitplan geführt.
|
|
- **`BesichtigungsBlock` (NEU):** Eigenständiges Objekt für Parcoursbesichtigungen.
|
|
- Kann mit mehreren Bewerben/Abteilungen verknüpft werden (Cross-Competition Inspection).
|
|
- Unterstützt Typen: `ZU_FUSS` (Standard) und `ZU_PFERD` (Spezialfall für Springpferde bis 110cm gemäß ÖTO).
|
|
- Validierung: Mindestens 5 Min. Puffer vor dem ersten Start (ÖTO §43).
|
|
|
|
### 3.2 Zeitberechnungs-Algorithmus (Präzisierung)
|
|
Die Logik in `StartlistenService.berechneStartzeiten` wird erweitert:
|
|
1. **Basis:** `Startzeit` der Abteilung.
|
|
2. **Vorlauf:** `besichtigungMinuten`.
|
|
3. **Starter-Loop:**
|
|
- `individuelleStartzeit = aktuelleZeit`.
|
|
- `aktuelleZeit += bewerb.reitdauerMinuten`.
|
|
- *Neu:* Berücksichtigung von festen Pausen nach X Startern (z.B. 10 Min. Pause alle 20 Starter).
|
|
4. **Nachlauf:** `umbauMinuten` am Ende der Abteilung/des Bewerbs.
|
|
|
|
### 3.3 Drag & Drop Logik (Frontend & Backend)
|
|
- **Frontend (Compose Desktop):**
|
|
- Implementierung eines `DraggableBewerbItem`.
|
|
- Visuelle Darstellung von Konflikten (Rote Markierung bei Überlappung).
|
|
- **Backend (API):**
|
|
- Neuer Endpunkt `PATCH /bewerbe/{id}/zeitplan` für schnelle Updates.
|
|
- Validierung der neuen Zeiten gegen den `austragungsplatzId` und `richterEinsaetze`.
|
|
|
|
## 4. Konflikt-Management
|
|
Das System arbeitet nach dem Prinzip **„Warnen statt Blockieren“** (ADR-0016):
|
|
- **Harte Fehler:** Nur bei technischer Unmöglichkeit (z.B. Datum in der Vergangenheit bei Live-Betrieb).
|
|
- **Warnungen:**
|
|
- Überlappung auf dem Platz.
|
|
- Richter hat gleichzeitig Einsatz in anderem Bewerb.
|
|
- Zeitunterschreitung für Reiter (Reiter startet in zwei kurz aufeinanderfolgenden Bewerben).
|
|
|
|
## 5. Synchronisation (Offline-First)
|
|
Änderungen am Zeitplan erzeugen `SyncEvents` (gemäß ADR-0022).
|
|
- **Lamport-Uhren:** Stellen sicher, dass bei gleichzeitigen Änderungen an zwei Laptops die zeitlich spätere Änderung (oder die mit höherer Priorität) gewinnt.
|
|
- **Echtzeit-Update:** Über WebSockets werden Zeitplan-Änderungen sofort an alle verbundenen Clients (z.B. Anzeige-Monitor, Richter-Tablet) gepusht.
|
|
|
|
## 6. Nächste Schritte
|
|
1. **Backend:** ✅ Implementiert (BewerbService, API, Zeitberechnungs-Pausen).
|
|
2. **Frontend:** Prototyping der Kalender-Ansicht mit Compose Desktop.
|
|
3. **QA:** Test-Szenarien für komplexe Verschiebungen (Kettenreaktionen bei „Anschließend“).
|