趙玉明 舒紅平 魏培陽

摘 要：用例驅(qū)動(dòng)整個(gè)統(tǒng)一軟件開發(fā)過程，但用例劃分缺乏統(tǒng)一標(biāo)準(zhǔn)規(guī)范，從而導(dǎo)致用例劃分不夠準(zhǔn)確。針對(duì)該問題，以業(yè)務(wù)場(chǎng)景為基礎(chǔ)，對(duì)用例粒度劃分展開研究，提出采用3種范式規(guī)范用例粒度劃分。從用例劃分源頭、建模階段及實(shí)際工程規(guī)模展開進(jìn)行分析，3種范式為建模人員在具體業(yè)務(wù)場(chǎng)景下的用例劃分提出解決方案，可為建模人員節(jié)省建模時(shí)間、提升建模效率，從而完善系統(tǒng)架構(gòu)。

關(guān)鍵詞：RUP;業(yè)務(wù)場(chǎng)景;軟件建模;用例劃分;范式

DOI：10. 11907/rjdk. 182425

中圖分類號(hào)：TP302

文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1672-7800（2019）006-0052-04

Abstract： The use case drives the whole software rational unified process（RUP）. However， the division of use cases lacks unified standards and norms， which leads to inaccurate division of use cases. In view of this problem， three norm forms are proposed to standardize the partition of use case granularity. In this paper， the use case granularity partitioning is studied based on business scenarios， and three norm forms are proposed to standardize the use case granularity partitioning in the modeling phase. The source of use case partitioning， the stage of modeling and the scale of the actual project are analyzed and the three norm forms provide solutions for use case partitioning in specific business scenarios. Through the three norm forms， modelers can save modeling time， improve modeling efficiency and the system architecture.

Key Words： RUP; business scenario; software modeling; use case granularity; norm forms

0 引言

在軟件工程領(lǐng)域，RUP既是一套軟件方法，又是一種典型的軟件開發(fā)模式。它以迭代增量式架構(gòu)為中心，用例驅(qū)動(dòng)的軟件開發(fā)方法為主要特征，其中用例驅(qū)動(dòng)是貫穿軟件開發(fā)始終的方法。用例驅(qū)動(dòng)整個(gè)軟件架構(gòu)的建立，軟件架構(gòu)是邏輯層次較高的系統(tǒng)視圖，是系統(tǒng)規(guī)劃與設(shè)計(jì)的高層次抽象[1]。

但是，在用例粒度劃分上，沒有一套完整的規(guī)范，導(dǎo)致對(duì)于同一個(gè)業(yè)務(wù)場(chǎng)景，不同的建模人員劃分出來的用例可能呈現(xiàn)不同程度的差異。同時(shí)，大多數(shù)建模人員并沒有相關(guān)領(lǐng)域知識(shí)，在建模過程中更多依靠建模理論知識(shí)及自身業(yè)務(wù)經(jīng)驗(yàn)。由于缺少具體業(yè)務(wù)場(chǎng)景與相關(guān)規(guī)范，無法準(zhǔn)確挖掘業(yè)務(wù)中的用例。

美國(guó)學(xué)者Wiegers突出說明了用例在軟件需求工程中的重要性，提出針對(duì)具體的業(yè)務(wù)場(chǎng)景，用例應(yīng)該有粒度，同時(shí)還提出用例與軟件架構(gòu)之間的關(guān)系，但是并沒有對(duì)用例劃分提出統(tǒng)一指導(dǎo)意見，也沒有指出如何從具體業(yè)務(wù)場(chǎng)景中推導(dǎo)出用例。文獻(xiàn)[3]在提出用例重要性的同時(shí)，發(fā)現(xiàn)一個(gè)系統(tǒng)用例個(gè)數(shù)需保證在20個(gè)左右，但是沒有提出相關(guān)理論依據(jù)，也沒有結(jié)合實(shí)際工程規(guī)模。文獻(xiàn)[1]雖然給出了用例劃分方法，也提出應(yīng)根據(jù)建模階段、工程規(guī)模及實(shí)際業(yè)務(wù)場(chǎng)景劃分粒度，但更多的是基于工程實(shí)例，沒有形成完整的理論規(guī)范。

基于以上分析，本文一方面結(jié)合國(guó)際前沿需求工程知識(shí)，另一方面，結(jié)合國(guó)內(nèi)研究與工程實(shí)踐，以文獻(xiàn)[6]-[9]的工程實(shí)踐為依托，提出從一個(gè)具體業(yè)務(wù)場(chǎng)景出發(fā)，從用例實(shí)質(zhì)入手，以建模階段及實(shí)際工程為依據(jù)，整合出3種用例劃分范式，使劃分出來的用例向上可以追溯業(yè)務(wù)場(chǎng)景，為軟件架構(gòu)設(shè)計(jì)提供基礎(chǔ)，向下可以推導(dǎo)需求，為驗(yàn)證需求提供依據(jù)，從而節(jié)約建模時(shí)間、提升建模效率。

1 影響用例粒度劃分的3個(gè)因素

用例粒度劃分存在3個(gè)方面的問題，也是影響用例劃分3個(gè)重要因素。

（1）在具體業(yè)務(wù)場(chǎng)景下，業(yè)務(wù)邊界模糊不清[5]。由于缺少邊界，不同的建模人員對(duì)業(yè)務(wù)進(jìn)行抽象提煉的方向不同，包含在邊界內(nèi)的用例也會(huì)呈現(xiàn)出不同程度的紊亂。

（2）混淆建模階段[4]。建?？梢苑譃椴煌碾A段，如果沒有對(duì)軟件建模所處的階段有一個(gè)清晰的認(rèn)識(shí)，劃分出來的用例粒度很難適合業(yè)務(wù)實(shí)際需要。

（3）缺乏對(duì)實(shí)際工程量的宏觀把握。有的軟件規(guī)模相對(duì)較大，有的較小。在軟件建模時(shí)，需要對(duì)軟件實(shí)際規(guī)模進(jìn)行宏觀把控，提高劃分準(zhǔn)確度與目的性。

2 用例粒度劃分范式設(shè)計(jì)原理

根據(jù)以上分析，本文結(jié)合用例實(shí)質(zhì)與具體應(yīng)用場(chǎng)景，提出用例粒度劃分的3種范式。

第一范式：主要以建模過程中用例粒度劃分的實(shí)質(zhì)為基礎(chǔ)。如果要使劃分的用例正確，首先需要一個(gè)清晰的業(yè)務(wù)邊界[6]，邊界大小直接決定建模者對(duì)業(yè)務(wù)的抽象層次。所以第一范式有效約束了劃分用例的源頭，以免用例粒度劃分在開始階段出現(xiàn)錯(cuò)誤。

第二范式：主要為在具體業(yè)務(wù)場(chǎng)景下，關(guān)于建模階段的分析。在業(yè)務(wù)建模階段，建模人員應(yīng)該關(guān)注具體業(yè)務(wù)，建立一個(gè)業(yè)務(wù)用例模型，解決實(shí)際業(yè)務(wù)問題。而在系統(tǒng)建模階段，用例的確定通常從業(yè)務(wù)用例模型中推導(dǎo)而來，這樣才能保證每一個(gè)系統(tǒng)用例均來自于實(shí)際業(yè)務(wù)。

第三范式：解決實(shí)際工程量的問題。有的工程量很大，可能需分解才能完成，這樣在實(shí)際用例選擇上也需依據(jù)實(shí)際情況而定。

3 3種范式具體實(shí)現(xiàn)過程

3.1 第一范式

在該范式（1NF）中，根據(jù)用例粒度劃分的本質(zhì)，提供劃分方法。

（1）確立邊界。邊界可以幫助建模者弄清楚現(xiàn)階段處于哪個(gè)抽象層次，如果沒有邊界或者邊界混亂，僅憑建模人員主觀判斷，往往導(dǎo)致混亂，無法準(zhǔn)確獲取實(shí)際需求，劃分的用例粒度合理性也難以得到保證。

（2）確立涉眾期望。在確定好一個(gè)邊界后（假設(shè)這個(gè)邊界是正確的），首先需找到邊界內(nèi)的涉眾（Stakeholder，與系統(tǒng)所有相關(guān)的對(duì)象，指在此邊界內(nèi)部的對(duì)象，有可能非人），然后，整理涉眾對(duì)系統(tǒng)的價(jià)值訴求，即涉眾期望。

3.2 第二范式

在第二范式（2NF）中，一方面，可以很好地解決不同建模階段用例粒度劃分出現(xiàn)的錯(cuò)誤;另一方面，可以對(duì)第一范式的用例進(jìn)行優(yōu)化。

第二范式（2NF）設(shè)計(jì)如下：

（1）分清建模階段，根據(jù)所處階段劃分用例粒度。

（2）在需求分析階段，使用UML建模時(shí)，主要分為業(yè)務(wù)建模、概念建模與系統(tǒng)建模。概念建模是業(yè)務(wù)建模與系統(tǒng)建模之間的過渡階段，本文主要探討業(yè)務(wù)建模與系統(tǒng)建模的用例粒度把握問題。在業(yè)務(wù)建模階段，用例需能夠描述一個(gè)完整的業(yè)務(wù)流程，以便確定需求范圍。

（3）在系統(tǒng)建模階段，該用例需能描述與計(jì)算機(jī)的一次交互。

因?yàn)橛美且粋€(gè)獨(dú)立的個(gè)體，用例劃分后需保證用例之間不存在高度耦合、內(nèi)容重復(fù)等問題。合理的用例粒度劃分格式如圖2所示，不合理的用例劃分如圖3所示。

第二范式過程如圖4所示。

第二范式算法步驟如下：

輸入：確定建模階段

輸出：合理的用例粒度

建模所處的階段 Stage

If ?Stage=業(yè)務(wù)建模階段

While 與一個(gè)業(yè)務(wù)流程無關(guān) do

選擇一個(gè)能說明一個(gè)業(yè)務(wù)流程的用例

Else

While 與計(jì)算機(jī)的交互無關(guān) do

選擇一個(gè)可以與計(jì)算機(jī)相互的用例

End

3.3 第三范式

第一范式與第二范式是在理想情況下分析、總結(jié)出來的，并沒有考慮實(shí)際工程規(guī)模的問題。第三范式（3NF）首先考慮工程量問題，然后劃分工程參與人數(shù)、時(shí)限等，即工作包問題，并根據(jù)工作包確定工程規(guī)模。最后，按照工程規(guī)模劃分用例粒度。

在工程量非常大時(shí)，一般要選擇大的用例。相反，如果選擇小的用例，則對(duì)于大的項(xiàng)目可能產(chǎn)生幾百個(gè)用例，與第一范式?jīng)_突，并且每個(gè)員工實(shí)際工程量也非常大，導(dǎo)致數(shù)量過大、過于細(xì)碎而無法控制。如果從宏觀上進(jìn)行把握，采用較大的用例粒度，將有助于控制需求范圍，減少需求遺漏。在工程量較小時(shí)，一般選用較小的用例，如果此時(shí)選擇較大的用例，則會(huì)使采集到的需求過于模糊而容易忽略細(xì)節(jié)，過程如圖5所示。

模式系統(tǒng)三的算法步驟如下：

輸入：確定工程的規(guī)模

輸出：合理的用例粒度

準(zhǔn)確判斷工程規(guī)模Project scale

If Project scale非常大

按照模式系統(tǒng)一、二的要求選取用例粒度

Else

按照模式系統(tǒng)一、二的標(biāo)準(zhǔn)來選取用例粒度

End

4 案例分析

4.1 案例選擇

該案例是一個(gè)網(wǎng)上購(gòu)物系統(tǒng)，主要涉眾買家、賣家及系統(tǒng)管理人員。在建模過程中，首先按照傳統(tǒng)方式建模;然后，基于業(yè)務(wù)場(chǎng)景采用3種范式進(jìn)行建模。通過將兩種用例劃分方法對(duì)比，可以發(fā)現(xiàn)在第二種情況下用例劃分更加合理，可為后續(xù)軟件架構(gòu)建設(shè)提供根本保障。

4.2 過程分析

4.2.1 傳統(tǒng)建模

按照傳統(tǒng)建模方式，建模人員首先整理涉眾期望，進(jìn)行分析和處理;然后整理出對(duì)應(yīng)用例，畫出具體用例圖。根據(jù)該方式畫出的用例如圖6所示。

從圖6可以看出，用例個(gè)數(shù)已達(dá)到16個(gè)，并且用例大小不一，沒有具體業(yè)務(wù)場(chǎng)景作為支撐。有的甚至是一個(gè)步驟，使架構(gòu)上兩個(gè)模塊具有非常緊密的聯(lián)系，有強(qiáng)依賴關(guān)系的邏輯被分配到架構(gòu)上要求獨(dú)立的模塊。

4.2.2 采用3種范式的建模

以業(yè)務(wù)場(chǎng)景為基礎(chǔ)，結(jié)合3種范式，展開對(duì)用例粒度的劃分。

首先結(jié)合第3范式判斷工程規(guī)模，可以看出其項(xiàng)目相對(duì)較小，用例選擇方法應(yīng)相對(duì)詳細(xì)，符合整體劃分原則。

根據(jù)第一范式，確定業(yè)務(wù)邊界。經(jīng)過分析，只有賣家與買家對(duì)系統(tǒng)有非常明確的期望，而系統(tǒng)管理員是被動(dòng)接收買家與賣家在網(wǎng)上的業(yè)務(wù)。所以根據(jù)具體業(yè)務(wù)場(chǎng)景，結(jié)合實(shí)際情況，業(yè)務(wù)邊界結(jié)構(gòu)圖7所示。

買家主要目的與期望是購(gòu)買商品，而賣家是賣商品。系統(tǒng)管理員通過維護(hù)網(wǎng)站從而為用戶服務(wù)。選擇物品、錄入商品信息等皆為買賣商品的一個(gè)步驟，所以基于該業(yè)務(wù)場(chǎng)景及邊界，用例粒度劃分如圖8所示。

然后根據(jù)第二范式，明確具體的建模階段，對(duì)以上業(yè)務(wù)用例粒度再進(jìn)行劃分。在系統(tǒng)階段，首先需保證分析來源是業(yè)務(wù)用例，然后保證系統(tǒng)用例適合在計(jì)算系統(tǒng)中執(zhí)行，最后保證劃分的用例可追溯到具體業(yè)務(wù)場(chǎng)景。圖9是結(jié)合買家購(gòu)買商品的系統(tǒng)用例劃分。

4.2.3 對(duì)比分析

傳統(tǒng)劃分方法缺乏相應(yīng)業(yè)務(wù)場(chǎng)景，粒度大小不一，有的甚至把步驟作為用例對(duì)待，難以調(diào)控、修改，很容易混淆建模階段，無法為軟件架構(gòu)設(shè)計(jì)提供合適的用例，也沒有為認(rèn)識(shí)業(yè)務(wù)系統(tǒng)提供更高的抽象層次，用例復(fù)雜度相對(duì)較高。

與傳統(tǒng)劃分方法相比，采用3種范式方法可以根據(jù)具體業(yè)務(wù)場(chǎng)景，以業(yè)務(wù)主角目標(biāo)為依據(jù)進(jìn)行劃分用例，嚴(yán)格避免將步驟當(dāng)作用例，還可以根據(jù)具體業(yè)務(wù)邊界進(jìn)行用例調(diào)控及修改;結(jié)合建模階段劃分用例，使劃分的用例為以后設(shè)計(jì)開發(fā)提供很好的基礎(chǔ);同時(shí)劃分的用例簡(jiǎn)單明了、層層遞進(jìn)，向下可推導(dǎo)需求，向上可追溯業(yè)務(wù)場(chǎng)景，也為架構(gòu)實(shí)現(xiàn)提供依據(jù)。

5 結(jié)語

針對(duì)建模階段用例粒度劃分不準(zhǔn)確的問題，本文從實(shí)際業(yè)務(wù)場(chǎng)景出發(fā)，在確定的業(yè)務(wù)場(chǎng)景下根據(jù)用例本質(zhì)、建模階段及實(shí)際工程規(guī)模，提煉出用例粒度劃分的3種范式。通過實(shí)際案例驗(yàn)證發(fā)現(xiàn)，3種范式為用例粒度劃分提供了方向、方法與規(guī)范，避免了用例粒度劃分不準(zhǔn)確的問題。同時(shí)通過3種范式劃分出來的用例，向上可以追溯場(chǎng)景、為軟件架構(gòu)設(shè)計(jì)提供方向，向下可以映射需求，提升需求把控的靈活性。

參考文獻(xiàn)：

[1] 譚云杰. 大象-Thinking in UML[M]. 北京：中國(guó)水利水電出版社，2011.

[2] WIEGERS K E. Software requirements [M]. 劉偉琴，劉洪濤，譯. 北京：清華大學(xué)出版社，2004.

[3] SOUZA V，MYLOPOULOS J. From awareness requirements to adaptive systems： a control-theoretic approach[C]. Proceedings of the 2nd IntlWorkshop on Requirements@Run.Time，2011：1-7.

[4] GOMAA H. Software modeling & design UML， use cases， pattern， &software architecture[M]. 北京：機(jī)械工業(yè)出版社，2016.

[5] 栗元邦，彭蓉，季晶晶，等. 經(jīng)驗(yàn)研究中情景感知需求獲取與建模系統(tǒng)文獻(xiàn)綜述[J]. 軟件學(xué)報(bào)，2018，29（2）：320-329.

[6] 楊芙清. 軟件工程技術(shù)發(fā)展思索[J]. 軟件學(xué)報(bào)，2005，16（1）：1-7.

[7] 鄒盛榮. UML面向?qū)ο笮枨蠓治雠c建模教程[M]. 北京：科學(xué)出版社，2016.

[8] 楊長(zhǎng)春. 實(shí)戰(zhàn)需求分析[M]. 北京：清華大學(xué)出版社，2016.

[9] 張家重，徐家福. 需求工程研究新進(jìn)展[J]. 計(jì)算機(jī)研究與發(fā)展，1998（9）：1-5.

[10] 陶傳奇，李必信，Jerry GAO，等. 基于模型的構(gòu)件軟件修改影響分析[J]. 軟件學(xué)報(bào)，2013，35（1）：942-960.

[11] 張莉，蒲夢(mèng)媛，劉奕君，等. 對(duì)軟件工程中經(jīng)驗(yàn)研究的調(diào)查[J]. 軟件學(xué)報(bào)， 2018，29（5）：1422-1450.

[12] 趙瑋. 面向?qū)ο筌浖こ讨熊浖枨蠓治鯷J]. 山西師范大學(xué)學(xué)報(bào)：自然科學(xué)版，2016，20（2）：26-28.

[13] 王聰，王智學(xué)，徐友云. 基于UML的面向C4ISR能力需求分析的對(duì)象建模語言[J]. 2015，42（2）：150-156.

[14] 董威，舒紹嫻，徐小平. 軟件需求工程課程建設(shè)思考與實(shí)踐[J]. 計(jì)算機(jī)工程與科學(xué)，2014，36（A2）：34-27.

[15] 王瑞雪，張 濤. UML模型驅(qū)動(dòng)的劃分測(cè)試用例生成方法研究[J]. 計(jì)算機(jī)應(yīng)用研究，2012，29（9）：3334-3337.

[16] 潘加宇. 用例有粒度么[J]. 程序員，2008（3）：72-74.

[17] 錢雪忠，宋建生. 基于UML圖和不同粒度切片的回歸測(cè)試研究[J]. 計(jì)算機(jī)工程與科學(xué)，2012，34（11）：124-129.

[18] 李玉琴 趙文耘. 從領(lǐng)域需求到產(chǎn)品線體系結(jié)構(gòu)的映射——一種面向特征的方法[J]. 計(jì)算機(jī)研究與發(fā)展，2007，44（7）：1236-1242.

[19] 萬江平，安詩(shī)芳，黃德毅. 軟件工程知識(shí)體系指南綜述[J]. 計(jì)算機(jī)應(yīng)用研究，2016，23（10）：1-3.

[20] 王繼成，高珍. 軟件需求分析的研究[J]. 計(jì)算機(jī)工程與設(shè)計(jì)，2002，23（8）：18-21.

（責(zé)任編輯：江 艷）