作者：張克強(qiáng)

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

在雅各布森用例分析方法和科伯恩用例分析方法中用例本身其實(shí)都沒有“業(yè)務(wù)規(guī)則”的屬性。但是業(yè)界使用中常常會給用例加上這個屬性，這是為什么呢？為什么兩位大師沒有加上，是大師們疏忽了？而為什么不少人加上了呢？

從時間和傳播上很容易推斷，業(yè)務(wù)規(guī)則的來源是傳統(tǒng)的需求規(guī)格說明書。在傳統(tǒng)的需求規(guī)格說明書中，整理提煉業(yè)務(wù)規(guī)則或稱業(yè)務(wù)邏輯是其中核心的分析產(chǎn)物。受到傳統(tǒng)需求規(guī)格說明書的深遠(yuǎn)影響，不少人覺得這樣的業(yè)務(wù)規(guī)則是值得寫的用例規(guī)約中的。

業(yè)務(wù)規(guī)則有哪些？

在《用例規(guī)約的編寫--業(yè)務(wù)規(guī)則和實(shí)體描述》一文（下文稱為c文）中，將業(yè)務(wù)規(guī)則分為三類：

1．第一種是全局規(guī)則，一般與所有用例都相關(guān)而不是與特定用例相關(guān)

2．第二種是交互規(guī)則，產(chǎn)生于用例場景當(dāng)中

3．第三種是內(nèi)稟規(guī)則，是指業(yè)務(wù)實(shí)體本身具備的規(guī)則，并且不因?yàn)橥獠康慕换ザ兓囊?guī)則，例如，每張定單至少要有一件商品，同一類商品數(shù)量不能大于5件等。

在這篇文章的后面提出“將這些單獨(dú)列出來并給予關(guān)注和管理是很有必要的”。

顯然的，將全局規(guī)則列出的話，肯定不會在用例規(guī)約中，因?yàn)樗c特定用例無關(guān)；那么在用例規(guī)約中要單獨(dú)列出來的是交互規(guī)則和內(nèi)稟規(guī)則。

用例規(guī)約與交互規(guī)則

先來看交互規(guī)則的情況，同樣在上述那篇文章中?“交互規(guī)則是在用例場景當(dāng)中產(chǎn)生的，它們規(guī)定了滿足什么條件后業(yè)務(wù)將如何反應(yīng)。通常，這部分規(guī)則是最復(fù)雜，也最不穩(wěn)定，最容易變化的。大家所說的需求經(jīng)常變更相信絕大部分就來自于此”，那么如果是先寫了用例場景（指事件流），再將這復(fù)雜不穩(wěn)定交易的規(guī)則提煉出來后，就將產(chǎn)生信息冗余一致性的問題。在以后處理變化時，需要修改2處。如果是提煉到用例以外，那么上下文關(guān)聯(lián)問題和冗余不一致問題就更加突出，如果是提煉在用例之內(nèi)，即是有專門的“業(yè)務(wù)規(guī)則”屬性字段，事件流的表現(xiàn)力是足夠表現(xiàn)任何復(fù)雜規(guī)則的，把相同信息在同一個地方寫兩次是沒有必要的。所以這樣的提煉是多余的。

而如果是在業(yè)務(wù)規(guī)則中先寫了交互規(guī)則，再來寫用例事件流，也可大致分為兩種情況，一是按傳統(tǒng)SRS寫法已經(jīng)書寫了較完整的交互規(guī)則，這種情況下，用例事件流的書寫就顯得多余，往往在2～4行字中說明參見業(yè)務(wù)規(guī)則，然后事件流就結(jié)束了，這種寫法相當(dāng)于穿著用例外衣的傳統(tǒng)SRS，我想這也許就是兩位大師都沒有加上“業(yè)務(wù)規(guī)則”屬性的原因。二是先非常概要的記錄了業(yè)務(wù)規(guī)則，然后書寫事件流來體現(xiàn)業(yè)務(wù)規(guī)則，這種情況下事件流的書寫就顯得有價值。那么在這種情況下這概要的業(yè)務(wù)規(guī)則就不必要獨(dú)占一個專門的屬性字段，完全可以寫到用例的簡要說明中。

用例規(guī)約與內(nèi)稟規(guī)則

再來看內(nèi)稟規(guī)則的情況，首先交互規(guī)則與內(nèi)稟規(guī)則的差異是極為模糊的，比如諸如“同一類商品數(shù)量不能大于5件”在交互中需要校驗(yàn)，是可以屬于交互規(guī)則的。其次這本身屬于需求的范疇，這是業(yè)務(wù)層面的規(guī)則，c文也是說“這類規(guī)則是業(yè)務(wù)實(shí)體的內(nèi)在規(guī)則”，但是c文緊接著說“因此應(yīng)該寫到領(lǐng)域模型文檔中”。顯然的此類規(guī)則應(yīng)當(dāng)反映在用例中，因?yàn)槿绻辉谟美蟹从?#xff0c;那么需求就是不完整的。其次在用例中如何反映？這與交互規(guī)則的情況是完全一樣，概要可以寫到簡要說明，具體規(guī)則的具體應(yīng)用在事件流中反映，如果規(guī)則的篇幅長而且又是比較細(xì)節(jié)，需要引用到其它文件，但前提是一定在事件流里明確說明并引用。

?

事實(shí)上c文在后面說到“同時這部分規(guī)則（指交互規(guī)則）通常在系統(tǒng)中以Control類去實(shí)現(xiàn)，MVC模式如此，SOA架構(gòu)中的BPEL也是如此”“這類規(guī)則（指內(nèi)稟規(guī)則）應(yīng)該實(shí)現(xiàn)到你的實(shí)體類中去，不論你的業(yè)務(wù)實(shí)體是EntityBean,JavaBean,POJO還是COM+，根據(jù)面向?qū)ο蟮姆庋b原則，內(nèi)稟的邏輯一定不要讓它暴露到外部去”，這就讓需求分析去考慮了后續(xù)分析設(shè)計的任務(wù)，需求分析已經(jīng)是天下難事，再兼顧分析設(shè)計，那么用例承擔(dān)了過重的任務(wù)。當(dāng)然在RUP當(dāng)中，用例確實(shí)承擔(dān)了如此重的任務(wù)，在“擁抱敏捷的用例分析方法”一文中說明了用例分析不必承擔(dān)過多的職責(zé)，不必考慮識別具體實(shí)現(xiàn)的類，專注于需求表達(dá)。專注于表達(dá)需求的用例對后續(xù)的面向?qū)ο蠓治雠c設(shè)計同樣是高效而且準(zhǔn)確的傳遞信息。

小結(jié)

經(jīng)過以上分析，可以看到“業(yè)務(wù)規(guī)則”確實(shí)不是用例規(guī)約的必需字段，可以通過用例簡要說明和事件流覆蓋用例級別所有的業(yè)務(wù)規(guī)則。如果非要有業(yè)務(wù)規(guī)則，有一個簡單的規(guī)則來幫助判斷是否體現(xiàn)了用例分析的優(yōu)勢：事件流的描述文字是否明顯比業(yè)務(wù)規(guī)則長？如果很長的業(yè)務(wù)規(guī)則配與很短的事件流，那么這是穿著用例外衣的傳統(tǒng)SRS寫法。

另外，有些規(guī)則篇幅可能比較長，也比較細(xì)節(jié)，比如說明地址信息的有效性校驗(yàn)，在《編寫有效用例》中建議在用例中引用，另外地方書寫，比如數(shù)據(jù)字典。這也是不錯的辦法。

參考文獻(xiàn)

OO系統(tǒng)分析員之路--用例分析系列（7）--用例規(guī)約的編寫--業(yè)務(wù)規(guī)則和實(shí)體描述，coffeewoo??http://blog.csdn.net/coffeewoo/article/details/4073551?

擁抱敏捷的用例分析方法，張克強(qiáng)，http://blog.csdn.net/zhangmike/article/details/6790919

總結(jié)

以上是生活随笔為你收集整理的需求用例分析之四：业务规则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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