Engineering Aspect-Oriented Systems
Gordon S. Blair, Lynne Blair, Awais Rashid, Ruzanna Chitchyan, Ana Moreira, Jo�ão Araújo · Lancaster EPrints (Lancaster University) · 2005
Aspect-oriented software development (AOSD) techniques aim at providing means for the systematic identification, modularisation and composition of crosscutting concerns throughout the software life cycle. A number of aspect-oriented programming approaches are available, for instance, AspectJ [2], composition filters [11], adaptive programming [53] and Hyper/J [56]. The concepts are also being applied at the earlier stages of software development. At the requirements engineering stage, [34, 65, 71] provide means for handling aspectual requirements. Similarly, a number of aspect-oriented specification [9, 30, 31, 69, 77] and design [23, 35, 72, 74] 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, organisational practices, constraints imposed by the tools or development environments, and the nature of the crosscutting concern. The latter 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 [16, 25] and more recently for aspect-oriented programming techniques [61]. As AOSD techniques mature, there is a need for guidelines supporting development of wellengineered 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 modularised. 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 aspectisation 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 modelled 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 [65]. However, when this clean separation of a crosscutting concern is not possible, aspect-oriented techniques should be used.