主题
软件架构评估
质量属性（⭐⭐⭐⭐⭐）
软件系统属性包括功能属性和质量属性，软件架构重点关注质量属性。
软件系统质量属性是一个系统的可测量或可测试的属性，用来描述系统满足利益相关者需求的程度。
根据软件系统生命周期，可将质量属性划分为：开发期质量属性和运行期质量属性。
开发期质量属性：
- 易理解性：指设计被开发人员理解的难易程度。
- 可扩展性：软件因适应新需求或需求变化而增加新功能的能力。
- 可重用性：重用软件系统或某一部分的难易程度。
- 可测试性：对软件测试以证明其满足需求规范的难易程度。
- 可维护性：修改缺陷、增加功能、提高质量属性时，识别修改点并修改的难易程度。
- 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
运行期质量属性：
- 性能：软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
- 安全性：软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
- 可伸缩性：用户数和数据量增加时，软件系统维持高服务质量的能力。例如通过增加服务器来提高能力。
- 互操作性：本软件系统与其他系统交换数据和相互调用服务的难易程度。
- 可靠性：软件系统一定时间内持续无故障运行的能力。
- 可用性：系统在一定时间内正常工作时间所占的比例。可用性会受到系统错误、恶意攻击、高负载等问题的影响。
- 鲁棒性【健壮性、容错性】：软件系统在非正常情况（非法操作、软硬件故障等）下仍能正常运行的能力。
性能
性能（Performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所处理的事件的个数。
例子：
- 同时支持1000并发。
- 响应时间小于1s。
- 显示分辨率达到4K。
- 资源需求：核心是减少完成单个任务所需的计算资源量。如计算优化、数据压缩、CDN等。
- 资源管理：核心是高效分配、复用和调度已有资源，以提高资源利用率。比如资源池化、利用CPU多核、弹性伸缩等。
- 资源仲裁：核心是当资源发生竞争或不足时，按照既定策略决定谁先谁后、谁得谁失，以保证系统关键功能的性能或整体稳定性。如调度算法、限流与降级、负载均衡等。
可用性
可用性（Availability）是系统能正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
示例：
- 主服务故障，1分钟内切换至备用服务器。
- 系统故障，1小时内修复。
- 系统支持7x24小时工作。
可修改性
可修改性（Modifiability）是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价来衡量可修改性。
示例：
- 更改系统报表模块，必须在2周内完成。
- 对web界面风格进行修改，修改必须在4个月内完成。
安全性
安全性（Security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。可划分为：
- 机密性：信息不泄露给未授权的用户。
- 完整性：防止信息被篡改。
- 不可否认性：不可抵赖。
- 可控性：对信息的传播及内容具有控制的能力。
示例：
- 可抵御SQL注入攻击。
- 对计算机的操作都有完整记录。
- 用户信息数据库授权必须保证99.99%可用。
易用性
易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。
示例：
- 界面友好。
- 新用户学习使用系统时间不超过2小时。
可测试性
软件可测试性是指通过测试揭示软件缺陷的容易程度。
示例：
- 提供远程调试接口。
- 支持远程调试。
架构评估（⭐⭐⭐⭐⭐）
重要概念
- 敏感点：是一个或多个构件（和/或构件之间的关系）的特性，它能影响系统的某个质量属性。
- 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。影响的质量属性存在负相关性，如安全和性能，安全性高性能就降低，因此需要权衡。
- 风险点：指架构设计中潜在的、存在问题的架构决策所带来的隐患。
- 非风险点：指不会带来隐患，一般以“xxx要求是可以实现（或接受）的”方式表达。
示例：
- 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计。
- 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的。
- 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性。
- 更改加密级别将对安全性和性能产生影响。
点我查看答案
1-敏感点；2-非风险点；3-风险点；4-权衡点。
评估方法
分类
- 基于调查问卷或检查表的方式
- 基于度量的方式
- 基于场景的方式
质量属性场景描述
场景是从风险承担者的角度与系统交互的简短描述。
质量属性场景由6部分组成：
- 刺激源：生成刺激的实体（如人、计算机或者任何其它刺激器）。
- 刺激：刺激源产生的具体事件或条件。
- 制品：刺激的目标（可以是整个系统，也可以是系统的一部分）。
- 环境：刺激发生时所要求的上下文或条件。比如当刺激发生时，系统要处于运行时状态。
- 响应：刺激到达后所采取的行动。
- 响应度量：对响应进行量化，以对需求进行测试。
可用性质量属性场景描述
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 系统内部、系统外部 |
| 刺激 | 疏忽、错误、崩溃、时间 |
| 环境 | 正常操作、降级模式 |
| 制品 | 系统处理器、通信信道、持久存储器、进程 |
| 响应 | 系统应该检测时间并进行如下一个或多个活动： 将其记录下来通知适当的各方，包括用户和其他系统； 根据已定义的规则禁止导致错误或故障的事件源； 在一段预先指定的时间间隔内不可用，其中时间间隔取决于系统的关键程度在正常或 降级模式下运行 |
| 响应度量 | 系统必须可用的时间间隔、可用时间、 系统可以在降级模式下运行的时间间隔、故障修复时间 |
例如：系统能够连续运行的时间不小于1000小时，闪退后能够在15s内自动重启。
可修改性质量属性场景描述
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 最终用户、开发人员、系统管理员 |
| 刺激 | 希望增加、删除、修改、改变功能、质量属性、容量等 |
| 环境 | 系统设计时、编译时、构建时、运行时 |
| 制品 | 系统用户界面、平台、环境或与目标系统交互的系统 |
| 响应 | 查找架构中需要修改的位置，进行修改且不会影响其它功能， 对所做的修改进行测试部署所做的修改 |
| 响应度量 | 根据所影响元素的数量度量的成本、资金； 该修改对其它功能或质量属性所造成影响的程度 |
例如：更改Web界面接口必须在2周内完成。
性能质量属性场景描述
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 用户请求、其它系统触发等 |
| 刺激 | 定期事件到达、随机事件到达、偶然事件达到 |
| 环境 | 正常模式、超载模式 |
| 制品 | 系统 |
| 响应 | 处理刺激、改变服务级别 |
| 响应度量 | 等待事件、期限、吞吐量、抖动、缺失率、数据丢失率 |
例如：正常负载情况下，系统必须在0.5s内对用户的交易请求进行响应。
可测试性质量属性场景描述
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户 |
| 刺激 | 已完成的分析、架构、设计、类和子系统集成；所交付的系统 |
| 环境 | 设计时、开发时、编译时、部署时 |
| 制品 | 设计、代码段、完整的应用 |
| 响应 | 提供对状态值的访问，提供所计算的值，准备测试环境 |
| 响应度量 | 已执行的可执行语句的百分比、如果存在缺陷出现故障的概率、 执行测试的时间、测试中最长依赖的长度、准备测试环境的时间 |
例如：测试人员在开发期间针对一个代码单元，执行一个测试序列，获取结果，并在20分钟内完成测试。
易用性质量属性场景描述
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 最终用户 |
| 刺激 | 想要学习的系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意 |
| 环境 | 系统运行时或配置时 |
| 制品 | 系统 |
| 响应 | 1. 系统提供以下一个或多个响应来支持“学习系统特性”：帮助系统与环境联系紧密界面为用户所熟悉；在不熟悉的环境中，界面是可以使用的。 2. 系统提供以下一个或多个响应来支持“有效使用系统”：数据和（或）命令的聚合；已输入的数据和（或）命令的重用；支持在界面中的有效导航；具有一致操作的不同视图；全面搜索；多个同时进行的活动。 3. 系统提供以下一个或多个响应来支持“使错误的影响最低”：撤销；取消；从系统故障中恢复；识别并纠正用户错误；检索忘记的密码；验证系统资源。 4. 系统提供以下一个或多个响应来支持“适配系统”：定制能力；国际化。 5. 系统提供以下一个或多个响应来支持客户“对系统的满意”：显示系统状态；与客户的节奏合拍 |
| 响应度量 | 任务时间、错误数量、解决问题的数量、用户满意度、用户知识的获取、成功操作在总操作中所占的比例、损失的时间/丢失的数据量 |
例如：新用户学习使用系统时间不超过2小时。
安全性质量属性场景描述
| 场景要素 | 可能的情况 |
|---|---|
| 刺激源 | 正确识别、非正确识别身份位置的来自内部/外部的个人或系统； 经过了授权/未授权后访问了有限的资源/大量资源 |
| 刺激 | 试图显示数据、修改/删除数据、访问系统服务、降低系统服务的可用性 |
| 环境 | 在线或离线、联网或断网、连接有防火墙或者直接连到了网络 |
| 制品 | 系统服务、系统中的数据 |
| 响应 | 对用户身份进行认证；隐藏用户身份；阻止对数据或服务的访问；允许访问数据或服务； 授予或收回对访问数据或服务的许可； 根据身份记录访问、修改或试图访问修改数据、服务； 以一种不可读的格式存储数据； 识别无法解释的对服务的高需求通知用户或另一个系统，并限制服务的可用性 |
| 响应度量 | 用成功的概率表示，避开安全防范措施所需要的时间、资源；检测到攻击的可能性； 确定攻击或访问、修改数据或服务的个人的可能性； 在拒绝服务攻击的情况下仍然获得服务的百分比； 恢复数据、服务；被破坏的数据、服务和（或）被拒绝的合法访问的范围 |
例如：信用卡支付必须保证99.999%的安全性。
基于场景的评估方法
SAAM
软件架构分析法：最初关注可修改性，后扩充到可移植性、可扩充性等。
ATAM
架构权衡分析法：由SAAM发展而来，主要针对：性能、可用性、可修改性、安全性，在系统开发之前，对这些质量属性进行评价和折中。
ATAM被分为4个主要的活动阶段（领域）： 
质量属性树
ATAM使用质量属性树来对质量属性进行分类和优先级排序。
属性树的结构：树根 => 质量属性 => 属性分类 => 质量属性场景（叶子节点）。
得到初始的属性树之后，需要对其进行修剪，保留重要场景（通常不超过50个），再对场景按重要性给定优先级（用H/M/L的形式），再按场景实现的难易度来确定优先级（用H/M/L的形式），这样对所选定的每个场景就有一个优先级对（重要程度、难易程度）。如：（H, L）表示该场景重要且易实现。
ATAM评估架构的步骤
- 描述和介绍阶段
- 介绍ATAM方法
- 描述商业目标：主要利益相关者包括最终用户、架构师和应用程序开发人员。
- 描述体系结构：侧重于架构、时间可用性以及架构的质量要求。关键问题包括技术约束以及与当前系统交互的其它系统。
- 调查和分析阶段
标识体系结构步骤
产生质量属性树
分析体系结构步骤：
（1）调查架构方法；
（2）创建分析问题；
（3）分析问题的答案；
（4）找出风险点、非风险点、敏感点和权衡点。
- 测试阶段
讨论质量需求的次序
使用头脑风暴的三种场景:
（1）用例场景：利益相关者是最终用户。
（2）增长情景：代表了架构发展的方式。
（3）探索性场景：代表架构中极端的增长形式。
分析体系结构步骤
- 报告阶段
- 提交结果
CBAM
成本效益分析法：在ATAM基础上建立软件的“经济”模型。