UML用例建模解析（三）

2. 編寫用例文件

繪製用例圖只是完成了用例建模最基本也是最簡單的一步，用例建模的核心在於編寫用例文件，用例文件又稱為用例規約或用例描述。顧名思義，用例文件是用於描述用例的文件，每一個用例對應於一個用例文件，在用例文件中需要用文字的方式描述用例的執行過程，即執行者與系統的互動過程。

 

用例文件需要通俗易懂，不僅專案的開發人員能夠理解，系統的使用者以及客戶也能夠看懂用例文件。一個完整的用例文件包括用例編號、用例名、執行者、前置條件、後置條件、涉眾利益、基本路徑、擴充套件路徑、欄位列表、業務規則、非功能需求和設計約束等組成部分。

 

一般在系統中需要給所有的用例一個統一規範的編號，如庫存管理系統，可以使用StockUC001、StockUC002等來對用例進行編號。每一個用例都需要提供一個清晰易懂的用例名，一般使用“動詞+名詞”的形式，如“檢視庫存報表”、“增加員工資訊”、“增加商品資訊”等，對於一些俗語可以使用簡寫，如“登入”、“註冊”、“入庫”、“出庫”等。

 

前置條件是用例執行之前系統所處的狀態，它必須是軟體系統可以識別到的狀態，如用例“入庫”的前置條件是“倉庫管理員已成功登入”，而不能是“倉庫管理員已開啟電腦”，因為是否“開啟電腦”庫存管理系統不能識別到；後置條件是用例執行之後系統應該具備的狀態，它也必須是系統能夠識別到的，如用例“入庫”的後置條件是“系統儲存入庫資訊，更新相關商品的庫存量”，而不能是“使用者退出系統”，因為“使用者退出系統”不是“入庫”操作所達到的系統狀態。

 

涉眾利益是對用例執行過程和結果很關心但不直接操作用例的人，如倉庫管理員在入庫和出庫時，雖然經理不直接入庫，但是他們對這個過程和結果很關心；如在火車站買票時，直接使用售票系統的是售票員，但是乘客很關心用例的執行結果，擔心是否會弄錯時間和車次，因此乘客是涉眾。執行者是直接執行用例的人，他們通過用例來直接執行系統提供的功能；涉眾是執行者操作用例時的觀眾，他們對用例的執行過程和結果很關心，因為涉及到他們的利益。

 

路徑又稱為“流程”，是指執行者和系統互動的過程。用例文件中最關鍵的部分是基本路徑，基本路徑又稱為“正常路徑”或者“開心路徑”，它是使用者最想看到、也最關心的路徑，是用例建模核心中的核心。在路徑中包含若干步驟，這些步驟構成了一個完整的互動過程，在描述基本路徑時，每一個步驟一般以執行者或者系統作為主語，如“倉庫管理員輸入待入庫商品資訊”，“系統驗證該商品庫存是否達到上限”等。在編寫路徑時需要注意以下幾個問題：

 

(1) 需要對步驟進行編號，一般用阿拉伯數字1、2、3、…進行編號，表示步驟的先後次序。

(2) 不能出現專業術語，因為用例文件需要系統的客戶和使用者都能夠看懂，因此不能出現諸如“JDBC”、“SQL”這樣的專業術語。

(3) 儘量使用主動語句，每一個步驟均以執行者或系統作為主語。

(4) 不要涉及到介面細節，如不能出現“倉庫管理員在文字框中輸入帳號”、“倉庫管理員在密碼框中輸入密碼”等句子，應該使用“倉庫管理員輸入帳號和密碼”來代替。

(5) 如果出現大量資料輸入或處理，需要將資料放入“欄位列表”中，如系統管理員在增加員工資訊時，需要增加員工帳號、員工密碼、員工所在部門、員工電話、員工郵箱等資訊，可以在用例文件中使用“系統管理員輸入員工資訊”來代替，而對於“員工資訊”的詳細描述可以放在用例文件的“欄位列表”中進行詳細說明。

(6) 注意分支和迴圈的處理，在用例文件中，分支可放在接下來要介紹的擴充套件流程中；而迴圈可以直接放在步驟描述中，如在入庫時可以一次入庫多個商品的資料，中間某些步驟如下：“2. 倉庫管理員輸入待入庫商品資訊；3. 系統驗證該商品庫存是否達到上限；4. 系統提示該商品入庫資訊增加成功；”，如果需要重複這幾步，可以在基本路徑中用如下語句描述：“如果還有商品需要入庫，重複第2-4步”。

 

基本路徑是用例文件的核心，通過路徑可以清楚瞭解執行者如何通過用例來實現相應的功能，因此，在編寫用例文件時，需要認真細緻編寫基本路徑，確保非專業人員都能夠在讀完基本路徑後理解執行者和系統的互動過程。

 

除了基本路徑之外，很多用例都存在一些替換路徑和異常路徑，通常可以將替換路徑和異常路徑統稱為擴充套件路徑。識別出一個用例的基本路徑並不難，但是要找到所有的擴充套件路徑是件很辛苦的工作。一個優秀的系統分析人員應該認真分析業務流程，試圖尋找出在基本路徑中每一個步驟可能存在的擴充套件方式，尋找出所有可能的擴充套件路徑。如倉庫管理員在入庫時可能會發生一些異常情況，如“供應商不存在”、“待入庫商品不存在”、“入庫時商品超過庫存上限”等，需要使用擴充套件路徑對這些情況進行清晰的描述，如“供應商不存在”，則需要設定一個擴充套件點，先執行“增加供應商資訊”用例，再選擇供應商編號，在擴充套件流程中可以這樣表示：“1a. 供應商不存在  1. 擴充套件點1：執行用例——StockUC003增加供應商資訊；2. 倉庫管理員選擇供應商編號。”。在這裡需要注意擴充套件路徑的編號，如果是基本路徑中步驟1的擴充套件路徑，可以使用1a、1b、1c等方式表示，然後對於擴充套件出來的子路徑再用1、2、3、…進行編號，其中在該子路徑的第1步指明這是一個擴充套件點，該擴充套件點名為“擴充套件點1”，在此時需要執行另一個用例StockUC003“增加供應商資訊”，則用例“入庫”和用例“增加供應商資訊”之間是擴充套件關係，“增加供應商資訊”是對“入庫”操作的擴充套件。如果沒有擴充套件點則直接書寫步驟，與基本路徑步驟寫法一致。

 

欄位列表、業務規則、非功能需求和設計約束是對用例的補充描述，欄位列表中包含某些步驟所涉及到的一些資料欄位，如在“增加商品資訊”用例中可以在其“欄位列表”中詳細列出商品資訊的內容，如“商品資訊包括：商品編號，商品名稱，商品型號，商品類別，商品單價，商品數量，庫存上限，庫存下限”，“欄位列表”為後續的資料庫設計工作提供了極大的幫助；業務規則用於描述在步驟中執行者或系統在執行某些操作時需要滿足的條件，如在“增加商品資訊”用例中，其“業務規則”包括“商品編號不能為空，商品數量必須是大於等於0的整數，庫存下限必須低於庫存上限”等；非功能需求用於描述用例在可靠性、安全性、可用性、移植性等方面的一些要求，如“系統響應時間不能超過30秒”、“可以支援同時100個使用者線上訪問”等；設計約束是指設計過程中存在的一些待解決的問題，如“商品編號的編碼問題”、“如何快速輸入商品編號”等。

 

在實際軟體開發過程中，用例編號、用例名、執行者、前置條件、後置條件和基本路徑是一個用例必不可少的組成部分，其他部分可根據實際情況確定，可有可無。下面提供庫存管理系統中“入庫”用例的用例文件，以供參考：

 

用例名稱	入庫
用例編號	StockUC006
執行者	倉庫管理員
涉眾利益	經理：瞭解各種商品的庫存資訊和每次入庫資訊。 系統管理員：瞭解入庫操作是否能夠正常執行，系統是否正確記錄入庫資訊並更新商品庫存。
前置條件	倉庫管理員已成功登入。
後置條件	系統儲存入庫資訊，更新相關商品的庫存量。
基本路徑	1. 倉庫管理員選擇供應商編號； 2. 倉庫管理員輸入入庫商品資訊； 3. 系統驗證該商品庫存是否達到上限； 4. 系統提示該商品入庫資訊增加成功； 如果還有商品需要入庫，重複第2-4步 5. 倉庫管理員提交入庫資訊； 6. 系統提示入庫成功。
擴充套件路徑	1a. 供應商不存在   1. 擴充套件點1：執行用例——StockUC003增加供應商資訊；   2. 倉庫管理員選擇供應商編號。 2a. 待入庫商品不存在   1. 擴充套件點2：執行用例——StockUC005增加商品資訊；   2. 倉庫管理員輸入入庫商品資訊。 4a. 增加失敗 1. 系統提示商品增加失敗，超過庫存上限； 2. 倉庫管理員重新輸入商品數量； 3. 系統再次驗證該商品庫存是否達到上限，直至該商品入庫資訊增加成功。
欄位列表	入庫商品資訊包括：商品編號、入庫數量、商品折扣。
業務規則	供應商編號不能為空； 商品編號不能為空； 入庫數量必須為正整數，且不能為空； 商品折扣為0-1之間的小數（可包含0和1），且不能為空。
非功能需求	系統響應時間不能超過30秒。
設計約束	如何快速輸入商品編號？

   

總之，用例建模包括用例圖的繪製和用例文件的編寫，其核心在於編寫用例文件。用例建模是軟體需求分析到最終實現的第一步，它從使用者的角度來描述軟體系統的功能，描述人們如何使用軟體系統。構造意義明確、格式規範的用例模型是軟體成功的第一步，希望大家在每個軟體專案的開發過程中都能夠認真、細緻地進行用例建模，為順利完成專案開發任務奠定堅實的基礎。

 

【作者：劉偉 http://blog.csdn.net/lovelion】