jump to navigation

Dependency Analysis at Design Time January 10, 2010

Posted by Peter Varhol in Architectures, Software tools.

Code is a complex entity, and as you accumulate thousands of lines of code or more in an application, it becomes difficult for a single person to understand at a detailed level.  Further, over time, with many hands touching it during its lifecycle, it almost inevitably becomes highly disorganized and “brittle,” as both Ed Yourdon and Fred Brooks have described.

In any non-trivial application, there is code that calls other code as a part of its execution process.  We say that if module A calls module B, then A is dependent upon B.  Dependencies like this are inevitable, unless we wanted to end up with a Fortran program, and they are in the aggregate desirable, since they help us create a more modular program.

There are a number of rules that we can apply to these dependencies, in order to make code more understandable and maintainable.  For example, if A calls B and B calls C and C calls A, you have a cyclic dependency, which can be difficult to understand and debug.

Dependencies that change frequently can also be a problem.  If A calls B and C, but with the next version A calls D and D calls B, the dependencies can be termed unstable.  When dependencies move around in that manner, it becomes more difficult for developers to remember the overall structure of the application.

I’ve been exposed to some dependency analysis tools in the past decade – Compuware’s Optimal Advisor, which was a rogue effort from my own development lab when I was at Compuware, IBM’s Structural Analysis for Java (SA4J), and Lattix Design Structure Matrix (DSM).  DSM has grown out of research conducted at MIT on representing and analyzing complex systems, and there is an active community pursuing research and development into its use.  DSM represents an application in a matrix view, with classes listed on both the horizontal and vertical axes.

It’s a challenge to encourage developers to perform this kind of analysis.  Optimal Advisor is long since gone, while SA4J is still available through IBM’s AlphaWorks program, but doesn’t appear to have been updated since 2004.  Unless there is an immediate bug or other problem with the code, architecture issues that may affect an application’s maintainability aren’t a high priority, even though from a lifecycle standpoint, they should be.

But Lattix, a commercial solution, is around and healthy, and has recently embarked upon a way to become much more relevant during the early stages of the application lifecycle.  Lattix for UML/SysML and Lattix for Rhapsody both provide a way to look at a Unified Modeling Language (UML) model, identify dependencies between classes and other aspects of these diagrams, and find and fix bad dependencies in the diagrams themselves.  This innovation means that you can produce better software designs by applying dependency analysis at the beginning of the development lifecycle.

I’m looking forward to actually giving this a try.  I don’t have access to Rhapsody, but the UML version should work with other UML tools like Enterprise Architect, albeit without the plug-in integration.  Being able to use dependency analysis at the design phase will simply result in better software designs when it counts.



1. Just What is Dependency Analysis? « Cutting Edge Computing - January 31, 2010

[…] by pvarhol in Architectures, Software development. trackback A couple of weeks ago I wrote a post on using dependency analysis at application design time.  That generated a good bit of interest, […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: