0

我有一项任务，其中规定了以下条件：

目的简要说明： ATM 是一种电子设备，用于自动取款。用户在授权后可以快速轻松地取款。用户通过读卡器和数字键盘与系统交互。小显示屏允许向用户显示消息和信息。银行会员可以访问特殊功能，例如订购对账单 要求简介： 需要自动柜员机 1. 允许授权持卡人进行交易

  1. 持卡人应查看和/或打印账户余额
  2. 持卡人须提取现金
  3. 持卡人须以现金或支票存款
  4. 持卡人应退出会话

允许银行会员获得额外的特殊服务

  1. 银行会员应能够订购对账单
  2. 银行成员应能够更改安全详细信息（例如 PIN 码）

允许访问授权的银行工作人员

  1. 授权人员可以访问重新进货机器

  2. 授权人员能够进行日常维护和保养

  3. 跟踪其中包含的金额并在库存减少时提醒银行工作人员

附加说明：用户应能够通过输入他们的帐号和 PIN 来访问 ATM。一旦系统验证了帐户处于活动状态并且 PIN 与帐号匹配，系统就会为用户提供四种选择。用户可以取款、存款、查看余额或退出会话。用户必须在他/她的帐户中至少有 100 美元。在任何交易结束时，都会向用户提供交易的打印副本。交易可以是 - 取款、存款或检查余额。一旦用户完成交易，系统会为用户提供相同的四个选择，直到用户决定退出。

该系统应与分配现金的设备、接受现金或支票的设备和打印机连接。由于本课程没有学习数据库，系统会将所有信息保存在两个 RandomAccess 文件中。一个文件将保存密码和其他帐户余额。

我已经构建了以下用例图，但对它应该有多详细，什么应该是扩展/包含以及什么应该是基本案例感到困惑。任何反馈都将受到欢迎。

银行会员和持卡人应该分开还是一起？从技术上讲，银行成员可以做的不仅仅是持卡人，比如更新安全细节或订单报表，但不是所有银行成员都是持卡人吗？

在此处输入图像描述

这是我拥有的另一个版本，减去退出不是用例，还有其他不正确的因素吗？

在此处输入图像描述

4

1 回答 1

1

以下是一些观察结果：

  • 正如评论的那样，Quit没有用例，因为它不会为参与者增加任何价值。相反，它看起来像是其他用例的后置条件。
  • 概括用例是一个坏主意（尽管每个 UML 都允许）。用例为使用所考虑系统的参与者展示了一个独特的附加值。在这种情况下，将多个用例归类为“常见”用例是没有帮助的。而是将专业化直接与演员联系起来并将其删除Transaction。
  • Bank Members与其将的关联复制到Quit/Transaction您，不如将其概括为Auth Card Holders.
  • 演员最好用单数。这是一个通用的角色名称，本身涵盖了任何数量的真实人/机器。
  • 需求/描述的一部分是进入用例的场景。尝试在用例中的功能分解中公开这些是常见的错误。

你的尝试还不错。但是从需求创建用例并不容易，需要大量的经验。所以（和往常一样）我建议阅读 Bittner/Spence 的用例。（不要阅读 UML 规范来了解 UC 合成。他们最多只能给出如何使用气泡和棒人的语法。）

正如 www.admiraalit.nl 所评论的那样，“可能”有用于概括用例的应用程序，您可以对此进行有争议的讨论。不使用它们是我自己的偏好，因为错误使用它比正确使用它更容易。导出/导入也是如此。只要你不知道它到底有什么用，就避免它。您倾向于开始功能分解，这不是 UC 所擅长的。

于 2019-09-23T06:28:04.270 回答