0

I am new to Object oriented design patterns. I have a basic idea of the domain model. However, I am stuck at the following problem. The problem is that I have a system that contains events and customers(both 1....*). Additionally, the events contain packages. The user is allowed to book events. However, he has to do it by booking a package that is contained inside an event. What should be the correct domain model of the given situation. I did a lot of research about similar questions, but could not find a suitable answer.

My guesses: 1)

In this image, The customers can book events, but I am unsure about this because customers are booking packages contained inside events. Should I select this domain model for the given system? It is intuitive because it allows customers to book events.

2) enter image description here

In this image, the domain model signifies the system's structure. However, customers should reach the packages only through events. Therefore, I am unsure about this domain model. How can a customer book a package when it is contained inside an event.

Please suggest which domain model is correct. I am a beginner so please provide a good explanation. Thanks for helping me out!

Shubham Sharma
  • 35
  • 7
  • Please provide an answer to this question. I can't proceed without an answer to this question. Thanks! – Shubham Sharma Jun 03 '16 at 07:19
  • Few remarks about your model 1. Don't put association names in rectangle as it isn't conforming UML specification and is confusing 2. Class names should be in singular form rather than plural Note also that this is a community run page. You might receive an answer in 5 minutes or in 5 weeks and it's still just great to receive here an answer at all. Please avoid being pushy. – Ister Jun 03 '16 at 07:33

1 Answers1

2

First of all - there is no definite answer. Usually you can create in several different ways and have good results.

Second - both contain relationships should be aggregations in my opinion. Events to System is (probably) a composite aggregation while Package to Event can be either composite (if a particular Package is specific for one Event only) or shared (if the same Package is available through various Events).

Now to the main question. If the relationship between Event and Package is a composition (composite aggregation) then you can model book relationship as an association between Customer and Package. Then the Event is uniquely recognizable. You can also extend your model adding a relationship to the Event that is a derived one (from book).

Here is an example (note the / sign depicting this is a derived association): derived association

Other option that is valid for both composite and shared aggregation between Event and Package is to model Book relationship between Customer and Event but model it as an association class. Then you have a class (Book) describing the association and this class can have a relationship chosenPackage to Package. In this case your model will look like this: association class

I can bet that you can also find also other methods of modelling your problem that still are valid and show all the information you provided so far.

Ister
  • 5,958
  • 17
  • 26
  • You could improve the diagram by adding a reading direction for the connector labels. In EA right-click the name (e.g. "goes to") and select Direction/To (where appropriate). – qwerty_so Jun 03 '16 at 07:43
  • @ThomasKilian I know that but I didn't do this on purpose. The truth is I don't know the exact navigability of the relationships in the diagram. BTW I know how to set things like derived association. Believe me, I know how to model navigability in EA as well ;-) However if you have any idea how can I better position the dashed line leading from association to its association class that would be of much help ;-) – Ister Jun 03 '16 at 07:56
  • The dashed line joins to the next segment of the connected association. You can not manipulate it by any means. You won't tell me that it's "Customer goes to Event" and not vice versa? – qwerty_so Jun 03 '16 at 08:18
  • Sorry, my mistake. I was thinking of navigability when you were talking about reading direction. You're right of course. Yet I follow here the suggestion of Howard Podesva to use reading direction only if it might be unclear. – Ister Jun 03 '16 at 10:26