Modularity Metrics, Part 2: Intercomponent Cyclicality

Intercomponent Cyclicality Transcript

Back to the Video Gallery
Watch the video on YouTube


Now we’ll take a look at another cyclicality metric called Intercomponent Cyclicality. It comes from Java, or .NET, or strongly object-oriented languages. It’s well known and accepted among object-oriented programmers that you try to avoid cycles within packages. If you’re writing C/C++ code, or if you’re a strongly object-oriented programmer, then a large part of your code is classes. Can we focus on our classes and see what the Intercomponent Cyclicality is? Lattix Architect gives you the tools to do just that.


There is a script in Lattix Architect called Generate Class Views. I will take this project and extract all the classes and all the relationships that pertain just to classes. In C/C++ you define a class in a header file while the implementation is typically in a different file. This script will combine it all together. You’ll get a single class-oriented view. There won’t be any source files or any header files, just classes.


I’ve already run that script so let’s go to the Navigator and load the project. This is an object-oriented project that I’ve loaded. Looking at the metrics we can see that the cyclicality is 38%. Our main interest today is to look at Intercomponent Cyclicality, which is still pretty high. This is interesting. Even though the cyclicality is 38%, meaning that 38% of the classes are in cycles, the Intercomponent Cyclicality indicates that 36% of the classes are in cycles that cross directory boundaries.


Once again we’ll use hierarchy to expand this. Most of our source is in xgpl_src. We can drill down further and see that comm has a lot of our code. Inside comm you can see that VirtualTerminal is 15.4%.


Now let’s go a little deeper and see what we can do about those cycles. Let’s look at the DSM view of the project. When we expand VirtualTerminal_Client we can see that both impl and ‘*’ are coupled together. Since they are in different directories, this coupling leads to Intercomponent Cyclicality being higher.


Let’s use Lattix Architect to refactor VirtualTerminal_Client. Choose Delete Subsystem Retain Children from the Edit menu. This flattens it out so everything is in one directory. As a result, any cycles should not show up in Intercomponent Cyclicality because all the cycles are within the same directory. Looking at the Metrics tab, you can see that there was almost no change to the Intercomponent Cyclicality.


Now we look for the next thing. What is it that VirtualTerminal_Client is in cycles with? If you look at the top level, you can see it’s in a cycle with something in impl. Go to the information pane to find out about this particular dependency. You can see there are some method calls being made. Impl is a low-level set of routines, or a low-level subsystem, and a lot of things depend on it. When you have something in impl that has a dependency on VirtualTerminal_Client, you’re pulling into cycles many things that might be in other subsystems.


Going back to the info pane, you can see that there are two dependencies, which are two method calls. We can navigate to the line in source where they happen to be. Here we see a method being called from a low-level subsystem to an application called VirtualTerminal_Client. There are ways of eliminating that dependency through an inversion of dependency, but that’s not our focus today.


Let’s go back to our Metrics tab. We’re looking at 15.385%. I’m going to hide that dependency as part of refactoring the system. I select Hide Dependency… from the menu and click OK. Now let’s look at the re-computation. Notice how much we reduced Intercomponent Cyclicality. VirtualTerminal_Client doesn’t contribute anything to Intercomponent Cyclicality and we reduced the total value by almost 15%.


That’s the beauty of being able to look at the system in its entirety in conjunction with metrics. Often, it’s a handful of dependencies that contribute to the erosion of the architecture and to poor metrics. You can look at the metric and correlate it to the place in code that is causing that unwanted cyclicality. Once you eliminate the dependency, you can see how much your metrics improve. You can experiment and identify which dependencies are the best to eliminate.