Evolution of software programming methodology.

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. Polymorphism provided a common behavior and interface for related concepts, and allowed more specialized components to change a particular behavior 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 ever more complex systems because these techniques permitted us to deal with that complexity. Currently, OOP serves as the methodology of choice for most new software development projects. Indeed, OOP has shown its strength when it comes to modeling common behavior. However, as we will see, and as you may have already experienced, OOP does not adequately address behaviors that span over many often unrelated modules. In contrast, AOP methodology fills this void. AOP quite possibly represents the next big step in the evolution of programming methodologies.

View the system as a set of concerns

We can view a complex software system as a combined implementation of multiple concerns. A typical system may consist of several kinds of concerns, including business logic, performance, data persistence, logging and debugging, authentication, security, multithread safety, error checking, and so on. You'll also encounter development-process concerns, such as comprehensibility, maintainability, traceability, and evolution ease. Figure 1 illustrates a system as a set of concerns implemented by various modules

Crosscutting concerns in a system

A developer creates a system as a response to multiple requirements. We can broadly classify these requirements as core module-level requirements and system-level requirements. Many system-level requirements tend to be orthogonal (mutually independent) to each other and to the module-level requirements. System-level requirements also tend to crosscut many core modules. For example, a typical enterprise application comprises crosscutting concerns such as authentication, logging, resource pooling, administration, performance, and storage management. Each crosscuts several subsystems. For example, a storage-management concern affects every stateful business object.

Let's consider a simple, but more concrete, example. Consider a skeleton implementation of a class encapsulating some business logic:

ublic class SomeBusinessClass extends OtherBusinessClass {
    // Core data members

    // Other data members: Log stream, data-consistency flag

    // Override methods in the base class

    public void performSomeOperation (OperationInformation info) {
        // Ensure authentication

        // Ensure info satisfies contracts

        // Lock the object to ensure data-consistency in case other
        // threads access it

        // Ensure the cache is up to date

        // Log the start of operation

        // ==== Perform the core operation ====

        // Log the completion of operation

        // Unlock the object

        // More operations similar to above

        public void save (PersitanceStorage ps) {
        }

        public void load (PersitanceStorage ps) {
        }

In the code above, we must consider at least three issues. First, other data members do not belong to this class's core concern. Second, implementation of performsomeoperation () seems to do more than perform the core operation; it seems to handle the peripheral logging, authentication, multithread safety, contract validation, and cache management concerns. In addition, many of these peripheral concerns would likewise apply to other classes. Third, it is not clear if save () and load () performing persistence management should form the core part of the class.

Crosscutting concern problems

Although crosscutting concerns span over many modules, current implementation techniques tend to implement these requirements using one-dimensional methodologies, forcing implementation mapping for the requirements along a single dimension. That single dimension tends to be the core module-level implementation. The remaining requirements are tagged along this dominant dimension. In other words, the requirement space is an one-dimensional space, whereas the implementation space is one-dimensional. Such a mismatch results in an awkward requirements-to-implementation map.

Symptoms

A few symptoms can indicate a problematic implementation of crosscutting concerns using current methodologies. We can broadly classify those symptoms into two categories:

* Code tangling: Modules in a software system may simultaneously interact with several requirements. For example, oftentimes developers simultaneously think about business logic, performance, synchronization, logging, and security. Such a multitude of requirements results in the simultaneous presence of elements from each concern's implementation, resulting in code tangling.

* Code scattering. Since crosscutting concerns, by definition, spread over many modules, related implementations also spread over all those modules. For example, in a system using a database, performance concerns may affect all the modules accessing the database.

Implications

Combined, code tangling and code scattering affect software design and developments in many ways:

* Poor traceability: Simultaneously implementing several concerns obscures the correspondence between a concern and its implementation, resulting in a poor mapping between the two.

* Lower productivity. Simultaneous implementation of multiple concerns shifts the developer's focus from the main concern to the peripheral concerns, leading to lower productivity.

* Less code reuse: Since, under these circumstances, a module implements multiple concerns, other systems requiring similar functionality may not be able to readily use the module, further lowering productivity.

* Poor code quality: Code tangling produces code with hidden problems. Moreover, by targeting too many concerns at once, one or more of those concerns will not receive enough attention.

* More difficult evolution: A limited view and constrained resources often produce a design that addresses only current concerns. Addressing future requirements often requires reworking the implementation. Since the implementation is not modularized, that means touching many modules. Modifying each subsystem for such changes can lead to inconsistencies. It also requires considerable testing effort to ensure that such implementation changes have not caused bugs.

The current response

Since most systems include crosscutting concerns, it's no surprise that a few techniques have emerged to modularize their implementation. Such techniques include mix-in classes, design patterns, and domain- specific solutions. With mix-in classes, for example, you can defer a concern's final implementation. The primary class contains a mix-in class instance and allows the system's other parts to set that instance. For example, in a credit card processing example, the class implementing business logic composes a logger mix-in. Another part of the system could set this logger to get the appropriate logging type. For example, the logger could be set to log using a filesystem or messaging middleware. Although the nature of logging is now deferred, the composer nevertheless contains code to invoke logging operations at all log points and controls the logging information.

Behavioral design patterns, like Visitor and Template Method, let you defer implementation. However, just as in case with mix-ins, the control of the operation -- invoking visiting logic or invoking template methods -- stays with the main classes.

Domain-specific solutions, such as frameworks and application servers, let developers address some crosscutting concerns in a modularized way. The Enterprise Javabeans (FJB) architecture, for example, addresses crosscutting concerns such as security, administration, performance, and container-managed persistence. Bean developers focus on the business logic, while the deployment developers focus on deployment issues, such as bean-data mapping to a database. The bean developer remains, for the most part, oblivious to the storage issues. In this case, you implement the crosscutting concern of persistence using an XML-based mapping descriptor.

The domain-specific solution offers a specialized mechanism for solving the specific problem. As a downside to domain-specific solutions, developers must learn new techniques for each such solution. Further, because these solutions are domain specific, the crosscutting concerns not directly addressed require an ad hoc response.

The architect's dilemma

Good system architecture considers present and future requirements to avoid a patchy-looking implementation. Therein lies a problem, however. Predicting the future is a difficult task. If you miss future crosscutting requirements, you'll need to change, or possibly reimplement, many parts of the system. On the other hand, focusing too much on low-probability requirements can lead to an overdesigned, confusing, difficult task. If you miss future crosscutting requirements, you'll need to change, or possibly reimplement, many parts of the system. On the other hand, focusing too much on low-probability requirements can lead to an overdesigned, confusing, bloated system. Thus a dilemma for system architects: How much design is too much? Should I lean towards underdesign or overdesign? For example, should an architect include a logging mechanism in a system that does not initially need it? If so, where should the logging points be, and what information should be logged? A similar dilemma occurs for optimization-related requirements -- with performance, we seldom know the bottlenecks in advance. The usual approach is to build the system, profile it, and retrofit it with optimization to improve the performance. This approach requires potentially changing many system parts indicated by profiling. Further, over time, new bottlenecks may appear due to changed usage patterns. The reusable library architect's task is even more difficult because he finds it harder to imagine all the usage scenarios for the library. In summary, the architect seldom knows every possible concern the system may need to address. Even for requirements known beforehand, the specifics needed to create an implementation may not be fully available. Architecture thus faces the under/overdesign dilemma.

The fundamentals of AOP

The discussion so far suggests that it can be helpful to modularize the implementation of crosscutting concerns. Researchers have studied various ways to accomplish that task under the more general topic of "separation of concerns." AOP represents one such method. AOP strives to cleanly separate concerns to overcome the problems discussed above.

AOP, at its core, lets you implement individual concerns in a loosely coupled fashion, and combine these implementations to form the final system. Indeed, AOP creates systems using loosely coupled, modularized implementations of crosscutting concerns. OOP, in contrast, creates systems using loosely coupled, modularized implementations of common concerns. The modularization unit in AOP is called an aspect, just as a common concern's implementation in OOP is called a class.

AOP involves three distinct development steps:

1. Aspectual decomposition: Decompose the requirements to identify crosscutting and common concerns. You separate module-level concerns from crosscutting system-level concerns. For example, in the aforementioned credit card module example, you would identify three concerns: core credit card processing, logging, and authentication.

2. Concern implementation: Implement each concern separately. For the credit card processing example, you'd implement the core credit card processing unit, logging unit, and authentication unit.

3. Aspectual recomposition: In this step, an aspect integrator specifies recomposition rules by creating modularization units -- aspects. The recomposition process, also known as weaving or integrating, uses this information to compose the final system. For the credit card processing example, you'd specify, in a language provided by the AOP implementation, that each operation's start and completion be logged. You would also specify that each operation must clear authentication before it proceeds with the business logic.

AOP differs most from OOP in the way it addresses crosscutting concerns. With AOP, each concern's implementation remains unaware that other concerns are "aspecting" it. For example, the credit card processing module doesn't know that the other concerns are logging or authenticating its operations. That represents a powerful paradigm shift from OOP.

Note- An AOP implementation can employ another programming methodology as its base methodology, thus keeping the base system's benefits intact. For example, an AOP implementation could choose OOP as the base system to pass on benefits of better implementation of common concerns with OOP. With such an implementation, individual concerns could employ OOP techniques for each identified concern. That is analogous to a procedural language acting as the base language for many OOP languages.

Weaving example

The weaver, a processor, assembles an individual concern in a process known as weaving. The weaver, in other words, interfaces different execution-logic fragments according to some criteria supplied to it.

To illustrate code weaving, let's return to our credit card processing system example. For brevity, consider only two operations: credit and debit. Also assume that a suitable logger is available.

Consider the following credit card processing module:

ublic class CreditCardProcessor {
    public void debit (CreditCard card, Currency amount)
       throws InvalidCardException, NotEnoughAmountException,
              CardExpiredException {
        // Debiting logic
    }

    public void credit (CreditCard card, Currency amount)
        throws InvalidCardException {
        // Crediting logic
    }
}

Also, consider the following logging interface:

ublic interface Logger {
    public void log (String message);

The desired composition requires the following weaving rules, expressed here in natural language (a programming language version of these weaving rules is provided later in this article):

1. Log each public operation's beginning

2. Log each public operation's completion

3. Log any exception thrown by each public operation

The weaver would then use these weaving rules and concern implementations to produce the equivalent of the following composed code:

ublic class CreditCardProcessorWithLogging {
    Logger_logger;
   public void debit (CreditCard card, Money amount)
        throws InvalidCardException, NotEnoughAmountException,
               CardExpiredException {
        _logger.log ("Starting CreditCardProcessor.credit (CreditCard,
Money) "

                    + "Card: " + card + " Amount: " + amount);
        // Debiting logic
        _logger.log ("Completing CreditCardProcessor.credit (CreditCard,
Money) "

                    + "Card: " + card + " Amount: " + amount);
    }

    public void credit (CreditCard card, Money amount)
        throws InvalidCardException {
        System.out.println ("Debiting");
        _logger.log ("Starting CreditCardProcessor.debit (CreditCard,
Money) "

                    + "Card: " + card + " Amount: " + amount);
        // Crediting logic
        _logger.log ("Completing CreditCardProcessor.credit (CreditCard,
Money) "

                    + "Card: " + card + " Amount: " + amount);

Anatomy of AOP languages

Just like any other programming methodology implementation, an AOP implementation consists of two parts: a language specification and an implementation. The language specification describes language constructs and syntax. The language implementation verifies the code's correctness according to the language specification and converts it into a form that the target machine can execute. In this section, I explain the parts and pieces of an aspect-oriented language.

The AOP language specification

At a higher level, an AOP language specifies two components:

* Implementation of concerns: Mapping an individual requirement into code so that a compiler can translate it into executable code. Since implementation of concerns takes the form of specifying procedures, you can to use traditional languages like C, C++, or Java with AOP.

* Weaving rules specification: How to compose independently implemented concerns to form the final system. For this purpose, an implementation needs to use or create a language for specifying rules for composing different implementation pieces to form the final system. The language for specifying weaving rules could be an extension of the implementation language, or something entirely different.

AOP language implementation

AOP language compilers perform two logical steps:

1. Combine the individual concerns

2. Convert the resulting information into executable code

An AOP implementation can implement the weaver in various ways, including source-to-source translation. Here, you preprocess source code for individual aspects to produce weaved source code. The AOP compiler then feeds this converted code to the base language compiler to produce final executable code. For instance, using this approach, a Java-based AOP byte code level; after all, byte code is still a kind of source code. Moreover, the underlying execution system -- a VM implementation, say -- could be aspect aware. Using this approach for Java-based AOP implementation, for example, the VM would load weaving rules first, then apply those rules to subsequently loaded classes. In other words, it could perform just-in-time aspect weaving.

AOP benefits

AOP helps overcome the aforementioned problems caused by code tangling and code scattering. Here are other specific benefits AOP offers:

* Modularized implementation of crosscutting concerns: AOP addresses each concern separately with minimal coupling, resulting in modularized implementations even in the presence of crosscutting concerns. Such an implementation produces a system with less duplicated code. Since each concern's implementation is separate, it also helps reduce code clutter. Further, modularized implementation also results in a system that is easier to understand and maintain. code. Since each concern's implementation is separate, it also helps reduce code clutter. Further, modularized implementation also results in a system

* Easleir-to-evolve systems: Since the aspected modules can be unaware of crosscutting concerns, it's easy to add newer functionality by creating new aspects. Further, when you add new modules to a system, the existing aspects crosscut them, helping create a coherent evolution.

* Late binding of design decisions: Recall the architect's under/overdesign dilemma. With AOP, an architect can delay making design decisions for future requirements, since she can implement those as separate aspects.

* More code reuse: Because AOP implements each aspect as a separate module, each individual module is more loosely coupled. For example, you can use a module interacting with a database in a separate logger aspect with a different logging requirement. In general, a loosely coupled implementation represents the key to higher code reuse. AOP enables more loosely coupled implementations than OOP.

* More code reuse: Because AOP implements each aspect as a separate module, each individual module is more loosely coupled. For example, you can use a module interacting with a database in a separate logger aspect with a different logging requirement. In general, a loosely coupled implementation represents the key to higher code reuse. AOP enables more loosely coupled implementations than OOP.

Page 10 of II

Do I need AOP?

Does AOP merely address design shortcomings? In AOP, the each concern's implementation is oblivious to the fact that it is being aspected by other concerns. This obliviousness sets AOP apart from OOP techniques. In AOP, the flow of composition runs from crosscutting concerns to the main concern, whereas in OOP techniques the flow runs in the opposite direction. Note, however, that OOP and AOP can merrily coexist. For example, you could employ a mix-in class as a composition using either AOP or OOP, depending upon your AOP comfort level. In either case, the mix-in class implementing a crosscutting concern doesn't need to know whether it is a mix-in class using hand composition or a part of an aspect using rule-based composition. For example, you could use a logger interface as a mix-in for some classes or as a logging aspect for others. Thus, there's an evolutionary path from OOP to AOP.