Dependencies are In
Published June 9, 2006 by John
There seems to be some small groundswell of attention to Dependency Management lately, although it may always be something of a fringe topic. In particular, I’m talking about it’s meaning as in “making decisions about the structure of your system so that it has the kinds of dependencies between pieces that you want.” It’s important, though, so I’m glad to see more people writing about it - that is, why you should care about the dependencies, how you can think about them, tools you can use to make them visible, and techniques you can use to rearrange things in your system so that dependencies that are there are the ones you want.
- Bill Venner talked about it in his thread on Where Did All The Beautiful Code Go?. One of the points is that there are plenty of tools available now to help you build the great code that you wanted to at the beginning. Feedback as you go is a constant refrain, from static code analysis to unit tests to design metrics (such as dependency metrics)
- My friend Kirk has made it a central part of his new blog, as well as offering a valuable tool, JarAnalyzer, to make component-level dependencies visible. He makes some excellent points on the why and how of looking at component dependencies.
- Andrew Glover has a series of articles on code quality, with dependency management as one of the key elements.
It’s certainly not a new idea, but it seems it has been relegated to the realm of Large Scale Projects and Big Tools, or else the people doing research on it haven’t found the bridge to the mainstream yet. In general, I think people just don’t tend to think about it until too late in most projects, when the system is getting unwieldy but you’re too committed to the current structure to do anything but live with it. Of course, the reason most people don’t do it is because there’s not much in the mainstream of tools to help. With low-barrier-to-entry tools now like JDepend and JarAnalyzer, perhaps it will be easier to start learning and applying.
I’ve run across some of the management or analyst level tools like Design Structure Matrix, but none of the tools supporting these are either open-source or at the level that a designer or architect would typically use. I don’t discount approaches like these as invalid, just as inaccessible.
Filed under Software
Posts
Sorry for the belated response, as I just happened to chance upon your blog now. I co-authored the paper at OOPSLA 2005 where we proposed the use of Dependency Structure Matrix (DSM) for the explicit management of dependencies in complex software. (http://sdg.lcs.mit.edu/pubs/2005/oopsla05-dsm.pdf)
There are significant benefits of DSMs over conventional approaches: They scale exceptionally well; we have created dependency models for system with more than 20,000 elements without any problems. They allow you to create a precise big picture view of the architecture that is easy to understand. They allow you to focus in on the dependencies that are problematic very quickly. And they allow you to specify dependency rules in a succint way that allows you to maintain the integrity of the architecture over its life cycle.
Note that some problematic dependencies are easy to fix. For instance, problematic static dependencies are generally easier to fix than others. Sometimes they can even be fixed by moving files or changing namespaces. However, there are also dependencies that are hard to fix but often those are the ones that highlight critical architectural flaws. The problematic dependencies don’t have to be fixed but knowing what they are allows the architecture to be improved over time. Finally, the benefits of visibility extend even to systems which are already modular and well architected through better understanding of the impact of change.
Originally DSMs were applied in the task and organization domains. We have applied this approach to software in Java, C/C++, .NET and Oracle. This could be considered a partial vindication of the generality of this approach. I do know of many architects who are happily using this approach. However, I suggest that you try it out and then you can decide if these tools are at a level that an architect would or could use.
Neeraj Sangal
Lattix, Inc.
Neeraj,
Thanks for the pointer to the OOPSLA paper. It looks like a good description of the process, and an example to boot. I’ll have to give it a read.
Thanks,
John