Übungsaufgaben zum Ansichtsmodell: die Mitfahrgesuche im Zeitfenster

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Ansichtsmodell: die
Mitfahrgesuche im Zeitfenster“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/flurmonitor-ansichtsmodell
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/flurmonitor-ansichtsmodell-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Ansichtsmodell
- View-Model
- record
- Clock
- Zeitfenster
- Sortierung
- Komponententest
- parametrisierter Test
- Grenzwerte
- Mitfahrgesuche

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Bewertung: je Zeile 1 Punkt. Bei Zeile 5 ist auch „UhrKonfiguration bzw. Clock-Bean“ richtig, bei Zeile 8 auch „MonitorAufbereitung“, wenn begründet wird, dass sie die Abbildung aufruft.

• Angebot ist eine Entity: Sie trägt @Entity, wird von JPA gespeichert, enthält die Fahrerin oder den Fahrer und Fachregeln wie belegePlatz() (1 Punkt).

• MonitorEintrag ist ein DTO: Er wird aus dem API-Vertrag openapi.yaml generiert und über GET /monitor/eintraege als JSON an alle Clients übertragen (1 Punkt).

• MonitorZeile ist ein Ansichtsmodell: Sie enthält nur die Werte, die die Tabelle auf der Seite /flurmonitor zeigt, und eine kleine Darstellungsregel (wenigePlaetze()), aber keine Namen (1 Punkt).

Reihenfolge: C (Fr 15:00), D (Sa 11:00), B (Mo 15:30). Hervorgehoben wird B, weil nur noch ein Platz frei ist.

• A fehlt, weil die Abfahrt um 14:30 Uhr schon vorbei ist. C fährt genau jetzt ab und gehört noch dazu, weil der Anfang des Zeitfensters einschließlich ist.

• Der nächste Schultag nach Freitag ist Montag; das Fenster endet vor Dienstag, 00:00 Uhr. E am Dienstag liegt deshalb außerhalb. D am Samstag liegt innerhalb, denn das Fenster umfasst alle Tage bis zum Ende des nächsten Schultags, auch das Wochenende.

Bewertung: richtige Auswahl C, D, B 2 Punkte (je Fehler 1 Punkt Abzug), Reihenfolge 1 Punkt, Hervorhebung von B 1 Punkt. Im Projekt nachgeprüft mit Zeitfenster.ab(LocalDateTime.of(2026, 10, 23, 15, 0)).

package de.dbh.mitfahrlabor.web.monitor;

import java.util.List;

import de.dbh.mitfahrlabor.service.GesuchZeile;

/** Ansichtsmodell der Seite /flurmonitor/gesuche: Standort und die sichtbaren Gesuche, früheste zuerst. */
public record GesucheAnsicht(String standort, List<GesuchZeile> gesuche) {

    public GesucheAnsicht {
        gesuche = List.copyOf(gesuche);
    }

    public int anzahl() {
        return gesuche.size();
    }
}

Bewertung: Record mit beiden Komponenten 1 Punkt, kompakter Konstruktor mit List.copyOf (oder Collections.unmodifiableList auf einer Kopie) 1 Punkt, anzahl() aus der Liste berechnet 1 Punkt.

package de.dbh.mitfahrlabor.web.monitor;

import java.time.Clock;
import java.time.LocalDateTime;
import java.util.Comparator;

import org.springframework.stereotype.Component;

import de.dbh.mitfahrlabor.service.GesuchService;
import de.dbh.mitfahrlabor.service.GesuchZeile;

/** Bereitet die offenen Gesuche für den Flurmonitor auf (MON-13a). */
@Component
public class GesucheAufbereitung {

    private static final Comparator<GesuchZeile> FRUEHESTE_ZUERST = Comparator.comparing(GesuchZeile::datum)
            .thenComparing(GesuchZeile::fruehestens);

    private final GesuchService gesuchService;
    private final Clock uhr;

    public GesucheAufbereitung(GesuchService gesuchService, Clock uhr) {
        this.gesuchService = gesuchService;
        this.uhr = uhr;
    }

    public GesucheAnsicht ansicht(String standort) {
        Zeitfenster fenster = Zeitfenster.ab(LocalDateTime.now(uhr));
        var sichtbar = gesuchService.offeneGesuche().stream()
                .filter(g -> fenster.enthaelt(g.datum(), g.spaetestens()))
                .sorted(FRUEHESTE_ZUERST)
                .toList();
        return new GesucheAnsicht(standort, sichtbar);
    }
}

Bewertung: @Component und beide Abhängigkeiten per Konstruktor 1 Punkt, Zeitpunkt aus LocalDateTime.now(uhr) (nicht ohne Uhr) 1 Punkt, Zeitfenster mit enthaelt(datum, spaetestens) 2 Punkte, Sortierung nach Datum und dann fruehestens 1 Punkt, Rückgabe einer GesucheAnsicht 1 Punkt. Im Projekt geprüft: Mit den Tests aus Aufgabe 2.2 ist die Klasse grün, die Abdeckung liegt bei 100 Prozent.

private final GesucheAufbereitung aufbereitung;

public MitfahrgesucheController(GesucheAufbereitung aufbereitung) {
    this.aufbereitung = aufbereitung;
}

@GetMapping("/flurmonitor/gesuche")
public String anzeigen(Model model) {
    model.addAttribute("ansicht", aufbereitung.ansicht("Foyer Gebäude A"));
    return "flurmonitor-gesuche";
}

<p class="lead">Flurmonitor im <span th:text="${ansicht.standort}">Eingang A</span></p>
<p>Offene Gesuche: <strong th:text="${ansicht.anzahl()}">2</strong></p>
<!-- … -->
<p th:if="${ansicht.gesuche.isEmpty()}" class="fs-4" th:text="#{gesuche.keine}">Gerade keine offenen Gesuche.</p>
<div th:unless="${ansicht.gesuche.isEmpty()}" class="table-responsive">
  <!-- … -->
  <tr th:each="gesuch : ${ansicht.gesuche}" th:object="${gesuch}">

Bewertung: Controller mit GesucheAufbereitung statt GesuchService und einem Attribut ansicht 1 Punkt, Standort und Anzahl im Template über ansicht 1 Punkt, Bedingung und Schleife über ansicht.gesuche 1 Punkt. Die Zellen der Zeile bleiben unverändert, weil GesuchZeile weiter verwendet wird. Im Projekt geprüft: Ein Smoke-Test mit fester Uhr auf Montag, 16.11.2026, 07:30 Uhr findet „Offene Gesuche: 2“ und beide Beispielgesuche.

Ein Gesuch ist so lange interessant, wie jemand die suchende Person noch mitnehmen kann, also bis zum Ende ihres Zeitfensters (1 Punkt). Mit fruehestens verschwände ein Gesuch „07:00 bis 08:00“ schon um 07:01 Uhr vom Monitor, obwohl eine Fahrt um 07:45 Uhr noch passen würde (1 Punkt).

Bewertung: je Zeile 1 Punkt für die richtige Entscheidung mit passender Begründung.

Clock.fixed(Instant.parse("2026-11-16T06:30:00Z"), ZoneId.of("Europe/Berlin")) (1 Punkt). Ein Instant wird in UTC angegeben; am 16.11.2026 gilt in Deutschland die Normalzeit UTC+1, 07:30 Uhr deutscher Zeit sind also 06:30 Uhr UTC. Die Zone Europe/Berlin sorgt dafür, dass LocalDateTime.now(uhr) wieder 07:30 Uhr liefert (1 Punkt).

@ExtendWith(MockitoExtension.class)
class GesucheAufbereitungTest {

    /** Montag, 16.11.2026, 07:30 Uhr in Deutschland; im Winter gilt UTC+1, also 06:30 Uhr UTC. */
    private static final Clock MONTAG_0730 = Clock.fixed(Instant.parse("2026-11-16T06:30:00Z"),
            ZoneId.of("Europe/Berlin"));

    @Mock
    private GesuchService gesuchService;

    @ParameterizedTest(name = "Gesuch {0} {1}–{2} -> sichtbar: {3}")
    @CsvSource({
        "2026-11-16, 07:00, 08:00, true",  // läuft gerade
        "2026-11-16, 06:30, 07:30, true",  // Grenzwert: spätestens genau jetzt
        "2026-11-16, 06:30, 07:29, false", // eine Minute vorbei
        "2026-11-17, 15:30, 23:59, true",  // letzte Minute des nächsten Schultags
        "2026-11-18, 00:00, 00:30, false", // Mitternacht danach
        "2026-11-13, 15:30, 16:30, false"  // Freitag davor
    })
    void zeigtGesucheBisZumEndeDesNaechstenSchultags(LocalDate datum, LocalTime fruehestens, LocalTime spaetestens,
            boolean sichtbar) {
        given(gesuchService.offeneGesuche()).willReturn(List.of(
                new GesuchZeile("Gütersloh", "Hauptbahnhof, ZOB Steig 3", "zur Schule", datum, fruehestens,
                        spaetestens, "")));

        var ansicht = new GesucheAufbereitung(gesuchService, MONTAG_0730).ansicht("Foyer Gebäude A");

        assertThat(ansicht.gesuche()).hasSize(sichtbar ? 1 : 0);
    }
}

Bewertung: feste Uhr mit richtigem Instant und Zone 1 Punkt, Mock des Service mit @Mock und MockitoExtension 1 Punkt, @ParameterizedTest mit @CsvSource und allen sechs Fällen 2 Punkte, Aufbereitung mit new ohne Spring-Kontext 1 Punkt, Prüfung auf ein bzw. kein Gesuch 1 Punkt. Imports: org.junit.jupiter.params.*, org.mockito.*, statisch assertThat und given. Im Projekt ausgeführt: sechs grüne Tests.

@Test
void sortiertNachDatumUndFruehestemZeitpunkt() {
    given(gesuchService.offeneGesuche()).willReturn(List.of(
            gesuch("Herford", "2026-11-17", "07:00"),
            gesuch("Bielefeld", "2026-11-16", "15:30"),
            gesuch("Gütersloh", "2026-11-16", "07:00")));

    var ansicht = new GesucheAufbereitung(gesuchService, MONTAG_0730).ansicht("Foyer Gebäude A");

    assertThat(ansicht.gesuche()).extracting(GesuchZeile::ort)
            .containsExactly("Gütersloh", "Bielefeld", "Herford");
    assertThat(ansicht.anzahl()).isEqualTo(3);
}

private static GesuchZeile gesuch(String ort, String datum, String fruehestens) {
    var ab = LocalTime.parse(fruehestens);
    return new GesuchZeile(ort, "Treffpunkt", "zur Schule", LocalDate.parse(datum), ab, ab.plusHours(1), "");
}

Bewertung: Testdaten unsortiert, mit gleichem Datum und verschiedener Uhrzeit 1 Punkt, Prüfung der Reihenfolge mit containsExactly 1 Punkt, Prüfung von anzahl() 1 Punkt. Alle Gesuche müssen im Zeitfenster liegen, sonst prüft der Test den Filter statt der Sortierung.

• Symptom A, Zeile 5: Die Bedingung vergleicht nur die Uhrzeit spaetestens mit der aktuellen Uhrzeit und ignoriert das Datum. 08:00 Uhr liegt vor 15:00 Uhr, also fliegt das Gesuch für morgen heraus, obwohl es in der Zukunft liegt (2 Punkte).

• Symptom B, Zeilen 4 und 5: Zeile 4 prüft nur die Obergrenze des Datums, eine Untergrenze fehlt. Zeile 5 lässt das Freitagsgesuch durch, weil 16:30 Uhr nach 07:30 Uhr liegt; dass der Freitag vorbei ist, prüft niemand (2 Punkte).

• Symptom C, Zeile 2: LocalTime.now() liest die Systemuhr in der Standardzeitzone der JVM statt der injizierten Clock. Die feste Uhr des Tests wirkt nur auf das Datum aus Zeile 1, die Uhrzeit kommt vom Rechner. Je nach Tageszeit und Zeitzone des Rechners werden andere Testfälle rot; in UTC ist es eine Stunde früher als in Deutschland (2 Punkte).

Im Projekt nachgeprüft: Mit diesem Code und der Testklasse aus Aufgabe 2.2 waren bei einer Rechnerzeit von 03:41 Uhr zwei Fälle rot (Fall 3 und 6), bei 12:41 Uhr vier Fälle (Fälle 1, 2, 6 und der Sortiertest).

public GesucheAnsicht ansicht(String standort) {
    Zeitfenster fenster = Zeitfenster.ab(LocalDateTime.now(uhr));
    var sichtbar = gesuchService.offeneGesuche().stream()
            .filter(g -> fenster.enthaelt(g.datum(), g.spaetestens()))
            .sorted(Comparator.comparing(GesuchZeile::datum)
                    .thenComparing(GesuchZeile::fruehestens))
            .toList();
    return new GesucheAnsicht(standort, sichtbar);
}

Bewertung: Datum und Uhrzeit aus derselben Uhr (LocalDateTime.now(uhr)) 1 Punkt, Datum und Uhrzeit zusammen vergleichen (datum.atTime(spaetestens)) 1 Punkt, Untergrenze „nicht vor jetzt“ einschließlich 1 Punkt, Obergrenze „vor Mitternacht nach dem nächsten Schultag“ 1 Punkt. Eine Lösung ohne Zeitfenster, die dieselben Bedingungen mit LocalDateTime selbst prüft, ist ebenso richtig.

Mit fester Uhr ist das Ergebnis jetzt bei jedem Lauf gleich (1 Punkt). Fall 6 (Freitag, 16:30 Uhr) wird zuverlässig rot, weil 16:30 Uhr nach 07:30 Uhr liegt und das Datum nicht nach unten begrenzt ist (1 Punkt). Fall 2 (spätestens genau 07:30 Uhr) wird ebenfalls rot, weil isAfter den Zeitpunkt „genau jetzt“ ausschließt, das Zeitfenster ihn aber einschließt (1 Punkt). Im Projekt nachgeprüft: Mit dieser Fassung sind genau diese beiden Fälle rot, unabhängig von Uhrzeit und Zeitzone des Rechners.

Je 1 Punkt, zum Beispiel:

• eine Regel in der Definition of Done bzw. im Review: im Hauptcode kein now() ohne Clock; automatisch prüfbar mit einer Checkstyle-Regel (z. B. Regexp auf \.now\(\)) oder einem Architekturtest mit ArchUnit,

• Grenzwerte um Mitternacht, die Vergangenheit und „genau jetzt“ als feste Testfälle in jede Aufbereitung aufnehmen,

• die Tests in der Pipeline zusätzlich mit einer anderen Zeitzone laufen lassen (z. B. TZ=Asia/Tokyo), damit Abhängigkeiten von der Systemzeit sofort auffallen.