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/