Aspect-Oriented Programming Under .NET

1. Aspect-Oriented Programming Under .NET Ramaswamy Krishnan-Chittur Advisor: Dr. James W. Fawcett

2. Contents • Background – An example • Introduction - How AOP works • Aspects explored - We studied four areas of application • Analysis - Comparison of metrics with and without • Conclusion - How effective is AOP? • Future work • Summary • Bibliography - 30 references in Thesis

3. 1. Background • Let us consider the following piece of code that calculates the area of a sector, given the radius and angle: public double SectorArea (double radius, double angle) { return ( radius * radius * angle / 2 ); } • Now, if we want to ensure that the code enables range check on its parameters and on the return value, such that • The radius must be non negative. • The angle should be between 0 and 2 PI, and may be • The return value, i.e., the sector area, is a non-negative value then, the code should be modified as follows:

4. 1. Background • The code with the validation check for its parameters could be: public double SectorArea (double radius, double angle) { if (radius < 0.0) throw new ArgumentOutOfRangeException ("radius out of range."); if ( (angle < 0.0) || (angle > 2 * 3.14) ) throw new ArgumentOutOfRangeException ("angle out of range."); double result = ( radius * radius * angle / 2 ); if (result < 0) throw new Exception (“Return value out of range."); return result; } • Wouldn’t it be better if we can develop a code like the following snippet for this purpose? [return: Range (Lower = 0.0)] publicdouble SectorArea ([Range (Lower = 0.0)] double radius, [Range (Lower = 0.0, Upper = 6.28)] double angle) { return ( radius * radius * angle / 2 ); }

5. 1. Background • This (AOP-based) code has managed to remove the if-then-else’s from the application code. • The style is Declarative programming. We replaced imperative code with a declaration of an attribute. • It is clear from the AOP-code that: • The return value has a lower bound of 0.0 • The parameter radius has a lower bound of 0.0 • The parameter angle has to be between 0.0 and 2 times PI • If any of the parameters, or the return value go out of range, an exception is raised with the necessary details which in turn, can be handled appropriately by the client.

6. 2. Introduction –Improving management of large software systems • SP - Structured Programming: Decomposes large monolithic programs into modules using functional decomposition • OOD - Object Oriented Design: Associates data with functions allowed to act on that data, e.g., an object, proven to be an effective structuring tool. • COM - Component Object Model: Reduces interdependencies between objects, using interfaces and object factories for isolation. • AOP - Aspect Oriented Programming: Separates program’s primary functionality from needed support infrastructure to simplify a program’s logic.

7. 2. Introduction -Aspects • In the early 1990’s, Gregor Kiczales et. al. published a seminal paper on what they called “the young idea of Aspect Oriented Programming” (AOP) at Proc-Europe Conference on object-oriented programming • In commonly employed code, there are elements that are orthogonal to the primary functionality of the code. • These elements, though extraneous to the primary purpose of the code, are vital to its proper execution. • Further more, they tend to be scattered throughout the system so that they contribute to the complexity of the code. • These elements are called aspects. • Examples of aspects include processing to support ‘security’, ‘fault-tolerance’ and ‘synchronization’.

8. 2. Introduction –AOP • Aspect-oriented programming (AOP) isolates aspects into separate modules so that the resulting client-code is • more purpose-specific, • more reusable, and • less complex. • The technique used in this thesis work for implementing AOP is the interception of method calls. • Interception is triggered by declaring attributes.

9. 2. AOP – How it works

10. 2. Introduction – Interception: Technique for implementing AOP

11. 2. AOP application : LAN Server

12. 2. Remember the Range Checker Example? • The code with the validation check for its parameters could be: public double SectorArea (double radius, double angle) { if (radius < 0.0) throw new ArgumentOutOfRangeException ("radius out of range."); if ( (angle < 0.0) || (angle > 2 * 3.14) ) throw new ArgumentOutOfRangeException ("angle out of range."); double result = ( radius * radius * angle / 2 ); if (result < 0) throw new Exception (“Return value out of range."); return result; } • Wouldn’t it be better if we can develop a code like the following snippet for this purpose? [return: Range (Lower = 0.0)] publicdouble SectorArea ([Range (Lower = 0.0)] double radius, [Range (Lower = 0.0, Upper = 6.28)] double angle) { return ( radius * radius * angle / 2 ); }

13. 2. Analysis of Range Checker • Client code statistics: • AOP library statistics: Client code: application-specific AOP library: Developed ONCE

14. 2. Analysis of Range Checker – payoff • AOP reduces the complexity of the application code: • less if-then-elses in the client code. • AOP captures the purpose of the code better: • [Range (Lower = 0.0)] double radius at the function declaration is more explicit and more readable than if (radius < 0.0) throw new ArgumentOutOfRangeException (“..."); in the body of the function. • AOP enhances abstraction and encapsulation: • The validation check is isolated as a separate module. Any change to validation check handling can be made at this ONE place. • AOP promotes reusability: • The range-checker attribute provides a common point where the out-of-range exceptions can be handled. • The range-checker can be applied to a variety of classes which need range-checks.

15. 2. But ---- • We have to exert significant effort to set up an attribute. • If we choose wisely the targets for AOP, where there are many opportunities to use them, then: • We simply declare attributes every place we need the service. • We don’t need to repeatedly write code to supply the service.

16. 2. Research Goals • To identify several applications where the aspect-oriented approach can be applied. • Aspects that are dealt with in this thesis work are: • Method-Synchronization, • Debugging, • Code-Profiling, • Prioritization, • Validation. • To evaluate the impacts of AOP on code complexity and performance. • Performance evaluation is based on metrics concerned with • cohesion, • line count, • cyclomatic complexity of the code.

17. 2. Outline • In the following sections, I will discuss the • The different aspects that were dealt with in this research • Method Synchronization • Debugging • Code Profiling • Message Prioritization • Summary of results • Conclusions • Prospects for future work

18. 3.1. Method Synchronization • Consider the following cases: • Writing to a file. • Enqueue, Dequeue operations on a queue. • These are two classical cases that require thread synchronization. Clearly, synchronization is orthogonal to purpose of these operations, but vital as well. • Synchronization, hence, can be classified as an Aspect.

19. 3.1. Method Synchronization – Background • Synchronization is often achieved by object synchronization, i.e., synchronizing the object: • The File stream in a file writing operation, • The Queue in an Enqueue / Dequeue operation. • Here, I discuss method synchronization using AOP. • A thread that enters must complete before another enters. • Methods synchronized with the same attribute do not execute simultaneously.

20. 3.1. Method Synchronization – Purpose • Method synchronization offers a simple solution to synchronize methods, even if the methods belong to different types. • Quite often in object synchronization, the synchronized object is locked throughout the method execution. Method synchronization offers a more purpose-specific substitute for these applications, by removing the synchronizing code from the body of the methods. • Method synchronization can be used for synchronizing even those sets of methods that DON’T work on a common object.

21. 3.1. Method Synchronization – Technique AOP code [Sync("Q")] publicvoid EnQ(string msg) { this.Q.Enqueue(msg); } [Sync("Q")] publicstring DeQ() { if(this.Q.Count == 0) thrownew Exception(); else return (string)this.Q.Dequeue(); } Synchronization aspect declared using attribute

22. 3. What we don’t say here • Technically, a lot is going on to make all this happen. • We’ve explained each step in some detail in Chapter 2 of the Thesis • Discusses basis for interception. • Chapter 3 discusses how interception is applied to Method Synchronization.

23. 3.1. Method Synchronization – Analysis • Client code statistics: • AOP library statistics:

24. 3.1. Method Synchronization – Contribution • Invented a new way of achieving Method-Synchronization in a .NET environment • Developed a .NET library that isolates the synchronization aspect into a module, and enables client code developers to plug this aspect into their application • Analyzed the incremental benefit and cost to use AOP for Method Synchronization.

25. 3.2. Debugging • A debugger application helps a client-code developer functionally interact with the code under execution. • A debugger should have at least some basic features, like capability to • programmatically set break points, • to restart the process being debugged, • to print out a stack trace, • to manipulate argument values

26. 3.2. Debugging –Introduction • Here, we discuss a new way to develop ‘debugger’ facilities that integrate into an application. • We think that integrated debugging may be very useful for vertical niche applications like Radar processing. • ‘Debugging’ is an aspect, and employing AOP is an effective way to develop applications with integrated ‘debugging’ capabilities. • This aspect can be successfully isolated into a library, and used with client code to develop a debugger-integrated aspect-oriented code.

27. What This Debugger Does • The custom debugger application that we have developed using AOP has facilities to: • Programmatically set break points • Manipulate input parameter values from sink stack • Print out the stack trace in case of an exception • Manipulate the return value • Ignore a return-exception, and substitute it with a dummy return value • Restart the application, all over again, at any point during execution

28. 3.2. Debugging –Architecture

29. 3.2. Debugging –Technique • Enabling / Disabling Debugging Enable debugging [DebuggerContext(true)] publicclass Closed : System.ContextBoundObject { // Closed figure class. } Disable debugging [DebuggerContext(false)] publicclass Closed : System.ContextBoundObject { // Closed figure class. }

30. 3.2. Debugging –Technique • Programmatically setting up break points Break point [DebuggerContext(true)] publicclass Closed : System.ContextBoundObject { [Debug(true)] publicdouble ClosedCalcArea(double Area) { // method implementation } }

31. 3.2. Debugging –Technique • Tracing and displaying metadata information • Traces info regarding • Argument • Method • Instance • Parameters

32. 3.2. Debugging –Technique • Pre-processing Application console Debugger window Editing the argument value

33. 3.2. Debugging –Technique • Post-processing An exception may be negated! Printing out the stack trace Process may be restarted

34. 3.2. Debugging –Technique • Tracing code segment that raised exception

35. 3.2. Debugging –Contribution • Our primary contribution has been in identifying that debugging is an aspect - Debugging features can be integrated into application code using AOP. • We have developed, for the purpose of illustration, a custom interception library which performs debugging services by intercepting method calls. • Integrated Debuggers could be quite valuable for specialized applications.

36. 3.3. Code profiling • Code profiling is the process of analyzing and quantifying the quality of a piece of code. • Here, we propose that code profiling applications can be developed effectively using AOP. • Code profiling areas that we have explored are – • Code Coverage: We discuss an Aspect-Oriented approach to develop code coverage applications. • Time Profiling: We illustrate an execution-time profiler application developed using AOP

37. 3.3.1. Code coverage • code coverage analysis: the process of discovering methods in a program that are not examined using a set of test cases. • Test drivers are executive codes that explore the functioning of a program. The two primary goals of a test driver are to • test all the methods in a program, and • to determine if they gracefully handle probing test cases supplying both good and bad inputs. • Code coverage analysis is a means to help the test driver designer achieve the first purpose - finding out if all the methods in a program have been tested.

38. 3.3.1. Code coverage – Technique [ Profile ( true ) ] public class MyClass : System.ContextBoundObject { // class implementation } True: Enable code coverage profiling False: Disable profiling

39. 3.3.2. Time Profiling • Time profiling: the process of finding out the time of execution of a method call with a specified set of parameters. • A time profiler collects data about how much time is consumed by the different methods in the program, with any specified argument list. This information enables the programmer to find out if execution times of various functions are acceptable. • Here, we explore AOP-based time profiling based on run-time interception of method calls

40. 3.3.2. Time profiling – Technique [ TimeProfile ( true ) ] public class MyClass : System.ContextBoundObject { // class implementation } True: Enable time profiling False: Disable time profiling

41. 3.3.2. Time profiling – Critical issues 1. Issue: Accuracy of time measurement: Solution - The AOP library uses a high-resolution timer (least count = 1 micro second) to determine the time of execution of any intercepted method call. 2.Issue: Overheads of Inter-context message passing: Solution - To reduce this inaccuracy, we employ ‘null interval’ techniques.

42. 3.3.Code profiling – Contributions • Identified aspect-oriented ways to develop code coverage applications. • Explored AOP-based time profiling - • A couple of issues regarding inaccuracy of measurement were identified, and solutions have been proposed. • The code profiler has been applied to a medium sized prototype application with interesting results.

43. 3.4. Prioritization • Consider a typical distributed computing system, where many clients talk to one server. • Due to its limited processing potential, a single-server environment requires effective and well-defined priority criteria – for its clients, and for the messages it needs to process. • Prioritization may be a crucial issue in a single-server environment, or generally in any system where the server’s workload is quite heavy compared to its processing power.

44. 3.4. Prioritization– Introduction • Priority assignment of messages is not the actual business of clients. • Similarly, prioritizing its clients is not the actual business of the server. Ideally, however, the server would have a provision for processing high priority clients first. • It would be useful if all distributed systems had a provision for prioritizing messages and clients, though each new developer would prefer not to have to produce code developed solely for this purpose. • For these reasons, we explore ‘prioritization’ as an aspect

45. 3.4.1. Client Prioritization • A server might need to handle requests from various clients; of these some clients might require higher priority than the others. For instance, in the case of a simple LAN, client prioritization may mean that the requests from an administrator be given higher priority than requests from staff personnel. • Client prioritization is the feature that enables the server to process messages from different clients based on the priority levels of those clients.

46. 3.4.1. Client Prioritization – Technique Add “Client Prioritization” logic here Specifying clients’ priorities in a file at the server side

47. 3.4.2. Message Prioritization • In a distributed computing system, clients send different types of messages to the server. Of these, some require higher priority than the others. For instance, an ‘Error’ message might be of higher priority than an ‘File-transfer’ message. • Message prioritization is the feature that enables a client to set a priority level for messages being sent to the server.

48. 3.4.2. Message Prioritization –Technique Add “message priority assignment” logic here.

49. 3.4. Prioritization –Contribution • Our primary contribution in this chapter has been in identifying that prioritization can be classified as an aspect of a distributed computing system, and can be successfully isolated into a separate module using AOP. • We have explored AOP-based • client prioritization and • message prioritization as two specialized cases of priority assignment. • The methods discussed here have been demonstrated on small prototype examples.

50. 4. Analysis • Let us quickly review the aspects that were dealt with in this thesis presentation: • a Range-Checker application, involving validation • “Method Synchronization” • “Debugging” • “Code-Profiling” • Code coverage • Time profiling • “Prioritization”. • Client prioritization • Message prioritization