SEKE 2012 Proceedings - Knowledge Systems Institute

The remainder of this paper is organized as follow. Section
2 presents some considerations about Aspect-Oriented
programs and also some related works. Section 3 presents
some considerations about the developed tool to apply the
proposed visual mapping and its architecture. Section 4
presents some applications of the proposed approach. Finally,
the final remarks and future works are presented in
Conclusions section.
2 Background
Kiczales et al. [14] argue that Object-Oriented Programming
(OOP) is a technology that can aid Software Engineering,
because the underlying object model provides a
better fit to real domain problems. But they pointed out
programming problems. For instance, OOP techniques are
not sufficient to clearly capture important design decisions
about different concerns implemented in a software system
– some requirements (usually non-functional) cannot be
clearly mapped to isolated units of implementation. Mechanisms
to persist objects in relational data bases and security
issues are examples of those concerns, usually named crosscutting
concerns, because they tend to cut across multiple
units of implementation [8].
Aspect-Oriented Programming (AOP) tackles the crosscutting
concerns problem supporting the definition of implementation
units (aspects) that cut across the system units
(base code), composing the expected behavior [14]. An
AOP language must define elements in order to combine
functional and non-functional code (aspects and base code).
Such elements establish a model to define points in the base
code where additional behavior may be defined (pointcuts);
a mechanism to identify these points (join points); encapsulation
units for these points specifications and behavior
enhancements (aspects); and a process to combine aspects
with the base code (weaver)[8].
Functional requirements (like business rules) are coded
inside a component language (e.g., Java) and non-functional
requirements (e.g., logging, persistence, connection and
transaction routines) are coded inside aspects. The weaver
process joins the component language code with the aspects
code, resulting in a runnable program. The language employed
as case study in this paper is the AspectJ, which is
an extension of Java language to support AOP.
An Aspect-Oriented program was used for this paper
to generate views. It was designed and coded using AspectJ
[16] and represents an on-line music store simulation,
in which a billing service observes song-play events to bill
the customer. An aspect implementation of the Observer
design pattern [11] was used to add billing and statistics.
Additionally, aspects track plays and lyric-shows events
were coded to charge the customer appropriately and to update
a list of the most frequently played songs.
One may observe the statical relations among aspects
and classes, but it is not possible to conclude how Aspects
crosscut a base code. Their relationships are important
elements to Program Comprehension and should
be mapped into visual structures to improve the cognitive
process, which motivated extending Software Visualization
techniques to deal with such elements.
After weaving and compilation processes of an AspectJ
program, specific structures of an Aspect-Oriented program
are tangled and spread in the bytecode. However, compilers
use marks about aspects and their advices that can be retrieved
by analyzing their signatures. The AspectJ compiler
stores its components’ signatures with specific markups,
making it possible to obtain and to organize data about a
compiled AspectJ program to a visual exploration.
2.1 Related Works
In Aspect Programs some interesting program elements
can be highlighted by a Software Visualization tool in certain
visual scenarios, such as, aspects, advices and pointcuts.
It allows viewing how an aspect crosscuts one or more
program structures, how much a program structure is modified
by one or more aspects, the resulting tangled and spread
code after the weaving process.
A TreeMap extension was proposed to show advised relations
of Aspect-Oriented programs [18], but it consists in
an user-based mining task by searching regular expressions
representing aspects and classes elements. Another tool,
AspectJ Development Toolkit (an Eclipse toolkit for AOP),
has the AJDT Visualizer [5]–aBars and Stripes visual representation
of classes and aspects, highlighting its affected
lines by aspects – but no visualization about how an aspect
produces specified behavior in a class or other aspect.
SourceMiner [4] can be used to enhance concern modularization
analysis, but the concerns (focusing in AOP) need to
be manually mapped. Another visualization tool, named
AspectMap [9], shows implicit invocations in the source
code. It allows visualizing join points shadows where aspects
are specified to execute, showing the advice type and
specified precedence information for a given join point.
In the next section we describe the coordination model
proposed, the software visualization tool that implements
such a model and its architecture, and how the visual mapping
is performed.
3 The Software Visualization Tool
In this paper we propose a software visualization tool,
called SoftV iz OAH , which employs a coordinated multiple
views (CMV) approach to visualize Aspect-Oriented
programs. The CMV schema is depicted in Figure 1. In
169