根据哪个Actor触发它，是否有可能使用不同的操作？

Question

UML是否允许这样做？

我可以定义演员如何与用例进行交互吗？ 换句话说，根据谁触发它，用例可以有不同的操作吗？ 例如在下面的图片中，客户支付食物，服务员接受支付，但客户和服务员连接到相同的用例。为服务员制作一个名为“接收付款”的单独用例不是更方便吗？

Answer 1

如果您想遵循非常严格的方式来描述客户端如何与餐厅进行交互作为讨论中的系统，那么您没有将服务员作为参与者，这是系统的一部分，不属于此层次的关系图。

---

是否有可能使用的情况下，以具有取决于哪个演员触发它不同的动作？

技术上是的，但它闻起来很糟糕。考虑将通用部分拆分为单独的场景（这可能需要创建新的通用角色）。无论如何，这与你的问题的主要部分无关。

客户支付食物，服务员接受支付，但客户端和服务员连接到相同的用例。

这里是棘手的部分。他们没有连接到相同的用例，只有客户端连接到您的“付费食物”。用例描述了Actor和正在讨论的系统之间的相互作用。在“为食物付费”中，服务员是系统的一部分，你只是没有把它作为这个级别的演员。

为服务员制作一个名为“接收付款”的单独用例不是更方便吗？

这实际上不是关于方便，而是。您有“客户为食品支付”一些高层次的“客户在餐馆吃饭”的情况。您可以通过“系统提供收据”，“客户提供现金”，“系统返回更改”等步骤将其扩展为较低级别的业务情景。

现在您可以将“系统提供收据”扩展到子功能级别的另一种场景中，您可以最后将服务员介绍为演员，并描述步骤如何进入收银机，使用徽章解锁，选择表格，点击“打印收据”......在这个级别的图表上，你最终会把服务员当作演员。

Answer 2

UML允许这样的事情，但他们都是胡说八道（就像你可以用英语交谈废话）。用例代表其主角的附加价值。如果你有一些UC Pay for food这只是Waiter的UC，而不是Client。后者只是次要角色，当然他没有来自加州大学的附加价值 - 反之则相反。

Answer 3

很容易。 UC图对此有特殊的词汇。

您可以采取支付行动Include接收货币和支付行为。这是绝对正常的。

不要忘记，用例图不一定是项目中最常见的图。 UML直言不讳地将图表限制为抽象层次。因此，您可以制作更常见的使用案例，无需使用include子任务，稍后再制作更具体的使用案例，使用include即可。第一个将被展示给客户，第二个可能不会。