架构设计小论文
细谈软件质量属性之可修改性
摘要：质量属性是软件属性之一，是软件架构关注的重点。架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性。质量属性包括：可用性、可修改性、性能、安全性、可测试性、易用性。 这篇文章将主要针对可修改性举行论述。对于软件开发人员来说，对程序进行修改是非常痛苦的，但是如果具有非常好的可修改性，那么将很大程度上减轻开发人员的工作量。
关键字：非功能需求，质量属性，可修改性
一、可修改性的理解
如果我们的系统或软件可以很容易、灵活的被正确修改，那么就具有良好的可修改性。
1.1 为什么要进行修改？
在开发过程中引起修改的因素无非就是需求的改变，而引起需求改变的因素有两种，一种是用户需求，另一种是系统需求。如果我们在开发过程中，用户的需求发生了变化，而这种变化我们必须要进行调整，那我们就需要对系统进行修改。或者某种需求的重要性会严重的影响系统的成本以及后期的收益，这是也必须对系统进行修改，这是用户方面的需求变化对系统可修改性的考验。而系统需求引起的系统调整，例如在我们在开发过程中，所需要的数据量越来越大，之前数据库已经无法承受大量的数据，那么对系统的数据存储方面进行修改就是不可避免的。
1.2 可修改性可以修改什么？
在开发过程中最常见的就是对源代码的修改，因为需求的变化，功能的变化，时常要对源代码进行修改，对修改后的代码进行测试，然后重新部署在系统中。其他的修改就是系统运行的环境的修改、系统计算的功能的修改、系统用到的硬件以及中间件的修改、系统数据存储数据库的修改。当然，如果需要，系统的任何方面都可以进行修改。
1.3 好的可修改性具有什么特点？
当我们对一个程序的其中一个模块进行修改时，我们的修改是否会对其他的模块造成影响，是否会影响系统整体逻辑，是否会引起后台的控制，是否会引起整个系统的崩溃，这体现了一个网站的整个架构的是否具备可修改性。
二、可修改性战术
可修改性战术的目标是控制实现、测试和部署变更的时间和成本。
以下讨论三种可修改性战术：局部化修改、防止连锁反应和推迟绑定时间。这三种战术都离不开一种关键的设计模式-“高内聚，低耦合”。
2.1 局部化修改
局部化修改的关键是在设计开发期间对系统的模块进行划分，就是利用单一职责的原则，一个模块负责一个单独的、完整的功能，以防一个模块的变更造成对其他模块的影响。
2.1.1 维持语义的一致性
这里的语义指的是模块职责之间关系。维持语义的一致性就是要保证这些模块可以协同合作，而又保持独立性，不过多的依赖其他模块。在这一过程中，离不开的一个战术就是战术就是“抽象通用服务”，它可以在需要进行修改的时候仅仅进行一次修改，而不需要对使用这些服务的每个模块中都进行修改，并且这个修改不会对其他部分造成影响。既可以保证局部化修改，也可以避免连锁反应。
2.1.2 预期期望的变更
预期期望的变更所关心的是如何使变更的影响最小，把要进行修改的模块放在一个集合中，为这个集合提供一个评估的方法，通常与一致性一起使用。
2.1.3 限制可能的选择
在进行局部化修改时，要修改的范围可能非常大，这时可能会影响很多模块。限制可能的选择将会降低这些修改所造成的影响。
2.1.4 泛化该模块
泛化能力指算法模型对未知数据的预测能力。而泛化这个模块具有输入计算更广泛的功能。
2.2 防止连锁反应
避免连锁反应才能把影响降到最小，不会像多米诺骨牌一样造成不可挽回的结果。防止连锁反应的关键思想就是在对一个函数或者类进行修改时，如何不对调用它的的类和函数造成影响。
2.2.1 依赖性战术
●要维持现有的接口。可以通过添加接口，添加适配器，提供一个占位程序的方式来实现。
●基于“依赖倒转原则”设计原则。搭建上层服务，如果需要修改相关功能可以实现局部化修改，不用再对上层服务进行修改。
●限制通信路径。在对一个模块进行修改时，如果有其他模块使用到了这个模块的数据，那么要减少对其的使用，保证减少影响。
●降低模块之间的依赖性。在两个要关联的类中间加入一个第三方代理，两个类不直接通信，而是通过这个第三方来保持联系，这样可以降低类之间的依赖性。
2.3 推迟绑定时间
推迟绑定时间支持通过减少需要修改的模块的数量而满足部署时间以及允许非开发人员进行修改。需要满足以下条件：
●运行时注册
●多态
●配置文件
●组件更换
●遵守已定义的协议
三、总结
为了一个软件的长期发展，在开发前的架构设计阶段不单单要考虑软件需要的功能，还要将软件的质量属性考虑进去，一个合理的软件架构足够应付需求的未知变化。这其中有了好的可修改性，才能更好的控制实现、测试和部署的时间和成本，具有更强的变更能力。
参考文献：
[1] 李智慧、大型网站技术架构核心原理与案例分析[M]、电子工业出版社,2013.9
[2] 程序猿胖子、质量属性、简书上发表、2018.01.20
