Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 22 SN

2009-11-19T19:56:29Z

SteelerNation:

Clone Detection and Clone Manipulation
The DRY principle says that a particular code fragment should not be repeated more than once in a program. But it happens. And when it does, it is good to be able to find the multiple code "clones." A variety of tools have been designed for this, and some of them even allow joint editing of the clones. Survey the techniques for dealing with the problem, and compare the effectiveness with refactoring (e.g., Extract Method).

'''Template'''
----

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T20:38:47Z

SteelerNation:

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
[http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented programming] has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both re-usability and maintainability of the code.
[[Image:Aop.jpg]]

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

'''Example'''

The best way to understand AspectJ is through example. Lets say we have a simple Hello World program.

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");
}
}

Let's assume that we want to use aspects to do the following modifications:

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.

public aspect MyAspect
{
public pointcut sayMethodCall (): call (public void TestClass.say*() );
public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String)) && args(str);
before(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() + "start..." );
}
after(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() + " end...");
}
before(String str): sayMethodCallArg(str)
{
if (str .length() < 3)
{
System.out.println ("Error: I can't say words less than 3 characters");
return;
}
}
}

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

AspectR lets a module wrap any number of methods in other classes with the advice methods of the module.

'''Example'''

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 parameter is the name of the method currently being wrapped.

The second parameter is the object receiving the method call.

The third parameter 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

==Conclusion==
Aspect-Oriented Programming an emerging software development technology that seeks new modularization of software systems. The technology allows for a more robust and sound software system. Not only has the benefits and clarity of Object-Oriented programming, but AOP provides an easier way to correlate different aspects of a software system into one single solution. Often too many programs and software systems are incomplete or not ideal because one aspect is treated greater than the other. AOP attempts to balance the aspects in such a way that the software system has a much more functional and reusable architecture.

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

7. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf AOP in Ruby]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T20:30:41Z

SteelerNation: /* AspectR */

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.
[[Image:Aop.jpg]]

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

'''Example'''

The best way to understand AspectJ is through example. Lets say we have a simple Hello World program.

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");
}
}

Let's assume that we want to use aspects to do the following modifications:

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.

public aspect MyAspect
{
public pointcut sayMethodCall (): call (public void TestClass.say*() );
public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String)) && args(str);
before(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
}
after(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
}
before(String str): sayMethodCallArg(str)
{
if (str .length() < 3)
{
System.out.println ("Error: I can't say words less than 3 characters");
return;
}
}
}

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

AspectR lets a module wrap any number of methods in other classes with the advice methods of the module.

'''Example'''

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 parameter is the name of the method currently being wrapped.

The second parameter is the object receiving the method call.

The third parameter 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

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

7. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf AOP in Ruby]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T20:24:03Z

SteelerNation: /* Links */

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.
[[Image:Aop.jpg]]

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

'''Example'''

The best way to understand AspectJ is through example. Lets say we have a simple Hello World program.

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");
}
}

Let's assume that we want to use aspects to do the following modifications:

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.

public aspect MyAspect
{
public pointcut sayMethodCall (): call (public void TestClass.say*() );
public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String)) && args(str);
before(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
}
after(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
}
before(String str): sayMethodCallArg(str)
{
if (str .length() < 3)
{
System.out.println ("Error: I can't say words less than 3 characters");
return;
}
}
}

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

7. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf AOP in Ruby]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T20:20:48Z

SteelerNation: /* AspectJ */

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.
[[Image:Aop.jpg]]

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

'''Example'''

The best way to understand AspectJ is through example. Lets say we have a simple Hello World program.

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");
}
}

Let's assume that we want to use aspects to do the following modifications:

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.

public aspect MyAspect
{
public pointcut sayMethodCall (): call (public void TestClass.say*() );
public pointcut sayMethodCallArg (String str): call
(public void TestClass.sayAnyThing (String)) && args(str);
before(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
"start..." );
}
after(): sayMethodCall()
{
System.out.println("\n TestClass." +
thisJoinPointStaticPart.getSignature().getName() +
" end...");
}
before(String str): sayMethodCallArg(str)
{
if (str .length() < 3)
{
System.out.println ("Error: I can't say words less than 3 characters");
return;
}
}
}

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T20:11:19Z

SteelerNation: /* Links */

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.
[[Image:Aop.jpg]]

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T20:10:23Z

SteelerNation: /* OOP and AOP at a Glance */

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.
[[Image:Aop.jpg]]

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming - Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

File:Aop.jpg

2009-10-14T20:09:44Z

SteelerNation:

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T19:56:02Z

SteelerNation:

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called [http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==OOP and AOP at a Glance==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming - Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T19:54:02Z

SteelerNation:

==Aspect-Oriented Programming==

Traditional [http://en.wikipedia.org/wiki/Software_development software development] has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary [http://www.merriam-webster.com/dictionary/decomposition decomposition]. This process leaves it to the programmers to code [http://en.wikipedia.org/wiki/Modular_programming modules] corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification, and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==So What exactly is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. [http://en.wikipedia.org/wiki/Engineering_design_process Design processes] break a system down into smaller and smaller units. [http://en.wikipedia.org/wiki/Programming_language Programming languages] provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages, and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

Aspect-oriented programming is a programming process that entails breaking down a program into distinct parts or what are called 'concerns.' This process is called http://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns]. Often times these concerns overlap and this is called [http://en.wikipedia.org/wiki/Cross-cutting_concern crosscutting concerns]. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and super-types of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parametrized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==Example of Aspect==

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Conclusion==
Object-oriented programming has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.

OOP encourages software re-use by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has met great success in modeling and implementing complex software systems, it has its problems. Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules.

AOP is a way to modularize code that is typically repeated and sandwiched all over in an object-oriented system. AOP is used for separating crosscutting concerns into single units called aspects. With AOP, we start by implementing our project using our OO language , and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code.

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming - Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-14T19:47:24Z

SteelerNation:

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-09T15:19:22Z

SteelerNation:

==Aspect-Oriented Programming==
'''THIS WILL BE TAKEN OUT'''
In writing a program, you must handle the many concerns of the system. A *concern* is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns. Discuss AOP in general, and touch briefly on AspectJ and AspectR, which facilitate it in Java and Ruby, respectively

'''Aspect Oriented Programming'''

Traditional software development has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. This process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==What is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parameterized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==Example of Aspect==

HERE IS WHERE AN EXAMPLE IS GOING (Not Done Yet)

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==Links==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming - Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-09T15:19:10Z

SteelerNation:

==Aspect-Oriented Programming==
'''THIS WILL BE TAKEN OUT'''
In writing a program, you must handle the many concerns of the system. A *concern* is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns. Discuss AOP in general, and touch briefly on AspectJ and AspectR, which facilitate it in Java and Ruby, respectively

'''Aspect Oriented Programming'''

Traditional software development has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. This process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==What is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parameterized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==Example of Aspect==

HERE IS WHERE AN EXAMPLE IS GOING (Not Done Yet)

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

===EXAMPLE CODE of ASPECTR – (Not Done Yet)===

==LINKS==

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

2. [http://www.ccs.neu.edu/home/lieber/AOP.html AOP and Adaptive Programming]

3. [http://wiki.java.net/bin/view/Javapedia/AspectOrientedProgramming - Java AOP]

4. [http://www.aspectprogramming.com/ Aspect Programming]

5. [http://oreilly.com/catalog/9780596006549 AspectJ]

6. [http://aspectr.sourceforge.net/ AspectR]

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-09T15:14:54Z

SteelerNation: /* Aspect-Oriented Programming */

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-09T15:14:19Z

SteelerNation:

==Aspect-Oriented Programming==
'''THIS WILL BE TAKEN OUT'''
In writing a program, you must handle the many concerns of the system. A *concern* is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns. Discuss AOP in general, and touch briefly on AspectJ and AspectR, which facilitate it in Java and Ruby, respectively

Aspect Oriented Programming

Traditional software development has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. This process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==What is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parameterized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==Example of Aspect==

HERE IS WHERE AN EXAMPLE IS GOING (Not Done Yet)

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

*Upward compatibility — all legal Java programs must be legal AspectJ programs.

*Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.

*Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.

*Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:

*Join points: method/constructor called, method/constructor executes (?), exception handler executes

*Most of the point-cut designator primitives

*Composition of point-cut designators

*'around' advices

*precedence/specificity among advices/aspects

*reflection by sending join-point object to advices with context of join point etc

*control-flow based crosscutting

==LINKS==

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-09T15:11:27Z

SteelerNation:

==Aspect-Oriented Programming==
'''THIS WILL BE TAKEN OUT'''
In writing a program, you must handle the many concerns of the system. A *concern* is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns. Discuss AOP in general, and touch briefly on AspectJ and AspectR, which facilitate it in Java and Ruby, respectively

Aspect Oriented Programming

Traditional software development has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. This process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.

Aspect-Oriented programming focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.

==What is AOP?==

===Introduction===

Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

===Terminology===

====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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.

====Advice====

This is the additional code that you want to apply to your existing model.

====Point-cut====

This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.

====Aspect====

The combination of the point-cut and the advice is termed an aspect.

===Overview===

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parameterized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.

This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.

==Example of Aspect==

HERE IS WHERE AN EXAMPLE IS GOING (Not Done Yet)

==AspectJ==

AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.

AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.

• Upward compatibility — all legal Java programs must be legal AspectJ programs.
• Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.
• Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.
• Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

===EXAMPLE CODE of ASPECTJ – (Not Done Yet)===

==AspectR==

AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.

There are some differences which AspectR does not have that AspectJ does:
* Join points: method/constructor called, method/constructor executes (?), exception handler executes
* Most of the point-cut designator primitives
* Composition of point-cut designators
* 'around' advices
* precedence/specificity among advices/aspects
* reflection by sending join-point object to advices with context of join point etc
* control-flow based crosscutting

CSC/ECE 517 Fall 2009/wiki2 9 SN

2009-10-09T15:05:41Z

SteelerNation:

Aspect-Oriented Programming

In writing a program, you must handle the many concerns of the system. A *concern* is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns. Discuss AOP in general, and touch briefly on AspectJ and AspectR, which facilitate it in Java and Ruby, respectively

Aspect Oriented Programming
Traditional software development has focused on developing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. This process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. When all these things are taken into account, this often results in serious issues being raised during the development and maintenance of a large software system.
Aspect-Oriented programming focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.
What is AOP?
Introduction
Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. From this perspective, many existing programming languages, including object-oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.
Terminology
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. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical.
Advice –
This is the additional code that you want to apply to your existing model.
Point-cut –
This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied.
Aspect –
The combination of the point-cut and the advice is termed an aspect.
Overview
AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using point-cuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.
Mechanisms for defining and composing abstractions are essential elements of programming languages. The design style supported by the abstraction mechanisms of most current languages is one of breaking a system down into parameterized components that can be called upon to perform a function.
But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components.

While they can be thought about and analyzed relatively separately from the basic functionality, programming them using current component-oriented languages tends to result in these aspects being spread throughout the code. The source code becomes a tangled mess of instructions for different purposes.
This phenomenon is at the heart of much needless complexity in existing software systems. A number of researchers have begun working on approaches to this problem that allow programmers to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form. These approaches have been called aspect-oriented programming.
Example:
HERE IS WHERE AN EXAMPLE IS GOING (Not Done Yet)
AspectJ
AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these 'crosscutting concerns'. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems.
AspectJ is a simple, practical, and compatible aspect-oriented extension to Java.
• Upward compatibility — all legal Java programs must be legal AspectJ programs.
• Platform compatibility — all legal AspectJ programs must run on standard Java virtual machines.
• Tool compatibility — it must be possible to extend existing tools to support AspectJ in a natural way; this includes IDEs, documentation tools, and design tools.
• Programmer compatibility — Programming with AspectJ must feel like a natural extension of programming with Java.

EXAMPLE CODE of ASPECTJ – (Not Done Yet)

AspectR
AspectR is the AOP Language for Ruby. It was modeled after and resembles a lot like AspectJ.
There are some differences which AspectR does not have that AspectJ does:
* Join points: method/constructor called, method/constructor executes (?), exception handler executes
* Most of the point-cut designator primitives
* Composition of point-cut designators
* 'around' advices
* precedence/specificity among advices/aspects
* reflection by sending join-point object to advices with context of join point etc
* control-flow based crosscutting

CSC/ECE 517 Fall 2009/wiki1a 2 sn

2009-09-11T15:17:15Z

SteelerNation:

== Comparison of Mock Frameworks ==
'''NOTE:''' THIS SECTION WILL BE REMOVED FOR FINAL VERSION

Assignment:
Mock objects and mock frameworks. When performing tests, it's convenient to have the objects be in a particular configuration, so that boundary cases can be tested. Setting up the objects can sometimes be complicated. The Wikipedia article for mock objects lists several, but does not compare them. Compare different systems for mock objects, and mock frameworks (which are used to set up mock objects).

== Definition ==
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]

Mock Frameworks are the environments that are available to create these mock objects and mock tests.
There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.

== Concepts ==

==='''Why Mock?'''===

*The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.

*Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.

*Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.

*Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.

*Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.

==='''Different Types'''===

====Proxy====
A proxy object is an object that is used to take the place of a real object. This is the original concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up through an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.

====Class Remapping====
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Instrument class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.

== Comparison of Different Systems ==

==='''EasyMock'''===
*EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
*Dynamic creation of Mock Objects
*Supports re-factoring-safe Mock Objects
*Ability to return values and exceptions.
*Method order checking
http://easymock.org/

==='''MOQ'''===
*Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
*Supports mocking interfaces as well as classes.
*Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
*Intercept and raise events on mocks
http://code.google.com/p/moq/.

==='''NMock'''===
*NMock is a dynamic mock object library for .NET.
*Dynamic creation of Mock Objects
*Allows expectations to be defined and fails the test if any expectations are violated
*Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterward using assertions
*Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

==='''Rhino Mocks'''===
*Only supports mocks of interfaces, delegates and classes, including those with parametrized constructors.
*Expectations on the called methods by using strongly typed mocks instead of strings.
*Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

==='''jMock'''===
*Forces test to be explicit about the argument values that will be passed to the expected methods
*Ability to write custom stubs, constraints, and Invocation Matchers
*Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

==='''Mocha'''===
*Similar to jMock only for Ruby
*Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

==='''Test::MockObject'''===
*Similar to jMock only for Perl
*Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

==='''JMockit'''===

*Simpler and more succinct APIs for writing tests with behavior verification or state verification
*Provides other tools for supporting the creation of large test suites
*Uses class remapping instead of the original proxy dependencies
https://jmockit.dev.java.net/

== Conclusion ==

A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.

The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.

== Links ==
1. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Framework Comparisons]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 sn

2009-09-08T18:35:58Z

SteelerNation:

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T18:32:04Z

SteelerNation: /* Comparison of Mock Frameworks */

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T18:28:33Z

SteelerNation: /* Links */

== Comparison of Mock Frameworks ==

== Definition ==
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]

Mock Frameworks are the environments that are available to create these mock objects and mock tests.
There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.

== Concepts ==

==='''Why Mock?'''===

*The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.

*Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.

*Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.

*Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.

*Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.

==='''Different Types'''===

====Proxy====
A proxy object is an object that is used to take the place of a real object. This is the original concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up through an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.

====Class Remapping====
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Instrument class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.

== Comparison of Different Systems ==

==='''EasyMock'''===
*EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
*Dynamic creation of Mock Objects
*Supports re-factoring-safe Mock Objects
*Ability to return values and exceptions.
*Method order checking
http://easymock.org/

==='''MOQ'''===
*Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
*Supports mocking interfaces as well as classes.
*Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
*Intercept and raise events on mocks
http://code.google.com/p/moq/.

==='''NMock'''===
*NMock is a dynamic mock object library for .NET.
*Dynamic creation of Mock Objects
*Allows expectations to be defined and fails the test if any expectations are violated
*Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterward using assertions
*Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

==='''Rhino Mocks'''===
*Only supports mocks of interfaces, delegates and classes, including those with parametrized constructors.
*Expectations on the called methods by using strongly typed mocks instead of strings.
*Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

==='''jMock'''===
*Forces test to be explicit about the argument values that will be passed to the expected methods
*Ability to write custom stubs, constraints, and Invocation Matchers
*Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

==='''Mocha'''===
*Similar to jMock only for Ruby
*Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

==='''Test::MockObject'''===
*Similar to jMock only for Perl
*Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

==='''JMockit'''===

*Simpler and more succinct APIs for writing tests with behavior verification or state verification
*Provides other tools for supporting the creation of large test suites
*Uses class remapping instead of the original proxy dependencies
https://jmockit.dev.java.net/

== Conclusion ==

A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.

The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.

== Links ==
1. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Framework Comparisons]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T18:28:08Z

SteelerNation: /* Links */

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T18:23:27Z

SteelerNation:

== Comparison of Mock Frameworks ==

== Definition ==
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]

Mock Frameworks are the environments that are available to create these mock objects and mock tests.
There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.

== Concepts ==

==='''Why Mock?'''===

*The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.

*Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.

*Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.

*Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.

*Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.

==='''Different Types'''===

====Proxy====
A proxy object is an object that is used to take the place of a real object. This is the original concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up through an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.

====Class Remapping====
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Instrument class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.

== Comparison of Different Systems ==

==='''EasyMock'''===
*EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
*Dynamic creation of Mock Objects
*Supports re-factoring-safe Mock Objects
*Ability to return values and exceptions.
*Method order checking
http://easymock.org/

==='''MOQ'''===
*Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
*Supports mocking interfaces as well as classes.
*Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
*Intercept and raise events on mocks
http://code.google.com/p/moq/.

==='''NMock'''===
*NMock is a dynamic mock object library for .NET.
*Dynamic creation of Mock Objects
*Allows expectations to be defined and fails the test if any expectations are violated
*Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterward using assertions
*Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

==='''Rhino Mocks'''===
*Only supports mocks of interfaces, delegates and classes, including those with parametrized constructors.
*Expectations on the called methods by using strongly typed mocks instead of strings.
*Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

==='''jMock'''===
*Forces test to be explicit about the argument values that will be passed to the expected methods
*Ability to write custom stubs, constraints, and Invocation Matchers
*Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

==='''Mocha'''===
*Similar to jMock only for Ruby
*Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

==='''Test::MockObject'''===
*Similar to jMock only for Perl
*Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

==='''JMockit'''===

*Simpler and more succinct APIs for writing tests with behavior verification or state verification
*Provides other tools for supporting the creation of large test suites
*Uses class remapping instead of the original proxy dependencies
https://jmockit.dev.java.net/

== Conclusion ==

A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.

The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.

== Links ==
http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T18:16:28Z

SteelerNation:

== Comparison of Mock Frameworks ==

== Definition ==
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]

Mock Frameworks are the environments that are available to create these mock objects and mock tests.
There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.

== Concepts ==

==='''Why Mock?'''===

The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.

Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.

Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.

Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-
Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.

Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.

==='''Different Types'''===

====Proxy====
A proxy object is an object that is used to take the place of a real object. This is the original concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up through an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.

====Class Remapping====
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Insturment class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.

== Comparison of Different Systems ==

==='''EasyMock'''===
EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
-Dynamic creation of Mock Objects
-Supports refactoring-safe Mock Objects
-Ability to return values and exceptions.
-Method order checking
http://easymock.org/

==='''MOQ'''===
Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
-Supports mocking interfaces as well as classes.
-Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
- Intercept and raise events on mocks
http://code.google.com/p/moq/.

==='''NMock'''===
NMock is a dynamic mock object library for .NET.
-Dynamic creation of Mock Objects
-Allows expectations to be defined and fails the test if any expectations are violated
-Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterwards using assertions
-Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

==='''Rhino Mocks'''===
-Only supports mocks of interfaces, delegates and classes, including those with parameterized constructors.
-Expectations on the called methods by using strongly typed mocks instead of strings.
-Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

==='''jMock'''===
- Forces test to be explicit about the argument values that will be passed to the expected methods
-Ability to write custom stubs, constraints, and Invocation Matchers
-Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

==='''Mocha'''===
-Similar to jMock only for Ruby
- Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

==='''Test::MockObject'''===
-Similar to jMock only for Perl
-Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

==='''JMockit'''===

-Simpler and more succinct APIs for writing tests with behavior verification or state verification
-Provides other tools for supporting the creation of large test suites
-Uses class remapping instead of the original proxy dependencies
https://jmockit.dev.java.net/

== Conclusion ==

A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.

The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.

== Links ==
http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T18:03:07Z

SteelerNation:

== Comparison of Mock Frameworks ==

== Definition ==
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]

Mock Frameworks are the environments that are available to create these mock objects and mock tests.
There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.

== Concepts ==

'''Why Mock?'''

The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.

Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.

Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.

Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-
Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.

Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.

'''Different Types:'''

Proxy:
A proxy object is an object that is used to take the place of a real object. This is the original concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up through an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.

Class Remapping:
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Insturment class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.

== Comparison of Different Systems ==

'''EasyMock-'''
EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
-Dynamic creation of Mock Objects
-Supports refactoring-safe Mock Objects
-Ability to return values and exceptions.
-Method order checking
http://easymock.org/

'''MOQ'''
Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
-Supports mocking interfaces as well as classes.
-Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
- Intercept and raise events on mocks
http://code.google.com/p/moq/.

'''NMock'''
NMock is a dynamic mock object library for .NET.
-Dynamic creation of Mock Objects
-Allows expectations to be defined and fails the test if any expectations are violated
-Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterwards using assertions
-Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

'''Rhino Mocks'''
-Only supports mocks of interfaces, delegates and classes, including those with parameterized constructors.
-Expectations on the called methods by using strongly typed mocks instead of strings.
-Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

'''jMock'''
- Forces test to be explicit about the argument values that will be passed to the expected methods
-Ability to write custom stubs, constraints, and Invocation Matchers
-Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

'''Mocha'''
-Similar to jMock only for Ruby
- Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

'''Test::MockObject'''
-Similar to jMock only for Perl
-Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

'''JMockit'''

-Simpler and more succinct APIs for writing tests with behavior verification or state verification
-Provides other tools for supporting the creation of large test suites
-Uses class remapping instead of the original proxy dependencies
https://jmockit.dev.java.net/

== Conclusion ==

A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.

The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.

== Links ==
http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T17:59:24Z

SteelerNation:

== Comparison of Mock Frameworks ==

== Definition: ==
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]

Mock Frameworks are the environments that are available to create these mock objects and mock tests.
There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.

== Concepts: ==

'''Why Mock?'''

The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.

Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.

Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.

Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-
Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.

Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.

'''Different Types:'''

Proxy:
A proxy object is an object that is used to take the place of a real object. This is the original concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up through an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.

Class Remapping:
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Insturment class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.

== Comparison of Different Systems: ==

'''EasyMock-'''
EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
-Dynamic creation of Mock Objects
-Supports refactoring-safe Mock Objects
-Ability to return values and exceptions.
-Method order checking
http://easymock.org/

'''MOQ'''
Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
-Supports mocking interfaces as well as classes.
-Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
- Intercept and raise events on mocks
http://code.google.com/p/moq/.

'''NMock'''
NMock is a dynamic mock object library for .NET.
-Dynamic creation of Mock Objects
-Allows expectations to be defined and fails the test if any expectations are violated
-Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterwards using assertions
-Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

'''Rhino Mocks'''
-Only supports mocks of interfaces, delegates and classes, including those with parameterized constructors.
-Expectations on the called methods by using strongly typed mocks instead of strings.
-Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

'''jMock'''
- Forces test to be explicit about the argument values that will be passed to the expected methods
-Ability to write custom stubs, constraints, and Invocation Matchers
-Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

'''Mocha'''
-Similar to jMock only for Ruby
- Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

'''Test::MockObject'''
-Similar to jMock only for Perl
-Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

'''JMockit'''
-Simpler and more succinct APIs for writing tests with behavior verification or state verification
-Provides other tools for supporting the creation of large test suites
-Uses class remapping instead of the original proxy dependencies
https://jmockit.dev.java.net/

== Conclusion: ==

A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.

The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.

== Links: ==
http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

CSC/ECE 517 Fall 2009/wiki1a/2 sc

2009-09-08T17:28:12Z

SteelerNation:

Mock objects and mock frameworks. When performing tests, it's convenient to have the objects be in a particular configuration, so that boundary cases can be tested. Setting up the objects can sometimes be complicated. The Wikipedia article for mock objects lists several, but does not compare them. Compare different systems for mock objects, and mock frameworks (which are used to set up mock objects).

Title: Comparison of Mock Objects and Mock Frameworks
Definition:
In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A computer programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. [FROM http://en.wikipedia.org/wiki/Mock_object ]
Mock Frameworks are the environments that are available to create these mock objects and mock tests. There are many different types of frameworks for different platforms. They are a set of programmable APIs that allow creation of mock and stub objects in relative easy fashion. Mock frameworks save the developer from the need to write repetitive code to test or simulate object interactions.
Concepts:
Why Mock?
The concept behind mock objects is that there is a need to create an object that will take the place of the real object. This mock object will expect a certain method to be called with certain parameters and when that happens, it will return an expected result. When writing units tests for a class that would normally use the real object, we can instead supply it with a mock object. This allows us a new level of flexibility in testing.
Ease of modifying the mock object during separate tests to get it to get it to return a range of different data. Test can pass in valid, invalid, and extreme ranges to test how the code calling it handles such situations.
Simulation of failures, such as the inability to connect to a database, to test the failure mode of classes.
Encourages better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. A running Object-Oriented program is a web of objects that collaborate by calling methods on each other. There sometimes can be many dependencies that have to be met in order to call certain objects. To make the complex dependencies be easily testable, mock objects are created in order to “mock” the stages that the object needs to be in, in order to call upon another object.
Often times in programming, only the changes in state of an object are tested. This would be acceptable only if there was one object. However, many real world applications contain hundreds upon hundreds of different objects. Mock objects have changed the focus of test from thinking about the changes in state of an object to thinking about its interactions with other objects.
Different Types:
Proxy:
A proxy object is an object that is used to take the place of a real object. This is the orginal concept for all mock frameworks. In the case of mock objects, a proxy object is used to imitate the real object your code is dependent on. The proxy object is created with the mocking framework, and then set it on the object using either a setter or constructor. One has to be able to set the dependency up thru an external means. This is one of the reasons Dependency Injection frameworks like Java Spring have increase in popularity because they allow the ability to inject the proxy objects without modifying code.
Class Remapping:
The second form of mocking is to remap the class file in the class loader. The concept is relatively new and is provided by the new java.lang.Insturment class. The basic idea is that the framework tells the class loader to remap the reference to another class file it will load which will be the mocked class. This allows one to be able to mock objects that are created by using the new operator much like other Object Oriented languages. Although this approach provides more functionality than the proxy object approach, it is much more complex and harder to write and fully understand.
Comparison of Different Systems:
EasyMock- .NET and Java
EasyMock has been the first dynamic Mock Object generator, relieving users of hand-writing Mock Objects, or generating code for them.
-Dynamic creation of Mock Objects
-Supports refactoring-safe Mock Objects
-Ability to return values and exceptions.
-Method order checking
http://easymock.org/

MOQ -.NET
Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 and C# 3.0 features.
-Supports mocking interfaces as well as classes.
-Supports the overriding of expectations where the test can set default expectations in a fixture setup, and override as needed on certain tests
- Intercept and raise events on mocks
http://code.google.com/p/moq/.

NMock
NMock is a dynamic mock object library for .NET.
-Dynamic creation of Mock Objects
-Allows expectations to be defined and fails the test if any expectations are violated
-Expectations are specified beforehand and verified on the fly as the code under test is being executed, rather than afterwards using assertions
-Implementations of interfaces are generate on the fly at runtime
http://www.nmock.org/index.html

Rhino Mocks
-Only supports mocks of interfaces, delegates and classes, including those with parameterized constructors.
-Expectations on the called methods by using strongly typed mocks instead of strings.
-Recursive mocking
http://ayende.com/projects/rhino-mocks.aspx

jMock
- Forces test to be explicit about the argument values that will be passed to the expected methods
-Ability to write custom stubs, constraints, and Invocation Matchers
-Works well with the auto completion and refactoring features of your IDE
http://www.jmock.org/index.html

Mocha
-Similar to jMock only for Ruby
- Supports testing frameworks: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest and JtestR.
http://mocha.rubyforge.org/

Test::MockObject
-Similar to jMock only for Perl
-Simple testing techniques
http://search.cpan.org/dist/Test-MockObject/lib/Test/MockObject.pm

JMockit
-Simpler and more succinct APIs for writing tests with behavior verification or state verification
-Provides other tools for supporting the creation of large test suites
-Uses class remapping instead of the original proxy dependencies

https://jmockit.dev.java.net/

Conclusion:
A mock object framework can make sure that the method under test, when executed, will in fact call certain functions on the mock object and that the method under test will react in an appropriate way to whatever the mock objects do. Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. Writing tests provides a framework to think about functionality, Mock Objects provides a framework for making assertions about those relationships and for simulating responses. Mock Objects also allows programmers to make their tests only as precise as they need to be.
The different frameworks provide a myriad of options for software developers to produce the correct mock tests for their software. The more complex the system, the more important it is when selecting the mock framework. Support for the framework is essential as well.
Links:
http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html