在正式討論如何獲取用例之前，筆者覺(jué)得有兩個(gè)問(wèn)題還是先解釋清楚為好，這對正確獲取用例有很大幫助。這兩個(gè)問(wèn)題也是初學(xué)者最為困惑，也是最難掌握的。一個(gè)是各種用例類(lèi)型之間的區別和用法，另一個(gè)是用例的粒度。
在正式討論如何獲取用例之前，筆者覺(jué)得有兩個(gè)問(wèn)題還是先解釋清楚為好，這對正確獲取用例有很大幫助。這兩個(gè)問(wèn)題也是初學(xué)者最為困惑，也是最難掌握的。一個(gè)是各種用例類(lèi)型之間的區別和用法，另一個(gè)是用例的粒度。
先說(shuō)說(shuō)用例類(lèi)型的問(wèn)題。
用例類(lèi)型，有的資料翻譯為版型，英文原文是stereotype。在Rose中默認的類(lèi)型有business usecase , business usecase realization和use case realization三種。相應的，就是指
業(yè)務(wù)用例：
業(yè)務(wù)用例實(shí)現：
用例實(shí)現：
若不指定類(lèi)型，則它就是通常意義上的use case ：
說(shuō)到需求分析階段，那么需求分析都有些什么階段呢？一般來(lái)說(shuō)，需求分析要經(jīng)過(guò)業(yè)務(wù)建模，用例分析和系統建模三個(gè)階段才能完成需求工作，這三個(gè)階段分別做什么筆者會(huì )在以后的文章的詳細闡述，這里為了說(shuō)明用例類(lèi)型的含義和使用，先簡(jiǎn)單介紹一下。
1、業(yè)務(wù)建模的目標是通過(guò)用例模型的建立來(lái)描述用戶(hù)需求，需求規格說(shuō)明書(shū)通常在這個(gè)階段產(chǎn)生。這個(gè)階段通常使用業(yè)務(wù)用例和業(yè)務(wù)用例實(shí)現兩種類(lèi)型；
2、用例分析是系統分析員采用OO方法來(lái)分析業(yè)務(wù)用例的過(guò)程，這個(gè)階段又稱(chēng)為概念模型階段。這個(gè)階段通常使用無(wú)類(lèi)型的用例。用例分析是一個(gè)過(guò)渡過(guò)程，但筆者認為其非常重要，業(yè)務(wù)架構通常在這個(gè)階段產(chǎn)生。
3、系統建模是將用戶(hù)的業(yè)務(wù)需求轉化為計算機實(shí)現的過(guò)程。這個(gè)階段通常使用無(wú)類(lèi)型的用例和用例實(shí)現兩種類(lèi)型。系統范圍，項目計劃，系統架構通常在這個(gè)階段形成雛形（在系統分析階段確定）。
所謂business usecase，是用來(lái)描述用戶(hù)原始需求的，它的含義是站在用戶(hù)的角度，使用用戶(hù)的業(yè)務(wù)術(shù)語(yǔ)來(lái)描述用戶(hù)在其業(yè)務(wù)領(lǐng)域所做的事情。業(yè)務(wù)用例命名，描述都必須采用純業(yè)務(wù)語(yǔ)言，而不能出現計算機術(shù)語(yǔ)。因為業(yè)務(wù)模型是系統分析員與用戶(hù)討論需求，達到一致理解的基礎，必須使用用戶(hù)熟悉的，不會(huì )有歧義的專(zhuān)業(yè)術(shù)語(yǔ)以避免系統分析員與用戶(hù)對同一事件的理解誤差。business usecase realization是達到需求可追溯要求的一個(gè)連接點(diǎn)，是用戶(hù)在其業(yè)務(wù)場(chǎng)景中如何做這一件事的載體。
筆者自己在用例分析和系統建模階段不區分用例類(lèi)型，都使用無(wú)類(lèi)型的use case，但在這兩個(gè)階段，用例的含義還是有所差別的。用例分析階段，用例主要是從 業(yè)務(wù)模擬的概念上，從OO的視角來(lái)分解、組合業(yè)務(wù)用例，粗略的建立一個(gè)業(yè)務(wù)架構。而在系統建模階段，用例主要是從計算機視角描述需求，規定開(kāi)發(fā)范圍，作為項目計劃的依據，為系統設計做準備。usecase realization的含義可從business use case realization推知。
再來(lái)說(shuō)說(shuō)用例的粒度問(wèn)題。
粒度是令人迷惑的。比如在A(yíng)TM取錢(qián)的場(chǎng)景中，取錢(qián)，讀卡，驗證賬號，打印回執單等都是可能的用例，顯然，取錢(qián)包含了后續的其它用例，取錢(qián)粒度更大一些，其它用例的粒度則要小一些。到底是一個(gè)大的用例合適還是分解成多個(gè)小用例合適呢？這個(gè)問(wèn)題并沒(méi)有一個(gè)標準的規則，筆者可以給大家分享的經(jīng)驗是根據階段不同，使用不同的粒度。在業(yè)務(wù)建模階段，用例的粒度以每個(gè)用例能夠說(shuō)明一件完整的事情為宜。即一個(gè)用例可以描述一項完整的業(yè)務(wù)流程。這將有助于明確需求范圍。例如取錢(qián)，報裝電話(huà)，借書(shū)等表達完整業(yè)務(wù)的用例，而不要細到驗證密碼，填寫(xiě)申請單，查找書(shū)目等業(yè)務(wù)中的一個(gè)步驟。在用例分析階段，用例的的粒度以每個(gè)用例能描述一個(gè)完整的事件流為宜?？衫斫鉃橐粋€(gè)用例描述一項完整業(yè)務(wù)中的一個(gè)步驟。需要注意的是，這個(gè)階段需要采用OO方法，歸納，抽象業(yè)務(wù)用例中的概念模型。例如，寬帶業(yè)務(wù)需求中有申請報裝，申請遷移地址用例，在用例分析時(shí)，可歸納和分解為提供申請資料，受理業(yè)務(wù)，現場(chǎng)安裝等多個(gè)業(yè)務(wù)流程中都會(huì )使用的概念用例。在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個(gè)用例能夠描述操作者與計算機的一次完整交互為宜。例如，填寫(xiě)申請單，審核申請單，派發(fā)任務(wù)單等?？衫斫鉃橐粋€(gè)操作界面，或一個(gè)頁(yè)面流。在RUP中，項目計劃要依據系統模型編寫(xiě)，因此另一個(gè)可參考的粒度是一個(gè)用例的開(kāi)發(fā)工作量在一周左右為宜。
上述的粒度劃分方法筆者是用相對比較具體化的一些依據來(lái)說(shuō)明。實(shí)際上，用例粒度的劃分依據（尤其是業(yè)務(wù)用例）最標準的方法是一個(gè)用例的粒度是否合適，是以該用例是否完成了參與者的某個(gè)目的為依據的。這個(gè)說(shuō)法比較籠統，也比較難以掌握。，舉個(gè)例子，某人去圖書(shū)館，查詢(xún)了書(shū)目，出示了借書(shū)證，圖書(shū)管理員查詢(xún)了該人以前借閱記錄以確保沒(méi)有未歸還的書(shū)，最后借到了書(shū)。從這段話(huà)中能得出多少用例呢？請記住一點(diǎn)，用例分析是以參與者為中心的，因此用例的粒度以能完成參與者目的為依據。這樣，實(shí)際上適合用例是：借書(shū)。只有一個(gè)，其它都只是完成這個(gè)目的過(guò)程--這里討論的用例指的是業(yè)務(wù)用例--這個(gè)例子是比較明顯的能夠區分出參與者完整目的的，在很多情況下可能并沒(méi)有那么明顯，甚至會(huì )有沖突。讀者可以從自己實(shí)際的情況去找出這種例子。以后的文章中筆者會(huì )做一些討論。
但是上述的粒度選擇并不是一個(gè)標準，只是在大多數情況下這樣的粒度選擇是比較合適的。筆者的意思也不是告訴讀者上述哪一種是最好的，而只是把一些常用的比較，劃分方法告訴讀者，期望的是幫助讀者在工作實(shí)踐中自己總結出一套適合自己的方法來(lái)?，F實(shí)情況中，一個(gè)大型系統和一個(gè)很小的系統用例粒度選擇會(huì )有較大差異。這種差異是為了適應不同的需求范圍。比如， 針對一個(gè)50人年的大型項目應該選擇更大的粒度，如果用例粒度選擇過(guò)小，可能出現上百甚至幾百個(gè)業(yè)務(wù)用例，造成的后果是需求因為過(guò)于細碎和太多而無(wú)法控制，較少的用例有助于把握需求范圍，不容易遺漏。而針對一個(gè)10人月的小項目應該選擇小一些的粒度，如果用例粒度選擇過(guò)大，可能只有幾個(gè)業(yè)務(wù)用例，造成的后果是需求因為過(guò)于模糊而容易忽略細節。一般來(lái)說(shuō)，一個(gè)系統的業(yè)務(wù)用例定義在多于10個(gè)，少于50個(gè)之間，否則就應該考慮一下粒度選擇是否合適了。
不論粒度如何選擇，必須把握的原則是在同一個(gè)需求階段，所有用例的粒度應該是同一個(gè)量級的。這應該很好理解，在描述一棟建筑時(shí)，我們總是把高度，層數，單元數等合在一起介紹，而把下水道位置，插座數量等合在一起介紹。如果你這樣介紹一棟樓：這棟樓有10層，下水道在廚房東南角，預留了15個(gè)插座，共有5個(gè)單元，聽(tīng)眾一定會(huì )覺(jué)得云山霧罩，很難在腦子里形成一個(gè)清晰的影像。
如果對上面兩個(gè)問(wèn)題讀者還有疑惑，不用著(zhù)急，在以后的文章中應該會(huì )逐步加深理解。
預告：下一篇文章將通過(guò)一個(gè)例子，闡述獲取用例的一般方法和如何判斷用例的粒度是否合適。
Q&A
--------------------------------------------------------------------------
Q：由 pushboy 發(fā)布
在業(yè)務(wù)建模階段，用例的粒度以每個(gè)用例能夠說(shuō)明一件完整的事情為宜。即一個(gè)用例可以描述一項完整的業(yè)務(wù)流程。"
"在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個(gè)用例能夠描述操作者與計算機的一次完整交互為宜。"
那么，這樣一個(gè)場(chǎng)景 —— 用戶(hù)管理，有增刪改查
這里，是把 用戶(hù)管理 作為一個(gè)用例，還是把增刪改查分別作為用例呢？
他們每一個(gè)都是一個(gè)完整的業(yè)務(wù)流程和一次完整交互，而且也都是一個(gè)actor發(fā)起的動(dòng)作；怎么來(lái)確認呢？
我們的前提是一個(gè)普通的比如說(shuō)財務(wù)系統，而不是一個(gè)用戶(hù)管理系統
A：這個(gè)問(wèn)題很好，用例的粒度總是在這樣左也可右也可之間難以決定。對這個(gè)問(wèn)題來(lái)說(shuō)，我的觀(guān)點(diǎn)是業(yè)務(wù)用例應當用“管理用戶(hù)”或“維護用戶(hù)”作為合適的粒度，而增，刪，改，查則在作為系統用例。我的理由是：
增刪改查不能做為一個(gè)完整的業(yè)務(wù)來(lái)理解。作為一個(gè)管理業(yè)務(wù)，數據只有先增，才會(huì )有改，才會(huì )有刪。增刪改查結合起來(lái)才能完成actor的管理目的，只刪或只增加都不是業(yè)務(wù)的全部。這篇文章后來(lái)我又補充了一條粒度的判斷標準，可以到http://coffeewoo.itpub.net/去看，是否是一項完整業(yè)務(wù)，要看actor的目標，而不是事情是否完整。這個(gè)例子中，actor的目標是為了增加一個(gè)用戶(hù)嗎？是為了刪除一個(gè)用戶(hù)嗎？都不是，而是為了管理用戶(hù)，這個(gè)目標包括了用戶(hù)這個(gè)實(shí)體的整個(gè)生命周期。
再討論深一些，如果業(yè)務(wù)要求對用戶(hù)除了增刪改查，還有別的要求，例如權限升級，用戶(hù)在組織機構中復雜的關(guān)系變更，用戶(hù)與外部系統的交互....實(shí)際的情況可能會(huì )更多，那么，如果將每個(gè)都作為一個(gè)業(yè)務(wù)用例，很容易造成一個(gè)結果，這些原本與用戶(hù)這個(gè)實(shí)體緊密關(guān)聯(lián)，共同組成用戶(hù)實(shí)體生命周期的業(yè)務(wù)，被割裂成多個(gè)獨立的業(yè)務(wù)，因為定義了多個(gè)用例（請參看本人第一篇中的用例特征第一條）。要知道，在RUP中，用例驅動(dòng)的含義是，一個(gè)用例就是一個(gè)分析單元，設計單元，開(kāi)發(fā)單元，測試單元甚至部署單元。相信讀者都知道，把緊密關(guān)聯(lián)的業(yè)務(wù)分成多個(gè)獨立部分去實(shí)施是高成本的，高風(fēng)險的。
另外，為什么我要說(shuō)在系統用例階段要把增，刪，改，查又分出來(lái)呢？原因在于，系統用例的目的是為了將actor的業(yè)務(wù)用計算機模擬出來(lái)。我們都知道，一般情況下，增，刪，改，查對一個(gè)actor來(lái)說(shuō)是不會(huì )同時(shí)發(fā)生的，每次actor只會(huì )完成其中的一個(gè)行為。分開(kāi)來(lái)，有利于詳細分析模擬這一行為的細節而不至于混淆。另一方面，對WEB應用來(lái)說(shuō)，針對數據的增，刪，改，查等，很容易形成所謂的“模板”，增加用戶(hù)用這個(gè)模板，增加其它基礎數據可能也用同一個(gè)模板，無(wú)非是操作的數據（實(shí)體）不同而已。因此，在很多情況下，這些模板是可以復用的。對這個(gè)例子來(lái)說(shuō)，在系統用例階段，我們可以用“管理用戶(hù)” include “增加用戶(hù)”來(lái)表示這個(gè)實(shí)現關(guān)系，同時(shí)，讓“增加用戶(hù)”，“增加X(jué)X數據”等等用例來(lái)繼承自一個(gè)抽象出來(lái)的“增加數據”用例，這樣，可復用的模板體現在“增加數據”用例上，而具體業(yè)務(wù)，則體現在“增加X(jué)X數據”上。實(shí)際上，這也是一種OO思想的體現。
只有一個(gè)查詢(xún)是比較特殊的，查詢(xún)一般不一定只局限于一個(gè)actor，也不一定局限這個(gè)用例，一般都是所謂的綜合查詢(xún)，是可能跨用例的。所以根據實(shí)際情況，查詢(xún)可以作為一個(gè)業(yè)務(wù)用例出現
聯(lián)系客服
