Chapter23.An Initial Assessment of Aspect-Oriented Programming


Chapter 23. An Initial Assessment of Aspect-Oriented Programming

ROBERT J. WALKER, ELISA L. A. BANIASSAD, AND GAIL C. MURPHY

The principle of separation of concerns [6] has long been used by software engineers to manage the complexity of software system development. Many programming languages provide explicit support for separation of concerns by providing different sub-languages for expressing the structure of data versus the functionality to be performed on the data. Pascal [10] is one example of a language with this design. Software specifiers and designers also use the principle when using notations, such as UML [18], which place structure and function information into separate diagrams.

Aspect-oriented programming is a new programming technique that takes another step towards increasing the kinds of design concerns that can be captured cleanly within source code [11]. Aspect-oriented programming provides explicit language support for modularizing design decisions that crosscut a functionally-decomposed program. Instead of spreading the code related to a design decision throughout a program's source, a developer is able to express the decision within a separate, coherent piece of code. For example, ensuring that a set of operations do not execute concurrently typically requires spreading code throughout the operations; an aspect-oriented approach allows the synchronization constraint to be specified in one separate piece of code. The aspect code is combined with the primary program code by an aspect weaver. Several different aspect-oriented programming systems have been built, including AML [9], an environment for sparse matrix computation, and RG [16], an environment for creating image processing systems.

The aspect-oriented approach claims to make it easier to reason about, develop, and maintain certain kinds of application code [11]. To begin assessing these claims, we undertook a series of exploratory qualitative studies, including both case studies and experiments[1] [17]. The case study format allowed us to investigate broad usefulness and usability questions surrounding the approach. The experiment format allowed us to focus on more specific questions related to the claims of the technique.

[1] We use the term experiment similar to Basili: "a study undertaken in which the researcher has control over some of the conditions in which the study takes place and control over (some aspects of) the independent variables being studied" [1, p. 444].

This paper reports on two of the exploratory experiments we conducted to investigate aspect-oriented programming. A particular aspect-oriented programming language created by researchers at Xerox PARC, called AspectJ™ (version 0.1) [1], was used in these studies. This version of AspectJ uses a slightly modified form of Java™ [7] for expressing the core functionality of a program, and supports two aspect languages: Cool for expressing synchronization concerns, and Ridl for expressing distribution concerns.[2]

[2] Version 0.2 of AspectJ provides more general purpose support for programming cross-cutting concerns [21].

Each of the two experiments considered a different programming activity. In the first experiment, we considered whether the separation of concerns provided by AspectJ enhanced a developer's ability to find and fix faults present in a multi-threaded program. The second experiment focused on the ease of changing an existing distributed system. In each case, we compared the performance and experience of programmers working in AspectJ with those of programmers working in a control language: Java in the case of the debugging experiment, and Emerald [3] in the case of the change experiment.

The results of these experiments highlight the importance of the aspectcore interface in achieving development benefits with aspect-oriented programming. The aspectcore interface refers to the boundary between code expressed as an aspect and the functionally-decomposed code. This interface is narrow when the scope of the effect of an aspect across the boundary is well-defined, and when the aspect can be reasoned about without extensive analysis of the core code. In the experiments, the narrow interface provided by the synchronization aspect language helped the participants to complete assigned tasks. In contrast, the wider interface provided by the distribution concern language seemed to hinder participants.

Our experiments also indicate that aspect-oriented programming may alter the programming strategies used by developers. Specifically, programmers may be more likely to first try to solve a problem related to a concern captured as an aspect by initially focusing on the aspect code. This new strategy tends to help when the programmer's hunch that the problem is pertinent to the concern is correct, and when the aspect cleanly captures the concern. When these conditions do not hold, this strategy may lead to a drop in programmer performance.

Although gathered at an early stage in the evolution of aspect-oriented programming, these empirical results can help evolve the approach in several ways. First, the results can help builders of cross-cutting modularity techniques, such as aspect-oriented programming and the closely related subject-oriented programming [8], improve the usefulness and usability of the techniques. The results can also help bridge to another useful form of empirical studylonger running industrial-based case studiesby helping potential early adopters of the technology determine whether the technique is suitable to address some of their development problems. Finally, software engineering researchers may build on our methods and results to continue experimental studies of both aspect-oriented programming and other separation of concern techniques.

We begin by describing the essential features of AspectJ. We then describe our experimental method and present the results of running each experiment. Next, we describe the insights into aspect-oriented programming that arise from the studies, critique the study format used, and discuss related work on studies investigating the effect of program structure on programming tasks. We conclude with a summary of the work.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net