Group:
data type
Group:
program design
Topic:
abstract data type
Topic:
abstraction in programming
Topic:
aspect-oriented programming
Topic:
declaration scope
Topic:
decomposition of a system into levels
Topic:
design for change
Topic:
families of programs
Topic:
identifying program modules
Topic:
information hiding
Topic:
interface between program modules
Topic:
localized understanding
Topic:
object-oriented classes
Topic:
programming with a database of modules
Topic:
separate a module's interface specification from its implementation
Topic:
software components
Topic:
software tools
Topic:
system integration
| |
Summary
A difficult, yet important, programming task is to break a problem into independent modules. These independent modules form a structured problem representation. A common decomposition is by hierarchical layers with sub-layers affecting only their parents. Each layer hides a source of indeterminacy from higher levels; i.e., the representation of a layer can be changed independently of other layers. The resulting insensitivity to change is another name for independence. It can be applied per module as well as per layer. This means that modules are interconnected only by reference or uniform data representation.
The content of each module should not effect its use; execution sequences should not effect its behavior; and the interconnections between modules should be flexible. Since module modification must be anticipated, difficult design decisions need to be identified before modules are determined. Effective decomposition needs to be as complete as possible; this implies that the specification tools must handle a large number of small modules. Decomposition should apply at all levels from atomic programming units to major programs or collections of programs. Ideally there is an identifiable module for each individual input or output entity in the real world. (cbb 5/80)
Subtopic: encapsulation as module 
| Quote: a programming language needs modularization to encapsulate abstract concepts [»wirtN3_1976]
| | Quote: independent modules require encapsulation and specification [»liskB_1996]
| | Quote: design for change by making a system flexible, extensible, and portable. Encapsulate the areas that are likely to change [»stroB_1991]
| | Quote: an interface should solve only one problem and let client routines do the rest; e.g., a parser calls client-supplied semantic routines [»lampBW10_1983]
| | Quote: encapsulation reduces the need for information hiding
|
Subtopic: module as hiding information
| Quote: a module should hide a design decision instead of dividing a program into major steps; information hiding [»parnDL12_1972]
| | Quote: a module hides a data structure with its internal links, accessing procedures, and modifying procedures [»parnDL12_1972]
| | Quote: design modules by hiding difficult or likely-to-change design decisions; not flowcharts or processing steps [»parnDL12_1972]
| | Quote: a module should hide the sequence for processing an item; also character codes and alphabetic ordering
|
Subtopic: module as well-defined, abstract unit
| Quote: an independent component of a system should appear only once [»ingaDH8_1981a]
| | Quote: a functionally strong module performs only one generic function, like square root; highly reusable [»joneTC4_1979b]
| | Quote: write large programs as segments (one page, one entrance and exit); refer to other segments as needed [»millHD_1971_, OK]
| | QuoteRef: conwME7_1963 ;;396 separable program if collection of modules with one-way, non-looping, discrete, flow of input and output
| | Quote: divide task-level plans for arms into action chunks with segmentation at interdependencies [»roacJW10_1987]
| | Quote: CLU uses a database of descriptive units; built incrementally; shows abstractions, parameters, operations, clusters, cross references [»liskBH2_1976, OK]
| | Quote: should not combine simple functions into one component [»parnDL5_1978]
| | Quote: a programming language needs modularization to encapsulate abstract concepts [»wirtN3_1976]
| | Quote: ideally, each class is responsible for the maintenance of all information relating to a single concept. If so, a change in a concept effects one class only
| | Quote: Jackson sees a system as many individual programs, one for each relevant entity in the real world [»jackMA_1975]
| | Quote: a module can replace another if it implements the same abstraction; without changing other modules
|
Subtopic: type vs. module
| Quote: a type defines a set of values while a module groups related declarations; a module exists in exactly one instance [»batesR11_2004]
| | Quote: Java classes describe a type with its instance variables and a module with its class variables; confuses type with module
| | Quote: a class method is not a method at all; it is a function, without a receiver [»batesR11_2004]
|
Subtopic: modules as functions
| Quote: avoid unordered modules, each implementing a function; difficult to integrate with each other; quadratic growth in complexity [»dijkEW2_1971]
|
Subtopic: problems with encapsulation
| Quote: class inheritance doesn't preserve encapsulation because functions are scattered among classes with many interdependencies [»wyboN4_1990]
| | Quote: end-to-end argument--implement functions at the endpoints of a communication system; do not implement within the communication system unless needed for efficiency [»saltJH11_1984]
| | Quote: an interaction object, e.g., filling a form, is implemented by a single component; while a subject domain object clearly cuts across the system [»winoT7_1979]
| Quote: modularity decays; in 1989, the change history clearly separated two clusters of modules; by 1996, these clusters had broken down
[»eickSG1_2001]
|
Related Topics
Group: data type (34 topics, 730 quotes)
Group: program design (13 topics, 454 quotes)
Topic: abstract data type (64 items)
Topic: abstraction in programming (67 items)
Topic: aspect-oriented programming (2 items)
Topic: declaration scope (16 items)
Topic: decomposition of a system into levels (49 items)
Topic: design for change (76 items)
Topic: families of programs (11 items)
Topic: identifying program modules (26 items)
Topic: information hiding (50 items)
Topic: interface between program modules (55 items)
Topic: localized understanding (43 items)
Topic: object-oriented classes (67 items)
Topic: programming with a database of modules (94 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software components (11 items)
Topic: software tools (20 items)
Topic: system integration
(5 items)
|
