A comprehensive analysis of UML class diagram relationships

UML's class diagram relationships are divided into: Association, aggregation/composition, dependency, generalization (inheritance). And the association is divided into two-way association, one-way association, self-correlation; Let's take a look at what these relationships are and where they differ.

1. Association


Bidirectional Association:
C1-C2: Refers to both sides know each other's existence, can call each other's public properties and methods.

This is described in the GOF design pattern book: Although this relationship is applicable in the analysis phase, we feel that it is too abstract to describe the class relationship within the design pattern, because the association relationship must be mapped to an object reference or pointer in the design phase. Object references are inherently self-contained and better suited to expressing the kind of relationship we are talking about. Therefore, this relationship is less used in the design time, the association is generally a direction.

The code generated by using Rose is this:

Class C1
{
Public
C2* theC2;

};

Class C2
{
Public
C1* theC1;

};

Two-Way association in the code of the performance of both sides have a pointer to each other, of course, can also be a reference or value.





One-Way Association:
C3->C4: Indicates an acquaintance relationship, meaning that C3 knows C4,C3 can invoke the public properties and methods of C4. There is no life-time dependency. is generally represented as a reference.

The generated code is as follows:

Class C3
{
Public
c4* theC4;

};

Class C4
{

};

The one-way association code behaves as C3 has C4 pointers, and C4 is ignorant of C3.

Self-correlation (reflexive Association):
Himself by quoting himself, with a reference of his own.

The code is as follows:

Class C14
{
Public
c14* theC14;

};

is to have a self-reference within yourself.

2. Aggregation/Combination

When there is a whole-part relationship between classes, we can use combinations or aggregations.



Aggregation: Represents the C9 aggregation C10, but C10 can leave the C9 and exist independently (independently of the meaning that this class exists in the problem domain of an application. How to solve this sentence, please see the following in the combination of explanations).

The code is as follows:

Class C9
{
Public
C10 theC10;

};

Class C10
{

};

Combination (also known as containment): The general is a solid diamond plus solid line arrows, as shown, indicates that C8 is C7 tolerant, and C8 can not leave C7 and independent existence. But this is depending on the problem domain, for example, in the field of care for cars, tires must be combined in the car category, because it is meaningless to leave the car. But in the business of selling tires, even if the tires leave the car, it makes sense, and it can be aggregated. In "agile development" also said that a combination B, then a need to know the life cycle of B, that is, may be responsible for generating or releasing B, or a in some way to know the generation and release of B. http://hovertree.com/

Their code is as follows:

Class C7
{
Public
C8 theC8;

};

Class C8
{
};

You can see that the code and the aggregation are the same. Specific how to distinguish, may only be used to distinguish the meaning of words.

3. Reliance



Depend on:
Refers to C5 may need to use some of the methods of C6, can also say, to complete all the functions of C5, must have C6 method of assistance. C5 relies on the definition of C6, which typically contains the C6 header file in the header file of the C5 class. Rose does not produce a property on the dependency relationship.

Note that you want to avoid two-way dependencies. In general, there should be no bidirectional dependencies.

Rose generates the following code:

C5.h
#include "C6.h"

Class C5
{

};

C6.h
#include "C5.h"

Class C6
{

};

Although Rose does not generate attributes, it is generally formally a method in a that uses the object of B as a parameter (assuming a depends on B). As follows:

#include "B.h"
Class A
{
void Func (B &b);
}

What is the difference between dependency and aggregation/combination, correlation, etc.?

Association is a relationship between classes, such as teachers teaching students, husbands and wives, water bottles and so on is a kind of relationship. This relationship is very obvious and can be derived directly from the analysis in the problem area.

Dependency is a weak association, as long as one class is used to another class, but the relationship to another class is not too obvious (it can be said that the "uses" the Class), it can be regarded as a dependency, dependence can be said to be an accidental relationship, rather than the inevitable relationship, that is, "I used it in some way, But in reality I don't have much to do with it. " Like me and the hammer, I had nothing to do with the hammer, but I used it when I was going to nail a nail, and it was a dependency that depended on the hammer to nail the nail.

The combination is a whole-part relationship, which is obvious in the problem domain, and can be obtained by direct analysis. For example, tires are part of a car, leaves are part of the tree, hands and feet are part of the body of this relationship, a very obvious whole-part relationship.

Several of these relationships (associations, aggregations/combinations, dependencies) may appear in code in another class in the form of pointers, references, values, and so on, but logically they have the difference.

It is also stated here that the so-called relationships are only valid in a problem domain, leaving the problem domain, which may not be the case, for example, in a problem domain, I am a carpenter, need to take a hammer to work, perhaps the whole question is the description of how I nailed the table with the hammer, nailed the chair, nailed the cupboard Since the whole problem is to describe this, I and the hammer is not only accidental dependence, I and the hammer relationship becomes very close, may rise to a combination of relations (let me suddenly think of the martial arts swordsman Sword, the sword died ... ）。 This example may be a bit absurd, but it is also to illustrate the truth that relationships and classes are all set up in a problem area, leaving the problem domain and they may no longer exist.


4. Generalization (inheritance)



Generalization relationship: Used when two classes have generalized relationships, such as fathers and children, animals and tigers, plants and flowers.
The code rose generates is simple, as follows:

#include "C11.h"

Class C12:public C11
{
};

5, here by the way to mention the template



The code for the above diagram corresponds to the following:

Template<int>
Class C13
{
};

Repeat here again, in fact, after reading the above description, we should understand the relationship between the relationships and specific to the code is how, so-called repetition, is only the above extension, such as A and B has a "1-to-many" of the repetition, there is a list in a, which holds the B object's n references , that's it.

Well, to here, already put the above diagram of the relationship is finished, I hope you can have some gains, I also spent a lot of time ah (drawing, generate code, write to the blog, alas, a sweat). But it's worth it if you can get a thorough understanding of these relationships in UML class diagrams. :)

http://www.cnblogs.com/roucheng/

A comprehensive analysis of UML class diagram relationships