Component-Watch goals

This tool is born from the firm belief that, when you start developing an application, one of the key activity (along with gathering the user requirements) is to identify the main components of the future application and choose an overall structure for it. It will bring you the usual architectural promises like modularity, maintainability, reusability, stability...

It's not the purpose of this document to explain or prove this assertion, nor will it try to explain what is a good structure and componentization for applications (There are plenty of architectural books about that). The component-watch tool proposes a practical way to achieve it.

To practically succeed in defining this global structural view and a clean break-up into components you will have to do the following (in addition to having a clue about what is a suitable structure and components for your practical case, but for that no tool will help)

• Investigate: As, most of the time, an application doesn't start from scratch or the structural concerns come after some coding, it implies that you will have to investigate the existing code to find the current structure and components.
• Specify: You should find a practical way to define the structure and components of your application and also map it to the java code.
• Communicate: ensure that the intended structure is known and understood by all relevant stakeholders. The ideal ways to communicate the structure is to make several diagrams expressing the different structural concerns present in your application.
• Keep in synch.: You must ensure that the described structure is effectively the up-to-date application code structure and not an idealised architect dream decoupled from reality. It means than any document created to express the structure must be easily (automatically) updated when code changes.
• Evolve: Detect the new artifacts (classes, components, external libraries ...) and easily update the project structure to add them.
• Enforce: Detect quickly (at least on a daily basis) any code artifact breaking the structural rules (and fix them)

"Component-Watch" helps you to perform those tasks. It allows defining components and continuously applying the components definition to a set of jar files. The tool will deduce all the relations between components and check rule compliance.

In addition it allows defining diagrams showing a selected set of components and their relationships.

The tool provides a rich UI interface displaying components, jars and classes and their relationships.

Comparison to other tool

By comparing Component-Watch to other code analysis tools, it is clear that the approach and goals are different.

Other tool	Component-Watch
Analyses relations between jar files   or java packages.	Analyses relations between components   that are defined with pattern matching expressions.
No high-level structure concept	Defines higher-level components to express application structure (like "layer", "tier", "subsystem" ...).
Evaluates generic design quality metrics   Like "Afferent Couplings" or "Abstractness".	Evaluates user-defined structure rules.
Deduce everything from sources or classes.	Allow the user to add information (to the analysed data)   at several levels:   * Component description   * Structure definition   * Structure rules   * Diagram layout
Produces lot of reports.	Produces:   * A single error report   * UML-like graphs   and provide a high-level user interface allowing clever   browsing.

Instead of generating metrics from code, Component-Watch let you express and enforce your code structure.

This is also obvious if you compare typical output like

• A graph generated by a usual jar-dependency tool:

• A graph generated by Component-Watch where you "see" application structure

At this stage, with only 11 jars, You can think that those two graphs are both clear and instructive but the main difference is that the second one already brings more information (in this case the fact that the application is partitioned in tree layers and two silos). This information was added 'manually', no automatic dependency tool can guess it. It will make a tremendous difference when the application will grow. You will be able you keep the second graph readable (and if needed to break it in simpler diagrams if it grows too much) while the first one will more and more look like a big spaghetti.