Explanations should take around 50 words. Some slack will be given to explanations with more words (however, don't press your luck too many times on this); explanations a page or more long will lose five points.
As top-down refinement proceeds, the newer modules should be less abstract than the older modules. Refinement defines the behavior of an existing module in terms of its constituent modules, which adds more detail about the existing module, reducing the abstraction level. In addition, the newly revealed constituent add details to the design, further reducing the abstraction level.
The answer is essentially the same for bottom-up refinement, but the directions are reversed.
The part-of (or aggregation) relation indicates one class is contained in
another class. However, the containing class still deals with contained class
via the contained class's interface (in the absence of idiotic constructs such
as C++ friend classes), which tends to limit the coupling effect.
The is-a relation between two classes brings along inheritance, which means the
child class becomes fully informed of the parent's details (with the exception
of private parent components). This greatly increases coupling because
changes to the parent class's components are immediately visible to the child
class.
For functional designs, high fan-out may indicate that refinement is being carried out at too fine a level, revealing too much detail per level and not creating the appropriate abstractions between levels.
Should this be the case, the fix would be to coarsen refinement so it creates fewer modules per level and decreases fan-out, and add more levels to cover the same amount of detail.
A number of people suggested that high fan-out from module M indicated low cohesion in M, presumably on the assumption that each of M's subordinate modules preforms separate, independent behaviors. While high fan-out from M may indicate low coupling in M, an examination of M's specification of external behavior would provide a more reliable indicator than would high fan-out.
For object-oriented designs, high fan-out may indicate an excessive number of classes without real distinction. As in functional design, it may also indicate the class hierarchy at that point in the design is too coarse. Note, however, that high fan-out may also indicate a high level of reuse between the parent and children classes, which, ignoring coupling, is usually a good thing.
The fix for excessive classes would be to re-examine the classes to determine if two or more of them aren't really the same class with minor variations, reducing the number of child. A coarse inheritance hierarchy can be refined by including a few more classes between the parent and its children, in a way similar to what was done for functional design.
Logical design clarifies a module's behavior by providing more information than is provided about the module in the architectural design. It might be reasonable to skip logical design for a module when the module's interface and behavior are well defined in the architectural design, as might be the case when modules are pulled from standard libraries or refer to well-known behaviors such as sorting (although you'd still have to indicate which modules from which libraries and what kind of sorting).
This page last modified on 28 February 2000.