Feedback on UML Class Diagram

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 an开发者_如何学运维ything needs to be changed (arrow directions) in order for it to be correct?

Thanks.

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.

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.