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

版权声明：作者：张克强。未经作者允许不得转载。 https://blog.csdn.net/zhangmike/article/details/28134897

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

RUP中对于业务用例的说明

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

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

 业务用例定义了一组业务用例实例。业务用例具有名称。

 

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

 

对于业务用例的检查点

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

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

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

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

§ 用例工作流程是否清楚并且能够理解？

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

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

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

§ 用例是否仅仅运行业务内部的活动？

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

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

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

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

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

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

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

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

对于抽象业务用例，您能够补充提问：

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

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

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

业务用例与业务用例实现 

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

业务用例本身展示了业务的外部视图，它确定了业务为了向主角交付期望结果。关键要运行什么。同一时候还确定了运行业务用例时，业务与主角之间须要进行哪些交互。必须在确定并允许每一个业务用例的工作时制作该视图。

这一系列业务用例描写叙述了业务的概貌，对雇员了解运行业务的哪些不同部分以及所期望的结果十分实用。

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

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

业务用例的范围 

有时，我们非常难确定一项服务是一个业务用例还是多个业务用例。在机场登记流程中应用业务用例的定义。一个旅客将机票和行李交给登记处服务人员，他为 旅客找到一个座位，然后打印登机牌并開始处理行李。

假设旅客携带的是普通行李，登记处服务人员将打印行李标签和旅客行李领取牌。在行李上贴好行李标签。最 后将行李领取牌和登机牌一起交给旅客。从而完毕该业务用例。

假设行李形状或所装东西比較特殊，不能按普通行李运输，则旅客必须将行李送往特殊行李台。

假设 行李过重，旅客必须去机场票务处交纳费用。由于登记处服务人员不负责收取费用。

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

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

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

好的业务用例的特征 

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

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

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

§ 支持用例可能不与主角进行交互。只是这样的情况不太常见。假设业务用例由某个内部事件启动。并且不必和主角进行交互就可以完毕活动，则可能出现上述情况。

好的抽象业务用例的特征 

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

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

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

§ 

业务用例的属性字段

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个系统用例并不困难，能够讲是比較easy。留意下原文的表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 中，业务用例和业务角色之间的关联是可导航的。

业务參与者和业务用例之间的关联是不可导航的。

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

§ 您必须在您的project的 Properties 标签页中选择 Profiles 选项卡，然后单击 Add Profile button，来向您的project中加入业务建模和健壮性分析原型。在 IBM Rational Rose 中，这是自己主动包括的。

在 UML 2.0 中。概要文件用于包装原型和标记值 UML 扩展。UML 2.0 规范要求您向 UML 建模project中加入概要文件来使用业务建模原型。

图 7 显示了业务模型中所找到的东西和系统用例模型中的东西之间的清楚映射。

在此特殊的实例中，能够看出，系统能够将业务角色的职责自己主动化。

它还显示出关键的业务角色是自己主动化的候选者。

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

系统用例模型能够追溯到业务分析模型。业务分析模型能够追溯到业务用例模型。

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

对于Rational系业务用例的小结

假设仅仅通过以上文字，我预计读者是难以真正理解业务用例，可是能够得出例如以下2点：

1，环绕着业务用例的使用起源于RUP，兴许尽管有演化，仍然有明显的RUP痕迹。兴许配套手段须要UML工具支撑，兴许能够关联到了类和类图。

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