Admin
10/09/2023
Share
Đầu tiên Use Case. là một kỹ thuật của công việc Nhà phân tích kinh doanh.
Use Case. là kỹ thuật dùng để mô tả sự tương tác giữa người dùng và hệ thống với nhau, trong một môi trường cụ thể và vì một mục đích cụ thể.
Sự giao tiếp ở đây có thể là:
Tất nhiên, việc tương tác này phải xảy ra trong một môi trường cụ thể, có nghĩa là trong một ngữ cảnh, phạm vi chức năng cụ thể, hoặc có thể là trong một hệ thống/ phần mềm cụ thể.
Kết thúc, mô tả tương tác này phải có một mục đích cụ thể. Use Case. phải biểu đạt được Requirement từ góc nhìn người dùng.
Một sơ đồ Use Case. có thể mô tả cách người dùng, như là độc giả, tương tác với trang blog Thinhnotes.
Một ví dụ đơn giản về Use Case..
Đó là toàn bộ các thông tin mà một Use Case. sẽ biểu đạt.
Về hình thức, Use Case. có hai dạng tồn tại:
Trong bài tiếp theo, tôi sẽ giới thiệu về Use Case. Diagram, không đề cập đến Use Case. Specification như trước đây.
Sơ đồ Use Case. là một thành viên trong bộ UML (Ngôn ngữ Mô hình hóa thống nhất).
Use Case. nằm trong nhóm Behavior trong bộ UML.
Các Diagram trong bộ UML này có mục đích riêng biệt. Tùy vào trường hợp và dự án, chúng ta sẽ áp dụng phù hợp để đạt hiệu quả tốt nhất.
Chúng ta hãy tìm hiểu về khái niệm và mục đích của Use Case., cùng với cách vẽ Use Case. Diagram nhé 😎.
2. Các thành phần của Use Case. Diagram
2.1. Actor., Use Case., Communication Link. và Boundary
Cũng không có gì quá phức tạp, Sơ đồ Use Case. bao gồm 5 thành phần chính:.
Các thành phần có trong một Use Case. Diagram
Actor. thì có thể là Người dùng, hoặc một System nào đó. Vì UML quy định Actor. là hình thằng người nên có thể anh em sẽ nhầm lẫn chỗ đó phải là người dùng nhưng hổng phải.
Một số câu hỏi anh em có thể tự lẩm bẩm trong đầu để xác định Actor. như sau:
(*) Trong phần này, tôi muốn nhấn mạnh điểm này cho mọi người. Không phải tất cả các giải pháp hoặc phần mềm được tạo ra để sử dụng bởi con người. Một số phần mềm được tạo ra để được sử dụng bởi các phần mềm khác.
Ví dụ như việc thực hiện các dịch vụ. Mình có một người bạn làm BA, giải pháp mà anh ta và đồng đội tạo ra là một dịch vụ không dành cho con người, mà được sử dụng bởi một hệ thống khác để xác minh người dùng.
Ký hiệu của Actor. chủ yếu là hình thằng người, nhưng để Diagram thêm phong phú, đa dạng thì anh em có thể sử dụng các hình dưới đây, miễn có ghi chú rõ ràng là được.
Các biểu tượng thể hiện Diễn viên..
Còn Use Case. là anh em sẽ thể hiện dưới dạng hình Oval, thể hiện sự tương tác giữa các Actor. và hệ thống.
Communication Link. thể hiện sự tương tác giữa Actor. nào với System. Nối giữa Actor. với Use Case..
Giới hạn của Hệ thống. là phạm vi mà Use Case. xảy ra. Ví dụ trong hệ thống CRM, phạm vi có thể là từng cụm tính năng lớn như Quản lý khách hàng, Quản lý đơn hàng, hoặc cả một module lớn như Quản lý bán hàng.
Okay từ trước đến giờ dễ thôi, mấy cái này nhìn qua là anh em biết ngay cái một.
Cái cuối cùng mới chính là cái mà mình tin là nhiều anh em vẫn còn rất dễ lộn, đó là Relationship.
2.2. Mối quan hệ
Mối quan hệ bao gồm 3 loại: Bao gồm, Mở rộng và Tổng hợp.
A) Bao gồm
Include nghĩa là mối quan hệ bắt buộc phải có giữa các Use Case. với nhau.
Xét về nghĩa, Include nghĩa là bao gồm, tức nếu Use Case. A có mối quan hệ include Use Case. B, thì nghĩa là: Use Case. A bao gồm Use Case. B. Để Use Case. A xảy ra, thì Use Case. B phải đạt được.
Một ví dụ về Bao gồm trong Use Case..
Xét ví dụ trên, chúng ta có Use Case.: Nhận xét bài notes. Use Case. này include 2 Use Case. khác là: Đăng nhập WordPress và Soạn thảo nhận xét.
Để có thể đánh giá một bài viết, rõ ràng anh em phải đăng nhập vào một tài khoản bất kỳ. Điều này giúp blog nhận diện anh em là ai, biết tên, quê quán và thông tin cá nhân của anh em.
Ví dụ trên blog của tôi, bạn cần đăng nhập vào tài khoản WordPress. Sau khi đã đăng nhập, bạn có thể viết nhận xét, chỉnh sửa hoặc xóa nó. Khi đã hoàn thành viết nhận xét, bạn chỉ cần nhấn nút Submit để hoàn tất.
Anh em chỉ có thể hoàn thành bước Nhận xét bài notes sau khi đã hoàn thành đăng nhập và soạn thảo nhận xét.
Hay nói cách khác để Use Case.: Nhận xét bài notes xảy ra, thì Use Case.: Đăng nhập WordPress và Use Case.: Soạn thảo nhận xét phải bắt buộc hoàn thành trước tiên.
Đó là mối quan hệ Include. Anh em hãy xem tiếp một số ví dụ dưới đây để dễ hiểu hơn.
Để rút tiền, khách hàng phải xác minh tài khoản trước tiên.
Để có thể đặt xe, bạn phải hoàn thành 3 giai đoạn này trước khi hệ thống cho phép đặt.
Hoặc khách hàng muốn đánh giá được chuyến đi thì trước đó họ phải đặt xe trước.
Hoặc tương tự là Use Case. thể hiện tính năng Theo dõi tiến độ giao hàng trên một trang e-Commerce bất kỳ.
Một số điểm cần chú ý khi vẽ Include cho Use Case.
Thực sự không có quy tắc nào rõ ràng cho việc khi nào cần tách Use Case. ra thành các Use Case. nhỏ và cho nó một mối quan hệ Include cả.
Việc tách hay không tách phụ thuộc duy nhất vào người vẽ. Và lý do lớn nhất để mối quan hệ Include ra đời là giúp cho các Use Case. của chúng ta DỄ QUẢN LÝ hơn; làm cho Use Case. Diagram trông có vẻ nguy hiểm hơn mà thôi 😎
Và anh em chỉ nên tách Use Case. khi nó có độ phức tạp lớn và những thứ tách ra được có thể được tận dụng ở các Use Case. sau này.
Độ phức tạp lớn thì khi tách ra mình mới có được những Use Case. vừa phải, đủ để diễn đạt dễ hiểu cho các stakeholders. Còn tận dụng được ở các Use Case. sau là sao?
Sử dụng Bao gồm như thế nào cho phù hợp?
Ví dụ Use Case. A gồm 2 Use Case. nhỏ bên trong là X và Y. Do đó Use Case. A được tách thành Use Case. X và Use Case. Y.
Tương tự, Use Case. B gồm Use Case. Y bên trong, nên được tách thành Use Case. Y.
Nhưng, Use Case. C gồm Use Case. X và Use Case. Z bên trong, nhưng chỉ có Use Case. X là được tách ra cho mối quan hệ Include. Vì có thể Use Case. Z “không đáng” để tách ra thành một Use Case. nhỏ hơn.
Chúng ta tách Use Case. X từ Use Case. A để Use Case. C có thể tận dụng được mà không cần vẽ lại. Tương tự, tách Use Cas Y từ Use Case. B để Use Case. A có thể tận dụng mà cũng không cần vẽ lại.
Điều này giúp Use Case. Diagram của chúng ta trở nên chặt chẽ, logic và gọn nhẹ hơn rất nhiều.
Còn Use Case. Z, vì nó không được “dùng lại” ở một Use Case. bất kỳ nào sau đó, nên người vẽ có thể cân nhắc có tách nó ra hay không!
Nếu Use Case. đó đủ lớn và khá là high-level, thì có lẽ chúng ta nên tách. Còn nếu ngược lại, Use Case. đã rõ ràng, là một requirement từ phía User cụ thể thì không đáng để anh em tách nó ra thành một Use Case. nhỏ, chỉ làm hình thêm thêm rối mà thôi.
Khi tách Use Case. ra thành các Use Case. nhỏ để tận dụng mối quan hệ Include, anh em hãy nhớ 2 thứ: độ lớn của Use Case. và khả năng tái sử dụng lại của nó.
Anh em nhớ rằng khi vẽ, hãy nhớ chỉ định mũi tên hướng tới thằng mà ta muốn bao gồm. Đừng quên qua phần Extend để tránh nhầm lẫn.
B) Mở rộng
Extend là mối quan hệ mở rộng giữa các Use Case. với nhau.
Nếu Include là mối quan hệ bắt buộc, thì Extend là một mối quan hệ không bắt buộc. Nó thể hiện mối quan hệ có thể có hoặc có thể không giữa các Use Case. với nhau.
Một Use Case. B là extend của Use Case. A thì có nghĩa Use Case. B chỉ là một thứ optional, và chỉ xảy ra trong một hoàn cảnh cụ thể nào đó.
Ví dụ như Grab đã được đề cập, chúng ta có thể dễ dàng thiết lập một mối quan hệ mở rộng như sau.
Ví dụ về mối quan hệ Mở rộng giữa các Trường hợp sử dụng..
Trong trường hợp này, Use Case.: Gửi tiền tip cho lái xe là một Use Case. có mối quan hệ Extend với Use Case.: Đánh giá chuyến đi. Tức, Use Case.: Gửi tiền tip cho lái xe chỉ là một Use Case. có thể xảy ra, hoặc không; và nó liên quan đến Use Case.: Đánh giá chuyến đi, chứ không phải bất kỳ một Use Case. nào khác.
À…À…Đề cập đến lúc có lúc không, tức là đề cập đến điều kiện xảy ra.
Anh em có thể thể hiện ý này một cách rõ ràng hơn bằng cách sử dụng một khía cạnh luôn đi kèm với Extend, đó là Extension Point 😎.
Extension Point nôm na là điều kiện mà Use Case. có mối quan hệ Extend sẽ xảy ra. Còn để sát nghĩa thì anh em có thể hiểu chữ Point ở đây nghĩa là điểm dữ liệu thể hiện sự khác biệt.
Tức nếu dữ liệu này là A thì Use Case. không xảy ra, nhưng nếu dữ liệu này là B thì Use Case. sẽ xảy ra.
Theo nhớ của tôi, có vẻ như chúng ta chỉ có thể đưa tiền tip cho tài xế, và nếu chúng ta đánh giá cuốc xe đó, điểm tối đa mà chúng ta có thể đưa ra là 5 sao.
Vậy thì anh em sẽ vẽ Use Case. Diagram chỗ đó như sau.
Use Case. Diagram có thể hiện rõ khi nào thì mối quan hệ Extend diễn ra.
Extension Point ở đây là dữ liệu Driver Rating. Nếu Driver Rating đạt giá trị 5 sao, thì Use Case.: Gửi tiền tip cho lái xe sẽ xảy ra, và hoàn toàn optional, tùy thuộc vào khách hàng.
Và nó liên quan mật thiết đến Use Case.: Đánh giá chuyến đi, là một phần mở rộng của Use Case.: Đánh giá chuyến đi.
Extension Point không nhất thiết phải là một dữ liệu nào đó trên hệ thống, mà có thể là một “điều kiện” bất kỳ, miễn là nó thể hiện được trường hợp cụ thể mà Use Case. sẽ xảy ra.
Trong một ví dụ khác.
Mối quan hệ Extend trong Use Case. Diagram của A kia rồi chấm côm.
Còn nếu Use Case. có quá nhiều mối quan hệ Extend, làm cho Diagram nhìn rối bời quá, anh em có thể bỏ luôn phần comment của Extension Point luôn cũng được.
Vẽ như vậy cũng không có vấn đề gì.
C) Tổng quát hóa
Generalization đơn giản là quan hệ cha con giữa các Use Case. với nhau. Nhưng khác biệt với Include và Extend là nó còn được dùng để thể hiện mối quan hệ giữa các… Actor. với nhau.
Đầu tiên là mối quan hệ cha-con giữa các Use Case.. Ví dụ:
Hoặc mối quan hệ cha-con giữa các Actor.. Ví dụ:
Ví dụ về mối quan hệ cha-con (Tổng quát hóa) trong Use Case..
Nhìn chung, Generalization giúp anh em thể hiện rõ hơn các yêu cầu bằng việc gom nhóm các Use Case. lại theo quan hệ cha-con. Cá nhân mình thì rất ít khi vẽ relationship này, chủ yếu chỉ dùng Include và Extend là chính.
Còn một điểm nữa là Generalization có tính kế thừa. Tức thằng cha có gì thì thằng con có cái đó, kể cả Use Case. hay Actor..
Ví dụ Use Case. A có include đến Use Case. B và C. Thì Use Case. A’ là con của Use Case. A cũng sẽ có mối quan hệ Include đến Use Case. B và C, mặc dù không được thể hiện trên hình.
Ô kê, vậy là xong phần Relationship – một trong những phần chuối nhất, dễ lộn nhất trong Use Case.. Hi vọng những ví dụ trên giúp anh em hiểu được cụ thể như thế nào là Include, Extend và Generalization trong một Use Case. Diagram 😎
3. Một số lỗi thường gặp khi thiết kế Use Case.
Use Case. Diagram là thứ để anh thể hiện được requirement của khách hàng.
Khi nhìn vào sao, khách hàng cảm thấy ngay lập tức hài lòng. Họ nhắm chân và nói nhỏ: “Chính xác đấy…Chính xác đấy…, Tính năng này có,… Tính năng kia cũng có, à… Kết hợp với dữ liệu này cũng được, hoàn hảo,… Đây là đủ rồi!”, Vậy là chúng ta đã vẽ rất tốt 🙂.
Chém nãy giờ mạnh vậy chứ mình vẽ chẳng bao giờ là ổn cả. PM cứ phải duyệt đi duyệt lại cả chục lần. Nhờ đó mới có những sai lầm phổ biến mà mình hay gặp khi vẽ Use Case. Diagram cho anh em tham khảo dưới đây, hehe.
3.1. Vấn đề về đặt tên
Trong mô hình hóa, việc đặt tên có ý nghĩa cực kỳ quan trọng.
Vì đã đề cập đến việc “mô hình hóa” là sử dụng hình ảnh để truyền đạt ý kiến, do đó, số lượng chữ viết giảm đi đáng kể. Bởi vì có ít chữ, những ghi chú trên biểu đồ phải ngắn gọn, súc tích và có giá trị ngay lập tức.
Nếu người đọc chỉ cần nhìn vào sơ đồ và gặp một dòng chữ khó hiểu, họ sẽ ngay lập tức mất hứng và không muốn tiếp tục xem nữa.
Nói về Use Case. thì có 1 vài lưu ý sau cho anh em:
Ví dụ: Thay đổi điểm thành viên, Chuyển tiền trong nước, Chuyển tiền quốc tế, Phê duyệt nhận xét bài viết.
BA chúng ta vẽ Use Case. nhằm mục đích diễn tả yêu cầu cho stakeholders hiểu, do đó anh em không được dùng những từ kỹ thuật trong đây, không thể hiện sự nguy hiểm ở đây, người ta đọc zô hông hiểu gì hết là trớt quớt.
Đặc biệt, hãy tránh việc đặt tên quá dài và không nên sử dụng cấu trúc bị động.
Lỗi 1: Vấn đề về việc đặt tên.
3.2. Vẽ Use Case. mà thành phân rã chức năng
Đây chính xác là vấn đề mà tôi thường gặp nhất, xảy ra thường xuyên khi vẽ Use Case..
Sai lầm 2: không phân biệt được phân rã chức năng và Use Case. (Nguồn ảnh: ModernAnalyst.com)
Dấu hiệu nhận biết rõ ràng nhất là khi Use Case. Diagram của anh em đầy rẫy chữ “manage”, manage cái này, manage cái kia…
Đầu tiên là chữ Manage rất rộng nghĩa. Yêu cầu quản lý A gồm 5 việc, thì không có nghĩa yêu cầu quản lý B cũng gồm 5 việc. Use Case. là diagram thể hiện yêu cầu của End-Users, nhằm đạt được một mục đích nào đó.
Khi nói đến việc quản lý bộ truyền động, hệ thống phanh hoặc hệ thống điều hòa không khí, ví dụ trên đã không rõ ràng về mục đích cuối cùng của việc quản lý đó.
Thứ hai, hình minh họa trên vẽ Use Case. nhưng lại chưa mang được góc nhìn của End-Users, tức chưa cho thấy được End-Users muốn đạt được gì sau ngần ấy Use Case. được liệt kê ra.
Có thể nguyên nhân là người vẽ chưa đủ thông tin về yêu cầu của người dùng cuối, hoặc không hiểu rõ hệ thống cần làm gì hoặc tương tác với hệ thống khác.
Từ đó mới có chuyện anh em nhìn vô Use Case. Diagram ở trên mà cảm thấy mông lung như một trò đùa. Do đó, chúng ta chỉ vẽ Use Case. khi đã có đủ thông tin cần thiết:
Ngoài ra, khi đã có đủ thông tin nhưng Use Case. mình vẽ vẫn bị confuse. Lý do có thể do các Use Case. mình vẽ bị lệch các cấp độ Requirement với nhau.
Ví dụ Use Case. A thì thể hiện Business Requirement, tức là rất high level. Nhưng sang Use Case. B và C thì lại nói rất detail tới mức Solution Requirement như.
3 Use Case. này bị lệch cấp độ với nhau, gây “rối bời” cho người xem.
Để sửa lại Use Case. trên, đơn giản mình chỉ cần bỏ Use Case. A: Quản lý học viên ra, vì nó là thứ rất chung chung, không thể hiện được mục đích cụ thể, so với 2 Use Case. còn lại.
Tuy nhiên, chữ “Manage” trong Use Case. lại rất công dụng, công dụng đến mức không thể không dùng trong các document mình làm, nó sẽ giúp mình giải quyết vấn đề ở mục số 3.4 phía dưới, đọc tiếp nhé anh em.
3.3. Mập mờ Use Case.
Các bạn có thể tham khảo một số hình ảnh dưới đây để hiểu rõ hơn.
Sai lầm 3: Rối nùi Use Case. (Nguồn hình: stackoverflow)
Vấn đề của hình này là ôm đồm quá nhiều. Dẫn đến quá nhiều Use Case. xuất hiện trong cùng một Diagram, đã vậy cũng không có Giới hạn của Hệ thống. rõ ràng.
Như anh em thấy, Use Case. này vẽ rất sai ở những điểm như sau:
Một note nhỏ quan trọng cho anh em, Use Case. Diagram sạch đẹp là chỉ nên có trên dưới 10 Use Case. trong đó. Các Use Case. còn lại anh em hãy dùng Giới hạn của Hệ thống. để phân chia theo phân hệ một cách hợp lý nhất có thể.
Nguồn ảnh: alexander-stoyan.Blogspot.Com.
Hình này thật dễ hiểu là quá tệ. Thực tế, trường hợp này cũng khá phổ biến, tôi đã trải qua nó trước đây. Mấu chốt nằm ở một số điều sau.
3.4. Quá cụ thể các chức năng CRUD
Mỗi thực thể được xem như một lần CRUD, tuy nhiên việc này tốn nhiều công sức. Thực tế, hầu hết thời gian và công việc đều tập trung vào việc CRUD dữ liệu trong các phân hệ và loại dữ liệu khác nhau.
Điều này tạo ra một sự lặp đi lặp lại ở các Use Case. Diagram, nhưng không thể hiện được gì nhiều cho người xem. Để giải quyết vấn đề này, anh em có thể có làm 1 trong 2 cách sau.
Cách 1.
Thêm một dòng note trước đoạn mô tả Use Case. trong tài liệu: “Toàn bộ dữ liệu đều có chức năng Thêm/ Đọc/ Sửa/ Xóa và chịu tác động bởi sự phân quyền từ phía Quản trị hệ thống” hoặc đại loại vậy. Để cho các stakeholder biết được rằng hệ thống có chức năng CRUD các dữ liệu này.
Nhưng cần nhớ rằng CRUD ở đây được đánh giá từ góc nhìn của người dùng cuối: liệu hệ thống có cho phép người dùng cuối thao tác CRUD dữ liệu hay không?
CRM cần có khả năng tạo dữ liệu ưu đãi để lấy dữ liệu ưu đãi từ hệ thống ERP.
Tuy nhiên, từ khía cạnh của người dùng cuối, không ai (bao gồm cả quản trị viên hệ thống) có thể tạo dữ liệu khuyến mãi trên CRM bằng cách thủ công, họ chỉ có thể đọc/sửa/xóa dữ liệu được lấy về này.
Vì vậy, ở đây chúng ta cần mô tả rõ ràng liệu tất cả dữ liệu có thể được End-Users CRUD hay không (không tính phân quyền).
Cách 2.
Tạo hẳn một Use Case. với tên là: Manage “X”, với X là một đối tượng bất kỳ.
Thay thế việc vẽ theo hướng bên trái bằng cách vẽ theo hướng bên phải.
Nếu thiếu bất kỳ một trong bốn tính năng CRUD, bạn có thể tạo một ghi chú nhỏ ở trên cùng để mô tả chi tiết các tính năng có trong Manage và các tính năng không có.
3.5. Vẻ đẹp
Cuối cùng vẫn quay về vấn đề thẩm mỹ. Nguyên nhân việc Use Case. mất thẩm mỹ đến từ 2 lý do:
Thực hiện mọi công việc, đặc biệt là việc mô hình hóa tài liệu. Hạn chế việc này là điều mà chúng ta nên cố gắng. Vì làm đúng một lần, làm đẹp một lần, sau này sẽ không phải làm lại và không mất công.
Một số điểm bạn cần lưu ý sau đây:
Hi vọng qua bài này anh em đã hiểu rõ bản chất của Use Case., và biết cách vẽ Use Case. Diagram. À mà không những biết cách vẽ, mà còn vẽ đúng, vẽ đẹp và tránh được những lỗi sai thường gặp nữa.
Bài sau mình sẽ note lại cách viết Use Case. Specification sau cho nhanh gọn và đơn giản nhất. Nếu có gì thắc mắc cứ thả còm men bên dưới hoặc email cho mình nhé.
Tạm biệt và mong gặp lại các bạn!!!
