可修改性战术分析

Posted 2021-03-06 990906lhc

  软件质量属性存在的意义是能够对一个软件项目进行衡量价值，然其又可以分为六个子属性：可用性分析，可修改性分析，性能分析，安全性分析，可测试性分析，易用性分析。我经过对这六个属性分析之后发现，可修改性是软件质量属性分析的一大重点。

  何为可修改性，如果把一辆汽车看成一个整体的系统，那么其中的各类零部件即是这个系统的各项类，发动机是驱动类等等。然而当我们使用这辆车久了之后，发动机老化了，我们是否要有一个需求，那就是把发动机卸了，再安一个新的。这就是大概可修改性的意义吧。

  然而我们为什么要修改我们的代码呢？原因有很多，但是统一来说就是个需求的问题：它可包含两个方面：1、用户需求，2、系统内在需求。需求，成本，修改三者的关系：需求无处不在，时时刻刻产生，判别一个需求的重要性来自于它对系统的成本产生的影响，如果严重影响了系统带来的收益，那必须对系统进行修改，如果某一部分相对于系统收益来说微不足道，甚至不会影响系统的收益，那改不改都“无可厚非”，可能你对这部分修改了还引起系统故障了咋办。例如：一个网站的图标有人觉得不好看，有人觉得不错。使用的人们已经习惯这个图标的表示或者惯性的认为这个图标代表什么。那么是否对这个图标进行修改？我以为没有必要修改，如果你修改了反而可能会引起使用者的错误判断，比如：这个网站是停止运维了吗？好，那我去用其他的系统吧。类似错误的判断会影响到系统的收益，所以不进行修改就挺好的。

  我们来举一个现实中的例子：

  我们一般在写一些需要数据库存储数据的项目时，首先就需要一个连接数据库的类：

DBUtil

  这个类在我们实验的时候非常实用，也非常必要。当我们想要将他的数据库连接更换的时候，我们就可以吧其中的数据库名称，用户名，密码修改一下即可使用。这就在我们的开发过程中非常的方便快捷，那些jar包也是实现某些功能而封装的类。这实际上就体现了“局部化修改”。

  另外，我们还应该防止出现“连锁反应”，即实现被挪用部分的修改不会引起对挪用它的部门的影响。在封装方法时，方法仅仅负责独立完成该方法所应该完成的功能，与其他方法并没有联系，在某个方法进行更改时并不会影响到除被更改方法以外的其他方法，不会产生连锁反应对程序的影响不会很大。

  

dao

  两种方法中其中一个方法被修改不会影响到另一个方法的正常执行 

  延迟绑定时间一一目标是控制部署时间并允许非开发人员进行修改：运行时注册（*即插即用）；配置文件（*启动时设置参数）；多态（*后期绑定）；组件更换（*允许载入时间绑定）；遵守已定义的协议（*允许独立进程的运行时绑定）。