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.

You can see the entire code-base at once in the LSM, so that it is possible to e.g. move any code item from any location to any other location.  But LSM also lets you explore dependencies from the highest architectural components down to the lowliest functions – just double-click to drill-down or elide the next level of detail – so the amount of information is further focussed.

Finally, LSM can further reduce the information displayed at one time by automatically grouping items according to different dependency patterns. For example sets of cyclically dependent items (tangles) can be grouped into a single higher-level component, expanded only when more detail about the logical group is desired. While reducing clutter, auto-grouping at the same time helps to understand complex structures.

Restructure101 provides a number of discovery and manipulation capabilities on top of the LSM. For example it is easy to find package tangles, and explore ways to to break them by moving (dragging and dropping) packages, classes, methods/fields, and other direct manipulations such as wrapping (creating sub-packages or inner classes), flattening (removing package structure) and automatic repackaging. Videos.


  1. How to create a killer call graph for impact analysis | Deconstructing Software

    […] a Maven project (actually THE Maven code-base as it happens), the apples are POM’s): This is an LSM of your code-base, where as far as possible dependencies flow […]

  2. Øredev 2012 – Lessons Learned

    […] of a large bowl of spaghetti, a.k.a. legacy code. Measures like cyclomatic complexity let you levelize dependencies among software modules and make them structured. Eager to know what is the difference […]

Leave a Reply to How to create a killer call graph for impact analysis | Deconstructing Software Cancel Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.