Aspect-oriented software development

Aspect-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.

History

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 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 computer science research, especially in Europe, where research activities on AOSD are coordinated by the [http://www.aosd-europe.net/ European Network of Excellence on Aspect-Oriented Software Development] (AOSD-Europe), funded by the European Commission.

Motivation

Crosscutting Concerns

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.

Example 1: Logging in Apache Tomcat

Figure 1 illustrates a decomposition into classes of the Apache Tomcat web container. The vertical bars in the diagram correspond to different packages in the Tomcat distribution. The length of these bars corresponds to the size of the code of these packages. In Figure 1, the code that corresponds to the classloading concern of the application have been highlighted in red. Classloading in Tomcat is a modular concern with respect to the system decomposition. Its implementation is contained in a small number of classes and is not intertwined with the implementation of other concerns.

Figure 2 represents the implementation of the logging concern in Tomcat. Logging in Tomcat is a crosscutting concern. Its implementation spreads over many classes and packages and is intermixed with the implementation of many other concerns.

Example 2: Coordination of Components

Figure 3 represents the UML architecture diagram of a telecom component. Each box corresponds to a process that communicates with other processes through connectors.

Figure 4 illustrates the impact of a coordination concern on the architecture of the system, such as "When the system starts up, all parts must initialize successfully, otherwise the system must shutdown".

The highlighted box corresponds to a coordinator process. This concern has an inpact on the implementation of each process in the diagram. Its implementation crosscuts the implementation of the other processes.

Examples of Crosscutting Concerns

Examples of concerns that tend to be crosscutting include:

* Synchronization
* Real-time constraints
* Error-checking
* Object interaction constraints
* Memory management
* Persistency
* Security
* Caching
* Logging
* Monitoring
* Business Rules
* Mobility
* Domain specific optimizations

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.

ystem Development

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.

ystem 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 code base.

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 P ..

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.

Concepts and Terminology

Aspect-Oriented languages provide explicit support for localizing crosscutting concerns into separated modules, called aspects. An Aspect is a module that encapsulate a crosscutting concern.Most aspect-oriented languages support the non-invasive introduction of behavior into a code base and quantification over points in the program where this behavior should be introduced.These points are called join points.

Join point model

Join points are points in the runtime execution of the system, such as method calls, where aspects inject behavior through advice bodies. A join point is a point in the execution of the program, which is used to define the dynamic structure of a crosscutting concern.

The join point model of an aspect-oriented language defines the types of join points that are supported by the aspect-oriented language and the possible interaction points between aspects and base modules.

Since join points are dynamic, it may be possible to expose runtime information such as the caller or callee of a method from a join point to a matching pointcut. Nowadays, there are various join point models around and still new under development. They heavily depend on the underlying programming language and AO language.

Examples of join points are
* method execution
* method call
* field read and write access
* exception handler execution
* static and dynamic initialization

A method call join point covers the actions of an object receiving a method call. It includes all the actions that compose a method call, starting after all arguments are evaluated up to return.

Many AOP languages implement aspect behavior by weaving hooks into join point shadows, which is the static projection of a join point onto the program code.

Figure 5 illustrates possible join points in the execution of a small object-oriented program. The highlighted join points include the execution of method "moveBy(int, int)" on a "Line" object, the calls to methods "moveBy(int, int)" on the "Point" objects in the context of the "Line" object, the execution of these methods in the context of the "Point" objects and the calls and execution of the "setX(int)" and "setY(int)" methods.

Pointcut Designators

The quantification over join points is expressed at the language level, using a construct named a pointcut. Pointcuts are defined as a predicate over the syntax-tree of the core program, and define an interface that constrains which elements of the core program are exposed by the pointcut. A pointcut picks out certain join points and values at those points. A pointcut can be composed out of other pointcuts using the AND, OR and NOT composition operators.Pointcut expressions can concisely capture a wide range of events of interests, using wildcards. For example, in AspectJ syntax, the move pointcut

"pointcut move: call(public * Figure.* (..))"

picks out each call to Figure's public methods.

cflow poincuts identify join points based on whether they occur in the dynamic context of other join points. For example, in AspectJ syntax "cflow(move())" picks out each join point that occurs in the dynamic context of the join points picked out by the move pointcut.

Pointcuts can be classified in two categories:
* Kinded pointcuts, such as the call pointcut, match one kind of join point using a signature.
* Non-kinded pointcuts, such as the cflow pointcut match all kinds of join points using a variety of properties.

Advice Bodies

An advice body is code that is executed when a join point is reached. Advice modularize the functional details of a concern. There exist different kinds of advice.
* Before advice run as a join point is reached, before the program proceeds with the join point
* After advice run after the program proceeds with that join point. When the join point corresponds to the execution of a method an after advice can be executed after the method returned or after raising an exception
* Around advice run as the join point is reached, and have explicit control over whether the program executes the join point. Around advice can modify the control flow of the program

When the execution of a join point triggers a pointcut expression, the advice bound to the pointcut is executed. The advice can interact with the rest system through the join point instance which contains reflective information on the context of the event that triggered the advice, such as the arguments of a method call or the target instance of a call.

Inter-type Declarations

Inter-type declarations allow the programmer to modify a program's static structure, such as class members and classes hierarchy. New members can be inserted and classes can be pushed down the class hierarchy.

Aspects

An Aspect is a module that encapsulate a crosscutting concern. An aspect is composed of pointcuts, advice bodies and inter-type declarations.

Aspect Weaving

Aspect weaving is a composition mechanism that coordinates aspects with the other modules of the system. It is performed by a specialized compiler, called a weaver.

Example

Figure 6 illustrates a classic example of a crosscutting concern in a figure editor example taken from the AOSD literature.The example describes an abstract Shape class that can be moved in the editor.Whenever a shaped is moved, the display needs to be refreshed. Figure 6 also depicts two Shape subclasses, Line and Point that implement the Shape functionality. The display refresh concern is scattered across the implementation of both subclasses. Figure 7 represents an aspect-oriented implementation of the same system, where an aspect encapsulates the display updating functionality.

The move pointcut descriptor of Figure 7 captures all the executions of the moveBy methods of a subclass of Shape and invokes the display refresh functionality after the execution proceeds. The concern is modularized, which makes it easier to evolve and maintain.

Discussion

Fragile Pointcuts

Coupling between Aspect and Base Modules

Aspect-Orientation in the Software Development Life cycle

Aspect-Oriented Requirement Engineering

Aspect-Oriented Requirement Engineering (also referred to as Early Aspects) focuses on the identification, specification and representation of crosscutting properties at the requirement level. Examples of such properties include security, mobility, availability and real-time constraints. Crosscutting properties are requirements, use cases or features that have a broadly-scoped effect on other requirements or architecture components.

Aspect oriented requirements engineering approaches are techniques that explicitly recognise the importance of clearly addressing both functional and non-functional crosscutting concerns in addition to non-crosscutting ones. Therefore, theseapproaches focus on systematically and modularly treating, reasoning about, composing and subsequently tracing crosscutting functional and non-functional concerns via suitable abstraction, representation and composition mechanisms tailored to the requirements engineering domain.

Specific areas of excellence under the denominator of AO Requirements Analysis are:
* the aspect oriented requirements process itself,
* the aspect oriented requirements notations,
* aspect oriented requirements tool support,
* adoption and integration of aspect oriented requirements engineering, and
* assessment/evaluation of aspect oriented requirements.

Aspect-Oriented System Architecture

Aspect-Oriented System Architecture focuses on the localization and specification of crosscutting concerns in architectural designs. Crosscutting concerns that appear at the architectural level cannot be modularized by redefining the software architecture using conventional architectural abstractions. Aspect-Oriented System Architecture languages propose explicit mechanisms to identify, specify and evaluate aspects at the architecture design level.

Aspect oriented architecture starts from the observation that we need to identify, specify and evaluate aspects explicitly at the architecture design level. Aspectual architecture approaches describe steps for identifying architectural aspects. This information is used to redesign a given architecture in which the architectural aspects are made explicit.In this regard, specific areas of excellence are:
* the aspect oriented architecture process itself,
* the aspect oriented architecture notations,
* aspect oriented architecture tool support,
* adoption and integration of aspect oriented architecture, and
* assessment/evaluation of aspect oriented architecture.

Aspect-Oriented Modeling and Design

Aspect oriented design has the same objectives as any software design activity, i.e. characterising and specifying the behaviour and structure of the software system. Its unique contribution to software design lies in the fact that concerns that are necessarily scattered and tangled in more traditional approaches can be modularized.Typically, such an approach includes both a process and a language. The process takes as input requirements and produces a design model. The produced design model represents separate concerns and their relationships. The language provides constructs that can describe the elements to be represented in the design and the relationships that can exist between those elements. In particular, constructs are provided to support concern modularization and the specification of concern composition, withconsideration for conflicts. Beyond that, the design of each individual modularized concern compares to standard software design.

Here, specific areas of excellence areas are:

* the aspect oriented design process itself,
* the aspect oriented design notations,
* aspect oriented design tool support,
* adoption and integration of aspect oriented design, and
* assessment/evaluation of aspect oriented design.

Aspect-Oriented Programming

Aspect-Oriented Programming includes programming techniques and tools that support the modularisation of crosscutting concerns at the level of the source code

Just like any other programming language, an aspect oriented language typically consists of two parts: a language specification and an implementation. Hence, there are two corresponding areas of excellence: support for language developers and support for application developers.

Support for application developers

An aspect oriented language supports the implementation of concerns and how to compose those independently implemented concerns. While the specification of such a language is the primary manual for application developers, it provides obviously noguarantee that the application developer will produce high-quality aspect-oriented programs. Specific areas of excellence:
* the crucial concepts of aspect oriented programming languages,
* programming in aspect oriented languages, and
* aspect oriented programming environments.

Support for language developers

Excellence on support for constructing aspect languages includes the following areas:
* constructing languages for specific domains and/or platforms, and
* transferring implementation principles of aspect oriented execution environments, including
** interpreters,
** compilers, and
** virtual machines.

Formal Method Support for Aspect-Orientation

Formal methods can be used both to define aspects semantically and to analyze and verify aspect oriented systems. Aspect-oriented programming extends programming notations with aspect modules that isolate the declaration of when the aspect should be applied (join points) and what actions should be taken when it is reached (advice).Expertise in formal semantic definitions of aspect constructs is useful for language designers to provide a deep understanding of the differences among constructs. Aspects potentially can harm the reliability of a system to which they are woven, and could invalidate essential properties that already were true of the system without the aspect. It is also necessary to show that they actually do add intended crosscutting properties to the system. Hence, numerous questions of correctness and verification are raised by aspect languages. Among the kinds of expertise are:
* specially designed testing techniques to provide coverage for aspects,
* program slicing and code analysis approaches to identify interactions among aspects and between aspects and underlying systems,
* software model checking techniques specialized for aspects, and
* inductive techniques to verify aspect oriented systems.

Each of the above approaches can be used to
* specify and analyze individual aspects relative to an existing system,
* define conditions for composing multiple aspects correctly, and
* detect and resolve potential interferences among aspects.

Although some approaches are already used in aspect languages, others are still subject of research and are not ready for routine industrial application. Nevertheless, awareness of these issues is essential for language designers, and for effective use of aspects, especially in safety-critical contexts.

Aspect Mining and Refactoring

Testing of Aspect-Oriented Programs

Maintenance of Aspect-Oriented Programs and Refactoring

Applications of Aspect-Oriented Software Development

Aspect-Oriented Middleware

Middleware and AOSD strongly complement each other. In general, areas ofexcellence consist of
* support for the application developer, which includes
** the crucial concepts of aspect supporting middleware,
** aspect oriented software development using a specific middleware, involving the aspect programming model, aspect deployment model, platform infrastructure, and services of the middleware, and
* product line engineering (methods, architectures, techniques) in distributed and ambient computing, and
* support for the middleware developer with respect to
** host-infrastructure middleware,
** distribution middleware,
** common middleware services, and
** domain-specific middleware services.

Adoption of Aspect-Oriented Software Development

* IBM Websphere Application Server (WAS) is a java application server that supports Java EE and Web Services. Websphere is distributed according to editions that support different features. Websphere uses AspectJ internally to isolate features of the different editions.
* JBoss Application Server (JBoss AS) is a free, open-source java application server that supports Java EE. The core of JBoss AS is integrated with the JBoss AOP aspect-oriented programming language. The application server uses JBoss AOP to deploy services such as security and transaction management.
* Oracle TopLink is a Java object-to-relational persistence framework that is integrated with the Spring Application Server. TopLink achieves high levels of persistence transparency using Spring AOP.
* SAP
* Sun Microsystems uses AspectJ to streamline mobile application development for the Java ME platform. Aspects are used to simplify the development of mobile applications for deployment to different operator decks and different mobile gaming community interfaces.
* Siemens Soarian is a health information management system that supports seamless access to patient medical records and the definition of workflows for health provider organizations. Soarian uses AspectJ to integrate crosscutting features such as tracing, auditing and performance monitoring in the context of an agile development process.
* Motorola wi4 is a cellular infrastructure system that provides support for the WiMAX wireless broadband standard. The wi4 control software is developed using an aspect-oriented extension to the UML 2.0 standard called WEAVR. WEAVR is used during the development for debugging and testing purposes.
* ASML is a provider of lithography systems for the semiconductor industry. ASML uses an aspect-oriented extension to C called Mirjam to modularize tracing and profiling concerns.
* Glassbox is a troubleshooting agent for Java applications that automatically diagnoses common problems. The Glassbox inspector monitors the activity of the Java virtual machine using AspectJ.

References

Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J.-M. Loingtier, J. Irwin (1997): Aspect-Oriented Programming, in: Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP 1997), Jyväskylä, Finland, Lecture Notes in Computer Science 1241, Springer-Verlag, 220-242] Murphy, G.C., R.J. Walker, E.L.A. Baniassad, M.P. Robillard, A. Lai, M.A. Kersten (2001): Does Aspect-Oriented Programming Work?, in: Communications of the ACM, October 2001, Vol. 44, No. 10, 75-77 ] Parnas, D.L. (1972): On the Criteria To Be Used in Decomposing Systems into Modules, in: Communications of the ACM, December 1972, Vol. 15, No. 12, 1053-1058] Tarr, P., H. Ossher, W. Harrison, S.M. Sutton Jr. (1999): N Degrees of Separation: Multi- Dimensional Separation of Concerns, in: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, California, USA, IEEE Computer Society Press, 107-119] Filman, R. and D. Friedman. “Aspect-oriented programming is quantification and Obliviousness.” Proceedings of the Workshop on Advanced Separation of Concerns, in conjunction with OOPSLA’00 (2000)] Rashid, A and A. Moreira. “Domain Models are NOT Aspect Free.” Proceedings of the 9th Internation Conference on Model-Driven Engineering Languages and and Systems (Models06). Genoa, Italy. LNCS 4199. Springer-Verlag (2006): 155-169.]

External links

* [http://www.aosd.net/ Aspect-Oriented Software Development Community and Conference]
* [http://www.aosd-europe.net/ European Network of Excellence on Aspect-Oriented Software Development]
* [http://www.early-aspects.net/ Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design]
* [http://trese.cs.utwente.nl/taosad/ The Aspect-Oriented Software Architecture Design Portal]
* [http://www.comp.lancs.ac.uk/computing/aop/ Aspect-Oriented Software Engineering at Lancaster]
* [http://dssg.cs.umb.edu/wiki/index.php/Early_Aspects_for_Business_Process_Modeling Early Aspects for Business Process Modeling (An Aspect Oriented Language for BPMN)]
* [http://trese.cs.utwente.nl/oldhtml/composition_filters/ Composition Filters Model]
* [http://www.ccs.neu.edu/research/demeter/ Demeter and Adaptive Programming]
* [http://www.research.ibm.com/sop/ IBM subject-oriented programming]