Section 25.8. EVALUATION

25.8. EVALUATION

We have used aspect-oriented component engineering on a range of problems. These have included the construction of adaptive user interfaces, multi-view software tools, plug-and-play collaborative work-supporting components, and several prototype enterprise systems. We have built some of these systems using our custom JViews component architecture and some with Java 2 Enterprise Edition software components. Using aspects to assist in engineering these components has helped us to design and build more reusable and adaptable components. We have carried out a basic empirical evaluation of aspect-oriented component engineering by having a group of developers design and prototype a set of components. These included experienced industry designers and post-graduate OO technology students. Feedback from the evaluation indicated that the designers found the aspect-based perspectives on their UML designs useful, both when designing components and when trying to understand others people's components and their compositions. Using aspects to assist in developing decoupled components is effective, though it needs good tool support. Run-time validation of software components with aspects is potentially an important long-term contribution of this work.

We have identified several key advantages of component development with aspect-oriented techniques.

• Crosscutting properties of a system can be explicitly represented in design diagrams. This provides a way for developers to see the impact of these crosscutting concerns on their components and the components' interfaces, operations, and relationships.

• Adding aspect information allows crosscutting behavior (aspect details) and related non-functional constraints (aspect detail properties) to be expressed together. This allows these to be more easily understood and reasoned about when building component compositions.

• Using aspect-oriented designs when implementing software components can result in greater decoupling of components.

• Using encodings of aspect information at runtime can provide a useful approach to providing run-time adaptability and run-time accessible knowledge about component behavior and constraints.

However, there are also several potential disadvantages to our approach.

• There is possibly considerable added complexity to the specifications and designs. Some of our component designers found that the additional diagrams and aspect annotations come with a high overhead. Others were unclear what aspect details and properties they should use and were unsure whether adding new aspect details and properties to their model was a good or bad thing.

• Currently, we have limited tool support for AOCE. Our tools are tuned to producing our custom JViews architecture's components, rather than more general J2EE or .NET components. This means that while developers can use aspect annotations in conventional CASE tools, these lack formal foundations and checking. The aspect designs are not yet supported by good code generation or reverse engineering tools.

• A considerable amount of effort must be put in by implementers to encode aspect information for association with software components. This can be overcome to a degree by extended tool support and by the use of a component architecture that directly supports aspect encoding and decoupled interaction.

• The use of different aspect ontologies by different developers or teams is an issue. Some developers might want to make use of differently named aspect details and properties that express the same information. Of course, developers could agree on the same set of aspects. However, third-party sourced components using different characterizations would need a mapping of one ontology to another. This is a difficult problem to solve in general.