Abituraufgaben: Assoziationen zwischen Klassen

Eine Paketstation kennt über die Rolle faecher höchstens 24 Pakete (0..24, also auch keins); umgesetzt als Reihung der Länge 24, freie Fächer sind null. Ein Paket kennt über empfaenger genau einen Kunden (1, nie null, im Konstruktor gesetzt). Beide Assoziationen sind nur in Pfeilrichtung navigierbar: Ein Paket weiß nicht, in welcher Station es liegt, ein Kunde kennt seine Pakete nicht.

public int abholen(Kunde k) {
    int anzahl = 0;
    for (int i = 0; i < faecher.length; i++) {
        if (faecher[i] != null && faecher[i].getEmpfaenger() == k) {
            faecher[i] = null;
            anzahl++;
        }
    }
    return anzahl;
}

Bewertet: Durchlauf über alle 24 Fächer (2 BE), null-Prüfung vor dem Aufruf mit Kurzschlussauswertung (1 BE), Vergleich des Empfängers (1 BE), Fach freigeben und zählen (1 BE), Rückgabe (1 BE). Ein vorzeitiges return beim ersten Treffer ist falsch, weil ein Kunde mehrere Pakete haben kann.

Die Pakete haben keinen Variablennamen im Programm; die Namen p1–p3 dienen nur dem Diagramm. Zwei Pakete verweisen auf dasselbe Objekt ina. Rückgabewerte: erster Aufruf 2 (Fächer 0 und 5 werden frei), zweiter Aufruf 0.

Kunde bekommt ein Attribut - pakete: DynArray<Paket> (Kardinalität * an der Paket-Seite), die Assoziation wird in beide Richtungen navigierbar. einlegen muss das Paket zusätzlich beim Empfänger eintragen, abholen es dort wieder entfernen. Risiko: Die Informationen liegen jetzt doppelt vor. Vergisst eine Methode eine der beiden Seiten, widersprechen sich Station und Kunde (Paket gilt beim Kunden als eingelagert, ist aber längst abgeholt). Deshalb sollten nur wenige, gut getestete Methoden beide Seiten gemeinsam ändern.

(1) „mindestens einem Wagen“ → 1..*, umgesetzt als dynamische Reihung; (2) „genau 60“ → Kardinalität 60, umgesetzt als Reihung der Länge 60; (3) „frei oder genau einer“ → 0..1 an der Reservierungs-Seite; (4) „kennt ihren Sitzplatz“ → 1 an der Sitzplatz-Seite. Weil Sitzplatz und Reservierung sich gegenseitig kennen müssen, ist diese Assoziation in beide Richtungen navigierbar (Linie ohne Pfeilspitzen). Je 1 BE für jede der vier Beziehungen, 2 BE für sinnvolle Attribute und Methoden.

public int freiePlaetze() {
    int frei = 0;
    for (int w = 0; w < wagen.size(); w++) {
        Wagen wg = wagen.get(w);
        for (int i = 0; i < wg.getAnzahlSitze(); i++) {
            if (wg.getSitz(i).istFrei()) {
                frei++;
            }
        }
    }
    return frei;
}

Test: Ein Zug mit zwei Wagen und zwei Reservierungen liefert 118. Bewertet: äußere Schleife mit size()/get (2 BE), innere Schleife (1 BE), Prüfung und Zählen (1 BE), Rückgabe (1 BE).

Nach dem Aufruf kennt r den Sitzplatz, der Sitzplatz aber nicht die Reservierung: s.istFrei() liefert weiterhin true. Ablauf: reservieren("Lea", w2, 10), danach reservieren("Max", w2, 10) — beide Aufrufe gelingen, der Platz ist doppelt vergeben, und freiePlaetze() zählt ihn trotzdem als frei. Ursache: Bei einer Assoziation in beide Richtungen wurde nur eine Seite gesetzt. Abhilfe: Im Konstruktor der Reservierung sitz.setReservierung(this); ergänzen und in reservieren vorher s.istFrei() prüfen.

Vorteil: einfacher, keine gegenseitigen Referenzen, die konsistent gehalten werden müssen; Anforderung (5) lässt sich damit weiterhin erfüllen. Nachteil: Vom Sitzplatz aus ist nicht mehr feststellbar, wer dort sitzt; beim Stornieren muss man die Reservierung über den Namen suchen, und belegt kann dem Bestand der Reservierungen widersprechen (Datenredundanz auf andere Art). Urteil: Für eine reine Belegungsanzeige genügt der Wahrheitswert; da eine Bahn aber Platzkarten prüfen und stornieren muss, ist die Referenz auf die Reservierung die bessere Modellierung — die Konsistenz sichert man durch eine einzige Methode, die beide Seiten setzt.