Structure101 3.1 – Software Architecture Sandboxing

Just released, Version 3.1 adds lots of new stuff to the Architecture perspective to make it much easier to discover the current structure and move classes or packages around to define a preferred architecture.

First thing is a simple expand and collapse button on each cell. So for example you can ask Structure101 to create a high-level architecture diagram from the current code-base – no need to worry about how deep to make the initial diagram since you can now expand and collapse cells once you have the initial diagram.

Let’s say you get the following diagram:

This shows a layering violation from the strut2 package to the dispatcher package. Click the “+” to find out what is being used at the next level of detail.

So something in struts2 is using something in dispatcher.controller. Expand both cells…

And we see there is a single class-to-class dependency causing the violation. Also, since the Dispatcher class is below the other classes in the dispatcher.controller layering, we know that the other classes use, but it does not use the other classes. And the layering in the struts2 package indicates that we can move Dispatcher to the indicated level to fix the violation without creating new ones. Just drag and drop Dispatcher to create this:

Collapsing the 2 top-level cells by clicking the “-” icons shows the original layering but with the underlying code rearranged so there is no longer an architecture violation.

Other stuff that has been added in this version:

• Once you have moved classes or packages, you can get a list of all the moved items.
• You can convert the list of moved items into transformations on the underlying model. This lets you iterate on a restructuring job – use an architecture diagram as a kind of “Sandbox” until you have some set of changes you’re happy with, then convert them into transformations and start sandboxing the next set of changes.
• You can now apply strict layering to a diagram. This means that cells can only use cells immediately below them, not below that.
• You can show any dependencies (i.e. not just violations) either on the whole diagram or on selected cells.
• You can drag items onto an architecture diagram from the dependency breakout.

Final note, if you are using the architecture diagrams to drive your developers, you should choose the expansion level of cells consciously before publishing them to the project repository. Their code changes will be checked against the visible levels only.