Use Case Diagram Là Gì

Bài viết Use Case Diagram Là Gì thuộc chủ đề về Giải Đáp thời gian này đang được rất nhiều bạn quan tâm đúng không nào !! Hôm nay, Hãy cùng NaciHolidays.vn tìm hiểu Use Case Diagram Là Gì trong bài viết hôm nay nha !

Các bạn đang xem bài : “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 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 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ì thế 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 vài 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 dùng để diễn tả sự tương tác giữa người dùng and hệ thống cùng nhau, trong một môi trường thiên nhiên rõ nét and vì một mục đích rõ nét.

Sự tương tác ở đây khả năng là:

Người 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õ nét, tức là bên phía trong một bối cảnh, phạm vi chức năng rõ nét, hoặc rộng hơn là trong một hệ thống/ ứng dụng rõ né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õ nét nào đó. Use Case phải diễn rả đc Requirement theo tầm nhìn rõ nét từ phía người dùng.

Ví dụ sơ đồ Use Case diễn đạt sự tương tác giữa người 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õ nét?Quá dễ chơi, này là trang blog hethongbokhoe.com (không phải trang Admin).Mục đích rõ nét? Người dùng khả năng đọc đc bài notes trên blog (dễ chơi bỏ lỡ)Người dùng khả năng bày tỏ đc sự thích thú bài notesNgười dùng khả năng 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 khả năng đọc đcNgười dùng khả năng viết bình chọn khen chê gạch đá những kiểu cho tác giảNgười dùng khả năng 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 nha 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ẽ nha anh em ????

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

2.1. Actor, Use Case, Communication kết nối 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 xuất hiện trong một Use Case Diagram

Actor thì khả năng là Người 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 khả năng anh em sẽ nhầm lẫn nơi đó cần là người dùng nhưng hổng phải.

một vài thắc mắc anh em khả năng 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 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 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 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 dùng bởi con người, mà đc cần dùng bởi một hệ thống khác để chứng thực 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 đa dạng, đa chủng loại thì anh em khả năng cần dùng những hình bên dưới đây, miễn có ghi chú chi tiết 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 kết nối 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 khả năng 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 danh mục.

Ô 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.

Mọi Người Cũng Xem   Không gian là gì - Có Nghĩa Là Gì, Ý Nghĩa La Gi 2021

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: IncludeExtend, 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õ né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 khả năng 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 nha.

*

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 độ đáp ứng trên một trang e-Commerce ngẫu nhiên.

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

Thực sự không có điều khoản nào chi tiết 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 ra 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 khả năng đ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 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ì thế 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ì khả năng 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 khả năng 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 khả năng 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 dùng lại” ở một Use Case ngẫu nhiên nào sau đó, nên người vẽ khả năng 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 đã chi tiết, là một requirement từ phía User rõ né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 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 đó nha 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ệ khả năng có hoặc khả năng 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õ nét nào đó.

Lấy ví dụ Grab ở bên trên, anh em sẽ đơn giản 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 khả năng xảy ra, hoặc không; and nó gây tác động 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 khả năng 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 khả năng 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ỉ khả năng 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.

Mọi Người Cũng Xem   Căn Cô Chín Là Gì

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ó tác độ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à khả năng là một “trường hợp” ngẫu nhiên, miễn là nó biểu thị đc tình huống rõ né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 ra nên Diagram nhìn rối bời quá, anh em khả năng 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 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ì khả năng đă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ì khả năng 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ì khả năng 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ó mong muốn 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 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õ nét như vậy nào là Include, Extend and Generalization trong một Use Case Diagram ????

3. một vài 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 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 dùng động từ, and cũng không mệnh đề quan hệ gì hết.Tên Use Case thì phải ghi chi tiết, 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ó mong muốn cho stakeholders hiểu, cho nên anh em không đc cần 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 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 nhiều 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 chi tiết đặ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ó mong muốn quản trị B cũng gồm 5 việc. Use Case là diagram biểu thị có mong muốn 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.

tác nhân khả năng do người vẽ chưa nắm đủ thông tin về có mong muốn của End-Users, ảnh chưa chắc chắn rõ rốt cuộc thì người 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ì thế, các bạn chỉ vẽ Use Case khi đã có rất nhiều đủ thông tin thiết yếu:

mặt khác, khi đã có rất nhiều đủ thông tin nhưng Use Case mình vẽ vẫn bị confuse. Lý do khả năng 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õ nét, đối với 2 Use Case còn lại.

Mọi Người Cũng Xem   Thế Giới Là Gì - Thế Giới Quan Là Gì

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 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 nha anh em.

3.3. Rối nùi Use Case

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

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

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… chi tiết đâ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õ né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 dùng Boundary of System để phân chia theo phân hệ một cách thức hợp lý nhất khả năng.

Hình này chi tiết 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 vài điều sau:

một vài Use Case đặt tên saiChưa tận dụng những Relationship để biểu thị, gây ra 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 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 khả năng 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ó công 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ó công 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 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 dùng nào (bao gồm System Admin) khả năng 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ì thế ở đâ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 khả năng 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. tác 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 Giảm 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 vài đ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 khả năng 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 chi tiết, 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 nha.

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

Các câu hỏi về Use Case Diagram Là Gì


Nếu có bắt kỳ câu hỏi thắc mắt nào vê Use Case Diagram Là Gì hãy cho chúng mình biết nha, mõi thắt mắt hay góp ý của các bạn sẽ giúp mình nâng cao hơn hơn trong các bài sau nha <3 Bài viết Use Case Diagram Là Gì ! được mình và team xem xét cũng như tổng hợp từ nhiều nguồn. Nếu thấy bài viết Use Case Diagram Là Gì Cực hay ! Hay thì hãy ủng hộ team Like hoặc share. Nếu thấy bài viết Use Case Diagram Là Gì rât hay ! chưa hay, hoặc cần bổ sung. Bạn góp ý giúp mình nha!!

Các Hình Ảnh Về Use Case Diagram Là Gì

Use Case Diagram Là Gì

Các từ khóa tìm kiếm cho bài viết #Case #Diagram #Là #Gì

Tra cứu thêm báo cáo về Use Case Diagram Là Gì tại WikiPedia

Bạn khả năng tham khảo nội dung chi tiết về Use Case Diagram Là Gì từ web Wikipedia.◄

Tham Gia Cộng Đồng Tại

💝 Nguồn Tin tại: https://NaciHolidays.vn/

💝 Xem Thêm Chủ Đề Liên Quan tại : https://naciholidays.vn/hoi-dap/

Related Posts

About The Author

Add Comment