UML-Klassendiagramm -> bitte um Hilfe

[Tom_t]

Hallo zusammen,

für mich ist die Modellierung der Klassendiagramme ein ganz neues Gebiet. Ich würde mich über den einen oder anderen Tipp zu der angehängten Aufgabe und meinem Modellierungsversuch freuen.

Aggregations- und Kompositionsverbindungen fehlen noch, war mir nicht sicher.

Was haltet ihr von dem Versuch? Totaler Schrott , oder kann man noch was retten?

Grüße,

Tom

Aufgabe.pdf

Versuch.pdf

[AndiE]

Wie lautet denn DEINE Aufgabe? Sollst du das DB-System konzipieren?

[VaNaTiC]

Ein paar kleine Anmerkungen von mir hätt ich dazu:

Prinzipiell musst Du - vorallem um das auch als DB-Schema abzubilden - noch diverse Members in Deine Klassen einbinden.

Ich würde eine Basis-Klasse (vielleicht auch abstract) Kinosaal einführen und die mit Film und so verlinken, davon erben dann nur die drei Klassen großer, mittlerer und kleiner Saal.

Auch würd in der Kinokarte nicht den Filmtitel halten, sondern eine ID auf Film halten und in Film alle dazu relevanten Einträge.

Wichtig ist für Dich auch, dass Du noch eine m-zu-n Verknüpfung von Film und Saal hast, denn laut Aufgabenstellung kann ein Film in mehreren Säalen gleichzeitig laufen. Und dieser - nennen wir es - Vorstellung (Film_ID, Saal_ID, Startzeit), kannst Du dann einen Verweis zur Kinokarte herstellen.

Im Gegensatz zu Deiner Ausführung, die Kinokarte als Verknüpfung für Saal und Film zu halten, hat diese m-zu-n Verknüpfung den Vorteil, dass Du auch das Managment der Filme pro Saal effizient abbilden kannst, ohne dabei die (in diesem Fall unrelevanten) Kinokarten zu berücksichtigen.

Auch die Klasse Kinokarte würde ich als Basisklasse (evtl. wieder abstract) ausführen. Und dieser Basisklasse alle Verweise/Verknüpfungen mitgeben.

Davon kannst Du dann z.Bsp. Normale Karten, Freikarten, Rabattkarten erben lassen. Denn die speziellen Kartenvarianten sind nur für die Kinokasse relevant.

Wie Du schon gesagt hast musst Du noch zu den Verknüpfungen/Verweisen die Art und Weise angeben (Aggregation, Komposition).

[AndiE]

Hallo,

ich schließe mich meinem Vorredner an, dass du ein Objekt "Vorstellung"

einbauen solltest.

Meine Idee:

(Objektnamen in "")

Nach dem Prinzip der Kapselung "kennt" "Vorstellung" seinen "Termin", seinen "Film" und seinen "Spielort".

Ich habe mir gedacht, daß die "Kinokasse" alle "Termine" kennt. An so einem Termin können mehrere "Vorstellungen" sein, die alle ihre ... (s.o.)kennen.

Die "Kinokasse" erstellt eine "Kinokarte".

"Kinokasse" und "Snackbars" würde ich von einem Objekt "Einnahmeobjekt" ableiten und die Säle, wie schon vorgeschlagen, von einem Objekt "Saal".

Das Kino kennt dann also "Einnahmeobjekte" und "Säle".

Ebenso wie die Waren der Snackbars von einer Basisklasse "Ware" und de Karten von einer Basisklasse "Karte".

Beide kann man von einer Klasse "Verkaufsgegenstände" ableiten.

LG

Andre'

Die "Säle" habe ich

[Tom_t]

super...vielen Dank für Eure Vorschläge. Ich werde morgen nochmal näher auf die Antworten eingehen und einen neuen Entwurf hochladen.

Bis dann,

Tom

[Tom_t]

so, nun habe ich es nochmal versucht. Allerdings lässt sich mittels der Vererbung nicht mehr zeigen, wieviele der jeweils kleinen, mittleren und großen Säle existieren sollen:confused:. Ich habe versucht eine die Klasse "Kinokarte" zu streichen. Nun weiß ich allerdings nicht ob's besser als vorher geworden ist. Vielleicht könnt ihr nochmal drüber schauen...

Grüße,

Tom

Versuch2.pdf

[VaNaTiC]

Ich kann aus der Aufgabenstellung nicht erkennen, dass es nicht gut wäre, prinzipiell eine 1-m Verknüpfung zwischen Saal und Kino zu haben, so dass sich die von Saal abgeleiteten großer, ... nur durch die Anzahl der Plätze, nicht direkt durch die Implementierung, unterscheiden.

Ich weiss nicht wie weit und wie "fein" das Modell sein soll, aber in der Snackbar würde ich keine einzelnen Artikel halten, sondern lieber eine 1-m Verknüpfung zu Verkaufsartikel, so wie es AndiE vorgeschlagen hat.

Auch würd ich den Besucher als solchen wahrscheinlich nicht als Objekt halten, außer das Kino soll registrierte Benutzer handeln. Stattdessen würde ich eine extra Klasse einführen, die Kinokarte heisst mit Verweis zu Film, Saal und Startzeit. Und eine "Factory" in der Kinokasse erzeugt davon abgeleitete Klassen Freikarte, Rabattkarte, Normalkarte.

Grundsätzlich würd ich sagen ist das ok. Wie eigangs erwähnt ist meiner Meinung nach für das DB-Design und die Implementierung die Kardinalität der Verknüpfungen nur zwischen einfacher ( 0..1 ) und mehrfacher ( 0..*, 1..* ) zu unterscheiden. Soll heißen, bei Mehrfachverbindung sollte die tatsächliche Saalanzahl dynamisch sein.

[AndiE]

Hallo,

ich habe meinen Ansatz mal zu Papier gebracht. Von oben her zeigt er, wie der Besucher das Kino nutzt, von unten, wie das Kino aufgebaut ist.

Es fehlen noch einige Dinge, aber das ist Absicht.