如何在用例图中正确使用<< generalization >>用例？

Question

我开始学习UML，我有点困惑。我有以下的用例图：

我问这是因为我想正确绘制图表我为任何人与UML的正确知识，能够理解并不仅仅是绘制图表的方式只是我明白。

现在对于我之所以用用例泛化这是为什么;

读的书UML 2和统一过程的第5.3节之后，我觉得我想要做的是用例泛化，在第100页看例子后特意此示例显示了用例称为查找产品信息，由于在页面表示101是抽象用例。

我们读到

的FindBook用例是更具体的。它专注于更抽象的父母来处理特定类型的产品，书籍。如果父用例没有事件流或不完整的事件流，则这是一个抽象用例。抽象用例很常见，因为您可以使用它们在最高抽象级别捕获行为。因为抽象的用例事件的缺失或不完整的流程，他们永远不能被系统

执行，这就是我想在我的图来表示。我有一个抽象使用情况，接通和这个用例是永远不会，因为它是被执行。它需要孩子，或者在这种情况下，由于系统将通过IR或KNOB开启，并且永远不会打开，这就是抽象的，孩子们需要专注于它。

所以这里的事情是，我不知道的多泛化。如果这样做是正确的。还是我改变例如又与IR和又与旋钮用例，接通与IR和，接通与KNOW使用情况，使打开这些孩子们可以并添加打开OFF与IR和关掉与旋钮使用案例和使这些孩子关掉，等等？

谢谢！

Answer 1

关于你的问题：最常见的方法，我所看到的，是让每个使用情况下，一个活动图。

你的用例图的几点：

1 - 我从来没有见过用例图多个专业化。你可能想重新考虑一下。当用例A（子）专用于用例B（父）时，它继承了所有的前置条件，后置条件，主流和替代流程步骤。我可以猜测，这个功能对于你父母的使用情况是不一样的（例如打开音量和打开）;因此多重​​专业化在这里是没有意义的，至少可以说。

2-使用案例泛化应避免，除非它为您的模型增加实际价值。它不是非常直观，会让你的图表模糊不清。

3-此用例图似乎倾向于将用例视为类和泛化为继承;这是不正确的。

4-您可能还想重新考虑您的用例的粒度级别;用红外/旋钮打开并用红外/旋钮关闭可能都集成在一个合理大小的用例中，并有一些替代流程。但这是您作为需求工程师的选择，任何人都可以以不同的方式做。

我推荐你看看UML 2 and the Unified Process这本关于用例泛化的5.3节。

建议：

让我们假设你想保持独立的用例开启和关闭，并集中在一个用例（开启）：

1 - 如果通过打开步骤IR与用旋钮开启完全不同，开启用例摘要并且不写任何spec（文本）或为其绘制任何活动图。然后专门研究两个用例，称为用旋钮开启，用IR开启，这些用具有单独的规格和/或活动图。

2-如果除了用户选择IR或旋钮的一个步骤外，用IR开启的步骤几乎与用旋钮开启的步骤相同;你可以使用替代流程。在这种情况下，您可以只有一个用例和一个规范和/或一个活动图。

对其他三种使用情况也是如此。