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.