• No results found

Coordinated Visualization of Aspect-Oriented Programs

N/A
N/A
Protected

Academic year: 2021

Share "Coordinated Visualization of Aspect-Oriented Programs"

Copied!
8
0
0

Loading.... (view fulltext now)

Full text

(1)

Coordinated Visualization of Aspect-Oriented Programs

´

Alvaro F. d’Arce1, Rog´erio E. Garcia1, Ronaldo C. M. Correia1

1Faculdade de Ciˆencias e Tecnologia

Universidade Estadual Paulista “J´ulio de Mesquita Filho” (UNESP) Rua Roberto Simonsen, 305 – 19.060-900 – Presidente Prudente – SP – Brazil

alvaro@darce.com.br, {rogerio,ronaldo}@fct.unesp.br

Abstract. Software Visualization provides support to program analysis by visual presentation, improving cognition to comprehension tasks. Focusing specifically on aspect-oriented source code, it’s needed to map features of Aspect-Oriented Program (aspects and advices) into visual presentations, providing suitable vi-sualization for understanding how aspects crosscut usual classes. In this paper we present a proposal of visual mapping for aspect-oriented programs aimed to support Program Comprehension by improving cognition.

1. Introduction

Aspect-Oriented Programming (AOP) supports the modularization of crosscutting

con-cerns by mechanisms that make possible the addition of behavior to selected elements of the programming language semantics, thus isolating implementation that otherwise would be spread and tangled throughout the base code [Kiczales et al. 2001]. However,

AOPnew features can increase the structural complexity of software systems, increasing

the difficulty to comprehend their architecture and structure, bringing up challenges to the comprehension of Aspect-Oriented Programs.

Software Visualization is an alternative approach to help software engineers to cope with structural complexity due to fragmentation and the need to compose fragments. However, the visualization must be able to deal with an Aspect-Oriented Program ef-fectively. The visualization process deal with gathering data, its organization and map-ping into visual structures to generate visual representations [Card et al. 1999]. Following such process, it is needed not only to have specific visual mapping for Aspect-Oriented

Programs, but also have mechanisms to gather and to organize data representing AOP

features.

Different techniques and tools have been proposed to support software

vi-sualization. For example, hierarchical structures can be visualized using Treemaps

[Johnson and Shneiderman 1991, Bederson et al. 2002, Pfeifer and Gurd 2006],

Poly-metric Views [Lanza 2004, Carneiro et al. 2008], andHyperbolic Trees[Munzner 1998]

(this last one for large structures); Bars and Stripes might be used for inter-relational structures visualization [Baldwin et al. 2009]. Besides, some extensions have been

pro-posed, like UML 3Dto visualize packages, classes and methods [Gall and Lanza 2006]

andDependence Graphsto inter-dependency level visualization [Wurthinger et al. 2008] can also be used to build visual representations to support comprehension process. These

visualization techniques can represent, by themselves, only theaspectsbefore the

wea-ving– they cannot represent the resulted code of an Aspect-Oriented Program after the

(2)

advised relations ofAOP[Pfeifer and Gurd 2006], but it is a user based mining by

search-ing regular expressions representsearch-ingaspectsand classes elements.

We have developed a visual mapping tackling Aspect-Oriented Program. To present our approach, the remainder of this paper is organized as follow. In Section 2 it’s presented some considerations about Aspect-Oriented Programs and features to its visualization. In Section 3 is presented the visual mapping for Aspect-Oriented Programs and the tool implemented. And in Section 4 the final remarks are presented.

2. Aspect-Oriented Program

AOPtackles crosscutting concerns problem supporting the definition units of

implemen-tation (aspects) that cut across the system units (base code), providing the behavior

ex-pected [Kiczales et al. 2001]. A genericAOPlanguage should define elements enough to

combineaspects and code base. The following elements were pointed out: a model to

describe base code points where additional behavior may be defined, namedjoinpoints;

a mechanism to identify thesejoinpoints; units that encapsulate bothjoinpoint

specifica-tions and behavior enhancements; and a process to combine both base code andaspects,

named the weaving process [Elrad et al. 2001]. Aspects and how they crosscuts a base

code are important elements that should be mapped into visual structures.

There are several programming languages extensions to supportAOP, one of them

is AspectJ: an extension of the Java language to supportAOP. In AspectJ are defined new

constructions toaspect, advices, andpointcuts. Aspectsare units that combinejoinpoint

specifications and pieces ofadvice. Also, aspects can declare members – attributes and

methods – to be owned by other types, what is called inter-type declarations.Advicesare

pieces of code joined to specified points in the program. Before, after and aroundadvices

are method-like constructs that can be executed before, after and in place of thejoinpoints,

respectively. TheAOPruntime invokes adviceautomatically when thepointcut matches

thejoinpointdefining the crosscutting behavior.

Listing 1. Piece of source code aspect-oriented

1 p u b l i c c l a s s A c c o u n t { 2 p r i v a t e f l o a t f u n d s ; 3 p u b l i c A c c o u n t (f l o a t f u n d s ) { t h i s. f u n d s = f u n d s ; } 4 p u b l i c f l o a t g e t F u n d s ( ) { r e t u r n f u n d s ; } 5 p u b l i c v o i d w i t h d r a w (f l o a t v a l u e ) { f u n d s −= f u n d s ; } 6 p u b l i c v o i d d e p o s i t (f l o a t v a l u e ) { f u n d s o += v a l u e ; } 7 } 8 p u b l i c a s p e c t R e g i s t e r { 9 p o i n t c u t w i t h d r a w ( A c c o u n t a c c , f l o a t v a l u e ) : 10 t a r g e t( a c c ) && a r g s( v a l u e ) && c a l l(∗ A c c o u n t . w i t h d r a w (f l o a t) ) ; 11 12 p o i n t c u t d e p o s i t ( A c c o u n t a c c , f l o a t v a l u e ) : 13 t a r g e t( a c c ) && a r g s( v a l u e ) && c a l l(∗ A c c o u n t . d e p o s i t (f l o a t) ) ; 14 15 a f t e r( A c c o u n t A c c o u n t , f l o a t v a l u e ) r e t u r n i n g( ) : w i t h d r a w ( A c c o u n t , v a l u e ) { 16 S y s t e m . o u t . p r i n t l n ("Withdraw - Value: " + v a l u e ) ; 17 } 18 a f t e r( A c c o u n t A c c o u n t , f l o a t v a l u e ) r e t u r n i n g( ) : d e p o s i t ( A c c o u n t , v a l u e ) { 19 S y s t e m . o u t . p r i n t l n ("Deposit - Value: " + v a l u e ) ; 20 } 21 }

In Listing 1 is shown pieces of source code of an Aspect-Oriented Program. In

(3)

and twoadvicesto register the transaction after calls towithdraw()anddeposit()methods.

The AspectJadviceweaver statically transforms the program so that at runtime it behaves

according to the language semantics, as show in Figure 1.

<<after-returning>>

2 1

Withdraw

Deposit <<after-returning>>

Figure 1. Execution model after weaving

To visualize Aspect-Oriented Programs, specifically AspectJ programs, it’s inter-esting that a Software Visualization tool highlights (in more than one visual scenario)

program characteristics likeaspects, advices and pointcuts, with the aim to let the user

view how anaspectcrosscuts one or more classes or how much a class is modified by one

or moreaspects, or how the code is tangled and spread by the weaver.

After the weaving and compilation processes, the specific data of an Aspect-Oriented Program are tangled and spread in bytecode, identified by specific signatures.

By these signatures, it’s possible to obtain data about programaspectsandadvices(two

important items in an Aspect-Oriented Program visualization) and organize them in a graph, along with the other program elements (like packages, classes and methods) to obtain data enough to generate the visual representations.

3. Aspect-Oriented Program Visualization

We proposed a multiple view approach to visualizeAOP, as depicted in Figure 2.

Struc-tural Presentationaims to show how the source code is organized in classes andaspects;

Inter-Units Presentation aims to show crosscutting between method and advices; and

Intra-Method Presentation aims to show the behavior intra-method after weaving pro-cess. One might observe in Figure 2 that visualizations are coordinated to allow exploring different levels of view.

Intra-Method Presentation (Graph View) Inter-Units Presentation (Hyperbolic View) Structural Presentation (Treemap View)

Figure 2. Presentations Schema

For each presentation was chosen suitable technique according to its pourpose: for

example, there are several techniques for hierarchical views, and we have chosenTreemap

to represent the program’s hierarchical structure includingaspectsandadvices(Structural

Presentation). Hyperbolic view was chosen to represents classes dependences coupled withaspectscrosscuts (Inter-Units Presentation), andControl Flow Graph (CFG) to vi-sualize the advised source code representing the behavior of a piece of code, showing

advicesover the code after the weaving process (Intra-Method Presentation). By the co-ordination of these three visual presentations, Aspect-Oriented Program can be visualized

(4)

in hierarchical structure, classes dependence,aspectscrosscuts, tangled code and spread code. A Software Visualization tool has been developed according to the visual mapping proposed, and it is shown in the following.

3.1. Sof tV izOAH: The Visualization Tool

The tool Sof tV izOAH consists in a standalone desktop software, and its architecture,

shown in Figure 3, is organized onto three layers: Dataset, Control and Visualization.

In addition, the tool allows visualizing test case results as described in the following. TheDataset layer is aimed to static and dynamic analyses creating data sets necessary

to generate the visualizations. TheReading Modulereads a program’s bytecode and

an-alyzes classes,aspectsand test cases. TheStatic Analysisreads classes, aspectsand test

cases (using JUnit). During the reading, the data flow stream of each unit is analyzed

and put into a data structure representing aCFG, while new instructions are inserted in

each unit code (instrumentation technique, containing methods andadvicescalls,

provid-ing feedback to allow monitorprovid-ing test cases by Dynamic Analysis), and it’s built a list

with all classes, aspects and their information obtained by the instrumentation. From

this list, it’s built a hierarchical structure, which will be used to generate the Treemap

visual presentation. Also, informations like superclass references, variable types, meth-ods parameters and returns, and others are grouped into a node table and an edge table

to mount a Dependence Graph (by the interpretation of these tables and the

organiza-tion of the links among the nodes), which is used to generate theHyperbolicvisual

rep-resentation. While doing a Structural Test, Dynamic Analysis monitors test cases and

registers each visited portion of code of each code unit, making a execution path. From

the path, the coverage criteria are verified to determine the test’s Result – each

crite-rion has its own standard to verify whether the test has been completely or partially met. During a test execution, the instrumentation sends to the tool information about each visited portion of code. This information is stored to be used by each visual representa-tion. By these two steps analyses, the tool gathers data to generate visual representations [Martins 2007, Trevisan 2010, Dutra 2010].

At Control layer the Integration Module organizes data obtained from Reading Moduleto generate visual presentations (all three presentations are generated at the same time) and provides mechanisms to coordinate them. These mechanisms capture interac-tion with visual presentainterac-tions to reflect them into another view. An event, caused by an

user interaction in a specific visualization, is captured. From this event, the Integration

Moduleobtains data about the selected unit of the program (class, method,aspector

ad-vice). The data structures stored in theDatasetlayer (i.e., the graph data structure, the list

containing information from the instrumentation, the hierarchical structure and the node and edge tables) are used to do the coordination among the visualizations. Then, an event is sent to each other visualization in the Visualization layer, informing the new state of the visual representation (i.e., highlighted items), performing, this way, the coordination. TheVisualizationlayer providesCFG, Treemapand Hyperbolicvisual

presenta-tions, as explained in Section 3. In each visual presentation,aspectsare highlighted. In

theCFGvisual representation, basic code blocks are represented by rectangles outlined

by a continuous line, code blocks advised byaspectsare represented by rectangles

out-lined by a dashed line and method returns are represented by rectangles outout-lined by a double line. Inside each rectangle there is a number indicating the code block execution

(5)

Hyperbolic View Treemap View Graph View Integration Module Reading Module JUnit DataSource Data set Cont rol Visu aliza tion Static Analysis Dynamic Analysis Bytecode Structural Test Result

Figure 3. Sof tV izOAH Tool architecture

sequence. Normal code sequences are represented by continuous lines, and exceptions

are represented by dashed lines. All code blocks belong to codes inside methods and

as-pects. If a test case (created by the user) is applied, each rectangle is colored according a gradient from red to green. The more the code block has failed in the test, the redder it’s colored. The more the code block has succeeded, the greener it is colored. Such color mapping allows viewing how succeeded (or failed) a test case covered the source code.

Also, Treemap presents hierarchical structures in constrained and nested

rectan-gles. Each rectangle can represent packages, classes, methods, aspects and advices. A

rectangle size represents the number calls to the represented method oradvice, and the

color represents test case results, just like the referred gradient. In theHyperbolicvisual

presentation, nodes represent whole program classes and aspects, and edges represent

dependency between each class or aspect, i.e. method calls and joinpoints. Each edge

is colored according to their structural tests results. Clicking on an edge, the participant

methods in its test are shown inTreemap. Clicking on a node, it is positioned in the center

of the graph and its representation is highlighted inTreemap. All visual presentations use

the same color mapping, but to highlightaspectselection, a different color is used.

Listing 2. Method calling two “adviced” methods

1 p u b l i c v o i d t r a n s f e r r i n g (i n t s o u r c e N u m b e r , i n t d e s t i n a t i o n N u m b e r , f l o a t v a l u e ) { 2 t r y { 3 a c c o u n t s o u r c e A c c o u n t = g e t a c c o u n t ( s o u r c e N u m b e r ) ; 4 a c c o u n t d e s t i n a t i o n A c c o u n t = g e t a c c o u n t ( d e s t i n a t i o n N u m b e r ) ; 5 i f ( s o u r c e A c c o u n t . g e t B a l l a n c e ( ) >= v a l u e ) { 6 s o u r c e A c c o u n t . w i t h d r a w ( v a l u e ) ; / / ADVICED METHOD 7 d e s t i n a t i o n A c c o u n t . d e p o s i t ( v a l u e ) ; / / ADVICED METHOD 8 } e l s e 9 throw new I n s u f f i c i e n t F u n d s E x c e p t i o n ( s o u r c e A c c o u n t . g e t N u m b e r ( ) , v a l u e ) ; 10 } c a t c h ( A b s e n t A c c o u n t E x c e p t i o n e ) { 11 S y s t e m . o u t . p r i n t l n ( e . g e t M e s s a g e ( ) ) ; 12 } c a t c h ( I n s u f f i c i e n t F u n d s E x c e p t i o n e ) { 13 S y s t e m . o u t . p r i n t l n ( e . g e t M e s s a g e ( ) ) ; 14 } 15 }

(6)

(a)Treemapvisualization (b) Methods of selected class

(c)Hyperbolicprojection (d) CFGvisualization

(7)

In Figures 4(d) and 4(a) are shown theCFGand theTreemapviews from

transfer-Testtest case, which calls transferringmethod – thetransferring method shown in

List-ing 2 callswithdraw anddeposit methods, which are “adviced” as depicted in Figure 1.

Each node inCFGrepresent a code block executed, and their connection represents

pos-sible path execution. All code blocks,advicesand methods are colored according to their

test results, using the same color mapping toCFGand theTreemap. When code block is

selected in the graph visualization, its respective method is selected in theTreemap

visu-alization, and when code block selected contains anadvice, the respectiveadviceis also

selected in theTreemap visualization. The selected rectangle in Figure 4(d) represent a

code block containing the calling towithdrawmethod and itsadvice, and both method and

adviceare highlighted in theTreemap visualization. The graph visualization is showing twoadvices(represented by rectangles with dashed lines) with their respectivepointcuts

(represented by their sequence in the graph) crosscutting a test case with the Account

class. The global view of the graph visualization represents the tangled and spread code.

In the example depicted in Figure 4(d), the code is tangled (advicesamong the code) and

theaspectis thinly spread (advicesare close to each other).

Nodes inHyperbolicview represent classes and aspects, distinguished by

differ-ent colors. Edges represdiffer-ent method calling or aspect crosscutting. By interacting with

Hyperbolic view, one might select classes, aspects and edges between them. When a

class oraspect is selected in theHyperbolicvisualization, the respective class or aspect

is also selected in theTreemap visualization, and its respective methods or advicesare

shown in a separated panel, depicted in Figure 4(b). By selecting an edge in the

Hyper-bolicvisualization, the participating methods oradvicesare also selected in theTreemap

visualization. In Figure 4 is shown the selected classTerminal– moved to center of

pro-jection –, its selection inTreemap visualization, and the list of methods. By interacting

with those visual presentations, one might observe howaspectscrosscut classes.

4. Final Remarks

We proposed a visual mapping to present features of Aspect-Oriented Programs using three coordinated visual presentations. Those visualizations aim to externalize structural

organization, the relations among classes and aspects, and the advised code. By

coor-dination proposed it is possible to highlight selected elements on different detail levels,

allowing the user to gather information aboutaspectand its spreading to the source code.

The visual mapping proposed has been evaluated using some AOPsource code.

One of them is theGanttProject1, originally written in Java that we modified to an

As-pectJ project by factoring some functionalities toaspects(to visualize them in the tool),

resulting in 51305 lines of code at all. According to preliminary evaluation, the tool functionalities are useful to support Aspect-Oriented Program understanding. However, to assess the effectiveness and efficiency of the visual mapping proposed in more realis-tic way, it is needed to conduct a controlled experiment, which will be conducted using an experimentation process. Such controled experiment will be conduct aimed to reveal

defects previously inserted into theGanttProjectsource code.

(8)

References

Baldwin, J., Myers, D., Storey, M., and Coady, Y. (2009). Assembly code visualization

and analysis: An old dog can learn new tricks! PLATEAU ’09 Workshop at Onward!

Bederson, B. B., Shneiderman, B., and Wattenberg, M. (2002). Ordered and quantum

treemaps: Making effective use of 2d space to display hierarchies. ACM Transactions

on Graphics (TOG), 4(21):833–854.

Card, S. K., Mackinlay, J. D., and Shneiderman, B. (1999). Readings in Information

Visualization – Using Vision to Think. MK Publishers Inc.

Carneiro, G., Magnavita, R., and Mendonc¸a, M. (2008). Combining software

visualiza-tion paradigms to support software comprehension activities. In 4th ACM symposium

on Software visualization (SoftVis’08), pages 201–202, NY, USA.

Dutra, L. S. (2010). Visualizac¸˜ao hier´arquica de programas orientados a aspectos. Fac-uldade de Ciˆencias e Tecnologia – Universidade Estadual Paulista “J´ulio de Mesquita Filho”. Technical Report.

Elrad, T., Filman, R. E., and Bader, A. (2001). Aspect-oriented programming –

introduc-tion. Commun. ACM, 10(44):29–32.

Gall, H. and Lanza, M. (2006). Software analysis visualization. 28th International

Con-ference on Software Engineering (ICSE Shangai 2006).

Johnson, B. and Shneiderman, B. (1991). Tree-maps: a space-filling approach to the

visualization of hierarchical information structures. InProceedings of the 2nd

confer-ence on Visualization ’91, VIS ’91, pages 284–291, Los Alamitos, CA, USA. IEEE Computer Society Press.

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W. G.

(2001). An overview of aspectj. ECOOP 2001 – Object Oriented Programming,

2072(2001):327–354.

Lanza, M. (2004). Codecrawler - polymetric views in action. In19th International

Con-ference on Automated Software Engineerings, pages 394–395.

Martins, R. M. (2007). Teste estrutural de programas orientados a aspectos. Faculdade de Ciˆencias e Tecnologia – Universidade Estadual Paulista “J´ulio de Mesquita Filho”. Technical Report.

Munzner, T. (1998). Exploring large graphs in 3d hyperbolic space. IEEE Computer

Graphics and Applications, 18(4):18–23.

Pfeifer, J. and Gurd, J. (2006). Visualization-based tool support for the development of

aspect-oriented programs. AOSD.

Trevisan, M. (2010). Visualizac¸˜ao de software orientado a aspectos usando visualizac¸˜ao hiperb´olica. Faculdade de Ciˆencias e Tecnologia – Universidade Estadual Paulista “J´ulio de Mesquita Filho”. Technical Report.

Wurthinger, T., Wimmer, C., and Mossenbock, H. (2008). Visualization of program

References

Related documents

In the case of the Neuro-LP optimization modules, part of the Neuro-DEA model, a structure similar to the ANN is used, where the synaptic weights (obtained in the training step)

The Highways Agency revised grouting specification for bridges requires the use of corrosion- resistant ducts which for internal tendons are bonded to the surrounding concrete.

In the past, state psychology boards attempted to limit the use of psychological assess- ments to licensed psychologists ( Naugle, 2009 ). While some professional groups are seeking

This security problem results from the violation of one of the principal security goals of the content creator (The site structure (or physical media) should not use any

In order to successfully analyse impartiality, neutrality and independence of humanitarian aid, this paper analyses to what extent these humanitarian aid principles

model? Are both entities needed in a specification model? name address driver's licence birthdate : Date Customer Info Customer.. 11d) (5 marks) Extend the model below to

when one knows that their privacy can be infringed upon will eventually result in no privacy expectations as technology becomes more invasive. For instance, innocent

This action plan sets out our approach to achieving a core national infrastructure that will support the delivery of the other three strands of Scotland’s Digital Future –