uml - 如何表示一个复杂的用例，其中主要流程的每个步骤都可以有多个场景(替代或错误路径)？

Question

小背景

我不熟悉编写用例和表示它们的场景。我正在处理一个复杂的系统。在分析系统的第一步中，我创建了一个用例图，其中每个用例代表系统的一个不同目标或值(value)。我尽力保持用例独立。所有这些用例都需要系统的初始化和激活，所以我决定把这个公共(public)部分拿出来，使用包含关系将它链接到主要用例。我明白 include 和 extend 关系只需要在必要时使用。现在，我正在研究为每个用例定义场景，然后根据场景开发用户故事和需求。

主要问题

用例非常复杂，分析它的最简单方法似乎是将其映射到一系列步骤/事件中，其中每个事件包含多个场景，并且每个场景都使用序列图表示。我了解事件不能是使用包含关系与主要用例相关的用例；但是有事件的顺序图似乎也是错误的。

表示主流程的每个步骤都很复杂并且参与者和系统之间可能有多个交互以及可能导致序列在该步骤或可能性终止的错误场景的用例的最佳方式是什么用户取消/中止序列？我附上了“初始化”用例事件图的简化版本。正如我提到的，每个事件都可以有很多场景。例如

• “执行自检”有很多步骤，每个步骤都可能导致失败，从而终止序列并提醒用户(通过 HMI)。然后用户可以终止初始化或重试。
• “验证系统配置”包括获取引用配置版本并将其与系统配置进行比较的步骤，然后在必要时下载新的配置文件，然后更新系统配置。每个步骤都可能会失败，从而导致向用户发送某种消息并终止序列。在某些情况下，用户应该能够跳过失败的步骤并在不执行该事件的情况下继续。图中的所有其他事件也是如此；许多步骤都有异常(exception)或替代路径。

我可以将这些映射到“初始化”用例的一个序列图中吗？我试图将所有这些放在一个序列图中的尝试失败了。我尝试将所有这些交互放在带有泳道的事件图上，但事情变得如此复杂，利益相关者很难理解正在发生的事情。
也许我试图在系统级别添加太多细节。我是否应该将所有这些临时步骤和交互留给较低级别​​的设计？我应该创建用例层次结构并降低复杂性吗？我很困惑。 :(处理这种复杂程度的最佳方法是什么？你能提供一些很好的例子吗。

Answer 1

幸运的是，表示复杂用例(主要流程的每个步骤都可以有多个场景)的唯一方法非常简单:

场景的复杂性不会改变参与者目标的简单性。如果目标不够简单，您可能会关注太多细节。或者事情没有他们应该的那么清楚。

场景通常用一组序列图来表示。但如果它变得非常复杂，你最好 show the flow with an activity diagram .

顺便说一句，您不需要为了建模通用步骤而人工创建扩展或包含的用例。您可以只为公共(public)部分创建一个单独的事件图。然后，在每个用例事件图中，您将插入公共(public)事件的调用操作。这也避免了误导性地将公共(public)部分包含在一个 UC 的描述中而忘记了其他部分。

最后但同样重要的是，您还想根据用例场景开发用户故事。这是一种混合方法，需要更多思考:

• 用户故事通常在没有用例的情况下使用。复杂的要求被描述为史诗。然后将史诗成功地细化为适合迭代的用户故事；
• 可以根据利益相关者的目标和任务来构建此类用户故事。这种方法称为用户故事映射。这更接近用例，但没有描述更高级别目标的术语。
• 用例驱动开发通常在没有用户故事的情况下使用:场景和事件直接导致开发而没有中间用户故事。

幸运的是，Use-Case 2.0方法允许结合两种方式。阅读链接的白皮书:它很短，是免费的，它是由用例的发明者和用例方法论的主要作者共同编写的；它提供了一种允许敏捷开发的重新设计方法，将用例用于全局，并使用用例切片将其动态分解为可在一次迭代中开发的单元。