扩展点 - 用例答案

【问题标题】：Point of extension - Use case扩展点 - 用例
【发布时间】：2011-08-15 18:49:59
【问题描述】：

假设我有一个用例买书，主要流程如下：

1- The user types the book code that he wants to buy
2- The system replies that there's enough stock of the requested book
3- The user confirm

很简单。

现在假设我想让用户在 2 到 3 之间也可以做另一件事。我该怎么说呢？我想这是对这个用例的扩展，但我不确定它的扩展点在哪里。

据我所知，如果我选择，比如说，在 3 中的扩展点，那么用户有机会做 3 或做所有扩展但不是 3。替代流程的相同行为。

但我想要的是不同的。我想要一些“2.5”或什么都不做……要么做，要么什么都不做；不是别的。

对于这个含糊的问题，我很抱歉。

【问题讨论】：

用例就像流程图，它们不需要在同一点结束。把它分开。

标签： analysis uml use-case

【解决方案1】：

一个选项是 Alistair Cockburn 的 Writing Effective Use Cases 中推荐的格式：

2a-  User wants to do another thing:
2a1- The user does another thing
2a2- The system responds in some way, returns to step 3

步骤 2a 发生在步骤 2 之后和步骤 3 之前。如果 UC 在步骤 2a2 结束，则只需将“返回到步骤 3”替换为“用例结束”或类似内容。

第一次。

【讨论】：

我在原始用例中将“扩展点”放在哪里？或者它是如何指定的？
你不知道——这就是重点。原始用例没有明确显示它的扩展位置。在主要流程中，您专注于主要的成功场景。扩展是通过引用在它们扩展/更改行为的主要场景中的步骤 id 来添加的。
在 Cockburn 的模型中，您将扩展直接附加到扩展用例描述中，因此没有扩展关系和扩展点。
@Gabriel: 同意没有 explicit 扩展点，尽管它们是隐含的。本质上，扩展 UC 描述中的每一步都是一个候选扩展点。同样，对于每个扩展 UC 扩展另一个情况的情况，都有一个隐式扩展关系。

【解决方案2】：

这里的问题是 UML 中的用例模型和用例描述之间的差异。扩展点是来自 UML 的一个概念，用于解耦扩展和扩展用例。如果你想坚持这一点，你必须自己定义分支和返回的位置，因为 UML 没有提到用例描述。我个人以及 sfinnie 都是 Alistair Cockburns 的用例方法的粉丝，但是它与 UML 标准不相符。还有另一种方法，由 Bittner（用例建模书）提出，他建议将场景拆分为带有标题的子流。

【讨论】：

好点。 UML 规范给人的印象是“扩展位置”必须在原始用例中明确定义。然而，“扩展点”并未正式指定。来自 UML 2.3 上层结构规范 (p608)：“故意未指定“扩展位置”的概念”。因此，有人可能会争辩说 Cockburn 的方案符合规范的意图。具体来说，Main 场景的每个步骤都是一个候选扩展点（由步骤编号标识）。 ctd...
...ctd。 @artu85：一般来说，我会说不值得太挂断电话。选择对你有用的东西，而不是完全符合规范的东西。尽管如此，@Gabriel 的观点还是值得注意的：如果您处于非常正式的环境中（或完成家庭作业！），那么您需要检查 Cockburn 的方案是否可以接受和/或记录您围绕扩展点的方法。 hth.
@sfinnie：补充一点，Bittner 的方案没有步骤编号，它使用标题作为子流，而不是理由是扩展与这些标题（扩展点）耦合，所以场景可以是独立更改（您可以添加或删除步骤而不会破坏扩展名），但是在 Cockburn 的方案中，更改方案可能会更改步骤编号并因此破坏扩展名......但如上所述，我是 Cockburn 的粉丝，原因有很多:)跨度>
以前没有遇到过比特纳的方法。感谢您的指点，将看看。

【解决方案3】：

我认为你真正想要的是一条替代路径。备用路径引用主路径或不同备用路径中的步骤。我通常将该参考作为替代中的开始步骤。然后 End 步骤要么是对它返回的位置的引用，要么是路径停止的指示。

【讨论】：