 |
Description  |
|
|
BACKGROUND OF THE INVENTION
This invention relates to methods and systems for computer programming, and
particularly, though not exclusively, to methods and systems for assisting
the programming of a processor which does not itself provide resources
that facilitate efficient programming.
For many years computer programming has generally involved writing
sequences of instructions specifying the operations to be performed by a
processor in order to accomplish a desired task. Such instructions are
expressed in the form of text using a very restricted vocabulary and
syntax specific to the programming language employed. This may be an
assembly language in which each instruction corresponds to one of the
repertoire of primitive operations that the processor can perform, or it
may be a `high-level` language in which each instruction represents a more
sophisticated operation itself corresponding to several tens or hundreds
of primitive operations. In either case the desired task must be analyzed
so that it may be defined in complete and unambiguous detail to an extent
dependent upon the level of the programming language to be used. The
result of this analysis then must be re-expressed in the form of an
exactly corresponding computer program.
Even though present high-level languages enable very complex operations to
be defined by each instruction, a typical computer program contains many
hundreds or thousands of instructions arranged in an intricate
inter-relationship. This provides copious possibilities for errors or
deficiencies in the programmed expression of the task to be performed,
resulting in failure or inappropriate operation of the computer when it
executes the program. The essentially textual format of typical
programming languages significantly exacerbates the problem of
assimilating and understanding the operation of a program so that it may
be compared with desired functions and corrected and extended as
necessary.
Various attempts have been made in recent years to alleviate different
apects of this problem. Thus a system called PegaSys provides a capability
to describe graphically the design of a separately written textual
program. This description provides a form of documentation of the program
and can also be verified by the system both for internal consistency and
for conformity with the textual version (IEEE Computer, Vol. 18, No. 8,
August 1985, pp. 72-85). Another system, developed at Brown University,
Rhode Island and known as Pecan, enables a program to be written in a
language such as Pascal with a text editor which uses information about
the allowable syntax of the language to assist the programmer in writing
the program (a syntax-directed editor). Representations of the program
using other display conventions are simultaneously maintained to provide
alternative views of the program and its structure (Sigplan Notices, Vol.
19, No. 5, May 1984, pp. 30-41).
Techniques have been developed for visual illustration of the execution of
a program by animation of a graphical depiction of the program structure.
In the Program Visualization project the user creates graphical pictures
and links them to program code and data; these graphical representations
or icons can be used during execution monitoring to illustrate progress
through the program (IEEE Computer, Vol. 18, No. 8, August 1985, p. 20). A
technique has been described for animating programs written in the
object-oriented programming language known as Smalltalk. Special
additional instructions are inserted at user-selected points in the
program to cause a corresponding change in a graphic display when the
section of the program containing such a special instruction is executed
(ibid., pp. 61-71). Another system developed at Brown University likewise
enables selected aspects of program execution to be illustrated
graphically (IEEE Software, Vol. 2, No. 1, Jan. 85, pp. 28-39). The Pecan
system noted above also provides the capability of executing the program
and highlighting each statement in the program as it is executed.
Graphical techniques have been devised for writing progams by manipulation
of graphical representations of program instructions. The Omega system
developed at Berkeley, California allows the programmer to construct
programs interactively by pointing to graphical structures on a display
screen and moving them around, but the structures only represent elements
of the program, the actual details of which have to be specified in a form
of text (IEEE Computer, Vol. 18, No. 8, August 1985, p. 20). Other systems
such as PiP (ibid., p. 23) and Think Pad (IEEE Software, Vol. 2, No. 2,
Mar. 85, pp. 73-79) enable programming to be performed by drawing and
modifying pictorial representations of data structures to be manipulated
by the program.
However, even these known techniques fail to provide an optimum programming
environment. Thus in many cases the programming still has to be performed
by writing instructions in textual format and is typically done on the
actual computer system which is intended to execute the finished program
when it is in use. Consequently the system may have very limited
facilities for program writing and debugging (a low-resolution display,
precluding the use of effective graphics, and a simple monitor utility),
or else the system may have such sophisticated and expensive facilities
that it is not suitable or cost effective for executing the program in its
intended operational environment. Furthermore existing systems for
providing an animated display of program execution generally cannot
illustrate multi-process programs, and/or cannot incorporate timing
constraints that are important in programming real-time processes for
controlling and/or responding to events occurring externally of the
processor.
SUMMARY OF THE INVENTION
It is an object of this invention to provide a system and method for
programming which provides an optimum programming environment for
developing and testing a program irrespective of the capabilities of the
processor (the `target` processor) intended to execute the program.
It is another object of this invention to provide a system and method for
programming which can be used to aid the preparation of multi-process
programs.
It is also an object of this invention to provide a system and method for
programming which can be used to aid the preparation of programs intended
to perform real-time tasks.
According to one aspect of this invention a system for machine-assisted
programming of a target processor which can execute a target programming
language, incorporates a processor which, typically, is different from the
target processor. The system is optimized for efficient programming and to
this end includes input means and graphical display means for displaying
graphical images in accordance with interactive input by an operator. Also
included are storage means for storing a representation of a program for
the target processor, this program representation being expressed in a
definition language which is executable (or translatable into a form that
is executable) on the system being used for the program development. Means
operatively coupled to the display means, the input means and the storage
means are provided to enable editing of the program representation by
interactive manipulation by an operator of the graphically displayed
graphical images. The program can then be tested with the aid of means for
providing a simulation of an external environment of the target processor,
and for simulating execution of the program by the target processor as if
the program were expressed in the target programming language. The
simulation includes simulation of interaction, in accordance with the
program, of the target processor with the simulation of its environment.
The execution characteristics of the program are made visible to the
operator by means operatively coupled to the display means, the storage
means and the simulation means for displaying the simulated execution of
the program. In one embodiment this is accomplished by animation of the
graphical images comprising the display of the program representation in
the definition language. When development of the program is complete,
translation means operatively coupled to the storage means is used for
translating the program representation in the definition language into a
corresponding representation in the target programming language.
Such a system provides several advantages. It allows the provisions of
facilities to optimize the programming environment for the operator which
are either impossible to provide with the target processor or can only be
provided with substantial effort and expense. Furthermore, these same
facilities are then available for programming other, different target
processors without the trouble of having to re-implement them in a
language executable by those processors.
It has been found that the system of this invention facilitates programming
by providing rapid feedback to the operator on the behavior of a program
under development, thereby enabling a significant reduction in the time
taken to develop a program compared to conventional programming on the
target processor itself.
Furthermore the simulation of the program execution in accordance with this
invention allows investigation of program behavior in circumstances which
occur only rarely and are difficult or impossible to test by practical
experiment.
BRIEF DESCRIPTION OF THE DRAWINGS
Additional objects and features of the invention will become more apparent
upon consideration of the following detailed description of the invention,
reference being had to the accompanying drawings in which:
FIG. 1 is a block schematic view of a system in accordance with the
invention;
FIG. 2 is a schematic diagram of a borehole logging operation using a data
processor, the programming of which can advantageously be accomplished
with the aid of the present invention;
FIG. 3 is a basic inheritance tree of objects included in an
object-oriented program used in one embodiment of the present invention;
FIG. 4 is an extended version of the inheritance tree of FIG. 3;
FIG. 5 is an example of a graphical display of a computer program prepared
with a system in accordance with this invention;
FIG. 6 is another inheritance tree of objects included in an
object-oriented program used in one embodiment of the present invention;
FIG. 7 is a generalization tree of objects included in an object-oriented
definition language used in one embodiment of the present invention;
FIGS. 8 and 10 are flow charts showing steps involved in simulation and
animation of a progam in one embodiment of the present invention; and
FIGS. 9a and 9b are inheritance trees of objects used in simulation of a
borehole environment in one embodiment of the present invention.
DETAILED DESCRIPTION
FIG. 1 shows in block schematic form the major components of a system for
use in programming a target processor in accordance with this invention.
Referring to FIG. 1, the system includes an input device 10 comprising a
keyboard 12 and a pointing and selection device 14 (commonly known as a
`mouse`), together with a high-resolution graphical display 16. The input
device 10 and the display 16 are arranged to interact in known manner with
a central processor 18 to enable an operator to manipulate graphical and
textual material shown on the display 16. In particular, the operator can
enter information via the keyboard 12, move the mouse 14 to control the
position of a corresponding cursor on the display 16 and press buttons 20
on the mouse 14 to select for manipulation items designated on the display
16 by the cursor. For convenience the processor 18 is represented in FIG.
1 in terms of the major functions which it performs. Thus the input device
10 and the display 16 interact with a graphical editor function 22 to
enable a computer program to be created and edited at least in part by
manipulation of graphical images. The program is stored in memory 24
associated with the processor 18, as indicated schematically at 26, and
can be read by a simulation function 28 of the processor 18. This function
28 simulates execution of the program 26 on another, different processor
(the target processor shown at 36) as if the program stored at 26 were
expressed in a language used by that processor. The simulation function
also simulates an environment external to the target processor 36 and in
which the program 26 is intended to operate, together with interaction of
the target processor 36 with the simulated environment under control of
the program 26. An animation function 30 interacts with the input device
10 and the display 16 to provide the operator with information about the
simulated execution of the program 26. In light of this information the
operator may review and alter the program 26 by means of the graphical
editor function 22, and then re-examine its simulated operation as
indicated by the simulation function 28 and the animation function 30.
When the operator is satisfied with the operation of the program 26 as
visualized in this way, the program stored at 26 is supplied to a
translation function 32. This reads the program 26 and generates an
equivalent version expressed in a language which can be executed by the
target processor 36. The equivalent version in this target language is
stored in the memory 24 as indicated schematically at 34, and can then be
transferred to the target processor 36 for final testing and use.
The arrangement shown in FIG. 1 allows the programming environment (the
input device 10, the display 16, the graphical editor function 22 and the
animation function 30) with which the operator interacts for the bulk of
the programming and testing process to be optimized for ease and
efficiency of use, irrespective of the hardware and software facilities
available on the target processor 36. For example, effective
implementation and use of the graphical editor function 22 is
significantly enhanced by the availability of the mouse 14 and the
high-resolution display 16. Likewise the graphical editor function 22 and
the animation function 30 are more readily implemented in certain
high-level languages than others. This hardware and software is often
relatively specialized and expensive, and may be either unnecessary or
unsuitable for the normal use of the target processor 36, or may not even
exist in a form which can be executed thereby. Typically this processor 36
may have only a keyboard, a low-resolution 24.times.80 character
non-graphical display, and able to execute programs in languages which are
widespread but not well-suited to graphical operations. Nonetheless, with
the system shown in FIG. 1 any such limitations in the capabilities of the
target processor 36 do not impose similar restrictions on the facilities
available to the operator; nor does the provision of desirable facilities
in the programming environment require the target processor 36 to be
equipped with hardware or software not required for its normal operation.
Another problem that could be encountered in attempting to use the target
processor 36 to develop and test a program is that such testing or
debugging freqently requires the addition of special extra instructions to
the program so that the processor 36 can both execute it and allow the
operator to monitor and interrupt execution. Such addition of instructions
results in the program under test being subtly but significantly different
from the program which will actually be executed in normal use. This can
result in unrepresentative behavior of the program during testing,
especially where correct timing of execution of the program instruction is
important. With the system of this invention any instructions required for
such testing are essentially part of the simulation function 28. No
special modification of the program 26 being developed is necessary for
the simulation stage, so the simulation of the program execution is more
closely representative of the execution of the program by the target
processor 36.
Those skilled in the art will recognize that the division of functions and
hardware adopted for the sake of clarity in FIG. 1 need not be reflected
in the actual implementation thereof. The graphical editor function 22,
the simulation function 28, the animation function 30 and the translation
function 32 can be combined in a variety of ways. Furthermore they would
likely interact with the memory 24 in various ways additional to the
reading and writing of the programs stored at 26 and 34, for example to
store and retrieve values temporarily required in the course of generating
displayed images. Similarly these functions would interact with (or
possibly incorporate) other functions for coordinating the overall
operation of the processor 18, the input device 10, the display 16, the
memory 24 and any other facilities provided by the system. The details of
such arrangements and the manner of their implementation are well known to
those skilled in the art. Accordingly such details need not be repeated in
the following description which will be limited to aspects of particular
significance to the present invention.
As noted above, the present invention permits a separation of the
programming environment from the program execution environment, and
exploits this separation so that each environment may be optimized for its
particular purpose without compromising desirable features of the other.
Thus the specific characteristics of the target processor 36 are not of
primary interest, except in so far as concerns the design of the
simulation function 28 to simulate those characteristics. By way of
illustrative example it will be assumed that the target processor is a
minicomputer (such as a `micro-Vax` manufactured and sold by the Digital
Equipment Corporation) equipped with conventional peripheral devices and
intended for real time acquisition of data from and control of a borehole
logging sonde, as is schematically illustrated in FIG. 2.
Referring to FIG. 2, an elongate logging tool or sonde 40 is suspended on
an armored communication cable 42 in a borehole 44 penetrating an earth
formation 46. The sonde 40 is moved in the borehole 44 by paying the cable
42 out and reeling it back in over a sheave wheel 48 and a depth gauge 50
by means of a winch forming part of a surface equipment 52. Usually the
logging measurements are actually made while the sonde 40 is being raised
back up the borehole 44, although in certain circumstances they may
additionally or alternatively be made on the way down. The depth gauge 50
measures displacement of the cable 42 over the sheave wheel 48 and thus
the depth of the tool 40 in the borehole 44.
The tool 40 includes one or more transducers for measuring parameters of
the formation 46, typically by means of electrical, acoustic or nuclear
techniques. The transducers generate signals related to the required
parameters and these signals are suitably conditioned by processing and
interface circuitry in the sonde 40 for transmission up the cable 42 to
the surface equipment 52. The equipment 52 includes the target processor
36 and typically receives, decodes, amplifies and records the signals on
chart and/or magnetic tape recorders as a function of the depth signals
generated by the depth gauge 50. In addition the equipment 52 may process
the data represented by these signals to yield indications of the required
formation parameters which are also recorded. Further processing of these
and other signals from the sonde 40 enables the surface equipment 52 to
monitor the operation of the sonde 40 and generate signals which are
transmitted down the cable 42 to control the sonde 40, for example to
synchronize the operation of its component circuits or modify circuit
parameters such as amplifier gain.
The precise details of the construction and operation of the sonde 40 and
the apparatus for communicating signals between the sonde 40 and the
surface equipment 52 are not part of the present invention, and, being
well known to those skilled in the art, need not be described here.
Likewise, specific techniques for processing the data received from the
sonde 40 to derive values for formation parameters and control signals to
be sent to the sonde 40 are not part of this invention and will not be
described.
The surface equipment 52 is required to be mobile and rugged, so there are
severe constraints on the configuration of the target processor 36. In
particular for reasons of efficient and economic use of space and other
resources, it is only practicable to include hardware and software
optimized in function and cost for the control of the sonde 40 and the
acquisition and processing of its measurements. Typically this requires a
relatively simple low or medium resolution display and the capability to
execute programs for performing control, measurement and arithmetic
processing. Such programs are normally written in a high-level language
such as C, Pascal or Fortran.
In contrast, an optimized programming environment typically includes
sophisticated high-resolution graphics display capabilities providing the
option of presenting information in several adjacent or overlapping
display areas (or `windows`) simultaneously, support for symbolic data
processing with appropriate data structures, and an appropriate suite of
programming tools and utilities. The kind of processor typically used in
the surface equipment 52 generally does not have the hardware and software
capabilities to provide such features. Thus neither the system as used at
the well-site nor any practical factory equivalent using essentially
similar equipment is a suitable basis for efficient development and
testing of programs.
Machines which are suitable for this purpose include the 1100 Series
Scientific Information Processor manufactured and sold by the Xerox
Corporation and capable of executing programs written in such languages as
KEE (available from IntelliCorp, Menlo Park, Calif.), Lisp or Smalltalk.
The present invention permits such a machine to be used for developing and
testing programs for the target processor 36 even though it is
significantly different from the target processor 36, and enables its
advantages to be exploited for programming purposes without incurring the
cost of providing its facilities directly on the processor 36 and without
adversely affecting the performance of the processor 36 in its normal
operational environment.
Programming languages such as KEE, Smalltalk, Loops or Objective-C are
known examples of the `object-oriented` type of language which is
especially preferred for implementing the graphical editor function 22. An
object-oriented language is so named because its basic programming entity
is called an `object`, which has the capability to store information and
to carry out predetermined operations (or methods) on that information in
response to messages sent to it, and to return the result of execution of
such a method to the sender of the message. An object is created as an
example or instance of a class of objects having certain predefined
attributes or instance variables in common. When an object is created, it
automatically acquires the set of instance variables and their values and
the set of methods for its class. In addition the instance variables may
themselves have secondary values or annotations. The initial values for
the instance variables and annotations of a class may be defined
explicitly or by inheritance from another class in a hierarchy of classes.
Programming with an object-oriented language primarily involves choosing
and defining classes of objects to be used in the program, defining the
hierarchy of such classes, defining the instance variables and annotations
for each class of objects, and defining the methods which each class of
objects can perform and the messages to be sent to it to invoke those
operations. The hierarchy of classes may be conveniently represented as a
succession of columns, each column containing names of objects at a
similar level in the hierarchy. Inheritance links are indicated by lines
joining the names of the objects linked in the hierarchy, with the more
senior member of the link being to the left of the junior member.
In the case of the graphical editor function 22, various basic types of
graphical images to be depicted on the display 16 are defined in terms of
corresponding objects having a hierarchy as shown in FIG. 3. Referring to
FIG. 3, the basic class is called PropertyDisplay, and has seven dependent
classes called Brush, Expression, Raster, TextString, Vector, Composite
and Interface. The Vector class is further divided into Closed and Open
objects, which comprise respectively: Ellipse, Circle, ClosedCurve,
Diamond, Box and Grid objects; and Line, Curve, Elbows, RightAngles and
Angles objects. The division of objects shown in FIG. 3 is chosen to
reflect the various different methods required to display each type of
object. However, those skilled in the art will appreciate that other
divisions and object names could be adopted.
Each object shown in FIG. 3 has instance variables which contain the data
and functions needed for graphical operations involving the image defined
by that object, such as displaying the image, selecting it with the mouse
14, reshaping it or moving it. Thus, for example, the Box object in FIG. 3
has an attribute known in this art as a slot (called for example
DisplayFn) which contains the method for drawing a box on the display 16.
Other slots for this object take the form of instance variables containing
data describing the box, such as the display `window` in which it should
appear, the region of that window it should occupy and its line width.
These instance variables are used by the method DisplayFn for control of
basic graphics functions of the display 16 to draw the box. In like manner
the Raster object would use its respective method, as identified in its
DisplayFn slot, to control the drawing of an image in accordance with
instance variables containing data defining the display window, the
position of the image in the window and a `bitmap` or collection of
numbers which when supplied to the display 16 cause it to show the desired
image. The basic graphics functions used by the methods to produce the
required image on the display 16 are usually incorporated by the
manufacturer as an integral part of the facilities of a processor/display
system. It will be evident to one skilled in the art how such functions
may be used to produce images of the basic graphical items specified in
FIG. 3.
Instance variables and other slots such as the ones containing the required
window and the display method are used by most or all of the objects shown
in FIG. 3. Accordingly these slots are conveniently included in the basic
PropertyDisplay object so that they may be inherited by all other objects
shown. However, instance variables which are more specific to particular
objects are included only in relation to those objects. Thus the bitmap
instance variable is provided only for objects in the Raster class.
For a particular programming task, the basic graphical items indicated in
FIG. 3 are used to create versions (known as `specializations`) suited to
the task. Thus the extended hierarchy shown in FIG. 4, in which
specializations introduced therein have their names indicated in upper
case letters, may be used to produce the display depicted in FIG. 5. This
represents a simple program for a target processor 36 operating in the
manner described in co-pending U.S. patent application Ser. No. 767,409 in
the name of Guthery, Barth and Barstow, filed Aug. 20, 1985 and assigned
to the assignee hereof. In such a processor, data is manipulated by
processes represented in FIG. 5 by boxes (or modules) such as 60 and is
transferred between processes via streams of data items represented in
FIG. 5 by grids such as 62. The processes may each be executed by
respective dedicated central processing units, or they may be executed in
a time-shared manner, for example by a single central processing unit.
Referring to FIGS. 4 and 5, the boxes such as 60 are examples of the
display produced by the object MODULEBOX in FIG. 4, a specialization of
the Box object. The groups of smaller boxes such as 62 are produced by the
object STREAMGRID, a specialization of the Grid object. The U-shapes such
as 64 below each group of boxes are produced by the object PIERVIEW which
is a specialization of the RightAngles object, and the black dots within
these U-shapes, as at 66, are produced by the object PIERLOCATION, a
specialization of the object Raster with a bitmap value chosen to produce
a solid dot on the display 16. The curved arrows such as 68 joining these
boxes are examples of the PIERBODY specialization derived from the Elbows
object. The text within the various boxes in FIG. 5 is produced by the
objects STREAMNAME and MODULENAME, which are specializations of another
special object SMNAME, itself a specialization of the object TextString.
These specializations may differ from the general objects from which they
are derived in several ways. Thus, default instance variable values
inherited from the general objects may be replaced by specific values, and
additional instance variables and/or annotations may be included. In
particular, data may be added specifying the graphical dependencies
between images corresponding to objects and their relative positions,
together with methods using this information to maintain linked images in
the correct visual relationship.
Thus an instance variable defining the position of the end of a Line object
may have an annotation making it dependent on the instance variable
defining the position of a Raster object in a window. When the position of
an object is altered, all other objects are checked for instance variables
with annotations indicating a dependency on the moved object. Any
dependency found causes the position of the dependent object to be updated
accordingly, the necessary data for the updating being obtained by
reference to the relevant instance variables of the object identified in
the dependency annotation. This feature may be used, for example, to
ensure that a line ending at a box remains connected to the box even if
the box is moved or reshaped.
Another example of addition of instance variables in specific objects is
the inclusion of an instance variable in the MODULENAME and MODULEBOX
objects, referring to the MODULE object (a specialization of the Composite
object) as being the whole object of which they are a part. Likewise, the
MODULE object includes two instance variables identifying the MODULENAME
and MODULEBOX objects as being its components. When a MODULE object is
actually created to be added to the display, these two instance variables
are used to create the necessary component MODULENAME and MODULEBOX
objects automatically. Thereafter, the instance variables in these objects
identifying the composite MODULE object provide dependency information as
described above. Thus, the instance variable defining the position of the
MODULENAME object is made dependent upon the instance variable defining
the display region of the associated MODULEBOX object, so that the name of
the module is automatically positioned within and moves with the module
box.
Graphical images defined by the objects shown in FIGS. 3 and 4 are created
and modified by sending messages to these objects, in a manner well known
to those skilled in this art. Typically the graphical editor function 22
provides a list or menu of possible operations and associated objects on
the display 16. The operator creates a module, for example, by moving the
mouse 14 to position the display cursor over a `Module` legend in a
`Create` menu on the display, and then pressing one of the buttons 20. The
graphical editor function 22 is arranged to respond to this action by
sending a `create` (also known as `instantiate`) message to the MODULE
object of FIG. 4. This causes the relevant methods defined within that
object to be executed to generate a new (module) object as a replica of
the MODULE object, prompting the operator for a name for the module, where
it is to be positioned and its size (these latter being conveniently
entered by further manipulation of the mouse 14). The necessary storage
space in memory 24 is assigned to the new object, any necessary
dependencies are set up, data needed for display is computed (by means of
such dependencies for example), and then a message is sent to the
DisplayFn slot of the new object to cause the method identified thereby to
be executed to display the module.
Images can be modified in similar manner, by selecting them with the mouse
14 and then selecting appropriate options from an appropriate menu on the
display 16. The graphical editor function 22 responds to such a selection
by identifying the object corresponding to the selected image and sending
it the appropriate message. The corresponding method in that object
carries out the required function, thereby updating any other affected
images indicated by dependencies as explained above. The method may, for
example, use three items of data: the object to be modified, the instance
variable(s) thereof to modify and the new value(s). All affected images as
indicated by dependencies are erased from the display 16, the value(s) of
the specified instance variable(s) are changed and the changes propagated
to the other affected objects via the dependencies, and the related images
are redisplayed in accordance with the new value(s). The instance variable
modified need not be directly associated with the object in question.
Thus, modifying a module image may involve altering the instance variable
defining the display region of its component MODULEBOX object. The
MODULENAME object does not need to be explicitly referred to in invoking
the method, since the dependency of the MODULENAME object on the MODULEBOX
object automatically causes its position to be changed as necessary.
Operation of the input device 10, the display 16 and the processor 18 to
facilitate the above-described operations, for example to coordinate
movement of the display cursor with operator movement of the mouse 14 and
to alter the display (such as by interchanging black and white) to
indicate a selected display image, is well known in the art, and generally
uses functions built-in to the system. Accordingly details of such
operation need not be given here.
Since any change in the appearance of a display image can be effected by
sending the appropriate message to the object corresponding to that image,
the animation function 30 can be readily implemented in this case by
arranging, as described below, for operation of the simulation function 28
to send such messages to each object upon simulated execution of the
program element depicted by the image corresponding to that object. Such
animation is a form of graphical editing coordinated by the simulation
function 28 rather than by the operator.
The set of objects shown in FIG. 4 is concerned solely with the graphical
depiction of components of the program 26 being prepared by the operator.
Details of these components relating to the content of the program 26
itself are stored by means of a second set of objects forming the
hierarchy shown in FIG. 6. Each possible component in the overall
structure of the program 26 has a corresponding object class, which has
instance variables for information about that type of object. For example,
the STREAM object in FIG. 6 includes instance variables for defining the
type of data items to be stored in the stream, the identity of the module
writing data items to it and the identity of any module that reads data
items from it. Likewise, the MODULE object includes instance variables for
defining the identity of the stream(s) it reads from and writes to, and
for identifying a block of program text defining the details of the
process represented by that module. The PRO | | |
