Group:
program module
Topic:
abstraction
Topic:
abstraction in programming
Topic:
access by current position
Topic:
aspect-oriented programming
Topic:
context
Topic:
decision table
Topic:
decomposition of a system into levels
Topic:
disorientation in a user interface
Topic:
ease of use
Topic:
program module as encapsulation
Topic:
fisheye views in the user interface
Topic:
handling complexity
Topic:
hypertext subsets, webs, and contexts
Topic:
identifying program modules
Topic:
information hiding
Topic:
literate programming
Topic:
local declaration of data
Topic:
local vs. global
Topic:
multiple views for a user interface
Topic:
names defined by context
Topic:
opaque and partially-opaque data types
Topic:
separate a module's interface specification from its implementation
Topic:
stepwise refinement
Topic:
the effect of scale
Topic:
the 'uses' hierarchy for organizing systems
Topic:
understanding systems
Topic:
uniform language systems
| |
Summary
Any problem can be understood if it is small enough. Large problems can be broken up, making explicit the problem's structure. Locally most details can be ignored because they are constant. Top/down design and information handling create systems which are locally understandable. This is destroyed if understanding requires implicit information from other modules. Note that local understanding can only work with systems. Real objects loose their integrity when split into pieces and must be understood in relationship to their environment. (cbb 5/80)
Subtopic: understanding within a context 
| Quote: to tell if a speaker mis-spoke, need to infer some of the speaker's meaning prior to the utterance; implies, decoding theories are incomplete [»blaiDC6_1992]
| | Quote: Subtext labels depend on the human ability to disambiguate labels by their context; labels are not unique [»edwaJ10_2005]
|
Subtopic: localized processing
| Quote: in an open system, control must be distributed so that local decisions are made where needed; uses local information [»hewiC7_1986]
| | Quote: process paradigm best for very large systems since users never need to see, and can not see, the system as a whole [»stroR10_1986]
| | Quote: object-oriented emphasizes global structure while process paradigm insists that all data is local [»stroR10_1986]
| | Quote: usually design data structures for localized processing, e.g., with an implicit cursor position [»hallJC5_1974]
| | Quote: design of Euclid ensured that only local information was needed for verification [»veneT3_1978]
|
Subtopic: economics
| Quote: numeric values required for solving the economic problem of resource and demand [»hayeFA9_1945]
| | Quote: instead of globally consistent economic information, have dispersed bits of incomplete, frequently contradictory information [»hayeFA9_1945]
| | Quote: prices coordinate the separate actions of different people; knowledge is dispersed [»hayeFA9_1945]
|
Subtopic: concise
| Quote: always remember you are on the wrong track when you need more than five lines [»dijkEW_1979]
| | Quote: with user-defined data types, programs are shorter; easier to write, understand, prove correct, modify [»parnDL3_1976]
| | Quote: a cohesive routine does one thing and does it well; described by a short title; helps reuse and avoids side effects [»peteS1_1997]
| | Quote: by not using concise, formal notation, many authors exceed the five-line limit and introduce too much complexity
| | Quote: it is better to split up functions into smaller pieces which may be useful for other purposes; abstraction [»wileDS11_1973, OK]
| | Quote: complicated systems look simple when split up; life is the opposite of this [»cbb_1973, OK]
|
Subtopic: concreteness
| Quote: Self promulgated the principles of concreteness, uniformity, flexibility, and immediacy
|
Subtopic: localized view
| Quote: for effective view navigation: views must be small, navigation should not require too many steps, and the path to a target must be discoverable [»furnGW3_1997]
| | Quote: a table improves view traversability because the neighborhoods are constant size and the diameter of the graph is the square root of its total size [»furnGW3_1997]
| | QuoteRef: morrJH1_1973 ;;16 Local objects allow local understanding of the object
| | QuoteRef: cbb_1973 ;;5/9/75 We see things in terms of a window. Local understanding
| | QuoteRef: cbb_1973 ;;8/8/75 Locally the amount of information is finite
| | QuoteRef: cbb_1973 ;;12/12/76 Localized viewpoint-- what is constant need not be indicated
| | QuoteRef: cbb_1973 ;;2/23/74 a.b.c\c is changing the reference point of a map i.e., letting the map cover a large area but remain local
| | QuoteRef: cbb_1973 ;;2/28/74 Now any space can locally be described as a map (i.e., == any space is locally a vector space)
|
Subtopic: module
| Quote: locality of information (modules): a programming system should keep related pieces of behavior and data together [»taivA4_1993]
| | Quote: the goal is to implement and reason about each module separately [»liskB_1996]
| | Quote: each module's structure should be simple enough to be understood fully [»parnDL3_1985]
|
Subtopic: expression
| Quote: understand X+Y by recursively understanding each part independently; manifest structure, clear meaning and purpose
| | Quote: the interface between the parts of X+Y is a single number
|
Subtopic: data type
| Quote: variables, arrays, files splits a machine into disjoint areas; updating one does not effect the others [»hoarCA_1974]
|
Subtopic: declaration scope
| Quote: block structure limits the scope of a variable; accessible from elsewhere only as a parameter [»hoarCA_1974]
|
Subtopic: information hiding
| Quote: information hiding necessary if designers wish to maintain control over a program's structure [»parnDL8_1971]
| | Quote: try to avoid functions that modify call-by-reference arguments. They make a program harder to read [»stroB_1991]
| | Quote: reference arguments should use 'const' if the argument is not modified; allows literal and expression arguments; improves readability
|
Subtopic: structured analysis
| Quote: structured analysis (SA) for communicating ideas; handle complexity by easy-to-grasp chunks [»rossDT1_1977]
| | Quote: structured analysis produces a hierarchy of diagrams, each describing a limited area; even complex subjects may be understood [»rossDT1_1977]
| | Quote: limit span of attention through top-down design; only one use of each program component [»jackMA_1975]
|
Subtopic: dialogue windows
| QuoteRef: goldA3_1976 ;;5 All communication through dialogue windows and a mouse. Only current window can listen
|
Subtopic: problems with non-local view
| Quote: C++ bugs took twice as long to correct as C bugs; C++ failure may be a long way away from the error [»hattL5_1998]
| | Quote: components involved in inheritance had six times more defects than those without [»hattL5_1998]
| | Quote: the interface between two machine code instructions is the entire machine [»hoarCA_1974]
|
Subtopic: problems with local view
Quote: can not subdivide universe of problems into fixed areas, each with its own special notation
[»holtAW5_1958]
|
Related Topics
Group: program module (10 topics, 336 quotes)
Topic: abstraction (62 items)
Topic: abstraction in programming (67 items)
Topic: access by current position (7 items)
Topic: aspect-oriented programming (2 items)
Topic: context (8 items)
Topic: decision table (29 items)
Topic: decomposition of a system into levels (49 items)
Topic: disorientation in a user interface (13 items)
Topic: ease of use (47 items)
Topic: program module as encapsulation (28 items)
Topic: fisheye views in the user interface (16 items)
Topic: handling complexity (60 items)
Topic: hypertext subsets, webs, and contexts (12 items)
Topic: identifying program modules (26 items)
Topic: information hiding (50 items)
Topic: literate programming (16 items)
Topic: local declaration of data (11 items)
Topic: local vs. global (29 items)
Topic: multiple views for a user interface (26 items)
Topic: names defined by context (36 items)
Topic: opaque and partially-opaque data types (14 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: stepwise refinement (25 items)
Topic: the effect of scale (17 items)
Topic: the 'uses' hierarchy for organizing systems (18 items)
Topic: understanding systems (48 items)
Topic: uniform language systems
(25 items)
|
