第七章 場景和步驟

1、主成功場景就是主執行者完成了目標，所有項目相關人員的利益都被滿足了的場景。

2、主成功場景和所有場景擴展都包含的元素

主成功場景 擴展場景

場景執行的條件 前置條件加上觸發事件 擴展條件

完成的目標 用例的名稱 完成用例目標，或者是在處理擴展場景後重新進入主成功場景

執行步驟集 場景主體

結束條件 結束時完成的目標

作為場景片斷的、可能的擴展集 用例模板中的擴展部分 可以嵌入到擴展體中，或者寫在擴展體裏面，或者就寫在擴展體的後面

3、場景主體：每個場景或片段被描述為由不同執行者完成目標的活動序列

序列即無判斷和循環，這是用例描述的基本特點。

場景主題必須把這三步描述完成（括號裏文字是例子）：兩個執行者之間的交互（“顧客輸入地址”）——為了保護項目相關人員利益的確認過程（“系統確認PIN密碼”）——滿足項目相關人員利益的內部變化（“系統從余額中扣除一定數量的金額”）

4、執行步驟時對用例的補充，並且都有統一的語法形式，在一個簡單活動中，執行者完成任務或向另外的執行者發送信息。

5、執行步驟的10大準則

（1）使用簡單的語法；

句子結構應該非常簡單：主語……謂語動詞……直接賓語……前置短語

例如 系統……從帳戶余額中扣除……一定數量……

（2）明確地寫出“誰控制球”；

作者舉了踢足球的場景的例子，說明了不管步驟的執行者如何變化，都要遵循（1）描述的格式。

（3）從俯視的角度來編寫用例；

從用戶的角度來寫用例，而不是從系統內部來描述系統

（4）顯示過程向前推移；

可能是翻譯的問題，意思應該是如果過程繁雜，超過了9步，那麽考慮提高目標層次，即“向前推移”

（5）顯示執行者的意圖而不是動作；

通過操縱系統的用戶界面來描述用戶的動作，這是在編寫用例時常見的一種嚴重錯誤，它使得編寫的目標處於一個很低的層次。我把它叫做“界面細節描述（interface detail description）”。在需求文檔中，我們只關心界面所要達到的意圖，總結在執行者之間傳遞的信息。可將這些低層次的步驟合並成一個步驟。

（6）包含“合理”的活動集；

用例描述為了表現一個事務，分解成了四個步驟，而這些步驟各有其復雜度，書中給出了五種形式，一種比一種分步多，作者傾向於中間第三和第四種形式，不過他也提出要視具體步驟復雜度來確定采用什麽形式

（7）“確認”而不是“檢查是否”

這是一個經常犯的錯誤，寫用例不是寫程序流程，不需要用選擇語法，需要選擇的時候，在擴展場景裏體現。

（8）可選擇地提及時間限制；

（9）習慣用語：“用戶讓系統A與系統B交互”；

要分開來寫，用戶與系統A怎麽怎麽樣，然後系統A和系統B怎麽怎麽樣，這樣用戶才能看的懂。

（10）習慣用語：“循環執行步驟X到Y，直到條件滿足”；

同（7），但如果需要重復的話，可直接在重復的步驟的前面和後面說明即可。

總之，這10大原則，目的就是為了讓用例成為用戶和開發人員溝通的橋梁，所以語言要簡單易懂，而且要邏輯清晰。

6、步驟編號使步驟更清晰，並在擴展部分給出引用的位置。完整的用例格式需要編號。

第八章 擴展

1、如何體現用例包含所有可能路徑

（1）用第二章所提到的條紋褲，缺點是場景的任何一個變化都導致了在其他包含相同文字的場景裏都必須做一份拷貝。

（2）使用條件語句，缺點是讀者要閱讀這些條件語句會很困難，特別是當一個條件句中又嵌套了一個條件句。

（3）將主成功場景從開始到結束，按照時間的順序寫出來，然後在每個分支點寫出場景的擴展。

書上提倡用方法（3）

2、擴展通常是這樣的，在主成功場景下，對於因為特別條件而出現行為分支的每個地方，寫出分支的條件以及處理分支的步驟。大多數擴展以重新與主成功唱機果農匯合而結束。這些擴展最可能出現在系統需求中。開發組通常對主成功場景很了解。而錯誤處理通常使用並不為開發人員所了解的業務規則。需求分析人員必須研究正確的系統響應，而這樣的研究經常會引入新的執行者、新用例或新擴展條件。

3、需求階段可分為三個階段:

（1）集中討論，發現你和同事能夠想到的每種可能。

（2）根據準則11、12，評估、刪除以及合並所有建議。

（3）詳細討論，並找到處理每一種情況的方法。

4、擴展條件（extension condition）就是在一些條件下系統會完成不同的動作，它不是失敗或異常，所以能夠包括成功和失敗兩種條件。

示例1：

……

4．用戶要求系統保存

……

擴展：

4a. 系統自動檢測中間保存的要求：

4a1……

4b. 保存失敗：

4b1……

5、集體討論所有可能的情況，這些情況中的場景可能失敗，或通過其他方式獲得成功，仔細考慮下面所有的條目（括號裏面內容是例子）：

? 一種可選擇的成功路徑（職員使用便捷的代碼）

? 主執行者操作錯誤（無效密碼）

? 主執行者無任何操作（等待密碼超時）

? “系統確認”這個短語的每一次出現，都暗示了將會有一個處理系統失敗的擴展（無效的賬號）

? 從輔助執行者那裏得到不恰當的響應或沒有響應（響應超時）

? 作為正常功能的一部分，檢測所設計系統的內部錯誤，並處理（現金分配阻塞）

? 必須處理不期望和異常的內部錯誤，並產生一個外部可見的結果（發現崩潰的事務日誌）

? 必須檢測系統關鍵性能的失敗（回答沒有在5秒內完成）

6、準則11：用“檢測到什麽”的方式來編寫條件

應該寫出系統檢測什麽，而不僅僅寫出發生了什麽。如：不要寫，“顧客忘記了密碼”，應該寫，“等待用戶輸入密碼的時間超時或密碼輸入的時間超時”。

7、合理化是為了使擴展列表盡可能的短。理想的擴展條件列表是所有的而且僅是必須由系統處理的情況。清除那些系統不需要處理的條件，合並那些對系統來說等價的條件，請使用下面的標準：

? 系統必須能夠檢測到條件

? 系統必須完成條件的檢測

8、作為合並等價條件的一部分，從低層用例中提取等價的失敗情況，合並到高層用例中。低層失敗的合並（rolling up）是我們在高層上避免擴展條件爆炸的一種方法。

9、擴展是一個小型的用例。觸發事件是擴展條件；目標是完成用例目標或者覆蓋所有可能出現的失敗。用例主體是執行步驟集和這些步驟可能的擴展。在用例中，擴展以完成或放棄它的目標作為結束。

10、準則12：條件處理的縮排方式

當我們使用編號方式時，應該縮排那些指明如何處理條件的執行步驟，並在子目後重新從編號1開始。

方式1

擴展

2a. 資金不足：

2a1.系統通知顧客，要求輸入一個新的數量。

2a2. 顧客輸入新的數量。

方式2

擴展

2a. 資金不足：

.1 系統通知顧客，要求輸入一個新的數量。

.2 顧客輸入新的數量。

方式2的優點是當編號變化時，例如步驟2變為步驟3，對擴展處理步驟的重新編號變得相當簡單。

11、將擴展分離為新的子用例，僅僅需要確定主執行者的目標是什麽，給出新用例的級別（可能是子功能級），在新級別中為新用例命名。在以下兩種情況下，你可以為擴展創建新用例：

? 擴展在多個地方使用。將擴展轉變為用例意味著它可以在同一個地方被跟蹤和維護。

? 擴展使得用例難以閱讀。我發現兩頁左右的用例文檔和三級縮排是可讀性的極限。

總結 ：本章著重介紹用例擴展的作用和編寫方式，使用擴展可以提高用例的可讀性，特別是面對客戶的時候，客戶也可以看的懂。

編寫有效的業務用例 讀書筆記04