0

I want to display the booking list of a restaurant for a given date. I omit the boundary object here. In the first diagram, the restaurant object maintains the complete set of booking made for the restaurant. In the second diagram, the restaurant object is not used. Are there any benefits using restaurant object? enter image description here

enter image description here

Ju Ju
  • 199
  • 1
  • 13

2 Answers2

1

The main benefit is encapsulation. Different restaurants can handle bookings in different manner. All you have to do is to build common interface for a Restaurant. Secondly in the former case the BookingSystem immediately have information about the restaurant (and you probably want to present that to either staff or a client). The latter one would have to handle this information in some other way.

Ister
  • 5,958
  • 17
  • 26
  • But I am doing this for only one restaurant. – Ju Ju Jul 27 '16 at 08:31
  • If we're talking about modelling the system of the restaurant, then such system control class should have direct access to Booking. As you've mentioned reaching through restaurant gives no benefit here. Moreover reaching Booking is a core of system functioning. – Ister Jul 27 '16 at 09:43
  • Thank you very much for the reply. Do you notice * at the right corner of entity class? I use that to describe the fact that there are many booking objects. Do I need to use that? – Ju Ju Jul 27 '16 at 12:43
  • Yes, I've noticed it. And while I recall such notation for simple loop in activity diagram I can't remember similar notation for lifelines so not only you don't have to - you actually shouldn't (unless you can provide a reference to some source confirming such usage of the "*"). Anyway my assumption was that the message is sent to multiple objects of the type Booking. – Ister Jul 27 '16 at 13:48
  • Yes, I can provide a reference. I am reading the book titled "Practical Object-oriented Design With UML" (Second Edition) written by Mark Priestley. In that book, In the chapater of Interaction Diagram, he said that multiplicity on a classifier role specifies the number of instances that can play that role in an interaction. The first diagram is the example diagram he used in other chapter. But he left multiplicity for the booking class. That is why I am confused. – Ju Ju Jul 28 '16 at 05:47
0

If your app is for one restaurant only, then everything that happens in your app is related to that restaurant and this object would not add significant benefit to this design: it could well be made implicit (second diagram).

The drawback is that your app design then relies completely on this underlying assumption. Very often, successful restaurant entrepreneurs open a second and a third venue. Some even become so popular to become a franchise with several thousands of restaurants. So keeping restaurant in the design (first diagram) has the advantage to cover a broader range of needs and easier reuse of the software, at a marginal additional thinking effort. (And the app could be more reusable and interest successful restaurant owners who would not consider it if you'd be mono-restaurant).

P.S: The * in the booking lifeline is not standard UML. The sequence diagram represent a scenario of interactions between lifelines that each represent an individual object. The communication diagram, a close cousin of the sequence diagram, has a * notation, but for the message numbering and not for instances either. Usually, in sequence diagram, a loop fragment is used to show an iteration. More about this topic in this other question

Christophe
  • 68,716
  • 7
  • 72
  • 138