Map
Index
Random
Help
th

QuoteRef: hendP9_1975

topics > all references > ThesaHelp: references g-h



ThesaHelp:
references g-h
Topic:
programming environment
Topic:
programming with a database of modules
Topic:
software components
Topic:
descriptive languages
Topic:
incremental development
Topic:
execution with program stubs
Topic:
non-constraining system
Topic:
text editing
Topic:
function call
Topic:
object-oriented procedures
Topic:
notation for declarations
Topic:
syntax analysis
Topic:
structured editors
Topic:
state
Topic:
data type as constructors, selectors, and predicates
Topic:
user-defined data type
Topic:
symbolic execution
Topic:
consistency testing
Topic:
model checker
Topic:
no need for replacement
Topic:
incremental testing
Topic:
state machine
Topic:
Thesa data structures
Topic:
representation data type
Topic:
function definition
Topic:
data type as a set of values
Topic:
test data selection
Topic:
automated testing
Topic:
linearization of hypertext
Topic:
primitive functions
Topic:
executable code from specifications and designs
Topic:
object serialization
Topic:
literate programming
Topic:
object-oriented fields
Topic:
type inheritance as reuse

Reference

Henderson, P., Snowdon, R.A., Gorrie, J.D., King, I.I., "The TOPD system", 77, Computing Laboratory, University of Newcastle upon Tyne, England, September 1975. Google

Other Reference

Stanford Computer Library #7888

Quotations
6 ;;Quote: with structured programming, a conventional interactive programming environment is used only in the last part of the process
6 ;;Quote: a partially completed program consists of many, interrelated, small components; need to keep track of them
6+;;Quote: can not encode abstractions directly into conventional programming systems
6+;;Quote: can not test a partially completed program until all parts are implemented or simulated
7 ;;Quote: TOPD stores fragments of design notations and their interrelationships in a database; can represent any stage of development
7 ;;Quote: with TOPD's design notation can specify a model for unimplemented parts; execution checks for consistency
7 ;;Quote: TOPD was like PEARL except that it did not constrain the order of program development
10 ;;Quote: TOPD operations work on the data-base that represents the developing program
10+;;Quote: editing in TOPD occurs on a text file called the scratchpad
14 ;;Quote: the basic TOPD statement is a procedure call v.p (v1,...,vn); v is both the first argument and indicates the class by its type
15 ;;Quote: declare a variable by its name and class identifier
15 ;;Quote: TOPD deduces classes and procedures by statements of the appropriate form; e.g., CHR.TEST in class CHAREADER
16 ;;Quote: a logical expression in TOPD compares a variable (e.g., CH) with a state identifier (e.g., BLANK)
16 ;;Quote: with type, declare predicates for testing type states, e.g., c = UPPERCASE
20 ;;Quote: TOPD's checkout feature 'symbolically' executes a procedure by using mutually exclusive test states
64 ;;Quote: the TOPD tester/checker stops on a missing item; could report everything missing
64 ;;Quote: TOPD's tester/checker could report which program states matched the predicted ones
66 ;;Quote: TOPD does not have an assignment statement because the semantics are complicated
67 ;;Quote: everyone liked TOPD's database; allowed retrieval of logical program structure using a logical index
67 ;;Quote: TOPD could check code fragments for syntactic correctness; quite useful
67 ;;Quote: modeling with a finite state machine is as difficult as programming; will report inconsistencies between model and implementation
68 ;;Quote: modeling with finite state machines is practical; TOPD discourages elaborate models by full expression of state transitions
72 ;;Quote: TOPD models a program by a set of abstract values for objects (i.e., states) and the effects of operations (i.e., transitions); used by tester/checker
73 ;;Quote: the left side of a procedure's transition defines the object states necessary for execution; the right side gives the resulting states
73 ;;Quote: the memory of a class is an elaboration in terms of more primitive objects
73 ;;Quote: the procedure body uses operations defined for parameters and class objects
73 ;;Quote: a set of state equivalences defines the abstract values of an object in a class in terms of values of the component objects
116 ;;Quote: the TOPD tester exhaustively executes the model of a procedure; result is state vectors for each valid execution path
117 ;;Quote: the TOPD tester annotates the procedure with its state vectors and reports on potential programming errors
117 ;;Quote: in a TOPD model, an operation's transitions should be defined for every state vector generated by TOPD
118 ;;Quote: TOPD's checker generates test cases from the model and determines if the procedure's result matches the model's result
139 ;;Quote: the TOPD flattener removes all hierarchical structure; then it's translated into equivalent COBOL statements
141 ;;Quote: a declared instance of a class is expanded into the variables recursively specified by the class's memory


Related Topics up

ThesaHelp: references g-h (299 items)
Topic: programming environment (46 items)
Topic: programming with a database of modules (94 items)
Topic: software components (11 items)
Topic: descriptive languages (22 items)
Topic: incremental development (74 items)
Topic: execution with program stubs (5 items)
Topic: non-constraining system (24 items)
Topic: text editing (34 items)
Topic: function call (28 items)
Topic: object-oriented procedures (41 items)
Topic: notation for declarations (20 items)
Topic: syntax analysis (29 items)
Topic: structured editors (35 items)
Topic: state (35 items)
Topic: data type as constructors, selectors, and predicates (20 items)
Topic: user-defined data type (13 items)
Topic: symbolic execution (8 items)
Topic: consistency testing (60 items)
Topic: model checker (49 items)
Topic: no need for replacement (4 items)
Topic: incremental testing (25 items)
Topic: state machine (67 items)
Topic: Thesa data structures (59 items)
Topic: representation data type (21 items)
Topic: function definition (25 items)
Topic: data type as a set of values (20 items)
Topic: test data selection (39 items)
Topic: automated testing (24 items)
Topic: linearization of hypertext (23 items)
Topic: primitive functions (34 items)
Topic: executable code from specifications and designs (18 items)
Topic: object serialization (13 items)
Topic: literate programming (16 items)
Topic: object-oriented fields (28 items)
Topic: type inheritance as reuse (27 items)

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