Apply the UML class diagram to the corresponding code set [collected on the network]

 

I,UML diagram and code representation of class-to-class relationships

 

The relationship between classes plays an important role in understanding object-oriented objects. I was often asked this question during interviews. Here I will introduce it.
There is a relationship between the class and the class:
(1) Generalization)
(2) Association)
(3) Dependency)
(4) Aggregation)

UML diagram and application code example:
1. Generalization)
[Generalization]
Represents the inheritance relationship between classes, the inheritance relationship between interfaces, or the Implementation relationship between classes on interfaces. The general relationship is directed from the subclass to the parent class, which is opposite to the inherited or implemented method.
[Specific performance]
Parent class instance = new subclass ()
[UML diagram] (Fig. 1.1)

Figure 1.1 Dependency between animal class and tiger class and Dog class

[Code performance]

1. ClassAnimal {}
2. ClassTiger extends Animal {}
3. PublicClass Test
4. {
5. Public void test ()
6. {
7. Animal a = new Tiger ();
8. }
9. }

2. Dependency)
[Dependency]
For two relatively independent objects, when one object is responsible for constructing an instance of another object or dependent on the service of another object, the two objects are mainly dependent on each other.
[Specific performance]
Dependencies are manifested in local variables, method parameters, and calls to static methods.
[Real-world example]
For example, if you want to screw the screw, do you want to use (that is, rely on) the screw driver to help you complete the screw (screw) work?
[UML representation] (Figure 1.2)

Figure 1.2 dependency between the Person class and the Screwdriver class

[Code performance]

1. PublicClass Person {
2. /** Screw */
3. Public void screw (Screwdriver screwdriver ){
4. Screwdriver. screw ();
5. }
6. }

3. Association)
[Association]
For two relatively independent objects, when the instance of one object has a fixed ing relationship with some specific instances of the other object, the two objects are associated.
[Specific performance]
Associations are implemented using instance variables.
[Real-world example]
For example, for customers and orders, each order corresponds to a specific customer, and each customer corresponds to a specific order. For example, for companies and employees, each company corresponds to a specific employee, each employee corresponds to a specific company
[UML diagram] (Fig. 1.3)

Figure 1.3 association between companies and employees

[Code performance]

1. PublicClass Company {
2. Private Employee employee;
3. Public Employee getEmployee (){
4. Return employee;
5. }
6. Public void setEmployee (Employee employee ){
7. This. employee = employee;
8. }
9. // Company operation
10. Public void run (){
11. Employee. startWorking ();
12. }
13. }

(4) Aggregation)
[Aggregation]
When object A is added to object B and becomes an integral part of object B, object B and object A are clustered. Aggregation is a type of association. It is a strong association, emphasizing the relationship between the whole and the part.
[Specific performance]
Like the association relationship, the aggregation relationship is also implemented through instance variables. There is no way to distinguish between associations and aggregation syntactically. In terms of semantics, the difference between the two can be better distinguished.
[Differences between Association and aggregation]
(1) The two objects involved in the Association are at the same level. For example, people and bicycles are associated rather than aggregated, because people are not composed of bicycles.
The two objects involved in an aggregation relationship are at an unequal level. One represents the whole and the other represents the part. For example, the computer and its display, keyboard, motherboard and memory are clustered, because the motherboard is part of the computer.
(2) For two objects with a clustering relationship (especially a strong clustering relationship), the overall object will restrict the lifecycle of the object that consists of it. Objects of a partial classification cannot exist independently. The lifecycle of an object depends on the lifecycle of the object of the entire class. When the entire lifecycle disappears, the partial lifecycle disappears. For example, if Michael's computer is stolen, all the components of the computer do not exist, unless Michael has removed some computer components (such as hard disks and memory) beforehand.
[UML diagram] (Fig. 1.4)

Figure 1.3 computer and component Aggregation

[Code performance]

1. PublicClass Computer {
2. Private CPU;
3. Public CPU getCPU (){
4. Return cpu;
5. }
6. Public void setCPU (CPU cpu ){
7. This. cpu = cpu;
8. }
9. // Enable the computer
10. Public void start (){
11. // Cpu operation
12. Cpu. run ();
13. }
14. }

 

 

II,

Comprehensive Analysis of UML class diagram relationships

 

 

 

UML class diagram relationships include association, aggregation/combination, dependency, and generalization (inheritance ). The Association is divided into two-way Association, one-way Association, and self-Association. Let's take a look at what these relationships are and what their differences are.

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.

The code generated using ROSE is as follows:

Class C1
{
Public:
C2 * theC2;

};

Class C2
{
Public:
C1 * theC1;

};

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.

The generated code is as follows:

Class C3
{
Public:
C4 * theC4;

};

Class C4
{

};

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.

The Code is as follows:

Class C14
{
Public:
C14 * theC14;

};

That is, there is a reference within your own.

2. Aggregation/Combination

When there is an integral-partial relationship between classes, we can use combination or aggregation.

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 ).

The Code is as follows:

Class C9
{
Public:
C10 theC10;

};

Class C10
{

};

 

Combination (also known as inclusion): Generally, solid diamond and solid line arrows indicate 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.

Their code is as follows:

Class C7
{
Public:
C8 theC8;

};

Class C8
{
};

As you can see, code is the same as aggregation. The specific differences may only be distinguished by semantics.

3. Dependency

Dependency:
Some methods of C6 may be used in C5. You can also say that the assistance of C6 must be provided to complete all functions in 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.

The code generated by Rose is as follows:

// C5.h
# Include "C6.h"

Class C5
{

};

// C6.h
# Include "C5.h"

Class C6
{

};

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"
Class
{
Void Func (B & B );
}

What is the difference between dependency and aggregation/combination and association?

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.

Dependent is a weak Association. When one class uses another class, but the relationship with another 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.

It should also be noted that the so-called relationships are valid only in a problem domain. If the problem domain is left, these relationships may not be valid, for example, they may be in a problem domain, I am a carpenter and need to work with a hammer. The whole problem may be described as how to pin the table, chair, and cupboard with a hammer. Since the whole problem is described as follows, the relationship between me and the hammer is not only accidental dependencies, but the relationship between me and the hammer has become very close and may rise to a combination relationship (reminds me of the sword of martial arts novels, the sword is dead ...). This example may be a bit ridiculous, but it is also to illustrate the truth that, like links and classes, they are all established in a problem field and leave this problem field, they may no longer exist.

4. generalization (inheritance)

Generalized relationship: This is used if two classes have generalized relationships, such as parent and child, animals and tigers, plants and flowers.
The code generated by ROSE is as follows:

# Include "C11.h"

Class C12: public C11
{
};

5. The template is mentioned here by the way.

The code for the above figure is as follows:

Template <int>
Class C13
{
};

Let's talk about the degree of repetition. In fact, after reading the above description, we should be clear about the relationship between the various relations and what the code is like, the so-called degree of repetition, it is just an extension above. For example, if A and B have A "one-to-many" repetition degree, there is A list in A that stores N references of object B, that's all.

Now, I have finished the class graph relationship above. I hope you will get something better. I have also spent a lot of time (drawing, generating code, writing to BLOG, alas, a sweat ). However, it is worth it if you can thoroughly understand the relationships of UML class diagrams. :)

 

 

 

 

 

 

Iii. UMLExample

Code:

interface IFly{    void Fly();}

interface ILanguage{    void Speak();}

class WideGoose : IFly{}

class Penguin : Bird{    private Climate climate;}

class WideGooseAggregate{    private WideGoose[] arrayWideGoose;}

class Bird{    private Wing wing;    public Bird()    {        wing = new Wing();    }}

abstract class Animal{    public Metabolism(Oxygen oxygen,Water water)    {    }}