Post này anh có chưa ạ ^^

Hi em,

UC A include UC B không có nghĩa là flow B nằm trong flow A.

Mục đích của UC Diagram là làm đơn giản hoá một chùm những thứ, mà user có thể tương tác với hệ thống (hay trong ngữ cảnh câu hỏi của e thì gọi nôm na là Tính năng đi cho đơn giản). Việc mình tách nhỏ ra từng Use Case là để dễ dàng quản lý và có cái nhìn sáng tỏ hơn về toàn bộ tính năng của system.

Mỗi UC là 1 tính năng độc lập, nó nên satisfy được 1 cái goal nào đó của user. Ví dụ UC “Đặt hàng” là để đáp ứng được goal mua hàng online tiện ích của user. UC “Đánh giá sản phẩm” là để thoả mãn nhu cầu được đánh giá, được lên tiếng, được nói về món hàng mình đã mua, đã xài của user.

Let say, phải mua hàng xong thì mới được đánh giá, lúc này UC “Đánh giá sản phẩm” sẽ include UC “Đặt hàng”, nhưng không có nghĩa là lúc mô tả UC Specs cho UC “Đánh giá sản phẩm” thì mình phải mô tả luôn luồng của UC “Đặt hàng” trong đó. Vậy thì việc tách riêng toàn bộ tính năng của system ra thành từng cục UC nhỏ mới có ý nghĩa. Mỗi UC đều có một flow từ start đến end riêng em nhé.
Còn nếu muốn diễn tả rỏ hơn về tổng quan quy trình thì em có thể dùng BPMN: https://thinhnotes.com/chuyen-nghe-ba/bpmn-va-su-loi-hai-cua-no/

Về câu thứ 2 thì em cứ xài cái nào cho đơn giản, dễ hiểu là được. UC nó chỉ là tool, nó phục vụ mình. Mình xài nó xong, thì output của mình phải đơn giản, dễ đọc, dễ hiểu. Nên em thấy xài như thế nào cho hợp lý, dễ dàng với em thì cứ chơi cái đó thôi. Cái nào không có trong chuẩn thì ghi cái note dưới là người ta đọc vào sẽ hiểu.

Đừng quá quan trọng đúng hay sai, quan trọng là nó có giúp em “facilitate” ý đồ của mình dễ dàng hơn hay không thôi nhé.

Cảm ơn Khoa nhé