Abituraufgaben: Klassendiagramm entwerfen

(1) → Anbieter mit * Stationen; (2) „bis zu zehn“ → 0..10, Reihung der Länge 10; (3) Attribute von Fahrzeug; (4) „sind Fahrzeuge“ → EAuto erbt von Fahrzeug; (5) Attribute von Kunde; (6) Buchung → 1 Kunde, → 1 Fahrzeug, Attribut minuten, Methode kosten(); (7) Kunde → * Buchung, also ist die Beziehung Kunde–Buchung in beide Richtungen navigierbar. Bewertet: sechs Klassen (2 BE), Vererbung (1 BE), fünf Assoziationen mit Kardinalitäten und Richtung (3 BE), Attribute/Methoden (1 BE).

Elektroautos: Ein Elektroauto ist ein Fahrzeug und hat alle seine Eigenschaften; nur der Akkustand kommt hinzu. Als Unterklasse erbt EAuto Kennzeichen, Preis und getPreisProMinute(); Stationen und Buchungen können mit dem Typ Fahrzeug arbeiten und nehmen trotzdem Elektroautos auf. Ein Attribut akkustand in Fahrzeug wäre bei Verbrennern sinnlos. Buchung und Kunde: Die Buchung speichert eine Referenz auf das Kunden-Objekt statt Name oder Führerscheinnummer — so ist der Kunde eindeutig und direkt erreichbar. Weil (7) verlangt, dass der Kunde seine Buchungen kennt, gibt es zusätzlich die Rückrichtung; beide Seiten müssen gemeinsam gesetzt werden (siehe c).

public class Buchung {
    private Kunde kunde;
    private Fahrzeug fahrzeug;
    private int minuten;

    public Buchung(Kunde kunde, Fahrzeug fahrzeug, int minuten) {
        this.kunde = kunde;
        this.fahrzeug = fahrzeug;
        this.minuten = minuten;
        kunde.hinzufuegen(this);      // Kunde kennt seine Buchungen
    }
    public double kosten() {
        return minuten * fahrzeug.getPreisProMinute();
    }
}

Bewertet: Attribute (1 BE), Konstruktor (1 BE), Eintragen beim Kunden mit this (2 BE), kosten() über die Referenz auf das Fahrzeug (1 BE).

Das Elektroauto enthält auch die geerbten Attribute. b.kosten() = 45 · 0,30 = 13,5.

(1) Namen statt Referenzen: bandname, buehnennummer, kaeufer sind Zeichenketten bzw. Zahlen. Tippfehler führen zu Bands, die es nicht gibt; ändert eine Band ihren Namen, müssen alle Auftritte geändert werden; weitere Daten der Band sind nicht erreichbar. (2) Doppelte Attribute: preis und kaeufer stehen in beiden Ticketklassen — gemeinsame Methoden müssten doppelt programmiert werden, eine Liste „aller Tickets“ ist nicht möglich. (3) Fehlende Beziehung: Das Festival kennt seine Auftritte nicht, nur eine Liste von Bandnamen; ein Programm kann das Line-up gar nicht durchlaufen. Weitere mögliche Punkte: Käufer als Zeichenkette statt eigener Klasse Person.

Außerdem: Festival → * Buehne, Auftritt → 1 Buehne.

Bewertet: Band und Person als Klassen mit Referenzen (2 BE), Oberklasse Ticket mit Vererbung (2 BE), Assoziationen mit Kardinalitäten 1 und * (2 BE).

public int auftritteVon(Band b) {
    int anzahl = 0;
    for (int i = 0; i < auftritte.size(); i++) {
        if (auftritte.get(i).getBand() == b) {
            anzahl++;
        }
    }
    return anzahl;
}

Test: Tritt die Band „Echo“ an zwei von drei geplanten Auftritten auf, liefert die Methode 2. Der Vergleich mit == ist hier richtig, weil es für jede Band genau ein Objekt gibt.

Ticket kennt Person: Bei der Einlasskontrolle wird ein Ticket gescannt und der Name des Käufers mit dem Ausweis verglichen — dafür muss man vom Ticket zur Person navigieren. Die Anforderung „kennt seinen Käufer“ verlangt genau diese Richtung. Person kennt Tickets: Sinnvoll für eine Ansicht „Meine Tickets“ oder zum Stornieren, sonst müsste man alle Tickets durchsuchen. Beides zusammen macht die Beziehung bidirektional und erfordert, dass beim Kauf beide Seiten gesetzt werden. Fazit: Pflicht ist die Richtung Ticket → Person; die Gegenrichtung nur, wenn eine Funktion sie wirklich braucht — jede zusätzliche Richtung ist eine Fehlerquelle. Aus Datenschutzsicht spricht für Sparsamkeit zudem, dass eine Person-Klasse mit allen Tickets ein vollständiges Kaufprofil darstellt.