Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- allgemein:test:uebungsaufgaben [06.10.2025 10:26] – [Aufgabe 06.10.2025] lars
+++ allgemein:test:uebungsaufgaben [06.10.2025 11:09] (aktuell) – [Aufgabe 06.10.2025] lars
@@ Zeile 138: / Zeile 138: @@
 ## Aufgabe 06.10.2025
-Gern! Hier ist eine kompakte, punktetaugliche Lösung inkl. sauberem Mermaid-Klassendiagramm (läuft mit aktuellen Mermaid-Versionen und DokuWiki-Plugin).
 <mermaid>
 classDiagram
-direction LR
 class Abteilung {
-  +abteilungsId: int
+  +abteilungsId : int
-  +name: string
+  +name : string
 }
 class Mitarbeiter {
-  +mitarbeiterId: int
+  +mitarbeiterId : int
-  +vorname: string
+  +vorname : string
-  +nachname: string
+  +nachname : string
-  +email: string
+  +email : string
 }
 class Techniker {
-  +technikerId: int
+  +technikerId : int
-  +skillset: string
+  +skillset : string
-  +telefonDurchwahl: string
+  +telefonDurchwahl : string
 }
 class Supportanfrage {
-  +ticketNr: string
+  +ticketNr : string
-  +status: Status
+  +status : string
-  +erstelltAm: DateTime
+  +erstelltAm : Date
-  +kurzbeschreibung: string
+  +kurzbeschreibung : string
 }
-class Status <<enumeration>> {
+Abteilung "1" o-- "0..*" Mitarbeiter : umfasst
-  OFFEN
+Mitarbeiter "1..*" --> "0..*" Supportanfrage : erstellt
-  IN_BEARBEITUNG
+Supportanfrage "0..*" o-- "0..1" Techniker : zugewiesenAn
-  WARTEND
-  GESCHLOSSEN
-}
-%% Generalisierung
 Mitarbeiter <|-- Techniker
-%% Aggregation Abteilung–Mitarbeiter
-Abteilung "1" o-- "0..*" Mitarbeiter : umfasst
-%% Assoziation Mitarbeiter–Supportanfrage (Ersteller)
-Mitarbeiter "1" --> "0..*" Supportanfrage : erstellt
-%% Assoziation Supportanfrage–Techniker (Zuweisung)
-Supportanfrage "1" --> "1" Techniker : zugewiesenAn
-%% Verwendungsbeziehung Status (Typattribut)
-Supportanfrage ..> Status : verwendet
 </mermaid>
 # b) Assoziation vs. Aggregation (am Ticketsystem erklärt)
-* **Assoziation**: Eine lose Beziehung zwischen zwei Klassen ohne „Ganze-Teil“-Semantik.
+  * **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).
+  * **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**.
+  * **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.
+  * **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.