Task-Specific Breakpoints - NetBeans Wiki

weaverchurchΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 11 μήνες)

339 εμφανίσεις

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

Active Task:

Out of a list of tasks, the one that is currently being worked on.

Task Context:

Everything in the IDE that supports work on the task: Files, details, the physical state of
the IDE.

: Not pertaining to a specific task.

: Pertaining to a

specific task.

: 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.

The Task
Focused Breakpoint Sp

If you look at the overall IDE
level landscape of breakpoints, and then apply a task
focused perspective
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
n no
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
er, while
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
ones. The
only ones that are disabled are those that are explicitly related to other tasks, and NOT to the active

Use Cases

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
them global.



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
specific breakpoint.


We need to give the user the option of whether or

not to restore the enabled/disabled state of
their task
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
the applica
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.

GUI Proposal

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 shows:


eakpoint name


Breakpoint location


Breakpoint state

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
same choices
in a section about Watches
, on the assumption that we
enable/disable them.