Sơ đồ tuần tự UML là một công cụ thiết yếu để hiểu hành vi động của một hệ thống. Nó mô hình hóa cách các đối tượng tương tác với nhau và thứ tự mà các tương tác này xảy ra, nhấn mạnh vàodòng chảy được sắp thứ tự theo thời gian của các tin nhắn. Nó rất quan trọng để xác định các trường hợp sử dụng, tài liệu hóa các lời gọi API và theo dõi các luồng giao dịch phức tạp.
Hướng dẫn này sẽ dẫn bạn qua các yếu tố cơ bản và các kỹ thuật mô hình hóa của sơ đồ tuần tự.
Cấu trúc cốt lõi và mục đích
Một sơ đồ tuần tự được tổ chức theo hai trục:
- Trục ngang:Hiển thị các thành phần tham giaCác đối tượng (hoặc các tác nhân, lớp và thành phần).
- Trục dọc (trục thời gian):Biểu diễn dòng chảy của thời gian, di chuyển xuống dưới. Các tin nhắn được gửi ở phía dưới sơ đồ xảy ra muộn hơn trong chuỗi.
Mục đích là để trả lời câu hỏi:“Trong tình huống cụ thể này (trường hợp sử dụng), các đối tượng này trao đổi thông tin theo thứ tự nào để đạt được kết quả mong muốn?”
Các yếu tố cơ bản của sơ đồ tuần tự
Để mô hình hóa một chuỗi, bạn cần ba yếu tố cốt lõi: các đường sống, tin nhắn và thanh kích hoạt.
A. Đường sống (Các thành phần tham gia)
Một đường sống biểu diễn một thành phần duy nhất—một đối tượng, thể hiện hoặc lớp—trong tương tác.
- Ký hiệu:Một hộp hình chữ nhật ở đầu sơ đồ chứa tên đối tượng, với một đường đứt đoạn dọc kéo dài xuống dưới.
- Ngữ pháp:
TênThànhPhần(nếu đối tượng là một thể hiện, ví dụ nhưngười dùng)TênThểHiện: TênLớp(ví dụ nhưauthService: AuthenticationService)
- Mục đích:Đường nét đứt chỉ sự hiện diện của người tham gia theo thời gian trong phạm vi của chuỗi.
B. Tin nhắn (Tương tác)
Các tin nhắn là các mũi tên ngang được vẽ giữa các đường đời. Chúng đại diện cho sự giao tiếp giữa các đối tượng, chẳng hạn như lời gọi phương thức, tín hiệu hoặc yêu cầu API.
Các loại tin nhắn:
| Loại tin nhắn | Ký hiệu | Mô tả |
|---|---|---|
| Lời gọi đồng bộ | Đường liền với đầu mũi tên đầy | Người gửi chờ phản hồi trước khi tiếp tục. Điều này khởi tạo mộtThanh kích hoạttrên đường đời của người nhận. |
| Phản hồi/Trao trả | Đường nét đứt với đầu mũi tên hở | Phản hồi cho một lời gọi đồng bộ, cho thấy việc trả lại quyền kiểm soát cho người gửi. Điều này thường đóng thanh kích hoạt. |
| Tin nhắn bất đồng bộ | Đường liền với đầu mũi tên hở | Người gửi không chờ phản hồi và tiếp tục thực thi của chính mình ngay lập tức. Thường gặp trong các kiến trúc dựa trên sự kiện. |
| Lời gọi tự thân | Mũi tên quay lại đường đời cùng một đối tượng | Một đối tượng gọi một trong các phương thức của chính nó. |
| Tin nhắn phát hiện | Mũi tên bắt đầu từ một điểm cuối và chạm vào một đường đời | Người gửi tin nhắn là không rõ hoặc nằm ngoài phạm vi biểu đồ (ví dụ: một sự kích hoạt bên ngoài). |
C. Thanh kích hoạt (Mô tả thực thi)
Thanh kích hoạt (còn gọi là điểm tập trung kiểm soát) là một hình chữ nhật dọc mỏng được vẽ trên đỉnh của một đường đời.
- Ký hiệu:Một hình chữ nhật dọc liền trên đường đời.
- Mục đích: Nó chỉ khoảng thời gian mà một đối tượng đang thực hiện một thao tác một cách tích cực (tức là phương thức của nó đang chạy) hoặc đang chờ phản hồi đồng bộ. Khoảng thời gian này bắt đầu khi nhận được một tin nhắn đồng bộ và kết thúc khi gửi tin nhắn phản hồi.
Mô hình hóa logic và luồng điều khiển
Để mô hình hóa logic kinh doanh phức tạp, bạn sử dụng các đoạn (hoặc khung) để bao quanh các phần của sơ đồ.
A. Các đoạn kết hợp
Các đoạn kết hợp cho phép bạn mô hình hóa logic điều kiện, lặp lại và các bước tùy chọn. Các đoạn phổ biến nhất bao gồm:
- Thay thế (alt):Dùng đểif-else logic. Đoạn được chia bởi một đường nét đứt, và mỗi phần bao gồm một điều kiện (một “bảo vệ”) trong dấu ngoặc vuông. Chỉ có một con đường có thể được chọn.
- Ví dụ:
[nếu thông tin xác thực người dùng hợp lệ]và[ngược lại / thông tin xác thực không hợp lệ].
- Ví dụ:
- Tùy chọn (opt):Dùng đểifcâu lệnh. Tương tác bên trong đoạn là tùy chọn và chỉ được thực hiện nếu điều kiện (bảo vệ) là đúng.
- Ví dụ:
[nếu người dùng có mặt hàng trong giỏ hàng].
- Ví dụ:
- Vòng lặp (loop):Dùng để lặp lại. Bảo vệ xác định điều kiện lặp lại (ví dụ như
[với mỗi mặt hàng]hoặc[trong khi (số lần thử < 3)]). - Tham chiếu (ref):Dùng để làm cho sơ đồ có cấu trúc hơn bằng cách tham chiếu đến một chuỗi tương tác được định nghĩa trong một sơ đồ tuần tự khác riêng biệt. Điều này giúp tránh làm sơ đồ trở nên quá rối rắm.
- Quan trọng (crit): Được dùng để chỉ một phần không được ngắt quãng, thường được dùng để mô hình hóa các quá trình đồng thời.
Ví dụ minh họa mô hình hóa từng bước
Hãy mô hình hóa một phiên bản đơn giản hóaQuy trình thanh toán của người dùng sử dụng các thành phần chính:
| Bước | Hành động | Loại tin nhắn |
|---|---|---|
| 1. | Người dùng nhấp vào “Thanh toán.” | Gọi đồng bộ |
| 2. | Frontend xác thực giỏ hàng. | Gọi tự thân (trên Frontend) |
| 3. | Frontend yêu cầu xử lý thanh toán. | Gọi đồng bộ |
| 4. | Cổng thanh toán kiểm tra số dư. | Gọi đồng bộ |
| 5. | Cổng thanh toán trả về “Thành công.” | Tin nhắn trả về |
| 6. | Frontend gửi một tin nhắn bất đồng bộ đến dịch vụ Kho để giảm tồn kho. | Tin nhắn bất đồng bộ |
| 7. | Frontend gửi một tin nhắn đồng bộ đến dịch vụ Đơn hàng để hoàn tất đơn hàng. | Gọi đồng bộ |
| 8. | Dịch vụ Đặt hàng trả về “Mã đơn hàng.” | Tin nhắn trả về |
| 9. | Frontend hiển thị trang xác nhận. | Tin nhắn trả về (đến người dùng) |
Mô hình hóa logic (đoạn khác)
Để xử lý lỗi, chúng tôi sử dụng mộtĐoạn khácđoạn:
- ĐặtKiểm tra Cổng thanh toán (Bước 4 & 5) bên trong một
altđoạn. - Phần đầu tiên được bảo vệ bởi
[Thành công]. Phần này bao gồm các bước 6, 7, 8 và 9. - Phần thứ hai, được chia bởi đường kẻ đứt đoạn, được bảo vệ bởi
[Thất bại]. Phần này bao gồm một tin nhắn đồng bộ mới:paymentService -> frontend: trả về "Thanh toán thất bại"và Frontend hiển thị trang lỗi.
Tóm tắt các nguyên tắc tốt nhất cho sơ đồ tuần tự
- Giữ tập trung:Một sơ đồ tuần tự duy nhất thường nên mô hình hóa một trường hợp sử dụng duy nhất hoặc một thao tác nguyên tử duy nhất (ví dụ: “Đăng nhập”, “Thêm sản phẩm vào giỏ hàng”). Sử dụngCác đoạn tham chiếucho các quy trình con.
- Đánh nhãn tin nhắn rõ ràng:Sử dụng cụm động từ cho tin nhắn, phản ánh tên phương thức hoặc điểm cuối API (ví dụ:
processPayment(amount, token)). - Xác định các bên tham gia một cách chính xác: Phân biệt giữa Người dùng (thành phần bên ngoài) và Đối tượng (thành phần hoặc thể hiện hệ thống bên trong).
- Thời gian chảy từ trên xuống: Đảm bảo các tin nhắn được sắp xếp nhất quán từ trên xuống dưới.
- Sử dụng các đoạn để kiểm soát: Tránh vẽ các nút quyết định phức tạp hoặc vòng lặp bên trong chính luồng tin nhắn; sử dụng
alt,opt, vàloopcác đoạn.
Để biết thêm chi tiết về UML và các phương pháp trực quan hóa được điều khiển bởi AI, hãy truy cập trung tâm tài nguyên UML của chúng tôitrung tâm tài nguyên UML.
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.