SEKE 2012 Proceedings - Knowledge Systems Institute

1 public privileged aspect Update {
2 void aroundAdvBody( Fig fe ) {
3 Display . update ();
4 }
5
6 @AroundAdviceUpdateConcern
7 @XCall("void aspects.update.Update.
8 aroundAdvBody(classes.Fig)" )
9 @Call("proceed(fe)")
10 void around( Fig fe ) : XDRUpdate . jp ( fe ){
11 proceed(fe);
12 aroundAdvBody( fe );
13 }
14 }
Figure 4. The Update aspect implementation.
1 /∗ Collection internal control flow join points
2 ∗ of the @UpdateConcern ∗/
3 before ( UpdateConcern upc ): upcWC(upc )
4 && XDRUpdate. staticxpidrscope (){
5 Util . addTrace(thisJoinPoint );
6 }
7 /∗ Collection internal control flow join points
8 ∗ of the @AroundAdviceUpdateConcern ∗/
9 before ( ) : aroundAdvWC ( ) {
10 Util . addTrace(thisJoinPoint );
11 }
Figure 5. Aspect code for tracing control flow
join points.
stating that such an advice must have a exclusive call (line
7) to the method Update.aroundAdvBody. The latter stating
that it must call the proceed method (line 9).
3 Contract Enforcement Implementation
In this section we describe how to implement the contract
enforcement of the XPIDRs previously discussed.
Due to the lack of space, secondary implementation details
are discussed in our technical report available at
http://www.cin.ufpe.br/˜hemr/seke12. The
main points of our strategy are covered in this section.
3.1 Checking Structural rules
Structural rules [9] are design rules that describe constraints
about classes and aspects members. Its realization
is similar to Java interfaces, but additional constraints
(beyond required public methods) such as required f elds
or expected AspectJ inter-type declarations. By using our
XPIDRs, we can force a developer to implement the required
types, methods and f elds we declare. For example,
in Figure 3 in line 8, we expose the method Point .setX. Until
the class Point is declared we got a warning message saying
that “no match for this type name”. Once the required
type is declared, we got a compile-time error saying that the
method “void Point .setX( int ) does not exist”. In this case
the developer is forced to implement the exposed member
by the XPIDR. This is an interesting feature described by
LSD design rule language [9] that we can support using the
AspectJ declare @ syntax (also known as supplying
annotation syntax). In summary, as with LSD [9],
XPIDRs enforce structural rules at compile-time.
3.2 Checking Behavioral Rules and Contracts
As discussed, a XPIDR interface adopts mechanisms
such as behavioral rules and contracts to provide a detailed
design specif cation in a grey box style [3] for program
modules like classes and aspects. Before checking such design
rules and contracts of the Update concern, we gather
information (using a trace-based mechanism) about all the
control f ow join points related to the Update concern.
Figure 5 presents the two before advice (lines 1−11)used
to trace all control f ow join points of the update concern.
The f rst one (lines 3−6) traces all the join points that occurs
within any join point marked with the Update concern annotation.
The second before advice (lines 9−11) traces all the
join points within the around advice, which is marked with
a specif c annotation, of the aspect Update. As observed, we
store each monitored join point (lines 5 and 10)byusingthe
method Util .addTrace. Such a method is available as a part
of the XPIDR API.
4 Discussion
We showed that AOP can be used to provide expressive
contract checking of aspect-oriented code. The main motivation
of our approach is that it does not requires any new
AOP-like construct to provide contract checking of AOP
code. Instead of new constructs, we reuse and combine
existing features like metadata annotations, pointcuts and
advice.
With the grey box specif cation approach, the specif er
can decide the degree in which the details are revealed.
Hence, our XPIDR illustrated in Figure 3 exposes that we
must have a class Point and a method setX. Also, the @Set
design rule states that the method Point .setX must have a
f eld state change to f eld Point .x. Suppose now that the
specif er decided to keep details more hidden and still obeying
the @Set design rule:
declare @method: ∗ Fig+. set ∗ (..): @Set( "* Fig+.*" );
This syntax abstracts the previous one by making details
more hidden. However, the @Set design rule still guarantee
properties of these set methods. Now, we just known that
any set method declared in any type Fig must have a f eld
state change to any f eld declared in type Fig.
152