Section 21.1. INTRODUCTION

21.1. INTRODUCTION

Separation of concerns (SOC) is a long-established principle in software engineering [30]. It has received widespread attention in modern programming languages, with constructs such as modules, packages, classes, and interfaces supporting properties such as abstraction, encapsulation, and information hiding. SOC has also received attention in software architecture and design, with techniques such as Composition Filters [1] and design patterns [12]. While advances in all of these areas have had significant benefits, problems due to inadequate separation of concerns remain [14]. This has led to recent work on "advanced separation of concerns" (ASOC), including subject-oriented programming and design [8, 13], aspect-oriented programming [11, 21], and multi-dimensional separation of concerns [37]. These bring several innovative ideas to programming in particular and to software development in general, which are now beginning to mature and coalesce under the heading of aspect-oriented software development (AOSD).

Surprisingly, concerns themselves have so far remained something of second-class citizens in ASOD. Current ASOD tools provide only limited support for explicit concern modeling. Representations of concerns tend to be tied to particular tools or artifacts, and concern modeling usually occurs only in the context of a particular type of development activity, such as coding or design [8, 22, 37]. A global perspective on concerns, one that spans the lifecycle and is independent of particular development tools or artifacts, has been lacking.

Concerns do not play a second-class role in software development. They arise at every stage of the lifecycle, spanning activities, artifacts, methods, and tools. If AOSD is to be fully realized, concerns must be treated as first-class entities throughout the lifecycle. Concern modeling must be a recognized and essential part of AOSD methods, and concerns must have independent representations on the same level as requirements, architecture, design, and so on.

Sections 21.2 and 21.3 define concerns and give a characterization of concerns in the software lifecycle. In Section 21.4, we argue that general-purpose, independent concern modeling is needed. Section 21.5 presents some requirements for a concern-modeling formalism and discusses some process issues related to concern modeling. Section 21.6 then gives an overview of the Cosmos concern-modeling schema, followed by an example of concern modeling in Section 21.7. Section 21.8 describes related work in the form of four early-lifecycle approaches to software modeling that address concerns in particular contexts. Section 21.9 provides some additional discussion of issues, and Section 21.10 presents a conclusion.