UML class diagram (advanced)

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, I suggest you consider using classesClassifier. 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", 10. 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 areClassObject. 2) We know that inheritance is not displayed here, because the line with the arrow is a dot line rather than a solid line. 10, with a closed one-way arrowPointLine means implementation (or implementation); as we see in figure 4, a line with a closed unidirectional arrowRealLine indicates 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 useAssociation classTo 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,ClassificationIs independentOverall class.

For example, we can imagine that,VehicleIs a whole entity, andWheelTires are part of the entire 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,PartClass lifecycle andNoIndependent fromOverallClass lifecycle-this is called synthesis aggregation. For example, consider the relationship between the company and the Department.Companies and departmentsAll 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.

Figure 14: A Reflection join instance

 

The relationship depicted in Figure 14 indicates that one employee instance may be the manager of another employee instance. However, because the "manages" relationship role has a Multiple Description of 0 .. *, an employee may not be managed by any other employee.

Visibility
In the object-oriented design, there is a mark for attributes and operation visibility. UML recognizes four types of visibility: public, protected, private, and package.

The UML specification does not require that attributes and operation visibility be displayed on the class diagram, but it requires that visibility be defined for each attribute and operation. To display the visibility on a class chart, place the visibility mark before the name of an attribute or operation. Although UML specifies four visibility types, the actual programming language may increase additional visibility or do not support UML-defined visibility. Table 4 shows different visibility types supported by UML.

Table 4: UML-supported visibility type labels

Flag Visibility type + Public # Protected - Private ~ Package

Now let's look at a class to illustrate the visibility types of attributes and operations. In Figure 15, all attributes and operations are public, except the updatebalance operation. The updatebalance operation is protected.

Figure 15: A bankaccount class shows its attributes and operation visibility

UML 2 supplement

Now that we have covered both basic and advanced themes, we will cover some new marks for the class diagrams added by UML 1. X.

Instance
When modeling a system structure, it is sometimes useful to show example-class instances. For this Structural Modeling, UML 2 providesInstance SpecificationIt displays the noteworthy information about the use of examples (or real-world) instances in the system.

The instance mark is the same as the class, but it replaces the only class name in the top area. Its name is spliced:

Instance Name : Class Name

For example:

Donald : Person

Because the purpose of displaying instances is to display noteworthy or related information, it is not necessary to include the entire object attribute and operation in your model. On the contrary, it is entirely appropriate to only display the attributes of interest and their values. 16.

Figure 16: An example of a plane class (show only the attribute values of interest)

 

However, it is not practical to present only some instances without their relationships. Therefore, UML 2 allows link/association modeling at the Entity layer. The same rule is used to draw associations with general class relationships. In addition to modeling associations, there is an additional requirement. The additional restriction is that the association relationship must be consistent with the class diagram, and the associated role name must also be consistent with the class diagram. An example is shown in figure 17. In this example, the instance is an example of the class graph in figure 6.

Figure 17: Example of replacing classes with instances in Figure 6

 

Figure 17 shows two instances of the flight class because the class diagram shows the relationship between the plane class and the flight class.0 or more. Therefore, we provide two flight instances related to the nx0337 plane instance.

Role
The instance of the modeling class is sometimes more detailed than expected. Sometimes, you may just want to create a class relationship model at a higher level. In this case, you should useRoleMark. Role tags are similar to instance tags. To create a role model for a class, you can draw a square and place the role name and Class Name of the class inside as the entity mark, but in this case, you cannot underline it. Figure 18 shows a role instance played by the employee class described in Figure 14. In Figure 18, we can think that even if the employee class is related to itself, the relationship is indeed about the roles of managers and team members between employees.

Figure 18: A class diagram shows the classes that play different roles in Figure 14.

Note that you cannot create a class role in a pure class diagram, even if figure 18 shows you can. To use the role mark, you will need to use the internal structure mark discussed below.

Internal Structure
One of the more useful functions of the UML 2 structure diagram is the new internal structure mark. It allows you to show how a class or another classifier is made up internally. This is not possible in UML 1.x, because the mark limits you to display only the aggregation relationships of a class. Now, in UML 2, the internal structure Mark gives you a clearer picture of how each part of the class maintains its relationship.

Let's look at an instance. In Figure 18, we have a class diagram showing how a plane class consists of four engines and two control software objects. What is omitted from this figure is information about how aircraft components are assembled. From the figure 18, you cannot explain whether each control software object controls two engines, one controls three engines, and the other controls one engine.

Figure 19: only show the class diagram of the relationship between objects

 

Drawing the internal structure of the class will improve this state. At the beginning, you draw a square with two areas. The top area contains the class name, while the lower area contains the internal structure of the class, which is displayed as the category of the parent class that assumes different roles, each category in the role is also related to other classes. Figure 19 shows the internal structure of the plane class. Pay attention to the internal structure to clarify the confusion.

Figure 20: An Example of the internal structure of the plane class.

 

In Figure 20, plane has two controlsoftware objects and each controls two engines. The controlsoftware (control1) Control Engine 1 and 2 on the left side of the figure. The controlsoftware (control2) Control Engine 3 and 4 on the right of the figure.

Conclusion

There are at least two important reasons for understanding class diagrams. The first is that it displays the static structure of the system classifier. The second reason is that the diagram provides the basic mark for other structural diagrams described by UML. Developers will think that class diagrams are specially set up for them, but other team members will find that they are also useful. Business analysts can use class diagrams to model the business vision of the system. As we will see in this series of articles on the basics of UML, other diagrams-including activity diagrams, sequence diagrams, and state diagrams-reference class modeling and documentation in class diagrams.

Component diagrams following the "UML basics" series.