Home | Print | Archive | Blog | Contact
A Newsletter for Unisys EAE and Agile Business Suite Clients | January 2019

Calculating Code Complexity with the MATRIX Tool

The term “cyclomatic complexity” refers to a software metric used to indicate the relative complexity of a given method.

The technique for determining cyclomatic complexity was first introduced in a paper by Thomas McCabe in 1976. Instead of inefficiently counting the lines of code in a method, McCabe devised of a way to assign a numerical value that speaks to the complexity of the method rather than its overall size. To arrive at this value, McCabe created a control flow graph of the code showing the basic blocks of code, with an edge between the blocks if the flow can pass from one block into the next.

Using this graph as a guide, the complexity of a single method can be calculated using following the formula, where a “node” is a block of code and an “edge” is the logical flow between two nodes:

Complexity: Edges-Nodes+2

Once you determine this numerical value, it’s possible to identify overly complex methods that could benefit from some form of refactoring.

A sample flow graph showing the nodes and edges for an Agile Business Suite (AB Suite®) method – along with the accompanying logic – is provided below.

The nodes in the example illustrate blocks of code, which can be: lines that don’t affect the flow
(the blue circles); “End” statements that terminate a block (the brown circles); database read looping statements (the yellow circles); or blocks that can affect the flow, such as the green diamonds used here to represent conditional statements. The edges – the lines between nodes – show the possible paths through the graph.

In this particular graph, there are 11 nodes and 13 edges. Here’s how these figures are applied in McCabe’s formula:

Complexity: 13-11+2=4

While useful as a way of comparing the relative complexity of two methods, this figure also indicates the number of distinct test cases required to completely test the method. The complexity of the above figure is four, which means four separate cases are needed to test every possible flow permutation through this method.

Aside from offering a useful indication of how hard it will be to fully test a method, the complexity figure also gives you a good idea of debugging difficulty. In fact, studies have shown a relationship between complexity and the frequency of defects in the code. So, refactoring not only makes the code easier to understand and test, it also reduces the potential for defects. A simple rule of thumb is that a single method should have a complexity of less than 20 and ideally under 10. Methods with a complexity over 40 are very difficult to debug and test thoroughly due to the sheer number of cases required to fully test every path through the logic.

Complexity, Simplified

The Unisys UK team developed a powerful query tool, called Model Analysis Tool for Research, Investigation, and XREF (MATRIX), which can assist with calculating the complexity of your AB Suite application. The example flow graph shown above was created automatically by MATRIX parsing the
lines of logic in the following AB Suite method.

Clicking on a node in the flow graph highlights the corresponding block of code and the edges associated with it, making it easy to understand how the logic flows through a method. Likewise, clicking on a line of code highlights the corresponding node and the edges leading in and out of the node.

With MATRIX, you’re able to perform a background task that calculates the complexity of every method in your AB Suite application. When this calculation completes, you’ll receive a spreadsheet showing the results, along with an average complexity for the entire system.

If you run this process at periodic intervals – say, once a month – you can use the results to determine if your application is getting more complex over time. While the total lines of code in your application
or an individual method may increase, the average complexity should decline as code is refactored
into smaller, more maintainable methods. If complexity is increasing, you may want to consider refactoring parts of the system using such new AB Suite features as method calls and
object-orientated programming.

MATRIX simplifies this process by scanning the application for similar blocks of code that could be refactored into a method. The image below shows an example of this process. MATRIX scanned an entire AB Suite system for code similar to the block shown in the upper-left portion of the image. It found similar blocks in four Ispecs, so there is the potential to refactor this code into a single method.

Subscribe | Unisys.com | Comment | Newsletter Archive