本文整理自《芝士架构公共知识红宝书》系统架构设计师公共基础知识第 4 章，涵盖架构基本定义、4+1 视图、ABSD 方法、架构风格、架构复用、DSSA、质量属性与架构评估等核心内容。
一、基本定义
信息系统架构是关于软件系统的结构、行为和属性的高级抽象。
- 描述阶段： 对象是直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件之间的通信
- 实现阶段： 抽象组件被细化为实际的组件（具体类或对象）
软件体系结构的设计通常考虑到设计金字塔中的两个层次：数据设计和体系结构设计。
二、软考中的 4+1 视图
Kruchten 在 1995 年提出”4+1”视图模型，从 5 个不同视角描述软件架构，每个视图只关心系统的一个侧面。
| 视图模型 | 5 个视图 | 记忆口诀 |
|---|---|---|
| 架构”4+1”视图模型 | 逻辑视图、开发视图、进程视图、物理视图、场景视图 | 罗凯进五常（罗→逻辑，凯→开发，进→进程，五→物理，常→场景） |
| RUP/UML 的”4+1”视图模型 | 逻辑视图、实现视图、进程视图、部署视图、用例视图 | 落实进步用（落→逻辑，实→实现，进→进程，部→部署，用→用例） |
| ABSD 中的 4+1 视图 | 逻辑视图、实现视图、进程视图、配置视图、用例视图 | 逻实进配 |
软考中共有 3 种 4+1 视图，注意区分。
三、软件架构设计与生命周期
架构设计贯穿软件生命周期的 6 个阶段：
| 阶段 | 主要研究内容 |
|---|---|
| 需求分析阶段 | 从需求模型转换到架构模型及保证可追踪性 |
| 设计阶段 | 架构模型描述相关内容（构件、连接器、ADL、多视图表示） |
| 实现阶段 | 缩小架构设计与具体实现的差距（引入编程概念、模型转换、构件组装） |
| 构件组装阶段 | 依据架构模型进行构件组装及处理失配问题 |
| 部署阶段 | 基于架构模型描述软硬件部署模型及分析质量属性 |
| 后开发阶段 | 动态软件架构及遗留系统架构相关研究 |
构件组装阶段的失配问题来源：
- 构件引起的失配（基础设施、控制模型、数据模型假设冲突）
- 连接子引起的失配（交互协议、连接子数据模型假设冲突）
- 全局体系结构的假设存在冲突
四、基于架构的软件开发方法 ABSD
4.1 基本概念
ABSD（Architecture-Based Software Design）方法是由体系结构驱动的，即由构成体系结构的商业、质量和功能需求的组合驱动。
3 个基础：
| 基础 | 说明 |
|---|---|
| 功能分解 | 使用基于模块的内聚和耦合技术 |
| 体系结构风格 | 通过选择架构风格来实现质量和商业需求 |
| 软件模板 | 利用一些软件系统的结构 |
核心特点：
- 自顶向下、递归细化的方法
- 迭代的每一个步骤都是清晰定义的
- 从不同视角观察架构（静态视角判断质量特性，动态视角判断系统行为特性）
- 用例捕获功能需求，质量场景捕获质量需求（变更场景、性能场景、可靠性场景、交互性场景）
4.2 ABSD 开发模型（6 个子过程）
| 阶段 | 主要内容 |
|---|---|
| 体系结构需求 | 获取用户需求并标识构件，需求评审 |
| 体系结构设计 | 需求激发和调整设计决策，通过不同视图表达质量目标 |
| 体系结构文档化 | 输出体系结构规格说明和测试质量设计说明书 |
| 体系结构复审 | 外部人员参与，标识潜在风险，发现设计缺陷 |
| 体系结构实现 | 按设计结构组装构件实现，完成系统连接合成 |
| 体系结构演化 | 需求变化归类→制订演化计划→修改构件→更新相互作用→组装测试→技术评审 |
记忆口诀：许设温敷实验（需求→设计→文档→复审→实现→演化）
五、软件架构风格
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它定义一个词汇表（构件和连接件类型）和一组约束（如何组合）。
5.1 数据流体系结构风格
| 二级风格 | 概念 | 应用 |
|---|---|---|
| 批处理 | 数据必须完整、以整体方式传递，前一步结束后才能开始下一步 | 经典数据处理、编译器 |
| 管道-过滤器 | 系统分解为处理步骤，通过数据流连接，一个步骤的输出是另一个的输入 | Unix Shell 程序 |
批处理 vs 管道-过滤器： 批处理前后构件不一定有关联，数据作为整体传递；管道-过滤器是前一个输出作为后一个输入，可并行执行。
5.2 调用/返回体系结构风格
| 二级风格 | 概念 | 应用 |
|---|---|---|
| 主程序/子程序 | 单线程控制，分治策略，子程序可合成为模块 | 早期结构化程序设计 |
| 面向对象 | 基于数据抽象，数据的表示方法和操作封装在对象中 | Java/C# 应用程序 |
| 层次型 | 每一层为上层提供服务并作为下层的客户，最多只影响两层 | Web 系统、数据库应用 |
| 客户端/服务器 | 基于资源不对等实现共享，三层 C/S 分为表示层、功能层和数据层 | Web 系统、数据库应用 |
5.3 以数据为中心的体系结构风格
| 二级风格 | 概念 | 应用 |
|---|---|---|
| 仓库 | 中央数据结构说明当前状态，独立构件对中央数据进行操作 | 现代 IDE、企业级数据管理系统 |
| 黑板 | 问题求解模型，将解空间组织成分级结构 | 信号处理（语音识别、模式识别） |
5.4 独立构件体系结构风格
| 二级风格 | 概念 | 应用 |
|---|---|---|
| 进程通信 | 构件是独立过程，连接件是消息传递 | 分布式系统、微服务架构 |
| 事件系统（隐式调用） | 构件不直接调用过程，而是触发或广播事件 | 集成工具、数据库管理系统、编辑器语法检查 |
| C2 | 构件和连接件都有顶部和底部，通过连接件绑定 | 并行构件网络 |
5.5 虚拟机体系结构风格
| 二级风格 | 概念 | 应用 |
|---|---|---|
| 解释器 | 人为构建运行环境，解析与运行自定义语言 | 在线游戏系统、业务灵活组合 |
| 规则系统 | 包括规则集、规则解释器、规则/数据选择器及工作内存 | 专家系统/决策支持系统 |
5.6 其他风格
| 风格 | 概念 | 应用 |
|---|---|---|
| 闭环控制（架构-过程控制） | 软件与硬件之间的反馈循环 | 空调控温、定速巡航 |
六、软件架构复用
6.1 软件产品线
软件产品线是一组软件密集型系统，共享一个公共的、可管理的特性集，满足某个特定市场或任务的需要，以规定的方式用公共的核心资产集成开发出来。
核心资产库包括：软件架构及其可剪裁的元素、设计方案及文档、用户手册、项目管理历史记录、软件测试计划和测试用例。
复用类型：
| 类型 | 定义 |
|---|---|
| 机会复用 | 开发过程中发现可复用资产就对其进行复用 |
| 系统复用 | 开发之前进行规划，决定哪些需要复用 |
6.2 架构复用的基本过程
| 阶段 | 主要内容 |
|---|---|
| 获取可复用的软件资产 | 资产须具备可靠性、广泛适用性、易理解性、易修改性 |
| 管理可复用资产 | 构件库支持存储、管理、检索、浏览与维护 |
| 使用可复用资产 | 通过修改、扩展、配置等方式定制资产，组装集成形成最终系统 |
七、特定领域软件体系结构 DSSA
DSSA（Domain-Specific Software Architecture）是专门为解决某一特定领域问题而设计的软件体系结构。
7.1 领域分类
| 类别 | 定义 | 适用范围 |
|---|---|---|
| 垂直域 | 定义特定系统族，包含族内多个系统 | 只能应用于成熟、稳定的领域 |
| 水平域 | 定义多个系统和多个系统族中功能区域的共有部分 | 只要存在部分功能共性即可 |
7.2 基本活动（3 种）
| 活动 | 目标 |
|---|---|
| 领域分析 | 获得领域模型，描述领域中系统的共同需求 |
| 领域设计 | 获得 DSSA |
| 领域实现 | 依据领域模型和 DSSA 开发和组织可重用信息 |
7.3 参与人员（4 种）
| 角色 | 描述 |
|---|---|
| 领域专家 | 资深用户、从事需求分析/设计/实现/项目管理的软件工程师 |
| 领域分析人员 | 具备知识工程背景的资深系统分析员 |
| 领域设计人员 | 资深软件设计人员 |
| 领域实现人员 | 资深程序设计人员 |
7.4 建立过程（5 个阶段）
定义领域范围 → 定义领域特定的元素 → 定义领域特定的设计和实现的需求约束 → 定义领域模型和体系结构 → 产生、搜集可重用的产品单元
八、系统质量属性与架构评估
8.1 软件系统质量属性
| 分类 | 包含属性 |
|---|---|
| 开发期（6 个） | 易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性 |
| 运行期（7 个） | 性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性 |
8.2 面向架构评估的质量属性（9 大必考）
| 属性 | 描述 | 典型对策 |
|---|---|---|
| 性能 | 系统响应能力，处理事务所需时间 | 优先级队列、增加计算资源、引入并发机制 |
| 可靠性 | 在错误情况下维持功能特性的能力 | 冗余设计、错误检测与恢复、异常处理、备份恢复 |
| 可用性 | 系统正常运行的时间比例 | 心跳机制、冗余系统、快速恢复机制、故障转移 |
| 安全性 | 阻止非授权访问或拒绝服务的能力 | 用户认证、授权管理、数据加密、防火墙、入侵检测 |
| 可修改性 | 快速、高性价比地变更系统的能力 | 模块化设计、接口标准化、抽象与封装、配置管理 |
| 互操作性 | 与其他系统或环境交互的能力 | 标准协议和接口、数据格式转换、中间件 |
| 可移植性 | 适应不同运行环境的能力 | 抽象层、环境无关代码设计、兼容性测试 |
| 可测试性 | 软件能够被有效测试的难易程度 | 设计分层与模块化、提供测试接口 |
| 易用性 | 系统让用户”好学、好找、好操作、少犯错” | 统一交互规范、即时反馈、降低认知负荷 |
可靠性 vs 可用性： 真题中涉及”发现错误并启用备用系统”“重定向到备用站点”等场景，默认归为可用性。
8.3 质量属性场景
质量属性场景是精确描述软件系统质量属性的手段，由 6 个组成部分组成：
| 组成部分 | 定义 |
|---|---|
| 刺激源 | 生成刺激的实体 |
| 刺激 | 到达系统时需考虑的条件 |
| 环境 | 刺激发生的条件 |
| 制品 | 被激励的对象 |
| 响应 | 激励到达后采取的行动 |
| 响应度量 | 对响应进行度量的方式 |
记忆口诀：原词换纸想读（刺激源→刺激→环境→制品→响应→度量）
8.4 架构评估中的重要概念
| 概念 | 定义 | 举例 |
|---|---|---|
| 敏感点 | 一个或多个构件的特性，影响某个质量属性 | 对查询请求处理时间的要求将影响数据传输协议设计 |
| 权衡点 | 影响多个质量属性的特性，是多个敏感点的综合 | 加密级别选择影响安全性和性能 |
| 风险点 | 可能导致架构出现问题或无法满足质量属性要求的特性 | 如果业务逻辑描述未达成共识，可能影响可修改性 |
| 非风险点 | 不会对架构质量属性造成负面影响或影响在可接受范围内 | 使用成熟的消息队列中间件不会带来明显风险 |
| 风险承担者 | 系统架构涉及的利益相关者 | 财务部门、销售部门 |
| 场景 | 从风险承担者角度对系统交互的简短描述 | 客户在公共 Wi-Fi 下登录银行系统，10 秒内完成验证 |
敏感点 vs 权衡点： 敏感点只影响一个质量属性；权衡点影响多个质量属性。
8.5 系统架构评估方法
SAAM（基于场景的架构分析方法）
| 维度 | 内容 |
|---|---|
| 目标 | 通过场景验证架构假设和原则，评估架构固有风险，比较不同架构方案 |
| 关注质量属性 | 主要关注可修改性 |
| 评估过程 | 场景开发 → 架构描述 → 单场景评估 → 场景交互评估 → 总体评估 |
ATAM（架构权衡分析方法）
ATAM 在 SAAM 基础上发展，主要针对性能、可用性、安全性和可修改性进行评价和折中。
4 个主要阶段（分析过程）：
| 阶段 | 内容 |
|---|---|
| 场景和需求收集 | 收集场景以及约束等需求信息 |
| 架构视图和场景实现 | 描述体系结构图，实现场景 |
| 属性模型构造和分析 | 构建属性模型并分析特定属性 |
| 折中 | 标志折中情况，识别敏感点 |
4 个实践阶段：
| 阶段 | 主要内容 |
|---|---|
| 演示阶段 | 评估团队介绍 ATAM 过程、业务目标和要评估的体系结构 |
| 调查和分析阶段 | 深入探讨架构方法，生成质量属性效用树，分析架构方法 |
| 测试阶段 | 通过头脑风暴和优先场景理解质量属性要求 |
| 报告阶段 | 向利益相关者呈现评估结果，为架构改进提供指导 |
效用树（Utility Tree）：
- 结构：树根 → 质量属性 → 属性分类 → 质量属性场景（叶子节点）
- 优先级排序：按重要性（H/M/L）和实现难易度（H/M/L）组成优先级对
- 如 (H, L) 表示该场景重要且易实现
CBAM（成本效益分析方法）
CBAM 的核心思想是架构策略影响系统的质量属性，质量属性变化会为相关方带来收益（效用）。CBAM 协助相关方根据投资回报率（ROI）来选择最优架构策略。
总结
| 领域 | 核心要点 |
|---|---|
| 基本定义 | 架构是结构、行为和属性的高级抽象，包含数据设计和体系结构设计 |
| 4+1 视图 | 3 种 4+1 视图：架构视图、RUP/UML 视图、ABSD 视图 |
| ABSD | 架构驱动，3 个基础（功能分解+架构风格+软件模板），6 个子过程 |
| 架构风格 | 5 大类：数据流、调用/返回、以数据为中心、独立构件、虚拟机 |
| 架构复用 | 软件产品线、机会复用 vs 系统复用、3 阶段复用过程 |
| DSSA | 垂直域/水平域、3 基本活动、4 参与人员、5 阶段建立过程 |
| 质量属性 | 9 大必考属性、质量属性场景 6 要素、敏感点 vs 权衡点 |
| 架构评估 | SAAM（关注可修改性）、ATAM（关注性能/可用性/安全性/可修改性）、CBAM（ROI） |
