Download MASTER THESIS

// a property is being expanded on this node
Expand(node, propertyName)
// get the value of the property being expande
targetValue = EvaluateProperty(node, propertyName)
// and add the value to the graph
// (either an edge to an existing node, or a new node)
existingNode = GetSeenNode(targetValue)
if existingNode != null then MakeEdge(node, existingNode)
else MakeEdge(node, NewNode(targetValue))
}
Listing 25 – Expanding a property in the Object graph
The algorithm does not recalculate the whole Object graph on every Expand action it assumes
that property getters don’t have any side effects on the rest of the graph, which is a reasonable
tradeoff between graph correctness and expand performance. Having property getters modify
other properties is rarely done in practice – the only reasonable use case is when a property
getter caches a value in a field or a data structure. Such scenario would be solved by
reevaluating all the properties of the instance instead of evaluating a single property. In
principle, property getters could modify also anything in the any other instances of the graph,
but that would a very bad programming practice and it is practically never done, therefore it
was decided not to make the general case much slower in order to account for a theoretical
edge case. After the graph is rebuilt completely (either when requested by user or after a
debugger step) the graph is in correct state. See also section 2.3 (Fundamental problem of
debugging) for more general discussion on the problems with determining debuggee state.
Of course, apart from Expanding, there will be also a Collapse feature, which consists of
removing the target Node and all its inbound and outbound edges from the graph.
2.6.4 Graph layout
Having the Object graph (that is, a graph inside the debugger isomorphic to the actual graph in
the debuggee) built, this section focuses on how to position the vertices and edges of the
Object graph on a 2D plane so that it looks natural to users.
Dynamic graphs and incremental stability
There is one special requirement to the Graph layout – the Object graph visualizer deals with
dynamic graphs, which directly relates to the Graph transitions feature.
There is a problem with calculating layout for dynamic graphs – if the layout algorithm does
not account for graph dynamicity, a small change to the graph can cause drastic changes to the
layout. Say for example that one node or edge is added to the graph and most nodes are
rearranged completely in the new layout. In other words, such layout is incrementally
unstable. In our scenario, incremental instability would mean large groups of nodes moving
around randomly when a debugger step introduces only small changes to the graph, which
would certainly mean bad user experience. The solution should therefore aim for incremental
stability of the layout.
45