Phân tích thiết kế hệ thống thông tin quản lý

Bài 13. Use Case Diagram – Bản đồ của hệ thống, không phải toàn bộ hệ thống

“Một bản đồ giúp bạn biết phải đi đâu. Nhưng muốn đến đích, bạn vẫn phải hiểu con đường.”

Mụ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 vai trò thực sự của Use Case Diagram.
  • Xác định Actor và Use Case trên sơ đồ.
  • Hiểu các mối quan hệ phổ biến giữa các Use Case.
  • Biết khi nào nên và không nên sử dụng Use Case Diagram.

1. Vì sao cần Use Case Diagram?

Sau bài trước, chúng ta đã đặc tả từng Use Case.

Ví dụ.

  • Đăng nhập
  • Đăng ký học phần
  • Hủy học phần
  • Xem thời khóa biểu
  • Thanh toán học phí
  • Xem lịch sử thanh toán
  • Cập nhật hồ sơ

Nếu hệ thống có:

  • 30 Use Case
  • 60 Use Case
  • 150 Use Case

thì việc đọc từng bản đặc tả sẽ rất khó.

Lúc này chúng ta cần một cách nhìn nhanh:

  • Hệ thống có những chức năng nào?
  • Ai sử dụng từng chức năng?
  • Những chức năng nào liên quan với nhau?

Đó chính là vai trò của Use Case Diagram.

2. Use Case Diagram là gì?

Use Case Diagram là sơ đồ mô tả:

  • Các Actor tương tác với hệ thống.
  • Các Use Case mà hệ thống cung cấp.
  • Các mối quan hệ giữa Actor và Use Case, hoặc giữa các Use Case.

Điều quan trọng cần nhớ:

Use Case Diagram không mô tả quy trình xử lý.

Nó cũng không mô tả:

  • cơ sở dữ liệu,
  • giao diện,
  • thuật toán,
  • trình tự thực hiện.

Nó chỉ trả lời:

Ai sử dụng hệ thống và họ sử dụng những chức năng nào?

3. Thành phần của Use Case Diagram

Một Use Case Diagram cơ bản gồm ba thành phần.

Actor

Actor là vai trò tương tác với hệ thống.

Ví dụ:

  • Sinh viên
  • Giảng viên
  • Quản trị viên
  • Thủ thư
  • Khách hàng

Lưu ý:

Actor không nhất thiết là con người.

Một hệ thống thanh toán, hệ thống email hoặc dịch vụ xác thực bên ngoài cũng có thể là Actor nếu chúng tương tác với hệ thống của bạn.

Use Case

Use Case biểu diễn mục tiêu mà Actor muốn đạt được.

Ví dụ:

  • Đăng nhập
  • Đăng ký học phần
  • Thanh toán học phí
  • Mượn sách
  • Trả sách

Tên Use Case nên bắt đầu bằng động từ và phản ánh mục tiêu nghiệp vụ.

System Boundary

System Boundary là khung bao quanh các Use Case.

Nó giúp trả lời câu hỏi:

Điều gì thuộc phạm vi của hệ thống?

Những Actor luôn nằm bên ngoài ranh giới này.

Các Use Case luôn nằm bên trong.

Đây là chi tiết nhỏ nhưng rất quan trọng khi xây dựng sơ đồ.

4. Mối quan hệ giữa Actor và Use Case

Đây là quan hệ đơn giản nhất.

Ví dụ:

Sinh viên
     |
     |—— Đăng nhập
     |
     |—— Đăng ký học phần
     |
     |—— Xem thời khóa biểu

Ý nghĩa:

Sinh viên có thể thực hiện các Use Case trên.

Đường nối này không thể hiện trình tự, không thể hiện luồng dữ liệu, và cũng không thể hiện quyền truy cập chi tiết.

5. Mối quan hệ giữa các Use Case

Ngoài quan hệ với Actor, các Use Case còn có thể liên hệ với nhau.

Trong học phần này, chúng ta tập trung vào hai quan hệ quan trọng nhất:

«include»

Sử dụng khi một Use Case luôn phải thực hiện một Use Case khác.

Ví dụ:

Đăng ký học phần
        |
     <<include>>
        |
Kiểm tra điều kiện tiên quyết

Mỗi lần đăng ký học phần đều phải kiểm tra điều kiện tiên quyết.

Do đó, hành vi này được tách thành một Use Case dùng chung.

Nguyên tắc:

  • Luôn xảy ra.
  • Mang tính tái sử dụng.
  • Giúp tránh lặp lại logic trong nhiều Use Case.

«extend»

Sử dụng khi một hành vi chỉ xảy ra trong một số điều kiện nhất định.

Ví dụ:

Thanh toán học phí
        |
      <<extend>>
        |
Xuất hóa đơn điện tử

Nếu người học yêu cầu hóa đơn, hệ thống sẽ thực hiện thêm Use Case này.

Nếu không, Use Case chính vẫn hoàn thành bình thường.

Nguyên tắc:

  • Không phải lúc nào cũng xảy ra.
  • Phụ thuộc vào điều kiện hoặc lựa chọn.

6. Khi nào nên dùng «include» và «extend»?

Đây là phần khiến sinh viên nhầm lẫn nhiều nhất.

Một cách ghi nhớ đơn giản:

«include»

Muốn hoàn thành Use Case A thì bắt buộc phải thực hiện B.

«extend»

Use Case A đã hoàn chỉnh, nhưng trong một số trường hợp có thể phát sinh thêm B.

Ví dụ:

Đăng nhập

↓

Kiểm tra tài khoản

→ luôn xảy ra

⇒ include

Thanh toán

↓

Xuất hóa đơn

→ chỉ khi người dùng yêu cầu

⇒ extend

7. Những gì Use Case Diagram không thể hiện

Đây là điểm rất quan trọng.

Use Case Diagram không trả lời:

  • Các bước thực hiện theo thứ tự nào?
  • Hệ thống xử lý dữ liệu ra sao?
  • Màn hình gồm những trường nào?
  • Điều gì xảy ra nếu có lỗi?

Những nội dung đó đã được mô tả trong:

  • Use Case Specification
  • Activity Diagram
  • Sequence Diagram

Đừng cố đưa tất cả thông tin vào một sơ đồ.

Sai lầm thường gặp

Vẽ quá nhiều Use Case trên một sơ đồ

Một sơ đồ có 80–100 Use Case sẽ rất khó đọc.

Hãy chia theo từng phân hệ hoặc nhóm nghiệp vụ.

Dùng tên kỹ thuật

Ví dụ:

  • CRUD Student
  • Update Database
  • Insert Record

Đây không phải ngôn ngữ nghiệp vụ.

Lạm dụng include và extend

Không phải hai Use Case nào có liên quan cũng cần include hoặc extend.

Chỉ sử dụng khi thật sự có mối quan hệ như đã trình bày.

Xem Use Case Diagram là tài liệu đầy đủ

Use Case Diagram chỉ là bản tóm tắt.

Muốn hiểu chi tiết, cần đọc Use Case Specification.

Tóm tắt

Use Case Diagram giúp mô tả:

  • Ai sử dụng hệ thống.
  • Hệ thống cung cấp những chức năng nào.
  • Các chức năng có liên hệ gì với nhau.

Nó là bản đồ tổng quan, không phải tài liệu mô tả chi tiết.

Hãy nhớ:

Một Use Case Diagram đẹp không phải là sơ đồ có nhiều ký hiệu UML, mà là sơ đồ giúp người đọc hiểu nhanh phạm vi và chức năng của hệ thống.

Deliverable

Xây dựng Use Case Diagram cho hệ thống của bạn.

Yêu cầu:

  • Có tối thiểu 5 Actor.
  • Có tối thiểu 15 Use Case.
  • Xác định rõ System Boundary.
  • Sử dụng «include» và «extend» khi phù hợp.
  • Không đưa giao diện hoặc chi tiết xử lý vào sơ đồ.

Sau khi hoàn thành, hãy tự trả lời:

  1. Một stakeholder mới có hiểu được phạm vi hệ thống chỉ sau 5 phút xem sơ đồ không?
  2. Mọi Use Case trên sơ đồ đã có đặc tả riêng chưa?

Nếu câu trả lời là chưa, sơ đồ vẫn cần được hoàn thiện.

Checklist

Sau khi học xong bài này, bạn nên trả lời được:

  • Use Case Diagram dùng để làm gì?
  • Actor, Use Case và System Boundary có vai trò gì?
  • Khi nào dùng «include»?
  • Khi nào dùng «extend»?
  • Biết giới hạn của Use Case Diagram.

Góc nhìn nghề nghiệp

Trong nhiều dự án, Use Case Diagram thường là sơ đồ đầu tiên được trình bày với khách hàng vì nó trực quan và dễ hiểu. Tuy nhiên, nhóm phát triển không dựa vào sơ đồ này để lập trình. Họ cần Use Case Specification, Requirement và các mô hình chi tiết khác.

Điều đó cho thấy vai trò thực sự của Use Case Diagram là giao tiếp, không phải đặc tả. Một sơ đồ tốt giúp các bên liên quan nhanh chóng thống nhất phạm vi và chức năng của hệ thống, từ đó giảm hiểu nhầm trước khi bước vào thiết kế và triển khai.

Bài tiếp theo

Đến đây, chúng ta đã biết hệ thống có những chức năng gì và ai sử dụng các chức năng đó.

Nhưng vẫn còn một câu hỏi:

Một quy trình nghiệp vụ diễn ra theo trình tự nào? Có những nhánh rẽ, điều kiện và vòng lặp nào trong quá trình xử lý?

Đó là nội dung của Bài 14 – Activity Diagram, nơi chúng ta sẽ chuyển từ góc nhìn chức năng sang góc nhìn luồng công việc (workflow). Đây cũng là sơ đồ được sử dụng rất phổ biến để mô tả quy trình nghiệp vụ trước khi nhóm phát triển bắt đầu thiết kế chi tiết hệ thống.

Comments are closed.

MENU