Table of contents
Every programmer should master these 7 UML diagram drawing methods ~
8. Build a design document using an appropriate UML model
Every programmer should master these 7 UML diagram drawing methods ~
As we all know, software development is a staged process. Different development stages require different model diagrams to describe business scenarios and design ideas. It is also essential to output different design documents at different stages. For example, the domain model and business model need to be output in the requirements analysis stage, the physical architecture design needs to be output in the architecture stage, and the database design needs to be output in the detailed design stage. Doing so can better practice software development and improve the practicality of software development.
The software modeling and design process can be divided into three stages: requirements analysis, architecture design and detailed design. In these three stages, a large number of model diagrams that comply with UML specifications are used, of which 7 are commonly used, including class diagrams, sequence diagrams, component diagrams, deployment diagrams, use case diagrams, state diagrams and activity diagrams.
In the requirements analysis phase, use case diagrams and domain model diagrams are used to describe user requirements and business scenarios. During the architecture design phase, component diagrams and deployment diagrams are used to describe the components and deployment of the software system. During the detailed design phase, class diagrams, sequence diagrams, and state diagrams are used to describe the implementation details of the software system.
Below we will explore how to draw these 7 model diagrams and how to use these models at different stages to generate corresponding design documents.
1. 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 relationships between classes. In a class diagram, each class consists of three parts: class name, attribute list, and method list.
In addition to describing the basic characteristics of classes, class diagrams are also used to represent the relationships between classes, including six static relationships:
- Association: Represents the relationship between one class object and another class object, such as the relationship between an order and a customer.
- Dependency: Indicates the use or call of one class to another class. For example, a customer needs to use the order class when placing an order.
- Composition: Represents an inclusion relationship, indicating that one class object contains another class object. For example, an order contains multiple products.
- Aggregation: It also represents an inclusion relationship, but the class objects included 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 inheritance relationships, but generalization relationships can be used to represent more abstract relationships, such as multiple classes implementing an interface.
By drawing class diagrams, we can clearly describe the classes in a software system and the relationships between them, helping developers better understand the structure and functions of the software system.
In UML tools, a group of related classes and their relationships are drawn in a picture, which is a class diagram.
As shown in the figure above, it describes the implementation class diagram of a typical chain of responsibility model.
Class diagrams are mainly drawn in the Detailed design stage. Once the class diagram design is completed, the development engineer can implement the code based on the class diagram. As long as the logic of the class method is not too complex, the code implemented by different engineers will be almost the same, which helps ensure the standardization and uniformity of the software. In practical applications, it is usually not necessary to draw class diagrams for all classes. Only core, representative, and technically difficult class diagrams need to be drawn.
In addition to drawing class diagrams during the detailed design phase, class diagrams can also be used to represent key domain model objects duringthe requirements analysis phase. In this stage, instead of focusing on attributes or behaviors, we should focus on identifying domain objects and the relationships between them. Therefore, it can be described using a simplified class diagram, where only the names of the classes and the relationships between them need to be drawn.
As shown above, the relationship between model objects such as SIM cards, operators, mobile phones, and mobile phone manufacturers is mined during the demand analysis stage.
2. Sequence diagram
In addition to class diagrams, another commonly used diagram is sequence diagrams.
Class diagram describes the static relationship between classes, whileSequence diagram is used to describe the dynamic calling relationship between participants. Each participant has a vertical downward lifeline, represented by a dotted line. Messages between participants represent their call sequence relationships in top-to-bottom order, which is where the term sequence diagram comes from. Each lifeline has an activation bar, which is the elongated rectangular bar in the diagram that is active only when the participant is active.
Sequence diagrams are often used to represent interactions between objects, which can be class objects or larger actors such as components, servers, subsystems, etc. In short, sequence diagrams can be used as long as it involves interactions between different participants. For example, the picture below shows the business process after the business analysis stage and the system construction.
Remember thatsequence diagrams can be used at different stages of software design.
3. Component diagram
A component is a design element with a larger granularity than a class. Usually a component contains multiple classes. Component diagrams are sometimes used similarly 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 diagram describes the static relationships between components, mainly dependencies. If you want to describe the dynamic calling relationship between components, you can use a component sequence diagram, using components as participants to describe the message calling relationship between components.
Due to the larger granularity of components, it is usually used to describe and design the modules of software and the relationships between them. Therefore, component diagrams need to be drawn in the early stages of design, generally used in the architectural design stage.
4. Deployment diagram
The deployment diagram describes the final physical deployment of the software system, including the number of servers that need to be deployed, the deployment locations of key components, etc. It is the final physical blueprint of the software system, which allows customers, bosses and engineers to clearly understand the final operating status of the system and its relationship with existing systems and third-party servers. Deployment diagrams allow you to estimate the purchase costs of servers and third-party software.
Therefore, the deployment diagram is a very macro diagram in the entire software design model and needs to be drawn early in the design. All parties can discuss whether to approve the plan based on the deployment diagram. Only when a consensus is reached on the deployment diagram can the subsequent detailed design be continued. Deployment diagrams are mainly used in the architecture design phase, and should echo each other with component diagrams.
5. 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. describe an organization that builds the system to the outside world. The capabilities provided, system use cases are reflected in the requirements analysis phase describing the capabilities provided by the system to the outside world.
In this picture, the left side is the business use case diagram, and the right side is the system use case diagram. Although their drawing methods are similar, they are essentially very different. For details, you can check out this article I wrote before.
The humanoid elements in the diagram are called characters, and the characters can be people or other systems. Because the functions of the system may be complex, the use case diagram may only contain a small part of the functions. These functions are drawn within a rectangular box, which is the use case boundary. Ellipses inside rectangular boxes represent individual functions, which may depend on each other or require expansion. Because the function description in the use case diagram is relatively simple, it usually needs to be accompanied by text description to form a requirements document.
6. State diagram
State diagrams are used to show the state transitions in the life cycle of a single object.
In business systems, many important domain objects have quite complex status changes, such as orders, which can have various statuses such as pending payment, pending review, pending shipment, pending receipt, transaction closure, 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 describing state using this method, the state is scattered to different places, which can lead to development errors and confusion for product managers during design.
Using UML state diagrams can effectively solve these problems because it can show the entire life cycle of the object and the relationship between each state and transition in one diagram. For example, the chart below shows the status changes of an order from creation to transaction completion.
7. 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 the system or business process, and allow developers to better understand how the entire system operates.
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 diamond represents the branch judgment. The use of these symbols can make the activity diagram more standardized and readable, helping 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 based on domain, system, role, etc. based on the scope of the activity, making the process boundaries clearer.
Flowcharts are also relatively universal and can be used to describe business processes inthe requirements analysis phase, or inArchitectural design phaseDescribe the interaction of subsystems and components, and you can also describe a class inDetailed design phase Calculation process inside the method.
8. Build a design document using an appropriate UML model
The UML model diagram itself is not difficult to master, but how to use appropriate UML models to express design intentions on the right occasions, form a set of clear and detailed software models, and reach consensus on design documents within and outside the team requires attention.
According to the needs of different stages of software design, we can use different model diagrams for modeling.
Inthe requirements analysis phase, we can use use case diagrams, activity diagrams, sequence diagrams and simplified class diagrams for domain model abstraction and relationships describe.
In thearchitecture design phase, the system physical blueprint and module relationships are described through component diagrams, component sequence diagrams and deployment diagrams.
In thedetailed design stage, the main focus is on the class diagram and the sequence diagram of the class. For complex method logic, you can use the method Activity diagram is described.
9. Summary
Master the seven types of UML model diagrams, including class diagrams, sequence diagrams, component diagrams, deployment diagrams, use case diagrams, state diagrams, and activity diagrams. Based on actual scenarios, select and skillfully apply the corresponding model diagrams in the requirements analysis, architecture design, and detailed design phases. , helps to effectively carry out software modeling and system design, and becomes an excellent architect who controls the overall situation and guides the technical team.
Pay attention to the specifications and annotations of the model diagram, follow the naming conventions, name the model elements, annotate the relationships and attributes of the model elements, etc., in a concise and clear manner. In addition, the UML model diagram is only a part of the design document and needs to be combined with other documents, such as requirements documents, design documents, test documents, etc., to form a complete design document to guide software development.
For tools for drawing UML, there are paid professional software design tools such as EA (Enterprise Architect), Astah and Edraw, as well as free online tools such ashttp://draw .io, processon, etc. It is recommended to choose the appropriate tool according to your own needs. It is also recommended to start with simple and easy-to-use tools.