Issue No. 01 - January/February (2006 vol. 23)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MS.2006.12
Christa Schwanninger , Siemens
Gail Murphy , University of British Columbia
You can measure a software system's value by its modularity. 1 The more modular the system, the easier it is to produce 2 and extend. Aspect-oriented programming 3 technologies aim to improve system modularity by modularizing crosscutting concerns. Global properties and programming and design issues can lead to crosscutting concerns—for example, error handling or transaction code, interacting features, and reliability and security.
Consider the improvements brought by object-oriented programming. Encapsulating data with its associated behavior in a class makes it easier for different developers to share the work needed to build the system. Developers need only communicate about and agree on the classes' interfaces. Let's take the canonical example of an object-oriented paint program designed according to the Observer pattern. 4 This program includes the elements painted by an abstract Shape class with concrete subclasses, such as Rectangle and Circle. A Display class makes shapes visible to the user. Developers can share the work needed to build the system by distributing work on the Shape hierarchy and on the Display class. The Shape hierarchy increases the system's value: you can extend it to represent UML class diagram notation to support software design editing and display, solving a different problem using the same framework.
Even when the developer chooses an object-oriented system's structure carefully, the implementation of some concerns still ends up being nonmodular, resulting in scattered and tangled code throughout the system. Common examples include logging, auditing, synchronization, and transactional support concerns. Our paint program offers a simple example: signaling an update to the display when shapes change will likely result in code scattered across classes in the Shape hierarchy as shown in figure 1. 5 AOP developers call update signaling a crosscutting concern because its structure inherently cuts across the classes of the Shape hierarchy. With the programming mechanisms available, the developer cannot simultaneously modularize both the representation of shapes and the representation of update signaling.
AOP improves this situation by supporting the modularization of crosscutting concerns. 5 Using an AOP language, a developer can define an UpdateSignalling aspect, a module that expresses code that crosscuts the system's structure and functionality. When needed, you can compose the aspect into the system. This modularization lets you independently apply the UpdateSignalling aspect or lets you implement different updating strategies. Then, you can configure the system with one of these strategies enabled or even omit the update functionality entirely. Just as an ordinary compiler or virtual machine implements the semantics of OO languages, an AOP compiler or VM implements the AOP language's semantics using a technique known as weaving.
Figure 2 provides an example of an UpdateSignalling aspect as expressed in a popular aspect-oriented language called AspectJ. 5 Included in this simple example is a Shape class with two subclasses: Rectangle and Circle. When one of the set methods is called on a kind of Shape object, an update notification must be sent to the Display class to refresh. The UpdateSignalling aspect declares the displayStateChangepointcut, which identifies points of interest in the execution called join points at which to compose behavior. In this case, the join points are each execution of any set method in a Shape subclass. The advice in the aspect indicates that the display should refresh after any join point identified by the displayStateChange pointcut. In this program, all the code related to display updating is now modularized in the aspect.
Display updating is a simple example of a crosscutting concern. In this special issue, Nicholas Lesiecki's experience report demonstrates the technology's power by describing the use of several aspects in the development of a Web-based search and e-commerce interface for advertising data. The aspects served various purposes, including aiding debugging, implementing a feature, and helping to enhance the functionality of a framework used for the development. The article shows the use of AspectJ's dynamic and static join point models: the dynamic model expresses computations to be composed into the system's runtime; the static model lets a developer modify the program's static structure. In addition to describing the aspects used, the article discusses tool support and adoption issues to consider when moving to aspect-oriented technology.
The version of AspectJ described in Lesiecki's article uses a static weaver, meaning that it weaves aspects into the system during compilation. Context-aware environments or systems that must be highly available might benefit from dynamic weaving, or weaving aspects into a system as it's running. Marc Ségura-Devillechaise and his colleagues describe in their article how you can use dynamic weaving to deploy a security patch to a running Web cache. They also describe how they used their Arachne system, which provides aspect-oriented support for systems written in C, to maintain simplicity in the Web cache code while adding performance improvements and support for new protocols. The Arachne language includes support for identifying join points based on sequences of function calls. This demonstrates an important direction for aspect-oriented technology—the development of semantically meaningful and stable pointcut languages. While Lesiecki shows current state of the art, Ségura-Devillechaise's article allows a glance at what we expect to work with in the medium-term future.
Bart Verheecke and his colleagues' article also describes the use of a dynamic aspect composition mechanism, but in the completely different domain of service-oriented architectures. A Web services management layer implemented with aspect technology allows the modularization of concerns, such as service composition, redirection, user authentication, and logging, which are otherwise scattered and tangled across client applications of Web services. They describe how the JasCo aspect language, which uses an extended version of a Java bean to hold crosscutting behavior, and a separate connector component allowed them to simplify and improve the development of a video-on-demand system.
Many AOP languages support selecting join points and modifying behavior at those join points from the aspect. Using this approach, the developer of code that will later be advised by the aspect can remain oblivious of crosscutting concerns—a useful property, but also a potential source for introducing unanticipated or even misbehavior. Whether or not obliviousness is a fundamental AOP property and how this property affects reasoning about the code in a modular way is an ongoing discussion topic within the community. William G. Griswold and his colleagues describe how introducing interfaces to describe crosscutting concerns can help expose appropriate join points to ensure that both the aspect code and the code to which the aspect applies can evolve gracefully together. They analyze how their approach aids evolution by considering changes to a version of the canonical figure editor example.
Aspect-oriented mechanisms were first developed for source code. The difficulties associated with nonmodularized crosscutting structure are not limited to implementation but also occur during requirements and design activities. It's anticipated that support for modularizing crosscutting concerns at these other stages of development can provide similar benefits to those seen at implementation and can enable better traceability across development stages and more flexible product configuration. The article by Elisa Baniassad and her colleagues describes the authors' ongoing work to bring aspect-oriented ideas to these earlier stages of the software development life cycle.
Similar to object-oriented software development 20 years ago, aspect-oriented technology requires us to change how we think about, design, and implement systems. In the early days of object technology, experts warned that these changes were likely too big of a leap for the average software developer. A similar discussion is ongoing among experts and vendors of aspect-oriented technology today. Learn more about each side's arguments in the Point/Counterpoint discussion on whether AOP is a technology for everyone.
More than ever, software developers must produce complex, configurable systems that must function in an ever-changing environment. In the next few years, we believe aspect-oriented technologies will play an increasing role in several additional areas: embedded systems, supporting customizability while meeting these systems' tight engineering constraints; product families, because crosscutting features can be implemented and combined according to customer needs; and ambient systems, as dynamic weaving can support runtime adaptability.
Gail Murphy is an associate professor in the Department of Computer Science at the University of British Columbia. Her research interests include software evolution and information structure. She received her PhD in computer science and engineering from the University of Washington. She is a member of the ACM and the IEEE Computer Society. Contact her at 2366 Main Mall, Vancouver BC, Canada V6T 1Z4; email@example.com.
Christa Schwanninger is a senior research scientist at Siemens AG's Corporate Technology division. Her research interests include software architecture, distributed object computing, patterns, software system families, and aspect-oriented software development. She received her MS in computer science from Johannes Kepler University. She is a member of the ACM. Contact her at Siemens AG, Corporate Technology, Software and Eng. Division, Otto-Hahn-Ring 6, 81739 Munich, Germany; firstname.lastname@example.org.