I feel confused about the three relationships Association, Aggregation and Composition in UML. I need to finish a project soon, until it became less unclear in my head, is it okay to use only Associations ?
Yes, of course it's okay. Both aggregation and composition are types of association. So what you create might not have all the detail it could have but it will still be correct. You can always add details later.
Remember that UML diagrams are models and not complete descriptions of the actual software.
I like to add that in many cases, there really is no clear or objective answer to the question if a given relationship is aggregation, composition or just association.
For more details, you could check this article.
Here's why this is so confusing:
| Ownership | Lifetime dependency | Association | none/anyone | none | Aggregation | one owner | none | Composition | one owner | on owner |
Those are some very clear definitions. We depict them this way:
However when you see
Does that guarantee there is no ownership or merely not insist on ownership? Composition is an Association after all. Now try to read this:
4 1 1 1 [Tire]---◆[Car]♢---[Spare Tire] | 1 | 1 [Cup of Coffee]
And tell me if the names or the UML give you a better understanding of what is going on. If you can't trust me to always use the narrowest relationship depiction possible the symbols stop being important.
Keep that in mind when you diagram. I'm not saying you always have to be 100% faithful, most people aren't, but take responsibility for that and somehow let us know when you are being serious about the symbols and when you aren't. Otherwise this becomes a write once, read never exercise.
Essentially, when you have an association, you're stating that at least one instance of A can be dynamically linked to at least one instance of B. You aren't constrained by the type of link existing between the two, other than it's a dynamic link, at class/instance level (i.e., an attribute, not a local variable in a method, that would be a dependency relationship instead). This is useful, for instance, when an instance simply makes use of another instance in a delegation.
When you use an aggregation, you're semantically stating that the instance of A is aggregating (e.g., "part of") at least an instance of B. This is a specialized version of an association, used for instance to model a container and the items it contains (the items of a list).
Composition is the most specialized kind of aggregation (and, by extension, of association). Semantically it expresses that A not only aggregates B, but that the instance cannot exist without its parts. Using a real-life example, it's like saying a LivingPerson needs a Brain and a Heart.
Of course, this is a matter of refining the model. If you are okay with just modeling the association and not going into much detail (usually in the early stages of the design/development, a practice recommended by Robert C. Martin), just go for associations only. If an aggregation or composition is semantically very relevant for the model, then you're somewhat forced to use them. The same goes for a lot of other UML elements (the stereotypes of a dependency, cardinalities...) The key part is that the model is clear enough to be understandable, yet concise enough to provide a clear understanding of the idea being modeled.