Home > Articles

Introduction to Aspect-Oriented Software Development

  • Print
  • + Share This
This chapter introduces the concept of aspect-oriented software development, in which code and programming is modular, allowing code to be repurposed for different software projects.
This chapter is from the book

This book is about aspect-oriented software development (AOSD), a set of emerging technologies that seeks new modularizations of software systems. AOSD allows multiple concerns to be separately expressed but nevertheless be automatically unified into working systems. We intend this book to be an overview of these technologies for the computer professional interested in learning about state-of-the-art developments.

In general, programming is about realizing a set of requirements in an operational software system. One has a (perhaps evolving) set of properties desired of a system, and proceeds to develop that system to achieve those properties. Software engineering is the accumulated set of processes, methodologies, and tools to ease that evolutionary process, including techniques for figuring out what we want to build and mechanisms for yielding a higher-quality resulting system.

A recurrent theme of software engineering (and engineering in general) is that of modularization: "separation and localization of concerns." That is, we have "concerns"—things we care about—in engineering any system. These concerns range from high-level, user-visible requirements like reliability and security to low-level implementation issues like caching and synchronization. Ideally, separating concerns in engineering simplifies system development by allowing the development of specialized expertise and by producing an overall more comprehensible arrangement of elements.

Traditional software development has focused on decomposing systems into units of primary functionality, recognizing the other issues of concern, and leaving it to programmers both 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. Sometimes these other concerns can be packaged into modules of behavior themselves (e.g., subroutines, methods, or procedures). However, often the degree of shared context or the cost of contextual change (for example, the cost of a subprogram call) necessitates intermixing (crosscutting) the instructions for the primary functionality and the other concerns. In any case, conventional development requires programmers 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.

Spreading out the responsibility for invoking the code for multiple concerns to all programmers produces a more brittle system. Each programmer who has to do something right is one more person who can make a mistake; each spot where something needs to be done is a potential maintenance mishap. 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 (likely poorly identified) situations.

We use the term aspect-oriented programming (AOP) to describe the activity of programming with multiple crosscutting concerns or aspects. The general modus operandi of programming AOSD systems is to let system developers express the behavior for each concern in its own module. Such a system must also include some directions for how the different concerns are to be knitted together into a working system (for example, to which program entities each separate concern applies) and a mechanism for actually producing a working system from these elements. For example, many AOSD systems provide a way to say, "High security is achieved by doing X. Reliability is achieved by doing Y. I want high security in the following places in the code and reliability on these operations." The AOSD system then produces an object that invokes the high security and reliability codes appropriately.

Concern-level illustrations of the application of AOP techniques include replication, configuration, debugging, mobility, program instrumentation, security, code movement, and synchronization. AOP is only beginning to penetrate commercial applications, but interesting prototypes have been demonstrated in areas such as application servers, operating systems kernels, real-time distributed event channels, distributed middleware, distributed quality-of-service, multi-agent system architectures, object databases, domain-specific visual modeling, collaboration, workflow, e-commerce, software visualization, engineering design, and data processing.

1.1 Book Organization

Just like object-oriented programming, aspect technology started with aspect-oriented programming languages. Currently, several aspect-oriented languages are in widespread availability, and researchers are continually inventing new ones. Part 1 of this book, "Languages and Foundations," examines this area, including descriptions of not only proposed AOP languages but also programming models based on aspect ideas and chapters discussing the fundamental and historical nature of AOP.

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. Part 2, "Software Engineering," examines these issues, 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.

Of course, the ultimate aim of programming is to develop software systems. In Part 3, "Applications," we present descriptions of the application of aspect technology to particular software problems, including examples that range from the systems to application levels.

Each part of the book includes an introduction to that area and chapters by contributors describing their own work. We invited each contributor to either create an original chapter, targeted at the advanced programmer, or to nominate reprinting an existing paper meeting those criteria. Several of our contributors chose to meld the two approaches, revising existing work in light of new experience and the intended audience.

AOSD is a rapidly evolving area. This format has enabled us to present the reader with a wider overview, a more current set of work, and a clearer sense of the diversity of opinions than a synopsis of different research or an in-depth study of one particular research direction would have provided.

  • + Share This
  • 🔖 Save To Your Account