Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1996-08-01
2001-04-17
Oberley, Alvin E. (Department: 2755)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C709S241000
Reexamination Certificate
active
06219826
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to the field of object-oriented programming. More specifically, it is related to an improved method and system for rendering the execution of object-oriented programs visually on a computer.
BACKGROUND
There are three important concepts in object-oriented programming: encapsulation, inheritance, and polymorphism. Encapsulation refers to how implementation details are hidden by an abstraction called an “object.” An object is said to encapsulate data and operations on that data. An object-oriented software system is made up of objects interacting with one another. They interact by sending “messages” to each other. An object implements its response to a message in a “method.” Objects are unaware of each other's implementations; they only know the messages other objects respond to. Encapsulation controls complexity by partitioning the software system into small, well-defined pieces, and it makes it easy to change part of the system without affecting other parts.
Objects send messages as a result of receiving them. The “call stack” for an object-oriented program records the current chain of communication from object to object. After the first object on (the top of) the call stack sends a message to the second object, the first object waits for the method on the second object (which implements the message) to finish executing. After the second object on the call stack sends a message to the third object, the second object waits for completion of the corresponding method, etc. The last object on the (bottom of the) call stack is the one for which a method is being executed currently. The first object on the call stack is the “caller” of the second object on the call stack. The second object is the first's “callee.” Similarly, the second object on the call stack is the caller of the third object, and the third is the callee of the second, and so forth.
Inheritance refers to taxonomic relationships between objects. An object belongs to and is defined by a “class.” A class defines the set of messages an object can respond to, and it defines the data and methods that implement those responses. An object is said to be an “instance” of a class. A class can have arbitrarily many instances.
Inheritance lets classes be defined in terms of other classes. A class that inherits from another class is called a “subclass” of the other class (which is called the “parent class” or “superclass”). The subclass responds to the same messages as its parent, and it may respond to additional messages as well. The subclass “inherits” its implementation from its parent, though it may choose to reimplement some methods and/or add more data. Inheritance lets programmers define new classes easily as incremental refinements of existing ones. It also enables polymorphism.
Polymorphism refers to the substitutability of related objects. Objects are “related” if they have the same “type,” and in most object-oriented languages that means they are instances of the same class, or they have a common parent class through inheritance. Objects that are related through inheritance may be treated uniformly, that is, without regard to their specific type. For example, a Graphic class that defines an abstraction for graphical objects may define a Draw method. The Graphic class might have subclasses Rectangle and Circle that reimplement the Draw method to draw a rectangle and circle, respectively. Polymorphism allows Rectangle and Circle instances to be treated uniformly as Graphic objects; that is, all one needs to know to tell an object to draw itself is that the object is an instance of a Graphic subclass. Whether the object is an instance of Rectangle or Circle is immaterial; one can send it the Draw message without knowing its exact type (e.g., Rectangle or Circle).
Polymorphism lets programmers write general code that can be customized later without change. Suppose we have code that draws pictures by sending Draw messages to a set of Graphic instances. We can pass it Rectangle and Circle objects, and it will tell them to draw themselves. Later we can define a new subclass of Graphic, say, Polygon, implementing its Draw method appropriately. Because Polygon is a subclass of Graphic, we can pass instances of Polygon to our picture-drawing code, and it will draw polygons in our picture—with no modification whatsoever.
Object-oriented programs often use thousands of objects, organized by tens or hundreds of classes. Often it's hard to understand how these programs work just by examining their code, since the code describes only the static aspects of the program (i.e., the classes). Understanding the dynamic aspects of the program requires a depiction of the program at execution time. Animated graphics are a way to depict an object-oriented program's execution.
U.S. Pat. No. 4,885,717 to Beck discloses a graphical presentation depicting individual objects on the display sending messages to each other. Objects appear as graphical nodes, and messages are shown as directed lines between the nodes. Once drawn, objects stay in fixed positions for the duration of the program's execution. No semantics are associated with placement of nodes.
Another well-known visual metaphor is the “interaction diagram,” which also depicts messages to classes or objects over time. Typically, a message is shown as a labeled directed line that points to a perpendicular line denoting a class or object. Distance along the class or object line corresponds to time. Lines denoting messages are parallel to each other and are ordered to reflect the order in which the messages were sent Lines denoting classes or objects appear parallel to each other and perpendicular to the message lines. The advantage this metaphor has over Beck's approach is that repeated messages sent to the same or nearby objects do not interfere with each other, since time is given a physical dimension.
STATEMENT OF PROBLEMS WITH THE PRIOR ART
There are two main problems with the prior art:
1. It does not handle realistic quantities of objects. Non-trivial object-oriented systems employ hundreds of objects or more. In Beck's approach, displaying each object in the system produces an unintelligible mass of graphics. Moreover, objects never disappear, even when they have been deleted. Deleted objects further clutter the presentation. They distract the observer, making it harder to see the objects that are active. Displaying deleted objects may also mislead the observer into thinking that there are more objects in the system than there really are. Interaction diagrams have analogous problems: as the number of objects or classes increases, one dimension of the diagram must increase with it. This quickly yields diagrams that are too large to be effective.
2. It does not handle realistic quantities of messages. Each time a message is sent, another directed line appears to depict it. Hence the number of directed lines corresponds to the number of message sends. Since this number generally exceeds the number of objects in the system, the display becomes cluttered with directed lines even more quickly than it does with objects. In Beck's approach, these lines compete for space that is determined by the number of objects. The resulting interference among the lines makes the diagram unintelligible. In interaction diagrams, the problem manifests itself as unmanageably long diagrams along the time dimension.
As a result of these problems, the prior art is not effective for systems that are large enough to need dynamic graphical presentation. The need exists for a visual metaphor that reveals both microscopic and macroscopic behavior in an object-oriented program regardless of its size and complexity. The present invention addresses such a need.
SUMMARY
In accordance with the aforementioned needs, the present invention is directed to an improved method and system for visualizing an object-oriented program's execution in a manner that facilitates understanding, debugging, and tuning programs of arbitrary size and
De Pauw Wim
Lorenz David Hod
Vlissides John Matthew
Wegman Mark N.
International Business Machines - Corporation
Oberley Alvin E.
Ratner & Prestia
Stecher Peter
LandOfFree
Visualizing execution patterns in object-oriented programs does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Visualizing execution patterns in object-oriented programs, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Visualizing execution patterns in object-oriented programs will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2506903