Modul 31751: Diskussion zu Klausur WS2014 (2015-03) mit Lösungsvorschlag

Und die letzte...

Anbei mein Lösungsvorschlag zum Download als zip-file:
Version 1.0
Passwort (ohne Anführungszeichen): "ichmachemit!"

Achtung: Scheinbar zeigt die Windows-Bildanzeige die Grafiken (UML) nicht korrekt an. Ihr müsst Klassen und Assoziationen mitsamt Kardinalitäten vor einem grauen (nicht schwarzen) Hintergrund sehen. Ist das nicht der Fall, verwendet IrfanView oder ein anderes externes Programm.


Anmerkungen zu Aufgabe 1:
Zu beachten war hier, dass Restriktionen bei Assoziationen natürlichsprachlich formuliert werden sollten. Ich habs in meinem Lösungsvorschlag dennoch formal gemacht, weil ich erst danach draufgekommen bin.
Mich irritiert nach wie vor die Angabe

...und geben Sie für jedes Attribut einen Datentyp (Boolean, Integer, Float, String und Date seien gegeben) an.

Das heißt, NUR diese Datentypen oder UNTER ANDEREM diese Datentypen? Bei der FSK-Abfrage gehört beispielsweise ein enum hin. Alles andere verursacht Augenkrebs. Leider tut sich im Moodle-Forum rein gar nichts, der Lehrstuhl antwortet auf kaum auf Anfragen.
In meinem Modell habe ich relativ viele Klassen, das ginge wahrscheinlich auch mit weniger, dafür hätte man aber mehr redundante Methoden. Die Klasse Benutzerhandlung habe ich eingeführt, weil beide Kinderklassen diesselben Methoden benutzen. Außerdem habe ich zwischen Benutzer und Benutzerhandlung eine Komposition gewählt, weil die Benutzerhandlung ohne Benutzer nicht exisitieren kann.
Bei den meisten Kardinalitäten bleibt m.E. sehr viel Interpretationsspielraum. Aber das kennt man ja.
Insgesamt ist das Modell noch nicht sauber (Primärschlüssel und Schlüsselattribute etc.), aber das wird m.E. auch nicht gefordert.

Update 29.8.2015:
Lt. der Klausuraufgabe soll bei den Adressen jegliche Redundanz vermieden werden. Ich habe den Adressteil ursprünglich (Version 1.0) dennoch in die Benutzerklasse intergriert, weil ich keinen Grund sah, dafür extra eine eigene Klasse anzulegen. Jeder Benutzer hat eine eigene Adresse und ohne Benutzer keine Adresse. Was ich dabei aber übersehen habe: Es kann mehrere Benutzer mit derselben Adresse geben. Dann hätte man natürlich Redundanzen drin. Adresse muss also eine eigene Klasse werden.

Anmerkungen zu Aufgabe 2a:
Attribute sind nicht zu modellieren. Die einzige Schwierikeit hier war zu differenzieren zwischen Attribut und Entity. Die unterschiedlichen Prüfungen hatte ich anfangs als Attribut "Prüfungsart" modelliert, aber das wäre dann doch zu einfach gewesen.