Comments on: Dependencies are In http://jbrugge.com/blog/2006/06/09/dependencies-are-in/ this and that and some of those Wed, 7 Jan 2009 05:29:53 +0000 http://wordpress.org/?v=2.0.4 by: John http://jbrugge.com/blog/2006/06/09/dependencies-are-in/#comment-7 Wed, 05 Jul 2006 18:11:05 +0000 http://jbrugge.com/blog/2006/06/09/dependencies-are-in/#comment-7 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 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

]]> by: Neeraj Sangal http://jbrugge.com/blog/2006/06/09/dependencies-are-in/#comment-6 Wed, 05 Jul 2006 02:34:14 +0000 http://jbrugge.com/blog/2006/06/09/dependencies-are-in/#comment-6 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. 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.

]]>