2.3 描述用例規約
應該避免這樣一種誤解――認為由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對于系統的功能有一個總體的認識。除此之外，我們還需要描述每一個有例的詳細信息，這些信息包含在用例規約中，用例模型是由用例圖和每一個用例的詳細描述――用例規約所組成的。RUP中提供了用例規約的模板，每一個用例的用例規約都應該包含以下內容：
簡要介紹該用例的作用和目的。 事件流 (Flow of Event)
包括基本流和備選流，事件流應該表示出所有的場景。 用例場景 (Use-Case Scenario)
包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。 特殊需求 (Special Requirement)
描述與該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的操作系統、開發工具等）。 前置條件 (Pre-Condition)
執行用例之前系統必須所處的狀態。 后置條件 (Post-Condition)
用例執行完畢后系統可能處于的一組狀態。
用例規約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態圖、活動圖或序列圖來輔助說明。只要有助于表達的簡潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其他圖形。如活動圖有助于描述復雜的決策流程，狀態轉移圖有助于描述與狀態相關的系統行為，序列圖適合于描述基于時間順序的消息傳遞。
2.3.1 基本流
基本流描述的是該用例最正常的一種場景，在基本流中系統執行一系列活動步驟來響應參與者提出的服務請求。我們建議用以下格式來描述基本流：
(1) 每一個步驟都需要用數字編號以清楚地標明步驟的先后順序。
(2) 用一句簡短的標題來概括每一步驟的主要內容，這樣閱讀者可以通過瀏覽標題來快速地了解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標題這一層，以免過早地陷入到用例描述的細節中去。
(3) 當整個用例模型基本穩定之后，我們再針對每一步驟詳細描述參與者和系統之間所發生的交互。建議采用雙向(roundtrip)描述法來保證描述的完整性，即每一步驟都需要從正反兩個方面來描述:(1)參與者向系統提交了什么信息；(2)對此系統有什么樣的響應。具體例子請參見附錄。
在描述參與者和系統之間的信息交換時，需指出來回傳遞的具體信息。例如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說參與者輸入了客戶姓名和地址。通�？梢岳迷~匯表讓用例的復雜性保持在可控范圍內，可以在詞匯表中定義客戶信息等內容，使用例不至于陷入過多的細節。
2.3.2 備選流
備選流負責描述用例執行過程中異常的或偶爾發生的一些情況，備選流和基本流的組合應該能夠覆蓋該用例所有可能發生的場景。在描述備選流時，應該包括以下幾個要素：
(1) 起點：該備選流從事件流的哪一步開始；
(2) 條件：在什么條件下會觸發該備選流；
(3) 動作：系統在該備選流下會采取哪些動作；
(4) 恢復：該備選流結束之后，該用例應如何繼續執行。
備選流的描述格式可以與基本流的格式一致，也需要編號并以標題概述其內容，編號前可以加以字母前綴A(Alternative)以示與基本流步驟相區別。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
