Association and aggregation dependencies in UML class diagrams and their differences

Association and aggregation dependencies in UML class diagrams and their differences

This article focuses on the relationship between UML class diagrams. The main types of UML class diagrams include association, aggregation/combination, dependency, and generalization. Here we will introduce the association, the relationship between aggregation and dependency and their differences.

UML class diagram relationship

1. Association

Bidirectional Association:

C1-C2: both parties know the existence of the other side, can call the other side of the Public attributes and methods.

This is described in the gof design patterns book: although this relationship is applicable in the analysis phase, we think it is too abstract to describe the class relationships in the design patterns, because the link must be mapped to an object reference or pointer during the design phase. Object Reference itself is directed and is more suitable for expressing the relationship we are discussing. Therefore, this relationship is rarely used during design, and associations are usually directed.
Two-way association shows that both parties have a pointer to each other in the Code. Of course, it can also be a reference or a value.

Unidirectional Association:

C3-> C4: indicates the acquaintance relationship. C3 knows C4 and C3 can call the common attributes and methods of C4. There is no life cycle dependency. It is generally a reference.
Code with one-way association shows that C3 has C4 pointer, while C4 has no knowledge about C3.

Self-Association (reverse Association ):

Reference yourself with your own reference. That is, there is a reference within your own.

2. Aggregation/Combination

When there is an integral-partial relationship between classes, we can use the combination or aggregation in the UML class diagram relationship.

Aggregation: indicates that c9 aggregates C10, but C10 can leave C9 and exist independently (the existence of this class makes sense in the problematic domain of an application. For more information about this sentence, see the explanation in the combination below ).

Combination (also known as inclusion): it is usually indicated by solid diamond and solid line arrows, as shown in. It indicates that C8 is tolerated by C7, and C8 cannot be independent from C7. However, this depends on the problem domain. For example, in the field of concerned about automobiles, tires must be combined in the automobile industry because it makes no sense when it leaves the automobile. However, in the shops where tires are sold, even if the tires leave the car, it makes sense, and this can be aggregated. In Agile development, we also said that if a combines B, A needs to know the lifecycle of B, that is, a may be responsible for generating or releasing B, or a knows the generation and release of B in some way.

3. Dependency

Dependencies in UML diagrams indicate that C5 may use some methods of C6. You can also say that the assistance of C6 is required to complete all functions of C5. C5 depends on the definition of C6. It generally contains the header file of C6 in the header file of C5 class. Rose does not generate attributes for the dependency.

Note: Avoid bidirectional dependency. Generally, there should be no two-way dependency.

Although Rose does not generate attributes, it is generally a method in form that uses the object of B as a parameter (assume that a depends on B ). As follows:
# Include "B. H"
Classa
...{
Voidfunc (B & B );
}

What are the differences between dependency and aggregation/combination and association in UML class diagrams?

Association is a kind of relationship between classes. For example, teachers teach students, husbands and wives, and water bottles are a kind of relationship. This relationship is very obvious and can be obtained directly through analysis in the problem field.

Dependency is a weak Association. When one class uses another class, but the relationship with the other class is not too obvious (it can be said that the class is "uses ), we can regard this relationship as dependency, and dependency can also be said to be an accidental relationship, rather than an inevitable relationship, that is, "I accidentally used it in a method, but in reality, I have little to do with it ". For example, I have nothing to do with a hammer, but I used it when I had to nail it. This is a dependency that relies on a hammer to complete the dingtalk.

A combination is a whole-part relationship. In the problem domain, this relationship is obvious and can be obtained through direct analysis. For example, tires are a part of a car, leaves are a part of a tree, and hands and feet are a part of the body. This relationship is very obvious as a whole-part relationship.
The preceding relationships (Association, aggregation/combination, and dependency) may appear in the code in the form of pointers, references, values, and so on in another class, but logically, they have the above differences.