Firstly, let me clarify some concepts according to my understanding:
1. Association End == Property, can be owned by Classifier or Association itself (e.g. N-ary Association)
2. In most cases, we are talking about Binary Association and the Association End is owned by the classifier connected to the Association.
In this case, Association End == Property == Classifier's attribute
3. Composition = Binary Association + (Property::aggregation = composite)
4. Aggregation = Binary Association + (Property::aggregation = shared)
Martin Fowler, The author of "UML Distilled" suggests that the aggregation link should not be used at all because it has no added value and it disturb consistency, Quoting Jim Rumbaugh "Think of it as a modeling placebo".
http://martinfowler.com/bliki/AggregationAndComposition.htmlThere is another clue for difference between Aggregation and Association, please refer to: http://ootips.org/uml-hasa.html
Aggregation is exactly the same as an association with the exception that instances cannot have cyclic aggregation relationships.
5. Dependency and Association describe things from different angle.
When talking about Dependency, there must be Supplier & Client. In UML, there are heaps of stereotyped dependency (e.g. <<use>>, <<trace>> ...)
When talking about association, one classifier has an attribute(Property) typed by another classifier; the instance of one classifier has (either owned or as reference) an instance of another classifier playing the role of the attribute.
Association usually implies dependency, but again, they dscribe things from different angle.
For example, in a basketball team, we may have following model:
Team
center: Player
small_forward: Player
power_forward: player
point_guard: Player
shooting_guard: Player
logo: Image (composite)
(1) there is dependency implied: if Player(Supplier) changed (e.g. all instances of Player can shoot from 100 yards away), then the Team(Client) must change(different offensive and defend tactics)
(2) 5 Team->Player associations or aggregations are implied; Each association has an association end owned by Team.
If instance of Team disband, instances of Player in this team can play for the other teams.
However, the team logo will be destroyed as well.
(3) If we create an instance "MiamiHeat :Team", then we can recruit James play the role of power_forward, Wade play the role of shooting_guard...
-------------------------
According to your question, the #1 depends on the navigability of your association. They are not true if the association is not bi-directional.
When do diagramming, the confusion usually comes from Aggregation VS Association. (answered by Martin Fowler
)
people usually don't have problem of using Composition if they have a clear design.
E.g. One modeler may design Car-Wheel to be composite while another one may think it is aggregation.
We can always find exception in real world against an existing model, which was designed to solve a problem in a specific context.
E.g. If I design wheels to be welded together with the car, it is composite; vice versa.
Personally, I think "end up with zero association relations" can not be applied to all cases (actually I think it is wrong if I don't know the context).
Just as the example above, one might prefer to create 5 attributes typed by Player while another modeler might prefer to use association to represent them.
In summary, Association is widely used in modeling. One concrete example is the UML Specification, refer to "Abstract Syntax" in each chapter.
