Logical architecture definition

SonarJ's main benefit is its ability to check a given set of Java source and class files to its conformance to a given logical architecture in real time. But before you can profit from this benefit you must first define the logical architecture that should be used as the blueprint for your system.

SonarJ defines several elements that allow you to incrementally develop your vision of the internal structure of your system. To structure your system you will probably first cut it horizontally into technical layers (e.g. user interface, business logic, data access). So the first architecture element defined by SonarJ is a "layer".

As a next step you will probably use domain driven aspects to cut your system vertically into so called "vertical slices". Therefore "vertical slices" are the second logical element used to describe a logical architecture with SonarJ.

If you look at the resulting structure you will see, that it looks like a grid. The boxes of this grid are what we call "subsystems". They are the third logical element used by SonarJ. Each layer must at least contain one subsystem. Every subsystem must be assigned to exactly one layer. On the other hand a subsystem also belongs to a vertical slice, if it has the same name as the vertical slice. Therefore the assignment of subsystems to vertical slices is done by naming convention.

If you have cut your system horizontally and vertically (optional) you might want to define the legal usage relations between layers and vertical slices. You probably will establish rules like "User interface can use business logic" or "our Contract slice can access the customer slice" By specifying allowed usage relations between layers and vertical slices you greatly reduce the allowed usage relations between subsystems. In fact it is easily possible to compute the remaining legal usage relations out of the rules defined on the high level elements "layer" and "vertical slice".

If you want to further restrict allowed usage relation on the subsystem level SonarJ gives you the opportunity to do that.

BTW, you define your logical architecture by using a graphical editor which is based on UML notation.

Physical mapping of architecture to Java code

As soon as you have defined your architecture down to the subsystem level you can now map it to your Java code. You just assign all the packages in your system to your subsystems. Technically you can see a subsystem as a set of Java packages. You can also decide to ignore certain packages or classes (e.g. test code or java.lang etc.)

If you want to restrict the access to a subsystem to a subset of the public classes exported by the packages defining the subsystem you can do so by defining one or more "named interfaces" for the subsystem.

Checking or architecture violations and cyclic dependencies

Now you have a logical architecture and a mapping of this architecture to your Java code. SonarJ will now parse your class files and source files to establish an in memory model of your system. It analyzes all the internal dependencies and checks if they conform to the rules defined in your logical architecture. Each violation is reported immediately. Moreover SonarJ provides enough additional information, so that it is easy to fix the problem.

Even without an architecture SonarJ is able to report all cyclic dependencies between packages (or even compilation units - if needed). The cycle viewer list all the dependencies creating the cycle and helps you to identify the link, that allows you to break the cycle with the least possible effort.

Metrics help you to monitor technical quality

Besides its ability to maintain a logical architecture and to identify cyclic dependencies SonarJ also is able to calculate a bunch of useful metrics:

• ACD (average component dependency - says a lot about internal coupling)
• LOC (lines of code -where is the beef?)
• Cyclomatic complexity (where is the complexity?)
• assertion usage
• relational cohesion
• Metrics of Robert C. Martin ( abstractness, instability etc.
• many others...

You can define thresholds for those metrics. E.g. you could define an upper bound for cyclomatic complexity of 15. Every developer that tries to create a method with a higher complexity will receive a warning. Then he can try to split the method into several less complex parts.

SonarJ aggregates all the metrics to the higher level. Therefore you can easily find out the cyclomatic complexity of a layer or the lines of code comprising a vertical slice.

ANT task and Maven plugin for your nightly build

SonarJ comes with an ANT task for your nightly build. This ANT task will create an XML report, that contains all the key statistics and metrics for your project. Moreover it contains a list of all remaining architecture or threshold violations. We also deliver an XSLT converter to convert this XML report into a more readable HTML version.

By using our free tool "qatracker" you can extract a daily set of metrics from the SonarJ report (and from other tools reports) to create a history of these values. "qatracker" can then create charts out of the historical data. These charts can be condensed in a highly informational management dashboard that keeps you informed about all important quality trends in your project.

Online demos and more information

There is still much more to explain. Please have a look at our SonarJ white paper or just download SonarJ and try it free for 30 days. We are also performing webinars every two or three weeks. Please contact us to register for the next one.