第六章中講述了前置條件、觸發事件和保證這三個方面。
簡單來說，前置條件字面理解就是我們經常說的條件，條件成立，結果才有可能發生，此處也類似我們所說的條件。簡單來說，建立訂單依賴於「已經登入」這個前置條件。也就是說，2的前提是1，1發生2才能發生。這樣就比較好理解了。在前置條件中，唯一強調的部分就是「一定要把真正必須的條件的寫入前置條件。」這裡有乙個典型的事例，我們假設在索要保險總金額之前，申請人至少已經提交了乙個申請或賬單。然而，並不總是這樣；系統不能保證這個假設的正確性，實際上這不是乙個必要條件。申請人應該能在任何時候索要他們的保險總金額，因此諸如「申請人已經提交了乙個賬單」這樣的前置條件是錯誤的。
同時，保證這個方面也類似上面說的前置條件，但是，此處保證一定是最小保證且這個語句一定要寫成簡單的斷言形式。這個最簡單的斷言句就是咱們中文裡說的縮句，而且是陳述句甚至是判斷句，而不是冗長的各種條件和結果的假設。這樣的話，才能夠使用例顯得更加簡潔和已讀。
第七章部分，講到了這本書中，我比較喜歡的一部分，主成功場景部分。尤其是當王老師讓我們重新描述乙個案例的時候，我幾乎是毫不猶豫的使用了這個方法。主成功場景，簡而言之，就是一條主線下來，只留下最重要並且成功的部分。然後，在主成功場景下進行補充說明和解釋，不斷的分支，這樣思路會更好的讓自己清楚和理解整個事件。主成功場景從開始寫到結束，按照時間的順序寫出來，然後使用擴充套件的方法在每個分支點寫出場景的擴充套件。寫擴充套件的時候，寫出分支的條件以及處理分支的步驟。並且大多數擴充套件以重新與主成功場景回合而結束。某種程度上，需要集中討論所有可能的失敗和可選擇的過程。從場景開始到結束以保證能夠盡可能的覆蓋所有情況。在第一遍完成的時候就會發現，其中有許多考慮步驟的方面，這時候就需要不斷的回頭重新考慮，至到完成完善整個場景。最後的要求就是：不斷修改和替換進入擴充套件中的步驟，使得當擴充套件處理結束時，就像完成了原來的步驟一樣。同時，0在必須的情況下才能建立擴充套件用例，因為這些用例不能被人們所理解，也不易維護。為了減少讀者的閱讀量，盡量的不讓他們接觸擴充套件用例。
通過寫主成功場景和使用擴充套件的方法，可以縮短的文件，減少讀者的閱讀量。
《編寫有效用例》閱讀筆記三
基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使...
《編寫有效用例》閱讀筆記一
這個學期的好幾門課程都會用到uml用例圖的相關知識，可見用例的重要性。用例圖作為軟體開發需求分析階段的主要表現形式，有很多值得去學習和研究的內容。這本書通過對具體的一些用例的分析，介紹了一些編寫有效用例的方法和技巧。這本書分為 用例體部分 經常討論的主題 對忙於編寫用例的人的提示 幾個部分，單從名稱...
編寫有效用例 閱讀筆記05
編寫了那麼多的用例，那用例到底是幹嘛的？用例為管理者指明應提交給使用者的系統功能。用例的標題指明主執行者的需求，同時系統也必須支援這些需求，而用例描述則說明了系統需要什麼功能以及將提供什麼服務。在一開始接觸用例的時候，uml課程中提及過用例的優先順序以及用例版本號等其他細節，對於這些資訊的彙總可以稱...