Four types of relationships and code implementation of class diagrams in UML, and four types of uml

Four types of relationships and code implementation of class diagrams in UML, and four types of uml

In the uml diagram, the most complex relationships are generalization, implementation, dependency, and association, if you understand these relationships, you will become familiar with understanding the UML diagram!

If you are not familiar with several relationships, you can take a look at the four relationships in uml. This blog briefly introduces these relationships. This article will focus on the introduction, how can these relationships be implemented in the code!

General Relationship

I think this may also be the simplest relationship. generalization is a special half of the process, that is, the opposite process of inheritance. Subclass inherits from the parent class, the parent class is generalized from the subclass!

A generalized relationship is a function that inherits from another class (called the parent class and parent interface, it can also add its own new function capabilities. inheritance is the most common relationship between classes or interfaces and interfaces. in Java, such relationships are identified by the keyword extends, in c #, it is represented. It is generally not controversial during design.

<Span style = "font-size: 18px;"> namespace DEMO {// class inheritance class ClassB: ClassA {} // interface inheritance interface InterfaceB: interfaceA {}}</span>

Implementation relationship

The implementation (realization) relationship refers to the function of a class to implement interface interfaces (multiple); implementation is the most common relationship between classes and interfaces; in Java, such relationships are clearly identified by the keyword implements, and ":" is used in c # to indicate that they are generally not controversial during design;

<Span style = "font-size: 18px;"> namespace DEMO {// class implementation Interface class ClassC: InterfaceC {}}</span>

Dependency

Dependency relationship: it is also a connection between classes. It indicates that one class depends on the definition of another class. dependency is always one-way. It can be simply understood that A class A uses another class B, and this relationship is contingent, temporary, and very weak, but changes in Class B will affect A. For example, if someone wants to cross the river and borrow A ship, the relationship between people and the ship is dependent. It is manifested in the Code layer, class B is used by Class A in A method as A parameter. You can also declare the variable of this class in the method weight, or directly reference this class!

Public class Boat {// <summary> /// cross the river // </summary> public voidriverCrossing () {// start // cross the river} public staticvoid riverCrossingByShip () {// cross the river with a large ship} // end Boat public class Person {// use the Bote class in the form of parameters. // The Bote class is held by a method of the Person class, the lifecycle ends with the completion of method execution. /// <Summary> /// crossing the river /// </summary> /// <paramname = "bote"> instance of the Ship </param> public voidriverCrossing (Boat bote) {bote. riverCrossing ();} // variable in the method weight life class // pay attention to the life cycle of the Bote class. It is instantiated only when the riverCrossing method is called. // It is the most important to hold the Bote class as a method of the Person class rather than the Person class. Public voidriverCrossing () {Boatbote = new Boat (); bote. riverCrossing ();} // directly apply the public voidriverCrossing () {Boat. riverCrossingByShip () ;}// end Person

Association
An association is indicated by a solid line and an arrow. Indicates that the relationship between classes is stronger than the dependency.
For example, the relationship between water and climate is as follows:

The Code is as follows:

<Span style = "font-size: 18px; "> namespace DEMO {// <summary> /// Water // </summary> class Water {// an instance of the bar climate class serves as a variable of this class! Public Climateclimate; publicWater () {}}// <summary> // Climate /// </summary> class Climate {publicClimate () {}}</span>

It can be seen that the Climate class is added to the Water class attribute.
Associations include one-way Association, two-way Association, self-Association, and multi-dimensional association. The last three can be left empty.
Unidirectional Association:

Bidirectional Association:

Self-Association:

Multi-dimensional association:

Differences between Association and dependency:
From the perspective of adding class attributes:
No attribute is added to any of the dependent classes. One of these classes serves as a parameter or return value for the method of another class, or as a variable of a method.
Two classes with associations, one of which becomes the attribute of another class, and the property is a more closely coupled, more persistent hold relationship.
From the perspective of link lifecycle:
Dependency is generated only when the class method is called and ends with the end of the method.
Associations are generated when the class is instantiated. When the class is destroyed, the link ends. Compared with dependency, the associated relationship has a longer lifetime.
The link is divided into aggregation and combination by link strength. The examples of Dayan and yundun are described below!
Geese like to be lively and afraid of loneliness, so they have been living in a group, so they have a group. Each of them has its own group, and each group has many geese, this relationship between geese and geese can be called aggregation.
In addition, each wild goose has two wings. The relationship between the wild goose and the wild goose wings is called combination.
It can be seen that:
The aggregated relationship is obviously not closely formed, and the geese will not survive because their Group Owners disband the geese;
However, yundun cannot survive independently from the yundun-the composite class has the same lifecycle.
Aggregation relationship diagram:

Combination relationship diagram:

The Code is as follows:

<Span style = "font-size: 18px;"> namespace DEMO {// <summary> // geese // </summary> class GooseGroup {public Goosegoose; publicGooseGroup (Goose goose) {this. goose = goose ;}/// <summary> /// Dayan /// </summary> class Goose {publicWing wing; publicGoose () {wing = new Wing () ;}}</span>

The difference between the two relationships is:
1. Different Constructors
The constructor of an aggregate class contains instances of another class as parameters.
Because the constructor transmits an instance of another class, the geese can exist independently from the geese.
Constructor of a combination class contains instantiation of another class
Because the constructor is instantiated, the two are closely coupled, and the wings cannot be separated from the geese.
2. Different information Encapsulation
In the aggregation relationship, the client can understand the GooseGroup class and Goose class at the same time, because they are independent.
In the composite relationship, the client only recognizes the geese and does not know the existence of the wings, because the wings are tightly encapsulated in the geese.

Summary:

There is no doubt about the relationship between inheritance and implementation. They reflect the vertical relationship between a category and a class, or between a class and an interface; the other four relationships reflect the reference and horizontal relationships between classes and classes, or between classes and interfaces, which is difficult to distinguish, there are many relationships between things. It is very difficult to prepare for positioning. As mentioned above, these relations are all semantic-level, so they cannot be fully differentiated from each other at the code level; but in general, the strength of the last several relationships is: Combination> aggregation> dependency.

 

Summary of several types of UML class diagrams

In a UML diagram, there are several common relationships: Generalization, implementation, Association, Aggregation, and Composition ), dependency 1. generalization (Generalization) [Generalization relationship]: it is an inheritance relationship that specifies how the child class features and behaviors of the parent class. For example, a tiger is an animal. arrow pointing: solid line with a triangular arrow. arrow pointing to parent class 2. implementation (Realization) [Implementation relationship]: The relationship between a type and an interface, indicating that the class is the implementation of all features and behaviors of the interface [arrow pointing]: dotted line with a triangular arrow, arrow pointing to interface 3. association: an Association that allows a class to know the attributes and methods of another class, the relationship between husband and wife can be bidirectional or unidirectional. Two-way association can have two arrows or no arrows, and one-way Association has one arrow. [Code embodiment]: member variable [Arrow and pointing]: a solid line with a common arrow pointing to the owner. The teacher and the student are two-way connections. The teacher has multiple students, the student may also have multiple teachers. However, the relationship between a student and a course is one-way association. A student may have to take multiple courses. The course is an abstract thing and he does not have any students. For Itself: 4. aggregation: the relationship between the whole and the part. for example, the overall and partial relationship between a car and a tire is. an aggregation relationship is a strong association relationship. The association and aggregation cannot be distinguished in syntax, and the specific logical relationship must be investigated. [Code embodiment]: member variable [Arrow and direction]: solid line with hollow diamond, the diamond points to the whole 5. composition: The relationship between the whole and the part ., without a company, there is no department composite relationship. This is a type of association relationship, which is stronger than the aggregation relationship, it requires that the object representing the whole in a common aggregation relationship be responsible for representing the lifecycle of some objects [Code embodiment]: member variable [Arrow and pointing]: solid line with solid diamond, diamond points to the whole 6. dependency: A Dependency is used. Therefore, do not use two-way Dependency. [Code expression]: local variables, method parameters, or call static methods [Arrow and direction]: dotted line with arrows, pointing to the strong and weak order of various relationships of the User: generalization = implementation> combination> aggregation> association> dependency The following UML diagram shows the relationships of various types of diagrams in a visual manner:

Summary of several types of UML class diagrams

For example, a tiger is a type of animal, that is, the characteristics of a tiger and that of animals. Arrow pointing: solid line with a triangular arrow. arrow pointing to parent class 2. implementation (Realization) [Implementation relationship]: The relationship between a class and an interface, indicating that a class is the implementation of all features and behaviors of an interface. [arrow pointing]: a dotted line with a triangular arrow. the arrow points to interface 3. association: an Association that allows a class to know the attributes and methods of another class, the relationship between husband and wife can be bidirectional or unidirectional. Two-way association can have two arrows or no arrows, and one-way Association has one arrow. [Code embodiment]: member variable [Arrow and direction]: solid line with normal arrows, pointing to the owner C # code: one-way Association of Public class Order {Public List order; public void AddOrder (Product product) {order. in Add (product) ;}} Public Class Product {}, there is a two-way association between the teacher and the student. The teacher has multiple students, and the student may also have multiple teachers. However, the relationship between a student and a course is one-way association. A student may have to take multiple courses. The course is an abstract thing and he does not have any students. Join for itself: 4. Aggregate [Aggregation relationship]: The relationship between the whole and the part, and the part can exist independently from the whole. If a car and a tire are in the overall and partial relationship, the tire can still exist when it leaves the car. An aggregation relationship is a strong association relationship. The association and aggregation cannot be distinguished in syntax, and the specific logical relationship must be investigated. [Code embodiment]: member variable [Arrow and direction]: solid line with hollow diamond, the diamond points to the whole 5. composition: The relationship between the whole and the part, but the part cannot exist independently from the whole. If the relationship between a company and a department is a whole and a part, no department exists without the company. A composite relationship is a type of association relationship, which is stronger than an aggregation relationship. It requires that the object representing the whole in a general aggregation relationship represents the lifecycle of some objects. [Code embodiment]: member variable [Arrow and direction]: solid line with solid diamond, the diamond points to the whole 6. dependency: A Dependency is a type of use relationship, that is, the implementation of a class requires the assistance of another class. Therefore, do not use two-way Dependency whenever possible. [Code expression]: local variables, method parameters, or call static methods [Arrow and direction]: dotted line with arrows, pointing to the strong and weak order of various relationships of the User: generalization = implementation> combination> aggregation> association> dependency The following UML diagram shows the relationships of various types of diagrams in a visual manner: