Now Reading: Mục đích và tầm quan trọng của việc xác định các tác nhân trong một phương pháp tiếp cận dựa trên trường hợp sử dụng

1
  • 01

    Mục đích và tầm quan trọng của việc xác định các tác nhân trong một phương pháp tiếp cận dựa trên trường hợp sử dụng

Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLpt_PTru_RUzh_CNzh_TW

Mục đích và tầm quan trọng của việc xác định các tác nhân trong một phương pháp tiếp cận dựa trên trường hợp sử dụng

UMLYesterday

Trong kỹ thuật phần mềm, đặc biệt là trong phương pháp phát triển dựa trên trường hợp sử dụng, việc xác địnhcác tác nhânlà một bước nền tảng và quan trọng. Các tác nhân đóng vai trò như cầu nối giữa hệ thống đang được phát triển và các thực thể bên ngoài tương tác với nó. Việc xác định và hiểu rõ các tác nhân một cách chính xác giúp các nhóm thiết kế các hệ thống lấy người dùng làm trung tâm, đầy đủ về chức năng và phù hợp với nhu cầu thực tế.

What is Use Case Diagram?

Bài viết toàn diện này khám phámục đích của việc xác định các tác nhân,các loại tác nhân (con người và phi con người), vai trò và trách nhiệm của họvai trò và trách nhiệm, cách quá trình này hỗ trợ các lĩnh vực khác nhau trong phát triển phần mềm, và cung cấpcác khái niệm chính, hướng dẫn và mẹo thực tếđể đạt được thành công.

🔍 1. Mục đích của việc xác định các tác nhân

Việc xác định các tác nhân không chỉ là một nhiệm vụ ban đầu—đó là một hoạt động chiến lược định hình toàn bộ vòng đời phát triển. Các mục đích chính bao gồm:

✅ 1. Xác định ranh giới hệ thống

Các tác nhân giúp xác định những gì nằm bên trong hệ thống (phần mềm) và những gì nằm bên ngoài. Sự rõ ràng này ngăn chặn hiện tượng mở rộng phạm vi và đảm bảo nhóm tập trung vào lĩnh vực đúng.

Ví dụ:Trong một hệ thống ngân hàng, khách hàng là một tác nhân bên ngoài hệ thống, trong khi mô-đun xử lý giao dịch là một phần của hệ thống.

✅ 2. Ghi lại các tương tác thực tế

Các tác nhân đại diện cho người dùng thực tế hoặc các hệ thống tương tác với phần mềm. Bằng cách xác định họ, các nhóm mô hình hóa các trường hợp sử dụng thực tế, phản ánh cách hệ thống sẽ được sử dụng trong thực tế.

✅ 3. Thúc đẩy việc phát hiện trường hợp sử dụng

Mỗi trường hợp sử dụng thường liên quan đến một hoặc nhiều tác nhân. Việc biết rõ các tác nhân giúp phát hiện đầy đủ các yêu cầu chức năng. Nếu bạn không biết ai đang sử dụng hệ thống, bạn sẽ không thể xác định được họ cần làm gì.

✅ 4. Cải thiện giao tiếp và hợp tác

Các tác nhân cung cấp một ngôn ngữ chung cho các bên liên quan, nhà phát triển, người kiểm thử và chuyên gia phân tích kinh doanh. Chúng giúp việc thảo luận về tính năng, xác minh yêu cầu và đồng thuận về kỳ vọng trở nên dễ dàng hơn.

✅ 5. Hỗ trợ lập kế hoạch kiểm thử và xác thực

Người kiểm thử có thể sử dụng các vai trò người dùng để thiết kế các kịch bản kiểm thử. Ví dụ, một vai trò người dùng “Khách hàng” có thể cần thực hiện các hành động “Đăng nhập”, “Chuyển tiền” và “Xem sao kê” — mỗi hành động này trở thành một trường hợp kiểm thử.

🧍‍♂️ 2. Các loại người dùng: Người và Không phải người

Các người dùng được phân loại rộng rãi thành hai loại:Người dùng ngườivàNgười dùng không phải người.

🧑‍💼 A. Người dùng người

Đây là những cá nhân tương tác trực tiếp với hệ thống.

Ví dụ:

  • Khách hàng

  • Quản trị viên

  • Nhân viên

  • Quản lý

  • Đại diện hỗ trợ

  • Bệnh nhân (trong hệ thống y tế)

Đặc điểm:

  • Có mục tiêu và động cơ.

  • Tương tác thông qua giao diện người dùng, biểu mẫu hoặc lệnh thoại.

  • Có thể có các vai trò với quyền hạn khác nhau (ví dụ: quản trị viên so với người dùng thường).

✅ Mẹo:Sử dụng tên gọi dựa trên vai trò (ví dụ: “Khách hàng đã đăng ký” thay vì “Người dùng”) để tránh hiểu nhầm.

🤖 B. Người dùng không phải người

Đây là các hệ thống bên ngoài, thiết bị hoặc quy trình tự động tương tác với phần mềm.

Ví dụ:

  • Máy ATM

  • Cổng thanh toán (ví dụ: Stripe, PayPal)

  • Máy chủ email

  • API Dịch vụ Thời tiết

  • Cảm biến IoT

  • Hệ thống Cổ điển (ví dụ: cơ sở dữ liệu cũ)

Đặc điểm:

  • Không phải con người, nhưng chúng khởi tạo hoặc phản hồi các hành động của hệ thống.

  • Thường đại diện cho các điểm tích hợp hoặc dịch vụ bên ngoài.

  • Có thể kích hoạt các trường hợp sử dụng một cách tự động.

✅ Ví dụ: Trong một hệ thống thương mại điện tử, “Cổng thanh toán” là một tác nhân xử lý các giao dịch thanh toán và gửi xác nhận trở lại hệ thống.

⚠️ Sai lầm phổ biến: Xem một thành phần hệ thống như một phần của hệ thống thay vì một tác nhân bên ngoài. Luôn tự hỏi: “Tác nhân này có khởi tạo một trường hợp sử dụng không?”

🎯 3. Vai trò và Trách nhiệm của Tác nhân

Hiểu rõ vai trò của tác nhânvai trò và trách nhiệmsẽ giúp hiểu sâu sắc hơn về cách họ sử dụng hệ thống và những gì họ mong đợi.

🔹 Vai trò: Tác nhân là ai

  • Mô tả người hoặc hệ thống trong bối cảnh cụ thể.

  • Thường liên quan đến một chức năng công việc hoặc loại hệ thống.

Ví dụ: “Nhân viên cho vay” so với “Khách hàng”

🔹 Trách nhiệm: Tác nhân làm gì

  • Các hành động mà tác nhân thực hiện trong hệ thống.

  • Mục tiêu mà họ hướng tới.

  • Dữ liệu mà họ cung cấp hoặc nhận.

Ví dụ: Tác nhân “Khách hàng” trong hệ thống Thương mại điện tử

Trách nhiệm Mô tả
Duyệt sản phẩm Xem danh sách và chi tiết sản phẩm
Thêm vào giỏ hàng Chọn các mục và thêm chúng vào giỏ hàng
Thanh toán Nhập thông tin vận chuyển và thanh toán
Theo dõi đơn hàng Xem trạng thái đơn hàng và cập nhật giao hàng

✅ Thực hành tốt nhất: Tài liệu trách nhiệm của người tham gia trong bảng hoặc chú thích sơ đồ trường hợp sử dụng để tăng tính rõ ràng.

🛠️ 4. Cách xác định người tham gia hỗ trợ các lĩnh vực phát triển

Việc xác định người tham gia phù hợp ảnh hưởng đến nhiều giai đoạn trong vòng đời phát triển phần mềm:

📌 1. Thu thập yêu cầu

  • Giúp xác định tất cả các nhóm người dùng và hệ thống bên ngoài.

  • Ngăn ngừa việc bỏ sót các nhu cầu quan trọng của người dùng.

  • Khuyến khích sự tham gia của các bên liên quan từ sớm.

📌 2. Mô hình hóa trường hợp sử dụng

  • Mỗi trường hợp sử dụng được kích hoạt bởi một người tham gia.

  • Cho phép khám phá hệ thống các yêu cầu chức năng.

  • Giúp tránh các trường hợp sử dụng trùng lặp hoặc chồng chéo.

📌 3. Thiết kế hệ thống và kiến trúc

  • Hướng dẫn thiết kế giao diện (UI/UX).

  • Ảnh hưởng đến bảo mật và kiểm soát truy cập (ví dụ: quản trị viên so với khách).

  • Xác định các điểm tích hợp (ví dụ: API bên thứ ba).

📌 4. Kiểm thử và xác thực

  • Các nhà kiểm thử sử dụng các vai trò người dùng để tạo các kịch bản kiểm thử.

  • Đảm bảo tất cả các hành trình người dùng đều được bao phủ.

  • Hỗ trợ tạo kịch bản kiểm thử tự động.

📌 5. Tài liệu người dùng và đào tạo

  • Các định nghĩa rõ ràng về người dùng giúp soạn thảo tài liệu hướng dẫn người dùng và tài liệu đào tạo.

  • Giải thích ai có thể làm gì trong hệ thống.

📌 6. Phát triển linh hoạt và phát triển theo từng giai đoạn

  • Trong Agile, các người dùng giúp xác định các câu chuyện người dùng (ví dụ: “Là một khách hàng, tôi muốn đặt lại mật khẩu của mình”).

  • Hỗ trợ ưu tiên danh sách công việc dựa trên nhu cầu người dùng.

🧩 5. Các khái niệm chính trong việc xác định người dùng

✅ 1. Người dùng ≠ Người dùng

  • Một người dùng là một cá nhân sử dụng hệ thống.

  • Một người dùng là bất kỳ thực thể nào tương tác với hệ thống.

  • Một người dùng có thể đảm nhận nhiều vai trò khác nhau (ví dụ: một quản lý đồng thời là khách hàng).

❌ Sai: “Người dùng” là người dùng duy nhất.
✅ Đúng: “Khách hàng,” “Quản lý,” “Quản trị viên hệ thống”

✅ 2. Người dùng là một thực thể bên ngoài

  • Các người dùng nằm bên ngoài ranh giới hệ thống.

  • Không bao gồm các thành phần nội bộ (ví dụ: “Cơ sở dữ liệu” không phải là người dùng—trừ khi đó là một hệ thống bên ngoài).

✅ 3. Một người dùng, nhiều trường hợp sử dụng

  • Một người dùng duy nhất có thể tham gia vào nhiều trường hợp sử dụng.

  • Ví dụ: Một “Khách hàng” có thể “Duyệt,” “Thêm vào giỏ hàng,” “Thanh toán” và “Đánh giá sản phẩm.”

✅ 4. Trường hợp sử dụng so với Người dùng

  • Use case mô tả một hành động hoặc mục tiêu.

  • Actors kích hoạt hoặc tham gia vào use case.

✅ Use Case: “Xử lý thanh toán”
✅ Actor: “Khách hàng” và “Cổng thanh toán”

📝 6. Hướng dẫn xác định Actor hiệu quả

Tuân theo các thực hành tốt nhất sau đây để đảm bảo việc xác định Actor chính xác và có ý nghĩa:

✅ 1. Bắt đầu bằng các cuộc phỏng vấn người liên quan

  • Trò chuyện với các nhà phân tích kinh doanh, người dùng cuối và người sở hữu hệ thống.

  • Hỏi: “Ai sử dụng hệ thống này? Ai gửi dữ liệu vào nó? Ai nhận đầu ra?”

✅ 2. Sử dụng câu hỏi “Ai khởi tạo?”

  • Với mỗi use case tiềm năng, hãy hỏi: “Ai khởi tạo tương tác này?”

  • Câu trả lời có khả năng là actor.

✅ 3. Tránh trừu tượng hóa quá mức

  • Đừng sử dụng các thuật ngữ mơ hồ như “Người dùng,” “Hệ thống,” hoặc “Người.”

  • Hãy cụ thể: “Khách hàng đã đăng ký,” “API bên thứ ba,” “Thiết bị di động.”

✅ 4. Xem xét tất cả các điểm tương tác

  • Suy nghĩ vượt ra ngoài người dùng trực tiếp: cảm biến, cron jobs, dịch vụ bên ngoài.

  • Ví dụ: Một cảm biến thời tiết có thể kích hoạt use case “Gửi cảnh báo.”

✅ 5. Sử dụng bài kiểm tra “Nó có phải là con người không?”

  • Nếu nó không phải là con người, hãy hỏi: “Nó có gửi hoặc nhận tin nhắn đến hệ thống không?”

  • Nếu có → đó là một actor phi con người.

✅ 6. Xác minh bằng sơ đồ use case

  • Vẽ sơ đồ use case và kiểm tra xem tất cả các actor có được biểu diễn hay không.

  • Đảm bảo không có use case nào “không có actor.”

💡 7. Mẹo và Thủ thuật để Thành công

Mẹo Giải thích
Sử dụng tên dựa trên vai trò Thay vì dùng “Người dùng”, hãy dùng “Khách hàng”, “Quản trị viên”, “Nhà cung cấp” — rõ ràng và dễ hành động hơn.
Sắp xếp các tác nhân theo vai trò Tạo một danh sách “Tác nhân” với mô tả, trách nhiệm và quyền hạn.
Tận dụng các nhân vật đại diện Xây dựng các nhân vật đại diện cho các tác nhân chính để thấu hiểu mục tiêu và điểm đau của họ.
Kiểm tra xem có tác nhân nào bị thiếu không Hỏi: “Điều gì sẽ xảy ra nếu hệ thống lỗi? Ai sẽ được thông báo?” → Thường tiết lộ các tác nhân ẩn.
Sử dụng quy tắc “Bên ngoài hệ thống” Nếu điều gì đó nằm bên trong hệ thống, thì nó không phải là một tác nhân.
Lặp lại và tinh chỉnh Xem xét lại các tác nhân trong mỗi giai đoạn phát triển. Các tính năng mới có thể tạo ra các tác nhân mới.
Tài liệu hóa các tác nhân trong một bảng tham khảo Duy trì một tài liệu sống với chi tiết về tác nhân để tham khảo trong tương lai.

🎯 Ví dụ thực tế: Hệ thống ngân hàng trực tuyến

Tác nhân:

  1. Khách hàng – xem tài khoản, chuyển tiền

  2. Nhân viên ngân hàng – xử lý các đơn vay

  3. Máy ATM – gửi yêu cầu rút tiền

  4. Hệ thống phát hiện gian lận – giám sát giao dịch và đánh dấu các hoạt động đáng ngờ

  5. Cổng thanh toán – xử lý thanh toán bằng thẻ tín dụng

Trường hợp sử dụng: “Rút tiền mặt”

  • Người tham gia: Khách hàng và máy ATM

  • Tương tác: Khách hàng đưa thẻ vào → ATM gửi yêu cầu → Hệ thống xác minh → Tiền được giải ngân

✅ Máy ATM là người tham gia vì nó khởi tạo tương tác.

🚫 Những sai lầm phổ biến cần tránh

Sai lầm Tại sao lại xấu Cách khắc phục
Xem các module nội bộ như người tham gia Vi phạm khái niệm ranh giới hệ thống Hỏi: “Điều này nằm bên trong hay bên ngoài hệ thống?”
Sử dụng các thuật ngữ mơ hồ như “Người dùng” Dẫn đến sự mơ hồ và thiếu yêu cầu Sử dụng các vai trò cụ thể: “Khách hàng”, “Nhà cung cấp”
Quên mất các người tham gia không phải con người Bỏ sót các tích hợp và tự động hóa Hãy nghĩ đến các API, cảm biến, công việc định kỳ (cron jobs)
Giả định một người tham gia cho mỗi trường hợp sử dụng Bỏ qua các tương tác phức tạp Cho phép nhiều người tham gia cho mỗi trường hợp sử dụng
Không xem xét lại người tham gia trong quá trình phát triển Người tham gia có thể thay đổi theo các tính năng mới Xem xét lại người tham gia trong các buổi lập kế hoạch sprint và tổng kết

✅ Kết luận

Việc xác định người tham gia trong phương pháp dựa trên trường hợp sử dụng không chỉ là một thủ tục hình thức—đó là một cốt lõi chiến lược của việc phát triển phần mềm thành công. Bằng cách xác định rõ ai tương tác với hệ thống (cả con người lẫn không phải con người), các đội sẽ thu được:

  • Hiểu sâu sắc hơn về nhu cầu người dùng

  • Yêu cầu đầy đủ và chính xác hơn

  • Thiết kế và kiến trúc hệ thống tốt hơn

  • Kiểm thử và tài liệu được cải thiện

  • Sự đồng thuận mạnh mẽ hơn từ các bên liên quan

Khi được thực hiện đúng cách, việc xác định người dùng (actor) sẽ biến những ý tưởng trừu tượng thành những thông tin cụ thể và có thể hành động. Nó đảm bảo phần mềm không chỉ hoạt động—mà còn giải quyết các vấn đề thực tế cho con người và hệ thống thực tế.

📚 Đọc thêm & Công cụ

  • Sách:

    • Mô hình hóa trường hợp sử dụng bởi Alistair Cockburn

    • Viết các trường hợp sử dụng hiệu quả bởi Alistair Cockburn

  • Công cụ:

    • Visual Paradigm (dùng cho sơ đồ trường hợp sử dụng)

    • Lucidchart / Draw.io (vẽ sơ đồ)

    • Jira + Confluence (dùng cho tài liệu về người dùng và trường hợp sử dụng)

  • Phương pháp:

    • Agile (câu chuyện người dùng được rút ra từ người dùng)

    • Thiết kế hướng miền (DDD) – người dùng là một phần của mô hình miền

🌟 Suy nghĩ cuối cùng:
“Bạn không xây dựng phần mềm cho hệ thống—bạn xây dựng nó cho con người, và những hệ thống phục vụ họ. Người dùng là bước đầu tiên để hiểu ai là những con người và hệ thống đó.”

Bằng cách thành thạo việc xác định người dùng, bạn đã đặt nền tảng cho một hệ thống không chỉ hoạt động được—mà còn thực sự có giá trị.

Related Posts

Recent Comments

Không có bình luận nào để hiển thị.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...