如何正确使用案例＆lt; <generalization>＆gt;在用例图中？</generalization>

Question

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

我问这个是因为我想正确地绘制我的图表，以便任何具有正确UML知识的人都可以理解而不仅仅是以我理解的方式绘制图表。

现在我使用用例概括的原因就是为什么;

在阅读UML 2一书的第5.3节和统一过程之后，我认为我正在尝试做的是用例概括，特别是在查看第100页的示例之后。此示例显示了一个名为 FindProduct 的用例，如第101页中所述，是一个抽象用例。

我们读到了

  

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

这就是我想在图表中表示的内容。我有一个抽象用例打开，这个用例永远不会按原样执行。它需要孩子，或者在这种情况下，孩子要专门化它，因为系统将通过IR或KNOB打开，而且永远不会打开，这是抽象的。

所以这里的事情是我不确定多重概括和如果这样做是正确的。或者我应该更改使用IR转和使用KNOB转用例使用IR打开和使用KNW打开用例并使其成为开启的子项，并添加使用IR关闭和使用KNOB关闭用例并制作这些关闭的孩子，依此类推？

谢谢！

Answer 1

关于你的问题：我见过的最常见的方法是每个用例都有一个活动图。

关于您的用例图的几点：

1-我从未见过用例图中的多项专业化。你可能想重新考虑一下。当用例A（子）专门用例B（父）时，它继承了所有前提条件，后置条件，主流和备用流程步骤。我可以猜测，这些功能对于您的父用例并不相同（例如，打开音量并打开）;因此，至少可以说，多重专业化在这里没有意义。

2-应避免使用案例概括，除非它为您的模型增加了实际价值。它不是很直观，使你的图表模糊不清。

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

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

我建议你看看UML 2 and the Unified Process一书中关于用例概括的第5.3节。

<强>建议：

假设您要保留单独的用例以打开和关闭并专注于一个用例（打开）：

1-如果使用IR打开的步骤与使用旋钮打开完全不同，请打开用例摘要，不要写任何规格（文本）或为其绘制任何活动图。然后专门研究两个用旋钮打开的用例，用IR打开，具体分别是规格和/或活动图。

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

对其他三个用例执行相同操作。