It is a common fact that the solution for any pattern consists of two different models: static, mainly class diagrams, and dynamic, by using sequence diagrams or state transition diagrams.

Let us visit Figure 1, in Pitfall #9, the model of the Resource Rental pattern [1, 2] that tries to model the common rules that govern any renting, whether the object rented is a DVD or a car. The Figure suffers from several notable deficiencies:

Problem #1: There are dangling classes in the example. Dangling classes in UML diagrams are a clear sign that something is not right or something is very wrong. A dangling class is a class connected to one and the only one class. We have identified two of these: Payment and TypeOfResource.

Problem #2: There are a number of unresolved many-to-many relationships. As noted by several authors, a model is not complete and thorough, until all many-to-many relationships have been decomposed into two one-to-many relations. We have identified two of these: between Resource and ResouorceBooking, and between ResourceRental and ResourceInstance.

Problem #3: This pertains to the use of “accessor” methods. Accessor methods are operations that have as their only purpose, to update the internal state of an object, thus violating one of the main principles of Object Oriented Design. These methods are called “get()” and “set()” in this pattern.

Problem #4: There are no names associated with the relationships. This is an inherent problem, because the pattern is incomplete in documentation. If the names are not there, then different interpretations of what a given link means may arise.

Problem #5: There is no real behavior associated with the classes. A big portion of the operations described in this model focus just on listing something by a given condition. For example, getRentalsByInstance() of the class ResourceInstance(). This is no real behavior associated with a responsibility for that class, but only a listing provided for some other object to operate on it.

Problem #6: Customer, Resource, TypeOfResource, and ResourceInstance have the same assigned responsibility, doing the same thing, get and set, and this a clear violation of the rule of abstractions

Problem #7: Resource, TypeOfResource, and ResourceInstance are passive objects and they cannot get and set.

Problem #8: What are the differences between Resource and ResourceInstance? There is absolutely no difference.

Problem #9: The model is missing in inheritance and aggregation.

In addition, the Figure contains a cross line between two associations.

References:

[1] R.T. Vaccare Braga et al. “A Confederation of Patterns for Business resource Management.” Proceedings of Pattern Language of Programs’ 98 (PLOP’98), September 1998.

[2] M.E. Fayad, Pitfall #9: Untraceable Patterns-The Pitfall of the Pattern Systems, The Software Patterns Blog at pattern.ijop.org