0

阅读有关UML的书，我不明白以下内容：

                                      --------include---> Add new manufacturer
  Servoce Assistant---Add new product
                                     <--------extend----Add new product type

我只是不明白。如果还有未知的制造商，它使用包含的案例添加制造商。但如果它是未知类型，还有extend？这对我来说没有任何意义。如果只能从不同的地方调用 Add 制造商，但 Add new product type 仅存在于这种情况下，那将是有意义的。这是对的吗？谢谢！

4

4 回答 4

5

以下解释可能有助于阐明用例图上的“扩展”和“包含”关系：

包含：一个包含用例调用或调用包含的用例。包含用于显示用例如何分解为更小的步骤。包含的用例位于箭头末端。

扩展：扩展用例向扩展用例添加目标和步骤。扩展仅在特定条件下运行。扩展用例位于箭头端。

在用例图上包含和扩展关系 http://i.msdn.microsoft.com/Dd409427.UML_UCOvStructure(en-us,VS.100).png

UML 用例图：参考http://msdn.microsoft.com/en-us/library/dd409427%28VS.100%29.aspx

于 2010-02-19T02:10:56.117 回答
1

如果还有未知的制造商，它使用包含的案例添加制造商。但如果它是未知类型，还有extend？这对我来说没有任何意义。

我也不完全确定这对我来说是否有意义。

UML2 规范说包括（第 16.3.5 节）：

两个用例之间的包含关系意味着包含用例中定义的行为包含在基本用例的行为中。当两个或多个用例的行为有共同部分时，应使用包含关系。然后将此公共部分提取到单独的用例中，以包含在具有该部分公共的所有基本用例中。由于包含关系的主要用途是重用公共部分，因此基本用例中留下的内容通常本身并不完整，而是依赖于包含的部分才有意义。这反映在关系的方向上，表明基本用例取决于加法，反之则不然。

包含用例的执行类似于子程序调用。在恢复执行包含用例之前，包含用例的所有行为都在包含用例中的单个位置执行。

...

请注意，包含用例不是可选的，并且始终需要包含用例才能正确执行。

和扩展（第 16.3.3 节）：

这种关系规定了一个用例的行为可以通过另一个（通常是补充的）用例的行为来扩展。扩展发生在扩展用例中定义的一个或多个特定扩展点。但是请注意，扩展用例是独立于扩展用例定义的，并且独立于扩展用例是有意义的。另一方面，扩展用例通常定义本身不一定有意义的行为。相反，扩展用例定义了一组模块化行为增量，这些增量在特定条件下增强了扩展用例的执行。

...

如果在扩展用例执行过程中到达第一个扩展点时扩展的条件为真，那么扩展用例的所有适当的行为片段也将被执行。如果条件为假，则不会发生扩展。

用例是在 OOD 语言中找到的相当程序化的东西。包含是子例程调用。扩展是可选过程，如条件逻辑或模板方法模式，其中主要方法可能会或可能不会调用更具体的实现。

由于用例是一个分类器，因此您可以在用例之间使用与类之间相同的泛化关系来表示泛化。扩展和包含表示可选和必需的子行为。

如果只能从不同的地方调用 Add 制造商，但 Add new product type 仅存在于这种情况下，那将是有意义的。这是对的吗？谢谢！

它说，每当您添加产品时，您总是会添加新的制造商，有时您可能会添加新的产品类别。它没有说明是否从其他地方调用了任何用例，尽管通常您只会拆分包含的用例（如果它们是）。鉴于现实世界的制造商生产不同的产品，这可能是一个糟糕的例子。

于 2010-02-01T19:44:20.847 回答
0

首先，您需要在这里给人们一些背景信息。您正在使用用例图。其次，我通常远离 UML 的扩展；但我会试一试。“包含”用于模块化用例。例如，“用户登录”被大量使用，并且比在它所在的每个用例中写出步骤更容易“包含”。“扩展”正在尝试对用例使用泛化/继承，但我不'认为它不是很好，很好用。这是一个示例，“添加老虎”扩展了“添加动物”。同样，我会远离“扩展”。

于 2010-01-31T01:39:06.013 回答
0

Tomas，您是指扩展点而不是扩展类吗？

以 LWoodyiii 的 Login 为例，您将以一切正常的使用场景为起点，然后您将在场景可能出错的地方添加到用例的扩展？

那里有很多例子，只是 google 的uml 用例扩展。

于 2010-01-31T01:58:43.317 回答