Extending Dynamic Linking for Program Customization, Analysis, and Evolution

86 Pages·2005·19.99 MB·English

Contents
W. Abdelmoez, I. Shaik, R. Gunnalan, M. Shereshevsky, K. Goseva-Popstojanova,
H.H. Ammar, A. Mili, C. Fuhrman: Architectural level Maintainability Based Risk Assessment . . . . . .4
Francoise Balmas, Harald Wertz, Rim Chaabane:
Visualizing Dynamic Data Dependences as a Help to Maintain Programs . . . . . . . . . . . . . . . . . . . . . . .8
Feng Chen and Hongji Yang, He Guo and Tianyang Liu:
Aspect-Oriented Programming based Software Evolution with Microsoft .NET . . . . . . . . . . . . . . . . .12
Rodrigo Santos de Espindola, Azriel Majdenbaum, Jorge Luiz Nicolas Audy:
Requirements Engineering Challenges for Software Maintenance Projects
in Distributed Software Development Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Beatriz Florián, Ángela Lozano, Silvia Takahashi:
Automatic Detection of Bad Smells Using Software Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Grace Gui, Holger M. Kienle and Hausi A. Müller: REGoLive:
Adding Web Site Comprehension to Adobe GoLive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Tracy Hall and Paul Wernick:
Using Program Slicing Metrics to Predict the Maintenance of Software . . . . . . . . . . . . . . . . . . . . . . .27
Igor Ivkovic and Kostas Kontogiannis:
Model Synchronization through Pattern-Based Association Grammars . . . . . . . . . . . . . . . . . . . . . . . .31
László Lengyel, Tihamér Levendovszky and Hassan Charaf:
Supporting Continuous Evolution of Software Systems with Transformation Maintenance . . . . . . . . .35
Grace Lewis, Edwin Morris, Liam O’Brien, Dennis Smith:
Analyzing the Reuse Potential of Migrating Legacy Components
to a Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Nuo Li, Jin-liang Ou, Mao-zhong Jin, Chao Liu:
Evaluate Java Program by an Extensible Metrics Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Gregorio Robles, Jesus M. Gonzalez-Barahona, Israel Herraiz:
An Empirical Approach to Software Archaeology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Oscar M. Rodríguez-Elias, Ana I. Martínez-García,
Aurora Vizcaíno, Jesús Favela, Mario Piattini:
Constructing a Knowledge Map for a Software Maintenance Organization . . . . . . . . . . . . . . . . . . . . .51
Serguei Roubtsov and Ella Roubtsova: Incremental Product Line Modelling . . . . . . . . . . . . . . . . . . .55
M.P. Ware & F. G. Wilkie:
AStudy of Evolving Complexity in a Re-Structured Business Application . . . . . . . . . . . . . . . . . . . . .59
Filip Van Rysselberghe and Serge Demeyer: Clone Evolution in Open Source Software Systems:
When, How and Why do Software Maintainers Remove Clones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Mehmet Sahinoglu: Quantitative Risk Assessement
for Software Maintenance with Bayesian Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Sumant Tambe, Navin Vedagiri, Naoman Abbas, Jonathan E. Cook:
DDL: Extending Dynamic Linking for Program Customization, Analysis, and Evolution . . . . . . . . . .71
Richard Wettel, Radu Marinescu: Archeology of Code Duplication:
Recovering Duplication Chains From Small Duplication Fragments . . . . . . . . . . . . . . . . . . . . . . . . . .75
Hui Zeng, David Rine: An Empirical Study on Software Defect Fix Effort Estimation
with Incomplete Historical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Ned Chapin: Experience Report on Maintaining Executable UMLSoftware . . . . . . . . . . . . . . . . . . . .83
Foreword to the Poster Session
By the General Chair
We are very proud to be able to include an excellent poster session in this year’s International Conference
for Software Maintenance. Poster sessions serve an important function in conferences of this type since
they give the attendants an opportunity to discuss with the poster presenters. Posters are intended to pro-
voke a discussion and to help conference participants learn from one another. The formal presentations are
one means of communication, the informal discussions provoked by the poster sessions are another.
The hosting hotel of the conference – the Budapest Thermal Hotel on Margaret’s Island – with it’s many
lobbies, health facilities and open cafes is particularly suitable for such small group discussions. We are
integrating the poster presentations with the coffee breaks so that all participants will have the opportuni-
ty to take part in the discussions. We trust that these discussions will be fruitful for both parties – the pre-
senters and the attendants.
In any case, the array of porters promises to be very informative. They include such hot topics as aspect-
oriented programming, predicting software evolution trends, software measurement, maintenance process-
es, dealing with duplicate code, program comprehension, reengineering software architecture, assessing
maintenance risks and extending dynamic linking for program customization. I heartily recommend every-
one taking part in these vital discussions.
Finally, I want to thank the authors of the poster presentations for their contribution to the technical excel-
lence of this year’s conference and to their help in making this a milestone event in promoting the signif-
icance of software maintenance and evolution.
Harry Sneed
General Chair
Program overview
Saturday STEP
(Sept 24)
Sunday STEP, VISSOFT
(Sept 25)
Monday WSE, Software Evolvability, Industrial Truck, Tutorial
(Sept 26)
Tuesday ICSM
(Sept 27) 8:30am-11:00am Registration
9:00am-10:30am Opening
ICSM- Technical sessions ICSM- Technical sessions ICSM- Technical sessions
11:00am-6:00pm 11:00am-6:00pm 11:00am-6:00pm
T1: Aspect Mining T2: Components & Frameworks T3: Distributed Systems
T4: Maintenance T5: Re- and Reverse Engineering T6: Source Code Analysis
T7: Maintenance in Practice T8: Process T9: Program Comprehension
ICSM
7:00pm Banquet Dinnerin the Grand Hotel Restaurant
Wednesday ICSM
(Sept 28) 9:00am-10:00am Keynote
ICSM- Technical sessions ICSM- Technical sessions ICSM- Technical & Panel
9:00am-6:00pm 9:00am-5:30pm 9:00am-5:30pm
T10: Feature Extractionand T11: Refactoring T12: Regression Testing
Analysis T14: Testing I. P1: Panel 1
T13: Theoretical Maintenance T16: Testing II. P2: Panel 2
T15: Evolution
ICSM
7:00pm Csárdás Eveningin the Wine Cellars of Budafok
Thursday ICSM
(Sept 29) 9:00am-10:00am Keynote
ICSM- Technical & Short papers ICSM- Short papers ICSM- Short papers &
9:00am-3:30pm 9:00am-3:30pm Dissertation
T17: Web maintenance & S1: Maintenance & Evolution 9:00am-3:00pm
Reengineering S4: Testing S2: Program Comprehension
S3: AOP & Web D1: PhD Dissertation session
ICSM
3:30pm Closing
Friday ICSM SCAM
(Sept 30) 8:30am-4:00pm Bugac puszta excursion
Saturday SCAM
(Oct 1)
Architectural level Maintainability Based Risk Assessment1

W.Abdelmoez, I. Shaik, R. Gunnalan, A. Mili C. Fuhrman
M. Shereshevsky, K. Goseva-Popstojanova, H.H. Ammar College of Computer Department of Sofware and IT
Lane Department of Computer Science, Science, Engineering
West Virginia University New Jersey Institute of École de technologie supérieure
Morgantown WV 26506 Technology Montreal, Canada H3C 1K3
{rabie, isrars, gunnalan, smark, katerina, Newark NJ 07102 [email protected]
ammar}@csee.wvu.edu [email protected]

Abstract
Software maintenance accounts for a large part of programmer skill and experience and the attributes of the
the software life cycle cost. Systems with good system itself are some of the variables that affect the
maintainability can be easily modified to fix faults or to maintenance process. According to [14], the cost of
adapt to changing environments. In this paper, we define software maintenance averages from 60% to 80% of the
maintainability-based risk as a combination of two overall software system cost. Furthermore, enhancements
factors: the probability of performing maintenance tasks (perfective and adaptive maintenance) account for 78%-
and the impact of performing these tasks. An estimation 83% of the maintenance effort. As a result,
procedure based on change propagation probabilities maintainability is an important software quality factor.
from architectural artifacts is presented. We illustrate IEEE computer society defines maintainability as the ease
how to apply the procedure on a case study which uses with which a software system or a component can be
design patterns to improve system quality. This type of modified to correct fault, improve performance or other
risk assessment helps in managing software maintenance attributes, or adapt to a changed environment [9].
process. It can be used to identify the most risky parts of
The research effort aimed at quantifying software
the system and assign them to the most experienced
maintainability is rather limited. Moreover, to the best of
maintainers.
our knowledge there are no attempts to quantify
Keywords: Maintainability-based risk, software maintainability-based risk for software systems. In
architectures, software metrics, software maintenance, general, risk assessment provides useful means for
change propagation probability. identifying potentially troublesome software components
that require careful development and allocation of more
testing effort. According to NASA-STD-8719.13A
1. Introduction
standard [12] risk is a function of the anticipated
Software maintenance is defined as modification of a frequency of occurrence of an undesired event, the
software product after delivery to correct faults, to potential severity of resulting consequences, and the
improve performance or other attributes, or to adapt the uncertainties associated with the frequency and severity.
product to a modified environment [8]. Basically, there This standard defines several types of risk, such as for
are three types of software maintenance; corrective example reliability risk, availability risk, acceptance risk,
maintenance deals with error corrections, perfective performance risk, cost risk, schedule risk, etc.
maintenance tries to improve the quality of the system,
In this paper, we focus on perfective maintenance
and adaptive maintenance concerned with system changes
and refactoring activities in particular. Refactoring is
as requirements and environment changes. Software
defined as a change made to the internal structure of
maintainers usually are not involved in the original
software to make it easier to understand and cheaper to
software development cycle. They must learn how a
modify without changing its observable behaviors.
program functions before they can change it. They often
Refactoring to improve the design of the system requires
interact with complex and difficult to comprehend
knowing which parts of the system need to be improved.
systems. The status of system documentation,
In [5], Fowler and Beck presented a list of bad smells that

1 This work is supported by the National Science Foundation through ITR program grant No CCR 0296082, and by NASA
through a grant from the NASA Office of Safety and Mission Assurance (OSMA) Software Assurance Research Program
(SARP) managed through the NASA Independent Verification and Validation (IV&V) Facility, Fairmont, West Virginia.

Copyright © Abdel-Moez W. 2005
4
help to identify where refactoring is needed. Examples of • Maintainability risk—It will be difficult to maintain the
bad smells include large class, lazy class, data class, and system in the future because of the way we conducted
switch statements. It should be noted that not all of the this maintenance.
smells can be identified at the architectural level.
In this paper, we focus on maintainability risk. In
One way to refactor the software is to use design particular perfective maintenance achieved by refactoring
patterns. According to [10], there are practical situations activities.
where patterns help to improve the quality of the design. There have been some studies trying to characterize
The intent is to improve maintainability by reducing or and quantify software maintainability. One of the famous
removing duplication, simplifying what is complicated studies [13] introduced the Maintainability Index (MI)
and making the design development better at measure which is calculated using a polynomial of widely
communicating. Design pattern is a software engineering used code level measures such as Halstead measures and
problem-solving discipline. It has roots in many McCabe’s cyclomatic complexity. In [11], Muthanna et
disciplines, including literate programming, and most al. conducted a similar study which used design level
notably in Alexander's work on urban planning and metrics to statistically estimate the maintainability of
building architecture [3]. The goal of the pattern software systems. They constructed a linear model based
community is to build a body of literature to support on a minimal set of design level software metrics to
design and development. The Gang of Four’s book [6] predict Software Maintainability Index. In [15], Prechelt
presented the first well-described and documented et al. conducted a controlled experiment to study the
catalog of design patterns for object-oriented design. effect of applying design patterns on maintenance effort.
They concluded that unless there is a clear reason to
In our research effort, we are concerned with
prefer a simpler solution, it is probably wise to choose the
maintainability-based risk that takes into account the
flexibility provided by the design pattern.
probability that the software product will need to endure a
certain type of maintenance and the consequences of
2.2. Change Propagation
performing this maintenance on the system.
Maintainability-based risk can be used to improve the The estimation procedure of maintainability-based
maintainability of the system architecture, to manage risk builds on our previous work on change propagation
system maintenance process, and to identify the risky probabilities [1]. Let us consider a software architecture
components of the system in terms of maintainability. modeled by components and connectors. We are
This study is part of a wider effort that considers other interested in the maintainability of the products
types of architectural level risk such as reliability-based instantiated from it. In corrective or perfective
risk [7] and performance-based risk [4]. maintenance tasks, change propagation probability
matrix for an architecture reflects on the probability of
The rest of the paper is organized as follows. In
changing component C as a result of a change to
Section 2, we briefly discuss the literature background of j
component C. The estimation of the elements cp of the
our study. In Section 3, we define how maintainability- i ij
change propagation matrix CP is based on the following
based risk can be estimated based on change propagation
definition [1] :
probabilities and illustrate our estimation procedure on a
case study using design patterns as means of refactoring. Definition. Given components C and C of a system S,
i j
Finally, in Section 4, we summarize our results and the change propagation probability from C to C is
i j
discuss the directions for future research. denoted by cp and defined as the following conditional
ij
probability
2. Background
cp = Pr(([C]≠[ C’])|([C]≠[C’])∧([S]=[S’])), (1)
ij j j i i
2.1. Software Maintenance Risks where [X] denotes the functionality of component/system
X and S’ is the system obtained from S by changing C
Many types of risk are ushered when software i
into C’ (and possibly C into C’ as a consequence).
systems undergo maintenance. They are similar to those i j j
To estimate the change propagation probabilities, we
we face when developing new software systems, but with
first analyze the architecture of the system under
different level of risk. These types of risk are [16]:
investigation using a structural diagram or a class
• Project risk— Maintenance project cannot be carried
diagram. From these artifacts, we can identify the
out within the budget or on time.
components and the connectors of the component-based
• Usability risk— Systems will cause problems and
system architecture. Then, we analyze message protocols
failures after the maintenance is conducted.
between every pair of components in the system which
5
provide us with the messages exchanged between Shotgun surgery is a phenomenon when every time a
components C and C. With the help of case tools, we can change is made to a component many little changes need
i j
get message sets for any pair of components in the system to be made to a lot of different components [5]. For
[2]. This information can also be obtained from static example, whenever we change a database we must
analysis tools of the source code. change several components. To identify a shotgun smell
An architecture can be seen as a collection of using the CP matrix, we examine if we have high values
components Ci, i=1,…,N. With every component Ci, we in a row corresponding to a component Ci. Changes to
associate the set V of the interface elements of the such a component need to be avoided because they
i
provided functions of C. We determine the usage propagate throughout the system.
i
coefficient value πij for every interface element ν∈V Thus, maintainability-based risk is proportional to:
v i
α Divergent change * Shotgun surgery
and every other component C, j≠i. They take binary
j
values: α Average (columns CP) * Sum (rows CP)
• πij =1, if the interface element ν provided by C is 1 N N
v i α ∑cp . ∑cp (3)
required by C. This means that any signature change in N ij ij
j i=1 j=1,j≠i
component C associated with interface element ν will
i
propagate to component C. We use equation (3) to estimate components’
j
• πij =0, otherwise. maintainability risk of the original system and the
v
refactored system after applying a design pattern. As a
Hence, for every pair of components C and C, i≠j,
i j case study, we use an open source calendar and task
the change propagation probability cp can be estimated
ij tracking software written in Java [17]. The design of the
based on the values of the usage coefficients π by [1] :
iνj calendar depends on MVC (Model view controller)
1 design pattern. We studied two versions of the calendar.
cp = ∑πij , (2) The first version implements only the view and the model
ij |V | v
i ν∈Vi of the MVC design pattern. The second version
incorporates the controller. Due to the space limitation,
only the results of the estimation procedure are presented.
3. Maintainability Based Risk
The details of the case study will be presented in the
We define maintainability-based risk as a poster.
combination of two factors: the probability of performing
maintenance tasks and the impact of performing these
tasks. In this paper, we limit our scope to refactoring
activities that are used to reorganize the system in order
to make it more adaptable to add requirements or improve
its quality. Accordingly, maintainability-based risk for a
component is defined as:
Probability of changing the component * Maintenance
impact of changing the component.
We use bad smells of the architecture to estimate
components’ maintainability-based risk. In particular, we
consider two smells: divergent change and shotgun
surgery.
Divergent change is when one component is
commonly changed in different ways for different reasons

[5]. For example, we have to modify the same component
whenever we change the database or add a new Figure 1. Components maintainability-based risk for the
calculation formula. To identify a divergent change smell case study
using the CP matrix, we examine if we have high values
Figure 1 shows components maintainability-based
in a column corresponding to a component C. Such a
i risk for the case study before and after implementing the
component is likely to undergo frequent changes in the
controller of the MVC pattern. We can identify that
maintenance phase due to changes in other components.
errmsg is the most risky component. This component is
responsible of showing an error message whenever an
6
exception occurs. The risk factor of this component is not [3] Alexander, C., S. Inshikawa, M. Silverstiein, M.
affected by adding the controller class of the MVC Jacobson, I. Fiksdahl-king, and S. Angel. “A Pattern
pattern because this modification does not address the Language”, Oxford University Press, New York, 1977.
errmsg component. However, there are improvements in [4] Cortellessa V., K. Goseva-Popstojanova, K. Appukkutty,
the maintainability-based risk of some components (e.g. A. Guedem, A. Hassan, R. Elnaggar, W. Abdelmoez, and
borg, apptgui, and tdgui). We restrict the analysis to the H. Ammar, “Model-Based Performance Risk Analysis”,
IEEE Transaction on Software Engineering, Vol.31,
components that existed before adding the controller to
No.1, January 2005, pp.3-20.
the MVC pattern. The biggest improvement in
[5] Fowler M.and Beck K, Refactoring: Improving the Design
maintainability risk factor is in borg component. This is a
of Existing Code, Addison-Wesley, 2004.
result of adding the controller class, as it causes the
coupling of the borg component to decrease because it is [6] Gamma E., R. Helm, R. Johnson and J. Vlissides,
"Design Patterns: Elements of Object-Oriented Software",
redirected to the added controller class. On the other
Addison-Wesley, 1995.
hand, this modification causes other components to be
[7] Goseva-Popstojanova K., A. Hassan, A. Guedem, W.
more coupled (e.g. taskmodel and taskgui ) because they
Abdelmoez, D. Nassar, H. Ammar, A. Mili,
need to interact with the added controller class. As a
“Architectural-Level Risk Analysis using UML”, IEEE
result the maintainability risk factor of these components
transaction on software engineering, Vol.29, No.10,
is increased.
October 2003, pp. 946-960.
[8] IEEE Standard for Software Maintenance, The Institute of
4. Conclusion
Electrical and Electronics Engineers, Inc.,New York,
In this paper, we introduce the concept of 1998.
architectural level maintainability-based risk assessment. [9] IEEE Standard Glossary of Software Engineering
Maintainability-based risk is defined as a combination of Terminology, The Institute of Electrical and Electronics
two factors: the probability of performing maintenance Engineers, Inc.,New York, 1990.
tasks and the impact of performing these tasks. We [10] Kerievsky J., Refactoring to Patterns, Addison-Wesley,
present an estimation procedure based on change 2004.
propagation probabilities using architectural information [11] Muthanna S., K. Ponnambalam, K. Kontogiannis and B.
of the system. We discuss its capability to assess the Stacey, “A Maintainability Model for Industrial Software
effect of applying design patterns on the components Systems Using Design Level Metrics”, Seventh Working
Conference on Reverse Engineering (WCRE'00),
maintainability. Maintainability-based risk assessment
Brisbane, Australia, November 23 - 25, 2000
can be used to guide software maintenance management.
Also, it can identify the risky parts of the system, so that [12] NASA Technical Std. NASA-STD-8719.13A, Software
Safety, 1997.
they can be assigned to the most experienced maintainers.
http://satc.gsfc.nasa.gov/assure/nss8719_13.html
Among our venues of future research, we plan to
[13] Oman, P. & Hagemeister, J. "Constructing and Testing of
carry out more experiments to examine how other design
Polynomials Predicting Software Maintainability."
patterns affect the maintainability-based risk of the
Journal of Systems and Software 24, 3 (March 1994): pp.
software components. We also plan to automate the 251-266.
computation of the maintainability-based risk by
[14] Pigoski T.M., Practical Software Maintenance: Best
extending the Software Architectures Change
Practices for Managing Your Software Investment, John
Propagation Tool (SACPT) [2]. Wiley & sons, 1996.
References [15] Prechelt, L.; Unger, B.; Tichy, W.F.; Brossler, P.; Votta,
L.G.; “A controlled experiment in maintenance:
comparing design patterns to simpler solutions”, IEEE
[1] AbdelMoez W., M. Shereshevsky, R. Gunnalan, H.H.
Transactions on Software Engineering,Vol. 27, No. 12,
Ammar, Bo Yu, S. Bogazzi, M. Korkmaz, A. Mili ,
Dec. 2001, pp.1134-1144
“Quantifying Software Architectures: An Analysis of
Change Propagation Probabilties”, ACS/IEEE [16] Sherer S., “ Using Risk Analysis to Manage Software
International Conference on Computer Systems and Maintenance ,” Software Maintenance: Research and
Applications (AICCSA 05), Cairo, Egypt, January 3-6, Practice, Vol. 9, 345-364, 1997.
2005. [17] Source Forge Project: BORG Calendar
[2] Abdelmoez W., R. Gunnalan, M. Shereshevsky, H.H. http://sourceforge.net/projects/borg-calendar/
Ammar, Bo Yu, M. Korkmaz, A. Mili, “Software
Architectures Change Propagation Tool (SACPT)”, Proc.
20th IEEE International Conference on Software
Maintenance (ICSM 2004), Chicago, IL, September 2004.
7
Visualizing Dynamic Data Dependences as a Help to Maintain Programs
Franc¸oiseBalmas HaraldWertz RimChaabane
LaboratoireIntelligence Artificielle
Universite´ Paris 8
93526Saint-Denis(France)
ffb,hw,[email protected]
Abstract gorithmicandoptimizationproblemswhicharisewhenma-
nipulatinghugeamountsofdata.
Thispaperisonaprojecttoevaluatetheimpactofvisu- To evaluate our approach, we applied our tool to a ver-
alizingdynamicdatadependencesinthecontextofmainte- sion of the classical AI Blocks World program [4]. In our
nanceactivities. version, the world is a table with different objects on it
Ourworkisbasedonpreviousworkindisplayingstatic which can be manipulated by a one-handed robot. Basi-
datadependencesandonexperiencewithlargesetsofde- cally, the program presents itself as an interpreter the user
pendencedisplayingstrategiesthatweadaptedtodealwith interacts with in order to create objects, make the robot
problemswheredynamicinformationiscrucial. We devel- movethemtootherplacesoraskforinformationaboutthe
oped a prototype around a Lisp interpreter and applied it currentstateoftheworld.
toahighlycomplexAIprogram. Thispermittedustobuild The program is around 1200 LOC long1 and includes
efficientvisualizationsandtoevaluatethebenefitsofusing morethan125functionsandmacros,manyglobalvariables
dynamic dependences for program understanding, debug- modifiedthroughpointers,indirectrecursivecalls,thuslong
ingandcorrectnesschecking. circularities,andescapes(i.e.nonstandardreturncontrols).
In this paper, we present our prototype, detailing espe- Itevolvedovertime,sincefirstdevelopedforteachingpur-
cially the different visualizations we introduced to allow pose and then modified several times to add further rea-
users to deal with hard to understand programs, and we sonningcapabilities. Allthesefeaturesmakethisprogram
discuss how dynamic dependences permit to see what re- rather complex, hard to understand for newcomers to the
allyhappensduringprogramexecutions. programanddifficulttomaintainfortheoneofuswhode-
velopedit.
In this paper, we report on this evaluation, discussing
boththedifferentkindsofvisualizationswedefinedandthe
1. Introduction
waytheyletusseewhathappenedduringexecutionofour
program, helping us to understand, debugand check it for
Inthepast, weusedstaticdatadependencestohelpun- correctness.
derstand and document programs [1], and developed dis-
playingstrategiestodealwithlargesetsofdependences[2].
2.Thetool
In this context, we showed that visualizing sample values
ofvariables,forawellchosenexecution,wasveryefficient
tohelpunderstandwhataprogramdoesandhowitworks. Ourtoolreliesonthreemodules: amodifiedLispinter-
That’swhywe decided to explorecomputing dynamicde- preter(a Cversionisunderconstruction), a database(cur-
pendencesand to evaluate the benefits of visualizing them rentlyaLispprogram)andaGUI(implementedinTcl/Tk).
forthoseactivitieswhereknowledgeaboutgivenexecutions We modified a Lisp interpreter to make it, in addition to
is crucial, that is program understanding, debugging and normalexecutionofprograms,extractdependencesatrun-
correctnesschecking. time. These dependences are sent to a Lisp program that
actsasadatabase,storingthedependencesandproducing,
For the sake of evaluation, we developed a prototype
aroundtheLisplanguage;actually,modifyinganinterpreter
1NotethatLOCinLispisverydifferentfromLOCinmoreusualpro-
ismuch easier thanmodifying a compiler,andhard to un-
gramminglanguagessuchasC,becauseofthecompactnessofcodeand
derstandLispprogramsarestillsmallenoughtoprevental- thepowerfullfunctionalprimitivesitoffers.
8
(de square (a) 5 3
(* a a)) Toplevel Toplevel
(de som2 (x y)
(+ (square x) (square y)))
A2 = 5 A1 = 3
? (som2 3 5)
= 34
som2
Figure1.Samplecode
R-som2 = 34
ondemand,thecorrespondinggraph–indot[3]format.Fi-
nally,a Tcl/TkGUI displaysthe graph, usingmechanisms Figure 3. Data dependence graph with only
toreduceitssize,andallowsuserstointeractwithittotune thetoplevelcallvisible
severalkindsofvisualizations.
Thefullsetofdependencesforagivencallisunlikelyto
bedisplayedasis,sinceitisusuallytolargetobereadable.
son, we introduced a tagging mechanism to classify func-
We thus group together nodes (that is pieces of code) be-
tions into control structures (they are functions in Lisp),
longingtothesamefunctioncall. Forexample,inthesam-
primitives (those standard functions that are implemented
plecodeofFig. 1,wichcomputesthesumofthesquareof
in Lisp itself) routines (small reusable functions related to
two numbers, we have nodesbelongingto the two calls to
theprogramathand)anduserfunctions(alltheremaining
functionsquareandweaggregatethemtoformtwogroups.
functions). ThenextSectionwillshowdifferentvisualiza-
Thesetwogroups,aswellasothernodes,belongtofunction
tionsthatdependonthisclassificationtofilteroutgivenset
som2 andare aggregatedto form the maingroup. We can
ofcalls.
thendisplaydependences showingonly these groups, thus
only the calls, andthe dependences betweenthem. Fig. 2
3.Visualizations
gives the corresponding graph for the call (som2 3 5) and
shows how values are transmitted between calls. Alterna-
tively, we can also get a graph with only the toplevel call Inthissection, weintroducethedifferentvisualizations
visible (see Fig. 3), showing just input and output of the ourtoolofferstohelpusersanalyzeprograms.Thefirstfour
whole program. Such views are very helpful when global arevariantsofcallgraphs:wenoticedthatnavigationinside
variables are used and modified by the program (see Sec- data dependences graphs is often tedious and call graphs
tion4). provide a good ’map’ to support this navigation. The last
fourvisualizationsarevariantsofdatadependencegraphs.
ENV
Callgraph Suchavisualizationoffersaglobaloverview
ofthefunctionstheprogramevalutedandthewaytheyare
A2 = 5 A1 = 3
organized. It also permits the user to ask for a given data
dependencegraphbyinteractivelyselectingacall: thiscall
som2 then becomes the focus of the displayed data dependence
graph(seebelow).
A1 = 5 R-som2 = 34 A1 = 3
User call graph This is a restricted version of the call
square square graphjustdescribed,whereonlyuserfunctionsareshown.
This permits to get a graph with much fewer calls – from
more than 3600 calls in the whole call graph for a ‘move-
R-square = 25 R-square = 9
object’instructiontoourrobotwecouldgetdowntoabout
30calls –, thus more easily readable. This also permits to
Figure2.Datadependencegraphwithallcalls
getaglobaloverviewofthemainfunctioncallsfromapro-
visible
grammer’sconceptualperspective.
For a large program, the number of function calls may One leveluser call graph This visualizationis a mixof
becomealsotoolargetogetreadablegraphs. Forthisrea- thetwopreviousones:acallgraphbeginningatagivenuser
9
functionandendingatthenextcallofauserfunction. That a data dependence view where only these calls are shown
is: whentraversingthecalltree,westopdrawingthegraph whileallothersarehidden.
whenwereachleavesorweencounteruserfunctions. This
visualizationgivesallnecessarydetailsbutlocallybounded
Thedifferentvisualizationspresentedinthissectionwere
byuserfunctions.
inspired by the needs we encountered during the process
oftryingto understand andevolvea rather largeandcom-
Return graph The Blocks World program uses inten- plexprogram.Theyshowedtobeveryusefulforinteractive
sivelythe‘escape’mechanismofLisp2 thatallowsthepro- goal-directed exploration. In the next Section we will dis-
gramcontroltodirectlyreturntoacallingfunctionupinthe cussmorespecificallytheuseofdynamicdatadependences
calltree. Itisthenoftenhardtoconceptuallyfollowwhere fordifferentprogrammingactivities.
the control is supposed to get back and how the program
issupposedtocontinueaftertheactivationofthe‘escape’.
4. Dynamic data dependences for program-
That’swhywe integrated the possibility to extendthe call
ming activities
graphs with the return graph: whenever control gets back
toanotherfunctionthantheonethatcalledthecurrentone,
thereturnarrowisdisplayedinred. Program discovery The first context where our visual-
izations proved to be useful is program discovery, that is
thetaskaprogrammerfaceswhens/hehastogetaquainted
Data dependence graph This visualization providesthe
withaprograms/hedidn’timplementher/himself. Evenif
standard data dependence graph we introduced in Section
interactingwiththerobot,ontheLispterminal,waseasyto
2, with either only the toplevel call, or all calls. It may
grasp, trying to understand how the program works in or-
focusonagivencall,thiswayconsideringonlythesubtree
der to handle object creation, placement and moving was
beginningatthiscall.
anotherquestion!
Adatadependencegraphfocusedonthetoplevelcallisa
Filtered data dependence graphs This visualization is goodviewtostartwith,sinceitshowshowglobalvariables
obtained whenever classes of functions are tagged to be aremodifiedduringthecall.Forexample,Fig.4showshow
filtered out. It is especially useful with data dependence the table, the object list and the object itself are modified
graphs where all calls are to be displayed, since it per- duringthe creationofanobject, showingthiswaythereal
mitstohidefunctionsoflesserinterestforthetaskathand. effectofthe call. Theuser-call-graphpermitted us thento
Forexample,tofocusonthedependencesfromaprogram- getaglobaloverviewoftheactionsperformed,whiletuning
mer’sconceptualperspective,itisusefultofilteroutcontrol data dependencegraphs for these differentactions gaveus
strucutres,primitivesandroutinesthatoftenfillagraphwith futherinformationonhowtheyaffecttheglobalvariables.
irrelevantinformation.
Finding bugs While working on the discovery of the
Firstlevelgraphs Thetwobasicpossibilitiestoexamine
BlocksWorldprogram,weencounteredgraphswithwrong
calls–onlythetoplevelcallvisible, oreverycallvisible–
variablevalues,incorrectnumberoffunctioncallsorunex-
provedtobeinsufficientinseveralcases,sincegivingeither
pected calls. Refining different graphs, we could navigate
toofewortoomanydetails.Weextendedourtoolfunction-
backwardandforwardtofindthesourceoftheproblem.
nalitieswithaviewwherethefunctioncallfocuseduponis
Forexample,wenoticedthatwhenfindingaplacewhere
visiblealongwitheachfirstlevelcall. Thisallowstheuser
to put a square object of 2x2, the robot only checked
toexaminehowagivenaction–implementedbyafunction
threepositionsonthetable,whileofcourseitshouldhave
call–isdecomposedintosmalleractions,withouttheneed
checkedat leastfour. This exampleshowsthatour visual-
toexaminetheactualcodeofthecall.
izations may directusers to problems theydon’tevensus-
pect: we didn’tsearch for any problem in finding a place,
Setsofcalls Sometimes,theautomaticallybuiltviewswe wejustsawtherewasone. Wecouldthendetectmorepre-
just described are not satisfying because centered on one ciselywhytherewasthisproblemandhowtosolveit.
call,whilewemightneedtheabilitytoseeasetofspecific
calls, especially to examine the values of global variables
Correctnesschecking Asanextensionofthetwoformer
before and after these different calls (see Section 4). For
points, we also used our views to verify that the program
this reason, selecting a few calls on a call graph results in
was behavingproperly. Forinstance, careful inspectionof
2Sometimescalled‘catch-and-throw’,thismechanismissimilartothe visualizationsoftheprogram’sexecutionaftercorrectionof
‘setjmp-longjmp’mechanismofC. the’findingplace’bugpermittedustoseeitscorrectness.
10