Chapter 1 Overview
3.1 Common Features of Aspect-Oriented Lan- Lan-guages
3.1.5 Summary of language features
The core concepts identified in this thesis by observing the above AO lan-guages are: advice actions, join point shadows, static and dynamic properties of matching join points, context reification at join points, strategies for (im-plicitly) instantiating aspects and receiving the instances, advice ordering at shared join points, and dynamic and scoped aspect deployment. These concepts are covered by the meta-model presented in the following section.
3.2 The Language Independent Aspect Meta-Model
The Language Independent Aspect Meta-Model (LIAM) is developed in this thesis and captures the aspect-oriented core concepts identified in the previ-ous section. The concrete AO concepts of the above described languages are mapped to LIAM and for some concepts the mapping is presented here to illustrate the meta-model. Especially, throughout this section the AspectJ language constructs and their mapping to LIAM are used to exemplify such a mapping. In Section 3.4, mappings of the more advanced languages CaesarJ, JAsCo and Compose* are presented to emphasize that the meta-model is appropriate to express state-of-the-art aspect-oriented languages.
Terms like pointcut-and-advice are usually used with the intuition of pointcuts and advice in the AspectJ language. However, the meta-model developed here has a slightly different granularity. For example, in AspectJ the order of different advice applicable at the same join point can only be determined per aspect whereas in LIAM ordering is a property of “pointcut-and-advice”. Thus, a more concise terminology is used here, which is different from the AspectJ related one, in order to avoid confusion of terms. The meta-model is implemented in Java whereby most of the meta-entities are abstract classes.
Figure 3.3 shows the meta-entities defined in LIAM as well as their re-lationships. To exemplify the usage of the entities Figure 3.4 shows an ob-ject model that represents the sample aspect in Listing 3.8 copied from Sec-tion 2.1.1. Assume the aspect is compiled to the class QueryInjectionChecker that contains thestaticmethodbefore 0(String sql)which is compiled from the advice’s body as in Listing 2.6. The object diagram in Figure 3.4 is explained along with the following discussion of the meta-entities.
1 aspectQueryInjectionChecker issingleton(){
2 before(String sql):
The Language Independent Aspect Meta-Model
Aspect AdviceUnit
JoinPointSet
JoinPointShadowSet
Pattern DynamicProperty
Context Action
DynamicPropertyExpression
*
*
*
0..1
0..2
1
1 1
1
MemberAction
ScheduleInfo InstantiationStrategy
1 1
*
Figure 3.3: Entities of the Language Independent Meta-Model.
The Language Independent Aspect Meta-Model
expression tree pointcut
pointcut-and-advice : AdviceUnit
: MethodCallAction
method=“QueryInjectionChecker.before_0(String) void“ : ScheduleInfo
time=BEFORE
: JoinPointSet
: JoinPointShadowSet
: BasicDynamicPropertyExpression : ArgContext
: List
: MethodPattern pattern=…
: RequiredTypeDynamicProperty type=String
: SingletonInstantiationStrategy :Aspect
: AndDynamicPropertyExpression
: BasicDynamicPropertyExpression : CFlowDynamicProperty
…
Figure 3.4: Example of a model in LIAM.
The Language Independent Aspect Meta-Model
org.aspectj.lang : JoinPoint this=
target=
arguments=
org.aspectj.lang : JoinPoint.StaticPart kind=
org.aspectj.lang : MethodSignature declaringTypeName=
name=
parameterNames=
returnType=
org.aspectj.lang : SourceLocation fileName=
line=
Figure 3.5: Runtime object model of JoinPointfor the ThisJoinPointContext.
3 call(ResultSet Connection.execQuery(CharSequence))
4 &&args(sql)
5 &&cflow(voidFacadeServlet.doPost(Request, Response))
6 {
7 if(isAttack(sql))
8 throw newSQLInjectionException();
9 }
10 }
Listing 3.8: Aspect in AspectJ syntax.
Context. As seen in the previous section, many features of AO languages depend on runtime values from the context of the current join point. The meta-entity Context models this. Specializations of Context model concrete values like the argument values passed to a called method. Contextis used by several other meta-entities discussed below, includingContextitself. Compos-iteContexts model composite values like theJoinPointobject that is accessible in the AspectJ language by means of the thisJoinPoint special form. The JoinPoint object is a composition of all values available at a join point; Fig-ure 3.5 shows an object diagram of such a value as it can be used by an advice. Figure 3.6 shows a model of the composite ThisJoinPointContext en-tity which can be used in a LIAM model to specify that a JoinPoint object has to be exposed at a join point.
Dynamic Property. The DynamicProperty meta-entity models a condition that can be satisfied by a property of the context in which a join point is executed at runtime. In Listing 3.8, line 4, theargspointcut designator plays
The Language Independent Aspect Meta-Model
:ThisJoinPointContext :ThisJoinPoint-StaticPartContext :ThisContext :TargetContext
:ArgumentsContext
:KindContext :SignatureContext
:SourceLocation-Context
Figure 3.6: Object model ofThisJoinPointContext context in LIAM.
two roles, restricting the runtime type of the argument passed to theexecQuery method and binding the value for use by the advice. In LIAM this is split up into several entities. As illustrated by the example LIAM model in Figure 3.4, the value is modeled as a Context entity, ArgContext in the example, used in two different places: the JoinPointSet and the RequiredTypeDynamicProperty both refer to the ArgContext. The former relationship means that the value is exposed to advice; the RequiredTypeDynamicProperty with the associated ArgContext means that at runtime the type of the argument is tested.
Dynamic Property Expression. Constraints for join points based on run-time values are represented by DynamicPropertyExpression forming an expres-sion tree withDynamicPropertys as its leafs. The inner nodes are either anand or an or operator; negations cannot be inner nodes, but a leaf can also be the negation of a DynamicProperty. In Figure 3.4, the data structure marked by the box expression tree is an example of the sub-pointcut in lines 4–5, Listing 3.8. Specializations of the DynamicProperty meta-entity can have as-sociated Contexts and represent concrete constraints for join points. In the example, the constraint of a type requirement for the argument value is ex-pressed. The CFlowDynamicProperty is only partly shown in Figure 3.4 for brevity.
Join Point Shadow Set and Pattern. The JoinPointShadowSetmeta-entity is associated with a Pattern object specifying lexical properties of matching join points. It embodies the quantification over join point shadows, i.e., instructions in the program. There is a hierarchy of Patterns implemented in LIAM which reflects the different possible join point shadows—like method calls or field reads—and their lexical properties—like their declaring class or their name. In the example, Figure 3.4, a MethodPattern is used to match method calls.
The Language Independent Aspect Meta-Model
Join Point Set. A JoinPointSet associates a JoinPointShadowSet with a list ofContexts and aDynamicPropertyExpression. The intuition behind this is that the first two entities select a set of join points matching a lexical pattern and satisfying a dynamic constraint; at these join points the specified runtime values are exposed. A JoinPointSet corresponds to a pointcut sub-expression in AspectJ that consists of a single statically evaluable pointcut designator—
e.g., a callorget designator—and an expression of pointcut designators that cannot be statically evaluated.
A full pointcut is represented by a collection of JoinPointSet objects in the meta-model. Every such object represents a single or-clause. Thus, this collection is the union set of all join points selected by any of its JoinPointSet objects. In AO language implementations based on weaving, join points are determined as a combination of a join point shadow and residual dispatch.
In LIAM the residual dispatch is modeled as aDynamicPropertyExpression. At matching join points, the values modeled by the list ofContexts are exposed to the advice. In Figure 3.4 the collection ofJoinPointSetand its associated meta-model entities are marked by the pointcut box. In Section 3.4 an automatic translator from AspectJ code to LIAM entities is presented which shows that all AspectJ pointcuts are representable in the meta-model.
Action and Instantiation Strategy. Sub-classes of Actionarbitrarily deter-mine what actually should happen as an advice. Also part of LIAM are con-crete actions, namely a class hierarchy of MemberActions. A member action can be reading or writing a field, or calling a method. The accessed members can either be instance members, i.e., a virtual method or an instance field, or static members. In the case of instance members, an InstantiationStrategy determines how to retrieve the object whose member is to be accessed. In the example LIAM model in Figure 3.4 the SingletonInstantiationStrategy ob-ject reflects theissingletonkeyword in line 1, Listing 3.8; this means that the advice is always executed in the context of the same aspect instance.
Advice Unit and Schedule Information. A collection of JoinPointSets is associated with an advice Action by an AdviceUnit entity, which also refers to a ScheduleInfo meta-entity. AdviceUnit captures the pointcut-and-advice concept in AspectJ while theScheduleInfodefines relationships betweenActions applicable at the same join point shadow, e.g., the order or mutual exclusion ofActions. The framework for executing LIAM models, discussed in the next section, also handles the actual join point event as an action at a join point shadow just like the ones added to a shadow because of a deployedAdviceUnit. Consequently, ordering actions includes arranging them relative to the join
The Framework for Implementing Aspect Languages
point’s action as is determined by the keywords before, after and around in AspectJ.
Aspect. AnAspect is a logical group ofAdviceUnits to be deployed together.
JoinPointSet, JoinPointShadowSet, AdviceUnit and Aspect provide logical group-ings of entities of the meta-model and cannot be sub-classed.