In program profiling to assess test set adequacy, a challenge is to select code to be included in the assessment. Current mechanisms are coarse-grained; biased to dominant modularizations; require tedious, error-prone manual selection; and leave tester intent implicit in inputs to testing tools. Aspect-oriented constructs promise to improving testing in two ways: by improving our ability to select the code to include in adequacy criteria, and by documenting selection intentions in declarative form in the code itself. One problem is that current join point models do not reveal program behavior in enough detail to support white-box coverage analysis. Our contribution is the formulation, prototyping, and evaluation of a language-and-tool-based approach to white-box coverage adequacy analysis that we call concern coverage. We develop and evaluate one instance of the general idea in which branches, in particular, are exposed as join points to support branch coverage analysis of crosscutting concerns. Our results are consistent with the claim that the idea has the potential to improve test coverage analysis. Categories and Subject Descriptors D.2.5 [Testing and Debugging]: Testing tools – code coverage analysis, testing. D.3.3 [Programming Languages]: Language constructs and features – generalized join point model, generalized advice.

This paper presents some of the experiences made with AOP. In an object oriented C++ framework, aspects have been identified which now have been separated from the components of the framework. In this paper, the focus is on life-cycle control aspects when applying the Command Processor pattern. Because no weaver technology was available, preprocessor macros were used. They simulate both operation and statement-level join points. Making the aspects of the code explicit yielded positive results. Introduction Recently, I came across AOP and wanted to evaluate the idea. Even more, after having read a couple of papers I wanted to profit from AOP immediately, although I am a novice in AOP. From experience it was well known, that the API of a framework never reflected the internal complexity. Growing complexity meant to make relationships among components more complex and/or put more and more code into methods that actually already did their job. The latter option often seemed to allow hig...

One of the newer programming paradigms are aspect-oriented programming where a program is written as a collection of program aspects (source code pieces) which with the help of an aspect weaver is woven to a complete program to be executed [KLM + 97]. An aspect is a design decision that manifests itself by program code that is tangled into the source

We will give some background for AOP. We will present a design philosophy for using aspects on top of an object-oriented paradigm. We will discuss alternative paradigms to which AOP might apply.

This paper presents some of the experiences made with AOP and AspectJ^TM. They got employed for supporting an existing tool for testing and monitoring of distributed systems (TOMDIS). Reusable aspects were defined to attach the Java instrumentation library to application code efficiently and at minimal costs. Some instrumentation requirements, the aspects and their implementation in AspectJ are presented. Not all requirements have been fulfilled by the aspect implementations because outgoing calls cannot be intercepted in AspectJ. This is regarded a lack of symmetry for join point definitions, limitations are presented and discussed. Introduction The goal of attaching a test and monitoring tool to an application is to make calls visible. The tool then can show where a call started and who was called. Details like method and class name and call parameters might be available also. The goal of using aspects and AspectJ^TM [4] is to achieve efficient, flexible and reversible instrumenta...

Component integration creates value by automating the costly and error-prone task of imposing desired behavioral relationships on components manually. Requirements for component integration, however, complicate software design and evolution in several ways: first, they lead to coupling among components; second, the code that implements various integration concerns in a system is often scattered over and tangled with the code implementing the component behaviors. Straightforward software design techniques map integration requirements to scattered and tangled code, compromising modularity in ways that dramatically increase development and maintenance costs.