See how UML For Java Programmers looks. A quick glance at the source code zip file looks like it follows a few designs from inception to completion, which ought to be pretty cool. Ooh! Slides from a presentation on the same topic. Uncle Bob is always good.
And note that he deliberately doesn't go to the level of detail of Aggregation vs Composition. Code doesn't really tell you much about either one. For example your example might be composition - a composed object doesn't necessarily have to compose itself. [ June 19, 2006: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
UML is an abstraction is supposed to be an abstraction from the code, which means that in fact there isn't a simple one to one mapping from UML to code. That is, there is are plenty of different ways to implement association, aggregation and composition in Java, and deciding on which one to use is the creative part of the programming job - there cannot be a cookbook for that, in my not so humble opinion.
That doesn't mean that there can't be advice, though. Can you tell us more about where you are coming from, why you are asking this question, so that we are in a better position to help you?
How much do you know about the semantics of the UML concepts?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 29, 2003
I'm pretty sure Uncle Bob didn't go to that level of detail because he felt it largely didn't matter. To Ilja's question about the semantics ... exactly how would your expectations for behavior in a composition relationship differ from an aggregation relationship? That's not a trick question - I hope you really have some answers. Will you code objects differently to make that happen, or just use them differently?
In one project I felt it was important to fill in the composition decoration on diagrams to let others know one object was responsible for the life cycle of another. It told people something about the intent of the design and how they should use objects, but probably made no difference at all in the Class itself. I don't recall if it was important because of the language (not Java) or the framework we were using, or the skills of the team. But I haven't much bothered with it in more recent projects.
You mentioned the word "Dependencies". Uncle Bob is all over those! His "Agile Software Development" book (also called PPP for the subtitle) is a goldmine on dependency management ideas.