1. Background

This section introduces the major concepts of Aspect-Oriented Software Development (AOSD), Component-Based Software Development (CBSD), and Architecture Description Languages (ADLs).

1.1. Introduction to AOSD

AOSD is a programming paradigm which aims at modularizing crosscutting concerns. Kiczales and the Xerox PARC team came out with this term to express that a single concern may cut across multiple objects, components or any other software entity, resulting in code tangling and code scattering . For instance, the logging concern is a crosscutting concern which is typically spread over a program. Figure 1 presents a conceptual view of (1) object-oriented paradigm on the left-hand side (2) aspect-oriented paradigm on the right-hand side. In (1) the application directly uses the API. With logging, for instance, each logged element has to explicitly call the logging API. In (2) a special entity called an aspect embodies the crosscutting concern and is woven to the application. Weaving an aspect to an application means producing a new application enhanced with the crosscutting behavior encapsulated by the aspect. Generally, as an aspect-oriented best practice, the aspect delegates the implementation of the service itself to the technical API.

Figure 1: AOSD overview

Even if no standardisation exists for AOSD concepts, most of AOSD approaches use the following terminology:

Aspect An aspect is the modularization of a crosscutting concern. Approaches such as AspectJ, AspectWerkz, or JAsCo consider aspects as different entities from those that compose the base system. These approaches are said to be asymmetric. Some other approaches such as FuseJ, HyperJ, or our proposal adopts a symmetrical approach: aspects are represented as components. It increases the reusability of aspects because components are conceived as highly reusable entities. We elaborate on the advantages and drawbacks of symmetry in following sections.

Advice code Advice codes implement the behaviour of an aspect. Similarly to classes and methods, the behaviour of an aspect can be split into several advice codes. Several types of advice code exist: before, around, after returning, or after throwing.

Join point A join point is a point in the execution of a program. Aspects are added on join points. Generally, join points are method invocations or calls, exception catch blocks, or field accesses.

Pointcut A pointcut designates a set of join points. It is used to specify where advice codes will apply. Some approaches such as JAsCo, JBoss AOP, or CaesarJ separate the pointcut definition from the advice code definition. It increases the reusability of advice codes. Pointcuts are frequently tied to the application because their definition is based on identifiers (class, method, field names) specific to applications. This is identified as the fragile pointcut issue. We give more details on this in Section 2.

Weaving The process of weaving an aspect to a set of base objects consists in assembling these entities together to produce the final application extended with the behaviours defined in the aspects. Weavers can be static (compile time), load-time (such as AspectJ), or dynamic (run-time).

1.2. Introduction to CBSD and Architecture Description Languages (ADLs)

CBSD is a development paradigm that aims to improve software development and to reduce costs by assembling systems from software components. A software component is understood as (...) a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.".

When describing a computer software system, software engineers often talk about the architecture of the system, where an architecture is generally considered as a component assembly. Thus, Architecture Description Languages (ADLs) are often used jointly with a component model. The three main notions which frequently appear in ADLs are the notions of component, binding, and composite-component. A binding is a contractually specified relationship between two component interfaces or ports. Composite-components encapsulate other components defining a hierarchy of components to represent a system.

In the remainder of this document we will consider the notions of component, binding, and composite-component as the main notions representing CBSD to build our unified model for components and aspects. From now, when we talk about a component model, we suppose the component model support these three notions. This means that the component model has to be a hierarchical component model because to the notion of composite-component.

The next section discuss the limits we have encountered with CBSD and AOSD.

2. Rationale

If CBSD and AOSD offer solutions for better code modularization: CBSD by providing hierarchies of highly reusable components, AOSD by modularizing crosscutting concerns; both approaches suffer from issues which seriously limit the evolution of a system. We first study the lack of crosscutting support in CBSD, we then elaborate on current AOSD drawbacks.

2.1. CBSD fails to deal with crosscutting concerns

Although CBSD extends object-orientation (OO) by specifying interactions between entities, the crosscutting concern issue addressed by AOSD (see Section 1.1) is not better handled with CBSD than it is by OO. Indeed, even if a system is better structured with components, some components mix various concerns (code tangling), and some concerns, such as logging, scatter some concerns over several components (code scattering). Code tangling and code scattering are the two symptoms of the crosscutting issue (see Section 1.1, and it is proved that whatever the decomposition performed, these issues arise. This phenomenon is termed as the tyranny of the dominant decomposition. Code tangling is a serious limit to code reusability. A component mixing concerns is not properly reusable. We know that AOSD nicely modularizes crosscutting concerns, so it seems relevant to apply AOSD principles to CBSD.

2.2. AOSD: Two dimensions as brakes for evolution

One of the main AOSD limits comes from the strict separation between the aspects and the base on which aspects are woven.
Firstly, two dimensions are more difficult to maintain and evolve than only one. Secondly, because pointcuts structurally define the join points on which an advice code applies, when the base code evolves pointcuts become obsolete. This phenomenon is termed as the fragile pointcut issue.

An other open issue in AOSD, which is indirectly related to the fragile pointcut issue, is the lack of visibility over crosscutting relationships. Indeed, when weaving an aspect to an application, most of the time the information about which entity is affected by the aspect is lost. It is also because this link is weak that the fragile pointcut issue exists.

Because CBSD requires AOSD techniques as well as AOSD requires CBSD ones, we found interesting to realize an unification. The integration is achieved into the CBSD world mainly because of the strong encapsulation and explicit relationships properties of components.