Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-12T23:55:09Z

Ajain9:

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11] [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1e_az chapter1]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns, Source Making]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern, computer_science wikipedia]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-12T23:49:45Z

Ajain9: /* References */

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns, Source Making]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern, computer_science wikipedia]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T09:50:43Z

Ajain9:

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1] 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3] 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T09:50:03Z

Ajain9:

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. [http://sourcemaking.com/design_patterns 1]
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. [http://c2.com/cgi/wiki?DesignPatterns 3]
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T09:48:11Z

Ajain9:

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages. [http://sourcemaking.com/design_patterns 1] [http://c2.com/cgi/wiki?DesignPatterns 3] [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ 5] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter 2]

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible. [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table 11]

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here. [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf 4]

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://c2.com/cgi/wiki?ObserverPattern 6]

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place. [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm 8]

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit. [http://www.oodesign.com/decorator-pattern.html 7]

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns. [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html 9]

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures. [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ 10]

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T09:34:42Z

Ajain9:

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible.

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here.

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit.

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns.

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

=References=
*[1]: [http://sourcemaking.com/design_patterns Design Patterns (Source Making)]

*[2]: [http://en.wikipedia.org/wiki/Design_pattern_(computer_science)?utm_source=twitterfeed&utm_medium=twitter Design pattern (computer_science) wikipedia.org]

*[3]: [http://c2.com/cgi/wiki?DesignPatterns Design Patterns wiki]

*[4]: [http://www.irisa.fr/prive/jezequel/enseignement/dp.pdf irisa.fr]

*[5]: [http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/slides/ Slides, uottawa.ca]

*[6]: [http://c2.com/cgi/wiki?ObserverPattern Observer Pattern, c2.com]

*[7]: [http://www.oodesign.com/decorator-pattern.html Decorator Pattern, oodesign.com]

*[8]: [http://www.oreillynet.com/ruby/.../ruby_design_patterns_observer.htm Ruby Design Patterns, Observer Pattern, oreillynet.com]

*[9]: [http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html Decorator Pattern with Ruby, lukeredpath.co.uk]

*[10]: [http://www.devarticles.com/c/a/Ruby-on-Rails/Iterators-in-Ruby/ Iterators in Ruby, devarticles.com]

*[11]: [http://www.site.uottawa.ca:4321/oose/index.html#designpattern_table uottawa.ca]

CSC/ECE 517 Fall 2010/ch7 7a AV

2010-12-01T08:55:28Z

Ajain9:

=Novel implementations of design patterns in dynamic languages=

==Design Pattern==

It is a template that provides a description of good design alternatives for the benefit of programmers. It is used to provide recurring solutions to design patterns in both static and dynamic object oriented languages.

==Importance of design patterns in programming languages==

i. In a given context, design patterns can be a reusable solution for a general problem. 
ii. For the benefit of novice programmers, design patterns are usually documented systematically. 
iii. Design patterns help us to learn from the experience of other software developers. 
iv. Design patterns are a framework for evolution and improvement of existing patterns. 
v. It provides better abstraction for program organization. 

==How to choose a particular design pattern?==

i. Identify the different classes and methods for a given problem. 
ii. Recognize the different solutions that can be used to solve the problem. 
iii. Compare and contrast the trade offs between the design patterns that can be used for that particular context. 
iv. Recognize the language limitations for each of the design patterns. 
v. Finally choose the most suitable and efficient design. 

=Design patterns in dynamic programming languages=

As dynamic languages need less overhead for bookkeeping (classes, methods) therefore design patterns are easier to use in dynamic languages. Dynamic o-o languages do not have class-restricted design, Hence design patterns are simpler and flexible.

Some design patterns have novel implementation in dynamic languages. The alternative ways of implementing design patterns ( such as observer, decorator, iterator) is being discussed here.

=Observer Pattern=
This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

[[Image:Fig5_1.png]]

Fig 5.1 Use Case diagram for Observer pattern

This pattern is used in the context, where frequent updates of different states take place.
It becomes an overhead if each object has to check whether the state has been updated or not. Hence all such objects (called the “observers”) register themselves to another object (“subject”). The subject is responsible to keep check on the object, and notify the observers when a change of state takes place.

==Implementation of observer pattern in ruby==
<pre>
module Observable #subject module which checks for update and notifies
def ModifyPrice( &callObservers )
@observers = []
@observers << callObservers
end

def notify_observers
@observers.each { |o| o.call }
end
end
</pre>

<pre>
class Seller #state that is checked frequently is price.
include Observable
attr :price
def initialize( price = 10 )
@price = price
end

def increasePrice
@price = @price + 2.5
notify_observers
end

def decreasePrice
@price = @price - 0.5
notify_observers
end

end
</pre>

<pre>
StoreKeeper = Seller.new
StoreKeeper.ModifyPrice do #updates price and then notifies
puts "The new price of the product is #{StoreKeeper.price}"
end

StoreKeeper.increasePrice
StoreKeeper.decreasePrice
StoreKeeper.increasePrice
</pre>

==Output==

The new price of the product is 12.5
The new price of the product is 12.0
The new price of the product is 14.5

In the above example, we have the observable module that checks if a particular state is being updated or not. When the update happens the notify function is immediately called.
We maintain a seller class that uses the observable module, when the seller increases or decreases the price of a product the notify_observers is called which then calls the
modify_price which prints the new price.
This program uses observer pattern in a novel way using closures which differs from its implementation in any other static language.

=Decorator Pattern=

This design pattern is used when additional functionalities have to be given to a particular class in a dynamic manner. It is an alternative for subclassing and inheritance (which is done statically). The most common application of decorator patterns is in designing of GUI toolkit.

[[Image:Fig6_1.png]]

Fig 6.1 Use Case diagram for Observer pattern

==Implementation of Decorator pattern in ruby==
<pre>
module Decorator
def initialize(decorated)
@decorated = decorated
end
end
</pre>
<pre>
class SimplePizza
def price
@price = 5
end
end
</pre>

<pre>
class OnionTopping
include Decorator

def price
@price = @decorated.price+ 1.1
end
end
</pre>

<pre>
class CheeseTopping
include Decorator

def price
@decorated.price + 1.0
end
end
</pre>
<pre>
#Price of Pizza without decoration(no toppings)
puts "price of pizza without Topping #{SimplePizza.new.price}"

#Price of Pizza with OnionToppings (decorater used here)
#initialise OnionTopping class as a decorator for the class SimplePizza
OTPizza =OnionTopping.new(SimplePizza.new)

puts "price of pizza with OnionTopping #{OTPizza.price}"

TwoTopping = CheeseTopping.new(OnionTopping.new(SimplePizza.new))
puts "price of pizza with cheese and Onion toppings #{TwoTopping.price}"
</pre>

==output==
price of pizza without Topping 5
price of pizza with OnionTopping 6.1
price of pizza with cheese and Onion toppings 7.1

In the example above, we have a class called SimplePizza which initializes the cost of a pizza without any toppings. There might be a situation where a customer would want a pizza with a topping instead writing the price for each type of pizza. For this porpose we use decorator patterns.

Here the SimplePizza is the base class. The OnionToppingPizza and cheeseToppingPizza classes are the decorators used for this base class. This program dynamically calculates the price of each pizza depending on the choice of topping.

Advantage:
Altough we dint write a class to calculate the price of a TwoToppingPizza, The decorator pattern used in this program was able to calculate the price of TwotoppingPizzza accurately.

=Iterator pattern=
Iterator design pattern is used to traverse each element of a collection object sequentially. While using the iterator, the programmer need not worry about the underlying interface of the collection object.The iterator interface usually consists of hasNext( ),next( ), isDone( ) functions.

[[Image:Fig7_1.png]]

Fig 7.1 Use Case diagram for Iterator pattern

==Implementation of Iterator pattern in ruby==

===Example 1 - square_arrayElements===

This is a simple example where in an iterator each is used to print the square of each element in an array using closures.

<pre>
def square_arrayElements (array)
array.each {|a| puts a*a }
end
</pre>
<pre>
array = [1,2,3,5]
square_arrayElements(array)
</pre>

 
Output: 
1 
4 
9 
25 
The array elements 1,2,3,4 is passed to the function square_arrayElements. The iterator parses each element and sends it to the block where the square of each element is calculated and prints it.

===Example 2 EvenOrOdd ===
In below program, the iterator traverses through each element of the array and checks if the element is odd or even. This check is performed in the block which prints whether the given element is odd or even.
<pre>
def evenOrodd(array1)
array1.each { |i|
if i % 2 == 0
puts "#{i} is a even number"
else
puts "#{i} is a odd number"
end

}
end
</pre>
<pre>
array1 = [1,2,3,5]
evenOrodd(array)
</pre>

Output 
1 is a odd number 
2 is a even number 
3 is a odd number 
5 is a odd number 

=conclusion=
Design patterns help novice software developers to write efficient programs. The novel implementations of a few designs patterns like observer, decorator and iterator in dynamic language like Ruby was discussed above.In the observer pattern the subject notifies any updates in the state to all its dependants (observers).The decorator pattern adds extra features to the already existing class.The iterator helps to access the elements of a collection object individually. The real-world situations where each design pattern can be used were illustrated with respective examples.

File:Fig7 1.png

2010-12-01T08:54:56Z

Ajain9:

File:Fig6 1.png

2010-12-01T08:52:21Z

Ajain9:

File:Fig5 1.png

2010-12-01T08:37:20Z

Ajain9:

CSC/ECE 517 Fall 2010/ch5 5f aj

2010-11-03T05:47:01Z

Ajain9:

SAS Component Object Model

==Introduction==
SAS (pronounced as "sass") is a collection of software for Statistical Analysis. SAS help analyst to perform data entry, retrieval, management and mining, report writing and graphics, statistical analysis, etc. SAS has business solutions that enable large-scale software solutions for areas such as IT management, human resource management, financial management, business intelligence, customer relationship management etc. SAS was started by Anthony J. Barr in 1966 [http://en.wikipedia.org/wiki/Anthony_James_Barr 1] as a NC state graduate student like us. SAS/AF is application facility, a set of application development tools to create customized desktop GUI applications. In simple words it can be called as a library of drag-and-drop widgets which are object oriented. SAS/AF software contain an enhanced SAS component Language also known as Screen Control Language. SCOM is an object oriented programming model that provides a framework for SAS/AF component development. SCOM makes it easy to develop plug-and-play components that adhere to simple communication rules, which in turn makes it easy to share information between components.

==Overview==
SCOM can be used to develop components that adhere to simple communication rules, which in turn make it easy to share information between components.

==SCOM in detail==
===Purpose of SCOM===

CSC/ECE 517 Fall 2010/ch5 5f aj

2010-11-03T04:05:05Z

Ajain9:

SAS Component Object Model

==Introduction==
SAS/AF software contain an enhanced SAS component Language also known as Screen Control Language. SCOM is an object oriented programming model that provides a framework for SAS/AF component development. SCOM makes it easy to develop plug-and-play components that adhere to simple communication rules, which in turn makes it easy to share information between components.

.[http://www.bredemeyer.com/use_cases.htm 2]

==Overview==
In general '''use cases''' are used to capture the '''who''' i.e the actors, the '''what''' i.e interactions and system reactions, and the '''purpose''' i.e the goal of a particular system without having to worry too much about the internal workings of the system. Use cases originated in the Object oriented community but their applicability is not limited to object oriented systems. [http://en.wikipedia.org/wiki/Use_case 1]

==SCOM in detail==
===Purpose of SCOM===

===Use case templates ===
*'''Use case'''
Each use case should have a unique name describing in a manner which describes its purpose. The name usually is a active phrase, in a verb-noun format. Use cases can also have a reference number associated with them, this is to indicate how they relate to other use cases. Also the use case name should maintain creation and modification history of the template, this information should be preceded by the keyword '''history'''.
*'''Description'''
In the description field of the use case template we maintain the goals of the use case. The description should list the source for the functional requirement, this information should be preceded by the keyword '''sources'''.
*'''Actors'''
Use cases identify the intent satisfying the role assumed by external '''actors''' interacting with the “system under discussion/test”. The actors can be classified into '''primary actor''' or '''secondary actor'''. A '''primary actor''' is one having a goal requiring the assistance of the system. A '''secondary actor''' is one from which the system needs assistance to satisfy a goal.[http://www.wilsonmar.com/1usecase.htm 8]
*'''Assumptions'''
Assumptions made in order to achieve the goals defined should be stated in a declarative manner. The assumptions should be evaluated to a true or false and in case if the assumption is false then it is unspecified as to what the use case will do. Behavior in case of an assumption failure can accounted for using use-case extensions.
*'''Steps'''
The sequence of interactions necessary to successfully meet the goal. The interactions between the system and actors are structured into one or more steps which are expressed in natural language. A step completes when all its component interactions have completed. A step has the form
<sequence number><interaction>. If there are multiple steps then each step should have a sequence number showing its position in the list of interactions. The execution of one or more steps can be made conditional by using programming-like IF-then-ELSE constructs.[http://www.bredemeyer.com/pdf_files/use_case.pdf 3]
*'''Variations'''
Variations represent any variation in the steps of the use case. The format of the variation is <step reference> < list of variations separated by or>.
*'''Non functional requirements'''
Non functional requirements related to fault tolerance,performance,etc are listed as <keyword> : < requirement>. Here again the non functional requirements are list in a natural and understandable format.
*'''Issues'''
This section lists the issues which are awaiting the resolution.

===Use case template example===
[[Image:usecasetemplateexample.png]]

===Types of Use cases===
*'''System use cases''': System use case describes the service which the system provides for the actor. The system use case describes what the system would do in response to the actor's actions. An actor in the system use cases can be wither a human user or another system interacting with the system under consideration.
*'''Business use cases''': Business use cases are used to define the processes which will be used by the external actors. The business use cases treat the system under consideration as a black box in which the actors are given a description as to what the process does by specifying a value. [http://www.agilemodeling.com/artifacts/systemUseCase.htm#Informal 5]

==Use case extension==
In order to deal with the case of assumption failure, a variant of the use cases can defined using the use case extension.
===Use case extension template===
*'''Use case extension''' [http://www.bredemeyer.com/pdf_files/use_case.pdf 3]
The extension name includes a unique identifier for the extension and a reference to the use case to which the extension applies
*'''Changed field'''
This field documents the field of the use case template which are going to be changed.
*'''Steps'''
This field mentions the steps field of the use case which require change, the changes are expressed in terms of new or altered steps which require change that apply to a use case at extension point, if some condition is true.

===Use case extension example===
Continuing the example of the online shopping portal system use case previously explained, on extending the use case we get the following use case extension template.[[Image:Usecaseextensiontemplateexample.png]]

==Use cases in UML==
UML represents the use cases in a diagrams called as the '''use case diagrams'''. [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_4_2q 4]
Lines in a UML use case between an actor and the system represent a more abstract concept of relationship of communication, acquaintance, or inheritance.
A use case circle can be more than a user invoking an on-demand service that passively waits until called upon.
A Use case circle can be event-driven, which proactively notifies one or more subscribers when specific events occur.
Services that run on their own without formal invocation may be better represented as an (automated) actor rather than as a use case circle.
The general representation of the use case environment in '''Unified Modeling Language'''(UML)is represented in the figure below
[[Image:Generalusecase.png]]

'''Example''': Consider a scenario in which a customer is visiting a online shopping portal system. In this scenario as we see the customer as the actor interacting with the online shopping portal system. [http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm 6]
The use case diagram covers the basic operations which the customer would normally perform while ordering an item from the shopping portal. This use case diagram can be extended to include extra scenarios such as the multiple item order, order cancellation and so on.

[[Image:Usecaseexample.png]]

==See Also==
*[http://en.wikipedia.org/wiki/List_of_UML_tools List of UML Tools]

*[http://alistair.cockburn.us/index.php/Pluggable_use_cases#Pluggable_Use_Case_Concept Pluggable Use Cases]

==References==
*[1]: Wikipedia.2010.Wikipedia-Use Case. wikipedia.org

*[2]: Bredemeyer.2006.Functional Requirements and Use cases. Bredemeyer Consultancy

*[3]: Coleman,Derek.1998.A Use Case Template:draft for discussion. Hewlett Packard

*[4]: Mediawiki.2007.Wiki reference wiki2_4_2q.North Carolina State University

*[5]: Ambler,W.Scott.2009.System Use Cases.Ambysoft Inc.

*[6]: Braun,David.2000.UML tutorial[online].Kennesaw State University

*[7]: Mall,R.2004. Fundamentals of Software Engineering. Prentice Hall, New Delhi.

*[8]: Mar,Wilson.2010. Use cases. Wilson Mar

==Links for References==
*[http://en.wikipedia.org/wiki/Use_case Use case]

*[http://www.bredemeyer.com/use_cases.htm Functional Requirements and Use cases]

*[http://www.bredemeyer.com/pdf_files/use_case.pdf Use case extension template]

*[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_4_2q Wiki reference]

*[http://www.agilemodeling.com/artifacts/systemUseCase.htm#Informal Use case Types]

*[http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm Use cases HOW TO?]

*[http://www.wilsonmar.com/1usecase.htm Use cases explained (8) ]

CSC/ECE 517 Fall 2010 ch5 5f aj

2010-11-02T15:54:35Z

Ajain9:

SAS Component Object Model

CSC/ECE 517 Fall 2010/ch5 5f aj

2010-11-02T15:50:43Z

Ajain9:

SAS Component Object Model

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:53:21Z

Ajain9: /* Aspect Oriented Programming */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ 4]. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html 9].

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications[http://aspectr.sourceforge.net/ 6]. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ 7].
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition [http://rubyforge.org/frs/?group_id=4281 8].

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:52:01Z

Ajain9: /* Example */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ 4]. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications[http://aspectr.sourceforge.net/ 6]. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ 7].
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition [http://rubyforge.org/frs/?group_id=4281 8].

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:50:52Z

Ajain9: /* AspectR */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ 4]. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications[http://aspectr.sourceforge.net/ 6]. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ 7].
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:48:48Z

Ajain9: /* AspectR */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ 4]. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications[http://aspectr.sourceforge.net/ 6]. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:36:20Z

Ajain9: /* Aspect Oriented Programming */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ 4]. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:26:05Z

Ajain9: /* Aspect Oriented programming vs Object Oriented Programming */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:14:49Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: [http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP Implementing Object Caching with AOP]

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

*[7]: [http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/ Aspect the Ruby way]

*[8]: [http://rubyforge.org/frs/?group_id=4281 Ruby Forge]

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:10:44Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

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

*[7]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[8]: http://rubyforge.org/frs/?group_id=4281

*[9]: [http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html A detailed series of articles about the basics of aspect-oriented programming and AspectJ]

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:03:37Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: [http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/ Alternative Implementations for Aspect-Oriented Programming Language Constructs: A Case Study in Ruby]

*[5]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

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

*[7]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[8]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:01:11Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming in Ruby]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[5]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

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

*[7]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[8]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T03:00:30Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]

*[2]: [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf Aspect Oriented Programming]

*[3]: [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf Aspect Oriented Programming, Comparison of Languages]

*[4]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[5]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

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

*[7]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[8]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T02:58:34Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: http://en.wikipedia.org/wiki/Aspect-oriented_programming

*[2]: http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

*[3]: http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

*[4]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[5]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

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

*[7]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[8]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T02:55:28Z

Ajain9: /* Aspect Oriented Programming */

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects [http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf 3]. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: http://en.wikipedia.org/wiki/Aspect-oriented_programming

*[2]: http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

*[3]: http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

*[4]: http://www.cs.virginia.edu/~sullivan/

*[5]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[6]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

*[7]: http://aspectr.sourceforge.net/

*[8]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[9]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T02:52:30Z

Ajain9:

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR. [http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf 2]
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: http://en.wikipedia.org/wiki/Aspect-oriented_programming

*[2]: http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

*[3]: http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

*[4]: http://www.cs.virginia.edu/~sullivan/

*[5]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[6]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

*[7]: http://aspectr.sourceforge.net/

*[8]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[9]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T02:51:41Z

Ajain9:

==Introduction==
Aspect Oriented Programming [http://en.wikipedia.org/wiki/Aspect-oriented_programming 1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR.
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: http://en.wikipedia.org/wiki/Aspect-oriented_programming

*[2]: http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

*[3]: http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

*[4]: http://www.cs.virginia.edu/~sullivan/

*[5]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[6]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

*[7]: http://aspectr.sourceforge.net/

*[8]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[9]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T02:50:22Z

Ajain9:

==Introduction==
Aspect Oriented Programming [1] is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR.
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: http://en.wikipedia.org/wiki/Aspect-oriented_programming

*[2]: http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

*[3]: http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

*[4]: http://www.cs.virginia.edu/~sullivan/

*[5]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[6]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

*[7]: http://aspectr.sourceforge.net/

*[8]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[9]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-16T02:43:38Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspect Oriented Programming in Ruby is known as AspectR.
Aspects such login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
*[1]: http://en.wikipedia.org/wiki/Aspect-oriented_programming

*[2]: http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

*[3]: http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

*[4]: http://www.cs.virginia.edu/~sullivan/

*[5]: http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

*[6]: http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

*[7]: http://aspectr.sourceforge.net/

*[8]: http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

*[9]: http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T02:40:29Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Aspect Oriented programming vs Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T02:36:45Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T02:35:56Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T02:17:20Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==Summary==
Aspect oriented Programming is a programming technique which has added a third dimension to programming languages, which is a significant improvement over Object Oriented Programming as it lets the programmer focus on working on the business logic in times when he has to change his line of thinking mid-way. All this without having to to be worried about his aspect being scattered through the code as all his new code can be incorporated in aspects.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T02:15:34Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming==

Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Cross-cutting: Cross-cutting phenomenon is directly responsible for the tangling in the code. The single composition mechanism the language provides us,i.e, procedure calling is very well suited to building up the unoptimized functional units. But it can't help us compose the functional units and the loop fusion simultaneously, because, they follow such different composition rules and yet must compose. This breakdown forces us to combine the properties entirely by hand.

Join Points: A well defined location at a point in the execution of a program. The join point model defines three things: When the advice can run called join points, a way to specify join points called point cuts and means to specify the code to run join points called advice. Join point model can be compared based on join points exposed, how join points are specified, the structural enhancements that can be expressed and the operations permitted at the join points.

PointCut: A set of join points.

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==AspectR==
Aspects such as login, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T02:02:51Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation ==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming ==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T01:59:42Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T01:37:58Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==AspectJ==
An AspectJ aspect is a crosscutting type consisting of an advice on pointcuts and lexical introduction of behavior into other types. It is a general-purpose aspect-oritented extension to Java. Like Classes, aspects can have internal state and behavior, can extend other aspects and classes, and can implement interfaces. AspectJ uses extensions to the Java programming language to specify the crossing rules. These extensions are designed in such a way that a Java programmer would find no difference in using them. The AspectJ extensions use the following constructs to specify the weaving rules programmatically; they are the building blocks that form the modules that express the crosscutting concern’s implementation.

Join point
In AspectJ everything revolves around ajoin points, since they are the places where the crosscutting actions are woven in. Lets look at below code snippet:

public class Post{
...
void addPost(String text){
//add to Post database the given text
}
}

The join points in the Post Class include the execution of the addPost() method and the access to the database table Post.

Pointcut
A pointcut can select join point that is a call to a method, and it could also capture the method's context, such as the target object on which the method was called and the method's arguments.

We can write a pointcut that will capture the execution of the addPost() method in the Post class shown earlier:
execution(void Post.addPost(String))

The pointcut construct in AspectJ allows use of a few wildcards to capture related set of join points. For example,
the following pointcut captures the execution of all methods in Post class and its subclasses:

execution(void Post+*(..))

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T01:35:47Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==AspectJ==
An AspectJ aspect is a crosscutting type consisting of an advice on pointcuts and lexical introduction of behavior into other types. It is a general-purpose aspect-oritented extension to Java. Like Classes, aspects can have internal state and behavior, can extend other aspects and classes, and can implement interfaces. AspectJ uses extensions to the Java programming language to specify the crossing rules. These extensions are designed in such a way that a Java programmer would find no difference in using them. The AspectJ extensions use the following constructs to specify the weaving rules programmatically; they are the building blocks that form the modules that express the crosscutting concern’s implementation.

Join point
In AspectJ everything revolves around ajoin points, since they are the places where the crosscutting actions are woven in. Lets look at below code snippet:

public class Post{
...
void addPost(String text){
//add to Post database the given text
}
}

The join points in the Post Class include the execution of the addPost() method and the access to the database table Post.

Pointcut
A pointcut can select join point that is a call to a method, and it could also capture the method's context, such as the target object on which the method was called and the method's arguments.

We can write a pointcut that will capture the execution of the addPost() method in the Post class shown earlier:
execution(void Post.addPost(String))

The pointcut construct in AspectJ allows use of a few wildcards to capture related set of join points. For example,
the following pointcut captures the execution of all methods in Post class and its subclasses:

execution(void Post+*(..))

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:58:32Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==AspectJ==
An AspectJ aspect is a crosscutting type consisting of an advice on pointcuts and lexical introduction of behavior into other types. It is a general-purpose aspect-oritented extension to Java. Like Classes, aspects can have internal state and behavior, can extend other aspects and classes, and can implement interfaces.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:56:08Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

==Aspect Oriented Programming==
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations.

[[Image:Figure2.png|frame|center]]
In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends.

Concepts

Join Points: A well defined location at a point in the execution of a program.
PointCut: A set of join points
Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.
Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==AspectJ==
An AspectJ aspect is a crosscutting type consisting of an advice on pointcuts and lexical introduction of behavior into other types. It is a general-purpose aspect-oritented extension to Java. Like Classes, aspects can have internal state and behavior, can extend other aspects and classes, and can implement interfaces.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:47:56Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end

==AspectJ==
An AspectJ aspect is a crosscutting type consisting of an advice on pointcuts and lexical introduction of behavior into other types. It is a general-purpose aspect-oritented extension to Java. Like Classes, aspects can have internal state and behavior, can extend other aspects and classes, and can implement interfaces.

==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:40:12Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

===Creating a Simple Aspect in Ruby===
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end
==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:32:23Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

==Creating a Simple Aspect in Ruby==
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end
==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:30:37Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

==Creating a Simple Aspect in Ruby==
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from http://rubyforge.org/frs/?group_id=4281
alternatively use gem install aquarium

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end
==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:28:54Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

==Creating a Simple Aspect==
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from http://rubyforge.org/frs/?group_id=4281
alternatively use gem install aquarium

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end
==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:28:26Z

Ajain9: /* References */

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

==Creating a Simple Aspect==
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from http://rubyforge.org/frs/?group_id=4281
alternatively use gem install aquarium

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end
==References==
1. http://en.wikipedia.org/wiki/Aspect-oriented_programming
2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf
3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf
4. http://www.cs.virginia.edu/~sullivan/
5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/
6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP
7. http://aspectr.sourceforge.net/
8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-07T00:27:25Z

Ajain9:

==Introduction==
Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

==Overview==
If we look at the programming field from a distance we’ll generally divide programming
languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one
as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and
polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by
describing so called aspects that cross-cut the structure of the program.

==Motivation and Terminologies==
Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect
Example.

[[Image:Figure1.png|frame|center]]

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

[[Image:Figure2.png|frame|center]]
Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects.
In Java, the aspects contain advice and intertype declarations. In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. The pointcuts in JAVA defines the times when one can access the user account, and the code in the advice body defines how the authentication implementation takes place.
Join points in Aspect Oriented Programming

==AspectR==
Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy.
Aspect oriented programming in Ruby can be implemented using Aquarium framework.

==Creating a Simple Aspect==
Let us understand how easily an aspect behavior can be setup.

===Setup===
Install Aquarium gem from http://rubyforge.org/frs/?group_id=4281
alternatively use gem install aquarium

===Example===
Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
end
end

Before advice tells what work needs to be done before the method is called.
After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.
class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result # block returns the result of the proceed.
end
end
==References==
http://en.wikipedia.org/wiki/Aspect-oriented_programming
http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf
http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf
http://www.cs.virginia.edu/~sullivan/
http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/
http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP
http://aspectr.sourceforge.net/
http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

CSC/ECE 517 Fall 2010/ch3 3d AI

2010-10-06T23:59:41Z

Ajain9: /* Example */