XWeaver
This page gives an overview of the XWeaver aspect weaver and of the AspectX language. This page assumes the reader to be familiar with aspect oriented programming (AOP). An introduction to AOP can be found here.
The Institut für Automatik where the XWeaver project originated and P&P software where it is being continued are concerned, among other things, with the design and development of software frameworks for control systems. A software framework targets a set of related applications and provides a set of adaptable components that can be used to construct these applications. In order to be included in the target application, the framework components must normally undergo a tailoring process where they are adapted to match the application needs. Commonly used tailoring techniques include class extension and object composition. More recently, aspect oriented techniques have received attention because of their potential to project systematic modifications onto some existing code base. However, their use in the embedded control domain raises some issues related to the software qualification process. Embedded applications are often critical and their code must consequently be subjected to some kind of qualification programme that certifies that it has reached some minimal level of quality. Since an aspect weaver is a tool to weave new code into existing code, the question arises as to whether the qualification process should be performed upon the weaver tool or upon the woven code. The two basic approaches are (see also figure below):
Figure 1: QualificationApproach_1
The first approach is regarded as impractical in the short term because of the difficulty of qualifying an aspect weaver. This difficulty is due both to the intrinsic complexity of aspect weavers and to the lack of experience in qualifying this type of applications. The second approach on the other hand places some indirect constraints on the aspect weaver which must be capable of producing modified code that is amenable to qualification. At the very least it is desirable that the modified code not be harder to qualify than equivalent code that had been written by hand. In practice, this means that the modified code must satisfy the following requirements:
Existing aspect weavers that were evaluated at the Institut für Automatik do not satisfy the above requirements. Arguably, their most important shortcoming is that they are unable to handle comments. This is an important drawback because in many cases the code documentation is directly embedded in the source code in the form of JavaDoc or JavaDoc-like comments. The code documentation is automatically generated by processing these comments. If aspect weavers do not update the code comments, then the code documentation becomes invalid and this clearly makes the qualification process of the modified code more expensive. Other shortcomings concern the visual structure of the modified code that is often harder to read than the original base code (the original code layout is normally lost during the weaving process) and the presence of extraneous code that may be "pulled in" by the weaver. The XWeaver tool was developed to address these concerns. More specifically, it is intended to implement a weaving process that does not change in any way the base code and that is capable of generating comments to document the newly woven code. Broadly speaking, the intention of XWeaver is to produce a modified code that "looks like" manually written code and that is therefore as easy to qualify as code that had been modified by hand. This is also expressed by saying that XWeaver must be minimally intrusive in the sense that it must not disrupt the structure of the existing code and must insert new code that complies with this structure.
Two additional and related requirements of XWeaver are customizability and extensibility. Customizability refers to the possibility of tailoring the rules that are used to weave new code into existing code. Extensibility refers to the possibility of adding new rules to handle new types of aspects. Both are important in the context of qualifiable applications in the control domain which are often characterized by idiosyncratic requirements. In order to accomodate them, the aspect language and the weaving process must be correspondingly flexbile and adaptable. Extensibility and adaptability are also important for another reason. Developing a comprehensive aspect language and aspect weaver for a base language of the complexity of C++ is a daunting task. It is believed that a more practical approach is to begin by developing an aspect language and weaver that only cover a small core of functionalities of the base language but to ensure that these are extensible so as to allow the language and the weaver to grow gradually.
The shortcomings of traditional aspect weaving approaches highlighted in the previous section stem from the fact that conventional aspect weavers operate upon an abstract representation of the base code. Commonly, the first stage in their processing is the parsing of the base code and the construction of its abstract syntax tree. The code modifications defined by the aspect program are performed upon this abstract form of the base code. A code-generating back-end then constructs the modified code. The base code is entirely re-generated. This model allows aspect weavers to carry out sophisticated modifications of the base code but it also destroys some valuable information about the base code, most notably its comments.
XWeaver takes a different approach in that it operates upon a model of the code that preserves all the information in the base code, including formatting, layout and comments. Following recent work by several authors (see Links), an XML-based model of the code is used. In particular, among the several offerings currently on the market, the XWeaver project selected srcML. The main attraction of srcML from the point of view of the XWeaver project is that it preserves all the information in the base code and it offers a "round trip" facility that allow the source code to be re-generated from its XML model in its exact original form. A drawback of srcML is that its model of the base code is more coarse-grained than would be the case if full parsing were carried out. Dedicated XML elements are only used for high-level structures (classes, methods, if-then-else clauses, etc) and this poses a fundamental limit to the kind of transformations that can be performed by XWeaver. However, srcML may be upgraded in the future to produce a finer-grained representation of the base code. In order to be ready to take advantage of these upgrades, XWeaver was specifically designed to be extensible.
The choice of an XML-based representation of the base code as the starting point for the weaving process has the further advantage of partially decoupling the aspect weaver and the aspect language from the language of the base code. Although a complete decoupling from the base code and the weaving process is not a realistic option it helps insulate the latter from the former. XWeaver was orginally targeted at C++ applications but with the availability of srcML for Java, was extended to support Java applications too. Most of the implementation done for weaving C++ source code could be reused to support Java weaving. Furthermore, XWeavers extensibility feature made it possible to use the same program for C++ and Java weaving. The appropriate extensions for each language can be selected at runtime.
The use of an XML-based model of the base code suggests the use of XSL as a language to implement the weaver. This however is only feasible in a simple manner if the aspect program is also written in XML. For this reason, an XML-based language was defined to express the aspects that must be woven by XWeaver. The corresponding language is called AspectX.
The next figure illustrates the weaving process used by XWeaver.
Figure 2: XWeaverApproach_1
Since XWeaver operates upon an XML-based model of the base code, one could argue that there is no need for a dedicated aspect language since an aspect transformation can be directly expressed as an XSL transformation. This position is correct but impractical. Writing an aspect transformation directly in XSL would be a difficult, error-prone, and rather tedious task requiring a detailed knowledge of XSL that only few users are likely to have. AspectX is intended to provide a higher-level way of describing an aspect transformation and one that is also accessible to non-specialist users. Indeed, one can recognize two primary components in XWeaver. The first one is essentially a compiler that translates the AspectX program into an equivalent XSLT program. This program is formulated as a set of rules that define transformations to be performed upon the elements in the srcML model of the base code. The second component of XWeaver provides an interpretation engine that can implement the transformation defined by these rules. The advantage of using AspectX rather than directly XSL is therefore the same advantage that one has from using a high-level programming language instead of assembler.
To facilitate the documentation of aspect programs, the AspectXdoc application is provided. AspectXdoc is a JavaDoc-like facility for the automatic generation of HTML documentation for aspect programs written in AspectX. AspectXdoc is implemented as a set of XSL programs that read the XML documents containing the AspectX programs, extract the comments from them and use them to construct a web site that documents the programs.
The XWeaver tool is currently available as a beta prototype. A GUI-based interface built as an Eclipse plug-in allows users to operate it in a simple and intuitive manner. The interface in particular includes an editing environment where users can build and run AspectX programs without detailed knowledge of the AspectX syntax. A large number of sample aspect programs are provided that can serve as blueprints for the construction of user-specific programs. A test suite is available that verifies the correct implementation of all weaving rules and the handling of all AspectX syntactical constructs.
XWeaver is registered as a SourgeForce project.