Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- allgemein:test:uebungsaufgaben [02.10.2025 12:27] – lars
+++ allgemein:test:uebungsaufgaben [06.10.2025 11:09] (aktuell) – [Aufgabe 06.10.2025] lars
@@ Zeile 1: / Zeile 1: @@
- **Aufgabe 2: Klassendiagramm entwerfen**
+[[..:start|zurück]]
+**Aufgabe: Klassendiagramm entwerfen**
 Du sollst ein System für eine Bibliothek modellieren. Folgende Anforderungen sind gegeben:
   * Eine Bibliothek verwaltet mehrere Bücher.
@@ Zeile 75: / Zeile 78: @@
 Benutzer "1" --> "0..*" Ausleihe
 </mermaid>
+----
+**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):**
+<mermaid>
+classDiagram
+class Rechnung
+class Position
+class Produkt
+Rechnung "1" *-- "1..*" Position
+Position "0..*" --> "1" Produkt </mermaid>
+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):** <mermaid>
+classDiagram
+class Rechnung
+class Position
+class Produkt
+Rechnung "1" o-- "1..*" Position
+Position "0..*" --> "1" Produkt </mermaid>
+----
+## Aufgabe 06.10.2025
+<mermaid>
+classDiagram
+class Abteilung {
+  +abteilungsId : int
+  +name : string
+}
+class Mitarbeiter {
+  +mitarbeiterId : int
+  +vorname : string
+  +nachname : string
+  +email : string
+}
+class Techniker {
+  +technikerId : int
+  +skillset : string
+  +telefonDurchwahl : string
+}
+class Supportanfrage {
+  +ticketNr : string
+  +status : string
+  +erstelltAm : Date
+  +kurzbeschreibung : string
+}
+Abteilung "1" o-- "0..*" Mitarbeiter : umfasst
+Mitarbeiter "1..*" --> "0..*" Supportanfrage : erstellt
+Supportanfrage "0..*" o-- "0..1" Techniker : zugewiesenAn
+Mitarbeiter <|-- Techniker
+</mermaid>
+# 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.