Monitoring and Enforcing Design Dependencies with Verifydesign

lthough software and architectural reuse has been a constant drumbeat in the technical press for many years, it's still common to see code and designs that violate many principles of reuse. For example, how many software systems have you seen that are similar to the diagram in Figure 1? Or when trying to reuse code, you find an exisiting component with functionality you need (Component E), but you also find it impossible to reuse the component because it depends on Component C—which your new system doesn't need. You might add that component only to find that, in turn, Component C depends upon Component A.

Such interdependencies are still typical of many software projects today. Of course, such code isn't generally produced on purpose. A team typically lays out the architecture, then starts coding up the system. As they code, bad dependencies unintentionally slip in—sometimes that just happens—and the team often doesn't even discover such unwanted dependencies until later in the development cycle.