1

I can't find anywhere else where I can show an OO system design and get feedback on it.

Could you identify any major issues with my design and how to fix them?


The description of the problem is as follows:

  1. Create a class diagram of a restaurant system. There are employees and they can perform many roles, depending on the demand. e.g.: an employee can be a Cook at a time, and a Waiter at some other time.
  2. The store owner must be able to go to the system and say: on such day, I need 3 cooks, 5 waiters, 2 managers, etc from 5PM to 8PM, and then from 8PM to 10PM I need 2 cooks, 2 waiters, and so on. The user didn't specify which employee will be there, only roles and quantities for time of day.
  3. There is an external system that can, after receiving a set of demands, decide which employees will fulfill those demands. How to call this system (what to pass to it and what to get back) must be part of the design.


Here's the class diagram I've built to fulfill the requirements:

enter image description here


What can be achieved from this design is:

  • An Employee have many Roles (requirement 1)
  • The Controller class is the one triggered by the user. Based on the input (on such day need these roles and quantities) it creates a list of Demands, each Demand indicates that N number of Roles is required between a start and end date (requirement 2)
  • The Controller calls the external api (Scheduler) passing the demands and the list of employees, and the api returns a Schedule object which is a composition of several ScheduleEntry. A ScheduleEntry ties an Employee to a Role for a given start and end date (requirement 3). Here this could be a Facade to an external system, but it's represented as a class for simplicity.
1

I think you're missing a multiplicity indicator here:

enter image description here

The Schedule that Scheduler.BuildSchedule() returns will sometimes have more than one ScheduleEntry in it wont it?

  • Yes, that is correct – mike t Apr 25 at 23:35
0

I get where you're coming from, I've made many such designs myself, and if that what is expected of you, then of course, it is what you supposed to do.

However, I would not design a real system that way. There are a couple of problems with this, the biggest one being, that you just take the "demands" from the user/owner and convert it to a relational data model. We don't know what happens next. Why do we need that model in the first place? The usage should drive the model, not your concept of how these things should relate to each other.

Ok, here is what I mean. Let's go one requirement at a time:

Create a class diagram of a restaurant system. There are employees and they can perform many roles, depending on the demand. e.g.: an employee can be a Cook at a time, and a Waiter at some other time.

This is context and definitions. There is no behavior defined, so no modeling yet.

The store owner must be able to go to the system and say: on such day, I need 3 cooks, 5 waiters, 2 managers, etc from 5PM to 8PM, and then from 8PM to 10PM I need 2 cooks, 2 waiters, and so on. The user didn't specify which employee will be there, only roles and quantities for time of day.

Ok, so the literal translation of that would be:

public interface System {
    void need(LocalTime from, LocalTime to, int cooks, int waiters, int managers);
}

Note, I modeled the absolute minimum what is required. Roles are not dynamic, time is kept as local time, there is no "result" of the operation, since none is required and I used the exact terms from the sentence above. The requirement is modeled as stated. Anything more needs more discussion or more specification.

There is an external system that can, after receiving a set of demands, decide which employees will fulfill those demands. How to call this system (what to pass to it and what to get back) must be part of the design.

This is so under-specified that the previous interface actually qualifies. We have a model of the external system (the interface), we have the information to pass, and we specify to not get back anything, since that information is not used anywhere in any behavior specified.

I'm not saying this single interface is the design you should go with. What I'm saying is that you shouldn't create a data model just for fun, because you are assuming a lot which may or may not be correct later when you actually have to use the data. So just ask what the data is used for, and do the model with that usage explicitly in mind, not a generic one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.