Section 25.5. COMPONENT IMPLEMENTATION WITH ASPECTS

25.5. COMPONENT IMPLEMENTATION WITH ASPECTS

When implementing software components, some key issues arise:

• How can reusability of components be maximized? This is desirable to realize the component-based development philosophy of "building systems from reusable parts."

• How can component interaction be decoupled, thereby minimizing the knowledge required of other components, interfaces, and methods? This allows greater compositional flexibility.

• How can run-time introspection of components be supported? This allows components at runtime to be understood by other components and by developers (or even end users) who may be reconfiguring a system (for example, plugging in new components).

• How can run-time adaptation and composition best be supported? This allows dynamically evolving systems.

In our work, we have used aspects to help achieve these goals. We have developed two approaches that make use of aspect information when implementing software components. Figure 25-6 (top) illustrates how information about the aspects affecting a component can be obtained.

Figure 25-6. Using aspects to decouple components.

The aspect information associated with a component can be queried by other components (1). We have developed two ways of doing this. One has the aspect information encoded using a special class hierarchy of "aspect information objects." The other has aspect information encoded in XML. After obtaining aspect-based information about another component, a client component can then invoke the component's functionality. This can be done by dynamically constructing method invocations (2). Alternatively, it can be done by calling standard adaptor methods implemented by the aspect objects (3).

These translate standard method calls into particular component method calls (4). This approach provides a way of greatly decoupling many common component interactions by the use of a set of standard aspect-oriented interactions.

Figure 25-6 (bottom) shows a simple example of using this decoupled approach. An itinerary item factory component instance wants to add a user interface affordance to the itinerary editor's user interface. The factory component knows nothing about how the editor's user interface is implemented. Neither does it know how its affordance will actually be realized (menu item, button, etc). First, it tells its own aspect information to initialize after plug-in (1). Its required extensible affordance aspect object queries the components related to the itinerary item factory (e.g., the itinerary editor) for its aspect information (2). It then locates a provided extensible affordance aspect object and requests this object to add an affordance to the itinerary editor's user interface (3). This creates a menu item (4) and adds it to the itinerary editor's menu bar at an appropriate place (5). The menu item notifies the factory when it should create a new travel item of a particular kind (6). The provided affordance aspect object knows how to create and add this affordance for its owning itinerary editor component. In this example, it adds a menu item. If the factory were associated with a different component that extended its interface with buttons, a new button would be created and added. This would be done without the factory having any knowledge of how it happened. We have used this approach to implement a wide variety of software components with highly decoupled interactions.