Appearance
考点清单
- [x] 软件架构风格定义与五大分类（数据流/调用返回/独立构件/虚拟机/仓库）
- [x] 经典风格详解：管道-过滤器/批处理/主程序子程序/面向对象/层次结构
- [x] 独立构件风格：进程通信/事件驱动（隐式调用）
- [x] 虚拟机风格：解释器/基于规则的系统
- [x] 仓库风格：数据库系统/黑板系统/超文本系统
- [x] C2 体系结构风格
- [x] 闭环控制（过程控制）风格
- [x] C/S、B/S、多层架构
- [x] MVC / MVP / MVVM
- [x] 富互联网应用（RIA）
笔记
一、软件架构风格概述
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，这组约束指出系统如何将这些构件和连接件组合起来。
核心要点：
- 架构风格反映了领域中众多系统所共有的结构和语义特性
- 指导如何将各个模块和子系统有效组织成完整系统
- 架构设计的核心问题是能否达到架构级的软件复用
- 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
二、五大架构风格分类 ★
| 风格类别 | 核心特点 | 代表 |
|---|---|---|
| 数据流风格 | 面向数据流，按顺序从前向后执行 | 批处理序列、管道-过滤器 |
| 调用/返回风格 | 构件间存在显式调用关系 | 主程序/子程序、面向对象、层次结构 |
| 独立构件风格 | 构件独立，通过事件/异步触发 | 进程通信、事件驱动（隐式调用） |
| 虚拟机风格 | 自定义规则供使用者使用，跨平台适配 | 解释器、基于规则的系统 |
| 仓库风格 | 以数据为中心，所有操作围绕数据中心 | 数据库系统、超文本系统、黑板系统 |
三、数据流风格详解
批处理序列：
- 构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互
- 每个处理步骤是独立程序，每一步必须在前一步结束后才能开始
- 数据必须是完整的，以整体方式传递
- 前后构件不一定有关联
管道-过滤器：
- 每个构件有一组输入输出，读取输入数据流，处理后产生输出数据流
- 前一个构件的输出作为后一个构件的输入，前后数据流关联
- 过滤器 = 构件，管道 = 连接件
- 早期编译器采用此风格
二者区别：批处理前后构件不一定关联且作为整体传递（必须前一个执行完）；管道-过滤器是前一个输出作为后一个输入（前面执行到部分即可开始下一个）。
四、调用/返回风格详解
主程序/子程序： 单线程控制，把问题划分为处理步骤，构件即主程序和子程序，过程调用作为交互机制。
面向对象： 构件是对象（抽象数据类型的实例），连接件是对象间交互方式（函数和过程调用）。
层次结构：
- 构件组成层次结构，每层为上一层提供服务，使用下一层服务
- 只能见到与自己邻接的层
- 修改某一层，最多影响相邻两层（通常只影响上层）
| 优点 | 缺点 |
|---|---|
| 支持基于可增加抽象层的设计，可将复杂问题分解为增量步骤 | 并非每个系统都可划分为分层模式 |
| 不同层次处于不同抽象级别 | 很难找到合适的层次抽象方法 |
| 只要相邻层接口相同，每层可用不同方法实现，支持软件复用 | 层次通信效率相对较低（需从高到低再回到高） |
分层架构两大脆弱性：底层错误会导致整个系统无法正常运行；层间引入通信机制会造成性能下降。
五、独立构件风格详解
进程通信： 构件是独立的进程，连接件是消息传递。消息传递方式：点对点、异步/同步、远程过程调用等。
事件驱动系统（隐式调用）：
- 构件不直接调用过程，而是触发或广播一个或多个事件
- 构件中的过程在事件中注册，事件触发时系统自动调用注册的过程
- 优点：为软件复用提供强大支持，便于构件维护和演化
- 缺点：构件放弃了对系统计算的控制
六、虚拟机风格详解
解释器：
- 组成：完成解释工作的解释引擎 + 存储被解释代码的存储区 + 记录引擎工作状态的数据结构 + 记录执行进度的数据结构
- 缺点：执行效率低
基于规则的系统：
- 组成：规则集、规则解释器、规则/数据选择器、工作内存
- 一般用在**人工智能领域和 DSS（决策支持系统）**中
- 适合业务规则频繁变化的场景
考题套路：业务灵活组合、自定义规则 → 虚拟机风格。其中规则系统偏向专家系统，解释器偏向自定义逻辑执行。
七、仓库（数据共享）风格详解
| 类型 | 组成与特点 | 应用领域 |
|---|---|---|
| 数据库系统 | 中央共享数据源 + 多个独立处理单元 | 通用数据管理 |
| 黑板系统 | 知识源 + 黑板（全局数据库）+ 控制 | 信号处理、问题规划、编译器优化等无确定性算法的场景 |
| 超文本系统 | 网状链接，用户可按联想跳转 | 互联网 |
现代编译器的集成开发环境一般采用数据仓库（以数据为中心的架构风格）进行开发，中心数据即程序的语法树。
八、C2 体系结构风格
C2 风格概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。
组织规则：
- 系统中的构件和连接件都有一个顶部和一个底部
- 构件的顶部应连接到某连接件的底部，构件底部应连接到某连接件的顶部，构件与构件之间不允许直接连接
- 一个连接件可以和任意数目的其它构件和连接件连接
- 两个连接件直接连接时，必须由其中一个的底部到另一个的顶部
九、闭环控制（过程控制）风格
当软件被用来操作一个物理系统时，软件与硬件之间粗略表示为一个反馈循环。通过接受一定输入，确定一系列输出，最终使环境达到新状态。适合于嵌入式系统，涉及连续的动作与状态。
典型场景：空调温控、轿车巡航定速、机器人运动控制等需要持续测量-比较-调节的场景。
十、C/S、B/S 与多层架构
两层 C/S 架构：
- 客户端和服务器都有处理功能，现已不常用
- 缺点：开发成本高、客户端复杂、维护升级困难、安全性问题、难以复用
三层 C/S 架构：
- 表示层（客户机）+ 功能层（应用服务器）+ 数据层（数据库服务器）
- 将处理功能独立出来
| 优点 |
|---|
| 各层逻辑独立，系统结构清晰，提高可维护性和可扩展性 |
| 允许灵活选用相应平台和硬件，良好的可升级性和开放性 |
| 各层可并行开发，可选用各自最适合的开发语言 |
| 功能层有效隔离表示层与数据层，安全管理层次更合理可控 |
三层 C/S 关键在于各层之间的通信效率，要慎重考虑通信方法、通信频度和数据量。
三层 B/S 架构：
- 三层 C/S 的变种：客户端变为浏览器，应用服务器变为 WEB 服务器
- 又称0 客户端架构
- 缺点：缺乏动态页面支持、安全性难控制、响应速度远低于 C/S、数据动态交互性不强
混合架构：
- 内外有别模型：内部 C/S，外部 B/S
- 查改有别模型：B/S 查询，C/S 修改
- 缺点：实现困难且成本高
富互联网应用（RIA）：
- 弥补 B/S 架构问题，本质还是网站模式
- 结合 C/S 反应速度快、交互性强 + B/S 传播范围广
- 数据能缓存在客户端，减少服务器往返
- 本质仍是 0 客户端，借助高速网速实现必要插件本地快速缓存（如小程序）
十一、MVC / MVP / MVVM
MVC 架构：
| 组件 | 职责 |
|---|---|
| 控制器（Controller） | 处理用户交互，从视图读取数据，控制用户输入，向模型发送数据 |
| 模型（Model） | 处理应用程序数据逻辑，负责数据库存取，表示业务数据和业务逻辑 |
| 视图（View） | 处理数据显示，用户看到并交互的界面，不进行实际业务处理 |
MVP： 将 MVC 的 Controller 换为 Presenter（呈现），完全切断 View 与 Model 的联系，由 Presenter 充当桥梁。View 非常薄（被动视图），Presenter 非常厚（所有逻辑）。
MVVM：
- 低耦合：View 可独立于 Model 变化，一个 ViewModel 可绑定到不同 View
- 可重用性：视图逻辑放在 ViewModel 中，多个 View 重用
- 独立开发：开发人员专注业务逻辑，设计人员专注页面
- 可测试：测试可针对 ViewModel 编写