I got blasted for the following quote in a recent eWeek article:

“If you’re in a large environment that is bureaucratic, filled with politics and has a [software development] process like the waterfall flavor of RUP [Rational Unified Process] what do you do?” Knoernschild asked. “It’s been my experience that the number one thing you can do is continuous integration. That can spawn so many business benefits.”

The blaster suggested that I have no idea what I’m talking about because there is no “waterfall flavor of RUP”. What I believe the blaster missed is the tongue in my cheek when I made the comment.

As is often the case, the quote didn’t capture the context of the statement. Many teams, when transitioning to an iterative process, commit a number of mistakes. One of the more common mistakes is to establish iterations centered around the traditional lifecycle phases. When I made the comment, I also pointed out that the “waterfall flavor of RUP” typically consists of the first iteration being the requirements iteration, followed by the design iteration, followed by the construction iteration, followed by the testing iteration, etc.

A class defines the variables and methods available to it’s specific instances. A class serves as the blueprint for an object. An object is an instance of a class with state. In Java, a class is a .class file

A component is a unit of deployment. A component contains classes. Components are invoked in-process (locally). Components are not instantiable. Components are stateless. Component interactions are synchronous. In Java, a component is a .jar file.

A service is a software system. Services are distributed, may execute in different processing environments, communicate over a network, and are invoked remotely. A service is not instantiable. Services are stateless. Service interactions are synchronous or asynchronous. A service contains components. In Java, a service is an .ear file with the appropriate deployment descriptor.

Agree or Disagree? I’m interested in your thoughts on this subject…

JarAnalyzer has always had the ability to create a dot-compliant output file that could be used with GraphViz to generate a component diagram. In the past, this had always been done using the DOTSummary class. Unfortunately, this meant that if you wanted to generate output files in both xml and dot, you had to run JarAnalyzer twice. Now, thanks to a stylesheet that I graciously stole from JDepend and modified to work with JarAnalyzer, there’s a new way to generate a dot-compliant output file that is much nicer than what you’ll get when using DOTSummary. Plus, you only have to run JarAnalyzer once, then apply two stylesheets to the xml file generated to get both the html report and component diagram.

In addition to being a bit more efficient, it’s also cleaner. The old component diagram is shown at left on top, while the new component diagram using the stylesheet is shown at bottom left. The stylesheet avoids the confusion where DOTSummary changed the name of the .jar file and stripped off the .jar extension. As seen on the diagrams, a .jar file named bill.jar now actually appears as bill.jar on the component diagram, not bill.

The new stylesheet isn’t part of the JarAnalyzer distribution…yet, but you can download the stylesheet. To run JarAnalyzer as part of your Ant build script and get both the html and component diagram output, drop the stylesheet in the directory containing JarAnalyzer (the same directory with jaranalyzer.xsl), and modify your build script similar to the following (you need GraphViz installed to run dot):

<target name="dotanalyzerapp.new" depends="bundle">
   <taskdef name="jaranalyzer"
             classname="com.kirkk.analyzer.textui.JarAnalyzerTask">
       <classpath>
           <pathelement path="${buildlib}/jaranalyzer-1.2.jar"/>
           <pathelement path="${buildlib}/lib/bcel-5.2.jar"/>
           <pathelement path="${buildlib}/lib/jakarta-regexp-1.3.jar"/>
           <pathelement path="${buildlib}/lib"/>
       </classpath>

   </taskdef>

   <jaranalyzer srcdir="${buildstats}"
                destfile="${buildstats}/appdependencies.xml"
                summaryclass="com.kirkk.analyzer.textui.XMLUISummary"/>

   <style in="${buildstats}/appdependencies.xml"
                    out="${buildstats}/appdependencies.html"
                    style="${buildlib}/jaranalyzer.xsl">
   </style>

   <style in="${buildstats}/appdependencies.xml"
                    out="${buildstats}/appdependencies.grph"
                    style="${buildlib}/jaranalyzer2dot.xsl">
   </style>

   <exec executable="dot" >
       <arg line="-Tpng -Nshape=box -Nfontsize=30 -Nwidth=1.5
              -Nheight=1.25<br></arg> ./buildstats/appdependencies.grph
              -o ./buildstats/appdependencies.png">
   </exec>

 </target>