Übungsaufgaben zu Klassenbeziehungen: Assoziation, Aggregation, Komposition und Multiplizitäten

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 „Klassenbeziehungen: Assoziation,
Aggregation, Komposition und Multiplizitäten“.

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/uml-klassendiagramm-assoziation
- https://oer-informatik.de/uml-klassendiagramm
- https://oer-informatik.de/uml-klassendiagramm-vererbung
- https://oer-informatik.de/uml-klassendiagramm-interface-abstraktion
- https://oer-informatik.de/uml-objektdiagramm
- Stilbeispiel: https://oer-informatik.de/uml-klassendiagramm-assoziation-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- UML-Klassendiagramm
- Assoziation
- Aggregation
- Komposition
- Multiplizität
- Rollennamen
- Objektdiagramm
- Beobachter

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.

Punkteverteilung (Vorschlag):

• 6 Punkte: je Klasse 1 Punkt für Namen und passende Attribute mit Datentyp (bei Session einschließlich freiePlaetze(): Integer).

• 13,5 Punkte: neun Beziehungen mit je 0,5 Punkten für die richtige Art und 1 Punkt für beide Multiplizitäten:

  Beziehungen der Beispiellösung

  Beziehung	Art	Multiplizitäten
  Veranstaltung – Slot	Komposition (Raute an Veranstaltung)	1 – 5
  Veranstaltung – Raum	Aggregation (Raute an Veranstaltung)	0..* – 1..*
  Veranstaltung – Session	Komposition (Raute an Veranstaltung)	1 – 0..*
  Slot – Session	Assoziation	0..1 – 0..8
  Raum – Session	Assoziation	0..1 – 0..*
  Person – Session (halten)	Assoziation	1..3 – 0..*
  Person – Session (buchen)	Assoziation	0..* – 0..*
  Session – Feedback	Komposition (Raute an Session)	1 – 0..*
  Session – Session (Fortsetzung)	Assoziation (Selbstbeziehung)	0..1 – 0..1

• 1,5 Punkte: Rollennamen für die beiden Assoziationen zwischen Person und Session (z. B. referierende/gehalteneSessions und teilnehmende/gebuchteSessions) sowie für die Selbstbeziehung (vorgaenger/fortsetzung).

Bewertungshinweise:

• Zwischen Feedback und Person darf keine Beziehung bestehen, weil das Feedback anonym ist. Eine solche Linie kostet 0,5 Punkte.

• Die Regel „je Slot höchstens eine Buchung“ lässt sich mit Multiplizitäten nicht ausdrücken. Wer sie als Einschränkung in geschweiften Klammern notiert (z. B. Notiz {höchstens eine gebuchte Session je Slot}), zeigt Sorgfalt; Punkte gibt es dafür nicht extra. Die Multiplizität 0..5 bei gebuchteSessions ist nur richtig, wenn Personen je Veranstaltung neu angelegt werden – die Notiz sagt aber, dass die Software für mehrere Veranstaltungen genutzt wird.

• Wer Veranstaltung – Session als einfache Assoziation zeichnet, verliert 0,5 Punkte (Art), wenn die Multiplizitäten stimmen.

• Attribute für die Beziehungen (z. B. -slots: Slot[5]) sind nicht nötig. Wer sie zusätzlich angibt, macht keinen Fehler.

• 0..1 steht am Ende von Slot und wird aus Sicht einer Session gelesen: Eine Session ist keinem oder genau einem Slot zugeordnet. Null gilt für eine eingereichte, noch nicht eingeplante Session; nach der Planung liegt sie in genau einem Slot. (1,5 Punkte)

• 0..8 steht am Ende von Session und wird aus Sicht eines Slots gelesen: In einem Slot finden mindestens keine und höchstens acht Sessions statt, weil es nur acht Räume gibt. (1,5 Punkte)

Eine Multiplizität steht immer an der Klasse, deren Anzahl sie angibt – also gegenüber der Klasse, aus deren Sicht man liest.

• Komposition Veranstaltung – Slot (2 Punkte): Beide Fälle sind Teil-Ganzes-Beziehungen. Ein Slot ist aber existenzabhängig: Er wird mit der Veranstaltung angelegt und mit ihr gelöscht, seine Lebensdauer ist also an die Veranstaltung gebunden. Außerdem gehört jeder Slot zu genau einer Veranstaltung (Multiplizität 1 am Ganzen).

• Aggregation Veranstaltung – Raum (2 Punkte): Räume gehören dem Berufskolleg und werden in der Raumverwaltung gepflegt. Sie existieren vor der Veranstaltung und weiter, wenn sie gelöscht wird, und sie können gleichzeitig zu mehreren Veranstaltungen gehören (Multiplizität 0..* am Ganzen). Eine Komposition ist deshalb nicht möglich.

Ein Rollenname beschreibt, welche Rolle die Objekte am jeweiligen Ende einer Assoziation spielen (z. B. Personen als referierende einer Session). Weil zwischen Person und Session zwei Beziehungen mit unterschiedlicher Bedeutung und unterschiedlichen Multiplizitäten bestehen (halten und buchen), lassen sich die Linien ohne Rollennamen nicht unterscheiden. In der Programmierung werden die Rollennamen meist zu den Namen der Referenzattribute (z. B. referierende, gebuchteSessions). (je 1 Punkt)

Die Multiplizität 0..8 legt im Klassendiagramm fest, welche Anzahlen zulässig sind (die Menge aller erlaubten Werte 0 bis 8). Die Kardinalität ist in der UML die tatsächliche Anzahl der Verbindungen eines bestimmten Objekts: Für Slot 3 beträgt sie 7. (je 1 Punkt)

Hinweis: In der Datenbankmodellierung und in vielen Aufgaben wird „Kardinalität“ gleichbedeutend mit Multiplizität verwendet. Ist dort nach Kardinalitäten im Klassendiagramm gefragt, sind die Multiplizitäten gemeint.

Je Anmerkung 1 Punkt für die richtige Einschätzung und 1 Punkt für eine Begründung, die die Notation (Raute, Multiplizität, Pfeilspitze) richtig deutet.

• Linienende: Aus der hohlen Raute wird eine gefüllte Raute an Schliessanlage (Komposition), weil die Schlösser dann existenzabhängig sind: Sie entstehen mit der Schließanlage und werden mit ihr entfernt. (1,5 Punkte)

• Multiplizität am Ganzen: Aus 0..1 wird 1, denn ein Schloss ohne Schließanlage gibt es nicht mehr. Die Multiplizität 1..* am Ende von Schloss bleibt. (1 Punkt)

• Folge für den Quelltext: Die Schließanlage erzeugt ihre Schlösser dann selbst (etwa mit einer Methode schlossAnlegen(art, seriennummer)), statt fertige Schloss-Objekte von außen zu übernehmen. (0,5 Punkte)

• Bestellung erzeugt ihre Bestellpositionen selbst (new Bestellposition(…) in positionHinzufuegen) und gibt keine Referenz darauf nach außen. Nur die Bestellung kennt ihre Positionen; sie leben und vergehen mit ihr → Komposition. (1,5 Punkte)

• Schliessanlage bekommt ein Schloss, das außerhalb erzeugt wurde, als Parameter übergeben (hinzufuegen(Schloss schloss)). Andere Programmteile behalten eine Referenz auf dasselbe Objekt (buegel), das Schloss kann also unabhängig von der Schließanlage weiterleben → Aggregation. (1,5 Punkte)

• Entfernt werden dürfen: das Schliessanlage-Objekt (nach Zeile 7 zeigt keine Referenz mehr darauf), das Bestellung-Objekt und mit ihm das intern erzeugte Bestellposition-Objekt, denn nur die Bestellung hat darauf verwiesen. Die Lebensdauer des Teils endet mit dem Ganzen (Komposition). (1,5 Punkte)

• Weiter erreichbar sind: das Schloss-Objekt über die Variable buegel – es überlebt das Ende der Schließanlage (Aggregation) – und der Artikel über lastenrad und den Katalog. Dass die Bestellposition den Artikel referenziert hat, ändert daran nichts. (1,5 Punkte)

Hinweis: In Java wird kein Objekt ausdrücklich gelöscht; ein Objekt „stirbt“, sobald es nicht mehr erreichbar ist. In Sprachen wie C++ müsste das Ganze seine Teile im Destruktor selbst freigeben.

Je Zeile 0,5 Punkte für die Beziehungsart und 0,5 Punkte für die Notation.

1. b2 hat keine Bestellposition, laut Klassendiagramm braucht jede Bestellung mindestens eine (1..*).

2. c1 ist mit p1 und p2 verbunden; als Teil einer Komposition gehört eine Konfiguration zu genau einer Bestellposition (1).

3. p2 ist mit zwei Artikeln (a1, a2) verbunden, erlaubt ist genau ein Artikel (1).

4. s2 gehört zu den Schließanlagen sa1 und sa2, erlaubt ist höchstens eine (0..1).

Je richtig benanntem Verstoß 1 Punkt. Die Kardinalitäten (tatsächliche Anzahlen der Links) liegen an diesen Stellen außerhalb der Multiplizität. Alle übrigen Verbindungen sind zulässig, z. B. hat sa2 mit einem Schloss die Untergrenze von 1..* gerade erreicht.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

// in der Klasse Bestellposition
float positionswertNetto() {
    float preis = einzelpreisNetto
    if (konfiguration != null) {
        preis = preis + konfiguration.aufpreisNetto
    }
    return preis * menge
}

// in der Klasse Bestellung
float gesamtNetto() {
    float summe = 0.0
    for (position ∈ positionen) {
        summe = summe + position.positionswertNetto()
    }
    return summe
}

// in der Klasse Bestellposition
FUNCTION positionswertNetto() : real
    preis: real := einzelpreisNetto
    if (konfiguration <> nil) then
        preis := preis + konfiguration.aufpreisNetto
    end if
    RETURN preis * menge
END positionswertNetto

// in der Klasse Bestellung
FUNCTION gesamtNetto() : real
    summe: real := 0.0
    foreach position in positionen
        summe := summe + position.positionswertNetto()
    next position
    RETURN summe
END gesamtNetto

// in der Klasse Bestellposition
Funktion positionswertNetto(): double
    preis: double := einzelpreisNetto
    wenn konfiguration <> null dann
        preis := preis + konfiguration.aufpreisNetto
    Ende wenn
    Rückgabe preis * menge
Ende positionswertNetto

// in der Klasse Bestellung
Funktion gesamtNetto(): double
    summe: double := 0.0
    für jedes position in positionen
        summe := summe + position.positionswertNetto()
    Ende für
    Rückgabe summe
Ende gesamtNetto

# in der Klasse Bestellposition
def positionswertNetto(self):  # Rückgabe: Gleitkommazahl
    preis = self.einzelpreisNetto
    if self.konfiguration != None:
        preis = preis + self.konfiguration.aufpreisNetto
    # Ende if
    return preis * self.menge
# Ende positionswertNetto

# in der Klasse Bestellung
def gesamtNetto(self):  # Rückgabe: Gleitkommazahl
    summe = 0.0
    for position in self.positionen:
        summe = summe + position.positionswertNetto()
    # Ende for
    return summe
# Ende gesamtNetto

Punkteverteilung: positionswertNetto 2 Punkte (Prüfung auf fehlende Konfiguration 1 Punkt, Berechnung und Rückgabe 1 Punkt); gesamtNetto 2 Punkte (Schleife über alle Positionen 1 Punkt, Aufsummieren und Rückgabe 1 Punkt).

Die Aufteilung folgt den Beziehungen: Jedes Ganze fragt nur seine direkten Teile. Wer konfiguration über einen Getter aus der Position herausholt, bekommt ebenfalls volle Punktzahl, wenn die Rechnung stimmt.

• Klassen mit Attributen und Methoden, Eintrag abstrakt (kursiv bzw. {abstract}) mit abstrakter Methode monitortext(), Anzeigeziel als <<interface>>: 3 Punkte

• Komposition Angebotsboerse (gefüllte Raute) – Eintrag mit 1 und 0..*: Die Börse erzeugt ihre Einträge selbst mit new und gibt sie nicht heraus, sie werden mit ihr gelöscht. 2 Punkte

• Aggregation Angebotsboerse (hohle Raute) – Anzeigeziel mit 0..* und 0..*: Die Ziele werden außerhalb erzeugt und über anmelden(…) übergeben, bestehen unabhängig und können bei zwei Börsen gleichzeitig angemeldet sein (0..2 am Ganzen ist ebenfalls richtig). 2 Punkte

• Generalisierung Fahrtangebot und Mitfahrgesuch → Eintrag (durchgezogen, hohles Dreieck) und Realisierung Flurmonitor und PushDienst → Anzeigeziel (gestrichelt, hohles Dreieck): 2 Punkte

Wer an den beiden Beziehungen der Börse zusätzlich eine Pfeilspitze zu Eintrag bzw. Anzeigeziel einzeichnet, liegt ebenfalls richtig: Im Quelltext kennt nur die Börse die anderen Objekte. Die Sichtbarkeit # von grunddaten() und der Konstruktor müssen nicht angegeben werden.

Foyer | Einträge: 1
App | neu: Angebot 07:05 Busbahnhof Bad Salzuflen, 3 Plätze frei
Foyer | Einträge: 2
Parkplatz | Einträge: 2

Beim Angebot sind der Foyer-Monitor und der Push-Dienst angemeldet (in dieser Reihenfolge). Vor dem Gesuch kommt der Parkplatz-Monitor hinzu, der Push-Dienst meldet sich ab; beide Monitore erhalten jetzt die Liste mit zwei Texten. (3 Punkte, je Zeile 0,75 Punkte)

Die Börse kennt nur das Interface Anzeigeziel. Welche Implementierung von aktualisieren(…) läuft, entscheidet sich erst zur Laufzeit am tatsächlichen Objekt in der Liste (Flurmonitor oder PushDienst), also durch Polymorphie bzw. späte Bindung. Ebenso wählt eintrag.monitortext() die Methode des jeweiligen Fahrtangebots bzw. Mitfahrgesuchs. (2 Punkte)

• Neu ist eine Klasse wie EMailVerteiler (Attribut z. B. adresse), die das Interface Anzeigeziel realisiert (gestrichelte Linie mit hohlem Dreieck) und aktualisieren(texte) implementiert. Ein Objekt davon wird mit anmelden(…) bei der Börse angemeldet. (2 Punkte)

• Die Börse hat ihre Aggregation nur zum Interface Anzeigeziel, nicht zu einer konkreten Klasse. Jedes Objekt, das das Interface realisiert, kann in ihrer Liste stehen und wird beim Benachrichtigen gleich behandelt. Die Börse ist also nur lose an die Anzeigeziele gekoppelt; neue Ziele lassen sich ergänzen, ohne dass sich an ihr etwas ändert. (2 Punkte)

• Datenschutz: Die Anzeigeziele bekämen die Eintrags-Objekte selbst und damit Zugriff auf alles, was ein Eintrag enthält oder später enthalten wird. Das widerspricht der Festlegung, dass nur fertige, anonyme Texte weitergegeben werden (Datenminimierung). (1,5 Punkte)

• Kopplung: Jedes Anzeigeziel hinge dann zusätzlich von Eintrag und seinen Unterklassen ab. Ändert sich die Eintrags-Hierarchie, müssten alle Monitore, der Push-Dienst und künftige Ziele angepasst werden. Mit Texten kennt ein Anzeigeziel nur String. (1,5 Punkte)

Fazit: Der Vorschlag ist abzulehnen. Ein begründetes Urteil mit beiden Gesichtspunkten erhält volle Punktzahl.

Je Fehler 1 Punkt für die Beschreibung und 1 Punkt für die Korrektur. Die Abhängigkeit <<use>> von Monatsstatistik zu Exportformat ist richtig: Die Statistik bekommt das Format nur als Parameter von exportieren(…).