Features

Code Query Language (CQL)
Compare Builds
82 code metrics
Manage Complexity and Dependencies
Detect Dependency Cycles
Harness Test Coverage Data
Enforce Immutability and Purity
Warnings about the health of your Build Process
Generate custom report from your Build Process
Diagrams
Facilities to cope with real-world environment

Code Query Language (CQL)

XDepend supports the Code Query Language (CQL) (specification available here) for maximum flexibility. Basically, XDepend considers your code as a database and you can write some CQL statements to query and check some assertions on this database. As a consequence, CQL is similar to SQL and supports the SELECT TOP FROM WHERE ORDER BY pattern. For example the following CQL query matches all public methods that have more than 30 lines of code:

SELECT METHODS WHERE NbLinesOfCode > 30 AND IsPublic

CQL will help you answer in seconds your questions about your code base

Is the code layered correctly?
SELECT PACKAGES WHERE !HasLevel
Which methods have been refactored since the last release and is not thoroughly covered by tests?
SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100
Which classes implement a particular interface?
SELECT TYPES WHERE IsClass AND Implement "java.util.Collection"
Which methods create objects of a particular class?
SELECT METHODS WHERE CreateA "java.util.HashSet"
Which methods assign a particular field?
SELECT METHODS WHERE IsDirectlyWriting "mypacckage.MyClass.myField"(not implemented in beta)
What are the 10 most complex methods?
SELECT TOP 10 METHODS ORDER BY CyclomaticComplexity
Which public methods could be declared as private?
SELECT METHODS WHERE IsPublic AND CouldBePrivate
Which complex method is not enough commented?
SELECT METHODS WHERE CyclomaticComplexity > 15 AND PercentageComment < 10 (not implemented in beta)

You can also be warned automatically when a CQL query returns a certain result. In this way, CQL queries become custom rules such as ...

I don’t want that my User Interface layer to depend directly on the DataBase layer:
WARN IF Count > 0 IN SELECT PACKAGES WHERE IsDirectlyUsing "DataLayer" AND NameIs "UILayer"
Static fields should not be named m_XXX (Custom naming conventions):
WARN IF Count > 0 IN SELECT FIELDS WHERE NameLike "^m_" AND IsStatic
Methods out of myPackage1 and myPackage2 should not have more than 30 lines of code:
WARN IF Count > 0 IN SELECT METHODS OUT OF ASSEMBLIES "myPackage1", "myPackage2" WHERE NbLinesOfCode > 30
Public methods should not be removed to avoid API breaking changes:
WARN IF Count > 0 IN SELECT METHODS WHERE IsPublic AND IsInOlderBuild AND WasRemoved

Writing CQL queries and constraints is straightforward both because it is a SQL-like langage and because VisualXDepend provides a CQL editor which supports intellisense and verbose compile error description.

Screencast
See an online demo about CQL in action (3mn)

Related Links
Write Active Conventions on your Code Base with CQL
Rules on .NET Framework usage
Rules for CLR Add-Ins Contract and View Assemblies

Compare Builds

In software development, products are constantly evolving. Hence, developers and architects must pay attention to modifications in code bases. Modern source code repositories handle incremental development. They can enumerate differences between 2 versions of source code files.

XDepend can tell you what has been changed between 2 builds but it does more than simple text comparison. It can distinguish between comment change and code change, between what has been added/removed and what has just been modified. With XDepend, you can see how code metrics are evolving and you know if coupling between components is increasing or not. XDepend can also continuously check modifications to warn you as soon as a breaking compatibility change appears.

Screencast
See an online demo about the Compare Builds feature (4mn)

Related Links
How to avoid regression bugs while adding new features
Ensure the quality of the code that will be developed this year

82 code metrics

There are many ways to measure a code base. The most common way is to count the number of lines of code. This metric gives a rough estimation of the effort that had been put in to develop the code base. It also allows you to obtain a quality level agreement by pinpointing fat methods and classes.

XDepend counts the number of lines of code. It also comes with 82 other code metrics. Some of them are related to your code organization (the number of classes or pacakges, the number of methods declared in a class...), some of them are related to code quality (complexity, percentage of comments, number of parameters, cohesion of classes, stability of assemblies...), some of them are related to the structure of code (which types are the most used, depth of inheritance...) and some of them are related to code coverage (%coverage, number of lines of code covered, branch coverage...).

XDepend also provides some facilities that will help you to detect metric anomalies and to fix your own thresholds.The VisualXDepend UI displays an interactive view of the architecture of your java applications. Such a view can be tuned according to numerous software metrics and can be saved in a PNG file in order to let you print posters.

Screencast
See an online demo about VisualXDepend basics and Metric view features (3mn)

Related Links
How do you count your number of Lines Of Code (LOC) ?
Why is it useful to count the number of Lines Of Code (LOC) ?
Layering, the Level metric and the Discourse of Method
Code metrics on Coupling, Dead Code, Design flaws and Re-engineering
A simple trick to code better and to increase testability

Manage Complexity and Dependencies

It is vital information to know how the elements of a code base depend on each other. As a developer you spend time thinking about how your layers should interact, creating interfaces and events to avoid dependencies between concrete classes.

As the code base grows, more and more time is spent managing and analyzing dependencies. If I refactor this piece of code, what will be the global impact? Is this layer allowed to access directly DB? Will I accidentally freeze the UI thread if my code invokes this method?

XDepend comes with several facilities that allow the efficient dependency management. In seconds you can know which part of the code will be impacted if you refactor a class, you can be advised if a layer dependency violation has been accidentally created, you can pinpoint precisely which part of the code relies on a particular tier component, you can list methods that can be reached from a given method etc…

See an online demo about Dependencies management (4mn).

Detect Dependency Cycles

The easiest way to keep a code base clean is to avoid dependency cycles between its components. Components are useful to partition a huge amount of code into smaller and understandable pieces. If a dependency cycle involves N components, these N components represent a single super-component. Indeed, the benefits of having N smaller components are lost: any component can be potentially broken by a change in any of the others components, you cannot unit test a component in isolation from the N-1 other ones and finally, all N components must be versioned and deployed all together.

Whether you consider that your components are classes, namespaces, assemblies or a mix in between, XDepend detects dependency cycles between them. It can also help you to find the right way to get rid of a particular dependency cycle. Once dependency cycles have been removed, XDepend can continuously check your code base to warn you as soon as a cycle is accidentally created.

White paper: Control component dependencies

See an online demo that explains how to remove dependency cycles with XDepend (5mn).

Harness Test Coverage Data

Writing automatic tests is a central practice to increase code correctness. Knowing which part of the code is covered by automatic tests helps improving tests and consequently, it helps increasing code correctness.

XDepend gathers code coverage data from Cobertura for the current beta, and soon clover and others. From this data, XDepend infers some metrics on methods, types, packages and jars : PercentageCoverage, NbLinesOfCodeCovered, NbLinesOfCodeNotCovered and BranchCoverage.

These metrics can be used conjointly with others XDepend features. For example you can know what code have been added or refactored since the last release and is not thoroughly covered by tests. You can write a CQL constraint to continuously check that a set of classes is 100% covered. You can list which complex methods need more tests.

See an online demo about how to harness test coverage data (3mn).

Enforce Immutability and Purity

At runtime, program’s states are instance and static fields’ values. Controlling how/when/why states are changing is one of the most challenging programming task. This becomes incredibly difficult in multi-threaded environment. This is because potential side-effects due to a state change get too complicated to be understood.

Object-Oriented developers get more and more inspired by the functional programming approach where most states are immutable. An object is immutable if its state doesn’t change once it has been created. A method is pure if its execution doesn’t change any field state. Immutable objects and pure methods are two efficient ways to limit unexpected side-effects.

Through some dedicated CQL conditions and rules, XDepend lets assert immutability and purity on your classes and methods. The best place to start with this feature is to look at the list of default CQL constraint and to read the associated documentation.

See an online demo about how to rationalize Multi-Threaded code (3mn).

Warnings about the health of your Build Process

XDepend is able to provide useful information about the health of your build process, including:

Jar versionning issues such as:

Jar references JarB v2.1 but only JarB v2.0 is available.
Jar references 2 versions of JarB (which is not necessarily a bad thing, but it's still useful to be aware of such situation).

Jar conflicts such as:

The name of my Jar main module file is different from the logical name of my Jar.
Several different Jars with the same name can be found (different = different hash code and/or different version).

Coverage files issues such as:

Corrupted or missing coverage files.
Coverage files and code source files not in-sync.
Coverage files and jars are not in-sync.

See an online demo about Warning management and Report generation (2mn).

Generate custom reports from your Build Process

XDepend can analyze source code (soon) and jars through XDepend.Console.exe. Each time it analyzes a code base, XDepend yields a report that can inform you about the status of your development. You can customize sections shown in the report and you can even provide your own XSL sheet for full customization.

You can also build your own set of CQL constraints that will be checked at each analysis. The report will warn you each time a constraint is violated. This feature makes automatic design and quality regression test a reality.

You might want to integrate XDepend analysis into your build process. This way, you will be advised regularly of the status of your development and XDepend will continuously check for the violation of CQL constraints. XDepend comes with facilities to help integration with your build process made with Maven, Ant, ...

See an online demo about integrating facilities to integrate XDepend into your build process (1mn30).
See an online demo about how to customize reports (1mn30).

Diagrams

XDepend outputs several kind of diagrams


Treemap metric	Abstracness vs. Instability

Dependencies matrix	Dependencies boxes and arrows

Facilities to cope with real-world environment

XDepend is non-intrusive. You don’t have to modify or to recompile your code to use it.

XDepend is easy to tackle with. It won’t take you more than 5 minutes to build a XDepend project to analyze a java application with dozens of jars.