Java UML Klassendiagramm - Java Aufgabe aus dem Studium

[frost911]

Hallo zusammen,

ich studiere Wirtschaftsinformatik in Köln, und muss nun im Fach Application Development ein UML Diagramm erstellen. Im Anschluss soll die Aufgabe auch programmiert werden, aber zunächst steht halt das Diagramm im Vordergrund.

Hier mal die Aufgabe:

„Zu einem Ereignis (z.B. Konzert, Lesung, Ausstellung) können von Kunden
Karten (pro Kunde mindestens eine bis zu maximal zehn Stück) erworben
werden. Jedes Ereignis hat eine Bezeichnung und eine Menge von Terminen mit
Orten und Preisen. Sollte ein gewünschter Termin ausgebucht sein, soll ein
Ausweichtermin vorgeschlagen werden (der zeitlich nächste zum
gewünschten). Für Kunden werden eine Kundennummer, Name und die Adresse
gespeichert, an die die Karten verschickt werden sollen. Eine Kartenbestellung
kann storniert werden, wenn dies mindestens 14 Tage vor dem Ereignis
stattfindet, werden keine Stornogebühren fällig, zwischen 14 und vier Tagen
davor 50%, danach wird der volle Kaufpreis als Stornogebühr fällig.“
Das Programm „Kartenbestellung“ soll drei Ereignisse mit jeweils drei Terminen
anlegen und zwei Kunden. Ein Kunde bestellt Karten für ein noch nicht
ausgebuchtes Ereignis, ein zweiter für ein ausgebuchtes. Im zweiten Fall soll
das System einen Ausweichtermin vorschlagen, der dann auch durch den
Kunden gebucht wird. Der erste Kunde soll eine Bestellung von Karten
stornieren und abhängig vom Datum die Stornogebühren mitgeteilt bekommen.

Hier meine bisherige Lösung (erstellt mit Visio 2010):



Ein kleines Feedback zu meiner Lösung wäre super und würde mich freuen

 

[abulafia]

Ich glaube bei den "Terminen" musst du noch nachbessern:

Jedes Ereignis hat eine Bezeichnung und eine Menge von Terminen mit
Orten und Preisen.

Edit: Sollte passen

 

[Prinzenrolle_]

Hmm ich wuerde, glaube ich, Preis auch nicht in den Termin nehmen. Das gehoert fuer mich schone eher zom Ereignis. Das Ereignis hat dann einen Termin, dieser Termin kann z.B. dann den Preis beeinflussen (Weekend kann z.B. wegen hoehere Nachfrage, teuerer sein)
Noch ein kleines Detail. Klassen schreibt man nicht in mehrzahl. Also wie das Ereignis. Du hast noch Termine etc. aendere das noch auf Termin etc.

Das ist ja jeweils ein einzelnes Objekt...

 

[abulafia]

Der Preis ist vom Termin abhängig. Denke das ist richtig.

Was soll die Summe unter Bestellung sein? Ich würde die Anzahl der Bestellungen dem Kunden zuordnen.

Also:

Kunde
-ID
-Name
-Anschrift
-Anzahl der Bestellungen

 

[frost911]

Danke für das Feedback!

Ich habe den Preis nun der Karte zugeordnet und aus dem Termin gestrichen, ich denke, dass macht am meisten Sinn und ist auch am nächsten an der Realität. (Ein Termin hat keinen Preis, die Karte hat den, ein Termin ist ja nur eine Bestimmung von Zeit und Ort). Ich habe auch überlegt, den Ort zu einer eigenen Klasse zu machen, schließlich hat ein Termin eigentlich keine Plätze, sondern ein Ort?!

Die Summe in der Bestellung soll den Rechnungsbetrag angeben, also einfach nur eine Addition der Kartenpreise der jeweiligen Bestellung.

Ich finde es etwas schwierig diese zusammenhänge in einem Klassendiagramm darzustellen, ich bin es eigentlich gewöhnt zunächst die Datenstruktur anhand eines ERDs zu erstellen und dann auf dieser Basis eine Anwendung zu schreiben.

 

[abulafia]

Die Karte wird aber aus dem Termin generiert .... ist eine Verbindungstabelle.

Um genau zu sein hat jeder Sitzplatz zu den jeweiligen Terminen seine eigene Karte. Das ist nicht berücksichtigt. Eigentlich müsste du noch Sitzplätze einfügen und denen dann die Karten zuordnen.
Jeder Termin hat einen Ort. Jeder Ort hat Sitzplätze. Jeder Sitzplatz hat dann seine Karte.

Ergänzung (3. November 2016)

Du brauchst Veranstaltungsort(ID, Anschrift, Anzahl der Sitzplätze, etc.), Sitzplatz(Nummer, Preis, Behindertengerecht), Termin (ID, Veranstaltungsort_ID, Zeit, Datum), Karte(Veranstaltungsort_ID, Termin_ID, Sitzplatz_Nummer)

Wenn du keine Sitzpplätze haben möchtest, fällt das raus und der Preis rutscht unter Termin.

Veranstaltungsort(ID, Anschrift, Anzahl der Sitzplätze, etc.), Termin (ID, Veranstaltungsort_ID, Zeit, Datum, Preis), Karte(Veranstaltungsort_ID, Termin_ID)


Oder du machst einen Festen Preis für den Ort. Also z. B. Museum kostet immer 10 € Eintritt. Danach wird aber nicht gefragt, also kannst du das so machen.

 

[frost911]

Verbindungstabelle? =P Es geht aber um ein Klassendiagramm zur OOP und nicht um ein ERD, in einem Klassendiagramm gibt es keine Verbindungstabellen.

Aber danke für deine Mühe, ich lasse es mit einfließen!!

 

[abulafia]

Im ER wäre es eine. Sinngemäß ist es hier ähnlich. Es geht ja um eine Datenstruktur/Whatever. Wusste nicht, wie ich mir hier sonst ausdrücken sollte. Hoffe der Sinn ist herübergekommen.

Die Ähnlichkeit zu einem ER ist aber schon irgendwie nicht zufällig, oder? Wie nennt man das denn hier. n-m

 

[frost911]

Naja alle Klassen sollten ja auch bei der Programmierung dann so implementiert werden, mach das aber keinen Sinn, sollte man es auch nicht im Klassendiagramm darstellen. Kardinalitäten bzw. Multiplizitäten gibt es sowohl in ERDs als auch in Klassendiagrammen, so kann eine Beispielklasse Kinosaal halt 1 - * Objekte des Typs Kinosessel beeinhalten, gibt es aber nichtmal einen, so kann man dann korrekterweise die Klasse Kinosaal NICHT instanzieren.

Daher, ja es gibt Gemeinsamkeiten, aber ein Klassendiagramm muss implementierbar sein und sich nicht an die Dogmas der Normalisierung halten.

 

[The Ripper]

Also ich seh kein Problem damit, wenn du eine Datenbankstruktur genau so auch auf Klassen übersetzt. Ich sage nicht, dass es die perfekte Lösung ist, aber generell wüsste ich nicht, was dagegen sprechen würde.

​Nenn doch mal ein Beispiel, welches nicht implementierbar wäre

 

[abulafia]

Keine Normalisierung. Prima, weil meine Idee mit den Sitzplätzen ist nicht sonderlich durchdacht. Du sollte so etwas wie eine Preisklasse einführen.
Also z.B. Platz(Nr, Preisklasse, Art( z. B. Stehplatz, Behindertengerecht etc)), Preisklasse(Preis, Ermäßigung).

Deine Struktur war schon okay. Preis bei Termin lassen und nicht differenzieren.