Visualizing Object Oriented Software:

Towards a Point of Reference for Developing Tools for Industry

Mariam Sensalire and Patrick Ogao

Faculty of Computing and IT
Makerere University
Kampala, Uganda
{msensalire,ogao}@cit.mak.ac.ug

Abstract ment process [8, 22]. This is inclusive of those that develop
software visualization tools. This nature of designing vi-
Developing a software visualization tool that gets high sualization tools under-utilizes the perceptual and cognitive
acceptability in the industry or research community would theories leading to tools that are not properly evaluated by
imply success for that particular tool. In the past, many the users for whom they are intended [16, 22]. As such
tools have been developed within the academic arena with many of the designed tools are not used in practice. To be
many more currently being developed. The rate of com- able to design a software visualization tool that is effective
mercial success for the developed tools however does not however, a proper needs assessment of the target users may
match their development rate. In this paper the views of need to be carried out [11].
expert programmers are sought on what should be incor- Sim [18] noticed this challenge and advocated for bench-
porated in a software visualization tool. These views are marking in an effort to better utilize the resources available
sought after exposing the programmers to three tools and in the software engineering field.
allowing them to use the tools for a period of time. The re- The work presented in this paper builds onto Sims work
sults from the observations show that many of the desires of and addresses a different perspective of the benchmark.
the expert programmers are not catered for in the currently Emphasis here is put on the potential need for a point of
existing tools. The potential need for a point of reference reference for developing tools for Industry.
for developing tools for Industry is also discussed. The rest of the sections in this paper are organized as
follows; Section 2 looks at previous work that is related to
what is presented in this paper while in section 3 the exper-
1. Introduction iment that was carried out is presented. In section four, the
results from the experiments are shown and finally section
five concludes and provides areas for future research.
Developers of software systems put a lot of effort in un-
derstanding the software they are working on especially if
they were not part of the team that designed it [2, 8].Many 2. Previous Work
times however, the developers can only rely on the source
code as the true representation of the program being worked In the past, comparison of software visualization tools,
on [13, 20]. developing tools based on user needs as well as benchmark-
Due to the complexity of source code, visualization has ing have all been looked at by different researchers.
been used to increase program understanding and many Notable in the tool comparison area is Pacione [13] who
tools have in effect been developed to respond to this de- compared five dynamic visualization tools and evaluated
mand [2, 16]. Plenty of techniques have been introduced them with one user in relation to comprehension questions.
with the many tools developed [2, 10] however, it is still a Pacione noted that identifying the views that were appropri-
challenge to choose the best one among them. In the ab- ate for particular comprehension tasks was still a challenge.
sence of a guide, new researchers and developers of tools He also stated that the usefulness of the multifaceted three-
may choose to design based on what they think is useful. dimensional model in software comprehension was yet to
Many times though, software developers do not involve be evaluated.
the final users as much as they should during the develop- There is also a body of work that advocates for the devel-
opment of tools based on the needs of the users since in the 3.2 Source Code
past, users of software visualization tools stated that their
desired features were not always available in the tools. Three different sets of source code were used for the
Bassil [3] identified the need to carry out a survey that three different tools. Code Crawler was evaluated using the
is targeted towards a more specific audience so as to get Lucene search engine source code, Creole was tested using
specific results for that group.This can then be followed by Apache beehive code whereas Source Navigator was tried
rapid prototyping which can help in reducing the time and using Apache tomcat code.
effort in designing a tool which may not be effective [22, A different subject system was assigned for each tool in
14]. Likewise, Cordy [5] used his experience in industry to order to ensure that there was no familiarity with the code
observe that it is an oversight to assume that a method that for each session. Using the same code could bias the par-
works well in academia would automatically be successful ticipants as knowledge from the previous session could be
in industry. carried forward.
Lucene Source Code Lucene is an information retrieval
Application Programming Interface (API), originally im-
3. The experiment plemented in Java by Doug Cutting. It is free, open source
and released under the Apache Software License [1].
This section looks at the results of observing five expert Apache beehive Apache Beehive is a Java Application
programmers using three visualization tools. Their likes Framework designed to make the development of Java En-
and queries with the tools used are discussed in an effort terprise Edition (EE) based applications quicker and easier
to show what the experts require if they are to adopt tool [1]. It was contained in 17 general packages with an average
support. of 7 sub-packages within each main package.
Apache Tomcat Code Apache Tomcat is a web con-
tainer that implements the servlet and the Java Server Pages
3.1 Tools (JSP) specifications from Sun Microsystems. It provides an
environment for Java code to run in cooperation with a web
Three tools were used for the study. These were Code server [1].
Crawler ([15], [9]), Creole ([4], [12]), and Source navigator
[19]. These tools were carefully selected based on the cri- 3.3 Participants
teria of being freely available, the ability to visualize object
oriented software and the difference between the techniques Five expert programmers from Industry participated in
used during visualization. the study. They were all male with over ten years experience
Selection of tools that utilize different techniques was both in programming and computer usage. They were expe-
very important in order to avoid results based on only a rienced with the object oriented paradigm with knowledge
given method of visualizing. of at least two object oriented languages The three projects
chosen were all in java - a language that all the participants
Code Crawler: This is a tool that combines the traditional had working knowledge of.
visualization graph display with simple metrics about the
software [6]. Code crawler is incorporated within Moose 3.4 Procedure
which is an extensible language independent environment
for re-engineering object oriented systems [7]. The five participants were all exposed to the three tools
one tool at a time. Each participant was given a 5 minutes
Creole: Creole is an Eclipse plug-in that integrates Shrimp introduction to a tool. After which they had 5 extra minutes
[21] with the Eclipse platform’s Java Development Tools for familiarizing with the tools themselves or seek any extra
(JDT) [4]. Its main purpose is to provide both the high level information. During this stage, sample tasks were given for
program views as well as different dependencies within the each tool in order to prepare for the actual experiment.
source code .It is able to display code using radial, grid, After the familiarization stage, 2 tasks for each tool were
and tree map techniques. given to the participants, one task at a time. The tasks given
out were;
Source Navigator: This is a source code analysis tool [19] i Describe the static structure of the system, ie the main
which enables code editing, display of classes and their re- classes and their relationships.
lationships as well as call trees. It uses a very simplistic
display format and does not use a lot of color and anima- ii What would be the effect of deleting a particular class
tion. or method from the source code?
 Those tasks were replicated for all the three tools how- 5.1. IDE Integration
ever the second task was modified according to the source
code being analyzed. There was concern of integrating the visualization tools
with an IDE. The reasoning was that when one visualizes,
i For Code crawler the second task was What would be it is usually for a purpose. If the desire is to add more code
the effect of deleting the Hook class? to existing software, then it would be too much effort to
switch between the visualization tool and the environment
ii For Creole, the second task was changed to that is being used to program. So even if a tool is able to
What would be the effect of deleting the generate amazing visualizations, the effort and time spent
org.apache.beehive.netui.tags switching between the two environments may have an ef-
fect on the knowledge preservation for programming thus
iii Source Navigator’s second task was naming the effect the desire for integration. Creole is noted to have achieved
of deleting the DbStoreTest class. this well especially if the programmers development envi-
ronment is eclipse.
These tasks were chosen because they could test the tools
5.2. Fast responses
capacity to provide answers concerning the large scale and
small scale static make up of the source code. The second
The speed of achieving the visualization was also highly
task was able to test further the relationships and external
complained about. Having programmed for a while, code
references of given parts of the code. This was necessary as
was not as difficult for the experts to comprehend as it is
a typical programmer would need both [13]. The answers
for the novices. This meant that the switch to tool support
to these tasks were recorded on a pre-arranged answer sheet
had to be supported by the speed of achieving the respective
that covered all the three tools.
task. More than two users stopped the generation of call
After working with a particular tool, there was a 2- graphs because they felt it was taking too long and a third
minute break before proceeding to the next tool. This du- user said that they would have achieved better results even
ration was kept short so as to ensure that the participants with a plain IDE as opposed to waiting for a solution that
attention was not diverted form the experiments. At the end takes too long. So even after the visualization has been gen-
of the tasks for all the three experiments, a questionnaire erated but the timing is not right, it is not considered useful.
was filled followed by an interview before terminating the Source Navigator was appreciated by all the participants for
session. its speed of response.

4. Observations 5.3. Minimal effort

There was preference for minimal effort during the gen-

It was observed that more time than had been planned eration of the visualization. Having to export and import
was taken during the experiment. The the pre-study ques- code in another format was found to be cumbersome for the
tionnaires used the allocated time, however the observa- participants. As much as possible direct code manipulation
tions, the answers during the tool exposure and the post was prefered and in cases where that was not possible, close
study interview and questionnaire all took more time than proximity to code was encouraged.
had been allocated. During the course of the experiment,
the participants made a lot of comments about the tools and 5.4. Good search abilities
also asked for extra functionality which was not always sup-
ported. The results from the questionnaires interviews as The ability to search the visualization was another de-
well as those observations are combined to provide the gen- sired component that the users felt could have been ad-
eralized results. This experiment was not aimed at choos- dressed better. Even a good visualization that can not be
ing the best tool among the three observed. The results will manipulated was not found to be useful. Searching was de-
therefore not be organized on a tool-by-tool basis. sired both at the displayed diagram level and at the source
code level in a manner that was related. Creole covered this
element to a greater extent.
5. Results
5.5. Clear display
The results of the study showed that there was a lot that
was desired by the programmers but was found to be lack- Simple clear displays were prefered by the participants.
ing. The main queries observed are noted below: If for example a class was shown, the participants desired
its name to be shown as well in close proximity to the class. [8] R. Elferink, D. Griffiths, and S. Zondergeld. Comparing
The named class hierarchy of code crawler was especially software development models: Structural problems in the
mentioned as having been very clear. cathedral and bazaar metaphors. 7th IMAC Conference
on Localization and Globalization in Technology Design,
Use and Transfer as a Subject of Engineering Education,
6. Limitations Duisburg-Essen, Germany, 2004.
[9] M. Lanza. Codecrawler-lessons learned in building a soft-
There are limitations to the approach used in this work ware visualization tool. Proceedings of the Seventh Euro-
that may hinder the level of generality of the results. The pean Conference on Software Maintenance and Reengineer-
ing, pages 409–418, 2003.
experiments carried out were in a controlled environment, a
[10] J. Maletic, J. Leigh, A. Marcus, and G. Dunlap. Visual-
method that has been criticized in the past [14, 17]. The area izing object oriented software in virtual reality. Proceed-
of static visualization was also especially looked at despite ings of International Workshop on Program Comprehension
the fact that a combination of static and dynamic visualiza- (IWPC01), pages 21–13, 2001.
tion may be useful for object oriented software. The lack [11] A. Marcus, L. Feng, and J. Maletic. 3d representations for
of a guideline for task selection during tool evaluation was software visualization. Proceedings of the 2003 ACM sym-
also a limitation. posium on Software visualization, San Diego, California,
page 27, 2003.
[12] R. Michaud, M. Storey, and X. Wu. Plugging-in visual-
6.1. Conclusions and Future work ization: Experiences integrating a visualization tool with
eclipse,. ACM Symp. on Software Visualization, (Soft-
From the results of the study carried out combined with vis’2003),, 2003.
literature from previous studies, it can be concluded that [13] M. Pacione, M. Roper, and M. Wood. A comparative
better visualization tools and techniques can be achieved if evaluation of dynamic visualization tools. Proceedings
the views of the target group are sought before hand . In of the 10th Working Conference on Reverse Engineering
order to develop tools that can be accepted in industry, con- (WCRE),Victoria, BC,Los Alamitos, pp. 80-89, CA: IEEE
centration should be put on finding out the needs of the in- CS Press,, pages 80–89, 2003.
[14] C. Plaisant. The challenge of information visualization eval-
dustry first and then later developing to meet those needs.
uation. Proceedings of the working conference on Advanced
Future work will involve improving the experiment and ap- visual interfaces, pages 109–116, 2004.
plying it to a plain IDE so as to compare results. [15] SCG. www.iam.unibe.ch/s̃cg/research/moose/index.html.
Software Composition Group - University of Berne, Switzer-
References land, 2006.
[16] T. Schafer and M. Mezini. Towards more flexibility in soft-
ware visualization tools. VISSOFT, pages 64–69, 2005.
[1] ASF. www.apache.org/. The Apache Software Foundation [17] B. Shneiderman and C. Plaisant. Strategies for evaluating
(ASF), 2007. information visualization tools: Multi-dimensional in-depth
[2] M. Balzer and A. Noack. Software landscapes: Visu- long-term case studies. Advanced Visual Interfaces Confer-
alizing the structure of large software systems. Joint ence Venice Italy, 2006.
EUROGRAPHICS-IEEE TVGD Symposium on Visualiza- [18] S. Sim, S. Easterbrook, and R. Holt. Using benchmark-
tion, 2004. ing to advance research:a challenge to software engineer-
[3] S. Bassil and R. Keller. Software visualization tools: Sur- ing. Twenty-fifth International Conference on Software En-
vey and analysis. Ninth International Workshop on Program gineering, Portland, Oregon,, pages 74–83, 2003.
Comprehension, page 4, 2001. [19] Source-Navigator-Team. http://sourcenav.sourceforge.net,.
[4] CHISEL. http://www.thechiselgroup.org/?q=creole. Uni- GNU,, 2006.
versity of Victoria, Canada, 2006. [20] M. Storey. On integrating visualization techniques for effec-
[5] J. Cordy. Comprehending reality practical barriers to in- tive software explorations. Proceedings of IEEE Symposium
dustrial adoption of software maintenance automation. Pro- on Information Visualization, 1997.
ceedings of the 11th IEEE International Workshop on Pro- [21] M. Storey, K. Wong, E. Fracchiat, and H. Miillert. On in-
gram Comprehension, page 196, 2003. tegrating visualization techniques for effective software ex-
[6] S. Demeyer, S. Ducasse, and M. Lanza. A hybrid reverse ploration. Proceedings of IEEE Symposium on Information
engineering approach combining metrics and program visu- Visualization, 1997.
alization. Proc. of the Working Conference on Reverse En- [22] M. Tory and T. Moller. Human factors in visualization re-
gineering (WCRE’99), IEEE, 1999. search. IEEE Transactions on Visualization and Computer
[7] S. Ducasse, M. Lanza, and S. Tichelaar. Moose: an exten- Graphics Vol 10, No.1, 2004.
sible language-independent environment for reengineering
object-oriented systems. Proceedings of the Second Inter-
national Symposium on Constructing Software Engineering
Tools (CoSET 2000), page 13, 2000.