需求用例分析之一:異常流
備選流,又稱備選事件流,英文是Alternative Flow。在RUP和UML中,備選流的解釋如下:備選事件流包括與正常行為相關的可選或異常特徵的行為,同時也包括正常行為的各種變形。您可以將備選事件流看作是基本事件流的“繞行道”,有些備選事件流將返回到基本事件流,而有些將結束此用例的執行。
分析RUP對於備選流的定義,可以看到備選流可以分成兩類:
1,不同做法但仍然達成用例目標;
2,異常情況,無法達成用例目標。
在實際用例分析中,由於備選流可能存在兩種情況,導致備選流存在2種主要寫法:
1.在備選流中說明基本流以外的異常情況的處理,可能仍然回到基本流,也可能導致用例結束。
在備選流中說明基本流以外的其它正常和異常情況的處理,覆蓋了其它功能。
第1種寫法的例子比較常見,下文將出現,這裡不再贅述。
第2種寫法的例子如下:
用例名稱:填寫請購單
簡要說明
員工線上填寫圖書請購單,內容包括:圖書名稱、出版社、作者、價格、訂購人(系統自動識別)、訂購部門、訂購日期等,填好後提交給圖書管理員稽核。
填寫請購單的主角是員工。
事件流
員工選擇“填寫請購單”,用例開始。
基本流
員工選擇“填寫請購單”,提交“填寫請購單”請求;
顯示“填寫請購單”視窗並列表顯示請購單資訊(已填寫未提交、已提交稽核未通過), 兩種狀態的請購單資訊通過選擇分別列出,稽核未通過的原因只能檢視不能修改;
請購單資訊包括:請購單編碼(系統自動生成)、訂購部門、訂購人、訂購日期、訂購原因、備註,和圖書明細包括:圖書名稱、出版社、作者、單價、數量等,圖書明細包括:新增,修改,刪除;
請購單資訊輸入操作見備選流;
新增:系統具體執行見“備選流 新增”
修改:系統具體執行見“備選流 修改”
刪除:系統具體執行見“備選流 刪除”
選擇“提交”,系統把選中的請購單提交給圖書管理員稽核,此用例結束。
備選流
填寫請購單基本流中抽取出三個備選流:
請購單資訊:新增、修改、刪除;
新增
(一)員工在“填寫請購單”資訊區選擇“新增”,提交“新增”請求;
(二)系統彈出“新增請購單”空白模式視窗;
(三)請購單資訊包括:圖書名稱、出版社、作者、單價、數量等;
(四)請購單資訊輸入完畢後,選擇“儲存”提交,系統驗證資料有效性,如驗證不成功,針對所提示錯誤資訊修正輸入資料,驗證成功關閉“新增請購單”視窗;
若繼續新增請購單,則重複㈠㈡㈢㈣步驟。
修改
(一)員工在“填寫請購單”資訊區列表選中要修改的請購單,提交“修改”請求;
(二)系統彈出“修改請購單”模式視窗,並顯示當前請購單資訊;
(三)修改相應資料後,選擇“儲存”提交,系統驗證資料有效性,如驗證不成功則根據錯誤提示重新輸入,驗證成功後儲存資料並關閉“修改請購單”模式視窗同時重新整理請購單資訊列表;
若繼續修改,則重複㈠㈡㈢步驟。
刪除
(一)員工在“填寫請購單”資訊區列表選中要刪除的請購單,提交“刪除”請求;
(二)若選中的請購單屬於稽核未通過,系統提示“不能刪除稽核未通過的請購單”;
(三)刪除後重新整理請購單列表資訊同時系統提示“編號為XXX的請購單已刪除!”;
若繼續刪除,則重複㈠㈡㈢步驟。
特殊需求
無
前置條件
員工登入系統。
後置條件
無
---例子結束----
第2種寫法中,在備選流中說明了基本功能,用例篇幅已經變長,如果備選流中出現異常,備選流將顯得更加臃腫。因此第2種寫法比較少見。
為了解決備選流的不同情況,人們識別率異常流來解決上述問題。