Need Details (code examples for relationships)

[Johnson K Jose]

Dear Friends,
I have following details regarding the relationship between various classes.
1. Association
An Association is a generic relationship between two classes, and is modeled by a line connecting the two classes. This line can be qualified with the type of relationship, and can also feature multiplicity rules (eg. one-to-one, one-to-many, many-to-many) for the relationship.
2. Composition
If a class cannot exist by itself, and instead must be a member of another class, then that class has a Composition relationship with the containing class. A Composition relationship is indicated by a line with a filled diamond.
3. Dependency
When a class uses another class, perhaps as a member variable or a parameter, and so "depends" on that class, a Dependency relationship is formed. A Dependency relationship is indicated by a dotted arrow.
4. Aggregation
Aggregations indicate a whole-part relationship, and are known as "has-a" relationships.
An Aggregation relationship is indicated by a line with a hollow diamond.
5. Generalization
A Generalization relationship is the equivalent of an inheritance relationship in object-oriented terms (an "is-a" relationship). A Generalization relationship is indicated by an arrow with a hollow arrowhead pointing to the base, or "parent", class.
Still except Generalization (here child class extends from the base class) I am not able to visualize the above concepts with respect to a Java code example. Can anyone please provide some light on these?
Thanks in advance
Regards
Johnson :roll: Association
[edited the subject to be more expressive - Ilja]
[ October 10, 2003: Message edited by: Ilja Preuss ]

[Jose Botella]

An association represents a relationship between instances of classes
class Teacher {
Students[] sa;
}
A teacher teaches a number of students.
An aggregation is an association in which there is a compound object and a number of "part" objects (maybe only one)
class Book {
Pages[] pa;
}
This book has 73 pages.
A composition is an aggregation in which a part object cannot exist out of the whole part. The lifetime of the part object is dictated by the whole object. Generally it is created and destroyed at the same time as the whole.
class Book {
Dedication d;
}
Robinson was so kind to handwrite a dedication on my copy of Swing 2nd.
A dependency states that an element (class, use case etc) has knowledge of another. It implies that if the independant element changes, the dependant should also change. Generally it means that there is a non attribute visibility, such as global, local or parameter.
class Book {
void print(PrintingPress pp) {...}
}
The print method would likely to be changed if the printing press does so.
_________________________________________________________________________
A good introduction to UML is UML Distilled by Martin Fowler.

[Stan James]

Isn't it interesting that all of those could be represented as a simple member variable? (If we allow dependency to be an attribute kinda thing.) It takes more code to see the differences in access, control and life cycle.
For example, if "page" were a non-visible inner class of book, one could only create a page or look at its contents by going through book methods. Another object could never tear a page out of a book by getting a page reference. Oops, I changed page from aggregation above to composition, didn't I?
Maybe another aggregation would be the classic car & wheels. Can a car exist without wheels? Sure, there's a Camaro on blocks in every town. Wheels without cars? Yup, I can mail-order new wheels and have them put on my, um, Camaro.
Are there any associations that are not dependencies? Maybe a container that holds generic objects and never has to operate on them?