使用耦合度量来支持系统架构 |
级别: 初级 Andrew Glover (aglover@stelligent.com), 总裁, Stelligent Incorporated 2006 年 5 月 23 日 大多数设计良好的软件架构都趋向于支持系统的可扩展性、可维护性和可靠性。遗憾的是,对质量问题的疏忽极可能使软件架构师的努力白费。在 追求代码质量 系列的这一期文章中,质量专家 Andrew Glover 解释如何持续地监视并纠正会影响软件架构的长期生存能力的代码质量方面。 上一期文章中,我展示了如何使用代码度量来评估代码质量。尽管在那一期介绍的圈复杂度针对低级细节,如方法中执行路径的数量,但其他类型的度量针对的是代码的更高级方面。在本期文章中,我将展示如何使用各种耦合度量 来分析和支持软件架构。 我将从两个比较有趣的耦合度量开始,即传入耦合 和传出耦合。这些基于整数的度量表示几个相关对象(即相互协调以产生行为的对象)。任一度量中高数值表示架构的维护问题:高传入耦合表示对象具有太多职责,而高传出耦合表示对象不够独立。在本期文章中,我将介绍每个这样的问题及其解决的方法。 具有太多职责并非什么坏事。例如,组件(或包)通常试图用于整个架构中,这就会给它们带来高传入耦合值。核心框架(如 Strut)、登录包(如 log4j)之类的实用工具以及异常层次结构通常具有高传入耦合。 在图 1 中,可以看到一个包 图 1. 传入耦合的符号 如图 1 所示,
通过进一步检查 通过理解传入耦合表示组件的职责,并持续监视这个度量,可以防止软件架构出现熵(entropy),即使在大多数设计良好的系统中也很容易出现熵。
很多架构设计在利用第三方包时都考虑到了灵活性。获得灵活性最好是通过使用接口来防止架构在第三方包中发生更改。例如,系统设计师可以创建一个内部接口包 来利用第三方记帐代码,但是只对这些使用记帐代码的包公开接口。顺便说一下,这与 JDBC 的工作原理类似。 图 2. 通过设计获得灵活性 如图 2 所示,acme.ascp 应用程序通过 如果要转换到第三方实现,只需要对 在对内部记帐包作出变更前,您可以分析代码覆盖率报告,以确定是否有任何测试真正 测试了这个包。找到一些级别的覆盖率后,您可以更仔细地检查这些测试案例来验证它们是否足够了。如果未找到覆盖率,您将会知道,关闭并插入新库的努力将更具风险性并可能花费更长的时间。 使用代码度量收集所有这些似乎正确的信息非常容易。另一方面,如果您根本不了解与测试覆盖率相关的包耦合的知识,那么为替换第三方库确定的时间最多就是个猜测!
前面提到过,即使计划得最好的架构也会出现熵。通过团队磨损或未充分记录的意图,没有经验的开发人员可能会疏忽地导入似乎有用的包,不久以后,系统传入耦合的值将开始增长。 例如,将图 3 与 图 2 进行比较。您注意到架构增加的脆弱性了吗?现在不仅 图 3. 出现代码熵 试图为另一个包关闭
如果传入耦合是一些依赖于某个特定组件的组件的话,那么传出耦合则是某个特定组件所依赖的一些组件。可以把传出耦合看作传入耦合的逆转。 对于更改如何影响代码来说,传出耦合的引号意义与传入耦合的类似。例如,图 4 描述了 图 4. dao 包中的传出耦合 如图 4 所示, 与传入耦合一样,抽象性度量在传出耦合中起作用。在 图 4 中,
检查传出耦合的关系数据,并将其与代码覆盖相关联,会促进作出更明智的决策。例如,假设一个新的需求传达给开发团队。您可以将与该需求相关的更改精确到图 4 所示的 在这种情况下,您的优势是了解 看到这个链接将帮助进行风险评估,甚至帮助进行工作级别的分析。如果未注意到这个链接,您可能已经猜到将需要快速编码工作来支持新需求。如果已经看到这个链接,就可以分配适当的时间和资源来降低
正像连续地监视传入耦合可以揭示架构设计中的熵一样,监视传出耦合也有助于发现不必要的依赖性。例如,在图 5 中,似乎在一些地方有人决定 图 5. user 包中的传出耦合 很明显,这并非架构设计最初意图。但是,由于您一直针对传出耦合而监视系统,所以可以轻松地重构并改正这些不一致。或许,
您可以将系统的传出耦合和传入耦合的数量结合起来,形成另一个度量:不稳定性。通过将传出耦合除以传出传入耦合的和( 例如,在图 5 中, 在设计和实现架构时,依赖于稳定的包是有益的,因为这些包不太可能更改。类似地,不稳定的包依赖性会在发生更改时增大架构内发生间接损害的风险。
到目前为止,我已经介绍了传入耦合和传出耦合,前者可用来评估更改包造成的影响,后者可用来评估外界的更改如何影响包。我还谈及了抽象性度量和不稳定性度量,前者在您想要了解如何轻松地对包进行修改时很有用,后者可用来了解包依赖性如何影响某个特定的包。 还可以使用另一个度量来了解影响软件架构的因素。这个度量通过 X, Y 坐标上的一条直线来平衡抽象性和不稳定性。主序列 是笛卡儿坐标上从 图 6. 主序列 通过沿着这条直线绘制包并测量它们到主序列的距离,可以推断包的平衡。如果包对于抽象性和不稳定性是平衡的,它的距离就接近于 0,如果包不平衡,那么它距离主序列的距离就接近于 1,如图 7 所示: 图 7. 到主序列的距离 检查到主序列的距离 度量会产生有趣的结果。例如,上面的 总体来说,“到主序列的距离” 度量尝试补偿实际实现。没有代码基包含所有抽象性和不稳定性值为 1 或 0 的包 —— 多数包的值位于这两个数字之间。通过监视 “到主序列的距离” 度量,可以衡量包是否正在变得不平衡。寻找偏远的值,如值接近于 1 的包(这表示它们距离主序列尽可能地远),有助于了解特定的不平衡如何影响架构的可维护性(例如,通过脆弱性)。
在本期文章中,您已经了解几种可以持续监视的架构度量。通过代码分析工具可以报告传入和传出耦合、不稳定性、抽象性、到主序列的距离,这些代码分析工具包括 JDepend、JarAnalyzer 和 Metrics plug-in for Eclipse(参见 参考资料)。监视系统的代码耦合度量有助于您掌握可破坏架构的常见趋势,即设计刚度、包熵和不必要的依赖性。此外,根据抽象性和不稳定性来测量系统平衡将使您不断的了解系统的可维护性。 学习
获得产品和技术
讨论
|