Diagrams in UML ~

UML includes nine types of diagrams: use case diagram, class diagram, object diagram, component diagram, deployment diagram, activity diagram, collaboration diagram, state diagram, and sequence diagram. Using Case, class, and sequence diagrams in these diagrams is the most useful.
Based on the intention, you can divide it into two types: structure chart and behavior chart.
Structural Diagram: Describes the static structure of the system. It is most useful when displaying the relationships between classes in the system.
Behavior chart: Describes the dynamic nature of the system. It is most useful in displaying how elements in the system collaborate to produce system behavior that meets requirements.

Structural Diagram

Obviously, to describe the static structure of a design pattern, it is appropriate to use class diagrams and object graphs.

Behavior chart

Obviously, to describe the behavior characteristics of a design pattern, it is appropriate to use the state chart and time sequence diagram.

It should be pointed out that a system design using UML often starts from the use case diagram and should be case-driven.

Relationships in UMLThere are four relationships in UML:

(1) Dependency

Dependency is the semantic relationship between two model elements. Changes in one element (independent element) affect the other element (dependency element) meaning (that is, "dependency element" is referenced in "independent element "). In the image, draw dependencies into a line that may have a direction, and occasionally carry a mark 2-14 on it.

(Independent element) (dependent element)

Figure 2-14 dependency

(2) Association

Association is the structural relationship between classes. It describes a group of chains that are links between objects (class instances. Aggregation is a special type of association that describes the structural relationship between the whole and the part. In Graphics, a solid line may be drawn through a check. It may have a direction and occasionally carries a mark on it. It also often contains modifications such as multiple features and end names, from 2 to 15. We will further detail the association below.

Figure 2-15 Association

(3) generalized relationship

Generalization is a special/general relationship in which special elements (child elements) are created based on general elements (parent elements. In this way, the child element shares the structure and behavior of the parent element (that is, the "Child element" inherits the "parent element "). On the graph, draw a generalized relationship into a solid line with a hollow arrow. The solid line points to the parent element, as shown in 2-16.

(Child element) (parent element)

Figure 2-16 generalized relationship

(4) Implementation relationship

Realization is the semantic relationship between categories. One Category specifies the contract that is executed by another category. There are implementation relationships in two ways: one is between interfaces and the classes or components that implement them, and the other is between usage and collaboration that implement them. On the graph, draw an implementation relationship into a dotted line with a hollow arrow. It is a combination of generalization and dependency, as shown in 2-17.

(Implementation) (Interface)

Figure 2-17 Implementation relationship

Association in a UML diagram Link:

General Relationship: indicates the inheritance relationship between classes, the inheritance relationship between interfaces, or the Implementation relationship between classes and interfaces. A general relationship refers to a subclass pointing to the parent class, or pointing from the class implementing the interface to the implemented interface, in the opposite direction of inheritance or implementation. As shown in:

Figure: general link

Association: A join between a class and a class. It allows a class to know the attributes and methods of another class. Associations include unidirectional associations, bidirectional associations, aggregation associations, merging associations, and reflection associations.

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 M.. n M to n

Table: multi-value and their representation

Unidirectional Association: In a unidirectional 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 associated overdraft financial report

Two-way Association: two classes know the relationship between them unless you limit some other types of association. Figure 6 shows the bidirectional association between the flight class and the plane class. Figure 6 bidirectional association between the flight class and the plane class
Aggregation Association: 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, 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 synthesis Association of the aggregation relationship between vehicles and tires (combination aggregation relationship): The combination aggregation relationship is another form of the aggregation relationship, however, 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: Reflection associations between the company class and department class: the class can also be associated with itself using reflection associations. 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: The employee class is related to it through the manager/manages role

Table 4: UML-supported visibility type labels

Flag	Visibility type
+	Public
#	Protected
-	Private
~	Package