UML练习ATM用例图
我有一项任务，其中规定了下列条件：
目的简述:自动取款机( ATM )是一种用于自动配钱的电子设备。用户在授权后可以快速、方便地取款。用户通过读卡器和数字键盘与系统交互。小屏幕允许向用户显示消息和信息。银行会员可以使用特殊的功能，例如订购一份声明摘要要求: ATM是必需的1.允许持卡人进行交易
withdrawals
- Card卡持卡人应查看和/或打印账户余额
- 卡持卡人应支付现金或支票存款
- 卡持有人应退出会议
允许银行成员获得额外的特殊服务
- 银行成员应能订购对账单
- 银行成员应能更改安全细节(如PIN号)
允许接触经授权的银行工作人员
machine
- Authorized工作人员能够进行日常服务，maintenance
- To跟踪其包含多少资金，并在股票下跌时提醒银行职员
。
附加备注:用户可以通过输入他们的帐号和密码进入自动取款机。一旦系统确认帐户是活动的，并且PIN与帐号匹配，系统将为用户提供四种选择。用户可以取款、存钱、支票余额或退出会话。用户必须在他/她的帐户中至少有100美元。在任何事务结束时，向用户提供事务的打印副本。交易可以是取款、存钱或支票余额。一旦用户完成了事务，系统将为用户提供相同的四种选择，直到用户决定退出为止。
系统应与设备接口，以分送现金、接受现金或支票的设备以及打印机。由于本课程没有对数据库进行研究，本系统将把所有信息保存在两个RandomAccess文件中。一个文件将保存密码和其他帐户余额。
我已经构建了下面的用例图，但是对于它应该有多详细、什么应该是扩展/包含以及什么应该只是一个基本案例感到困惑。欢迎任何反馈意见。
银行会员和持卡人应该分开还是一起？从技术上讲，银行成员可以做的不仅仅是持卡人，比如更新安全细节或订单声明，但不是所有的银行成员都是持卡人吗？
下面是我的另一个版本，减去退出不是用例，还有其他不正确的因素吗？
回答 1
Stack Overflow用户
发布于 2019-09-23 06:28:04
以下是一些观察结果：
- 评论说，
Quit不是用例，因为它没有为参与者增加任何价值。相反，它看起来像其他用例的后置条件，cases. - Generalizing用例是个坏主意(尽管每个UML都是允许的)。用例显示了使用正在考虑的系统的参与者的单个唯一的附加价值。在这种情况下，将服务器用例分组在“公共”用例的帽子下面是没有帮助的。相反，将专门化与参与者直接连接起来，并删除将
Transaction. - Instead复制
Bank Members关联到Quit/Transaction的操作，您可以对Bank Members进行泛化，对参与者使用单数。它是一个通用的角色名称，其本身涵盖了任何数量的实际persons/machines. - A，需求/描述的一部分是进入用例的场景。在用例中尝试在功能分解中公开这些是常见的错误。
你的尝试还不错。但是从需求创建用例并不容易，需要大量的经验。因此(一如既往)，我建议阅读Bittner/Spence关于用例的文章。(不要阅读UML规范以获得UC合成的概念。他们最多能给出如何使用气泡和粘人的语法。)
正如www.admiraalit.nl所评论的那样，“可能”有一些应用程序用于泛化用例，您可以对此进行有争议的讨论。这是我自己的偏好，不使用它们，因为错误地使用它比正确地使用它更容易。出口/进口也是如此。只要你不知道它有什么好处，就避免这样做。您倾向于开始功能分解，这不是UC的好处。
https://stackoverflow.com/questions/58052670
复制相似问题
腾讯云开发者
