Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Automatically implement design guidelines in your code

Add Hammurapi, a design-compliance solution, to your toolbox

By Sidharth Sankar, JavaWorld.com, 04/18/05

As a J2EE architect, I'm required to deliver detailed designs to project teams. Along with the UML (Unified Modeling Language) model, I also deliver design guidelines that capture best practices. For example, in Struts applications, I recommend avoiding instance variables in Action classes because Action classes are singletons, and the potential for multiple threads simultaneously executing an Action class instance is very real. As another example, in any DAO (Data Access Object) application, an important design guideline is to close all open database resources. Failure to do so is always disastrous—especially in a production environment.

Intent is all very well; however, implementation is key. At present, the most common way to implement design guidelines is to do code reviews, where, typically, experienced members visually inspect code and catch noncompliant situations. Such situations might include cases where coding standards (indent level) are violated and/or cases where design standards (no instance variables in Action classes) are violated.

This is a very inefficient process on two counts: It requires at least two resources (the reviewer and the developer). Plus, quality, being a function of the reviewer, is not consistent. In addition, as per my experience, in their zeal to enforce standards, reviewers alienate developers, which is bad for team morale.

A couple of years ago, I came across Checkstyle, a tool for automatically enforcing coding standards. It integrates seamlessly into Ant and is driven by an XML-based configuration file.

Hammurapi does for design standards what Checkstyle does for coding standards. Hammurapi, open source software developed by Pavel Vlasov, is a tool that can analyze a codebase against a set of design guidelines. When the tool comes across a guideline violation, it flags the violation in a report. As with Checkstyle, it seamlessly integrates with Ant. And likewise, it is driven by an XML-based configuration file.

Running Hammurapi

You can run Hammurapi directly from the command line and also from Eclipse as a plug-in. In this article, however, I discuss how to run Hammurapi as an Ant task.

Note: You can download the source code that accompanies this article from Resources.

Integration with Ant is very straightforward, as the code below illustrates:

 1   <target name="design_review" depends="init">
 2      <taskdef name="hammurapi" classname="org.hammurapi.HammurapiTask">
 3         <classpath>
 4            <fileset dir="${hammurapi.home}\lib">
 5               <include name="**\*.jar"></include>
 6            </fileset>
 7         </classpath>
 8      </taskdef>
 9      <hammurapi>
10         <src dir="src"/>
11         <output dir="docs\review"/>
12         <classpath>
13            <pathelement location="${$log4j.home}\lib\log4j.jar"\/>
14            <pathelement location="${weblogic.home}\lib\weblogic.jar"\/>
15         </classpath>
16      </hammurapi>
17   </target>

Line 1 defines a target called design_review. It depends on another target called init, which initializes build properties (${hammurapi.home} in Line 4, for instance). Line 2 defines a new task called hammurapi. This Ant task is implemented by the class org.hammurap.HammurapiTask. The nested element classpath, beginning on Line 3, specifies classfiles required for defining this task.