Phân tích và thiết kế động
Mục lục
Giới thiệu Phân tích và thiết kế động
Khi hệ thống cần hiểu hành vi, không chỉ cấu trúc
🧭 1.1. Vì sao cần mô hình động?
Trong bài học trước, bạn đã học về phân tích tĩnh – nơi hệ thống được biểu diễn như một tập hợp lớp, thuộc tính và quan hệ giữa chúng.
Tuy nhiên, điều đó chỉ cho ta biết hệ thống được cấu tạo như thế nào, chứ không cho ta biết nó hoạt động ra sao.
💡 Một hệ thống phần mềm không chỉ là “bộ xương” (class diagram), mà còn là “chuyển động” – chính là các tương tác, luồng xử lý và phản hồi với người dùng.
🔄 1.2. Mô hình động là gì?
Mô hình động (Dynamic Model) mô tả:
- Cách các đối tượng tương tác với nhau
- Cách hệ thống phản hồi với hành động người dùng
- Trình tự các bước diễn ra khi thực hiện một chức năng
📌 1.3. Mô hình tĩnh vs. mô hình động
| So sánh | Mô hình TĨNH | Mô hình ĐỘNG |
|---|---|---|
| Mục tiêu chính | Biểu diễn cấu trúc hệ thống | Biểu diễn hành vi, luồng xử lý |
| Giai đoạn sử dụng | Phân tích kiến trúc, thiết kế lớp | Thiết kế quy trình, giao tiếp |
| Công cụ chính | Class Diagram | Activity Diagram, Sequence Diagram |
| Có yếu tố thời gian? | ❌ Không | ✅ Có |
| Mô tả tương tác người dùng? | ❌ Không | ✅ Có |
🧠 1.4. Khi nào cần mô hình động?
- Khi bạn cần hiểu một luồng xử lý phức tạp
- Khi bạn muốn phát triển logic từ use-case
- Khi bạn cần xác định ai gọi ai, theo thứ tự nào
- Khi bạn muốn viết mã nhưng chưa rõ luồng nghiệp vụ
🧩 1.5. Công cụ chính:
- Activity Diagram (Sơ đồ hoạt động)
→ Mô tả chi tiết xử lý nội bộ
→ Tương tự sơ đồ dòng (flowchart), nhưng có swimlane, fork/join - Sequence Diagram (Sơ đồ trình tự)
→ Mô tả chuỗi giao tiếp giữa các đối tượng
→ Nhấn mạnh thứ tự gọi hàm, trả kết quả
🧾 1.6. Các câu hỏi mà mô hình động giúp trả lời:
| Câu hỏi | Trả lời qua |
|---|---|
| Khi người dùng nhấn nút X, điều gì xảy ra? | Activity Diagram |
| Ai gọi đến phương thức “xử lý thanh toán”? | Sequence Diagram |
| Việc kiểm tra tồn kho diễn ra ở đâu trong quá trình? | Activity Diagram |
Luồng giao tiếp giữa User, Cart, Order là gì? | Sequence Diagram |
⚠️ 1.7. Sai lầm khi không dùng mô hình động
| Không làm | Hệ quả |
|---|---|
| Không mô hình hóa quy trình | Code khó tổ chức, xử lý logic sai |
| Không hiểu rõ thứ tự gọi hàm | Viết sai luồng điều khiển |
| Không xác định vai trò từng đối tượng | Gây chồng chéo, trách nhiệm mờ |
Ghi nhớ:
- Mô hình động = mô tả hệ thống “sống” và “phản ứng”
- Là phần không thể thiếu trong thiết kế hoàn chỉnh
- Giúp nhóm hiểu: “Chuyện gì xảy ra khi người dùng làm gì đó?”
- Là nền tảng để:
- Viết code có luồng rõ ràng
- Tối ưu hiệu năng xử lý
- Giao tiếp tốt hơn trong nhóm
Sơ đồ hoạt động – Mô hình hóa quy trình xử lý chi tiết
🧠 2.1. Sơ đồ hoạt động là gì?
Sơ đồ hoạt động (Activity Diagram) là công cụ mô hình hóa dùng để:
- Biểu diễn luồng xử lý nghiệp vụ
- Mô tả các bước trong một quy trình từ đầu đến cuối
- Cho thấy luồng điều khiển (control flow) và quyết định (decision) trong hệ thống
💡 Nó rất giống sơ đồ dòng (flowchart), nhưng mạnh mẽ hơn nhờ:
- Có swimlane để phân vai trò
- Hỗ trợ song song, rẽ nhánh, hợp nhất
📌 2.2. Khi nào nên dùng sơ đồ hoạt động?
| Tình huống | Dùng Activity Diagram để… |
|---|---|
| Mô tả một Use Case cụ thể | Hiểu rõ các bước nghiệp vụ |
| Viết mã cho một tính năng phức tạp | Hình dung logic trước khi code |
| Thiết kế UI dựa trên luồng thao tác | Biết thứ tự xuất hiện nút, thông báo |
| Kiểm tra tính đầy đủ của yêu cầu | Phát hiện nhánh thiếu, trường hợp chưa xử lý |
🧰 2.3. Các thành phần chính trong sơ đồ hoạt động
| Thành phần | Biểu tượng UML | Mô tả ngắn |
|---|---|---|
| Initial Node | ⚫ | Điểm bắt đầu |
| Activity / Action | 🟦 (hình chữ nhật bo tròn) | Một hành động đơn vị |
| Decision Node | ◆ | Rẽ nhánh điều kiện |
| Merge Node | ◆ | Gộp lại các nhánh |
| Fork Node | —► | Tách song song |
| Join Node | ◄— | Hợp lại sau xử lý song song |
| Final Node | ◯ ⚫ | Kết thúc |
| Swimlane | Cột dọc | Phân vai trò actor/object |
| Transition (Arrow) | → | Luồng điều khiển |
🔍 2.4. Cách xây dựng một sơ đồ hoạt động
Bước 1: Xác định đối tượng chính
→ Ai đang thực hiện hành động? (người dùng, hệ thống, nhân viên…)
Bước 2: Ghi lại luồng xử lý bằng lời
→ Viết các bước theo trình tự:
“Người dùng đăng nhập → nhập mật khẩu → hệ thống xác minh → chuyển hướng”
Bước 3: Chuyển từng bước thành Action
→ Dùng hình chữ nhật bo tròn để biểu diễn
Bước 4: Xác định nhánh / điều kiện / song song
→ Dùng biểu tượng Decision (◆), Fork, Join nếu có
Bước 5: Phân chia Swimlane
→ Mỗi người/đối tượng là 1 cột riêng
✍️ 2.5. Ví dụ đơn giản: Mượn sách
Giả sử Use Case là: “Người dùng mượn sách tại thư viện”
Ta có thể mô hình hóa:
- Người dùng quét thẻ →
- Nhân viên kiểm tra sách còn không →
- Nếu còn → nhập thông tin mượn →
- Nếu không → thông báo không có sách
👉 Sơ đồ gồm:
- 2 Swimlane: User, Staff
- Action: Quét thẻ, Kiểm tra sách, Nhập thông tin, Thông báo
- Decision: “Sách còn?” với 2 nhánh Yes/No
💡 2.6. Ưu điểm của sơ đồ hoạt động
| Ưu điểm | Tác dụng thực tế |
|---|---|
| Trực quan, dễ hiểu | Giúp cả kỹ thuật và không kỹ thuật cùng nắm được quy trình |
| Mô tả xử lý chi tiết | Rất hữu ích để chuyển thành mã lệnh |
| Phát hiện nhánh chưa xử lý | Giúp kiểm thử, thiết kế giao diện chính xác |
| Phân rõ trách nhiệm | Nhờ Swimlane, biết ai làm gì, ở bước nào |
⚠️ 2.7. Cẩn thận với các lỗi thường gặp
| Lỗi | Tác hại |
|---|---|
| Vẽ quá chi tiết | Mất thời gian, trùng logic với code |
| Không dùng swimlane | Khó phân biệt trách nhiệm |
| Thiếu Decision node | Logic không rõ ràng, dễ thiếu kiểm soát |
| Thiếu Final node | Không biết quy trình kết thúc ở đâu |
🧾 2.8. Ghi nhớ:
- Activity Diagram mô tả luồng xử lý từng bước, rất gần với logic lập trình
- Dễ dùng để:
- Xây dựng UI đúng trình tự
- Chuyển từ Use Case sang hành vi cụ thể
- Kiểm thử hệ thống
- Là công cụ trung gian tuyệt vời giữa:
- Yêu cầu nghiệp vụ
- Thiết kế giao diện
- Code thực thi
Từ sơ đồ hoạt động đến mã nguồn – Viết code dựa trên quy trình
🎯 3.1. Mục tiêu: Chuyển logic hình ảnh thành mã thực thi
Sơ đồ hoạt động (Activity Diagram) là một cách biểu diễn luồng xử lý bằng hình ảnh.
Nhưng đến một lúc nào đó, bạn cần hiện thực hóa những bước xử lý đó thành mã nguồn cụ thể.
💬 Nếu sơ đồ hoạt động giống như kịch bản, thì code chính là bộ phim.
🧱 3.2. Mỗi hành động = một dòng code
- Mỗi Action trong sơ đồ thường tương ứng với:
- Một dòng lệnh
- Một lời gọi phương thức
- Một khối xử lý (if/else, vòng lặp…)
- Decision Node trong sơ đồ → tương ứng với
if,switch - Fork/Join Node → tương ứng với xử lý song song (thread, async)
🧪 3.3. Ví dụ chuyển đổi từng bước
📌 Mô tả sơ đồ:
“Người dùng nhập ISBN → hệ thống tìm sách → nếu tìm thấy → hiển thị thông tin sách → nếu không → thông báo lỗi”
✍️ Mã C# tương ứng:
csharpCopyEditvoid findBookFlow(string isbn)
{
Book foundBook = findBook(isbn);
if (foundBook != null)
{
displayBookInfo(foundBook);
}
else
{
showError("Không tìm thấy sách.");
}
}
🧩 3.4. Cấu trúc mã phổ biến khi chuyển từ sơ đồ
| Biểu tượng sơ đồ | Cấu trúc tương ứng trong code |
|---|---|
| Action | Lệnh, phương thức (method call) |
| Decision | if, switch |
| Merge | Kết thúc điều kiện, tiếp tục luồng chính |
| Fork / Join | Parallel.For, Task.WhenAll (C#), async/await |
| Final Node | return, exit, hoặc kết thúc hàm |
🛠 3.5. Kỹ thuật triển khai: “Từ trong ra ngoài”
Trong lập trình hướng đối tượng, tốt nhất là:
- Viết các phương thức nhỏ trước (được gọi trong sơ đồ)
- Sau đó viết method tổng, là bản chuyển thể từ sơ đồ hoạt động
💡 Bạn không thể viết
findBookFlow()nếu chưa cófindBook()vàdisplayBookInfo()
🔁 3.6. Sử dụng prototype code để kiểm thử
- Khi còn nghi ngờ logic → có thể viết mã nguyên mẫu (throwaway prototype)
- Viết nhanh từng nhánh xử lý → chạy thử → xác nhận
- Sau đó mới viết bản chính thức với mã sạch hơn
⚠️ 3.7. Những lỗi phổ biến khi dịch từ sơ đồ sang code
| Lỗi | Hệ quả |
|---|---|
| Bỏ sót điều kiện trong Decision | Logic thiếu → lỗi chạy hoặc sai luồng |
| Không chia nhỏ hành động | Hàm quá dài, khó bảo trì |
| Quên viết hàm được gọi | Lỗi biên dịch, khó debug |
| Không rõ vai trò actor nào xử lý | Code lẫn lộn giữa các class |
📌 3.8. Cách tổ chức mã tốt theo sơ đồ
- Mỗi Swimlane (actor) → tương ứng với 1 class/method chịu trách nhiệm
- Action của người dùng → nên gọi vào controller/UI layer
- Action của hệ thống → nên gọi vào business logic hoặc service
🧾 3.9. Checklist khi viết code từ sơ đồ hoạt động
✅ Viết rõ ràng từng bước xử lý
✅ Sử dụng if, while, for để phản ánh rẽ nhánh / lặp
✅ Tạo đủ các method nhỏ trước khi gọi
✅ Comment tương ứng với từng hành động trong sơ đồ
✅ Kiểm thử logic từng nhánh
💬 Ghi nhớ chương này:
- Sơ đồ hoạt động là nền móng trực tiếp cho việc lập trình
- Chuyển đổi tốt → giúp code sạch, đúng logic, dễ mở rộng
- Việc viết code cần:
- Tư duy mạch lạc
- Chia nhỏ phương thức
- Gắn logic với nghiệp vụ
Sơ đồ trình tự – Mô hình hóa chuỗi tương tác giữa các đối tượng
🧠 4.1. Sơ đồ trình tự là gì?
Sequence Diagram (sơ đồ trình tự) là công cụ dùng để mô tả:
- Thứ tự các lời gọi phương thức giữa các đối tượng
- Luồng tương tác trong một use-case
- Ai gọi ai, vào thời điểm nào, và trả về gì
💬 Nếu sơ đồ hoạt động mô tả bên trong một vai trò, thì sơ đồ trình tự mô tả sự giao tiếp giữa các vai trò (đối tượng, lớp, actor).
🔎 4.2. Khi nào cần dùng Sequence Diagram?
| Tình huống | Lý do nên dùng Sequence Diagram |
|---|---|
| Có nhiều class cùng tham gia một chức năng | Biết rõ thứ tự gọi hàm, tránh vòng lặp |
| Thiết kế hệ thống phức tạp | Nhìn được toàn cảnh giao tiếp |
| Phân công lập trình cho nhóm | Biết class nào cần method gì |
| Kiểm thử logic nghiệp vụ | Theo dõi và mô phỏng được luồng xử lý |
🧱 4.3. Các thành phần trong sơ đồ trình tự
| Thành phần | Ký hiệu / Mô tả |
|---|---|
| Lifeline | Dọc xuống – đại diện cho 1 object hoặc actor |
| Message | Mũi tên đầy – lời gọi method |
| Return Message | Mũi tên đứt nét – giá trị trả về |
| Activation Bar | Thanh dọc trên lifeline – thời gian đối tượng xử lý |
| Frame | Ô chữ nhật bao quanh – mô tả logic: điều kiện, lặp, tùy chọn |
| [guard] | Điều kiện gọi hàm – ví dụ: [sách có sẵn] |
🧍♂️ 4.4. Lưu ý quan trọng: class ≠ object
- Trong sơ đồ class: bạn mô tả class
- Trong sơ đồ trình tự: bạn mô tả đối tượng cụ thể
Ví dụ:
book1:Booklà một instance cụ thể của classBookuser:Patronlà một đối tượng cụ thể đang tương tác
✍️ 4.5. Ví dụ: Trình tự mượn sách
Tình huống Use-Case:
“Người dùng yêu cầu mượn sách. Hệ thống kiểm tra trạng thái sách. Nếu sẵn có, tiến hành ghi nhận giao dịch.”
Sơ đồ sẽ gồm:
- Lifeline:
User,Library,Book,LoanManager - Message:
requestLoan(),checkAvailability(),createLoanRecord() - Return Message:
true/false,confirmation
🛠 4.6. Frame phổ biến trong UML
| Frame | Ý nghĩa | Ví dụ |
|---|---|---|
alt | Điều kiện rẽ nhánh (if/else) | [sách có sẵn] |
loop | Vòng lặp (while, for) | [i < count] |
opt | Hành động tùy chọn (if) | [user is admin] |
par | Hành động song song | [gửi email] và [cập nhật DB] |
🔁 4.7. So sánh sơ đồ hoạt động và sơ đồ trình tự
| Tiêu chí | Activity Diagram | Sequence Diagram |
|---|---|---|
| Mục tiêu chính | Mô tả luồng xử lý bên trong | Mô tả tương tác giữa các đối tượng |
| Gần với… | Mã trong 1 method | Luồng Use Case |
| Mức độ chi tiết | Từng bước thao tác cụ thể | Giao tiếp và lời gọi giữa object |
| Có yếu tố thời gian? | Có (luồng tuần tự) | Rất rõ ràng về thời gian gọi |
⚠️ 4.8. Những lỗi thường gặp khi vẽ Sequence Diagram
| Lỗi | Tác hại |
|---|---|
| Vẽ class thay vì object | Không đúng chuẩn UML |
| Mũi tên không đúng thứ tự | Gây hiểu sai logic |
| Gộp nhiều luồng logic trong 1 sơ đồ | Rối, khó đọc |
| Không dùng frame cho điều kiện | Mất đi tính rõ ràng trong nhánh |
🧾 4.9. Checklist khi xây dựng Sequence Diagram
✅ Mỗi đối tượng đều có tên & class rõ ràng (vd: user:Patron)
✅ Mỗi lời gọi phương thức có tên method rõ ràng
✅ Dùng đúng return message nếu cần thiết
✅ Dùng frame [condition] cho logic rẽ nhánh
✅ Không lặp lại thao tác đã có trong class khác
✅ Tập trung cho từng Use Case – không gộp nhiều luồng
Ghi nhớ :
- Sơ đồ trình tự cho thấy hệ thống “giao tiếp” như thế nào
- Là công cụ chiến lược để:
- Lập kế hoạch logic nghiệp vụ
- Phân công nhiệm vụ trong nhóm
- Tái hiện hành vi Use Case ở cấp cao
- Nên dùng sau sơ đồ lớp và sơ đồ hoạt động
🎯 Nếu sơ đồ class là “bản đồ tĩnh”, thì sequence diagram là “kịch bản tương tác thời gian thực”.
Tổng kết mô hình động – Kết hợp sơ đồ hoạt động và sơ đồ trình tự hiệu quả
🎯 5.1. Tại sao cần cả hai loại sơ đồ?
Trong phân tích động, ta có 2 công cụ chính:
- Activity Diagram → thể hiện chi tiết bên trong 1 chức năng
- Sequence Diagram → thể hiện tương tác giữa các đối tượng
💬 Cả hai đều giúp ta “diễn hoạt” hệ thống – nhưng mỗi cái nhìn từ một góc độ khác.
🔍 5.2. So sánh tổng quát
| Đặc điểm | Activity Diagram | Sequence Diagram |
|---|---|---|
| Góc nhìn | Luồng nghiệp vụ bên trong 1 actor/class | Giao tiếp giữa nhiều đối tượng |
| Mức độ chi tiết | Rất chi tiết từng bước xử lý | Chi tiết lời gọi phương thức và thời gian |
| Phù hợp với… | Viết code cho method cụ thể | Hiểu logic Use Case phức tạp |
| Có yếu tố tuần tự theo thời gian? | Có, theo luồng từ trên xuống | Có, thứ tự gọi hàm từ trái sang phải |
| Có mô tả điều kiện rẽ nhánh? | Có, rất rõ với Decision node | Có, dùng [guard] + frame alt/opt |
| Biểu diễn hành vi song song? | Có (Fork/Join) | Có (frame par) |
| Dễ dùng cho test case? | ✅ | ✅ |
🧱 5.3. Khi nào dùng sơ đồ nào?
| Mục tiêu phân tích | Sử dụng sơ đồ |
|---|---|
| Thiết kế chi tiết logic của một quy trình | Activity Diagram |
| Xác định rõ ai gọi ai trong 1 Use Case | Sequence Diagram |
| Truy ngược lỗi logic trong 1 hành động | Activity Diagram |
| Xác minh thứ tự gọi phương thức giữa object | Sequence Diagram |
| Viết unit test | Cả hai đều hỗ trợ |
📦 5.4. Quy trình đề xuất: kết hợp cả hai sơ đồ
Ví dụ: Use Case “Đặt hàng”
- Bước 1: Vẽ sơ đồ lớp (class diagram)
→ Xác định các class chính:User,Cart,Order,Product - Bước 2: Vẽ sơ đồ trình tự (sequence)
→ Giao tiếp:User→Cart→Order
→ Hiển thị thứ tự lời gọiaddToCart(),checkout(),confirmPayment() - Bước 3: Chọn một bước cụ thể → vẽ sơ đồ hoạt động (activity)
→ Ví dụ: hành độngcheckout()sẽ có sơ đồ gồm:- Kiểm tra giỏ hàng
- Tính phí
- Gửi email xác nhận
- Lưu đơn hàng
✅ Như vậy: sequence giúp chia tổng thể, activity giúp tập trung chi tiết.
🧭 5.5. Lời khuyên khi áp dụng mô hình động
- Đừng cố vẽ tất cả sơ đồ cho mọi chức năng → chỉ vẽ khi cần
- Luôn kết nối các sơ đồ với Use Case để tránh lan man
- Với dự án nhóm:
- Activity Diagram giúp viết mã chính xác
- Sequence Diagram giúp phân chia module, trách nhiệm
🧾 5.6. Checklist hoàn chỉnh mô hình động
✅ Đã xác định các Use Case quan trọng
✅ Có sơ đồ trình tự cho Use Case phức tạp
✅ Có sơ đồ hoạt động cho chức năng logic nhiều bước
✅ Tất cả sơ đồ đều dễ chuyển thành mã
✅ Không có phần xử lý nào bị “bỏ trống” trong sơ đồ
💬 Ghi nhớ chương này:
- Mô hình động không bắt buộc vẽ nhiều – nhưng khi vẽ, phải dùng được
- Activity Diagram giúp bạn viết code tốt hơn
- Sequence Diagram giúp bạn tổ chức hệ thống rõ ràng hơn
- Kết hợp cả hai = nền tảng vững chắc để lập trình đúng hướng
🎯 Phân tích tốt = mô hình hóa đúng = tiết kiệm công sức và tránh sai sót về sau
Bài viết liên quan:
Dịch vụ thiết kế Wesbite
