Cross-cutting Concern Research Articles

Cooperative aspect-oriented programming

Aspect-oriented programming (AOP) seeks to improve software modularity via the separation of cross-cutting concerns. AOP proponents often advocate a development strategy where programmers write the main application (base code), ignoring cross-cutting concerns, and then aspect programmers, domain experts in their specific concerns, weave in the logic for these more specialized cross-cutting concerns. This purely oblivious strategy, however, has empirically been shown to tightly couple aspects to base code in many cases, hindering aspect modularity and reuse. In essence, the more intricate the weaving between the cross-cutting concern and the base code (lexically and/or semantically), the harder it becomes to: (a) robustly specify how to weave the aspects in at the required points, (b) capture interactions between aspects and base code, and (c) preserve the correct weaving as the base code evolves. We propose an alternate methodology, termed cooperative aspect-oriented programming (Co-AOP), where complete lexical separation of concerns is not taken as an absolute requirement. Instead, cross-cutting concerns are explicitly modeled as abstract interfaces through explicit join points (EJPs). Programmers specify where these interfaces interact with base code either through explicit lexical references or via traditional oblivious aspects. This explicit awareness allows base code and aspects to cooperate in ways that were previously not possible: arbitrary blocks of code can be advised, advice can be explicitly parameterized, base code can guide aspects in where to apply advice, and aspects can statically enforce new constraints upon the base code that they advise. These new techniques allow aspect modularity and program safety to increase, and bring us towards a cooperative AOP paradigm. We illustrate our methodology via an example on transactions, and also give an initial evaluation of cooperative AOP through an empirical study on program extensibility comparing both the traditional and cooperative AOP methodologies. Initial results show that cooperative AOP techniques result in code that is less complex with lower overall coupling, facilitating extensibility.

Knowledge-Based AOP Framework for Business Rule Aspects in Business Process

In recent years, numerous studies have identified and explored issues related to web-service-oriented business process specifications, such as business process execution language (BPEL). In particular, business rules are an important cross-cutting concern that should be distinguished from business process instances. In this paper, we present a rule-based aspect oriented programming (AOP) framework where business rule aspects contained in business processes can be effectively separated and executed. This is achieved by using a mechanism of the business rule itself at the business rule engine instead of using existing programming language-based AOP technologies. Through some illustrative examples, this work also introduces a method by which business rule aspects, separated through an external rule engine, can be represented and evaluated. We also demonstrate how they can be dynamically woven and executed by providing an implementation example which uses two open-source-based products, the Mandarax rules engine and Bexee BPEL engine.

Weaving temporal and reliability aspects into a schema tapestry

In aspect-oriented programming (AOP) a cross-cutting concern is implemented in an aspect. An aspect weaver blends code from the aspect into a program’s code at programmer-specified cut points, yielding an aspect-enhanced program. In this paper, we apply some of the concepts from the AOP paradigm to data. Like code, data also has cross-cutting concerns such as versioning, security, privacy, and reliability. We propose modeling a cross-cutting data concern as a schema aspect. A schema aspect describes the structure of the metadata in the cross-cutting concern, identifies the types of data elements that can be wrapped with metadata, i.e., the cut points, and provides some simple constraints on the use of the metadata. Several schema aspects can be applied to a single data collection, though in this paper we focus on just two aspects: a reliability aspect and a temporal aspect. We show how to weave the schema for these two aspects together with the schema for the data into a single, unified schema that we call a schema tapestry. The tapestry guides the construction, interpretation, and validation of an aspect-enhanced data collection.

Building an autonomous vehicle by integrating lego mindstorms and a web cam

There are many possible ways to integrate Lego Mindstorms robots into the standard computer science curriculum. This paper presents a way to use these robots to teach image processing or vision by building an autonomous vehicle. The vehicle uses an off-the-shelf web cam for all of its navigation. Integration of the camera, robot, and controlling computer is discussed, as are the image processing units used, the structure of a state machine controlling them, and the cross-cutting concern of reducing both input and output noise throughout all aspects of the project.

A Case Study of Development of a Java Bytecode Analyzer Framework Using AspectJ

Aspect-orientation is a new programming paradigm that can localize a cross-cutting concern in a single module. This paper proposes a new type of Java bytecode analyzer framework based on aspect-orientation. It includes several new design and implementation techniques that are general or specific to the domain of language systems. We also observe that aspect-orientation improves extensibility, type safety, execution efficiency, and simplicity of the API, when compared with existing analyzer frameworks based on object-orientation such as Soot. This paper reports the following: structural extension of elementary objects maintaining type safety and execution efficiency; separation of a bytecode parser and concrete instruction sets; a visitor based on the stack-machine model; binary operations that are simple, extensive, and easy to maintain; and separation of nonfunctional concerns such as verification. We also observe that AspectJ currently has two limitations: it is not sufficiently expressive to structure aspects strongly depending on the inner structure; and it does not provide a general approach to write advice that cannot be described with information of its pointcut only.

Re-engineering Security as a Crosscutting Concern

Re-engineering Security as a Crosscutting Concern