Aspect-Oriented Programming Reloaded

While aspect-oriented programming supports the modular definition of crosscutting concerns, most approaches to aspect- oriented programming fail to improve, or even preserve, modular reasoning. The main problem is that aspects usually carry, through their pointcuts, explicit references to the base code. These dependencies make programs fragile. Changes in the base code can unwittingly break a pointcut definition, rendering the aspect ineffective or causing spurious matches. Conversely, a change in a pointcut definition may cause parts of the base code to be advised without notice. Therefore separate development of aspect-oriented programs is largely compromised, which in turns seriously hinders the adoption of aspect-oriented programming by practitioners. We propose to separate base code and aspects using Join Point Interfaces, which are contracts between aspects and base code. Base code can define pointcuts that expose selected join points through a Join Point Interface. Conversely, an aspect can offer to advise join points that pro- vide a given Join Point Interface. Crucially, however, aspect themselves cannot contain pointcuts, and hence cannot refer to base code elements. In addition, because a given join point can provide several Join Point Interfaces, and Join Point Interfaces can be organized in a subtype hierarchy, our approach supports join point polymorphism. We describe a novel advice dispatch mechanism that offers a flexible and type-safe approach to aspect reuse.

The rapidly growing mobile market has stimulated the demand for more and more complex custom applications for embedded mobile devices, for example, smart phones. To manage this complexity and, at the same time, to keep the time to market small, advanced software engineering methods have to be applied. Aspect-oriented programming (AOP) provides advanced modularization and abstraction mechanisms. The main advantages of this concept are improved maintainability, reusability, and extensibility of applications. Furthermore, dynamic AOP can be used to implement the dynamic adaptation of mobile device applications to changing contexts, like the location. However, the overhead introduced by the additional abstraction mechanisms limits the applicability to embedded mobile devices because they have limited resources (CPU, memory) compared to desktop PCs. To overcome this problem, we present a set of optimizations that significantly reduce the overhead of common AOP mechanisms and, finally, make AOP applicable for embedded mobile devices. The foundation of our work is a thorough analysis of the overhead that is typically generated by the realization of AOP mechanisms. The key idea of our approach is a deep integration of AOP mechanisms into the virtual machine. To this end, we shift mechanisms like the registration of activated aspects to the level of the JVM. Furthermore, we optimize the execution of AOP programs by introducing caching mechanisms and specialized bytecode instructions that are tailored for the execution of AOP mechanisms. Moreover, we analyze AOP-specific semantic code properties in order to develop optimizations that utilize these AOP-specific semantic information and that exploit typical AOP usage schemes. In addition to the AOP optimizations, we realize an efficient dynamic aspect deployment mechanism. We apply our optimizations to the Java-based aspect-oriented programming language ObjectTeams [HHM07] by extending the extremely small and portable JamVM [Lou] Java virtual machine. To evaluate our approach, we execute micro benchmarks, investigate the effect of our optimizations on a real-world application, and finally discuss the transferability of our optimizations to other approaches. Our evaluation shows a considerable performance gain for the aspect activation and the aspect execution of ObjectTeams. In particular, we demonstrate that our optimizations improve the performance of commonly used AOP mechanisms by up to 90%. At the same time, we reduce the code size of the adapted classes, which is also important for small devices. Finally, with our case study, namely the OTPong game application, we show that our approach is capable of significantly optimizing the execution time of real-word applications. Our main contribution is a significant reduction of the overhead of high-level AOP constructs, which is also demonstrated by the results of our experiments. The success of the optimizations provides evidence that advanced high-level abstraction techniques like AOP can be efficiently used in embedded mobile devices. Furthermore, our work shows that efficient dynamic aspect deployment can be supported on the level of the JVM. This substantially enhances the dynamic capabilities of ObjectTeams.

In current aspect-oriented systems, aspects usually carry, through their pointcuts, explicit references to the base code. Those references are fragile and hinder important software engineering properties such as modular reasoning and independent evolution of aspects and base code. In this work, we introduce a novel abstraction called Join Point Interface, which, by design, aids modular reasoning and independent evolution by decoupling aspects from base code and by providing a modular type-checking algorithm. Join point interfaces can be used both with implicit announcement through pointcuts, and with explicit announcement, using closure join points. Join point interfaces further offer polymorphic dispatch on join points, with an advice-dispatch semantics akin to multimethods. To support flexible join point matching, we incorporate into our language an earlier proposal for generic advice, and introduce a mechanism for controlled global quantification. We motivate each language feature in detail, showing that it is necessary to obtain a language design that is both type safe and flexible enough to support typical aspect-oriented programming idioms. We have implemented join point interfaces as an open-source extension to AspectJ. A case study on existing aspect-oriented programs supports our design, and in particular shows the necessity of both generic interfaces and some mechanism for global quantification.

Advice is a mechanism, widely used in aspect-oriented languages, \nthat allows one program component to augment or modify the behavior of \nother components.\nWhen advice and other components are composed together they become tightly coupled, \nsharing both control and data flows. However this creates important problems:\nmodular reasoning about a component becomes very difficult; and \ntwo tightly coupled components may interfere with each other's control and data flows.\n\nThis paper presents EffectiveAdvice, a disciplined model of advice, \ninspired by Aldrich's Open Modules, that has full support for effects. \nWith EffectiveAdvice, \nequivalence of advice, as well as base components, can be checked by\nequational reasoning. \nThe paper describes EffectiveAdvice as a Haskell library in which \nadvice is modeled by mixin inheritance and effects are modeled by monads.\nInterference patterns previously identified in the literature are \nexpressed as combinators. Parametricity, together with the combinators, is used to\nprove two harmless advice theorems. The result is an effective semantic model of advice \nthat supports effects, and allows these effects to be \nseparated with strong non-interference guarantees, or merged as needed.

6 - Improving Your Productivity

For systems which deal with serious or dangerous things (for example nuclear power plant), programs are constrained by legislation to be safe in any case, which requires verification process during the execution, in other words “Runtime Verification” (RV). The field of runtime verification has many different names: runtime monitoring, runtime checking, runtime result checking, runtime reflection, monitoring oriented programming, design by contract, runtime analysis, dynamic analysis, trace analysis, fault protection, etc. Aspect-oriented programming (AOP) is a useful paradigm for monitoring programs, even if it was not created for this purpose. Indeed, AOP tries to deal with crosscutting concerns (tangled and scattered codes) by “capturing” them within a new entity called aspect, and runtime verification properties are conceptually transversal to the code they verify, unavoidably resulting in such crosscutting codes. AOP is always used as an extension of an existing language. Hence it is necessary to design an aspect language extending the target language, and to use what is called a weaver, to realize a binding operation between the target program and the aspects. Thus, one can find many aspect-programming extensions (including an aspect language and an aspect weaver) for most programming languages. The first one to be developed was AspectJ, designed for Java, and which has been the best-known reference among aspect-oriented tools until now. We use an AspectJ-like tool, straight inspired from AspectJ but designed for C, called ACC, which is itself an improved version of AspectC. The purpose of this paper is to explore the possibility of implementing and monitoring generic (also called parameterized) verification properties, i.e. which could be used on any target code, with ACC through a basic example. As ACC, contrary to AspectJ, does not provide abstraction for aspects, which would have made generic monitoring an easy task, we tried to simulate abstraction by making use of macros in the aspect code, which boils down to monitor every parameterized property within one macro function. We will see that despite losses of expressiveness without complexification of the monitoring code, the method still allows monitoring generically any property which is already monitorable directly in ACC.

Developing a machine model natively supporting aspect-oriented programming (AOP) is fruitful not only for implementing interpreters and compilers for AOP languages but also for understanding the essence of the AOP paradigm. This position paper shows a machine model based on open classes and predicate dispatch and it briefly describes a list of predicates that are necessary for modeling AspectJ. This machine model is useful for comparing AOP and object-oriented programming (OOP) on a side-by-side basis. Our initial observation is that AOP is a natural extension to OOP with respect to language constructs.

After reading the chapter, you should be able to explain the key concepts of collaboration-based design and feature-oriented programming, understand the key mechanisms of AspectJ and write simple aspects in this language, implement product lines with feature-oriented and aspect-oriented languages and their combination, discuss trade-offs between these and previous implementation techniques, contrast feature-oriented and aspect-oriented languages regarding their key mechanisms select a suitable implementation technique for a given product line, critically discuss the conflict between preplanning and obliviousness, and discuss strategies of developing feature-oriented extensions of other code and noncode languages.

Aspect-Oriented Programming (AOP) is a programming paradigm that implements crosscutting concerns in a modular way. People have witnessed the prosperity of AOP languages for Java and C++, such as AspectJ and AspectC++, which has propelled AOP to become an important programming paradigm with many interesting application scenarios, e.g., runtime verification. In contrast, the AOP languages for C are still poor and lack compiler support. In this paper, we design a new general-purpose and expressive aspect-oriented C programming language, namely Aclang, and implement a compiler for it, which brings fully-fledged AOP support into the C domain. We have evaluated the effectiveness and performance of our compiler against two state-of-the-art tools, ACC and AspectC++. In terms of effectiveness, Aclang outperforms ACC and AspectC++. In terms of performance, Aclang outperforms ACC in execution time and outperforms AspectC++ in both execution time and memory consumption.

A code smell is any symptom in the source code that possibly indicates a bad design or programming problem. Many code smells in aspect-oriented programming (AOP) are very different from those in object-oriented programming. Therefore, new detection strategies should be conceived to identify whether a particular slice of aspect-oriented code is affected by a specific smell. Unfortunately, research on AOP usually focuses on providing abstract descriptions of code smells, without providing operational definitions of their detection strategies. Such strategies are becoming increasingly required due to the growing use of AOP in the development of long-living systems, including frameworks, libraries and software product lines. This paper presents a family of metric-based strategies that support the detection of recurring smells observed in existing aspect-oriented systems. We analyzed the accuracy of such smell detection strategies and also of those previously reported in the literature. Our study involved in total 17 releases of 3 evolving aspect-oriented systems from different domains. The outcome of our evaluation suggests that strategies for previously-documented AOP smells do not present a satisfactory accuracy. Our analysis also revealed that: (1) newly-discovered strategies achieved better results than well-known ones, and (2) the detection strategies seem to have high accuracy with respect to the identification of both trivial and non-trivial code smells.

Software Testing is an evaluation mechanism that signifies the importance of software quality assurance, which will evaluate a particular system to check if it will satisfy all the requirements specified by the user. One cannot underestimate the importance of software testing. The wider perceptibility of software systems and the cost, which is related to the software failure are driving factors for efficient planning through testing. In this paper, we elaborate on the Unit testing and Data flow testing techniques applied on Object-oriented Programming and Aspect-oriented Programming. Moreover a tabular contrast of both the techniques is presented representing the differences between both the techniques.

The modularity of aspect-oriented programming (AOP) has been a controversial issue. To investigate this issue compared with object-oriented programming (OOP), we propose a simple language providing AOP mechanisms, which are enhanced traditional OOP mechanisms. We also present its formal system and then show that programs in this language can be only mostly modularly ( i.e. separately) typechecked and compiled.We mention a source of this unmodularity and discuss whether or not it is appropriate to claim that AOP breaks modularity compared with OOP.

Aspect-oriented programming is a promising approach to address separation of concerns. Aspect-oriented programming languages address the problems of scattering and entanglement by providing an abstraction for specifying cross-cutting concerns in a modular manner. The relevant aspects are then composed to derive the desired implementation. However, current aspect-oriented programming languages only allow this composition to be specified in terms of programming language constructs. This is restrictive and can only be used for simple compositions. Many situations in practice need a richer composition context that cannot be expressed using programming language constructs. Models, being at a higher level of abstraction and closer to the problem domain, can be used to capture this information. We propose an approach to extend aspect-oriented programming with a composition mechanism that can make use of the information captured in models. We also outline an implementation of the proposed approach. The proposed approach has been used to seamlessly integrate model-centric and code-centric development.

AspectJ is a well-established programming language for the implementation of aspect-oriented programs. It supports the aspect-oriented programming paradigm by providing a special unit, called aspect, which encapsulates crosscutting code. While with AspectJ a suitable aspect-oriented programming language is at hand, no feasible modeling language is available that supports the design of AspectJ programs. In this work, such a design notation for AspectJ programs is presented based on the UML. It provides representations for all language constructs in AspectJ and specifies an UML implementation of AspectJ's weaving mechanism. The design notation eases the perception of aspect-orientation and AspectJ programs. It carries over the advantages of aspect-orientation to the design level.

A quantitative and qualitative assessment of aspectual feature modules for evolving software product lines