General availability of Restructure101 for Java and .NET

Need to refactor your software architecture?

Today we are very pleased to announce the general availability of Restructure101 version 1.0 for Java and .NET. Restructure101 lets software developers refactor their software architecture to remove costly dependency tangles and structural complexity.

We developed an interactive visual model called the Levelized Structure Map (LSM) which was specifically designed to allow software architects delve into structural problems and to explore solutions by directly manipulating the model in a sandbox environment. Continue Reading

Making JUnit 4.8.2 tangle free – a possible solution

During the development of the soon to be released Restructure101, we used JUnit as a test harness to determine if Restructure101 could in fact do what it was being designed to do. In short, we wanted to see how easily one could remove tangles and improve its architecture with zero knowledge of the code, and, where possible, avoid breaking its API.

Unfortunately JUnit is mostly an API so it ended up primarily as a product management/test exercise. But the results warrant a blog post as it did demonstrate very clearly how in a very short space of time one can make some fairly significant improvements to the architecture of your code.

We fed our results back to JUnit‘s David Saff and Kent Beck. Here’s what they had to say:

“The finishing touches are now going into JUnit 4.9. Many of the suggestions from Restructuring101 were good, and we would have implemented them if JUnit were an internal library.

Unfortunately, a majority of classes in JUnit have many more external than internal uses, and it’s hard to justify breaking or deprecating legitimate clients to improve internal structure. Lessons learned for next time, however.”

“Lessons learned” indeed – demonstrating the importance of monitoring your software architecture from the get-go!

So, if you are in the position of starting out, be sure to use a tool like Structure101 to keep your architecture in check. Or if you already have a well established code base whose architecture is not where you’d like it to be, read on and see how you can get back on track in a surprisingly short space of time. Continue Reading

Introducing Levelized Structure Maps (LSM)

Levelized Structure Maps (LSM) are a new, intuitive way to visualize and manipulate software systems. Using LSM, large-scale refactoring to remove dependency tangles and other over-complexity, becomes second nature. LSM are the core of Restructure101.

Items in the LSM are levelized into rows, or levels, so that every item depends on at least one item on the level immediately below it. Items in the same row do not depend on each other, and items on the lowest level do not depend on any other items at the same scope. This arrangement conveys a lot of dependency information so that most of the item-to-item dependency arrows can be hidden without loss of context. For example it is normal to work with just the feedback dependencies displayed, along with the dependencies for the currently selected items. Continue Reading

Headway to introduce Restructure101 at Lausanne JUG – Feb 10th

Headway founder, Chris Chedgey, will make the first public presentation of Restructure101 at the Lausanne JUG, 18:30 February 10th,  at the Moevenpick Hotel in Lausanne, Switzerland.

Interesting format for the event. Five “static analysis” vendors (Coverity, Parasoft, Xdepend, Sonar, and ourselves of course) presenting an assessment of the Icescrum open source code base, 20 mins each.

It looks like there is a good deal of interest already, apparently only 9 seats left, so a good idea to register in advance here.

Structure101 New Feature: Class Name-map

The name-map is a feature that most users will not require. But, there are certain use cases where its use can be invaluable. For example:

  • If you have a large volume of class to class transformations, you may notice the client reaction time becoming slow. To workaround this use the Java name-map, as it can bypass heavy transform rules with direct class to class mapping at the lowest level.
  • If you can extract a class-to-architecture mapping from another tool, this will avoid the need to re-enter the mapping in (Re-)Structure101.
  • If there are certain classes you’d like to “mark”, e.g. if there are API classes you wish to indicate as not movable, you can do this by adding a prefix or suffix to the class name as a visual indication. E.g. you could map com.myco.MyApiClass to com.myco.API_DO_NOT_TOUCH__MyApiClass

These are just some of the use cases already being used by our customers.

To enable a name map, first create a text file with the from and to class name on one line, separated by a tab character. An example file can be seen if you export Transformations, as it is the same file format. e.g. com.foo.B com.foo.B_DB_CLASS

Then, add the following property to the top of your project file <property name=”name-map-location” value=”path-to-you-class-map-file.txt”/>. And that’s it.

As long as this file is found the client software will attempt to map the classes as you’ve defined.

For the IDE plugin to map the same classes, you must publish a snapshot where a name map was specfied and loaded for it.

Note that this map does not support wildcards.

Maven and Sonar Plugins for Structure101

With the recent v3.4 release of Structure101, we have included plugins for Maven and Sonar.

The Maven plugin makes it really easy to include checks for complexity and architecture violations as part of your build, and report or break the build accordingly.

The Sonar plugin displays Structure101 architecture diagrams overlaid with any layering rule violations, and adds over-complexity to whatever other metrics you monitor in Sonar.

One other significant change in Structure101 v3.4 is that the package vs. jar hierarchies have been promoted to the project level – you make the decision on which “breakout” you want to use when you create your project. Making the jar hierarchy a first-class citizen means you can detect complexity at the jar level, and use the architecture diagrams to define jar dependency/layering rules.

Plus we gave the icons a face-lift so they look all young and slick again…

Structure101 Headless

An often overlooked extension to Structure101 is the “Headless” mode of operation. This lets you hook s101 into your nightly build so that it checks for things like newly introduced complexity or architectural rules being violated while you sleep. You specify what you want checked, and whether you want to break the build or just receive a warning.

Eran Harel (“Code Slut”) has blogged how he uses this in Orbitz.

Mapping Architecture Diagrams to Code – the “most specific pattern” rule

Architecture Diagrams in Structure101 are mapped to the physical code by patterns associated with each cell in the diagram. This enables the visual specification of rules that can then be applied to a specific version of your code so that Structure101 can overlay any violations on the diagram and let you discover the offending code items.

When you let Structure101 create the diagrams for you, and stick to changes like adjusting the layering, expanding packages, or moving packages to new parents, etc., you can mostly leave it to Structure101 to handle the patterns. However, occasionally you may see some behavior that seems odd unless you understand how patterns interact.  And of course you may want to take advantage of the more advanced capabilities.

A key aspect that is not obvious at first is the “most specific pattern” rule. This says that where a physical class maps to more than one cell, the Architecture Diagram associates the class with the cell that has the “most specific” pattern.

Here’s an example diagram which was automatically generated from part of the Findbugs code-base:

18-11-2009 15-48-38

… and here is the same diagram showing the pattern associated with each cell:

18-11-2009 16-16-02

If I have a code-base that happens to contain a class edu.umd.cs.findbugs.classfile.impl.ClassFactory, then that class matches the pattern associated with the cell called ClassFactory. However it also matches the patterns for both ancestor cells “impl” and “classfile”. Since the ClassFactory cell’s pattern is the most specific (no wildcards), that is the cell to which Structure101 associates our physical class. And since a class is associated with at most one cell, that class is not associated with either ancestor cell, even though it matches their (less specific) patterns.

As expected, here are the associated items that Structure101 reports for the ClassFactory cell:

18-11-2009 16-51-41

… and the parent “impl” cell:

18-11-2009 16-55-15

Now I delete the 3 inner cells so that the diagram looks like this (the patterns for the remaining cells are unaltered):

18-11-2009 17-11-59

Since the cells with the more specific patterns are gone, the classes that were associated with them now match the next most specific pattern – the parent “impl” cell:

18-11-2009 17-17-54

This can be puzzling – I click on the “expand” button, the child cells are added to the diagram (which I expect), but the list of items associated with the parent is suddenly empty (which I don’t).

Why would we do it this way? We figured it was the best way to be future proof (the wildcards handle any added/removed classes) while at the same time supporting refactoring (e.g. if I move a class to a new package, the most specific pattern goes with it, but all the other classes still match to the original parent).

Top