2

小背景

我不熟悉编写用例并表示它们的场景。我正在处理一个复杂的系统。在分析系统的第一步中，我创建了一个用例图，其中每个用例代表系统的不同目标或价值。我已尽力保持用例独立。所有这些用例都需要系统的初始化和激活，所以我决定取出这个通用部分，并使用包含关系将其链接到主要用例。我了解仅在必要时才需要使用包含和扩展关系。现在我正在研究为每个用例定义场景，然后根据场景开发用户故事和需求。

主要问题

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

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

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

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

在此处输入图像描述

4

2 回答 2

3

幸运的是，表示一个复杂用例的唯一方法很简单：主流程的每一步都可以有多个场景：

在此处输入图像描述

场景的复杂性不会改变演员目标的简单性。如果目标不够简单，您可能会查看太多细节。或者事情并不像他们应该的那样清楚。

场景通常用一组序列图表示。但如果它变得非常复杂，你最好用活动图来展示流程。

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

最后但同样重要的是，您还希望基于用例场景开发用户故事。这是一种需要更多思考的混合方法：

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

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

于 2022-02-02T00:05:51.143 回答
2

一个复杂的用例可以保留一个用例，但它可能需要多个图表来指定其流程。

您的活动图（尽管不是 100% 兼容 UML）很好地概述了用例的流程。将此作为主图。我会在单独的图表中分解复杂的步骤。为了表示在单独的图表中分解了一个步骤，您可以显示一个 rake 符号，如下所示：

耙

有关详细信息，请参阅 UML 2.5.1 规范，第 16.3.4.1 节。

于 2022-02-02T08:37:50.827 回答