Symbol browsing in an object-oriented development system

Abstract

A system of the present invention includes a development system having a language compiler for generating application and system software from source listings. The system includes an Integrated Development Environment having a browser. Methods of the present invention include inspecting symbols (e.g., classes, objects, methods, variables, and the like) dynamically, i.e., while retaining active scope of the symbol. More particularly, the browser of the present invention directly references symbol information stored in object code or executable modules, which are generated during compilation of the source listings. In this manner, the system provides symbol information directly relevant to the context (location in source listing) the user/programmer is currently working.

Claims

What is claimed is:

1. In a development system for compiling source listings into application and system programs, each of the source listings comprising a plurality of symbols for instructing operation of a program, a method for browsing symbols comprising:

(a) compiling a source listing containing the symbols into a compiled program, said compiled program selectively storing symbol browsing information when browsing is desired by a user;

(b) selecting a symbol of interest from a device displaying the source listing, said symbol being located at a particular location in the source listing and having a particular scope at that location;

(c) receiving a request from the user for browsing the selected symbol of interest;

(d) determining from the stored symbol browsing information, browsing information specific for the symbol of interest; and

(e) displaying said browsing information to the user, so that browsing information with a scope appropriate for the selected symbol at the particular location is displayed.

2. The method of claim 1, wherein said source listings are selected ones of Pascal, C, C++, and assembler listings.

3. The method of claim 1, wherein said compiled program comprises an object file linked with other object and library files for creating an executable program.

4. The method of claim 1, wherein the symbol browsing information is stored in a browsing table in the compiled program.

5. The method of claim 1, wherein the symbol browsing information includes line number information specifying a position of the symbol in the source listing.

6. The method of claim 1, wherein said compiling step includes translating said symbols into machine instructions executable by a processor.

7. The method of claim 1, wherein said symbols are selected ones of program variables and functions.

8. The method of claim 1, wherein said symbols are selected ones of program classes, objects, and class methods.

9. The method of claim 1, wherein said information displayed to the user includes relationships between said classes.

10. The method of claim 1, wherein step (b) includes:

selecting a symbol of interest from the display device with a pointing device.

11. The method of claim 1, wherein the request from the user is generated by the pointing device.

12. The method of claim 1, wherein said request includes a right button signal generated by the pointing device.

13. The method of claim 1, wherein said information displayed to the user includes a name, at least one type, and related members of the symbol.

14. The method of claim 13, wherein said at least one type is a selected one of a variable and a function.

15. The method of claim 13, wherein said at least one type includes a class, and wherein said related members include superclasses and subclasses of the class.

Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of computer systems and, more particularly, to systems and methods for compiling source programs, particularly object-oriented ones, into system and application programs.

Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a "computer program," direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.

Owing to their digital nature, computers essentially only understand "machine code," i.e., the low-level, minute instructions for performing specific tasks--the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring human language so that humans can get computers to perform specific tasks.

While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programing languages. The most widely used programming languages are the "high-level" languages, such as C or Pascal. These languages allow data structures and algorithms to be expressed in a style of writing which is easily read and understood by fellow programmers.

A program called a "compiler" translates these instructions into the requisite machine language. In the context of this translation, the program which is written in the high-level language is called the "source code" or source program. The low-level or machine language, on the other hand, comprises "object code." Once created, object code (e.g., .obj file) is a separate program in its own right--it includes instructions which may be executed by the target microprocessor. In practice, however, the object code is usually first linked (i.e., combined) with other object code or libraries, which include standard routines.

Compilers are fundamental to modern computing. Translating human-oriented programming languages into computer-oriented machine languages, compilers allow computer programmers to ignore the machine-dependent details of machine language. Instead of focusing on the register set or memory architecture of a particular computer, for instance, one may simply concentrate on solving the problem at hand. Thus, high-level languages are "portable," that is, they afford a level of abstract which permits a single program to be implemented on several different machines, including ones of vastly different architecture.

Of particular interest to the present invention are compiler and development tools designed for graphic user interfaces (GUIs), such as Microsoft.RTM. Windows and Apple.RTM. Macintosh System 7. Employing an intuitive "desktop metaphor", including such familiar objects as file cabinets, folders, and trash cans, these system have largely displaced awkward command-line systems, such as MS-DOS.

While GUIs are easy for the users to use, they are by no means simple to program. Instead, the intuitive user interface belies an extremely complex system, one having hundreds of API (Application Programming Interface) calls. A simple "Hello World" Microsoft Windows program written in C, for example, requires a hundred or so lines of source code. Besides the sheer bulk of the API, however, the programmer faces an even greater challenge--that of understanding the intricacies of a message-driven environment.

At the heart of a GUI such as MS-Windows is a message or event-driven system, one which requires a shift in the way programmers normally think about computer programs. Traditionally, programmers have developed programs consisting of sequential procedures or modes. As such these programs have a well-defined beginning, middle, and end, with little or no flexibility for the user to vary this pre-determined sequence.

A GUI, in contrast, promotes a "modeless" model, that is, one not tied to any particular predefined sequence of modes. To accomplish this, these systems introduce the notion of "events" and "messages." An event is any activity of interest, such as the press of key on a keyboard or movement of a pointing (mouse) device. The system responds to an event by sending a message to the currently executing application(s). In MS-Windows, for instance, when the user clicks a left mouse button, a WM.sub.-- LBUTTONDOWN message is sent. Similarly, pressing a keyboard key causes a WM.sub.-- KEYDOWN message to be sent. If the user selects an item from a menu, a WM.sub.-- COMMAND message is sent. Other messages correspond to manipulating scroll bars (WM.sub.-- HSCROLL, WM.sub.-- VSCROLL), resizing windows (WM.sub.-- SIZE), redrawing windows (WM.sub.-- PAINT), closing windows (WM.sub.-- CLOSE), and so on.

There are so many messages which may be generated in fact that managing them has become quite a choir in itself. Using C, for example, the programmer writes an event loop that checks to see whether there any messages which must be responded to. In practice, however, this entails writing a gargantuan case statement that dispatches messages to various functions. And in a Windows program of any complexity, this case statement often spans several pages, making development and maintenance of the program an exceedingly difficult task. Thus, there is much interest in devising tools which reduce or eliminate the complexity of GUI development.

Although not an object-oriented system itself, Windows possesses characteristics which facilitate application development with object-oriented programming (OOP) methodologies. Most notably, Windows is an event-driven or message-based system; its messages are analogous to the OOP concept of sending messages to objects. Combining the event-driven nature of Windows with an OOP language creates a single, more consistent development model. Just as a high-level language frees a programmer from the need to understand machine-level details, an OOP language, by hiding Windows details, eases the task of learning an event-driven architecture.

While the move from procedural to object-oriented programming has facilitated the creation and maintenance of GUI application software, present day development tools have not kept pace. More particularly, application development in an object-oriented programming language, such as C++, brings with it a host of new complexities which the application developer must somehow manage. For instance, a C++program of even modest complexities requires the creation and maintenance of immense class hierarchies--sophisticated data structures with complex interdependencies. Thus, while a programmer may encapsulate the complexities of a GUI application in an object-oriented framework, the complexities of such a framework, in turn, must be managed with tools which are inadequate for object-oriented development.

What is needed are system and methods for simplifying the creation and management of object-oriented applications, particularly those with complex class hierarchies. More particularly, such a system should provide the developer with the ability to easily manage the complex data structures attendant to object-oriented development. The present invention fulfills this and other needs.

SUMMARY OF THE INVENTION

The present invention recognizes a need for providing an object-oriented development environment with tools for managing complex data structures and hierarchies. A system of the present invention includes a development environment having a compiler, a linker, and an interface. Through the interface (either command-line or UI driven), an application or system developer supplies source code listings to the compiler. Additional source and/or programs are provided by standard libraries and class libraries. From the source listings (including header and include files), the compiler generates object modules. In turn, these may be linked with other object modules or libraries to generate program executable by a target processor.

The interface of the present invention includes a browser module for providing on-demand inspection of symbols which comprise the source listings. In a preferred embodiment, "browsing information" (i.e., symbols and their data) is optionally stored in object code modes (or executable programs if linked) upon generation by the compiler. A browsing window is provided for on-demand inspection of symbols in the source listing, whereby reference is made to the browsing information stored in the executable program corresponding to the source listings. Since browsing information is stored and later referenced directly from code modules themselves, the browser of the present invention provides information (e.g., visibility or "scope") which is appropriate for the context (exactly where in the source code) a programmer is currently working.

The browsing module of the present invention also includes a filter interface for managing the display of complex and sometimes voluminous information. In particular, a user interface component resembling a familiar DIP (dual-inline package) switch is displayed on the screen for setting various filters. In this manner, the user may easily toggle filters as desired for a particular view of the information.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram of a computer system in which the present invention may be embodied.

FIG. 1B is a block diagram of a software system for controlling the operation of the system of FIG. 1A, the software system including an object-oriented development system of the present invention.

FIG. 2A is a screenshot bitmap of an event-driven graphic user interface employed the present invention.

FIG. 2B is a block diagram comparing an event-driven model with traditional modal architecture.

FIG. 3A is a block diagram of the development system of FIG. 1B.

FIG. 3B is a flowchart illustrating the general operation of the development system of FIG. 3A.

FIGS. 4A-B are screen bitmaps illustrating an integrated development environment (IDE) of the system of the present invention.

FIG. 5 is a screen bitmap illustrating a help dialog which is invoked in response to a request for information about a symbol in the IDE of FIG. 4.

FIGS. 6A-B are screen bitmaps illustrating the implementation of a browser module of the present invention, which is displayed in response to a user request for information about a particular symbol.

FIGS. 7A-F are screen bitmaps illustrating construction and operation of the browser module of FIG. 6B.

FIGS. 7G-N are screen bitmaps illustrating inspection of a class hierarchy for application software using the browsing module of the present invention.

FIG. 8A is a block diagram illustrating the relationship between the browser of the present invention and object files (where browser information is stored).

FIG. 8B is a flowchart illustrating a method of the present invention for browsing symbols.

FIG. 8C is a flowchart illustrating a method of the present invention for enumerating browsing information of a symbol; this method is a subroutine of the method represented in FIG. 8B.

FIG. 8D is a method of the present invention for filtering the display of screen information.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

General Architecture

A. System Hardware

The present invention may be embodied on a computer system such as the system 100 of FIG. 1, which includes a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a display device 106, and a mass storage 107 (e.g., hard disk). Additional input/output devices, such as a printing device 108, may be provided with the system 100 as desired. As shown, the various components of the system 100 communicate through a system bus 110 or similar architecture.

B. System Software

The following description will focus on the presently preferred embodiments of the present invention, which are operative in the Microsoft Windows environment. The present invention, however, is not limited to any particular application or any particular environment. Instead, those skilled in the art will find that the system and methods of the present invention may be advantageously applied to a variety of system and platforms, including Macintosh, UNIX, NextStep, and the like. Moreover, while the present invention is particularly useful for object-oriented systems, those skilled in the art will appreciate that the system and methodology of the present invention may also be employed to advantage in procedural environments (including C, BASIC, assembler, and the like) as well. Therefore, the description of the exemplary embodiments which follows is for purposes of illustration and not limitation.

Illustrated in FIG. 1B, a computer software system 150 is provided for programing the operation of the computer system 100. Software system 150, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system 160 and a windows shell or interface 180. One or more application programs, such as application programs 170 or windows applications programs 190, may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100. OS 160 and shell 180, as well as application software 170, 190, communicate with the user through an interface 165 for receiving commands and data and displaying results and other useful information.

Software system 150 also includes a development system 200 of the present invention for developing system and application programs. As shown, the development system 200 includes components which interface with the system 100 through windows shell 180, as well as components which interface directly through OS 160.

In a preferred embodiment, the system 100 is an IBM-compatible personal computer, available from a variety of vendors (including IBM of Armonk, N.Y.). Operating system 160 is MS-DOS and shell 180 is Microsoft Windows, both of which are available from Microsoft Corporation of Redmond, Wash.; alternatively, the system 100 may be implemented in other platforms, including Macintosh, UNIX, and the like. In an exemplary embodiment, development system 200 includes Borland Pascal 7.0; alternatively, system 200 includes Borland C++, version 3.1. Both are available from Borland International of Scotts Valley, Calif. Application software 170, 190, on the other hand, can be any one of a variety of software applications, including word processing, database, spreadsheet, text editors, and the like.

Event-driven Windows Development

A. Windows interface

As shown in FIG. 1C, the system 100 typically presents UI 165 as a windowing interface or workspace 200. Windows interface 200 is a rectangular, graphical user interface (GUI) providing one or more windows 201 for display on screen 106; additional window objects may be displayed in various sizes and formats (e.g., tiled or cascaded), as desired. At the top of window 201 is a menu bar 210 with a plurality of user-command choices, each of which may invoke additional submenus and software tools for use with application objects. Window 201 also includes a client area 220 for displaying and manipulating screen objects, such as graphic object 221 and text object 222. In essence, the client area is a workspace or viewport for the user to interact with data objects which reside in the memory 102 of the computer system 100.

Windows interface 200 includes a screen cursor or pointer 225 for selecting and otherwise invoking screen objects of interest. In response to user movement signals from the pointing device 105, the cursor 225 floats (i.e., freely moves) across the screen 106 to a desired screen location. During or after cursor movement, the user may generate user-event signals (e.g., mouse button "clicks" and "drags") for selecting and manipulating objects, as is known in the art. For example, Window 201 may be closed, resized, or scrolled by "clicking on" (selecting) screen components 212, 214/5, and 217/8, respectively. Keystroke equivalents, including keyboard accelerators or "hot keys", are provided for performing these and other user operations through keyboard 104.

B. Event-driven Architecture and "Messages"

Underlying the windows interface is a message or event-driven architecture. This model is perhaps best described by contrasting its operation with that of a modal or sequential architecture which has been traditionally employed. In this manner, the reader may appreciate the added flexibility as well as complexity of an event-driven system.

As shown in FIG. 2B, a modal program 250 comprises a series of discrete operating blocks or modes 255, with a well-defined beginning, middle and end. In actual operation, such a program typically displays a series of input screens for receiving user information, for example, to create a written report. For instance, the first entry screen may require a customer name, the second a customer address, the third a part number, and so on. The program typically terminates in an output mode, for reporting results determined from the various inputs. Thus, the program 250 follows a fairly rigid sequence of operation, with each input or entry mode demanding successful completion before the program proceeds to the next step.

While a modal program is relatively easy to design and implement, it is not so easy to use. The design certainly ensures that all required information is entered, but only at the expense of forcing users to operate in a manner dictated by the program. Specifically, since the program is built around a pre-arranged set of modes, a user cannot get from one mode to another without first completing a previously-required mode. In the present example, for instance, a user must needlessly complete a customer name entry screen (and any other intervening input screens) just to access part number information. Any deviation from this sequence by the user is simply not permitted. Lacking flexibility, modal programs make a poor choice for handling real-world tasks.

As shown in the second half of FIG. 2B, an event-driven architecture 260 eschews a pre-selected sequence, opting instead for an "event loop." The event loop 261 is a centralized mechanism for processing messages about user and system events. It includes an event queue 270 and mechanisms for retrieving 263 and dispatching 269 messages to various window classes 280. Before each of these components is further described, it is helpful to understand the notion of "messages."

In a typical modal environment, especially those typified by a character-based UI, a program reads from the keyboard by making an explicit call to a function, such as the C function getchar(). The function typically waits until the user presses a key before returning the character code to the program; all system activity ceases until completion of this one step. In a Windows environment, in contrast, the operating system uses messages to manage and synchronize multiple applications and hardware events, such as clicks of a mouse or presses of a keyboard, which in MS-Windows are converted to messages by Windows event handlers.

From a programming perspective, a message is simply a data structure containing information about a particular event. In MS-Windows, a message structure includes a message identifier, a 16-bit unsigned integer which serves as a symbolic constant for a particular event. For example, messages from a window object might include information about creating (WM.sub.-- CREATE), closing (WM.sub.-- CLOSE), moving (WM.sub.-- MOVE), and re-sizing (WM.sub.-- SIZE) the window. Additional event data are available as message parameters (e.g., Windows wParam and lParam); the exact interpretation of a given parameter vary with each event type represented. Input messages are collected in a system-wide queue and then directed to the proper window. These messages, along with timer and screen paint (screen redraw) messages, must be passed to the target application(s) of interest.

A mechanism is provided for retrieving messages from the system queue and dispatching them to the appropriate application which, in turn, may proceed to process any message that arrives. Each window belongs to a particular window type which defines certain characteristics common to all windows of that type. Associated with each type is a Windows function which processes all messages sent to windows of its type. An application queue is provided where Windows may place messages that belong to a specific application. When the application is ready to receive input, it simply reads the awaiting messages. If none are found or if there exists a message for other applications with higher priority, Windows passes control to the other applications.

To process these events, therefore, a message or event loop 261 may be simply constructed as:

    ______________________________________
    while (GetMessage (&msg, NULL, 0, 0))
             {
             TranslateMessage (&msg) ;
             DispatchMessage (&msg) ;
             }
    return msg.wParam ;
    ______________________________________

    ______________________________________
    Symbol          Meaning
    ______________________________________
    const           Constant
    func            Function
    label           Label
    proc            Procedure
    type            Type
    var             Variable or a typed constant
    ______________________________________

    ______________________________________
    Letter          Symbol
    ______________________________________
    F               Function
    P               Procedure
    T               Type
    V               Variable
    C               Constant
    L               Label
    I               Inherited from an ancestor
    p               Private symbol
    v               Virtual method
    ______________________________________

                  APPENDIX A
    ______________________________________
    Table lists exemplary keys and menu commands that
    activate specific browser functions.
    Task:           Preferred command:
    ______________________________________
    Browse objects  Choose Search.linevert split.Objects.
    Browse units    Choose Search.linevert split.Units.
    Browse global symbols
                    Choose Search.linevert split.Globals.
    Browse Symbol   Place the cursor on the symbol in
                    the code, choose Search.linevert split.Symbol, or
                    hold down Ctrl and click the right
                    mouse button.
    Select Browser Option
                    Choose Options.linevert split.Browser.
    Select Source Tracking
                    Choose
                    Options.linevert split.Environment.linevert split.Options
                    2
                    Preferences.
    Select Mouse Options
                    Choose Options.linevert split.Environment.linevert
                    split.Mouse.
    Open a Previous browser
                    Choose Search.linevert split.Previous Browser,
                    choose Previous on the browser
                    window local menu, or press Ctrl+P.
    Select Local Browser
                    Press Ctrl+O, or choose Options on
                    Options browser window local menu.
    Edit source code
                    Press Ctrl+Enter, press Ctrl+G, or
                    choose Goto Source on the browser
                    window local menu.
    Track source code
                    Press Spacebar from the Browser,
                    press Ctrl+T, or choose Track
                    Source on the browser window local
                    menu.
    Display reference info
                    Press Ctrl+R from the browser or
                    click the R in the window frame.
    Display scope info
                    Press Ctrl+S from the Browser,
                    or click the S in the window frame.
    Display inheritance info
                    Press Ctrl+I from the Browser,
                    information or click the I in the
                    window frame.
    Reverse Sub-browsing
                    Hold down Shift while selecting the
    setting         next browsing action.
    ______________________________________

• Inventors
  Frid-Nielsen, Lars Kristian;
• Assignee
  Borland International, Inc. (Scotts Valley, CA)
• Published
  Apr-14-1998
• Current US Classes:
  345/854
  717/102
• Application #
  710292
• International Classes
  G06F 003/00
• Field of Search
  395/326-358 395/604-606 395/701-709 345/326-358
• Examiner
  Breene; John E.
• Agent
  Smart; John A.
• US Patent References:
  5095423
  5117349
  5129082
  5339433
  5432903
  5557730