Wednesday, April 16, 2008

STAN IDE free for Open Source

I am happy to announce the availability of free STAN IDE licenses for Open Source projects.

For those who don't know: STAN IDE is the Eclipse 3.3+ integrated product variant. STAN IDE provides its own perspective, showing various dependency graphs, ranking metric violations, generating HTML reports, etc. STAN adds a launch configuration type for Structure Analysis to the IDE, thereby allowing to run an analysis directly from the Java Package Explorer. See for further information.

By sharing STAN IDE, we aim to support the Open Source community in general and the Eclipse community in particular. So, if you are managing an Open Source project and would like to utilize STAN IDE, please submit your proposal to info at stan4j dot com, providing
  • the name of your project,
  • a short project description,
  • the Web URL of your project,
  • the status of your project.

Friday, March 28, 2008

STAN 1.0 is out!

Finally, STAN 1.0 is reality and has been shipped to early adopters. Thanks to everyone who helped to make this happen!

Sunday, March 2, 2008

Introducing Metric Queries

STAN public Beta 3 adds support for metric queries. Here's the Query View:

Pressing one of the new buttons (e.g. Class Query...) launches the query dialog:

Saturday, March 1, 2008

STAN Usability Enhancements

STAN APP Public Beta 3 comes along with some nice usability features:
  • Choose workspace on startup - When starting STAN, a dialog lets you choose a workspace location.
  • Switch workspace - Use File > Switch Workspace... to change your workspace on the fly.
  • Confirm exit on close - When closing the workbench window, a dialog asks you to confirm exiting STAN.
  • Software Updates - Use Help > Search for Updates... to upgrade to the latest version.
  • Monitor heap space - The status bar now shows you the amount of heap space currently in use.
  • Rename project - Rename the selected project via its context menu or press F2.
I hope you'll find some of these useful.

Wednesday, February 13, 2008

ACD and Testability

The Component Dependency (CD) for a component C is defined as the amount of other components that C depends on, either directly or indirectly.

There are two flavors of Component Dependency
  1. absolute CD, expressed as the number of other components
  2. relative CD, expressed as the percentage of other components
In other words, relative CD is absolute CD divided by the number of components (-1) multiplied with 100.

STAN shows you the (relative) Average Component Dependency (ACD) metric for libraries, packages and units (toplevel classes).

For symmetry reasons, we may note that
  • ACD is the average amount of components that a component depends on
  • ACD is the average amount of components that depend on a component
So far so good. But how is this related to testability?

Consider we have a code base with 1000 units and an ACD for units of 10%. That is, on average, a unit depends on 100 other units (and 100 other units depend on it), either directly or indirectly.

But this also means that
  1. changing a unit may affect (and potentially break) 100 other units
  2. a unit may be affected (and potentially broken) by changes in any of 100 other units
This shows that ACD is indeed an interesting measure for testability: smaller values allow for simpler and more robust testing.

Finally, let me give some real world examples:

Project #units rel. ACD abs. ACD
Spring 2.5.1 1595 2.50% 40
Groovy 1.5.4 833 27.57% 229
Hibernate 3.2.6 1085 67.04% 727

Monday, February 11, 2008

A little bit of history...

Back in summer 2006, Oliver and I started to think about creating a tool that would measure some metrics, detect design tangles and dump out a report. We wanted to use these reports to serve as quick indicators for the code/design quality and as a base for discussing quality issues with our customers. We then searched for open source projects that would assist us in doing the hard work, providing us the code dependencies and metrics. To make it short, there was none. Next, we checked for commercial products. Again, without luck.

However, as we evaluated and used these tools we got some idea of what we consider to be useful from the developer's point of view. We learned that those "architecture first" solutions tend to fail and that we took the most benfits from tools that really helped us to understand the structure of the code base: now, dependency analysis became a hot topic. Anyway, at that point we had no plans for implementing our own solution in this area.

During fall 2006, we started coding to get what we initially wanted. We decided to analyze Java bytecode, not source. Parsing bytecode is much faster and allows to analyze code bases where we do not have access to the sources. All went fine and within a couple of weeks we ended with a command line tool which produced lots of numbers, formatted as HTML.

In November 2006, we both got involved in a project with one of our customers, so the quality stuff was pending then. By the end of the year, I left the project. Oliver stayed a little longer and I spent some time creating the basic framework for STAN.

I am a Java developer since 1.0. But after years of J2EE I had to realize that I didn't know how to create a Java-based desktop application in these times. I didn't want to come out with one of those home-grown Swing applications, so I played around with the Eclipse Rich Client Platform. Not only that RCP provided me what I was looking for, it was also attractive because it left room for the idea of moving STAN into my favorite IDE one day.

Still early 2007, we went back to dependency analysis. We knew that STAN wouldn't be worth all the effort without having neat graphs. The most intuitive way for drawing dependency graphs uses a hierarchical, layered layout, which ensures that a maximum number of dependencies have a common direction (e.g. top-down or left-to-right). Only a minimum set of "feedback" dependencies point into the opposite direction. We were pretty sure that we wouldn't be able to get this done, but we had no choice. We read some papers on layered graph layout, understood a few, implemented some algorithms, played, improved... About a month or so (I can't remember) later we got a basic implementation. Another month to utilize GEF, yet another to tweak the implementation, yet another to add nifty features like expand/collapse, partitioning, etc.

We began to issue monthly STAN previews to friends, hoping to get some feedback and help. Well, due to continuous annoyance, we got some! In summer 2007, Andreas and Markus joined our team. Andreas took over the IDE integration part. We agreed that it would be really cool to have a "Run As... Structure Analysis" in the Package Explorer's context menu. After a month or so, it was there. Markus had the idea to support other languages and started working on a parser for - damned, I forgot the name... Due to his rare time, he wasn't able to finish it, but it works as a prototype and serves as a proof of concept. I hope we can come back to this soon! Markus also helped to setup our build management.

During fall 2007, we started another feature offensive: the Pollution Chart, the Couplings View and the Dependency Landscape were added. In late November, we felt ready to share a public beta with a wider audience. Finally, STAN 1.0 will be launched within the next weeks...