I'm not sure if there is a standardised definition now. I've read many books about UML and there are many difference interpretations about assoziation, aggregation and composition.
In all books the following facts are valid:
1.) Composition is more stronger as aggregation
2.) Aggregation is more stronger as association.
The difference between association and aggregation (with my point of view):
An aggregation defines a whole part relation. There is an association between human and cars. A human can drive a car. But I think this is no aggregation, because a human is no part of the car.
An aggregation could be a racing driver and his team. Michael Schumacher was a member of the ferrari team. The relation between Michael Schumacher and Ferrari could be modeled as aggregation.
The difference between aggregation and composition:
A composition is a stronger aggregation. If you delete the whole - you have to delete the part. I think the relation between Michael Schumacher and Ferrari is no composition. If Ferrari would stop driving races, the drivers could go to another team.
It's much harder to say if the engine and the car is a composition or only an aggregation. I think with normal cars it is a composition. Normally you don't reuse an engine. If you sell a car, you will sell it with its engine.
But I think with racing cars, the relationship between a car and his engine is an aggregation because with racing cars the engine is changed many times.
When I code, I don't think in associations, aggregations and compositions. You can code all kind of the relations with instance variables or you can use a mapping algorithm.
Every compony has another view, how to use uml-diagrams. Some componies use uml-diagrams as a contract with the customer. I don't like it, because I can't expect that the customer can read UML or often he does have a different interpretation as I have.
Some companies thinks that the uml-diagrams must have nearly the same level of detail as the code. They want to generate code from the uml-diagrams. They expect the programmer has only to do some optimisation. So they are independent from the computer language. I don't like this view, because I don't know how to
test the correctness of a uml-diagram.
I think the best way to use uml-diagrams is to enforce communication or brain-storming. I like UML-diagrams only on white boards or on sheets of paper, that I use only for some days. If I have to introduce a new employee, it makes sense first to draw the relations of the most important classes and after this to concentrate on the code. I think it's much easier for the new employeer if he sees how I draw and explain the diagram, than to give him a printing. And if I can't explain the relations of the base classes without electronical help, I know that the my model is too complicated (or I'm to stupid for my job). The level of detail is much lower as code. I don't model inner classes. I think that is the decision of the programmer when to use inner classes.
