SEKE 2012 Proceedings - Knowledge Systems Institute

1 public aspect XDRUpdate {
2 public pointcut jp (Fig fe ): target(fe)
3 && ( call ( void Fig+. set ∗ (..))) && @annotation (UpdateConcern );
4 public pointcut bcscope (): within (Fig+);
5 public pointcut acscope (): within (∗ Update ∗ );
6 public pointcut xpidrscope(): bcscope () || acscope ();
7 /∗ Grey box specification of the Update concern base code ∗/
8 declare @method: void Point . setX( int ): @UpdateConcern(Method.POINT SETX);
9 declare @method: void Point . setX( int ): @Set(”int Point.x”);
10 /∗ Grey box specification of the Update crosscutting concern code ∗/
11 declare @method: void Display . update (): @UpdateConcern(Method.DISPLAY UPDATE);
12 declare @method: void Update . aroundAdvBody( Fig ): @UpdateConcern(Method.UPDATE AROUND);
13 declare @method: void Update . aroundAdvBody( Fig ): @Requires(”fe != null”);
14 declare @method: void Update . aroundAdvBody( Fig ): @XCall(”public static void Display.update()”);
15 declare @method: void Update . aroundAdvBody( Fig ): @Ensures(”fe != null”);
16 }
Figure 3. An example of the XPIDR for the update concern of the figure editor.
can choose whether or not reveal specif c details of code to
be advised. For example, lines 8−9 explicitly present details
of the base code. So, developers referring this XPIDR
know that the based code specif cally contains a Point .setX
method. Besides that, we can observe that such a method
contains two attached annotation properties.
The former (line 8) is an annotation which can be declared
anywhere. It refers to the update concern that the
system realizes. Furthermore, it provides an enumeration
property (Method.POINT SETX) which specif cally identif
es which particular element of the Update concern it belongs
to (the method Point .setX in this case). We use a
enumeration property because we can mark several methods
and advice of a particular concern.
The latter denotes the set behavioral rule [9]. Hence,
we can exactly specify what f elds must be set within the
method Point .setX. In this case, the design rule on line 9
states that the method Point .setX must have an a assignment
(f eld state change) to the f eld Point .x. Wealsorepresent
behavioral rules as metadata annotations. Thus, the
set design rule is denoted by @Set, which is attached to
the Point .setX method. With XPIDR we can also employ
f ve more design (behavioral) rules. Table 1 presents the
six design rules we draw from LSD [9] and that we made
available by XPIDR. Note that since AspectJ 5, we can attach
(mark) methods using the AspectJ supplying annotation
feature such as declare @method (lines 8−15).
The syntactic part of the XPIDR also exposes other
two methods: (i) the method Display .update in line 11,
and (ii) the method void Update.aroundAdvBody(Fig) in lines
12−15. Both are related to the crosscutting concern code.
The second one (Update.aroundAdvBody) denotes a separate
method to represent an advice since AspectJ does not support
supplying annotations for advice yet. The method
Update.aroundAdvBody is composed by the behavioral rule
@XCall to denote that the advice must have a call to method
Display .update. This mandatory call is also exclusive in the
scope of the XPIDR for the Update concern (since the notation
starts with an ‘x’).
Considering the behavioral contracts, pre- and postcondition
are specif ed in lines 13 and 15 (see Figure 3), respectively.
These conditions state that the target object
(denoted by fe) must be non-null before and after method
Update.aroudAdvBody’s execution. We refer to fe which is
the exposed target Fig object by the pointcut jp. We also
represent behavioral contracts as metadata annotations. We
adopted the work by Boysen [2] in our XPIDR, which already
provide Java 5 annotations for JML [7]. These JML
behavioral contracts as metadata annotations can be also attached
to the base code.
Note that we use simple Java methods to refer to AspectJ
advice since advice declarations in AspectJ are unnamed.
We cannot explicitly refer them in our XPIDR to
attach annotations with design rules. With such a limitation
we rely on simple methods that are supposed to encapsulate
the advice behaviors. For example, to implement the
update concern, we should have an aspect named Update
and according to our XPIDR it must declare the method
Update.aroundAdvBody. Such a method is called from within
an around advice declared in the same aspect Update.
Figure 4 presents a Update aspect (lines 1−14) using our
XPIDR provided in Figure 3. The aspect now depends only
on the abstract public pointcut signatures of XDRUpdate, not
on implementation details of the Fig and Point classes. As
mentioned, we cannot supply annotations for AspectJ advice.
Hence, we also specify the advice declared in the
Update aspect. In line 6 we mark the around advice with
a custom metadata annotation (@AroundAdvice
UpdateConcern). In addition, the around advice (lines
10−13) is specif ed with two behavioral rules. The former
151