After covering aspects of static and manual analysis in the last two articles, this blog entry presents a tool that can be used for static analysis as well as for explicit questions of manual analysis, such as architecture validation.


There are many useful tools that can be used for a code review. One of them is jQAssistant, which was released under the GNU General Public License in version 3. jQAssistant takes the structure of the compiled code and stores it in the graph database Neo4j. Neo4j is a database engine that visualizes and stores data in graphs. For example, classes or interfaces are created as nodes in the visualization. The edges represent the relationships between the nodes (implements, contains, …). The query language used in Neo4j is Cypher, which allows a simple formulation of complicated database queries. Cypher is based on the property graph model. In the property graph model, labels and properties are added to the graphs, which are usually defined as a set of nodes and edges. Each node can have one or more labels and each edge has exactly one label. Labels describe the type of a node or edge. Both nodes and edges can have one or more properties.

At the beginning of the analysis the jQAssistant server scans the artifacts to be evaluated. Rules for the analysis can be stored as XML document or AsciiDoc file in the folder “jqassistant/rules”. These are divided into “Concepts” and “Constraints”. Concepts are used to extend the data set with helpful information. Constraints are used to implement the rules. A defined rule is considered not to be fulfilled as soon as a contrary result can be found during the analysis. With the help of provided plugins it can be determined in jQAssistant which queries are supported and how the visualization of the static analysis should look like. In addition, arbitrary further possibilities of customization can be developed by the user to adapt the source code check to his own needs.

Via the analysis a technical fault can be determined by classifying found violations into different severity levels. The severity levels are divided into:

> Blocker Issues

> Critical Issues

> Major Issues

> Minor Issues

> Information Issues

For example, the set of rules can also be automatically incorporated into the build process for architecture validation. The rules are displayed using a browser in which queries can be started and the results displayed in graphical and tabular form.

Example:

Simple rules are possible, such as asking whether class files request an uppercase letter:

However, more complex architecture rules can also be implemented, which, for example, output all classes that access other modules via a non-permitted path:

A big advantage of jQAssistant is the extensibility and adaptability by additional plugins and own rulesets. The analysis follows a self defined set of rules, which can be adapted exactly to the given problem. Thus, developers can quickly recognize if there are deviations from the self-defined rules and make necessary adjustments.

Conclusion

During a code review, structures can be easily recognized and clearly displayed by visualizing the data as graphs. By the possibility to adapt its queries to the respective questions, many different insights can be gained and generated. For example, the structure of an application can be analyzed by connecting dependencies between the modules.



Comments

No Comments

Related Posts