Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Improving a Structure Chart
This material was covered during lectures on February 28, 1997.
In this second major step of ``Structured Design,'' we repeatedly look for design problems and take steps to correct them. The assessment of designs (to find design problems) is discussed on this page and the next two pages (on levels of cohesion) and levels of coupling) that follow it. Heuristics for improving designs are given after that and, finally, the example is concluded.
Pressman's text, Software Engineering - A Practitioner's Approach discusses functional independence, including cohesion and coupling, in Sections 10.4.2 - 10.4.4 (pages 333-338).
Page-Jones' book, The Practical Guide to Structured Systems Design devotes three chapters to this topic - See Chapters 5-7, pp. 58-146.
If possible, each module will be functionally independent: It will have one well defined job, and it will have a simple interface, so that it can be implemented independently from the rest of the system, and then combined with the rest of the system.
We'll assess ``functional independence'' by evaluating
If possible, no module will be overly complex:
Once a module's algorithm has been chosen, and pseudocode added to the ``module specification,'' this specification should be at most two (or three) pages long.
(Almost) every module will have low fan-out - It should (directly) call at most seven other modules - unless the module corresponds to a ``transaction center'' on the DFD (in which case, the module might call lots of others, but might also be quite simple).
On the other hand, no module should be trivial!
The set of all modules that any given module ``influences'' should be easy to identify (and, ideally, small).
The scope of effect of a module is the set of other modules; module B is in the ``scope of effect'' of module A if the behaviour of (an execution of) module B is affected by a decision made by (an execution of) module A.
The scope of control of a module is the set of other modules that the given module can call, either directly or indirectly.
You could define the ``scope of control'' inductively as follows:
Whenever possible, the scope of effect of a module should be contained in the scope of control of that module, because the ``scope of control'' of a module is easy to discover from the structure chart.
Tramp data and tramp control flags are data and control signals that are generated as outputs by one module and then ``migrate'' through a large part of the structure chart, being passed as input or returned as output by numerous modules, without being inspected or changed, until they reach the module(s) where they're used.
Tramp data and tramp control flags are a sign of problem (called decision splitting) - that a decision made in one module will effect the behaviour of other modules, and it will difficult to discover which other modules are affected by this decision. As a corollary: If the first module is changed, then changes may be required in the other modules as well.
Therefore, ideally, a structure chart shouldn't include any tramp data or tramp control signals.
The system should not include ``redundant'' modules - that is, there should be no sets of two or modules that all do the same thing (and might be expected to ``do it'' the same way).
Whenever possible, each module's behaviour should be ``predictable.'' In particular, whenever possible, each module should have the property that if you call it two or more times with the same inputs, then it will produce the same outputs each time.
Some exceptions to this rule are unavoidable. These involve
Try to keep the number of these ``exceptions'' as small as possible.
Information Hiding should be used: That is, there should be a well defined ``interface'' between
and the rest of the system. Each of these ``interfaces'' should consist of a small set of simple modules, whose only job is to act as part of the interface, and such that the rest of the system can only access the data area or I/O device by calling one or more of the modules in the interface.
Then, if the implementation of a data area is changed, or if an I/O device is changed, then (ideally) it is only necessary to change the interface modules.
It won't always be possible to achieve all this. Fixing one ``design problem'' can sometimes cause, or aggravate, another, and you'll find it necessary to make tradeoffs when dealing with conflicting design goals.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Improving a Structure Chart