基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使用。搜尋任何東西都會有相同的步驟，對此為了方便操作我們可以建立乙個引數化用例，為每個用例起乙個別名。然後將別名資料值劃分為三個不同的精度級別，可以在一定程度上簡化用例描述。
當對業務過程進行建模時，在重組前需要通過用例對其系統進行文件化，通過用例建立符合設計要求的外部行為需求，設計之後使用用例對信新過程文件化。在自上而下的分析法中，需要清楚組織行為中的專案相關人員，外部主執行者，組織需要響應的觸發事件，組織提供的服務以及專案相關人員的成功結果。業務設計過程可以採用黑盒用例進行描述，此階段會充分發揮技術的作用，創新資源組和新過程。但是隨著技術的更新，會使用白盒用例，這其中不涉及技術，因為計算機完成的事人也可以完成。
軟體需求分析中，用例會表會給人乙個清晰的功能描述。乙個開發組可以使用用例來制定軟體設計任務，以保持用例對映的及時性。設計任務步並不與用例單元整齊對應，所以一項設計任務產生的業務物件或者行為能同時用於多個用例。在制定粗略的系統功能圖時需要首先對系統採用的敘述方式達成共識；然後對應用領域達成共識，並集中討論系統主執行者和系統目標；再編寫系統描述並彙總。然後對功能圖精確化，首先對格式達成共識，然後編寫用例繼而進行審核。把應用描述作為用例編寫開始之前的練習，並把用例概述作為專案概要的一部分。
在用例缺少系統的功能或者執行者的作用時需要對用例進行修改。軟體開發時編寫用例的過程需要有很多描述，需要有強大的表達能力，在之前就感覺乙個真正的大師級人物無論是開發者還是工程師，都會熱愛體育，或者**，顯然還要有很強的文學素養。需要在用例編寫時使用例易於閱讀。而且當乙個人對於文學、體育或藝術等方面有深刻的研究的時候，在工作時會有很大益處，可以幫助人開啟思路，橫向縱向思維的雙向發展是很重要的。
用例就像是乙個不斷展開的故事，頂級用例呼叫最外層用例，最外層用例再展開為使用者目標用例或海平面用例。設計範圍比較容易引起混亂，人們對系統的邊界往往會有不同的觀點。重要的是要清楚：業務用例的設計範圍是業務運作不涉及技術問題，系統用例的設計範圍就是要設計的計算機系統涉及技術問題。可以用圖示來區分業務用例和系統用例或者在用例本身包含的系統內部放置一幅系統的圖畫。人們在開發時經常會犯得錯誤會反映最重要的問題，這一點在很多領域都是成立的。用例的每一句話都描述了乙個要實現的子系統；還要從系統的外部看待整個系統，然後以乙個較高的姿態進行描述用例；用力的可讀性必須要強否則會失去它存在的意義；而且乙個用例在不同時間可能會被用到不同的地方，要學會遷移；系統通常會被看作黑盒，否則會難以閱讀；在主成功場景之後需要選擇正確的路徑；要學會接受改變因為改變在整個過程中是必須的；優勢細化功能和用例是非常必要的，需要自己把握；用協作圖代替文字可以提高可讀性。用例的提示是很重要的，無論是哪個階段都有必要去考慮完全。
雖然uml工具可以是我們在圖形中獲得很多資訊，但是文件的重要性是毋庸置疑的。圖形是乙個二維的助記根據，是以認知為目的的。包含關係是**於程式語言中的子程式呼叫，需要各種引數輔助完成作用。在有「使用者採取了某種行動」時可以考慮使用泛化，有時泛化僅僅包含特殊操作。在此書中有很多細節上的東西，在平常的小實驗中自己根本不會注意到，以後一定要逐漸規範自己的工作流程。
《編寫有效用例》閱讀筆記一
這個學期的好幾門課程都會用到uml用例圖的相關知識，可見用例的重要性。用例圖作為軟體開發需求分析階段的主要表現形式，有很多值得去學習和研究的內容。這本書通過對具體的一些用例的分析，介紹了一些編寫有效用例的方法和技巧。這本書分為 用例體部分 經常討論的主題 對忙於編寫用例的人的提示 幾個部分，單從名稱...
編寫有效用例 閱讀筆記05
編寫了那麼多的用例，那用例到底是幹嘛的？用例為管理者指明應提交給使用者的系統功能。用例的標題指明主執行者的需求，同時系統也必須支援這些需求，而用例描述則說明了系統需要什麼功能以及將提供什麼服務。在一開始接觸用例的時候，uml課程中提及過用例的優先順序以及用例版本號等其他細節，對於這些資訊的彙總可以稱...
編寫有效用例 閱讀筆記03
第六章中講述了前置條件 觸發事件和保證這三個方面。簡單來說，前置條件字面理解就是我們經常說的條件，條件成立，結果才有可能發生，此處也類似我們所說的條件。簡單來說，建立訂單依賴於 已經登入 這個前置條件。也就是說，2的前提是1，1發生2才能發生。這樣就比較好理解了。在前置條件中，唯一強調的部分就是 一...