AspectJML: modular specification and runtime checking for crosscutting contracts

Aspect-oriented programming (AOP) is a popular technique for modularizing crosscutting concerns. In this context, researchers have found that the realization of design by contract (DbC) is crosscutting and fares better when modularized by AOP. However, previous efforts aimed at supporting crosscutting contract modularity might actually compromise the main DbC principles. For example, in AspectJ-style, reasoning about the correctness of a method call may require a whole-program analysis to determine what advice applies and what that advice does relative to DbC implementation and checking. Also, when contracts are separated from classes a programmer may not know about them and may break them inadvertently. In this paper we solve these problems with AspectJML, a new specification language that supports crosscutting contracts for Java code. We also show how AspectJML supports the main DbC principles of modular reasoning and contracts as documentation

What Does Aspect-Oriented Programming Mean for Functional Programmers?

Aspect-Oriented Programming (AOP) aims at modularising crosscutting concerns that show up in software. The success of AOP has been almost viral and nearly all areas in Software Engineering and Programming Languages have become "infected" by the AOP bug in one way or another. Interestingly the functional programming community (and, in particular, the pure functional programming community) seems to be resistant to the pandemic. The goal of this paper is to debate the possible causes of the functional programming community's resistance and to raise awareness and interest by showcasing the benefits that could be gained from having a functional AOP language. At the same time, we identify the main challenges and explore the possible design-space

Towards an aspect weaving BPEL engine

This position paper proposes the use of dynamic aspects and the visitor design pattern to obtain a highly configurable and extensible BPEL engine. Using these two techniques, the core of this infrastructural software can be customised to meet new requirements and add features such as debugging, execution monitoring, or changing to another Web Service selection policy. Additionally, it can easily be extended to cope with customer-specific BPEL extensions. We propose the use of dynamic aspects not only on the engine itself but also on the workflow in order to tackle the problems of Web Service hot deployment and hot fixes to long running processes. In this way, composing aWeb Service "on-the-fly" means weaving its choreography interface into the workflow

Traceability and AOSD - From Requirements to Aspects

The traceability question is addressed through the development of a framework to go from requirements to aspects using the Design by Contract methodology. It is demonstrated that by starting at the requirements stage, and specifying an early aspect in the same semi-formal language as the system's existing requirements, we have the basis from which to design the aspects at the implementation stage. The language of pre- and post-conditions is shown to match closely that of aspects, in that pre-conditions match the aspect's pointcut, and the post-condition matches the advice part of the aspect. This thus gives us traceability from 'early aspects' to 'late aspects'. This approach will shed some light on the relationship between requirements and their refinements to pre- and post conditions, and the traceability of requirements in the face of reuse over time. The addition of a new crosscutting requirement is investigated in terms of the framework, demonstrating the relationship between early and late aspects and traceability. The framework promises to help with the design of the late aspects. We propose the concept of relevancy: information in a requirement beyond its specification as pre- and post-conditions, as a way of identifying join points

Taming Aspects with Membranes

International audienceIn most aspect-oriented languages, aspects have an unrestricted global view of computation. Several approaches for aspect scoping and more strongly encapsulated modules have been formulated to restrict this controversial power of aspects. This paper leverages the concept of programmable membranes of Boudol, Schmitt and Stefani, as a means to tame aspects by customizing the semantics of aspect weaving locally. Membranes have the potential to subsume previous proposals in a uniform framework. Because membranes give structure to computation, they enable flexible scoping of aspects; because they are programmable, they enable visibility and safety constraints, both for the advised program and for the aspects. The power and simplicity of membranes open interesting perspectives to unify multiple approaches that tackle the unrestricted power of aspects

Translucid contracts: Expressive specification and modular verification of aspect oriented interfaces

As aspect-oriented (AO) programming techniques become more widely used, their use in critical systems such as aircraft and telephone networks, will become more widespread. However, careful reasoning about AO code seems difficult because: (1) advice may apply in too many places, and (2) standard specification techniques do not limit the control effects of advice. Commonly used black box specification techniques cannot easily specify control effects, such as advice that does not proceed to the advised code. In this work we avoid the first problem by using Ptolemy, a language with explicit event announcement. To solve the second problem we give a simple and understandable specification technique, translucid contracts, that not only allows programmers to write modular specifications for advice and advised code, but also allows them to reason about the code\u27s control effects. We show that translucid contracts support sound modular verification of typical interaction patterns used in AO code. We also show that translucid contracts allow interesting control effects to be specified and enforced

Adopting Architectural Event Modules for Modular Coordination of Multiple Applications

Nowadays, large-scale software systems consist of multiple applications, which interact with each other to fulfill desired system-level requirements. It is usually required to coordinate the interactions of the constituent applications to ensure that the system-level requirements are fulfilled. In this paper, we outline a set of requirements that must be fulfilled to facilitate the modular composition of multiple applications. We introduce the concept of architectural event modules, which are abstractions to represent constituent applications and their coordination logic in a modular and uniform way. We explain the implementation of this concept in the EventReactor language, and define their formal semantics in processing events using the UPPAAL toolset. We illustrate the suitability of architectural event modules in achieving modularity and loose coupling in the composition of multiple applications by means of a case study in the domain of energy-efficient computing

Aspect-Oriented Modularization of Assertion Crosscutting Objects

Software Engineering Conference, 2005. APSEC '05. 12th Asia-PacificDate of Conference:15-17 Dec. 200

Whitepaper: The Value of Improving the Separation of Concerns

Microsoft's enterprise customers are demanding better ways to modularize their software systems. They look to the Java community, where these needs are being met with language enhancements, improved developer tools and middleware, and better runtime support. We present a business case for why Microsoft should give priority to supporting better modularization techniques, also known as advanced separation of concerns (ASOC), for the .NET platform, and we provide a roadmap for how to do so