Phân tích & Thiết kế hướng đối tượng linh hoạt (Agile Object Orientation)

Phân tích & Thiết kế hướng đối tượng linh hoạt (Agile Object Orientation)

12-06-2025
Toanngo92
0 Comments

Mục lục

OOAD là gì và vì sao cần quan tâm?

Phân tích và thiết kế hướng đối tượng (Object-Oriented Analysis and Design – OOAD) là một phương pháp giúp chúng ta phát triển phần mềm dựa trên các đối tượng (object) – những thành phần mô phỏng các thực thể, hành vi trong thế giới thực.

OOAD không phải là điều mới mẻ, nhưng vẫn là nền tảng vững chắc của ngành công nghiệp phần mềm hiện nay, đặc biệt trong môi trường phát triển linh hoạt (agile). Nó giúp chúng ta:

Quản lý hệ thống lớn và phức tạp tốt hơn
Mô hình hóa thực tế theo cách gần gũi với tư duy con người
Dễ bảo trì, tái sử dụng và mở rộng phần mềm

Tuy nhiên, cũng cần thẳng thắn rằng OOAD không phải là “thuốc tiên” cho mọi vấn đề. Nó cũng có nhược điểm, đặc biệt nếu lạm dụng hoặc hiểu sai.

Trong bài viết này, ta sẽ xem xét sự ra đời của OOAD từ bối cảnh lịch sử, lý do nó ra đời, và vai trò của nó trong sự chuyển dịch từ cách tiếp cận cũ sang thiết kế phần mềm hiện đại.

Trước đây – Cách tiếp cận truyền thống và giới hạn của nó

Phân tích hệ thống trước OOAD:

Trước khi OOAD ra đời và phổ biến, hai phương pháp được dùng phổ biến nhất trong phân tích và thiết kế phần mềm là:

1. Mô hình hóa tập trung dữ liệu (Data-Centric Modelling)

Phương pháp này xem hệ thống chủ yếu như một tập hợp dữ liệu và quy trình xử lý dữ liệu, với ít chú trọng đến hành vi riêng biệt của từng thành phần trong hệ thống.

2. Mô hình thác nước (Waterfall Model)

Một mô hình phát triển tuyến tính, trong đó:

Giai đoạn phân tích → thiết kế → lập trình → kiểm thử → triển khai → bảo trì
Diễn ra tuần tự, không quay lại bước trước

Những giới hạn của cách tiếp cận cũ

Không phù hợp với hệ thống phức tạp
- Khi phần mềm lớn lên, có nhiều mối quan hệ tương tác → sơ đồ mô hình hóa truyền thống trở nên quá tải và khó bảo trì
Khó thích ứng với thay đổi
- Mô hình thác nước giả định rằng mọi yêu cầu đều rõ ràng từ đầu – điều hiếm xảy ra trong thực tế
- Khi yêu cầu thay đổi giữa chừng → rất khó sửa lại mà không phá vỡ toàn bộ quy trình
Thiếu tính mô-đun, dẫn đến chi phí bảo trì cao
- Các phần trong hệ thống gắn chặt với nhau, khó thay thế từng phần riêng biệt
Không phản ánh tư duy và cách sử dụng thực tế
- Người dùng thường nghĩ về các “thực thể” (người, đơn hàng, sản phẩm), không nghĩ về “dữ liệu và xử lý” – điều mà mô hình truyền thống nhấn mạnh

OOAD xuất hiện như một giải pháp

Trước những vấn đề đó, OOAD ra đời như một bước chuyển mình cần thiết, giúp:

Đơn giản hóa thiết kế bằng cách tập trung vào “đối tượng” thay vì “dữ liệu”
Cho phép thiết kế lặp (iterative) và thích ứng linh hoạt hơn
Tăng khả năng mở rộng, bảo trì, tái sử dụng mã

Tóm tắt

Nội dung	Mô tả
Hạn chế của phương pháp cũ	Không phù hợp với hệ thống phức tạp, khó thay đổi, thiếu mô-đun
Mô hình hóa tập trung dữ liệu	Nhấn mạnh xử lý dữ liệu hơn hành vi, khó mở rộng
Mô hình thác nước (Waterfall)	Tuyến tính, không thích ứng với thay đổi yêu cầu
OOAD xuất hiện như giải pháp	Lấy đối tượng làm trung tâm, phù hợp hơn với tư duy thực tế

Ghi nhớ: OOAD không chỉ là một công cụ kỹ thuật – nó là một cách nhìn nhận hệ thống gần với cách con người nghĩ, hành động và tổ chức thế giới xung quanh.

Độ phức tạp phần mềm

📌 Vấn đề: phần mềm ngày càng phức tạp

Khi công nghệ phát triển, các hệ thống phần mềm ngày càng mở rộng về:

Số lượng chức năng
Số lượng người dùng
Tích hợp với nhiều hệ thống khác

Kết quả là:

Các sơ đồ thiết kế truyền thống trở nên rối rắm, khó hiểu
Việc bảo trì, cập nhật hay mở rộng gặp khó khăn nghiêm trọng
Hệ thống càng lớn, rủi ro lỗi và chi phí sửa lỗi càng cao

🧠 Giải pháp: Hướng đối tượng (Object Orientation)

1. Đơn giản hóa kiến trúc bằng “object”

Thay vì thiết kế hệ thống như một khối lớn, OOAD phân chia hệ thống thành các đối tượng (object) – mỗi đối tượng là:

Một đơn vị độc lập
Có dữ liệu riêng (thuộc tính)
Có hành vi riêng (phương thức)
Tự quản lý trạng thái và cách xử lý

→ Nhìn mỗi object như một chương trình nhỏ tự hoạt động

🤝 Tư duy thiết kế theo hướng tương tác

Toàn bộ hệ thống giờ đây không còn là một dòng chảy dữ liệu tuyến tính, mà là:

Một mạng lưới tương tác giữa các đối tượng nhỏ

Ví dụ:

Một hệ thống bán hàng có thể gồm các object: KháchHàng, GiỏHàng, SảnPhẩm, ĐơnHàng, ThanhToán
Mỗi object có nhiệm vụ riêng, và chúng giao tiếp với nhau để hoàn thành quy trình

📈 Lợi ích chính khi dùng object để thiết kế:

Lợi ích	Mô tả
Giảm rối rắm sơ đồ	Mỗi object là một đơn vị, sơ đồ rõ ràng hơn
Dễ hiểu và dễ trình bày	Dễ mô tả cho người không chuyên
Tăng tính mô-đun	Có thể chỉnh sửa, thay thế từng phần
Tăng khả năng tái sử dụng	Một object có thể dùng lại trong hệ thống khác

📘 Chương 4: Hướng đối tượng – Từ hàm thủ tục đến đối tượng thông minh

🔄 Từ lập trình thủ tục (procedural) đến lập trình hướng đối tượng

Trước đây, hầu hết chương trình được viết theo phong cách cấu trúc tuần tự:

Gồm các hàm (function) xử lý dữ liệu được lưu ở nơi khác
Dễ gây lỗi khi mở rộng hệ thống
Thiếu khả năng tổ chức và quản lý phức tạp

✅ Hướng đối tượng cải tiến như thế nào?

Mỗi đối tượng là một thực thể hoàn chỉnh
- Kết hợp dữ liệu và hành vi trong một gói
Tăng tính trừu tượng
- Có thể mô hình hóa các thực thể ngoài đời: người dùng, đơn hàng, thiết bị…
Mã dễ bảo trì và mở rộng
- Thay vì viết lại toàn bộ, có thể kế thừa hoặc mở rộng object sẵn có

⚠️ Vì sao lập trình cấu trúc cũ thiếu tính bảo trì?

Hàm và dữ liệu tách rời → sửa một chỗ có thể gây lỗi chỗ khác
Không có ranh giới rõ ràng → dễ đụng chạm không mong muốn
Không hỗ trợ tính đóng gói, kế thừa, đa hình – những đặc tính cốt lõi của OOP

💡 OOP là bước tiến để khắc phục các nhược điểm trên

Vấn đề của lập trình cũ	OOP giải quyết thế nào
Hàm tách biệt dữ liệu	Gộp lại thành object
Khó mở rộng	Sử dụng kế thừa, interface
Dễ lỗi khi bảo trì	Dùng encapsulation và phân rã hợp lý
Tư duy theo quy trình máy	Chuyển sang tư duy theo thực thể

💬 Ghi nhớ: Hướng đối tượng không chỉ là cú pháp hay công cụ – nó là một cách tư duy phần mềm hiện đại, giúp ta đối mặt với sự phức tạp bằng cách chia nhỏ và tổ chức hợp lý.

Lợi ích và Hạn chế của OOAD

Lợi ích của Phân tích và Thiết kế Hướng đối tượng (OOAD)

OOAD không chỉ là một kỹ thuật, mà là một cách tư duy toàn diện về phần mềm – từ phân tích yêu cầu, thiết kế hệ thống, đến lập trình và bảo trì. Dưới đây là những lợi ích cốt lõi:

✅ 1. Hệ thống dễ phân rã thành các đơn vị logic

OOAD cho phép chia hệ thống lớn thành các lớp (class) và đối tượng (object) – mỗi phần có trách nhiệm rõ ràng.
Nhờ đó:
- Dễ thiết kế theo từng module
- Dễ kiểm soát phạm vi chức năng của từng thành phần

✅ 2. Tăng khả năng bảo trì

Mỗi thành phần có thể:
- Được cập nhật độc lập
- Được kiểm thử riêng lẻ
Giảm rủi ro ảnh hưởng lẫn nhau khi thay đổi hệ thống

✅ 3. Tái sử dụng hiệu quả hơn

Các lớp và object được thiết kế tốt có thể:
- Dùng lại trong nhiều dự án
- Mở rộng bằng kế thừa hoặc interface

→ Giảm chi phí phát triển, tăng tốc độ xây dựng hệ thống mới

✅ 4. Gần với thế giới thực

OOAD mô hình hóa hệ thống theo các thực thể ngoài đời, giúp:
- Dễ hiểu cho người không chuyên
- Dễ liên hệ trong quá trình phân tích nghiệp vụ

📌 Tóm tắt lợi ích

Lợi ích	Ý nghĩa thực tiễn
Dễ phân rã hệ thống	Tổ chức tốt hơn, rõ ràng trách nhiệm giữa các phần
Tăng khả năng bảo trì	Dễ chỉnh sửa từng phần mà không ảnh hưởng toàn cục
Dễ tái sử dụng	Phát triển nhanh hơn, giảm chi phí
Mô hình hóa gần với thực tế	Dễ hiểu, dễ trình bày và dễ đồng thuận với người dùng

🟥 5.2. Hạn chế của OOAD – Khi sức mạnh trở thành gánh nặng

Dù OOAD là phương pháp hiệu quả, nó không hoàn hảo, và việc áp dụng sai hoặc quá mức có thể dẫn đến nhiều vấn đề.

⚠️ 1. Hệ thống lớn có thể sinh ra hàng trăm lớp

Khi mỗi đối tượng đều có class riêng, số lượng class có thể tăng chóng mặt:
- Gây khó đọc, khó quản lý
- Khó tìm lỗi hoặc hiểu luồng xử lý

⚠️ 2. Dễ thiết kế sai class

Việc phân chia class đòi hỏi:
- Hiểu rõ nghiệp vụ
- Kinh nghiệm thiết kế tốt
Nếu thiết kế sai:
- Code rối
- Không tận dụng được tính tái sử dụng

⚠️ 3. Cân bằng giữa coupling và cohesion

Hai khái niệm quan trọng:
- Cohesion: mức độ “gắn kết nội tại” của một class – càng cao càng tốt
- Coupling: mức độ “phụ thuộc giữa các class” – càng thấp càng tốt

Thách thức: Khi cohesion tăng, coupling cũng có thể tăng → cần thiết kế khéo léo để đạt cân bằng

⚠️ 4. OOAD vẫn là tư duy “khó quen” với người mới

Với người dùng hoặc sinh viên mới học:
- Khái niệm “đối tượng” có thể trừu tượng và khó hiểu
- Khó phân biệt giữa “class”, “object”, “instance”, “method”…

📌 Tóm tắt hạn chế

Hạn chế	Nguy cơ nếu không xử lý tốt
Số lượng class lớn	Rối rắm, khó quản lý, nặng hiệu suất
Dễ thiết kế sai cấu trúc	Mất lợi thế bảo trì, khó mở rộng
Cần cân bằng coupling/cohesion	Nếu mất cân bằng → hệ thống dễ bị phụ thuộc hoặc phân mảnh
Không dễ tiếp cận cho người mới	Tốn thời gian học, cần ví dụ minh họa rõ ràng

Kết luận

OOAD là công cụ mạnh mẽ để phát triển phần mềm trong thế giới hiện đại – đặc biệt khi kết hợp với phương pháp agile. Tuy nhiên, sức mạnh của OOAD đòi hỏi phải dùng đúng cách. Thiết kế không tốt trong OOAD sẽ khiến hệ thống trở nên phức tạp hơn, chứ không phải đơn giản hơn.

💡 Ghi nhớ: OOAD tốt không đến từ số lượng class hay biểu đồ, mà từ sự hiểu biết sâu sắc về nghiệp vụ, người dùng và khả năng tổ chức hợp lý hệ thống.

Quy trình OOAD đơn giản

OOAD không cần phức tạp – Chỉ cần đúng quy trình

Một trong những hiểu lầm phổ biến là OOAD chỉ dành cho các hệ thống lớn với nhiều biểu đồ UML rối rắm. Thực tế, OOAD có thể bắt đầu rất đơn giản, chỉ với 5 bước rõ ràng và lặp lại.

💡 Mục tiêu của quy trình này: biến yêu cầu người dùng thành hệ thống có cấu trúc hướng đối tượng, có thể phát triển dần và dễ bảo trì.

5 bước trong quy trình OOAD cơ bản

✅ Bước 1: Xác định nhu cầu của người dùng

Thu thập yêu cầu từ người dùng qua:
- Phỏng vấn
- Khảo sát
- Quan sát thực tế
Thể hiện bằng sơ đồ Use Case:
- Ai sử dụng hệ thống?
- Họ cần làm những hành động nào?

✅ Bước 2: Mô tả chi tiết các bước xử lý

Với mỗi Use Case → mô tả luồng xử lý cụ thể qua Activity Diagram
Giúp nhóm hiểu các bước cụ thể cần có, xác định logic nghiệp vụ

✅ Bước 3: Phân rã yêu cầu thành lớp

Phân tích chức năng và dữ liệu → chia hệ thống thành các lớp (class)
Mỗi lớp sẽ:
- Quản lý một phần nghiệp vụ
- Có thuộc tính và hành vi riêng

🔧 Dùng Class Diagram để biểu diễn các lớp và mối quan hệ giữa chúng

✅ Bước 4: Xác định tương tác giữa các thành phần

Sau khi có các class → xác định:
- Class nào tương tác với class nào?
- Giao tiếp như thế nào?
Thể hiện bằng Component Diagram hoặc Sequence Diagram

✅ Bước 5: Lặp lại quy trình

Đây là bước cốt lõi của OOAD và agile:
- Không cố gắng thiết kế hoàn chỉnh ngay từ đầu
- Làm – kiểm thử – cải tiến – làm tiếp
- Thêm yêu cầu mới → quay lại bước 1

Tính lặp (iteration) là cốt lõi của OOAD

“Bạn sẽ không bao giờ đúng ngay từ lần đầu.”

Vì:

Yêu cầu thay đổi liên tục
Người dùng hiểu rõ hơn khi thấy bản mẫu
Nhóm phát triển có thêm kinh nghiệm khi làm

Thiết kế lặp (iterative design) không phải là làm sai → sửa → làm lại, mà là:

Làm một phần nhỏ
Kiểm tra ngay
Hoàn thiện dần toàn bộ hệ thống

Quy tắc thiết kế hướng người dùng

Trong OOAD hiện đại (đặc biệt trong môi trường agile), người dùng là trung tâm của thiết kế. Điều đó có nghĩa:

Không đoán thay người dùng
Phải gặp, phỏng vấn, quan sát, kiểm thử
Thiết kế phải dựa trên ngữ cảnh sử dụng thật

Một hệ thống “đúng kỹ thuật” nhưng “sai người dùng” là một hệ thống thất bại.

Tóm tắt quy trình OOAD đơn giản

Bước	Mô tả ngắn gọn	Ký hiệu / Công cụ hỗ trợ
1	Xác định người dùng và hành động	Use Case Diagram
2	Mô tả chi tiết quy trình	Activity Diagram
3	Chuyển yêu cầu thành lớp	Class Diagram
4	Xác định tương tác giữa các lớp	Component Diagram / Sequence Diagram
5	Lặp lại quy trình nếu có thay đổi mới	Agile iteration

Ghi nhớ:

OOAD không cần bắt đầu từ biểu đồ rối rắm → chỉ cần 5 bước cơ bản là đủ
Lặp lại là sức mạnh – càng lặp, thiết kế càng tốt
Nghe người dùng nhiều hơn là tự suy diễn
Mọi thứ cần hướng tới mục tiêu: dễ phát triển – dễ bảo trì – đúng nhu cầu

Phân rã và trừu tượng hóa

Cách tư duy để giải quyết vấn đề hệ thống phức tạp

🧩 7.1. Phân rã – Cắt nhỏ để dễ kiểm soát

Một trong những kỹ năng nền tảng trong phát triển phần mềm là khả năng phân rã (decomposition).
Khi phải đối mặt với một hệ thống lớn, chúng ta không thể hiểu toàn bộ một lần, mà phải:

Chia nhỏ hệ thống thành các phần hợp lý
Xử lý từng phần một cách riêng biệt
Sau đó tổ chức lại để hoàn thiện tổng thể

💡 Phân rã là hành động chuyển “tổng thể phức tạp” thành “các phần đơn giản hơn để giải quyết”.

🔍 7.2. Tại sao cần phân rã?

Vấn đề nếu không phân rã	Hậu quả
Hệ thống quá lớn, khó hiểu	Dễ gây quá tải nhận thức
Không rõ chức năng từng phần	Khó bảo trì và mở rộng
Các phần bị chồng chéo trách nhiệm	Dễ gây lỗi, thiếu kiểm soát
Không thể làm việc nhóm hiệu quả	Mỗi người không biết nên làm gì

🧠 7.3. Trừu tượng hóa – Nhìn hệ thống ở đúng “tầm cao”

Abstraction (trừu tượng hóa) là một công cụ giúp ta:

Giấu đi chi tiết không cần thiết, chỉ tập trung vào thông tin quan trọng ở mỗi giai đoạn
Nhìn hệ thống dưới các cấp độ khác nhau

Ví dụ:

Cấp độ cao: “Khách hàng đặt hàng”
Cấp độ thấp: Hệ thống kiểm tra kho, xử lý thanh toán, ghi log…

🎯 Thiết kế tốt = phân rã hợp lý + trừu tượng đúng tầm.

🔄 7.4. Phát triển tăng dần (Incremental Development)

Phân rã và trừu tượng hóa không chỉ là hành động một lần, mà là quy trình lặp lại theo chiều sâu:

Ban đầu: chia nhỏ hệ thống thành phần chính
Sau đó: đi sâu từng phần, trừu tượng hóa mức tiếp theo
Cứ thế lặp lại → hệ thống trở nên rõ ràng, dễ hiểu và có cấu trúc rõ ràng

🛠 7.5. Công cụ hỗ trợ phân rã trong OOAD

Công cụ / Kỹ thuật	Mục đích
Use Case Diagram	Chia theo hành động người dùng
Class Diagram	Chia theo thực thể / vai trò
Component Diagram	Chia theo mô-đun hoặc nhóm chức năng
Package Diagram	Nhóm các class có liên quan
Sequence Diagram	Phân rã logic xử lý theo thời gian

📌 7.6. Nguyên tắc khi phân rã

Nguyên tắc	Giải thích
Mỗi phần có trách nhiệm rõ ràng	Một class hoặc module chỉ nên làm một việc
Giữ phần nhỏ, dễ hiểu	Giới hạn số lượng method, biến trong mỗi class
Tránh phụ thuộc lẫn nhau	Thiết kế sao cho các phần có thể hoạt động độc lập tương đối
Mỗi phần có thể kiểm thử riêng	Giúp phát hiện lỗi sớm, dễ bảo trì

Ghi nhớ

Phân rã là cách xử lý hệ thống phức tạp bằng cách chia nhỏ và cô lập
Trừu tượng hóa là cách tư duy theo tầng, không nhìn chi tiết cùng lúc
Đây là cốt lõi của OOAD và phát triển phần mềm hiện đại
Mọi hệ thống phức tạp bạn thấy – đều được xây dựng từ những phần đơn giản hơn bạn tưởng

Sơ đồ Use-Case

Sơ đồ Use-Case là gì?

Sơ đồ Use-Case (Ca sử dụng) là công cụ trực quan giúp mô tả các hành động chính mà người dùng có thể thực hiện với hệ thống. Đây là bước đầu tiên trong quá trình phân tích – giúp trả lời:

Ai là người sử dụng hệ thống?
Họ muốn đạt được điều gì?
Từng nhóm người dùng có thể làm được gì?

💡 Use-Case Diagram là cách thể hiện hệ thống không phải qua công nghệ, mà qua hành vi người dùng.

📌 8.2. Các thành phần chính của sơ đồ Use-Case

Thành phần	Mô tả
Actor (tác nhân)	Là thực thể tương tác với hệ thống (người dùng, hệ thống khác, bộ phận nội bộ…)
Use Case (trường hợp sử dụng)	Là hành động mà actor có thể thực hiện (ví dụ: “Đăng nhập”, “Mua hàng”, “In hóa đơn”)
Đường kết nối	Biểu diễn mối liên hệ giữa actor và hành động họ có thể làm
Sơ đồ tổng thể	Không thể hiện chi tiết quy trình, chỉ vẽ “bức tranh lớn” của toàn bộ hệ thống

🧍‍♂️ 8.3. Actor là ai?

Có thể là người dùng thật (Khách hàng, Nhân viên…)
Hoặc hệ thống bên ngoài tương tác với hệ thống của bạn (Ví dụ: cổng thanh toán, API đối tác…)

→ Quan trọng: actor không nằm bên trong hệ thống, mà là tác nhân từ bên ngoài

📝 8.4. Cách biểu diễn sơ đồ Use-Case

Ký hiệu	Ý nghĩa
Hình người que	Actor
Hình oval	Use Case
Đường kẻ nối	Mối quan hệ giữa Actor và Use Case
`<<uses>>`	Một hành động dùng hành động con
`<<extends>>`	Một hành động mở rộng hành vi từ hành động khác

📈 8.5. Các đặc điểm quan trọng của sơ đồ Use-Case

Không thể hiện thứ tự thực hiện các hành động
- Tức là không chỉ rõ hành động nào xảy ra trước, sau
Không thể hiện chi tiết logic nghiệp vụ
- Chỉ mô tả “Ai có thể làm gì?”
Giúp xây dựng giao diện người dùng
- Mỗi Use Case nên có một chức năng rõ ràng trong UI

🧠 8.6. Lợi ích của sơ đồ Use-Case

Lợi ích	Mô tả
Giao tiếp dễ dàng	Giúp khách hàng, lập trình viên, quản lý cùng hiểu hệ thống
Dễ phân tích và kiểm thử	Từ Use Case → tạo kịch bản kiểm thử thực tế
Là nền tảng để thiết kế lớp	Từ Use Case → xác định các class cần có
Tập trung vào người dùng	Thiết kế tính năng đúng nhu cầu, không lan man

📌 8.7. Các lưu ý khi xây dựng sơ đồ Use-Case

Đơn giản hóa
- Chỉ thể hiện hành động quan trọng và đại diện
Không cần thể hiện toàn bộ hệ thống
- Có thể vẽ nhiều sơ đồ nhỏ cho từng nhóm chức năng
Không mô tả logic bên trong mỗi hành động
- Sẽ xử lý ở bước sau (Activity diagram, Sequence diagram…)

🔧 8.8. Kỹ thuật mở rộng sơ đồ

Khi một hành động gồm nhiều bước con rõ ràng, dùng <<uses>> để chia tách
Khi có hành động phụ thuộc, hoặc mở rộng từ một hành động khác, dùng <<extends>> để mô tả

👉 Những mở rộng này không bắt buộc – chỉ dùng khi thực sự cần, để giữ sơ đồ rõ ràng.

🧭 8.9. Từ sơ đồ Use-Case đến thiết kế hệ thống

Mỗi Use Case → có thể dẫn đến 1 hoặc nhiều Class, Sequence, Activity Diagram
Đây là cầu nối giữa yêu cầu người dùng và thiết kế kỹ thuật

Ghi nhớ:

Sơ đồ Use-Case giúp nhìn hệ thống từ mắt người dùng
Đơn giản nhưng cực kỳ quan trọng để phân tích đúng, thiết kế chuẩn
Chỉ nên thể hiện những hành động có ảnh hưởng đến hệ thống
Là bước khởi đầu của phân tích hướng đối tượng – nếu sai, sẽ kéo theo sai toàn bộ quy trình

Event Decomposition – phân tích sự kiện

9.1. Phân tích sự kiện là gì?

Event Decomposition (phân tích sự kiện) là một kỹ thuật có hệ thống để xác định những hành động nào cần được đưa vào sơ đồ Use-Case, bằng cách đặt câu hỏi:

“Điều gì đang xảy ra xung quanh hệ thống mà đòi hỏi hệ thống phải phản ứng lại?”

🧠 9.2. Tư duy hộp đen – Không nhìn vào bên trong hệ thống

Hãy hình dung hệ thống như một chiếc hộp đen:
- Bạn không cần biết nó hoạt động bên trong ra sao
- Bạn chỉ tập trung vào các sự kiện “đập vào” nó từ bên ngoài
Mỗi sự kiện đó → là ứng viên cho một Use Case

🔍 9.3. Các loại sự kiện cần phân tích

Có 3 loại sự kiện chính có thể kích hoạt hành vi từ hệ thống:

Loại sự kiện	Mô tả	Ví dụ
External Events	Tác động từ bên ngoài vào hệ thống	Khách hàng đặt hàng, nhân viên cập nhật hồ sơ
Temporal Events	Xảy ra do thời gian, lịch trình	Gửi email hàng tuần, tính lương cuối tháng
State Events	Xảy ra khi dữ liệu trong hệ thống đạt trạng thái nhất định	Tồn kho xuống thấp → gửi cảnh báo mua thêm

🧍‍♂️ 9.4. External Events – Sự kiện do tác nhân bên ngoài gây ra

Là những hành động mà người dùng hoặc hệ thống bên ngoài chủ động gửi yêu cầu vào hệ thống
Ví dụ:
- Người dùng mua hàng
- Quản trị viên cập nhật sản phẩm
- Hệ thống đối tác gọi API

→ Mỗi tương tác như vậy có thể trở thành 1 Use Case

⏰ 9.5. Temporal Events – Sự kiện theo thời gian

Các hành động tự động xảy ra theo lịch hoặc sau một khoảng thời gian nhất định
Có thể được:
- Cài đặt bởi người dùng
- Kích hoạt bởi hệ thống

Ví dụ:

Gửi báo cáo doanh số mỗi tuần
Tự động khóa tài khoản sau 30 ngày không hoạt động
Trừ phí sau 10 phút mua hàng

📊 9.6. State Events – Sự kiện dựa trên trạng thái hệ thống

Là các sự kiện nảy sinh từ sự thay đổi dữ liệu nội tại trong hệ thống
Hệ thống tự phát hiện trạng thái đạt ngưỡng → sinh ra hành động

Ví dụ:

Hàng tồn kho dưới 10 → tạo phiếu đề nghị mua
Tài khoản hết tiền → từ chối giao dịch tiếp theo

✅ Thường là kết quả gián tiếp của các sự kiện external hoặc temporal

📝 9.7. Cách áp dụng event decomposition

Đọc kỹ yêu cầu bài toán hoặc phỏng vấn người dùng
Gạch ra mọi sự kiện có thể xảy ra
Phân loại chúng theo 3 nhóm trên
Lọc lại những sự kiện có tác động đến hệ thống
Gộp/tách nếu cần để tránh quá chi tiết hoặc quá sơ sài
Chuyển thành danh sách Use Case ban đầu

📌 9.8. Lưu ý khi chọn sự kiện

Nguyên tắc lựa chọn sự kiện hợp lý	Lý do
Chỉ chọn sự kiện có ảnh hưởng trực tiếp tới hệ thống	Tránh vẽ Use Case “vô dụng”
Bỏ qua các sự kiện “chuẩn bị” hoặc “kết thúc”	Vì chúng không làm hệ thống phản hồi
Duy trì mức độ chi tiết nhất quán	Dễ hiểu, tránh lệch logic giữa các sơ đồ

📋 9.9. Ví dụ minh họa: hệ thống thương mại điện tử

Actor	Sự kiện đề xuất	Use Case tương ứng
Customer	Xem sản phẩm theo danh mục	`Tìm sản phẩm`
Customer	Thêm sản phẩm vào giỏ hàng	`Thêm vào giỏ`
Admin	Sửa thông tin sản phẩm	`Cập nhật sản phẩm`
Hệ thống	Hết ngày 30 hàng tháng	`Tính lương`
Hệ thống	Sản phẩm hết hàng	`Gửi cảnh báo nhập hàng`

Ghi nhớ:

Event Decomposition là kỹ thuật thực tế, dễ áp dụng
Là bước đầu tiên để xây dựng Use Case đúng – đủ – có ích
Giúp chuyển yêu cầu trừu tượng thành danh sách hành vi cụ thể
Cực kỳ phù hợp với phương pháp phát triển phần mềm linh hoạt (agile)

Agile OOAD

0.1. OOAD và Agile – Hai tư tưởng, một mục tiêu

OOAD (Phân tích & Thiết kế Hướng Đối tượng) giúp chúng ta tổ chức phần mềm rõ ràng, có cấu trúc và dễ mở rộng.

Agile (Phát triển phần mềm linh hoạt) giúp chúng ta thích ứng nhanh, làm theo vòng lặp nhỏ, phản hồi sớm.

💡 Khi kết hợp, ta có Agile OOAD – vừa có thiết kế bài bản, vừa có khả năng điều chỉnh linh hoạt theo thay đổi.

🧭 10.2. Sơ đồ Use-Case trong Agile OOAD

Trong môi trường agile, Use-Case diagram không chỉ là công cụ kỹ thuật, mà còn là phương tiện giao tiếp hiệu quả:

Dễ hiểu với cả người không chuyên
Làm rõ ai làm gì trong hệ thống
Dễ chỉnh sửa theo phản hồi mới
Có thể tạo ngay trong buổi họp khách hàng

👉 Use-Case diagram là “ngôn ngữ chung” giữa khách hàng và nhóm phát triển.

🧠 10.3. Ghi nhớ: Use-Case để phục vụ giao tiếp, không phải để “trang trí” tài liệu

Không cần mỗi sơ đồ phải dùng đủ mọi cú pháp <<uses>>, <<extends>>…
Không cần biểu đồ phải hoàn hảo, đầy đủ mọi tình huống
Chỉ cần đủ rõ để truyền đạt đúng – là đủ tốt

🛠 10.4. Tinh thần Agile trong OOAD

Nguyên tắc Agile	Ứng dụng vào OOAD
Cá nhân & tương tác hơn quy trình & công cụ	Use-Case diagram để hỗ trợ đối thoại, không để “trưng bày”
Phần mềm chạy được hơn tài liệu đầy đủ	Thiết kế sơ đồ nào dùng được ngay – thì mới cần thiết
Phản hồi sớm & thường xuyên	Mỗi iteration đều điều chỉnh sơ đồ, class, use-case
Linh hoạt theo thay đổi	Không khóa cứng sơ đồ – sẵn sàng sửa khi có yêu cầu mới

📉 10.5. Đừng “thờ phụng sơ đồ”

❌ Sai lầm phổ biến: Nghĩ rằng phải có đủ sơ đồ UML thì thiết kế mới “chuyên nghiệp”.

Thực tế trong Agile:

Chỉ giữ những sơ đồ cần thiết để truyền đạt
Bỏ những gì không mang lại giá trị thực
Không vẽ class diagram nếu class đó dễ hiểu qua code
Không cần sequence diagram nếu logic đã rõ từ Use Case

✅ 10.6. Agile OOAD = Thiết kế đủ tốt, sẵn sàng thay đổi

Làm từng phần nhỏ → kiểm thử → cải tiến → làm tiếp
Sơ đồ và thiết kế phải dễ cập nhật
Người dùng phải được tham gia xuyên suốt, không chỉ lúc đầu

🎯 Tài liệu ít thôi, nhưng mỗi cái đều có lý do tồn tại.

📌 10.7. Khi nào nên tạo sơ đồ?

Trường hợp	Có nên tạo sơ đồ?
Tính năng mới, chưa rõ luồng logic	✅ Nên có Use Case / Activity
Class phức tạp, nhiều quan hệ	✅ Cần Class Diagram
Chức năng nhỏ, team hiểu rõ	❌ Có thể bỏ qua
Đã có flow rõ ràng trong code	❌ Không cần vẽ thêm

Ghi nhớ:

Agile OOAD không chống lại sơ đồ – mà chống lại việc vẽ sơ đồ vô nghĩa
Sơ đồ Use-Case là công cụ giao tiếp, không phải để “làm đẹp tài liệu”
OOAD có sức mạnh tổ chức – Agile có sức mạnh thích nghi → kết hợp là lựa chọn tối ưu
Trong môi trường linh hoạt, làm đủ – đúng lúc – đúng mục tiêu là tốt nhất

Thuật ngữ	Định nghĩa
Use Case Diagram	Sơ đồ thể hiện tương tác mức cao giữa hệ thống và actor
Event Decomposition	Phân tích sự kiện để xác định chức năng hệ thống cần có
Actor	Thực thể tương tác với hệ thống (người dùng hoặc hệ thống phụ)