The XRadar architecture is based on pipeline processing. In the following sections, we will describe the design of each process in the Statics pipeline.
The analysis process is simply calls to the various ant-tasks corresponding to the sources. In some cases the java class is called directly, to override default behavior or if a ant task does not exist for the source. The common denominator of all the analysis sources is that they take produce XML files. Typically the source or the class paths of the system to be analysed are used as the basis for the analysis-library's produced XML-result.
All files from the analysis process are put into the docs/xml directory. The files are now ready to be used by the next step in the process - merge.
The merge process in statics uses merging stylesheets to merge each analysis into a common xml after one after the other. This is the process that puts all the pieces togather. JDepend is - due to historical reasons - the first step in the process and is used to lay out the xml. Thereafter, it is not that important which other merges comes in what order. In the end, you have one big (and a little ugly xml), that is build up into a hierarchy from package down to method and field. All metrics are populated under the right place in the hierarchy.
There is no magic to each merge step. There is a master-merge.xsl that most of the specific merge stylesheets inherit from. Each merge is run from the ant script as a style task. The task takes in the master-xml that is to be updated with the particular analysis, as well as a path to the analysis xml-document. The analysis xml is then merged into the master-xml. The means in which the merge is done is highly dependent on the structure of the xml-document.
The result from the merge process are put into docs/xml-folder. We are now ready for cleaning, classifying and nomalizing the resulting xml. The merge-post-process can begin.
After all merging is done, the post-process begins. 3 concrete tasks are done one after the other:
The report itself is generated by one call to one stylesheet: master-report-detail-frames.xsl. This stylesheet call about 20 or so other stylesheets to build up the whole report. There are many files in the report, and the way in which these are produced is through the xalan-extension Redirect, that is used in many of the sub-stylesheets. A call to Redirect makes a totally new page. The statics report process does not use the noramalized xml to produce the reports. This should probably be fixed in a future release.
Documenting the whole report structure here would be strange, since the report structure is evolving and continually simplified and extended. Hence, we recommend that the best way to explore the XRadar Statics Report is it start with master-report-detail-frames.xsl and go into each of the included stylesheets.
In statics, the SVG's were originally transformed to images before shown in the XRadar. This took time and wasted space. At one internal release before the system went public, I decided to embed the svg's directly into the system instead. Unfortunately, the old legacy is still there. The svg's in statics are still produced in a separate process to the report. For dynamics, both svgs and html are produced together in the same process. This is especially good for development speed and readability - but unfortunately not available in statics. The statics graphing process uses both the initial and the normalized xml to produce the graphs.