Details about the diagram of the Unified Modeling Language (UML) Version 2.0

Yin and yang in UML 2

Refer to other articles and tutorials in the basic UML series. Unified Modeling Language (UML) 2.0 UML basics: Introduction to Unified Modeling Language UML basics: sequence diagram UML basics: component Diagram Draw a clean UML diagram Case modeling skills Introduction to UML sequence diagram Good Habit of drawing UML Sequence Diagrams Use UML for entity-link Modeling Subscribe to the RSS feeds of UML-related articles and tutorials

In UML 2, there are two basic graph categories: structure diagram and behavior diagram. Each UML diagram belongs to the two diagrams. The purpose of the structure diagram is to display the static structure of the modeling system. They include classes, components, and (or) object graphs. On the other hand, the behavior chart shows the dynamic behavior of objects in the system, including object methods, collaboration, and activities. An instance of a behavior diagram is an activity diagram, with an example diagram and a sequence diagram.

General Structure Diagram

As I said, the structure chart shows the static structure of the modeling system. Focus on the system components without considering the time. In the system, the static structure is propagated by the display type and Their instances. In addition to displaying the system type and Their instances, the structure chart also displays at least some relationships between these elements. If possible, it even displays their internal structures.

Throughout the entire software lifecycle, structural charts are useful to various team members. In general, these graphs support design verification and communication between individuals and teams. For example, business analysts can use class or object graphs to model current assets and resources, such as ledger, product, or geographic layers. Architects can use components and deployment diagrams to test/confirm whether their designs are adequate. Developers can use class diagrams to design and write documents for the system code (or code to be written) class.

Special Class Diagram

UML 2 regards the structure diagram as a classification; there is no "structure diagram" here. However, a class chart provides a primary instance of the structure chart type and an initial set of a set of Mark elements for all other structural charts. Because class diagrams are so basic, the rest of this article will focus on the class graph mark set. At the end of this article, you will have an understanding of how to draw a UML 2 class diagram, and have a solid foundation for understanding the other structure diagrams that will be involved in the subsequent article.

Basic

As mentioned earlier, a class chart aims to display the type of a modeling system. In most UML models, these types include:

• Class

• Interface
• Data Type
• Components

UML has a special name for these types: "Classifier ". Generally, you can regard classifier as a class, but technically, classifier is a more common term. It is better to reference the other three types above.

Class Name

Class UML represents a rectangle, vertically divided into three areas, 1 shows. The class name is displayed in the top area. The middle area lists the attributes of the class. The bottom area lists the operations of the class. When you draw a class Element on a class chart, you must have a top area, the following two regions are optional (when the figure description is only used to show the high-level details of the relationship between classifiers, the following two regions are unnecessary ). Figure 1 shows how a flight is modeled as a UML class. As we can see, the name isFlightIn the middle area, we can see three attributes of the Flight class: flightNumber, departureTime, and flightDuration. In the bottom area, we can see that the Flight class has two operations: delayFlight and getArrivalTime.

Figure 1: Flight class diagram

Class Attribute list

The attribute section of the class (Central Region) lists the attributes of each class on the separator line. The attribute section is optional. When you use it, it contains each attribute displayed in the list of classes. The line is in the following format:

name : attribute type

flightNumber : Integer

To continue with the Flight class example, we can use the property type information to describe the class attributes, as shown in table 1.

Table 1: attribute names of the Flight class with association types

Attribute name Attribute type FlightNumber Integer DepartureTime Date FlightDuration Minutes

In the business class diagram, the attribute type is usually consistent with the Unit, which may be meaningful to the readers of the diagram (for example, minute, dollar, and so on ). However, the class diagram used to generate Code requires that the class attribute types must be limited to the types provided by the program language, or included in the types of models implemented in the system.

Display specific properties with default values in the class diagram, which is sometimes useful (for example, in a bank account application, a new bank account is initially zero ). The UML specification allows the following marks to be used as the default values in the attribute list section:

name : attribute type = default value

For example:

balance : Dollars = 0

The default value of the display attribute is optional. Figure 2 shows that a bank account class hasBalanceThe default value is 0.

Figure 2: shows a bank account chart with a default balance attribute value of $0.

Class operation list

The class operation is recorded in the third (lowest) area of the class image rectangle. It is also optional. Similar to attributes, class operations are displayed in the List format, and each operation is on its own line. The operation uses the following marks:

name(parameter list) : type of value returned

The ing of Flight operations in table 2 below.

Table 2: Flight class operations mapped from Figure 2

Operation name Response parameters Value Type DelayFlight Name Type NumberOfMinutes Minutes N/ GetArrivalTime N/ Date

Figure 3 shows that the delayFlight operation has a Minutes input parameter-numberOfMinutes. However, the delayFlight operation does not return values. 1. When an operation has parameters, the parameters are placed in the brackets of the operation. Each parameter uses the format "parameter name: parameter type ".

Figure 3: Flight operation parameters, including the "in" identifier that can be selected.

When operating parameters are documented, you may use an optional indicator to display the input or output parameters of parameters to operations. This selectable indicator appears in "in" or "out", as shown in the "Action" Area in "3. In general, these indicators may be helpful unless an early programming language, such as Fortran, is used. However, in C ++ and Java, all parameters are "in" parameters, and according to UML specifications, since "in" is the default type of parameters, most people will miss the input/output indicators.

Inheritance

An important concept in object-oriented design,InheritanceIndicates a class (subclass)InheritanceAnother class (superclass) has the same function, and adds its own new features (a non-technical analogy, imagining that I have inherited my mother's general music capabilities, but in my house, I am the only one playing an electric guitar. In order to model and inherit on a class chart, a closed, single-key (or triangular) solid line is pulled from the subclass (class to inherit behavior) and directed to the superclass. Consider the Bank Account type: Figure 4 shows how the CheckingAccount and SavingsAccount classes inherit from the BankAccount class.

Figure 4: inheritance is represented by a closed, single-arrow solid line pointing to the superclass.

In Figure 4, the inheritance relationship is drawn by a separate line of each super class, which is used in IBM Rational Rose and IBM Rational XDE. However, there isTree tagThe alternative method can draw an inheritance relationship. When there are two or more sub-classes, as shown in 4, you can use a tree mark in addition to the inheritance line mixed together like a branch. Figure 5 re-draws the same inheritance as Figure 4, but this time it uses a tree mark.

Figure 5: an inherited instance using a tree sign

Abstract classes and operations
Careful readers will notice that the class name BankAccount and withdrawal operations in figures 4 and 5 use italics. This indicates that the BankAccount class is an abstract class, And the withdrawal method is an abstract operation. In other words, the BankAccount class uses withdrawal to specify abstract operations, and both the CheckingAccount and SavingsAccount sub-classes perform operations of their respective versions.

However, superclasses (parent classes) are not necessarily abstract classes. It is normal to use standard classes as superclasses.

Association
When you model a system, specific objects are associated with each other, and these associations must be clearly modeled. There are five associations. In this section, I will discuss two of them-bidirectional Association and unidirectional Association, and I willBeyond the basicsThis section discusses the three associated types. Please note that the detailed discussion on when to use each type of association does not fall within the scope of this article. On the contrary, I will focus on the purpose of each association and explain how to draw an association on the class diagram.

Bidirectional (standard) Association
An association is a join between two classes. Associations are always assumed to be two-way; this means that the two classes know the relationship between them unless you limit some other types of associations. Looking back at the Flight example, Figure 6 shows a standard type association between the Flight class and the Plane class.

Figure 6: two-way association between a Flight class and a Plane class

A bidirectional Association is represented by a solid line between two classes. At any end of the line, you place a role name and multiple values. Figure 6 shows that Flight is associated with a specific Plane, and the Flight class knows this association. Because the role name is represented by the Plane class, Plane assumes the "assignedPlane" role in the association. The multi-value description 0 following the Plane class... 1 indicates that when a Flight object exists, there can be one or no Plane associated with it (that is, Plane may not be allocated ). Figure 6 also shows that Plane knows its association with the Flight class. In this association, Flight assumes the "assignedFlights" role. The figure in Figure 6 shows that Plane entities can not be associated with flight (for example, it is a brand new aircraft) or associated with an unlimited flight (for example, an airplane that has been in service for 5 years.

As you are confused about the descriptions of the values that may occur at the end of the association, table 3 below lists some examples of the values and their meanings.

Table 3: multi-value and their representation

Possible multi-value descriptions Indicates Description 0 .. 1 0 or 1 1 Only one 0 ..* 0 or more * 0 or more 1 ..* One or more 3 Only three 0 .. 5 0 to 5 5. 15 5 to 15

Unidirectional Association
In a one-way Association, two classes are related, but only one class knows the existence of this association. Figure 7 shows an instance of one-way associated overdraft financial report.

Figure 7: one-way association of an instance: OverdrawnAccountsReport BankAccount class, while BankAccount class does not know anything about Association.

A unidirectional Association is a solid line with an open arrow pointing to a known class (an unclosed arrow or triangle for flag inheritance. As with standard associations, one-way associations include a role name and a multi-value description. However, if they are different from standard bidirectional associations, one-way associations only contain the role names and multi-value descriptions of known classes. In the example in figure 7, OverdrawnAccountsReport knows the BankAccount class, And the BankAccount class assumes the "overdrawnAccounts" role. However, unlike the Standard Association, The BankAccount class does not know that it is associated with OverdrawnAccountsReport. 2

Software Package
Inevitably, if you are modeling a large system or a large business domain, there will be many different classifiers in your model. Managing all classes is a daunting task; therefore, UML providesSoftware Package. The software package enables the modeler to organize the model classifier into the namespace, which is like folders in the file system. Dividing a system into multiple software packages makes it easy to understand, especially when each software package represents a specific part of the system. 3

There are two methods in the figure to indicate the software package. There are no rules for which tag to use, except for your personal judgment: which is easier to read the class chart you have drawn. Both methods start with a smaller rectangle (for positioning) nested in a large rectangle, as shown in 8. However, the modeler must determine how the package members are represented, as follows:

• If the modeler decides to display the software package members in the large rectangle, all the Members 4 need to be placed in the rectangle. In addition, the names of all packages must be placed within the small rectangle of the software package (8 is displayed ).

• If the modeler decides to display the package members outside the large rectangle, all the members displayed on the graph will be placed outside the rectangle. To display the classifier that belongs to the software package, draw a line from each classifier to the circumference with the plus sign inside. These circles stick to the software package (Fig. 9 ).

Figure 8: Example of a software package element showing a software package member in the rectangle of the software package

Figure 9: A Software Package example that represents a software package member through a connection line

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, 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.

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 displayeddelayFlight(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.

 

Information Source: http://www.ibm.com/developerworks/cn/rational/321_uml/