Chapter17.Engineering Aspect-Oriented Systems

Chapter 17. Engineering Aspect-Oriented Systems

GORDON S. BLAIR, LYNNE BLAIR, AWAIS RASHID, ANA MOREIRA, JOÃO ARAãJO, AND RUZANNA CHITCHYAN

Aspect-oriented software development (AOSD) techniques aim at providing means for the systematic identification, modularization, and composition of crosscutting concerns throughout the software lifecycle. A number of aspect-oriented programming approaches are available, such as AspectJ [5], composition filters [8], adaptive programming [58], and Hyper/J [61]. The concepts are also being applied at the earlier stages of software development. At the requirements engineering stage, [7, 34, 70, 76] provide means for handling aspectual requirements. Similarly, a number of aspect-oriented specification [2, 28, 29, 74, 82] and design [7, 21, 36, 77, 79] approaches have been proposed. With a range of techniques available to a software engineer at each stage, the task of engineering an aspect-oriented system poses significant challenges. At each development stage, the software engineer needs to employ the most suitable aspect-oriented technique for the application being developed. The choice of technique can be dictated by a number of factors including system requirements, organizational practices, constraints imposed by the tools or development environments, and the nature of the crosscutting concern. The last implies that multiple techniques may be employed at each stage in conjunction with each other. This hybrid view of separation of concerns has previously been advocated by multi-paradigm approaches [14, 23] and more recently for aspect-oriented programming techniques [66].

As AOSD techniques mature, there is a need for guidelines supporting the development of well-engineered aspect-oriented systems. It is the aim of this chapter to provide such guidelines for key phases of the software lifecycle. The guidelines are aimed at describing the distinguishing characteristics of AOSD approaches at each stage and their suitability for the application or concern being modularized. By making these guidelines available, we aim to support the software engineer in choosing the optimal technique or set of techniques at each stage. Note that aspectization should not be a forced phenomenon. Conventional separation of concerns techniques (e.g., object-oriented approaches) should be used if crosscutting concerns can be cleanly modeled without having to encapsulate them in a separate unit. For instance, a crosscutting concern could be embodied in the choice of specific system architecture rather than an individual unit [70]. However, when this clean separation of a crosscutting concern is not possible, aspect-oriented techniques should be used.

The structure of the chapter mirrors the typical software lifecycle, considering AOSD at each stage. In particular, Section 17.1 considers aspects and requirements engineering, with Section 17.2 addressing aspect-oriented specification. Design and implementation issues are then addressed in Sections 17.3 and 17.4, respectively. Section 17.5 addresses the important issue of software evolution and aspects, highlighting the issue of dynamic aspects. Section 17.6 then examines the potential problem of aspect interactions, and Section 17.7 presents some concluding remarks.