正在生成/查看報告的有效用例嗎？

如果我們將「取消訂單」用例，用戶可能必須在從訂單列表中取消特定訂單之前查看所有訂單。正如我所看到的，「查看訂單」是「取消訂單」用例的前提條件。正在生成/查看報告的有效用例嗎？

而且還可以有其他使用情況，如查看/生成列表或報告。這些在用例圖中是否有效？

來源

2017-07-31 Harshakj89

用戶可能必須在取消之前查看所有訂單......「查看訂單」是「取消訂單」用例的先決條件。

在你的情況下，它不是一個先決條件。這是「取消訂單」用戶目標用例中的一個步驟。「查看訂單」用例可以擴展此步驟（或根據您描述的級別保留爲單個步驟）（如果用戶可能爲視圖）或包含（如果用戶必須爲視圖）。

其他用例如查看/生成列表或報告。這些在用例圖中是否有效？

最有可能你正面臨着（注意用例的標題）：

用戶目標的用例類似Accountant orders [payments/agents/etc.] report步驟System generates [payments/agents/etc.] report。（請記住，用戶永遠不會有意向的系統「，現在我想生成報告」，用戶需要一些更高的目標報告）。
子功能用例System generates [payments/agents/etc.] report。

如果您的圖表全部是關於用戶目標用例和層次結構中更高的 - 不要犧牲子功能的可讀性。更好地爲特定業務流程或應用程序域創建單獨的圖表。

來源

2017-07-31 19:11:32 Vlad

通常情況下，用例顯示了一個單一的附加價值，一個考慮中的系統返回給參與者。現在，什麼是附加價值？有時候要看情況。特別是當你與CRUD打交道時，討論往往會最終將頭髮分開。因此，對於「創建/讀取/更新/刪除X」顯示單獨的UCs還是將它們彙總到單個「管理X」中，最好取決於單個CRUD部件的重要性。如果觀看是一個非常重要的部分，因爲它大部分時間完成，並且CUD絕對是它的一部分，它們應該被拆分。如果你做所有CRUD操作的強度差不多一樣，那麼使用單一統一通信系統會更好。

來源

2017-07-31 11:15:18

生成報告 - 是的。更重要的是，不僅可以爲不同類型的用戶提供報告，還可以爲SW的支持者區分報告。

但是別忘了，您還應該從DB生成SQL報告的角度報告高層次的，可以根據需要或自動完成幷包含一些集中信息的報告。您可以編寫不同抽象層次的用例。對於面向人的用例，第一個報告是可以的，而對於更具體的用例，DB報告是可以的。這些最後的那些並不經常使用。

因此，我們可以設想一個表：

      high level     low level 
Users      useful/usual    The reports themselves are not useful 
Support/lisense team  useful/not so usual   useful/usual

在這裏，你有這樣的用例元素報表和頻率使用等情況下使用的有效性。

來源

2017-07-31 13:26:22 Gangnus

正在生成/查看報告的有效用例嗎？

回答

相關問題