UML用例允许“用例多态”吗？

Question

我有两个角色：User和Admin，它们将与我的系统交互。Admin将泛化应用于来自User的固有用例。我有一个名为authenticate的用例，它应该有两种不同的行为。此用例的后置条件是:用户身份验证。

1. 如果User正在调用它，它应该只要求username
2. 如果Admin正在调用它，它应该要求username和password

用例图应该是这样的：

Answer 1

这个答案已经为UML2.5.1规范更新了。

首先，表示法似乎是有效的。

参与者(18.2.1)只能有UseCases、组件和类的关联，这些关联必须是二进制的。

管理员和用户之间的关系是泛化的(定义在9.9.7中)。它是DirectedRelationship的专门化(定义在7.8.5中)，它是关系的专门化(定义在7.8.15中)。关系的专门化是DirectedRelationship和Association (定义在11.8.1中)。这意味着泛化不是一个关联。

演员对什么是有效的协会施加限制。然而，Actor的定义并不限制其他关系，因此我们需要查看定义的层次结构，以确定泛化是否有效。

Actor是BehavioredClassifier的专门化(10.5.1)。没有一个定义的关联结束涵盖这个案例，所以我们需要继续寻找。BehavioredClassifier是分类器的专门化(10.5.1.3)。分类器的关联结束之一是泛化。因为分类器允许分类器之间的泛化，而Actor是一个分类器，而对泛化没有进一步的限制，所以这种关系似乎是有效的。

我想指出的是，没有一个示例图显示两个Actor之间的泛化关系。此外，在文本中没有讨论(我可以找到)关于这种关系。了解它的唯一方法是遵循行为者、协会和泛化的正式定义，贯穿于它们的层次结构中。

接下来要看的是这个图表对读者是否有意义。

形式上，用例在UML规范的第18节中描述--用例是系统提供的一组行为，这组行为也可以包括变体(变体包括，但不限于异常行为和错误处理)。非正式地说，用例是“通常定义角色和系统之间实现目标的交互的操作或事件步骤的列表”。

作为一名读者，如果我在没有任何解释性文本的情况下看到了图表，我会假设由身份验证用例定义的行为对于Admin和用户都是相同的。毕竟，两者都与同一组称为身份验证的行为有关系。我不会期望图表上的一个符号表示两组不同的事件步骤。

在UML中，用例可以相互关联，例如通过扩展和包含关系以及泛化。这些可以用于修改用例的行为。

我相信你可以用UML用例图来表达你想表达的一切。然而，我并不认为问题中的示例是向感兴趣方传递信息的最佳方式。

我倾向于通常避免用例图。相反，我倾向于一些文本或表格方法中的一种，用于捕获用例，将它们相互关联，并提取跨用例共享到单个位置的公共步骤或信息。这类似于Martin在UML蒸馏中提供的建议。

如果您强烈认为需要用例图，我将查看如何表示身份验证用例，以便更清楚地说明实际上有两个不同的流。我相信这里有几种不同的选择，它们都符合规范。

Answer 2

我更愿意使用用例之间的泛化关系来分解两个用例之间的共性。

用例、电话订单和网络订单是抽象用例顺序(斜体)的专门化。

换句话说，当您发现两个或多个在行为、结构和目的上有共同之处的用例时，就会使用泛化。当发生这种情况时，您可以在一个新的、通常是抽象的用例中描述共享部分，然后通过子用例进行专门化。

一旦知道，您将进一步使用(和)构造用例，以获得对项目的更多了解。

注意：(了解有关用例的更多信息)

1. 父用例可以专门化为一个或多个表示父用例的更特定形式的子用例。
2. 父母和孩子都不一定抽象。
3. 尽管父母在大多数情况下都是抽象的。
4. 子级继承父级的所有结构、行为和关系。同一父级的子级都是父级的专门化。
5. 泛化既适用于用例，也适用于参与者。