追求代码质量（3）: 软件架构的代码质量

原文出处： IBM中国

上一期文章中，我展示了如何使用代码度量来评估代码质量。尽管在那一期介绍的圈复杂度针对低级细节，如方法中执行路径的数量，但其他类型的度量针对的是代码的更高级方面。在本期文章中，我将展示如何使用各种耦合度量 来分析和支持软件架构。

我将从两个比较有趣的耦合度量开始，即传入耦合 和传出耦合。这些基于整数的度量表示几个相关对象（即相互协调以产生行为的对象）。任一度量中高数值表示架构的维护问题：高传入耦合表示对象具有太多职责，而高传出耦合表示对象不够独立。在本期文章中，我将介绍每个这样的问题及其解决的方法。

传入耦合

具有太多职责并非什么坏事。例如，组件（或包）通常试图用于整个架构中，这就会给它们带来高传入耦合值。核心框架（如 Strut）、登录包（如 log4j）之类的实用工具以及异常层次结构通常具有高传入耦合。

在图 1 中，可以看到一个包com.acme.ascp.exception具有一个值为 4 的传入耦合。这并不奇怪，因为web、dao、util和frmwrk包都希望利用一个公共的异常框架。

图 1. 传入耦合的符号

如图 1 所示，exception包具有一个值为 4 的传入耦合（或者叫做 Ca），这并非是件坏事。异常层次结构很少会出现很大的改变。监视exception包的传入耦合是个好主意，然而，由于彻底改变了这个包中的行为或契约，所以将引起它的四个依赖包全都出现连锁反应。

测量抽象性

通过进一步检查exception包并注意抽象到具体类的比率，可以派生出另一个度量：抽象性。在本例中，exception包具有零抽象性，因为它的所有类都是具体的。这与我前面的观察是一致的：exception包中的高度具体性表示对exception作出的任何更改将影响所有相关包，即com.acme.ascp.frmwrk、com.acme.ascp.util、com.acme.ascp.dao和com.acme.ascp.web。

通过理解传入耦合表示组件的职责，并持续监视这个度量，可以防止软件架构出现熵（entropy），即使在大多数设计良好的系统中也很容易出现熵。

支持设计灵活性

很多架构设计在利用第三方包时都考虑到了灵活性。获得灵活性最好是通过使用接口来防止架构在第三方包中发生更改。例如，系统设计师可以创建一个内部接口包 来利用第三方记帐代码，但是只对这些使用记帐代码的包公开接口。顺便说一下，这与 JDBC 的工作原理类似。

图 2. 通过设计获得灵活性

如图 2 所示，acme.ascp 应用程序通过com.acme.ascp.billing包与第三方记帐包相耦合。这创建了一定级别的灵活性：如果有了另一个第三方记帐包更加有利用价值，那么应该只有一个包会受到变更的影响。此外，com.acme.ascp.billing的抽象性值是 0.8，这表明它可以通过接口和抽象类来防止被修改。

如果要转换到第三方实现，只需要对com.acme.ascp.billing包进行重构。更好的方法是：通过在设计中考虑灵活性以及了解变更的隐含意义，可以通过开发人员测试来防止修改所造成的任何损害。

在对内部记帐包作出变更前，您可以分析代码覆盖率报告，以确定是否有任何测试真正 测试了这个包。找到一些级别的覆盖率后，您可以更仔细地检查这些测试案例来验证它们是否足够了。如果未找到覆盖率，您将会知道，关闭并插入新库的努力将更具风险性并可能花费更长的时间。

使用代码度量收集所有这些似乎正确的信息非常容易。另一方面，如果您根本不了解与测试覆盖率相关的包耦合的知识，那么为替换第三方库确定的时间最多就是个猜测！

监视熵

前面提到过，即使计划得最好的架构也会出现熵。通过团队磨损或未充分记录的意图，没有经验的开发人员可能会疏忽地导入似乎有用的包，不久以后，系统传入耦合的值将开始增长。

例如，将图 3 与 图 2 进行比较。您注意到架构增加的脆弱性了吗？现在不仅dao包直接利用第三方记帐包，而且另一个甚至不想直接使用任何记帐代码的包也引用了这两个记帐包！

图 3. 出现代码熵

试图为另一个包关闭com.third.party.billing包确实很具有挑战性！设想一下降低产生缺陷和中断系统各种行为方面的风险所需的测试脚手架。事实上，像这样的架构很少变更，因为它们无法支持修改。更糟糕的是，即使像对现有组件的升级这样的重要修改也会导致整个代码基中断的事情出现。

传出耦合

如果传入耦合是一些依赖于某个特定组件的组件的话，那么传出耦合则是某个特定组件所依赖的一些组件。可以把传出耦合看作传入耦合的逆转。

对于更改如何影响代码来说，传出耦合的引号意义与传入耦合的类似。例如，图 4 描述了com.acme.ascp.dao包，它具有一个值为 3 的传出耦合（或者叫做 Ce）：

图 4. dao 包中的传出耦合

如图 4 所示，com.acme.ascp.dao包依赖于org.apache.log4j、com.acme.ascp.util和com.acme.ascp.exception组件来履行其行为契约。与传入耦合中一样，依赖性级别本身并不是什么坏事。重要的是您对耦合的了解以及耦合如何影响对相关组件的更改。

与传入耦合一样，抽象性度量在传出耦合中起作用。在 图 4 中，com.acme.ascp.dao包完全是具体的；因此它的抽象性为 0。这表示其传出耦合包含com.acme.ascp.dao的组件自己会变得脆弱，因为com.acme.ascp.dao包与 3 个附加的包具有传出耦合。如果它们中的一个（比如说com.acme.ascp.util）发生更改，将会在com.acme.ascp.dao中发生连锁反应。因为dao无法通过接口或抽象类隐藏注入细节，所以任何更改都可能影响它的依赖组件。

耦合与覆盖相加等于……

检查传出耦合的关系数据，并将其与代码覆盖相关联，会促进作出更明智的决策。例如，假设一个新的需求传达给开发团队。您可以将与该需求相关的更改精确到图 4 所示的com.acme.ascp.util包。而且，在以前几个版本中，依赖于util并且具有 0 抽象性的dao包具有很多高优先权的缺陷（非常可能是因为对这个包进行的开发人员测试太有限，有意思的是，最大的可能是由于代码中的高复杂性值引起的）。

在这种情况下，您的优势是了解com.acme.ascp.util和com.acme.ascp.dao之间的关系。知道dao包依赖于util这一事实告诉您，为支持新需求而在util中进行的任何修改可能会对易出故障的dao包产生负面的影响！

看到这个链接将帮助进行风险评估，甚至帮助进行工作级别的分析。如果未注意到这个链接，您可能已经猜到将需要快速编码工作来支持新需求。如果已经看到这个链接，就可以分配适当的时间和资源来降低dao包中的间接损害。

监视依赖性

正像连续地监视传入耦合可以揭示架构设计中的熵一样，监视传出耦合也有助于发现不必要的依赖性。例如，在图 5 中，似乎在一些地方有人决定com.acme.ascp.web包要为com.acme.ascp.user提供内容。在user包中的某处，一个或多个对象正在实际从web包导入一个对象。

图 5. user 包中的传出耦合

很明显，这并非架构设计最初意图。但是，由于您一直针对传出耦合而监视系统，所以可以轻松地重构并改正这些不一致。或许，web包中有用的实用工具对象应该移动到实用工具包，以便其他包可以利用它而不会引起不必要的依赖性。

测量不稳定性

您可以将系统的传出耦合和传入耦合的数量结合起来，形成另一个度量：不稳定性。通过将传出耦合除以传出传入耦合的和（Ce / (Ca + Ce)），可以生成一个比率，表示一个稳定的包（值接近于 0）或者不稳定的包（值接近于 1）。如这个等式所示，传出耦合对包的稳定性起作用：一个包越依赖于其他包，面对更改时它越容易受到连锁反应的影响。反过来说，一个包越被依赖，它越不可能发生更改。

例如，在图 5 中，user包的不稳定性值为 1，这表示它有一个值为 4 的传出耦合，而没有传入耦合。像com.acme.ascp.dao这样的包中的更改将会 影响user包。

在设计和实现架构时，依赖于稳定的包是有益的，因为这些包不太可能更改。类似地，不稳定的包依赖性会在发生更改时增大架构内发生间接损害的风险。

到主序列的距离

到目前为止，我已经介绍了传入耦合和传出耦合，前者可用来评估更改包造成的影响，后者可用来评估外界的更改如何影响包。我还谈及了抽象性度量和不稳定性度量，前者在您想要了解如何轻松地对包进行修改时很有用，后者可用来了解包依赖性如何影响某个特定的包。

还可以使用另一个度量来了解影响软件架构的因素。这个度量通过 X, Y 坐标上的一条直线来平衡抽象性和不稳定性。主序列 是笛卡儿坐标上从X=0和Y=1到X=1和Y=0的一条直线，如图 6 所示：

图 6. 主序列

通过沿着这条直线绘制包并测量它们到主序列的距离，可以推断包的平衡。如果包对于抽象性和不稳定性是平衡的，它的距离就接近于 0，如果包不平衡，那么它距离主序列的距离就接近于 1，如图 7 所示：

图 7. 到主序列的距离

检查到主序列的距离 度量会产生有趣的结果。例如，上面的user包生成的值为 0。就一个实现包来说，这个包是平衡的，即高度不稳定。

总体来说，“到主序列的距离” 度量尝试补偿实际实现。没有代码基包含所有抽象性和不稳定性值为 1 或 0 的包 —— 多数包的值位于这两个数字之间。通过监视 “到主序列的距离” 度量，可以衡量包是否正在变得不平衡。寻找偏远的值，如值接近于 1 的包（这表示它们距离主序列尽可能地远），有助于了解特定的不平衡如何影响架构的可维护性（例如，通过脆弱性）。

结束语

在本期文章中，您已经了解几种可以持续监视的架构度量。通过代码分析工具可以报告传入和传出耦合、不稳定性、抽象性、到主序列的距离，这些代码分析工具包括 JDepend、JarAnalyzer 和 Metrics plug-in for Eclipse（参见 参考资料）。监视系统的代码耦合度量有助于您掌握可破坏架构的常见趋势，即设计刚度、包熵和不必要的依赖性。此外，根据抽象性和不稳定性来测量系统平衡将使您不断的了解系统的可维护性。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
• “追求代码质量: 监视圈复杂度”（Andrew Glover，developerWorks，2006 年 3 月）：使用简单的代码度量和基于 Java™的用于监视圈复杂度的工具来识别危险代码。
• “追求代码质量: 不要被覆盖报告所迷惑”（Andrew Glover，developerWorks，2006 年1 月）测试覆盖测量如何使您误入歧途。
• 追求代码质量：阅读 Andrew Glover 撰写的完整系列文档。
• “使用 ConTest 进行多线程单元测试”（Yarden Nir-Buchbinder 和 Shmuel Ur，developerWorks，2006 年 5 月）并发程序的覆盖测量解决方案。
• “测试遗留代码”（Elliotte Harold，developerWorks，2006 年 5 月）：为从未经过测试的遗留代码开发一个单元测试套件。
• Java 技术专区：数百篇关于 Java 编程各个方面的文章。

获得产品和技术

• JDepend：生成设计质量度量的 Java 包依赖性分析器。
• JarAnalyzer：这个工具分析 jar 文件之间的关系。
• Metrics plug-in for Eclipse：计算圈复杂度和其他与代码复杂性以及耦合相关的度量。

讨论

• 参与论坛讨论。
• developerWorks blogs：加入 developerWorks 社区！