UML class diagram (5)

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.

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 does not support visibility defined by % 20uml % 20. 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 type of structural modeling, UML 2 provides instance specification elements that display the noteworthy information for using 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 that the relationship between the plane class and the flight class is zero 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 use the role mark. 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.

Footer

1 delayflight does not return values, because I have made a design decision and do not return values. It can be argued that the delayed operation should return a new arrival time. In this case, the Operation attribute will be displayed as delayflight (numberofminutes: minutes): Date.

2 It may seem strange that the bankaccount class does not know the overdrawnaccountsreport class. This modeling allows the report class to know the business class they report, but the business class does not know that they are being reported. This decouples the coupling of the two objects and thus makes the system more adaptable to changes.

3. The software package is huge for organizing your model classes, but remember that your class diagram should be easy to communicate with the modeling system. When your software package has many classes, it is best to use multiple topic class diagrams instead of just generating a large class diagram.

4. To understand the importance, when I say "all those Members", I only mean that the class in the current graph will be displayed. Shows a diagram of a software package with content. You do not need to display all its content. It can display the subset of included elements according to some criteria, which means that not all software package classifiers are required.

5 when drawing a class diagram, all you need to do in the UML specification is to put the class in the top area of the rectangle, and you process the interface in the same way. However, the UML specification considers that, it is optional to place the "class" text in this area. If the class is not displayed, it should be assumed.

For more information, see the original article on the developerworks global site.