You should read an application's domain/buisness requirements and then be able to "maybe" distinguish between aggregation and association.
At the code level, you may not be able to see a difference. Or, if you read enough classes and trace various execution paths, then you might be able to see the difference.
Either way, an object-oriented design should be "based" on domain/business requirements and this is where you should go to further understand design diagrams.
Hope this helps!
Joined: Jan 28, 2010
Thanks for your input.
I'm not trying to figure out of what type some relationship is in a piece of code.
What I'm asking, is given a diagram implemented in Java, if I take that diagram
and I randomly start replacing associations with aggregations (or vice versa) and
then write it in Java again, will it yield the same code?
The goal is to know whether or not I should be asking myself : do I have an association
or an aggregation here? when designing my programs.
Joined: Apr 16, 2008
You are welcome
You the programmer are in charge and control of reading a diagram and then writing code that implements what you think the diagram means. An Aggregation relationship is a type of Association, so it may be tricky to distinguish this from code statements (on the surface.) It is clearly distinguishable in diagram notation however. This is why I mentioned using the written requirements to understand whether it should be this one or that one.
The goal is to know whether or not I should be asking myself : do I have an association or an aggregation here? when designing my programs.
Here is where you should be referring to the requirements to figure out if you should design to an Aggregation or an Association. The answer to this question is in the written requirements, it is not in the code. The requirements come first, then you create UML diagrams and then you write the code. You should know whether you have an Association or an Aggregation relationship when you are creating the diagrams.
If you are attempting to design an application without requirements, this is another issue outside the scope of interpretting UML notation.