Support for the incremental design of aspects themselves has been neglected, even as the use of aspects in conjunction with underlying systems is gaining acceptance. The ways in which aspects can cooperate or interfere with each other need to be made ...

Support for the incremental design of aspects themselves has been neglected, even as the use of aspects in conjunction with underlying systems is gaining acceptance. The ways in which aspects can cooperate or interfere with each other need to be made explicit at the design level. An aspect architecture, a new software architecture viewtype, is proposed, and its general principles are explained. An instantiation for extending UML is described, where designs of aspects provide maximal flexibility, and a new concern diagram is provided to show how aspects can be combined to treat different concerns of a system. An example shows aspect architecture views of a digital sound recorder.

An effective requirements engineering (RE) approach must harmonise the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. Techniques such as use cases and viewpoints help achieve separation of ...

An effective requirements engineering (RE) approach must harmonise the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. Techniques such as use cases and viewpoints help achieve separation of stakeholders' concerns but ensuring their consistency with global requirements and constraints is largely unsupported. In this paper we propose an approach to modularise and compose such crosscutting, aspectual requirements. The approach is based on separating the specification of aspectual requirements, non-aspectual requirements and composition rules in modules representing coherent abstractions and following welldefined templates. The composition rules employ informal, and often concern-specific, actions and operators to specify how an aspectual requirement influences or constrains the behaviour of a set of non-aspectual requirements. We argue that such modularisation makes it possible to establish early trade-offs between aspectual requirements hence providing support for negotiation and subsequent decision-making among stakeholders. At the same time early separation of crosscutting requirements facilitates determination of their mapping and influence on artefacts at later development stages. A realisation of the proposed approach, based on viewpoints and the eXtensible Markup Language (XML), supported by a tool called ARCaDe and a case study of a toll collection system is presented.

In this paper we introduce a novel aspect oriented implementation language, called JAsCo. JAsCo is tailored for component based development and the Java Beans component model in particular. The JAsCo language introduces two concepts: aspect beans and ...

In this paper we introduce a novel aspect oriented implementation language, called JAsCo. JAsCo is tailored for component based development and the Java Beans component model in particular. The JAsCo language introduces two concepts: aspect beans and connectors. An aspect bean describes behavior that interferes with the execution of a component by using a special kind of inner class, called a hook. The specification of a hook is context independent and therefore reusable. A connector on the other hand, is used for deploying one or more hooks within a specific context. To implement the JAsCo language, we propose a new "aspect-enabled' component model, which contains build-in traps that enable to interfere with the normal execution of a component. The JAsCo component model is backward-compatible with the Java Beans component model. Furthermore, the JAsCo component model allows very flexible aspect application, adaptation and removal at run-time. The necessary tool support for the JAsCo approach has been implemented. In addition, we present a performance assessment of our current implementation.

Aspects are a novel programming language feature, to express concerns in program design that crosscut traditional abstraction boundaries. The focus of this paper are dynamic aspects. Such aspects are specified as pointcut designators (patterns ...

Aspects are a novel programming language feature, to express concerns in program design that crosscut traditional abstraction boundaries. The focus of this paper are dynamic aspects. Such aspects are specified as pointcut designators (patterns in the call stack), coupled with advice (code whose execution is triggered by the given pattern). We propose a more primitive syntax for pointcut designators, based on regular expressions. This primitive syntax facilitates a new static analysis that in turn enables a more efficient implementation of aspects.

We define a generic join point model for checking the Law of Demeter (LoD). Join points are trees, pointcuts are predicates over join points, and advice is checked statically similar to how declare warning is checked in AspectJ. We illustrate how the ...

We define a generic join point model for checking the Law of Demeter (LoD). Join points are trees, pointcuts are predicates over join points, and advice is checked statically similar to how declare warning is checked in AspectJ. We illustrate how the joint point form is mapped to the object and class forms of LoD, and provide an implementation in AspectJ that approximates LoD's class form by dynamically checking a particular execution using only the join points' static part. The paper proposes two ways to extend AspectJ to provide access to lexical join points directly. The first proposes statically executable advice and pointcut designators over lexical join points. The second proposes statically executable meta-advice over the exposed abstract syntax tree of the program and using Demeter style traversals to mirror AspectJ pointcuts.

The FreeBSD operating system more than doubled in size between version 2 and version 4. Many changes to primary modularity are easy to spot at a high-leveL For example, new device drivers account for 38% of the growth. Not surprisingly, changes to crosscutting ...

The FreeBSD operating system more than doubled in size between version 2 and version 4. Many changes to primary modularity are easy to spot at a high-leveL For example, new device drivers account for 38% of the growth. Not surprisingly, changes to crosscutting concerns are more difficult to track. In order to better understand how an aspect-oriented implementation would have fared during this evolution, we introduced several aspects to version 2 code, and then rolled them forward into their subsequent incarnations in versions 3 and 4 respectively. This paper describes the impact evolution had on these concerns, and provides a comparative analysis of the changes required to evolve the tangled versus aspect-oriented implementations.Our results show that for the concerns we chose, the aspect-oriented implementation facilitated evolution in four key ways: (1) changes were better localized, (2) configurability was more explicit, (3) redundancy was reduced, and (4) extensibility aligned with an aspect was more modular. Additionally, we found that the aspect-oriented implementation had negligible impact on performance.

A crosscut language is used to describe at which points an aspect crosscuts a program. An important issue is how these points can be captured using the crosscut language without introducing tight coupling between the aspect and the program. Such tight ...

A crosscut language is used to describe at which points an aspect crosscuts a program. An important issue is how these points can be captured using the crosscut language without introducing tight coupling between the aspect and the program. Such tight coupling harms the evolvability of the program and the reusability of the aspect. Current pattern-based capturing already offers a certain decoupling between aspects and the program but it may still suffer from what we call the arranged pattern problem. In this paper, we discuss this problem and present a logic-based crosscut language from which we distill what language features are beneficial to avoid this problem.

We present aspect-oriented programming in Jiazzi. Jiazzi enhances Java with separately compiled, externally linked code modules called units. Units can act as effective "aspect" constructs with the ability to separate crosscutting concern code ...

We present aspect-oriented programming in Jiazzi. Jiazzi enhances Java with separately compiled, externally linked code modules called units. Units can act as effective "aspect" constructs with the ability to separate crosscutting concern code in a non-invasive and safe way. Unit linking provides a convenient way for programmers to explicitly control the inclusion and configuration of code that implements a concern, while separate compilation of units enhances the independent development and deployment of the concern. The expressiveness of concern separation is enhanced by units in two ways. First, classes can be made open to the addition of new behavior, fields, and methods after they are initially defined, which enables the direct modularization of concerns whose code crosscut object boundaries. Second, the signatures of methods and classes can also be made open to refinement, which permits more aggressive modularization by isolating the naming and calling requirements of a concern implementation.

Aspect-oriented software development allows the programmer to identify and treat separately concerns that, subsequently, can be woven to different target applications. For this, aspect-oriented languages like AspectJ and Hyper/J provide mechanisms for ...

Aspect-oriented software development allows the programmer to identify and treat separately concerns that, subsequently, can be woven to different target applications. For this, aspect-oriented languages like AspectJ and Hyper/J provide mechanisms for defining and composing such crosscutting concerns. An introduction is a mechanism for defining certain static crosscutting concerns, i.e., concerns that affect the type of the application they are woven to. This paper discusses the implementations of introductions in AspectJ and Hyper/J and reveals their limitations by presenting typical examples of static crosscutting code that cannot be handled adequately by them. To solve these deficiencies we will present the concept of parametric introduction, which are introductions that rely on parameters that are evaluated during weavetime.

Join point interception (JPI), is considered an important cornerstone of aspect-oriented languages. However, we claim that JPI alone does not suffice for a modular structuring of aspects. We propose CAESAR, a model for aspect-oriented programming ...

Join point interception (JPI), is considered an important cornerstone of aspect-oriented languages. However, we claim that JPI alone does not suffice for a modular structuring of aspects. We propose CAESAR, a model for aspect-oriented programming with a higher-level module concept on top of JPI, which enables reuse and componentization of aspects, allows us to use aspects polymorphically, and introduces a novel concept for dynamic aspect deployment.

Recent developments in service architectures suggest that run-time adaptations could be implemented with dynamic AOP. In this paper we discuss application requirements on run-time AOP support and present a system that addresses these requirements. We ...

Recent developments in service architectures suggest that run-time adaptations could be implemented with dynamic AOP. In this paper we discuss application requirements on run-time AOP support and present a system that addresses these requirements. We provide basic support for weaving using the Just-In-Time compiler, while the AOP system is treated as an exchangeable module on top of the basic support. This approach allows us to provide low run-time overhead, AOP system flexibility, and secure weaving. We provide an extensive empirical evaluation and discuss the tradeoffs resulting from using the JIT compiler and a modularized architecture.

Given the high proportion of HTTP traffic in the Internet, Web caches are crucial to reduce user access time, network latency, and bandwidth consumption. Prefetching in a Web cache can further enhance these benefits. For the best performance, however, ...

Given the high proportion of HTTP traffic in the Internet, Web caches are crucial to reduce user access time, network latency, and bandwidth consumption. Prefetching in a Web cache can further enhance these benefits. For the best performance, however, the prefetching policy must match user and Web application characteristics. Thus, new prefetching policies must be loaded dynamically as needs change.Most Web caches are large C programs, and thus adding one or more prefetching policies to an existing Web cache is a daunting task. The main problem is that prefetching concerns crosscut the cache structure. Aspect-oriented programming is a natural technique to address this issue. Nevertheless, existing approaches either do not provide dynamic weaving, incur a high overhead for invocation of dynamically loaded code, or do not target C applications. In this paper we present μ-Dyner, which addresses these issues. In particular, μ-Dyner provides a low overhead for aspect invocation, that meets the performance needs of Web caches.

Persistence - the storage and retrieval of application data from secondary storage media - is often used as a classical example of a crosscutting concern. It is widely assumed that an application can be developed without taking persistence requirements ...

Persistence - the storage and retrieval of application data from secondary storage media - is often used as a classical example of a crosscutting concern. It is widely assumed that an application can be developed without taking persistence requirements into consideration and a persistence aspect plugged in at a later stage. However, there are no real world examples showing whether persistence can in fact be aspectised and, if so, can this be done in a manner that promotes reuse and is oblivious to the application. In this paper, we provide an insight into these issues drawing upon our experience with a classical database application: a bibliography system. We argue that it is possible to aspectise persistence in a highly reusable fashion, which can be developed into a general aspect-based persistence framework. Nevertheless, application developers can only be partially oblivious to the persistent nature of the data. This is because persistence has to be accounted for as an architectural decision during the design of data-consumer components. Furthermore, designers of such components also need to consider the declarative nature of retrieval mechanisms supported by most database systems. Similarly, deletion requires explicit attention during application design as mostly applications trigger such an operation.

Middleware technologies such as Web Services, CORBA and DCOM have been very successful in solving distributed computing problems for a large family of application domains. As middleware systems are getting widely adopted and more functionally mature, ...

Middleware technologies such as Web Services, CORBA and DCOM have been very successful in solving distributed computing problems for a large family of application domains. As middleware systems are getting widely adopted and more functionally mature, it is also increasingly difficult for the architecture of middleware to achieve a high level of adaptability and configurability, due to the limitations of traditional software decomposition methods. Aspect oriented programming has brought us new design perspectives because it permits the superimpositions of multiple abstraction models on top of one another. It is a very powerful technique in separating and simplifying design concerns. In this paper, we first show that, through the quantification of aspects in the legacy implementations, the modularity of middleware architecture is greatly hindered by the ubiquitous existence of tangled logic. We then go one step further by factoring out a number of aspects identified in the mining work and re-implementing them as aspect programs. The aspect oriented re-factorization allows us to apply a set of software engineering metrics to quantify the changes of the re-factored system in both the structural complexity and the runtime performance. The aspect oriented re-factoring proves that the aspect oriented programming is capable of composing orthogonal design requirements. The final "woven" system is able to correctly provide both the fundamental functionality and the "aspectized" functionality with negligible overhead and a leaner architecture. Further more, the configurability of middleware is dramatically increased because the "aspectized" features can be configured in and out during the compile-time

From the early days of object-oriented programming, the model-view-controller paradigm has been pursued for a clear design which separates different responsibilities within an interactive application. In contrast to its untyped implementation in Smalltalk, ...

From the early days of object-oriented programming, the model-view-controller paradigm has been pursued for a clear design which separates different responsibilities within an interactive application. In contrast to its untyped implementation in Smalltalk, any implementation in a statically typed language involves certain trade-offs which either blur the clear structure, destroy the intended independence, or introduce undue administrative overhead. Each alternative creates a different caricature of the originally crisp architecture. The programming model Object Teams provides a new modeling unit called Team plus a number of binding mechanisms by which a Team and its contained roles can be bound to existing parts of an application. It turns out that these mechanisms fit nicely for implementing a clear model-view-controller design not only for single elements but also for complex structures of GUI elements plus their binding to complex model structures. We furthermore propose to use the model-view-controller paradigm as a benchmark for AOSD approaches, since it combines a set of typical problems concerning the separation and integration of concerns.

There are two important points of view on inclusion or subtype polymorphism in object-oriented programs, namely polymorphic access and dynamic dispatch. These features are essential for object-oriented programming, and it is worthwhile to consider whether ...

There are two important points of view on inclusion or subtype polymorphism in object-oriented programs, namely polymorphic access and dynamic dispatch. These features are essential for object-oriented programming, and it is worthwhile to consider whether they are supported in aspect-oriented programming (AOP). In AOP, pieces of crosscutting behavior are extracted from the base code and localized in aspects, losing as a result their polymorphic capabilities while introducing new and unexplored issues. In this paper, we explore what kinds of polymorphism AOP languages should support, using AspectJ as the basis for the presentation. The results are not exclusive to AspectJ---aspectual polymorphism may make aspects in any comparable AOSD language more expressive and reusable across programs, while preserving safety.

Aspect-oriented software design will need to support languages with first-class and higher-order procedures, such as Python, Perl, ML and Scheme. These language features present both challenges and benefits for aspects. On the one hand, they force the ...

Aspect-oriented software design will need to support languages with first-class and higher-order procedures, such as Python, Perl, ML and Scheme. These language features present both challenges and benefits for aspects. On the one hand, they force the designer to carefully address issues of scope that do not arise in first-order languages. On the other hand, these distinctions of scope make it possible to define a much richer variety of policies than first-order aspect languages permit.In this paper, we describe the subtleties of pointcuts and advice for higher-order languages, particularly Scheme. We then resolve these subtleties by alluding to traditional notions of scope. In particular, programmers can now define both dynamic aspects traditional to AOP and static aspects that can capture common security-control paradigms. We also describe the implementation of this language as an extension to Scheme. By exploiting two novel features of our Scheme system---continuation marks and language-defining macros---the implementation is lightweight and integrates well into the programmer's toolkit.

Strategic programming is a generic programming idiom for processing compound data such as terms or object structures. At the heart of the approach is the separation of two concerns: basic dataprocessing computations vs. traversal schemes. Actual traversals ...

Strategic programming is a generic programming idiom for processing compound data such as terms or object structures. At the heart of the approach is the separation of two concerns: basic dataprocessing computations vs. traversal schemes. Actual traversals are composed by passing the former as arguments to the latter. Traversal schemes can be defined by the strategic programmer using a combinator style that relies on primitives for layered traversal.In this paper, we take a look at strategic programming from an aspect-oriented programming perspective. Throughout the paper, we compare strategic programming with adaptive programming, which is a well-established aspectual approach to the traversal of object structures. We start from the observation that aspect-oriented programming terms, e.g., crosscutting, join point, and advice can be instantiated for aspectual traversal approaches.

A development task related to a crosscutting concern is challenging because a developer can easily get lost when exploring scattered elements of code and the complex tangle of relationships between them. In this paper we present a source browsing tool ...

A development task related to a crosscutting concern is challenging because a developer can easily get lost when exploring scattered elements of code and the complex tangle of relationships between them. In this paper we present a source browsing tool that improves the developer's ability to work with crosscutting concerns by providing better support for exploring code. Our tool helps the developer to remain oriented while exploring and navigating across a code base. The cognitive burden placed on a developer is reduced by avoiding disorienting view switches and by providing an explicit representation of the exploration process in terms of exploration paths. While our tool is generally useful, good navigation support is particularly important when exploring crosscutting concerns.

Aspect-oriented software development (AOSD) has primarily focused on linguistic and meta-linguistic mechanisms for separating concerns in program source. However, the kinds of concern separation and complexity management that AOSD endeavors to achieve ...

Aspect-oriented software development (AOSD) has primarily focused on linguistic and meta-linguistic mechanisms for separating concerns in program source. However, the kinds of concern separation and complexity management that AOSD endeavors to achieve are not the exclusive province of programming language design.In this paper, we propose a new model of concern separation called visual separation of concerns (VSC), which is based on a new model of program storage. By altering the mechanisms used to store and manipulate program artifacts, much of the capability of concern separation can be captured without performing any linguistic transformations. We also describe our implementation of VSC, which is based on Stellation, an experimental software configuration management system. The VSC approach combined with software configuration management can have advantages over conventional approaches by avoiding program transformations, by providing persistent storage of features such as concern maps, and by enabling new techniques for concern identification and manipulation.