Use case là gì

     

Use case là gì? tò mò về use case về các thành phần có trong một use case và cách để tạo ra chúng thông qua bài viết sau đây


Menu bài xích viết

2. Các thành phần của Use caseCác quan hệ tình dục trong Use case3. Các giai đoạn xây dựng một Use Case Diagram4. Những sai lầm hay chạm chán phải khi xây dựng Use Case

1. Use case là gì?

Use case là 1 trong kỹ thuật được sử dụng trong kỹ thuật ứng dụng và hệ thống để thâu tóm được những yêu cầu tính năng của hệ thống. Hoặc nói theo cách khác Use case là kỹ thuật biểu đạt sự thúc đẩy giữa người dùng và hệ thống trong một môi trường, bởi vì một mục tiêu cụ thể. Sự xúc tiến này hoàn toàn có thể là:

Cách thức mà bạn dùng bên phía ngoài (actor) xúc tiến cùng một hệ thống.Cách thức mà khối hệ thống thống cửa hàng cùng các khối hệ thống khác.

Bạn đang xem: Use case là gì

*
Use case là gì?

Mỗi use case tế bào tả phương thức actor ảnh hưởng với khối hệ thống để đạt được kim chỉ nam nào đó. Từng use case rất có thể tạo ra được một hoặc những kịch bản tương ứng với cụ thể về mỗi cách thức để đạt được phương châm nào đó.

Khi biểu thị user case, tín đồ ta đang tránh sử dụng thuật ngữ kỹ thuật cầm vào kia họ sử dụng ngữ điệu của người tiêu dùng cuối hoặc chuyên viên về nghành nghề đó. Tạo thành một user còn rất cần được có sự phù hợp tác nghiêm ngặt giữa người phân tích khối hệ thống và người tiêu dùng cuối. Một trong những cách màn biểu diễn trực quan lại phổ biến bây chừ là lược vật dụng use case của UML.

2. Các thành phần của Use case

Actor

Actor được thực hiện để chỉ người tiêu dùng hoặc một đối tượng người dùng nào đó bên ngoài tương tác cùng rất hệ thống. Để khẳng định được một actor đó gồm phải tốt không, bạn cần xem xét qua những câu hỏi như sau:

Ai là tín đồ sử dụng chức năng chính của hệ thống?Ai là admin của hệ thống, là người cài đặt, quản lý và duy trì hệ thống,…?Ai là người sẽ bắt buộc hệ thống cung ứng để tiến hành các tác vụ hằng ngày?Hệ thống sẽ phải xử lý và làm việc với những trang máy phần cứng nào?Hệ thống rất cần được tương tác cùng với các hệ thống khác nào?Ai là tín đồ input dữ liệu vào khối hệ thống (đối với khối hệ thống lưu trữ dữ liệu)?

*

User case

User case là tác dụng mà các Actor vẫn sử dụng, để tìm các ra được các user ta phải vấn đáp được các câu hỏi như sau:

Actor này cần những chức năng như thế nào của hệ thống, vận động chính của actor là gì?Actor có rất cần phải tạo, buộc phải đọc, bắt buộc hủy bỏ, phải sửa chữa thay thế hay là tàng trữ một loại tin tức nào kia trong hệ thống?Actor có cần được báo cho khối hệ thống về phần lớn sự khiếu nại nào kia không? Ngược lại hệ thống có bắt buộc phải thông tin cho Actor về phần lớn thay đổi bất ngờ trong nội bộ hệ thống không?Công việc hàng ngày của Actor có thể được dễ dàng hóa hoặc bổ ích hóa qua các tính năng mới trong hệ thống?Use case rất có thể tạo ra bởi vì sự kiện nào không giống không?Hệ thống có nhu cầu các thông tin đầu vào/đầu ra nào? Những tin tức đó từ bỏ đâu tới và sẽ đi đâu?Khó khăn và thiếu vắng chính trong khối hệ thống hiện thời nằm tại vị trí đâu?

Các dục tình trong Use case

Trong kia gồm có 3 loại: Include, Extend, và Generalization

Include

*

Include được có mang là mối quan hệ bắt buộc phải bao gồm giữa các use case với nhau. Một Use case có thể chứa chức năng của một use case khác như một phần xử lý của nó. Xem về nghĩa, Include trong giờ đồng hồ Anh nghĩa là bao gồm. Tức nếu nói Use Case A có quan hệ Include cùng với Use Case B thì điều này có nghĩa Use Case A bao hàm Use Case B.

Trên đấy là một ví dụ: Để rút được chi phí trong thẻ, mọi bạn phải cần trải qua bước xác xắn tài khoản. Chỉ khi đúng đắn được thông tin tài khoản bạn mới có thể rút được tiền trong thẻ, hay có thể nói rằng để Use case “rút tiền” xẩy ra thì Use case “xác thực tài khoản” cần phải hoàn thành. Đây là mối quan hệ Include.

Extend

*

Extend được định nghĩa là mọt quan hệ mở rộng giữa các Use case với nhau. Nếu đối với Include là mối quan hệ bắt buộc thì Extend lại là mối quan hệ không bắt buộc, hoàn toàn có thể có hoặc ko giữa những 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à 1 trong thứ optional, và chỉ xảy ra trong một trả cảnh rõ ràng nào đó.

Quan gần cạnh ví dụ sau đây:

Ở vào trường vừa lòng này, Use case “ gởi tiền tip cho lái xe” là 1 Use case gồm quan hệ Extend so với Use case “ reviews chuyến đi”. Tức là Use case “ gửi tiền tip đến lái xe” rất có thể xảy ra hoặc không xảy ra. Với nó chỉ tương quan đến Use case “ nhận xét chuyến đi” chứ không cần liên quan ngẫu nhiên đến Use case nào khác.

Generalization

*

Generalization được hiểu dễ dàng là côn trùng quan hệ phụ thân con giữa những Use case cùng với nhau. Đây là điểm khác biệt nhất thân Generalization với Include cùng Extend, chúng được dùng làm thể hiện quan hệ giữa các Actor với nhau. Chúng được thể hiện qua lấy ví dụ như sau đây:

Mối quan hệ phụ thân – con giữa những Use case

Khi singin thì hoàn toàn có thể đăng nhập qua số smartphone hoặc singin qua email.Đặt sản phẩm cũng có thể đặt qua điện thoại cảm ứng hoặc website.Thanh toán rất có thể thanh toán qua thẻ ATM, thẻ quốc tế, ví điện tử,…Tìm tìm sản phẩm có thể tìm kiếm bởi từ khóa, theo nhóm sản phẩm,…

Mối quan liêu hệ phụ vương – nhỏ giữa những Actor

Khách hàng gồm người sử dụng cũ và quý khách hàng mớiHoặc Vendor thì hoàn toàn có thể gồm Retailers với Wholesalers.

Xem thêm: Bột Xí Muội Là Gì - Hướng Dẫn Cách Làm Món Khoai Lang Lắc Bột Xí Muội

3. Những giai đoạn xây dừng một Use Case Diagram

Giai đoạn quy mô hóa

Bước 1: cấu hình thiết lập ngữ cảnh của hệ thống đích.

Bước 2: Chỉ định các Actor

Bước 3: Chỉ định các Use Case

Bước 4: Định nghĩa những quan hệ giữa cácActor và những Use Case

Bước 5: Đánh giá các Actor và các Use Case nhằm tìm cách cụ thể hóa.

Giai đoạn cấu trúc

Bước 1: Đánh giá các Use Case cho quan hệ include

Bước 2: Đánh giá các Use Case đến quan hệ extend

Bước 3: Đánh giá những Use Case đến quan hệ Generalization

Giai đoạn review

Bước 1: chất vấn để bảo vệ là khối hệ thống đã được phạt triển đúng chuẩn và phù hợp với các đặc tả được chế tạo ra.

Bước 2: Phê chuẩn để bảo đảm an toàn rằng hệ thống sẽ được phạt triển chính là thứ mà quý khách hoặc người tiêu dùng cuối thiệt sự đề xuất đến.

4. Những sai lầm hay chạm mặt phải khi xây dựng Use Case

Sơ thứ Use Case là thứ thể hiện được đa số yêu mong từ phía khách hàng, thế nên khi thiết chúng ta cần sao cho thật đơn giản mà vẫn bảo vệ chi tiết và dễ hiểu nhất. Dưới đó là những sai trái mà các bạn khi kiến thiết vẫn vẫn hay thường gặp gỡ phải nhất, vậy đề xuất làm ra sao để khắc phục?

Đặt tên ko chuẩn

*

Vì là quy mô hóa cần cần diễn tả bằng hình ảnh, nỗ lực sử dụng ít chữ nhất gồm thể. Bởi vậy, số đông gì được ghi trên Use Case Diagram đề nghị thật cô ứ đọng và có mức giá trị tức thì. Xem xét dành cho mình khắc phục chúng:

Actor thì phải kê tên bằng danh từ, không sử dụng động từ, với cũng không mệnh đề quan hệ nam nữ gì hết.Tên Use Case thì cần ghi rõ ràng, rành mạch, đẹp tuyệt vời nhất là dưới format: Verb + Noun.Tránh khắc tên quá dài và tránh việc dùng đẳng cấp bị động.

Lẫn lộn giữa Use Case và phân chảy chức năng

*

Sai lầm bắt gặp ngay là đầy đủ từ “quản lý” (manage) trên sơ đồ. Use Case đề xuất truyền thiết lập được mục tiêu sau cùng, đựng đựng ánh mắt của người dùng cuối cùng.

*

Là một sai trái nhiều người mắc phải ở đông đảo điểm như sau:

Xác định sai Use Case (nên bắt đầu nhiều UC như vậy): những thứ như single, double, num of guest…Đặt thương hiệu Use Case sai: vô số cụm danh từ đến Use Case.Không bao gồm Boundary of System.Những Use Case gồm extend ko ghi chú rõ ràng điều kiện lúc nào thì UC extend xảy ra.

Xem thêm: Block Fb Là Gì ? Block Là Gì Trên Facebook Trên Messenger Ý Nghĩa Của Từ Block Trên Facebook Là Gì

Bạn buộc phải tận dụng các Relationship để khiến cho các Use Case link với nhau, tiếp nối sử dụng Boundary of System để phân nhóm, giới hạn cho các Use Case

Quá đi sâu vào chi tiết các tác dụng CRUD

*

Nếu áp dụng mỗi thực thể là 1 trong những lần CRUD thì sẽ rất tốn công. Điều này cũng tạo nên sự lặp đi lặp lại ở các sơ đồ vật Use Case nhưng mà lại bắt buộc hiện được rất nhiều thông tin cho những người xem. Gồm hai cách để giải quyết, các bạn có tham khảo:

Thêm một dòng chú ý trước đoạn biểu thị Use Case trong tài liệu: “Toàn bộ tài liệu đều có chức năng Thêm/ Đọc/ Sửa/ Xóa với chịu ảnh hưởng 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 những stakeholder biết được rằng hệ thống có công dụng CRUD các dữ liệu này.Tạo hẳn 1 Use Case có tên là manage X với X là 1 đối tượng người dùng bất kỳ.

Thiếu thẩm mỹ

Nhiều sơ thứ Use Case hơi thiếu thẩm mỹ, không được thiết kế hợp lý yêu cầu không mê say được tín đồ dùng. Vì chưng vậy, các bạn cần chăm chú thiết kế những Use Case trong Diagram như sau:

Kích cỡ các Use Case trong Diagram là bắt buộc như nhau, của cả cha-con, lẫn các mối dục tình Include. Mặc dù nhiên, Use Case có Extend sẽ được vẽ to hơn một chút.Nhớ phải khắc ghi Use Case ID vào hình vẽ.Các quan hệ không được chồng chéo lẫn nhau. Bạn bè có thể vẽ 1 Actor ở cả 2 vị trí khác nhau để tránh những đường nối bắt chéo cánh lên nhau.Khi vẽ Use Case Diagram, tập trung vào câu hỏi What nhằm tìm ra Use Case, tránh thắc mắc How, bởi khi đó đồng đội rất dễ đi vào detail.Và nếu được, hãy tô color lên Use Case để xem Diagram được rõ ràng, sáng sủa và mạch lạc