10 Mẹo để Tạo Sơ đồ Trường Hợp Sử dụng Chuyên nghiệp

Mô hình hóa Trường hợp Sử dụng là gì?

Mô hình hóa trường hợp sử dụng là câu trả lời đơn giản cho câu hỏi ‘Người dùng (khách hàng) muốn gì?’. Nó cho phép bạn biểu diễn trực quan điều mà người dùng muốn đạt được khi sử dụng sản phẩm cuối cùng, có thể là một hệ thống, một phần mềm, một chương trình, v.v. Mô hình hóa trường hợp sử dụng là một kỹ thuật hữu ích, cung cấp cho các nhà phát triển phần mềm nền tảng vững chắc để xây dựng các hệ thống phần mềm đáp ứng nhu cầu khách hàng.

Mặc dù ký hiệu được áp dụng trong sơ đồ trường hợp sử dụng có vẻ đơn giản và không truyền tải nhiều chi tiết, cách thu thập, tổ chức và phát triển các trường hợp sử dụng lại ảnh hưởng lớn đến hướng đi của vòng đời phát triển phần mềm, và do đó ảnh hưởng đến chất lượng sản phẩm phần mềm cuối cùng.

10 Mẹo Thực tế cho Mô hình hóa Trường hợp Sử dụng

Trong bài viết này, chúng tôi sẽ đi qua mười mẹo để tối đa hóa hiệu quả của việc vẽ sơ đồ trường hợp sử dụng. Chúng tôi sẽ không giải thích chi tiết trường hợp sử dụng là gì, mà sẽ đề cập đến một số khái niệm chính về mô hình hóa UML, sơ đồ trường hợp sử dụng và thu thập yêu cầu.

1. Suy nghĩ từ góc nhìn người dùng cuối

Rõ ràng rằng bạn cần biết mong đợi của người dùng để xây dựng một hệ thống phần mềm hoạt động tốt, và nguyên tắc này đặc biệt quan trọng trong mô hình hóa trường hợp sử dụng. Nhiều người đã nhầm lẫn rằng mô hình hóa trường hợp sử dụng là một quá trình mô hình hóa các chức năng hệ thống, điều này có thể sai. Chính xác hơn, mô hình hóa trường hợp sử dụng là cách mô hình hóa những gì người dùng muốn. Mỗi trường hợp sử dụng trong sơ đồ trường hợp sử dụng nên tạo ra một mục tiêu quan sát được thông qua tương tác của người dùng với phần mềm hoặc hệ thống cuối cùng. Đôi khi, mục tiêu người dùng giống với một chức năng hệ thống nhưng điều này không phải lúc nào cũng đúng. Ví dụ, ‘Đăng nhập’ là một chức năng hệ thống nhưng chắc chắn không phải là mục tiêu người dùng – Không ai sẽ khởi chạy chương trình, đăng nhập rồi rời đi! Vì vậy, càng vẽ nhiều chức năng hệ thống trong sơ đồ trường hợp sử dụng, mô hình trường hợp sử dụng càng ít hiệu quả trong việc thể hiện mong đợi thực tế của người dùng trong suốt quá trình phát triển phần mềm. Do đó, khi bạn phát triển mô hình trường hợp sử dụng, hãy cố gắng diễn đạt mọi thứ bằng cách trước tiên suy nghĩ từ góc nhìn người dùng cuối.

2. Tránh đặt tên trường hợp sử dụng quá dài

Nếu bạn đang đọc một sơ đồ trường hợp sử dụng được chuẩn bị cho hệ thống ATM, bạn muốn thấy trường hợp sử dụng nào trong số các trường hợp sau đây? ‘Rút tiền’ và ‘Rút tiền và Cập nhật số dư trong tài khoản’. Trường hợp sử dụng thứ hai dường như mô tả chi tiết hơn, đúng không? Còn nếu bạn có 50+ trường hợp sử dụng khác nhau với tên dài như vậy thì sao? Có lẽ bạn sẽ không muốn đọc sơ đồ nữa và có thể mắt bạn sẽ đau.

Một trong những lý do chúng ta cần mô hình hóa là vì chúng ta muốn hiểu một hệ thống phần mềm phức tạp một cách dễ dàng và đơn giản. Đó là lý do tại sao UML đã cung cấp cho chúng ta nhiều loại ký hiệu khác nhau, mỗi loại đại diện cho một góc nhìn cụ thể trong việc mô tả một hệ thống phần mềm hoàn chỉnh. Tinh thần này cũng áp dụng cho việc đặt tên cho các trường hợp sử dụng. Nếu chúng ta cố gắng đặt tên cho các trường hợp sử dụng bằng mô tả chi tiết, tại sao chúng ta không dùng file văn bản thay vì vậy? Để sơ đồ trường hợp sử dụng dễ hiểu, điều quan trọng là giữ tên các trường hợp sử dụng ngắn gọn nhưng vẫn mang tính mô tả. Hãy giữ tên ngắn và để phần mô tả chi tiết vào phần mô tả của các trường hợp sử dụng.

3. Người diễn viên là một vai trò, chứ không phải là một con người thực sự

Một số người cố gắng biểu diễn nhân viên trong một tổ chức như các người diễn viên trong sơ đồ use case, dẫn đến việc có một sơ đồ với Peter, Mary, Daisy, v.v. Nhớ rằng, một người diễn viên đại diện cho một vai trò duy nhất bao gồm con người, hệ thống con hoặc bất kỳ thực thể nào khác có đặc điểm riêng và chia sẻ cùng mục tiêu và kỳ vọng.

4. Mô hình hóa use case chung bằng mối quan hệ

Một use case đại diện cho một mục tiêu người dùng, có thể đạt được bằng cách đi qua một chuỗi các bước. Khi các bước giống hệt nhau xuất hiện trong nhiều use case, bạn có thể tùy chọn tạo một use case mới cho các bước chung và kết nối nó với các use case kích hoạt các bước đó. Bằng cách sử dụng use case được bao gồm, điều này làm rõ rằng các use case bao gồm thực sự chia sẻ cùng một tập hợp các bước như được biểu diễn bởi các use case được bao gồm, không có sự mơ hồ.

5. Mô hình hóa hành vi ngoại lệ

Mối quan hệ Extend có thể được sử dụng để xác định khi nào và như thế nào hành vi của một use case có thể bị kích hoạt bởi một use case khác. Việc mở rộng diễn ra tại các điểm mở rộng được xác định trong use case được mở rộng. Use case mở rộng xác định các bước có thể được thực hiện bởi use case được mở rộng dưới các điều kiện cụ thể.

6. Mô hình hóa tình huống với luồng sự kiện

Một use case đại diện cho một mục tiêu người dùng, có thể đạt được bằng cách đi qua một chuỗi các bước. Một số người cố gắng mô hình hóa các bước trực tiếp trên sơ đồ use case bằng cách kết nối người diễn viên và use case bằng rất nhiều mối quan hệ, giả vờ là các bước, điều này chắc chắn sai. Thay vào đó, các bước của use case có thể được mô tả tốt trong trình chỉnh sửa luồng sự kiện của use casetrình chỉnh sửa luồng sự kiện.

Trình chỉnh sửa luồng sự kiện ở dạng bảng, mỗi hàng đại diện cho một bước của use case. Bạn có thể ghi các bước đó, có hoặc không có luồng điều kiện. Bạn cũng có thể áp dụng định dạng văn bản để nhấn mạnh các ý tưởng chính.

7. Sử dụng tốt các stereotype để phân loại

Stereotype là một cơ chế cho phép bạn giới thiệu ký hiệu đặc thù lĩnh vực bên cạnh các ký hiệu chuẩn. Một stereotype được hiển thị trong cặp dấu guillemets, ở phía trên tên hình dạng khi áp dụng stereotype. Việc sử dụng stereotype một cách phù hợp giúp người đọc dễ dàng nhận ra sự khác biệt giữa các use case.

8. Mô hình hóa luồng hệ thống chi tiết bằng sơ đồ tuần tự

Sơ đồ tuần tựgiúp bạn mô hình hóa hành vi hệ thống bằng cách biểu diễn sự giao tiếp và trao đổi tin nhắn giữa các đối tượng theo thời gian. Nhưng bắt đầu từ đâu? Thay vì đoán xem nên mô hình hóa tương tác nào, bạn có thể bắt đầu bằng cách tham khảo nhu cầu của người dùng, chính xác là điều mà mô hình use case nhằm mục đích trình bày.

Chúng ta biết rằng mỗi use case đại diện cho một mục tiêu người dùng duy nhất. Việc vẽ sơ đồ tuần tự từ một use case ngụ ý rằng bạn đang mô hình hóa những gì hệ thống máy tính cần làm để đáp ứng nhu cầu người dùng. Về lý tưởng, sẽ không có thiết kế dư thừa vì tất cả các sơ đồ tuần tự đều được tạo từ các use case, đại diện cho những gì người dùng mong muốn.

9. Áp dụng cùng chiều rộng cho các use case khi phù hợp

Vì tên của các use case có độ dài khác nhau, nên việc các use case có chiều rộng khác nhau là điều bình thường. Để sơ đồ trở nên đẹp hơn và dễ đọc hơn, sẽ tốt nếu điều chỉnh chúng về cùng một chiều rộng.

10. Sắp xếp người diễn viên và use case theo cách có ý nghĩa

Một sơ đồ use case với các người diễn viên và use case được đặt ngẫu nhiên chắc chắn là cơn ác mộng đối với người đọc. Người đọc phải xem xét kỹ sơ đồ để tìm thông tin họ muốn từ các người diễn viên và use case rải rác. Sẽ tốt hơn nếu sắp xếp các hình dạng theo cách có trật tự. Bạn cũng có thể nhóm các use case bằng các hình dạng gói nếu cần thiết.