This article is the third part of the series of articles in this journal to describe our Aspect.NET project – an aspect-oriented programming (AOP) framework for Microsoft.NET based on a number of new ideas (for the first two articles, see #4 and 5 in the References section). This article analyzes the advantages of using AOP, presents the current status of Aspect.NET – its design principles, its working version – and gives some practical examples.

The evolution of software and the customers’ for it, as well as the needs of the everyday fixing, update, and enhancement of software often lead to poorly understandable and tangled code, with fragments of implementation of quite different functionalities unclearly intermixed in the same software modules.
   
The AOP approach allows you to define the implementation of crosscutting concerns in separate modules and to describe the approach’s weaving into the target code by high-level metalanguage. In particular, this relates to our Aspect.NET project.
  
In this article we’ll demonstrate how Aspect.NET helps to develop well-structured and clearly implemented applications, using the power of AOP as part of Visual Studio.NET 2005 (Whidbey).
   
First we’ll consider the general principles of the AOP technology, then we’ll describe the design and implementation principles of Aspect.NET, and finally we’ll show the advantages of Aspect.NET by way of an example of developing a software system of order processing.

AOP Background
AOP is one of the most prospective approaches among state-of-the-art software technologies. This technology offers simple and elegant ways of developing complicated software systems. Such systems usually consist of the code to implement business logic and the code that implements a variety of the other crosscutting concerns such as transaction mechanisms, security checks, profiling, and tracing. Crosscutting concerns penetrate several layers of abstraction and appear to be intermixed with each other and with the basic business logic code. Object-oriented programming allows you to clearly define the concepts of the problem domain, but for solving most of the tasks combining several objects and updating several abstract layers is required. For example (see #1 in the References section), to add to an operating system the new functionality of prefetching data from memory, it should be implemented at the virtual memory layer, file system layer (local and remote), and disk layer, and runtime context information on prefetching should be passed between those abstract layers. Design and code patterns afford the ability to combine several objects at the same abstract layer for solving some task. However first, to apply them one should manually make changes to the existing classes, since the patterns cannot be automatically extracted and reapplied to some other projects. Second, the implementation of patterns penetrates a number of modules, which are crosscutting concerns themselves.
   
Aspect-oriented programming allows you to define the implementation of a crosscutting concern as a single module (referred to as an aspect), together with the rules of their weaving into the target code – pointcuts, and with the actions to be inserted into some definite points of the target code – joinpoints. It helps to both better understand the functionality implemented as an aspect definition (since all of the aspect’s code is located in one place), and to make it reusable (since, in order to weave the aspect into different joinpoints, it is enough to change its pointcuts).
   
It should be noted that AOP does not replace OOP, but that it complements it in quite a natural way. The implementation of patterns by means of AOP increases their efficiency (see #2 in the References section). All of the AOP systems follow this general approach. Currently the most common AOP tools are Java oriented, and AOP implementations for Microsoft.NET are still at the experimental stage.
   
The most widespread and powerful AOP tool is AspectJ (www.aspectj.org) implemented as an extension of the Java programming language by aspect definition metalanguage. For implementing such an approach, all of the architecture should be developed from scratch and changed every time the language specification is updated As compared to this approach, developing aspect declarations in a separate metalanguage allows for a more flexible way of defining aspect and its weaving rules, and improves readability of aspects.
   
There are a number of alternative approaches to aspect definition that allow for the declaration of aspects in an already existing language. They are based on aspect declarations represented as attributes (AspectWerkz [http://aspectwerkz.codehaus.org/] for Java, AOP.NET [M. Blackstock. Aspect Weaving with C# and .NET.        
      
www.cs.ubc.ca/~michael/publications/AOPNET5.pdf]) or XML files (JBoss AOP [www.jboss.org/ products/aop], Spring AOP [www.springframework.org/docs/reference/aop.html] for Java, Weave.NET [www.dsg.cs.tcd.ie/sites/Weave.NET.html]). The main advantage of these approaches is the opportunity to use already existing tools for application development. The shortcoming of aspect representation by attributes is as follows: complicated aspect definitions in this format are more difficult to read and understand. There is an additional shortage of aspect representation by XML files – specification of aspects is stored separately from their implementation.
   
Aspect weaving into a target application can be performed dynamically (JBoss AOP, Spring AOP, AOP.NET or interceptor approach [see #3 in the References section]) or statically (AspectJ, CCC for .NET [Y. Xiong, F. Wan. CCC: An Aspect Oriented Intermediate Language on .NET Platform: www.fit.ac.jp/~zhao/waosd2004/ pdf/Xiong.pdf]). In the former case, the virtual machine invokes the appropriate actions of the aspect when the related conditions are satisfied at runtime. In this case, the overhead for aspect weaving can dramatically decrease the performance. Besides, with runtime aspect weaving, the set of joinpoints that can be tracked is somewhat limited and some kinds of events just cannot be caught, e.g., access to or update of some field. On the contrary, with static aspect weaving, the aspects woven and the target application are joined together, at the class file/bytecode level for Java or at assembly/MSIL code level for .NET. In this case, there is actually no overhead related to invoking the actions of the aspects, and, in addition, the result of weaving is more understandable and can be viewed by the user.
   
Finally, an important reason why AOP tools are not yet widespread for .NET is the lack of adequate GUI in the current tools. For this reason, features of visual debugging and visualizing aspects are lacking also. In their turn, AOP tools for Java are available via a popular integrated development environment – Eclipse.
   
Now let’s consider how the above and a number of other issues are successfully resolved in Aspect.NET (see #4, 5, and 6 in the References section).

Aspect.NET Design Approach
Aspect.NET is a language-agnostic visual environment for developing aspect-oriented applications for Microsoft.NET that was implemented as an add-in to Microsoft Visual Studio.NET 2005 (Whidbey). Also supported is functioning in an SSCLI (Rotor) environment. Using Aspect.NET, the user can define and weave aspects and assess the results of the weaving in his or her projects.
   
Aspect.NET uses two approaches to aspect definition: AOP metalanguage and attribute specifications. An aspect definition in Aspect.NET is mapped to a special kind of Whidbey project (Aspect) that can be either converted to the aspect’s implementation class with the appropriate attribute annotations, or compiled straight to the aspect’s assembly.  Then, the compiled aspect’s assembly is used in aspect weaving.
   
Detailed description of our AOP meta-language can be found in the References section (4-6). In short, an aspect definition consists of:

• header (with optional formal parameters)
• data (optional)
• modules (classes, methods, functions, etc.)
• actions (method calls or just statements)
• weaving rules for each action in Aspect.NET metalanguage

    Weaving rules (or pointcuts in terms of the more common AOP tools) are suggestions for the weaver pertaining to where and how to join the action to the target application or to its module subject to the weaving operation.
For example, the construct

%before %call *OrderSystem.StartOrderProcessing

means the following: insert the aspect’s action before calling the StartOrderProcessing method of the OrderSystem class. Listing 1 shows an example of aspect for implementing profiling functionality for an order processing system.
   
An aspect can use information in the context of a joinpoint to which its action is woven. In the current version, this context information can be passed as arguments to the action. In the example in Listing 1, the string argument methname is the full qualified name of the method that the action is applied to, e.g., Orders.OrderSystem.StartOrder- Processing. If the second argument of the action is of type Object, it denotes a reference to the target object to whose member the action was applied, or null, if the member is static.