Group:
program design
Topic:
decomposition of a system into levels
Topic:
deployable module or assembly
Topic:
design for change
Topic:
program module as encapsulation
Topic:
function definition
Topic:
general vs. specific purpose systems
Topic:
hierarchical structures
Topic:
information hiding
Topic:
interface between program modules
Topic:
language flexibility
Topic:
localized understanding
Topic:
object-oriented design
Topic:
separate a module's interface specification from its implementation
Topic:
software components
Topic:
software tools
| |
Summary
The rules for identifying modules vary widely. Some examples are reduce compilation dependencies, increase system use, prevent duplication, reduce data dependencies, use minimal subset, avoid implementation assumptions, have one for each entity, or one for each design decision, or simple with standardized interfaces, called only by layer above, avoid assumptions about available functions. As Parnas noted, this is a difficult task.
Dijkstra noted the ten orders of magnitude between execution and instruction. This argues heavily for modules. The problem is that those modules are arbitrary and tend to become grab bags organized around some property. Thesa attacks the problem directly by creating instructions that can take any amount of time to run. Now a long program becomes a small number of instructions. (cbb 1/90)
Subtopic: identifying modules 
| Quote: module decomposition is independent of a hierarchical structure [»parnDL12_1972]
| | Quote: each module's structure should be simple enough to be understood fully [»parnDL3_1985]
| | Quote: change a module's implementation without knowledge of the implementation of other modules and without affecting the behavior of other modules [»parnDL3_1985]
| | Quote: secrets are more important than interfaces or roles; secrets clarify the responsibilities of a module [»parnDL3_1985]
| | Quote: well-structured programs limit the assumptions that parts make about each other
|
Subtopic: module as related data/program
| Quote: locality of information (modules): a programming system should keep related pieces of behavior and data together [»taivA4_1993]
|
Subtopic: cluster as globals
| Quote: use clusters to maintain a related set of global variables [»naurP3_1969, OK]
|
Subtopic: functional composition
| Quote: Unix programs are easily connected with other programs because they have few features and do one thing well [»kernBW1_1979]
| | Quote: in Unix, produced a rhyming dictionary by composing existing functions with a reverse function [»kernBW1_1979]
| | Quote: avoid unordered modules, each implementing a function; difficult to integrate with each other; quadratic growth in complexity [»dijkEW2_1971]
| | Quote: use higher-order functions to glue together simple functions; e.g., vector sum as 'reduce add 0' and list concate as 'reduce cons b a' [»hughJ_1984]
|
Subtopic: lazy evaluation
| Quote: lazy evaluation is a powerful tool for modularization
|
Subtopic: separate data from program
| Quote: data independence means maintaining data/file structures separately from programs; e.g., the size of the ZIP code field [»morgH_1980]
|
Subtopic: separate domain from presentation
| Quote: separate the presentation code from domain code; the UI should only display information [»fowlM3_2001]
| | Quote: domain code is easy to port while presentation code is tied to the operating system and hardware [»fowlM3_2001]
| | Quote: while presentation code is difficult to test, can test the domain code through direct calls [»fowlM3_2001]
|
Subtopic: module size
| Quote: module decomposition produces many small modules; software module guide for completeness, convincing arguments, software maintenance [»parnDL3_1985]
| | Quote: some experiments show that multi-page modules have the lowest errors per line of code [»shneB_1985]
| | Quote: it is better to split up functions into smaller pieces which may be useful for other purposes; abstraction [»wileDS11_1973, OK]
| | Quote: 20% of maintenance cost due to procedure size; optimal size was 44 executable statements [»bankRD11_1993]
| | Quote: programmers who did not use large modules had 38% fewer defects and were nearly twice as likely to pass the acid test [»demaT5_1989]
|
Subtopic: submodules
| Quote: module decomposition into submodules without overlapping or missing responsibilities [»parnDL3_1985]
|
Subtopic: decomposing distributed or parallel applications
| Quote: ideal reactive systems produce outputs simultaneously with inputs; allows decomposition without affecting behavior, timing, or interleaving [»benvA9_1991]
| | Quote: if organize modules as multi-tasks, can delay task division until later; otherwise the initial architecture determines the tasks [»clarDD12_1995]
|
Subtopic: problems with modules
| Quote: modularity decays; in 1989, the change history clearly separated two clusters of modules; by 1996, these clusters had broken down [»eickSG1_2001]
| Quote: finite automata do not support hierarchical design or concurrency; large, real-time systems are impossible to understand
[»benvA9_1991]
|
Related Topics
Group: program design (13 topics, 454 quotes)
Topic: decomposition of a system into levels (49 items)
Topic: deployable module or assembly (12 items)
Topic: design for change (76 items)
Topic: program module as encapsulation (28 items)
Topic: function definition (25 items)
Topic: general vs. specific purpose systems (11 items)
Topic: hierarchical structures (46 items)
Topic: information hiding (50 items)
Topic: interface between program modules (55 items)
Topic: language flexibility (34 items)
Topic: localized understanding (43 items)
Topic: object-oriented design (30 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software components (11 items)
Topic: software tools
(20 items)
|
