扩展所有用例

Question

我有一个关于uml的问题并扩展用例的表示法。我如何扩展所有用例。例如，如果我创建了一个连接用例，它几乎延伸了所有用例，但我不想在用例图上用符号连接所有用例非常可怕。我能怎么做？

Answer 1

首先：用例的重要性 建模用例图（用例建模）是软件分析中的重要步骤，用例建模应由专业分析师执行：

1. 所有估算（时间，预算，资源等）均基于用例执行。
2. 在一些用例驱动方法中，所有后续步骤都基于用例。
3. 等等。

其次：了解用例建模陷阱。 在用例建模中，我们需要考虑一些与您的问题相关的陷阱：

1. （陷阱＃1：用户不理解的用例。）（参见reference 1）

用例是表示用户需求的一种方式，用户需求描述了用户需要对产品执行的操作。用例应该关注用户在系统帮助下需要完成的任务，因此它们应该与用户的业务流程相关。您的用户应该能够阅读和查看用例以查找可能的问题，例如缺少备用流或错误处理的异常。如果用户无法与用例相关，则会出现问题。也许他们从技术而非商业角度写得太多了。

2. （陷阱＃4：描述特定的用户界面元素和动作）（参见reference 1）

编写“必要”用例，在抽象级别描述用户与系统之间的交互，而不包含用户界面细节。用例描述不应包括屏幕设计，尽管简单的用户界面原型可以有助于用例探索。

3. （2.每个用例都没有明确的业务目标）（参见reference 2）
4. （6.详细说明用例）（参见reference 2）

第三：用例建模是方法论的需求范畴。

我们不应该在用例中加入常用的实现方法。实施中的常用方法由方法的后续步骤中的其他图处理。 （也许在设计模型中）因此，如果我们将所有常用方法放在用例模型中，则用例数量会增加很多。 （我们在第一部分中提到的估计出错了）

Answer 2

你不能 - 而且这是无稽之谈。用例显示了actor的附加值。用例的扩展非常罕见。在大多数情况下，人们尝试应用功能分解，并将在多个用例中重复出现的操作步骤误认为是“部分”用例。他们不是！如果你试图做你所描述的，你就走错了路。您应该考虑使用案例合成的原因和位置。

我强烈建议您阅读Bittner / Spence以正确了解用例的全部内容。

Answer 3

您可以使用use继承。

像这样的东西，用例B和C被扩展，因为这是继承的。

但正如@Kilian所说，你解释为什么需要这样的模型会很有趣。