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

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • uebungsaufgaben
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 12:30] – larsallgemein:test:uebungsaufgaben [06.10.2025 11:09] (aktuell) – [Aufgabe 06.10.2025] lars
Zeile 1: Zeile 1:
- **Aufgabe: Klassendiagramm entwerfen**+[[..:start|zurĂĽck]] 
 + 
 +**Aufgabe: Klassendiagramm entwerfen**
  
 Du sollst ein System fĂĽr eine Bibliothek modellieren. Folgende Anforderungen sind gegeben: Du sollst ein System fĂĽr eine Bibliothek modellieren. Folgende Anforderungen sind gegeben:
Zeile 76: Zeile 78:
 Benutzer "1" --> "0..*" Ausleihe Benutzer "1" --> "0..*" Ausleihe
 </mermaid> </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:**
 +
 +  1. Zeichne das Klassendiagramm mit den passenden Beziehungstypen.
 +  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?
 +
 +**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.1759401001.txt.gz · Zuletzt geändert: von lars