Home

The Structure and Value of Modularity in Software Design

The Structure and Value of Modularity in Software Design, K.J. Sullivan, W.G. Griswold, Y. Cai, B. Hallen.

The concept of information hiding modularity is a cornerstone of modern software design thought, but its formulation remains casual and its emphasis on changeability is imperfectly related to the goal of creating value in a given context. We need better models of the structure and value of information hiding, for both their explanatory power and prescriptive utility. We evaluate the potential of a new theory—developed to account for the influence of modularity on the evolution of the computer industry — to inform software design. The theory uses design structure matrices to model designs and real options techniques to value them. To test the potential utility of the theory for software we represent a model software system in its terms—Parnas’s KWIC—and evaluate the results. We contribute an extension to design structure matrices and show that the options results are consistent with Parnas’s conclusions. Our results suggest that such a theory does have potential to help inform software design.

This is really neat stuff; the authors use options theory to estimate the added value of a modular design relative to a less-modular design. It's always nice when an informal engineering intuition can be analyzed more precisely.

By neelk at 2007-04-11 16:02 | Software Engineering | other blogs | 7860 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Sullivan gave a talk today at Iowa State

Sullivan gave a talk today at Iowa State about this. He started off talking about how companies like Amazon have given up on monolithic development in favor of using components/services.

After that he talked at length about constructing a graph of inter-dependences, and then decomposing it into dense subgraphs. The best graphic was a picture of the Mozilla call graph before and after it went open source. The version Netscape released had noise all over the adjacency matrix, while the more recent open source versions have almost everything in tight boxes around the main diagonal.

He also showed a dependency graph for some aspect oriented code and how changing the name of one function would put a wrench in all the aspect code. Good visualization to back up the arguments of fellow AOP neigh-sayers :)

The take-home point for me was that we need a set of software analysis tools that construct a dependency graph of data types and functions, decompose the graph into a "clique partition", then output warnings for dependencies between "cliques" or "cliques" that are too large.

I'll talk to my colleague who wrote GLOW when he gets back from Poland next week and see if he wants to implement this functionality.

By Chad Brewbaker at Thu, 2007-04-12 22:31 | login or register to post comments

Sounds interesting

keep us updated about such a tool

By David Teller at Fri, 2007-04-13 15:57 | login or register to post comments

Some notes on this paper,

Or how the Internet is dangerous. The paper that was linked was never published. Apparently ESEC/FSE 2001 must have rejected this.

I also asked Dave Parnas about this work, and his reply was not overly positive (I can't repeat it here without permission, which I don't have). His main point however was that this method requires some data to be available (the ``experiments'') for comparison, and in real life this data would rarely be available [me: because it would be much too expensive to collect].

On the other hand, the ideas about dependency graphs and diagonal-dominance are known to a lot of people in software engineering, and they are indeed quite useful. Too bad that more tools do not have this built-in.

By Jacques Carette at Wed, 2007-06-06 00:25 | login or register to post comments