QuoteRef: hendP9_1975

topics > all references > ThesaHelp: references g-h

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


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

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.