UML class diagram (4)

Document directory

•  

• Abstract: this is an article about the unified modeling language, that is, the basic diagram used in UML. In this article, I will discuss the structure diagram, which is a new graph type that has been proposed in UML 2. Since the purpose of this series of articles is to help people understand the mark elements and their meanings, this article mainly involves class diagrams. You will soon know the reason for doing so. Subsequent articles will cover other diagrams contained in the structure category.

Understand basic importance

In UML 2, it is more important to understand the basics of class diagrams. This is because class diagrams provide basic building blocks for all other structural charts. For example, a component or an object graph (just for some examples ).

Exceeds basic
So far, I have introduced the basics of class diagrams, but please continue reading! In the following sections, I will guide you to the more important aspects of the class graph you will use. These include interfaces in the UML 2 specification, three other association types, visibility, and other supplements.

Interface
Before this article, we recommend that you consider classifier using classes. In fact, classifier is a more general concept, including data types and interfaces.

The complete discussion of when and how to efficiently use data types and interfaces in the system structure diagram is not covered in this article. In this case, why should I mention data types and interfaces here? You may want to simulate these classifier types on the structure chart. At this time, it is important to use the correct mark or at least know the classifier types. If you do not properly draw these classifiers, it is very likely that your readers will be confused and the system will not be able to meet your needs in the future.

A class is different from an interface: A class can have real instances of its form. However, an interface must have at least one class to implement it. In UML 2, an interface is considered as a special element of class modeling. Therefore, the interface is drawn like a class, but the top area of the rectangle also has the text "interface", as shown in 5

Figure 10: class graph instance for implementing the person interface in the worker sor class and Student Class

In the figure shown in figure 10, both the aggregsor and student classes implement the person interface, but do not inherit from it. We know that this is because of the following two reasons: 1) the person object is defined as an interface-it contains the "interface" text in the object name area, in addition, we can see that because the optical sor and student objects are marked according to the rules of class objects (no additional classifier text exists in their names), they are class objects. 2) We know that inheritance is not displayed here, because the line with the arrow is a dot line rather than a solid line. As shown in 10, a dot line with a closed unidirectional arrow represents implementation (or implementation); as we see in figure 4, a solid line with a closed unidirectional arrow represents inheritance.

More associations
As mentioned above, I have discussed two-way Association and one-way Association. Now, I will introduce the three types of associations.

Association class
In associated modeling, You need to include other classes in some cases because they contain valuable information about associations. In this case, you will use the association class to bind your basic association. The associated class is the same as the general class. The difference is that the main class and the associated class are connected by an intersection of point lines. Figure 11 shows the associated classes of an Aviation Industry instance.

Figure 11: add the association class mileagecredit

In the class diagram shown in Figure 11, the association between the flight class and the frequentflyer class produces an association class called mileagecredit. This means that when an instance of the flight class is associated with an instance of the frequentflyer class, an instance of the mileagecredit class will be generated.

Aggregation
Aggregation is a special type of association used to describe the relationship between "population and local. In the basic aggregation relationship, the lifecycle of a partial classification is independent of that of the entire class.

For example, we can imagine that a car is a whole entity, and a wheel tire is a part of a whole car. Tires can be manufactured and placed in warehouses a few weeks before they are placed in the vehicle. In this instance, the wheel class instance clearly exists independently of the car class instance. However, in some cases, the life cycles of some classes are not independent of the life cycles of the entire class-this is called synthesis aggregation. For example, consider the relationship between the company and the Department. Both the company and department are modeled as classes. Before the company exists, the Department cannot exist. Here, the Department class instance depends on the company class instance.

Let's further explore basic aggregation and composite aggregation.

Basic Aggregation
An association with an aggregation relationship indicates that a class is part of another class. In an aggregation relationship, the subclass instance can be longer than the parent class. To express an aggregation relationship, you draw a solid line from the parent class to the partial classification, and draw an unfilled prism at the end of the parent class association. Figure 12 shows an example of the aggregation relationship between a vehicle and a tire.

Figure 12: An Example of aggregation Association

Combination Aggregation
A combination of aggregation relationships is another form of aggregation relationships, but the lifecycle of a subclass instance depends on the lifecycle of the parent instance. In Figure 13, the composite Relationship Between the company class and the Department class is displayed. Note that the composite relationship is drawn like an aggregation relationship, but this time the diamond is filled.

Figure 13: An example of a composite relationship

In link Modeling in Figure 13, a company class instance has at least one department class instance. Because the link is a combination, the Department instance is automatically removed/destroyed when the company instance is removed/destroyed. Another important feature of composite aggregation is that the partial classification can only be related to the instance of the parent class (for example, the company class in our example ).

Reflection Association
Now we have discussed all the join types. As you may have noticed, all our examples have shown the relationship between two different classes. However, classes can also be associated with reflection. At first, this may be meaningless, but remember that classes are abstract. Figure 14 shows how an employee class relates to itself through the manager/manages role. When a class is associated with itself, this does not mean that the instance of the class is related to itself, but an instance of the class is related to another instance of the class.

14: A Reflection Association instance

Figure 14: The Relationship depicted indicates that one employee instance may be the manager of another employee instance. However, because the "manages" relationship role has a multi-layered description of % 200 .. *, one employee may not be managed by any other employee.