怎样计算事务

既然您已经看到了决定什么是以及什么不是用例事务的清晰解释，让我们检查在用例中计算事务的一些挑战。如上面所述，用例的权重是由它所包含的用例事务的数量所决定的，但是，什么时候系统对刺激源的反应会计算成不同的？

使用用例事务与流程

让我们通过检查上面介绍过的工作入口的搜索流程开始。如果用户在寻找一个“Java”类型的工作，他选择了 Java，然后系统会在数据库中搜索这种类型的所有工作。当用户寻找一个“.Net”类型的工作，它选择了 .Net。然后系统会搜索数据库来找到该类型的所有工作。这两种是不是不同的事务？当然不是。用例配置本身是抽象的或者通用的，在这个意义上您不要对不同的搜索项期待不同的流程。这只不过是安装过程中的一点不同。但是，您可以对一个使用预定义类型或者自由格式文本的搜索期待不同的流程。

另一方面，处理例外是一个灰色的区域。假设您有了带有七个区域的输入屏幕，它们中的所有都有不同的限制。您有一个日期区域，一个邮政编码，一个输入区域，以及等等。每一个检查可能会在单独的流程中得到描述，因此被计算成可能不止一个事务。您可以选择的是，提供一个通用的流程。它预假设有一个可以容易处理的例外种类的框架。在这种情况下，您应该将该流程计算成一个事务。

使用当作环形路线的用例事务，可以在用例中随处可见。因为一个用例配置至少有一个基本流程，它也至少应该有一个事务。没有事务的流程是没有意义的，因为系统在没有刺激源时什么都不会做，用户在没有弄清系统的反应之前也不会提供任何刺激源。

几乎一直都会有描述处理例外的流程（因此，“例外的流程”）。每一个例外流程都至少含有一个事务。这点也适用于一个可选择的流程；对于每一个可选择的流程都应该有至少一个流程。很可能您需要查看基本流程，以查看可选择流程中事务的刺激源；这取决于处理用例的特定指定原则。

它给了您一个任何用例配置中用例事务小数量的指示：流程中至少应该有以下数量的事务。 8

显示和计算

如果您拥有识别用例事务的能力，您是否需要对它们平等的重视？我们的策略是显示它们中的，每一个与事务（如果可以应用的话），但是有些时候并不计算它们的权重。我们的策略要比直接忽略它们更加直接。如果需要的话，调整原始的估算也十分的容易。

通过这种方式，您能够看出框架的价值。如果用例计算十个事务的话，但是它们中只有三个值得处理，另外三个遵循框架，该用例是普通的而不是复杂的。表 1 中显示了一个例子。

表 1 ：不同假设性用例计算的事务

许多系统步骤可以是一个新的用例

是不是没有办法解释一个用例业务暗含的系统步骤与只有一步系统步骤之间的差异？您的直觉告诉您构建 6 个系统步骤要比构建 1 个需要更大的努力。实际上，我们完全赞成。但是，您不应该试着通过计算系统步骤，而应该通过隔离另外系统步骤涉及到的功能性，来解决这些小问题。如果您拥有大量的功能性，那么可能它是用例本身。注意不要将任何堆积的功能发展成“用例”的状态。这将会是功能性降级。但是应用如下的规则：后续的用例必须拥有一个清晰的目标，这符合至少一个投资者的利益（并不一定与用户相似）。 9

一个范例可以是用例“产生年平均”。在这个用例的过程中，会生成一些报告，代表一个特定投资者的利益。生成每一个报告的过程中，会涉及到一些系统步骤。为每一个报告定义单独的用例，能够帮助您找到合适的投资者，而不用打扰其他的投资者。通过这种方式，我们能够提供更加保险的估算了。

批任务

如果用例使用在缺乏用户交流的情况之下（在这方面我们有较好的经验），那么您怎样将业务的概念转化成一个环形路线。坦白来说，在这里它并不适用。您需要其他的方式来估算这种用例的权重。而且，这是由专家估算来完成的。表 2 显示了它们是怎样在扩展卡中显示的。

表 2：业务与添加的批任务同时计算

 如果批任务要比一个复杂的用例还要大，那么它应该还有不止一个目标，因此该工作可以分解成更多的用例，每一个用例都能够服务于至少一个投资者的利益。这种机理能够适用于任何用例，这些用例要比实际上还要复杂许多（见于表 2）。如果您不能找到一个好的原因，去分解一个批任务，您可以转化成图 1 中提到的“补充性效果”类型。

非常复杂的用例

一些作家看到了用例点方法中的困难之处，因为在 8 个业务的复杂用例与 16 个业务之间，没有什么不同之处。在我们的经验中，由超过 12 个业务组成的用例，能够满足不止一个目标。所以，它们是问题性用例模型的标志。换句话说，如果您拥有超过 12 个业务的用例，那么考虑一个新的用例是值得的。 10

在项目的早期阶段计算用例业务

在写下所有的用例配置后，计算业务变得简单起来。另一方面，估算是在项目的早期进行预测的。在这里，您只有用例模型，以及每一个用例的简单介绍。为了展望组成用例的流程，以及涉及到的用例事务，您需要经验的帮助。如果您没有这个经验，不要犹豫去咨询拥有类似系统和背景工作经验的同事。通过创建如表 2 所示 的扩展单来开始，并填入展望的事务。这将会形成管理用例范围的基础，您能解释哪些用例需要比用户预料的那样更多的事务。