趙玉明 舒紅平 魏培陽

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

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

DOI：10. 11907/rjdk. 182425

中圖分類號：TP302

文獻標識碼：A文章編號：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ū)動的軟件開發(fā)方法為主要特征，其中用例驅(qū)動是貫穿軟件開發(fā)始終的方法。用例驅(qū)動整個軟件架構(gòu)的建立，軟件架構(gòu)是邏輯層次較高的系統(tǒng)視圖，是系統(tǒng)規(guī)劃與設(shè)計的高層次抽象[1]。

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

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

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

1 影響用例粒度劃分的3個因素

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

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

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

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

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

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

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

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

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

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

3.1 第一范式

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

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

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

3.2 第二范式

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

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

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

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

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

因為用例是一個獨立的個體，用例劃分后需保證用例之間不存在高度耦合、內(nèi)容重復(fù)等問題。合理的用例粒度劃分格式如圖2所示，不合理的用例劃分如圖3所示。

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

第二范式算法步驟如下：

輸入：確定建模階段

輸出：合理的用例粒度

建模所處的階段 Stage

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

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

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

Else

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

選擇一個可以與計算機相互的用例

End

3.3 第三范式

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

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

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

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

輸出：合理的用例粒度

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

If Project scale非常大

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

Else

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

End

4 案例分析

4.1 案例選擇

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

4.2 過程分析

4.2.1 傳統(tǒng)建模

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

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

4.2.2 采用3種范式的建模

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

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

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

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

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

4.2.3 對比分析

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

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

5 結(jié)語

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

參考文獻：

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

[2] WIEGERS K E. Software requirements [M]. 劉偉琴，劉洪濤，譯. 北京：清華大學出版社，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]. 北京：機械工業(yè)出版社，2016.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（責任編輯：江 艷）