Map
Index
Random
Help
th

QuoteRef: jackMA_1975

topics > all references > ThesaHelp: references i-l



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

Reference

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

Quotations
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.