Table of contents
Class Diagram
Class diagram is one of the most widely used UML graphics in software design, used to describe the characteristics of classes and the static relationship between classes . In a class diagram, each class consists of three parts: class name , attribute list , and method list .
- Association: Indicates the relationship between a class object and another class object, such as the relationship between an order and a customer.
- Dependency (Dependency): Indicates the use or call of one class to another class, such as the need to use the order class when a customer places an order.
- Composition: Indicates a containment relationship, indicating that one class object contains another class object, such as an order containing multiple commodities.
- Aggregation: It also represents an inclusion relationship, but the class objects contained in the aggregation relationship can be shared by multiple classes, for example, a school contains multiple classes.
- Inheritance: Indicates that a class inherits from another class, can inherit properties and methods from the parent class, and can add new properties and methods.
- Generalization: Similar to the inheritance relationship, but the generalization relationship can be used to represent a more abstract relationship, such as multiple classes implementing an interface.
Sequence Diagram
Sequence diagrams are used to describe the dynamic calling relationship between participants . Each participant has a vertically downward lifeline, which is indicated by a dotted line. Messages between participants represent their invocation sequence relationship from top to bottom, which is where the word sequence diagram comes from. Each lifeline has an activation bar, which is a thin rectangular bar in the diagram that is only active when the participant is active.
Component Diagram
A component is a design element with a larger granularity than a class , and usually a component contains multiple classes. Component diagrams sometimes serve a similar purpose to package diagrams and are often used to describe physical components such as JARs, DLLs, etc. In practice, we use component diagrams more for module design.
Component diagrams describe static relationships between components, mainly dependencies . If you want to describe the dynamic call relationship between components, you can use the component sequence diagram to describe the message call relationship between components with components as participants.
Due to the large granularity of components, it is usually used to describe and design software modules and the relationship between them. Therefore, component diagrams need to be drawn in the early stages of design, generally used in the architectural design stage.
deployment diagram
The deployment diagram describes the final physical deployment of the software system , including the number of servers to be deployed, the deployment locations of key components, and so on. It is the final physical blueprint of the software system, allowing customers, bosses and engineers to clearly understand the final operating state of the system and its relationship with existing systems and third-party servers. Through the deployment diagram, you can estimate the procurement cost of servers and third-party software.
Therefore, the deployment diagram is a fairly macroscopic diagram in the entire software design model, which needs to be drawn in the early stage of design. All parties can discuss whether to approve the scheme based on the deployment diagram. Only when a consensus is reached on the deployment diagram can the subsequent detailed design proceed. Deployment diagrams are mainly used in the architecture design phase and should echo each other with component diagrams.
use case diagram
Use case diagrams are divided into business use cases and system use cases . Business use case diagrams are mainly reflected in the business analysis stage, describing the capabilities provided by an organization that undertakes the system. System use cases are reflected in the requirements analysis stage to describe the capabilities provided by the system .
In this figure, the business use case diagram is on the left and the system use case diagram is on the right . Although their drawing methods are similar, they are very different in essence. For details, please check this article I wrote before.
The human-shaped elements in the diagram are called characters , which can be people or other systems. Because the functions of the system may be very complex, the use case diagram may only contain a small part of the functions, and these functions are drawn in a rectangular box, which is the use case boundary. Ellipses inside rectangular boxes represent individual functions, which may depend on each other or require extensions. Because the functional description in the use case diagram is relatively simple, it usually needs to be accompanied by a text description to form a requirements document.
State diagram
A state diagram is used to show the state transitions in the life cycle of a single object .
In the business system, many important domain objects have fairly complex state changes, such as orders, which can have various states such as pending payment, pending approval, pending shipment, pending receipt, transaction closing, and transaction completion.
These state changes can be described in text form in the use case diagram, and change with different operations of each user. However, when using this method to describe the state, the state will be scattered in different places, which may lead to development errors and confusion for product managers at design time.
Using UML state diagram can effectively solve these problems, because it can show the entire life cycle of an object and the relationship between each state and transition in one diagram. For example, the chart below shows the status change of an order from creation to transaction completion.
The state diagram should be drawn in the requirements analysis stage to describe the logical relationship of state transitions, and it should also be drawn in the detailed design stage . At this time, the state should be represented by enumerated values to guide specific development.
activity diagram
Activity diagrams are often used to describe dynamic behavior in a system or business process. It can clearly show the control flow from one activity to another, depict the logic and flow of a system or business process, and allow developers to better understand how the entire system works.
In the activity diagram, the solid circle represents the beginning of the process, the hollow circle represents the end of the process, the rounded rectangle represents the activity, and the rhombus represents the branch judgment. The use of these symbols can make the activity diagram more standardized and readable, and help to improve the efficiency and quality of system development.
In addition, activity diagrams introduce an important concept - swim lanes. Activity diagrams can divide activities into different swim lanes according to the scope of activities, such as domains, systems, and roles, so as to make the process boundaries clearer.
The flow chart is also more universal. It can describe the business process in the requirements analysis phase , describe the interaction of subsystems and components in the architecture design phase , and describe the calculation process inside a class method in the detailed design phase .