2

我正在尝试创建有关 Scooter 系统的用例图。我已经创建了图表，您可以在此处找到它： 用例图：

在此处输入图像描述 我收到了一些关于这张图的评论：

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

如何根据评论修复图表？

附加信息：对系统的要求是：

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

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

要开始租用滑板车，用户必须扫描滑板车上的二维码贴纸。然后，该应用程序会检查付款信息，如果没有付款信息，则要求输入新信息。当支付信息正常时，滑板车解锁，用户可以开始骑行。要结束骑行，用户单击应用程序中的按钮。然后，该应用程序会计算行程摘要，显示所走路线、行驶距离和最终价格。与此同时，踏板车再次被锁定。然后，用户可以通过使用提供的信用卡详细信息授权付款或选择不同的付款方式来继续进行。

要成为金牌会员，用户只需单击一个按钮，就会看到新功能和成本的概述。如果同意，用户可以继续进行与之前相同的过程；使用提供的信用卡详细信息授权付款，或选择其他付款方式。金卡会员可提前预订滑板车。此过程首先在应用程序的地图上选择一个，或扫描踏板车的二维码。黄金会员然后选择为下一小时保留踏板车。在此期间，它不再显示为可供其他用户使用。

4

1 回答 1

3

该图中的主要问题是它的大多数用例都不是真正的用例。用例需要与参与者进行交互，并且应该与参与者的目标相对应。您在图表中拥有的大多数东西似乎都是现实特征。

如果是这样的ScooterProvider话，他可能是一个演员：

  • 公司的人工代表，例如文员、呼叫中心接线员。但我很难想象通过应用程序租用的每辆滑板车都会有人际互动。

  • 另一个有助于用例的系统。我们可以在这里想象一个专门的系统，它可以进行定价并与所考虑的系统进行交互。但是从整体上看，这似乎不太可能：我认为您尝试在这里展示您的系统应该自动执行的操作。这不是用例图的目的。

根据目标重新考虑您的用例：用户可能希望与您的系统交互的不同原因是什么？您将获得一个简化的集合，然后更好地对应用例。其余功能只是在用例描述中添加的特定要求。

不知道要求，很难就演员泛化提出建议：

  • 演员泛化意味着专业演员可以做一般演员可以做的一切，甚至更多。
  • 参与者是用户/系统在交互中扮演的角色。如果某些差异不是真正基于角色的，最好不要用概括的方式表现出来；使用约束以纯文本形式解释某些条件适用于用户调用用例。
  • 如果某些用例会引起中间角色的改变，请避免泛化，因为这是完全模棱两可的。

现在有了修改后的用例列表，您可能会遇到更少的此类问题：一旦折扣在更一般pay或check-out用例中消失，您将不再需要区分优惠券和其他用户。无论如何，任何用户都会突然想起口袋里有一张优惠券，或者可能决定保留优惠券以备下次骑行：优惠券实际上不是特定于演员的。

编辑，鉴于要求：

确认取消优惠券用户;-)

你选择了从系统来看的分析：任何用户都可能使用系统，但只要没有登录，系统就不知道用户的种类，可能性有限。如果您采用这种方法，您将拥有：guest(not logged-in), logged-in (normal) user, (logged-in) gold user。

由于只能使用guests来创建新帐户sign-up，因此其他参与者无法“继承”来宾。但是其他参与者也不会登录，因为他们只有在已经连接后才具有自己的角色。黄金用户必然是注册用户。

另一种方法是独立于系统状态来查看参与者角色。然后，您将拥有：（visitor根本没有帐户的人），registered users（他们有帐户，但是当他们使用系统时可以登录）并且gold users确实必须是注册用户。

有一个特殊用例reserve scooter仅适用于gold members并且黄金会员绑定到参与者（通过支付获得的权利）而不是短期临时系统状态的事实是使参与者相关的两个论点并且比通过约束处理此状态更合适。

于 2020-09-19T16:12:27.157 回答