Code Quality For Software Architects

From NeoWiki

Use coupling metrics to support your system architecture

Andrew Glover, President, Stelligent Incorporated

25 Apr 2006

Most well-designed software architectures are intended to support a system's extensibility, maintainability, and reliability. Unfortunately, inattention to quality issues can easily undermine a software architect's best effort. In this installment of In pursuit of code quality, quality expert Andrew Glover explains how to continuously monitor and correct quality aspects of code that can affect the long-term viability of your software architecture.

Last month, I showed you how to use code metrics to evaluate the quality of your code. While the cyclomatic complexity metrics introduced in that column focus on low-level details, such as the number of execution paths in a method, other types of metrics focus on more high-level aspects of code. This month, I'll show you how to use various coupling metrics to analyze and support your software architecture.

I'll start out with two of the more interesting coupling metrics, namely afferent coupling and efferent coupling. These integer-based metrics represent a count of related objects (i.e., objects that coordinate with each other to produce behavior). High numbers in either metric can signify architectural maintenance issues: High afferent coupling indicates an object has too much responsibility, and high efferent coupling suggests the object isn't independent enough. This month, I'll look at each of these problems and some ways to get around them.

Afferent coupling

Having too much responsibility isn't necessarily a bad thing. For example, components (or packages) often are intended to be utilized throughout an architecture, which gives them high afferent coupling values. Core frameworks (like Struts), utilities like logging packages (like log4j), and even exception hierarchies usually have high afferent coupling.

In Figure 1, you can see a package, com.acme.ascp.exception, with an afferent coupling of 4. This isn't a surprise because the web, dao, util, and frmwrk packages would all expect to utilize a common exception framework.

Figure 1. Signs of afferent coupling

As you see in Figure 1, the exception package has an afferent coupling, or Ca, of 4, which in its case isn't such a bad thing. Exception hierarchies rarely change dramatically. Monitoring the afferent coupling of the exception package is a good idea, however, because drastic changes to the behavior or contract of exceptions in this package could cause ripple effects throughout its four dependent packages.

Measuring abstractness

By further examining the exception package and noting the ratio of abstract to concrete classes, you can derive another metric: abstractness. In this case, the exception package has an abstractness of zero because all its classes are concrete. This correlates with my earlier observation: The high degree of concreteness in the exception package means that any changes to exception will affect all related packages, namely com.acme.ascp.frmwrk, com.acme.ascp.util, com.acme.ascp.dao, and com.acme.ascp.web.

By understanding that afferent coupling denotes a component's responsibility and by monitoring this metric over time, you can shield a software architecture from entropy, which some say naturally occurs even in the most well-designed systems.

Support design flexibility

Many architectures are designed with flexibility in mind when utilizing third-party packages. Flexibility ideally is gained by using interfaces to shield the architecture from changes within third-party packages. For example, system designers could create an internal interface package to utilize third-party billing code but only expose interfaces to those packages that use the billing code. This, by the way, is similar to the way JDBC works.

Figure 2. Flexibility by design

About the author

Andrew Glover is president of Stelligent Incorporated, which helps companies address software quality with effective developer testing strategies and continuous integration techniques that enable teams to monitor code quality early and often. He is the co-author of Java Testing Patterns (Wiley, September 2004).

"When you have learned to snatch the error code from the trap frame, it will be time for you to leave.", thus spake the master programmer.