基于Java Swing的ATM系统序列图构建方法咨询

核心原则：根据序列图的目标受众和用途决定 #

如果你的序列图是用来梳理业务逻辑流程（比如给后端开发、业务分析师看），可以优先展示核心业务类的交互，暂时省略UI类；如果是用来指导完整系统开发（包括UI层实现），或者需要明确用户操作到逻辑层的完整链路，就必须加入UI类。

两种场景的具体实现方案 #

1. 聚焦业务逻辑的序列图（不含UI）

以「客户取款」流程为例，交互序列如下：

• 外部参与者（客户） → Customer：调用login()（传入账号+PIN）
• Customer → ATM：验证通过后同步登录状态
• 外部参与者（客户） → Account：发起取款请求（传入金额）
• Account → Transaction：创建交易记录
• Transaction → Transaction：调用generateReceipt()生成PDF凭证
• Account → MySQL数据库：更新账户余额
• ATM → MySQL数据库：获取并存储交易记录

这种方式能清晰展示核心业务逻辑的依赖和数据流向，适合专注于业务规则的梳理。

2. 完整链路的序列图（包含UI类）

如果需要体现用户操作到逻辑的完整路径，以「客户转账」流程为例，交互序列如下：

• 外部参与者（客户） → ATMSwingUI：输入转账金额、目标账号，点击确认按钮
• ATMSwingUI → Customer：调用login()验证当前登录状态
• Customer → ATM：确认已登录账户信息
• ATMSwingUI → Account：发起转账请求（传入当前账户、目标账号、金额）
• Account → Account：验证目标账户合法性
• Account → MySQL数据库：扣减当前账户余额、增加目标账户余额
• Account → Transaction：创建转账交易记录
• Transaction → Transaction：调用generateReceipt()生成凭证
• Transaction → ATMSwingUI：返回凭证生成状态，UI提示用户完成

这种方式能明确UI层如何调用业务逻辑，适合前端开发和全流程测试人员参考。

逻辑与UI分离的配套序列图设计 #

既然你已经尝试分离逻辑与UI，可以给序列图做分层处理：

• 用垂直虚线划分「UI层」和「业务逻辑层」
• UI类仅负责接收用户输入、调用逻辑层方法、展示结果，不掺杂业务规则
• 核心业务类专注于数据处理、数据库交互、业务规则校验，避免与UI耦合

这种设计既保持了序列图的清晰性，又能体现分层架构的设计思路。

内容的提问来源于stack exchange，提问作者Adrian Floroiu