第十二章质量属性与架构
软考高级系统架构设计师备考，写着方便自己看，如果有发现不对或少得的地方可以多多指正，谢谢各位兄弟。
一、软件系统质量属性
1. 质量属性的两大分类（生命周期维度）
|
分类 |
核心定义 |
包含属性 |
通俗案例 |
|---|---|---|---|
|
开发期质量属性 |
软件开发阶段关注的特性 |
易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性 |
易理解性：新接手老项目的开发人员，1周就能理清核心逻辑，说明系统易理解性好 |
|
运行期质量属性 |
软件运行阶段关注的特性 |
性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性 |
可伸缩性：短视频平台用户从1亿涨到5亿，仅通过扩容服务器就维持了流畅体验，说明可伸缩性好 |
真题提示：该分类是单选基础题，直接选「开发期+运行期」即可。
2. 面向架构评估的6类核心质量属性
这部分是案例、论文的高频考点，需要掌握定义、衡量指标、设计策略和典型案例：
|
质量属性 |
核心要点 |
案例 |
|---|---|---|
|
性能 |
定义：系统对事件的响应能力，指标：响应时间、吞吐量；设计策略：优先级队列、并发机制、资源调度 |
医院挂号系统把急诊预约请求放入最高优先级队列，优先处理，就是性能优化的典型实践 |
|
可靠性 |
定义：系统抵御错误、持续运行的能力，指标：MTTF（平均失效等待时间）、MTBF（平均失效间隔时间），失效率恒定且修复快时二者几乎相等；设计策略：冗余、心跳检测 |
金融核心交易系统采用双活数据中心，一个中心故障后另一个秒级接管，就是提升可靠性的设计 |
|
可用性 |
定义：系统正常运行时间占总时间的比例，指标：故障间隔时间、故障恢复速度；设计策略：冗余、Ping/Echo机制 |
云服务器承诺99.99%可用性，即全年宕机时间不超过52分钟 |
|
安全性 |
分为4类：机密性（信息不泄露给未授权方）、完整性（信息不被非法篡改）、不可否认性（收发行为不可抵赖）、可控性（信息传播可被管控）；设计策略：入侵检测、身份认证、权限控制 |
微信聊天记录仅收发双方可见是机密性；转账后无法否认自己发起过交易，就是不可否认性 |
|
可修改性 |
包含4类：可维护性（修复缺陷的难易度）、可扩展性（新增功能的难易度）、结构重组（重构构件关系的难易度）、可移植性（跨环境迁移的难易度）；设计策略：接口-实现分离、抽象、信息隐藏 |
把支付模块的接口和具体实现分离，后续新增数字人民币支付方式仅需修改实现类，不影响其他模块，就是可修改性好的体现 |
|
互操作性 |
定义：与其他系统交换数据、调用服务的难易度 |
政务服务平台可以直接调取公安的身份信息、税务的纳税信息，无需用户重复提交材料，就是互操作性强的体现 |
真题提示：区分可靠性和可用性：可靠性关注「不出错」，可用性关注「出错了多久能恢复」。
3. 质量属性场景（精准描述质量需求的工具）
由6个要素组成，是论文中描述需求的核心工具：
|
要素 |
定义 |
淘宝新增直播功能的案例 |
|---|---|---|
|
刺激源 |
发起请求的实体 |
淘宝后端开发人员 |
|
刺激 |
触发的变更条件 |
需要新增直播带货功能 |
|
环境 |
场景发生的背景 |
系统处于日常运行态 |
|
制品 |
被修改的对象 |
淘宝APP后端服务 |
|
响应 |
系统采取的动作 |
快速定位修改点，完成开发测试并上线 |
|
响应度量 |
可量化的结果 |
本次修改耗时2人月，未影响其他现有功能 |
二、系统架构评估核心知识
1. 架构评估三大核心概念
|
概念 |
核心定义 |
案例 |
|---|---|---|
|
敏感点 |
实现一个特定质量属性时，构件需要具备的特性 |
要实现高安全性，加密模块必须具备高强度加密算法支持，这就是安全性的敏感点 |
|
权衡点 |
同时影响多个质量属性的特性，是多个敏感点的交集 |
提高加密等级会提升安全性，但会增加CPU开销降低性能，此时加密等级就是典型的权衡点 |
|
风险承担者（利益相关人） |
所有受架构影响的角色 |
架构师需要平衡业务方（要快速上线）、运维方（要系统稳定）、安全部门（要合规）的多方诉求 |
|
场景 |
风险承担者对系统交互的简短描述，用「刺激、环境、响应」三要素刻画 |
评估可修改性时，场景可描述为：「系统运行态下，开发人员要新增报表导出功能，3人月内完成上线且无副作用」 |
真题提示：题干中如果一个决策同时影响2个及以上质量属性，直接选「权衡点」。
2. 主流架构评估方法
|
方法 |
核心特点 |
案例 |
|---|---|---|
|
SAAM（基于场景的架构分析方法） |
最早的架构评估方法，核心聚焦可修改性 |
评估OA系统架构时，先梳理「新增请假审批流程」「修改考勤规则」等场景，逐一评估架构对这些场景的支持程度 |
|
ATAM（架构权衡分析方法） |
SAAM的升级版，核心关注性能、安全性、可修改性、可用性四大质量属性，用「效用树」做优先级排序 |
评估电商大促架构时，先通过效用树把「10万并发下响应<3秒」（性能）、「支付数据零泄露」（安全性）、「大促前可快速新增优惠券功能」（可修改性）、「故障30秒内自动恢复」（可用性）列为最高优先级场景，再逐一分析架构支持能力 |
|
CBAM（成本效益分析法） |
在ATAM基础上增加成本核算，按ROI（投资回报率）选择最优架构 |
评估发现两个优化方案：A投入100万提升20%性能，B投入80万提升15%性能+10%可用性，计算ROI后选择B更符合业务利益 |
真题提示：
① ATAM效用树的层级为：树根→质量属性→属性分类→质量属性场景（叶子节点）
② ATAM核心关注的四大属性是「性能、安全性、可修改性、可用性」，是单选必考题
其余SAEM、AHP等评估方法仅需了解，不做高频考点。
三、中间件技术核心考点
1. 基础定义与特点
中间件是处于操作系统和应用系统之间的系统级软件，作用是屏蔽底层异构环境（不同OS、数据库、网络）的差异，实现分布式系统的资源共享和协同工作。
核心特点：①不是单一软件，是一类产品；②不仅实现系统互连，更实现应用互操作；③核心优势是网络通信能力。
案例：Java应用要访问Oracle数据库，不需要自己写底层网络交互代码，只需要通过JDBC中间件即可完成操作。
2. 两大核心支持
|
支持类型 |
核心作用 |
案例 |
|---|---|---|
|
交互支持 |
协调分布式环境下组件间的通信，提供消息队列、RPC、ORB等机制，屏蔽底层网络细节 |
微服务之间通过RabbitMQ消息队列异步传输订单数据，无需关心TCP协议细节 |
|
公共服务 |
提供可复用的通用能力，如事务管理、安全服务、负载均衡、容错等 |
通过Redis实现分布式锁，通过Nginx实现流量负载均衡，都是中间件提供的公共服务 |
3. 常见中间件分类
|
分类 |
作用 |
典型案例 |
|---|---|---|
|
通信处理（消息）中间件 |
实现跨平台可靠数据传输 |
IBM MQSeries，金融系统跨行转账靠它保证数据不丢失 |
|
事务处理中间件 |
协调分布式事务的顺序、一致性和负载均衡 |
BEA Tuxedo，电商下单「减库存+扣余额」的分布式事务靠它保证原子性 |
|
数据存取中间件 |
统一不同数据库的访问接口 |
JDBC、ODBC，应用更换数据库时无需修改大量代码 |
|
Web服务中间件 |
提供Web应用的运行时容器 |
Tomcat、JBoss，Java Web应用都部署在这类中间件中运行 |
|
安全中间件 |
提升系统安全等级 |
SSL/TLS，浏览器地址栏的「小锁」就是它实现的传输加密 |
|
跨平台中间件 |
实现不同语言系统的互操作 |
CORBA，C++编写的后台服务和Java编写的客户端可以无缝交互 |
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
20
0- 0
已为社区贡献2条内容
所有评论(0)