The Coad Letter: Modeling and Design Edition, Issue 79, the Example Teaches, by Stephen Palmer
Welcome to another Coad Letter issue.
Working with a team building an object model recently, I was reminded
again of the power of a good example.
So this month two related strategies for using examples to illustrate
a class diagram.
ps Together 5.0 has been released - check out what's new at www.togethersoft.com
- JSP editor, EJB 2.0 and much, much more.
pps Thanks for all the feedback from last month's issue - especially
those who sent in additional suggestions for common developer ailments.
The Example Teaches
|"Example is the school of mankind, and they will learn at no other."
-- Edmund Burke
|"Example is always more efficacious than precept."
-- Samuel Johnson
|"The example teaches."
-- A Latin proverb
|"Example is not the main thing in influencing others, it is the only
-- Albert Schweitzer
|"Example isn't another way to teach, it is the only way to teach."
-- Albert Einstein
|"I'd rather see a sermon than hear one any day"
-- Edgar A. Guest
Strategy 2001-03-01: Ask the Domain Experts to Provide an Example
If you are having trouble visualizing whether a class diagram meets the
business needs, ask the domain experts to provide a concrete example that
you can walk through with them.
A good example is worth a thousand words of description.
A good example illustrates both the usual occurrences and the types of
exceptional cases that may arise.
A good example is complex enough to contain ample teaching points but simple
enough to be understood.
Question: In UML, how we can represent a hierarchy of objects from the
Answer: As a class with an association 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.
Strategy 2001-03-02: Use an object diagram to illustrate a general class
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.
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.
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. See Coad
Letter #76 for a description of a somewhat analogous situation when modeling