需求用例分析之五：业务用例之Rational系

作者：张克强    作者微博：张克强-敏捷307

RUP中对于业务用例的说明

  业务用例的定义："业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供应商。"

    业务用例实例是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。 业务用例定义了一组业务用例实例。业务用例具有名称。

 

业务用例是定义一组业务用例实例，其中每个实例都是业务执行的一个操作序列，对于特定的业务主角来说，操作序列所产生的结果是可见值。

 

对于业务用例的检查点

§ 即使对于业务工程团队以外的人员来说，它的名称和简要说明是否清楚并且易于理解？

§ 从局外人（主角）的角度，每个业务用例是否完整？

§ 每个业务用例是否涉及至少一个主角？

§ 每个支撑用例是否涉及至少一个主角？如果不是，它必须通过内部事件启动，而且不必与主角相互作用以执行它的活动。

§ 用例工作流程是否清楚而且可以理解？

§ 为使项目团队以外的人员理解，措词是否足够口语化？

§ 它是否说明工作流程，而且不仅仅说明用例的目的？

§ 它是否从外部观点来说明工作流程？

§ 用例是否只执行业务内部的活动？

§ 是否属于用例的所有可能的活动都得到说明？

§ 是否只提到与用例相互作用的主角？

§ 是否只说明属于用例的活动？

§ 它是否只提到与其相关的用例？

§ 它是否明确指出何时不需要固定活动顺序？

§ 工作流程是否构造合理？

§ 是否清楚说明工作流程的起始和结束？

§ 是否清楚说明每个扩展关系以便确定插入用例的方式和时间？

对于抽象业务用例，您可以补充提问：

§ 作为其自身的抽象业务用例，该业务用例是否足够真实可靠？

§ 它是否包含逻辑相关的活动？

§ 是否有理由使业务用例存在？

业务用例与业务用例实现 

在受用例驱动的业务建模项目中，您将制作业务的两个视图。

业务用例本身展示了业务的外部视图，它确定了业务为了向主角交付期望结果，关键要执行什么。同时还确定了执行业务用例时，业务与主角之间需要进行哪些交互。必须在确定并同意每个业务用例的工作时制作该视图。这一系列业务用例描述了业务的概貌，对雇员了解执行业务的哪些不同部分以及所期望的结果十分有用。

另一方面，业务用例实现给出了业务用例的内部视图，它确定了如何组织和执行工作来获得期望的结果。实现中包含了业务角色和业务实体，它们涉及业务用例的执行，以及进行该工作所需的业务角色和业务实体之间的关系。必须制作该视图，以便确定并同意为获得期望的结果，如何在每个业务用例中组织工作。

两种业务用例视图面向的主要对象都是业务中的人员 - 外部视图供业务用例外的人员使用，而内部视图则供业务用例内的人员使用。

业务用例的范围 

有时，我们很难确定一项服务是一个业务用例还是多个业务用例。在机场登记流程中应用业务用例的定义。一个旅客将机票和行李交给登记处服务人员，他为 旅客找到一个座位，然后打印登机牌并开始处理行李。如果旅客携带的是普通行李，登记处服务人员将打印行李标签和旅客行李领取牌，在行李上贴好行李标签，最 后将行李领取牌和登机牌一起交给旅客，从而完成该业务用例。如果行李形状或所装东西比较特殊，不能按普通行李运输，则旅客必须将行李送往特殊行李台。如果 行李过重，旅客必须去机场票务处交纳费用，因为登记处服务人员不负责收取费用。

您是否要为登记处、特殊行李台和票务处各设一个业务用例呢？或者您只需要一个业务用例？的确，该处理过程涉及三种不同的操作。但问题是，是否每个操 作对携带特殊行李的旅客都是有意义的？当然不是，只有整个过程（从旅客到达登记处直到他补交完行李超重费）对旅客来说才是有意义的。所以，涉及三个不同柜 台的整个过程才是一次完整的使用，即一个业务用例。

除了这个标准之外，另一个实用的方法就是将密切相关服务的说明放在一起，这样您可以同时对它们进行复审、修改和测试，为它们编写手册，并将它们作为一个单元来管理。

值得注意的是两个独立的业务用例可能有相似的开始。

好的业务用例的特征 

§ 其名称和简要说明清晰易懂，甚至对业务建模团队之外的人来说也是如此。

§ 从外部（即主角的）角度看，每个业务用例都是完整的。例如，保险公司的“索赔处理”业务用例以一个客户提交索赔请求开始。如果不包含保险公司向客户发出有关索赔请求处理决定的通知或（在同意赔偿的情况下）保险赔偿的支付，则“索赔处理”业务用例是不完整的。

§ 每个业务用例一般至少涉及一个主角。业务用例由主角启动，通过与主角进行交互来完成活动并交付结果。

§ 支持用例可能不与主角进行交互，不过这种情况不太常见。如果业务用例由某个内部事件启动，并且不必和主角进行交互即可完成活动，则可能出现上述情况。

好的抽象业务用例的特征 

§ 具有实质性。请记住，具体业务用例与其抽象业务用例必须易于理解。因此，一个抽象业务用例不应该太小。如果某个抽象业务用例不具有实质性，您应该将其删去，而其活动应在受影响的具体业务用例中进行说明。

§ 它包含逻辑上相关的活动。

§ 它为某个特定原因而存在。一个抽象业务用例应该包含以下三类活动中的任意一类：多个业务用例中共用的活动；可选的活动；或那些非常重要、要在模型中强调的活动。

§ 

业务用例的属性字段

RUP使用了“特征名”来指代属性字段，见下表。

特征名	简要说明		UML 表示
名称	业务用例的名称。		模型元素上的“名称”的属性。
简要说明	业务用例的角色和目的的简要说明。		标注值，“短文本”类型。
目标	业务用例的可评测目标的规约。		标注值，“格式文本”类型。
性能目标	与业务用例相关的度量规约和使用这些度量的目标的定义。		标注值，“格式文本”类型。
工作流程	业务用例所代表的工作流程的文本说明。该流程应描述业务为将值交付给业务主角所做的事件，而不是业务解决问题的方式。所有业务人员都应能理解该说明。		标注值，“格式文本”类型。
类别	业务用例的类别是“核心”、“支撑”或“管理”。		标注值，“短文本”类型。  另外，您可以选择使用带有特殊图标的构造型来区分用例的类别。
风险	执行和/或实施业务用例的风险的规约。		标注值，“格式文本”类型。
可能性	业务用例的估计改进可能性的说明。		标注值，“格式文本”类型。
流程拥有者		对业务流程拥有者的定义是管理变更和计划变更的人。		标注值，“格式文本”类型。
特殊需求		如前所述，工作流程未涵盖的业务用例特征。		标注值，“短文本”类型。
扩展点		一组在业务用例的事件流程内的位置，在这些位置中使用扩展关系可插入其他行为。		标注值，“短文本”类型。
关系		用例参与的关系，如通信关联关系、包含关系和扩展关系。		由附带包通过聚合关系“owns”拥有。
活动图		这些图显示工作流程的结构。		通过可追踪到用例协作上的“types”和“relationships”的聚合关系拥有参与者。
用例图		这些图显示涉及用例的关系。		通过可追踪到用例协作上的“types”和“relationships”的聚合关系拥有参与者。
工作流程图解		手绘的草图或根据示意板制作会议绘制的图。		标注值，未解释的类型。

 

来自于Rational后续的关于业务用例的文章

在《使用UML进行有效的业务建模：描述业务用例和实现》中给出了详尽的例子，依次用到了如下图：

1. 业务用例图

2. 业务用例实现的序列图

3. 业务参与者和业务执行者参与业务的协作图

a) 本段落花费了大段文字和图表说明如何命名消息

4. 源自业务用例实现的用例图

5. 状态图

仔细分析这个文章，可以发现全文充分运用了UML工具和各类UML图，包括协助图，序列图等等，对接下去识别类，得到类图很有帮助。此文对于业务用例与系统用例的比例给出了如下提示：

有多少个业务用例？

总的来说，业务用例的数量应该比系统用例的数量要少。业务用例的实现包括了业务参与者和业务执行者的参与，者两者都将潜在的需要与系统进行交互，并且因此拥有他们自己的用例集合。通常情况下，业务用例对系统用例的比率应该在 1:5 到 1:10 之间。在我们的例子中，”准备 Tender“ 业务用例被用五个系统用例来表示，如图 12 。业务用例的价值在于它将用例放到了上下文关系中 － 显示一个业务用例组如何能够被实现以交付业务价值。

如果业务用例和系统用例的数量是可比的（比如， 1:1 到 1:3 的比率），我将提出对业务建模的要求。如果业务用例和系统用例的粒度是相似的，那么其中的一个类型就是多余的。

上述文字前中后竟然是矛盾的。前半段提到“通常情况下，业务用例对系统用例的比率应该在 1:5 到 1:10 之间”，后半段却讲“如果业务用例和系统用例的数量是可比的（比如， 1:1 到 1:3 的比率），我将提出对业务建模的要求。”，最后讲“如果业务用例和系统用例的粒度是相似的，那么其中的一个类型就是多余的。” 这是明显的逻辑错乱。 当中如果修改为“如果业务用例和系统用例的数量是可比的（约1:5 到 1:10 的比率），我将提出对业务建模的要求。”才合乎其全文逻辑。

就此文的例子而言，直接识别5个系统用例并不困难，可以讲是比较容易，留意下原文的表2即可证实。

而关于当前流行的“业务价值”判断，在敏捷开发实践，用户故事的颗粒度一般而言要比用例小，而在用户故事上开展的业务价值判断、优先级调整已经得到广大软件界的公认，其有效而且高效。那么回到业务用例和系统用例，何必非要在业务用例这个层面来判断业务价值，直接在系统用例上判断是完全可行的。而在当前短迭代增量开发的情况下，对于整个业务用例的优先级判断无法指导具体迭代的范围选择，因为业务用例的体量往往大于一个迭代能够完成的体量。甚至于系统用例都很可能超过一个迭代能完成的体量，所以最新的Use-Case 2.0引入了Use-Case slice的概念来切分用例，以便短迭代处理。

在《使用 UML 进行业务建模：理解业务用例与系统用例的相似和不同之处》中

业务用例与系统用例的相似之处：两个模型都有用例说明。如果您对业务用例模型以及系统用例模型的 RUP 模版进行检查，您会发现它们的格式十分相似。两者都包含先决条件、后置条件、扩展点 以及特殊需求。业务用例说明有基本的工作流和可选择的工作流，从而取代了基本的事件流和可选流。

 文中提到了UML for the IT Business Analyst 中对业务用例的定义：

"业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。"

这个定义表明了通过实现业务目标创造价值的观点。它通过把一个业务过程描述成一个可能包含手工和自动化过程的具体工作流来详述 RUP 的定义。这个定义还指出，工作流可能发生在一个长期时间段中。所有的这些都十分的重要。

那么系统用例又是怎样的呢？系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系，而不是业务过程。

UML 业务模型包括两个模型：用例视图（Use-Case View）中的业务用例模型和逻辑视图（Logical View）中的业务分析模型。业务用例模型中的主图是业务用例图。您还可以随意加入表示单个业务用例的 UML 活动图，来图形化地显示工作流过程。

业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如何相关联，以及它们需要如何协作，来执行业务用例的抽象。业务分析模型中有三种类型的 UML 图，如图 3 所示：类（Class）、时序（Sequence）和通信（Communication）图。

关于使用 RSA 和 UML 2.0 创建业务用例图的提示：

§ 在 UML 1.x 中，您可以将参与者原型化为业务角色。在 UML 2.0 中，您必须创建一个类，然后将其原型化为业务角色。在 UML 2.0 中，您可以将参与者原型化为业务参与者，但您不能将参与者原型化为业务角色。

§ 在 UML 2.0 中，业务用例和业务角色之间的关联是可导航的。业务参与者和业务用例之间的关联是不可导航的。

§ 作为最佳实践，我推荐断开业务用例和业务角色之间的导航，从而保持业务角色与业务参与者的一致。业务角色及其用例关联应该按照业务参与者与业务用例通信的同样方式来绘制。

§ 您必须在您的工程的 Properties 标签页中选择 Profiles 选项卡，然后单击 Add Profile 按钮，来向您的工程中添加业务建模和健壮性分析原型。在 IBM Rational Rose 中，这是自动包含的。在 UML 2.0 中，概要文件用于包装原型和标记值 UML 扩展。UML 2.0 规范要求您向 UML 建模工程中添加概要文件来使用业务建模原型。

图 7 显示了业务模型中所找到的东西和系统用例模型中的东西之间的清晰映射。在此特殊的实例中，可以看出，系统能够将业务角色的职责自动化。它还显示出关键的业务角色是自动化的候选者。

记住，业务模型包含业务用例模型和业务分析模型。业务分析模型是业务用例模型的实现，并且拥有紧密的集成化和可追溯性。系统用例模型可以追溯到业务分析模型。业务分析模型可以追溯到业务用例模型。

使用该方法，您可以构建从业务分析模型演化来的系统用例模型。这向您的整个 UML 模型提供了一致性和可追溯性。

对于Rational系业务用例的小结

如果只通过以上文字，我估计读者是难以真正理解业务用例，但是可以得出如下2点：

1，围绕着业务用例的使用起源于RUP，后续虽然有演化，仍然有明显的RUP痕迹，后续配套手段需要UML工具支撑，后续可以关联到了类和类图。

2，相关于业务用例的术语在RUP中有：业务用例，业务用例实例，业务用例实现，业务角色，业务实体，具体业务用例，抽象业务用例，业务流程，业务参与者和业务执行者等等。除了搞需求方法论研究的人（比如笔者），谁还能分辨其中差异和联系？对比到用户故事和用例分析，谁还愿意选择这业务用例分析？