Evolutionary architecture and emergent design: emergency design through metrics

Introduction: Software metrics can help you look for hidden design elements in your code so they can become idiomatic patterns. This phase of evolutionary architecture and emergency design explains how to use metrics and visualization to discover important code elements that are masked by complexity.

One of the challenges of emergent design is finding idiomatic patterns and other design elements that are hidden in code. Metrics and visualization help identify the important parts of the code, thus extracting some design elements. This paper mainly discusses two indices, cyclomatic complexity (cyclomatic complexity) and afferent coupling (afferent coupling). The relative complexity of the cyclomatic complexity measurement method. Incoming coupling indicates how many other classes use the current class. This article describes some of the tools that show and understand these two metrics, and how to help discover design features by combining metrics.

I discussed the cyclomatic complexity in the "test-driven design, part 2nd", but there are some details that are not discussed. One difficulty in measuring cyclomatic complexity through Java™ Tools is the unit of work. Cyclomatic complexity is a method-level metric, but the work units in Java programming are classes. Therefore, the cyclomatic complexity metric is usually expressed as the total complexity or average complexity of all methods in the class. Both of these forms make sense.

For example, the following conditions may occur. Suppose a class contains a very complex method (CC = 40), but there are a number of very small methods (such as the Get/set method pairs common in Java code). Tools such as JAVANCSS report the total complexity of all methods, so the entire class has a high cyclomatic complexity. If you use tools such as Cobertura, which report the average cyclomatic complexity of a class, then this class does not look bad because a lot of simple methods obscure the complexity of that complex method. Because the unit of work does not match, it makes sense to observe the total value and average of the cyclomatic complexity at the same time. If you consider them individually, you may come to the wrong conclusion. The use of these two indicators also helps to eliminate this possibility.

Software index and physical index

In software, the index refers to the application of objective measures to develop the workpiece, so as to judge the characteristics of coarse grained. Unlike physical indicators, such as scales, most software metrics do not reflect some of the characteristics of the real environment. The cyclomatic complexity value (for example, 5) has no unit of measurement; it does not indicate any physical properties of the code. This number only makes sense when compared to the cyclomatic complexity of other code.

Other metrics that make sense for the design are two coupling numbers: outgoing (efferent) and afferent coupling. The outbound coupling measures the number of classes referenced by the current class. It's easy to check for outgoing coupling by simply checking: Open the class you want to check, the reference to other classes in the statistics (fields and parameters). Incoming coupling is more difficult to judge, but more valuable. It measures the number of other classes that use the current class. You can use the command line FU to judge it, or you can use other tools that understand this metric. This tool includes CKJM, an open source tool for running the Chidamber & Kemerer object-oriented metrics set. Although CKJM is somewhat complex to set up and run, it can provide cyclomatic complexity (the sum of cyclomatic complexity for all methods in the reporting class) and the number of outgoing and incoming coupling.

But how do they play their role (especially in design) after the numbers are obtained? Index numbers provide only one dimension of information about the code, and the numbers themselves often don't make much sense. There are two ways to get useful information through metrics. One way is to observe the value of changes and trends over time. You can also combine metrics to provide richer information, and this article describes this approach.

Indicators and Design

I have used the struts code base as an example in several articles in this series, not because I prefer struts, but because it is a well-known Open-source project. Believe me: Hidden design features can be found in most of the world's code! Now that you've used Struts, this article continues to use it to illustrate my point.

The output of the CKJM is text, which can be converted to XML (or it can be converted to another format using XSLT). Figure 1 shows a combination of several CKJM metrics in which the WMC (Weight Methods per Class) is the cyclomatic complexity of the method of the class, and the Ca is afferent coupling.

Figure 1. Tabular form of CKJM index results

Figure 2 shows the same table sorted by WMC:

Figure 2. CKJM index sorted by WMC