這個學期的好幾門課程都會用到uml用例圖的相關知識，可見用例的重要性。用例圖作為軟體開發需求分析階段的主要表現形式，有很多值得去學習和研究的內容。這本書通過對具體的一些用例的分析，介紹了一些編寫有效用例的方法和技巧。這本書分為「用例體部分」、「經常討論的主題」、「對忙於編寫用例的人的提示」幾個部分，單從名稱來看便知這是具有豐富的軟體開發經驗的人對各種開發案例的總結歸納，可以從中學到很多細節性的知識。
首先， 用例是代表系統中各個專案相關人員之間就系統的行為所達成的契約，描述了系統對某一專案相關人員的請求做出的響應。根據執行者的不同請求系統將執行不同的行為序列，每乙個行為序列稱為場景，用例正是多個不同場景的集合。根本來說，用例是以簡單文字形式呈現的。根據記錄物件的不同，被討論的系統可以指組織本身或者電腦程式；讀懂乙個用例很簡單，但要寫出乙個好的用力就會很難了。首先要明確三個概念：範圍、主執行者、層次；老師上課時也一直強調必須先明確範圍，因為它基本是作為頂層資料流圖的，只有首先確定範圍才可能繼續後續工作，否則整個專案就會不斷被擴張。
人們在大多數情況下沒有時間去把用例寫得正式、完整、漂亮，而只是盡可能將其寫的充分，這就足夠了。而且有時候用例要給非專業人員來看，他們會對系統有直接的操作或某種關聯，所以要將用例做得更加通俗易懂。用例是用來討論未來系統的需求問題，而不是需求描述，作為系統的功能性需求，它會將系統設計文件化。根據不同的情況和場景，用例編寫可能會很規範，也可能會比較隨意。用例確實是需求但也不是所有的需求，因為它只是所有需求文件中的一部分。人們只要寫出一段用例，就能通過少量的編寫節省大量的時間，還要堅持作錯誤處理。
系統用例「範圍」的確定是十分關鍵的一環，也是很不容易把握的。其中，功能範圍是指系統要提供的服務，設計範圍和功能範圍的確定需要考慮專案相關人員和執行者的相關業務以及他們同系統之間的互動。用例開始執行通常是主執行者觸發的，輔助執行者是為了將系統與外部介面相連。三個目標層次的定義更加方便了對於目標功能和作用的界定，使用者目標是使用者使用系統目標，相當於基本業務過程；概要層次包含多個使用者目標，它可以顯示使用者目標的執行語境，顯示相關目標的生命週期順序，並為最底層用例提供乙個人目錄表；子功能層次的目標是指那些在實現使用者目標時可能會用到的目標。可以用圖示來突出目標層次，使整個用例更加清晰明了。
用例的前置條件宣告了啟動該用例之前系統必須滿足的條件，乙個典型的例子就是「使用者登入並通過了身份驗證」，說明通過身份驗證之後使用者才可以進入系統進行相關操作，而系統也不會再對使用者身份進行檢查。最小保證是系統向專案相關人員做出的最低承諾，比方說只有收到付款之後才可以啟動訂單。另外，為失敗的事務處理做日誌並不是乙個顯而易見的需求而是至關重要的，對於失敗的記錄可以解決許多紛爭，由中可見，用例的編寫時日誌記錄以及錯誤處理的重要性。成功保證說明了用例成功結束之後專案相關人員的哪些利益得到了滿足，這通常是最小保證的新增內容。觸發事件則是指啟動用例的事件，例如使用atm機的觸發事件就是插入銀行卡。
《編寫有效用例》閱讀筆記三
基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使...
編寫有效用例 閱讀筆記05
編寫了那麼多的用例，那用例到底是幹嘛的？用例為管理者指明應提交給使用者的系統功能。用例的標題指明主執行者的需求，同時系統也必須支援這些需求，而用例描述則說明了系統需要什麼功能以及將提供什麼服務。在一開始接觸用例的時候，uml課程中提及過用例的優先順序以及用例版本號等其他細節，對於這些資訊的彙總可以稱...
編寫有效用例 閱讀筆記03
第六章中講述了前置條件 觸發事件和保證這三個方面。簡單來說，前置條件字面理解就是我們經常說的條件，條件成立，結果才有可能發生，此處也類似我們所說的條件。簡單來說，建立訂單依賴於 已經登入 這個前置條件。也就是說，2的前提是1，1發生2才能發生。這樣就比較好理解了。在前置條件中，唯一強調的部分就是 一...