Giải đáp một số câu hỏi về Biểu đồ hoạt động (Phần 3)

Q3. Trong use case diagram, ta có nhất thiết phải vẽ mỗi use case 1 biểu đồ hoạt động?

Em chào chị ạ. Chị ơi em có 1 câu hỏi như sau: Nếu dùng use case diagram để liệt kê các chức năng, ta có nhất thiết phải vẽ mỗi use case 1 biểu đồ hoạt động không ạ? Hay là ta có thể vẽ CRUD vào 1 biểu đồ hoạt động không chị?

— 

Bản chất usecase diagram và activity diagram là hai loại biểu đồ khác nhau. Cho nên việc vẽ chúng cũng độc lập nhau.

Với trường hợp em hỏi thì:

• Nếu chức năng quá phổ biến hoặc quá nhỏ, em có thể không cần vẽ biểu đồ hoạt động (ví dụ chức năng thêm mới một item mà item đó chỉ có 1-2 trường....) ==> tuy nhiên với trường hợp này, thì BA nên đảm bảo rằng các phần phổ biến này đã được mô tả hoặc qui định rồi (tức trong team cũng đã biết và tuân thủ, nhớ là bằng văn bản nhé). Xem ví dụ dưới:

Giả sử Hệ thống có rất nhiều chức năng ngắn như thế này, đơn cử chỉ là thêm một Tag Name, hoặc một trường gì đó, thì có thể chỉ cần vẽ biểu đồ hoạt động một lần, các chức năng khác có thể dùng tương tự (nhưng phải đưa vào qui ước của dự án, hoặc common function).

• Usecase để liệt kê ra chức năng và mối quan hệ (nếu có) giữa các chức năng, nhưng nếu chức năng phức tạp, cần xử lí nhiều điều kiện thì rất nên vẽ biểu đồ hoạt động ra. Ví dụ chức năng thêm mới Customer, nhưng lại kèm theo các điều kiện như: Customer có doanh số mua từ 100tr thì xếp hạng Vàng, dưới 100tr thì xếp hạng Bạc.... thì những cái này trong usecase diagram không diễn tả được, cho nên chỉ có thể diễn tả ở biểu đồ hoạt động.
• Với trường hợp em hỏi có thể vẽ CRUD vào 1 biểu đồ hoạt động không thì chị trả lời như sau nhé:
  • Nếu các CRUD là một phần của nghiệp vụ, thì em đưa vào biểu đồ hoạt động. Ví dụ: Khi tạo mới một Customer (C) thì phải Update lại danh sách User, do user giờ đã là Customer, tức ta update trạng thái của Enduser về trạng thái đã là Customer chẳng hạn (U), đồng thời Delete đi trạng thái tạm trước đó (D) và cuối cùng có thể xem lại thông tin Customer (R) ==> biểu diễn trong cùng 1 biểu đồ, có thứ tự trước sau.
  • Nếu CRUD độc lập nhau, tức là có 4 chức năng riêng biệt gồm: Thêm mới Customer (C), Xem thông tin Customer (R), Cập nhật thông tin Customer (U) và Xóa Customer (D) ==> thì em phải vẽ thành 4 biểu đồ hoạt động nhé.

Xem ví dụ sau để phân biệt rõ (ví dụ mẫu nên luồng để ở mức cơ bản, chứ luồng xử lí cụ thể có thể phức tạp hơn tuy vào yêu cầu nghiệp vụ):

Hình trên là ví dụ về CRUD trong cùng một tính năng liên quan đến Quản lí Tài khoản, bao gồm:

Số (1) là dùng R để truy vấn xem dữ liệu người dùng nhập vào có đúng không.

Số (2) là dùng D để xóa tài khoản người dùng (nếu chức năng nghiệp vụ yêu cầu là xóa khỏi DB luôn) hoặc dùng U để update lại trạng thái tài khoản người dùng thành Đã xóa (nếu chức năng nghiệp vụ yêu cầu giữ lại mọi dữ liệu trên DB)

Số (3) là U (dùng để cập nhật lại dữ liệu có liên quan, hoặc của chính bản ghi ở bước (2)). Hoặc số (3) còn có thể là I (Insert thêm một bản ghi vào bảng Deleted_User chẳng hạn).

Còn ví dụ về CRUD được thể hiện thành các biểu đồ hoạt động riêng, chính là Chức năng Thêm mới Tài khoản (C), Cập nhật Tài khoản, Xóa Tài khoản (và xóa tài khoản ngoài việc sử dụng một biểu đồ hoạt động riêng thì trong biểu đồ đó lại có cả CRUD).