Abstract

0 7 4 0 -7 4 5 9 / 0 6 / $ 2 0 . 0 0 © 2 0 0 6 I E E E J a n u a r y / F e b r u a r y 2 0 0 6 I E E E S O F T W A R E 6 1 focus criterion, in the early stages of the software life cycle. "Early" signifies occurring before implementation in any development iteration. An aspect in requirements is a concern that crosscuts requirements artifacts; an aspect in architecture is a concern that crosscuts architectural artifacts. Identifying and managing early aspects helps to improve modularity in the requirements and architecture design and to detect conflicting concerns early, when trade-offs can be resolved more economically.In addition, identifying aspects at one stage provides benefits downstream. Knowing requirements-level aspects helps the architect design a better system, and knowing architecture-level aspects helps produce a more robust implementation. Early aspects can span development activities, and many find their way into the code as traditional implementation aspects. More concretely, identifying and managing early aspects across phases can ■ increase the consistency of requirements and architecture designs with each other and with the implementation; ■ provide a rationale and traceability for aspects across life-cycle activities; and ■ help ensure that crosscutting concerns evident in a system's problem domain or solution space are captured as aspects in the implementation.In this article, we describe how to identify and capture early aspects in requirements and architecture activities and how they're carried over from one phase to another. We'll focus on requirements and architecture design activities to illustrate the points, but the same ideas apply in other phases as well, such as domain analysis or in the fine-grained design activities that lie between architecture and implementation. There are many approaches for working with early aspects in practice (for a Discovering Early Aspects T raditionally, aspect-oriented software development has focused on the software life cycle's implementation phase: developers identify and capture aspects mainly in code. But aspects are evident earlier in the life cycle, such as during requirements engineering and architecture design.Early aspects are concerns that crosscut an artifact's dominant decomposition, or base modules derived from the dominant separation-of-concerns

The principle of separation of concerns has long been used by software engineers to manage the complexity of software system development. Programming languages help software engineers explicitly maintain the separation of some concerns in code. As another step towards increasing the scope of concerns that can be captured cleanly within the code, Kiczales and colleagues have introduced aspect-oriented programming. In aspect-oriented programming, explicit language support is provided to help modularize design decisions that cross-cut a functionally-decomposed program. Aspect-oriented programming is intended to make it easier to reason about, develop, and maintain certain kinds of application code. To investigate these claims, we conducted two exploratory experiments that considered the impact of aspect-oriented programming, as found in AspectJ version 0.1, on two common programming activities: debugging and change. Our experimental results provide insights into the usefulness and usability of aspect-oriented programming. Our results also raise questions about the characteristics of the interface between aspects and functionallydecomposed core code that are necessary to accrue programming benefits. Most notably, the separation provided by aspect-oriented programming seems most helpful when the interface is narrow (i.e., the separation is more complete); partial separation does not necessarily provide partial benefit.

No abstract

No abstract