UML使用是否可以顯示演員可以做的所有事情（功能）或演員想要做的所有事情（目標）？

Question

假設我們有一個簡單的在線商店。事情是，用戶希望實現與商店將是：

1. 註冊（創建一個帳戶）
2. 瀏覽項目
3. 項目添加到購物籃
4. 結賬和支付
5. 查看帳戶信息
6. 編輯帳戶信息 等

然而，會有功能，用戶可以啓動，但不會是他們使用該系統的主要目標：

1. 登錄
2. 註銷
3. 選擇「電子產品」部門
4. 選擇「車輛「部門
5. 輸入交貨詳情 等

我認爲，之類的東西LOGI n和註銷不應該在UML用例圖中。原因是用戶不想去登錄的網上商店;他們總是會有另一個目標，即查看/編輯帳戶信息或瀏覽和購買東西。

同樣，這兩個select'語句'是瀏覽項目用例的一部分。我不會使用泛化，因爲可能有很多部門。

最後，輸入交付詳細信息是「結帳」或「編輯帳戶信息」用例的一部分。我通常會在'編輯帳戶信息'用例中使用這種情況，否則你可能會使用「編輯名稱」，「編輯電子郵件」等用例。

我主要關心的是如果你有非常複雜的用途案例圖它擊敗了一個人的目的，因爲它不容易閱讀。

所以，我的問題如下。我的想法背後是否正確？最好只在用例圖或者演員可以發起的所有事情中對'真正'的目標進行建模？

Answer 1

UML使用是否可以顯示演員可以做的所有事情（功能）或 演員想要做的一切（目標）？

它可以是 - UML規範在這方面沒有規定。 Alistair Cockburn創建了一個categorisation for Use Cases，表明他們關注的級別。

說了：

我最關心的是，如果你有一個非常複雜的用例圖，它 失敗有一個，因爲它不會是容易閱讀的目的。

這是一個非常真實的風險。就我個人而言，我發現我通過關注用戶和他們的目標，從UC獲得最大收益。他們希望從系統中獲得什麼價值？

保持在這個水平可以防止「看不見樹木」的情況 - 也阻止了UC成爲一個完整的功能分解設計。

hth。

Answer 2

從圖中排除一些用例並沒有錯，實際上它可能是一個好主意。例如，如果要將您的圖表顯示給業務部門，則可以繪製一個描述操作用例的UML模型。如果你要把你的圖表交給程序員，你會想給他們一個他們必須實現的完整描述。這些只是您的系統的型號。當用戶繪製用例圖時，通常還會寫出每個用例的行爲（如自由文本描述，僞代碼或使用交互圖）。

UML規範說：

用例是一組由系統執行的動作，其產生可觀察到的結果是，典型地，的值的一個或多個參與者或說明書該系統的其他利益相關者。

登錄和註銷可觀察到的用戶。雖然用戶不會以登錄的唯一目標訪問您的站點，但這種用例肯定有一些您也想描述的執行流程。如果您不允許用戶自行啓動登錄，將會出現包含登錄的功能。用戶在離開網站之前可能也有興趣退出，這樣就不會有會話數據保存在他的計算機中。

選擇「電子產品」部門，選擇「汽車」部門 ...爲什麼不只是選擇部門（我想，他們是不是太不一樣了）。

我會畫這個和其他用例，只要它們與模型相關。