用例事务是一个“环形的路线”

Ivar Jacobson，用例的发明者，将用例事务描述成从用户到系统，再到用户的“环形路线”；在系统等待一个新的输入时事务完成了。 4 换句话说，在一次事务中，用户运行输入系统的一些操作。此时系统发生反应。它处理输入并将处理的结果返回给用户。当用户对结果做出反应时，一个新的事务开始了，它反过来由可以作为系统的输入。

用例事务不总是一个用例步骤

Jacobson 的话还包含了另外一层意思：用例事务并不是定义为“用例流程中的步骤”。只是对由一个“环形路线”组成的用例流程自身，这种定义才成立。尽管一些书写用例的方法将它描述成叙述用例事务的另一种方法，但毕竟它不是标准的方式。 5

用例事务不是一个“刺激源”

有些作者建议“用户运行的刺激源的存在性是定义事务的部分”。 6 尽管一次事务总是从一个刺激源开始（是用户进行了一项触发系统反应的操作），刺激源本身并不是完整的事务。假设您拥有一个以下的用例描述：

    用户选择一个 X。
    ...

    （n）用户提交。
    ...

现在还不清楚系统是否对步骤（1）和（n）中刺激源作出了反应，或者系统是否对步骤（1）或者步骤（n）分别作出。因此，两个刺激源可以组成一个或者两个事务。它并不取决于刺激源，而是取决于刺激源和回应的组合。

用例事务并不是一个数据库活动

在 Web 上进行的许多次讨论中，您可以找到定义为“一系列要么完全执行，要么一点也不执行的活动”的用例事务。 7 。该定义听起来像是数据库管理系统中的一个事务性机理，如果它没有正常运行的话该步骤可以返回。在我们的经验中，这不是在一个用例描述中将一片内容与另一片内容隔离起来的方法。它也行会激发一个想法，也是事务在一定程度上与数据库中的读写操作相关。但是，在一个环形路线中，系统根本不用查询数据库也是可能的。这个过程中数据库也行根本不会涉及到，或者数据来自系统以外。因此得出用例事务一定会与数据库中的事务联系起来的结论是不合适的。

用例事务不是一个系统步骤

用例事务中的系统可能会在一步完成。表面上，我们可能会得出用例事务只是一个系统步骤。但是，一个系统步骤并不是描述用例事务的一个较好的基础，因为它取决于对您计算的多少步骤的描述。而且，系统本身并没有多少涉及到 Actor 与系统之间的联系。换句话说，您的估算应该基于“环形的”事务，而不是系统步骤。

范例：复杂的用户界面

用例事务的“环形路线”方法，在估算用户界面复杂性方面显示出其价值。一个范例是工作入口项目，在这个项目中可以设计出一个工作设计机器。在基于用例模型（Survey）的早期估算中，工作搜索界面被认为是简单的；用户可以从一系列的下拉菜单中选择搜索项，然后进行选择。但是，在用于产生用例描述的用户界面中，，如果系统可以对已作出的选择进行回应，并更改后续下拉菜单中内容的话，那么可以预见应用的可用性会得到提高。换句话说，本来应该是一个的事务现在变成了两个。

这里是用例配置的第一个草稿：

 该段文字扩展如下：

这里您可以看到两个“环形路线”。将用例配置当作证明，查看调整初始估算后的合理性变得容易起来。

将用例事务保持在一定的层次上

如果用例事务是一个紧跟系统回应的刺激源，那么它十分能够计算成一个事务？例如，如果我从我的键盘上敲入一个“K”，那么这是一个刺激源，然后系统会通过在屏幕上显示一个能组成“K”的像素点来回应这个刺激源。所以，我们以前推荐的定义是不是太狭隘了？

不，不是这样的。它显示您理解用例事务时，应该与用例事务本身被理解保持同一个层次。现在，您可能对输入字母这种操作不感兴趣，当字母出现在屏幕上的，您会觉得这是理所当然的；您不需要在系统中构建什么东西来产生结果。但是，如果您的内容是描述键盘模型与图形化反应器，这样一个用例事务是十分合理的。