Reports

One of the major features of the XRadar is a defined metric that is totally configurable for the user. Here you may define what your system quality is. In the front page of the HMLT report, the system quality report is depicted with a snapshot of the the whole project. The coloring represents the quality of the metric or the specific subsystem (red = bad, yellow = worry, green = OK). By pressing on the module you get a spider graph of the subsystem quality as well as a scorecard.

An example of the scorecard

Statics

An example of the dependency graph

The HTML presentation starts at the system and subsystem level, but drilldowns are available down to package, class and method level. Navigation can be done in "javadoc style" to find suitable packages and classes. In the main window you can view scorecard reports on architecture, package design, code, test, source control and system specific views. Reports consist of tables with metrics and hyperlinks for detail, and dynamic SVGs with navigation features.

To give an example, one important view in the scorecard section, the architecture dependency report is defined by the dependency configuration. The graphics part of that report is shown in the figure when you have a mouseover on one of the subsystems. Note that the green lines represent legal dependencies and the red lines represent illegal dependencies. A subsystem is orange if it has illegal dependencies. On the other hand, if it is green it only has legal dependencies.

There is also a system analysis section in the radar. Here you are able to view reports on system design, code quality, class coupling, redunant code, external dependencies as well as the system specific reports. Several of these can be used to find trouble areas across the system.

A recent and exciting addition to the XRadar is analysis of duplications. This big source of entropy in a system can now be on all interesting levels of detail. In addition, we now have a new and fairly revolutionary way of presenting the duplications between the classes in a subsystem - the duplication matrix. Note that a duplication within a class will manifest itself as a dot on the diagonal of the matrix. The size of the dot represents the number of duplications within the class or between two classes. See the figure below for an example. Here the mouse pointer is hovering over one of the duplications.

An example of the duplication matrix

Dynamics

The Dynamics report has similar views as statics, except here you analyse how the system trends over time. There is a seamless navigation between the Statics view and the similar dynamics view in the reports. Drill-downs are possible from the system level to subsystem level and package level. All views include selected graphical trend reports on architecture and package design, code size and quality and test quality. Along the time axis you have the releases. For more historical data within one area, there is also more data in tabular form. See the figure below for a teaser of some example graphs in the report.

Example Dynamics total quality  graph Example Dynamics architecture graph
Example Dynamics code quality graph Example Dynamics test suite graph