System for graphically representing operation of object-oriented programs

What is claimed:

1. An object oriented program employing

a plurality of transmitting objects,

a plurality of receiving objects,

a plurality of messages, wherein said plurality of messages are transmitted to said plurality of receiving objects by said transmitting objects, and

an existing debugger routine, wherein said existing debugger routine can suspend operation of said program;

a diagramming debugger process comprising the steps of:

recording transmission of said plurality of messages from said plurality of transmitting objects as the program is running wherein said recording includes examining a next program instruction, recording names of transmitting objects, recording messages sent, recording names of receiving objects, and allowing the existing debugger operation to take place;

graphically representing the recorded transmission,

wherein said graphic representation includes:

a first plurality of area-limited representations of said transmitting objects;

a second plurality of area-limited representations of receiving objects; and

a third plurality of area-limited representations of said messages.

2. The diagramming debugger process according to claim 1 wherein:

said first plurality of area-limited representations of said transmitting objects comprise rectangular boxes, and wherein the names of said transmitting objects are in juxtaposition with said boxes.

3. The diagramming debugger process according to claim 1 wherein:

said second plurality of area-limited representations of said receiving objects comprise rectangular boxes, and wherein the names of said receiving objects are in juxtaposition with said boxes.

4. The diagramming debugger process according to claim 3 wherein:

said third plurality of area-limited representations of said messages comprise arrows and text, said arrows extending from said first area-limited representations to said second area-limited representations, and said text being placed in said rectangular boxes of said second plurality of area-limited representations.

5. A method for monitoring the operation of an object oriented program while operating a debugger routine in an object oriented programming system, including graphically representing the operation of said program while said program is running, wherein the method is executed by a computer, the method comprising the steps of:

halting the debugger;

duplicating a current context of said debugger;

examining the duplicate context;

recording transmitting objects, messages transmitted by said transmitting objects, and objects which receive said messages during examination of the duplicate context;

generating graphic representations of said recording, said representations comprising first area-limited representations of said transmitting objects, second area-limited representations of said receiving objects, and third area-limited representations of said messages; and

displaying said graphic representations as visible output.

6. The method according to claim 5 wherein:

said first area-limited representations comprise first rectangles with the transmitting objects' names adjacent said first rectangles;

said second area-limited representations comprise second rectangles with the receiving objects' names adjacent said second rectangles; and

said third area-limited representations comprise arrows originating in said first rectangles and terminating in said second rectangles, with the text of said messages placed within the perimeter of said second rectangles.

7. The method according to claim 6 wherein

the step of generating said second representations further comprises modifying said first representations if the receiving objects are within the same class as the transmitting objects, said modifying comprising the steps of:

extending the rectangle of said first graphic representations;

adding the name of the receiving objects below the name of the transmitting objects; and

adding the name of the transmitted messages within the perimeter of the rectangles and adjacent to the receiving objects' names.

8. The method according to claim 5 wherein:

the step of displaying a visible output of said graphic representations comprises displaying an image on a computer terminal.

9. The method according to claim 5 wherein:

the step of displaying a visible output of said graphic representations comprises displaying an image on a computer printer.

10. The method according to claim 5 wherein said first area-limited representations of said transmitting objects are displayed in the temporal order in which the objects, which said representations represent, transmit messages.

11. The method according to claim 5 wherein said second area-limited representations of said receiving objects are displayed in the temporal order in which the objects, which said representations represent, receive messages.

12. The method according to claim 5 wherein said third area-limited representations of said messages are displayed in the temporal order in which messages, which said representations represent, are transmitted.

13. The method for monitoring the operation of an object oriented program while operating a debugger routine in an object oriented programming system, including graphically representing the operation of said program while said program is running, wherein the method is executed by a computer, the method comprising the steps of:

halting the debugger;

duplicating a current context of said debugger;

examining the duplicate context;

recording transmitting objects, messages transmitted by said transmitting objects, and objects which receive said messages during said examining of the duplicate context;

generating a plurality of area-limited graphic representations of said transmitting objects, of said receiving objects and, said messages; and

displaying said graphic representations as visible output.

14. The method according to claim 13 including selectively skipping one or more steps of displaying graphic representations of individual transmitting objects, graphic representations of messages, receiving objects.

15. A graphic debugger process used within an object oriented computer system while running an object oriented program, the process comprising:

acquiring transmitting-object information, receiving-object information and transmitted-message information;

generating area-limited graphic representations of said information; and

displaying said graphic representation.

16. A graphic debugger process as set forth in claim 15 wherein

the step of acquiring said transmitting object information, said receiving object information, and said transmitted message information comprises:

halting operation of an existing debugger routine;

duplicating the context of the existing debugger routine;

examining the operation of the existing debugger routine;

storing the transmitting-object information in memory;

storing the receiving-object information in memory;

storing the transmitted-message information in memory; and

continuing operation of the existing debugger routine.

17. A graphic debugger process as set forth in claim 16 wherein said generating area-limited graphic representations of said information comprises the steps of:

generating a first area-limited representation of said transmitting-object information, said first area-limited representation including a first rectangle with the transmitting object name adjacent to said first rectangle;

generating a second area-limited representation of said receiving-object information, said second area-limited representation including a second rectangle with the receiving object name adjacent to said second rectangle; and

generating a third area-limited representation of said transmitted-message information, said third area-limited representation including an arrow, originating proximate said first rectangle and terminating proximate said second rectangle, with the text of said message placed within the perimeter of said second rectangle.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

This invention relates in general to systems for monitoring operation of software programs and in particular to a system for monitoring and documenting sequences of operations performed by object-oriented computer programming systems.

When computer processors were first developed, they were programmed directly in machine language and programs comprised sequences of binary encoded instructions indicating operations to be performed by a computer processor on a step-by-step basis. To facilitate programming, assembly languages were developed in which machine language instructions were represented by mnemonics and an assembly language program consisted of a collection of such mnemonics listed in the order that the instructions they represent were to be carried out. As higher level languages such as "Basic", "Fortran", "Pascal" and the like were developed, complex functions often requiring the processor to execute hundreds or even thousands of machine language instructions were represented by code comprising relatively few words, numbers and symbols more easily understood by humans than assembly language mnemonics. Yet even in these higher level languages, programs consist of code generally listed in the order in which the functions represented by the code are to be performed by the computer.

Such "sequential" languages are particularly useful for writing programs which cause a computer to carry out a predetermined sequence of operations. However computers are often utilized for modeling systems of interactive components in order to determine sequences of actions such systems would perform under various conditions. For example a programmer may wish to program a computer to mimic the manner in which some particular digital logic network responds to a particular input stimulus. When the programmer doesn't know beforehand what sequence of steps the logic network would carry out in response to the stimulus, but only how each individual component changes its outputs in response to a change to its inputs, the programmer often finds it difficult to utilize sequentially organized instructions to program a computer to model the behavior of the system.

In contrast to sequentially organized software, "object-oriented" software is organized into "objects", each comprising a block of computer instructions describing various procedures ("methods") to be performed in response to "messages" sent to the object. Such operations include, for example, the manipulation of variables and the transmission of one or more messages to other objects. Thus one "programs" in an object-oriented programming language by writing individual blocks of code each of which creates an object by defining its methods. A collection of such objects adapted to communicate with one another by means of messages comprises an object-oriented program. Object-oriented computer programming facilitates the modeling of interactive systems in that each component of the system can be modeled with an object, the behavior of each component being simulated by the methods of its corresponding object, and the interactions between components being simulated by messages transmitted between objects. Typically a user may stimulate an object through an image on a computer terminal representing the object, for example by utilizing a mouse to control a cursor on the screen to select the object, and by utilizing buttons on the mouse or a keyboard to transmit messages to the selected object. An object may also provide information to the user through its image on the screen by means of data displays or graphical changes to its image.

An operator may stimulate a collection of interrelated objects comprising an object-oriented program by sending a message to one of the objects. A method of the object receiving the message may cause the object to respond, carrying out predetermined functions which may include sending messages to one or more other objects. The other objects may in turn carry out additional functions in response to the messages they receive, including sending still more messages. In such manner sequences of message and response may continue indefinitely or may come to an end when all messages have been responded to and no new messages are being sent. When modeling systems utilizing an object-oriented language, a programmer need only think in terms of how each component of a modeled system responds to a stimulus and not in terms of the sequence of operations to be performed in response to some stimulus. Such sequence of operations naturally flows out of the interactions between the objects in response to the stimulus and need not be preordained by the programmer.

Although object-oriented programming makes simulation of systems of interrelated components more intuitive, the operation of an object-oriented program is often difficult to understand because the sequence of operations carried out by an object-oriented program is usually not immediately apparent from a software listing as in the case for sequentially organized programs. Nor is it easy to determine how an object-oriented program works through observation of the readily apparent manifestations of its operation. Most of the operations carried out by a computer in response to a program are "invisible" to an observer since only a relatively few steps in a program typically produce a change in an image on a screen or some other observable computer output. Some object-oriented programming systems include a "debugger" permitting a programmer to interrupt program operation at any point, to inspect the states of variables controlled by each object, and to review and change the methods associated with objects in the system. Some debuggers also provide a listing (a "message stack") of the messages which have been sent, but for which a response has not yet been completed. While such debuggers are useful, it is nonetheless difficult for a programmer to comprehend the sequence of actions performed with an object-oriented program, simply by interrupting a program and reviewing the message stack or current state of variables maintained via the objects involved.

SUMMARY OF THE INVENTION

In an object-oriented computer program, software is organized into "objects" each comprising a block of program instructions describing various procedures ("methods") to be performed in response to "messages" sent to the object from another object. In accordance with the present invention, a "diagramming debugger" creates a graphical representation of the sequence of messages sent during operation of an object-oriented program. When one object transmits a message to another object, the diagramming debugger displays representations of the transmitting and receiving objects on a computer screen, each representation suitably comprising a box with labels identifying the represented object. The box representing a sending object includes therein a symbol (comprising, for example, one or more characters) identifying the method that sent the message, while the box representing the receiving object includes therein a symbol identifying the method invoked by the message. The message is suitably represented by an arrow pointing from the symbol identifying the sending method to the symbol identifying the invoked method.

As program operation continues, a box representing an object may be added to the display whenever the object first receives a message, and a symbol representing an additional method may be added to an existing box whenever the method is first invoked. The order in which arrows are drawn on the screen between method symbols within the displayed boxes provides a graphical representation of the order in which messages are sent. Thus by continually adding boxes, method symbols, and arrows to the display as the program progresses, the diagramming debugger "animates" program operation so as to make the sequence of messages sent and methods performed by an object-oriented program easier to follow and comprehend.

It is accordingly an object of the present invention to provide a graphical representation of a sequence of operations performed by an object-oriented computer program.

The subject matter of the present invention is particularly pointed out and distinctly claimed in the concluding portion of this specification. However, both the organization and method of operation of the invention, together with further advantages and objects thereof, will best be understood by reference to the following description taken in connection with accompanying drawings.

DRAWINGS

FIGS. 1-12 are illustrations of displays produced on a computer screen according to the method of the present invention.

DETAILED DESCRIPTION

In "object-oriented" computer programs, software is organized into a collection of "objects", each object comprising a block of program instructions describing various procedures ("methods") to be performed by the computer in response to various commands ("messages") sent to the object. Such operations may include, for example, the manipulation of stored data, control of visual displays or other computer outputs, and the transmission of one or more messages to invoke methods performed by other objects One "programs" in an object-oriented programming system by creating a collection of individual blocks of code each of which defines the methods associated with an object, each method including an indication of the message which invokes the method and a set of instructions for causing the computer to carry out an operation or a set of operations in response to the message.

A user may initiate program operation by sending a message to one of the collection of objects comprising a program using a keyboard, mouse or other computer input means which is monitored by the receiving object. In response to the initial message, a method in the receiving object may cause the computer to carry out predetermined activities which include sending messages to one or more other objects in the system. These other objects may in turn carry out activities in response to the messages they receive, including sending still more messages to additional objects in the system. In such fashion a sequence of message and response may continue indefinitely following the initial message, or may come to an end when all messages are complete and no new messages are sent.

Thus while code in an object-oriented program is generally not organized in sequential fashion, an object-oriented program nonetheless may perform a sequence of operations in response to a stimulus message. As stated, the nature of such sequence of operations is not readily apparent to a programmer simply by reviewing the software listing and a programmer may find it hard to determine or comprehend how an object-oriented program "works" in terms of the steps it carries out, a disadvantage when attempting to debug a program which does not behave as expected.

In accordance with the present invention, the sequence of message transmissions carried out by a collection of objects of an object-oriented program is graphically represented. When one object transmits a message to another object, representations of the transmitting and receiving objects are displayed on a computer screen, each representation suitably comprising a box with labels identifying the represented object. The box representing the sending object includes therein a "selector" (a symbol comprising, for example, one or more characters) identifying the method that sent the message, while the box representing the receiving object includes therein a selector identifying the method invoked by the message. The message is suitably represented with an arrow pointing from the selector identifying the sending method to the selector identifying the invoked method. As program operation continues, a box representing an object may be added to the display whenever the object first receives a message, and a selector representing a method of an object may be added to an existing box representing the object whenever the method is first invoked. Selectors and arrows appearing on the screen at any time comprise a representation (hereinafter referred to as a "Cunningham diagram") of the messages sent in the course of executing a program, identifying the sending and receiving method associated with each message. The order in which arrows and selectors are added to the Cunningham diagram provides a graphical indication of the order in which the messages were sent and methods invoked. Thus by sequentially adding boxes, selectors, and arrows to the display as the program progresses, the present invention "animates" object oriented program operation so as to make the sequence of messages and responses occurring in the course of executing an object-oriented program easy to follow and comprehend.

The preferred embodiment of the present invention is implemented as an improvement to "Smalltalk-80" (hereinafter referred to as "Smalltalk"), a well known object-oriented computer programming language. "Smalltalk-80" is a registered trademark of the Xerox Corporation and the Smalltalk computer language is described in the books Smalltalk-80, The Language and Its Implementation, by Adele Goldberg and David Robson, and Smalltalk-80, the Interactive Programming Environment, by Adele Goldberg, both published in 1983 by the Addison-Wesley Publishing Company, and incorporated herein by reference.) As a programming convenience, Smalltalk objects are created and identified according to a hierarchy of object "classes", each object class comprising a set of one or more methods for implementing behavior common to each object of the class. In creating a new class of objects whose behavior varies in some respect from the behavior of an existing class, the new class is established as a "subclass" of the existing class. Objects of the new subclass may rely on code implementing methods shared in common with objects of its "superclass" (the existing class) and only code implementing methods which differ from methods of its superclass need be separately written and stored when creating the subclass. All Smalltalk classes are created as subclasses of an existing class, except the "root" class of the Smalltalk system, class Object, and it is by creating classes in this fashion that a tree-like hierarchy of object classes is created. Objects of any particular class may make use of methods of any of its "ancestral" superclasses in the hierarchy when its own class has no suitable method for responding to a particular message.

To illustrate the use and operation of the present invention, the sequence of operations carried out by a collection of objects in the Smalltalk system in evaluating the Smalltalk expression "2+3.0" will be described and then illustrated by a sequence of Cunningham diagrams produced according to the present invention. The expression "2+3.0" transmits a message +3.0 to the integer 2, a Smalltalk object. The hierarchy of Smalltalk classes relating to an object such as 2 is shown below in table I.

TABLE 1 ______________________________________ Object Magnitude Number Float Fraction Integer LargeNegativeInteger LargePositiveInteger SmallInteger ______________________________________

All Smalltalk classes descend from the class Object. Classes which represent various kinds of numbers are subclasses of class Number. Number is a subclass of the class Magnitude, a direct subclass of Object. (Other subclasses of class Magnitude not shown in Table I include, for example, Date and Time.) The class Number has three subclasses: Float for objects representing various floating point numbers, Fraction for objects representing fractional numbers, and Integer for objects representing integers. Subclasses LargeNegativeInteger and LargePositiveInteger of class Integer contain methods for objects representing negative and positive integers requiring more than a single machine word to be expressed in binary form. A subclass SmallInteger of Integer contains methods for objects representing integers requiring only a single machine word to be expressed in binary form. The number 2 is an object of the SmallInteger class.

In the message +3.0 sent to the Smalltalk object 2, the "+" symbol is a "method selector" which identifies a procedure (method) to be executed by the receiving object in response to the message. (By convention the method names are expressed in boldface type.) The number "3.0" is an "argument" of the message +3.0 comprising input data required in the course of executing the + method. When the object 2 receives the message +3.0, it searches the methods of its class SmallInteger to determine if a method identified by the selector + exists. It happens that one such method + does exist in class SmallInteger, and this method normally sums the argument of the message with the value represented by the receiving object (in this case 2), and then returns the result to the message sender. However the + method of the SmallInteger class is adapted only to add an integer to integer 2 and is not adapted to add a floating point number such as 3.0 to integer 2. When the SmallInteger object 2 determines that its class method + cannot respond to the message +3.0 carrying a floating point argument, it retransmits the +3.0 message to its superclass, Integer.

When Integer receives the message +3.0, it checks to see if it has a method identified by the + selector, and if it has no such method +, it retransmits the +3.0 message to its superclass, Number. The message continues to be retransmitted up the class hierarchy until a + method for responding to the message is found. However class Integer does have a method +, and this method differs from the + method of SmallInteger because it is capable of adding integers and floating point numbers, although not directly. In response to the +3.0 message, Integer's + method first checks the argument of the +3.0 message to see if it is an integer number. It does this by sending a message "isInteger" to the Smalltalk object 3.0, a member of the Float class, which responds to the isInteger message by indicating that it is not an integer. When Integer method + learns that 3.0 is not an integer, it transmits a message "retry: + coercing 3.0" to the object 2 which looks for a method identified by selector retry:coercing: for implementing the message. Since 2 does not in fact have such a method, it forwards the message to its superclass, Integer. Integer also has no such method, and therefore forwards the retry:coercing: message to its superclass Number.

Number does have a retry:coercing: method which solves the problem of adding the integer 2 to the floating point number 3.0 by converting integer 2 into a floating point number 2.0 and then sending the message +3.0 to the Float object 2.0. The Float object 2.0 then executes its + method which adds 2.0 and 3.0 and returns the floating point number 5.0. In the course of its operation, Number's retry:coercing method initially sends a message "generality" to object 2 and another "generality" message to the object 3.0. The generality methods executed by objects 2 and 3.0 in response to the generality messages cause them to return information to Number's retry:coercing: method which enables it to determine which object, 2 or 3.0, belongs to a more "general" class. According to the concept of "generality", when an object of a class A can be represented by an object of a class B without loss of information about the class A object, but an object of class B cannot be represented by an object of class A without loss of information about the class B object, then class B is more "general" than class A. In this case, the integer number 2 could be converted ("coerced") into a floating point number 2.0 without loss of information about its value but the floating point number 3.0 could not be coerced into an integer 3 without losing information about its value, namely its floating point precision. Thus the Float class is more "general" than the Integer class.

When the retry:coercing: method of the class Number learns that 3.0 belongs to a more general class than 2, it sends object 3.0 a message "coerce: 2" to object 3.0. The coerce: method accessed by object 3.0 responds to this message by returning the floating point number 2.0. The retry:coercing: method in Number then transmits a message "perform: + with: 3.0" to the floating point object 2.0, causing object 2.0 to execute its + method with the argument 3.0, whereby it returns the sum 5.0. This value is forwarded back to the initiator of the original message +3.0 to object 2, thereby completing evaluation of the expression "2+3.0".

From the foregoing discussion, it can be seen that in the Smalltalk system, execution of even an apparently simple procedure such as adding 2 to 3.0 involves a relatively complex sequence of messages and responses which is difficult to visualize. The source code which implements this sequence of operations is not developed as a sequence of instructions corresponding to the sequence of operations, but rather is written and stored in the form of methods grouped within a complex hierarchy of object classes without any obvious indication of the order in which such methods might be executed. Consequently, it is often difficult to predict the behavior of a collection of interactive Smalltalk objects carrying out an operation simply by looking at source code listings of the class methods utilized by the objects. Nor is it easy to determine what objects may be involved in a particular operation.

The present invention relates to an improvement to a prior art Smalltalk "debugger" (as described in Smalltalk-80, the Interactive Programming Environment by Adele Goldberg, 1983, Addison-Wesley Publishing Company), a collection of Smalltalk objects which permits a programmer to monitor evaluation of a Smalltalk expression (i.e. to monitor the response of a collection of Smalltalk objects to one or more messages sent thereto) on a "step-by-step" basis wherein each step includes execution of a method or a portion of a method, with expression evaluation being halted after each step so that a user may investigate the current states of variables controlled by Smalltalk objects utilized in the course of evaluating the expression. The prior art debugger also displays a list of messages sent, along with text of methods invoked by the messages. The improvement converts the prior art debugger into a "diagramming debugger" which in addition to performing the aforementioned functions, creates a sequence of Cunningham diagrams illustrating message transmissions occurring in the course of expression evaluation, thereby animating program operation. FIGS. 1-12 illustrate a sequence of displays produced on a computer screen in the course of utilizing the diagramming debugger of the present invention to produce a sequence of Cunningham diagrams animating the evaluation of the expression "2+3.0".

The Smalltalk system permits an operator to transmit a message to an object by utilizing a three-button mouse connected to a computer terminal accessing the Smalltalk system. The mouse moves a cursor on the screen, and buttons on the mouse may be depressed to display menus on the screen listing commands an operator may select. A menu selection is typically made by moving the cursor over a menu item and then releasing the button used to invoke the menu. Thereafter the menu is removed from the screen and response to the selected command is initiated by sending a predetermined message to an object in the Smalltalk system. With reference to FIG. 1, an operator invokes the diagramming debugger of the present invention to monitor evaluation of a Smalltalk expression such as 2+3.0 by typing the line "DiagramDebugger debug: [2+3.0]" into the standard Smalltalk "Workspace" window 12. Thereafter the operator utilizes cursor 14 to select a command 16 "do it" from a Smalltalk standard menu 18 displayed by depressing the middle button of the threebutton mouse while the cursor is within the Workspace window 12.

The Smalltalk system is adapted to "simultaneously" carry out multiple processes such as monitoring the keyboard, monitoring the mouse, managing a clock, running multiple user programs and the like, and the Smalltalk system must establish a new process in order to evaluate the expression 2+3.0 In response to the "do it" command, a "newProcess" message is sent to the standard Smalltalk object BlockContext which creates a new "suspended" process for evaluation of the expression in block [2+3.0], and the Smalltalk compiler compiles the string "DiagramDebugger debug: [2+3.0]" as a method "unboundMethod" of a standard Smalltalk class UndefinedObject. A "suspended" process is a process which is halted until restarted by a "resume" command. The message unboundMethod is then sent to the class UndefinedObject which responds by displaying a window 20 as shown in FIG. 2, labeled "DiagramDebugger" and having a number of panes 21-27.

As previously mentioned, the preferred embodiment of the invention relates to an improvement to a the Smalltalk debugger of the prior art, and this prior art debugger implements panes 21-26 of window 20. The improvement implements pane 27, utilized to display a Cunningham diagram graphically representing messages sent in the course of program execution. Pane 21 displays a "stack" containing lines indicating messages which have been sent but for which methods invoked by the messages have not yet been fully executed. The stack shows the order in which messages were sent, the most recently sent message appearing in the top line of the stack. Each line of the stack includes the name of the class of the message receiving object and the message selector, the receiving object class name and the message selector being separated by a symbol ">>". Pane 22 displays a listing of the Smalltalk code for a method for responding to a message on the stack in pane 21 selected by the operator. The operator can select any message on the stack by using the mouse to point the cursor at the message and then operating a mouse button, the selected message being highlighted. When the operator has made no selection, the message at the top of the stack is automatically selected and highlighted. Panes 23 and 24 comprise a Smalltalk "inspector" permitting inspection of variables controlled by the receiving object of the selected message in pane 21, while panes 25 and 26 comprise a Smalltalk inspector permitting inspection of temporary variables utilized by the method displayed in pane 22. Variable names are displayed in panes 23 and 25, and when an operator uses the mouse to select a variable name in pane 23 or 25, the current value of the variable is displayed in pane 24 or 26, respectively.

The message stack in pane 21 includes two lines. The lower line "[ ] in Blockcontext>>newProcess" indicates the message newProcess was sent to BlockContext and the upper line "[ ] in UndefinedObject>>unboundMethod" indicates that the unboundMethod message was sent to UndefinedObject. The top line of the stack is selected and therefore the text of the unboundMethod method is displayed in pane 22. Pane 23 shows the only pseudovariable "self" associated with the UndefinedObject. Pane 25 is empty since the method unboundMethod in pane 22 utilizes no temporary variables. Panes 24 and 26 are empty because no variable is selected in pane 24 or 25. In pane 22, the first message to be sent (+3.0) by unboundMethod when expression evaluation commences is highlighted. Since the process for evaluating 2+3.0 is currently suspended, the display remains fixed as shown in FIG. 2 until the operator causes the process to resume.

To cause the process to resume, the operator may place the cursor over pane 27, invoke a "diagram" menu 30 as shown in FIG. 2, and then select a command 32 "send" from the menu. The send command causes the message +3.0 to be sent to the object 2. Thereafter, as shown in FIG. 3, the diagramming debugger displays a highlighted box 40 in pane 27 representing the object 2, and an arrow 50 representing the message +3.0 sent to it. Block 40 has one "class line" labeled with the class name SmallInteger of object 2 and containing a "+" symbol, the selector of the SmallInteger class method invoked by message 50. The arrowhead of arrow 50 is directed to the + symbol to indicate the + method of SmallInteger was invoked by the message. The highlighting of box 40 indicates the SmallInteger object 2 represented by box 40 is in the process of responding to a message, but that the process has been interrupted (suspended) by the diagramming debugger. Before displaying box 40 on the screen, the diagramming debugger displays a "corner" cursor in pane 27 in the shape of the upper left corner of a square and the operator utilizes the mouse to move the corner cursor to a desired location on the screen and depresses a mouse button. The diagramming debugger then displays the box 40 on the screen with its upper left corner in the position indicated with the corner cursor and connects arrow 50 to the box.

After the +3.0 message is sent to object 2, the diagramming debugger adds the line "SmallInteger>>+" to the top of the stack in pane 21, displays the text of the method + of class SmallInteger in pane 22, and displays the temporary variable aNumber utilized by the SmallInteger + method in pane 25. The value of the variable aNumber is 3.0, the argument of the +3.0 message. The SmallInteger + method text displayed in pane 22 includes a comment bounded by quote marks describing the function of the method. Following the comment, SmallInteger method + includes a line "<primitive: 1>" indicating the addition function of the + method is to be carried out by an assembly language subroutine (a "primitive"). The next line thereafter is executed if the primitive cannot go to completion. In this example the primitive can only add two integers and therefore cannot add the floating point number 3.0 to the integer 2. The highlighted portion (+ aNumber) of the next line defines the next message to be sent by the SmallInteger object 2. Since the value of the aNumber variable is 3.0, the message +3.0 will be sent to "super", a pseudovariable referring to SmallInteger's super class, Integer.

To cause the message +3.0 to be sent to Integer, the operator may again bring forth the display menu 30 of FIG. 2 over pane 27 and select the "send" command. The Cunningham diagram display thereafter changes as shown in FIG. 4. In FIG. 4, box 40 is expanded to include a line labeled with the name Integer of the class receiving the last message and containing another selector symbol + indicating the Integer class method invoked by the message. The + symbol following the SmallInteger class name in box 40 is linked to the + symbol following the Integer class name by a new arrow 51 indicating the + method of SmallInteger sent a message invoking the + method of class Integer. Box 40 suitably flashes (i.e., its highlighting turns on and off) to indicate it is presently responding to a message sent up the class hierarchy of SmallInteger object 2 represented by the box 40. A line "SmallInteger(Integer)>>+" is added to the top of the stack in pane 21 for indicating a message with selector + sent to SmallInteger was forwarded up the class hierarchy to its superclass Integer. The text of the Integer class + method replaces the text of the SmallInteger class method + in pane 22.

In pane 22 of FIG. 4, the first line of the Integer class + method following a comment enclosed in quotes is "aNumber isInteger". This expression, when executed, causes the highlighted message "isInteger" to be sent to object 3.0, since 3.0 is the value of the temporary variable aNumber. When the operator invokes the command "step" from the pane 27 display menu 30 of FIG. 2, the isInteger message is sent to object 3.0, changing the display as shown in FIG. 5. The step command invoked from menu 30 causes the diagramming debugger to permit process operation to continue until the response to the highlighted message in pane 22 of FIG. 4 is complete, rather than suspending the process prior to execution of the first step o