A Case Study on Spring Framework
The Spring Framework is a great application framework and inversion of control container for the Java platform. It is also a great example of high-quality software. Spring Framework is the foundation for all Spring projects
Collectively, the Spring Framework and the family of Spring projects is often referred to simply as “Spring.” Spring provides everything required beyond the Java programming language for creating enterprise applications for a wide range of scenarios and architectures. It has been developed over 17 years.
We analysed the Spring Framework with CodeMR. CodeMR is an architectural software quality and static code analysis tool. You can find analysis report generated with CodeMR at: https://www.codemr.co.uk/case-reports/spring-framework/html/html_report_spring-core/htmlx/lbd/dashboard.html..
Also, the project source code and model can be found on our GitHub page at: https://github.com/CodeMR-Models/spring-framework.
The overview of the project is given below:
On the left side, we can see summary information about the project. It has over 200K lines of code and more than 5K classes.
We can see its modules on the right side. Like Spring Core and messaging webmvc, we see the auto-generated software dependency graphs in the center. In CodeMR, we use the term “working set” instead of modules. Working sets represent a more flexible, logical way of grouping software entities. Working sets can be generated automatically by the tool (according to the module structure of the project) or they can be defined by the user. Metric charts can be constructed for different working sets for analyzing large software into modules.
The pie chart in the Overview tab shows overall quality metric distribution for selected metrics.
This is a circle chart from the Spring Core module. In CodeMR metric charts, software entities like package, class, and method are represented in a hierarchical way, which reflects their actual encapsulation scheme in code. In this chart, inner circles represent classes and outer circles represent packages, and the size of circles shows line of code. Heat map colors show the coupling quality attribute level. Where green shows low-coupled classes, and red shows highly coupled classes. As you see, there is only one highly coupled class and most classes are loosely coupled.
Color of chart shapes represents the metric of the corresponding software entity. We categorize each metric into five levels: low, low-medium, medium-high, high, and very high. Because red color is associated with danger in most cultures, the red color indicates a high value of selected metric. The heat-map color representation indicates the metric value of the entity changes the color scale to a green-to-red spectrum (low → high) .
The size of chart shapes is proportional to the line of code metrics of the corresponding software entity.
This is a CodeMR graph for the Spring core module. In this graph, nodes represent classes and edges represent relations between these classes, different edge colors show different types of relation, outer polygons represent modules or packages again, size of nodes show class line of code, and node color shows the complexity. Green is low; red is high. Also, node shape indicates the coupling degree. The more corners means it has more interaction points, so it is more coupled. As we see in Spring Core modules, most classes have good quality attribute values, as they are green and circle-shaped. There are a few complex classes with the orange and red color, but their complexity can be managed if they are well tested. Also, the module structure seems well distributed.
This is another CodeMR graph that shows only inheritance relations in one picture. We can see the place of classes in the inheritance tree. These are the classes with a high depth of inheritance value. We can also see impact of complex classes.
Inheritance graph of Spring context module: