Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:37:12Z

Vdiyer: /* Terminologies used in Aspect Oriented Programming */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.'''Cross-cutting concerns''':(For a definition, go to [[http://en.wikipedia.org/wiki/Cross-cutting_concern Appendix 3]].) Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.'''Advice''': Advice is the extra code that we want to add to our already existing model.

3.'''Point-cut''': Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.'''Aspect''': Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Inside the classes, existing methods can be wrapped around by code using AspectR.The design of the code can be improved since it separates different concerns into different parts of the code. It is similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

'''3'''. cross cutting concerns - http://en.wikipedia.org/wiki/Cross-cutting_concern

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:33:25Z

Vdiyer: /* Terminologies used in Aspect Oriented Programming */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns:(For a definition, go to [[http://en.wikipedia.org/wiki/Cross-cutting_concern Appendix 3]].) Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Inside the classes, existing methods can be wrapped around by code using AspectR.The design of the code can be improved since it separates different concerns into different parts of the code. It is similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

'''3'''. cross cutting concerns - http://en.wikipedia.org/wiki/Cross-cutting_concern

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:32:15Z

Vdiyer: /* Appendix */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns:[[http://en.wikipedia.org/wiki/Cross-cutting_concern Appendix 3]] Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

'''3'''. cross cutting concerns - http://en.wikipedia.org/wiki/Cross-cutting_concern

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:31:31Z

Vdiyer: /* Terminologies used in Aspect Oriented Programming */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns:[[http://en.wikipedia.org/wiki/Cross-cutting_concern Appendix 3]] Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:29:20Z

Vdiyer: /* Appendix */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:29:02Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:28:19Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

• Join points

• Object receives method/constructor call

• Field accessed (if access is via getter/setter method)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:27:05Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR:

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects:

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:16:39Z

Vdiyer: /* AspectJ Plugin tool */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]].
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:16:19Z

Vdiyer: /* AspectJ Plugin tool */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[http://eclipse.org/ajdt/ Appendix 2]]
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:15:48Z

Vdiyer: /* AspectJ Plugin tool */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ. For a clearer definition, go to [[ Appendix 2]]
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:14:53Z

Vdiyer: /* AspectJ */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC. For a better definition, go to [[http://en.wikipedia.org/wiki/AspectJ Appendix 1]]

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:13:56Z

Vdiyer: /* Appendix */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

'''1'''. AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. For more information refer to: http://en.wikipedia.org/wiki/AspectJ

'''2'''. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:07:04Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ. [[http://aspectr.sourceforge.net/ 5]]

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect

• Supports "abstract" Aspects and overriding between advices.

• Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

• Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:

source:http://aspectr.sourceforge.net/
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.[[http://aspectr.sourceforge.net/ 5]]

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base.[[http://aquarium.rubyforge.org/index.html 6]]

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.[[http://aquarium.rubyforge.org/index.html 6]]

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T22:01:22Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect.

Supports "abstract" Aspects and overriding between advices.

Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

source: http://aspectr.sourceforge.net/
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T21:58:24Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect.

Supports "abstract" Aspects and overriding between advices.

Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

source: http://aquarium.rubyforge.org/index.html
class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T21:50:42Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised

Aspects: classes inheriting Aspect.

Supports "abstract" Aspects and overriding between advices.

Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advices to

Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T21:49:37Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call

• Field accessed (if access is via getter/setter meth)

Advices: before (pre), after returning and after throwing (post)

Advices can access:

• Object and method receiving call

• Arguments to call

• Return value

• exceptions raised.

Aspects: classes inheriting Aspect.

Supports "abstract" Aspects and overriding between advices.

Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to.

Pointcut parameters.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T21:47:23Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo):

Join points:

• Object receives method/constructor call, and

• Field accessed (if access is via getter/setter meth) * Advices: before (pre), after returning and after throwing (post) *

Aspects: classes inheriting Aspect.

• Supports "abstract" Aspects and overriding between advices. * Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to. * Pointcut parameters.

Advices can access:

• Object and method receiving call,

• Arguments to call,

• Return values, and

• exceptions raised.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T21:47:06Z

Vdiyer: /* AspectR */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== AspectR ==

Aspect-oriented programming concepts to Ruby is provided by AspectR. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo):

* Join points:

• Object receives method/constructor call, and

• Field accessed (if access is via getter/setter meth) * Advices: before (pre), after returning and after throwing (post) *

Aspects: classes inheriting Aspect.

• Supports "abstract" Aspects and overriding between advices. * Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to. * Pointcut parameters.

Advices can access:

• Object and method receiving call,

• Arguments to call,

• Return values, and

• exceptions raised.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called.

== Appendix ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== References & Resources ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

[4]http://rubyforge.org/projects/aquarium/

[5]http://aspectr.sourceforge.net/

[6]http://aquarium.rubyforge.org/examples.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T19:59:51Z

Vdiyer: /* Aspect R */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== ASPECTJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== APPENDIX ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== Aspect R ==

Aspect-oriented programming concepts to Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo): * Join points:

• object receives method/constructor call, and

• field accessed (if access is via getter/setter meth) * Advices: before (pre), after returning and after throwing (post) *

Aspects: classes inheriting Aspect.

• supports "abstract" Aspects and overriding between advices. * Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to. * Pointcut parameters.

Advices can access:
• object and method receiving call,

• arguments to call,

• return values, and

• exceptions raised.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:

class ServiceTracer
include Aquarium::DSL before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args log "Entering:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|log "Leaving:
#{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
end
end

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called!

== REFERENCES ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T19:48:11Z

Vdiyer: /* Aspect R */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== ASPECTJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== APPENDIX ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== Aspect R ==

Aspect-oriented programming concepts to Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo): * Join points:

• object receives method/constructor call, and

• field accessed (if access is via getter/setter meth) * Advices: before (pre), after returning and after throwing (post) *

Aspects: classes inheriting Aspect.

• supports "abstract" Aspects and overriding between advices. * Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to. * Pointcut parameters.

Advices can access:
• object and method receiving call,

• arguments to call,

• return values, and

• exceptions raised.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:
class ServiceTracer
include Aquarium::DSL 
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| 
log "Entering: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}" 
end 
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| 
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}" 
end 
end 

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:

class ServiceTracer
include Aquarium::DSL around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| log "Entering:
{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called!

== REFERENCES ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T19:36:27Z

Vdiyer: /* Aspect R */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== ASPECTJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== APPENDIX ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== Aspect R ==

Aspect-oriented programming concepts to Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo): * Join points:

• object receives method/constructor call, and

• field accessed (if access is via getter/setter meth) * Advices: before (pre), after returning and after throwing (post) *

Aspects: classes inheriting Aspect.

• supports "abstract" Aspects and overriding between advices. * Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to. * Pointcut parameters.

Advices can access:
• object and method receiving call,

• arguments to call,

• return values, and

• exceptions raised.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:
class ServiceTracer
include Aquarium::DSL 
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| 
log "Entering: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}" 
end 
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| 
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}" 
end 
end 

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:
class ServiceTracer
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
log "Entering: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called!

== REFERENCES ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T19:33:44Z

Vdiyer: /* Aspect R */

== ''' Aspect Oriented Programming - An Introduction''' ==

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems began to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own. [[http://onjava.com/onjava/2004/01/14/aop.html 1]]

== Terminologies used in Aspect Oriented Programming ==

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Here are the definitions of some of the standard terms that would be required to understand AOP concepts.

1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

2.Advice: Advice is the extra code that we want to add to our already existing model.

3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.

4.Aspect: Aspect is the combination of the point-cut and the advice.

The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers. [[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== AspectJ ==

AOP has been implemented in different languages, among them Smalltalk and Java. The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox PARC.

Like any other aspect-oriented compiler, the AspectJ compiler includes a weaving phase that unambiguously resolves the cross-cutting between classes and aspects. AspectJ implements this additional phase by first weaving aspects with regular code and then calling the standard Java compiler. [[http://www.voelter.de/data/articles/aop/aop.html 3]]

Let's consider the following example to understand this better.
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
source: http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

[[http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm 2]]

== ASPECTJ Plugin tool ==

The AspectJ Development Tools (AJDT) project provides Eclipse platform based tool with AspectJ.
AspectJ is run under the same open source collective as the Eclipse project and provides the most advanced AspectJ plug-in for an IDE. The AspectJ Development Tools (AJDT) for Eclipse not only provides Eclipse users with tools to code AspectJ applications, but also includes a visualizer to show you where your aspects will be applied. To know how to install this tool AJDT, click here http://onjava.com/onjava/2004/11/24/aspect_j.pdf or http://www.eclipse.org/ajdt/EclipseCon2006/

== APPENDIX ==

1. For more information on AJDT, click here : http://eclipse.org/ajdt/

== Aspect R ==

Aspect-oriented programming concepts to Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. It is somewhat similar to AspectJ

Main features of AspectR (in AspectJ lingo): * Join points:

• object receives method/constructor call, and

• field accessed (if access is via getter/setter meth) * Advices: before (pre), after returning and after throwing (post) *

Aspects: classes inheriting Aspect.

• supports "abstract" Aspects and overriding between advices. * Wildcards (really regexps) can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to. * Pointcut parameters.

Advices can access:
• object and method receiving call,

• arguments to call,

• return values, and

• exceptions raised.

AspectR lets a module wrap any number of methods in other classes (or objects) with the "advice" methods (in the lingo of Aspect/J) of the module.

require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...) or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/) or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)

Advice methods are passed a variable number of parameters: the first is the name of the method currently being wrapped the second is the object receiving the method call the third is the exit/return status:
Array with return value(s) if the method exited normally
true if the method exited with an exception
nil if the method hasn't yet exited (for preAdvice)
the rest are the arguments that were passed to the wrapped method.

Aquarium is a framework that implements Aspect-Oriented Programming (AOP) for Ruby.
Aquarium provides a Domain Specific Language (DSL) with which you can express “aspectual” system behaviour in a modular way, i.e.,using a succinct language and without repeating yourself all over your code base!

Imagine you want to trace all invocations of the public, instance methods in all classes whose names end with “Service”. Here’s how you can implement that behavior in Aquarium:
class ServiceTracer
include Aquarium::DSL 
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| 
log "Entering: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}" 
end 
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args| 
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}" 
end 
end 

The #before advice adds behavior that is invoked before each method is invoked, in this case, it logs a message with the name of the executing class and method, followed by the list of arguments passed to the method.
The #after advice adds similar behavior the is invoked after each method is invoked.

A more succinct implementation of this behavior uses #around advice:
class ServiceTracer
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
log "Entering: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result = join_point.proceed
log "Leaving: #{join_point.target_type.name}##{join_point.method_name}: object = #{object}, args = #{args}"
result # block needs to return the result of the "proceed"!
end
end

The special method #proceed invokes the advised method, passing it the args list (by default). For #around advice, you must call#proceed unless you specifically don’t want the original method called!

== REFERENCES ==

[1] http://onjava.com/onjava/2004/01/14/aop.html

[2] http://www.developer.com/design/article.php/3308941/Aspect-Oriented-Programming.htm

[3] http://www.voelter.de/data/articles/aop/aop.html

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:29:33Z

Vdiyer: /* REFERENCES */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:29:13Z

Vdiyer: /* AspectJ */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:27:18Z

Vdiyer: /* REFERENCES */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:26:53Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:25:01Z

Vdiyer: /* AspectJ */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:23:21Z

Vdiyer: /* '''APPENDIX''' */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:23:02Z

Vdiyer: /* '''APPENDIX''' */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:22:46Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:20:53Z

Vdiyer: /* Terminologies used in Aspect Oriented Programming */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:20:05Z

Vdiyer: /* ''' Aspect Oriented Programming - An Introduction''' */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:16:23Z

Vdiyer: /* Terminologies used in Aspect Oriented Programming */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:15:00Z

Vdiyer: /* ASPECTJ Plugin tool */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T17:13:50Z

Vdiyer: /* AspectJ */

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T15:44:53Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T15:40:13Z

Vdiyer:

When Object-Oriented (OO) programming was entering into the field of software development, it changed the way how software was developed. The software systems begun to be viewed as groups of entities and the interaction between those entities, which allowed them to tackle larger, more complicated systems and develop them in less time than ever before. However, OO programming is static, and a thus a change in requirements could have a brought a major impact on development time lines.

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops.

For example, we develop a web application where a servlet accepts the values of an HTML form, binds them to an object, passes them into the application to be processed, and then returns a response to the user. This basic functionality of the servlet may be very simple, and can be fulfilled with minimum amount of code. But, by the time secondary requirements such as exception handling, security, and logging have been implemented , the size of the code increases to about three times of original. Having said that, it is not mandatory for the servlet to know about the logging or security mechanisms being used, and hence can be called as secondary requirements. Its primary function is to just accept input and process it.

Using AOP , we can dynamically modify our static model to include the code required to fulfill the secondary requirements without having to modify the original static model. We can also keep this additional code in a single location rather than having to scatter it across the existing model, as we would have to if we were using OO on its own.

ASPECTJ

Here are some of the standard terms that would be required to understand AOP concepts.
1.Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.
2.Advice: Advice is the extra code that we want to add to our already existing model.
3.Point-cut: Point-cut is the point of execution in the application at which cross-cutting concern needs to be applied.
4.Aspect: Aspect is the combination of the point-cut and the advice.
The other terms that appear often in AOP are introductions (where interfaces/methods/fields can be added to existing classes). These hold tremendous potential for developers,

Just as the important facets of OOP are inheritance, encapsulation, and polymorphism, the components of AOP are join points, pointcut, advice, and introduction.

Let's consider the following example to understand this better.
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {
System.out.println (s);
}
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
This is the existing Java code called TestClass.java. Now if we want to make use of aspects to make two modifications such as:
1.We would like to print a message before and after any call to the TestClass.sayHello() method.
2.We need to test that the argument of the TestClass.sayAnyThing() method is at least three characters.

Here is the AspectJ implementation
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String))
&& args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3
characters");
13: return;
14: }
15: }
16: }

From 1, we see that an aspect is defined in the same way as a Java class. Just like any Java class, an aspect may have member variables and methods. In addition, it may include pointcuts, advices, and introductions.
In lines 2 and 3, we specify the place in the TestClass code where our modification will take place.
In AspectJ, 'join points' represent well-defined points in a program's execution. Typical join points in AspectJ include method/constructor calls, method/constructor execution, field get and set, exception handler execution, and static and dynamic initialization. In the example above, two join points are used :the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria. The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall (): call (public void
TestClass.say*() );

In this line, we define a pointcut- sayMethodCall, which picks out any call to the TestClass.sayHello method. It also picks out any public TestClass method with zero arguments and a name that starts with 'say' (for example, TestClass.sayBye).
Pointcuts are used in the definition of advice. An advice is used to define additional code to be executed before, after, or around join points. In our example, lines 4–6 and 7–9 define two advices that will be executed before and after the first pointcut. Lines 10–15 implement an advice associated with the second pointcut and are used to set a precondition before the execution of the TestClass.sayAnyThing method.
Thus pointcuts and advice let us affect the dynamic execution of a program.
Introduction allows aspects to modify the static structure of a program. By using introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions.

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T15:38:49Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T15:36:15Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T15:35:39Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki29 VB

2009-10-09T15:34:02Z

Vdiyer:

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:21:21Z

Vdiyer: /* C# */

XUnit in general, is only one kind of testing framework for object oriented languages. This page talks about the major testing frameworks available for the major object oriented languages such as Java, C++, C#,Python, Ruby and C#. Comparisons have been made wherever possible between the major frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto standard for unit testing. However, other frameworks such as TestNG, JTIGER have been built to address various faults and deficiencies with JUnit. Our primary objective is to compare the various testing frameworks that exist for object oriented languages based on the primary purpose of the framework, features, the platforms on which they operate, etc and thus help in picking up the best testing framework that fits in a particular suitable environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit and XUnit, please refer to the http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']] and [[http://en.wikipedia.org/wiki/XUnit '''APPENDIX 2''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of testing such as unit testing, integration testing, functional testing, end-to -end testing. (For definition and more information on the different kinds of testing, refer to [[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']] and [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']]

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in them.
Add the information about our test (such as the class name, the groups we wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology used in Test automation where test scripts are executed and verified based on the data values stored in one or more central data sources or databases. For a detailed description on data driven testing click here: http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods that belong to these groups and specify groups that contain other groups. It is very flexible as it can help in choosing one set of regular expression and excluding the other sets. This splits the various test groups and there is no need to recompile again if we want to run two different tests back to back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA, MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing. The tests written for this framework will exercise the interactions with the container. Cactus also provides other frameworks such as code logic unit testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that it is much easier to have to write tests for a single framework than for several. It is believed that Cactus provides a middle ground that provides a high confidence that your code will run when deployed .[[http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

== '''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit testing,Functional testing, end-to-end testing, integration testing ||Primarily unit testing. Also have frameworks for code logic unit testing , functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites, ||Flexible for running large test suites of code and thus one test\'s failure shouldn\'t mean having to rerun a suite of thousands. || No, it is suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE, IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an effective unit-testing framework, meaning that it was built to facilitate testing single objects. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to define a test as a method whose name starts with test, and we can now run fixtures just once as opposed to for each test. However TestNG established itself as an annotations-based framework long before Junit 4. TestNG pioneered testing with annotations in Java programming, which made it a formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more information) method as static, which consequently requires us to also declare the fixture, finder, as static. We also have to declare the init() method as public. Looking at the TestNG code, you can find that such conventions aren't required. Its init() method is neither static nor public.
Flexibility has been one of the strong points of TestNG right from the start. JUnit works well for a unit of code, whereas TestNG is better suited for high-level testing. Its flexibility is especially useful with large test suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java 2 Micro Edition (J2ME) library containing a unit testing framework for J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.||A lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the power of an external scripting language. It provides some nifty advanced features and great assert functionality. It does require the use of a scripting language as part of the build process, so those uncomfortable with that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework The major drawbacks are the relative verbosity for adding new tests and fixtures. [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [[http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [[http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html 10]]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.

A well explained example can be seen at http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list
of testing frameworks are available for C# which are NUnit, csUnit, Pex, dotunit,
VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].
{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Nunit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''PEX'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take adavntage of the .NET languages. It is a free open source unit testing tool for all the test-driven development .NET languages including C#.||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases. It has been inspired from JUnit and can be used as an add-in along with the NUnit

||It is a tool to generate efficient unit tests with a high code coverage and are converted to C# automatically. It determines the relevant test inputs for the code hunting for boundary conditions, exceptions and assertion failures. Pex enables Parameterized Unit Testing, an extension of Unit Testing that reduces test maintenance costs.
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/The%20Hello%20World%20of%20Pex.html
|-
| Used as ||Testing framework, GUI and console tool||Testing Framework ,Console tool and VS.NET Add In||It supports NUnit, MbUnit and xUnit.net.Extensions for these test frameworks can be downloaded from the Pex Extensions Project[[http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/reference%20manual.html 14]].
|-
|
|}

=APPENDIX=

'''1''' '''JUnit''' - JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and comprises a family of unit testing frameworks collectively known as xUnit that originated with SUnit. (For more information refer to http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''2''' '''XUnit''' - Various code-driven testing frameworks have come to be known collectively as xUnit. These frameworks allow testing of different elements (units) of software, such as functions and classes. (For more information refer to http://en.wikipedia.org/wiki/XUnit)

'''3''' '''unit testing''' - unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use, where a unit is the smallest testable part of an application. For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''4''' '''integration testing''' - is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing. For more information refer http://en.wikipedia.org/wiki/Integration_testing

'''5''' '''BeforeClass''' - Refer to http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

'''6''' '''parameterized testing''' - . A parameterized unit test is simply a method that takes parameters, calls the code under test, and states assertions.

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6] http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

[14] http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/reference%20manual.html

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:19:50Z

Vdiyer: /* References */

XUnit in general, is only one kind of testing framework for object oriented languages. This page talks about the major testing frameworks available for the major object oriented languages such as Java, C++, C#,Python, Ruby and C#. Comparisons have been made wherever possible between the major frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto standard for unit testing. However, other frameworks such as TestNG, JTIGER have been built to address various faults and deficiencies with JUnit. Our primary objective is to compare the various testing frameworks that exist for object oriented languages based on the primary purpose of the framework, features, the platforms on which they operate, etc and thus help in picking up the best testing framework that fits in a particular suitable environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit and XUnit, please refer to the http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']] and [[http://en.wikipedia.org/wiki/XUnit '''APPENDIX 2''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of testing such as unit testing, integration testing, functional testing, end-to -end testing. (For definition and more information on the different kinds of testing, refer to [[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']] and [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']]

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in them.
Add the information about our test (such as the class name, the groups we wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology used in Test automation where test scripts are executed and verified based on the data values stored in one or more central data sources or databases. For a detailed description on data driven testing click here: http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods that belong to these groups and specify groups that contain other groups. It is very flexible as it can help in choosing one set of regular expression and excluding the other sets. This splits the various test groups and there is no need to recompile again if we want to run two different tests back to back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA, MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing. The tests written for this framework will exercise the interactions with the container. Cactus also provides other frameworks such as code logic unit testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that it is much easier to have to write tests for a single framework than for several. It is believed that Cactus provides a middle ground that provides a high confidence that your code will run when deployed .[[http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

== '''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit testing,Functional testing, end-to-end testing, integration testing ||Primarily unit testing. Also have frameworks for code logic unit testing , functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites, ||Flexible for running large test suites of code and thus one test\'s failure shouldn\'t mean having to rerun a suite of thousands. || No, it is suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE, IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an effective unit-testing framework, meaning that it was built to facilitate testing single objects. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to define a test as a method whose name starts with test, and we can now run fixtures just once as opposed to for each test. However TestNG established itself as an annotations-based framework long before Junit 4. TestNG pioneered testing with annotations in Java programming, which made it a formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more information) method as static, which consequently requires us to also declare the fixture, finder, as static. We also have to declare the init() method as public. Looking at the TestNG code, you can find that such conventions aren't required. Its init() method is neither static nor public.
Flexibility has been one of the strong points of TestNG right from the start. JUnit works well for a unit of code, whereas TestNG is better suited for high-level testing. Its flexibility is especially useful with large test suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java 2 Micro Edition (J2ME) library containing a unit testing framework for J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.||A lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the power of an external scripting language. It provides some nifty advanced features and great assert functionality. It does require the use of a scripting language as part of the build process, so those uncomfortable with that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework The major drawbacks are the relative verbosity for adding new tests and fixtures. [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [[http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [[http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html 10]]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.

A well explained example can be seen at http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list
of testing frameworks are available for C# which are NUnit, csUnit, Pex, dotunit,
VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].
{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Nunit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''PEX'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take adavntage of the .NET languages. It is a free open source unit testing tool for all the test-driven development .NET languages including C#.||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases. It has been inspired from JUnit and can be used as an add-in along with the NUnit

||It is a tool to generate efficient unit tests with a high code coverage and are converted to C# automatically. It determines the relevant test inputs for the code hunting for boundary conditions, exceptions and assertion failures. Pex enables Parameterized Unit Testing, an extension of Unit Testing that reduces test maintenance costs.
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/The%20Hello%20World%20of%20Pex.html
|-
| Used as ||Testing framework, GUI and console tool||Testing Framework ,Console tool and VS.NET Add In||It supports NUnit, MbUnit and xUnit.net.Extensions for these test frameworks can be downloaded from the Pex Extensions Project.
|-
|
|}

=APPENDIX=

'''1''' '''JUnit''' - JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and comprises a family of unit testing frameworks collectively known as xUnit that originated with SUnit. (For more information refer to http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''2''' '''XUnit''' - Various code-driven testing frameworks have come to be known collectively as xUnit. These frameworks allow testing of different elements (units) of software, such as functions and classes. (For more information refer to http://en.wikipedia.org/wiki/XUnit)

'''3''' '''unit testing''' - unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use, where a unit is the smallest testable part of an application. For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''4''' '''integration testing''' - is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing. For more information refer http://en.wikipedia.org/wiki/Integration_testing

'''5''' '''BeforeClass''' - Refer to http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

'''6''' '''parameterized testing''' - . A parameterized unit test is simply a method that takes parameters, calls the code under test, and states assertions.

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6] http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

[14] http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/reference%20manual.html

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:18:10Z

Vdiyer: /* APPENDIX */

XUnit in general, is only one kind of testing framework for object oriented languages. This page talks about the major testing frameworks available for the major object oriented languages such as Java, C++, C#,Python, Ruby and C#. Comparisons have been made wherever possible between the major frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto standard for unit testing. However, other frameworks such as TestNG, JTIGER have been built to address various faults and deficiencies with JUnit. Our primary objective is to compare the various testing frameworks that exist for object oriented languages based on the primary purpose of the framework, features, the platforms on which they operate, etc and thus help in picking up the best testing framework that fits in a particular suitable environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit and XUnit, please refer to the http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']] and [[http://en.wikipedia.org/wiki/XUnit '''APPENDIX 2''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of testing such as unit testing, integration testing, functional testing, end-to -end testing. (For definition and more information on the different kinds of testing, refer to [[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']] and [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']]

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in them.
Add the information about our test (such as the class name, the groups we wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology used in Test automation where test scripts are executed and verified based on the data values stored in one or more central data sources or databases. For a detailed description on data driven testing click here: http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods that belong to these groups and specify groups that contain other groups. It is very flexible as it can help in choosing one set of regular expression and excluding the other sets. This splits the various test groups and there is no need to recompile again if we want to run two different tests back to back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA, MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing. The tests written for this framework will exercise the interactions with the container. Cactus also provides other frameworks such as code logic unit testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that it is much easier to have to write tests for a single framework than for several. It is believed that Cactus provides a middle ground that provides a high confidence that your code will run when deployed .[[http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

== '''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit testing,Functional testing, end-to-end testing, integration testing ||Primarily unit testing. Also have frameworks for code logic unit testing , functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites, ||Flexible for running large test suites of code and thus one test\'s failure shouldn\'t mean having to rerun a suite of thousands. || No, it is suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE, IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an effective unit-testing framework, meaning that it was built to facilitate testing single objects. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to define a test as a method whose name starts with test, and we can now run fixtures just once as opposed to for each test. However TestNG established itself as an annotations-based framework long before Junit 4. TestNG pioneered testing with annotations in Java programming, which made it a formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more information) method as static, which consequently requires us to also declare the fixture, finder, as static. We also have to declare the init() method as public. Looking at the TestNG code, you can find that such conventions aren't required. Its init() method is neither static nor public.
Flexibility has been one of the strong points of TestNG right from the start. JUnit works well for a unit of code, whereas TestNG is better suited for high-level testing. Its flexibility is especially useful with large test suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java 2 Micro Edition (J2ME) library containing a unit testing framework for J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.||A lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the power of an external scripting language. It provides some nifty advanced features and great assert functionality. It does require the use of a scripting language as part of the build process, so those uncomfortable with that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework The major drawbacks are the relative verbosity for adding new tests and fixtures. [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [[http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [[http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html 10]]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.

A well explained example can be seen at http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list
of testing frameworks are available for C# which are NUnit, csUnit, Pex, dotunit,
VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].
{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Nunit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''PEX'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take adavntage of the .NET languages. It is a free open source unit testing tool for all the test-driven development .NET languages including C#.||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases. It has been inspired from JUnit and can be used as an add-in along with the NUnit

||It is a tool to generate efficient unit tests with a high code coverage and are converted to C# automatically. It determines the relevant test inputs for the code hunting for boundary conditions, exceptions and assertion failures. Pex enables Parameterized Unit Testing, an extension of Unit Testing that reduces test maintenance costs.
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/The%20Hello%20World%20of%20Pex.html
|-
| Used as ||Testing framework, GUI and console tool||Testing Framework ,Console tool and VS.NET Add In||It supports NUnit, MbUnit and xUnit.net.Extensions for these test frameworks can be downloaded from the Pex Extensions Project.
|-
|
|}

=APPENDIX=

'''1''' '''JUnit''' - JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and comprises a family of unit testing frameworks collectively known as xUnit that originated with SUnit. (For more information refer to http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''2''' '''XUnit''' - Various code-driven testing frameworks have come to be known collectively as xUnit. These frameworks allow testing of different elements (units) of software, such as functions and classes. (For more information refer to http://en.wikipedia.org/wiki/XUnit)

'''3''' '''unit testing''' - unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use, where a unit is the smallest testable part of an application. For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''4''' '''integration testing''' - is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing. For more information refer http://en.wikipedia.org/wiki/Integration_testing

'''5''' '''BeforeClass''' - Refer to http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

'''6''' '''parameterized testing''' - . A parameterized unit test is simply a method that takes parameters, calls the code under test, and states assertions.

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6] http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:17:01Z

Vdiyer: /* C# */

XUnit in general, is only one kind of testing framework for object oriented languages. This page talks about the major testing frameworks available for the major object oriented languages such as Java, C++, C#,Python, Ruby and C#. Comparisons have been made wherever possible between the major frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto standard for unit testing. However, other frameworks such as TestNG, JTIGER have been built to address various faults and deficiencies with JUnit. Our primary objective is to compare the various testing frameworks that exist for object oriented languages based on the primary purpose of the framework, features, the platforms on which they operate, etc and thus help in picking up the best testing framework that fits in a particular suitable environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit and XUnit, please refer to the http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']] and [[http://en.wikipedia.org/wiki/XUnit '''APPENDIX 2''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of testing such as unit testing, integration testing, functional testing, end-to -end testing. (For definition and more information on the different kinds of testing, refer to [[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']] and [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']]

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in them.
Add the information about our test (such as the class name, the groups we wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology used in Test automation where test scripts are executed and verified based on the data values stored in one or more central data sources or databases. For a detailed description on data driven testing click here: http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods that belong to these groups and specify groups that contain other groups. It is very flexible as it can help in choosing one set of regular expression and excluding the other sets. This splits the various test groups and there is no need to recompile again if we want to run two different tests back to back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA, MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing. The tests written for this framework will exercise the interactions with the container. Cactus also provides other frameworks such as code logic unit testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that it is much easier to have to write tests for a single framework than for several. It is believed that Cactus provides a middle ground that provides a high confidence that your code will run when deployed .[[http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

== '''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit testing,Functional testing, end-to-end testing, integration testing ||Primarily unit testing. Also have frameworks for code logic unit testing , functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites, ||Flexible for running large test suites of code and thus one test\'s failure shouldn\'t mean having to rerun a suite of thousands. || No, it is suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE, IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an effective unit-testing framework, meaning that it was built to facilitate testing single objects. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to define a test as a method whose name starts with test, and we can now run fixtures just once as opposed to for each test. However TestNG established itself as an annotations-based framework long before Junit 4. TestNG pioneered testing with annotations in Java programming, which made it a formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more information) method as static, which consequently requires us to also declare the fixture, finder, as static. We also have to declare the init() method as public. Looking at the TestNG code, you can find that such conventions aren't required. Its init() method is neither static nor public.
Flexibility has been one of the strong points of TestNG right from the start. JUnit works well for a unit of code, whereas TestNG is better suited for high-level testing. Its flexibility is especially useful with large test suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java 2 Micro Edition (J2ME) library containing a unit testing framework for J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.||A lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the power of an external scripting language. It provides some nifty advanced features and great assert functionality. It does require the use of a scripting language as part of the build process, so those uncomfortable with that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework The major drawbacks are the relative verbosity for adding new tests and fixtures. [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [[http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [[http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html 10]]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.

A well explained example can be seen at http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list
of testing frameworks are available for C# which are NUnit, csUnit, Pex, dotunit,
VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].
{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Nunit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''PEX'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take adavntage of the .NET languages. It is a free open source unit testing tool for all the test-driven development .NET languages including C#.||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases. It has been inspired from JUnit and can be used as an add-in along with the NUnit

||It is a tool to generate efficient unit tests with a high code coverage and are converted to C# automatically. It determines the relevant test inputs for the code hunting for boundary conditions, exceptions and assertion failures. Pex enables Parameterized Unit Testing, an extension of Unit Testing that reduces test maintenance costs.
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/The%20Hello%20World%20of%20Pex.html
|-
| Used as ||Testing framework, GUI and console tool||Testing Framework ,Console tool and VS.NET Add In||It supports NUnit, MbUnit and xUnit.net.Extensions for these test frameworks can be downloaded from the Pex Extensions Project.
|-
|
|}

=APPENDIX=

'''1''' '''JUnit''' - JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and comprises a family of unit testing frameworks collectively known as xUnit that originated with SUnit. (For more information refer to http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''2''' '''XUnit''' - Various code-driven testing frameworks have come to be known collectively as xUnit. These frameworks allow testing of different elements (units) of software, such as functions and classes. (For more information refer to http://en.wikipedia.org/wiki/XUnit)

'''3''' '''unit testing''' - unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use, where a unit is the smallest testable part of an application. For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''4''' '''integration testing''' - is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing. For more information refer http://en.wikipedia.org/wiki/Integration_testing

'''5''' '''BeforeClass''' - Refer to http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6] http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:15:27Z

Vdiyer:

XUnit in general, is only one kind of testing framework for object oriented languages. This page talks about the major testing frameworks available for the major object oriented languages such as Java, C++, C#,Python, Ruby and C#. Comparisons have been made wherever possible between the major frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto standard for unit testing. However, other frameworks such as TestNG, JTIGER have been built to address various faults and deficiencies with JUnit. Our primary objective is to compare the various testing frameworks that exist for object oriented languages based on the primary purpose of the framework, features, the platforms on which they operate, etc and thus help in picking up the best testing framework that fits in a particular suitable environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit and XUnit, please refer to the http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']] and [[http://en.wikipedia.org/wiki/XUnit '''APPENDIX 2''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of testing such as unit testing, integration testing, functional testing, end-to -end testing. (For definition and more information on the different kinds of testing, refer to [[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']] and [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']]

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in them.
Add the information about our test (such as the class name, the groups we wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology used in Test automation where test scripts are executed and verified based on the data values stored in one or more central data sources or databases. For a detailed description on data driven testing click here: http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods that belong to these groups and specify groups that contain other groups. It is very flexible as it can help in choosing one set of regular expression and excluding the other sets. This splits the various test groups and there is no need to recompile again if we want to run two different tests back to back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA, MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing. The tests written for this framework will exercise the interactions with the container. Cactus also provides other frameworks such as code logic unit testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that it is much easier to have to write tests for a single framework than for several. It is believed that Cactus provides a middle ground that provides a high confidence that your code will run when deployed .[[http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

== '''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit testing,Functional testing, end-to-end testing, integration testing ||Primarily unit testing. Also have frameworks for code logic unit testing , functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites, ||Flexible for running large test suites of code and thus one test\'s failure shouldn\'t mean having to rerun a suite of thousands. || No, it is suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE, IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an effective unit-testing framework, meaning that it was built to facilitate testing single objects. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to define a test as a method whose name starts with test, and we can now run fixtures just once as opposed to for each test. However TestNG established itself as an annotations-based framework long before Junit 4. TestNG pioneered testing with annotations in Java programming, which made it a formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more information) method as static, which consequently requires us to also declare the fixture, finder, as static. We also have to declare the init() method as public. Looking at the TestNG code, you can find that such conventions aren't required. Its init() method is neither static nor public.
Flexibility has been one of the strong points of TestNG right from the start. JUnit works well for a unit of code, whereas TestNG is better suited for high-level testing. Its flexibility is especially useful with large test suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java 2 Micro Edition (J2ME) library containing a unit testing framework for J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.||A lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the power of an external scripting language. It provides some nifty advanced features and great assert functionality. It does require the use of a scripting language as part of the build process, so those uncomfortable with that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework The major drawbacks are the relative verbosity for adding new tests and fixtures. [[http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [[http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [[http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html 10]]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.

A well explained example can be seen at http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list of testing frameworks are available for C# which are csUnit, NUnit, dotunit, VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''NUnit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''Systin'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take the advantage of the .NET languages.||It is a free open source unit testing tool for all the test-driven development .NET languages including C#. ||Systin creates a domain specific testing language which allows an automatic testing of applications at the system level.
|-
| ||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases.||It has been inspired from JUnit and can be used as an add-in along with the NUnit||The tests can be written in a simple document which can be converted to a .net language driver class
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||
|-
| ||||||
|-
| Used as||Testing framework, GUI and console tool||Testing Framework , Console tool and VS.NET Add In||
|-
|
|}

=APPENDIX=

'''1''' '''JUnit''' - JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and comprises a family of unit testing frameworks collectively known as xUnit that originated with SUnit. (For more information refer to http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''2''' '''XUnit''' - Various code-driven testing frameworks have come to be known collectively as xUnit. These frameworks allow testing of different elements (units) of software, such as functions and classes. (For more information refer to http://en.wikipedia.org/wiki/XUnit)

'''3''' '''unit testing''' - unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use, where a unit is the smallest testable part of an application. For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''4''' '''integration testing''' - is the activity of software testing in which individual software modules are combined and tested as a group. It occurs after unit testing. For more information refer http://en.wikipedia.org/wiki/Integration_testing

'''5''' '''BeforeClass''' - Refer to http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6] http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:02:05Z

Vdiyer: /* Cactus */

XUnit in general, is only one kind of testing framework for object oriented
languages. This page talks about the major testing frameworks available for
the major object oriented languages such as Java, C++, C#,Python, Ruby and
C#. Comparisons have been made wherever possible between the major
frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto
standard for unit testing. However, other frameworks such as TestNG, JTIGER
have been built to address various faults and deficiencies with JUnit. Our
primary objective is to compare the various testing frameworks that exist
for object oriented languages based on the primary purpose of the framework,
features, the platforms on which they operate, etc and thus help in picking
up the best testing framework that fits in a particular suitable
environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit,
please refer to http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of
testing such as unit testing, integration testing, functional testing,
end-to -end testing. (For definition and more information on the different
kinds of testing, refer to[[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']], [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']] )

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in
them.
Add the information about our test (such as the class name, the groups we
wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology
used in Test automation where test scripts are executed and verified based
on the data values stored in one or more central data sources or databases.
For a detailed description on data driven testing click here:
http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods
that belong to these groups and specify groups that contain other groups. It
is very flexible as it can help in choosing one set of regular expression
and excluding the other sets. This splits the various test groups and there
is no need to recompile again if we want to run two different tests back to
back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA,
MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities
such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as
Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are
executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the
following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that
provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use
a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing.
The tests written for this framework will exercise the interactions with
the container. Cactus also provides other frameworks such as code logic unit
testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that
it is much easier to have to write tests for a single framework than for
several. It is believed that Cactus provides a middle ground that provides a
high confidence that your code will run when deployed .[[http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

=='''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]]==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit
testing,Functional testing, end-to-end testing, integration testing
||Primarily unit testing. Also have frameworks for code logic unit testing ,
functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from
Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites,
||Flexible for running large test suites of code and thus one test\'s
failure shouldn\'t mean having to rerun a suite of thousands. || No, it is
suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level
testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE,
IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an
effective unit-testing framework, meaning that it was built to facilitate
testing single objects. TestNG, on the other hand, was built to address
testing at higher levels, and consequently, has some features not available
in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to
define a test as a method whose name starts with test, and we can now run
fixtures just once as opposed to for each test. However TestNG established
itself as an annotations-based framework long before Junit 4. TestNG
pioneered testing with annotations in Java programming, which made it a
formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are
more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more
information) method as static, which consequently requires us to also
declare the fixture, finder, as static. We also have to declare the init()
method as public. Looking at the TestNG code, you can find that such
conventions aren't required. Its init() method is neither static nor
public.
Flexibility has been one of the strong points of TestNG right from the
start. JUnit works well for a unit of code, whereas TestNG is better suited
for high-level testing. Its flexibility is especially useful with large test
suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[
http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java
2 Micro Edition (J2ME) library containing a unit testing framework for
J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets,
hierarchically structured XML, and topologically sorted SQL-DML.||A
lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit.
However for C++, there is no one clear winner. CppUnit is the most widely
used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major
downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great
support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly
output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus
needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit
based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the
power of an external scripting language. It provides some nifty advanced
features and great assert functionality. It does require the use of a
scripting language as part of the build process, so those uncomfortable with
that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not
required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework
The major drawbacks are the relative verbosity for adding new tests and
fixtures. [[
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write
a narrative in a document which can directly be executed as a test. It is
included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the
simplicity of a narrative test like doctest is accompanied by it’s own flaws
.Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more
generic. Specific tests are narrower and better in communicating intent and
ensuring coverage.

• The test code is executed in a special way thus making it difficult to
reason about how it will be executed. It is also harder to program around
the tests.

• It is actually difficult to get an outline of the tests at glance. There’s
no tool that can give an overview of the unit tests in a doc test file [[
http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at
http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional
in nature allowing it to be written for individual functions or the class as
a whole.

The fact that Unittest is based on jUnit makes people with the xUnit
familiarity pick it up really quick hence it is more Java based than python
.It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under
test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the
strong basis on jUnit makes it difficult for the pure Python coders [[
http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at
http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of
which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to
use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests
and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks
which have evolved over the years which include RSpec, Trantula, Flog,
RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is
Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just
writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a
non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and
stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which
makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342 10]]'''||Cucumber,
the latest addition to the Rspec family allows one to
execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at
http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is
a Rail’s plugin that produces a detailed report describing the URL’s that it
has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing,
particularly if you are practicing test-driven development (TDD). Tarantula
runs against your actual Web site thereby helping you to identify the
problems associated with your production server, user-generated data, and
HTML compliance.

A well explained example can be seen at
http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog
is a tool which gives you a profile of your code’s complexity.
It can given the complexity pertaining to each method in your code. One can
also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code
areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here
http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list
of testing frameworks are available for C# which are NUnit, csUnit, Pex, dotunit,
VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].
{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Nunit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''PEX'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take adavntage of the .NET languages. It is a free open source unit testing tool for all the test-driven development .NET languages including C#.||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases. It has been inspired from JUnit and can be used as an add-in along with the NUnit

||It is a tool to generate efficient unit tests with a high code coverage and are converted to C# automatically. It determines the relevant test inputs for the code hunting for boundary conditions, exceptions and assertion failures. Pex enables Parameterized Unit Testing, an extension of Unit Testing that reduces test maintenance costs.
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/The%20Hello%20World%20of%20Pex.html
|-
| Used as ||Testing framework, GUI and console tool||Testing Framework ,Console tool and VS.NET Add In||It supports NUnit, MbUnit and xUnit.net.Extensions for these test frameworks can be downloaded from the Pex Extensions Project.
|-
|
|}

=APPENDIX=

'''JUnit''' - JUnit is a unit testing framework for the Java programming
language. JUnit has been important in the development of test-driven
development, and comprises a family of unit testing frameworks collectively
known as xUnit that originated with SUnit. (For more information refer to
http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''XUnit''' - Various code-driven testing frameworks have come to be known
collectively as xUnit. These frameworks allow testing of different elements
(units) of software, such as functions and classes. (For more information
refer to http://en.wikipedia.org/wiki/XUnit)

'''unit testing''' - unit testing is a software verification and validation
method in which a programmer tests if individual units of source code are
fit for use, where a unit is the smallest testable part of an application.
For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''integration testing''' - is the activity of software testing in which
individual software modules are combined and tested as a group. It occurs
after unit testing. For more information refer
http://en.wikipedia.org/wiki/Integration_testing

'''BeforeClass''' - Refer to
http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

'''parameterized testing''' - . A parameterized unit test is simply a method that takes parameters, calls the code under test, and states assertions.

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6]
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

[14] http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/reference%20manual.html

CSC/ECE 517 Fall 2009/wiki1b12 AV

2009-09-29T03:01:25Z

Vdiyer: /* An example comparing JUNIT 4 and TestNG */

XUnit in general, is only one kind of testing framework for object oriented
languages. This page talks about the major testing frameworks available for
the major object oriented languages such as Java, C++, C#,Python, Ruby and
C#. Comparisons have been made wherever possible between the major
frameworks available in each language.

=Java Testing Frameworks =

Plenty of testing framework exist for Java. JUnit has been the de facto
standard for unit testing. However, other frameworks such as TestNG, JTIGER
have been built to address various faults and deficiencies with JUnit. Our
primary objective is to compare the various testing frameworks that exist
for object oriented languages based on the primary purpose of the framework,
features, the platforms on which they operate, etc and thus help in picking
up the best testing framework that fits in a particular suitable
environment.
This article DOES NOT introduce JUnit or XUnit. For information on JUnit,
please refer to http://www.junit.org or [[http://en.wikipedia.org/wiki/Junit '''APPENDIX 1''']]

== TestNG Framework ==

TestNG is a testing framework which can help to meet a broad range of
testing such as unit testing, integration testing, functional testing,
end-to -end testing. (For definition and more information on the different
kinds of testing, refer to[[http://en.wikipedia.org/wiki/Unit_testing ''' APPENDIX 3''']], [[http://en.wikipedia.org/wiki/Integration_testing ''' APPENDIX 4''']] )

To write a TestNG test, we need to:
Write the business logic of the test, and insert the TestNG annotations in
them.
Add the information about our test (such as the class name, the groups we
wish to run, etc) in a testing.xml file or in build.xml.
Run the test.
TestNG supports data driven testing.(Data-driven testing is a methodology
used in Test automation where test scripts are executed and verified based
on the data values stored in one or more central data sources or databases.
For a detailed description on data driven testing click here:
http://en.wikipedia.org/wiki/Data-driven_testing )

TestNG is invoked in several different ways:
With a testing.xml file
ANT
Command line

It is possible to group the test methods of TestNG. We can declare methods
that belong to these groups and specify groups that contain other groups. It
is very flexible as it can help in choosing one set of regular expression
and excluding the other sets. This splits the various test groups and there
is no need to recompile again if we want to run two different tests back to
back.

Requirements:
JDK 1.4, 1.5
Invoked in many environments such as command line, ant, ECLIPSE, IDEA,
MAVEN, etc

The annotations available in TestNG can be found at:
http://testng.org/doc/documentation-main.html#annotations

TestNG is inspired from JUnit and Nunit, with additional functionalities
such as Flexible test configuration, support for data driven testing, etc.[[http://testng.org/doc/documentation-main.html 1]]

== Cactus ==

Cactus is a test framework for testing server-side java code such as
Servlets, EJB, etc. It extends J Unit.
Cactus implements an in-container strategy which means that tests are
executed inside the container.
The Cactus testing unit can be viewed as a system that consists of the
following components:

--Cactus Framework: This provides the API to write Cactus tests.

--Cactus Integration Modules: They are front ends and frameworks that
provide easy ways of using the Cactus Framework. Eg: Eclipse plugin

--Cactus Samples: They demonstrate how to write Cactus tests and how to use
a few Integration Modules. [[http://jakarta.apache.org/cactus/index.html 2]]

A useful testing framework provided by Cactus is integration unit testing.
The tests written for this framework will exercise the interactions with
the container. Cactus also provides other frameworks such as code logic unit
testing, functional unit testing.

Cactus was developed to fit only integration unit testing with the idea that
it is much easier to have to write tests for a single framework than for
several. It is believed that Cactus provides a middle ground that provides a
high confidence that your code will run when deployed .[[
http://jakarta.apache.org/cactus/index.html 2]]

To know how it works, click here :
http://jakarta.apache.org/cactus/how_it_works.html

== '''COMPARISON BETWEEN JUnit,TestNG and Cactus frameworks''' [[
http://junit.sourceforge.net/doc/cookbook/cookbook.htm 3]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JUnit4'''
| align="center" style="background:#f0f0f0;"|'''TestNG'''
| align="center" style="background:#f0f0f0;"|'''Cactus'''
|-
| Supporting Type of Testing||Suitable more for Unit testing||Supports Unit
testing,Functional testing, end-to-end testing, integration testing
||Primarily unit testing. Also have frameworks for code logic unit testing ,
functional logic unit testing
|-
| Conventions||Rigid ||Flexible||Not as flexible as TestNG
|-
| Derived from JUnit||Yes, from the previous versions||Inspired from
Junit,with added functionalities ||Extends JUnit
|-
| Flexibility for large suites||Not flexible for large test suites,
||Flexible for running large test suites of code and thus one test\'s
failure shouldn\'t mean having to rerun a suite of thousands. || No, it is
suitable for unit testing.
|-
| Suitable for ||Best for a single object||Best for a higher level
testing||Best for server-side java code such as Servlets, EJB, etc.
|-
| Works with||Command line, ANT,ECLIPSE||Command line,ANT, ECLIPSE,
IDEA,MAVEN||ANT
|-
| ||||||
|-
|
|}

== An example comparing JUNIT 4 and TestNG ==

'''JUnit 4 v/s TestNG'''

(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

The frameworks differ is in their core design. JUnit has always been an
effective unit-testing framework, meaning that it was built to facilitate
testing single objects. TestNG, on the other hand, was built to address
testing at higher levels, and consequently, has some features not available
in JUnit

JUnit 4 makes clever use of annotations. JUnit no longer requires you to
define a test as a method whose name starts with test, and we can now run
fixtures just once as opposed to for each test. However TestNG established
itself as an annotations-based framework long before Junit 4. TestNG
pioneered testing with annotations in Java programming, which made it a
formidable alternative to JUnit. [[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

Sample J Unit 4 code

package test.com.acme.dona.dep;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import org.junit.BeforeClass;
import org.junit.Test;
public class DependencyFinderTest {
private static DependencyFinder finder;
@BeforeClass
public static void init() throws Exception {
finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull("deps was null", deps);
assertEquals("should be 5 large", 5, deps.length);
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Sample TestNG code

package test.com.acme.dona.dep;
import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Configuration;
import org.testng.annotations.Test;
public class DependencyFinderTest {
private DependencyFinder finder;
@BeforeClass
private void init(){
this.finder = new DependencyFinder();
}
@Test
public void verifyDependencies()
throws Exception {
String targetClss =
"test.com.acme.dona.dep.DependencyFind";
Filter[] filtr = new Filter[] {
new RegexPackageFilter("java|junit|org")};
Dependency[] deps =
finder.findDependencies(targetClss, filtr);
assertNotNull(deps, "deps was null" );
assertEquals(5, deps.length, "should be 5 large");
}
}
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)

Both the codes may look a lot similar. However TestNG coding conventions are
more flexible than JUnit 4.

JUnit forces us to declare the @BeforeClass (See [[http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html '''APPENDIX 5''']] for more
information) method as static, which consequently requires us to also
declare the fixture, finder, as static. We also have to declare the init()
method as public. Looking at the TestNG code, you can find that such
conventions aren't required. Its init() method is neither static nor
public.
Flexibility has been one of the strong points of TestNG right from the
start. JUnit works well for a unit of code, whereas TestNG is better suited
for high-level testing. Its flexibility is especially useful with large test
suites.[[http://www.ibm.com/developerworks/java/library/j-cq08296 4]]

== Some other JAVA testing units [[
http://www.opensourcetesting.org/unit_java.php 5]] ==

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''JEasyTest'''
| align="center" style="background:#f0f0f0;"|'''J2ME Unit Testing Toolkit'''
| align="center" style="background:#f0f0f0;"|'''Jailer'''
| align="center" style="background:#f0f0f0;"|'''Mockrunner'''
|-
| Features||Generates coverage report Allows virtual mock object||Is a Java
2 Micro Edition (J2ME) library containing a unit testing framework for
J2ME||Does test data exporting. JDBC agnostic Generates DbUnit datasets,
hierarchically structured XML, and topologically sorted SQL-DML.||A
lightweight framework for unit testing applications in the J2EE environment.
|-
| Integrates with:||ECLIPSE 3.3||ANT ||Platform Independent||OS independent
|-
|
|}

= Testing frameworks for C++ =

When it comes to unit testing in Java, a unanimous choice would be JUnit.
However for C++, there is no one clear winner. CppUnit is the most widely
used tool for C++ which is a part of the XUnit family.

Following is a few basic factors to judge a good testing unit in C++ [[
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle6]]

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Features'''
| align="center" style="background:#f0f0f0;"|'''CppUnit'''
| align="center" style="background:#f0f0f0;"|'''BOOST.test'''
| align="center" style="background:#f0f0f0;"|'''CxxUnit'''
|-
| Minimal amount of work needed to add new tests ||No, and thus a major
downfall.||Yes||Yes, very good.
|-
| Easy to modify and port ||Medium||Medium||Simplest
|-
| Supports setup/teardown steps ||Yes||||Best
|-
| Handles exceptions and crashes well.||Yes||Yes, above others||Great
support.
|-
| Good assert functionality.||Pretty decent.||Yes||Best
|-
| Supports different outputs. ||Yes. Comes with IDE friendly
output.||Probably, Not trivial to change.||Yes
|-
| Supports suites||Yes.||Yes, but with a big catch. ||Yes
|-
|
|}

CppUnit passes most of the above tests , except for the first point and thus
needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit
based.

Out of the above three , cxxUnit turns out to be a favourite.

It comes close to the requirements of an ideal framework by leveraging the
power of an external scripting language. It provides some nifty advanced
features and great assert functionality. It does require the use of a
scripting language as part of the build process, so those uncomfortable with
that requirement, might want to look at one of the other two frameworks.

For work restricted to the PC, where modifying the framework is not
required Boost.Test could be a very good choice.
CppUnit , which has come a long way in years is a solid, complete framework
The major drawbacks are the relative verbosity for adding new tests and
fixtures. [[
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle 6]]

= Python =

'''Doctest''': It is a simple, ingenuine technology that allows you to write
a narrative in a document which can directly be executed as a test. It is
included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the
simplicity of a narrative test like doctest is accompanied by it’s own flaws
.Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more
generic. Specific tests are narrower and better in communicating intent and
ensuring coverage.

• The test code is executed in a special way thus making it difficult to
reason about how it will be executed. It is also harder to program around
the tests.

• It is actually difficult to get an outline of the tests at glance. There’s
no tool that can give an overview of the unit tests in a doc test file [[
http://en.wikipedia.org/wiki/Doctest 7]].

An detailed information about doctest with thorough examples can be read at
http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional
in nature allowing it to be written for individual functions or the class as
a whole.

The fact that Unittest is based on jUnit makes people with the xUnit
familiarity pick it up really quick hence it is more Java based than python
.It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under
test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the
strong basis on jUnit makes it difficult for the pure Python coders [[
http://en.wikipedia.org/wiki/Unit_testing 8]]

A detailed information about doctest with thorough examples can be read at
http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of
which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to
use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests
and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

=Ruby =

The basic testing framework for RUBY is xUnit . There are some frameworks
which have evolved over the years which include RSpec, Trantula, Flog,
RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| style="background:#f0f0f0;"|'''Description'''
|-
| '''Rspec[[http://www.elctech.com/tutorials/rspec-tutorial 9]]'''||It is
Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just
writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a
non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and
stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which
makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[[http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342 10]]'''||Cucumber,
the latest addition to the Rspec family allows one to
execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at
http://cukes.info/
|-
| ||
|-
| '''Tarantula[[http://www.ruby-forum.com/topic/144083 11]]'''||Tarantula is
a Rail’s plugin that produces a detailed report describing the URL’s that it
has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing,
particularly if you are practicing test-driven development (TDD). Tarantula
runs against your actual Web site thereby helping you to identify the
problems associated with your production server, user-generated data, and
HTML compliance.

A well explained example can be seen at
http://www.railslodge.com/plugins/959-tarantula

|-
| '''Flog[[http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog 12]]'''||Flog
is a tool which gives you a profile of your code’s complexity.
It can given the complexity pertaining to each method in your code. One can
also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code
areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here
http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

= C# =

The list of frameworks that apply for .NET are applied for C#. A long list
of testing frameworks are available for C# which are NUnit, csUnit, Pex, dotunit,
VSNUnit, Nester[[http://csharp-source.net/open-source/testing-tools 13]].
{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Nunit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''PEX'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take adavntage of the .NET languages. It is a free open source unit testing tool for all the test-driven development .NET languages including C#.||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases. It has been inspired from JUnit and can be used as an add-in along with the NUnit

||It is a tool to generate efficient unit tests with a high code coverage and are converted to C# automatically. It determines the relevant test inputs for the code hunting for boundary conditions, exceptions and assertion failures. Pex enables Parameterized Unit Testing, an extension of Unit Testing that reduces test maintenance costs.
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/The%20Hello%20World%20of%20Pex.html
|-
| Used as ||Testing framework, GUI and console tool||Testing Framework ,Console tool and VS.NET Add In||It supports NUnit, MbUnit and xUnit.net.Extensions for these test frameworks can be downloaded from the Pex Extensions Project.
|-
|
|}

=APPENDIX=

'''JUnit''' - JUnit is a unit testing framework for the Java programming
language. JUnit has been important in the development of test-driven
development, and comprises a family of unit testing frameworks collectively
known as xUnit that originated with SUnit. (For more information refer to
http://www.junit.org,http://en.wikipedia.org/wiki/Junit)

'''XUnit''' - Various code-driven testing frameworks have come to be known
collectively as xUnit. These frameworks allow testing of different elements
(units) of software, such as functions and classes. (For more information
refer to http://en.wikipedia.org/wiki/XUnit)

'''unit testing''' - unit testing is a software verification and validation
method in which a programmer tests if individual units of source code are
fit for use, where a unit is the smallest testable part of an application.
For more information refer http://en.wikipedia.org/wiki/Unit_testing

'''integration testing''' - is the activity of software testing in which
individual software modules are combined and tested as a group. It occurs
after unit testing. For more information refer
http://en.wikipedia.org/wiki/Integration_testing

'''BeforeClass''' - Refer to
http://junit.sourceforge.net/javadoc_40/org/junit/BeforeClass.html

'''parameterized testing''' - . A parameterized unit test is simply a method that takes parameters, calls the code under test, and states assertions.

= References =

[1] http://testng.org/doc/documentation-main.html

[2] http://jakarta.apache.org/cactus/index.html

[3] http://junit.sourceforge.net/doc/cookbook/cookbook.htm

[4] http://www.ibm.com/developerworks/java/library/j-cq08296

[5] http://www.opensourcetesting.org/unit_java.php

[6]
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

[7] http://en.wikipedia.org/wiki/Doctest

[8] http://en.wikipedia.org/wiki/Unit_testing

[9] http://www.elctech.com/tutorials/rspec-tutorial

[10] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[11] http://www.ruby-forum.com/topic/144083

[12] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[13] http://csharp-source.net/open-source/testing-tools

[14] http://research.microsoft.com/en-us/um/redmond/projects/pex/wiki/reference%20manual.html