本章属于教材第二篇 “关键技术”，由蔺一帅编写，是系统分析师考试的核心章节，覆盖上午综合知识选择题、下午案例分析题，同时是论文写作的高频选题方向，整体围绕 “架构概念→建模→风格→标准→设计实现→质量评估” 的完整体系展开。
一、本章主要内容
12.1 软件架构概述
核心定义：软件架构是软件系统的基本结构，由构件、构件间的关系、设计原则与约束共同构成，是连接需求与代码实现的桥梁，需同时支撑功能性需求与非功能性需求（性能、安全、可维护性等）。
架构的核心价值
干系人沟通的通用语言：让用户、开发、运维等不同角色基于架构达成共识。
早期设计决策的载体：确定系统最核心的技术选型、模块划分等决策，这类决策修改成本极高。
系统实现的约束框架：规定构件拆分规则与交互方式，保障设计一致性。
支撑复用与风险控制：通用架构模式可跨项目复用，早期架构评审可避免后期大规模返工。
架构发展阶段：萌芽阶段（无明确架构概念）→ 初级阶段（UML 等结构模型，关注实现细节）→ 高级阶段（高层抽象架构，区分架构与代码结构）→ 完善阶段（形成架构评估、演化的完整体系）。
12.2 软件架构建模
（1）5 类架构模型（按建模侧重点划分）
结构模型：以构件、连接件、约束为核心，描述系统静态组成结构。
框架模型：侧重系统宏观拓扑与整体组织，描述构件的高层划分。
动态模型：关注系统运行时的行为、状态变化与构件交互。
过程模型：描述架构设计的全流程、活动与步骤。
功能模型：以系统功能层次为核心，描述功能的划分与映射关系。
（2）“4+1” 视图模型（Philippe Kruchten）
本章核心知识点，通过 5 个视角完整描述软件架构，由 “场景” 串联四个视图：
逻辑视图：面向最终用户，对应功能需求，描述系统静态逻辑结构（类、业务模块）。
开发视图：面向编程人员，关注代码层面的组织方式，描述包、组件、依赖库的静态结构。
进程视图：面向系统集成人员，关注运行时性能、并发、吞吐量，描述进程、线程的动态交互。
物理视图：面向系统运维工程师，关注硬件部署与网络拓扑，描述系统物理节点的分布与通信。
场景（第 5 视图）：通过用例 / 业务场景串联四个视图，验证架构设计的合理性，是所有视图的公共交集。
12.3 软件架构风格
本章内容最丰富的小节，将经典架构分为 6 大类，每类包含具体风格、特征、适用场景与优缺点，是考试核心考点。
数据流风格
批处理序列：数据整体传递，前一阶段完全结束后下一阶段才启动，各步骤独立，适用于离线批量数据处理（如月度报表生成）。
管道 - 过滤器：数据以流式逐段处理，每个过滤器为独立构件，输入输出无缝衔接，适用于数据流水线场景（如编译器、视频转码）。
调用 / 返回风格
主程序 / 子程序：单线程自上而下层次调用，传统结构化程序的经典结构。
面向对象风格：对象封装数据与方法，通过消息交互，具备高内聚、低耦合特征。
层次型架构：按抽象层级划分，每层仅调用下层、为上层提供服务，修改最多影响相邻两层，如经典的表示层 - 业务层 - 数据层架构。
C/S 架构：分为二层（胖客户端，业务逻辑在客户端）与三层（表示层、功能层、数据层分离，引入中间件，支持瘦客户端与横向扩展）。
B/S 架构：三层架构的 Web 化形态，客户端为浏览器，零安装、维护集中，适用于广域网用户分散的场景。
以数据为中心的风格
仓库风格：中央数据存储为核心，各独立构件主动读写共享数据，如数据库管理系统。
黑板风格：由知识源、黑板、控制三部分组成，无固定求解算法，由黑板状态驱动知识源工作，适用于复杂不确定问题，如语音识别、IDE 智能提示、专家系统。
虚拟机风格
解释器风格：模拟自定义虚拟机执行指令，灵活性极高但运行效率低，如脚本解释器、JVM。
规则系统风格：基于规则库与推理引擎，匹配规则触发对应动作，如决策支持系统、风控规则引擎。
独立构件风格
进程通信风格：独立进程通过消息传递交互，分为同步 / 异步、RPC 等模式，是分布式系统的基础。
事件驱动（隐式调用）：构件注册事件，事件触发时自动调用对应过程，松耦合、复用性强，如 GUI 事件系统、消息发布订阅模式。
面向服务架构（SOA）
核心思想：将业务功能封装为自治、标准化的服务，通过统一协议交互，实现服务复用与业务组合。
延伸演进：微服务架构是 SOA 的轻量化形态，服务粒度更细、独立部署、技术栈灵活。
12.4 软件架构标准
核心为 IEEE 1471-2000（ISO/IEC 42010） 软件架构描述标准，定义了架构描述的元模型与核心元素关系：
核心要素：系统、环境、干系人、关注点、架构说明、视图、模型。
核心逻辑：架构说明由多个视图组成，每个视图对应一类干系人的特定关注点；视图由模型构成，从特定角度具象化描述架构。
12.5 基于架构的软件开发过程
完整覆盖架构从需求到演化的全生命周期，分为 5 个核心阶段：
架构需求阶段：获取架构相关需求，标识系统核心构件，完成架构需求评审，明确功能与非功能需求对架构的约束。
架构设计阶段：提出候选架构模型，将需求映射到具体构件，分析构件交互关系，生成正式架构方案并完成设计评审。
架构文档化：输出标准化架构设计文档，包含架构视图、构件说明、设计原则与约束，是开发、评审、演化的核心依据。
架构实现阶段：将架构设计映射到具体技术栈，选择对应框架与中间件，按架构约束完成编码与系统集成。
架构演化阶段：系统运行过程中，根据业务需求变化调整架构，包含演化规划、构件增改、架构重构、演化评审等环节。
12.6 软件架构质量属性与评估
核心质量属性：架构设计的核心目标是保障非功能属性，主要包括性能、可用性、可修改性、安全性、可测试性、易用性等。
质量属性场景：将抽象质量属性量化、场景化的标准方法，由 6 要素构成：刺激源、刺激、环境、制品、响应、响应度量，是架构评估的核心工具。
主流架构评估方法
SAAM（基于场景的架构分析方法）：最早的标准化架构评估方法，以可修改性为核心评估目标，通过场景验证架构能力，适合项目早期的候选架构对比选型。核心步骤：场景开发→架构描述→单场景评估→场景交互分析→总体评估。
ATAM（架构权衡分析方法）：在 SAAM 基础上发展而来，核心目标是解决多质量属性间的冲突与折中，识别架构中的风险点、敏感点、权衡点。核心分为四个阶段：演示介绍→调查与分析（生成质量属性效用树）→测试验证→评估报告。
关键概念
敏感点：某个构件的设计 / 参数，会显著影响某一个质量属性。
权衡点：同时影响多个质量属性的敏感点，调整它会让一个属性提升、另一个属性下降，是架构折中决策的核心。
风险点：架构中存在的设计隐患，可能导致质量属性无法达标。
二、主要考点与考情分析
本章在上午综合知识中占 5-8 分，下午案例分析中占 15-20 分，同时是论文写作高频选题，考情分布如下：
（一）上午综合知识（选择题）考点
基础概念辨析：软件架构的定义与作用、5 类架构模型的特征区分、架构发展阶段，多为概念匹配题。
“4+1” 视图模型：必考 1-2 题，考查每个视图的面向角色、关注点、动静态属性，如 “关注系统并发性能的是哪个视图”。
架构风格判断：本章最高频考点，占选择题分值一半以上。出题方式为给出业务场景，判断对应架构风格；或给出风格，选择适用场景 / 优缺点。易混点为管道 - 过滤器与批处理、黑板与仓库、二层与三层 C/S。
IEEE 1471 标准：考查核心元素的对应关系，如 “视图对应干系人的什么？由什么构成？”。
质量属性场景：考查 6 要素的区分，给出场景描述判断刺激源、刺激、环境等要素。
架构评估方法：SAAM 与 ATAM 的目标、流程、适用场景对比，以及敏感点、权衡点、风险点的概念辨析。
（二）下午案例分析考点
架构风格选型：给出具体业务场景，要求选择合适的架构风格，说明选型理由并对比不同方案的优劣。
质量属性场景补全：给出系统质量目标，要求补充为完整的质量属性场景，或判断场景描述的错误。
架构评估应用：结合项目背景，考查 ATAM 的执行流程、输出产物，或识别案例中的敏感点、权衡点，给出质量属性冲突的折中方案。
架构问题诊断与优化：给出某系统的架构设计方案，指出存在的架构缺陷，结合性能、可用性、可扩展性等属性提出优化建议。
“4+1” 视图落地：要求说明具体业务系统中，逻辑视图、开发视图、进程视图、物理视图分别包含哪些内容。
（三）论文写作考点
软件架构设计是系统分析师论文的核心选题方向，高频题目包括：
论软件架构风格的选型与实践
论基于架构的软件开发方法
论软件系统质量属性的设计与保障
论微服务架构的设计与落地
论架构评估方法在项目中的应用
论文评分核心是结合真实项目，体现架构设计的决策过程、问题与解决方案，避免纯理论堆砌。
三、重难点深度解析
（一）重点：易混架构风格的核心区分
（二）难点：质量属性场景 6 要素精准区分
这是案例题的高频失分点，核心是理清 “谁 - 什么事 - 什么情况 - 作用对象 - 系统反应 - 衡量标准” 的逻辑：
刺激源：触发事件的主体（谁发起），如用户、外部系统、硬件故障。
刺激：具体发生的事件（发生了什么），如提交订单、服务器宕机、需求变更。
环境：事件发生的约束条件（什么情况下），如高并发高峰期、系统升级窗口、正常运行时段。
制品：被作用的对象（作用在什么上），如交易系统、数据库模块、缓存服务。
响应：系统的应对动作（系统怎么做），如处理请求、切换备机、拒绝非法访问。
响应度量：量化的达标指标（怎么算合格），如响应时间 < 300ms、可用性 99.9%、故障恢复时间 < 10 分钟。
（三）难点：SAAM 与 ATAM 的核心差异
（四）易错点：敏感点、权衡点、风险点的关系
敏感点只影响单个质量属性，是单属性的关键影响因子；
权衡点同时影响多个质量属性，是 “双刃剑”，所有权衡点本质都是敏感点；
风险点是架构中未合理设计的隐患，通常是未被妥善处理的敏感点或权衡点。
举例：“接口加密强度” 是权衡点 —— 强度越高安全性越好，但性能会下降；“单节点部署无备份” 是可用性的风险点。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
欢迎访问 小易撩挨踢