Patent Application
20070043547
The present system relates to the field of simulating network properties and behavior and particularly to an interface to facilitate debugging of a simulation.
A network is composed of a set of components, each with some associated behavior and properties. A discrete event simulation of such a network is a software program whose execution represents as much of the network's components' properties and behavior as necessary for the simulation's purpose. As such, modeling network communications typically involves simulating a large number of components with properties and behavior. In the case of incorrect results, one needs to “debug” the simulation by analyzing these components during simulation execution.
Debugging the simulation's behavior typically involves a review and analysis of the actions of a large number of simulated network components. Furthermore the processes that are executed in the simulation are typically programmed using a high level programming language such as C, C++, Java, or other high level programming language of the like where one can inadvertently express incorrect behavior. However, to track down issues in these processes during the simulation, one often has to investigate their behavior at the programming instruction level. However, prior systems typically require debugging either at the event level (high level) or the source level (low level) using text-based debuggers.
It is an object of the present system to overcome disadvantages and/or make improvements in the prior art.
The present system includes a system, method and device for generating a user interface for debugging a network simulation. In operation, a network is simulated based on modeled network behavior. A user interface (UI) is provided to depict both of a high level element and a low level element based on the simulation. The high level element may be presented in a hierarchical view representing a hierarchy of elements. The hierarchical view may be provided in a tree-view. The hierarchy of elements may be based on a topological hierarchy of elements within the simulated network. In one embodiment, the hierarchy of elements may be based on a taxonomy of elements within the simulated network or the hierarchy of elements may be based on a simulation hierarchy of elements within the simulated network. An invoking element may be depicted higher in the hierarchical view than an element invoked by the invoking element.
Within the hierarchical view, selectable levels of simulation detail may be provided. The high level element may be provided with a visual characteristic that distinguishes that high level element from another high level element that is a different type of high level element. For example, the high level element may be provided with a visual characteristic that indicates that the high level element is an active element in the simulation. For example, an active element may be an element currently undergoing an action within the simulation, such as processing a data packet
In one embodiment, a first simulation trace may be depicted and stored as the high level element. Thereafter, a change may be received in the modeled network behavior from a user and the network may be simulated based on the changed network behavior. A second simulation trace may thereafter be created based on the simulation of the changed network behavior. The UI may provide a comparison of the first simulation trace to the second simulation trace. A visual indication may be provided of a difference between the first and second simulation traces.
The high and low level elements may be updated dynamically as the simulation progresses. A selection of a particular high level element may result in a display of a further low level element based the selected high level element. A low level breakpoint may be conditioned in the simulation based on a high level characteristic present at some point in the simulation. In an alternate embodiment, in response to a high level breakpoint in the simulation, the UI may depict the low level element based on a portion of the simulation present at a time of the high level breakpoint. In one embodiment, an integrated command line structure is provided wherein both high and low level commands may be entered within a single command line.
The invention is explained in further detail, and by way of example, with reference to the accompanying drawings wherein:
The following are descriptions of illustrative embodiments that when taken in conjunction with the following drawings will demonstrate the above noted features and advantages, as well as further ones. In the following description, for purposes of explanation rather than limitation, illustrative details are set forth such as architecture, interfaces, techniques, etc. However, it will be apparent to those of ordinary skill in the art that other embodiments that depart from these details would still be understood to be within the scope of the appended claims. Moreover, for the purpose of clarity, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the present system.
It should be expressly understood that the drawings are included for illustrative purposes and do not represent the scope of the present system. In the accompanying drawings, like reference numbers in different drawings may designate similar elements. The present system may depict different portions of a simulation including components being simulated, processes, sub-processes, variables, stack data, states of components, etc., all of which may be depicted in various portions of the system in accordance with the present system. Accordingly, for purposes of simplifying a description, the term “element” as utilized herein is intended to include all of the above and other related portions of a simulation that may be advantageously displayed unless explicitly or implicitly stated otherwise.
The system and method described herein address problems in prior art systems. In accordance with the present system, event level and source level debugging tools and information are provided within a user interface (UI). The UI may be provided by an application running on a computer. The visual environment is displayed by the computer on a display device and a user is typically provided with an input device to influence events or images depicted on the display. UI's present visual images which describe various visual metaphors of an operating system, an application, etc. implemented on the computer.
The user typically moves a user-controlled object, such as a cursor or pointer, across a computer screen and onto other displayed objects or screen regions, and then inputs a command to execute a given selection or operation. Other applications or visual environments also may provide user-controlled objects such as a cursor for selection and manipulation of depicted objects in either of a two-dimensional or three-dimensional space.
The user interaction with and manipulation of the computer environment is achieved using any of a variety of types of human-computer interface devices that are connected to the computer controlling the displayed environment. A common interface device for UI's is a mouse, trackball, keyboard, etc. A mouse is moved by a user in a planar workspace to move an object such as a cursor on the two-dimensional display screen in a direct mapping between the position of the user manipulation and the position of the cursor. This is typically known as position control, where the motion of the object directly correlates to motion of the user manipulation.
An example of such a UI is a UI for interaction within a debugging environment to assist a user, such as a network administrator, to debug a network simulation. Through use of the user interface in accordance with the present system, for example provided as a graphical user interface (GUI), use of network debuggers, such as text-based symbolic debuggers, is simplified in that simulated network components may be readily identified and viewed before, during and after the simulation. The present system facilitates access to information about specific high level and low level elements and enhances an ability to pinpoint the cause of incorrect behavior in the simulation.
In accordance with an embodiment, an object browser may be provided that displays network elements in a hierarchical fashion. For example, the hierarchy may be based on topology (e.g., child-of) indicating an interconnection relationship of network elements, such as simulated network components. In another embodiment, the hierarchy may be based on taxonomy (e.g., is-a), for example, indicating a similarity of component types within the hierarchy. In any event, the hierarchical display may enable the user to control the amount of detail provided in the UI view, such as within a simulation trace. For example, the information may be displayed using a tree-view of elements to enable the user to select how much detail to display on each branch. A default setting may show only top level elements. In one embodiment, details of a currently active component (e.g., a node currently processing a data packet) may be displayed to enable a view of a flow of processing throughout a simulation. As may be readily appreciated, other views such as a hierarchical view of the processing flow may also be readily applied.
The hierarchical view provided in
A hierarchical trace of a simulation may also be saved for future reference or comparison to a current trace. In this way, portions of the high and/or low level description may be altered and simulated for comparison to a simulation trace made prior to the alteration. The comparison may be facilitated in accordance with an embodiment of the present system in that a difference between simulations may be depicted utilizing an indication, such as the highlighting 160. Further, elements such as parameters that resulted in a difference in the simulation may also be provided in a portion of the UI to facilitate a distinction being made between simulations. Other visualizations may be provided in accordance with the present system to facilitate identifying differences between two executions of the simulation.
In accordance with an embodiment, the hierarchy 100 may be updated dynamically as components are created or destroyed during the course of the simulation. In addition, the UI in accordance with the present system may be utilized to provide low level information based on depicted high level information. For example, current properties or attributes (low level information) of an element in the hierarchy 100 (high level information) may be displayed as desired. In one embodiment, “right-clicking” on an element depicted in the hierarchy 100 may provide a pop-up menu with a menu selection to display current attributes of the element. In addition, a button (e.g., see button 858 of
Advantageously, the present system enables a display of execution progress and data in a high level context which generally is easier for a user to follow thereby simplifying a debugging process. This allows the display of symbolic information about an element in the context of the high level debugger, without requiring the user to manually perform the conversion from a high level reference (e.g., modeled in C/C++) to a low level representation. So for example one can select a process from the hierarchical view shown in
As such, the present system may operate as a front-end for a low level symbolic debugger that may step through the low level representation of the network simulation, such as assembly code or instructions of a programming language, and display low level data such as the programming variables 330. Accordingly, the present system enables stepping through an execution of one or more processes associated with network elements. In this way, the state of these processes as execution progresses may be reviewed and/or altered.
Conversely, setting a high level constraint such as a breakpoint in the simulation based on a processing element (e.g., when a specific high level event is about to be executed), enables the user to not only stop at the event-level to perform high level operations, but also enables the user to see the source code view of the active process at that instant of processing within the UI 500 provided in accordance with an embodiment of the present system. Accordingly, in the illustrative embodiment shown in the UI 500, the high level view 520 of the simulation (e.g., simulation event) and the low level view (e.g., actual C and/or C++ functions involved in the execution of the event) are provided within a single UI, namely the UI 500.
In another embodiment depicted in
provides more flexibility for identifying elements of the simulation and associated data. The combination of both high level debugging data and low level debugging data within a single UI provides numerous opportunities to readily gain insight into a current simulation without requiring separately entering and exiting high and low level debuggers during the simulation process.
In accordance with an embodiment of the present system, interaction with one portion of the UI 800, such as the first portion 810, may result in a change in displayed information in the same portion and/or a change in displayed information in another portion such as the second portion 820. For example, the indication 860 may be provided to identify an element in the first portion 810 that is currently active. Selection of the button 858 may change a part of the first portion 810, such as an area 870 and/or may change a part of the depicted second portion 820, such as one or more of elements 822, 824, 826. A button 880 may be provided to update an element based on a current simulation event if any of the elements of the UI 800 are not being updated dynamically.
The methods of the present system are particularly suited to be carried out by a computer software program, such program containing modules corresponding to one or more of the individual steps or acts described and/or envisioned by the present system. Such program may of course be embodied in a computer-readable medium, such as an integrated chip, a peripheral device or memory, such as the memory 920 and/or other memory coupled to the processor 910.
The computer-readable medium and/or memory 920 may be any recordable medium (e.g., RAM, ROM, removable memory, CD-ROM, hard drives, DVD, floppy disks or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store and/or transmit information suitable for use with a computer system may be used as the computer-readable medium and/or memory 920.
Additional memories may also be used. The computer-readable medium, the memory 920, and/or any other memories may be long-term, short-term, or a combination of long-term and short-term memories. These memories configure processor 910 to implement the Uls, methods, operational acts, and functions disclosed herein. The memories may be distributed or local and the processor 910, where additional processors may be provided, may also be distributed or may be singular. The memories may be implemented as electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by a processor. With this definition, information on a network is still within memory 920, for instance, because the processor 910 may retrieve the information from the network for operation in accordance with the present system.
The processor 910 is capable of providing control signals and/or performing operations in response to input signals from the user input device 970 and executing instructions stored in the memory 920. The processor 910 may be an application-specific and/or general-use integrated circuit(s). Further, the processor 910 may be a dedicated processor for performing in accordance with the present system and/or may be a general-purpose processor wherein only one of many functions operates for performing in accordance with the present system. The processor 910 may operate utilizing a program portion, multiple program segments, and/or may be a hardware device utilizing a dedicated or multi-purpose integrated circuit.
Of course, it is to be appreciated that any one of the above embodiments or processes may be combined with one or more other embodiments or processes or be separated in accordance with the present system. As should be clear, the present system enables a user to model network operation including network communications such as simulating a large number of elements with properties and behavior. The present system further provides a ready system for debugging the simulation by providing a UI for both providing ready access to both high level and low level debugging information related to these elements during a simulation. The present system provides a graphical environment that simplifies the use of high and low level debuggers, such as text-based symbolic debuggers, in the context of the network elements and thereby, facilitates access to information about specific elements and enhances the ability to debug incorrect behavior in the simulation.
Finally, the above-discussion is intended to be merely illustrative of the present system and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments. Thus, while the present system has been described with reference to exemplary embodiments, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the broader and intended spirit and scope of the present system as set forth in the claims that follow. In addition, the section headings included herein are intended to facilitate a review but are not intended to limit the scope of the present system. Accordingly, the specification and drawings are to be regarded in an illustrative manner and are not intended to limit the scope of the appended claims.
In interpreting the appended claims, it should be understood that:
a) the word “comprising” does not exclude the presence of other elements or acts than those listed in a given claim;
b) the word “a” or “an” preceding an element does not exclude the presence of a plurality of such elements;
c) any reference signs in the claims do not limit their scope;
d) several “means” may be represented by the same item or hardware or software implemented structure or function;
e) any of the disclosed elements may be comprised of hardware portions (e.g., including discrete and integrated electronic circuitry), software portions (e.g., computer programming), and any combination thereof;
f) hardware portions may be comprised of one or both of analog and digital portions;
g) any of the disclosed devices or portions thereof may be combined together or separated into further portions unless specifically stated otherwise;
h) no specific sequence of acts or steps is intended to be required unless specifically indicated; and
i) the term “plurality of” an element includes two or more of the claimed element, and does not imply any particular range of number of elements; that is, a plurality of elements can be as few as two elements, and can include an immeasurable number of elements.
This application claims the benefit of U.S. Provisional Patent Application No. 60/709,777, filed Aug. 19, 2005.
| Number | Date | Country | |
|---|---|---|---|
| 60709777 | Aug 2005 | US |
