It takes more than a group of keen developers coding like mad to create a software system that meets requirements yet is robust to change. As new requirements are discovered, new code must be written and existing code maintained. Without careful consideration of code structure, packaging, and component dependencies, a large system can quickly turn into a "big ball of mud."

Managing dependencies between components becomes critical if a software team is to maintain the level of agility required in today's environment, where customers are demanding increasingly complex business systems delivered faster and cheaper. If component and package dependencies are not well managed, the code base becomes fragile and unmaintainable, a common cause of a software project failure.

Currently, tool support to help developers and architects prevent system degradation is poor. The type of support required is where the feature set of most CASE tools stops. Luckily for us a new breed of tool is now available ­ Small Worlds.

Product Description
Small Worlds provides insight into the structure of Java or C++ software systems through a variety of innovative visual models and statistics. These include views for managing component and package dependencies, tracking the effects of change, system coherency, and summary reports. The views help identify problem areas of the code that may need system-level refactoring.

There's also a plug-in API that allows integration into other tools (Forte being the first), and several export options that save visual representations of the system in GIF or HTML format.

Small Worlds supports three modeling notations, or "skins": UML, Small Worlds, and Global. The UML skin does what you would expect. The Small Worlds skin focuses on the code "flow" rather than the containment hierarchy (i.e., the direction of change rather than associations). The Global skin removes visual decorations to simplify complex diagrams.

The Review
To see how Small Worlds handles a large system, I decided to import the source code from my current project ­ a J2EE-based application with 230,000 lines of Java code in 1,320 files. On my modest laptop it took three minutes for the compiled code to be imported and then another two for the views to be created.

Reading through the informative Small Worlds user manual pays off! There are so many features and ways information is presented that you can easily lose sight of what you need to accomplish. There is a big "wow" factor with this tool, which makes it easy to get sidetracked. Therefore, it's very important that you have a clear understanding of the questions you want answered before you start navigating though your code.

The heart of Small Worlds is the Explorer window that presents a visual representation of system components; convenient navigation between components; and a set of fine-grained filter controls to hide abstractions, implementation, different kinds of dependencies (uses, extends), packages, and classes. Changing to the Small Worlds skin provides a view that illustrates the flow of the code, which is useful for depicting the effects of change.

Apart from the Explorer, the feature I was most eager to look at was the summary report. There I was told that our system was 98% stable, but that there were problem areas (no surprise there), two possibly serious. The first is a Local Hub, a component that has many immediate dependencies and dependents. The component in question was one I suspected was a problem, and now I had evidence. Drilling into the "What If" view immediately demonstrated the rippling effect this component causes when modified. Lowering the threshold of hub dependencies by using the "Show run play" option exposed other hubs I would have to deal with next.

The next problem I investigated was a tangle, a cyclic loop between components. Nothing good ever comes from cyclic dependencies, especially if they're between classes. Drilling into the Explorer view showed me that the tangle was package-based and needed investigating (see Figure 1).

Figure 1

Viewing the details of the tangle exposed 24 loops that could be broken. Each loop has a weight associated with it that suggests if the dependency is a weak or strong link. With this information and the powerful "What If" feature, I can make educated recommendations to the development team as to how to make this section of the code more robust to change.

Summary
There is no other tool on the market that deals with the complexity of managing component dependencies as completely as Small Worlds. You can reverse-engineer class diagrams in many visual UML tools, and even purchase some plug-ins for Rational Rose, but none provide a feature set anywhere close to that of Small Worlds.

To take full advantage of the insights provided by the tool and apply them to a large software system, you need an expert user and a strong individual who has the commitment of the entire development organization. However, novice or intermediate-level developers may take advantage of the Visualizer edition that removes the analysis tools and concentrates on navigating through the system structure. For example, the "Random explore all" feature from the Explorer is a great way for new developers to get a feel for the system.

I found this to be an exciting tool and one that I've already used to good effect. The ROI is somewhat intangible unless you're into tracking metrics in your development process, but Small Worlds can help with that too. I do have some minor usability issues with the tool, and the user manual bundled with the installation was not current, but none of this prevents me from highly recommending Small Worlds to others.

References