Trường hợp sử dụng có thể không có diễn viên không?

Question

Tôi đang làm việc trên sơ đồ ca sử dụng của một hệ thống hoàn toàn tự động. Một hệ thống bên ngoài sẽ chỉ kích hoạt một trường hợp sử dụng của hệ thống này. Hầu hết các trường hợp sử dụng khác là các tác vụ được lên lịch và được bộ hẹn giờ gọi. Tôi có một trường hợp sử dụng được gọi bởi bộ đếm thời gian và nó bao gồm và mở rộng hai trường hợp sử dụng khác.

Khi tôi viết sử dụng trường hợp discriptions, ai sẽ là diễn viên cho UC-2 và UC-3. Trường hợp sử dụng có thể tồn tại mà không có diễn viên không? Tôi đã thấy nhiều sơ đồ ca sử dụng đã bao gồm hoặc mở rộng các trường hợp sử dụng mà không trực tiếp kết nối với một diễn viên. Vui lòng làm rõ điều này. Cảm ơn trước.

EDIT: Hệ thống của tôi được kết nối với DBMS. Hệ thống của tôi sẽ phân tích thời gian tải công việc cơ sở dữ liệu theo thời gian và kiểm tra xem có thể thực hiện bất kỳ điều chỉnh nào không. Đó là tất cả về hệ thống của tôi. UC-1 là phân tích DBMS, UC-2 là kiểm tra thống kê hiệu suất và UC-3 là điều chỉnh cơ sở dữ liệu. Vì vậy, hẹn giờ là một trong đó gọi trường hợp sử dụng. DBMS nhận được lợi ích. Các bước trong Kiểm tra Hiệu suất (UC-2) được lặp lại trong một trường hợp sử dụng khác. Đó là lý do tại sao tôi đặt nó như một trường hợp sử dụng riêng biệt. Mặt khác, cơ sở dữ liệu Tune (UC-3) sẽ chỉ được thực hiện nếu có nhu cầu điều chỉnh sau khi phân tích cơ sở dữ liệu.

Answer 1

Chính thức điều này là chính xác. Một trường hợp sử dụng bao gồm là một phần bắt buộc của trường hợp sử dụng bao gồm và trường hợp sử dụng mở rộng sẽ tùy ý mở rộng một số trường hợp sử dụng. Vì @Ister ghi chú trong nhận xét, diễn viên cho các trường hợp sử dụng được bao gồm/mở rộng sẽ là trường hợp sử dụng chính.

Nhưng, và điều này từ trải nghiệm của tôi, bạn nên tránh sử dụng những mối quan hệ bao gồm/mở rộng đó. Trong hầu hết các trường hợp, mọi người có khuynh hướng sử dụng chúng để phân hủy chức năng, điều này là sai. Một ca sử dụng sẽ hiển thị một giá trị gia tăng cho tác nhân của nó, không phải là một phần chức năng được sử dụng ở đâu đó. Trong hầu hết các trường hợp, cấu trúc của giá trị gia tăng không có mặt và bạn cũng có thể hiển thị từng bong bóng như một trường hợp sử dụng độc lập hoặc tích hợp nó vào trường hợp sử dụng chính. Tôi khuyên bạn nên đọc Bittner/Spence để đi sâu vào vấn đề.

Edit1: Tôi chỉ nhận ra câu

kích hoạt chỉ là một trường hợp sử dụng của hệ thống này

này chứ không phải vẻ như bạn trộn trường hợp sử dụng với các hoạt động. Nó không phải là một phần chức năng. Một trường hợp sử dụng được thêm giá trị. Có một kịch bản (bộ) cho một ca sử dụng có kích hoạt. Nhưng nói "một trường hợp sử dụng được kích hoạt" âm thanh chỉ là sai. Bạn kích hoạt các hoạt động của một trường hợp sử dụng (nơi nó bắt đầu nhận được kỹ thuật). Hầu hết các nhà kỹ thuật đều gặp khó khăn trong việc cắt giảm và trừu tượng hóa các trường hợp sử dụng. Một lý do nữa để đọc Bittner/Spence.

Chỉnh sửa2: Trong nhận xét của bạn, bạn đang nói về các trường hợp sử dụng kỹ thuật. Tôi thừa nhận rằng tôi đã thảo luận chuyên sâu về điều này trong quá khứ. Nhưng bạn cần phải phân biệt giữa kỹ thuật và kinh doanh. Các trường hợp sử dụng nghiệp vụ của bạn là Analyse DBMS, Check Performance và Tune database. Vì vậy, chúng không phải là UCs cho một số Timer nhưng đối với một số tổ chức quan tâm đến hiệu suất. UC duy nhất cho Timer là Trigger task (hoặc một cái gì đó tương tự). Có một vết cắt. Các Timer không quan tâm đến kinh doanh. Nó sẽ vui vẻ kích hoạt tắt máy của hệ thống trong cùng một cách. Nó không trở thành một diễn viên kinh doanh chỉ vì thực tế rằng nó được sử dụng về mặt kỹ thuật để bắt đầu một số quy trình kinh doanh có liên quan.

Và đừng quên: đọc Bittner/Spence. Đối với tôi cuốn sách này là một mở mắt vì tôi cũng không có ý tưởng về ý định của các trường hợp sử dụng.

Answer 2

Trường hợp sử dụng luôn là trường hợp được thực hiện bởi (các) diễn viên. Trong tình huống của bạn, diễn viên chính là hệ thống đang được thảo luận.

Về mặt kỹ thuật, bạn có thể giới thiệu bộ hẹn giờ làm diễn viên thực hiện bước UC-1 đầu tiên, nhưng tốt hơn là KISS. Chỉ cần thêm một dòng trước các bước UC-1 thông qua quy ước chung:
Trigger: timer according to [Link to requirements about timer schedule].
Nếu bạn phải viết điều gì đó ngoài dòng này (ví dụ kiểm tra hẹn giờ trước khi kích hoạt UC-1) thì giờ phải trở thành diễn viên.

Nhìn chung, cấu trúc trường hợp sử dụng của bạn trông rất hợp lệ đối với tôi, đừng quên kết nối UC-1 với một số mục tiêu cao hơn. Và vui lòng xóa mở rộng/bao gồm như đã đề cập.

Answer 3

Có khả năng UC2 và UC3 không thực sự sử dụng các trường hợp nhưng thực tế là các bước/hành động trong UC1. Một cách hay để kiểm tra xem bạn có trường hợp sử dụng thực là hỏi bản thân của bạn nếu có bất kỳ diễn viên nào (con người, hệ thống hoặc thời gian, v.v.) sẽ có trường hợp sử dụng đó làm mục tiêu hoàn chỉnh. Nói cách khác, bất kỳ diễn viên nào cũng bắt đầu trường hợp sử dụng này. Ngoài việc này - Thỉnh thoảng bạn có thể có trường hợp sử dụng không có tác nhân khởi tạo. Điều này sẽ chỉ xảy ra trong trường hợp có nhiều trường hợp sử dụng khác (nghĩa là ít nhất 2) sẽ bao gồm hoặc mở rộng trường hợp sử dụng đó. Trong trường hợp này, trường hợp sử dụng có mục đích tạo điều kiện tái sử dụng trong mô hình của bạn và đơn giản hóa mô hình - đặc biệt khi bạn viết câu chuyện về ca sử dụng của mình. Đừng đi ra khỏi con đường của bạn để tạo ra bao gồm và mở rộng các mối quan hệ luôn luôn kiểm tra đôi - nếu không có diễn viên đang sử dụng trường hợp sử dụng bạn đang bao gồm hoặc mở rộng và không có trường hợp sử dụng khác đang sử dụng nó thì bạn hoàn toàn không cần nó.