“Activity Diagram mô tả công việc. Sequence Diagram mô tả sự cộng tác.”
Theo tôi, Bài 15 là bước chuyển quan trọng nhất của cả học phần.
Đến đây, sinh viên sẽ bắt đầu chuyển từ tư duy nghiệp vụ (Business Thinking) sang tư duy thiết kế phần mềm (Software Design Thinking).
Đây cũng là nơi nhiều giáo trình khiến sinh viên nhầm lẫn.
Các em thường nghĩ:
Sequence Diagram là phiên bản “chi tiết hơn” của Activity Diagram.
Điều đó không đúng.
Hai sơ đồ trả lời hai câu hỏi hoàn toàn khác nhau:
- Activity Diagram: Quy trình nghiệp vụ diễn ra như thế nào?
- Sequence Diagram: Các đối tượng trong hệ thống phối hợp với nhau như thế nào để thực hiện quy trình đó?
Nếu hiểu được sự khác biệt này, sinh viên sẽ biết khi nào cần dùng mỗi loại sơ đồ
Vị trí của bài học trong chuỗi bài
Business Problem
↓
Stakeholder
↓
AS-IS Process
↓
TO-BE Process
↓
Requirement Engineering
↓
Use Case
↓
Use Case Specification
↓
Use Case Diagram
↓
Activity Diagram
↓
Sequence Diagram ← Bạn đang ở đây
↓
Domain Model
↓
Class DiagramMục tiêu bài học
Sau khi hoàn thành bài học này, bạn có thể:
- Hiểu mục đích của Sequence Diagram.
- Phân biệt Sequence Diagram với Activity Diagram.
- Xác định các đối tượng tham gia trong một Use Case.
- Mô hình hóa luồng trao đổi thông điệp giữa các đối tượng.
- Tránh những sai lầm phổ biến khi xây dựng Sequence Diagram.
1. Vì sao cần Sequence Diagram?
Giả sử chúng ta có Activity Diagram cho Use Case Đăng ký học phần.
Sơ đồ cho biết:
- Sinh viên chọn học phần.
- Hệ thống kiểm tra điều kiện tiên quyết.
- Hệ thống kiểm tra số chỗ còn lại.
- Hệ thống lưu kết quả.
- Hệ thống thông báo thành công.
Nhưng vẫn còn một câu hỏi:
Bên trong hệ thống, các thành phần nào phối hợp với nhau để thực hiện các bước này?
Ví dụ:
- Giao diện gọi ai?
- Ai kiểm tra điều kiện tiên quyết?
- Ai truy vấn cơ sở dữ liệu?
- Ai cập nhật lịch học?
- Ai gửi thông báo?
Đó là điều Sequence Diagram mô tả.
2. Sequence Diagram là gì?
Sequence Diagram là sơ đồ UML mô tả sự trao đổi thông điệp giữa các đối tượng theo trình tự thời gian.
Điểm quan trọng là:
Trục dọc biểu diễn thời gian.
Thông điệp được gửi từ trên xuống dưới theo đúng thứ tự xảy ra.
Nó giúp trả lời câu hỏi:
Đối tượng nào gọi đối tượng nào để hoàn thành một Use Case?
3. Sequence Diagram không mô tả điều gì?
Sequence Diagram không mô tả:
- Quy trình nghiệp vụ tổng thể.
- Luồng công việc giữa các phòng ban.
- Giao diện người dùng chi tiết.
- Cấu trúc cơ sở dữ liệu.
Đó là nhiệm vụ của các mô hình khác.
Sequence Diagram chỉ tập trung vào tương tác giữa các đối tượng.
4. Các thành phần cơ bản
Actor
Khởi tạo tương tác.
Ví dụ:
- Sinh viên
- Thủ thư
- Khách hàng
Actor thường là điểm bắt đầu của Sequence Diagram.
Lifeline
Mỗi đối tượng tham gia tương tác có một lifeline.
Ví dụ:
- Student
- RegistrationController
- RegistrationService
- CourseRepository
- NotificationService
Lifeline thể hiện sự tồn tại của đối tượng trong suốt quá trình tương tác.
Message
Thông điệp được gửi giữa các đối tượng.
Ví dụ:
Student
↓
RegistrationController
↓
RegistrationService
↓
CourseRepositoryMỗi mũi tên biểu diễn một lời gọi phương thức hoặc yêu cầu xử lý.
Activation
Activation biểu diễn khoảng thời gian đối tượng đang thực hiện một công việc.
Nó giúp người đọc biết khi nào một đối tượng đang xử lý và khi nào trả quyền điều khiển cho đối tượng khác.
Return Message
Sau khi xử lý xong, đối tượng có thể trả kết quả cho đối tượng đã gọi.
Trong nhiều công cụ UML hiện đại, thông điệp trả về có thể được lược bỏ nếu không làm thay đổi ý nghĩa của sơ đồ.
5. Ví dụ
Use Case:
Đăng ký học phần
Trình tự tương tác có thể như sau:
Student
↓
RegistrationController
↓
RegistrationService
↓
CourseRepository
↓
RegistrationRepository
↓
NotificationServiceLuồng thông điệp:
- Student gửi yêu cầu đăng ký học phần.
- Controller tiếp nhận yêu cầu.
- Controller gọi Service xử lý nghiệp vụ.
- Service kiểm tra điều kiện tiên quyết.
- Service truy vấn số chỗ còn lại.
- Service lưu kết quả đăng ký.
- Service yêu cầu gửi thông báo.
- Controller trả kết quả cho Student.
Activity Diagram và Sequence Diagram đều mô tả cùng một Use Case, nhưng từ hai góc nhìn khác nhau.
6. Activity Diagram và Sequence Diagram khác nhau như thế nào?
| Activity Diagram | Sequence Diagram |
|---|---|
| Mô tả quy trình nghiệp vụ | Mô tả sự tương tác giữa các đối tượng |
| Tập trung vào các hoạt động | Tập trung vào các thông điệp |
| Trả lời “Quy trình diễn ra như thế nào?” | Trả lời “Các đối tượng phối hợp như thế nào?” |
| Phù hợp để trao đổi với stakeholder | Phù hợp để trao đổi với nhóm phát triển |
Hai sơ đồ không thay thế nhau mà bổ sung cho nhau.
7. Sequence Diagram và kiến trúc phần mềm
Một Sequence Diagram tốt thường phản ánh kiến trúc của hệ thống.
Ví dụ với kiến trúc nhiều lớp:
Actor
↓
Presentation Layer
↓
Application Layer
↓
Domain Layer
↓
Infrastructure Layer
↓
DatabaseNhìn vào sơ đồ, chúng ta có thể đánh giá:
- Có vi phạm nguyên tắc phân lớp không?
- Có đối tượng nào đang đảm nhận quá nhiều trách nhiệm không?
- Có bước xử lý nào nên tách thành dịch vụ riêng không?
Sequence Diagram không chỉ là tài liệu phân tích mà còn hỗ trợ đánh giá thiết kế.
Sai lầm thường gặp
Chỉ vẽ Actor và Database
Nhiều sinh viên vẽ:
Actor
↓
DatabaseĐiều này bỏ qua toàn bộ các thành phần xử lý nghiệp vụ.
Trong hầu hết các hệ thống hiện đại, dữ liệu không được truy cập trực tiếp từ giao diện.
Đưa giao diện chi tiết vào sơ đồ
Ví dụ:
- Nhấn nút màu xanh.
- Chọn tab bên trái.
Đây là chi tiết của giao diện người dùng, không phải nội dung của Sequence Diagram.
Vẽ mọi lớp trong hệ thống
Một Sequence Diagram chỉ nên mô tả các đối tượng thực sự tham gia vào Use Case.
Không cần đưa toàn bộ kiến trúc của hệ thống vào một sơ đồ.
Không đồng bộ với Use Case
Nếu Sequence Diagram thực hiện các bước khác với Use Case Specification hoặc Activity Diagram, tài liệu sẽ mất tính nhất quán.
Tóm tắt
Sequence Diagram mô tả cách các đối tượng phối hợp để thực hiện một Use Case.
Nó giúp:
- Hiểu rõ trách nhiệm của từng đối tượng.
- Hỗ trợ thiết kế phần mềm.
- Kiểm tra tính hợp lý của kiến trúc.
- Làm cơ sở để lập trình.
Hãy nhớ:
Activity Diagram mô tả dòng công việc. Sequence Diagram mô tả dòng thông điệp.
Deliverable
Chọn 03 Use Case trong hệ thống của bạn và xây dựng Sequence Diagram.
Yêu cầu:
- Có Actor khởi tạo.
- Có tối thiểu 5 đối tượng tham gia.
- Thể hiện đầy đủ các thông điệp chính.
- Phản ánh đúng trình tự thời gian.
- Đồng nhất với Use Case Specification và Activity Diagram đã xây dựng.
Sau khi hoàn thành, hãy tự đánh giá:
- Mỗi đối tượng có một trách nhiệm rõ ràng không?
- Có thông điệp nào vi phạm kiến trúc phân lớp của hệ thống không?
Checklist
Sau khi học xong bài này, bạn nên trả lời được:
- Sequence Diagram dùng để làm gì?
- Phân biệt Sequence Diagram và Activity Diagram.
- Hiểu ý nghĩa của Actor, Lifeline, Message và Activation.
- Mô hình hóa được tương tác giữa các đối tượng.
- Kiểm tra được tính hợp lý của thiết kế thông qua Sequence Diagram.
Góc nhìn nghề nghiệp
Trong các dự án hiện đại, Sequence Diagram thường không được xây dựng cho mọi Use Case, mà chỉ tập trung vào các luồng nghiệp vụ quan trọng hoặc phức tạp. Những Use Case đơn giản có thể được mô tả đầy đủ bằng Use Case Specification và mã nguồn.
Tuy nhiên, với các chức năng liên quan đến nhiều dịch vụ, tích hợp hệ thống hoặc quy trình nghiệp vụ phức tạp, Sequence Diagram vẫn là công cụ hiệu quả để thảo luận về thiết kế trước khi lập trình. Nó giúp nhóm phát triển thống nhất trách nhiệm giữa các thành phần, phát hiện sớm các phụ thuộc không cần thiết và giảm chi phí chỉnh sửa ở giai đoạn triển khai.
Bài tiếp theo
Đến đây, chúng ta đã mô hình hóa hành vi của hệ thống thông qua Requirement, Use Case, Activity Diagram và Sequence Diagram.
Nhưng vẫn còn một câu hỏi quan trọng:
Hệ thống đang quản lý những đối tượng nào? Chúng có những thuộc tính gì và quan hệ với nhau ra sao?
Đó là nội dung của Bài 16 – Domain Model, nơi chúng ta sẽ chuyển từ mô hình hóa hành vi (Behavioral Modeling) sang mô hình hóa cấu trúc miền nghiệp vụ (Structural Modeling). Đây là nền tảng để xây dựng Class Diagram và thiết kế cơ sở dữ liệu trong các bước tiếp theo.