Evolution of MonoDevelop Structure

In this case study article, we analyze MonoDevelop IDE using Designite tool. We present how the structure and smell profile evolved (during 2011 to 2015 timeframe) with the help of a few graphs. By reading this article, you will know how you can perform a grounded analysis of the evolution of any codebase using an appropriate tool.

MonoDevelop [1] is an open-source IDE that supports multiple platforms. The history of software could be traced back to late 2003 when a few developers from the Mono community began migrating SharpDevelop from Windows (Windows Forms) to Linux environment (Gtk#) [2]. The oldest available version (0.8), along with many other recent versions, of MonoDevelop could be found at the GitHub page [3] of the software.

MonoDevelop is under active maintenance and development. It is interesting to see how the structure of the software evolved in recent years. We took 15 different versions of the software from version 2.5.90 (released on 1st March 2011) to version 5.9.2.2 (released on 18th May 2015) and analyzed them using Designite [4]. Using Designite’s Excel export feature, we generated the excel sheets and analyzed the results.

Let us see how the structure and smell profile evolved during this period with the help of a few graphs that present different perspectives of the structure of MonoDevelop.

First, let us look at the change in the size of the software in terms of LOC (Lines of Code). Figure 1 shows the change in the size of the software for the selected versions.

Mono1
Figure 1: LOC (Lines of Code) for the selected versions of MonoDevelop

The size of the software increased from 584 KLOC to 795 KLOC during the first few selected versions and then it started decreasing till it reached to 425 KLOC. The latest selected version is of 504 KLOC. Did you notice a sudden drop in size from version 2.8.8.4 to version 3.0.4? This sudden drop in size could be due to refactoring (for instance, to remove duplicate code) or due to separating components from the project. Let us see a few more graphs that may provide more information for making an informed guess.

Mono2
Figure 2: Average LOC per method for all the selected versions of MonoDevelop

Mono3
Figure 3: Average WMC (Weighted Methods per Class) for all the selected versions of MonoDevelop

Mono4
Figure 4: Maximum WMC (Weighted Methods per Class) for all the selected versions of MonoDevelop

Figures 2 to 4 show that the quality of the software has improved in terms of complexity (after version 3.0.4.6) as well as the average size of a method (after version 2.8.8.4) has reduced. Therefore, we can make an informed guess that MonoDevelop has gone through considerable refactoring after version 2.8.8.4.

This sounds ok so far. Now, let us take a look at the “design smell density” (i.e., the average number of design smells found per thousand lines of code). Designite provides this number in the summary of the analysis.

Mono5
Figure 5: Design smell density (per KLOC) for all the selected versions of MonoDevelop

Oops! The design smell density has increased after version 4.0.3.13. Isn’t interesting? We have seen that the complexity within the project and the average number of statements per methods have reduced. However, something has gone wrong with the project that has been reflected by the increased number of design smells after version 4.0.3.13.

Let us drill down deeper to see what kinds of smells came up in the right half of the smell density figure. Figure 6 to 9 present the detailed design smells detected by Designite in the MonoDevelop project.

Mono6
Figure 6: Abstraction design smells for all the selected versions of MonoDevelop

Mono7
Figure 7: Encapsulation design smells (Deficient Encapsulation) for all the selected versions of MonoDevelop

Mono8
Figure 8: Modularization design smells for all the selected versions of MonoDevelop

Mono9
Figure 9: Hierarchy design smells for all the selected versions of MonoDevelop

What do we observe in the above four figures? We can see that most of the design smells has reduced towards the right side. However, Cyclic-dependent Modularization is the biggest component from the Figure 8 that is contributing massively towards the increased design smell density of the project towards the right half side. Another big contributor is the Unutilized Abstraction design smell.

Summary

The analysis of the evolution of MonoDevelop reveals something interesting: though the size of the code dropped considerably during some releases and the generally got improved, the design smell density increased due to the introduction of specific smells (especially Cyclically-dependent Modularization smell).
So, what is the key takeaway from this case study? Using relevant design analysis or metric tools can reveal interesting insights about the quality of the software.

References

  1. MonoDevelop website. Available at – http://www.monodevelop.com/ [Last accessed on 2nd July 2015]
  2. MonoDevelop Wikipedia page – Available at – https://en.wikipedia.org/wiki/MonoDevelop [Last accessed on 2nd July 2015]
  3. GitHub – MonoDevelop page. Available at – https://github.com/mono/monodevelop [Last accessed on 2nd July 2015]
  4. Designite website. Available at – http://www.designite-tools.com [Last accessed on 2nd July 2015]