Software evolution is a multifaceted subject. For example, engineers can focus on the plain historical aspects that describe how the codebase of a system changes over time, using tools like SvnStat, Ohloh or more extravagant solutions like Code Swarm and Gource. It is also possible to look at how the quality and maintainability of the project rises and falls over a project's lifetime. Squale and Sonar are examples of tools used for this purpose. Finally insights on the structure and quality of the code itself can be gathered by exploiting a wide range of code metrics. Our Facets of Software Evolution application brings together these different facets of software evolution in one place, harnessing the functionality and flexibility of SOFAS to provide different interactive software evolution views or 'facets' of a project. In fact, SOFAS provides a great deal of different analyses that can be used and combined to examine the quality and evolution of a software system. However, it still lacks effective ways to visualize the data produced. Our application aims exactly at filling this gap. Starting from just a version control repository URL, it combines different SOFAS analyses to reconstruct a detailed view on the history and quality of the software project being studied. As of now three facets have been implemented. In the following, we briefly describe each of them:
This is the default view shown to anyone visiting the analysis page of any project. It includes 3 different visualizations:
- Overview Pyramid. It gives a concise view over the complexity, coupling and hierarchy of every major version of the system (users can scroll through the different version using a slider). This pyramid, based on the Metrics Pyramid introduce by Lanza and Marinescu in Object-Oriented Metrics in Practice, consists of three parts targeting different project properties:
Inheritance - Displayed in the green area at the top, it shows how much inheritance is used in the system.
Size and complexity - Displayed in the yellow area on the left hand side, it combines several known metrics that are useful to assess how complex and big the system is.
Coupling - Shown in the blue area on the right side, it shows to which extent classes are coupled to each other.
- Overview Pyramid Evolution. It is a flat representation of the pyramids of all the major versions of a system. Its main purpose is to give an overall impression on how the project evolved, specifically if the Overview Pyramid metric ratios have gotten better or worse over time and how they compare to each other.
- Code Disharmonies List. It displays a summary of all the code disharmonies found for every major version of the system.
Entity Metrics Facet
This view contains two different browsers that can be used to explore every major version of the system (its packages and classes) and view a wide range of associated metrics and disharmonies:
- Project Treemap. It gives an overall view of the project structure and hierarchy and the metrics associated to its entities, its classes and packages, using an interactive treemap. The color and size of the rectangles representing the classes can be bound to different metrics (LOC, NOM, WMC, NOA, Code Disharmonies, etc.). When hovering over a specific entity in the map, the side panel will show the values of several related metrics. A slider allows the user to "go back in time" and examine the treemap of any past major version of the system.
- Treebrowser. It serves as a browser for two different visualizations, which are drawn for any selected project's entity (classes and packages):
Metrics Kiviat Diagram
Kiviat diagrams (also known as spider, polar or radar graphs) provide a way of visualizing changes over time in a collection of n-ary tuples. In our case, the tuples contain metrics of a given entity and tere is one tuple for each release the entity existed in. Below the diagram a slider allows the user to go through the different releases of the selected entity and view the associated metrics.
This view shows the distribution of ownership of a selected entity between the projects's developers. The size of each rectangle in the treemap respresents the code ownership for a specific committer, i.e., committers associated with a larger rectangle have a stronger ownership than those with a small one. Ownership information is calculated using four different techniques: code churn, lines of code added, lines of code deleted and number of commits. The user can select the one that the visualization should use.
Project Evolution Facet
This view illustrates the history of the project ever since the very first commit to give an overall impression on how the project has evolved since its inception. Unlike the other views, here the data is not presented per-release but for the entire project's lifetime. It uses two visualizations:
- Lines of Code. In this view the commits are plotted on the X axis while the Y axis represents the number of lines of code. As such, the X axis does not represent linear time. However, timestamps are provided at regular intervals to ease orientation. Hovering over the plot will show the commit information at any point on the graph, such as the date, the name of the committer, how many lines of code the project has at this point, and if the commit represented the release of a new version of the system, the name of the release will be shown as well (along with a small colored circle).
- Commits per Month This view plots on a graph the number of commits by every committer for every month in the project's history. Hovering over the column sections reveals information on the respective committer as shown in the screenshot below.
How does it work?
When visiting the main web page of the Facets front-end, the visitor is presented with the simple submission form shown underneath. The user needs to enter only the URL of the project repository, select if it’s a git or SVN repository, and give a name for the analysis request. The analysis request is submitted by the click of a button. The back-end first does some automatic sanity checks on the repository and if successful, the user is supplied with two URLs. Both lead to the new analysis page, however one of the links contains an additional argument that contains a token. Using the link with the token will allow the visitor to delete the analysis. With this simple method, only the creator of an analysis can delete it, without the need for a user registration form or a user database.
- Giacomo Ghezzi and Harald C. Gall "A Framework for Semi-Automated Software Evolution Analysis Composition" Automated Software Engineering, Vol. 20 (3), 2013. (Journal Article).