软件架构与设计习题课 2 不同架构风格应用

这次的作业主要是利用课上所学过的各种架构风格来对之前设计的 ATM 来进行不同的理念尝试。

Main program and sub routines

这个风格实际上跟程序设计的思路很像，就是利用顺序、分支和循环来构建整个系统的逻辑，具体的设计主要就是根据 ATM 所需要执行的事务，合并公共部分，再利用分发机制由主程序切换到子任务，完成后再返回后续处理，设计如下：

面向对象的设计就和上周的作业差不多了，实际上就是每个组件能够独立完成需要这个组件参与的行动，然后组件之间通过过程调用来进行联系，具体如下：

虚拟机实际上就是分层风格，不同层次之间通过 API 进行通信。那么对于 ATM 来说，一个可能的分层模型就是每一层暴露给下一层的都是一个统一的标准化的操作，具体如下：

设计的逻辑其实和上面的虚拟机比较类似，只是把整个具体操作分离成了服务端与客户端。其中客户端负责做一些简单的验证和计算，服务端通过更加强大的硬件系统保证一致性。ATM 机的设计其实天然符合这种架构，如下：

MVC 模型其实不算特别适合 ATM 机，因为本身来说，显示的状态和内容有限，而且由于数据和逻辑紧密联系，分开来其实会带来一些不安全的因素，但是也是可以来尝试用这种架构来设计的，如下：

这个架构风格和一开始根据事务流程，有些类似，差别在于这个的设计重点在于数据的流动，然后根据数据的流动方向来设计对应的逻辑和步骤，具体如下：

这种模式实际上不大适合 ATM 机的交互，因为 ATM 需要在每个步骤都由用户确定来保证安全性，如果硬要用这种模式，就是用户一开始输入所有的内容，然后进行自动流程处理，如下：

Blackboard 的模式实际上跟 Client Server 有点类似，通过统一的数据访问接口，由 Blackboard 进行中心管理和流程控制，实话说不是特别适合 ATM，一个可能的设计如下：

这两种都不太适合 ATM 的设计，原因如下：

这两种同样不算特别适合 ATM，主要是设计思想的问题，无论是 interpreter 还是 mobile code，强调的都是灵活性。那么对于 ATM 来说，如果要排序的话，灵活性可能是最后一位的。因为灵活的同时不可避免就不太安全。

至于 Mobile Code，如果 mobile 一段恶意代码，显然要出大事，所以几乎不会被考虑。

这个模式在 ATM 的架构中也不算太合适，因为如果按照点对点的设计，那么一端是 ATM，另一端是银行，但是对于很多 ATM 来说，因为一端必须是银行，所以就变成了类似 Client Server 架构了。

基本的思路是通过事件来进行各个组件的连接和交互，简单来说如下：

这个架构的目标主要是兼容各种平台各种平台，因此也带来了很多复杂性。ATM 还是一个比较需要稳定，也不会有太多变化，所以不是特别适合。

这一课的主要目的是自己动手尝试设计不同的架构风格，学习就是先不要管对错，试试再说，可以慢慢修正嘛。