Needs to understand the difference between boundary, controller, logical class types

Question

As the title implies I am trying to understand the difference between boundary, controller and logical class types, which are used in the MVC pattern.

I will do so using an example. Please consider the following Class Diagram :

I have to add the needed analyse classes of type boundary and controller to account for the two use-cases : borrow a book and reserves book. The following is my answer ( sorry for my hand-writing ) :

So is this a right answer? Also, the logical classes in this case are book, student copy ( the classes that do the business process analysis ) ?

Answer 1

You are trying to use the entity-control-boundary analysis to design an MVC architecture.

Indeed, all the classes in your diagram belong to the „logical domain“, so are entities in the ECB logic, and model in the MVC.

The boundary classes would be the GUI classes that interact with the user. They are indeed missing in the original diagram.

But be careful: the ECB approach has some similarities with the MVC pattern it is not the same: the controller has a very different purpose:

• In MVC the controller has the monopoly of user input, and user commands, whereas in ECB the user input would go to the boundary.
• In ECB, the controller represents a use case with domain logic as well, whereas all the domain logic goes into the model in MVC.

Depending on whether you want to use ECB or MVC, your class design would therefore be different:

• In an ECB architecture, the boundary (GUI in your case) is indeed not supposed to interact with the entities (see in the wikipedia article the section on “robustness”). Your schematic adjustment would be ok. If it was an exercise about use case driven approach it’s ok.
• But in ECB, you’d be supposed to have a distinct controller for each use case. These are missing. You’d also be supposed to have a separate boundary for each combination of actor and use case. These might be missing, unless you’d have the same user interface for both use-cases.
• In an MVC architecture, the model is supposed to know about the view to update it (the view is an observer of the model), in which case a link would be missing.

Answer 2

Three out of two of your classes don't have behavior. In an object-oriented setting this is not ok. Objects without behavior are just data records, which are unwelcome in OO.

Regarding boundaries, those are for external systems (mostly), there is usually no reason to introduce them inside an application. I.e. if you want to present your object on the ui, have the object be capable of presenting itself.