可修改性及其实现战术
对于可修改性一般场景的图示及可修改性具体场景，读者可仿照前面可用性的描述方式， 自行练习。
（2）可修改性战术。包括局部化修改、防止连锁反应、推迟绑定时间。 ① 局部化修改。在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内，从而降低修改的成本。 维持语义的一致性：语义的一致性指的是模块中责任之间的关系，使这些责任能够协同工作，不需要过多地依赖其他模块。耦合和内聚指标反映一致性，应该根据一组预期的变更来度量语义一致性。使用“抽象通用服务”（如应用框架的使用和其他中间软件的使用）来支持可修改性是其子战术。 预期期望的变更：通过对变更的预估，进行预设、准备，从而使变更的影响最小。 泛化该模块：使一个模块更通用、更广泛的功能。 限制可能的选择：如在更换某一模块（如处理器）时，限制为相同家族的成员。
② 防止连锁反应。由于模块之间有各种依赖性，因此，修改会产生连锁反应。防止连锁反应的战术如下。 信息隐藏：就是把某个实体的责任分解为更小的部分，并选择哪些信息成为公有的，哪些成为私有的，通过接口获得公有责任。 维持现有的接口：尽可能维持现有接口的稳定性。例如通过添加接口（通过新的接口提供新的服务）可以达到这一目的。 限制通信路径：限制与一个给定的模块共享数据的模块。这样可以减少由于数据产生/使用引入的连锁反应。 仲裁者的使用：在具有依赖关系的两个模块之间插入一个仲裁者，以管理与该依赖相关的活动。仲裁者有很多种类型，例如：桥、调停者、代理等就是可以提供把服务的语法从一种形式转换为另一种形式的仲裁者。
③ 推迟绑定时间。系统具备在运行时进行绑定并允许非开发人员进行修改（配置）。 运行时注册：支持即插即用。 配置文件：在启动时设置参数。 多态：在方法调用的后期绑定。 构件更换：允许载入时绑定
性能及其实现
（2）性能战术。性能与时间相关，影响事件的响应时间有两个基本因素。 资源消耗：事件到达后进入一系列的处理程序，每一步处理都要占用资源，而且在处理过程中消息在各构件之间转换，这些转换也需要占用资源。 闭锁时间：指对事件处理时碰到了资源争用、资源不可用或对其他计算的依赖等情况，就产生了等待时间。 性能的战术有如下几种。 ① 资源需求 减少处理事件流所需的资源：提高计算效率（如改进算法）、减少计算开销（如在可修改性与性能之间权衡，减少不必要的代理构件）。 减少所处理事件的数量：管理事件率、控制采样频率。 控制资源的使用：限制执行时间（如减少迭代次数）、限制队列大小。 ② 资源管理 引入并发：引入并发对负载平衡很重要。 维持数据或计算的多个副本： C/S 结构中客户机 C 就是计算的副本，它能减少服务器计算的压力；高速缓存可以存放数据副本（在不同速度的存储库之间的缓冲）。 增加可用资源：在成本允许时，尽量使用速度更快的处理器、内存和网络。 ③ 资源仲裁 资源仲裁战术是通过如下调度策略来实现的。 先进/先出（FIFO）； 固定优先级调度：先给事件分配特定的优先级，再按优先级高低顺序分配资源； 动态优先级调度：轮转调度、时限时间最早优先； 静态调度：可以离线确定调度。
安全性及其实现战术
（2）安全性战术：包括抵抗攻击、检测攻击和从攻击中恢复。 ① 抵抗攻击 对用户进行身份验证：包括动态密码、一次性密码、数字证书及生物识别等； 对用户进行授权： 即对用户的访问进行控制管理； 维护数据的机密性：一般通过对数据和通信链路进行加密来实现； 维护完整性：对数据添加校验或哈希值； 限制暴露的信息； 限制访问：如用防火墙、 DMZ 策略。 ② 检测攻击。一般通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法。 ③ 从攻击中恢复。 恢复：与可用性中的战术相同； 识别攻击者：作为审计追踪，用于预防性或惩罚性目的。
可测试性及其实现战术
（2）可测试性战术：包括输入/输出和内部监控。 ① 输入/输出 记录/回放：指捕获跨接口的信息，并将其作为测试专用软件的输入； 将接口与实现分离：允许使用实现的替代（模拟器）来支持各种测试目的； 优化访问线路/接口：用测试工具来捕获或赋予构件的变量值。 ② 内部监控。
当监视器处于激活状态时，记录事件（如通过接口的信息）。
易用性及其实现战术
（2）易用性战术：包括运行时战术、设计时战术和支持用户主动操作。
① 运行时战术 任务的模型：维护任务的信息，使系统了解用户试图做什么，并提供各种协助； 用户的模型：维护用户的信息，例如使系统以用户可以阅读页面的速度滚动页面； 系统的模型：维护系统的信息，它确定了期望的系统行为，并向用户提供反馈。
② 设计时战术。将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变化，因此，单独维护用户接口代码将实现变更局部化。这与可修改性相关。
③ 支持用户主动操作。支持用户的主动操作，如支持“取消”、“撤销”、“聚合”和 “显示多个视图”。