如何識別 UML 建模中的用例

用例方法是一種識別系統業務目標的技術。用例的識別有助於定義系統範圍，確保找到的需求都與業務價值、需求和戰略保持一致。

用例分析中的參與者是什麼？

參與者指定用戶或與正在開發的系統交互的任何其他系統所扮演的角色。它可能代表人類用戶、外部硬件或其他主體所扮演的角色。參與者總是在系統之外，通過啟動用例、向它們提供輸入和/或從它們接收輸出來直接與用例交互。雖然單個物理實例可能扮演多個不同參與者的角色，但參與者不一定代表特定的物理實體，即觸發發送電子郵件警報的計時器。

識別用例——用例分析中參與者的特徵
簡單地列舉團隊成員對涉眾或目標用戶的看法，在討論中更容易達成共識。

1. Actor位於系統之外，不屬於系統的某個部分，所以我們不需要“構建”“actor”；
2. 只有能夠使用系統、與系統交互、與系統交換信息的人才是系統的參與者；
3. Actors 會啟動並參與用例，所以找到 Actors 可以指導我們找到用例；
4. 雖然我們不需要“開發參與者”，但我們需要考慮接口。系統需要考慮actor使用的接口（用戶體驗/GUI），或者係統需要通過actor提供的接口獲取數據。

演員是誰？問以下問題：

1. 誰會使用這個系統？
2. 誰來安裝這個系統？
3. 誰來啟動這個系統？
4. 誰來維護這個系統？
5. 誰來關閉這個系統？
6. 哪些其他系統將使用該系統？
7. 誰將從這個系統中獲得信息？
8. 誰將向該系統提供信息？
9. 當預設時間到來時，會自動發生一些事情嗎？
10. 哪些系統將與該系統聯網？
11. 是否有任何硬件設備連接到該系統？
12. 哪些數據庫將與該系統聯網？
13. 公司裡誰會使用這個系統？\
14. 誰會在公司之外使用這個系統？
15. 當特定時間或事件發生時，這個系統是否需要自動通知誰或其他系統？

演員類型

許多分析師在用例圖繪製過程中忽略了關鍵角色，因為他們只識別人類角色。以這種方式對用例參與者進行分類有助於分析師確保他們不會忽略用例圖中的任何關鍵參與者。

還有另一種對參與者進行分類的方法。他們可以：

• 人類
• 系統軟件
• 硬件
• 定時器/時鐘

識別用例的問題列表

1. 參與者希望從這個系統中獲得什麼樣的功能？
2. 該系統是否存儲信息？哪些參與者將創建、閱讀、更新和刪除這些信息？
3. 當系統內部狀態發生變化時，系統是否需要通知參與者？
4. 系統是否需要知道任何外部事件？當這個外部事件發生時，哪個參與者會通知系統？
5. 該系統是否需要定期執行任何操作？
6. 當一些重要的外部事件發生時，系統是否需要自動執行某些操作？
7. 這個用例的名稱是否足夠清楚？這個用例的結果可以直接從這個用例的名字來判斷嗎？
8. 這個用例會有多個結果嗎？或者這些結果是在不同的時間點產生的？