问等待评审和请求的结果是否被视为提交请求的事件流的一部分？

EN

在“添加就业应用程序”用例的事件流程中，是否考虑了“等待审查的应用程序”和“公司的响应”？

这取决于抽象的级别和您在该用例中的观点。

如果用例是从一个非常高的角度编写的，那么公司的反应，任何随后的面试，直到实际的雇用，都可能是用例的一部分。

如果用例更多地是从用户与软件应用程序的交互的角度编写的，那么最好将每个用例限制在与应用程序的单个静坐/会话中通常会发生的事件流上。

“等待应用程序被审查”一步绝对不应该是用例的一部分。它不是某个人(或系统)在交互中采取的行动。它充其量是用例各步骤之间时间的指示。这样的等待时间通常是隐式的。

基本流程是否包括回复(“继续招聘过程”和“拒绝申请”)，还是在备选流程中考虑“拒绝申请”？

基本流程只显示通过用例的单一路径，通常是通往成功结果的最常见路径。

替代流显示了用户可以在用例中达到目标的其他方式。

如果用户无法实现他们的目标，那么在某个时候，他们会偏离到一个异常流。

假设用户的目标是雇用他们，那么拒绝他们的应用程序就意味着他们会在那时进入一个异常流(这可能很快就会终止用例)。

用例Add employment application似乎符合一个相当精确和基本的目标:一旦它被添加，它就完成了。这件事背后没有比这更好的东西了。

如果是Apply for employment，那就意味着有一个更大的图景:申请过程比添加申请更广泛:它可以包括回复、面试邀请等。

最终，在描述这个案子的叙述中，你会决定其中的内容。但它应该与用例名称一致。

其他用例元素也起作用：

• 如果用例有两个参与者，候选人作为主要参与者，招聘人员作为次要参与者，您会强烈建议某种反馈，因为次要参与者参与了实现主要参与者的目标。
• 如果只有一个演员，我会想象如果有反馈的话，那就是某种送货收据。

等待不是一种行动。等待是一个非即时的答复的结果。我强烈建议不要提这件事。如果你想要的话：

• 请注意，“等待”将强烈建议主动等待，即用户在系统前面等待，直到应答出现为止。
• 其他术语可能更好地反映用户一直在做的事情，例如监视应用程序、检查响应等.

因此，由于用例是一种交流工具，因此花一些时间选择准确、准确的术语来命名事物和减少误解是很重要的。