软件体系架构_系统质量属性场景描述_结合《淘宝网》实例
系统质量属性是软件系统在质量方面的需求，本文从架构来分析质量属性的实现，实践中最常用的6个系统质量属性包括可用性（Availability）、可修改性（Modifiability）、性能（Performance）、安全性（Security）、可测试性（Testability）和易用性（Usability）。质量属性场景作为刻画质量属性的手段，由以下6个部分组成：
l 刺激源：生成该刺激的实体（人、计算机系统或其他激励器）；
l 刺激：刺激到达系统时可能产生的影响（即需要考虑和关注的情况）；
l 环境：该刺激在某条件内发生。如系统可能正处于过载情况；
l 制品：系统中受刺激的部分（某个制品被刺激）；
l 响应：刺激到达后所采取的行动；
l 响应度量：当响应发生时，应能够以某种方式对应其度量，用于对是否满足需求的测试。
这是一种统一规范的方式来表达质量属性的需求。但是这是一般的质量属性场景，当分析不同的系统时，需要结合具体场景，具体场景通常是指从一般场景中抽取特定的、面向具体系统的内容。下面用质量属性场景分析法分别对6个系统质量属性结合《淘宝网》具体实例逐一进行介绍：
1. 可用性
可用性是指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。
(1)可用性一般场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
系统内部、系统外部 |
|
刺激 |
错误：疏忽（构件对某输入未做出反应）、崩溃、时间不当（响应时间太早或太迟）、响应不当（以一个不正确的值来响应） |
|
制品 |
系统的处理器、通信通道、持久性存储器、进程 |
|
环境 |
正常操作、降级模式 |
|
响应 |
系统应检测事件、并进行如下一个或多个活动： l 记录故障，通知用户或系统 l 根据已定义的规则禁止故障源 l 不可用（进入修理状态） l 继续在正常或者降级状态下运行 |
|
响应度量 |
可用时间、修复时间、各种情况的时间间隔 |
(2)可用性具体场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
用户 |
|
刺激 |
大量用户同时进行访问，系统短时间内高并发访问超过阈值而出现崩溃现象 |
|
制品 |
系统 |
|
环境 |
正常操作 |
|
响应 |
系统检测到事件：记录故障，通知系统 |
|
响应度量 |
一分钟后，系统又可以继续正常使用 |
(3)可用性战术
目标是阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复称为可能。战术分为：错误检测、错误恢复、错误预防。
①错误检测
l 命令/响应：一个构件发出一个命令，并希望在预定义的时间内收到一个来自审查构件的响应，例如远程错误的检测
l 心跳（计时器）：一个构件定期发出一个信条消息，另一个构件收听到消息。如果未收到心跳消息，则嘉定构件失败，并通知错误纠正构件。
l 异常：当出现异常时，异常处理程序开始执行。
②错误恢复
l 表决：通过冗余构件（或处理器）与表决器连接，构件按相同的输入及算法计算输出值给表决器，由表决器按表决算法（如多数规则）确定是否有构件出错，表决通常用在控制系统中。
l 主动冗余（热重启、热备份）：所有的冗余构件都以并行的方式对事件作出相应。它们都处在相同的状态，但仅使用一个构件的响应。丢弃其余构件的响应。错误发生时通过切换的方式使用另一个构件的响应。
l 被动冗余（暖重启/双冗余/三冗余）：一个构件（主构件）对事件作出响应，并通知其他构件（备用的）必须进行的状态更新（同步）。当错误发生时，备用构件从最新同步点接替主构件的工作。
l 备件：是计算平台配置用于更换各种不同的故障构件。
l 状态再同步：主动和被动冗余战术要求所恢复的构件在重新提供服务前更新其状态。更新方法取决于可以承受的停机时间、更新的规模以及更新的内容多少。
l 检查点/回滚：检查点就是使状态一致的同步点，它或者是定期进行，或者是对具体事件作出响应。当在两个检查点之间发生故障时，则以这个一致状态的检查点（有快照）和之后发生的事务日志来恢复系统（数据库中常使用）。
③错误预防
l 从服务中删除：如删除进程再重新启动，以防止内存泄漏导致故障的发生。
l 事务：使用事务来保证数据的一致性，即几个相关密切的步骤，要么全成功，要不全不成功。
l 进程监视器：通过监视进程来处理进程的错误。
2.可修改性
(1)可修改性一般场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
最终用户、开发人员、系统管理员 |
|
刺激 |
希望修改功能、质量属性或者系统容量 |
|
制品 |
系统用户界面、运行平台、环境或与目标系统交互的系统 |
|
环境 |
设计时、构建时、编译时、运行时 |
|
响应 |
查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改 |
|
响应度量 |
对修改的成本进行度量，对修改的影响进行度量 |
(2)可修改性具体场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
开发人员 |
|
刺激 |
修改用户界面 |
|
制品 |
系统用户界面 |
|
环境 |
设计开发时 |
|
响应 |
进行修改且不会影响其他功能 |
|
响应度量 |
3小时之内，完成界面的代码更改 |
(3)可修改性战术
①局部化修改。在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内，从而降低修改的成本。
l 维持语义的一致性：语义的一致性指的是模块中责任之间的关系，是这些责任能够协同工作，不需要过多的依赖其他模块。耦合和内聚指标反映一致性，应该根据一组预期的变更来度量语义一致性。使用”抽象通用服务“（如应用框架的使用和其他中间软件的使用）来支持可修改性是其子战术。
l 预期期望的变更：通过对变更的预估，进行预设、准备，从而使变更的影响最小。
l 泛化该模块：使一个模块更通用、更广泛的功能。
l 限制可能的选择：如在更换某一模块（如处理器）时，限制为相同家族的成员。
②防止连锁反应。由于模块之间有各种依赖性，因此，修改会产生连锁反应。防止连锁反应的战术如下：
l 信息隐藏：就是把某个实体的责任分解为更小的部分，并选择哪些信息称为公有的，哪些称为私有的，通过接口获得公有责任。
l 维持现有的接口：尽可能维持现有接口的稳定性。例如通过添加接口（通过新的接口提供新的服务）可以达到这一目的。
l 限制通信路径：限制于一个给定的模块共享数据的模块。这样可以减少由于数据产生/使用引入的连锁反应。
l 仲裁者的使用：在具有依赖关系的两个模块之间插入一个仲裁者，以管理与该依赖相关的活动。仲裁者有很多种类型，例如：桥、调停者、代理等就是可以提供把服务的语法从一种形式转换为另一种形式的仲裁者。
③推迟绑定时间。系统具备在运行时进行绑定并允许非开发人员进行修改（配置）。
l 运行时注册：支持即插即用。
l 配置文件：在启动时设置参数。
l 多态：在方法调用的后期绑定。
l 构件更换：允许载入时绑定。
3. 性能
(1)性能一般场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
大量独立源中的一个，可能来自系统内部或者外部 |
|
刺激 |
定期事件、随机事件、偶然事件 |
|
制品 |
系统 |
|
环境 |
正常模式、超载模式 |
|
响应 |
处理刺激、改变服务级别 |
|
响应度量 |
度量等待、期限、吞吐量、缺失率、错误丢失等 |
(2)性能具体场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
用户 |
|
刺激 |
随机事件到达，购买商品 |
|
制品 |
系统 |
|
环境 |
正常运行 |
|
响应 |
请求被处理 |
|
响应度量 |
响应时间不超过5秒 |
(3)性能战术
①资源需求
l 减少处理事件流所需的资源：提高计算效率（如改进算法）、减少计算开销（如在可修改性与性能之间权衡，减少不必要的代理构件）。
l 减少所处理事件的数量：管理事件屡，控制采样频率。
l 控制资源的使用：限制执行时间（如减少迭代次数）、限制队列大小。
②资源管理
l 引入并发
l 维持数据或计算的多个副本：C/S结构中客户机C就是计算的副本，他能减少服务器计算的压力；高速缓存可以存放数据副本（在不同速度的存储器之间的缓冲）。
l 增加可用资源：在成本允许时，尽量使用速度更快的处理器、内存和网络。
③资源仲裁
资源仲裁战术是通过如下调度策略来实现的：
l 先进/先出FIFO
l 固定优先级调度：先给事件分配特定的优先级，再按优先级高低顺序分配资源。
l 动态优先级调度：轮转调度、时限时间最早邮线。
l 静态调度；可以离线确定调度。
4.安全性
(1)安全性一般场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
对敏感资源进行访问的人或系统（授权或未授权） |
|
刺激 |
试图修改数据，访问系统服务 |
|
制品 |
系统服务、系统中的数据 |
|
环境 |
在线或者离线、直接或者通过防火墙入网 |
|
响应 |
对用户验证，阻止或允许访问数据或服务 |
|
响应度量 |
避开安全措施所需要的时间或资源；增加安全性的成本；恢复数据/服务 |
(2)安全性具体场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
未授权的用户 |
|
刺激 |
试图修改数据，修改商品价格 |
|
制品 |
系统中的数据 |
|
环境 |
正常操作下 |
|
响应 |
对用户身份进行验证，阻止访问未授权的数据 |
|
响应度量 |
操作被拒绝，恢复数据 |
(3)安全性战术
包括抵抗攻击、检测攻击和从攻击中恢复。
①抵抗攻击
l 对用户进行身份验证：包括动态密码、一次性密码、数字证书及生物识别码。
l 对用户进行授权：即对用户的访问进行控制管理。
l 维护数据的机密性：一般通过对数据和通信链路进行加密来实现。
l 维护完整性：对数据添加校验或哈希值。
l 限制暴露的信息
l 限制访问：如用防火墙，DMZ策略。
②检测攻击。一般通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法。
③从攻击中恢复
l 恢复：与可用性中的战术相同。
l 识别攻击者：作为审计追踪，用于预防性或惩罚性目的。
5.可测试性
(1)可测试性一般场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
各类测试人员（单元测试、集成测试、验收、用户） |
|
刺激 |
一种测试 |
|
制品 |
设计、代码段、完整的应用 |
|
环境 |
设计时、开发时、编译时、部署时 |
|
响应 |
提供测试的状态值、测试环境与案例的准备 |
|
响应度量 |
测试成本、出现故障的概率、执行的时间等 |
(2)可测试性具体场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
开发人员 |
|
刺激 |
已完成架构和子系统的集成 |
|
制品 |
代码段 |
|
环境 |
开发阶段 |
|
响应 |
准备集成环境 |
|
响应度量 |
执行测试的时间 |
(3)可测试性战术
①输入/输出
l 记录/回放：指捕获跨接口的信息，并将其作为测试专用软件的输入。
l 将接口与实现分离：允许使用实现的替代（模拟器）来支持各种测试目的。
l 优化访问线路/接口：用测试工具来捕获或赋予构件的变量值。
②内部监控。当监视器处于激活状态时，记录事件（如通过接口的信息）。
6.易用性
(1)易用性一般场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
最终用户 |
|
刺激 |
学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意 |
|
制品 |
系统 |
|
环境 |
运行时或配置时 |
|
响应 |
上下文相关的帮助系统；数据和/或命令的集合，导航；撤销、取消操作，从系统故障中恢复；定制能力，国际化；显示系统状态 |
|
响应度量 |
任务时间，错误数量，用户满意度、用户知识的获得，成功操作的比例等 |
(2)易用性具体场景描述
|
场景的部分 |
可能的值 |
|
刺激源 |
最终用户 |
|
刺激 |
搜索商品时，根据品牌、价格区间进行筛选 |
|
制品 |
系统 |
|
环境 |
正常运行时 |
|
响应 |
显示按要求筛选后的数据 |
|
响应度量 |
99%以上的用户对筛选结果满意 |
(3)易用性战术
①运行时战术
l 任务的模型：维护用户的信息，使系统了解用户试图做什么，并提供各种协助
l 用户的模型：维护用户的信息，例如使系统以用户可以阅读页面的速度滚动页面。
l 系统的模型：维护系统的信息，它确定了期望的系统行为，并向用户提供反馈。
②设计时战术。将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变化，因此，单独维护用户接口代码将实现变更局部化。这与可修改性相关。
③支持用户主动操作。如支持“取消”、“撤销”、“聚合”和“显示多个视图”。
