- Strategy 1: Ask the Domain Experts to Provide an Example
- Strategy 2: Use an Object Diagram to Illustrate a General Class Diagram
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Strategy 2: Use an Object Diagram to Illustrate a General Class Diagram
Question: In UML, how we can represent a hierarchy of objects from the same class?
Answer: As a class with an association to itself with one end of the association marked with 0..* and the other as 0..1 (see Figure 1).
){kind=link}
It's 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 of illustrating interactions between objects. However, both types of diagram have problems showing the sort of recursive interaction found in hierarchies of objects. Often it's easier to draw out an example of the hierarchy using UML's object notation and work with that.
Figure 1 A hierarchy of objects in UML.
Sometimes we can generalize a class diagram to a point where it's 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's an example from Java Modeling in Color with UML: Enterprise Components and Process (Prentice Hall PTR, 1999, ISBN 0-13-011510-X). An organization contains a set of Organizational Units that in turn contain sets of sub-units. The sub-units don't necessarily form a hierarchy; they can form a directed graph or network (see Figure 2).
){kind=link}
Figure 2 A general UML model.
Imagine a medium-sized 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. To cap it all, a headquarters 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 (see Figure 3). 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 headquarters object. We could augment the diagram with constraints to explain the rules. However, in this case it's probably better to simply list the rules in a note.
){kind=link}
Figure 3 Object diagram explaining the use of the OrganizationalUnit class.
The object diagram above is a little abstract; the objects don't represent specific objects in the problem domain but rather categories of objects. A more concrete example is shown in Figure 4. The more concrete example, especially if it's 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.
){kind=link}
Figure 4 Specific example of the use of the OrganizationalUnit class.
Notes
Whether to use a general class model or a more specific class model is a design tradeoff. The general model provides more flexibility but normally requires more coding of constraints to ensure that only valid links are created between objects of those classes.
Strategy pattern can be used to reduce the impact of changes to constraints in a more general class model. See Coad Letter #76 for a description of a somewhat analogous situation when modeling user roles.