修复用例图：演员边界和泛化

Question

我正在尝试创建一个关于滑板车系统的用例图。我已经创建了该图，你可以在这里找到它：用例图。

我收到了一些有关此图的评论，其中包括：

1. 该系统（或滑板车提供商）不是参与者。事实上，系统边界表示系统，在用例中我们描述了外部参与者如何与系统交互。
2. 参与者之间的泛化使用不正确，例如，现在金牌会员也被允许注册。

我应该如何根据这些评论修复图表？

---

附加信息: 该系统的要求是:

打开应用程序后，它会显示靠近客人设备的可用滑板车。为了访问更多功能，应用程序需要客人注册帐户或登录。登录后，用户可以选择任何可用的滑板车并租用它。然后他们将进行骑行，并最终停止和结束租赁期。除此基本功能外，用户还可以升级其帐户到金牌会员帐户，从而进一步允许他们提前预订滑板车。在本文的其余部分中，您将找到更多有关应用程序的详细信息，这些详细信息应纳入您的解决方案中。并非所有步骤都完全展开，因此您可以自由选择这些细节。

在使用应用程序的任何服务之前，客户必须首先创建用户档案。这包括填写一些个人信息（姓名、电子邮件地址、信用卡信息等）。接下来，我们描述了成功使用其帐户登录的用户可以访问的场景。

要开始租用电动滑板车，用户必须扫描滑板车上的QR码贴纸。然后应用程序检查付款信息，并要求输入新信息（如果没有付款信息）。当付款信息正确时，滑板车就会解锁，用户可以开始骑行。结束骑行时，用户在应用中点击一个按钮。然后应用程序计算骑行摘要，显示所走路线、行驶距离和最终价格。同时，滑板车再次被锁定。然后用户可以通过使用提供的信用卡详细信息授权付款，或选择其他付款方式进行下一步操作。

要成为黄金会员，用户点击一个按钮，然后会看到新功能和费用的概述。如果同意，用户可以通过与之前相同的流程进行下一步操作：使用提供的信用卡详细信息授权付款，或选择其他付款方式。黄金会员可以提前预订电动滑板车。这个过程是从地图中选择一个，或扫描滑板车的QR码开始的。然后黄金会员选择预订接下来一个小时的滑板车。在此期间，该滑板车不再显示为其他用户可用。

- Ornela

---

评论已经告诉你哪里出了问题。UC图中还有更多的漏洞。没有了解需求，这里没有人能够帮助你。 - qwerty_so

嗨，我又编辑了一下问题，包括需求。 - Ornela

既然你已经得到了答案：“登录”并没有用处，因为它并没有增加价值。它只是你对某些用例施加的限制。 - qwerty_so

Answer 1

此图的主要问题在于大多数使用情况实际上并不是使用情况。使用案例需要与演员进行交互，并应对应于演员目标。您图中的大多数内容似乎实际上是功能。

如果ScooterProvider满足以下条件，则可以作为演员：

- 公司的人类代表，例如职员，呼叫中心操作员等。但我几乎无法想象每次通过应用程序租赁Scooter时都需要人类互动。 - 另一个系统对使用情况有贡献。我们在这里可以想象一个专门的系统，该系统进行定价并与正在考虑的系统进行交互。但是从整体上看，这似乎不太可能：我认为您尝试显示此处应自动完成的系统。这不是用例图的目的。

重新考虑您的用例以实现目标：用户可能希望与您的系统交互的不同原因是什么？您将获得一组较小的集合，然后更好地对应用例。其余特性只是要添加到用例描述中的特定要求。

由于不了解要求，很难建议演员概括：

- 演员概括意味着专门的演员可以做一般演员可以做的一切，甚至可能更多。 - 演员是用户/系统在交互中扮演的角色。如果某些差异实际上并不基于角色，则最好不要用概括显示它；使用约束说明文本以解释某些条件适用于用户调用用例。 - 如果某些用例会引起中途角色变更，请避免概括，因为这是非常模糊的。

现在有了修订后的用例列表，您可能会遇到更少的此类问题：一旦折扣在更一般的支付或结帐用例中消失，您将不再需要区分优惠券和其他用户。无论如何，任何用户都可能突然记得口袋里有优惠券，或者可能决定将优惠券保留下来供下次骑行使用：优惠券确实不是特定于演员的。

根据需求进行编辑：

确认删除优惠券用户 ；-)

您选择了从系统视角进行的分析：任何用户都可能使用系统，但只要未登录，系统就不知道用户类型并且可能性受限。如果采取此方法，则会有：guest（未登录），logged-in（normal）user（已登录的普通用户），（已登录的）gold user。

由于只有guests才能通过sign-up创建新账户，因此其他角色无法从访客那里“继承”。但是其他角色也不会登录，因为他们只有在连接后才有角色。因此，黄金用户必须是已注册用户。

另一种方法是独立于系统状态查看角色。然后你会有：visitor（没有账户的人），registered users（他们有一个账户，但使用系统时可以登录），以及gold users，他们必须是已注册用户。

有一个特殊的用例reserve scooter，只适用于gold members，而且黄金会员身份是与演员相关联的（通过付款获得的资格），而不是与临时系统状态相关联，这两个论点使演员相关并且比通过约束处理此状态更为合适。

- Christophe

---

嗨，我再次编辑了问题，包括要求。问题在于每个用例图都与演员有交互，正如要求中所解释的那样。然而，我也认为系统不能成为演员，但我想将时间作为演员来描述实现每个功能所需的时间。 - Ornela

再次您好，非常感谢您的回答。您的帮助相当大。我还想问您一个最后的问题。如果我们为演员“Scooter Provider”这样做：<<System>> Scooter Provider，是否有问题？因此，在这种情况下，演员将扮演身份验证的角色。 - Ornela

@Ornela 如果您有一个外部系统介入认证过程，该系统角色可以为登录用例做出贡献。它作为角色的角色可以被证明，因为用例也有助于实现其他系统的目标。但是，您应该称其为“身份验证服务”，而不是“滑板车提供商”，并且它应该是您系统之外的外部服务。根据要求，“滑板车提供商”涉及的所有事情实际上都是您的系统应该完成的事情。它在您的系统中，而不是在系统之外。因此，它不能成为一个角色。 - Christophe