Small Worlds 2.0

a dependency analyzer by Information Laboratory, Inc.

Small Worlds is a tool for exploring and analyzing dependencies in object oriented software systems. It promises to "help prevent [...] failures by allowing managers, engineers, developers, and testers to gain critical understanding of stability issues in their systems" by "performing a structural analysis, evaluating the overall stability, and pointing out potentially problematic areas". It even claims giving managers the ability to assess the maintainability of a system without having to know anything about programming.

To investigate the meat behind those claims, I used Small Worlds Analyzer Edition 2.0 for Java, provided by Information Laboratory. There is also a version for C++ and a shortened Visualizer Edition. I mainly analyzed an open source project, first because there is no problem with publishing details about it, and second because I am very familiar with the code and therefore in a good position to judge the findings of the tool. The project consisted of 94 classes/interfaces in 12 packages forming a net of 386 relationships. I also took a quick shot at two bigger projects, one of around 600, one of over 1000 "objects".

Installation

Installation went very smoothly. After downloading and starting the setup program for Windows, I only had to enter the registration key. That was it. The registration key is bound to the MAC address of the installation machine, so you have to get a new key if you find yourself needing to replace the network adapter. As the folks of Information Laboratory seem to be very responsive in general, that probably shouldn't be much of an issue.

Setting up a project

After starting the program, you are welcomed by a project wizard. It gives you the option to either open a recently worked on project or start a new one.

Small Worlds works on class files, so you don't need the sources of the project. The files can reside either in jar- or zip-files or in a directory structure (or any combination of the three). It also wants to know the location of the used external libraries. Optionally, you can configure the location of source- and javadoc-files. These aren't used in the analysis, but can be viewed from the explorer.

First exploration

After loading the class files, you get to the Application Guide. This guide presents the six main parts of the tool, giving a short description and the option to get more information on a part or to Launch a particular one. The first is the Explorer, used to "navigate through software as a web of relationships". (The segmentation into those parts is only done for the convenience of the beginner - they are integrated rather seamlessly and you will later switch between them without even noticing.)

The Explorer can best be described as an interactive form of a simplified UML class diagram. There is always one entity (class, interface or package) at the center of the screen, surrounded by its dependants and entities it depends on. The type and level of dependencies shown can be configured in detail - which is necessary because showing all dependencies can quickly produce a complex, useless mess. After fiddling with the settings a little bit, we can finally get a usable view, for example focused on incoming dependencies. There are also some Quick Filters predefined for typical configurations. If you hover the mouse cursor over an entity, a window containing detailed information pops up.

By clicking on an entity, that entity gets centered in the view. This way you can browse through the system step by step. There are also predefined views on specific aspects of the system, for example all the existing inheritance relationsships. Unnecessary to mention that you can also search for a specific entity by name.

The analysis Summary

Probably the most important part of the Analyzer Edition is the Summary. The Summary is a textual description of the system, giving you some general statistics and pointing out potential problems, linked to sections containing more information. The types of potential problems Small Worlds analyses are tersely described in the help system.

Let's take a look at a tangle (a tangle is a group of entities with circular dependencies). After clicking on the link and choosing one of the identified tangles, the Explorer is showing the tangle. To further analyze it, we can activate the Details view and highlight a specific circular dependency.

What now?

OK, certainly a tangle is a bad thing. But what do we do about it? This is were Small Worlds seems to let us down. Neither in the online help, nor in the manual did I find any advice on how to break a tangle. Finally I found a message in the Small Worlds forum, promptly and concisely answered by the support team, as seems to be generally the case. It explains that you should find the dependency that doesn't make sense (where a simple concept depends on a more complex one, for example - hopefully a weak dependency) and remove it. Sadly, it doesn't give any hints on how such a dependency might be broken - though I suspect you would get an equally concise answer if you asked (probably pointing out something along the lines of the Dependency Inversion Principle).

Other metrics and views

Small Worlds also provides a whole bunch of other, more conventional metrics like instability, abstractness and imbalance (distance from the main sequence) of packages. The program thereby colors the values by potential criticality and makes it easy to spot entities demanding special attention. Some of the metrics can also be portrayed in statistical charts.

If you want to share the above metrics and the Summary with your colleagues without having them to crowd around your monitor, you can save every screen as HTML and/or GIF file as appropriate or even create a whole hyperlinked HTML-report.

Another interesting view is the Skeleton view. It shows the "dependency hierarchy" of the system in a form of a pyramid - the entities with only outgoing dependencies on the bottom, those with only incoming dependencies on the top. Ideally, this view actually shows you a triangle - major deviation from this shape can point out problems in the design. Tangles, butterflies etc. can be specially colored (as can be done in the explorer). You can also highlight the dependants of an entity by clicking on it.

For the latter there is even another specific view called "What If". Here the classes and interfaces are grouped by packages. If you click on an entity, a simple animation is started, connecting it to all its dependants, thereby showing you the potential effects of a change in that entity.

Something missing?

The information Small Worlds presents is quite voluminous and might even be overwhelming at the beginning. Nevertheless there are some things, Small Worlds won't tell you.

For example, Small Worlds gave the above mentioned "middle sized" system a stability rating of 94%, though I experienced it to be rather hard to maintain and extend. This was because of a lot of indirect coupling, like one class expecting another class to organize an array in a specific way. Those dependencies aren't considered by Small Worlds, and would probably be very hard to.

There are also other, more "mechanical" design heuristics Small Worlds currently doesn't take into account, like the Law Of Demeter. Another request from the forum is analysis on the method level in addition to the current class/interface/package levels.

Besides this, Small Worlds also doesn't record the history of a project. So, if you want to know how some metrics changed while the design evolved, you need to keep track of that in some other way.

Fortunately, the folks at Information Laboratory seem to be fully aware of these issues, so that we can look forward to upcoming releases. There are talks about promising features like refactoring wizards, history tracking with visualization of structural changes and charts for metrics through the lifetime of a project.

Conclusion

Small Worlds is certainly a very powerful design analysis tool. The information it presents will give you much to think about and might highlight critical problems you weren't previously aware of.

But you shouldn't expect it to do your work for you (as you shouldn't expect from any tool). You still need to interpret the information in the light of your situation and find the right ways to act accordingly.

Therefore I don't think this tool could or should replace a manager's trust in the development team or the extensive care for new team members. An introduction by Pair Programming, accompanied with some high-level class diagrams on the white board will still be way more effective than browsing in the Small Worlds Explorer in most situations.

If you are aware of these social and technical limitations, Small Worlds can without doubt be a very effective tool for analyzing and teaching specific critical design aspects in your object oriented projects.

Resources