SEKE 2012 Proceedings - Knowledge Systems Institute

Table 1. Behavioral Rules in LSD [9].
Rule Description
call(method)
xcall(method)
get(field)
xget(field)
set(field)
xset(field)
It must have a method call within the def ned
scope.
It must have a method call exclusively within
the def ned scope.
It must have a field state access within the
def ned scope.
It must have a field state access exclusively
within the def ned scope.
It must have a field state change within the
def ned scope.
It must have a field state change exclusively
within the def ned scope.
pect code, we can observe the xcall behavioral rule in line
14. Such a rule states that the around advice of aspect Update
must have a call to Display.update () method. Also, since the
xcall rule starts with an ‘x’, the method Display.update ()
cannot be called in other place inside the scope of the design
rule interface Changed.
Since a specif er using LSD can decide what to hide and
reveal, in relation to specif c internal control f ow effects,
we would say that LSD is also a grey box approach [3].
However, LSD does not support behavioral contracts such
as preconditions. This can be mitigated by incorporating
JML features to LSD design rule language. It is important
to note that LSD is not a standard AspectJ program. It is a
good proposal to be implemented in the current AspectJ language.
Therefore, currently, the authors of LSD are working
towards a release for AO developers [9].
Another work on these problems uses the notion of
translucid contracts [1]. A translucid contract describes in
a detailed way the behavior of aspects when applied to the
AO interfaces. With translucid contracts, the specif er decide
to hide some details, while revealing others. Translucid
contracts are based on grey box specif cation approach [3].
Translucid contracts are similar to XPIs (Figure 1), but
instead of AspectJ, translucid contract is implemented in
Ptolemy with its quantif ed typed events [10].
Finally, the AO community has a plenty of techniques to
reason about their programs [14, 4, 9, 1]. But the existing
behavioral contracts for AO interfaces, which are AspectJbased
[4, 14], are insuff ciently to advert developers about
inconsistencies in AO program designs and implementations.
Therefore, the AO community is lacking for an approach
to def ne expressive contracts for AO programs using
aspect constructs.
1.3 Contributions to the State-of-the-art
Then main contribution of this work is the use of standard
AO constructs like those of AspectJ to enforce control
f ow effects. We extend the XPI approach [4] to add
more expressive contract checking properties for AO programs.
Likewise XPI [4], we employ aspects to enforce AO
contracts combined with grey box specif cation based approach
[3] taken from LSD [9] and translucid contracts [1].
To provide the grey box specif cation approach, we draw on
the work of LSD. Hence, we demonstrate how to apply behavioral
rules, such as xcall , using plain aspect constructs.
In this paper we focus on three mechanisms to enforce
contracts for AOP: (i) metadata annotations, (ii) pointcuts
and (iii) advice [6]. Our goal is understand how the combination
of these approaches can provide a more expressive
way to check contracts for aspects than those already researched
[14, 4]. We discuss some benef ts of the use of
annotations as a part of our solution to promote contracts
for AO programs.
2 XPIs with Design Rules
The key idea behind our design methodology is to introduce
a design phase for each crosscutting concern. Hence,
a designer establishes a crosscutting design rule interface to
decouple the base and the aspect design. Such a crosscutting
design rule is based on a previous work by Griswold
et al. [4], the well known crosscut programming interfaces
(XPIs). The main difference is that we extend XPIs with
the notion of behavioral rules [9]. Hence with such behavioral
rules, we enhance XPIs with a grey box specif cation
capability [3]. We call our enhanced XPI as crosscut programming
interface with design rule,orXPIDR.
We implement XPIDRs as syntactic constructs in AspectJ.
A XPIDR is composed of the following elements: (i)
a name; (ii) a set of one or more abstract join points; (iii)
a scope in which the abstract join points are def ned; (iv)
during the system’s concern specif cation, the specif er can
expose or hide specif c join points, and (v) all the exposed
join points should also present their specif cations using behavioral
rules and contracts.
All of these elements are declared by using standard AspectJ
constructs. Such elements enable one to provide an
expressive interface to be respected by the base and crosscutting
concern implementation of the system.
2.1 The Figure Editor with XPIDRs
Figure 3 illustrates the use of XPIDR, written in AspectJ,
for the f gure editor example (lines 1−16). By convention,
aspects that specify XPIDRs begin with an “XDR” to distinguish
them from non-interface aspects. Hence, the XPIDR
XDRUpdate declared in Figure 3 is the same aspect illustrated
previously in Figures 1 and 2 named Changed.
XPIDR comprehends simple pointcut declarations in
which aspects can provide the advising code without needing
to refer directly to the underlying source code (lines
2−3). In addition, we can also specify properties of the underlying
pointcuts in a grey box style. Thus, the specif er
150