This chapter provides an overview of Sonar, presenting the objectives and features of the platform, and highlighting how developers and software quality benefit from it. It follows an overview of the platform's architecture, so as to gain a better understanding about how Sonar analyzes and measures quality. Finally, the chapter closes by discussing the Sonar community and its ecosystem. In this chapter we cover:
What is Sonar?
Features of Sonar
Covering software quality on Seven Axes
Architecture of Sonar
Source code analyzers
The Sonar community and ecosystem
Sonar is a software quality management platform primarily for Java programming language, enabling developers to access and track code analysis data ranging from styling errors, potential bugs, and code defects to design inefficiencies, code duplication, lack of test coverage, and excess complexity. Everything that affects our code base, from minor styling details to critical design errors, is inspected and evaluated by Sonar.
Consider Sonar as your team's quality and improvement agent. While the primary supported language is Java, more languages are supported with extensions or commercial plugins, for example C, PHP, and JavaScript. At the time of writing, more than 10 languages were supported with plans to add more in the future. The additional languages are supported in the form of plugins, taking advantage of the platform's extensible and flexible architecture.
Sonar collects and analyzes source code, measuring quality and providing reports for your projects. It combines static and dynamic analysis tools and enables quality to be measured continuously over time. More than 600 code rules are incorporated into the platform, checking the code from different perspectives.
Rules are separated into different logical groups and each one contributes at a different level towards the overall quality of the project in case. Analysis results, code violations, and historical data are all available and accessible through a well-thought-out user interface consisting of different components, with each one serving and fulfilling different needs and scopes.
The Sonar platform analyzes source code from different aspects. To achieve this, Sonar drills down to your code layer by layer, moving from module level down to class level. Picture this as a vertical movement through your source code from top to bottom components. At each level, Sonar performs both static and dynamic analysis producing metric values and statistics, revealing problematic areas in the source that require inspection or improvement. The analysis is not a monolithic procedure but examines code from different perspectives, introducing the concept of axes of quality. The results are then interpreted and consolidated in a very informative and visually appealing dashboard, enabling you to form an opinion about defective code and quality testing over projects. You can now take educated decisions as to where to start fixing things in a cost-effective manner, reducing the technical debt.
Although Sonar can be run as a one-off auditor, where the platform really shines is when you have it track and check your source code continuously. While a single inspection proves to be useful at times, it does not make the most out of the platform. The intended use is to have Sonar integrated into the team's development process, exploiting the platform's true capabilities.
If all these sound complex and advanced, they are not. It is a matter of a single download and running a script to have Sonar up and running, waiting to assess our code. Afterward, we can choose among different methods of how to import projects into the platform for analysis.
What makes Sonar really stand out is that it not only provides metrics and statistics about your code but translates these nondescript values to real business values such as risk and technical debt. This conversion plays a major role in the philosophy of the platform enabling a new business dimension to unfold, which is invaluable to project management. Sonar not only addresses to core developers and programmers but to project managers and even higher managerial levels as well, due to the management aspect it offers. This concept is strengthened more by Sonar's enhanced reporting capabilities and multiple views addressing source code from different perspectives.
From a managerial perspective, transparent and continuous access on historical data enables the manager to ask the right questions.
To better illustrate this, the following are some possible cases discussing quality and source code matters based on feedback from Sonar, either visual or textual:
Case 1: Complexity has jumped up lately; should we further examine the design and implementation of the recently added features? (Notice the line that represents overall complexity increasing close to 9.000.)
 |
Case 2: Many major violations popped up during the last iteration. Are things moving too fast? Is the team taking more than it can handle? What about pace? (Sonar reports 589 major code violations.)
 |
Case 3: Documentation is lacking and team composition is about to change. Let us clarify and better explain what our code is about. At least the public API! (Big red boxes represent undocumented public APIs.)
 |
Sonar in the development environment acts as a quality management center. It is the place of reference when code quality matters arise, and sessions with team members drilling down views, exploring deficiencies and discussing software design and its implementation are not uncommon. The ease of the installation process and the broad accessibility by the web interface make it a perfect choice to inspect and share code quality among managers and developers.
An extra step is added to the developers' lifecycle, that of quality review and inspection. After updating and committing code, tests are executed within the context of the build server, producing a fresh artifact. Then, Sonar takes over collecting and analyzing source code and test results. Once the analysis process is complete, the Sonar dashboard is updated with inspection data reflecting the latest changes.
It is vital not to force Sonar into the development process but let the team embrace it.
Let us put technical details and issues aside for a moment and focus more on the psychological aspect of this process as a whole. There is no more rewarding experience for a developer than watching the results of his/her work on a daily basis, experiencing how his/her actions directly reflect upon the improvisation of the final product. Eventually, Sonar proves to be an essential part of a development setup, while the whole process becomes second nature to the developer.
There is one obstacle though that every development team will meet, that of the fear barrier and how to get over it. And by fear, we mean the fear to expose the quality of team members' source code, or most importantly the lack of it. And this is perfectly normal and expected.
Note
Overcoming the fear barrier
What you can do is run Sonar undercover for a couple of iterations, touching and bettering only your code, escaping comments and reviews on team members. Another approach would be to use it only as an information tool, without emphasizing it. Once you start writing better code, and have substantially improved and corrected errors, you can then host a team session highlighting the platform, presenting the positive effects upon the project, in an effort to encourage team members to use it for improvisation.
One good point would be to emphasize on how rewarding the experience is to watch quality grow over time in response to code corrections and design changes. This warm feeling is the best incentive for each and every developer.
The Sonar platform comes with a vast array of components in order to provide insightful and accurate information. Moreover, its flexible architecture allows functionality to be added on demand via a plugin system.
Let's take a closer look at the features the core platform has to offer:
With Sonar's project dashboard, you gain quick access to and insight about all your projects through a comprehensive dashboard. The dashboard presents vital quality metrics in an efficient way, highlights sections which require your attention, and finally includes common interface practicalities, such as sorting, adding, or removing columns to make browsing easier. The majority of the user interface is implemented in AJAX and the transitions between the different views and drilldowns are quick and smooth. Likewise, the components of the platform from simple to more complex ones are very responsive and react in a timely fashion to your actions.
 |
The dashboard is fully customizable, and you can select which metric columns each view contains and reorder them as you like. The ability to internationalize the platform is a huge plus allowing you to present a total solution covering every aspect, from pleasant and practical interface to language settings. Generally speaking, language friendliness is very much welcomed if you intend to provide a Sonar instance to a less-technical audience.
If you want to take look at the Sonar dashboard in full swing, point your browser at Nemo, a Sonar demo instance by SonarSource S.A. hosting the platform's own source code among other well-known open source projects at http://nemo.sonarsource.org.
More than 600 rules are incorporated into Sonar, performing simple checks to complex calculations. Rules can be fully parameterized to meet different development needs, and if this is not enough, with a little help from the lively community, you can even implement your own, covering every possible need.
The strictest Sonar profile includes about 720 rules, but probably you won't ever need to activate it. It is not even suggested to use all of them at all. The objective is to provide as many coding rules as possible and let the developer make choices accordingly, assigning them to custom profiles for projects. Obviously, there is the ability to host multiple different profiles with specific sets of rules and further assign these profiles to different projects for maximum flexibility.
Metrics are necessary to form objective and reliable opinion on any piece of software. Like in every science or process, metrics are essential to measure and reproduce behavior and functionality, and help evaluate/compare source code, establishing a common ground among different pieces of software. In other words, metrics form a common denominator for all software and they have become an integral part of the development process.
Note
Not a magic bullet
Sonar is not a magic bullet. A solid development process, creativity, dedication, and practical design are still some of the necessary virtues to create a successful and quality product. Writing code for the sake of metrics is basically cheating. Tricking the system to produce desirable results, disconnected from the functional requirements, is as you understand under-productive. Such a bad practice only detracts from the final product instead of improving it.
One use for software metrics, which does not have to do directly with quality is that they can also provide insight and deeper knowledge about the source code, revealing potential pitfalls, and providing a safe guideline for new developers to follow. Sonar includes all classical metrics related to software development, some of them being:
If you have at least a couple of development years under your belt at some time or another, you have probably wondered how you could ever manage without writing any tests for your code. Untested software results in an unstable product, not working as expected. Experience shows that the first thing the end user does with an untested feature ends up to be unexpected and never taken into consideration during development. Random input, experimenting, or using the feature/component for something other than what it was designed for, are all viable and very real cases. While clients demand dynamic help systems and comprehensive manuals, they never ever read them, expecting the software to meet their expectations one way or another.
Software testing verifies that a feature will work as expected and meets design requirements. However, writing tests for the sake of testing only to cheat the metrics, covering low-risk code, and leaving out crucial areas, is pointless. This kind of testing, while it consumes time and resources, adds nothing to the final quality of your product.
Sonar identifies high-risk software pieces and locates untested code not only at line, but even at branch level, taking into consideration all possible outcomes of a conditional operation. Additionally, Sonar provides useful statistics concerning test successes and total duration.
 |
Knowing where quality suffers and what aspects of your software need to be strengthened is one thing, specifically locating these problematic areas is another. Sonar features smart components as the metrics radiator that in combination with the dashboard allow you to drill down effortlessly to your source code reaching classes that require attention quickly. It may sound like a complex investigative task or an alternative search tool for your source code but this is not the case.
Drill down is a standard professional method used to browse code. You set a focal point, undocumented code for example, and move downwards from summary information to more detailed data, subsequently exploring modules, packages, and classes.
Sonar stores all analysis results in a database, preserving historical data for future reference and comparison, enabling you to track the evolution of your code. At any time you can check out a past version of your codebase from the repository and add it to the project's time line for comparison. Examining a data point in isolation can enlighten your team about the state of the code in the given time frame, but the information accumulated by the historical data proves to be invaluable in the long run, helping to determine the best approach for the health of your project.
 |
You can examine the progress of your code using one of the three different components available: the Time Machine, the Motion Chart, and the Timeline. Each component can be dynamically customized to access historical data on all metrics supported. The Motion Chart, the fanciest of the components, features an animated bubble chart tracking metrics in four different dimensions: the X and Y axes, plus the color and size of the bubbles.
Maven is a build automation tool like Ant, streamlining the steps of the build process in software development. Checking out code, compiling, generating documentation and reports, running tests, producing artifacts, and finally deploying them, are some of the goals supported by Maven and implemented via plugins. Different profiles described in XML configuration files dictate the execution steps that take place during the build process while providing configuration details.
The Sonar platform takes advantage of the Maven goal-oriented philosophy, simplifying configuration. All you have to do is add the Sonar Maven Plugin into your project to get support for Sonar-oriented goals. The only requirement is to have the Sonar server up whenever the goal is executed. Basically, the setup requires zero or minimal configuration if you are familiar with Maven.
Much thought and work has been put into the platform's user interface in regards to both appearance and behavior. The clean interface is mostly self-explanatory but if you have any queries or feel like clarifying some things more, there is plenty of documentation and media available within the Sonar community covering many topics, from traditional getting started wikis to screencasts exploring advanced Sonar features. It is important to note here the web nature of the user interface, accessible straight from your browser.
Sonar introduces a new paradigm on measuring quality without trying to reinvent the wheel in the field of metrics and rules. While it features its own implemented set of rules, under the hood most work is handled by familiar and long-trusted tools. Sonar unifies these tools, leveraging existing functionality, collecting output, and finally refining the results to follow suit with the platform's objective.
As SonarSource puts it:
Sonar can transparently orchestrate all those components for you.
Obviously, the procedure of running these tools manually in sequence to produce raw values and statistics is now rendered obsolete, since Sonar automatically streams the whole process in one combined analysis step.
Sonar features a standard role-based authentication system allowing you to secure your instance, create as many users as required, and assign them to groups. A user can belong to more than one group, while access to the various Sonar services and functionality can be fine-grained by assigning appropriate roles.
Two groups have a special status in Sonar:
Of the four roles available in Sonar, one is global, referring to the instance, and the three others are attached to projects:
Global Administrators: Can perform all administration functions for the instance: global configuration, personalization of the Time Machine, and the home page
Project Administrators: Can perform administration functions for a project by accessing its settings
Project Users: Can navigate through every service of a project, except viewing source code and settings
If a global security system exists within your environment, such as Atlassian Crowd SSO, LDAP, or Microsoft Active Directory, you can delegate all Sonar authentication function to these systems using the appropriate plugins.
The Sonar platform is extensible via a plugin system. More functionality can be added using plugins, either open source or commercial. A dedicated repository located at http://sonar-plugins.codehaus.org/ hosts the Sonar plugin library. From there, you can choose and download the plugins you require for your Sonar instance and read documentation and installation instructions specifically written for each one separately. Plugins enable Sonar to measure more programming languages, add more metrics and rules, and integrate the platform with third-party systems such as LDAP or Continuous Integration build servers.
Some of the more interesting plugins and a brief description of what they do are shown in the following list:
PHP: Analysis using PHP Unit, PHP Depend, PHP MD, and SQLI CodeSniffer
Groovy
JavaScript
C, C#
Web: currently supports analysis for JSF and JSP pages.
Build stability: Reports on stability of project build using Continuous Integration engine data
Rules meter: Gives information on the level of activation of projects' quality profiles
Sonargraph: Provides architecture governance features accompanied by metrics about cyclic dependencies and other structural aspects
Useless code: Reports on the number of lines that can be reduced in an application
PDF Report: Generates a PDF report with analysis results
Timeline: Displays measures history using a Google Timeline Chart to replay the past
Quality Index: Calculates a global Quality Index based on coding rules, style, complexity, and unit-testing coverage
Technical debt: Calculates the technical debt on every component with breakdown by duplications, documentation, coverage, and complexity
SQALE—Quality Model (Commercial): An implementation of the SQALE Methodology
Hudson/Jenkins and Bamboo: Enables to configure and launch Sonar analysis from Hudson or Jenkins continuous integration engines
Crowd and LDAP: Enables delegation of Sonar authentication to Atlassian Crowd and to LDAP or Microsoft Active Directory respectively
Switch off violations: Excludes some violations in a fine-grained way
IDE:
Supports French and Spanish languages
First of all, it is important to point out that quality is a perceptional concept and quite subjective. One way to define software quality is through abstractions and examining it from different perspectives.
Take a moment to read the following lines:
I cdnuolt blveiee taht I cluod aculaclty uesdnatnrd waht I was rdgnieg. The phaonmneal pweor of the hmuan mnid. It deosn't mttaer in waht oredr the leteerrs in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit pclae. The rset can be a taotl msess and you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.
The preceding text does not contain one single word spelled correctly but proves to be readable. The preceding paragraph tests the human brain's ability to recognize common patterns rather than convey a message to the reader. From a product perspective, someone could support that although the text is flawed it does the job, since it manages to remain understandable. But this has the side effect of deteriorating the final reading experience, requiring additional effort to reconstruct the words and phrases. The reader unconsciously stresses his mind in an effort to adapt and decipher the messed-up words, sharing focus between restructuring text, and understanding what is actually written, a not-so-pleasant user experience. On the other hand, the editor assigned to improve or add to the text would have to cope with this non-standard writing practice delaying the whole process.
Switch the corrupt text for a software product's source code. The reader is now the end user of the product and the editor the developer. They both experience product quality differently, each one from their own views. The end user from a functional perspective while the developer from a structural one.
Generally speaking, it is common to separate quality into:
To measure external quality the product is treated like a black box, testing and interacting its exposed features, observing behavior, and reassuring that it works as expected according to the requirements.
 |
To measure internal quality, esoteric inspection of the software is required. The structure of the source code is analyzed and evaluated against coding standards and practices. As for software design, it is necessary to examine at what level it adheres to basic principles of software architecture. This approach of measuring quality is referred to as a white box approach because it deals with the software's internal workings, peeking inside source code. The Sonar platform does exactly that, measuring the internal quality of a software piece. However, it is important to note that high internal quality does not enforce or guarantee external quality, but it indirectly betters it in terms of its overall outcome.
Software quality measurement is a quantitative process summing up weighted attribute values, which in part describe specific software characteristics. For each characteristic, a set of such measurable attributes is defined, and the existence of such characteristic, or its quality factor, is directly correlated to those attributes.
As a matter of fact, quality is rated along many different dimensions. Likewise, Sonar classifies associated attributes and metrics in seven dimensions, seven technical axes of quality which the Sonar team prefers to cal them as:
The seven deadly sins of a developer.
Overall, Sonar defines the following technical axes:
Coding standards—respect coding standards and follow best practices
Potential bugs—eliminate code violations to prevent vulnerabilities
Documentation and comments—provide documentation especially for the Public API, the source code
Duplicated code—isolates and refines duplications, Don't Repeat Yourself
Complexity—equalizes disproportionate distributed complexity among components; eliminates complexity if possible
Test coverage—writes unit tests, especially for complex parts of the software
Design and architecture—minimize dependencies
Note
DRY—Don't Repeat Yourself
Don't Repeat Yourself is a programming principle aimed at reducing repetition of code. The DRY principle is stated as:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Source code written with this principle in mind is obviously easier to maintain. When a bug arises, there is only one single point in the source responsible for the malfunction and patching this point would suffice, without the need to modify other parts of the software.
The core engine of the platform, Squid, is supported by additional code analyzers which Sonar orchestrates together to measure quality.
The following diagram represents the upper-level components of the platform and how they interact with each other:
 |
1. An analysis request is triggered using one of three possible methods:
2. Sonar receives the request and starts analyzing the project's source code. The analysis is based on the project's Sonar profile activating any additional plugins or reporting capabilities, if any.
3. When the analysis is over, results are stored to a database for future reference and history tracking.
4. Finally, the user interface and its components are updated with the new data. You can access data from your browser and the web dashboard. Conveniently, Sonar reporting is also made available within your IDE, either Eclipse or IDEA, allowing you to review and correct code violations on the spot.
In a continuously integrated environment, the analysis process is triggered by the build server. The server checks out source code from the repository, compiles and executes all unit or integration tests, after which it produces the necessary builds. Finally, Sonar takes over analyzing the source. A good practice for a time-consuming process such as this is to trigger it once a day, when developers are inactive. The process is then called a nightly job and the final build produced a nightly snapshot. Next time, developers will have access to the latest data and reports about the project, enabling them to review how recent changes affected the overall quality of the project.
To analyze code, Sonar utilizes some of the most popular and proven tools available in the open source community. These tools pass through source code performing standard checks reviewing errors and possible bugs, each from their own perspective. The nature of the checks range from minor styling ones, for example the detection of unwanted trailing spaces, to more complex ones that easily promote to potential bugs, such as unchecked variables eligible to result in null references. Since version 2.1 Sonar provides its own rules engine too, based on Squid.
Sonar includes the following five analyzers:
Sonar's core analyzer Squid, works on Java dependencies and calculates object-oriented metrics. It implements the visitor pattern to visit dependencies between methods, fields, classes, and packages. Some of the metrics calculated are the following:
RFC—Response for Class
LCOM4—Lack of Cohesion Methods
DIT—Depth of Inheritance Tree
NOC—Number of Children
Checkstyle ensures that all source code adheres to coding standards. Its main duty is to check code from an aesthetic perspective with emphasis on layout and styling. However, during its development more checks were added straying away from the initial coding style and standards concept. Now Checkstyle is capable of performing broader checks like identifying class design problems, duplication, and common bug patterns. Checkstlyle, and the rest of the tools we are going to examine here, can also run standalone.
Note
Bug patterns
A bug pattern is badly structured code that under certain circumstances can produce errors. These vulnerabilities may not always fail a test case but can potentially lead to memory outage, performance degradation, security breaches, and many other problems. Such common error-prone structures have been identified and standardized, so that they can be identified easily by source code analyzers.
According to its creator, a standard definition for the PMD acronym does not exist. In any case, the following are some interpretations taken straight away from the What does it mean section of the project 's SourceForge page:
Project Mess Detector
Programs of Mass Destruction
Project Meets Deadline
Head on to PMD's home page for a more comprehensive list.
PMD scans Java source code and reports on problems such as the following:
Possible bugs—
empty/try/catch/finally/switchstatementsDead code—unused local variables, parameters, and private methods
Suboptimal code—wasteful
String/StringBuffercodeComplex expressions—unnecessary
ifstatements,forloops instead ofwhileDuplicate code—copied/ pasted code
FindBugs performs static analysis to check source code and trace bugs and defects. It covers many different aspects such as vulnerabilities, malicious code, performance, and coding standards.
Cobertura, based on the jcoverage Java library, is used to calculate the percentage of code accessed by tests and identify which parts of your source code lack test coverage. Additionally, it calculates cyclomatic complexity for each class and the average cyclomatic complexity for each package.
Clover emphasizes more on test coverage, providing a rich user interface and can be easily used as a standalone tool, offering a complete quality testing solution.
Sonar, like every respectable open source project, comes with a thriving community and a vibrant ecosystem built around it.
The community features four separate mailing lists to discuss everything Sonar:
A dedicated issue tracker to track Sonar development and submit tickets can be found at the following URL:
http://jira.codehaus.org/browse/SONAR
A comprehensive documentation wiki maintained by Sonar's team members can be found at:
http://docs.codehaus.org/display/SONAR/Documentation
The official Sonar blog can be found at:
http://www.sonarsource.org/category/blog/
Additionally, Sonar has a strong presence across social networks:
If you want to learn more about Sonar or even write your own plugins for the platform, Sonar's plugin ecosystem in combination with a friendly and welcoming community provides everything you will need.
You can subscribe to the developers' list, request access to Sonar's source control management system Forge, and benefit from the continuous integration environment that has been set up to serve development needs by navigating to the following URL:
Sonar was founded in 2008 by SonarSource S.A., a Swiss company that brought forth a bold statement:
SonarSource S.A.: democratize access to software quality management
Thus Sonar was born, in an effort to fulfill the company's objective to create a platform that would enable easy and continuous access to code quality metrics. The big picture was the platform to achieve such high adoption rates, capable of establishing it as a commodity in development teams along with IDEs.
The company did not only succeed, but pushed things further with the introduction of the Continuous Inspection paradigm similar to the Continuous Integration practices, a movement that is now considered to be a best practice among development teams and members especially in the context of an agile environment.
SonarSource, since its inception has jolted the software industry, creating an innovative platform that caused significant impact as long as quality management is considered. In comparison to other tools, the Sonar platform was revolutionary, inventing a new method towards quality inspection, which later became a standard practice under the term Continuous Inspection. Therefore, in 2010 it received the Jolt Productivity Award for providing a manager's best friend with highlights on the detailed dashboard, the tracking of historical data, and code analysis from different perspectives.
After initial versions of the platform were publicly released, Sonar was presented at numerous JavaOne conferences and was recommended as the tool of choice to measure, track, and gain access to code quality data. In most cases, the platform was sitting next to a Hudson/Jenkins build server in a continuous integration setup.
The Sonar platform is open source and distributed under the GNU Lesser General Public License Version 3, the most widely used license for free software. This means that you can modify and redistribute the platform freely as long as all software and modifications released still remain under the GPL Version 3.
Apart from the core platform and the free plugins developed and gardened by the community, SonarSource company offers commercial products built around the extensible Sonar ecosystem. Worth mentioning is the SQALE plugin, a full implementation of the Software Quality Assessment method based on Lifecycle Expectations. If you want to learn more about this method you can point your browser at http://www.sonarsource.com and navigate from there to the plugins section.
Additionally, among other services, SonarSource company offers professional support carried out by Sonar's core contributors and accepts requests to develop plugins on demand in case additional functionality is required.
This chapter gave an overview of the Sonar platform, its history, and its features. We further explored the concept of quality in software products and how it is measured.
We analyzed the methodology of covering quality on seven axes and detailed the Sonar architecture along with the code analyzers it provides. Finally, we took a closer look around the Sonar community and its ecosystem.
In the next chapter, we will focus on setting up the environment and installing Sonar along with plugins.