Aspect-Oriented Software Development
spect-oriented software development (AOSD) is an emerging software development technology that seeks new modularizations of software systems. AOSD allows multiple concerns to be expressed separately and automatically unified into working systems.
Traditional software development has focused on decomposing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. The traditional development process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. These concerns span across the primary functional units within the application, and often results in serious problems faced during the application development and maintenance. The distribution of the code for realizing a concern becomes especially critical as the requirements for that concern evolve - a system maintainer must find and correctly update a variety of situations.
Aspect-Oriented Software Development focuses on the identification, specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system.
Aspect-Oriented Software Development technology started with Aspect-Oriented Programming (AOP) languages. The term AOP was introduced by Gregor Kiczales and his team at Xerox Palo Alto Research Center through a paper published in the proceedings of the European Conference on Object Oriented Programming in June 1997. The team also developed a popular AOP language called AspectJ which has gained a lot of acceptance and popularity from the Java developer community. AOP concepts appeared as well in earlier research on software modularization, such as Composition Filters, developed at the University of Twente in the Netherlands, Adaptive Programming at NorthEastern University, USA and Subject-Oriented Programming (later evolved to Multidimensional Separation of Concerns) at IBM.
Currently, several aspect-oriented programming languages are available for a variety of languages and platforms.
Just as object-oriented programming led to the development of a large class of object-oriented development methodologies, AOP has encouraged a nascent set of software engineering technologies, include methodologies for dealing with aspects, modeling techniques (often based on the ideas of the Unified Modeling Language, UML), and testing technology for assessing the effectiveness of aspect approaches. AOSD now refers to a wide range of software development techniques that support the modularization of crosscutting concerns in a software system, from requirement engineering to analysis and design, architecture, programming and implementation techniques, testing and software maintenance techniques.
Aspect-oriented software development has constantly gained in popularity, and is the subject of an annual conference, the International Conference on Aspect-Oriented Software Development, held for the first in 2002 in Enschede, The Netherlands. AOSD is a rapidly evolving area. It is a popular topic of Software Engineering research, especially in Europe, where research activities on AOSD are coordinated by the European Network of Excellence on Aspect-Oriented Software Development (AOSD-Europe), funded by the European Commission.
The motivation for aspect-oriented programming languages stem from the problems caused by code scattering and tangling. The purpose of Aspect-Oriented Software Development is to provide systematic means to modularize crosscutting concerns.
The implementation of a concern is scattered if its code is spread out over multiple modules. The concern affects the implementation of multiple modules. Its implementation is not modular.
The implementation of a concern is tangled if its code is intermixed with code that implements other concerns. The module in which tangling occurs is not cohesive.
Scattering and tangling often go together, even though they are different concepts.
Aspect-oriented software development considers that code scattering and tangling are the symptoms of crosscutting concerns. Crosscutting concerns can not be modularized using the decomposition mechanisms of the language (object or procedures) because they inherently follow different decomposition rules. The implementation and integration of these concerns with the primary functional decomposition of the system causes code tangling and scattering.
Problems Caused by Scattering and Tangling
Scattering and tangling of behavior are the symptoms that the implementation of a concern is not well modularized. A concern that is not modularized does not exhibit a well defined interface. The interactions between the implementation of the concern and the modules of the system are not explicitly declared. They are encoded implicitly through the dependencies and interactions between fragments of code that implement the concern and the implementation of other modules.
The lack of interfaces between the implementation of crosscutting concerns and the implementation of the modules of the system impedes the development, the evolution and the maintenance of the system.
A module is primarily a unit of independent development. It can be implemented to a large extent independently of other modules. Modularity is achieved through the definition of well defined interfaces between segments of the system.
The lack of explicit interfaces between crosscutting concerns and the modules obtained through the functional decomposition of the system imply that the implementation of these concerns, as well as the responsibility with respect to the correct implementation of these concerns, cannot be assigned to independent development teams. This responsibility has to be shared among different developers that work on the implementation of different modules of the system and have to integrate the crosscutting concern with the module behavior.
Furthermore, modules whose implementation is tangled with crosscutting concerns are hard to reuse in different contexts. Crosscutting impedes reuse of components. The lack of interfaces between crosscutting concerns and other modules makes it hard to represent and reason about the overall architecture of a system. As the concern is not modularized, the interactions between the concern and the top-level components of the system are hard to represent explicitly. Hence, these concerns become hard to reason about because the dependencies between crosscutting concerns and components are not specified.
Finally, concerns that are not modularized are hard to test in isolation. The dependencies of the concern with respect to behavior of other modules are not declared explicitly. Hence, the implementation of unit test for such concerns requires knowledge about the implementation of many modules in the system.
System Maintenance and Evolution
The lack of support for the modular implementation of crosscutting concerns is especially problematic when the implementation of this concern needs to be modified. The comprehension of the implementation of a crosscutting concern requires the inspection of the implementation of all the modules with which it interacts. Hence, modifications of the system that affect the implementation of crosscutting concern require a manual inspection of all the locations in the code that are relevant to the crosscutting concern. The system maintainer must find and correctly update a variety of poorly identified situations.
Aspect-Oriented Software Development
The Nature of Aspect-Orientation
The focus of Aspect-Oriented Software Development (AOSD) is in the investigation and implementation of new types of software modularity that provide support for explicit abstractions to modularize crosscutting concerns. Aspect-Oriented Programming languages provide explicit abstractions for the modular implementation of crosscutting concerns in code, called aspects, and a mechanism to automatically compose aspects with the base code.
The best known definition of the nature of AOSD is due to Filman and Friedman, which characterized AOSD using the equation aspect orientation = quantification + obliviousness.
AOP can be understood as the desire to make quantified statements about the behavior of programs, and to have these quantifications hold over programs written by oblivious programmers.
AOP is the desire to make statements of the form: In program P, whenever condition C arises, perform action A over a conventionally coded program.
Obliviousness implies that a program has no knowledge of which aspects modify it where or when, whereas quantification refers to the ability of aspects to affect multiple points in the program.
The notion of non-invasiveness is often preferred to the term obliviousness. Non-invasiveness expresses that aspects can add behavior to a program without having to perform changes in that program, yet it does not assume that programs are not aware of the aspects.
Filman's definition of aspect-orientation is often considered too restrictive . Many aspect-oriented approaches use annotations to explicitly declare the locations in the system where aspects introduce behavior. These approaches require the manual inspection and modification of other modules in the system and are therefore invasive. Furthermore, aspect-orientation does not necessarily require quantification. Aspects can be used to isolate features whose implementation would otherwise be tangled with other features. Such aspects do not necessarily use quantification over multiple locations in the system.
The essential features of Aspect-Oriented Software Development are therefore better characterized in terms of the modularity of the implementation of crosscutting concerns, the abstractions provided by aspect-oriented languages to enable modularization and the expressiveness of the aspect-oriented composition operators.