先說說用例類型的問題。
用例類型，有的資料翻譯爲版型，英文原文是stereotype。在Rose中默認的類型有business usecase , business usecase realization和use case realization三種。相應的，就是指
業務用例：
業務用例實現：
用例實現：
若不指定類型，則它就是通常意義上的use case ：
Rose中定義了上述默認類型，但是也可以自定義用例類型。初學用UML建模的人常常在這些類型中迷失，搞不清楚這些類型是什麼含義，什麼時候該使用什麼類型。簡單說，需求分析中的各個階段要描述和分析的目標不同，爲表達不同的視角和分析目標，需要使用不同的用例類型。筆者的觀點是，用例類型的區分是爲了形式上的統一，但用例類型既然可以自定義，它就是一個很靈活的用法，不必墨守成規，大可在工作中根據實際情況定義適合自己項目特點和軟件過程的用例類型。不過，默認的用例類型已經幾乎可以滿足需求分析的各個階段，自定義的必要性並不大，並且UML的意義就是使用統一的形式描述需求，因此最好使用默認的類型。
說到需求分析階段，那麼需求分析都有些什麼階段呢？一般來說，需求分析要經過業務建模，用例分析和系統建模三個階段才能完成需求工作，這三個階段分別做什麼筆者會在以後的文章的詳細闡述，這裏爲了說明用例類型的含義和使用，先簡單介紹一下。
1、業務建模的目標是通過用例模型的建立來描述用戶需求，需求規格說明書通常在這個階段產生。這個階段通常使用業務用例和業務用例實現兩種類型；
2、用例分析是系統分析員採用OO方法來分析業務用例的過程，這個階段又稱爲概念模型階段。這個階段通常使用無類型的用例。用例分析是一個過渡過程，但筆者認爲其非常重要，業務架構通常在這個階段產生。
3、系統建模是將用戶的業務需求轉化爲計算機實現的過程。這個階段通常使用無類型的用例和用例實現兩種類型。系統範圍，項目計劃，系統架構通常在這個階段形成雛形（在系統分析階段確定）。
所謂business usecase，是用來描述用戶原始需求的，它的含義是站在用戶的角度，使用用戶的業務術語來描述用戶在其業務領域所做的事情。業務用例命名，描述都必須採用純業務語言，而不能出現計算機術語。因爲業務模型是系統分析員與用戶討論需求，達到一致理解的基礎，必須使用用戶熟悉的，不會有歧義的專業術語以避免系統分析員與用戶對同一事件的理解誤差。business usecase realization是達到需求可追溯要求的一個連接點，是用戶在其業務場景中如何做這一件事的載體。
筆者自己在用例分析和系統建模階段不區分用例類型，都使用無類型的use case，但在這兩個階段，用例的含義還是有所差別的。用例分析階段，用例主要是從 業務模擬的概念上，從OO的視角來分解、組合業務用例，粗略的建立一個業務架構。而在系統建模階段，用例主要是從計算機視角描述需求，規定開發範圍，作爲項目計劃的依據，爲系統設計做準備。usecase realization的含義可從business use case realization推知。
再來說說用例的粒度問題。
粒度是令人迷惑的。比如在ATM取錢的場景中，取錢，讀卡，驗證賬號，打印回執單等都是可能的用例，顯然，取錢包含了後續的其它用例，取錢粒度更大一些，其它用例的粒度則要小一些。到底是一個大的用例合適還是分解成多個小用例合適呢？這個問題並沒有一個標準的規則，筆者可以給大家分享的經驗是根據階段不同，使用不同的粒度。在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情爲宜。即一個用例可以描述一項完整的業務流程。這將有助於明確需求範圍。例如取錢，報裝電話，借書等表達完整業務的用例，而不要細到驗證密碼，填寫申請單，查找書目等業務中的一個步驟。在用例分析階段，用例的的粒度以每個用例能描述一個完整的事件流爲宜。可理解爲一個用例描述一項完整業務中的一個步驟。需要注意的是，這個階段需要採用OO方法，歸納，抽象業務用例中的概念模型。例如，寬帶業務需求中有申請報裝，申請遷移地址用例，在用例分析時，可歸納和分解爲提供申請資料，受理業務，現場安裝等多個業務流程中都會使用的概念用例。在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整交互爲宜。例如，填寫申請單，審覈申請單，派發任務單等。可理解爲一個操作界面，或一個頁面流。在RUP中，項目計劃要依據系統模型編寫，因此另一個可參考的粒度是一個用例的開發工作量在一週左右爲宜。
上述的粒度劃分方法筆者是用相對比較具體化的一些依據來說明。實際上，用例粒度的劃分依據（尤其是業務用例）最標準的方法是一個用例的粒度是否合適，是以該用例是否完成了參與者的某個目的爲依據的。這個說法比較籠統，也比較難以掌握。，舉個例子，某人去圖書館，查詢了書目，出示了借書證，圖書管理員查詢了該人以前借閱記錄以確保沒有未歸還的書，最後借到了書。從這段話中能得出多少用例呢？請記住一點，用例分析是以參與者爲中心的，因此用例的粒度以能完成參與者目的爲依據。這樣，實際上適合用例是：借書。只有一個，其它都只是完成這個目的過程--這裏討論的用例指的是業務用例--這個例子是比較明顯的能夠區分出參與者完整目的的，在很多情況下可能並沒有那麼明顯，甚至會有衝突。讀者可以從自己實際的情況去找出這種例子。以後的文章中筆者會做一些討論。
但是上述的粒度選擇並不是一個標準，只是在大多數情況下這樣的粒度選擇是比較合適的。筆者的意思也不是告訴讀者上述哪一種是最好的，而只是把一些常用的比較，劃分方法告訴讀者，期望的是幫助讀者在工作實踐中自己總結出一套適合自己的方法來。現實情況中，一個大型系統和一個很小的系統用例粒度選擇會有較大差異。這種差異是爲了適應不同的需求範圍。比如， 針對一個50人年的大型項目應該選擇更大的粒度，如果用例粒度選擇過小，可能出現上百甚至幾百個業務用例，造成的後果是需求因爲過於細碎和太多而無法控制，較少的用例有助於把握需求範圍，不容易遺漏。而針對一個10人月的小項目應該選擇小一些的粒度，如果用例粒度選擇過大，可能只有幾個業務用例，造成的後果是需求因爲過於模糊而容易忽略細節。一般來說，一個系統的業務用例定義在多於10個，少於50個之間，否則就應該考慮一下粒度選擇是否合適了。
不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。這應該很好理解，在描述一棟建築時，我們總是把高度，層數，單元數等合在一起介紹，而把下水道位置，插座數量等合在一起介紹。如果你這樣介紹一棟樓：這棟樓有10層，下水道在廚房東南角，預留了15個插座，共有5個單元，聽衆一定會覺得雲山霧罩，很難在腦子裏形成一個清晰的影像。
如果對上面兩個問題讀者還有疑惑，不用着急，在以後的文章中應該會逐步加深理解。
預告：下一篇文章將通過一個例子，闡述獲取用例的一般方法和如何判斷用例的粒度是否合適。
Q&A
--------------------------------------------------------------------------
Q：由 pushboy 發佈
在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情爲宜。即一個用例可以描述一項完整的業務流程。"
"在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整交互爲宜。"
那麼，這樣一個場景 —— 用戶管理，有增刪改查
這裏，是把 用戶管理 作爲一個用例，還是把增刪改查分別作爲用例呢？
他們每一個都是一個完整的業務流程和一次完整交互，而且也都是一個actor發起的動作；怎麼來確認呢？
我們的前提是一個普通的比如說財務系統，而不是一個用戶管理系統
A：這個問題很好，用例的粒度總是在這樣左也可右也可之間難以決定。對這個問題來說，我的觀點是業務用例應當用“管理用戶”或“維護用戶”作爲合適的粒度，而增，刪，改，查則在作爲系統用例。我的理由是：
增刪改查不能做爲一個完整的業務來理解。作爲一個管理業務，數據只有先增，纔會有改，纔會有刪。增刪改查結合起來才能完成actor的管理目的，只刪或只增加都不是業務的全部。是否是一項完整業務，要看actor的目標，而不是事情是否完整。這個例子中，actor的目標是爲了增加一個用戶嗎？是爲了刪除一個用戶嗎？都不是，而是爲了管理用戶，這個目標包括了用戶這個實體的整個生命週期。
再討論深一些，如果業務要求對用戶除了增刪改查，還有別的要求，例如權限升級，用戶在組織機構中複雜的關係變更，用戶與外部系統的交互....實際的情況可能會更多，那麼，如果將每個都作爲一個業務用例，很容易造成一個結果，這些原本與用戶這個實體緊密關聯，共同組成用戶實體生命週期的業務，被割裂成多個獨立的業務，因爲定義了多個用例（請參看本人第一篇中的用例特徵第一條）。要知道，在RUP中，用例驅動的含義是，一個用例就是一個分析單元，設計單元，開發單元，測試單元甚至部署單元。相信讀者都知道，把緊密關聯的業務分成多個獨立部分去實施是高成本的，高風險的。
另外，爲什麼我要說在系統用例階段要把增，刪，改，查又分出來呢？原因在於，系統用例的目的是爲了將actor的業務用計算機模擬出來。我們都知道，一般情況下，增，刪，改，查對一個actor來說是不會同時發生的，每次actor只會完成其中的一個行爲。分開來，有利於詳細分析模擬這一行爲的細節而不至於混淆。另一方面，對WEB應用來說，針對數據的增，刪，改，查等，很容易形成所謂的“模板”，增加用戶用這個模板，增加其它基礎數據可能也用同一個模板，無非是操作的數據（實體）不同而已。因此，在很多情況下，這些模板是可以複用的。對這個例子來說，在系統用例階段，我們可以用“管理用戶” include “增加用戶”來表示這個實現關係，同時，讓“增加用戶”，“增加XX數據”等等用例來繼承自一個抽象出來的“增加數據”用例，這樣，可複用的模板體現在“增加數據”用例上，而具體業務，則體現在“增加XX數據”上。實際上，這也是一種OO思想的體現。
只有一個查詢是比較特殊的，查詢一般不一定只侷限於一個actor，也不一定侷限這個用例，一般都是所謂的綜合查詢，是可能跨用例的。所以根據實際情況，查詢可以作爲一個業務用例出現。
感謝網友pushboy 提出問題。原帖位於：http://www.itpub.net/507773.html
*********************************************************
作者coffeewoo 歡迎您訪問文章原始出處 : http://coffeewoo.itpub.net ，閱讀中有任何問題可以在BLOG上留言或發郵件到 [email protected]，我將盡力爲您解答。具有代表性的問題我會以 Q &A的形式收錄到對應的文章之後。希望本系列文章對您有幫助。歡迎轉載，敬請註明，謝謝 ^_^
強烈期待下文 太讚了！
強烈期待下文 太讚了！
最近比較忙，今天正好上來更新。難得兄弟喜歡，以後常來逛逛啊:) 謝謝！
好 謝謝
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 好文章,挺喜歡的,以前看過一些書講用例不是象老兄這樣以一個筆記的形式講的,看不下去,現在正好能夠好好的學習一下,謝謝!
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 very good
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 好文章，現在挺明白的，不過在具體實踐中還得結合樓主的文章好好體會體會
審覈能作爲一個業務用例嗎？ 在業務流程中，審覈是經常用到的一個東東，不知道在業務建模階段，是否應該作爲一個用例？如果是，則又導致用例非常多！
麻煩解答一下！謝謝！
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 Q&A提得好，答得更好。我正遇到這個問題。一下子豁然開朗了。贊一個。
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 good!
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 天啊,樓主文章裏的圖片真詭異，圖片另存爲存成一個HTML文件，內容“rss功能維護中，暫停使用。預計與一週後開放。 ”，用影音傳輸帶能抓下來，但居然另命名不了，把抓下來的往WORD裏放，又居然光有個方框看不到圖片，高人就是高人
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 太精彩了，興奮的直搓手！
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 提個關於過程控制的軟件需求分析問題，對於業務管理者來說（一般是中層們），他們也是系統的用戶，但他們參與系統的主要方式是對中層之下用戶操作業務的結果進行查詢分析，這樣這些查詢久的定義成用例。可這些查詢用例之間或是和其他用例之間又沒有什麼交互，那我是不是需要把每個這樣的查詢用例當成一個單獨的業務來繪製業務場景圖，或是把這些查詢弄成一個綜合查詢業務，但那樣泳道好像太多，沒有實際意義。疑惑。
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 請教,如果將用戶的"增刪改查"合併爲一個"用戶管理",那麼業務用例實現的活動圖怎麼畫?難道要對一個用例實現分別畫4個活動圖?
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 通常在業務建模階段是解決要做什麼，也叫需求提出階段；分析模型階段是解決能做什麼，通常分析模型並不一定能被用戶和客戶理解，但分析模型有助於開發人員驗證在需求提出階段產生的系統規格說明書，分析模型可叫做應用域模型；系統建模型解決怎麼做這個問題，也即是執行者怎樣和系統交互來處理應用域模型。
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 路過，看過，收益過！！ 不頂不行！！！
不僅僅對樓主的知識佩服，更對樓主的精神和人品讚揚。
樓主給我們做了榜樣，向樓主學習！！
附帶：現在很多人都恃才自傲，不可否認他們的知識令人折服，但他們的人品卻大打折扣。
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 不錯,謝謝了.
附帶：現在很多人都恃才自傲，不可否認他們的知識令人折服，但他們的人品卻大打折扣。
這裏頭包括我.嘿嘿.
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 拜讀你的大作，受益頗多，非常感謝！有一個問題請教！
是否讀過軟件需求這本書，在其中，需求層次分爲業務需求，用戶需求及系統需求。對應這三個層次是不同的三類人員：高層管理人員、系統用戶及系統分析人員。
對應着你的業務建模，似乎描述用戶需求，請問，在這裏如何區分上述的業務需求和用戶需求，抑或你的業務建模結果已體現了二者。
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 你好，咖啡兄。此處系統架構應是系統體系結構是麼！如果是，你是根據設計視、過程視、實現視、配置視這幾個視圖來描述體系結構圖的，所有就有需求分析階段確定雛形，在系統分析階段確定。其中，需求分析階段確定用例視；在系統分析階段確定設計視、過程視、實現視、配置視，對麼。
在文中提到主要的輸入：草圖，系統架構，業務規則，補充用例規約，系統原型。主要的輸出：調整後的分析模型，子系統，組件視圖和部署視圖（針對分佈式應用而言），請問在系統分析階段（邏輯設計階段）能設計出部署圖麼？。
還有，似乎在通常的開發方法學中系統分析階段包括需求分析階段，因此不知你是如何劃分的，非常感謝！
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 需求分析師和系統分析員的區別是什麼？
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 coffeewoo ：你說根據實際情況，查詢可以作爲一個業務用例出現。
那麼在一個系統中，特別是管理信息系統中，涉及大量的查詢，每個人也都有權限進行查詢。如果此時按照你說的將查詢作爲一個業務用例。那到系統分析階段呢，查詢下面的系統用例豈不很多很多，針對每種情況都有一個系統用例，此時用例數目是否太多了？盼望你的解答！！
這裏太棒了，這幾天一定逐一看完，抓緊時間！！
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 還是有點迷糊，，在琢磨琢磨把
re: OO系統分析員之路--用例分析系列（2）--用例的類型與粒度 在這篇博文中，我看到了你對業務模型以及系統模型的描述，但似乎沒有看到，用例分析也就是概念模型的部分的描述。