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