Topic: identifying program modules

topics > computer science > programming > Group: program module

program design

decomposition of a system into levels
deployable module or assembly
design for change
program module as encapsulation
function definition
general vs. specific purpose systems
hierarchical structures
information hiding
interface between program modules
language flexibility
localized understanding
object-oriented design
separate a module's interface specification from its implementation
software components
software tools


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 up

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 up

Quote: locality of information (modules): a programming system should keep related pieces of behavior and data together [»taivA4_1993]

Subtopic: cluster as globals up

Quote: use clusters to maintain a related set of global variables [»naurP3_1969, OK]

Subtopic: functional composition up

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 up

Quote: lazy evaluation is a powerful tool for modularization

Subtopic: separate data from program up

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 up

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 up

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 up

Quote: module decomposition into submodules without overlapping or missing responsibilities [»parnDL3_1985]

Subtopic: decomposing distributed or parallel applications up

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 up

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

Related Topics up

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)

Updated barberCB 5/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.