Post on 17-Jul-2015
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 1/29
A
Seminar report
On
ASPECT ORIENTED PROGRAMMING
Submitted
In Partial Fulfillment
For The Award of the Degree Of
BACHELOR OF TECHNOLGY
In Information Technology
Submitted To: Submitted By:
Mr. Shiv Kumar Agarwal Sudhanshu Mathur
Head Of Department Roll no:IT08059
Department Of I.T.
DEPARTMENT OF INFORMATION TECHNOLOGY
JAIPUR ENGINEERING COLLEGE, KUKAS
RAJASTHAN TECHNICAL UNIVERSITY
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 2/29
A
Jaipur Engineering College, Kukas,
JaipurSESSION 2011-2012
CERTIFICATE
This is to certify that project entitled “Aspect oriented programming”, submitted by
“Sudhanshu Mathur”, students of final year B.Tech in Information Technology, JAIPUR
ENGINEERING COLLGE, KUKAS, JAIPUR was completed under my supervision andtheir work was found satisfactory and I found them sincere towards their work.
Signature
Mr.Shiv Agarwal
Head, Department of IT
Place: - Jaipur
Date: - 14/03/2012
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 3/29
Preface
This report intends to reflect some of the basics required for building a project i.e. “Aspect
oriented programming and related fundamentals”. The total aspects have been formulated and
presented on the basis of ideas and information gathered from emerging technology.
This report has been written in response to a comprehensive study. The report mentions and
evaluates the various aspects, through analysis of the various facts and figures. Accuracy and
precision has been given prime consideration, while compiling the report.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 4/29
ACKNOWLEDGEMENT
Let me in this page express my heartiest gratitude to all those who helped me in various
stages of this study. I am very much thankful to Dr. G.D.SHARMA, Director (Academics),
JEC College, Kukas, and Mr. Shiv Kumar Agarwal, HOD, Dept. Of IT for giving me
permission to undergo the seminar and providing all other necessary facility. I would also
thankful to Mr. Manoj Raman and Ms Anuradha, Sr. Faculty of IT department for their
kind support.
During the seminar period all the staff member of Deptt. have helped me with there skills.
Here by I express my sincere thanks to seminar coordinator. Also I am thankful to other
technical staff of the Deptt. who have helped me to complete my seminar successfully. I wishto express my deep sense of gratitude to my seminar guide for her valuable guidance and kind
cooperation without which this project would have not been possible.
Sudhanshu Mathur
(IT08059)
IT Department
Jaipur Engineering College
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 5/29
INDEX
CHAPTER NAME OF THE CHAPTER PAGE NO
1. INTRODUCTION 02
2 GOALS OF ASPECT ORIENTED
PROGRAMMING
04
3 TERMINOLOGY
3.1 CROSS
CUTTING
CONCERN
S
07
3.2 ASPECT 08
3.3 ADVICE 08
3.4 JOIN-
POINT
09
3.5 POINT-
CUT
10
07
4 OVERVIEW OF ASPECT ORIENTED
PROGRAMMING
11
5 ARCHITECTURE OF AOP 13
6 MOTIVATION AND BASIC CONCEPTS 14
7 ASPECT-J
17
8
COMPARISION TO OTHER PROGRAMMING
PARADIGMS
22
9
ADVANTAGES & DISADVANTAGES 23
10
CONCLUSION 24
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 6/29
ABSTRACT
In software engineering, the programming paradigms of Aspect- Oriented
programming (AOP), and Aspect- Oriented Software development (AOSD) attempt toaid programmers in the separation of concerns, specifically cross-cutting concerns, as an
advance in modularization. AOP does so using primarily language changes, while AOSD
uses a combination of language, environment, and method. Separation of concerns entails
breaking down a program into distinct parts that overlap in functionality as little as possible.
All programming methodologies including procedural programming and object-oriented
programming support some separation and encapsulation of concerns (or any area of interest
or focus) into single entities. For example, procedures, packages, classes, and methods all
help programmers encapsulate concerns into single entities. But some concerns defy these
forms of encapsulation. Software engineers call these crosscutting concerns, because they cutacross many modules in a program. Logging offers one example of a crosscutting concern,
because a logging strategy necessarily affects every single logged part of the system. Logging
thereby crosscuts all logged classes and methods. AOP is a new technology for separating
crosscutting concerns into single units called aspects. An aspect is a modular unit of
crosscutting implementation. It encapsulates behaviour that affects multiple classes into
reusable modules. Typically, an aspect is scattered or tangled as code, making it harder to
understand and maintain. It is scattered by virtue of the function (such as logging) being
spread over a number of unrelated functions that might use its function, possibly in entirely
unrelated systems, different source languages, etc. That means to change logging can require
modifying all affected modules. Aspects become tangled not only with the mainline function
of the systems in which they are expressed but also with each other. That means changing
one concern entails understanding all the tangled concerns or having some means by which
the effect of changes can be inferred.
Aspects emerged out of object-oriented programming and computational reflection. AOP
languages have functionality similar to, but more restricted than metaobject protocols.
Aspects relate closely to programming concepts like subjects, mixins, and delegation. Other
ways to use aspect-oriented programming paradigms include Composition Filters and
the hyperslices approach. Since at least the 1970s, developers have been using forms of
interception and dispatch-patching that resemble some of the implementation methods forAOP, but these never had the semantics that the crosscutting specifications provide written in
one place.
Designers have considered alternative ways to achieve separation of code, such as C#'s
partial types, but such approaches lack a quantification mechanism that allows reaching
several join points of the code with one declarative statement.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 7/29
CHAPTER 1
INTRODUCTION
Aspect Oriented Programming (AOP) is a promising new technology for
separating crosscutting concerns that are usually hard to do in object-oriented programming .
Now-a-days, object-oriented programming (OOP) has become the mainstream programming
paradigm where real world problems are decomposed into objects that abstract behavior and
data in a single unit.OOP encourages software re-use by providing design and language
constructs for modularity, encapsulation, inheritance, and polymorphism. Although OOP has
met great success in modelling and implementing complex software systems, it has its
problems. Practical experience with large projects has shown that programmers may face
some problems with maintaining their code because it becomes increasingly difficult tocleanly separate concerns into modules. An attempt to do a minor change in the program
design may require several updates to a large number of unrelated modules. AOP is a new
technology for separating crosscutting concerns into single units called aspects. An aspect is a
modular unit of crosscutting implementation. It encapsulates behaviors that affect multiple
classes into reusable modules. With AOP, we start by implementing our project using our OO
language (for example, Java), and then we deal separately with crosscutting concerns in our
code by implementing aspects. Finally, both the code and aspects are combined into a final
executable form using an aspect weaver. As a result, a single aspect can contribute to the
implementation of a number of methods, modules, or objects, increasing both reusability
and maintainability of the code.
In computing, Aspect-oriented-programming (AOP) is a programming
paradigm which aims to increase modularity by allowing the separation of cross-cutting
concerns. AOP forms a basis for aspect-oriented software development. AOP includes
programming methods and tools that support the modularization of concerns at the level of
the source code, while "aspect-oriented software development" refers to a whole engineering
discipline.
Question arises that what actually computing is and what we have to do for that….
Computing is usually defined as the activity of using and improving computer
hardware and software. It is the computer-specific part of information technology. Computer
science (or computing science) is the study and the science of the theoretical foundations of
information and computation and their implementation and application in computer systems.
Aspect-oriented programming entails breaking down program logic into distinct parts (so-
called concerns, cohesive areas of functionality). Nearly all programming paradigms support
some level of grouping and encapsulation of concerns into separate, independent entities by
providing abstractions (e.g., procedures, modules, classes, methods) that can be used for
implementing, abstracting and composing these concerns. But some concerns defy these
forms of implementation and are called crosscutting concerns because they "cut across"multiple abstractions in a program.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 8/29
Logging exemplifies a crosscutting concern because a logging strategy necessarily affects
every logged part of the system. Logging thereby crosscuts all logged classes and methods.
All AOP implementations have some crosscutting expressions that encapsulate each concern
in one place. The difference between implementations lies in the power, safety, and usability
of the constructs provided. For example, interceptors that specify the methods to intercept
express a limited form of crosscutting, without much support for type-safety ordebugging. AspectJ has a number of such expressions and encapsulates them in a special
class, an aspect. For example, an aspect can alter the behavior of the base code (the non-
aspect part of a program) by applying advice (additional behavior) at variousjoin
points (points in a program) specified in a quantification or query called a pointcut (that
detects whether a given join point matches). An aspect can also make binary-compatible
structural changes to other classes, like adding members or parents.
Starting from or! and other primitive filters, the programmer could work up to the definition
of a filter that selects just those black pixels on a horizontal edge, returning a new image
consisting of just those boundary pixels.
functionality implementation
pixelwise logical operations written using loop primitive as above
shift image up, down written using loop primitive;
slightly different loop structure difference of two images (defun remove! (a b)
(and! a (not! b)))
pixels at top edge of a region (defun top-edge! (a)
(remove! a (down! a)))
pixels at bottom edge of a region (defun bottom-edge! (a)
(remove! a (up! a)))
horizontal edge pixels (defun horizontal-edge!
(a)
(or! (top-edge! a)
(bottom-edge! a)))
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 9/29
CHAPTER 2
GOALS OF AOP
Aspect-oriented programming (AOP) better separates concerns than previous
methodologies, thereby providing modularization of crosscutting concerns.
In the early days of computer science, developers wrote programs by means of direct
machine-level coding. Unfortunately, programmers spent more time thinking about a
particular machine's instruction set than the problem at hand. Slowly, we migrated to higher-
level languages that allowed some abstraction of the underlying machine. Then came
structured languages; we could now decompose our problems in terms of the procedures
necessary to perform our tasks. However, as complexity grew, we needed better techniques.
Object-oriented programming (OOP). Let us view a system as a set of collaborating objects.
Classes allow us to hide implementation details beneath interfaces. Polymorphisms provided
a common behavior and interface for related concepts, and allowed more specialized
components to change a particular behaviour without needing access to the implementation of
base concepts. Programming methodologies and languages define the way we communicate
with machines. Each new methodology presents new ways to decompose problems: machine
code, machine-independent code, procedures, classes, and so on. Each new methodology
allowed a more natural mapping of system requirements to programming constructs.
Evolution of these programming methodologies let us create systems with ever increasing
complexity. The converse of this fact may be equally true: we allowed the existence of evermore complex systems because these techniques permitted us to deal with that complexity.
Aspect-oriented programming (AOP) better separates concerns than previous methodologies,
thereby providing modularization of crosscutting concerns.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 10/29
Good modularity XML parsing
Figure 1
URL pattern matching in org.apache.tomcat
– red shows relevant lines of code
– nicely fits in two boxes (using inheritance)
Good modularity URL pattern matching
Figure 2
URL pattern matching in org.apache.tomcat
– red shows relevant lines of code
– nicely fits in two boxes (using inheritance)
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 11/29
Implications of Non-modularization
Redundant code
– same fragment of code in many places
Difficult to reason about
– non-explicit structure
– the big picture of the tangling isn’t clear
Difficult to change
– have to find all the code involved
– and be sure to change it consistently
– and be sure not to break it by accident
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 12/29
CHAPTER 3
TERMINOLOGY
Before we delve too deeply into AOP, let's introduce some terminology to help us understand
the concepts.
Cross-cutting concerns: Even though most classes in an OO model will perform a
single, specific function, they often share common, secondary requirements with other
classes. For example, we may want to add logging to classes within the data-access layer and
also to classes in the UI layer whenever a thread enters or exits a method. Even though the
primary functionality of each class is very different, the code needed to perform the
secondary functionality is often identical.
Advice: This is the additional code that you want to apply to your existing model. In our
example, this is the logging code that we want to apply whenever the thread enters or exits a
method.
Point-cut: This is the term given to the point of execution in the application at which cross-
cutting concern needs to be applied. In our example, a point-cut is reached when the thread
enters a method, and another point-cut is reached when the thread exits the method.
Aspect: The combination of the point-cut and the advice is termed an aspect. In the examplebelow, we add a logging aspect to our application by defining a point-cut and giving the
correct advice. Aspects should have the following properties: robust (change to one aspect
should have a limited impact on other aspects), systemic (they affect the target program at
many different places), cross-cutting each other (in the target program information about one
aspect is mixed with information about other aspects), loosely coupled (an aspect should not
know the details of other aspects), contain join points (which are used to combine the
aspects).
CROSS- CUTTING CONCERNS
Separation of concerns entails breaking down a program into distinct parts that overlap in
functionality as little as possible. All programming methodologies including
procedural programming and object-oriented programming support some separation and
encapsulation of concerns (or any area of interest or focus) into single entities. For example,
procedures, packages, classes, and methods all help programmers encapsulate concerns into
single entities. But some concerns defy these forms of encapsulation. Software engineers call
these crosscutting concerns, because they cut across many modules in a program.
An example of crosscutting concerns is "logging," which is frequently used in
distributed applications to aid debugging by tracing method calls. Suppose we do logging at
both the beginning and the end of each function body. This will result in crosscutting allclasses that have at least one function. Other typical crosscutting concerns include context-
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 13/29
sensitive error handling, performance optimization, and design patterns. Crosscutting
concerns may exist in some programs, especially large ones. However, in some situations,
redesign of the system might transform a crosscutting into an object. AOP assumes that
crosscutting concerns may exist in programs and can't be re-factored out of the
design in all situations.
ASPECT
Any AOP language has some crosscutting expressions that encapsulate the concern in one
place. The difference between AOP languages lies in the power, safety, and usability of
the constructs provided. E.g., interceptors that specify the methods to intercept express a
limited form of crosscutting, without much support for type-safety or debugging. AspectJ has
a number of such expressions and encapsulates them in a special class, an aspect. For
example, an aspect can alter the behaviour of the base code (the non-aspect part of a
program) by applying advice (additional behaviour) at various join points (points in a
program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary- compatible structural changes to other
classes, like adding members or parents. Many AOP languages support method executions
and field references as join points. In them the developer can write a pointcut to match, for
example, all field-set operations on specific fields, and code to run when the field is actually
set. Some also support things like defining a method in an aspect on another class. AOP
languages can be compared based on the join points they expose, the language they use to
specify the join points, the operations permitted at the join points, and the structural
enhancements that can be expressed. When thinking of an object and its relationship to other
objects we often think in terms of inheritance. We define some abstract class; let us use a Dog
class as an example. As we identify similar classes but with unique behaviours of their own,
we often use inheritance to extend the functionality. For instance, if we identified a Poodle
we could say a Poodle Is A Dog, so Poodle inherits Dog. So far so good, but what happens
when we define another unique behaviour later on that we label as an Obedient Dog? Surely
not all Dogs are obedient, so the Dog class cannot contain the obedience behaviour.
Furthermore, if we were to create an Obedient Dog class that inherited from Dog, then where
would a Poodle fit in that hierarchy? A Poodle is A Dog, but a Poodle may or may not be
obedient; does Poodle, then, inherit from Dog, or does Poodle inherit from Obedient Dog?
Instead, we can look at obedience as an aspect that we apply to any type of Dog that is
obedient, as opposed to inappropriately forcing that behaviour in the Dog hierarchy. Insoftware terms, aspect-oriented programming allows us the ability to apply aspects that
alter behavior to classes or objects independent of any inheritance hierarchy. We can then
apply these aspects either during runtime or compile time.
ADVICE
Advice is a way of expressing a cross cutting action that needs to occur. Now that the aspect
has defined the points it should log, it uses advice to accomplish the actual logging. Advice is
code that executes before, after, or around a join point. You define advice relative to a
pointcut, saying something like "run this code after every method call I want to log." Hence
the advice is the action taken by an aspect at a particular join point. Different types of advice
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 14/29
include “around", "before" and "after" advice.
Types of advice:
Before advice: Advice that executes before a join point, but which does not have the ability
to prevent execution flow proceeding to the join point (unless it throws an exception).After returning advice: Advice to be executed after a join point completes normally: for
example, if a method returns without throwing an exception.
After throwing advice: Advice to be executed if a method exits by throwing an exception.
After (finally) advice: Advice to be executed regardless of the means by which a join
point exits (normal or exceptional return).
Around advice: Advice that surrounds a join point such as a method invocation. This is the
most powerful kind of advice. Around advice can perform custom behaviour before and after
the method invocation. It is also responsible for choosing whether to proceed to the join point
or to shortcut the advised method execution by returning its own return value or throwing anexception. Around advice is the most general kind of advice.
JOINPOINT
Join point is a point during the execution of a program, such as the execution of a method or
the handling of an exception. In Spring AOP, a join point always represents a
method execution. Join point information is available in advice bodies by declaring a
parameter of type : aspectJ. lang. JoinPoint.
Joinpoint is the well defined points in code that can be identified. Think of a joinpoint as
a defined point in program flow. A good example of a joinpoint is the following: when
code invokes a method, that point at which that invocation occurs is considered the join point.
The pointcut allows us to specify or define the joinpoints that we wish to intercept in our
program flow. A Pointcut also contains an advice that is to occur when the joinpoint is
reached. So if we define a Pointcut on a particular method being invoked, when the
invocation occurs or the joinpoint is invoked, it is intercepted by the AOP framework and the
pointcut's advice is executed. An advice can be several things, but you should most
commonly think of it as another method to invoke. So when we invoke a method with a
pointcut, our advice to execute would be another method to invoke. This advice or method to
invoke could be on the object whose method was intercepted.
Join point models The advice-related component of an aspect-oriented language defines a join point model
(JPM). A JPM defines three things:
When the advice can run: These are called join points because they are points in a
running program where additional behavior can be usefully joined. A join point needs to
be addressable and understandable by an ordinary programmer to be useful. (It should also
be stable across inconsequential program changes in order for an aspect to be stable
across such changes.) A way to specify (or quantify) join points, called point cuts. Pointcuts
determine whether a given join point matches. Most useful pointcut languages use a syntax
like the base language (e.g., Java signatures are used for AspectJ) and allow reuse throughnaming and combination.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 15/29
A means of specifying code to run at a join point: In AspectJ, this is called advice, and
can run before, after, and around join points.
POINT- CUT
Point- cut is a way of specifying a Joinpoint by some means of configuration or code.
Pointcut is a predicate that matches join points. Advice is associated with a pointcutexpression and runs at any join point matched by the pointcut (for example, the execution of
a method with a certain name). The concept of join points as matched by pointcut expressions
is central to AOP: Spring uses the AspectJ pointcut language by default. The pointcut allows
us to specify or define the joinpoints that we wish to intercept in our program flow. A
Pointcut also contains an advice that is to occur when the joinpoint is reached.
So if we define a Pointcut on a particular method being invoked, when the invocation occurs
or the joinpoint is invoked, it is intercepted by the AOP framework and the pointcut's advice
is executed. An advice can be several things, but you should most commonly think of it as
another method to invoke. So when we invoke a method with a pointcut, our advice toexecute would be another method to invoke. This advice or method to invoke could be on the
object whose method was intercepted.
SOME POINTS
CUT DESIGNATORS
execution - for matching method execution join points, this is the primary
pointcut designator you will use when working with Spring AOP.
within - limits matching to join points within certain types (simply theexecution of a method declared within a matching type when using Spring AOP)
this - limits matching to join points (the execution of methods when using Spring AOP)
where the bean reference (Spring AOP proxy) is an instance of the given type.
target - limits matching to join points (the execution of methods when using Spring AOP)
where the target object (application object being proxied) is an instance of the given type.
args - limits matching to join points (the execution of methods when using Spring AOP)
where the arguments are instances of the given types
target - limits matching to join points (the execution of methods when using Spring AOP)
where the class of the executing object has an annotation of the given type.args - limits matching to join points (the execution of methods when using Spring
AOP) where the runtime type of the actual arguments passed have annotations of the
given type.
annotation - limits matching to join points where the subject of the join point (method being
executed in Spring AOP) has the given annotation.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 16/29
CHAPTER 4
OVERVIEW OF AOP
When Object-Oriented (OO) programming entered the mainstream of software
development, it had a dramatic effect on how software was developed. Developers could
visualize systems as groups of entities and the interaction between those entities, which
allowed them to tackle larger, more complicated systems and develop them in less time than
ever before. The only problem with OO programming is that it is essentially static, and a
change in requirements can have a profound impact on development timelines. Aspect-
Oriented Programming (AOP) complements OO programming by allowing the
developer to dynamically modify the static OO model to create a system that can grow tomeet new requirements. Just as objects in the real world can change their states during their
lifecycles, an application can adopt new characteristics as it develops. Consider an example:
many of you have developed simple web applications that use servlets as the entry point,
where a servlet accepts the values of a HTML form, binds them to an object, passes them into
the application to be processed, and then returns a response to the user. The first cut of the
servlet may be very simple, with only the minimum amount of code required to fulfill the use
case being modeled. The code, however, often inflates to three to four times its original size
by the time secondary requirements such as exception handling, security, and logging have
been implemented. I use the term "secondary requirements" because a servlet shouldnot need to know about the logging or security mechanisms being used; its primary function
is to accept input and process it. AOP allows us to dynamically modify our static model to
include the code required to fulfill the secondary requirements without having to modify the
original static model (in fact, we don't even need to have the original code). Better still, we
can often keep this additional code in a single location rather than having to scatter it across
the existing model, as we would have to if we were using OO on its own. Programs are
decomposed into suitable cross-cutting building blocks, i.e. a building block affects many
parts of the combined program. Building blocks which contain redundant information are
over specified and need to be reduced to a description which removes the overspecification.
The reduced description is expressed in an aspect description language. This leads to a
solution of a more general problem while at the same time removing the redundancy from the
program. The reduced building blocks need to be compiled together into the original or an
improved form of the original program. An important issue is how the reduced descriptions
collaborate. They need to refer to a common vocabulary (join points) so that the compiler can
regenerate the original program. To understand a program, we need to understand the aspects
underlying the program. To avoid manual aspect extrication and to ease evolution, it is better
to express the aspects directly. Evolution is simplified, since changes to aspects are localized
to an aspect description rather than spread out through a program. Aspects should have the
following properties: robust (change to one aspect should have a limited impact on otheraspects), systemic (they affect the target program at many different places), cross-cutting
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 17/29
each other (in the target program information about one aspect is mixed with information
about other aspects), loosely coupled (an aspect should not know the details of other aspects),
contain join points (which are used to combine the aspects).
Join point models The advice-related component of an aspect-oriented language defines a join point model
(JPM). A JPM defines three things:
1. When the advice can run. These are called join points because they are points in a
running program where additional behavior can be usefully joined. A join point needs
to be addressable and understandable by an ordinary programmer to be useful. It
should also be stable across inconsequential program changes in order for an aspect
to be stable across such changes. Many AOP implementations support method
executions and field references as join points.
2. A way to specify (or quantify) join points, called pointcuts. Pointcuts determine
whether a given join point matches. Most useful pointcut languages use a syntax like
the base language (for example, AspectJ uses Java signatures) and allow reuse
through naming and combination.
3. A means of specifying code to run at a join point. AspectJ calls this advice, and can
run it before, after, and around join points. Some implementations also support things
like defining a method in an aspect on another class.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 18/29
CHAPTER 5
ARCHITECTURE OF ASPECT ORIENTED PROGRAMMING
Figure 3
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 19/29
CHAPTER 6
MOTIVATION AND BASIC CONCEPTS
Some code is scattered or tangled, making it harder to understand and maintain. It is scattered
when one concern (like logging) is spread over a number of modules (e.g., classes
and methods). That means to change logging can require modifying all affected modules.
Modules end up tangled with multiple concerns (e.g., account processing, logging, and
security). That means changing one module entails understanding all the tangled concerns.
For example, consider a banking application with a conceptually very simple method
for transferring an amount from one account to another: However, in a real-world banking
application, this transfer method seems far from adequate. It requires security checks toverify that the current user has the authorization to perform this operation. The operation
should be in a database transaction in order to prevent accidental data loss. For diagnostics,
the operation should be logged to the system log. And so on. The code has lost its elegance
and simplicity because the various new concerns have become tangled with the basic
functionality (sometimes called the business logic concern). Transactions, security, and
logging all exemplify cross-cutting concerns. (This particular example may not be the best as
this represents a failure to properly factor classes: a transfer should be its own object.)
Also consider what happens if we suddenly need to change (for example) the
security considerations for the application. In the program's current version, security-related
operations appear scattered across numerous methods, and such a change would require a
major effort. Therefore, we find that the cross-cutting concerns do not get properly
encapsulated in their own modules. This increases the system complexity and makes
evolution considerably more difficult.
AOP attempts to solve this problem by allowing the programmer to express cross-cutting
concerns in stand-alone modules called aspects. Aspects can contain advice (code joined to
specified points in the program) and inter-type declarations (structural members added to
other classes). For example, a security module can include advice that performs a security
check before accessing a bank account. The pointcut defines the times (join points) that a
bank account can be accessed, and the code in the advice body defines how the securitycheck is implemented. That way, both the check and the places can be maintained in one
place. Further, a good pointcut can anticipate later program changes, so if another developer
creates a new method to access the bank account, the advice will apply to the new method
when it executes.
AOP concepts
Let us begin by defining some central AOP concepts. Unfortunately, AOP
terminology is not particularly intuitive; however, it would be even more confusing if spring
used its own terminology.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 20/29
Aspect: A modularization of a concern that cuts across multiple objects. Transaction
management is a good example of a crosscutting concern in J2EE applications. In
Spring AOP, aspects are implemented using regular classes (the schema-based approach) or
regular classes annotated with the Aspect annotation AspectJ style).
Join point: A point during the execution of a program, such as the execution of a
method or the handling of an exception. In Spring AOP, a join point always represents a
method execution. Join point information is available in advice bodiesby declaring a
parameter of type “aspectj.lang.JoinPoint”.
Advice: Action taken by an aspect at a particular join point. Different types of
advice include "around," "before" and "after" advice. Advice types are discussed below.
Many AOP frameworks, including Spring, model an advice as an interceptor, maintaining
a chain of interceptors "around" the join point.
Pointcut: A predicate that matches join points. Advice is associated with a
pointcut expression and runs at any join point matched by the pointcut (for example, the
execution of a method with a certain name). The concept of join points as matched by
pointcut expressions is central to AOP: Spring uses the AspectJ pointcut language by default.
Introduction: (Also known as an inter-type declaration). Declaring additional methods
or fields on behalf of a type. Spring AOP allows you to introduce new interfaces (and
a corresponding implementation) to any proxied object. For example, you could usean introduction to make a bean implement an IsModified interface, to simplify caching.
Target object: Object being advised by one or more aspects. Also referred to as
the advised object. Since Spring AOP is implemented using runtime proxies, this object
will always be a proxied object.
AOP proxy: An object created by the AOP framework in order to implement the
aspect contracts (advise method executions and so on). In the Spring Framework, an AOP
proxy will be a JDK dynamic proxy or a CGLIB proxy. Proxy creation is transparent to users
of the schema-based and AspectJ styles of aspect declaration introduced in Spring 2.0.
Weaving: Linking aspects with other application types or objects to create an advised
object. This can be done at compile time (using the AspectJ compiler, for example),
load time, or at runtime. Spring AOP, like other pure Java AOP frameworks, performs
weaving at runtime.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 21/29
Aspect Weaver
AOP is a new technology for separating crosscutting concerns into single units called aspects.
An aspect is a modular unit of crosscutting implementation. It encapsulates behaviours that
affect multiple classes into reusable modules. With AOP, we start by implementing our
project using our OO language (for example, Java), and then we deal separately with
crosscutting concerns in our code by implementing aspects. Finally, both the code and
aspects are combined into a final executable form using an aspect weaver. As a result, a
single aspect can contribute to the implementation of a number of methods, modules, or
objects, increasing both reusability and maintainability of the code. Figure explains the
weaving process. It should note that the original code doesn't need to know about any
functionality the aspect has added; it needs only to be recompiled without the aspect to regain
the original functionality.
Figure 4
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 22/29
CHAPTER 7
ASPECTJ
Aspect Oriented Programming and Java
AOP is a concept, so it is not bound to a specific programming language. In fact, it can help
with the shortcomings of all languages (not only OO languages) that use single, hierarchical
decomposition. AOP has been implemented in different languages (for example, C++,
Smalltalk, C#, C, and Java).
Of course, the language that gains a great interest of the research community is the Java
language.
The following is a list of tools that support AOP with Java:
AspectJ
Aspect-Werkz
Hyper/J
JAC
JMangler
MixJuice
PROSE
ArchJava
AspectJ, created at Xerox PARC, was proposed as an extension of the Java language for
AOP. Join points, Pointcut, Advice, and Introduction -Where the tools of OOP are
inheritance, encapsulation, and polymorphism, the components of AOP are join points,
pointcut, advice, and introduction. For a better understanding of these new terms,
let's consider the following simple example.
public class TestClass {
public void sayHello () {
System.out.println ("Hello, AOP");
}
public void sayAnyThing (String s) {System.out.println (s); }
public static void main (String[] args) {
sayHello ();
sayAnyThing ("ok");
}
}
Listing 1: TestClass.java
Now, we have our existing Java code in TestClass.java. Let's assume that we want to use
aspects to do the following modifications:
We would like to print a message before and after any call to the TestClass.sayHello()
method.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 23/29
We need to test that the argument of the TestClass.sayAnyThing() method is at least
three characters.
The following list is the AspectJ implementation.
1: public aspect MyAspect {
2: public pointcut sayMethodCall (): call (public void TestClass.say*() );
3: public pointcut sayMethodCallArg (String str):
call (public void TestClass.sayAnyThing (String)) && args(str);
4: before(): sayMethodCall() {
5: System.out.println("\n TestClass." + thisJoinPointStaticPart.getSignature().getName()
+ "start..." );
6: }
7: after(): sayMethodCall() {
8: System.out.println("\n TestClass." + thisJoinPointStaticPart.getSignature().getName() + "
end...");9: }
10: before(String str): sayMethodCallArg(str) {
11: if (str .length() < 3) {
12: System.out.println ("Error: I can't say words less than 3 characters");
13: return;
14: }
15: }
16: }
Listing 2: MyAspect.ajLine 1 defines an aspect in the same way we define a Java class. Like any Java class, an
aspect may have member variables and methods. In addition, it may include pointcuts,
advices, and introductions. In Lines 2 and 3, we specify where in the TestClass code our
modification will take place. In AspectJ terms, we define two pointcuts. To explain what a
pointcut means, we first need to define join points. Join points represent well-defined points
in a program's execution. Typical join points in AspectJ include method/constructor calls,
method/constructor execution, field get and set, exception handler execution, and static and
dynamic initialization. In our example, we have two join points:
the call to TestClass.sayHello and TestClass.sayAnyThing methods.
Pointcut is a language construct that picks out a set of join points based on defined criteria.
The criteria can be explicit function names, or function names specified by wildcards.
public pointcut sayMethodCall ():
call( public void TestClass.say*() );
In the preceding line, we define a pointcut, named sayMethodCall, that picks out any call to
the TestClass.sayHello method. Moreover, it picks out any public TestClass method with
zero arguments and a name that starts with "say" (for example, TestClass.sayBye). Pointcuts
are used in the definition of advice. An advice in AspectJ is used to define additional code to
be executed before, after, or around join points. In our example, Lines 4 and 7 define twoadvices that will be executed before and after the first pointcut. Finally, Lines 10-
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 24/29
15 implement an advice associated with the second pointcut and are used to set a
precondition before the execution of the TestClass.sayAnyThing method.Whereas pointcuts
and advice let you affect the dynamic execution of a program, introduction
allows aspects to modify the static structure of a program. By using introduction, aspects can
add new methods and variables to a class, declare that a class implements an interface, or
convert checked to unchecked exceptions.
AspectJ Compiler
Initially, you have to download the most recent version of AspectJ, available for free at
its official site and install it. Compiling and running our example is very easy. Just write:
ajc MyAspect.aj TestClass.java
java TestClass
You should note that the source code at TestClass.java didn't change. To return to the
original functionality of your program, just use your Java compiler to re-compile it.
Developing with AspectJ Now that you have better sense of what aspect code looks like, let'sturn our attention briefly to the business of writing aspects. In other words, let's answer the
question, "How can I get the above code to work?" For aspects to affect regular class-based
code, the aspects must be woven into the code they modify. To do this using AspectJ, you
must compile your class and aspect code with the ajc compiler. ajc can operate either as a
compiler or a precompiler, generating either valid .class or .java files, which you can then
compile and run in any standard Java environment (with the addition of a small run-time
JAR). To compile with AspectJ, you will need to explicitly specify the source files (both
aspect and class) that you want to include in a given compilation -- ajc does not simply search
your class path for relevant imports the way javac does. This makes sense because each class
in a standard Java application acts as a somewhat isolated component. A class needs only the
presence of classes that it directly references in order to operate correctly. Aspects represent
aggregate behaviours that span multiple classes. Therefore, an AOP program needs to be
compiled as a unit rather than one class at a time. By specifying the files that are included in a
given compilation, you can also plug and unplug various aspects of your system at compile
time. For instance, by including or excluding the logging aspect described earlier from a
compilation, the application builder can add or remove method tracing from the Cactus
framework. An important limitation to the current version of AspectJ is that its compiler can
only weaver aspects into code for which it has the source. In other words, you cannot use ajc
to add advice to precompiled classes. The AspectJ team regards this limitation as temporary,and the AspectJ Web site promises that a future version (officially 2.0) will allow byte code
modification.
Tool support
Several development tools are included as part of AspectJ's release. This bodes well
for AspectJ's future, because it indicates a strong commitment on the part of the authors to
making AspectJ friendly to developers. Tool support is particularly important for an aspect-
oriented system because program modules can be affected by other modules of which they
have no knowledge.
One of the most important tools released with AspectJ is a graphical structure browser
that reveals at a glance how aspects interact with other system components. This structure
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 25/29
browser is available as a plug-in for popular IDEs as well as a stand-alone tool. Other Spring
aspects for AspectJ. In addition to the Configurable support, spring-aspects.jar contains an
AspectJ aspect that can be used to drive Spring's transaction management for types and
methods annotated with the Transactional annotation. This is primarily intended for users
who want to use Spring's transaction support outside of the Spring container. The aspect
that interprets Transactional annotations is the Annotation Transaction Aspect. When usingthis aspect, you must annotate the implementation class (and/or methods within that class),
not the interface (if any) that the class implements. AspectJ follows Java's rule that
annotations on interfaces are not inherited.
A Transactional annotation on a class specifies the default transaction semantics for
the execution of any public operation in the class. A Transactional annotation on a method
within the class overrides the default transaction semantics given by the class annotation (if
present). Methods with public, protected, and default visibility may all be annotated.
Annotating protected and default visibility methods directly are the only way to get
transaction demarcation for the execution of such operations.
Aspect-Oriented Programming in Java
Object oriented programming has become main stream over the last years, having
almost completely replaced the procedural approach. One of the biggest advantages of object
orientation is that a software system can be seen as being built of a collection of discrete
classes. Each of these classes has a well defined task, its responsibilities are clearly defined.
In an OO application, those classes collaborate to achieve the application's overall goal.
However, there are parts of a system that cannot be viewed as being the responsibility of only
one class, they cross-cut the complete system and affect parts of many classes. Examples
might be locking in a distributed application, exception handling, or logging method calls. Of
course, the code that handles these parts can be added to each class separately, but that would
violate the principle that each class has well-defined responsibilities. This is where AOP
comes into play: AOP defines a new program construct, called an aspect, which is used to
capture cross-cutting aspects of a software system in separate program entities. The
application classes keep their well-defined responsibilities. Additionally, each aspect captures
cross-cutting behaviour.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 26/29
CALLING PROCEDURES
Figure 5
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 27/29
CHAPTER 8
COMPARISION TO OTHER PROGRAMMING PARADIGMS
Aspects emerged out of object-oriented programming and computational reflection.
AOP languages have functionality similar to, but more restricted than meta object protocols.Aspects relate closely to programming concepts like subjects, mixins, and delegation. Other
ways to use aspect-oriented programming paradigms include Composition Filters and the
hyperslices approach. Since at least the 1970s, developers have been using forms of
interception and dispatch-patching that are similar to some of the implementation techniques
for AOP, but these never had the semantics that the crosscutting specifications were written
in one place. Designers have considered alternative ways to achieve separation of code, such
as C#'s partial types, but such approaches lack a quantification mechanism that allows
reaching several join points of the code with one declarative statement.
Procedural programming
In procedure oriented programming the main program is divided in to different
and distinct functions and also they are programmed in to separate modules. The
execution can be in a particular sequence. It follows a top- down approach for program
execution. Execution in a given sequence
FORTRAN, C, COBOL
Functional programming
In functional programming the program execution is through different well defined functions.
If any function require any additional task it includes another sub functions. Evaluating afunction Lisp, ML
Logic programming
In logic programming the program execution based on certain logics. Proving a theorem for
Prolog
Object-oriented programming (OOP)
In object- oriented programming all the real world problems are decomposed in to different
entities called objects. Objects are the basic run time entities of a program. Organizing a set
of objects Smalltalk, Java, C++ (to some extent).
Aspect-oriented programming (AOP)
In AOP aspects are run at certain join points specified in the program.
Execution based on certain behaviours AspectJ (a Java extension) Complements OOP
ASPECT ORIENTED. Class code unit that encapsulates methods and attributes. Aspect code
unit that encapsulates Pointcuts, advice, and attributes. Method signatures define the entry
points for the execution of method bodies. Pointcut define the set of entry points (triggers) in
which advice is executed. Method bodies implementations of the primary concerns. Advice
implementations of the cross cutting concerns. Compiler converts source code into objectcode. Weaver instruments code (source or object) with advice.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 28/29
CHAPTER 9
ADVANTAGES AND DISADVANTAGES OF AOP
ADVANTAGES:
The major advantages while using the AOP are follows:
1.) It improves the tractability of the program.
2.) It can be used for developing simpler and cleaner code.
3.) The code can be reusable and therefore reduce the redundancy of code.
4.) It is more easy to maintain than other programming languages.
This advantage of AOP helps the programmers for developing more powerful softwares.
DISADVANTAGES:
Although AOP has several advantages it has some disadvantages.
1.) It is difficult to understand software because of invisibly injected aspects.
2.) It has fragile build problems.
3.) It has a complicated control flow breakage.
4.) There may be a chance for reduce quality of software if aspects are not
appropriately managed.
5/14/2018 Report on Aspect Oriented Programming - slidepdf.com
http://slidepdf.com/reader/full/report-on-aspect-oriented-programming 29/29
CHAPTER 10
CONCLUSION
Programs are decomposed into suitable cross-cutting building blocks, i.e. a building block affects many parts of the combined program. Building blocks which contain redundant
information are overspecified and need to be reduced to a description which removes the
overspecification. The reduced description is expressed in an aspect description language.
This leads to a solution of a more general problem while at the same time removing the
redundancy from the program. The reduced building blocks need to be compiled together into
the original or an improved form of the original program. An important issue is how the
reduced descriptions collaborate. They need to refer to a common vocabulary (join points) so
that the compiler can regenerate the original program."Aspect Oriented Programming",
further, does provide a methodology, or at least as much a one as Object Oriented (which is,admittedly, scattered across such things as closures, classes, prototypes, etc.). If you read into
Aspect Oriented, you'll learn that the methodology consists of:
(a) Identifying from the language the places that modifications may be performed (join
points).
(b) A means of specifying which code to modify or where to add code (pointcuts), a means of
specifying the modification to perform (advice or inter-type declarations depending on
whether the code is 'run' or not).
We got a different approach about programming paradigms which can be essentially used infrequent manner around the world’s best technologies.