Abstract: A computer program product and a method for providing a graphical representation of a software, the method includes: receiving semantic concern defining information; populating at least one semantic concern, in response to the received semantic concern defining information; and associating between multiple elements in response to semantic relation information, if semantic concern relation information was previously received.

Abstract: A computer program product and a method for providing a graphical representation of a software, the method includes: receiving semantic concern defining information; populating at least one semantic concern, in response to the received semantic concern defining information; and associating between multiple elements in response to semantic relation information, if semantic concern relation information was previously received.

Abstract: A test coverage tool provides output that identifies differences between the actual coverage provided by a test suite run on a program under test and the coverage criteria (e.g., the coverage criteria required by the test/development team management). The output from the test coverage tool is generated in the same language that was used to write the coverage criteria that are input to an automated test generator to create the test cases which form the test suite. As a result, the output from the coverage tool can be input back into the automated test generator to cause the generator to revise the test cases to correct the inadequacies. This allows iterative refinement of the test suite automatically, enabling automated test generation to be more effectively and efficiently used with more complex software and more complex test generation inputs.

Abstract: A meeting negotiation system provides a new approach to scheduling events by negotiating schedules while preserving privacy through a shared representation that separates the meeting negotiation from the meeting invitation. The negotiation system integrates all scheduling-related information such as times users can meet, location, etc. and reduces dependency on designations of time as free or busy by a potential meeting attendee. Consequently, the negotiation system enables time preferences richer than just free or busy, allowing potential meeting attendees to designate preference in addition to time available. The negotiation system supports annotations and comments as a discussion mechanism, giving feedback to the meeting scheduler before the meeting invitation is issued. Possible times provided for the meeting are provided in the form of a bounded negotiation; participants may select the best time for them to attend a meeting from the bounded negotiation.

Abstract: Provided are an execution monitoring tool, a method and a computer program product for monitoring a message processing program or system. The execution monitoring tool identifies locations within the message processing program corresponding to a predefined set of execution progress stages, and inserts execution progress report generator components at these locations. Execution progress reports (including a representation of the message contents and structure) are then sent to the execution monitoring controller which maps the report data to its own representation of the program to determine the current position within an execution program. The message contents and structure, as well as the structure of the program and the current execution position, are displayed during execution on a test system. The execution reports include the current execution status as well as the position within the execution flow.

Abstract: Provided are an execution monitoring tool, a method and a computer program product for monitoring execution of an hierarchical visual program. Execution progress reports are sent to an execution monitoring controller which maps the report data to its own representation of the hierarchical program to determine the current position within an execution program. The hierarchical structure of the program and the current execution position are displayed during execution on a test system. The execution monitoring controller maintains an hierarchical representation of the visual program's structure, builds an execution stack from the execution progress reports, and compares the received reports with the hierarchical representation to determine a current execution position. The execution reports include the current execution status as well as the position within the execution flow.

Abstract: The present invention allows tests generated by multiple test generators to be merged into a comprehensive test specification, allowing multiple test generators to work together as a single unit, and allowing tests from multiple test generators to be combined to achieve a single defined testing goal.

Abstract: A test coverage tool provides output that identifies differences between the actual coverage provided by a test suite run on a program under test and the coverage criteria (e.g., the coverage criteria required by the test/development team management). The output from the test coverage tool is generated in the same language that was used to write the coverage criteria that are input to an automated test generator to create the test cases which form the test suite. As a result, the output from the coverage tool can be input back into the automated test generator to cause the generator to revise the test cases to correct the inadequacies. This allows iterative refinement of the test suite automatically, enabling automated test generation to be more effectively and efficiently used with more complex software and more complex test generation inputs.

Abstract: Provided are an execution monitoring tool, a method and a computer program product for monitoring execution of an hierarchical visual program. Execution progress reports are sent to an execution monitoring controller which maps the report data to its own representation of the hierarchical program to determine the current position within an execution program. The hierarchical structure of the program and the current execution position are displayed during execution on a test system. The execution monitoring controller maintains an hierarchical representation of the visual program's structure, builds an execution stack from the execution progress reports, and compares the received reports with the hierarchical representation to determine a current execution position. The execution reports include the current execution status as well as the position within the execution flow.

Abstract: Provided are an execution monitoring tool, a method and a computer program product for monitoring a message processing program or system. The execution monitoring tool identifies locations within the message processing program corresponding to a predefined set of execution progress stages, and inserts execution progress report generator components at these locations. Execution progress reports (including a representation of the message contents and structure) are then sent to the execution monitoring controller which maps the report data to its own representation of the program to determine the current position within an execution program. The message contents and structure, as well as the structure of the program and the current execution position, are displayed during execution on a test system. The execution reports include the current execution status as well as the position within the execution flow.

Abstract: A technique, system, and computer program for presenting test coverage metrics in a visual programming environment. The information is presented in the same general visual manner in which a visual programmer creates a visual program. A number of alternative presentation styles are defined whereby the visual program is augmented to indicate test coverage status. For example, when displaying connections, one color may be used when displaying a connection to indicate that it has been covered, while a different color is used for connections that were not covered. Or, different line styles (such as solid versus dashed, or different degrees of line thickness) may be used to represent the same information. Alternatively, the test coverage status may be indicated by annotating the graphical representation of the visual program with text (such as “covered” or “not covered”).

Abstract: A method, system, and computer program for presenting runtime performance data for analysis in a visual programming environment. The performance data is presented in substantially the same manner in which a visual programmer creates a visual program. A number of alternative presentation styles are defined whereby the visual program is augmented to indicate performance data. For example, when displaying connections, one color may be used when displaying a connection to indicate it has been executed a relatively high number of times, while a different color (or a different hue of the first color) is used for connections that were executed a relatively low number of times. Or, different line styles may be used (such as different degrees of line thickness, or solid lines compared to lines comprised of dashes of varying length) may be used to represent the same information.

Abstract: A method, system, and computer program for providing test coverage metrics in a visual programming environment. A test coverage model for visual programming is defined, which accounts for the specialized nature of visual programming, and the metrics are based on this model. The metrics are expressed in terms of elements familiar to the visual programmer, as opposed to using source code metrics. In a preferred embodiment, these elements comprise events, actions, connections, and attributes. The code implementing a visual program is instrumented according to this model, and test coverage information is gathered as the instrumented program executes.

Abstract: A method, system, and computer program for providing runtime performance analysis in a visual programming environment. A performance data collection technique for visual programming is defined, which accounts for the specialized nature of visual programming, and the analysis is based on this collected data. The performance data is expressed in terms of elements familiar to the visual programmer, as opposed to using a source code approach. In a preferred embodiment, these elements comprise events, actions, connections, and attributes. The code implementing a visual program is instrumented according to this performance data collection technique, and performance information is gathered as the instrumented program executes. Preferably, the information gathered comprises execution counts and elapsed time per element.