🖥️ Veni. Vidi. sudo rm -rf / vici.

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
allgemein:test:uebungsaufgaben

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Ăśberarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
allgemein:test:uebungsaufgaben [02.10.2025 14:01] – larsallgemein:test:uebungsaufgaben [06.10.2025 11:09] (aktuell) – [Aufgabe 06.10.2025] lars
Zeile 90: Zeile 90:
  
 Beschreibung: Beschreibung:
-  +
   * Eine Rechnung besteht aus mehreren Positionen.   * Eine Rechnung besteht aus mehreren Positionen.
   * Jede Position bezieht sich auf genau ein Produkt.   * Jede Position bezieht sich auf genau ein Produkt.
Zeile 100: Zeile 100:
   2. Welche Beziehung besteht zwischen Rechnung und Position? Aggregation oder Komposition?   2. Welche Beziehung besteht zwischen Rechnung und Position? Aggregation oder Komposition?
   3. Wie wĂĽrde sich die Modellierung ändern, wenn Position ohne Rechnung nicht existieren kann?   3. 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. 
  
allgemein/test/uebungsaufgaben.1759406487.txt.gz · Zuletzt geändert: von lars