基于业务场景的用例粒度划分范式

2019-07-08赵玉明舒红平魏培阳

软件导刊 2019年6期

关键词：范式

赵玉明舒红平魏培阳

摘要：用例驱动整个统一软件开发过程，但用例划分缺乏统一标准规范，从而导致用例划分不够准确。针对该问题，以业务场景为基础，对用例粒度划分展开研究，提出采用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]。建模可以分为不同的阶段，如果没有对软件建模所处的阶段有一个清晰的认识，划分出来的用例粒度很难适合业务实际需要。

（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.