Specific Breakpoints: Use Cases and Requirements
In a task
focused IDE, one of the aspects of development that can be specific to a given task are
debugging breakpoints and watches. In a typical application space, there might be literally hundreds of
breakpoints and watches configured and enabled, but when you start focusing the IDE around a certain
task, the number of breakpoints and watches that
are actually USEFUL in the context of the task is
limited. It is thus seen as a great efficiency gain to be able to only enable breakpoints that are specific to
the task currently being worked on. The design question is thus how much control to give the
around defining which breakpoints/watches are task
specific, which aren’t, and how to deal with
breakpoints/watches when the task is made active.
Definition of Terms
a unit of work
Out of a list of tasks, the one that is currently being worked on.
Everything in the IDE that supports work on the task: Files, details, the physical state of
: Not pertaining to a specific task.
: Pertaining to a
: Pertaining to two or more tasks.
: To set up a breakpoint to fire during debugging
: To set up a breakpoint NOT to fire during debugging
: To specify a new breakpoint on a line of code.
Focused Breakpoint Sp
If you look at the overall IDE
level landscape of breakpoints, and then apply a task
to them, you get something that looks like this:
In this Venn diagram, you have some global breakpoints, that is, breakpoints that were set whe
specific task was active. You have task
specific breakpoints, i.e. those that were set when a task WAS
active. And, possibly, you have shared breakpoints, i.e. a breakpoint that is relevant to two or more
tasks (e.g. BP13). For each of these, you h
ave a state: enabled or disabled, as shown by the checkboxes.
Now, let’s say we make a task active, and while it is, we set a few breakpoints and do some debugging.
As we add breakpoints, they are added to the Task Context. Based on the task, the develop
working on the task, may or may not disable these breakpoints, and might later re
enabled them. The
next day, the developer comes back to their task. What do they expect to see, in terms of what
breakpoints are enabled?
Is it something like thi
In this example, the only breakpoints that are enabled are those that were set while the task was active.
All others are “off”.
Or is it like this?:
In this example, all of the task
specific breakpoints are enabled, but so are the generic/global
only ones that are disabled are those that are explicitly related to other tasks, and NOT to the active
The underlying use cases are then:
I only want to enable the breakpoints that I set while working on this task.
I only want t
o enable the breakpoints that I set while working on this task, as well as any global
I only want to enable the breakpoints that I set while working on this task, AND I want to be able
to explicitly pick other breakpoints that I know are of pe
rtinence to the task at hand, whether or
not I actually set them while working on the task.
And one more:
There are some breakpoints I might set during a task that aren’t really task
specific, and I want
to be able to kick them out of the context and make
We need to have the ability to track breakpoints that are set while a task is active.
We need to have the ability to track the enabled/disabled state of a task
We need to give the user the option of whether or
not to restore the enabled/disabled state of
specific breakpoints, or instead just enable all of them, when a task is made active.
We need to have the ability to indicate that a breakpoint that we have in the task context is
really NOT task
cific, that is, remove it from the task context
list and make it generic/global
(or, if it
associated with other tasks, task
specific to those)
We need to have the ability to manually add breakpoints to the task context from elsewhere in
tion space that weren’t set during the task being active.
Specifically, these are
breakpoints that are already
associated with other tasks.
We need to have the ability to, when activating a task, make all other breakpoints disabled.
Once we have the abili
ty to enable/disable a watch, the same logic should apply to watches.
With relation to the Breakpoints area of the Task Context window, there should be a table
very similar, if
not identical, to the main IDE’s Breakpoints window
That table should have Add,
from Context, and Clear
toolbar icons available. Add will bring up a
popup breakpoint picker with a list of all breakpoints in the application space, except for those already
associated with the task context. Remove will remove
the breakpoint from the context. Clear will
unset the breakpoint completely.
With relation to the Preferences around breakpoints and watches, this is the logical And/Or chain that
must be followed to allow for the flexibility specified in the requirements above (x’s are checkboxes, o’s
are radio b
As I work on a task:
X Add breakpoints I set to my task context
X Also save the enabled/disabled state of breakpoints
When I act
ivate a task:
X Set breakpoints in my Task Context
X Disable all other breakpoints
Note: Again, we would have the
in a section about Watches
, on the assumption that we