Patent Application
20080209405
Computer applications are commonly developed by application developers using a typical development environment. Such a development environment generally includes a text editor, a compiler, and a debugger. The application developer uses the text editor to enter source code written in a development language such as C, C++, or C#. The compiler translates the computer source code to object code. Object code may be code or instructions directly executable by the computer's central processing unit. The object code may require further standard software modules to be linked in order to create an executable application.
During application development, errors, also known as bugs, may be introduced into the source code by the application developer. The application developer may wish to discover the source of the errors and correct the errors through a process known as debugging the source code.
The process of debugging begins with setting the compiler to produce debug object code during compilation. Such debug object code may have embedded symbols or other markers indicating an equivalency between a line of source code and object code. Additional information related to the symbols and the source code may be stored in an external file.
The debugger may then control execution of the compiled debug object code and the application developer may then pause execution of the compiled debug object code, step through the source code corresponding to the compiled debug object code, inspect the values of variables, and the like. The debugger allows the application developer to view and inspect each line of source code as it is executed giving the application developer an opportunity to determine the cause of bugs or errors.
This process of debugging is commonly used with textual programming languages such as C, C++, or C#. Textual programming languages are written in text and are debugged using textual debuggers such as that described above. In contrast, visual programming languages (VPLs) are programmed using a graphical user interface. An application developer creates computer programs or applications in a visual programming language by manipulating user interface elements corresponding to program elements using a graphical user interface (GUI).
Such program elements may have been developed by an application developer in a textual programming language for deployment and execution in an application environment such as the Microsoft Decentralized Software Services (DSS) environment. The application environment typically routes messages between program elements, evaluates the program elements as messages arrive at the specified input of the program element, sends messages from the program elements as a result of the evaluation of the program elements, and the like.
During application development, the program elements are available for a user to manipulate using a GUI. The GUI may be used by a user to draw the logic and dataflow of an application such that the resulting diagram resembles a conventional flowchart. However, in contrast to a conventional flowchart, the diagram does not abstractly represent the application and instead completely describes the functioning of the application.
Errors or bugs may also be introduced into an application created in a visual programming language. However, a typical debugger designed for a textual programming language may not debug applications created in a visual programming language environment due to the visual nature of the development language.
The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
The present example provides distributed debugging services for a visual programming language. In one implementation, a debugging engine is disposed within a runtime execution environment. The execution environment and debugging engine provide the debugging state and debugging methods to one or more debugger user interfaces either connected locally or connected on a network.
The visual programming language debugging engine may further provide the debugging state and a set of debugging methods to the user interfaces. The user interfaces may then display the current debugging state and send network messages to call the debugging methods on the visual programming language debugging engine. The user interfaces may also poll the visual programming language debugging engine at regular intervals for debugging state updates or may subscribe to the debugging state via network services offered by the execution environment.
Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
Like reference numerals are used to designate like parts in the accompanying drawings.
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
Although the present examples are described and illustrated herein as being implemented in a distributed debugging system for a visual programming language, the system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of distributed debugging system for a visual programming language.
Although not required, embodiments of the invention will be described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.
In other embodiments, device 100 may include additional features and/or functionality. For example, device 100 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in
The term “computer readable media” as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 104 and storage 108 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 100. Any such computer storage media may be part of device 100.
Device 100 may also include communication connection(s) 112 that allow device 100 to communicate with other devices. Communication connection(s) 112 may include, but is not limited to, a modem, a Network Interface Card (NIC), or other interfaces for connecting computing device 100 to other computing devices. Communication connection(s) 112 may include a wired connection or a wireless connection. Communication connection(s) 112 may transmit and/or receive communication media.
Communication media typically embodies computer readable instructions or other data in a “modulated data signal” such as a carrier wave or other transport mechanism and includes any information delivery media. The term “computer readable media” may include communication media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media.
Device 100 may include input device(s) 114 such as keyboard, mouse, pen, voice input device, touch input device, infra-red cameras, video input devices, and/or any other input device. Output device(s) 116 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 100. Input device(s) 114 and output device(s) 116 may be connected to device 100 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 114 or output device(s) 116 for computing device 100.
Components of computing device 100 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 100 may be interconnected by a network. For example, memory 104 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.
Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 130 accessible via network 120 may store computer readable instructions to implement one or more embodiments of the invention. Computing device 100 may access computing device 130 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 100 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 100 and some at computing device 130. Those skilled in the art will also realize that all or a portion of the computer readable instructions may be carried out by a dedicated circuit, such as a Digital Signal Processor (DSP), programmable logic array, and the like.
To provide a better understanding of the structure and functioning of a visual programming language,
The computer program described by the example diagram 200 initializes a variable and sets the value of the variable to 1, tests the variable to determine if the variable is equivalent to 10, and if not, increments the variable. If the variable is equivalent to 10, a string is set to “counted to 10” and is passed to a program element functioning to display an alert dialog box displaying the string.
Within the example diagram 200, the example program element 202 is a “data” program element. A data program element creates a data value and sends the data value to the output pin. In the example program element 202, the data is the value “1”. The output pin of the example program element 202 is connected to the input pin of the example program element 204. The example program element 204 represents a variable named “Test” within the example diagram 200. The arrow representing the connection between the program element 202 and the program element 204 includes the word “Set” to indicate that the arrow is connected to the “set data” pin supported by the program element 204. Such a connection indicates that the variable named “Test” should be set to the value “1”.
The output pin of the program element 204 is connected to one input pin on the example program element 206. The function of the program element 206 is to “merge”, or, pass the value of each input pin untouched. The output pin of the program element 206 is connected to the input pin of the example program element 208. The function of the program element 208 is to perform an “if” comparison. The result of the “if” comparison is sent along the output pin, and, in this example, the output pin of the “if” comparison is connected to the input pin of the example program element 214. The program element 208 also includes and “else” statement that will execute should the “if” statement fail. The “else” statement includes a corresponding output pin. In this example, the output pin of the “else” statement is connected to the input pin of the example program element 210.
The function of the program element 210 is to “calculate” the current value of the variable “Test” and increment the value by 1. The output pin of the program element 210 is connected to the input pin of the example program element 212. The example program element 212 functions similarly to the example program element 204 in that the function of the example program element 212 is to set the value of the variable “Test” to the value received at the input pin. The output pin of the example program element 212 is connected to an input pin of the program element 206 so the value may be “merged”, or, passed unchanged.
Program execution ends when the “if” condition tested at the program element 208 fails and program flow continues along the output pin connected to the “else” condition to the input pin of the program element 214. The program element 214 functions similarly to the example program element 202, in that the program element 214 functions to create a data value and sends the data value including the string “Counted to 10” to the output pin of program element 214.
The output pin of the program element 214 is connected to the input pin of the example program element 216. In this example, the input pin of the program element 216 has been set to “AlertDialog” to indicate that the program element 216 should display a dialog box with the style “AlertDialog” and the text received from the output pin of the program element 214. Program execution ends at this point.
The example diagram 200 is illustrated as a standalone application; however, such an example diagram 200 may exist as a discreet unit of functionality. That is, the example diagram 200 may be considered to be a program element including input pin and output pin and may be used as part of a larger visual programming application.
Turning now to
For illustrative purposes, the execution environment 310 includes an example visual programming language diagram 306. Such a visual programming language diagram 306 may be implemented as described with regard to
The debugging engine 302 is communicatively coupled to a network services component 308. In turn, network debugger user interfaces 320 and 325 and local debugger user interface 340 are each communicatively coupled to the network services component 308. The debugging engine 302 may send the debugging state and other associated information to any of the network debugger user interfaces 320 and 325 and the local debugger user interface 340 via the network services component 308. Conversely, any of the network debugger user interfaces 320 and 325 and local debugger user interface 340 may execute methods to modify the debugging state on the debugging engine 302 via the network services component 308. Each of the debugger user interfaces 320, 330, and 340 implements a debugging method 325 that will be discussed in further detail in the discussion of
The network services component 308 provides network services such as web services, protocol services such as the hypertext transport protocol (HTTP), and the like. The network services component 308 also provides functionality for exchanging data messages using a communication protocol such as the simple object access protocol (SOAP), the decentralized software services protocol (DSSP) from Microsoft Corporation, and the like. In addition, the execution environment 310 and the debugging engine 302 may provide a public interface to local and network clients via the network services component 308.
The execution environment 310 executes visual programming language applications. The execution environment 310 receives an execution model of the application from a visual programming language editor or other computer application capable of creating and deploying a visual programming language application. An execution model may include, but is not limited to including, a list of program elements, connections between program elements, a description of the visual programming language application, information regarding other computer software services with which the visual programming language application communicates, and the like. Such execution model elements may be represented by the diagram 306 and program elements 304 and 305.
When the visual programming language application was created by the visual programming language editor, the visual programming language editor may have also sent the visual representation of the diagram and associated data 307. Such a graphical visual representation may be an image file such as a bitmap, or the like. Such associated data may include one or more unique identifiers representing one or more corresponding program elements. Such associated may include a mapping between the unique identifiers representing program elements in a visual programming language application and the graphical visual representation of the visual programming language application. Such a mapping includes a unique identifier of the program elements that may be included in the visual programming language application and the location or identify of each program element in the graphical visual representation. Such a location may be coordinates, a bounding box, or the like.
The debugging engine 302 may control and/or publish the debugging state of one or more visual programming language applications executing in the execution environment 310. The debugging engine 302 may be completely integrated into the execution environment 310 such that the debugging engine 302 is able to manipulate and inspect the execution of applications, modules, and the like within the execution environment 310. The public interface of the debugging engine 302 may include data fields including information regarding the current mode of execution, a queue of pending program elements to be executed, an identifier corresponding to the last executed program element, a list of breakpoints, and the like.
The public interface of the debugging engine 302 may further include methods providing functionality to step through the pending program elements in the queue, execute all pending program elements in the queue, halt execution of the pending program elements in the queue, execute pending program elements in the queue at a predetermined rate, set an execution breakpoint, clear an execution breakpoint, enable or disable a breakpoint, or the like. Debugger user interfaces 320, 330, and 340 may utilize functionality provided by either of the network services component 308 or the execution environment 310 to subscribe to the debugging engine and receive data from the data fields and execute methods to control the debugging engine 302.
Each of the debugger user interfaces 320, 330, and 340 may be a world wide web browser such as Microsoft Internet Explorer©. In an alternative embodiment, each of the debugger user interfaces 320, 330, and 340 may be a visual programming language editor. The debugging engine 302 may send a link or path to the a visual representation of the diagram and associated data 307 corresponding to the visual programming language diagram 306 or may be a link or path to the visual programming language diagram 306 itself. The debugging engine 302 may then send the debugging state as formatted data, for example, data formatted in the extensible markup language (XML). The debugging engine 302 may further send presentation information such as extensible stylesheet language (XSLT) instructions corresponding to the debug state. Such presentation information includes instructions to instantiate the debugger user interface on any of the debugger user interfaces 320, 330, and 340.
The presentation information includes instructions allowing the instantiated user interface to interpret the visual representation of the diagram and associated data 307. For example, the associated data of the visual representation of the diagram and associated data 307 may include data indicating the location of one or more program elements and the connections between the program elements. The presentation information may include instructions to properly interpret such locations and draw bounding boxes or the like around a currently executing program element. In the example where the debugger user interface is a visual programming language editor, the visual programming language editor may include instructions to properly interpret such locations and draw bounding boxes or the like around a currently executing program element.
The instantiated user interface provides a view of the visual programming language diagram 306 and user interface elements that allow a user to interact with the debugging engine 302. In one example, the instantiated user interface highlights, or draws a bounding box around the program element that will be executed next in the queue. The user may then interact with the user to interface to step through execution, break execution, set a breakpoint, and the like.
Each of the debugger user interfaces 320, 330, and 340 may connect to the debugging engine 302 concurrently. That is, each of the debugger user interfaces 320, 330, and 340 may call debugging methods implemented on the debugging engine 302 and the results of such method calls will be sent back to each of the debugger user interfaces 320, 330, and 340 in the form of the debugging state. In this way, debugging may be distributed amongst each of the debugger user interfaces 320, 330, and 340.
The instantiated user interface may subscribe to the debugging state published by the debugging engine 302 via the network services component 308. In an alternative embodiment, the instantiated user interface may poll the debugging engine 302 at a predetermined interval via the network services component 308. The debugging engine 302 may provide data representing the complete debugging state or may provide a reduced set of data representing only the change of the debugging state since the debugging state was last sent.
Turning now to
For example, the debugging engine 302 may include a debugging state 400 and a set of debugging methods 450. Each of the debugging state 400 and the debugging methods 450 may be manipulated by a client via runtime network services 454 implemented by the debugging engine 302. For example, if the debugging engine 302 is disposed in the Microsoft Robotics Studio runtime services system, the debugging engine 302 may implement each of the debugging state 400 and the debugging methods 450 as a service contract provided by the runtime network services 454.
The debugging state 400 may include the current mode 402 of the debugging engine 302, a queue 404 of program elements pending execution, and identifier of the last 408 program element executed, and a list of one or more breakpoints 410. The mode may indicate that the debugger is currently stepping through a visual programming language application, executing a visual programming language at full speed, executing a visual programming language application at a speed other than full speed, not debugging any visual programming language at all, and the like.
The debugging engine 302 also includes a set of public methods 450. For example, the debugging engine 302 may include a step method 412 that executes the first program element in the queue 404. The run method 414 executes all program elements in the queue 404, sets the current mode 402 to “running”. The break method 416 pauses execution of pending program elements in the queue 404 and sets the current mode 402 to “stepping”. The slow method 418 causes the debugging engine 302 to execute pending program elements in the queue 404 at a predetermined rate and sets the current mode 402 to “slow”.
The set breakpoint method 420 inserts a breakpoint that will pause execution of the application when the breakpoint is encountered in the queue 404. The clear breakpoint method 422 removes a breakpoint that has been inserted using the set breakpoint method 420. The enable breakpoint method 424 either enables a disabled breakpoint or enables a disabled breakpoint in the queue 402.
Block 502 refers to an operation in a connection is established to the visual programming language that is being debugged. For example, a connection may be established by following a uniform resource identifier (URI) link to network services executing a visual programming language application. Flow continues to block 506.
Block 506 refers to an operation in which the current debugging state and any presentation logic is received. The current debugging state may include a link or path to the visual programming language application diagram of the application being debugged. Flow continues to block 508.
Block 508 refers to an operation in which the presentation logic is used to instantiate the user interface using the current debugging state received at block 506. Flow continues to block 510.
Block 510 refers to an operation in which the server is polled for the current debugging state at a predetermined time interval. In an alternative embodiment, a subscription may have been established with the server and such polling is unnecessary as the current debugging state is sent when necessary. Flow continues to block 512.
Block 512 refers to a decision to determine if the current debugging session has ended. The current debugging session may end in response to the last pending program element being executed, the user explicitly ending debugging, or any other operation that results in the termination of debugging. In response to a positive determination, flow continues on to block 514. In response to a negative determination, flow returns to block 510.
Block 514 refers to an operation in which the debugging method 325 terminates execution.
