13.软件架构评估

软件质量属性

性能

性能（Performance）是指系统的响应能力，即要经过多长事件才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。例如：同时支持1000并发；响应时间小于1s；显示分辨率达到4K。
代表参数：响应时间，吞吐量；设计策略：优先级队列，资源调度

性能战术

1. 资源需求

• 提高计算效率

• 减少计算开销

• 管理事件率

• 控制采样频率

2. 资源管理

• 引入并发

• 维持多个副本

• 增加可用资源

3. 资源仲裁 - 资源调度策略：

• 先进/先出

• 固定优先级

• 动态优先级

• 静态调试

可用性

可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。例如：主服务器故障，1分钟内切换至备用服务器；系统故障，1小时内修复；系统支持7x24小时工作。
代表参数：故障间隔时间，设计策略：冗余，心跳线

可用性战术

1. 错误检测

• 命令/响应【Ping/Echo】

• 心跳

• 异常

2. 错误恢复

• 表决

• 冗余【主动/被动】

• 备件

3. 错误预防

• 进程监视器

• 事务

• 从服务器删除

安全性

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性以及可控性等特征。例如：可抵御SQL注入攻击；对计算机的操作都有完整记录；用户信息数据库授权必须保证99.99%可用。
设计策略：追踪审计

安全性战术

1. 抵抗攻击

• 身份验证

• 用户授权

• 数据加密

• 数据完整性

• 限制暴露

• 限制访问

2. 检测攻击

• 入侵检测

3. 从攻击中恢复

• 识别：审计追踪

• 恢复：冗余【与可用性重叠】

可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。例如：更改系统报表模块，必须在2周内完成；对Web界面风格进行修改，修改必须在4个月内完成。
主要策略：信息隐藏

可修改性战术

1. 局部化修改

• 维持语义一致性

• 预期期望的变更

• 泛化模块

• 限制可能的选择

• 抽象通用服务

2. 防止连锁反映

• 隐藏信息

• 维持现有的接口

• 限制通信路径

• 使用仲裁者

3. 推迟绑定时间

• 运行时注册

• 配置文件

• 多态

• 组件更换

• 遵守已定义的协议

易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。例如：界面友好；新用户学习使用系统不超过2小时。

可测试性

软件可测试性是指通过测试揭示软件缺陷的容易程度。例如：提供远程调试接口，支持远程调试。

敏感点、权衡点、风险点、非风险点

1. 敏感点：是一个或多个构件（和或构件之间的关系）的特性。

2. 权衡点：是影响多个质量属性的特征，是多个质量属性的敏感点。

3. 风险点：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

4. 非风险点：是指不会带来隐患，一般以“xxx要求是可以实现（或接受）的”方式表达。

架构评估方法

业界已开发出多种软件架构评估的方法，按基于的技术手段来看，可以分为三类：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。其中基于场景的方式是使用最多的。

基于场景的方式由 SEI 首先提出并应用在架构权衡分析法 （Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。

基于场景的评估方法

软件架构分析法 SAAM

SAAM：最初用于分析架构可修改性，后扩展到其他质量属性。

架构权衡分析法 ATAM

ATAM：在SAAM的基础上发展起来的，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

行动计划：

1. 第一阶段：场景和需求收集

• 收集场景

• 收集需求/约束/环境

2. 第二阶段：架构视图和场景实现

• 描述架构视图

• 实现场景

3. 第三阶段：属性模型构造和分析

• 特定属性分析（优秀的单一理论）

4. 第四阶段：折中

• 标志折中

• 标志敏感的

软件产品线

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。

核心资产库包括软件架构及其可剪裁的元素， 更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录（如预算和进度）、 软件测试计划和测试用例。复用核心资产（特别是软件架构），更进一步采用产品线将会惊 人地提高生产效率、降低生产成本和缩短上市时间。

产品线的本质是在软件开发架构过程中， 以一种规范的、策略性的方法复用资产。

双生命周期模型

建立方式

产品线必须建立在公司在某一领域（行业）深耕多年的经验，存在一定的积累。

1. 将现有产品演化为产品线

2. 用软件产品线替代现有产品集

3. 全新软件产品线的演化

4. 全新软件产品线开发

组织结构类型

1. 设立独立的核心资源小组

2. 不设立独立的核心资源小组

3. 动态的组织结构

要成功实施产品线，主要取决于以下因素：

1. 对该领域具备长期和深厚的经验

2. 一个用户构件产品的好的核心资源库

3. 好的产品线架构

4. 好的管理（软件资源、人员组织、过程）支持

– THE END –