用例中的事件流 (Flow of Events) 是什么？

用例描述了多个Actor与系统之间的交互，以便为发起 Actor 提供可观察的价值结果。

系统的功能由不同的用例定义，每个用例代表特定参与者的特定目标（获得可观察的价值结果）。

在下图所示的自动柜员机中，银行客户可以从账户中提取现金、在账户之间转移资金或将资金存入账户。这些对应于参与者在使用系统时的特定目标。

图 ：ATM 用例示例。

 每个用例都与参与者之一的目标相关联。用例的集合构成了使用系统的所有可能方式。您应该能够简单地通过观察用例的名称来确定用例的目标。

用例以参与者与系统之间的对话形式描述参与者与系统之间的交互，其结构如下：

这种形式的每个对话都称为“事件流”。

因为有许多事件流可能实现目标（例如，流可能会根据参与者的特定输入而有所不同），并且存在无法实现目标的情况（例如，当前需要的网络连接不可用），每个用例将包含多个流，包括一个“基本事件流”和几个“替代流” (Alternative Flow)。

事件的基本流程为理想情况指定参与者和系统之间的交互，其中一切都按计划进行，参与者的目标（价值的可观察结果）得到满足。基本流程代表了系统为此用例提供的主要能力。

顾名思义，替代流程指定与同一目标相关的替代交互。

与用例密切相关的是场景的概念。场景是特定的事件流 (Flow of Events)，用于系统的一组特定输入、系统状态和系统环境状态。场景与测试用例密切相关。

事件流应该足够清楚地描述参与者和系统之间的交互，以使局外人易于理解。事件流应该代表系统做什么，而不是系统是如何设计来执行所需行为的。

对于事件流的内容，请遵循以下准则：

事件流的两个主要部分是事件的基本流和事件的替代流程。事件的基本流程应涵盖执行用例时“通常”发生的情况。可选的事件流包括与正常行为相关的可选或异常特征的行为，以及正常行为的变化。你可以把可选的事件流看成是对基本事件流的绕道，其中一些会返回到基本事件流，而另一些会结束用例的执行。

作为起点，使用用例主要场景的分步描述。然后，逐渐向这个场景添加细节，描述用例做什么，而不是如何解决系统内部的问题。

事件流描述探索：

一个用例由许多场景组成，每个场景代表用例的特定实例，这些实例对应于来自参与者的特定输入或环境中的特定条件。每个场景都描述了系统提供行为的替代方式，或者它可以描述失败或异常情况。

在详细说明主要场景时，通过询问以下问题来确定替代流程：

最好也迭代地开发这些场景。从识别它们开始。检查每个可能的场景以确定它是否相关，它是否真的可以发生，以及它是否与其他场景不同。消除多余或不必要的场景，然后开始阐述更重要的场景。

下图中的直箭头表示事件的基本流程，曲线表示相对于法线的替代路径。一些替代路径返回到事件的基本流程，而其他路径则结束用例。

用例事件流的典型结构

为了阐明事件流在结构中的适合位置，您需要为每个绕行到基本事件流的绕行描述以下内容：

如果事件的替代流程非常简单，那么在事件的基本流程部分（使用一些非正式的“if-then-else”结构）来描述它可能很诱人。应该避免这种情况。太多的选择会使正常行为难以看到。此外，在基本事件流部分中包含替代路径将使文本更像伪代码并且更难阅读。

基本流和替代流都可以进一步结构化为子流。在这样做时，您的主要目标应该是文本的可读性。一个指导原则是，子流应该是用例中具有明确目的的行为片段，并且在您执行所描述的所有操作或不执行任何操作的意义上是“原子的”。

在用例的特殊需求中，您描述了事件流未涵盖的所有用例需求。这些通常是会影响设计模型的非功能性需求。

前提条件是在可以启动用例之前需要的系统及其环境的状态。后置条件是用例结束后系统可以处于的状态。使用前置条件和后置条件的概念来阐明事件流如何开始和结束会很有帮助。但是，只有在用例描述的受众同意它有帮助时才使用它们。

显示了一个示例。

前置条件和产生的后置条件的说明