bfish.xaedalus.net

Werd homez.

Here is a Perl script that will extract dependency information from all the C++ source and header files it finds within a specified directory structure, and spit out a bunch of interesting stuffs it can find out about them. It would be fairly trivial to convert to parsing Java or something, essentially just change “.cpp” to “.java” and “#include” to “import” or whatever it is.

EDIT: Version 2.0 released. Changes since 1.1:

• Fixed a couple of fatal bugs;
• A few more command line options;
• It warns if the dependency graph is not levelizable;
• Experimental support for Java.

EDIT: Version 1.1 released. Changes since 1.0:

• Better documentation;
• More command line options;
• Option to generate a PNG image of the dependency graph (uses GraphViz; example below).

It gives each component (.cpp/.h pair) a level:

Level 1 means it depends only on external libraries (including system libraries); it can be tested independently of any other component in the system.

Level 2 means it depends on external libraries and one or more members of level 1; it can be tested independently of other components in levels 2 and higher.

Level n means it depends on external libraries and one or more members of levels <n; it can be tested independently of components in levels >n.

Circularly dependent components share a level and are marked with an asterisk.

It then calculates the normalised cumulative component dependency (NCCD):

num_of_dependencies / (num_of_components * log(num_of_components))

An NCCD of 1.0 is the theoretical baseline of a system in which the dependency graph resembles a balanced binary tree. <1 is loosely coupled, >1 is becoming more tightly coupled. In practice, anything <1.5 is good, and anything >2.0 is not so good. 0.0 would mean that none of the components depends on any other.

And when you achieve low coupling you automatically acheive high cohesion; the two are intertwined. Components become more cohesive when you strive to keep only closely tied functionality within each single component. Refactor mercilessly whenever a component is becoming too eclectic, and keep in mind the dependency graph when factoring out functionality into a new component. This encourages appropriate reuse, as it makes interfaces more general and allows clients to gain access to some functionality that they want without pulling in a load of useless garbage at the same time.

Sign off!

Acknowledgements/bibliography:

Large Scale C++ Software Design, John Lakos, 1996, Addison-Wesley Publishing

Caveats:

Although direct circular dependencies are allowed, indirect circular dependencies are not so far. That is to say, cycles in the dependency graph passing through three or more components. Behaviour in this case is undefined.