|
场景的部分 |
可能的值 |
|
刺激源 |
最终用户、开发人员、系统管理员 |
|
刺激 |
增加、删除、修改：功能、质量属性、容量 |
|
制品 |
用户界面、平台、环境或关联系统 |
|
环境 |
运行时、编译时、构建时、设计时 |
|
响应 |
查找要修改的位置进行修改（不影响其他功能），进行测试、部署所修改的内容 |
|
响应质量 |
对修改的成本进行度量，对修改的影响进行度量 |
系统的可修改性的方面包括：易读、易于查错、易于改错、可以根据环境的变化进行各种改变和改进、可以根据用户的要求进行各种改变和改进。
引起系统修改的两个因素：
l 用户需求
l 系统内在需求
（初期的淘宝使用的是MySQL作为它的数据库，对于起初的淘宝也是适用的，因为没有产生MySQL无法处理的大量数据及相应的实时处理业务。但是近几年来淘宝的数据爆炸产生，在这总系统本身产生的需求下，如果不进行系统数据库方面的修改会严重影响到淘宝带来的收益）
可修改性战术。包括局部化修改、防止连锁反应、推迟绑定时间。无论是局部化修改还是防止连锁反应，都是基于“高内聚，低耦合”思想。
① 局部化修改。在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内，从而降低修改的成本。
② 防止连锁反应。我们平时编程无论是写函数还是写类，都会被其它的类或函数（方法）调用，防止连锁反应就是实现对被调用部分的修改不会引起对调用它的部分的影响。
防止连锁反应的战术如下：
信息隐藏：就是把某个实体的责任分解为更小的部分，并选择哪些信息成为公有的，哪些成为私有的，通过接口获得公有责任。
维持现有的接口：尽可能维持现有接口的稳定性。例如通过添加接口（通过新的接口提供新的服务）可以达到这一目的。
限制通信路径：限制与一个给定的模块共享数据的模块。这样可以减少由于数据产生/使用引入的连锁反应。
仲裁者的使用：在具有依赖关系的两个模块之间插入一个仲裁者，以管理与该依赖相关的活动。
③ 推迟绑定时间。系统具备在运行时进行绑定并允许非开发人员进行修改（配置）。
原文：https://www.cnblogs.com/zmh-980509/p/12396820.html