作者：張克強??? 作者微博：張克強-敏捷307

RUP系的考慮

在RUP中，沒有對用例的顆粒度給出清晰的指導。2004年Rational?中國區技術銷售經理?傅純一發表一文《用例建模指南》，是這樣說明用例的粒度的。

我的系統需要有多少個用例？這是很多人在用例建模時會產生的疑惑。描述同一個系統，不同的人會產生不同的用例模型。例如對于各種系統中常見的"維護用戶"用例，它里面包含了添加用戶、修改用戶信息、刪除用戶等操作，這些操作在該用例的事件流可以表述成為基本流的子事件流(subflow)。

管理用戶-基本事件流

該基本流由三個子事件流構成：

1)?添加用戶子事件流
…

2)?修改用戶?子事件流
…

3)?刪除用戶子事件流
…

但是你也可以根據該用例中的具體操作把它抽象成為三個用例，它所表示的系統需求和單個用例的模型是完全一樣的。

應該如何確定用例的粒度呢？在一次技術研討會上，有人問起Ivar?Jacoboson博士，一個系統需要有多少個用例？大師的回答是20個，當然他的意思是最好將用例模型的規模控制在幾十個用例左右，這樣比較容易來管理用例模型的復雜度。在用例個數大致確定的條件下，我們就很容易來確定用例粒度的大小。對于較復雜的系統，我們需要控制用例模型一級的復雜度，所以可以將復雜度適當地移往每一個用例的內部，也就是讓一個用例包含較多的需求信息量。對于比較簡單的系統，我們則可以將復雜度適度地曝露在模型一級，也就是我們可以將較復雜的用例分解成為多個用例。

用例的粒度不但決定了用例模型級的復雜度，而且也決定了每一個用例內部的復雜度。我們應該根據每個系統的具體情況，因時因宜地來把握各個層次的復雜度，在盡可能保證整個用例模型的易理解性前提下決定用例的大小和數目

傅的這篇文件代表了當時雅各布森-RUP系對用例顆粒度的看法。

科伯恩的關于顆粒度的考慮

在科伯恩的編寫有效用例中，探討了CRUD類型用例，CRUD是指創建、檢索、更新和刪除，上述的添加用戶、修改用戶和刪除用戶就是典型的CRUD類型用例。書中提到“S.R.A公司的Susan?Lilly認為分離的CRUD用例便于追蹤，主執行者可以安全地調用不同功能。但是，我傾向于先使用單個管理實體用例對其進行處理，這樣可以減少用例數目。如果編寫用例的復雜度增加，再對其進行分裂。”“在實際使用中，兩種方法都可以使用，到目前為止沒有足夠的證據表明哪個方法好或不好”。

編寫開發用例的時間顆粒度

仍然在《編寫有效用例》中，談到了用例需要的平均時間，對于識別用例摘要，即是草擬，平均每人每天2.8個，可以換算為每用例草擬摘要需2.9小時，整理并添加其他需求，總計每個用例需要2個工作周，而開發需要每用例3到5個工作周。合計的話，約每用例需要5到7個工作周，可換算為每用例約需要200工時到280工時，或者1.2人月到1.7人月。

而在1993年Gustav?Karner提出的用例點方法中，一個中等用例含有4～7個環形事務，計為10個用例點；一個復雜用例含有超過7個環形事務，計為15個用例點。Gustav?Karner給出的缺省用例生產率是每用例點需20工時，對于中等用例而言，就需要200工時，復雜用例需要300工時。這個結果與科伯恩的結果極為接近。

譚云杰（Coffeewoo）在《大象Thinking in UML》第2版中，提到了好像一個用例費時約2人周（那書好厚，回頭再找找不到了，也許記錯了）

執行用例的時間顆粒度

另外一個觀察用例顆粒度的維度是用例執行的時間。在科伯恩的書里，用戶目標用例標為藍色，海平面（對等于雅各布森用例的系統用例），在多數情況下，用戶目標用例需要一次2到20分鐘的處理。概要層次（白色、云朵，風箏）的用例通常需要執行幾個小時到幾個月，甚至幾年。這層次的用例對照到雅各布森用例體系，相當于業務用例。

在《大象Thinking in UML》第2版中，提出“以一個用例能夠描述操作者與計算機的一次完整交互為宜”，按這樣推斷的話，與2到20分鐘的處理是一致的。

用例篇幅的顆粒度

還有一個觀察用例顆粒度的維度是用例規約的篇幅，科伯恩推薦用例的主成功場景的步驟在3到8、9步。他說：“對于一個要通過10個以上中間步驟才能完成對過程來說，人們感覺是不能容忍或難以想象的”。“幾乎所有多于11步的用例都可以被裁短而不影響表達。”

從RUP和編寫有效用例公布的各類例子來看，一個步驟一般在A4篇幅下需要1行到3行，基本流或者主成功場景加上備選流或者擴展場景再加上各類用例屬性字段，一般而言用例的篇幅是在半頁到2頁A4紙范圍內。

Use-Case?2.0中的顆粒度

2011年，雅各布森為首三人等發布了Use-Case?2.0。其第4條原則是Principle?4:?Build?the?system?in?slices。將Use-Case進行切片，稱為Use-Case?Slice。

The?concept?of?a?use-case?slice?is?as?integral?to?Use-Case?2.0?as?the?use?case?itself.?It?is?the?slices?that?enable?the?use?cases?to?be?broken?down?into?appropriately?sized?pieces?of?work?for?the?development?team?to?tackle.?Imagine?that?you?are?part?of?a?small?team?producing?working?software?every?two?weeks.?A?whole?use?case?is?probably?too?much?to?be?completed?in?one?two-week?period.?A?use-case?slice?though?is?another?matter?because?it?can?be?sliced?as?thinly?as?the?team?requires.?Use-case?slices?also?allow?the?team?to?focus?on?providing?a?valuable,?usable?system?as?soon?as?possible,?shedding?all?unnecessary?requirements?on?the?way.

在Use-Case?2.0中，Use-Case?Slice的推薦組織方式是利用條目化工具與Use-Case分別管理，維護兩者的關聯從屬關系，推薦采用了故事點了對Use-Case?Slice進行估算。這樣處理后，Use-Case相當于User?Story中的EPIC，Use-Case?Slice相當于User?Story。

更多相關文章

需求用例分析之六：業務用例之科伯恩系

需求用例分析之五：業務用例之Rational系

需求用例分析之四：業務規則

需求用例分析之三：補充規約

需求用例分析之二：級別設置

需求用例分析之一：異常流

總結

以上是生活随笔為你收集整理的需求用例分析之八：用例颗粒度的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。