**Dies ist eine alte Version des Dokuments!**
Aufgabe: Klassendiagramm entwerfen
Du sollst ein System fĂĽr eine Bibliothek modellieren. Folgende Anforderungen sind gegeben:
- Eine Bibliothek verwaltet mehrere BĂĽcher.
- Jedes Buch hat einen Titel, Autor, ISBN und Status (verfĂĽgbar/verliehen).
- Ein Benutzer kann BĂĽcher ausleihen.
- Die Klasse Ausleihe dokumentiert, welches Buch wann von welchem Benutzer ausgeliehen wurde.
Aufgabenstellung:
- Entwirf ein UML-Klassendiagramm mit allen relevanten Klassen, Attributen und Beziehungen.
- Kennzeichne die Sichtbarkeit der Attribute.
- Welche Klasse sollte Methoden enthalten – z. B. ausleihen() oder zurückgeben()?
Lösung:
Aufgabe : Beziehungstypen erkennen
Gegeben sind folgende Klassen:
- Rechnung
- Position
- Produkt
Beschreibung:
- Eine Rechnung besteht aus mehreren Positionen.
- Jede Position bezieht sich auf genau ein Produkt.
- Ein Produkt kann auf mehreren Rechnungen erscheinen.
Aufgabenstellung:
- Zeichne das Klassendiagramm mit den passenden Beziehungstypen.
- Welche Beziehung besteht zwischen Rechnung und Position? Aggregation oder Komposition?
- Wie würde sich die Modellierung ändern, wenn Position ohne Rechnung nicht existieren kann?
Lösung
1) Klassendiagramm (mit Beziehungstypen & Multiplizitäten)
Empfohlen (fachlich korrekt: Komposition zwischen Rechnung und Position):
Hinweis: Dadurch ergibt sich indirekt eine n:m-Beziehung zwischen Rechnung und Produkt (ĂĽber Position).
2) Aggregation oder Komposition?
Komposition. Positionen sind Teil der Rechnung (Lebenszyklus gebunden); löscht man die Rechnung, verschwinden die Positionen.
3) Wenn Position ohne Rechnung nicht existieren kann …
… dann ist genau das die Komposition (gefüllter Diamant).
Falls du zuvor Aggregation modelliert hattest, tausche einfach o-- gegen *-- aus:
Alternative (Aggregation, nur falls Positionen eigenständig existieren dürften):
Aufgabe 06.10.2025
b) Assoziation vs. Aggregation (am Ticketsystem erklärt)
- Assoziation: Eine lose Beziehung zwischen zwei Klassen ohne „Ganze-Teil“-Semantik.
- Beispiel: Mitarbeiter — erstellt — Supportanfrage. Ein Mitarbeiter kann viele Anfragen erstellen; die Objekte existieren unabhängig voneinander. Aggregation (leere Raute „o–“): „Ganze-Teil“ mit geteilter Lebensdauer (Teil kann auch ohne Ganzes existieren).
- Beispiel: Abteilung o– Mitarbeiter. Eine Abteilung *umfasst Mitarbeiter, aber Mitarbeiter können unabhängig existieren bzw. in eine andere Abteilung wechseln. (Keine Komposition, weil das Leben des Mitarbeiters nicht von der Abteilung abhängt.)
# c) 1:n oder m:n zwischen „Mitarbeiter“ und „Supportanfrage“?
- Begründet 1:n: In den Anforderungen steht, dass jeder Mitarbeiter mehrere Supportanfragen stellen kann und eine Supportanfrage von einem Mitarbeiter stammt (Ersteller). Damit: Mitarbeiter 1 — n Supportanfrage.
- Wann m:n? Nur wenn das Domänenmodell erlauben würde, dass mehrere Mitarbeiter gemeinsam als Ersteller derselben Anfrage gelten (z. B. Co-Ersteller oder Ticket-Übernahme als „Erstellerrolle“), was hier nicht gefordert ist. Deshalb ist 1:n korrekt und einfacher.