用例型別有的翻譯為版型；英文為stereotype。用例型別一般分為：普通用例(usecase)和業務用例(business usecase).
業務建模的目標是通過用例模型的建立來描述使用者需求，需求規格說明書通常在這個階段產生。這個階段通常使用業務用例型別；
用例分析是系統分析員採用 oo 方法來分析業務用例的過程，這個階段又稱為概念模型階段。這個階段通常使用無型別的用例。 用例分析是乙個過渡過程，但筆者認為其非常重要， 業務架構通常在這個階段產生。
系統建模是將使用者的業務需求轉化為計算機實現的過程。這個階段通常使用無型別的用例和用例實現兩種型別。系統範圍， 專案計畫，系統架構通常在
這個階段形成雛形（在系統分析階段確定）。
所謂 business usecase，是用來描述使用者原始需求的， 它的含義是站在使用者的角度， 使用使用者的業務術語來描述使用者在其業務領域所做的事情。
業務用例命名、描述都不必須採用純業務語言。而不能使用計算機術語。因為業務模型是系統分析員與使用者討論需求， 達到一致理解的基礎， 必須使用使用者熟悉的，不會有歧義的專業術語以避免系統分析員與使用者對同一事件的理解誤差。
筆者自己在用例分析和系統建模階段不區分用例型別， 都使用無型別的 use case， 但在這兩個階段， 用例的含義還是有所差別的。 用例分析階段， 用例主要是從業務模擬的概念上， 從 oo 的視角來分解、 組合業務用例， 粗略的建立乙個業務架構。 而在系統建模階段， 用例主要是從計算機視角描述需求， 規定開發範圍，作為專案計畫的依據， 為系統設計做準備。
粒度是令人迷惑的。 比如在 atm 取錢的場景中， 取錢， 讀卡，驗證賬號， 列印回執單等都是可能的用例， 顯然， 取錢包含了後續的其它用例， 取錢粒度更大一些， 其它用例的粒度則要小一些。 到底是乙個大的用例合適還是分解成多個小用例合適呢？ 這個問題並沒有乙個標準的規則， 筆者可以給大家分享的經驗是根據階段不同， 使用不同的粒度。在業務建模階段， 用例的粒度以每個用例能夠說明一件完整的事情為宜。 即乙個用例可以描述一項完整的業務流程。這將有助於明確需求範圍。 例如取錢， 報裝**， 借書等表達完整業務的用例， 而不要細到驗證密碼， 填寫申請單， 查詢書目等業務中的乙個步驟。在用例分析階段， 用例的的粒度以每個用例能描述乙個完整的事件流為宜。 可理解為乙個用例描述一項完整業務中的乙個步驟。需要注意的是，這個階段需要採用 oo 方法， 歸納， 抽象業務用例中的概念模型。 例如， 寬頻業務需求中有申請報裝， 申請遷移位址用例，在用例分析時，可歸納和分解為提供申請資料， 受理業務，現場安裝等多個業務流程中都會使用的概念用例。在系統建模階段， 用例視角是針對計算機的，因此用例的粒度以乙個用例能夠描述操作者與計算機的一次完整互動為宜。 例如， 填寫申請單， 審核申請單， 派發任務單等。 可理解為乙個操作介面， 或乙個頁面流。在 rup 中， 專案計畫要依據系統模型編寫， 因此另乙個可參考的粒度是乙個用例的開發工作量在一周左右為宜。
實際上，用例粒度的劃分依據（尤其是業務用例） 最標準的方法是乙個用例的粒度是否合適， 是以該用例是否完成了參與者的某個目的為依據的。舉個例子， 某人去圖書館， 查詢了書目， 出示了借書證， 圖書管理員查詢了該人以前借閱記錄以確保沒有未歸還的書， 最後借到了書。 從這段話中能得出多少用例呢？ 請記住一點， 用例分析是以參與者為中心的， 因此用例的粒度以能完成參與者目的為依據。 這樣， 實際上適合用例是： 借書。 只有乙個，其它都只是完成這個目的過程——這裡討論的用例指的是業務用例——這個例子是比較明顯的能夠區分出參與者完整目的的， 在很多情況下可能並沒有那麼明顯， 甚至會有衝突。
不論粒度如何選擇， 必須把握的原則是在同乙個需求階段， 所有用例的粒度應該是同乙個量級的。
參考：
oo_raod coffeewoo
UML 用例粒度
剛剛接觸uml的時候，這個粒度搞的我一臉懵逼，但是經過系統的學習，還是將其解決了！這塊的知識屬於uml用例圖中的知識，所以在解釋名詞的時候都是以uml為根據的！以前在學軟體工程的時候有乙個名詞叫做測試用例，那個用例指的是為了測試系統的正確性提前準備的例子。在uml中的用例主要是對系統的使用者需求 主...
UML 用例的粒度
來自 太初有產 乙個用例到底因該多大呢？這個問題恐怕很難說得清楚。按照我們對用例的定義來說，用例就是使用者 外部系統 和系統的一次典型互動。但是有可能這個互動特別複雜。我們來看gis系統中的乙個很普通的互動 新增圖層。對於新增圖層這個用例使用者的要求顯然是系統能夠記住這個圖層並在系統中其它地方使用，...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...