SEKE 2012 Proceedings - Knowledge Systems Institute

The use of metadata annotations brings two additional
benef ts for the XPIDR interface specif cation and verif -
cation. The f rst one guarantees that the specif celements
exposed by the XPIDR (using the AspectJ supplying annotation
syntax) must be declared by the base and aspect code.
The second one is that unlike XPIs, we can now check specif
c properties of a particular AspectJ advice. We match a
specif c advice based on its annotation type.
In relation to the use of design rules, we can minimize
the impact of the well known problem of pointcut fragility.
For example, if a developer changes the base code, by removing
a join point shadow (a method call), can lead the
aspect code to behave in a different way from what is expected.
Hence, our XPIDR checks the method call occurrence
and if it is not found, the developer is warned about
the missing join point.
4.1 Feature Request
Some problems we had during XPIDR specif cation
could be avoided if we could add a supply clause for advice.
Therefore, we submitted a feature request to the AspectJ
team, which they hope to consider for a future version
of AspectJ. We suggested the support of a new construct
that marks an advice with an annotation. For example, it
could be used as in the following:
declare @advice : update . around ( . . ) : @UpdateConcern;
This declaration would avoid the extra annotations added
directly in the advice declaration, such as the one used to
say that an around advice must proceed.
5 Summary
Metadata annotations, pointcuts and advice are useful
techniques commonly used for separating concerns in
source code. We have combined these three AO techniques
towards a design by contract methodology for AOP. Each of
these AO mechanisms makes a different kind of task: annotations
mark join points related to the base and aspect code;
pointcuts bindings sets of join points marked with annotations,
and advice provide the checking code implementation
to sets of join points denoted by pointcuts.
We have combined the notion of crosscut programming
interfaces (XPIs) [4] with more expressive design rules
adopted by LSD [9]. Such design rules are specif ed and
checked using the three AO mechanisms we focus in this
paper. We call our enhanced XPIs as crosscut programming
interfaces with design rules, orXPIDRs.
Our main contribution is that we have devised a practical
alternative way to a enable an expressive design by contract
methodology for AOP using existing AOP constructs like
those of AspectJ. In addition, our approach, called XPIDRs,
is a grey box specif cation based approach, which provides
means to detailed specify control f ow effects for both base
and aspect code. In a grey box specif cation, the designer
decides whether or not to expose control f ow effects. As a
result, only interesting control f ow effects are exposed.
Finally, and most importantly, using XPIDRs a developer
does not require new AO constructs, which in turns
makes the adoption by the AO community more easier. We
argued that the design rules of XPIDRs showed to be more
expressive than the existing AO based techniques [4, 14].
References
[1] M. Bagherzadeh et al. Translucid contracts: expressive specif
cation and modular verif cation for aspect-oriented interfaces.
In Proceedings of AOSD’11, 2011.
[2] K.P.Boysen. Aspecif cation language design for jml using
Java 5 annotations. Technical report, Iowa State University,
2008.
[3] M. Büchi and W. Weck. The greybox approach: When
blackbox specif cation hide too much. Technical report,
Aug. 06 1999.
[4] W. G. Griswold et al. Modular software design with crosscutting
interfaces. IEEE Softw., 23:51–60, January 2006.
[5] G. Kiczales et al. Aspect-oriented programming. In ECOOP
97, 1997.
[6] G. Kiczales et al. Getting Started with AspectJ. Commun.
ACM, 44(10):59–65, 2001.
[7] G. T. Leavens, A. L. Baker, and C. Ruby. Preliminary design
of JML: A behavioral interface specif cation language for
Java. ACM SIGSOFT Software Engineering Notes, 31(3):1–
38, Mar. 2006.
[8] B. Meyer. Applying “design by contract”. Computer,
25(10):40–51, 1992.
[9] A. C. Neto et al. A design rule language for aspect-oriented
programming. In SBLP ’09, 2009.
[10] H. Rajan and G. T. Leavens. Ptolemy: A language with
quantif ed, typed events. In ECOOP 2008.
[11] H. Rebêlo et al. Implementing java modeling language contracts
with aspectj. In Proc. of the 2008 ACM SAC, 2008.
[12] H. Rebêlo et al. The contract enforcement aspect pattern. In
Proceedings of the 8th SugarLoafPlop, pages 99–114, 2010.
[13] H. Rebêlo et al. Assessing the impact of aspects on design
by contract effort: A quantitative study. In SEKE, pages
450–455, 2011.
[14] T. Skotiniotis and D. H. Lorenz. Cona: aspects for contracts
and contracts for aspects. ACM SIGPLAN Notices,
39(10):196–197, Oct. 2004.
A. Online Appendix
We invite researchers to replicate, analyze, and compare
our XPIDR implementation of the f gure editor against its
counterpart in XPI. The implementations are available at:
http://www.cin.ufpe.br/˜hemr/seke12.
153