Aspect Oriented Programming AOP

1
Aspect Oriented Programming(AOP)

• Vijaya L Uppala
• 10/14/2003

2
Problem

• Neither procedural nor object-oriented
  programming techniques are sufficient to clearly
  capture some of the important design decisions
  the program must implement. This forces the
  implementation of those design decisions to be
  scattered throughout the code, resulting in
  tangled code that is excessively difficult to
  develop and maintain. Certain design decisions
  have been so difficult to clearly capture in
  actual code.

3
Solution

• We call the properties these decisions address
  aspects.
• Aspect oriented programming, is a new programming
  technique, that makes it possible to clearly
  express programs involving such aspects,
  including appropriate isolation, composition and
  reuse of the aspect code.

4
AOP

• Aspect-Oriented Programming (AOP) is a paradigm,
  which enables separation of concerns, and
  provides a clean way of encapsulating
  crosscutting concerns. The rationale behind AOP
  is that computer systems are better programmed by
  separately specifying and implementing the
  various concerns of the system and some
  description of their relationships. The
  mechanisms in the underlying AOP environment are
  responsible for weaving or composing the
  different concerns into a coherent program.

5
Concerns

• Concerns can range from
• High level notions like security and quality of
  service to low-level notions such as logging,
  caching, buffering and so on.
• They can be functional, like features or business
  rules, or nonfunctional, such as synchronization
  and transaction management.

6
Crosscutting Concerns

• With conventional programming languages, there
  are certain concerns that are very hard to
  encapsulate in a single programming language
  entity (e.g., a class or function).
• These concerns are known as crosscutting
  concerns. Crosscutting concerns make programs
  harder to read, maintain, understand, and reuse.
• AOP focuses on mechanisms that enable clean
  modularization of crosscutting concerns.

7
Generalized Procedure (GP)

• Many existing programming languages, including
  object-oriented languages, procedural languages
  and functional languages, can be seen as having a
  common root in that their key abstraction and
  composition mechanisms are all rooted in some
  form of generalized procedure.
• These are referred as generalized-procedure (GP)
  languages.
• The design methods that have evolved to work with
  GP languages tend to break systems down into
  units of behavior or function. This style has
  been called functional decomposition

8
Putting together..

• Components are properties of a system, for which
  the implementation can be cleanly encapsulated in
  a generalized procedure.
• Aspects are properties for which the
  implementation cannot be cleanly encapsulated in
  a generalized procedure. Aspects and cross-cut
  components cross-cut each other in a systems
  implementation.
• Aspect-oriented programming technology supports
  clean abstraction and composition of both
  components and aspects.
• The key difference between AOP and other
  approaches is that AOP provides component and
  aspect languages with different abstraction and
  composition mechanisms. A special language
  processor called an aspect weaver is used to
  coordinate the co-composition of the aspects and
  components.

9
Example of How Aspects Cross-Cut Components

• Using AOP the functionality of tracing can be
  treated as a concern and factored out of existing
  code. Tracing serves a common purpose in the
  application but crosscuts multiple classes.
  Therefore, using AOP, the tracing code can be
  factored out from all the classes into an aspect.
  The locations in the application code from where
  the tracing code is factored out are known as
  join-points.
• Once the tracing code has been factored out, all
  the join-points are declared in a file using a
  special notation. A tool such as AspectJ is then
  used to weave the aspect code that is the tracing
  code, at the join-points. However, the actual
  application code stays independent of any tracing
  code. Thus there is a clear separation of
  application logic and crosscutting concerns such
  as tracing.

10
Other Examples of How Aspects Cross-Cut Components
11
Detailed Example

• The example comes from the document processing
  domain where we wanted to implement a distributed
  digital library that stores documents in many
  forms and provides a wide range of operations on
  those documents.
• The functionality of this system is well captured
  using an object-oriented model. In such an
  approach the objects are documents, repositories,
  different printable forms for the documents (pdf,
  ps, rip ), printers, servers etc.

12
Detailed Example

• There are several aspects of concern, including
• Communication, by which we mean controlling the
  amount of network bandwith the application uses
  by being careful about which objects and
  sub-objects get copied in remote method calls.
• Coordination constraints, by which we mean the
  synchronization rules required to ensure that the
  component program behaves correctly in the face
  of multiple threads of control.
• Failure handling, by which we mean handling the
  many different forms of failure that can arise in
  a distributed system in an appropriately
  context-sensitive way.
• For now, we will continue with just the
  communication aspect.

13
Detailed Example

• The Component Language Program
• Designing an AOP system involves understanding
  what must go into the component language, what
  must go into the aspect languages, and what must
  be shared among the languages. The component
  language must allow the programmer to write
  component programs that implement the systems
  functionality, while at the same time ensuring
  that those programs dont pre-empt anything the
  aspect programs need to control. The aspect
  languages must support implementation of the
  desired aspects, in a natural and concise way.
  The component and aspect languages will have
  different abstraction and composition mechanisms,
  but they must also have some common terms, these
  are what makes it possible for the weaver to
  co-compose the different kinds of programs.

14
Detailed Example

• The Component Language Program
• In this example, component programs must
  implement elements such as books, repositories,
  and printers. In order to allow the communication
  aspect program to handle communication, component
  programs must avoid doing so.
• In this case Java serves quite well as the
  component language. It provides an object model
  that implements the appropriate components, and
  avoids addressing the communication aspect.
• So, using Java as the component language, the
  definition of two simple classes, books and
  repositories of books, look like

15
Detailed Example

• The Component Language Program

16
Detailed Example

• The Aspect Language Program
• Communication aspect programs would like to be
  able to control the amount of copying of
  arguments that takes place when there is a remote
  method invocation.
• To do this, the aspect language must effectively
  allow them to step into the implementation of
  method invocation, to detect whether it is local
  or remote, and to implement the appropriate
  amount of copying in each case.

17
Detailed Example

• The Aspect Language Program
• Using this language, the following fragment of
  the communication aspect program says that when
  books are registered with a repository, all of
  their sub-objects should be copied when they are
  de-registered or returned as the result of a
  lookup, only the ISBN number is copied. The rest
  of the book, including large sub-objects such as
  the printable representations, is not copied
  unless it is needed at some later time.
• remote Repository
• void register (Book)
• void unregister (Book copy isbn)
• Book copy isbn lookup(String)

18
Detailed Example

• Aspect Weaver
• Aspect weavers must process the component and
  aspect languages, cocomposing them properly to
  produce the desired total system operation.
  Essential to the function of the aspect weaver is
  the concept of join points, which are those
  elements of the component language semantics that
  the aspect programs coordinate with.
• In the digital library example, the join-point
  representation includes information about dynamic
  method invocations such as the concrete classes
  of the arguments and their location. The join
  point representation can be generated at runtime
  using a reflective runtime for the component
  language.

19
COMBINING AOP AND XP

• While XP is a methodology affecting overall
  software design and development, AOP is a
  technique aimed at separating and implementing
  crosscutting concerns. Therefore, although at
  first glance the two may not appear to have much
  in common, they do share a well defined
  intersection where AOP can influence the way XP
  is done.

20
Effect of AOP on XP Values

• Simplicity is improved with respect to the
  structure of the application code. Crosscutting
  concerns are untangled into aspects, which makes
  the code simpler to understand.
• Communication Since an aspect addresses
  crosscutting concerns, it can serve as an
  excellent source of documentation. In fact, using
  AOP can enhance communication and understanding
  of the code among developers.
• AOP has no effect on the following XP values
  Courage and Feedback.

21
Effect of AOP on XP Practices

• Simple Design AOP leads to simple design by
  incorporating separation of concerns. The
  increased modularity of the code makes it easier
  to enhance the software and make modifications.
• Collective Ownership Aspects help reduce the
  need for collective code ownership. This is
  because using aspects helps separate tangled code
  and thus allows a more refined separation of
  responsibilities of programmers. However, even
  with such a separation of responsibilities, the
  need for collective ownership cannot be totally
  eliminated.
• Refactoring AOP can supplement tedious
  refactorings since AOP can add functionality that
  the original code is not prepared to do so

22
Effect of AOP on XP Practices

• Testing AOP supports testing in many ways such
  as by providing support for factoring out test
  code that is commonly glued to the application
  code. This can reduce the footprint and
  likelihood of unused code (dead code) causing any
  problems at run-time. AOP can also be used for
  specialized test cases and spike tests as well as
  to develop test cases that include combining
  multiple test cases.
• Small Releases The differences between small
  releases can be viewed as a set of aspects
• Continuous Integration AOP can make continuous
  integration more difficult since with AOP it is
  necessary to determine which aspects to weave in
  and which not for every integration step.
  Nevertheless, AOP can be used for providing a
  flexible means of integrating configurable
  behavior.

23
Effect of AOP on XP Practices

• Coding Standards Because XP has no explicit
  design or architecture phase, it is important
  that implementation choices, that have a critical
  impact on the quality of the software, get
  coordinated by coding standards.
• AOP has no effect on the following XP practices
  Pair Programming, Planning Game, Metaphor and
  On-Site Customer.

24
Recommendations to developersfor introduce AOP
in their systems that use anXP methodology.

• Knowledge of developers Since AOP affects all
  parts of a system it requires most, if not all,
  developers to be knowledgeable of AOP. This in
  turn requires that the developers be willing to
  adopt a new paradigm and educate themselves on
  how to use both AOP and XP effectively.
• Extensive use of AOP AOP can be beneficial, but
  only if it is used in the entire software. Using
  AOP for only single tasks, such as testing, or
  implementing a single feature, will lead to
  additional overhead. The more AOP is used in a
  project, the more it will be worth investing the
  initial learning overhead.

25
Recommendations to developersfor introduce AOP
in their systems that use anXP methodology.

• Using right tools If AOP is used to encapsulate
  crosscutting concerns into aspects, it becomes
  essential to use the right visualization tool to
  view how and where the aspects influence the base
  code. Therefore, it is important that the right
  set of tools is available to help the developers
  integrate AOP with XP.
• Awareness of changes AOP influences many XP
  values, practices and principles. It is therefore
  necessary that developers be aware of all the
  changes that are introduced into the system as a
  result of using AOP. In particular, since AOP can
  result in crosscutting changes that affect a
  large part of the system, each change can in
  reality affect several developers working on the
  system.

26
Open Issues

• How much does it help in the development of
  real-world applications?
• How much does it help with maintenance?
• Can we develop measures of which applications it
  will be more or less useful for?
• It is important to begin a systematic study to
  find existing
• systems that have AOP-like elements in their
  design.
• Exploring the space of different kinds of
  component and aspect language designs.
• Another important area of exploration is the
  integration of AOP with existing approaches,
  methods, tools and development processes.

27
Conclusion

• The AOP conceptual framework helps to design the
  systems, and the AOP-based implementations have
  proven to be easier to develop and maintain,
  while being comparably efficient to much more
  complex code written using traditional
  techniques.
• AOP provides a programmatic and encapsulated way
  of expressing crosscutting concerns that is
  usually missing in OO languages. It can therefore
  complement XP methodology giving developers a
  powerful tool to take advantage of.
• Using AOP benefits many values, practices, and
  principles of XP.
• However, there are some areas where combining AOP
  and XP requires careful thought and planning.