Runtime aspect weaving through metaprogramming

technical reportWe describe an extension to the Java language, Handi-Wrap, that supports weaving aspects into code at runtime. Aspects in Handi-Wrap take the form of method wrappers, which allow aspect code to be inserted around method bodies like advice in AspectJ. Handi- Wrap offers several advantages over static aspect languages such as AspectJ. First, aspects can be woven into binary libraries. Second, a wrapper in Handi-Wrap is a first-class Java value, which allows users to exploit Java mechanisms to define and weave wrappers. For example, wrappers can be passed explicit constructor arguments, and wrapper objects can be composed. Finally, methods in all Java classes, including anonymous classes, can be wrapped. A prototype of Handi-Wrap is implemented in a compile-time metaprogramming system for Java, called Maya; we briefly describe how Maya?s features support Handi- Wrap

Early aspects: aspect-oriented requirements engineering and architecture design

This paper reports on the third Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design Workshop, which has been held in Lancaster, UK, on March 21, 2004. The workshop included a presentation session and working sessions in which the particular topics on early aspects were discussed. The primary goal of the workshop was to focus on challenges to defining methodical software development processes for aspects from early on in the software life cycle and explore the potential of proposed methods and techniques to scale up to industrial applications

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

Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified Typed Events

Implicit invocation (II) and aspect-oriented (AO) languages provide software designers with related but distinct mechanisms and strategies for decomposing programs into modules and composing modules into systems. II languages have explicitly announced events that run registered observer methods. AO languages have implicitly announced events that run method-like but more powerful advice. A limitation of II languages is their inability to refer to a large set of events succinctly. They also lack the expressive power of AO advice. Limitations of AO languages include potentially fragile dependence on syntactic structure that may hurt maintainability, and limits on the available set of implicit events and the reflective contextual information available. Quantified, typed events, as implemented in our language Ptolemy, solve all these problems. This paper describes Ptolemy and explores its advantages relative to both II and AO languages

Specifying design rules in aspect-oriented systems

Programação Orientada a Aspectos é conhecida como uma técnica para modularização de interesses transversais. Entretanto, construções que visam apoiar a modularidade transversal podem quebrar a modularidade de classe. Como consequência, os desenvolvedores de classes enfrentam problemas de modificabilidade, desenvolvimento em paralelo e entendimento, porque precisam estar conscientes da implementação dos aspectos sempre que forem desenvolver ou dar manutenção em uma classe. Ao mesmo tempo, aspectos são vulneráveis a mudanças nas classes, já que não existe um contrato especificando os pontos de interação entre estes elementos. Estes problemas podem ser mitigados através de Regras de Projeto entre classes e aspectos. Nós apresentamos uma linguagem para especificação de Regras de Projeto (LSD) e exploramos seus benefícios desde as fases iniciais do processo de desenvolvimento, especialmente com o objetivo de dar apoio ao desenvolvimento modular de classes e aspectos. Nós discutimos como nossa linguagem melhora a modularidade transversal sem quebrar a modularidade de classe. Além disso, especificamos a semântica da linguagem em Alloy. A linguagem é implementada através de uma extensão do abc (AspectBench Compiler), tornando mais fácil expressar e checar muitas das Regras de Projeto encontradas em sistemas Orientados a Aspectos. Nós avaliamos LSD usando o sistema Health Watcher como estudo de caso e comparamos com abordagens existentes._________________________________________________________________________________________ ABSTRACT: Aspect-Oriented Programming is known as a technique for modularizing crosscutting concerns. However, constructs aimed to support crosscutting modularity might actually break class modularity. As a consequence, class developers face changeability, parallel development and comprehensibility problems, because they must be aware of aspects whenever they develop or maintain a class. At the same time, aspects are vulnerable to changes in classes, since there is no contract specifying the points of interaction amongst these elements. These problems can be mitigated by using adequate Design Rules between classes and aspects. We present a Design Rule specification language (LSD) and explore its benefits since the initial phases of the development process, specially with the aim of supporting modular development of classes and aspects. We discuss how our language improves crosscutting modularity without breaking class modularity. Besides, we specify the language semantics in Alloy. The language is implemented through an extension of abc (AspectBench Compiler), making it easy to express and check most of the Design Rules found in Aspect-Oriented systems. We evaluate the language using the Health Watcher system as case study and compare it with existent approaches

AOP++: A Generic Aspect-Oriented Programming Framework in C++

Abstract. This paper presents AOP++, a generic aspect-oriented pro-gramming framework in C++. It successfully incorporates AOP with object-oriented programming as well as generic programming naturally in the framework of standard C++. It innovatively makes use of C++ templates to express pointcut expressions and match join points at com-pile time. It innovatively creates a full-fledged aspect weaver by using template metaprogramming techniques to perform aspect weaving. It is notable that AOP++ itself is written completely in standard C++, and requires no language extensions. With the help of AOP++, C++ programmers can facilitate AOP with only a little effort.

Towards Multi-Paradigm Software Development

Multi-paradigm software development is a possible answer to attempts of finding the best paradigm. It was present in software development at the level of intuition and practiced as the “implementation detail” without a real support in design. Recently it is making a twofold breakthrough: several recent programming paradigms are encouraging it, while explicit multi-paradigm approaches aim at its full-scale support. In order to demonstrate this, a survey of selected recent software development (programming) paradigms (aspect-oriented approaches and generative programming) and multiparadigm approaches (multi-paradigm programming in Leda, multi-paradigm design in C++, and intentional programming) is presented. The survey is preceded and underpinned by the analysis of the concept of paradigm in computer science in the context of software development, since there is no common agreement about the meaning of this term, despite its wide use. The analysis has showed that there are two meanings of paradigm: large-scale and small-scale