 - 运行期质量属性)
运行期质量属性
- 核心定义：指在软件运行阶段所关注的质量属性。
- 主要内容：运行期质量属性主要包含以下七个方面：
| 属性 | 核心定义与说明 |
|---|---|
| 性能 | 软件系统及时提供相应服务的能力。包括对速度、吞吐量和容量等指标的要求。 |
| 安全性 | 软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。 |
| 可伸缩性 (可扩展性) | 当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提升系统处理能力。 |
| 互操作性 | 本软件系统与其他系统交换数据和相互调用服务的难易程度。 |
| 可靠性 | 软件系统在一定的时间内持续无故障运行的能力。 |
| 可用性 | 系统在一定时间内正常工作的时间所占的比例。会受到系统错误、恶意攻击、高负载等问题的影响。 |
| 鲁棒性 (健壮性/容错性) | 软件系统在非正常情况下（如用户进行了非法操作、相关的软硬件系统发生了故障等）仍能够正常运行的能力。 |
总结：运行期质量属性关注软件在生产环境中的行为表现。它们共同决定了系统在面对真实用户、数据和复杂环境时的稳定性、效率和安全水平，是终端用户最能直接感知到的软件质量维度。
12.1.2 面向架构评估的质量属性
在软件架构评估过程中，通常关注以下八种核心质量属性。
| 属性 | 核心定义 | 关键要点与细分 |
|---|---|---|
| (1) 性能 | 指系统的响应能力。即要经过多长时间才能对某个事件做出响应，或者在某个时间段内系统所能处理的事件个数。 | 衡量指标：响应时间、吞吐量。 设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。 |
| (2) 可靠性 | 是软件系统在应用或系统错误面前，在意外或错误使用的情况下，维持其功能特性的基本能力。 | 衡量指标：平均失效等待时间（MTTF）、平均失效间隔时间（MTBF）。在失效率为常数和修复时间很短的情况下，两者几乎相等。 两个层面： •容错：错误发生时确保系统行为正确，并进行内部“修复”。 •健壮性：使系统不受错误使用和错误输入的影响，能按既定程序忽略错误。 设计策略：冗余、心跳、选举、Ping/Echo。 |
| (3) 可用性 | 是系统能够正常运行的时间比例。经常用两次故障之间的时间长度，或在出现故障时系统能够恢复正常的速度来表示。 | 衡量指标：如故障间隔时间。 设计策略：冗余、心跳、选举、Ping/Echo。 |
| (4) 安全性 | 是指系统在向合法用户提供服务的同时，能够阻止非授权用户使用的企图或拒绝服务的能力。 | 可细分为： •机密性：保证信息不泄露给未授权的用户、实体或过程。 •完整性：保证信息的完整和准确，防止信息被非法修改。 •不可否认性：信息交换的双方不能否认其在交换过程中发送或接收信息的行为。 •可控性：保证对信息的传播及内容具有控制的能力，防止为非法者所用。 设计策略：入侵检测、用户认证、用户授权、追踪审计。 |
| (5) 可修改性 | 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量。 | 可细分为： •可维护性：在错误发生后“修复”软件系统的难易程度。 •可扩展性：软件为适应新需求或需求变化而增加新功能的能力。 •结构重组：重新组织软件系统的构件及构件之间的关系的难易程度。 •可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。 设计策略：接口-实现分离、抽象、信息隐藏。 |
| (6) 功能性 | 是系统所能完成所期望的工作的能力。 | 核心：一项任务的完成需要系统中许多或大多数构件的相互协作。 |
| (7) 可变性 | 指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。 | 应用场景：当要将某个架构作为一系列相关产品的基础时，可变性很重要。 |
| (8) 互操作性 | 作为系统组成部分的软件通常需要与其他系统或自身环境相互作用。 | 核心要求：为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。 典型问题：程序和用其他编程语言编写的软件系统的交互作用就是互操作性问题，这种互操作性也影响应用的软件架构。 |
12.1.3 质量属性场景描述
1. 概念引入
为了精确描述软件系统的质量属性，通常采用质量属性场景 (Quality Attribute Scenario)作为描述和定义质量需求的具体手段。它是一种面向特定质量属性的、结构化的需求描述方式。
2. 质量属性场景的六个组成部分
一个完整的质量属性场景由以下六个部分构成，它们共同定义了一个具体的、可评估的质量需求实例。
| 组成部分 | 核心定义 |
|---|---|
| 刺激源 (Source) | 产生该刺激的实体，可以是人、计算机系统或任何其他刺激器。 |
| 刺激 (Stimulus) | 当刺激到达系统时，所需考虑的具体条件或事件。 |
| 环境 (Environment) | 刺激发生时，系统所处的特定条件（如正常运行、过载、维护等）。 |
| 制品 (Artifact) | 被刺激的对象，可能是整个系统，也可能是系统的某个特定部分。 |
| 响应 (Response) | 刺激到达后，系统（或制品）所必须采取的行动。 |
| 响应度量 (Response Measure) | 用于对响应进行度量的具体指标，以便对该需求进行验证和测试。 |
3. 实例：可修改性质量属性场景（以淘宝APP为例）
以下以“淘宝APP功能更新”为例，展示一个可修改性质量属性场景的具体应用。
| 场景组成部分 | 对应实例描述 |
|---|---|
| 刺激源 | 淘宝APP的开发团队（开发人员修改代码）。 |
| 刺激 | 淘宝APP需要进行版本更新，以增加新功能或修复已知问题。 |
| 环境 | APP运行平台（如iOS、Android的应用商店发布环境）。 |
| 制品 | 新版本的淘宝APP安装包。 |
| 响应 | 成功发布新版本，增添了计划中的功能或修复了特定的BUG。 |
| 响应度量 | 用户可以观察到：过去的某个BUG已消失，或者应用中出现了承诺的新功能。 |
总结：质量属性场景通过刺激-响应模型，将抽象的质量属性（如可修改性、性能、安全性等）转化为包含具体角色、条件、对象、行动和验收标准的实例。这种描述方法使质量需求变得具体、可评估、可测试，是架构设计与评估的重要沟通与验证工具。
12.1.3 质量属性场景描述 - 可修改性场景实例
可修改性质量属性场景描述实例
下表展示了一个完整的、用于描述“可修改性”质量属性的通用场景模板。它通过定义场景的六个要素及其可能的具体情况，为评估系统的可修改性提供了清晰的分析框架。
| 场景要素 | 可能的情况 / 描述 |
|---|---|
| 刺激源 | 最终用户、开发人员、系统管理员 |
| 刺激 | 希望增加、删除、修改、改变功能、质量属性、容量等 |
| 环境 | 系统设计时、编译时、构建时、运行时 |
| 制品 | 系统用户界面、平台、环境或与目标系统交互的系统 |
| 响应 | 查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改 |
| 响应度量 | 根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度 |
实例应用说明：
- 此模板定义了评估系统“可修改性”时需考虑的核心维度。
- 在实际分析中，可根据具体变更需求（刺激），选择或组合“可能的情况”来构建一个具体的评估场景。
- 例如，当“开发人员”（刺激源）在“编译时”（环境）希望“增加一个新功能”（刺激）时，评估其“响应”（如定位、修改、测试的难易程度）和“响应度量”（如修改所影响的代码模块数、所需人天）即可形成一个具体的可修改性评估用例。
12.1.3 质量属性场景描述
质量属性场景主要用于描述和定义系统的特定质量需求。它主要关注以下六类质量属性，并明确了每类属性在场景描述中需要考察的核心方面。
| 质量属性 | 场景主要关注点 |
|---|---|
| 可用性 | 系统故障发生的频率、故障发生时的表现、允许系统非正常运行的时间长度、何时可以安全地出现故障、如何防止故障发生以及故障发生时的通知要求。 |
| 可修改性 | 系统在改变功能、质量属性时需要付出的成本和难度。此类场景可能发生在系统设计、编译、构建、运行等多种情况和环境下。 |
| 性能 | 系统的响应速度，可通过效率、响应时间、吞吐量、负载等指标客观评价性能的好坏。 |
| 可测试性 | 系统测试过程中的效率，以及发现系统缺陷或故障的难易程度。 |
| 易用性 | 用户使用系统时的容易程度，包括系统的学习曲线、完成操作的效率、用户对使用过程的满意程度等。 |
| 安全性 | 系统在向合法用户提供服务的同时，阻止非授权用户使用的能力。 |
总结：质量属性场景是一种结构化的需求描述方法，它将抽象的、非功能性的质量要求（如“系统要可靠”、“界面要友好”）转化为针对具体属性、包含明确关注点的、可评估和验证的具体场景，从而为架构设计和测试提供明确的依据。
12.2 系统架构评估
12.2.1 系统架构评估中的重要概念
1. 系统架构评估定义
系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策的过程。
2. 三个核心概念
(1) 敏感点与权衡点
- 核心定义：是关键的架构决策。
- 敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
- 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
- 典型示例 (加密级别)：
- 提高加密级别可以提高安全性，但可能需要耗费更多的处理时间，从而影响性能。
- 如果对机密消息的处理有严格的时间延迟要求，则加密级别就可能成为一个权衡点。
(2) 风险承担者 (利益相关人)
- 核心定义：系统的架构涉及很多人的利益，这些人都对架构施加各种影响，以保证自己的目标能够实现。
- 核心角色 - 软件系统架构师：
- 是风险承担者之一。
- 职责是负责在软件架构的质量需求间进行权衡。
- 所关心的问题是对其他风险承担者提出的质量需求进行折中和调停。
(3) 场景
- 核心作用：在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。
- 核心描述：
- 是从风险承担者的角度，对与系统的交互所做的简短描述。
- 在架构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。
总结：理解敏感点/权衡点有助于识别关键设计决策；明确风险承担者及其目标（特别是架构师的调和角色）是评估的社会维度；运用场景则是将抽象的质量目标具体化、可评估化的核心方法。三者共同构成了进行有效架构评估的基础认知框架。
12.2.1 系统架构评估中的重要概念
1. 评估的时间点与目的
- 时间点：系统架构评估通常位于架构设计之后，系统设计之前。
- 关联性：因此，它与后续的设计、实现、测试阶段没有直接关系。
- 核心目的：评估所采用的架构是否足以解决软件系统的需求。
2. 系统架构评估的三种方法
| 评估方法 | 核心特点与描述 | 关键要素/备注 |
|---|---|---|
| (1) 基于调查问卷或检查表的方法 | 类似于需求获取中的问卷调查，但侧重于架构方面。 | 要求：评估人员必须对评估的领域非常熟悉。 |
| (2) 基于场景的评估方法 | 主要方法。通过分析架构对特定场景（使用或修改活动）的支持程度，来判断其对质量需求的满足度。 | 场景设计三要素： 1.刺激（事件） 2.环境（事件发生条件） 3.响应（架构应对过程） 应用：ATAM（架构权衡分析方法）、SAAM（软件架构分析方法）。 |
| (3) 基于度量的评估方法 | 制定定量指标（如代码行数）来直接度量架构。 | 核心活动： 1. 建立质量属性与度量间的映射原则； 2. 从文档中获取度量信息； 3. 分析推导出系统质量属性。 要求：评估人员需对架构熟悉。 |
12.2.2 系统架构评估方法
1. 基于场景的架构分析方法 SAAM
SAAM (Software Architecture Analysis Method) 是一种针对非功能质量属性的架构分析方法，是最早形成文档并得到广泛使用的软件架构分析方法。
(1) 特定目标
对描述应用程序属性的文档进行审查，以验证基本的架构假设和原则。
(2) 评估技术
- 采用的核心技术是场景技术。
- 场景代表了描述架构属性的基础，详细描述了各种系统必须支持的活动和可能存在的状态变化。
(3) 质量属性
- 该方法的基本特点是把任何形式的质量属性都具体化为场景。
- 可修改性是 SAAM 分析的主要质量属性（核心关注点）。
(4) 风险承担者
- SAAM 旨在协调不同参与者（风险承担者）之间感兴趣的共同方面。
- 作为后续架构决策的基础，以达成对架构的共识。
(5) 架构描述
- 时间点：SAAM 通常在架构的最后版本确定后使用，但早于详细设计阶段。
- 形式要求：架构的描述形式应当被所有参与者理解。
- 描述维度：架构的功能、结构和分配被定义为描述架构的 3 个主要方面。
(6) 方法活动
- 主要输入：问题描述、需求声明和架构描述。
- 分析流程：SAAM 分析评估架构的过程包括以下 5 个步骤：
- 场景开发
- 架构描述
- 单个场景评估
- 场景交互评估
- 总体评估
- 逻辑关系：
- “场景开发”通过迭代生成“体系结构描述”。
- “单个场景评估”与“场景交互评估”通过逻辑或（OR）汇聚为“单个体系结构评估”。
- 结合比较多个体系结构的需求，最终输出“总体评估”。
(7) 已有知识库的可重用性
- SAAM不考虑这个问题。
(8) 方法验证
- SAAM 是一种成熟的方法，已被广泛应用到众多系统中，包括但不限于：
- 空中交通管制系统
- 嵌入式音频系统
- WRCS（修正控制系统）
- KWIC（根据上下文查找关键词系统）
12.2.2 系统架构评估方法
2. 架构权衡分析方法 ATAM
ATAM (Architecture Tradeoff Analysis Method) 是在 SAAM 的基础上发展起来的，主要针对性能、安全性、可修改性和可用性，在系统开发之前，对这些质量属性进行评价和折中。
核心目标与参与者
- 核心目标：让架构师明确如何权衡多个质量目标。
- 主要参与者：评估小组、项目决策者和其他项目相关人。
四大活动领域
ATAM 被分为四个主要的活动领域，整个评估过程强调以质量属性作为架构评估的核心：
- 场景和需求收集
- 体系结构视图和场景实现
- 属性模型构造和分析
- 折中
ATAM 分析评估过程（九步法）
ATAM 的评估过程通常分为四个阶段，共包含九个具体步骤：
阶段1：场景和需求收集
- 收集场景
- 收集需求约束环境
阶段2：体系结构视图和场景实现
3. 描述体系结构视图
4. 实现场景阶段3：属性模型构造和分析
5. 特定属性分析（优秀的分析理论）阶段4：折中
6. 标志敏感度
7. 标志折中
8. 产生分析最终输出
- 形成行动计划
12.2.2 系统架构评估方法
2. 架构权衡分析方法 ATAM（续）
补充：ATAM 方法的评估实践阶段划分
用 ATAM 方法评估软件架构，其工作分为 4 个基本阶段，即演示、调查和分析、测试和报告。
(1) 阶段1：演示（Presentation）
这是使用 ATAM 评估软件体系结构的初始阶段。
- ① 介绍 ATAM：描述 ATAM 的评估过程。
- ② 介绍业务驱动因素：着重业务视角，提供有关系统功能、主要利益相关方、业务目标和其他限制等信息。
- ③ 介绍要评估的体系结构：侧重可用性以及体系结构的质量要求。
(2) 阶段2：调查和分析（Investigation and Analysis）
在这个阶段，人们对评估期间需要重点关注的一些关键问题进行彻底调查。
- ① 确定架构方法：涉及能够理解系统关键需求的关键架构方法。
- ② 生成质量属性效用树：确定最重要的质量属性，并确定有限次序。
- ③ 分析体系结构方法：
- 彻底调查和分析，找出处理相应质量属性架构的方法。
- 包括4个主要阶段：调查架构方法 -> 创建分析问题 -> 分析问题的答案 -> 找出风险、非风险、敏感点和权衡点。
(3) 阶段3：测试
- ① 头脑风暴和优先场景：将头脑风暴的优先列表与生成质量属性效用树中所获取的优先方案进行比较。
- ② 分析架构方法。
(4) 阶段4：报告 ATAM
- 提供评估期间收集的所有信息，呈现给利益相关者。
12.2.2 系统架构评估方法
质量属性效用树 (Utility Tree)
ATAM 方法采用效用树（Utility tree）这一工具来对质量属性进行分类和优先级排序。
效用树的结构：
- 树根：质量属性
- 下一层：属性分类
- 叶子节点：质量属性场景
ATAM 主要关注的质量属性：
ATAM 主要关注以下 4 类质量属性，因为这 4 个质量属性是利益相关者最为关心的：- 性能 (Performance)
- 安全性 (Security)
- 可修改性 (Modifiability)
- 可用性 (Usability)
12.2.2 系统架构评估方法
3. 成本效益分析法 CBAM
基本概念
- 全称：Cost-Benefit Analysis Method。
- 基础：在 ATAM 的基础上构建。
- 核心目的：对架构设计决策的成本和收益进行建模，让决策者根据投资回报率 (ROI)来选择合适的架构。
- 应用时机：在 ATAM 确定质量合理的基础上，再对效益进行分析。
分析流程（8个步骤）
整理场景
- 确定场景，并确定优先级。
- 选择优先级最高的1/3场景进行分析。
对场景进行细化
- 对每个场景进行详细分析。
- 确定最好、最坏的情况。
确定场景的优先级
- 项目干系人对场景投票。
- 根据投票结果生成场景的权值。
分配效用
- 对场景响应级别确定效用表。
- 建立策略、场景、响应级别的表格。
形成“策略-场景-响应级别”的对应关系
使用内插法确定期望的质量属性响应级别的效用
- 根据效用表确定所对应的具体场景的效用表。
计算各架构策略的总收益
根据受成本限制影响的投资回报率 ROI 选择架构策略
- 估算成本。
- 用上一步的收益减去成本，计算 ROI 并排序。
- 从而选择收益最高的架构策略。
中间件
1. 定义
中间件是指在一个分布式系统环境中处于操作系统和应用程序之间的系统级软件。它可以在不同的技术之间共享资源，将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。
2. 位置与特点
中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通信。
- (1) 软件类别：中间件是一类软件，而非一种软件。
- (2) 核心功能：不仅仅实现互连，还要实现应用之间的互操作。
- (3) 架构特性：基于分布式处理的软件，最突出的特点是其网络通信功能。
3. 任务
中间件的任务是使应用程序开发变得更容易，通过提供统一的程序抽象，隐藏异构系统和分布式系统下低级别编程的复杂度。
4. 架构图示
- 分层结构：
- 顶层：应用（...）
- 中间层：中间件（分布式系统服务）
- 底层：操作系统（...）、网络、数据库
5. 支持的两方面内容
中间件提供的支持通常包括两方面：
(1) 交互支持
- 作用：协调系统中不同组件之间的通信和数据交换。
- 机制：
- 消息队列
- 远程过程调用（RPC）
- 对象请求代理（ORB）
- 目的：实现分布式环境中的进程间通信（IPC）。
- 优势：使得应用程序不必关心底层网络细节，能够更专注于业务逻辑。
(2) 提供公共服务
- 服务内容：中间件提供对服务的可复用的实现，如：
- 事务管理
- 安全服务
- 命名和目录服务
- 持久化服务
- 负载均衡
- 故障恢复和容错能力等。
- 解决问题：有助于解决分布式系统中常见的问题，如一致性、可用性和伸缩性。
中间件
中间件的功能
负责连接与通信：
- 负责客户机与服务器之间的连接和通信。
- 负责客户机与应用层之间的高效率通信机制。
提供互操作与控制机制：
- 提供应用层不同服务之间的互操作机制。
- 提供应用层与数据库之间的连接和控制机制。
提供开发与运行平台：
- 提供多层架构的应用开发和运行的平台。
- 提供应用开发框架，支持模块化的应用开发。
屏蔽底层差异：
- 屏蔽硬件、操作系统、网络和数据库的差异。
提供高级管理与安全功能：
- 提供应用的负载均衡和高可用性。
- 提供安全机制与管理功能。
- 提供交易管理机制，保证交易的一致性。
提供通用服务：
- 提供一组通用的服务去执行不同的功能。
- 避免重复的工作，使应用之间可以协作。
中间件
中间件的分类
通信处理（消息）中间件
- 功能：保证系统能在不同平台之间通信，利用消息传递机制实现分布式系统中可靠的、高效的、实时的跨平台数据传输。
- 示例：IBM 的 MQSeries。
事务处理（交易）中间件
- 功能：实现协调处理顺序、监视和调度、负载均衡等功能。
- 示例：BEA 的 Tuxedo。
数据存取管理中间件
- 功能：为不同种类数据的读写和加解密提供统一的接口。
- 示例：Windows 平台的 ODBC 和 Java 平台的 JDBC 等。
Web 服务器中间件
- 功能：提供 Web 程序执行的运行时容器。
- 示例：Tomcat、JBOSS 等。
安全中间件
- 功能：用中间件屏蔽操作系统的缺陷，提升安全等级。
- 示例：Kerberos、SSL/TLS。
跨平台和架构的中间件
- 功能：用于开发大型应用软件。
- 示例：CORBA、JavaBeans、COM+模型。
专用平台中间件
- 功能：为解决特定应用领域的开发设计问题提供构件库。
- 示例：Android SDK、iOS SDK。
网络中间件
- 功能：包括网管、接入、网络测试、虚拟社区和虚拟缓冲等，也是当前最热门的研发项目。
- 示例：TCP/IP协议栈、HTTP服务器。
13.1 软件可靠性基本概念-13.1.1 软件可靠性定义
1. 软件可靠性定义
软件可靠性（Software Reliability）是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。
2. 软件可靠性和硬件可靠性区别
(1) 复杂性：
- 软件复杂性比硬件高。
- 大部分失效来自于软件失效。
(2) 物理退化：
- 软件不存在物理退化现象。
- 硬件失效主要是由于物理退化所致。
(3) 唯一性：
- 软件是唯一的，每个复制版本都一样。
- 两个硬件不可能完全一样。
(4) 版本更新周期：
- 硬件较慢。
- 软件较快。
13.1.2 软件可靠性的定量描述
1. 规定时间
- 自然时间
- 运行时间
- 执行时间（占用CPU）
2. 失效概率
- 软件运行初始时刻失效概率为0，随着时间增长单调递增，不断趋向于1。
3. 可靠度
- 定义：软件系统在规定的条件下、规定的时间内不发生失效的概率。
- 计算公式：等于1 - 失效概率。
4. 失效强度
- 单位时间软件系统出现失效的概率。
5. 平均失效前时间 (MTTF)
- 定义：平均失效等待时间，即系统从开始运行到发生第一次故障所经历的平均时间。
6. 平均恢复前时间 (MTTR)
- 定义：平均修复时间，即从出现故障到修复成功的时间。