Designing the whyline

Doing so on Pac to increase his visibility. This supports exploration of not happen, and provides the answer shown in Figure 4. The runtime data. When Ellen moves the cursor over an action, actions included are only those that prevented Pac from the action and the code that caused it become selected, resizing: the predicate whose expression was false and the supporting diagnosis and repair. These features allow Ellen actions that defined the properties used by the expression.

This exposes hidden dependencies between actions likely contain the fault. Figure 4. This question from being reached, and the why did slice on each. The button Interrogative Debugging interface, so we had general prevents the hard mental operation of recalling facts questions about its usability and impact: determined earlier in debugging activity.

We will refer to the first an unnecessary search for non-existent errors. The With study used an Alice programs are implemented internally using a control iterative design methodology: observations from user flow graph CFG , where expressions are represented as session were used to fix usability problems and inform the data flow graphs attached to CFG nodes. These graphs are design of features for successive sessions.

Programming history is used to traverse the execution history based on experience ranged from beginning Visual Basic to the location of the time cursor.

The four participants in the We use static [20] and dynamic [22] analysis to support: Without study will be referred to as C1-C4, and the five in 1. Creation of a database of all changes to output all the With study as E1-E5. Participants were given the layout in Figure 1 and 90 structure, and for answering false propositions. Generation of precise dynamic slices on the code in 1. Pac must always move.

Generation of all potential definitions and uses of 2. Ghost must move in random directions half of the properties from static DFGs, used for constructing time and directly towards Pac the other half. We do not support 3. If Ghost is chasing and touches Pac, Pac must flatten continuous number spaces i.

If Pac eats the big dot, ghost must run away for 5 seconds, then return to chasing. We used Alice-specific design heuristics to construct 6. If Pac eats all of the dots, Ghost must stop and Pac program slices. For example, for each question we had to must hop indefinitely.

Because our observations showed that questions were specifications to be six distinct tasks, since the code asked immediately after failures, we sliced on the most necessary to accomplish them were only related by the recent execution of a program statement.

Participants were also expressions. Including more runtime actions would have videotaped while they worked, for later analysis.

In generalizing why did questions, and programmers rarely asked invariant our experiences, there are many issues to consider. These have implications for the Table 3 describes six identical debugging scenarios that design of future ID interfaces. When E1 first used the Whyline, he hypothesize and diagnose by inspecting and rewriting code.

Identical debugging scenarios in the With and Without studies. I need an event to start it. That must be dot2". In our user studies, using the latest execution of the queried Usability issues were also found in sessions 4 and 5, but not statement was sufficient. In more complicated Alice of the same magnitude as in the first three. One possible interaction would allow programmers to further specify their questions What was Helpful?

This may require domain- question menu. Observations confirmed our hypothesis that specific heuristics to design effectively. Can you make this for Java? We plan to further refine the Whyline and formally investigate these findings.

There are many open questions in designing ID tools for other languages. For example, for a given language and Similarly, relating code to runtime actions interactively programming task, what output will programmers want to with the time cursor and visual highlighting helped with ask about?

In a modern code base, output might be diagnosis and repair activities, as predicted. Had this numerical, message-based, or simply the execution of a relationship not been explicitly visualized, more text would stub of code. One way to automatically determine the have been needed to denote what caused the runtime action, granularity and nature of such output would be to search for decreasing visibility, and programmers would have had to previous executions of code in recently modified source manually search for the code responsible.

Even still, the sheer number of predicted. This seemed to be because the visualization possible questions would be overwhelming. Future work acted as an external memory aid to help programmers must devise methods for selecting a small set of simulate runtime execution. In the Without study, contextually relevant questions from all possible questions.

Even with Making the Whyline More Helpful these methods, failures that are difficult to reproduce or Currently, questions about complex Boolean and numerical take significant time to reproduce will pose significant expressions give equally complex answers.

This is because challenges. We Reichwein et al. For more complex paths as correct or incorrect, which feeds into a software, there would be a host of visualization and visualization of which computations may be faulty [16]. One Programmers often needed to inspect the internals of Alice approach might be to use semantic differencing methods primitives.

People and computers v, A. Sutcliffe and L. Macaulay, Lencevicius et al. However, it forces programmers to [9] Green, T. Briggs et al. Journal of Visual Languages timeline [3] for debugging distributed Ada programs.

Their and Computing, 7, , ID interfaces have no such requirement. An observational study. International Journal of Human-Computer Studies, 54 2 , , Development and evaluation We have discussed a new debugging paradigm, called of a model of programming errors, IEEE Symposia on Interrogative Debugging, and a new debugging interface Human-Centric Computing Languages and called the Whyline. Our user studies demonstrate that the Journal of Automated Software Engineering, 10 1 , Whyline can dramatically reduce debugging time, , Communications of the ACM, 40 4 , , Program We thank the programmers in our user studies for their understanding behavior during debugging of large participation.

Opinions, findings and conclusions or [16] Reichwein, J. Slicing recommendations expressed in this material are those of the spreadsheets: An integrated methodology for author s and do not necessarily reflect those of the NSF. A Austin, Texas, Journal of Visual Languages and [2] Blackwell, A. Applying attention Computing, 14, , Software Environments, , Arlington, VA, National Institute of strategy.

Display-based problem solving strategies [20] Tip, F. Isolating cause-effect chains from computer [6] Gestwicki, P. Environments, , Arlington, VA, Either Ellen did not notice that Pac ate the big dot, or she forgot about the dependency.

When Ellen played the world, Alice hid the code and expanded the worldview and property panel, as seen in Figure 1. This relates property values to program output. Ellen presses the why button after noticing that Pac did not shrink, and a menu appears with the items why did and why didn't, as in Figure 2.

The submenus contain the objects in the world that were or could have been affected. The menu supports exploration and diagnosis by increasing visibility and decreasing the viscosity of considering them. Because Ellen expected Pac to resize after touching the ghost, she selects why didn't and scans the property changes and animations that could have happened.

When she hovers the mouse over a menu item, the code that caused the output in question is highlighted and centered in the code area see Figure 2. This supports diagnosis by exposing hidden dependencies between the failure and the code that might be responsible for it. This also avoids premature commitment in diagnosis by showing the subject of the question without requiring that the question be asked.

Ellen asks why didn't Pac resize. The Whyline answers the question by analyzing the runtime actions that did and did not happen, and provides the answer shown in Figure 3. The actions included are only those that prevented Pac from resizing: the predicate whose expression was false and the actions that defined the properties used by the expression.

By excluding unrelated actions, we support observation and hypothesizing by increasing the visibility of the actions that likely contain the fault. To support diagnosis, the names and colors are the same as the code that caused them. This improves consistency and closeness of mapping with code. Figure 3. The Whyline reveals that Pac didn't resize because the big dot was eaten. The arrows represent data and control flow causality.

Predicate arrows are labeled true or false and dataflow arrows are labeled with the data used by the action they point to. The arrows support progressive evaluation, and thus hypothesizing, by helping Ellen follow the runtime s computation and control flow. Along the x-axis is event-relative time, improving the closeness of mapping to the time-based Alice runtime system.

Along the y-axis are event threads: this allows co-occurring events to be shown, supporting juxtaposibility. Ellen interacts with the timeline by dragging the time cursor the vertical black line in Figure 3. Doing so changes all properties to their values at the time represented by the time s location.

This supports exploration of runtime data. When Ellen moves the cursor over an action, the action and the code that caused it become selected, supporting diagnosis and repair.

These features allow Ellen to rewind, fast-forward, and the execution history, receiving immediate feedback about the state of the world.