[Zope-dev] ZPatterns, ObjectDomain, UML and all that.....

[Steve Alexander]

Steve Spicklemire wrote:

> 
> 3) (Last question I promise!.. for now) Is there any real difference
> between the plain lines, open bubbles, and closed bubbles other than
> the number of (master) objects with relations to the (slave?). If both
> objects refer back to eachother, should there be two bubbles? (That
> doesn't seem to be an option with ObjectDomain.) Is there a good
> source on the net that talks about this stuff? I've been reading some
> of the specs at omg.org... and I'm guessing there's something out
> there more friendly ... but I haven't found it yet...

First off, a disclaimer: I don't think UML is all that helpful fr 
modeling Zope applications, or ZPatterns applications. I'll explain why 
some other time.

The "bubbles2" you're talking about are to indicate aggregation and 
composition.

These are different from the cardinality of the relationship.

See http://www.cat-box.net/steve/umltalk/page11.html for an example of a 
plain association, an association that says "a person may keep any 
number of cats, but a cat only has one owner", and an association with 
the roles "pet" and "owner".

On http://www.cat-box.net/steve/umltalk/page13.html, the diagram shows 
aggregation and composition. The examples are of a car, and a tooth. The 
enamel and fillings in a tooth are tightly bound together, and not 
really separable without pain (!). However, you can remove the engine 
and wheels from a car, and consider them separately, without too much 
trouble. So, the car example is aggregation, the tooth example is 
composition.

In UML, objects linked by composition are semantically equivalent to 
attributes. So, in the tooth example, I could have had the enamel and 
collection of fillings as attributes of the tooth.

Aggregation indicates a responsibility in the relationship. So, in the 
Car example, if I sell my car, or scrap my car, the engine and wheels go 
as well. However, if I break my car's engine, that has no implications 
for the rest of the car or its wheels, except that I need a new engine.

When you're expressing object-oriented designs, an aggregate 
relationship implies that the controlling object (the "master", with the 
diamond next to it) is responsible for creating, destroying, and 
answering queries about its aggregate objects.


If you want to learn UML, I recommend "Practical Object-Oriented Design 
with UML", Mark Priestley, pub. McGraw Hill, ISBN 0-07-079599-5.

I think Coad's notation is better and clearer, as it allows you to 
communicate information about objects and their classes all in one 
place. Coad's notation is more about showing interactions of objects, 
whereas UML makes that awkward, and is mostly used for expressing static 
information about relationships between classes.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net