基于業務場景的用例粒度劃分范式

趙玉明 舒紅平 魏培陽

摘 要：用例驅動整個統一軟件開發過程，但用例劃分缺乏統一標準規范，從而導致用例劃分不夠準確。針對該問題，以業務場景為基礎，對用例粒度劃分展開研究，提出采用3種范式規范用例粒度劃分。從用例劃分源頭、建模階段及實際工程規模展開進行分析，3種范式為建模人員在具體業務場景下的用例劃分提出解決方案，可為建模人員節省建模時間、提升建模效率，從而完善系統架構。

關鍵詞：RUP;業務場景;軟件建模;用例劃分;范式

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 引言

在軟件工程領域，RUP既是一套軟件方法，又是一種典型的軟件開發模式。它以迭代增量式架構為中心，用例驅動的軟件開發方法為主要特征，其中用例驅動是貫穿軟件開發始終的方法。用例驅動整個軟件架構的建立，軟件架構是邏輯層次較高的系統視圖，是系統規劃與設計的高層次抽象[1]。

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

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

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

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

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

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

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

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

2 用例粒度劃分范式設計原理

根據以上分析，本文結合用例實質與具體應用場景，提出用例粒度劃分的3種范式。

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

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

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

3 3種范式具體實現過程

3.1 第一范式

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

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

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

3.2 第二范式

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

第二范式（2NF）設計如下：

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

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

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

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

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

第二范式算法步驟如下：

輸入：確定建模階段

輸出：合理的用例粒度

建模所處的階段 Stage

If ?Stage=業務建模階段

While 與一個業務流程無關 do

選擇一個能說明一個業務流程的用例

Else

While 與計算機的交互無關 do

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

End

3.3 第三范式

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

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

模式系統三的算法步驟如下：

輸入：確定工程的規模

輸出：合理的用例粒度

準確判斷工程規模Project scale

If Project scale非常大

按照模式系統一、二的要求選取用例粒度

Else

按照模式系統一、二的標準來選取用例粒度

End

4 案例分析

4.1 案例選擇

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

4.2 過程分析

4.2.1 傳統建模

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

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

4.2.2 采用3種范式的建模

以業務場景為基礎，結合3種范式，展開對用例粒度的劃分。

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

根據第一范式，確定業務邊界。經過分析，只有賣家與買家對系統有非常明確的期望，而系統管理員是被動接收買家與賣家在網上的業務。所以根據具體業務場景，結合實際情況，業務邊界結構圖7所示。

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

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

4.2.3 對比分析

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

與傳統劃分方法相比，采用3種范式方法可以根據具體業務場景，以業務主角目標為依據進行劃分用例，嚴格避免將步驟當作用例，還可以根據具體業務邊界進行用例調控及修改;結合建模階段劃分用例，使劃分的用例為以后設計開發提供很好的基礎;同時劃分的用例簡單明了、層層遞進，向下可推導需求，向上可追溯業務場景，也為架構實現提供依據。

5 結語

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

參考文獻：

[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]. 北京：機械工業出版社，2016.

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

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

[7] 鄒盛榮. UML面向對象需求分析與建模教程[M]. 北京：科學出版社，2016.

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

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

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

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

[12] 趙瑋. 面向對象軟件工程中軟件需求分析[J]. 山西師范大學學報：自然科學版，2016，20（2）：26-28.

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

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

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

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

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

[18] 李玉琴 趙文耘. 從領域需求到產品線體系結構的映射——一種面向特征的方法[J]. 計算機研究與發展，2007，44（7）：1236-1242.

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

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

（責任編輯：江 艷）