日本ソフトウェア科学会第 39 回大会 (2022 年度) 講演論文集

Visual Debugger with a Customizable View
Rifqi Adlan Apriyadi, Hidehiko Masuhara, Youyou Cong

Visual debuggers provide more concrete representations of program behavior than what might normallystill be abstract. For object-oriented languages, their object-centric components, such as objects and theirrelationships, are the information their visual debuggers aim to concretize. However, none of such debuggers provide the capability to customize their graphical view. Customization ought to facilitate better
comprehensibility of the program behavior, which consequently aids in bug discovery, by allowing for amore focused program state view. This can be achieved by customizing the representation of objects ofa class in accordance with the theoretical concept, or by abstracting away unnecessary information. This
research proposes a visual debugger for Java with customization features for its graphical view that allows
users to customize the visual representation of the program state through customization speciﬁcations. To
provide ﬂexible customizability, the proposed system would provide customization elements that function
as building blocks for users to use in their speciﬁcations.

with other objects with regards to their references.

1 Introduction

Moreover, this view is frequently displayed as a

The main goal of visual debuggers is to enhancetree of objects where referenced objects are lower

program state understanding, and consequently,

in the tree as their children. Tree structures de-that of the program behavior. Visual debuggers

pict items that could have children which could also

display relevant information graphically to facili-

have children of their own. However, each item

tate this purpose. This is fueled by the fact that

could at most only have one parent and children

visualizations of abstract information concretize itof an item could not include any of the its parents.

by displaying relationships and patterns [5].

This means that a tree structure is not the most ac-

For object-oriented languages, understanding the

curate nor concrete depictions of these relationships

behavior of a program is signiﬁcantly more diﬃ-

as objects could be referenced by multiple diﬀerent

cult than understanding its structure or design [3].

objects while the referenced ones could, in turn, do

Therefore, it is important to display the object-

the same to more, even the ones higher up in thecentric information of program states — the statetree.

of the program at a point in time or in program sus-

To those eﬀorts, visualizations are often in thepension — whilst debugging [4]. This includes theform of object diagrams — or their variants — tovalues of variables of objects and their relationships

show the aforementioned relationships between ob-

Visual Debugger with a Customizable View
Rifqi Adlan Apriyadi, Hidehiko Masuhara, Youyou
Cong, School of Computing, Department of Mathematical and Computing Science, Tokyo Institute ofTechnology.

jects [11] [8] [7] [9]. In an object diagram, an object
is a node or vertex and their references to other objects are represented by directed edges to the them.
An simple example of an object diagram could beLaptoparticleRepairitemId (int): 1001

equipped to cover this practice, causing the process
to become counter-intuitive.

type (RepairType): BAT_REP
modelId (int): 256
contact

ownerCustomer

Given this, the main problem causing these two
shortcomings is the rigidity of the graphical viewsin terms of how they display program states. Users

name (String): Johncannot control the visualization of their program

cusId (int): 3018

states to match their situations, harming users’ un-phone (String): "0987654"

derstanding of program states.
図1

Example of an Object Diagram

To alleviate this problem, this research proposesa visual debugger for a chosen object-oriented pro-seen in Figure 1, which shows a Repair object rep-

gramming language, Java, where users are able toresenting a repair order which has variables article

customize the object diagram view by means ofand contact which reference a registered item anda customization speciﬁcation to ﬁt their current

a customer, respectively.

needs. The proposed system is to be built on Visual

However, although the main purpose of visual

Studio Code utilizing its various available APIs. A

debuggers is to facilitate program understanding,comparative experiment is to be conducted to ver-they often come short in reaching this goal in some

ify the eﬀectiveness of the debugger with regard tosituations.

the problem it aims to solve.

Large program states often manifest

this shortcoming by cluttering the debugger view

The aim of this research is to investigate an ap-

with a large object diagram, even for modestly sizedproach to the development of a visual debugger

programs [4] [12]. Though some of these projects

with a feature that allows for ﬂexibility in display-provide workarounds by allowing users to prune ob-

ing these program states. Section 2 details the pro-

ject nodes from the view to simplify it, this solu-

posal and key features relevant to the problem attion merely removes information relating to these

hand. Furthermore, Section 3 presents the speciﬁcs

objects completely when some parts of it might stillof the implementation of the prototype of the tool

be relevant [8].

aimed to represent this research whose success is toFurthermore, it is not uncommon to have imple-

be validated as described in Section 4. Finally, sim-

mentations of a concept to be diﬀerent from how

ilar work will be mentioned in Section 5 followed bythey are portrayed in theory. An example of this

this paper’s conclusion in Section 6.

is the internal representation of lists when writinga heap sort algorithm. A visual debugger will nor-

2 Proposal

mally display lists the way they are represented in-This research proposes a visual debugger withternally, which greatly impedes the programmer incustomization features in its graphical view.

understanding the current program state while de-Among other things, these features ought to coverbugging, given that they would most likely need

the aforementioned common ﬂaws present visual

to visually observe the behavior of their program

debuggers for object-oriented languages.

working on a heap structure. Even though the pur-section ﬁrst describes the customization featurespose of the visualization is to facilitate the under-

which will then be followed by the description ofstanding of concepts and their behaviors [10] [6] as

how customization is a potential solution.

represented by the visualized objects, they are un-

This

Though the purpose of the customization featureis to avoid rigidity, it is also important for the fea-

Singleture itself to not stumble onto the same pitfall. In
this eﬀort, the debugger provides users with cus-

moveMaker

card

tomization elements that act as building blocks.
With these building blocks, the users should be able

PlayerCard

to specify their own customizations to the debugger

name (String): "Walt"

rank (int): 5
suit (Suit): SPADES

view in various components of the language, such as
for a speciﬁc class, class ﬁeld, method, method pa-

図2

Uncustomized

rameter, etc. Through a speciﬁcation, the debugger
view will display program states accordingly onceSingledebugging starts.
Types of customization elements include:

card (Card): 5♠(a) Invisible Edge: The removal of an edge relating two object nodes from the view

moveMaker(b) Imaginary Edge: The addition of an edge
relating two object nodes to the view

Playername (String): "Walt"(c) Invisible Object: The removal of an object
node and all its incoming and outgoing edges

図3

Customized

from the view(d) Imaginary Object: The addition of an object
node to the viewthe card variable.
Furthermore, it is anticipated that it would be(e) Node Description: Allows each object touseful for customizations to be accompanied by op-

have their own descriptions which could tailor

tional conditions which allow users to specify when

to its current state.

a customization is applied. For example, to specify

For example, Figures 2 and 3 show sample mock-the list to heap customization as discussed in theup object diagrams of the visual debugger. Bothprevious section, conditions would prove useful to

subﬁgures display a Single object — representing

indicate where to create imaginary edges and wherea Single move made by a player involving only one

to remove ones that would normally exist. It is

card in a card game — that has variables moveMaker

also envisioned that some combinations of these el-of class Player and card of class Card representing

ements will be used frequently for higher-level cus-

the player making the Single move and the card

tomizations, such as in the use case of merging two

within the move, respectively. Figure 2 shows thenodes of objects where one wraps the other in theuncustomized view and Figure 3 shows it with some

implementation side. Therefore, a few higher-level

customizations applied. The customizations usedcustomization elements that are predicted to be of

in Figure 3 are:frequent use that serve as shorthands for combina-• Declaring the Card class as an invisible nodetions of the building block customization elements• Declaring the card variable in the Single classshall be provided as well. In addition to specifying

to be an invisible edge

the customization before debugging, the debugger• Adding a custom description to object nodes

would also allow for the user to customize the viewof the Single class to show the description ofwhile debugging, which would serve as a quality-of-

life feature for small customizations or to preview

Concrete Debugger

how the customization that the users have in mind.
For the case of the inconsistency between the con-

Debug Adapter

cept and its representation in runtime, users could

Debug Adapter Protocol

customize the view to closer resemble the represen-

Debugger Extension

tation of the concept in theory despite how the data

VSCode Extension API

is actually stored internally. For example, users

VSCodecould customize the view to show a node with atextual description of a matrix instead of showing

VSCode WebView API

an array that refers to more arrays, the former al-

WebView UI

lowing for a more comprehensible view.
On the other hand, for the case of visual clutter, users could specify customizations to the viewthat abstract information that is irrelevant to thecurrent situation [13]. For instance, users could re-

図4

The Architecture of the Visual Debugger

duce visual clutter by making immutable objects ofa class as node elements of objects that have themcan be seen in Figure 4 and is described as follows:

as reference and removing any of their nodes from• The user interacts with the WebView UI

the view completely, if the behavior of this class is• The WebView UI exchanges information withcurrently of no importance.

VSCode using the VSCode WebView API• VSCode communicates the visual debugger

3 Implementation
The tool is to be developed as a debugger for Javaextension that is to be built using the VSCode
Extension API

due the support it is given by the software used for• The extension manages the debugger by com-the development. Furthermore, it is a convenient

municating with VSCode’s Debug Adapter

choice given that most research projects taken as(DA) for Java through the Debug Adapter Pro-

reference for this research [7] [8] [9] [1] build their

tocol (DAP)

tools for Java, as well.

• The DA handles the communication with
Java’s concrete debugger.

3. 1 Visual Debugger User Interface
The UI of the debugger will be implemented as an

3. 2 Debug View Customizability

extension for Visual Studio Code, hereafter referred

The main concerns in the implementation of theto as VSCode. WebView [2] will be used to display

view customization features of the visual debug-

the UI due to the fact that extensive ﬂexibility ingers are how users would specify their customiza-

designing the UI is provided and that VSCode hastions and how the visual debugger would under-

its own dedicated API for it. This ﬂexibility will

stand them. For the former, there are a few options

also allow for the development to be facilitated byavailable.

a visualization library that lies in abundance. The

One option would be to provide a dedicated Do-

UI would extend the debugger UI of VSCode. In

main Speciﬁc Language (DSL) that users would use

either case, the architecture of the tool to be built

to write in to specify their customizations in a sepa-

rate ﬁle. Requiring users to specify their customizations in a separate ﬁle allows them to be as expres-

4 Validation

sive as need to be in their customization speciﬁca-

The main aspect to be validated in this researchtion. However, this would require them to specify

is how much the use of view customization in awhich customization applies to which part of thevisual debugger improves the understandability of

program, which might involve cumbersome identi-

program behavior, or lack thereof. Since the view ofﬁcation. This is especially troublesome for large

the visual debugger will be a variant of an object

projects where paths to classes are often long.

diagram, the component whose understandability

Another option would be to provide annotations

is to be measured is the object diagram in the viewusers could use in diﬀerent parts of the program,and certainly not the code used for the validation

which would also require a DSL, albeit not nec-

itself. However, although there are already stud-

essarily one as expressive as the previous option.

ies on measuring understandability of code, there

Users would have greater convenience in specifying

is yet to be a devised metric for the measurement

which customization applies to which parts of theof diagram understandability.

program given that annotations could generally be

Therefore, a comparative experiment ought to beplaced on virtually most of the language’s compo-

conducted which aims to compare the average timenents, resolving the identiﬁcation problem from theit takes for participants to understand the behav-

previous option. However, as speciﬁcations along

ior of provided programs in two diﬀerent settings.

with their conditions would be made in these an-

The control group would be tasked to understandnotations, it is questionable how expressive these

the behavior of programs using the visual debugger

speciﬁcations could be given that heavily expressive

without any customizations applied on the debug-

speciﬁcations may litter the ﬁle. Additionally, thisger view. In other words, this group would only

option would not allow users to write customiza-

use the basic view of the debugger. The treatment

tions on parts of the program in read-only ﬁles.

group would be tasked to do the same with the

Finally, the third option is to incorporate bothsame set of programs provided, except they will beof the previous options, taking the best of bothusing the visual debugger with customizations al-worlds. If the user is not to provide lengthy speciﬁ-

ready applied. To have the provided tools be uni-

cations for each annotation or if they are not to beform to all participants in the treatment group, thewritten in a read-only ﬁle, then these annotations

customization speciﬁcation will already be provided

could remain and would not disarrange the pro-for them. For both groups, they will be asked to dogram ﬁle. Otherwise, they could be made written

their tasks using the debugger as much as possible.

into a separate ﬁle. The downside to this option is

It is expected that the average time taken to un-

the development eﬀort required to implement bothderstand each program in the treatment group toof these functionalities.

be smaller than that of the control group.

Regardless of the speciﬁcation method option

This experiment will certainly have extraneous

chosen, speciﬁcations are to be compiled into an

variables present that may inﬂuence the results of

XML ﬁle, which the debugger could more easily

each participant. The biggest of these variables

parse and create its internal representation from.

would be the amount of experience and knowledge
participants already have in the experimentation
environment. A participant may have more expe-

is its simplicity and pedagogy. BlueJ provides an
Evaluationinteractive environment in which students could in-

Results

teract directly with classes and objects, allowing
Control Group

Treatment Groupthem to learn the behavior of the object-oriented
programming paradigm.
Similarly, Jeliot3 [9] is a pedagogic tool aimed

Code

Code

Surveyalso at novice students for object-oriented programming, as well. It provides a fully or semi-automatic

Speciﬁcations

visualization of the data and control ﬂows of the
図5

Flow of the Experiment

program. In addition to supporting visualizationsof object instances and inheritance, this version ofrience in the programming language, in program
comprehension and debugging, or in the theory the

Jeliot also introduces object-oriented concepts.
Velázquez-Iturbide et al.

[13] developed Win-

programs emulate. Though these variables could

HIPE, an environment providing students the ca-

not be avoided, they should have the capacity topability of customizing the visualization of expres-be minimized through careful distribution of par-sions. The customization areas it provides are in

ticipants. For example, the distributions of the two

the choice between textual or graphical visualiza-groups could be done in such a way that the groups

tions, or a mixture of both, the typographic styles

are balanced in terms of their participants’ experi-used, and visualization simpliﬁcation.

ence and knowledge, the information of which could
be obtained by a survey some time before the ex-

6 Conclusion

periment is conducted. Figure 5 illustrates the ﬂow

Though the addition of visual debuggers and sim-of the experiment.

ilar tools has been acclaimed, the very nature ofvisualizations is that they mirror abstract infor-

5 Related Workmation in a ﬁnite space, leading to rigidity. The

This section discussed the more well-known tools

research this paper describes aims to discover thefor program visualizations. Though not all of themmethods, considerations, and results of developing

have the same concept as the visual debugger dis-a visual debugger that overcomes the trap of rigid-

cussed in this paper, they all provide visualizations

ity through customizability.

aimed at concretizing program behavior comparedto their predecessors.
Java Interactive Visualization Environment (JIVE)

The visual debugger proposed is to allow users
to specify their customizations which will be automatically applied once they start debugging. Basic[8] is a visual debugger built as a plug-in for thecustomization elements are provided that serve as

Eclipse Java debugger. It features an object dia-building blocks for any customization. The debug-

gram view, a sequence diagram view, backwards

ger will be developed as an extension to Visual Stu-

stepping, and query-based debugging — though

dio Code due to the fact that it provides convenient

without the ﬂexibility this research aims to achieve.

APIs for the view, the extension development, and

BlueJ [7] is an integrated Java development en-

the debugger back-end.

vironment designed for introductory teaching to

The validation of the success of the tool is

object-oriented programming. Its main property

planned to be done by means of a comparative ex-periment, where participants are to be separated
into control and treatment groups. They are to be
separated accordingly such that the programming
experience and proﬁciency of the two groups are
as balanced as possible. This is important given
the fact that the rate in which participants can understand program behavior through the use of thetool is the variable of interest, which may vary immensely.
参 考 文 献[ 1 ] Cardillo, G., Schürmann, P., and Lagadec,
A.: Visual OO Debugger, PhD Thesis, OST
Ostschweizer Fachhochschule, 2022.
[ 2 ] Cockburn, A., Greenberg, S., McKenzie, B., Jasonsmith, M., and Kaasten, S.: WebView: A graphical aid for revisiting Web pages, Proceedings of the
OZCHI, Vol. 99, 1999, pp. 15–22.
[ 3 ] De Pauw, W., Lorenz, D. H., Vlissides, J. M.,
and Wegman, M. N.: Execution Patterns in ObjectOriented Visualization., COOTS, Vol. 98, 1998,
pp. 16–16.
[ 4 ] Gestwicki, P. and Jayaraman, B.: Interactive
visualization of Java programs, Proceedings IEEE
2002 Symposia on Human Centric Computing Languages and Environments, IEEE, 2002, pp. 226–
235.
[ 5 ] Ho, S. Y.: Seeing the value of visualization,(2010).
[ 6 ] Keahey, T. A. et al.: Using visualization tounderstand big data, IBM Business Analytics Ad-

vanced Visualisation, Vol. 16(2013).
[ 7 ] Kölling, M., Quig, B., Patterson, A., and Rosenberg, J.: The BlueJ system and its pedagogy,
Computer Science Education, Vol. 13, No. 4(2003),
pp. 249–268.
[ 8 ] Lessa, D., Czyz, J. K., and Jayaraman, B.:
JIVE: A pedagogic tool for visualizing the execution of Java programs, Bericht, Univ. of New York,Buﬀalo, (2010).
[ 9 ] Moreno, A., Myller, N., Sutinen, E., and BenAri, M.: Visualizing programs with Jeliot 3, Proceedings of the working conference on Advanced visual interfaces, 2004, pp. 373–376.
[10] Naps, T., Cooper, S., Koldehofe, B., Leska, C.,Rößling, G., Dann, W., Korhonen, A., Malmi, L.,
Rantakokko, J., Ross, R. J., et al.: Evaluating the
educational impact of visualization, Acm sigcse bulletin, Vol. 35, No. 4(2003), pp. 124–136.
[11] Oechsle, R. and Schmitt, T.: Javavis: Automatic program visualization with object andsequence diagrams using the java debug interface (jdi), Software visualization, Springer, 2002,
pp. 176–190.
[12] Sinha, V., Karger, D., and Miller, R.: Relo:
Helping users manage context during interactive
exploratory visualization of large codebases, Visual Languages and Human-Centric Computing(VL/HCC’06), IEEE, 2006, pp. 187–194.
[13] Velázquez-Iturbide, J. Á. and Presa-Vázquez,A.: Customization of visualizations in a functional programming environment, FIE’99 Frontiersin Education. 29th Annual Frontiers in Education Conference. Designing the Future of Scienceand Engineering Education. Conference Proceedings (IEEE Cat. No. 99CH37011, Vol. 2, IEEE,
1999, pp. 12B3–22.