Domain specific aspect-oriented language extensions offer unique capabilities to deal with a variety of cross cutting concerns. Ideally, one should be able to use several of these extensions together in a single program. Unfortunately, each extension generally implements its own specialized weaver and the different weavers are incompatible. Even if the weavers were compatible, combining them is a difficult problem to solve in general, because each extension definesits own language with new semantics. In this paper we present a practical composition framework, named Awesome, for constructing a multi-extension weaver by plugging together independently developed aspect mechanisms. The framework has a component-based and aspect-oriented architecture that facilitates the development and integration of aspect weavers. To be scalable, the framework provides a default resolution of feature interactions in the composition. To be general, the framework provides means for customizing the composition behavior. Furthermore, to be practically useful, there is no framework-associated overhead on the runtime performance of compiled aspect programs. To illustrate the Awesome framework concretely, we demonstrate the construction of a weaver for a multi-extension AOP language that combines Cool and AspectJ. However, the composition method is not exclusive to Cool and AspectJ-it can be applied to combine any comparable reactive aspect mechanisms.

The simultaneous use of multiple aspect languages has the potential of becoming a significant one, as new aspectoriented frameworks are developed and existing ones expand to incorporate features of others. A key challenge in combining multiple aspect-oriented languages is identifying and resolving adverse feature interactions. These interactions occur due to the incompatible and inconsistent treatment of aspects, join points, and advice across different languages. In this paper, we analyze the root cause of this feature interaction problem. We classify common features of aspect languages, describe how these features may interact when using different aspect languages in tandem, and concretely illustrate how these interactions may be resolved. Our work allows AOP users and tool developers to reason about the occurrence of such adverse and unexpected feature interactions, and to apply several patterns for resolving these problems.

A plethora of aspect mechanisms exist today. All of these diverse mechanisms integrate concerns into artifacts that exhibit crosscutting structure. What we lack and need is a characterization of the design space that these aspect mechanisms inhabit and a model description of their weaving processes. A good design space representation provides a common framework for understanding and evaluating existing mechanisms. A well-understood model of the weaving process can guide the implementor of new aspect mechanisms. It can guide the designer when mechanisms implementing new kinds of weaving are needed. It can also help teach aspect-oriented programming (AOP). In this paper we present and evaluate such a model of the design space for aspect mechanisms and their weaving processes. We model weaving, at an abstract level, as a concern integration process. We derive a weaving process model (WPM) top-down, differentiating a reactive from a nonreactive process. The model provides an in-depth explanation of the key subprocesses used by existing aspect mechanisms.

Studies of Aspect-Oriented Programming (AOP) usually focus on a language in which a specific aspect extension is integrated with a base language. Languages specified in this manner have a fixed non-extensible AOP functionality. This paper argues the need for AOP to support the integration and use of multiple domain-specific aspect extensions together. We study the more general case of integrating a base language with a set of third-party aspect extensions for that language. We present a general mixin-based semantic framework for implementing dynamic aspect extensions in such a way that multiple, independently developed aspect mechanisms can be subject to third-party composition and work collaboratively. Principles governing the design of a collaborative aspect mechanism are aspectual effect exposure and implementation hiding.

Web-application development cuts across the HTTP protocol, the client-side data presentation languages (HTML, XML), the server-side technology (Servlets, JSP, ASP, PHP), and the underlying resource (files, database, information system). Consequently, different web development design concerns including functionality, presentation, control, and structure are tangled and scattered, leading to code that is hard to develop, maintain, and reuse. In this paper we analyze the cause and consequences of crosscutting in existing web development technologies. We distinguish between intra-crosscutting that results in code tangling and inter-crosscutting that results in code scattering. All current web development models including MVC fail to address inter-crosscutting. We present two new web development models: XP and DDD. The XP model introduces extension points as place-holders for structure-dependent code. The DDD model extends the MVC framework with extension points. We present a novel domain-driven web development framework named WebJinn that completely separates web development concerns. The result is a significant improvement in web development in terms of reuse. WebJinn has been used to develop web application at several web sites.

The manifestation of miscellaneous aspect-oriented extensions raises the question of how these extensions can be used together to combine their aspectual capabilities or reuse aspect code across extensions. While white-box composition of aspect mechanisms can produce an optimal compound mechanism, as exemplified by the merger of AspectJ and AspectWerkz into AspectJ 5, it comes with a high integration cost. Meanwhile, generic black-box composition can compose arbitrary aspect mechanisms, but may result in a compound mechanism that is suboptimal in comparison to white-box composition. For a particular family of aspect extensions, e.g.,AspectJ-like mechanisms, glass-box composition offers the best of two worlds. Glass-box may rely on the internal structure of, e.g., a pointcut-and-advice mechanism, without requiring a change to the code of the individual mechanisms. In this paper we compare white-, black-, and glass-box composition of aspect mechanisms. We explain subtle composition issues using an example drawn from the domain of secure and dependable computing, deploying a fault-tolerance aspect written in AspectWerkz together with an access-control aspect written in AspectJ. To compare the three composition methods, we integrate a TinyAJ extension with a TinyAW extension, and compare the results of running the aspects in a black-box framework and in a glass-box framework to the result of running these aspects in AspectJ 5. This work was supported in part by NSF?s Science of Design program under grants numbered CCF-0438971 and CCF-0609612, and by the Program for Secure and Dependable Computing at University of Virginia.

There is a growing interest in the composition of aspect mechanisms. All extant works, however, avoid an important question: what should the semantics of the composed multi-extension language be? The problem is that the semantics for the composition is nowhere specified. Therefore, even if third-party composition of aspect mechanisms were successful, it is difficult to evaluate the correctness of the composition. In this paper, we propose the use of AspectJ 5 as a benchmark for evaluating and comparing composition techniques for integrating pointcut-and-advice mechanisms. If an aspect mechanism X implements the semantics of AspectJ and another mechanism Y implements the semantics of AspectWerkz, then the semantics of the composition X+Y can be checked against the semantics of AspectJ 5. We present a novel parallel composition technique, and illustrate that it passes the AspectJ 5 benchmark.

The goal of this paper is to draw attention to and raise awareness of a feature interaction problems in the integration of aspect mechanisms. We illustrate the problem by examining feature interactions between AspectJ 1.2 and AspectWerkz as found in AspectJ 5.

An important challenge in teaching aspect-oriented programming is establishing a ?mental model? of weaving. In this position paper we review three evolutionary stages in forming a mental representation for AOP. These stages help a novice to progressively develop a good mental model of AOP.

Aspect Oriented Programming (AOP) is a powerful reflective programming tool. In this paper we discuss how simple yet effective AOP constructs can be used to facilitate the process of program comprehension on three bodies of code. The first is the Java portion of a sizable third party legacy system for manipulating and displaying protein sequences entitled Friend. The second is Eclipse, an open source Java IDE. The third is Compress, a SPEC JVM98 Java benchmark. We study uses of the AspectJ AOP language to expose both dynamic and static software characteristics. Examples provided are actual code and data from our experience re-engineering the Friend software but the AOP techniques presented can be applied towards any system.

With most of today's aspect-oriented language extensions, developers have both aspectual and core reflection mechanisms available to them. From a software engineering point of view, these mechanisms serve different purposes in different application areas. This paper explores to what extent aspectual and core reflection overlap. Interactions of aspectual and core reflection are discussed based on practical observations in concrete examples.

Normally, Aspect-Oriented Programming (AOP) is used for plugging and not for unplugging. Aspects (concerns) are weaved into a system, thus providing a modularized way to add crosscutting features to a base program. For example, given a base program without logging and given a logging aspect, the AOP weaver produces from the untangled code an executable with the desired crosscutting logging behaviors. The benefit is that the logging code is modularized, e.g., you can easily activate or deactivate logging. However, what if a legacy system written without AOP technology already contains logging functionality hard-coded in the base program? How do you deactivate logging then? In this paper, we explore the use of AOP for writing aspects that transform exiting hard-coded calls into plugs that can be used to retarget the client to use other subcomponents. Applying AOP for unplugging has potential usage in connection with components. You are given a monolithic system. You apply AOP to non-intrusively decouple the system's components. You may then replace some of the legacy components with alternative third-party components.