A fundamental concern in designing in a program is how the modules depend on one another. Roughly speaking, a moduleA depends on a moduleB ifA won\u2019t work properly withoutB working properly. Dependence is a liability, because it makes it hard to mod- ify the program locally. If you changeB, you may have to make a compensating change toA (and then to whatever depends onA, and so on). For this reason, dependences are often described asc o up ling, and the attempt to reduce the dependences between mod- ules asde coupling.

of the program, and is generally small and fairly easy to construct. You should draw MDD\u2019s as part of your design process before you start writing code, and you will often \ufb01 nd it helpful to draw an MDD for a program that you\u2019re maintaining or using in some way if one doesn\u2019t already exist.

\ue000e idea of module dependences was \ufb01rst articulated by David Parnas in a seminal paper entitled Designing Software for Ease of Extension and Contraction (IEEE Transac- tions on Software Engineering, Vol. SE-5, No 2, 1979). Parnas de\ufb01ned theu se s relation amongst modules as follows: a moduleA uses a moduleB if \u201ccorrect execution of \u2018\u2019B may be necessary forA to complete the task described in its speci\ufb01cation\u201d. He goes on: \u201c\ue000at is, A uses B if the correct of functioning ofA depends upon the availability of a correct implementation ofB\u201d.

Note that he saysmay be necessary and noti s necessary. Dependency relations, like modi\ufb01es clauses (which we learnt about earlier in our study of procedure speci\ufb01cations) are actually more useful for what they omit than for what they state: ifA usesB, we can\u2019t say very much, but ifA doesnot useB, then we know that we can safely make changes toB (or remove it entirely) without a\ufb00ectingA.

\u00b7Reusable subsets. Which groups of modules can we take and reuse in another pro- gram? Suppose we want the functionality thatC provides. \ue000en sinceC usesE we will need to takeE also. So the set of modules{C,E} forms what Parnas calls a \u2018reusable subset\u2019. If we wantB, we need everything; that is, there is no reusable subset that containsB that isn\u2019t the whole program.

modules on which they depend, and so on. If the program is layered, this strategy will allow us to avoid writing stubs entirely. Or in the case of a program like ours, it will tell us which modules must be implemented together or which stubs we must write. For example, if afterC we implementD, we will need a stub forA, sinceD uses it.

\u00b7Division of Labour. \ue000e uses diagram helps \ufb01gure out how to allocate the task of implementing modules to di\ufb00erent teams. Suppose we have two teams. It\u2019s clear that dividing into{A,B,D} andC,E is a better choice than dividing into{A,E} and{B,C,D}, for example, because it allows subprograms to be put together that can be tested independently with fewer stubs.

change propagation, and also for answering questions about which modules should be examined to trace a bug in the behaviour of one module (or to verify that the module operates correctly).

\u00b7Modern programming features. It\u2019s not obvious how to draw a uses diagram for a Java program, in which there are modules that are actually speci\ufb01 cations and not execut- able code (ie, interfaces), and in which relationships between modules can arise on the \ufb02y at runtime (because passing an object essentially passes a handle on the code of its class).

\ue000e MDD notation described in your course text addresses the transitivity problem. A moduleA is said to depend on a moduleB \u2018if a change to thesp e ci\ufb01c ation ofB might causes a change inA\u2019. Every module is assumed to have a speci\ufb01cation, and to be re- quired to satisfy it.

So now it\u2019s clear that some kinds of changes don\u2019t propagate. If we want to changeB, but only the implementation and not the speci\ufb01cation, thenA need not change. If we want to change the speci\ufb01cation ofB, thenA is likely to need changing. Oddly, this may not require a change to the implementation ofB; we might be weakening the speci\ufb01 cation, for example, to admit a more e\ufb03 cient implementation at some later point. Questions about bug tracking are also easier to address now. A bug inB may indeed causeA to fail to meet its speci\ufb01cation; whether it does will depend on whetherB now fails to meetit s speci\ufb01cation.

Even this new notation, however, is not perfect. It doesn\u2019t allow us to say thatA depends onB via a speci\ufb01cation that isnot the complete speci\ufb01cation ofB \u2013 that is, the one its implementor contracted to. \ue000is turns out to be a crucial distinction in many object oriented programs. When we study design patterns, we\u2019ll see that many of them rely on the introduction of a new speci\ufb01cation between two modules that weakens the coupling between them.

\ue000is term, we\u2019ll therefore use a new dependency notation that I have developed. It\u2019s not perfect, but it does seem to give us the extra expressive power we need without becom- ing too complicated. You\u2019ll be using this notation in your own work, so you should make sure you understand it well!