Übungsaufgaben zur Codegenerierung: Mitfahrgesuche aus dem Vertrag

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 „Codegenerierung: Mitfahrgesuche
aus dem Vertrag“.

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/spring-boot-openapi-codegenerierung
- Stilbeispiel: https://oer-informatik.de/spring-boot-openapi-codegenerierung-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- OpenAPI Generator
- Codegenerierung
- Contract First
- Bean Validation
- Interface
- Spring Boot
- HTTP-Statuscodes
- Fehlersuche

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.

Je Zeile 1 Punkt:

Je Anfrage 1 Punkt:

1. 201 Created: gültig, legeAngebotAn() ist implementiert und antwortet mit Location-Header.
2. 400 Bad Request: @Min(value = 1) aus minimum: 1 verletzt; die Methode wird gar nicht aufgerufen.
3. 201 Created: Der Vertrag fordert nur minimum: 0; die Grenze je Kilometer ist eine Fachregel, die noch niemand prüft.
4. 404 Not Found: Der Pfad gehört zum tag buchungen; BuchungenApi wird von keiner Klasse implementiert, Spring kennt den Pfad nicht.
5. 501 Not Implemented: AngebotController implementiert AngeboteApi, überschreibt aendereAngebot() aber nicht; die default-Methode antwortet.
6. 400 Bad Request: Im Schema AngebotAenderung erlaubt status nur den Wert abgesagt; offen lässt sich nicht umwandeln, noch bevor eine Methode aufgerufen wird.

Im Paket api: GesucheApi.java (1 Punkt). Im Paket api.model: Gesuch.java, GesuchNeu.java und GesuchStatus.java (1 Punkt). Die Schemas Richtung und Problem gab es schon.

ResponseEntity<List<Gesuch>> sucheGesuche(Richtung richtung)
ResponseEntity<Gesuch> stelleGesuchEin(GesuchNeu gesuchNeu)
ResponseEntity<Gesuch> holeGesuch(Long gesuchId)

Bewertung: Methodennamen aus den operationIds (1 Punkt), Rückgabetypen mit ResponseEntity und List bei der Suche (1 Punkt), Parametertypen Richtung, GesuchNeu, Long (2 Punkte). Im erzeugten Code tragen die Parameter zusätzlich @RequestParam, @Valid @RequestBody und @PathVariable.

package de.dbh.mitfahrlabor.web;

import java.time.LocalDate;
import java.util.List;

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.RestController;

import de.dbh.mitfahrlabor.api.GesucheApi;
import de.dbh.mitfahrlabor.api.model.Gesuch;
import de.dbh.mitfahrlabor.api.model.GesuchStatus;
import de.dbh.mitfahrlabor.api.model.Richtung;

@RestController
public class GesuchController implements GesucheApi {

    private final List<Gesuch> gesuche = List.of(
            new Gesuch().id(1L).mitfahrerId(3L).haltepunktId(1L).richtung(Richtung.ZUR_SCHULE)
                    .datum(LocalDate.of(2026, 11, 23)).zeitVon("06:45").zeitBis("07:15")
                    .status(GesuchStatus.OFFEN),
            new Gesuch().id(2L).mitfahrerId(3L).haltepunktId(3L).richtung(Richtung.ZUR_SCHULE)
                    .datum(LocalDate.of(2026, 11, 23)).zeitVon("07:00").zeitBis("07:20")
                    .status(GesuchStatus.OFFEN),
            new Gesuch().id(3L).mitfahrerId(3L).haltepunktId(1L).richtung(Richtung.NACH_HAUSE)
                    .datum(LocalDate.of(2026, 11, 23)).zeitVon("15:00").zeitBis("16:00")
                    .status(GesuchStatus.OFFEN));

    @Override
    public ResponseEntity<List<Gesuch>> sucheGesuche(Richtung richtung) {
        List<Gesuch> treffer = gesuche.stream()
                .filter(g -> richtung == null || g.getRichtung() == richtung)
                .toList();
        return ResponseEntity.ok(treffer);
    }

    @Override
    public ResponseEntity<Gesuch> holeGesuch(Long gesuchId) {
        return gesuche.stream()
                .filter(g -> g.getId().equals(gesuchId))
                .findFirst()
                .map(ResponseEntity::ok)
                .orElse(ResponseEntity.notFound().build());
    }
}

Bewertung: @RestController und implements GesucheApi (2 Punkte), Startdaten mit den erzeugten Klassen (2 Punkte; Konstruktor mit allen Werten ist ebenso richtig), Suche mit Filter und null für „alle“ (2 Punkte), Abrufen mit equals() und 404 (2 Punkte). Die Richtung wird mit == verglichen, weil Richtung eine Aufzählung ist; IDs vom Typ Long dagegen mit equals().

Je Body 2 Punkte (Code 1 Punkt, Begründung 1 Punkt):

1. 501 Not Implemented: Der Body ist gültig, stelleGesuchEin() wird aber nicht überschrieben; die default-Methode antwortet.
2. 400 Bad Request: 6:45 passt nicht zum Muster HH:MM (@Pattern); geprüft wird vor dem Aufruf der Methode.
3. 400 Bad Request: datum ist Pflichtfeld (@NotNull).
4. 501 Not Implemented: Beide Uhrzeiten passen zum Muster. Dass das Zeitfenster rückwärts läuft, kann die Validierung aus dem Vertrag nicht erkennen, weil sie jedes Feld einzeln prüft. Diese Regel muss das Backend selbst prüfen und dann mit 400 oder 422 antworten.

Je Teil 3 Punkte (Ursache 2 Punkte, Korrektur 1 Punkt):

a) Der Generator legt die Klasse EnumConverterConfiguration, die nach-hause in Richtung.NACH_HAUSE umwandelt, ohne die Option ins Paket org.openapitools.configuration. Das liegt außerhalb von de.dbh.mitfahrlabor, der Komponentenscan findet die Klasse nicht, und Spring versucht Richtung.valueOf("nach-hause"), was scheitert. Korrektur: "configPackage" to "de.dbh.mitfahrlabor.api.config" (bzw. <configPackage> bei Maven).

b) Der Ordner build/generated wird bei jedem Build aus dem Vertrag neu geschrieben, Änderungen von Hand gehen verloren. Korrektur: Die Regel gehört nicht in erzeugten Code. „Datum nicht in der Vergangenheit“ ist eine Fachregel, die im Backend geprüft wird (Artikel 04 und 08). Der OpenAPI Generator bietet zusätzlich die Erweiterung x-field-extra-annotation an, mit der man im Vertrag eine zusätzliche Annotation für ein Feld angeben kann; auch dann steht die Regel im Vertrag und nicht in der erzeugten Datei.

c) Die Schnittstelle heißt jetzt zeigeGesuch(…); die mit @Override gekennzeichnete Methode holeGesuch(…) überschreibt nichts mehr. Korrektur: Methode im Controller in zeigeGesuch umbenennen oder, falls die Umbenennung im Vertrag ein Versehen war, die operationId zurücksetzen. Ohne @Override würde der Build durchlaufen und der Endpunkt mit 501 antworten.

Für Code First (je 1 Punkt, zwei davon):

• Es gibt nur eine Quelle, den Code; der erzeugte Vertrag passt immer zum Code.
• Kein Generator im Build, kein erzeugter Code, weniger Konfiguration.
• Schneller Einstieg für kleine Projekte, bei denen nur ein Team an Backend und Frontend arbeitet.

Gegen Code First (je 1 Punkt, zwei davon):

• Der Vertrag entsteht erst, wenn das Backend programmiert ist. Die drei Frontend-Teams des Mitfahrlabors können nicht parallel anfangen.
• Der Vertrag ist dann ein Nebenprodukt; Änderungen an der Schnittstelle passieren beim Programmieren, ohne dass sie bewusst abgestimmt werden.
• Der Systemtest in Artikel 11 soll gegen den Entwurf prüfen. Wird der Vertrag aus dem Code erzeugt, prüft man den Code gegen sich selbst.

Entscheidung (2 Punkte): Für das Mitfahrlabor passt Contract First besser, weil mehrere Frontends dieselbe Schnittstelle nutzen, der Vertrag im V-Modell als Systementwurf vor der Implementierung feststehen soll und der Systemtest eine unabhängige Grundlage braucht. Eine gut begründete Entscheidung für Code First (etwa für einen Prototyp mit nur einem Team) ist ebenfalls richtig.