Modularity Metrics, Part 1: System Cyclicality

System Cyclicality Transcript

Back to the Video Gallery
Watch the video on YouTube


The topic for today’s video is modularity. Modularity is one of the most important tools you have for keeping your software understandable and maintainable. How can we measure modularity? Today I’ll focus on a specific metric, which you may have heard of and which is a good measure of modularity. The metric is called Cyclicality.


We’ll take a look at Cyclicality and use it to figure out the parts of our system that could use improvement. Then, as a bonus, we’ll take a look at a metric that is a derivation of Cyclicality and comes from the object-oriented world. We’ll see how to apply it in the C/C++ domain.


Let’s get started. We’re looking at an open source project called IsoAgLib. Let’s assume we don’t know anything about the system. We’ll look at the metrics to determine which parts of the code are tightly coupled.


Let’s open the Metrics tab. We can see there are several metrics and today we will focus on the architectural metrics. In particular, we’ll look at the System Cyclicality metric. The metric is showing us that 47.7% of the files are in cycles. This means that almost half of the project is included in cycles of some kind.


Let’s look inside the project. Hierarchy is a key tool and will allow us to navigate to the location of the cyclicality and determine why the numbers are so high. We can see that most of the cyclicality is coming from a directory called xgpl_src, which is also where most of our code resides. Once we expand it, we’ll take a look at a directory called IsoAgLib, which is 46% of that 47%.


We’ll drill down further down and see that the directory called comm has 42% of the 47%. This shows us that a very large part of comm. Let’s expand comm. Comm consists of a number of components and we can see the cyclicality of each. TaskController has 6.7% of the 47%. As you scan down, you can see that VirtualTerminal happens to be 20% of the 47.4%, which is a little under one half.


We can drill down further and see that there are two parts to VIrtualTerminal, both of which are pretty closely coupled to each other.


Let’s take a look at a DSM to see if we can view this cyclicality. We’ve expanded the DSM and we’re now looking at IsoAgLib and comm. We’ll open up comm and take a look at VirtualTerminal_Client, which contains almost 40% of the code. This is the part that is very strongly coupled. You can see that part is in impl and part, which are the definitions, happens to be in the root of the directory and is in “*”. It’s all coupled. Whatever the intent was to separate the definitions and the implementation has been lost at this point.


Notice how we were able to drill down and identify the coupling right from the metric. Lattix Architect will give you the tools to determine whether there’s a better way of organizing this code. That’s a different topic, but by using Lattix Architect we can begin to refactor this.


Let’s try one more thing. Let’s use the menu to hide the entire VirtualTerminal subsystem from the project. Notice how all of the metrics were quickly recalculated. We can see that the comm Cyclicality metric was reduced but there remains a lot of coupling. The next area of coupling we should focus on is TaskController, where there is a significant amount of coupling.


Now let’s look at a different cyclicality metric called Intercomponent Cyclicality.