Abituraufgaben: Projekt: Software im Team

Funktional (drei davon): Buslinie auswählen; Abfahrtszeit an einer gewählten Haltestelle anzeigen; Verspätung einer Linie melden und bei den Abfahrtszeiten berücksichtigen; Barrierefreiheit einer Haltestelle anzeigen.

Nicht-funktional: Verfügbarkeit ohne Netz (zuletzt geladener Fahrplan); Bedienbarkeit (Abfahrtszeit nach höchstens zwei Klicks); Datenschutz (keine Speicherung von Standortdaten). Auch die Obergrenze von 20 Haltestellen je Linie kann als Randbedingung genannt werden.

Die Reihung wird im Konstruktor mit 20 Plätzen erzeugt; hinzufuegen liefert false, wenn sie voll ist. getAbfahrt(name) liefert startzeit + verspaetung + fahrzeit der gefundenen Haltestelle, z. B. −1, falls es keine Haltestelle dieses Namens gibt. Die Verspätung gehört zur Linie, nicht zur Haltestelle, weil sie für alle Abfahrten der Linie gilt. Da die Fahrzeit von der Linie abhängt, steht ein Haltestellen-Objekt für einen Halt dieser Linie; eine Haltestelle, die zwei Linien anfahren, erscheint also in beiden Linien als eigenes Objekt. Andere schlüssige Entwürfe (z. B. getAbfahrt(index: Ganzzahl)) sind gleichwertig, sofern sie alle funktionalen Anforderungen abdecken.

Das Klassendiagramm legt die öffentliche Schnittstelle fest: Klassennamen, Methodennamen, Parameter- und Rückgabetypen. Nur wenn diese feststehen, kann das Team „Buslinie“ Aufrufe wie h.getFahrzeit() programmieren, während das Team „Haltestelle“ die Methode noch implementiert – die Teams arbeiten parallel, ohne auf fertigen Quelltext zu warten. Ohne Vereinbarung entstehen abweichende Namen oder Typen (etwa getZeit(): Zeichenkette statt getFahrzeit(): Ganzzahl), die erst beim Zusammenfügen auffallen und dann aufwendig angepasst werden müssen. Außerdem können Testfälle schon vor der Implementierung gegen die Schnittstelle formuliert werden. Die interne Umsetzung (private Attribute) bleibt dabei jedem Team selbst überlassen.

Erwartet werden mindestens istFrei (oder getBuchung), buchen und stornieren mit vollständigen Typen und eindeutig festgelegtem Verhalten bei ungültigen Eingaben (kein Programmabbruch). Die Reihung selbst gehört nicht zur Schnittstelle.

Ausgangszustand: Raum r = new Raum("Pharao", 2, 6); – die Tests werden in dieser Reihenfolge ausgeführt.

Entscheidend ist, dass jede Grenze von beiden Seiten getestet wird und das erwartete Ergebnis vor der Ausführung aus der Anforderung abgeleitet ist, nicht aus dem Programm.

T1, T2, T4, T5, T7 und T9 liefern das erwartete Ergebnis. Drei Tests schlagen fehl:

T3 liefert false statt true: personen >= maxSpieler schließt die zulässige Höchstzahl 6 aus; richtig ist personen > maxSpieler.

T6 liefert true statt false: Die Buchung „Füchse“ wird zwar nicht überschrieben, die Methode meldet aber auch bei belegtem Fenster Erfolg – die Gruppe „Eulen“ hielte sich für gebucht.

T8 bricht mit einer ArrayIndexOutOfBoundsException ab: slot > zeitfenster.length lässt slot = 5 durch, der letzte gültige Index ist aber 4; richtig ist >=.

public boolean buchen(int slot, String gruppe, int personen) {
    if (slot < 0 || slot >= zeitfenster.length) {
        return false;
    }
    if (personen < minSpieler || personen > maxSpieler) {
        return false;
    }
    if (zeitfenster[slot] != null) {
        return false;
    }
    zeitfenster[slot] = new Buchung(gruppe, personen);
    return true;
}

Mit dieser Fassung liefern T1 bis T9 genau die erwarteten Ergebnisse.

Pro: Alle drei beginnen sofort, niemand wartet; der Entwurf in Material 4 legt die Attribute bereits fest. Ein gemeinsamer Test am Ende zeigt, ob das Gesamtsystem aus Sicht der Nutzer funktioniert.

Contra: „Jeder programmiert seine Klasse so, wie er sie braucht“ bedeutet, dass es keine vereinbarte Schnittstelle gibt. Material 4 enthält für Raum außer getName keine Methoden; Jannik und Sofia würden Methoden aufrufen, die Aylin anders benennt oder anders festlegt (etwa Rückgabe void statt Wahrheitswert). Solche Fehler zeigen sich erst beim Zusammenfügen und verursachen dann großen Nacharbeitsaufwand. Testen erst am Ende über die Oberfläche macht die Fehlersuche schwer: Ein falsches Ergebnis kann aus jeder der drei Klassen stammen. Die Fehler aus c) wären schon mit einem Test der einzelnen Klasse sofort aufgefallen. Zudem hängt der Test von Sofias Oberfläche ab – verzögert sie sich, verzögert sich jeder Test.

Ergebnis: Der Vorschlag ist in dieser Form abzulehnen. Sinnvoll ist, zuerst gemeinsam die Schnittstellen (wie in a) festzulegen und Testfälle (wie in b) aus den Anforderungen abzuleiten. Danach können die drei tatsächlich parallel arbeiten, jede Klasse wird für sich getestet, und der Gesamttest am Ende ist nur noch eine Ergänzung.