软件架构与设计 习题课 1 面向对象复习

前面几讲我们了解了一堆概念，这一节课里我们借用 ATM 的例子，来回顾一下面向对象设计的基本知识（注：本『课』由第一次作业拓展而成）

---

这一讲的主要任务有三个：

1. 利用软件开发者的知识，设计一个软件系统，作为之后进行修改的基础
2. 复习一下面向对象分析与设计的基本知识
3. 熟悉如何使用 UML 来表达软件设计

主要的产出有以下这三个：

1. 用例图 Use Case Diagram：从用户角度定义系统功能
2. 类图 Class Diagram：列出系统中的不同组件
3. 时序图 Sequence Diagram：给出组件间的关联

接下来，我们先来看一下具体的需求。

系统需求

需求很重要，尤其是作为课程作业，有没有好好阅读决定了能不能清晰定义设计的边界，也就意味着能不能用最有效率的方式完成老师的要求。但是在实际工作中，需求本身往往也是不明确的，就需要架构师有穿透力和远见，透过现象看本质，找到最佳的设计方案。

基本来说，我们需要确定的是系统的核心架构以及组件间的依赖和连接。也就是说，先根据需求设计不同的组件，然后用某种方式把它们连接起来。具体的需求如下：

每一台 ATM 机有这些硬件：

• 读卡装置：刷卡或插卡
• 键盘：输入密码
• 显示屏：显示交互信息
• 存取款槽：存钱或取钱时放钱的地方
• 打印机：打印回执
• 开关：开启或关闭 ATM

ATM 机与银行的交互可以抽象成一个黑盒不在这次设计的范围内，使用流程如下：

• 一台 ATM 机一次只能为一名用户提供服务
• 用户需要插卡并输入密码（会传输给银行进行验证）
• 验证通过后可以进行交易（查询/存取款/转账/等等）
• 交易过程中卡都在 ATM 机子里面（例外的情况会具体列出来）
• 每次交易都需要通过银行验证，在存钱取钱拆信封等物理操作完成之后还会再发送第二条消息
• 如果密码输入错误，需要重新输入，最多有三次机会，都错误的话会吞卡，用户需要找银行来拿回卡
• 如果交易失败（不是因为密码错误）的话，屏幕会显示错误信息，并询问用户是否需要再次交易
• 交易成功会给用户打印收据，包括日期时间机器位置交易类型账户数额和目前余额
• 关闭 ATM 之前需要与银行确认，关闭之后可以装现金，取出信封之类的
• 如果 ATM 里面不够钱，就会推荐附近够钱的 ATM
• 如果是从其他银行取钱，会收取一定的手续费，收取之前需要用户确认
• 通常来说有每日的取款金额限制

ATM 机应该提供以下服务：

• 用户可以从与这张卡关联的账户中取钱，数量为 20 的倍数，取钱之前需要银行验证
• 用户可以向与这张卡管理的账户中存钱，现金或者支票都可以，用户需要输入存钱的金额，在机器移除装支票的信封时需要手动确定，接收信封之前需要银行同意
• 用户可以在与这张卡关联的账户之间相互转账
• 用户可以查询与这张卡关联的账户

其他事项：

• 试着指出一些非功能需求，提出一些问题，想一下边界情况
• 因为设计金钱，所以需要保证可靠性，思考一下出问题怎么保证一致性（原子操作）
• 当前用户信息在取卡之后需要消除
• 可能之后会支持更多银行，留下拓展空间
• ATM 支持多语言

用例图 Use Case Diagram

这里是比较简单的画法，比方说没有涉及到交易时的细节，只是给出了顶层的几个大类的操作。（当然理论上应该画得更详细，但是我懒）

类图 Class Diagaram

设计类图的时候需要注意，因为和之后的时序图有关系（类越多时序图越复杂），所以需要进行合理的抽象和组合。比如说，ATM 机有许多硬件，如果每个都是一个类，那么交互就很复杂了，不妨只有一个 Machine 类，里面包含其他的硬件的类别（当然这里不会详细画出来），这样就保证了和用例图在同一个层次的抽象上，让人一看就明白。

这里抽象出来几个具体的类别，利用继承来简化设计，注意，并不包括银行部分的设计。

时序图 Sequence Diagram

这里同样是采用了比较简略的设计。

参考资料

• 统一建模语言, Unified Modeling Language