作者：張克強(qiáng)??? 作者微博：張克強(qiáng)-敏捷307

RUP系的考慮

在RUP中，沒有對(duì)用例的顆粒度給出清晰的指導(dǎo)。2004年Rational?中國(guó)區(qū)技術(shù)銷售經(jīng)理?傅純一發(fā)表一文《用例建模指南》，是這樣說明用例的粒度的。

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

管理用戶-基本事件流

該基本流由三個(gè)子事件流構(gòu)成：

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

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

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

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

應(yīng)該如何確定用例的粒度呢？在一次技術(shù)研討會(huì)上，有人問起Ivar?Jacoboson博士，一個(gè)系統(tǒng)需要有多少個(gè)用例？大師的回答是20個(gè)，當(dāng)然他的意思是最好將用例模型的規(guī)模控制在幾十個(gè)用例左右，這樣比較容易來管理用例模型的復(fù)雜度。在用例個(gè)數(shù)大致確定的條件下，我們就很容易來確定用例粒度的大小。對(duì)于較復(fù)雜的系統(tǒng)，我們需要控制用例模型一級(jí)的復(fù)雜度，所以可以將復(fù)雜度適當(dāng)?shù)匾仆恳粋€(gè)用例的內(nèi)部，也就是讓一個(gè)用例包含較多的需求信息量。對(duì)于比較簡(jiǎn)單的系統(tǒng)，我們則可以將復(fù)雜度適度地曝露在模型一級(jí)，也就是我們可以將較復(fù)雜的用例分解成為多個(gè)用例。

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

傅的這篇文件代表了當(dāng)時(shí)雅各布森-RUP系對(duì)用例顆粒度的看法。

科伯恩的關(guān)于顆粒度的考慮

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

編寫開發(fā)用例的時(shí)間顆粒度

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

而在1993年Gustav?Karner提出的用例點(diǎn)方法中，一個(gè)中等用例含有4～7個(gè)環(huán)形事務(wù)，計(jì)為10個(gè)用例點(diǎn)；一個(gè)復(fù)雜用例含有超過7個(gè)環(huán)形事務(wù)，計(jì)為15個(gè)用例點(diǎn)。Gustav?Karner給出的缺省用例生產(chǎn)率是每用例點(diǎn)需20工時(shí)，對(duì)于中等用例而言，就需要200工時(shí)，復(fù)雜用例需要300工時(shí)。這個(gè)結(jié)果與科伯恩的結(jié)果極為接近。

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

執(zhí)行用例的時(shí)間顆粒度

另外一個(gè)觀察用例顆粒度的維度是用例執(zhí)行的時(shí)間。在科伯恩的書里，用戶目標(biāo)用例標(biāo)為藍(lán)色，海平面（對(duì)等于雅各布森用例的系統(tǒng)用例），在多數(shù)情況下，用戶目標(biāo)用例需要一次2到20分鐘的處理。概要層次（白色、云朵，風(fēng)箏）的用例通常需要執(zhí)行幾個(gè)小時(shí)到幾個(gè)月，甚至幾年。這層次的用例對(duì)照到雅各布森用例體系，相當(dāng)于業(yè)務(wù)用例。

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

用例篇幅的顆粒度

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

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

Use-Case?2.0中的顆粒度

2011年，雅各布森為首三人等發(fā)布了Use-Case?2.0。其第4條原則是Principle?4:?Build?the?system?in?slices。將Use-Case進(jìn)行切片，稱為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分別管理，維護(hù)兩者的關(guān)聯(lián)從屬關(guān)系，推薦采用了故事點(diǎn)了對(duì)Use-Case?Slice進(jìn)行估算。這樣處理后，Use-Case相當(dāng)于User?Story中的EPIC，Use-Case?Slice相當(dāng)于User?Story。

更多相關(guān)文章

需求用例分析之六：業(yè)務(wù)用例之科伯恩系

需求用例分析之五：業(yè)務(wù)用例之Rational系

需求用例分析之四：業(yè)務(wù)規(guī)則

需求用例分析之三：補(bǔ)充規(guī)約

需求用例分析之二：級(jí)別設(shè)置

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。