0

I am creating a Class Diagram for a simple booking system for the theater. I would like to know if the diagram makes any sense and if anything needs to be changed (arrow directions) in order for it to be correct?

Thanks. enter image description here Image URL: https://i.stack.imgur.com/zWiGW.jpg

Sandeep Bansal
  • 6,280
  • 17
  • 84
  • 126
  • 1
    On its own a class diagram will hardly make any sense. To be able to give comments we need to know much more than just the diagram. Of course we can use our knowledge of seats and tickets and of UML in general but in the end we need to know the system you are trying to show to be able to give correct feedback. – Emond Apr 23 '11 at 16:15

2 Answers2

1

Here are some recommendations that you're free to incorporate or ignore as you see fit:

  • I don't agree with the relationship between Show and Venue. It seems more natural to have a Booking maintain the relationship between a Show and a Venue.
  • I don't see a Date for a Show anywhere. Did I miss it? That seems important.
  • Shows don't have Seats; a Venue has Seats.
  • A Ticket ought to entitle you to a Seat in a Venue on a particular date. I don't see that.
  • TicketType should be nothing but an enum.
  • Decompose User to have a Name, Address, and Credential classes. Separate the Credentials out from User.
  • A real payment system would need far more than what you have showing (e.g. CreditCard, etc.)

I think your model needs a lot of work.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Thanks for the feedback. 1. How would I show a booking maintain the relationship, would I connect the booking to the line inbetween the two classes? 2. added date 3. corrected venues to have seats. 4. corrected to have a ticket require the seat. 5 & 6. They will be worked on after I have complete any problems that I currently have with the model. – Sandeep Bansal Apr 23 '11 at 16:24
  • No, you'd have a booking relate a single Show to a single Venue on a given Date. You'd remove the relationships you have now. – duffymo Apr 23 '11 at 18:05
  • I've already given enough, and you haven't upvoted or accepted anything. – duffymo Apr 23 '11 at 19:53
  • Sorry was just working on my diagram, I normally accept answers towards the end of the day. Thanks for the information. – Sandeep Bansal Apr 23 '11 at 19:57
0

In addition to what duffymo said, here are some generic observations not strictly related to this particular diagram but rather you modeling practices.

  • If an association is one way navigable then there is no need to name both ends. You have named both ends of all associations, but only navigable end needs a name.

  • Drop the 'can' from all association ends. In some cases there is a handy term, for example show can be hosted at a Venue. But in other cases it's perfectly fine and even common practice to name association ends same as the class at that end. (so name the Seat end simply Seats)

  • Avoid many to many relationships if you can. If you can't then look into adding an association class in between, it almost always makes sense.