用例建模指南

領測軟件測試網

提款-備選事件流

　　備選流一：用戶可以在基本流中的任何一步選擇退出，轉至基本流步驟5。

　　備選流二：在基本流步驟1中，用戶插入無效信用卡，系統顯示錯誤并退出信用卡，用例結束。

　　備選流三：在基本流步驟２中，用戶輸入錯誤密碼，系統顯示錯誤并提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯誤后，信用卡被系統沒收，用例結束。

　　…

　　通過基本流與備選流的組合，就可以將用例所有可能發生的各種場景全部描述清楚。我們在描述用例的事件流的時候，就是要盡可能地將所有可能的場景都描述出來，以保證需求的完備性。

1.3 用例方法的優點

　　 用例方法完全是站在用戶的角度上（從系統的外部）來描述系統的功能的。在用例方法中，我們把被定義系統看作是一個黑箱，我們并不關心系統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統發生交互；針對每一參與者，用例方法又描述了系統為這些參與者提供了什么樣的服務（抽象成為Use Case），或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統的一個總體印象。

　　與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用于表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。用例方法比傳統的SRS更易于被用戶所理解，它可以作為開發人員和用戶之間針對系統需求進行溝通的一個有效手段。

　　在RUP中，用例被作為整個軟件開發流程的基礎，很多類型的開發活動都把用例作為一個主要的輸入工件(Artifact)，如項目管理、分析設計、測試等。根據用例來對目標系統進行測試，可以根據用例中所描述的環境和上下文來完整地測試一個系統服務，可以根據用例的各個場景(Scenario)來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。

2. 建立用例模型

　　 使用用例的方法來描述系統的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內容：

用例圖(Use Case Diagram)
確定系統中所包含的參與者、用例和兩者之間的對應關系，用例圖描述的是關于系統功能的一個概述。 用例規約(Use Case Specification)
針對每一個用例都應該有一個用例規約文檔與之相對應，該文檔描述用例的細節內容。

　　在用例建模的過程中，我們建議的步聚是先找出參與者，再根據參與者確定每個參與者相關的用例，最后再細化每一個用例的用例規約。

2.1 尋找參與者

　　 所謂的參與者是指所有存在于系統外部并與系統進行交互的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：

系統開發完成之后，有哪些人會使用這個系統？ 系統需要從哪些人或其他系統中獲得數據？ 系統會為哪些人或其他系統提供數據？ 系統會與哪些其他系統相關聯？ 系統是由誰來維護和管理的？

　　這些問題有助于我們抽象出系統的參與者。對于ATM機的例子，回答這些問題可以使我們找到更多的參與者：操作員負責維護和管理ATM機系統、ATM機也需要與后臺服務器進行通訊以獲得有關用戶帳號的相關信息。

文章來源于領測軟件測試網 http://www.kjueaiud.com/