This paper reports our experience using AspectJ, a general purpose aspect-oriented extension to Java, to implement distribution and persistence aspects in a web-based information system. This system was originally implemented in Java and restructured with AspectJ. Our main contribution is to show that AspectJ is useful for implementing several persistence and distribution concerns in the application considered, and other similar applications. We have also identified a few drawbacks in the language and suggest some minor modifications that could significantly improve similar implementations. Despite the drawbacks, we argue that the AspectJ implementation is superior to the pure Java implementation. Some of the aspects implemented in our experiment are abstract and constitute a simple aspect framework. The other aspects are application specific but we suggest that different implementations might follow the same aspect pattern. The framework and the pattern allow us to propose architecture-specific guidelines that provide practical advice for both restructuring and implementing certain kinds of persistent and distributed applications with AspectJ.

In general, aspect-oriented programs require a whole-program analysis to understand the semantics of a single method invocation. This property can make reasoning difficult, impeding maintenance efforts, contrary to a stated goal of aspect-oriented programming. We propose some simple modifications to AspectJ that permit modular reasoning. This eliminates the need for whole-program analysis and makes code easier to understand and maintain. 1.

Abstract. Modeling four aspect-oriented programming mechanisms shows the way in which each supports modular crosscutting. Comparing the models produces a clear three part characterization of what is required to support crosscutting structure: a common frame of reference that two (or more) programs can use to connect with each other and each provide their semantic contribution. 1

We present a new classification system for aspect-oriented programs. This system characterizes the interactions between aspects and methods and identifies classes of interactions that enable modular reasoning about the crosscut program. We argue that this system can help developers structure their understanding of aspect-oriented programs and promotes their ability to reason productively about the consequences of crosscutting a program with a given aspect. We have designed and implemented a program analysis system that automatically classifies interactions between aspects and methods and have applied this analysis to a set of benchmark programs. We found that our analysis is able to 1) identify interactions with desirable properties (such as lack of interference), 2) identify potentially problematic interactions (such as interference caused by the aspect and the method both writing the same field), and 3) direct the developer’s attention to the causes of such interactions.

Aspect-orientation can help to separate concerns in software. One of the goals of this separation is to promote flexibility and configurability; this is especially true when constructing program families (and product-lines). This paper introduces a set of principles that instruct in the creation of flexible, configurable, aspect-oriented systems. We illustrate the principles through their application to a software product-line. The principle of dependency alignment serves as a guideline for structuring concern implementation in modules, eliminating unwarranted dependencies between concerns. The principles of orthogonal and weakly orthogonal aspects instruct in the design of aspects that are included in some system configurations, but not in others. We show how these principles scale to larger systems and larger concern implementations.

This paper present a semantan(7W1W2 compilat2( framework for an aspect716C7 tt programming language based on it operat'W(/ semantma model. Usingpart(1 evaluatlua tl framework can explain several issues incompilat]2 processes, including howt o find places in programtog t insert aspect code and howt o remove unnecessaryrun-tes checks.It also illustW(/2 optstW(/2' of calling-contal sensit - e pointn(' (cflow), implementp in real compilers. Keywords Aspect SandBox, dynamic join point model,part12 evaluatu -( FutC ura project2C1 compile-t2] weaving, contn(1 sensit] e point(7 designat21 cflow) 1.

Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is a difficult task that accounts for a large proportion of the effort of performing program evolution. One possibility to mitigate this problem is to produce textual documentation that describes scattered concerns. However, this approach is impractical because it is costly, and because, as a program evolves, the documentation becomes inconsistent with the source code. The thesis of this dissertation is that a description of concerns, representing program structures and linked to source code, that can be produced cost-effectively during program investigation activities, can help developers perform software evolution tasks more systematically, and on different versions of a system. To validate the claims of this thesis, we have developed a model for a structure, called concern graph, that describes concerns in source code in terms of relations between program elements. The model also defines precisely the notion of inconsistency between a concern graph and the

We propose an aspect-oriented programming (AOP) language called Aspectual Caml based on a strongly-typed functional language Objective Caml. Aspectual Caml o#ers two AOP mechanisms, namely the pointcut and advice mechanism and the type extension mechanism, which gives similar functionality to the inter-type declarations in AspectJ. Those mechanisms are not simple adaptation of the similar mechanisms in existing AOP languages, but re-designed for common programming styles in functional languages such as type inference, polymorphic types, and curried functions. We implemented a prototype compiler of the language and used the language for separating crosscutting concerns in application programs, including a type system separated from a compiler of a simple language.

This paper describes a technique for improving separation of concerns at the level of domain modeling. A contribution of this new approach is the construction of support tools that facilitate the elevation of crosscutting modeling concerns to first-class constructs in a type-system. The key idea is the application of a variant of the OMG Object Constraint Language to models that are stored persistently in XML. With this approach, weavers are generated from domain-specific descriptions to assist a modeler in exploring various alternative modeling scenarios. The paper examines several facets of Aspect-Oriented Domain Modeling (AODM), including: domain-specific model weavers, a language to support the concern separation, an overview of code generation issues within a meta-weaver framework, and a comparison between AODM and AOP. An example of the approach is provided...

Abstract: Developers of modern software systems are often required to build software that addresses security, fault-tolerance and other dependability concerns. A decision to address a dependability concern in a particular manner can make it difficult or impossible to address other concerns in software. Proper attention to balancing key dependability and other concerns in the