软件系统属性包括功能属性和质量属性
- 功能属性：客户的需求，软件系统最基本的要求，正常软件开发流程识别即可。
- 质量属性：大多需要通过分析，才能识别到的需求。
质量属性
- 开发期质量属性
核心：这类属性和"软件开发、维护、测试"相关，影响开发效率和后期维护成本。
易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性
（助记：理扩重试维移）（谐音：李扩重试卫衣）
-
易理解性：开发人员、维护人员能快速理解系统结构、代码逻辑，降低沟通和维护成本（考点：架构设计的清晰性、代码注释规范）。
-
可扩展性：系统能方便地增加新功能、扩展业务场景（比如电商系统后期新增"直播带货"功能，无需重构整体架构，和可修改性、可变性关联）。
-
可重用性：系统的构件、模块能重复利用到其他项目或本项目的其他部分（对应咱们之前说的"体系结构级复用"，比如分层架构的通用接口可复用）。
-
可测试性：系统设计便于设计测试用例、开展自动化测试，能快速发现并定位bug（考点：模块化设计、接口标准化，案例题偶考"如何提升系统可测试性"）。
-
可维护性：系统出现故障后，能快速排查、修复，且修改后不影响其他模块（考点：模块化、松耦合，和可用性关联，可用性=可靠性+可维护性）。
-
可移植性：系统能在不同的硬件、操作系统、环境下正常运行（比如一套系统既能跑在Windows，也能跑在Linux，优化思路：跨平台语言、容器化Docker）。
- 运行期质量属性
核心：这类属性是用户能直接感受到的，也是架构设计的核心目标，每一个都要吃透优化思路，是如何提升某类运行期质量属性的重点：
性能、安全性、可靠性、可用性、互操作性、可伸缩性、鲁棒性
（助记：性能、安全、可靠、可用、鲁作伸）
-
性能：系统"快不快"，核心是响应速度、吞吐量、并发用户数（优化：缓存、负载均衡、异步处理、分库分表）。
-
安全性：系统"安不安全"，防止非法访问、数据泄露、恶意攻击（优化：加密、数字签名、防火墙、访问控制、权限管理）。
-
可靠性：系统"稳不稳"，软件系统在一定的时间内持续无故障运行的能力（考点：平均无故障时间MTTF，优化：容错技术、热备/冷备、故障转移）。
-
可用性：系统"能不能用"，软件系统在一定的时间内正常运行时间的占比（比如99.9%可用性，意味着每年故障时间不超过8.76小时，优化：故障自动恢复、定期备份、双机热备）。
-
互操作性：指本软件系统与其他系统交互数据和项目调用服务的难易程度。
-
可伸缩性：系统能根据业务量变化，灵活调整资源（比如高峰期并发增加，能快速扩容；低峰期缩容，优化思路：集群、弹性伸缩、云服务器）。
-
鲁棒性：系统遇到异常情况（比如输入错误、网络中断）时，能正常运行、不崩溃，具备容错能力（比如用户输入非法字符，系统不报错，而是给出提示，优化：异常捕获、边界值处理），也称健壮性或容错性。
面向架构评估的质量属性（架构评估必考，综合知识、案例题高频）
为了评价一个软件系统，特别是软件系统的架构，需要进行架构评估。在架构评估过程中，评估人员所关注的是系统的质量属性，评估方法所普遍关注的质量属性有以下几种：
性能、安全性、可靠性、可用性、互操作性、可修改性、功能性、可变性
核心：架构评估时，评估人员重点关注的属性，涵盖上述两类中的核心，无需重复记忆，重点记"评估时重点关注"这一前提，考试会问"架构评估中重点关注的质量属性有哪些"。
补充重点（易混淆点）：
-
互操作性：不同系统、不同平台之间能正常数据交换、接口调用（比如车载APP对接云端和汽车硬件，优化：标准接口REST API、通用协议HTTP/MQTT）。
-
可变性：是可修改性的子集，侧重"应对业务需求变化"，比如动态调整促销规则，无需重启服务器（优化：配置化设计、规则引擎）。
-
可修改性：是指能够快速地以较高的性价比对系统进行变更的能力。可修改性包括以下四个方面：可扩展性、可重用性、可维护性、可移植性
-
功能性：系统实现用户要求的所有功能（基础属性，架构评估中作为辅助，论文中可开篇提及"满足用户功能性需求，同时兼顾各类质量属性"）。
质量属性场景描述：6要素模板
案例题常考"描述某类质量属性的场景"
质量属性场景6要素：刺激源、刺激、环境、制品、响应、响应度量
- 刺激源：谁产生的刺激（用户、系统、外部系统等）
- 刺激：发生了什么（并发访问、故障、攻击、修改请求等）
- 环境：系统处于什么状态（正常运行、高负载、故障恢复等）
- 制品：被影响的部分（整个系统、某个模块、接口、数据库等）
- 响应：系统如何处理（处理请求、故障转移、拒绝服务、修改完成等）
- 响应度量：可量化指标（响应时间≤200ms、可用性 99.9%、修改耗时≤2 人天）
补充说明：质量属性场景是一种面向特定质量属性的需求，主要关注性能、安全性、可用性、可修改性、可测试性、易用性等6类质量属性。
举例（性能场景，贴合考试）：刺激源（用户）、刺激（1000人并发访问系统）、环境（网络正常、服务器负载50%）、制品（系统接口）、响应（系统处理请求并返回结果）、响应度量（响应时间≤1秒）。
具体举例6个属性：
| 质量属性 | 刺激源 | 刺激 | 环境 | 制品 | 响应 | 响应度量（可量化） |
|---|---|---|---|---|---|---|
| 性能 | 外部用户 | 发起高并发查询请求 | 系统处于业务高峰期 | 商品列表查询接口 | 系统处理请求并返回数据 | 平均响应时间不超过 500ms |
| 安全性 | 恶意攻击者 | 尝试进行 SQL 注入攻击 | 系统对外提供互联网服务 | 用户登录认证模块 | 系统拦截攻击并记录安全日志 | 恶意请求拦截成功率达到 100% |
| 可用性 | 应用服务器节点 | 发生硬件宕机故障 | 系统正常对外提供服务 | 核心业务集群系统 | 集群自动剔除故障节点，流量切换至健康节点 | 服务中断时间不超过 10 秒 |
| 可修改性 | 开发维护人员 | 提出修改业务规则需求 | 系统处于版本迭代维护期 | 订单结算核心模块 | 通过配置文件或扩展点完成逻辑修改 | 修改及回归测试总工作量不超过 3 人·天 |
| 可测试性 | 测试工程师 | 执行接口自动化测试用例 | 系统部署在独立测试环境 | 支付网关服务模块 | 模块提供 Mock 接口及日志埋点，支持用例执行 | 测试用例执行通过率 ≥ 95%，问题定位时间 ≤ 1 小时 |
| 易用性 | 首次使用的普通用户 | 执行订单提交操作 | 用户使用 PC 端浏览器访问 | 电商平台前端交互系统 | 系统提供清晰引导及操作提示 | 用户完成操作平均步骤 ≤ 3 步 |
敏感点与权衡点：
-
敏感点：一个点，改了它，某类质量属性就会明显变化（比如缓存大小，改大了性能提升，改小了性能下降；再比如接口设计，改了接口会影响互操作性）。
-
权衡点：两个及以上质量属性的"取舍"（比如追求性能，可能要牺牲可修改性；追求安全性，可能要牺牲性能；追求可用性，可能要增加成本），案例题常考"权衡某两个质量属性的方案"。
总结
| 场合 | 关注的质量属性 | 特点 |
|---|---|---|
| 开发期质量属性 | 易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性（谐音：李扩重试卫衣） | 软件开发、维护、测试相关 |
| 运行期质量属性 | 性能、安全性、可靠性、可用性、互操作性、可伸缩性、鲁棒性（助记：性能、安全、可靠、可用、鲁作伸，7个） | 用户能感受到的体验 |
| 面向架构评估的质量属性 | 性能、安全性、可靠性、可用性、互操作性、可修改性、功能性、可变性（助记：性能、安全、可靠、可用、作变修功，8个） | 评估架构是否合理，能否支撑业务 |
| 场景描述关注的质量属性 | 性能、安全性、可用性、可修改性、可测试性、易用性（助记：性能、安全、可用、修测易用，6个） | 可统一模板、可量化 |
疑问：为什么不同场景，质量属性个数不一样？
- 运行期质量属性（7个）：关注"系统跑起来后，用户能感受到的所有关键属性"
核心逻辑：运行期是系统交付后，用户实际使用的阶段，所以要覆盖"快、稳、安、好用"等所有和"运行体验"相关的属性（性能、安全性、可伸缩性等7个），缺一不可------比如用户用系统，既关心响应快不快（性能），也关心会不会崩（鲁棒性），这些都要包含。 - 面向架构评估的质量属性（8个）：关注"评估架构好不好，需要看的核心属性"
核心逻辑：架构评估的目的是判断"这个架构设计是否合理、能否支撑业务"，所以会筛选出"对架构设计影响最大"的8个属性------比如增加"功能性"（架构要先支撑核心功能）、"可变性"（架构要能应对业务变化）、"互操作性"（架构要能和其他系统对接），而运行期的"可操作性""鲁棒性""可伸缩性"，更多是后期运维、开发的细节，不是架构评估的核心，所以不纳入。 - 质量属性场景描述（6个）：关注"能通过场景清晰描述、易量化的属性"
核心逻辑：质量属性场景需要用"刺激源、响应、响应度量"等6要素量化（比如性能场景"响应时间≤1秒"），有些属性很难量化描述，就不纳入。比如运行期的"可操作性"（好不好用太主观）、"鲁棒性"（异常情况太多，难统一量化），面向架构评估的"功能性"（侧重是否实现，无需场景量化）、"可变性"（变化场景太灵活，难统一模板），所以只保留6个易量化、案例题常考的属性（可用性、可修改性等）。