unverständliches Klassendiagramm

[marco_90]

Hallo leute,

habe von meinem lehrer ein Klassendiagramm als hausaufgabe bekommen, komme damit aber leider gar nicht klar, ich wollte kurz fragen ob mir jemand sagen kann ob ich es richtig gemacht habe?

Wäre super wenn mir jemand antwortet bzw. hilft, weil ich komm nicht weiter!

Hier die aufgabenstellung:

stellen sie ein uml-klassendiagramm für min. die folgenden klassen auf.

treffen sie gegebenenfalls annahmen, wenn detaillierte informationen fehlen.

bedenken sie auch die attribute der einzelnen klassen zu notieren. ein artikel hat min. einen namen.

unterscheiden sie bei produkten zwischen getränken und speisen, bei getränken muss etwa die menge angegeben werden

kategorie, produkte ( getränke, speisen) preis, kunde, bestellung

meine Lösung habe ich hier mal hochgeladen:

http://img180.imageshack.us/img180/5380/forfachinformatiker.jpg

schonmal vielen dank für die Hilfe im Voraus

[LadyPreis]

habs jetzt nur kurz überflogen... sind also wahrscheinlich nicht alle Fehler hier aufgeführt:

• Du hast überall Vererbungspfeile genutzt. In deinem Beispiel ist aber keine Vererbung zu erkennen.
  
• Die Klasse Produkt fehlt komplett
  
• Bestellung braucht keinen Speisenamen, sondern eine (oder mehrere) Speise(n)
  
• Bestellung braucht keinen Speisenamen, sondern ein (oder mehrere) Getränk(e)
  
• Bestellung braucht keinen Preis, da der bei dir über die bestellnummer erreichbar ist
  
• Laut Aufgabenstellung fehlt bei Getränk die Menge
  

Das ist das, was mir auf die schnelle aufgefallen ist

[kingofbrain]

Deine Lösung ist leider in verschiedenen Punkten falsch. Was wolltest Du mit den Pfeilen ausdrücken? Die Semantik dieser Pfeile ist es, eine Vererbungshierarchie aufzubauen. Das wäre bei Dir so:

Bestellung erbt von Preis und Kunde, Speisen und Getränke erben jeweils von Bestellung. Also *ist* eine Bestellung ein Preis *und* eine Bestellung *ist* ein Kunde. Genauso *ist* eine Speise eine Bestellung. Ich vermute, Du wolltest hier Relationen abbilden. Dafür gibt es einen entsprechenden Pfeil (in der einfachsten Version die Assoziation).

Dann haben Speisen und Getränke zwar die Attribute gemeinsam, aber sie sind beides keine Produkte. Hier wäre der Punkt gewesen, an dem Du Vererbung sinnvoll einsetzen hättest können.

Versuche mal, die einzelnen Klassen in eine logische Beziehung zu bringen. Verwende dabei folgendes Muster: X ist Y, X ist Teil von Y, X steht in Relation zu Y. Beispiele:

Ein Getränk ist ein Produkt

Ein Produkt hat einen Preis

Eine Bestellung enthält Produkte

Mit diesen Sachverhalten kannst Du sehr einfach die Klassen zueinander bringen (über den jeweiligen Verbinder).

Probier, die logische Beziehung zunächst mal schriftlich zu fixieren und hier einzustellen. Dann sprechen wir darüber und danach wird auch das Diagramm was. Je nachdem, wie schnell Du bist, sogar noch vor Ostern (während der Feiertage werde ich vermutlich nicht auf fi.de sein ).

Schöne Grüße,

Peter

[marco_90]

Hey ihr 2,

seit mir bitte nicht böse, aber wenn es um UML geht bin ich echt am *****, das kapier ich wirklich nicht so ganz, kann mich da so schlecht reindenken!

Hab es jetzt nochmal probiert nach euren vorschlägen und ich hoffe es stimmt einigermaßen:

http://img521.imageshack.us/img521/448/unbenanntwl.jpg

ich hoffe ihr seit nicht böse, ich schnalls einfach nicht:beagolisc

[LadyPreis]

du musst ein bißchen weiter denken als die standardmäßigen Datentypen.

Beispiel Bestellung: Eine separat gespeicherte Tischnummer ist dort nicht notwendig, da zu der Bestellung ein Kunde gehört, bei welchem bereits die Tischnummer gespeichert ist. (Über die Logik dahinter mag ich mich jetzt nicht äußern). Smoit wäre das doppelte Datenhaltung.

Die Vererbung ist generell ok, allerdings zeigen die Pfeile in die falsche Richtung... die Spitze immer an das allgemeinere Objekt.

Außerdem musst du in Getränk & Speisen nicht extra den preis speichern. Dadurch, dass diese beide Klassen von Produkt erben, haben sie automatisch schon dieses Attribut

[marco_90]

@ladyPreis

Hey, also hab jetzt deine vorgeschlagenen Änderungen erledigt,

somit ist das Diagramm also richtig für die angabe oder?

gruß und vielen Dank Marco

[perdian]

seit mir bitte nicht böse, aber wenn es um UML geht bin ich echt am *****, das kapier ich wirklich nicht so ganz, kann mich da so schlecht reindenken!

Hast du denn schonmal bewusst und mit Aufmerksamkeit ein Tutorial, oder - noch besser - ein gutes Buch zu dem Thema gelesen und dich intensiv mit den Grundlagen vertraut gemacht?

[marco_90]

ja wir haben es in der schule durchgenommen, und weil ich die erste hausaufgabe dazu nicht verstehe wollte ich nicht gleich ein Buch bestellen!

wenn ich die nächsten hausaufgaben nicht verstehe werde ich es aber machen.

p.S. stimmt die lösung jetzt?

[kingofbrain]

Also mir fehlt noch die Kategorie (wobei für mich aus der Angabe nicht hervorgeht, was kategorisiert werden soll).

Und für mich ist nicht plausibel, warum ein Produkt eine Menge haben sollte. Die Menge sollte doch an der Relation zwischen Produkt und Bestellung hängen, oder? Schließlich wird das Produkt A vom Kunden X 2 mal bestellt, vom Kunden Y 3 mal.

Was ist die Bestellnummer in der Bestellung? Und auf was bezieht sich die Produktmenge in der Bestellung?

Ein bisschen musst Du also noch.

[lupo49]

Die Vererbungspfeile sind falsch herum und Attribute aus einer Oberklasse werden nicht erneut in die Kindklasse eingetragen.

[marco_90]

mir kommt es langsam so rüber als sei die Angabe bisschen blöd oder?

ne ich komm nicht mehr weiter mit produktmenge usw.^^

[kingofbrain]

Ich kann ein wenig schlecht helfen, weil mir nicht klar ist, welche Konzepte von UML Klassendiagrammen Du kennst. Für die Modellierung der Produktmenge zwischen Bestellung und Produkt brauchst Du entweder eine abgeleitete Assoziation, oder Du musst eine Zwischenklasse Bestellposten einfügen, in welcher Du die Menge angibst. Überleg doch mal in der echten Welt: macht es Sinn, in einer Bestellung eine Eigenschaft Produktmenge zu haben (stell Dir mal die Rechnung im Restaurant vor: gibts da einen Punkt Produktmenge?)? Nein, die Anzahl an Produkten ist keine Eigenschaft der Bestellung und auch nicht des Produkts, sondern des bestellten Produkts.

Was ist mit den restlichen Punkten? Zeig mal das aktuelle Modell.

Peter

[marco_90]

ja das hab ich schon ausgebessert mit der produktmenge.

hier ist die aktuelle lösung von mir:

http://img100.imageshack.us/img100/5380/forfachinformatiker.jpg

[kingofbrain]

Gut, die Frage mit der Bestellnummer in der Bestellung bleibt: was soll die ausdrücken?

Die redundanten Namen und Mengen in Getränken und Speisen sind auch noch vorhanden. Was soll Menge hier bedeuten (Anzahl Pommes, 0,4l Cola?)?

Wie drückst Du aus, dass ein Kunde 2 Gläser Wasser hatte?

Und der Vollständigkeit halber würde ich auch noch die Multiplizität der Assoziationen angeben, also 1:1, 1:n, m:n

Peter

[marco_90]

das mit meine ich mit menge (= wie viele gläßer wasser bestellt wurden)

ja die bestellnummer habe ich auch entfernt, ist sinnlos!

kardinalitäten ist also das was ich noch machen muss?

[kingofbrain]

Die Kardinalität wie ich sie in diesem Kontext kenne, ist die konkrete Anzahl, die Multiplizität ist der mögliche Bereich der Kardinalitäten. Deshalb kenne ich Kardinalitäten eher aus Objektdiagrammen, wo bestimmte Objektzustände dargestellt werden. Im Endeffekt meinte ich, Du solltest angeben, ob ein Kunde eine oder mehrere Bestellungen haben kann und ob eine Bestellung zu einem oder mehreren Kunden gehört. Ebenso bei der Relation zwischen Bestellung und Produkt.

Die Menge ist als wesentliches Merkmal noch offen. Ich habe ein paar Posts weiter oben erläutert, wie man es lösen kann. Probier, das umzusetzen und meld Dich, wenn Du nicht weiterkommst mit konkreten Fragen.

Peter