用例是否有可能根据哪个Actor触发它而采取不同的操作？

Question

UML是否允许这样做？

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

Answer 1

UML允许这样的事情，但它们是无稽之谈（就像你可以使用英语来说废话）。用例表示其主要角色的附加值。如果你有一些UC template<template<class ...> class Op, typename ...Args> struct Detector<void_t<typename Op<Args...>::type>, Op, Args...> { // ^^^^^^^^ ^^^^^^ static constexpr bool value = true; }; ，这只是Pay for food的UC，而不是Waiter。后者只是次要角色，当然他没有从这个UC中获得额外的价值 - 恰恰相反。

Answer 2

如果你想按照非常严格的方式描述客户如何与餐馆作为讨论中的系统进行交互，那么你没有服务员作为一个参与者，它是系统的一部分，不属于这个级别的图表。

  

用例是否有可能根据哪个Actor触发它而采取不同的操作？

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

  

客户支付食品费用，服务员接受付款，但客户和服务员连接到同一个用例。

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

  

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

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

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

Answer 3

很容易。 UC图有特殊的说法。

您可以执行付款操作Include接收货币和付款操作。这绝对是正常的。

不要忘记，用例图不必是项目中最常见的图表。 UML直言不讳地将图表限制为抽象级别。因此，您可以创建更常见的用例，不使用include子任务，然后使用include生成更具体的用例。第一个将是向客户展示，第二个可能不会。