3.3 基于場景建模

用戶滿意度是度量基于計算機系統或產品成果的最重要的方式之一。因此，如果軟件工程師了解最終用戶（和其他參與者）希望如何與系統交互，軟件團隊就能夠更好、更準確地刻畫需求特征，完成有針對性的分析和設計模型。因此，使用UML需求建模將從開發用例、活動圖和泳道圖形式的場景開始。

3.3.1 新建初始用例

用例從某個特定參與者的角度出發，采用簡明的語言描述一個特定的使用場景。如果想讓用例真正有價值，就必須知道：①編寫什么？②應該有多詳細？③如何組織說明？

需求工程工作首先是起始和導出，它們提供了開始編寫用例所需要的信息。運用需求收集會議、QFD和其他需求工程機制來確定干系人，定義問題范圍，說明整體運行目標，建立優先級順序，概述所有已知的功能需求，描述系統將處理的信息（對象）。

開發用例時，應列出特定參與者執行的功能或活動。這些可以從所需系統功能的列表，通過與干系人交流，或通過評估活動圖（作為需求建模中的一部分而開發）獲得。

3.3.2 細化初始用例

為了全面理解用例描述功能，描述交互操作是非常必要的。因此，主場景中的每個步驟將通過如下提問得到評估。

●在這一狀態點，參與者能進行一些其他動作嗎？

●在這一狀態點，參與者有沒有可能遇到錯誤的條件？如果有可能，這些錯誤會是什么？

●在這一狀態點，參與者有沒有可能遇到其他行為（如由一些參與者控制之外的事件調用）？如果有，這些行為是什么？

這些問題的答案導致創建一組次場景（Secondary Scenarios）。次場景屬于原始用例的一部分，但是表現了可供選擇的行為。

用例應該注明異常處理，即如果軟件能檢測出異常所發生的條件，就應該在檢測出后馬上處理這個條件。在某些情況下，異常處理可能拖累影響其他用例處理條件的開發。

3.3.3 編寫正規用例

當一個用例包括關鍵活動或描述一套具有大量異常處理的復雜步驟時，應采用更為正規的方法。在很多情況下，不需要創建圖形化表示的用戶場景。然而，當場景比較復雜時，圖形化表示將更有助于理解。UML提供了圖形化表現用例的能力。圖3-8所示為SafeHome產品描述了一個初步的用例圖，每個用例由一個橢圓表示。

圖3-8 SafeHome系統的初步用例圖

每種建模注釋方法都有局限，如果描述不清晰，用例也可能會誤導或產生歧義。一個用例關注功能和行為需求，一般不適用于非功能需求。用例方法不適用于必須特別詳細和精準的需求建模情景（如關鍵安全系統），但軟件工程師會遇到的絕大多數情境都適用于基于場景建模。如果開發得當，用例是重要的建模工具之一。