Use Case Diagram Là Gì

Use Case Diagram Là Gì

Hê lô anh em. Ở kỳ trước mình đã nói về BPMN – một đồ nghề khá bổ ích của BA. Hiện nay mình sẽ tiếp tục nói về 1 trong các đồ nghề khác cũng rất là quan trọng không kém, đó đó chính là Use Case.

Bài Viết: Use case diagram là gì

Bản thân mình thời điểm đầu cần sử dụng Use Case cũng gặp rất đông phức tạp. Một mớ bồng bông thắc mắc cứ lởn quởn trong đầu: thực chất của Use Case là gì, cần sử dụng cho mục đích nào, vẽ vậy đúng hay chưa, có rõ nét quá không, hoặc thậm chí vẽ Use Case xong cũng chẳng biết để làm gì???

Vì vậy bài này mình sẽ note về các thứ mình học đc, làm đc and đương nhiên quan trọng đặc biệt là các sai lầm mà mình từng bận rộn phải khi làm Use Case.

Content

2. Những thành phần của Use Case Diagram2.2. Relationship3. Một số sai lầm phổ cập khi vẽ Use Case
1. Use Case là gì?

Trước tiên Use Case là một technique của việc làm Business Analyst.

Use Case là kỹ thuật cần sử dụng để diễn tả sự tương tác giữa người sử dụng and hệ thống cùng nhau, trong một môi trường thiên nhiên rõ rệt and vì một mục đích rõ rệt.

Sự tương tác ở đây có thể là:

Người sử dụng tương tác với hệ thống như vậy nào?Hoặc, hệ thống tương tác với những hệ thống khác như vậy nào?

And đương nhiên, sự tương tác này phải bên phía trong một môi trường thiên nhiên rõ rệt, tức là bên phía trong một bối cảnh, phạm vi chức năng rõ rệt, hoặc rộng hơn là trong một hệ thống/ ứng dụng rõ rệt.

Sau cùng, việc diễn tả sự tương tác này phải nhằm biểu đạt một mục đích rõ rệt nào đó. Use Case phải diễn rả đc Requirement theo tầm nhìn rõ rệt từ phía người sử dụng.

Ví dụ sơ đồ Use Case diễn đạt sự tương tác giữa người sử dụng là fan hâm mộ với trang blog hethongbokhoe.com chẳng hạn.

Ví dụ dễ chơi về Use Case

Tương tác ở đấy là gì?Người hâm mộ đọc bài notesNgười hâm mộ thích thú bài notesNgười hâm mộ chia sẻ trình bày bài notesNgười hâm mộ bình chọn bài notesNgười hâm mộ gửi bài notes cho fan hâm mộ khác qua emailMôi trường thiên nhiên rõ rệt?Quá dễ chơi, này là trang blog hethongbokhoe.com (không phải trang Admin).Mục đích rõ rệt? Người sử dụng có thể đọc đc bài notes trên blog (dễ chơi bỏ lỡ)Người sử dụng có thể bày tỏ đc sự thích thú bài notesNgười sử dụng có thể chia sẻ trình bày bài notes này trên những nguồn gốc khác để nhiều bạn khác có thể đọc đcNgười sử dụng có thể viết bình chọn khen chê gạch đá những kiểu cho tác giảNgười sử dụng có thể gửi bài notes này qua email cho một người ngẫu nhiên.

Đấy là tất tần tật các content mà một Use Case sẽ biểu thị.

Về bề ngoài thì Use Case tồn tại ở 2 dạng:

Hình vẽ Use Case (Use Case Diagram)Đặc tả Use Case (Use Case Specification).

Ở bài sau mình sẽ nói Use Case Specification sau nhé anh em. Bài này mình sẽ tập trung nói về Use Case Diagram.

Use Case Diagram là một thành viên trong họ UML (Unified Modeling Language).

Use Case thuộc họ Behavior trong bộ UML

Mỗi Diagram trong bộ UML này đều có các mục đích khác nhau. Tùy tình huống, tùy dự án mà anh em sẽ “rút hàng” ra chiến như vậy nào cho hợp lý.

Hiểu sơ bộ Use Case là gì and mục đích của nó, các bạn cùng thăm dò rõ nét Use Case Diagram and cách thức vẽ nhé anh em ????

2. Những thành phần của Use Case Diagram

2.1. Actor, Use Case, Communication Liên kết and Boundary

Cũng không có gì quá nan giải, Use Case Diagram gồm 5 thành phần chính:

ActorUse CaseCommunication LinkBoundary of SystemVà, Relationships.

Những thành phần có trong một Use Case Diagram

Actor thì có thể là Người sử dụng, hoặc một System nào đó. Vì UML điều khoản Actor là hình thằng người nên có thể anh em sẽ nhầm lẫn nơi đó cần là người sử dụng nhưng hổng phải.

Một số thắc mắc anh em có thể tự lẩm bẩm trong đầu để định vị Actor như sau:

Ai là người dùng hệ thống?Ai mới là người Admin của hệ thống (tức người setup, quản trị, duy trì… hệ thống)?Hệ thống này có đc cần sử dụng bởi ngẫu nhiên một hệ thống nào khác không? (*)Hệ thống lưu trữ dữ liệu, vậy ai là người input dữ liệu vào hệ thống?Hệ thống lưu trữ dữ liệu, vậy ai là người cần các dữ liệu output?

Ở mục (*), mình thích highlight cho anh em chỗ này. Không phải giải pháp/ ứng dụng nào làm ra đều đc cần sử dụng bởi con người. Có các ứng dụng làm ra, khiến cho… ứng dụng khác cần sử dụng.

Chẳng hạn như làm những services. Mình chứa một đứa bạn làm BA, giải pháp mà ảnh cùng bằng hữu làm ra là 1 services không đc cần sử dụng bởi con người, mà đc cần sử dụng bởi một hệ thống khác để chứng thực người sử dụng.

Ký hiệu của Actor chủ yếu là hình thằng người, nhưng để Diagram thêm đa dạng, đa chủng loại thì anh em có thể cần sử dụng những hình bên dưới đây, miễn có ghi chú cụ thể là đc.

Những ký hiệu biểu thị Actor.

Còn Use Case là anh em sẽ biểu thị bên dưới dạng hình Oval, biểu thị sự tương tác giữa những Actor and hệ thống.

Communication Liên kết biểu thị sự tương tác giữa Actor nào với System. Nối giữa Actor với Use Case.

Boundary of System 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 công dụng to như Quản trị quý khách, Quản trị lên đơn, hoặc cả một module to như Quản trị bán sản phẩm.

…

Ô kê nãy giờ dễ ẹc, mấy cái này nhìn sơ 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, này là Relationship.

2.2. Relationship

Relationship gồm 3 loại: Include, Extend, and Generalization.

a) Include

Include nghĩa là mối quan hệ bắt buộc phải có giữa những Use Case cùng nhau.

Xét về nghĩa, Include nghĩa là kể cả, tức nếu Use Case A có mối quan hệ include Use Case B, thì nghĩa là: Use Case A kể cả Use Case B. Để Use Case A xảy ra, thì Use Case B phải đạt đc.

Ví dụ về Include trong Use Case

Xét ví dụ trên, các bạn có Use Case: Đánh Giá bài notes. Use Case này include 2 Use Case khác là: Đăng nhập WordPress and Soạn thảo bình chọn.

Rõ rệt anh em cảm thấy: để bình chọn đc một bài viết, anh em cần phải đăng nhập khẩu 1 tài khoản nào đó, để blog nhận diện anh em ai đã, tên gì, quê quán, giai gái ra sao.

Ví dụ ở blog mình là anh em sẽ cần đăng nhập khẩu tài khoản WordPress. Sau khi đăng nhập xong, anh em phải soạn thảo bình chọn, tức là gõ bình chọn, biên tập, xóa tới xóa lui. Sau khi viết xong bình chọn, anh em sẽ bấm nút Submit để hoàn thành chẳng hạn.

Chỉ lúc nào xong 2 bước trên (đăng nhập and soạn thảo bình chọn), thì anh em mới có thể xong bước Đánh Giá bài notes đc.

Hay nói cách thức khác để Use Case: Đánh Giá bài notes xảy ra, thì Use Case: Đăng nhập WordPress and Use Case: Soạn thảo bình chọn phải bắt buộc hoàn thành đầu tiên.

Đó đó chính là mối quan hệ Include. Anh em xem tiếp 1 số ví dụ bên dưới cho dễ tưởng tượng nhé.

Muốn rút đc tiền thì trước tiên quý khách phải chứng thực tài khoản đi cái đã.

Muốn đặt đc xe thì phải hoàn thành đc 3 công đoạn này rồi hệ thống mới cho đặt.

Hoặc quý khách muốn reviews đc chuyến đi thì trước đó họ phải đặt xe cái đã.

Hoặc hệt như là Use Case biểu thị công dụng Theo dõi tiến độ phục vụ trên một trang e-Commerce ngẫu nhiên.

Một số điểm cần để ý khi vẽ Include cho Use Case

Thực sự không có điều khoản nào cụ thể cho việc lúc nào cần tách Use Case ra thành những Use Case bé dại and cho nó một mối quan hệ Include cả.

Việc tách hay không tách lệ thuộc duy nhất vào người vẽ. And lý do to nhất để mối quan hệ Include ra đời là cứu cho những Use Case của các bạn DỄ QUẢN LÝ hơn; gây nên Use Case Diagram trông hình như mất an toàn hơn mà thôi ????

And anh em chỉ nên tách Use Case khi nó có độ nan giải to and các thứ tách ra đc có thể đc tận dụng ở những Use Case sau này.

Độ nan giải to thì khi tách ra mình mới có đc các Use Case vừa phải, đủ để biểu đạt dễ hiểu cho những stakeholders. Còn tận dụng đc ở những Use Case sau là sao?

Cần sử dụng Include như vậy nào cho hợp lý?

Ví dụ Use Case A gồm 2 Use Case bé dại nằm trong là X and Y. Vì vậy Use Case A đc tách thành Use Case X and Use Case Y.

Gần giống, Use Case B gồm Use Case Y nằm trong, nên đc tách thành Use Case Y.

Nhưng, Use Case C gồm Use Case X and Use Case Z nằm 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 bé dại hơn.

Các bạn 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. Gần giống, 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 đó cứu Use Case Diagram của các bạn làm nên chặt chẽ, logic and gọn nhẹ hơn rất đông.

Còn Use Case Z, vì nó không đc “cần sử dụng lại” ở một Use Case ngẫu nhiên 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 đó đủ to and khá là high-level, thì có lẽ các bạn nên tách. Còn nếu ngược lại, Use Case đã cụ thể, là một requirement từ phía User rõ rệt thì không đáng để anh em tách nó ra thành một Use Case bé dại, chỉ làm hình thêm thêm rối mà thôi.

Khi tách Use Case ra thành những Use Case bé dại để tận dụng mối quan hệ Include, anh em hãy nhớ 2 thứ: độ to của Use Case and khả năng tái cần sử dụng lại của nó.

Còn cách thức vẽ thì anh em cứ đừng quên include tới thằng nào thì dấu mũi tên hướng tới thằng đó nhé anh em. Nhớ để qua phần Extend cho khỏi lộn.

b) Extend

Extend là mối quan hệ mở rộng giữa những Use Case cùng 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ó biểu thị mối quan hệ có thể có hoặc có thể không giữa những Use Case cùng 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, and chỉ xảy ra trong một hoàn cảnh rõ rệt nào đó.

Lấy ví dụ Grab ở bên trên, anh em sẽ dễ dàng có đc một mối quan hệ Extend như sau.

Ví dụ về mối quan hệ Extend giữa những Use Case

Trong tình huống 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: Reviews 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; and nó ảnh hưởng đến Use Case: Reviews chuyến đi, chứ không phải ngẫu nhiên một Use Case nào khác.

À…à…Nhắc tới lúc có những lúc không, tức là nhắc tới trường hợp xảy ra.

Anh em có thể biểu thị rõ ý chỗ này bằng một thứ luôn đi cùng với Extend, này là Extension Point ????

Extension Point nôm na là trường hợp 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 biểu thị sự khác biệt.

Tức nếu dữ liệu chính là A thì Use Case không xảy ra, nhưng nếu dữ liệu chính là B thì Use Case sẽ xảy ra.

//Theo mình đừng quên có vẻ anh em chỉ có thể gửi tiền tip cho tài xế, nếu cuốc xe đó anh em chấm họ maximum là 5 sao.//

Vậy thì anh em sẽ vẽ Use Case Diagram nơi đó như sau.

Xem Ngay: Suit Là Gì – Nghĩa Của Từ Suit

Use Case Diagram có biểu thị rõ lúc nào thì mối quan hệ Extend ra mắt.

Extension Point ở đấy là dữ liệu Driver Rating. Nếu Driver Rating đạt trị giá 5 sao, thì Use Case: Gửi tiền tip cho lái xe sẽ xảy ra, and tuyệt đối optional, tùy từng quý khách.

And nó ảnh hưởng mật thiết đến Use Case: Reviews chuyến đi, là 1 phần mở rộng của Use Case: Reviews chuyến đi.

Extension Point không nhất thiết cần là một dữ liệu nào đó trên hệ thống, mà có thể là một “trường hợp” ngẫu nhiên, miễn là nó biểu thị đc tình huống rõ rệt mà Use Case sẽ xảy ra.

Ở 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, gây nên Diagram nhìn rối bời quá, anh em có thể bỏ luôn phần phản hồi của Extension Point luôn rất được.

Vẽ vầy cũng hông sao.

c) Generalization

Generalization dễ chơi là quan hệ cha con giữa những Use Case cùng nhau. Nhưng khác biệt với Include and Extend là nó còn đc cần sử dụng để biểu thị mối quan hệ giữa những… Actor cùng nhau.

Trước tiên là mối quan hệ cha-con giữa những Use Case. Ví dụ:

Đăng nhập thì có thể đăng nhập qua số Smartphone, hoặc đăng nhập qua email.Mua hàng thì có oder qua Smartphone, hoặc oder qua website.Trả tiền thì thanh toán trả tiền qua card ATM, qua card thanh toán trả tiền quốc tế, hoặc qua ví điện tử.Hoặc search thì có thể search bằng từ khóa, hoặc search theo nhóm món đồ.

Hoặc mối quan hệ cha-con giữa những Actor. Ví dụ:

Quý khách gồm quý khách cũ and quý khách mớiHoặc Vendor thì có thể gồm Retailers and Wholesalers.

Ví dụ về quan hệ cha-con (Generalization) trong Use Case.

Nhìn chung, Generalization cứu anh em biểu thị rõ hơn những có nhu cầu bằng việc gom nhóm những 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ỉ cần sử dụng Include and 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 đó, bao gồm Use Case hay Actor.

Ví dụ Use Case A có include đến Use Case B and 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 and C, mặc dù không đc biểu thị trên hình.

…

Ô kê, vậy là xong phần Relationship – một trong các phần chuối nhất, dễ lộn nhất trong Use Case. Hi vọng các ví dụ trên cứu anh em hiểu đc rõ rệt như vậy nào là Include, Extend and Generalization trong một Use Case Diagram ????

3. Một số sai lầm phổ cập khi vẽ Use Case

Use Case Diagram là thứ để anh biểu thị đc requirement của quý khách.

Vẽ sao mà quý khách nhìn vô một phát là cảm thấy khoái liền. Quý khách mà chân nhịp nhịp, miệng lẩm bẩm: “Đúng rồi…đúng rồi…, công dụng này có,… công dụng kia có luôn, à… gắn vào lấy dữ liệu này có, ô kê ô kê,… vầy là đủ rồi!”, thì coi như anh em đã vẽ khá good ????

Chém nãy giờ mạnh vậy chứ mình vẽ chẳng khi nào là ổn cả. PM cứ phải duyệt đi duyệt lại cả chục lần. Nhờ đó mới có các sai lầm phổ cập mà mình hay gặp khi vẽ Use Case Diagram cho anh em tìm hiểu thêm bên dưới đây, hehe.

3.1. Chuyện đặt tên

Trong quy mô hóa, chuyện đặt tên là rất-rất-rất quan trọng.

Vì đã nói “mô-hình-hóa” tức là các bạn cần sử dụng hình ảnh để nói chuyện, thì khi đó hàm lượng chữ chiếm rất ít. And chính vì nó ít, nên các gì các bạn ghi trên diagram phải rất súc tích, cô đọng and có trị giá ngay tức thì.

Chỉ cần người đọc họ nhìn vô diagram mà cảm thấy ngay 1 dòng chữ khó hiểu, thì ngay lập tức tụt bà nó hết mood, hết muốn xem tiếp rồi.

Nói về Use Case thì có 1 vài chăm chú sau cho anh em:

Actor thì phải đặt tên bằng danh từ, không cần sử dụng động từ, and cũng không mệnh đề quan hệ gì hết.Tên Use Case thì phải ghi cụ thể, rành mạch, đẹp tuyệt vời nhất là bên dưới format: Verb + Noun.

Ví dụ: Đổi điểm thành viên, Chuyển tiền trong nước, Chuyển tiền quốc tế, Duyệt bình chọn bài viết.

BA các bạn vẽ Use Case nhằm mục đích diễn đạt có nhu cầu cho stakeholders hiểu, cho nên anh em không đc cần sử dụng các từ kỹ thuật trong đây, đã không còn hiện sự mất an toàn ở đây, người ta đọc zô hông hiểu gì hết là trớt quớt.

And nổi biệt là né đặt tên quá dài and đừng nên cần sử dụng kiểu bị động.

Sai lầm 1: Chuyện đặt tên.

3.2. Vẽ Use Case mà thành phân rã chức năng

Đây đúng đắn là lỗi mà mình hay gặp nhất, rất thường xuyên gặp khi vẽ Use Case.

Sai lầm 2: không nhận ra đc phân rã chức năng and Use Case (Nguồn ảnh: ModernAnalyst.com)

Thể hiện nhận thấy cụ thể đặc biệt là khi Use Case Diagram của anh em đầy rẫy chữ “manage”, manage cái này, manage cái kia…

Trước tiên là chữ Manage rất rộng nghĩa. Nhu yếu quản trị A gồm 5 việc, thì không có nghĩa có nhu cầu quản trị B cũng gồm 5 việc. Use Case là diagram biểu thị có nhu cầu của End-Users, nhằm đạt đc một mục đích nào đó.

Ở ví dụ trên, nếu nói Manage Gears, Manage Brakes, hay Manage Air Conditioner thì quá tối nghĩa, chả ai hiểu nhằm mục đích sau cùng là để làm gì.

Thứ hai, hình minh họa trên vẽ Use Case nhưng lại chưa mang đc tầm nhìn của End-Users, tức chưa cho cảm thấy đc End-Users muốn đạt đc gì sau ngần ấy Use Case đc liệt kê ra.

Nguyên nhân có thể do người vẽ chưa nắm đủ thông tin về có nhu cầu của End-Users, ảnh chưa chắc chắn rõ rốt cuộc thì người sử dụng họ muốn làm gì trên hệ thống, hay hệ thống phải tương tác các gì với hệ thống khác.

Từ đó mới có chuyện anh em nhìn vô Use Case Diagram ở trên cao mà cảm nhận mông lung như 1 trò đùa. Vì vậy, các bạn chỉ vẽ Use Case khi đã có rất nhiều đủ thông tin thiết yếu:

Ngoài ra, khi đã có rất nhiều đủ thông tin nhưng Use Case mình vẽ vẫn bị confuse. Lý do có thể do những Use Case mình vẽ bị lệch những cấp độ Requirement cùng nhau.

Ví dụ Use Case A thì biểu thị Business Requirement, tức là rất high level. Nhưng sang Use Case B and C thì lại nói rất detail tới mức Solution Requirement như.

Để làm lại Use Case trên, dễ chơi mình chỉ cần bỏ Use Case A: Quản trị học sinh ra, vì nó là thứ rất chung chung, đã không còn hiện đc mục đích rõ rệt, đối với 2 Use Case còn lại.

Tuy vậy, chữ “Manage” trong Use Case lại rất công năng, công năng đến mức độ đã không còn không cần sử dụng trong những document mình làm, nó sẽ bị cứu mình giải quyết vấn đề ở mục số 3.4 phía bên dưới, đọc tiếp nhé anh em.

3.3. Rối nùi Use Case

Anh em tìm hiểu thêm một số hình sau sẽ rõ.

Vấn đề của hình chính là ôm đồm quá nhiều. Dẫn đến quá nhiều Use Case có mặt trong cùng một Diagram, đã vậy cũng không có Boundary of System cụ thể.

Như anh em cảm thấy, Use Case này vẽ rất sai ở các điểm như sau:

Cam kết sai Use Case (nên mới nhiều UC như thế): các thứ như single, double, num of guest… cụ thể đâu cần là một Use Case, đâu cần là một sự tương tác.Đặt tên Use Case sai: quá nhiều cụm danh từ cho Use Case.Không có Boundary of System.Các Use Case có extend không ghi chú rõ rệt trường hợp lúc nào thì UC extend xảy ra.

Một note bé dại quan trọng cho anh em, Use Case Diagram sạch xinh là chỉ nên có trên bên dưới 10 Use Case trong đó. Những Use Case còn lại anh em hãy cần sử dụng Boundary of System để phân chia theo phân hệ một cách thức hợp lý nhất có thể.

Hình này cụ thể là quá thứ dữ. Thật ra tình huống này cũng tương đối phổ cập, mình trước kia bị hoài. Mấu chốt tới từ một số điều sau:

Một số Use Case đặt tên saiChưa tận dụng những Relationship để biểu thị, gây nên những Use Case quá rời rạc nhau, and trông rất không hợp logic.Người vẽ không cần sử dụng Boundary of System để phân nhóm, giới hạn những Use Case.And nổi biệt, người vẽ quá chú trọng đến những chức năng căn bản nhất, này là: CRUD – Create/Read/Cập nhật/Delete.

3.4. Quá rõ nét những chức năng CRUD

Như ví dụ trên, mỗi thực thể là một lần CRUD. Như thế quá tốn effort, trong khi 96,69% là ở phân hệ nào, hay dữ liệu nào, anh em cũng đều cần phải CRUD dữ liệu hết.

Điều đó tạo được một sự lặp đi lặp lại ở những Use Case Diagram, nhưng đã không còn 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 thức sau.

Cách thức 1

Thêm 1 dòng note trước đoạn diễn tả Use Case trong tài liệu: “Tất cả dữ liệu đều có tác dụng Thêm/ Đọc/ Sửa/ Xóa and chịu tác động bởi sự phân quyền từ phía Quản lý hệ thống” hoặc đại loại vậy. Khiến cho những stakeholder biết đc rằng hệ thống có tác dụng CRUD những dữ liệu này.

Nhưng nên nhớ CRUD ở đấy là đứng từ tầm nhìn End-Users: hệ thống có được phép End-Users CRUD dữ liệu hay không?

Ví dụ hệ thống CRM lấy dữ liệu ưu đãi từ hệ thống ERP. Thì về thực chất CRM phải có khả năng Create dữ liệu ưu đãi, thì mới lấy dữ liệu ưu đãi từ ERP về đc.

Nhưng theo tầm nhìn của End-Users, thì không một người sử dụng nào (bao gồm System Admin) có thể tạo thủ công bằng tay dữ liệu ưu đãi trên CRM, mà End-Users họ chỉ Đọc/ Sửa/ Xóa dữ liệu đc lấy về này thôi.

Vì vậy ở đây anh em cần diễn tả rõ là có phải cục bộ dữ liệu đều được phép End-Users CRUD đc hay không (không tính phân quyền).

Cách thức 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 người dùng ngẫu nhiên.

Nếu không đầy đủ 4 công dụng CRUD, thì anh em có thể làm 1 cái note bé dại phía trên, nói rõ Manage là có các công dụng gì, không có các công dụng gì.

3.5. Mỹ thuật

Cuối cùng vẫn trở lại vấn đề thẩm mỹ và làm đẹp. Nguyên nhân việc Use Case mất thẩm mỹ và làm đẹp tới từ 2 lý do:

Mắt thẩm mỹ và làm đẹp kém: chiếm 0,00000000000069%Ẩu, cẩu thả: chiếm 99,00000000000000069%

Làm gì cũng như vậy, nổi biệt là quy mô hóa để làm document. Ẩu là thứ mình nên nỗ lực hạn chế nó nhất. Vì làm đúng 1 lần, xinh 1 lần, sau này đỡ bận rộn công sửa lại chứ hông có gì hết.

Một số điểm anh em cần để ý sau:

Kích cỡ những Use Case trong Diagram là phải tương đồng, bao gồm cha-con, lẫn những mối quan hệ Include. Tuy vậy, Use Case có Extend để được vẽ lớn hơn một chút.Nhớ phải lưu lại Use Case ID trong hình vẽ.Những mối quan hệ không đc chồng chéo lẫn nhau. Anh em có thể vẽ 1 Actor ở 2 vị trí đặt khác nhau để né những đường nối bắt chéo lên nhau.Khi vẽ Use Case Diagram, tập trung vào thắc mắc What để tìm ra Use Case, né thắc mắc How, vì khi đó anh em rất dễ đi vào detail.And nếu đc, hãy tô màu lên Use Case để nhìn Diagram đc cụ thể, lạc quan and mạch lạc ????

.

.

.

Hi vọng qua bài này anh em đã hiểu rõ thực chất của Use Case, and biết cách thức vẽ Use Case Diagram. À mà không các biết cách thức vẽ, mà còn vẽ đúng, vẽ xinh and né đc các lỗi sai thường gặp nữa.

Xem Ngay: Canister Là Gì – Canister Trong Tiếng Tiếng Việt

Bài sau mình sẽ note lại cách thức viết Use Case Specification sau cho nhanh gọn lẹ and dễ chơi nhất. Nếu có gì câu hỏi cứ thả còm men dưới hoặc email cho mình nhé.

Thể Loại: San sẻ Kiến Thức Cộng Đồng

Bài Viết: Use Case Diagram Là Gì

Thể Loại: LÀ GÌ

Nguồn Blog là gì: https://hethongbokhoe.com Use Case Diagram Là Gì