UML union and association

Question

Here I am with another question about aggregation and association. I wanted to learn some of the basics of UML, so I started reading Martin Fowler's “UML Distilled”. I read both chapters about classes, and there is one thing that I cannot fully understand, I think, is aggregation versus association. The book has this quote:

In the days before UML, people were usually pretty vague about what aggregation is and what association is. Regardless of whether they were vague or not, they were always incompatible with everyone else. As a result, many model designers believe aggregation is important, albeit for various reasons. Thus, UML includes aggregation (Figure 5.3), but with little or no semantics. As Jim Rambo says, “think of it as a placebo for modeling” [Rumbaugh, UML Reference].

As I understand from this quote and the ones that I read when the stack overflows, it doesn’t matter which of these two relationships I use, they mean basically the same thing, or is there a situation where using aggregation instead of association would be justified and / or I could not exchange one for another without changing the "value" of the class diagram?

I ask this because this book was written in 2003, and some things could change over the last few years.

Answer 1

Rumbo's statement is Uncle Bob's most famous and good advice. As I said elsewhere , aggregation is semantically so weak that practically nothing is profitable. This has only one valid angular case (acyclicity of recursive relations), however few people know and understand this. So you should still indicate in the comments anyway.

I just do not use it. And they never felt the loss. Stick to simple binary associations and focus on what really matters - getting power and the right name. You will get much more from this than trying to solve the insoluble link against aggregation.

NTN.

Answer 2

Maybe this can help you, but I don’t think you will find the perfect explanation:

The difference is one of the implications. Aggregation means the whole / part and associations do not. However, there is not likely to be a big difference in how these two relationships are implemented. That is, it would be very difficult to look at the code and determine if there should be a special aggregation or association relationship. For this reason, it is fairly safe to completely ignore the aggregation relation.
[Robert C. Martin | UML]

And an example for each situation:

a) Association is a relationship in which all objects have their own life cycle and no owner. Let's take the example of Teacher and Student. Several students can communicate with one teacher and one student can communicate with several teachers, but there is no ownership between the objects, and both have their own life cycle. Both can create and delete independently.

b) Aggregation is a specialized form of the Association, where each object has its own life cycle, but there is property and the child, the object cannot belong to another parent object. Let's take the example of the Department and the teacher. One teacher cannot belong to several departments, but if we delete the department, the teacher’s object will not be destroyed. We can think of an yes relationship.
[Maesh | GeeksWithBlogs]

Answer 3

I tend to use Aggregation to display a relationship that matches composition with one big difference: the containing class is not responsible for the life cycle of the contained object. Typically, a pointer (not null) or a reference to the object to be contained is passed to the containing constructor of the class. The containing object throughout the entire life cycle depends on the existing object. The containing object cannot do its job (completely) without the containing object. This is my interpretation of the part / whole relationship implied by Aggregation.

Answer 4

In UML, aggregation is undefined and because they do not have well-defined semantics. A valid example of using aggregation is the encapsulation of several classes, as described in Eric Evans' Driven Driven Development.

eg. The car has four wheels. You can calculate the total number of meters that each wheel has launched for each car. This calculation is made by the car entity, because it knows which wheels it has, and you don't care which wheels belong to which car.

A car is the root of aggregation for all its parts, such as wheels, and you cannot access parts of the car from outside the aggregation, just the root.

Thus, basically aggregation encapsulates a set of classes that belong to each other.

Answer 5

A wise implementation does not make much difference, but conceptually there is a big difference: aggregations are used to express hierarchies. When you work with a component hierarchy, certain types of operations must be in the root interface:

• find subcomponents in a hierarchy
• add / remove subcomponents to / from hierarchy
• change the common attributes of all components
• move hierarchy recursively (visitor pattern)
• reconfigure hierarchy and links (associations) between components

Most of these operations are not needed when working with associations.

Answer 6

This term is often confused.

Aggregation and composition are some of the types of associations. there is hardly a difference between aggregations and associations during implementation, and many will skip aggregate relationships in general in their diagrams with association relationships.

You can get this idea from this analogy.

Class: A (person) and class: B (car) has an association association if Class: A has a class declaration: B, and also an object of class: B (car) is not essential to create an object of class: A (person).

Class: A (car) and class: B (bus) are aggregated if Class: A has a class declaration: B, as well as a class object: B (bus) is essential to create a class object: A (car).

Hurrah!

Answer 7

To add, I would simply suggest downloading the UML specification from OMG: the best link and have a look at p 110.

none Indicates that the property does not have aggregation semantics.

shared Indicates that the property has common aggregation semantics. The exact semantics of general aggregation depends on the application area and the fashion designer.

composite Indicates that the property is aggregated in different ways, i.e. a compound object is responsible for the existence and storage of compound objects (see definition of parts in 11.2.3).

Answer 8

They do not mean the same thing! I can say this:

Association association : a class refers to another class. In fact, this shows that the class is associated with another class, but they do not necessarily have attributes to display these relationships ... for example, “Teacher” and “Students”, although the class “Teacher” does not have an attribute that applies to students, but we know that the teacher actually has students ... And also the "School" class has "teachers" and "student properties", which now make these two classes connected to each other.

Aggregation ratio : class contains another class. But if the container (ClassRoom) is destroyed, then the contained one (chair) is not. In fact, ClassRoom owns the Chair. Aggregation is stronger than Association relationships.

Here is also a tutorial about this and all of UML2.0 that explains everything easily and simply, you might find it useful: https://github.com/imalitavakoli/learn-uml2

TIP . Also let me say that since association relationships exist between classes most of the time, we sometimes don’t do this to prevent unnecessary complexity.