This article summarizes UML class diagrams. I didn't intend to talk about UML class diagrams, because when I was learning design patterns, I would automatically ignore UML when I saw it. It felt very complicated at first glance. But with the deepening of learning, I found that I did not master UML class diagrams and did not have overall control over design patterns or a certain framework. So instead of avoiding it, it is better to dare to face it. Today, let us understand what UML class diagrams are.
Speaking of UML class diagrams, let's first look at what UML is. It is defined on Wikipedia as follows:
- UML is the Unified Modeling Language (Unified Modeling Language), it is an open method used to explain, visualize, build and write an open method for developing, object-oriented, software-intensive system products. UML exhibits a series of best engineering practices, which have been proven effective in modeling large-scale and complex systems, especially at the software architecture level.
It may be a bit abstract from the definition. To put it bluntly, it is a standardized modeling language composed of diagrams. Generally, the language we understand is composed of text, and this unified modeling language is composed of diagrams. We know that to develop a software system, not only programmers, but also analysts, designers, testers, etc., in order to allow different people to understand and communicate this software system, such a set of languages was born. We said that this language is composed of diagrams. There are several types of diagrams here. The most commonly used ones are: use case diagrams, class diagrams, sequence diagrams, state diagrams, activity diagrams, component diagrams, deployment diagrams, etc. Since this article mainly explains class diagrams, I won't understand the others in depth, and interested students can search for this content on the Internet.
Now let’s get back to the subject, let’s focus on the class diagram, which describes the relationship between classes in our software system. Since the description is the relationship between class and class, let's first look at how the next class is represented, and then look at the relationship between them. First we define a very simple Person class, the code is as follows:
public class Person {
private String name;
private int age =1;
public String getName() {
return name;
}
public int getAge() {
return age;
}
public void setName(String name) {
this.name=name;
}
public void setAge(int age) {
this.age=age;
}
}
This Person class is very simple. It defines two fields, name and age, in which age has an initial value of 1, and also defines the set and get methods of name and age. It’s very simple. Then let’s take a look at how this class is represented in the UML class diagram:
we can see that we drew a rectangle and then divided it into three grids from top to bottom. The first grid is the class name, and the second grid is Field attributes in the class, the expression of the attributes here also has a certain format, as follows:
权限 属性名：类型 [ = 默认值 ]
Since our name and age are private here, we add a-in front, and there are several other permissions: public, protected, default, which correspond to +, #, ~ respectively. Since our age here has a default value of 1, we add'=1' to the end of the type to indicate it. Next, let’s look at the third box. The third box is the method of the class. The format is as follows:
权限 方法名称(参数列表) [ : 返回类型]
It is also very simple, I believe you will see it at a glance, the return type is optional, so I won't do too much explanation here.
Relationship between classes
Well, above, we have briefly understood the way a class is represented in the class diagram, and then we will understand the relationship between the next class and the class. There are several relationships between the class and the class as follows: generalization (Generalization), implementation ( Realization, Dependence, Association, Aggregation, Composition.
I must have heard such a nursery rhyme: I found a penny on the side of the road and handed it to the police uncle. Next, I will explain the relationship between classes and classes one by one based on this story.
Generalization relationship
The generalization relationship is also called the inheritance relationship in Java. In UML, we use a line with a hollow triangle to represent it. We add two classes, a Studen class and a Policemen class. Both classes inherit from the Person class, then Their class diagram is shown as follows:
Realization relationship
The realization relationship here is the realization relationship between classes and interfaces in Java. In UML, we use a dotted line with a hollow triangle to indicate. Since both Student and Policeman are professions, the student's profession is learning, and the police's profession is to protect the people. So here we define an interface, which has a professional method:
public interface ICareer{
void career();
}
This interface is represented by UML class diagram as follows:
You can see that there is an extra <> character on the interface name to indicate that this is an interface. Next we let Student and Policeman implement this interface, the UML class diagram is as follows:
Dependency
Dependency is a very weak relationship. It generally refers to one class using another class. Here the student picks up the money and gives it to the police uncle. The student and the police uncle are a kind of dependency. Because it is an accident that students find money and give it to the police, there is no relationship between them after it is handed over to the police. We add a payment method to the student class and a method to collect money in the police class. When the student’s payment method is called, the police’s method of collecting money is called. Student's code is as follows:
public class Student{
....
....
public Policemen policemen;
.....
public void sendCoin(){
policemen.receiveCoin();
}
}
It can be seen that the Policemen class is referenced in the Student class, which means that the Student depends on the Policemen. This dependency is represented by a dotted line with an arrow, and the arrow points to the dependent object. Here is the Policemen. The UML class diagram is shown as follows:
connection relation
The association relationship is a relatively strong relationship, and their relationship is relatively lasting and stable. For example, when a student comes out of the home, the student and the home are a kind of relationship. This relationship is relatively stable. The association is divided into one-way association and two-way association. If one class knows or refers to another class, and the other class does not know or does not refer to this class, then the two classes are one-way related. For example, the relationship between students and home is one-way, because every student has a home (orphans are not considered), but it cannot be said that every home has students. One-way association is represented by a solid line with an arrow, and the arrow points to the referenced or contained class, which is the home class here. Examples are as follows:
Two-way association means that two classes know each other's existence. For example, the relationship between teacher and student is two-way. Xiao Ming’s Chinese teacher is Teacher Zhang, and Teacher Zhang’s students have Xiao Ming. A two-way association uses a solid line without arrows to connect two classes. Examples are as follows:
Aggregation relationship
The aggregation relationship is a special kind of association relationship. The aggregation relationship emphasizes the relationship between the whole and the part, and the part can exist without the whole. For example, the relationship between a flock of geese and a big geese is an aggregation relationship, and the big geese can exist independently without the flock. Another example is the relationship between police and uniforms. Uniforms are also part of the police, and uniforms can exist without the police. In the UML class diagram, the aggregation is represented by a straight line with a hollow diamond, where the diamond points to the whole:
Combination relationship
The combination relationship is also a special kind of association relationship. It is very similar to the aggregation relationship. It also emphasizes the relationship between the whole and the part. The difference is that the part cannot exist without the whole. For example, when a student picks up money by hand, the hand is part of the student, but the hand cannot exist independently of the student. It would be terrible to think about it if the hand could exist independently. . . Here we call the student and the hand a combination relationship, represented by a solid rhombus line, where the rhombus points to the whole:
Well, these relationships are almost the same here. In fact, you will find that the strengths of dependencies, associations, aggregations, and combinations are getting stronger and stronger: Combination>Aggregation>Relation>Dependency.
Finally, you will find that you have unknowingly used UML class diagrams to complete the above story of pupils picking up money:
