QuoteRef: jackMA_1975

topics > all references > ThesaHelp: references i-l

references i-l
handling complexity
structured programming
no need for efficiency
data-driven design
decomposition of a system into levels
structured flow diagram
generalized repetition
repetitive control
reusable programming
stepwise refinement
localized understanding
top-down vs. bottom-up design
execution tracing
spatial vs. temporal representation
separate a module's interface specification from its implementation
the 'uses' hierarchy for organizing systems
processing a sequence
defensive programming
incremental testing
programming with data
temporary data objects
sensitivity of software to change
Thesa programming system
database as a model of reality
recursive data structures
loosely structured data
data structures
uniform data model
program module as encapsulation
task scheduling
database implementation
programming without errors


Jackson, M.A., Principles of Program Design, London, Academic Press, 1975. Google

v ;;Quote: programs should always be simple even if their tasks are complex
vi ;;Quote: Jackson's design method dissects the problem into parts and structures those parts into a solution
vi+;;Quote: Jackson's method gives a procedure for designing programs which is simple and self-evidently correct
vii ;;Quote: if you must optimize, do it after writing a perfectly clear and unoptimized solution
vii ;;Quote: optimization makes a system less reliable, harder to maintain, more expensive to build, and harder to optimize
11 ;;Quote: both accessing and modifying a data structure can be associated with its components
16 ;;Quote: hierarchy allows large and complex programs out of simple components; complexity only through number of components and levels
19 ;;Quote: Jackson's diagrams show the components of an entity; not a flowchart
21 ;;Quote: Jackson's diagrams indicate repetition, sequence, and selection by boxes
23 ;;Quote: should only have one form of iteration; reduces design complexity
23 ;;Quote: repeat..until is harder to use correctly since first iteration does not test the conditional; loop body has two distinct contexts
32 ;;Quote: need to dissect the structure of problem data down to elementary data types, and the structure of the program down to primitive operations
33 ;;Quote: a primitive operation should be used in many places in many different programs
33 ;;Quote: limit span of attention through top-down design; only one use of each program component
34 ;;Quote: if programs are structured as trees then always know the origin of any component
34 ;;Quote: if a program reuses components then the context of a statement depends on the prior execution history; requires a trace to debug
36 ;;Quote: generalized components are only created by bottom-up design
36 ;;Quote: a generalized component should be seen as an operation of an abstract machine; internals are inaccessible
36 ;;Quote: the top-down designer creates tree structures; at a level with no shared components
49 ;;Quote: many programs read and process serial input
63 ;;Quote: many programs become an iteration over data records; this is wrong
64 ;;Quote: an iteration of data records prevents the expression of important relationships between records
64 ;;Quote: a data structure should contain all relationships relevant to the program
101 ;;Quote: a data structure reflects the problem; this includes error handling
101 ;;Quote: should design data structures so that erroneous data does not interfere with processing of good data
106 ;;Quote: components must rely on the correctness of any module it gets data from
123 ;;Quote: to backtrack in a Jackson program/data structure tree use 'posit..admit..'; creates a restartable block
151 ;;Quote: structure and operations of a program must correspond with structure and components of the data it processes
151 ;;Quote: structure clashes--when data structures do not correspond 1-1
166 ;;Quote: synchronization--current place in the program text must correspond with current place in data structure
166 ;;Quote: JacksonDesignMethod uses unstructured temporary files to avoid structure clashes
237 ;;Quote: Jackson bases program structure on the data structures of serial files
237 ;;Quote: program inversion turns a program to process a complete file, into one processing one record at a time
251 ;;Quote: only an unoptimized design can have a clearly understood and simple structure
251+;;Quote: to prevent logical errors during optimization, one must understand the program fully
251 ;;Quote: apparently innocuous changes to a program can have surprising and disastrous effects
259 ;;Quote: reducing the size of a program is usually more important than increasing speed of execution
268 ;;Quote: common subroutines from bottom-up design are reused; those from top-down design are for optimization
279 ;;Quote: data structures model the problem environment; good foundation from program structures
279 ;;Quote: Jackson avoids recursive data structures because they occur rarely in data processing
280 ;;Quote: the most important limitation on data structures is that they are hierarchical but must be explored sequentially
280+;;Quote: the serial file is the fundamental data structure; explored sequentially
280 ;;Quote: many files are serial because they are chronologically ordered
280 ;;Quote: Jackson sees a system as many individual programs, one for each relevant entity in the real world
280 ;;Quote: in design, each individual program should have one input and one output file for transactions on an entity such as employees or suppliers
280 ;;Quote: need an overall control program to direct individual transactions and to transfer program output to other programs or to system output
280 ;;Quote: create a master file by inverting the programs for entities of a class; e.g., class of employees
283 ;;Quote: can not find logic errors by testing because they depend on combinations of circumstances; should make testing unnecessary

Related Topics up

ThesaHelp: references i-l (342 items)
Topic: handling complexity (59 items)
Topic: structured programming (27 items)
Topic: no need for efficiency (28 items)
Topic: data-driven design (41 items)
Topic: decomposition of a system into levels (49 items)
Topic: structured flow diagram (36 items)
Topic: generalized repetition (16 items)
Group: repetitive control   (7 topics, 117 quotes)
Topic: reusable programming (77 items)
Topic: stepwise refinement (25 items)
Topic: localized understanding (43 items)
Topic: top-down vs. bottom-up design (30 items)
Topic: execution tracing (39 items)
Topic: spatial vs. temporal representation (21 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: the 'uses' hierarchy for organizing systems (18 items)
Topic: processing a sequence (17 items)
Topic: defensive programming (22 items)
Topic: incremental testing (25 items)
Topic: backtracking (30 items)
Topic: programming with data (16 items)
Topic: temporary data objects (6 items)
Topic: file (22 items)
Topic: co-routines (13 items)
Topic: sensitivity of software to change (44 items)
Topic: efficiency (96 items)
Group: Thesa programming system   (11 topics, 561 quotes)
Topic: database as a model of reality (25 items)
Topic: recursive data structures (18 items)
Topic: loosely structured data (20 items)
Group: data structures   (12 topics, 275 quotes)
Topic: uniform data model (19 items)
Topic: program module as encapsulation (28 items)
Topic: task scheduling (49 items)
Topic: database implementation (18 items)
Topic: programming without errors (28 items)

Collected barberCB 1980
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.