I have been looking at metrics for coupling and also look at DSM.
One of the tools I’ve been using looks at coupling between ‘modules’ with a module being a unit of distribution (in this case a .net assembly).
I feel that I should be more interested in looking at coupling between packages (or namespaces) than with units of distribution.
Should I be more concerned with coupling between packages/namespaces (ensure that abstractions only depend on abstractions, concrete types depend on abstractions and their are no cycles in the dependencies so that refactoring and extending is easy) or should I be concerned with whether I can deploy new versions without needing to update unchanged units of distribution?
What does anyone else measure?
For what it’s worth, my gut feel is that if I focus on the package/namespace coupling then the unit of distribution coupling will come for free or at least be easier.
First, it’s easy to go overboard looking at dependencies and coupling. Make sure you aren’t over complicating it.
With that disclaimer out of the way, here’s what I suggest.
There’s really 3 different views to dependency/coupling management: 1) physical structure (i.e. assembly dependencies) 2) logical structure (i.e. namespace dependencies) 3) implementation structure (i.e. class dependencies)
For large apps, you will need to at least examine all 3, but you can usually prioritize.
For client deployed apps, number 1 can be very important (i.e. for things like plug-ins). For apps deployed inside the enterprise (i.e. asp.net), item #1 usually turns out to be not so important (excluding frameworks reused across multiple apps). You can usually deploy the whole app easy enough not to take the overhead of a complicated structure for #1.
Item #2 tends to be more of a maintainability issue. Know your layer boundaries and their relationship to namespaces (i.e. are you doing 1 layer per namespace or are you packaged differently at the logical level). Sometimes tools can help you enforce your layer boundaries by looking at the logical dependency structure.
Item #3 is really about doing good class design. Every good developer should put forth a pretty good amount of effort into ensuring he is only taking on the proper dependencies in his classes. This is easier said than done, and is typically a skill that has to be acquired over time.
To get a bit closer to the heart of your question, item #1 is really about how the projects are laid out in the VS solution. So this isn’t an item to measure. It’s more of something you setup at the beginning and let run. Item #2 is something you might use a tool to check during builds to see if the developers have broken any rules. It’s more of a check than a measure really. Item #3 is really the one you’d want to take a good look at measuring. Finding the classes in your codebase which have a high amount of coupling are going to be pain points down the road, ensure the quality on those guys. Also, measuring at this level allows you to have some insight into the quality (overall) of the codebase as it’s evolved. In addition, it can give you a red flag if someone checks some really raunchy code into your codebase.
So, if you want to prioritize, take a quick look at #1 and #2. Know what they should look like. But for most apps, item #3 should be taking the most time.
This answer, of course, excludes huge frameworks (like the .NET BCL). Those babies need very careful attention to #1. 🙂
Otherwise, you end up with problems like this: ‘Current versions of the .NET Framework include a variety of GUI-based libraries what wouldn’t work properly in Server Core’ http://www.winsupersite.com/showcase/win2008_ntk.asp
Where you can’t run .NET on a GUI-less install of Windows Server 2008 because the framework takes dependencies on the GUI libraries…
One final thing. Make sure you are familiar with the principles behind good dependency/coupling management. You can find a nice list here:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod