Sonntag, 23. August 2015

Modul 31751: Diskussion zu Klausur SS2014 (2014-09) mit Lösungsvorschlag

Noch eine Klausur...

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.


Anmerkung zu Aufgabe 1: 
Die Angaben waren hier eigentlich sehr einleuchtend. Etwas kniffelig war der Brückenschlag Bestellung - Lieferung mit Einhaltung der Lieferfristen und Feststellung der Fristüberschreitung. Die Kardinalitäten der Assoziationen waren auch relativ intuitiv modellierbar, d.h. frei nach dem Motto: Was macht Sinn?
Diesmal waren in den Klausurangaben die Datentypen auf boolean, int, float, string, date beschränkt. Ich habe bei den Aggregatzuständen dennoch enum gewählt, weil es sich einfach mehr als aniebetet. Alternativ könnte man auch jeden einzelnen Aggregatzustand als boolean definieren oder ein Attribut Aggregatzustand überhaupt nur als String. Möglich ist vieles, am besten passt m.E. aber enum. Bei der Klausur hätte ich hier wohl einen Vermerk gemacht. Selbiges dann auch bei Verderblichkeit und Lagerfähigkeit.
Die Rekursion beim Fremdgut war prinzipiell klar. Ich tue mir aber immer etwas schwer, was die Beschriftung betrifft. Hier gibts ja keinen Assoziationsnamen, sondern Rollen. Ich habe hier als Rollen Oberteil und Unterteil gewählt. Ein Fremdgut besteht als Oberteil aus * Unterteilen (also aus keinem, einem oder mehreren). Ein Fremdgut kann als Unterteil Bestandteil von 0..1 Oberteilen sein (außer sich selbst). Oder anders gesagt: Ein Fremdgut kann aus mehreren anderen FG bestehen und selbst Teil eines oder keines anderen FGsein.
Bei Skontohöhe und Treuerabatt scheint es darauf anzukommen, OB es Skonto/Rabatt gibt und wie hoch diese dann sind. Meiner Meinung nach ist die OB-Abfrage aber sinnlos, denn ein Skonto oder Rabatt von 0% implizieren das ja ohnehin. Ich habe hier also keinen boolean o.ä. eingebaut.
IDs und keys von Klassen, wo es nicht extra spezifiziert wurde, habe ich diesmal nicht dazumodelliert. Weiß jemand, ob dies bei der Klausur gefordert wird?
Leserichtungen der Assoziationen kann ich mit argoUML irgendwie nicht eingeben. Scheint wohl auch nicht vorgesehen zu sein.

Anmerkung zu Aufgabe 2a:
Hier bereitete mir der Zusatz
"Zu berücksichtigen ist allerdings, dass der rechnungsempfangende Kunde von dem Kunden, der die Buchung getätigt hatte, abweichen kann
Schwierigkeiten.Was heißt das?
- Jede Rechnung hat genau einen Rechnungsempfänger (1)
- Jeder Rechnungsempfänger kann eine oder mehrere Rechnungen bekommen (m)
- Jeder Rechnungsempfänger ist ein Kunde (1)
- Jeder Kunde kann ein Rechnungsempfänger sein oder nicht (c)
- Nicht jeder buchende Kunde ist ein Rechnungsempfänger
Im ER-Diagramm ist das bei mir ein Kreisschluss geworden. Das ginge sicherlich auch über eine Rekursion, aber ich komm da jetzt nicht drauf.
Ausnahmesweise habe ich hier die Attribute mitmodelliert. Muss man nicht.

Anmerkung zu Aufgabe 3a:
Die Zeilen mit Häckchen stimmen definitiv (waren Teil meiner EA in diesem Semester).

Anmerkung zu Aufgabe 3b:
Die Modellierung des GP-Modells finde ich - bei ordentlich und eindeutig formulierter Aufgabenstellung!!! - am einfachsten in der Klausur. Bei diesem Beispiel war es nur nach dem GPS7 etwas komplexer, wo mehrere Funktionslinien mit UND und XOR parallel liefen.

Kommentare:

  1. Ich schon wieder :-)
    Habe mich soeben mal mit Aufgabe 1 befasst. Das Schöne ist das wir grundlegend mal wieder übereinstimmen. Ein paar Fragen/Anmerkungen habe ich dennoch:
    Ich habe den von dir erwähnten boolean bei Skonto und Treuerabatt mit aufgenommen. Der Grund: Bietet ein Lieferant zum Beispiel Skonto an (2%), aber keinen Treuerabatt (0%) würde sich durch die Multiplikation ja zwangsweise ein Wert von Null ergeben. Daher halte ich diese Vorabfrage durchaus für sinnvoll.
    Dann ist mir aufgefallen das du in der Klasse Fremdgut die Operation ermittleTransportbedingungen() angibst und das auch in allen Unterklassen tust. Gibt es dafür einen Grund?
    Bei der Bestellung habe ich es bei bei einer Operation für bestimmeFristüberschreitung() belassen, das ist aber sicherlich Geschmackssache.

    Das war es aber auch im Großen und Ganzen.

    LG Florian

    AntwortenLöschen
    Antworten
    1. Zitat: "Bietet ein Lieferant zum Beispiel Skonto an (2%), aber keinen Treuerabatt (0%) würde sich durch die Multiplikation ja zwangsweise ein Wert von Null ergeben. Daher halte ich diese Vorabfrage durchaus für sinnvoll."

      Ja, kann man sicher so argumentieren. Aber da bist du schon eher beim Programmieren als beim Modellieren. Genausogut könnte ich später im Code schreiben "Wenn (Skonto != 0) oder (Rabatt != 0), dann.." und schon wäre dieses Problem gelöst und du sparst dir ein Attribut, dessen Wert du ja auch abfragen müsstest ("Wenn (Rabatt = FALSE)..."). Ich persönlich bleibe lieber bei weniger Attributen.

      Zitat: "Dann ist mir aufgefallen das du in der Klasse Fremdgut die Operation ermittleTransportbedingungen() angibst und das auch in allen Unterklassen tust. Gibt es dafür einen Grund?"

      Naja, ich habe zwar eine abstrakte Klasse Fremdgut, aber nicht automatisch eine _abstrakte_ Methode ermittleTransportbedingungen() in dieser Klasse. Da aber die Berechnung der Transportbedingungen jeweils ganz anders ist, wird in den Subklassen die Methode überschrieben.

      Bei Modellieren habe ich kurz überlegt, die Methode in der Klasse Fremdgut einfach als abstract zu deklarieren, denn wenn ich mich richtig erinnere, dann müssen Subklassen von abstrakten Klassen alle abstrakten Methoden/Attribute der Superklasse implementieren, um nicht selbst abstrakt zu sein. In diesem Fall hätte ich das Überschreiben wohl nicht mehr extra unterstreichen müssen. Aber selbst da bin ich mir nicht ganz sicher, wie man dass korrekt modellieren müsste (mit/ohne Methoden in den Subklassen)? Sicher könnte man da wohl nur sein, wenn man ein Interface einbauen würde. Aber das geht weit über den Lehrstoff aus dem MIS-Skript hinaus, ich habe jedenfalls nichts konkretes dazu gefunden.

      So, das waren meine Überlegungen zum Thema. Bitte korrigiert mich, wenn ich Blödsinn verzapfe (was durchaus sein kann)! OOP liegt auch schon wieder eine Weile zurück.

      MfG,
      Markus

      Löschen
    2. aaaaaaaaaalta, was schreibst du da? sicher, dass du das nicht beruflich machst?

      Löschen
  2. Hallo mal wieder... Ist übrigens sehr schade das das hier scheinbar zum Dialog zwischen uns beiden wird, wirklich sehr sehr schade. Wenn man schon bei enier Studienform wie dieser keine "direkten" Mitstudenten hat, sollte doch jeder froh für eine Plattform wie diese hier sein um sich auszutauschen. Auf Deutsch: Beteiligt Euch!!!

    Aber das nur am Rande.

    Ich habe eine ganz interessante Entdeckung zu Aufgabe 2 gemacht, da wir uns ja schon öfter die Frage stellten wie ausführlich die Modellierung der einzelnen Aufgaben verlangt wird. Ich habe mich nämlich bei der Bearbeitung meiner Einsearbeit zugegebenermaßen sehr sehr kurz gehalten und nun festgestellt das diese Aufgabe ja exakt der aus der Einsendearbeit entspricht. Dabei habe ich dann doch eine beachtliche Punktzahl erwirtschaftet :-) Wie kann ich dir denn am besten mal ein Bild davon zukommen lassen Markus? LG Flo

    AntwortenLöschen
    Antworten
    1. Hi Flo,

      schick mir einfach eine Mail über das Kontaktformular, dann melde ich mich wieder bei dir.

      Die EA habe ich ja auch in diesem Semester bearbeitet, aber aus der Antwort bin ich genau beim kritischen Punkt Kunde-Rechnung-Rechnungsempfänger nicht schlau geworden.

      Bin gespannt auf deine Version.

      MfG
      Markus

      Löschen
    2. Ach ja, was sagst du eigentlich zu meinem Begründungsvorschlag zu deinen Fragen/Anmerungen? Würd' mich interessieren...

      Löschen
    3. Ahh, ok, das bin ich dir noch schuldig.
      Ja, du hast wahrscheinlich recht das ich an der Stelle mit dem Skonto/Rabatt schon wieder zu sehr in der Programmierung war. Liegt wahrscheinlich daran das ich mich damit momentan hobbymäßig viel beschäftige ;-)
      Zu der Vererbung mit den abstrakten Klassen muss ich leider gestehen das ich mich da nochmal in das entsprechende Kapitel einlesen muss, da ich das so wie du es schreibst so noch nicht ganz nachvollziehen kann... Vielleicht habe ich da jetzt auch zu einfach gedacht. Du hast vollkommen Recht damit das die Berechnungen zu unterschiedlich sind um Sie nur in der Oberklasse zu modellieren. Nur nach meinem momentanen Wissensstand könnte man sich dann die Methode in der Oberklasse sparen. Aber da bin ich scheinbar einfach (noch) nicht genug im Thema.
      LG

      Löschen