你會顯示一個Actor不能在用例圖上做的事情嗎？

Question

在用例圖上，您可以顯示演員不能所做的事情，例如因爲他們沒有權限執行此操作？

還是僅僅因爲他們沒有將他們加入特定用例的行而暗示？

Answer 1

如果用例圖表是一個演員試圖做某些不允許的事情，然後被拒絕的情況，那麼是的，我會展示它。

否則，我會堅持只包含實際上是用例的一部分的東西。

Answer 2

不可以。一個演員將被連接到他所能做的一切。如果演員不能這樣做，那麼它不會顯示。

Answer 3

您可以爲可以完成任務的角色扮演者建模。然後，您可以擁有另一個使用案例，其原始演員試圖獲取給定的角色。

Answer 4

這是替代路徑的用途。基本路徑（也稱爲快樂路徑）將顯示當正確的Actor啓動用例時發生的情況。在替代路徑中，您可以顯示如果錯誤的Actor嘗試啓動它會發生什麼。

Answer 5

恕我直言，這個問題和大多數的答案給用例的方式應該使用一個錯誤的印象。

用例用作使用自然語言的需求技術。這是最有效的方式。

當它與過多的UML /建模相結合時，它可能是徹底的破壞性技術。使用案例文本的結構化建模，例如通過使用UML活動圖建模主流和替代流程進行建模，這是一個久經考驗的方式，例如創建Use Cases of Mass Destruction。

用例圖可能很有用，但我們應該記住用例作爲一種技術的目的，該技術首先是識別系統應支持的用戶目標。隨後，我們可以使用自然語言在主要流程，替代流程等使用案例文本中捕獲更多細節。

使用圖表工具，我們可以看到一些簡單信息： - 對於每個用戶目標，我們可以創建模型元素類型用例。 - 使用帶有用例元素的系統的框顯示系統邊界。 - 在actor和use case之間創建關係以顯示actor對系統有一個特定的目標。

然而，保持映射到目標的演員的最新列表是次要的。進行利益相關者分析，制定參與者名單是識別用戶目標的手段。在確定了用戶目標後，嚴格來說不再需要保留演員名單。

如果我們詢問有關如何將用戶權限放入用例模型的問題，我們很可能會嘗試捕獲太多信息。我們應該抽象模型元素，以便模型不會嘗試回答/捕獲這些類型的詳細設計問題。