Aspect Decomposition

Obviously, a given design problem can have crosscutting concerns and conventional abstraction mechanisms fail to appropriately cope with these concerns. AOSD provides explicit abstractions for representing crosscutting concerns, also called aspects. As such, a given design problem is decomposed into concerns that can be localized into separate modules and concerns that tend to crosscut over a set of modules.

Figure 5. Separating Aspects

To specify the points that the aspect crosscuts a so-called pointcut specification is used. A pointcut specification is in essence a predicate over the complete set of joinpoints that the aspect can crosscut. A pointcut specification can enumerate the joinpoints or provide a more abstract specification. In an abstract sense, aspects can thus be specified as follows:

       Aspect name

            Pointcut specification

By providing explicit language constructs the notion of aspect becomes an explicit first-class abstraction. The crosscutting is actually localized in the pointcut specification. The pointcut specification indicates which points the aspect crosscuts but it does not specify what kind of behavior is needed. For this the concept of advice has been introduced. An advice is a behavior that can be attached before, around or after a joinpoint in the pointcut specification.

       Aspect name

          Pointcut specification

          Advice

The above concepts seem now to be accepted by the AOSD community. Several aspect-oriented languages exist in the literature. Although they differ in the way of specifying aspects, pointcuts and advices in essence they all adopt the above concepts. We will not elaborate on each of the aspect-languages here but suffice to refer to the corresponding web-sites to see how these concepts (and additional specific concepts) have been implemented. The aosd.net home page provides a nice link to different aspect languages.