Các Thành Phần Cần Lưu Ý Khi Vẽ Biểu Đồ UseCase
Bạn là Tester mới đang cần đọc hiểu sơ đồ UseCase để hiểu dự án và viết testcase và bạn là Tester đang có hướng chuyển sang làm BA bài viết này bắt đầu với các thành phần của UseCase giúp bạn đi từ cơ bản
Xin chào các bạn đã ghé qua blog donghanhcungtester.com, blog hôm nay giúp bạn hiểu kỹ hơn về biểu đồ USECASE. Bài viết giúp Tester có thể đọc hiểu biểu đồ từ trên bàn giao, giúp bạn hiểu được dự án có những chức năng nào( chức năng chính, chức năng phụ), đối tượng tham gia vào dự án để từ đó bạn có thể đưa ra được nhiều trường testcase hơn.
Với Tester đang có hướng chuyển sang BA-IT hoặc các bạn sinh viên đang muốn hiểu kỹ về biểu đồ UseCase
I.Quy trình vẽ Use Case diagram
Xây dựng được một sơ đồ Use Case hoàn chỉnh cần trải qua 3 giai đoạn: Giai đoạn mô hình hóa, giai đoạn cấu trúc & giai đoạn review.
Giai đoạn mô hình hóa:
Bước 1: Thực hiện thiết lập ngữ cảnh của hệ thống.
Bước 2: Xác định các Actor.
Bước 3: Xác định các Use Case.
Bước 4: Định nghĩa các mối quan hệ giữa Actor và Use Case.
Bước 5: Đánh giá các mối quan hệ đó để tìm cách chi tiết hóa.
Giai đoạn cấu trúc:
Bước 6: Đánh giá các Use Case cho quan hệ Include.
Bước 7: Đánh giá các Use Case cho quan hệ Extend.
Bước 8: Đánh giá các Use Case cho quan hệ Generalization .
Giai đoạn review:
Bước 9: Kiểm tra (verification): Đảm bảo hệ thống đúng với tài liệu đặc tả.
Bước 10: Thẩm định (validation): Đảm bảo hệ thống sẽ được phát triển là thứ mà khách hàng cuối thực sự cần thiết
II.Hiểu thành phần của biểu đồ
Ngoài ra nếu bạn chưa rõ luồng hệ thống và chưa thử vẽ biểu đồ Usecase thì bạn hãy đọc bài viết để hiểu hơn về biểu đồ do Leader hoặc BA đưa tài liệu cho bạn nhé
Các bạn khi bắt đầu thực hành vẽ USECASE chắc hẳn có rất nhiều vấn câu hỏi xung quanh biểu đồ và đặc biệt rất muốn làm rõ, một vài câu hỏi dễ thấy nhất là:
Câu 1: Khi nào sử dụng các kiểu mũi tên này cho biểu đồ của bạn?
Hình 1. Demo các thành phần sẽ có và hay sử dụng
Câu 2: Nhìn hình trên thì các thành phần của UseCase gồm những gì?
Câu 3: Cách xác định actor như thế nào?
Câu 4: Usecase gồm những gì?
Câu 5: Tại sao phải vẽ UseCase trong khung dự án 1?
Câu 6: Khái niệm về UseCase? Tại sao phải sử dụng UseCase
Câu 7: UseCase tổng quan và UseCase phân rã khác nhau như nào?
Câu 8: Mối quan hệ giữa Actor với UseCase, giữa các actor với nhau, giữa các usecase với nhau?
Câu 9: Lưu ý khi vẽ UseCase
Cùng mình trả lời chi tiết nhé:
Câu 2: Các thành phần của UseCase:
Một Usecase đơn giản gồm các thành phầm cơ bản như: System boundary, Usecase, actor và relationship
- System boundary: là một hình chữ nhật. Tất cả những chức năng cần code sẽ được đặt ở trong này, và dev cũng chỉ code những chức năng có ở trong này. Vì vậy, khi vẽ usecase cần lưu ý những chức năng nào cần thực hiện thì phải để ở trong system boundary --- Trả lời câu hỏi 5 ở trên
- Actor: có nhiệm vụ thể hiện những user tham gia vào hệ thống. Trong một vài trường hợp, actor cũng có thể được thể hiện là hình chữ nhật để đại diện cho một sơ đồ usecase khác
- Usecase: đóng vai trò là chức năng của hệ thống, được kết hợp bởi động từ + danh từ và được dùng để thể hiện một hành động nào đó. Mỗi actor cần phải liên kết với 1 use case, tuy nhiên một vài use case có thể không liên kết với actor nào
- Relationship: mối liên hệ, sau này phân tách ra mối liên hệ giữa actor với usecase/các actor/các usecase
Tiếp đến câu 6: Khái niệm về UseCase:
Theo wikipedia định nghĩa, Use Case (Trường hợp sử dụng) là “Một kỹ thuật được dùng trong kỹ thuật phần mềm và hệ thống để nắm bắt yêu cầu chức năng hệ thống. Use Case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (Actor) và hệ thống.”
Use Case mô tả sự tương tác giữa người dùng và hệ thống ở trong một môi trường cụ thể, vì một mục đích cụ thể. Môi trường nằm trong một bối cảnh, phạm vi hoặc hệ thống phần mềm cụ thể. Mục đích cụ thể là diễn tả được yêu cầu theo góc nhìn từ phía người dùng.
Trả lời cho câu hỏi tại sao phải sử dụng UseCase:
- Giống như một bản hợp đồng giữa người phát triển phần mềm và khách hàng.
- Là công cụ mạnh mẽ cho việc lập kế hoạch. Được dùng trong tất cả các giai đoạn trong quy trình phát triển hệ thống :
+ Khách hàng phê chuẩn biểu đồ use-case
+ Sử dụng biểu đồ use case để thảo luận với khách hàng.
+ Các thành viên tham gia vào dự án, sử dụng mô hình này để hiểu rõ hơn về hệ thống
Để giải thích rõ hơn về khái niệm chúng ta cùng trả lời cho câu 3: Cách xác định actor như thế nào?
Hiểu về Tác nhân:
- Một người dùng cụ thể có thể đóng vai trò là các tác nhân khác nhau, có nghĩa là người đó có nhiều vai trò khác nhau trong hệ thống
- Không phải là một phần của hệ thống
Vidu:
(Tác nhân KHÔNG phải là một phần của hệ thống
Tác nhân trao đổi thông tin với hệ thống:
+ Gửi thông tin tới hệ thống
+ Nhận thông tin từ hệ thống)
Các xác định tác nhân:
Actor là thành phần chỉ người dùng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống. Để xác nhận đó có phải là Actor hay không thì cần xem xét dựa và những câu hỏi sau:
- Ai là người sử dụng chức năng chính của hệ thống (tác nhân chính)?
- Ai sẽ là admin của hệ thống – Người cài đặt, quản lý và bảo trì hệ thống (tác nhân phụ)?
- Ai sẽ cần hệ thống hỗ trợ để thực hiện các tác vụ hằng ngày?
- Hệ thống này có cần phải tương tác với các hệ thống nào khác không?
- Ai là người input dữ liệu vào hệ thống (trường hợp hệ thống lưu trữ dữ liệu)?
- Ai hay cái gì quan tâm đến giá trị mà hệ thống sẽ mang lại?
Trả lời tiếp câu 4: Usecase gồm những gì?
Khái niệm UseCase:
− Mô tả chức năng của hệ thống, là một chuỗi các hành động của hệ thống thực hiện nhằm thu được một kết quả dễ thấy tới một tác nhân nào đó.
− Một use case mô hình hóa một hội thoại giữa một hoặc nhiều tác nhân với hệ thống
− Một use case mô tả hành động của hệ thống thực hiện nhằm mang đến một giá trị nào đó cho tác nhân.
Cách xác định Usecase:
Use Case là các chức năng mà các Actor sẽ sử dụng hay thể hiện sự tương tác giữa người dùng và hệ thống. Để tìm ra được các Use Case, ta cần trả lời những câu hỏi sau:
- Actor cần những chức năng nào của hệ thống?
- Actor có hành động chính là gì?
- Actor có cần đọc, thêm mới, hủy bỏ, chỉnh sửa hay lưu trữ loại thông tin nào trong hệ thống không?
- Hệ thống có cần thông báo những thay đổi bất ngờ trong nội bộ cho Actor không?
- Công việc hàng ngày của Actor có thể được đơn giản hóa hoặc hữu hiệu hóa qua các chức năng của hệ thống?
- Use Case có thể được tạo ra bởi sự kiện nào khác không?
- Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đó sẽ đi từ đâu đến đâu?
- Những khó khăn và thiếu hụt của hệ thống hiện tại nằm ở đâu?
Sau khi xác định được actor, usecase cho biểu đồ UseCase thì chúng ta sẽ quan tâm tiếp đến đâu hỏi số 8: Mối quan hệ giữa Actor với UseCase, giữa các actor với nhau, giữa các usecase với nhau? Và giải thích cho Hình 1.
− Mối liên hệ giữa các actor với nhau
+ Khái quát hóa (Generalization)
+ Giao tiếp(Association)
− Mối liên hệ giữa actor và use case
+ Giao tiếp (Association)
− Mối liên hệ giữa các use case với nhau
+ Generalization: Khái quát hóa
+ Include: Bao hàm
+ Extend: Mở rộng
Giải thích kỹ hơn về mối liên hệ:
1. Generalization: Khái quát hóa
Generalization là mối quan hệ cha con giữa các Use Case với nhau. Generalization còn thể hiện khả năng thể hiện mối quan hệ giữa các Actor với nhau.
Ví dụ: Mối quan hệ cha – con giữa các Use Case:
- Đăng nhập (cha): Có thể thông qua số điện thoại (con) hoặc Email (con).
- Đặt hàng (cha): Có đặt hàng qua số điện thoại (con) hoặc website (con).
Ví dụ: Mối quan hệ cha – con giữa các Actor:
Khách hàng (cha): Gồm khách hàng cũ (con) và khách hàng mới (con).
2. Association: Giao tiếp
- Quan hệ giao tiếp (Association) giữa Actor và Use Case: Quan hệ giao tiếp giữa Actor và Use Case biểu diễn bởi mũi tên hay đường thẳng nối Actor với Use Case.
Một Actor có thể được kết hợp với một hoặc nhiều Use Case, và một Use Case có thể được kết hợp với một hoặc nhiều Actor. Use Case được cài đặt thành một vài Module chương trình và các Actor sẽ sử dụng chương trình này bằng cách nhập thông tin vào, nhận thông tin ra. Nghĩa là con người hoặc hệ thống, trong vai trò Actor này, sẽ giao tiếp với các thể hiện của Use Case, tham gia chuỗi các sự kiện được Use Case biểu diễn cho biết có một kết hợp giữa một Actor và một Use Case.
Association được biểu diễn bằng một đường thẳng thể hiện sự tương tác giữa việc actor nhập thông tin vào và nhận thông tin ra từ usecase
Association được biểu diễn bằng một đường thẳng chứa mũi tên, cho thấy mối quan hệ hai chiều giữa các thành phần.
Chiều của quan hệ chính là chiều của tín hiệu gửi đi:
- Từ tác nhân tới Use Case:
+ Kích hoạt Use case
+ Hỏi thông tin nào đó trong hệ thống
+ Thay đổi thông tin nào đó trong hệ thống
+ Thông báo cho UC về một sự kiện đặt biệt nào đó xảy ra với hệ thống
- Từ Use Case tới tác nhân:
+ Nếu như có một điều gì đó xảy ra với hệ thống và tác nhân đó cần được biết sự kiện đó
+ UC đôi khi cần hỏi thông tin nào đó từ một tác nhân trước khi UC đó đưa ra một quyết định
3. Include: Bao hàm
Include là mối quan hệ bao gồm hoặc bắt buộc phải có giữa các Use Case với nhau. Hiểu đơn giản hơn: Để Use Case A xảy ra thì phải đạt được Use Case B.
Ví dụ: Use Case A rút tiền xảy ra thì Use Case B xác thực tài khoản phải hoàn thành.
4. Extend: Mở rộng
Extend biểu diễn mối quan hệ mở rộng, không bắt buộc, có thể có hoặc không giữa các Use Case với nhau.
Ví dụ hình ảnh ở trên: các usecase Tạo tài khoản mới hay Lấy lại mật khẩu không bắt buộc xảy ra cùng với usecase Đăng nhập. Nó chỉ xảy ra khi người dùng có nhu cầu tạo tài khoản mới hoặc lấy lại mật khẩu.
Mục quan tâm sau khi xác định usecase, actor thì sẽ phải quan tâm các lưu ý khi đặt tên cho actor và usecase – trả lời cho câu 9:
Lưu ý cho Usecase:
- Tên của UC nên chỉ rõ kết quả của quá trình tương tác với tác nhân
+ Tên nên là động từ
+ Mô tả ngắn gọn về mục đích của UC
- Tạo ra các UC quá nhỏ:
+ Hành động quá đơn giản mà chỉ cần mô tả bởi vài dòng
- Tạo ra quá nhiều Use case (hàng chục):
+ Nhóm các Use case liên quan thành một Use case tổng quát (mức 1)
+ Mô tả các Use Case tổng quát ở một sơ đồ khác (mức 2)
Ví dụ: “Quản lý sách” bao gồm “Nhập sách”, “Xuất sách”, “…”
- Sử dụng các Use-case quá cụ thể, hoặc làm việc với dữ liệu quá cụ thể. Ví dụ:
+ “Tìm sách theo tên” (nên là “Tìm sách”)
+ “Nhập Pin vào máy ATM” (nên là “Nhập PIN”)
+ “Thêm sách” (nên là “Quản lý sách” bao gồm “Thêm sách”)
Lưu ý cho Actor:
− Tên tác nhân phải mô tả vai trò của tác nhân đó một cách rõ ràng
− Tên nên là danh từ
− Cần mô tả khái quát khả năng của tác nhân đó
Câu 7: UseCase tổng quan và UseCase phân rã khác nhau như nào?
Sau khi đọc hết blog này bạn sẽ có thể vẽ được một biểu đồ UseCase, nhưng biểu đồ Usecase lại được chia ra là 2 dạng: UseCase tổng quan và UseCase phân rã
Để hiểu kỹ hơn bạn hãy đọc thêm 2 blog này của mình nữa nè: UseCase tổng quan, UseCase phân rã
III.Tổng kết mục đích bạn sẽ nắm được ở phần này:
1. Hiểu rõ các thành phần trong biểu đồ Usecase
2. Xác định được actor tương tác với hệ thống là ai.
3. Xác định được Usecase trong hệ thống
4. Hiểu được mối quan hệ giữa actor – usecase, actor-actor, usecase-usecase
IV. Câu hỏi
1. Khi nào chúng ta sử dụng liên kết << extend>> và <<include>>?
2. Xác định tác nhân bằng cách nào?
3. Phân biệt sự khác nhau giữa người dùng và tác nhân
Tổng kết:
Xây dựng Biểu đồ use case: Dựa trên tập yêu cầu ban đầu, người phân tích tiến hành xác định các tác nhân, use case và các quan hệ giữa các use case để mô tả lại các chức năng của hệ thống. Một thành phần quan trọng trong biểu đổ use case là các kịch bản mô tả hoạt động của hệ thống trong mỗi use case cụ thể.
Nếu có thắc mắc gì hãy để lại cmt mình giải đáp. Nếu bạn là người mới bắt đầu với nghề Tester ( sinh viên, người trái ngành) hay liên hệ mình để được coaching 1-1 nha, email mình: donghanhcungtester@gmail.com
Hoặc mời mình 1 cốc trà sữa nè!
Cảm ơn các bạn đã ghé qua Blog của mình!
Để lại một câu trả lời
Để làm việc được tốt bạn hãy hiểu về mục đích, luồng hoạt động của nó, sau đó mới là tìm hiểu sử dụng công cụ hỗ trợ nó. Blog của mình sẽ hướng các bạn sinh viên và các bạn trái ngành đi từ đầu hiểu bản chất cơ bản vững chắc sau đó là mở rộng hơn