I saw that there are many introductions to UML diagrams on the Internet, but they are incomplete, so I refer to some UML books, blogs, videos, official websites, and based on the latest UML 2.5 version (covering 14 types of UML diagrams), I summarized this article, hoping to give a little reference to students in system analysis and design.
In the first part, "Understanding the Design Methods of Business Modeling & System Analysis of 14 UML Diagrams in One Article (Part I)", the structure and design examples of the first 7 UML core diagrams were explained, which was biased towards the introduction of operations, and the next part will continue to explain the other 7 kinds of dynamic behavior diagrams and their cases.
Dynamic Behavior Diagram (7 types)
08
Use case diagram
8.1. Function
A Use Case Diagram is a diagram that consists of actors, use cases, boundaries, and the relationships between them to describe the functionality of a system.
A Use Case diagram is a model diagram of the functionality of a system that can be observed by external users, and is a blueprint of the system.
The main function of the use case diagram is to list the use cases and actors in the system, and show which participant is involved in the execution of which use case
Core Concepts:
- Use case: A functional unit in a system that can be described as an interaction between a participant and the system.
- Participant: An external entity that meaningfully interacts with a system through its boundaries.
- Generalization: The relationship between participants and participants.
- Relevance: The relationship between the use case and the actor.
- Extend, Contain, Generalize: Relationships between use cases.
Recommended for use
Business modeling, requirements elicitation and definition, etc.
8.2. Component elements
| Constituent elements | sign | function |
| participator |  | External entities that meaningfully interact with the system through its boundaries, Represented by a small person Note that the participant is located outside the system boundary, not part of the system |
| example | | A functional unit in a system that can be described as an interaction between a participant and the system. Represented by an ellipse A use case is a collection of activities in which a participant does something in a system from start to finish. It is an externally visible system function that describes the services provided by the system. |
| System boundaries | | Used to describe the system boundary, represented by a rectangular box |
| exegesis | | For annotations, connected by a dotted line |
| relationship | Contains relationships | Contains relationships. Represents the connections between participants and participants, between actors and use cases, and between use cases and use cases. Represented by a dashed line with an arrow (not a triangular arrow) with a < > in the middle<include>, pointing from the base use case (overall) to the included use case (partial) |
| Extend relationships | Extend relationships. Represented by a dashed line with an arrow (not a triangular arrow) with a < > in the middle<extend>, led by the extended use case to the base use case example | |
| Generalization relationships Example: Generalized relationships between participants | Generalization relationships. Represents a child-parent relationship, from a child object to a parent object, where the object can be a participant or a use case. Represented by a solid line with a "hollow triangle arrow", pointed by a child object (actor or use case) to a parent object (actor or use case) | |
| relevancy | It is generally used for associations between actors and use cases | |
| Annotate connections | Used to connect comment blocks |
Let's take a closer look at these elements:
(1) Participants
The most common participants are people and systems, and in addition to this, it can also be "time"
Identifying participants can be considered from the following perspectives:
1) The person or thing that provides input to the system
2) A person or thing that receives the output of the system
3) Third-party systems or devices that need to be accessed
4) Whether the time triggers certain events
5) The person responsible for supporting or maintaining the information in the system
Participants in the system can generally be divided into four categories:
Key business actors: Associated people who primarily benefit from the execution of the use case.
Primary System Participant: An associated person who interacts directly with the system to initiate or trigger a business or system event.
External service contributor: An associated person who responds to a request from a use case.
External receiving participant: A non-primary associated person who receives some value or output from the use case.
(2) Examples
The use case is the goal of the participants, and the characteristics of the use case ensure that the use case can correctly capture the functional requirements, and it is also the basis for judging whether the use case is accurate.
1) The use case is a verb-object phrase
2) Use cases are relatively independent
3) Use cases are initiated by participants
4) Use cases should have observable execution results
5) A use case is a unit
(3) Relationships
1) Inclusion relationships
Inclusion refers to the behavior that one use case (base use case) can contain that other use cases (including use cases) have, and the behavior defined in the containing use case will be inserted into the behavior defined by the base use case.
2) Expand relationships
Scaling refers to the enhancement of the behavior of one use case (extended use case) to another use case (base use case).
Extensions are represented by a dashed arrow with the Enxtend stereotype appended, pointing to the base use case.
Note: The extension is in the opposite direction to the included arrow, which indicates that the extension depends on the extension use case and not the base use case, which determines when the extension is executed, and the base use case knows nothing about it.
The use of extended use cases consists of four parts:
Base Use Case: The use case that needs to be extended, the "registered" use case.
Extended Use Case: Provide the use case of the added behavior sequence, as shown in the "Check Real-Name Information" use case.
Extended relationship: Indicated by a dashed arrow pointing to the base use case.
Extension point: One or more locations in the base use case, where a condition is used to decide whether or not to interrupt the execution of the base use case to execute a fragment in the extended use case.
8.3. Examples
(1) Library management system use case diagram
09
Activity diagram
9.1. Function
An activity diagram is an execution process (business process) that describes the actions (activities) of a use case from the beginning to the end, which is a supplementary introduction to the internal process of the use case, emphasizing the flow of actions within the use case, and is generally used in early business process modeling.
An Activity Diagram is a behavioral model that models the dynamic aspects of a system. It describes the flow between actions (activities) within a use case, emphasizes the sequence and conditions under which the behavior is executed, and is primarily used to describe the internal behavioral characteristics of a method, mechanism, or use case. An activity diagram is essentially a flowchart that shows the flow of control from activity to activity, and unlike traditional flowcharts, it can also demonstrate high-level concepts such as concurrency, object flow, partitioning, and more.
Each execution of an activity consists of the execution of a series of internal actions, in which each action may be executed 0 or more times and executed in a certain order, each action will result in a change in the state of the system or the transmission of messages, coordinating the internal behavior execution logic through the flow of control or object flow.
Activity diagrams are another common tool used by UML to model the dynamic behavior of a system, describing the sequence of activities and showing the flow of control from one activity to another.
Core Concepts:
- Activity, Composite Activity: Represents the control logic inside a use case.
- Object, Object Flow: A data object that is related to an activity.
- Transfer, Branch: Controls the order of activities.
- Concurrency and synchronization: Supports concurrency and synchronization between activities.
- Partitions: Describe the different participants of the event.
Recommended scenario
Business modeling, requirements, class design, etc
9.2. Component elements
| Constituent elements | sign | function |
| Activity/Action | | Indicates the action in the process, which is generally expressed by one verb phrase |
| object | | |
| Send events | | |
| Accept the event | | |
| Partitions (lanes) | | The active partition is used to identify a set of actions with the same characteristics that are placed in the same compartment There is no order between partitions, activities in different partitions can be done sequentially or concurrently, and action and object flows allow crossing the divider In a business model or requirement, organizations are often partitioned according to their unit or system role, and one unit or role is responsible for the behavior of all nodes in the partition. In a design model, you can partition by different classes (or components), with one class (or component) responsible for performing the behavior of all nodes in that partition. Partition bars can be placed horizontally or vertically, and each action can be placed in the corresponding partition according to its execution body, so that the execution body of the action can be clearly defined. |
| Decision points | In practical use, it consists of three elements, which are the diamond (decision point), the arrow, and the condition. There are two types of arrows: one is the entry arrow (pointing from the outside to the diamond), and the other is the leaving arrow (pointing out from the diamond), and there is a condition on the exit arrow to indicate when the conversion is met | In the activity diagram, for the same trigger time, different activities can be shifted according to different conditions, and each possible transition is a branch |
| Fork/Merge | element | Used to separate or converge control flows |
| origin | | Activity start node |
| 终点 | | Activity end node |
| The flow ends | | Active sub-process node |
| control flow | | The control flow is used to connect two actions or control nodes, and after the previous node action is executed, the next action is entered through the control flow. The control flow does not pass objects or data, only control tokens, and all tokens from the source node will be passed to the target node |
| Object streams | | An object stream connects an action node to an object node (or directly connects two object pins) and is used to pass an object or data that represents the "production" object of the source action, or the object that is "consumed" by the target action |
9.3. Examples
(1) Activity diagram of the restaurant diner eating use case
First of all, starting from the starting point, the first action is entered through the control flow, that is, the diner walks into the restaurant, and the restaurant usher helps to check if there are any vacant seats. After the action is executed, a branch with or without a vacancy will be generated, and the two branches will be placed on the output control flow of the decision node through the decision node description. If there is a vacancy, the diner will directly receive the seat and enter the follow-up action, otherwise, if there is no vacancy, the diner will register his name, and the receptionist will send a number to indicate the order of waiting, and the diner will wait.
During the waiting period, the usher will frequently check if there is an empty seat (this action is not modeled in the diagram), and if there is a vacant seat, a signal to find the vacant seat will be sent to the corresponding diner (this is an independent control flow performed by the leader), at this time, the two control flows converge and merge with the branch flow with the vacant seat to enter the leader action.
After the reception is completed, the usher arranges for the waiter to order, the waiter hands the menu, and the diner orders according to the recipe. After the order is completed, a menu object is formed through the object flow, and the waiter sends the hot dish from the menu to the chef (asynchronous sending event), thus notifying the chef to make the hot dish, and then arranging the cold dish with drinks. After the chef receives the hot dish menu (asynchronous reception event), he starts an independent process of making hot dishes, and sends a signal to notify the waiter to serve the hot dishes after the hot dishes are ready, and the control flow of the current chef ends. After receiving the signal that the hot dish is ready, the waiter serves the main course for the diners, which is a new process that is relatively independent of the control flow of the previous cold drink. After the cold drinks and main course are served, they converge to move on to the checkout (omitting the process of eating for diners in the middle).
(2) Activity diagram of the borrowing use case
(3) Shopping use case activity diagram
Swimlanes are divided into: member lanes and system lanes. The member selects the product and adds it to the shopping cart, and the system completes the order generation and payment.
Start node: Members add products to the shopping cart, click [Order Confirmation], and start the order process by the system
End node: The product is sent and the payment is successful, and the order processing process is completed
活动状态：产生订单、Check Credit Cart 核对信用卡、Check Stock 核对库存量、Deliver Goods 发送商品、Process Credit Cart 付款
Fork and confluence: [Generate Order] The fork is to check whether the inventory quantity and the amount paid by the member are sufficient, if it is insufficient, cancel the order, if the inventory and payment amount are sufficient, send the goods and payment, and finally merge for the order to be completed.
(4) Consult the use case activity diagram
10
State machine diagram
10.1. Function
A State Machine Diagram is a Statechart Diagram in UML 1.x that uses states and events to describe the behavior of an object itself. It is a very important behavior diagram that emphasizes the change in the state of an object caused by an event.
Sequence diagrams and communication diagrams are both types of interaction diagrams, and they focus on describing the process of interaction between objects. However, sometimes the object itself is also complex, and it may involve different states and behaviors, which need to be represented by a state machine diagram, focusing on the state and behavior interactions within the object.
Core Concepts:
- State, initial state, final state.
- Events, Transfers, Actions.
- Concurrent state machines.
Recommended use occasions: similar design occasions
10.2. Component elements
| Constituent elements | sign |
| Stage | |
| 浅度历史（Shallow History） | |
| 深度历史（Deep History） | |
| Choice | |
| 初态（Initial State） | |
| 终态（Final State） | |
| 转移（Transition） | |
| 分叉/合并(Fork/Join) | |
10.3. Examples
11
Interaction Diagram - Sequence Diagram (Timing Diagram)
11.1. Role
A Sequence Diagram is used to show the interaction between objects, and it focuses on the chronological order of messages between objects
Core Concepts:
- Objects, Lifelines, Execution Occurrences, Messages.
- Interaction Frame: A new concept in UML 2 that encapsulates fragments in an interaction graph and allows you to impose certain operations (e.g., selection, looping, parallelism, etc.) on the fragments, allowing UML to support complex interaction modeling.
11.2. Component elements
| Constituent elements | sign |
| Object/Lifeline （Object/lifeline） | |
| Interaction fragments （Interaction Frame） | New in UML 2 |
| Execution occurs （Execution Occurrence） | |
| State invariant （State Invariant） | |
| Synchronize messages （Synchronous Message） | |
| Asynchronous messages (Asynchronous Message) | |
| Return the message （Return Message） | |
| 创建消息（Create Message） | |
11.3. Examples
Diagram of the order of the borrowing process:
(1) UML 1.x version
(2) UML 2.x version
12
Interaction Diagram - Communication Diagram (Collaboration Diagram)
12.1. Function
A Communication Diagram, known as a Collaboration Diagram in UML 1.x, represents the relationships and interactions between a group of objects. Communication diagrams and sequence diagrams are isomorphic (the ability to describe is the same, and many tools provide automatic conversion to and from each other), but with different emphasis. The core concepts in the communication diagram include the following:
When displaying the object interaction diagram, the sequence diagram focuses on describing the sequence of interactions, while the relationship between the interactive objects cannot be reflected, and the communication diagram describes the interaction diagram of the object interaction from another perspective.
Core Concepts:
- Objects, collaboration roles
- Collaboration, interaction, messaging.
Recommended use occasions: including use case analysis, use case design, etc.
12.2. Component elements
| Constituent elements | sign |
| Object/Lifeline （Object/Lifeline） | |
| link （Link） | |
| Synchronize messages （Synchronous Message） | |
| Asynchronous messages (Asynchronous Message) | |
| Return the message （Return Message） | |
12.3. Examples
(1) A communication diagram of the completion of the borrowing process
13
Interaction Diagram - Time Diagram
13.1. Function
A Timing Diagram is an interactive graph that shows the real time information when a message crosses different objects or roles, and can describe the time point when the state of a single or multiple objects changes and the time period during which a specific state is maintained. In addition, sequence diagrams, as the main means of representing interactions, can also add time constraints to indicate the time point when the state of an object changes and the time period during which a particular state is maintained.
For certain systems (e.g. real-time systems) where real time information is important (e.g. a message must be returned within 1 second after it is sent), UML 2 introduces a new time graph to describe time information.
As a new UML model, time graphs have not been widely popularized at present
Core Concepts:
- Time constraints, duration constraints, lifelines
- Statuses, conditions, events
13.2. Component elements
| Constituent elements | sign |
| State/Condition Practice Line （State/Condition Timeline） | |
| Take the value of the lifeline （General Value Lifeline） | |
| lifeline （Lifeline） | |
| message （Message） | |
13.3. Examples
The phone call scenario is used as an example to illustrate how to use a time graph
A sequence diagram (timing diagram) of the telephone call process with time constraints
Time graph of the phone call process (in a straight line)
Time graph of the call process (in a regional way)
14
Interaction Diagram - Interaction overview diagram
14.1. Function
An Interaction Overview Diagram is a hybrid of an activity diagram and a sequence diagram, which visually represents the flow logic between a set of related sequence diagrams. is a new type of diagram in UML 2.
When the interaction behavior inside a use case is very complex, it may not be well represented by a sequence diagram, and the behavior of the use case may be split into several sequence diagrams. At this point, the relationship between these sequence diagrams can be described by the interactive overview diagram.
Core Concepts:
- Interaction fragments.
- Beginning, destination, decision, transfer.
Recommended use occasions: including use case analysis, use case design, etc.
14.2. Component elements
| Constituent elements | sign |
| 片段（Frame） | |
| 交互引用（Interaction Use） | |
| 决策点（Decision） | |
| 起点(InitialNode) | |
| 点(FinalNode) | |
| 控制流（ControlFlow） | |
14.3. Examples
A flowchart of a reader using the system
Author: Liu Renquan (Yi Ge)
Source-WeChat public account: Ant R&D efficiency
Source: https://mp.weixin.qq.com/s/w8ZM1rgL2fm9LI5oRYv7Bw