Scenario driven debugging: Language and tool support

Debugging is the activity of identifying and fixing the software faults that cause a software failure. To identify the culprit software faults, software developers need to observe the internal behaviors of the software system related to the erroneous program task and comparing the observation to the desired behavioral model of the software system.;Traditionally, software developers use source-level breakpoint, print-statement or assertions to observe the internal behaviors of the software system and compare the observations against desired behavior models. These techniques, however, are less effective for large scale object oriented (OO) software systems. In OO software systems, program tasks are implemented as sequences of interactions between different objects. A class can be instantiated into multiple objects, each of which may participate in implementing different program tasks. Source-level breakpoints, print-statements, and assertions cannot distinguish different objects instantiated from the same class. Moreover, they cannot correlate different object interactions in an object interaction sequence. To check the OO system's runtime behaviors related to a program task, software developers must manually examine the execution trace, identify the interactions among a particular group of objects that impelement the program task, and compare these identified object interactions with the desired object interaction scenarios. This manual checking is often painstaking and error prone.;We proposed the scenario driven debugging for effectively debugging large scale OO software systems. In the scenario driven debugging, software developers use object interaction scenarios as a mean to observe the check the program executions automatically. The desired object interaction scenario for implementing a program task is specified as a runtime checkable scenario specification, which defines the the desired order of the object interactions of an object interaction scenario and the data-related properties that must be satisfied at different steps of the object interaction scenario. During debugging, the scenario specification is compiled into runtime execution monitors for automatically monitoring and checking the interactions between specific objects of the software system. The checking results generated by these runtime execution monitors can be used to narrow or identify software faults, or to reject debugging hypotheses.;We found that the existing behavior modeling languages used in testing and runtime monitoring are not suitable for specifying runtime checkable scenario models. To support the scenario driven debugging, we introduce a formal behavior modeling language---Behavior View Diagrams (BVD)---and develop a prototype debugger---SDebug---that can use BVD specifications during debugging. BVD inherits a number of control flow constructs from UML2 sequence diagrams for specifying complex object interaction scenarios with loops, alternatives, and concurrencies. BVD extends UML2 sequence diagrams with a number of mechanisms for identifying runtime objects and executing automated checks for data-related properties. Software developers may define automated monitoring and checking actions, using Python statements, to extract the value of program variables or message arguments at specific steps, and use them to check the the values of other program variables or message arguments at later steps of the the scenario. The prototype debugger, SDebug, allows software developers to generate runtime execution monitors from BVD specifications and bind them to specific objects to monitor their interactions. SDebug also allows software developers to stop the program execution at particular object interactions in the scenario for interactive inspection.;We formally define the syntax and semantics of BVD. The syntax of BVD is defined as a UML profile so that any UML editor supporting UML profiles can be used to construct BVD specifications. The formal semantics of BVD is defined as two coordinating parts: The ordering semantics of a BVD specification is defined as a concurrency calculus formula. The data-manipulation semantics (e.g., identifying runtime objects or interpreting property-checking statements) of the BVD specification is defined as a Python program. This bipartite approach allows us to integrate a complex event-ordering semantics, like the one of UML2 sequence diagrams, with a complex data-manipulation semantics, like the one of Python. We believe that this semantic defining approach can be adopted to define the formal semantics of other similar languages, such as message sequence charts or live sequence charts.;In summary, this thesis research introduces BVD and SDebug that enable the scenario driven debugging. The applications of BVD and SDebug, however, is not restricted to debugging OO programs only. With minor adjustment, BVD and SDebug can be used to monitor and check the behaviors of concurrent processes. BVD specifications can be weaved into existing software systems for testing, runtime error detection and runtime error prevention. BVD specifications can also be used to test design artifacts at early stages of the software developement procss.