UML 练习 ATM 用例图

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

以下是一些观察结果：

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

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

---

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