blog.stan4j.com

Dependency Analysis with STAN (Video)

2010-05-22T06:05:00.000-07:00

We've created a video introducing dependency analysis with STAN. Watch and listen to the music of Tiefenrausch Klangkombinat, a Jazz/Funk/Fusion combo from Frankfurt.

Project and Bundle Dependency Graphs

2009-12-11T02:32:00.000-08:00

STAN IDE 2.0 introduces tools to visualize Eclipse project and OSGi bundle dependencies. The tools are packaged into additional, optional features

STAN IDE Tools (project dependencies)
STAN IDE Tools - PDE (bundle dependencies)

Once installed, the project/bundle dependencies are available from Window > Show View in category STAN Tools:

Both views follow the same usage patterns. Let's take some project dependencies as an example. Just drag and drop projects from Eclipse' Package (or Project) Explorer to add them to the graph.
OK, what's about the "+" and "-" overlay icons?

A "+" indicates that there are outgoing dependencies that are currently not shown. These dependencies can be added by double clicking the node. E.g. adding outgoing dependencies for de.odysseus.stan.eclipse.coverage.core may give
A "-" indicates that there are incoming dependencies that are currently not shown. These dependencies can be added by double clicking the node while holding the ALT key. E.g. adding incoming dependencies for de.odysseus.stan.eclipse.coverage.core may give

Here's what the edge labels mean:

For project dependencies, edges may be labeled "s" (static), "d" (dynamic) or "s+d" (both). A "static" dependency can be added on the "Project References" page in the project's properties. A "dynamic" dependency is introduced through Java Build Path, Java EE Module Dependencies, etc.
For bundle dependencies, edges may be labeled "r" (requires bundle), "i" (imports packages), or "i+r" (both). Fragments may also have an "h" (is hosted by) dependency to their host bundle.

Both views also let you remove selected nodes by simply pressing the DEL key.

As a final example, here are the outgoing (transitive) bundle dependencies for org.eclipse.core.runtime:
By the way, use the "+" button from the view's toolbar to add bundles from your active target platform.
Hope you like it!

STAN 2.0 Public Beta available

2009-11-01T04:51:00.000-08:00

The beta period will last until February 28 of 2010. During this period, you are invited to download and use the fully functional product for evaluation purposes. Moreover, STAN 2.0 will have a community license option for free, non-commercial use.

What's New?

Sandbox View - Explore dependencies between any artifacts as easy as Drag'n Drop
Map View - Visualize metric ratings in fancy green-to-red treemaps
IDE Tools - Views to show Eclipse Project/Plug-in dependency graphs

If you haven't used STAN before, now is the time!

STAN 1.1 with Community License Option

2009-06-28T07:46:00.000-07:00

STAN 1.1 has just been released. Since 1.0 more that a year ago, we went through 1.0.1 to 1.0.4, constantly improving the product regarding to stability and usability. Since 1.0, lots of "little things" have found their way into STAN:

Choose between Java 5 generic and raw signatures
Determine the order in which libraries are analyzed
Improved "Open Declaration" (F3) in STAN IDE
Copy to clipboard in Query/Violations/Dependencies View
In addition to class exclusions, inclusion patterns are supported
Show dependencies for multiple edge selections in Dependencies View
Parse annotations, indicate @Deprecated with an icon overlay
Introduce pollution, a number suitable to trace quality over time
Added treemap overview in Structure Explorer and Pollution View
Show excluded classes under a separate root in Structure Explorer
Re-include excluded classes from the Explorer's context menu

With STAN 1.1 we also updated the license terms by adding a Community License option.

What does that mean? Well, you may now download and use STAN without a license key! However, structure analysis will be limited to 100 classes. Any classes exceeding that limit will be automatically excluded from the analysis. That's the only restriction when using STAN under the terms of the community license option. The other license conditions did not change: if you like STAN, you can still register at stan4j.com for a 30 days evaluation and you can still buy node-locked or personal licenses.

STAN IDE free for Open Source

2008-04-16T07:57:00.000-07:00

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 http://stan4j.com/ 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.

Cheers!

STAN 1.0 is out!

2008-03-28T03:02:00.000-07:00

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

Introducing Metric Queries

2008-03-02T08:53:00.000-08:00

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:

STAN Usability Enhancements

2008-03-01T04:19:00.000-08:00

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.

ACD and Testability

2008-02-13T12:13:00.000-08:00

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

absolute CD, expressed as the number of other components
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

changing a unit may affect (and potentially break) 100 other units
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

A little bit of history...

2008-02-11T11:34:00.000-08:00

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...