Ask the Domain Experts to Provide an Example

If you are having trouble visualizing whether a class diagram meets the business needs, try asking the domain experts to provide a concrete example that you can walk through with them.

A set of good specific examples is often worth pages of text or hours of discussion trying to describe generally how things need to work.

Look for examples that cover the usual scenarios and the exceptional cases that may arise.

In addition, look for examples that are complex enough to contain ample teaching points but simple enough to be understood.

In UML, we often represent a hierarchy of objects as an association from a class to itself with one end of the association marked with 0..* and the other as 0..1.  It is not always easy to visualize and mentally manipulate hierarchies of objects described in a class diagram. Normally, sequence diagrams and collaboration diagrams do a good job illustrating interactions between objects. However, both types of diagram have problems showing the sort of recursive interaction found in hierarchies of objects. Often it is easier to draw out an example of the hierarchy using UML's object notation and work with that.

Use an object diagram to illustrate a general class diagram

Sometimes we can generalize a class diagram to a point where it is hard to see how objects of those classes should be linked in a particular context. In these circumstances, use an object diagram to communicate the structure of the objects for a specific example. This can be especially useful when hierarchies or complicated networks of objects are represented.

Example

Here is an example from the Java Modeling in Color with UML book:

An organization contains a set of Organizational Units which in turn contain sets of sub units. The sub-units do not necessarily form a hierarchy; they can form a directed graph or network.

Imagine a medium size company having a couple of regional centers, one on the East Coast and one on the West Coast. Each regional center manages a number of branch offices. A nice neat hierarchy so far. Now imagine that each branch office specializes in a particular line of business and reports to a Division too. To cap it all we have a headquarters that oversees the divisions  and regions. Is our  OrganizationalUnit model capable of representing this more complicated structure.  

Using a rather abstract object diagram we can demonstrate that our OrganizationalUnit class does indeed enable us to represent this dual reporting structure. Each branch office object links to both a division object and a regional center object. Each division and regional center object links to the single head quarters object. We could augment the diagram with constraints to explain the rules. However, in this case it is probably better to simply list the rules in a note.

The object diagram above is a little abstract; the objects do not represent specific objects in the problem domain but rather categories of object. A more concrete example is shown below. The more concrete example, especially if it is a good example, is very useful for walking through specific scenarios. The more abstract object diagram is better at proving or illustrating a general class diagram.  

Notes

• Whether to use a general class model or a more specific class model is a design trade off. The general model provides more flexibility but normally requires more coding of constraints to ensure only valid links are created between objects of those classes.
• Strategy pattern can be used to reduce the impact of changes to constraints used in a more general class model.

This article was is an update of CoadLetter #79.