AspectX Language Guide

This page introduces the AspectX language that is used to write aspect programs for the XWeaver aspect weaver. It should however be stressed that practical and non-trivial usage of AspectX requires some familiarity with XML and XPath and the willingness to become acquainted with the structure of the srcML representation of C/C++/Java base code. The latter is fairly simple and mostly intuitive. Visual inspection of the XML-based models of C/C++/Java source code generated by srcML will quickly reveal its general structure. Finally, it should be noted that this project web site includes a collection of sample aspect programs that illustrate through examples how AspectX programs are built.

General

The AspectX language is built upon an XML-based grammar. An AspectX program is implemented as one single XML file. The syntax of the AspectX language is defined by an XML Schema. A syntactically correct AspectX program is an XML document that is valid according to this XML Schema. The syntax of AspectX is therefore fully defined by an XML Schema. This page gives an overview of some of its most important concepts that will help readers understand the schema definition. The XML Schema is commented and serves as a formal language reference. The AspectX XML Schema can be accessed through the project download page.

AspectX programs can be commented and the AspectXdoc tool is offered to automatically process these comments and generate HTML documentation of the aspect programs.

Key Concepts

Like any aspect program, an AspectX program specifies some changes to be done upon some base code. The key concepts of the language are roughly modelled on those of mainstream aspect languages (in particular AspectJ) and are:

  • The pointcut to identify the locations in the base code where modifications are required
  • The code modifier to describe the new code that must be inserted in the base code
  • The advice to represent a pointcut and an associated code modifier to specify a modification to be performed upon the pointcut

AspectX associates an XML element to the last three of the above key concepts as follows:

  • The pointcut is described by a pointcut element
  • The code modifier is described by a codeModifier element
  • The advice is described by an advice element

All these elements are additionally characterized by a type attribute. Conceptually, the element name defines an abstract type and the value of the type attribute defines a concrete type. Thus, for instance, the language defines an abstract code modifier concept represented by the codeModifier element. The current implementation of the XWeaver tool can process several concrete types of code modifiers identified by certain values of the type attribute (e.g. codeFragment, declaration, definition, etc).

Using this analogy, it is possible to illustrate the abstract relationships among the basic elements of the AspectX language with an UML diagram:

umlModel

Figure 1: umlModel

The UML diagram should be interpreted as follows:

  • A UML class represents an XML element
  • The UML class attributes represent XML element attributes
  • A UML association link represents the relationship between an XML element and one of its children elements.
  • The annotations in the UML diagram state constraints on the legal combinations of the language elements that cannot be easily expressed using UML

The diagram states, among others, the following facts:

  • A restriction can be based on none or one pointcut.
  • A pointcut consists of one or more other pointcuts with the restriction that the type of the parent pointcut must be of the same as the type of the children pointcut it contains.
  • An advice consists of a pointcut and a set of code modifiers
  • An aspect program consists of an aspect element that in turn consists of a set of advices and a set of pointcuts

The UML diagram is not a formal definition of the language. It only shows the most important relationships modelled by the AspectX language (which is defined by the XML Schema). The UML diagram, for instance, does not cover the presence of XML elements for documenting an AspectX program and other issues that are not essential to the understanding of the language.

The important point to stress is that the AspectX language is basically defined at the level of the abstract elements only and does not enforce relationships or constraints at the level of concrete types. The chief advantage of this approach is that it allows easy extensibility. Users can add new concrete types without having to change the language. Users, for instance, can easily define a new type of code modifier by adding a new option to the range of values of the type attribute of the codeModifier element. The chief drawback of this approach is the limited degree of static checking that can be performed upon AspectX programs. The XML Schema can detect use of illegal type values but it cannot enforce constraints on their combinations (e.g. constraints on the type of restriction element that can be associated to a certain type of pointcut element). This type of checks must be done at run time by the aspect weaver.

The next four sections describe the semantic of each of the three basic elements of the AspectX language.

Pointcuts

AspectX assumes the base code to be written using the srcML XML-based language (see the discussion of the approach to aspect weaving). The srcML language maps C++/Java syntactical constructs in the base code to dedicated XML elements. Thus, a class in the base code is described in srcML by an XML element named src:class (a class definition). A class method in the base code is described in srcML by two XML elements named function_decl (method declaration) and function (method definition). And so forth for other C++/Java syntactical constructs.

In AspectX, a pointcut designates a set of XML elements in the srcML representation of the base code. A pointcut in AspectX is described by an element of type pointcut. The set of target elements in the srcML representation of the base code is a function of the following attributes and subelements of pointcut:

  • The type attribute
  • The constraint attribute
  • The restriction subelement
  • The pointcut/pointcutRef subelement
  • The and subelement
  • The or subelement
  • The not subelement

The next figure illustrates this concept. The oval in the figure represents the set of elements in the srcML representation of the base code. To each pointcut in an AspectX program is associated a subset of these elements (shaded items in the figure). The way this subset is selected is a function of the attributes and subelements listed above.

pointcutType

Figure 2: pointcutType

The type attribute identifies elements in the srcML description by name. In other words, a join point with a type attribute with value value identifies all the XML elements in the srcML description of the base code with name value. As an illustration, consider the following (not very meaningful) AspectX pointcut:

     <pointcut type="src:class">
          . . .
     </pointcut>

This pointcut identifies all srcML elements of type class. This means that it identifies all C++/Java classes in the base program. The prefix src: specifies that class is an element of the srcML namespace. This prefix should be used whenever srcML elements are referenced in AspectX programs.

Correct usage of the type mechanism requires familiarity with the srcML representation of the base code because it requires the writer of the AspectX program to know which element are used in srcML documents and what their meaning is in terms of the C++/Java code they describe. In order to help users, the following table lists the element names that are most commonly used as pointcut type values.

srcML Element Description
src:class A C++ or Java class. The following example of a pointcut identifies all class definitions with the name Foo: <pointcut type="src:class" constraint="src:name='Foo'"/>
src:function A method definition in C++ or Java. Also used for function definitions in C/C++
src:function_decl A function or method declaration in C++ (not used in Java)
src:constructor A constructor definition.
src:constructor_decl A constructor declaration
src:destructor A destructor definition in C++ (not used in Java).
src:destructor_decl A destructor declaration in C++ (not used in Java).
src:comment A comment. A comment element has a type attibute which can be set to line for single line comments or block for block comments.
src:return A return statement
src:unit A source file. This is always the outermost element of any srcML file.
src:block A block is the part of a program enlcosed in curly braces.

The items in the first column are the names of the srcML elements that can be used as values for the type attribute of the pointcut. The items in the second column give a description of the syntactical element in the C++/Java base code which they describe.

The constraint attribute of the pointcut element defines an boolean condition that is evaluated on all the srcML elements identified by the type attribute. Elements over which the boolean condition evaluates to false are discarded. Elements over which the boolean condition evaluates to true are instead retained. The boolean condition is expressed using the XPath syntax. The next figure illustrates this concept graphically. The type attribute identifies a first subset of elements in the srcML representation of the base code and the constraint attribute identifies a subset within this subset.

pointcutConstraint

Figure 3: pointcutConstraint

From the point of view of the AspectX language, the value of the constraint attribute is just a string. The interpretation of the string as an XPath expression is done by the XWeaver. In its present implementation, the range of expressions that are understood by XWeaver are basically defined by the srcML DTD. This is best illustrated by means of an example:

     <pointcut type="src:function_decl" constraint="src:name='activate'">
          . . .
     </pointcut>

This pointcut captures all function declarations whose name is "activate". This example works because the src:function_decl element in a srcML document represents a C++ function or method declaration and it has a subelement called src:name that holds the name of the function or method. As a more complex example, consider the following join point definition: 

     <pointcut type="src:function_decl" constraint="starts-with(src:name, 'get') and contains(src:type,'*')">
           . . .
     </pointcut>

This pointcut captures all function declarations which starts with the string 'get' and where the return type inlcudes the string '*'. Correct usage of the constraint mechanism requires familiarity with the srcML representation of the base code. In order to help users, the following table lists the element names that are most commonly used in formulating poincut constraints.

srcML Element srcML Subelement Description
src:class src:name The name of the class
src:class src:super Information about the superclasses, src:super itself has src:name subelements with the name of the superclass as its content
src:function src:name The name of a function. In C++ method names are the splitted into two src:name subelements, like this:
<src:name><src:name>Class name</src:name>::<src:name>Method name</src:name></src:name>
Therefore the name of the of a mehtod is described by: src:name/src:name[2]. Similarly the class name is described by: src:name/src:name[1]
src:function src:type The return type of the function or method
src:function_decl src:name The name of the function or method declaration
src:function_decl src:type The return type of the function or method
src:return src:expr Contains the expression after the return statement

The items in the first column are the names of the srcML elements that can be used as values for the type attribute of the pointcut. The items in the second column are the names of the subelements that may appear in a constraint expression for those elements. The third column gives a description of the syntactical elements in the C++/Java base code which they describe (refer to the srcML documentation for a full description).

Restrictions

The subelements in a pointcut element can be used to further particularize the set of srcML elements that are identified by the pointcut. The key subelement is restriction. Restriction elements take the following form:

    <restriction type="typeName">
        . . .
    </restriction>

Conceptually, a restriction element describes a restriction based on a pointcut. Technically a restriction subelement can always be replaced by a (maybe fairly complicated) xpath exression in the constraint attribute of the pointcut. A restriction element can take a pointcutRef or a pointcut as a subelement.

For some special restriction it is also possible that they do not have a subelemnt at all. So far there is no implementation for such a restriction. An example would be a restriction, which restricts a pointcut of type src:class to only address classes that do not have a superclass. It is also possible that future pointcuts may contain other elements to parametrize a restriction. The way in which the restriction element impacts its pointcut is determined by the value of its type attribute. The following table lists the possible restriction types and gives a short description of each. For each restriction type the possible parent and child pointcut types are also listed.

Restriction type Description Valid parent poinctut types Valid child pointcut types
contain Only elements are inluded, which contain the elements defined by the pointcut. all all
within Only elements are inluded, which are subelements of the elements defined by the pointcut. all all
followedBy Only elements are included, which are directly followed by an element defined by the pointcut. all all
isDefinitionOf Only unit elements are included, which are the definition of the unit or class element defined by the pointcut. This is only applicable to C++ code and tests the suffixes of the source files (e.g .h or .cpp). The values for suffixes can be set in the XWeaver Project file. src:unit src:class, src:unit
parentOf Only element is included, which is parent of the elements defined by the pointcut. all all

Consider the contain value first. Its usage is best illustrated through an example:

    <pointcut type="typeName" constraint="xpathExpr">
        <restriction type="contain">
            <!-- definition of pointcut P -->
        </restriction>
    </pointcut>

As explained above, the type and constraint attributes of the pointcut identify a set J of srcML elements. The subelement pointcut of the restriction defines a second subset P of srcML elements. The elements identified by the above pointcut are all the elements in J that contain an element of P as one of their subelements. As a more concrete example consider:

    <pointcut type="src:class">
        <restriction type="contain">
            <pointcut type="src:function_decl" constraint="starts-with(src:name, 'get')"/>
        </restriction>
    </pointcut>

This pointcut captures all classes which contain at least one method, which name starts with the string 'get'.

The usage of the within type for the restriction is similar (and, as it were, symmetric to that of the contain type). Consider:

    <pointcut type="typeName" constraint="xpathExpr">
        <restriction type="within">
            <!-- definition of pointcut P -->
        </restriction>
    </pointcut>

The type and constraint attributes of the pointcut identify a set J of srcML elements. The subelement pointcut of the restriction defines a second subset P of srcML elements. The elements identified by the pointcut are all the elements that are in J and that are subelements of an element of P. As a more concrete example consider:

    <pointcut type="src:function_decl">
        <restriction type="within">
            <pointcut type="src:class" constraint="src:name='Foo'"/>
        </restriction>
    </pointcut>

This pointcut captures all function declarations which are defined inside a class named 'Foo'.

Finally, consider the followedBy type for a restriction:

    <pointcut type="typeName" constraint="xpathExpr">
        <restriction type="followedBy">
            <!-- definition of pointcut P -->
        </restriction>
    </pointcut>

As usual, the type and constraint attributes of the pointcut identify a set J of srcML elements. The subelement pointcut of the restriction defines a second subset P of srcML elements. The elements identified by the above pointcut are all the elements that are in J and that have an element of P as their next element. As a more concrete example consider:

    <pointcut type="src:comment">
        <restriction type="followedBy">
            <pointcut type="src:class" constraint="src:name='Foo'"/>
        </restriction>
    </pointcut>

This pointcut captures all comments which are defined directly above a class named 'Foo', which is normally the comment for the class. For greater flexibility, AspectX allows restrictions to be combined using "and" and "or" clauses or negate a restriction with "not". This is done by using and , or and not elements to gather together several restrictions. The and, or and not elements can in turn be combined. As an example consider:

    <pointcut type="src:class">
        <or>
            <and>
                <restriction type="contain">
                    <pointcut type="src:function_decl" constraint="starts-with(src:name, 'get')/>
                </restriction>
                <not>
                    <restriction type="contain">
                        <pointcut type="src:function_decl" constraint="starts-with(src:name, 'set')"/>
                    </restriction>
                </not>
            </and>
            <restriction type="contain">
                <pointcut type="src:function_decl" constraint="starts-with(src:name, 'setValue')"/>
            </restriction>   
        </or>
    </pointcut>

This pointcut captures all classes that either have a function declaration which starts with 'get', but have no function decalrations that starts with 'set' or have a function declaration that starts with 'setValue'.

Referencing pointcuts

Pointcuts can be defined as reusable named pointcuts. These named pointcuts can be referenced by a pointcut reference. A pointcut reference in AspectX is written with the element poinctutRef. Any anonymous pointcut (pointcut without a name) can be replaced by a reference to a named pointcut. This makes it possible to reuse pointcuts. Pointcuts can also be referenced if they are defined in another file. Then the aspect needs to include the aspect containing the referenced pointcut. This is done by the include mechanism. In AspectX this is expressed by the include element. An include element has one mandatory attribute, the href attribute which value will be set to the file the included aspect can be found (relative to the current aspect or as an absolute path). PointcutRef elements which refer to an external pointcut must have an additional attribute aspect which tells in which aspect the referenced pointcut can be found. A poinctuRef without an aspect attribute always references a local (defined in the same aspect) pointcut.

Combining Pointcuts

Pointcuts can be compined with the algebraic operators and, or and not. These operators are translated to their equivalent xPath operator.

As an example, consider the following:

    <pointcut name="classGroup" type="src:class">
        <description>A group of classes identified by name</description>
        <or>
          <pointcut type="src:class" constraint="src:name='CC_TelemetryManager'"/>
          <pointcut type="src:class" constraint="src:name='CC_ManoeuvreManager'"/>
          <pointcut type="src:class" constraint="src:name='CC_TelecommandManager'"/>
        </or>
    </pointcut>

This pointcut gathers together three pointcuts each of which identifies one specific class. The set of XML elements in the srcML representation of the code that are identified by this pointcut is therefore the set of elements that describe the three classes named in the pointcuts.

Code Modifiers

Code modifier elements are used in AspectX programs inside advice elements to describe the code that must be inserted in the base code at a specific location or set of locations. The code specified by the code modifier may be either added to the existing code or it may be added in lieu of the existing code, depending on the type of advice within which the code modifier is embedded. Note that the code modifier only specifies the code to be inserted, it does not specify the locations where the code should be inserted. These are specified by a pointcut. This separation between the change to be performed and the location where it should be performed is an important aspect of AspectX in that it helps to implement a modular (and hence extensible and cutomizable) aspect weaver. In particular, it helps to divide the code transformation process into a compilation and location process and a code weaving process.

The current implementation of XWeaver recognizes the following concrete types of code modifier elements:

Code Modifier Type Description
codeFragment Represents a generic code fragment. This can be anyhting from a simple expression to a multine block of code.
comment A comment. There's no distinction made between a line and a block comment.

C/C++ specific Code Modifiers

include Represents an #include statement for a file in the base code.
declaration Represents a declaration (field, method, constructor etc.) in C++. for a class in the base code. This code mofifier must have an accessModifer subelement to specify the access modifer for the declaration to be inserted. The following example code modifier inserts a private member variable x: 
 
    <codeModifier type="declaration">
        <accessModifier type="private"/>
        <text>int x;</text>
    </codeModifier>
definition Represents a definition (method, constructor, destructor) for a class or a file in the base code.
accessModifierBlock This code modifier represents an access modifier in a C++ class. Possible blocks are: private, pubtdc and protected. To specifiy a specific access modifer the codeModifier element needs to have a accessModifierBlock subelement with a type attribute that can have the values private, pubtdc or protected. A code modifier of type accessModifierBlock can have more than one accessModifierBlock subelement to add several blocks in one run. See the following code for an example that adds a pubtdc and a protected access modifier block to a class: 
 
    <codeModifier type="accessModifierBlock">
        <accessModifierBlock type="pubtdc"/>
        <accessModifierBlock type="protected"/>
    </codeModifier>

Java specific Code Modifiers

import Represents a Java import statement
member Represents a member a Java class. E.g a method, inner class or a field.

From the point of view of the AspectX language, the content of a code modifier element is simply an alphanumeric string (enclosed within one or more text subelements that are required to preserve layout). Exceptions are special subelements for code modifiers of type declaration and accessModiferBlock. From the point of view of the aspect weaver, this string represents a piece of C++/Java code that the weaver should insert in the base code at the appropriate place. This code will sometimes need to refer to its context. For instance, code which shall be inserted within the body of a method may need to use the names of the method parameters. For this purpose, XWeaver provides dollar variables to access this type of information. The following dollar variables are defined:

Pointcut type Variable Value
src:block ${blockBody} The body of the block (indented).
src:class ${className} The name of the class
src:class ${superClassNames[i]} The name of the i-th super class
src:function and src:function_decl ${className} The name of the class the function is defined in
src:function and src:function_decl ${functionName} The name of the function
src:function and src:function_decl ${functionType} The type of the function
src:function and src:function_decl ${paramNames[i]} The names of the i-th parameter
src:function and src:function_decl ${paramTypes[i]} The types of the i-th parameter
src:return ${function} The function of the return statement is defined in. This value of this variable is a XML node-set and should only be used as an XSLT variable but not directly as a dollar variable. Example: 
 
    <codeModifier>
        <text>&lt;![CDATA[ <xsl:value-of select="$function/src:name"/>]]&gt;</text>
    </codeModifier>
src:return ${className} The name of the class the return statement is defined in.
src:return ${functionName} The name of the function the return statement is defined in.
src:return ${functionType} The type of the function the return statement is defined in.
src:return ${functionParamNames[i]} The names of the i-th parameter of the function the return statement is defined in.
src:return ${functionParamTypes[i]} The types of the i-th parameter of the function the the return statement is defined in.
src:unit ${className} The name of the class this unit belongs to. If the unit belongs to no class (e.g. main.cpp or any c file) this variable contains the empty string

Thus, for instance, an advice that modifies all setter methods that take a pointer as a first parameter and inserts code to verify that the pointer is non-null might be implemented as follows:

    <advice type="begin">
      <pointcut type="src:function" 
         constraint="contains(src:parameter_list/src:param[1]/src:decl/src:type, '*')"/>
      <codeModifier type="codeFragment">
        <text>assert( ${paramNames[1]} != 0 );</text>
      </codeModifier>
    </advice>

The code modifier accesses the name of the first parameter of the setter method as "${paramNames[1]}".

Because proper code layout is considered important for XWeaver, dollar variables can be written in a special way to add indentation. All whitespaces inserted after the opening curly brace of a dollar variable are considered as indentation and added to each line of the dollar variable's value. The follwing example adds two spaces to each line of the body of a block:

${  blockBody}
.

The dollar variable mechanism is implemented to be easily extensible to cover a wide range of variable types. Arguably the most obvious implementation would have been for XWeaver to parse the text in a codeModifier element and to identify and parse the dollar variables within it. This however would have made extension of the language to use new types of dollar variables difficult. The approach taken by XWeaver is instead to define dollar variables at the level of the aspect language using terms defined at the level of the base code language (or, more precisely, at the level of the language that is used to model the base code). As already mentioned, from the point of view of the AspectX syntax, the dollar variables are just part of the string content of a codeModifier element. Their interpretation as XML element names and XPath conditions is only done by the aspect weaver. More precisely, it is done during the compilation phase of the weaving process. The text in a codeModifier element is being searched for dollar variables of the form "${variableName}". The dollar variables are then replaced by an <xsl:value-of select="$variableName"/> XSL - element by the compiler. At the time the base code is annotated by the locator these XSL elements are evaluated. Therefore, the annotated base code already contains the values of the dollar variables as plain text. This works because the XWeaver compiler generates XSL variables with the same names as the dollar variables allowed by AspectX. Thus, extensions to cover a new type of dollar variable called $newVar simply requires the XWeaver compiler to generate an XSL variable of name of the dollar variable. This approach is easily extensible, as new variables can be defined in a modular manner. The main drawback of this approach is the coupling that is introduced between the aspect language and the srcML language. The full exploitation of the power of the dollar variable mechanism in an AspectX program requires knowledge of how srcML models the base code.

It may be preferable to directly declare a variable in an aspect, than to extend the XWeaver each time an aspect needs to use a special variable. This is especially useful for variables that are not used in any other aspect. To manage this, it is possible to use xsl elements in a codeModifier element. Instead of using a text element as the sublement of the code modifier element all xsl elements need to be enclosed in a xsl element. The following advice example should clarify this. it prints out the number of parameters of a function:

    <advice type="begin">
      <pointcut type="src:function">
        <description>Any function</description>
      </pointcut>
      <codeModifier type="codeFragment">
        <xsl>
          <xsl:text>cout &lt;&lt; "Number of parameters: </xsl:text>
          <xsl:value-of select="count(src:parameter_list/src:param)"/>
          <xsl:text>" &lt;&lt; endl;</xsl:text>
        </xsl>
      </codeModifier>
    </advice>

Note that xsl elements need to be in the xsl namespace, which is http://www.w3.org/1999/XSL/Transform. The prefix xsl in the example above must therefore be bound to the xsl namespace. This is normally done in the root element of the aspect like this: 

   <aspect ... xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    	...
   </aspect>

Also note that the xsl element (the direct subelement of the codeModifier element) is itself in the AspectX namespace (default namespace). The xsl:text element used above has nothing to do with the text element from the AspectX namespace. Please refer to the xsl documentation for an explanation of the xsl:text element. Refer to the aspects in the AspectX library for full examples.

Advices

An advice comprises a pointcut and a code modifier and is intended to specify a transformation to be applied at the location specified by the pointcut by inserting the code specified by the code modifier. Advices have a type attribute which specifies whether the code in the code modifier should complement or replace the existing code and it specifies where exactly the new code should be inserted. This is necessary because the pointcut only specifies a set of XML elements in the srcML description of the base code. The type attribute specifies where the location in the base code of the code insertion relative to the element location specified by the pointcut. The following concrete advice types are foreseen in the current implementation of XWeaver:

  • add: the new code should be added to the existing code in the element identified by the pointcut
  • replace: the new code should replace the element identified by the pointcut
  • before: the new code should be inserted before the element identified by the pointcut
  • after: the new code should be inserted after the element identified by the pointcut (this is not yet implemented)
  • begin: the new code should be inserted at the beginning of the element identified by the pointcut
  • end: the new code should be inserted at the end of the element identified by the pointcut
  • around: the new code should replace the code within the element identified by the pointcut
  • change: A specific part of the element identified by the pointcut is changed (e.g. the name of a method) (this is not yet implemented)

As an example of an advice consider the following:

<pointcut name="rootClass" constraint="name='CC_RootObject'">
    <description>This pointcut identifies the class whose name is "CC_RootObject"</description>
</pointcut>

<advice type="add" name=". . .">
    <description>This advice adds two mutex variable declaration to the root class</description>
    <pointcutRef ref="rootClass"/>
    
    <codeModifier type="declaration">
        <accessModifier>protected</accessModifier>
        <text>pthread_mutex_t syncMutex_1;</text>
    </codeModifier>
    
    <codeModifier type="declaration">
        <accessModifier>protected</accessModifier>
        <text>pthread_mutex_t syncMutex_2;</text>
    </codeModifier>
</advice>

This advice specifies the location to which it should be applied through a pointcut that identifies one particular class (the class whose name is CC_RootObject). The code modifier specifies two new protected variable declarations. The advice type specifies that these new declarations should be added to the existing ones.

Extensibility

Extensibility is one of the key objectives of the XWeaver project (see discussion of the project approach). At the level of the AspectX language, extensiblity can be understood in two senses. Firstly, it may refer to the ability of the language to express new kinds of aspect transformations. Secondly, it may refer to the ability of the language to take advantage of new features of the XML model of the base code produced by the srcML tool. AspectX is designed to be extensible in both senses.

Extensibility in the first sense is realized as discussed above through the possibility of defining new concrete types for the basic language elements. Some extensibility with respect to upgrades of the XML model of the base code generated by srcML is achieved, as already mentioned, by interleaving the AspectX language with the srcML language. Essentially, an AspectX program is parameterized with the names of the XML elements and attributes defined by srcML. This introduces a degree of independence from the srcML language and allows it to be robust to extensions of srcML (although it forces the aspect programmer to be familiar with srcML).

The issue of extensibility also comes into play when considering the language of the base code. AspectX was originally developed for C++ applications. This is reflected in some of its constructs. There is, for instance, a type of code modifiers that is specifically aimed at manipulating the list of #include files. Most AspectX language constructs however are not specific to C++ and are applicable to other object-oriented languages (e.g. Java). The availability of srcML for Java and the extensibility mechanisms described above made it very easy to extend AspectX to become an aspect language for Java-based applications.

Examples

This delivery contains several concrete and commented examples of aspects expressed in AspectX. Refer to the sample aspect programs page for a full list.