不知道大家有沒和我類似的感覺，就是在做開發的時候，經常看到需求文件裡的用例2字，或者聽到關於用例的談話，或者測試用例之類的，一般的感覺就是用例就是乙個需求功能點，也沒去太在意，這裡我想自己做個對於用例的總結。
我不想過於刻板的去討論用例的概念，這裡先從乙個例子入手，比如我問你：請在30秒內說出盡可能多的筷子，勺子和盤子的相同點與不同點。
不知道大家是否有種感覺，就是腦子裡似乎都知道，但是要一下子通盤考慮的說出來，卻一時間不知如何下手 ？其實這個問題沒有標準答案，看似簡單的問題反映了我們是否習慣以抽象的方法去看待和理解事物，這裡的每乙個相同點和不同點都可以來自乙個抽象角度。例如：從用途的角度去抽象時，它們的相同點可能是3者都是餐具，不同點是筷子是用於夾的，勺子是用於舀的，盤子是用於盛的；從使用方法的角度去抽象時，它們的相同點可能是3者都是需要用手拿的，不同點是拿的方式不同；還可以從其它抽象角度得出不同的結果。
在軟體專案中，當我們自己試圖去分析需求，面對大量的需求資料時，是否覺得無從下手呢 ？ 這時與其說是分析能力不足，不如說是自己還沒有找到明確的抽象角度！物件導向和面向過程的不同就是面向過程希望你通盤考慮，這時人腦需要考慮的資訊量就變得很大，使得自己大腦發暈或一時反映不過來，問題變得複雜化；而物件導向希望你通過抽象從而以不同的角度來把問題分解成小塊，從而使得問題簡單化，回想下剛剛的筷子，勺子和盤子的例子就知道啦。
具體來說，在做需求分析的時候，首要目標不是通盤考慮，不是要弄清楚業務是如何一步一步完成的，而是要明確有多少個參與者？每個參與者的目標是什麼 ？ 參與者的目標就是我們的抽象角度，與分析乙個個複雜的業務流程相比，單獨分析參與者的乙個個目標要簡單的多，參與者的目標就是乙個用例，這也就是為什麼用例會成為建模的方法的原因之一。
用例是一種把現實世界的需求捕獲下來的方法，需求裡包含客戶對這個系統的各種各樣的願望。我們要描述乙個系統的功能性需求，就是要找到對這個系統有願望的人，讓他們來說明他們想要在這個系統裡做的事，想要的結果。如果所有對系統有願望的人要做的事情都找全了，也就是問題領域的抽象角度都找出來了，那麼系統的功能性需求就確定了。接下來的工作就是實現用例，一旦用例都實現了，那麼問題領域也就解決了，這就是用例驅動開發的原理。其他的分析，設計，測試等都是由用例來驅動的，乙個用例就是乙個開發單元，設計單元，測試單元。
我個人認為建模同樣是用例驅動的，因為尋找用例的過程，就是確定參與者的過程，同時繪製出用例實現的活**，確定用例規則。那麼現實世界就可以對映到業務模型中來了。因為不管是任何行業，無論什麼業務，其本質無非是由人，事，物，規則組成的。人是中心，人要做事，做事產生物，做事要遵守規則。人驅動系統，事體現過程，物記錄結果，規則是控制。建立模型就是要弄明白有什麼人做什麼事，什麼事產生什麼物，中間有什麼規則，再把人，事，物，規則之間的關係定義出來，模型也就出來了。
uml 採用參與者對應現實世界的人，用例對應參與者的業務目標，業務場景對應規則，業務物件對應物。人，事，物，規則就這樣在描述用例的過程中被模型化了，於是現實世界就轉化成了業務模型，這也是物件導向分析方法的第一步--現實世界對映到了物件世界。
**：
轉 本人對於「用例」的一些理解和總結
不知道大家有沒和我類似的感覺，就是在做開發的時候，經常看到需求文件裡的用例2字，或者聽到關於用例的談話，或者測試用例之類的，一般的感覺就是用例就是乙個需求功能點，也沒去太在意，這裡我想自己做個對於用例的總結。我不想過於刻板的去討論用例的概念，這裡先從乙個例子入手，比如我問你 請在30秒內說出盡可能多...
轉 本人對於「用例」的一些理解和總結
不知道大家有沒和我類似的感覺，就是在做開發的時候，經常看到需求文件裡的用例2字，或者聽到關於用例的談話，或者測試用例之類的，一般的感覺就是用例就是乙個需求功能點，也沒去太在意，這裡我想自己做個對於用例的總結。我不想過於刻板的去討論用例的概念，這裡先從乙個例子入手，比如我問你 請在30秒內說出盡可能多...
轉 本人對於「用例」的一些理解和總結
不知道大家有沒和我類似的感覺，就是在做開發的時候，經常看到需求文件裡的用例2字，或者聽到關於用例的談話，或者測試用例之類的，一般的感覺就是用例就是乙個需求功能點，也沒去太在意，這裡我想自己做個對於用例的總結。我不想過於刻板的去討論用例的概念，這裡先從乙個例子入手，比如我問你 請在30秒內說出盡可能多...