a test driven approach for aspectualizing legacy software using mock systems

Available online at www.sciencedirect.com

www.elsevier.com/locate/infsof

Information and Software Technology 50 (2008) 621–640

A test driven approach for aspectualizing legacysoftware using mock systems

Michael Mortensen a,*, Sudipto Ghosh b, James M. Bieman b

a Hewlett-Packard, 3404 E. Harmony Rd MS 88, Fort Collins, CO 80528, United Statesb Computer Science Department, Colorado State University, Fort Collins, CO 80523-1873, United States

Received 21 December 2006; received in revised form 17 May 2007; accepted 5 June 2007Available online 16 June 2007

Abstract

Aspect-based refactoring, called aspectualization, involves moving program code that implements cross-cutting concerns into aspects.Such refactoring can improve the maintainability of legacy systems. Long compilation and weave times, and the lack of an appropriatetesting methodology are two challenges to the aspectualization of large legacy systems. We propose an iterative test driven approach forcreating and introducing aspects. The approach uses mock systems that enable aspect developers to quickly experiment with differentpointcuts and advice, and reduce the compile and weave times. The approach also uses weave analysis, regression testing, and code cov-erage analysis to test the aspects. We developed several tools for unit and integration testing. We demonstrate the test driven approach inthe context of large industrial C++ systems, and we provide guidelines for mock system creation.� 2007 Elsevier B.V. All rights reserved.

Keywords: Mock systems; Aspect-oriented programming; Legacy systems; Refactoring; Testing

1. Introduction

Aspect-oriented programming provides a new construct,an aspect, that can modularize scattered and tangled(termed cross-cutting) code. Replacing cross-cutting codewith aspects can improve the design structure of legacy sys-tems [16,34]. The use of aspects in a refactored aspectual-

ized system helps modularize cross-cutting code concerns.As with any refactoring technique, a systematic approachto testing is needed to check that new faults are not intro-duced [11].

In an aspect-oriented program, cross-cutting concernsare modularized into aspects. The aspects are woven intothe primary code by a preprocessor, compiler, or run-timesystem. An aspect includes advice, which is the functional-ity to be woven in, and a point-cut, which identifies the

0950-5849/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2007.06.002

* Corresponding author.E-mail addresses: [email protected] (M. Mortensen),

[email protected] (S. Ghosh), [email protected] (J.M.Bieman).

locations in the primary code, called joinpoints, where theadvice is inserted. Advice specifies when it executes: before

advice executes before the joinpoint, after advice executesafter the joinpoint, and around advice executes instead ofa joinpoint [19]. Around advice can either bypass or exe-cute the code represented at the joinpoint. Aspect lan-guages such as AspectJ [3] and AspectC++1 [12] offer aset of pattern-matching mechanisms to match advice tojoinpoints. We use AspectC++ in this work, since we arerefactoring legacy C++ systems.

This paper introduces the use of mock systems to aid inaspectualization of a system. Developers develop and testaspects within the small mock system, which can be quicklywoven and compiled. After testing aspects in the mock sys-tem, we weave them with the real system. Our approachuses the testing of aspects with mock systems as unit testingand the testing of the real system as a form of integrationtesting. We apply coverage criteria to test the aspects,

1 www.aspectc.org

mailto:[email protected]



http://www.aspectc.org

622 M. Mortensen et al. / Information and Software Technology 50 (2008) 621–640

and use existing system regression tests for integration test-ing. We use information generated during weaving to auto-mate this approach, and we demonstrate the approach byaspectualizing large C++ systems using AspectC++.

The remainder of this paper is structured as follows.Section 2 summarizes related background work. We pres-ent our test driven approach in Section 3 and describenew tools to find faults and analyze coverage in Section4. In Section 5, we describe aspects that we developed torefactor legacy systems using mock systems. Section 6presents a set of guidelines for creating mock systems.We evaluate the feasibility of our approach in Section7. Conclusions and future work are described inSection 8.

2. Background

We summarize related work on aspect mining and refac-toring, test driven development, and testing of aspect-ori-ented programs.

2.1. Aspect mining and refactoring

Aspectualizing involves finding cross-cutting code, in aprocess called aspect mining, followed by refactoring.

Coady and Kiczales [8] refactor legacy operating sys-tems written in C to use aspects. Two main criteria identifythe aspects: intent and program structure. They report thatusing aspects helps to localize changes, reduces redun-dancy, and improves modularity. These benefits are real-ized with negligible performance impact.

Lohmann et al. [26] use aspects to implement cross-cut-ting architectural decisions, such as synchronization poli-cies and power usage that affect many modules in asystem, to improve modularity and allow architecturalflexibility.

Hannemann et al. [17] refactor cross-cutting concerns byidentifying roles performed by system components. Rolesare mapped to design patterns and aspects using a tool thatautomates the transformation of the system into anAspectJ-based system. Rather than identify componentroles, we examine the code for scattered code fragments.

One use for aspects is to modularize framework-relatedcode in applications that use frameworks. Our intent issimilar to that of Ghosh et al. [13], who differentiatebetween business logic and code that interacts with middle-ware services, and implement middleware-related code withaspects.

Tonella and Ceccato [34] empirically assess aspectizableinterfaces in the Java Standard Library. They use aspectsto implement secondary concerns of classes and interfacessuch as serializability or participation in a role of a designpattern (e.g. observable). They report that using aspectsimproves maintainability and understandability. We alsoseek to implement secondary concerns as aspects, but ourrefactoring is done within applications rather than in aframework or library.

Marin et al. [28] identify and use fine-grained refactoring

types to identify and classify refactorings. A refactoringtype documents a concern’s intent, its typical idiomaticimplementation without aspects, and an aspect-orientedmechanism to implement the concern. We also identifyaspects based on intent and idiomatic implementation.

Clone detection techniques [5] can also identify cross-cutting concerns. Bruntink et al. [6] evaluate the effective-ness of clone detection software in identifying cross-cuttingconcerns in legacy C software, and report that error-han-dling code and parameter checking code were easiest toautomatically identify.

2.2. Test driven development

Test Driven Development (TDD) is a software processin which unit tests are written before the functional codeis written. A key goal of TDD is that all code has associ-ated tests. To emulate a complex system dependency, testdriven development may use a mock object (or mock) inplace of the real object [4]. Mock objects are similar tostubs used in testing, but emulate a class or interface, andmay provide some basic checking, such as the validity ofargument values.

We use two key ideas from test driven development:mock objects and the use of tests to drive refactoring. Weextend the concept of mock objects to create mock systems,providing a context for creating and unit testing aspects.We weave aspects into the mock systems to develop themthrough iterative unit testing, which increases confidencein aspects introduced into a real system.

2.3. Testing aspect-oriented programs

Douence et al. [9] explore techniques to reason about orspecify aspect-oriented systems to better understand theeffects of aspects on the system. In general, complete veri-fication of aspect behavior is not practical. Thus, we focuson improved testing techniques.

Alexander et al., [1] describe a key problem related totesting aspects: aspects depend on weaving and do not existindependently, and are often tightly coupled to the contextto which they are woven. Thus, aspects cannot be unittested in isolation, but can only be tested in conjunctionwith the core concerns that they are woven with. We usemock systems, weaving aspects with the mock concernsand using mock concern method calls to provide unit test-ing of the woven functionality.

Aspect-oriented programming can also introduce newfaults, by way of faulty advice code or faulty pointcuts[1]. Existing AOP testing approaches focus on aspect-spe-cific faults [22,29], or on coverage criteria to provide ade-quate testing of aspects in the context of a system.Proposed coverage criteria for aspects are based on data-flow coverage [37], path coverage [23], and state-based cov-erage [36]. Dataflow and path coverage require programanalysis that is beyond the scope of our work. Our legacy

1. Identify crosscutting concern

Develop mock system

Prototype aspect

Unit test

Remove crosscutting code from real system

[all tests passed]

Weave aspects with real system and compile

4. Run regression tests

[unit test failed]

[regression test failed]

[all tests passed]

2.

3.

Fig. 1. Steps for our approach.

M. Mortensen et al. / Information and Software Technology 50 (2008) 621–640 623

systems do not have state diagrams to guide state-basedtesting. However, we do measure coverage of joinpointsmatched by a pointcut, as described in Section 3.2.

Zhou et al. [38] use an incremental testing approach inwhich classes are unit tested, aspects are tested with someclasses, and then aspects are integrated one at a time withthe full system. Test case selection forces the execution ofspecific aspects. Using our approach, iterative test cyclesare applied to the mock system rather than the full system.Rapid iterations are achieved because the mock system andaspects can be compiled and woven in a small fraction ofthe time required to compile and weave the full system.

Lesiecki [24] advocates delegating advice functionalityto classes, so that the classes used by advice can be unittested directly. This is similar to the language approachof JAML [27], which implements aspects as classes thatare woven by XML specifications. Lesiecki uses mockobjects and mock targets to help unit test aspects anduses visual markup in the Eclipse Integrated Develop-ment Environment (IDE) to verify that pointcuts affectedthe expected program points. A mock target is similar toour concept of a mock system. However, a mock targetis created from an aspect to unit test pointcut matching.By contrast, our mock systems are created from the realsystem based on how we expect aspects to be used inthat system.

3. Approach

We use the following steps in our aspectualizationapproach:

(1) Identify cross-cutting concerns and duplicated codein the legacy system that can be realized as an aspect.

(2) Create a small mock system to iteratively develop andunit test a prototype aspect.

(3) Refactor the real system to use the aspect by remov-ing duplicate or cross-cutting code from the systemand then weaving the aspect.

(4) Conduct integration testing of the refactored systemby running the regression tests.

Fig. 1 illustrates the approach. During the first twosteps, developers use the mock system to experiment withseveral aspect pointcut specifications and advice to test thatthey correctly modularize the cross-cutting concerns. Thepointcut specifications must have the correct strength [1]so that they match all (and only) the desired joinpoints inthe mock system.

The mock system mimics the structures that the aspectwill interact with in the real system so that the pointcut willalso work in the real system. We typically create a mocksystem for each aspect. The advice must specify correctbehavior. The aspect is woven with the mock system sothat we can validate advice behavior. After step three isperformed, developers need to test the refactored systemusing pre-existing regression tests.

Creating and debugging aspects often requires devel-opers to iteratively identify, develop, integrate, and testaspects. Thus, the steps may be repeated as needed.Problems encountered during integration may result inchanging an aspect and re-testing within the mocksystem.


3.1. Identifying aspects in legacy systems

The legacy systems described in this paper consist of twoVLSI CAD applications which are both based on a VLSICAD framework [31]. We identify aspects in the systemto factor out scattered identical or similar code, to enablefast debugging, and to provide automatic enforcement ofsystem-wide policies.

Like Coady and Kiczales [8], we use intent and structureas a primary means to identify aspects. We look for fea-tures that cross-cut modules or provide the means (intent)to deal with cross-cutting concerns (such as callbacks andmixins). For example, we identify policies based on thedesign intent of a base class and scattered code in methodsof its subclasses. We also refactor system-wide concernsthat affect performance and architectural decisions suchas caching and system configuration, following theapproach of Lohmann et al. [26].

Just as Ghosh et al. [13] differentiate between applica-tion-specific code and middleware-related code, we useaspects to modularize cross-cutting application code thatuses framework methods and data structures. Since ourexample systems are framework-based, we seek candidateaspects such as code repeated when using the framework,or common idioms associated with parts of the framework.

Due to a lack of appropriate tools for C++ code (sometools support refactoring of Java code [17,34]), we primar-ily rely on manual inspection of source code and simpletextual approaches such as grep to identify aspect candi-dates. Developing automated aspect mining tools is notthe goal of our work.

Because cross-cutting code typically involves many filesand classes, code browsers and Unix utilities such as grephelp to identify similar or related code. Aspect mining toolsthat fully parse a program are a better long term approach[15]. We have begun experimenting with clone detectionsoftware, as Bruntink et al. [6] have done, to evaluate codeclones as potential aspects. Our initial efforts involve theuse of CCFinder [18] to identify code clones in thePowerAnalyzer.

3.2. Using mock systems to create and unit test aspects

In this step we aim to produce aspects with pointcutspecifications and advice that will work correctly in the realsystem. Each identified cross-cutting concern is imple-mented as an aspect. A mock system consists of functionsand classes that implement a simple program with similarprogram structure and behavior as the real system, buton a much smaller scale: hundreds of lines of code (LOC)instead of tens of thousands. A mock system contains join-points that mimic the real system. The pointcuts aredefined to match the mock system structure. We createthe mock system by copying or implementing the subsetof classes, methods, and functions in the real system thatare relevant to an aspect. The methods and functions needonly implement enough functionality for the mock system

to run the test. The mock system may use assertions toaid in unit testing the aspect. Guidelines for this processare in Section 6.

The overall goal of unit testing is to test that (1) thepointcuts have the correct strength and (2) the advice iscorrect. During test execution of the woven mock system,we aim to achieve joinpoint coverage and mock systemstatement coverage. Joinpoint coverage requires executingeach joinpoint that is matched by each aspect. Thus, join-point coverage focuses on testing each aspect in all of thecontexts where it is woven. We use statement coverage toidentify any mock system code that was not executed.

To meet the goal of correct pointcut strength, we ana-lyze the weave results to identify unused advice. In addi-tion, for each advice of each aspect, we annotate somemethods or functions in the mock system to indicatewhether or not they should be advised. We use four typesof annotations: ADVISED, NOT_ADVISED, ADVISED_-BY(name), and NOT_ADVISED_BY(name). These anno-tations express the design intent – whether or not a coreconcern is expected to have advice that matches it. Thename argument can be used to indicate a specific aspectthat should or should not advise a method. We checkwhether the annotated methods had the expected advice(or lack or advice), depending on the annotation. Oneadvantage that our annotations provide is that they arechecked right after weaving, and do not depend on runningthe mock system.

We use three support tools: weave analysis, adviceinstrumentation, and coverage measurement. Weave analy-sis evaluates pointcut strength, while advice instrumenta-tion and coverage analysis check that advice is tested inall contexts (joinpoints), supporting the goal of specifyingcorrect advice.

3.3. Removing cross-cutting code

Once we complete unit testing of the woven mock sys-tem, we apply the aspects to the real system. Refactoringinvolves removing scattered code, and may also involverestructuring or renaming core concerns so that pointcutstatements can match the desired joinpoints in the pro-gram. The aspects are then woven with the refactoredsystem.

The goal of unit testing with the mock system is to avoidchanging an aspect during integration testing. Someaspects, such as caching, define a pointcut as a list of allfunctions to cache. When using the aspect with the real sys-tem, this pointcut must change to reflect each cachedmethod from the real system, but the advice can be testedwithin the mock system.

3.4. Integration testing of refactored system

This step tests whether or not aspectualizing the sys-tem introduces new faults by running existing regressiontest suites. We do not seek 100% statement coverage of


the real systems, since the regression tests do not achievecomplete coverage on our legacy systems even withoutaspects. We use joinpoint coverage to verify that advicethat we are adding has been tested in all executioncontexts, and add regression tests if needed to achievejoinpoint coverage.

If a regression test fails, we determine the root cause ofthe failure. Suspected root causes can be simulated in themock system by emulating the system context that con-tained a fault or that exposed a fault in the aspect. Thisallows us to observe the erroneous behavior in the mocksystem and fix it before we modify, weave, and compilethe real system. During integration testing, any unusedadvice is reported as an error. In addition, annotations(such as Advised and NotAdvised) can be inserted inthe real system to check that aspects advise the intendedcore concerns.

4. Tools

We developed three tools to support our approach:

(1) The Weave analyzer checks for unused advice and forannotation violations.

(2) The Advice instrumenter supports coverage analysis.(3) The Coverage analyzer measures joinpoint coverage

and statement coverage of the mock system.

Our unit and system testing tools support AspectC++,and they leverage features of the AspectC++ weaver.The AspectC++ weaver writes information about theweave results to an XML file for use by IDEs such asEclipse.2 The XML weave file lists the pointcuts and advicefor each aspect, identifying each with a unique numericalidentifier. The weave file lists all source code joinpoints(by line number) that are matched by each pointcut [33].

4.1. Weave analyzer

The weave analyzer parses the XML weave file, whichidentifies the line numbers of joinpoints matched by eachpointcut. Next, it reads the core concern source code tofind the line numbers that have annotations indicatingwhere advice should and should not be woven. Weaveanalysis checks for our four types of annotations:ADVISED, NOT_ADVISED, ADVISED_BY(name), andNOT_ADVISED_BY(name).

By comparing line number information from the XMLweave file with the lines that have annotations, the weaveanalyzer identifies lines of code with one of the followingannotation violations:

(1) Lines with an ADVISED annotation that are notmatched by any pointcut.

2 http://www.eclipse.org

(2) Lines with an ADVISED_BY(name) annotation thatare not matched by a pointcut of the named aspect.

(3) Lines with a NOT_ADVISED annotation that arematched by any pointcut.

(4) Lines with a NOT_ADVISED_BY(name) annotationthat are matched by a pointcut of the named aspect.

For each of these annotation violations, the tool printsthe line of source code and the preceding and succeedinglines to provide context. Checking for annotation viola-tions helps identify pointcut strength errors by flaggingpointcuts that do not match the developer’s intent. TheNOT_ADVISED annotations identify pointcuts that aretoo weak, matching methods the designer did not intend.The ADVISED annotations identify pointcuts that are toostrong (restrictive), missing intended joinpoints.

In addition to checking annotations, the weave analyzerreports any advice whose pointcuts match no program join-points as an error. Unused advice indicates a pointcuterror. Example output of the location and body of unusedadvice that was identified by weave analysis of the Erc-

Checker mock system is shown below:

========================

We have UNUSED advice:

Advice: aspect:0 fid:1 line:18 id:0

type:after lines: 4

========================

File: LogMath.ah aspect: LogExecution

lines: 18-21

advice call("% mth%(. . .)") : after ()

{cerr << " AFTER calling "

<< JoinPoint::signature()

<< endl;

}

When a method with an ADVISED annotation does nothave a matching pointcut, the tool prints the line of sourcecode along with the preceding and succeeding lines. Exam-ple output for a such method is shown below:

========================

We have UNADVISED code: did not find a

Pointcut for Line 13 of file ./main.cc

which was specified as ADVISED

========================

void run_checks() /* AOP=ADVISED */

{

4.2. Advice instrumenter

As part of our build process, we instrument advice toenable the measurement of joinpoint coverage. During exe-cution of the mock or real system, we gather informationabout which aspects were executed, and, for each each

http://www.eclipse.org


aspect, which joinpoints are executed. To gather thisdata, we preprocess the aspects before weaving, andfor each advice body we insert a call to a C++ macro,TEST_TRACE, which we define. This macro produces thefollowing: the aspect filename, the source code line numberof the advice body, and the joinpoint identifier where theaspect is executing.

The aspect filename is determined in C++ by the C++preprocessor directive __FILE__, which is replaced at com-pile-time by the actual name of the file containing the direc-tive. In AspectC++, aspect file names end .ah; file namesare not changed during the weave.

The source code line number of the advice body isinserted as an argument to the macro call that is addedto the advice. Although C++ contains a directive to emitthe actual line number of a statement, __LINE__, the num-ber is determined at compile-time. Since AspectC++ usessource-to-source weaving, the line numbers emitted bythe __LINE__ directive are based on the woven code ratherthan on the source code. The coverage analyzer (describedin Section 4.3) uses the XML weave data, which refers topre-weave source numbers. Thus, we cannot use the__LINE__ directive. Instead, the advice instrumenterembeds the pre-woven line number as a parameter to theTEST_TRACE macro.

To obtain the joinpoint identifier, the TEST_TRACEmacro uses an AspectC++ construct: JoinPoint::JPID,which is an integer that can be accessed within advice code.The integer serves as the joinpoint identifier that was writ-ten to the XML weave file.

4.3. Joinpoint coverage analyzer

We measure joinpoint coverage during both mock andsystem testing. System joinpoint coverage data is calculatedduring regression runs from the instrumented code. Thegenerated data includes the original, pre-weave source codeline number of the advice and the joinpoint ID (available inAspectC++ advice as JoinPoint::JPID). This data iscross-referenced to the XML weave file to identify anyadvised joinpoints that were not executed.

Existing statement coverage tools can check coverage ofall mock code during unit testing. We use gcov

3 on thewoven code, which generates a coverage file for each sourcefile. Statement coverage produced by gcov identifiesmissed core concern code in the mock system. Since themock system is designed to emulate interactions betweenthe aspect and real system and to call methods that willbe advised, we use this coverage to check that we are actu-ally testing all the statements in the mock code.

The gcov output is a copy of the mock system code thatmarks how many times each line was executed. We processthis file to ignore AspectC++-specific aspect definitioncode that gcov incorrectly analyzes. Our coverage ana-

3 http://gcc.gnu.org/onlinedocs/gcc/Gcov.html

lyzer prints out any missed mock system statements fromthis gcov output file. Sample output is shown below:

File QueryPolicy.ah was covered

File main.cc was covered

File query.h had 2 missed lines:

###: 63:this->_exec_old_executeQuery();###: 67:inline void _exec_old_execute

std::cerr << "Executing query

File erc_main.cc had 2 missed lines:

###: 64: cerr << "No LevelManager

###: 65: return;

TotalLinesMissed = 4

The results above indicate that two code fragments werenot used. The first unused code fragment reported (associ-ated with lines 63 and 67 of query.h) refers to a method inthe base class of a mock hierarchy. The method was over-ridden by every child class and thus was never used. Wefixed this by converting it into a pure virtual method inthe base class. The second unused code fragment (lines64–65 of erc_main.cc) represents error-handling codethat was not tested. We covered this fragment by addingcode to the mock system to test the error-handling code.Because the mock system is small and is created to testaspects, we aim for 100% statement coverage of the mocksystem. When using gcov and g++ in the mock system,we do not enable compiler optimizations, avoiding knowninteractions problems between gcov coverage and g++

optimization.Fig. 2 shows the data read in and produced by our tools,

and how the tools use data produced by the AspectC++weaver. The advice instrumenter reads an aspect and addsa call to TEST_TRACE, with the ‘#’ value indicating that anactual line number would be inserted. The weave analyzerreads the C++ source code and XML weave file, and is runafter the code is woven. The coverage analyzer reads theXML weave file and output of the woven system to identifyadvised joinpoints that were not executed.

4.4. Related tool approaches

The AspectC++ weaver may eventually be extended byits developers to identify unused advice as an error whenweaving. Even if such an extended weaver were available,our tools provide other capabilities not offered by theAspectC++ or AspectJ weavers. Our four annotationsenable developers to indicate where they do and do notexpect advice, so that pointcut errors can be caught imme-diately after weaving. These annotations help when creat-ing a pointcut. We also believe they should help duringmaintenance, since changes to core concerns could changethe matching joinpoints.

Laddad [20] shows how to use the declare error

construct in AspectJ to compare two pointcuts (i.e. anold one and a potential new one) to catch errors whena pointcut is changed. His approach does not help

http://gcc.gnu.org/onlinedocs/gcc/Gcov.html

Fig. 2. Using the tools during refactoring.


when a pointcut is initially created, nor does hisapproach compare the matched pointcuts to sourcecode annotations that capture a developer’s intentand expectation.

5. Example mock systems and aspects

We used mock systems to aspectualize two legacy sys-tems at Hewlett-Packard. We now describe the aspects


and mock systems and use them as a running example andfor evaluating our approach. In this section we firstdescribe the two legacy systems. Next, we describe fourtypes of aspects and the mock systems used to developand test them. Our evaluation results are presented in Sec-tion 7.

5.1. The legacy systems

The ErcChecker is a C++ application that consists ofapproximately 80,000 LOC. It performs 59 different electri-cal checks. Each electrical check implements a set of virtualmethods as a subclass of an abstract class ErcQuery. Weuse aspects to modularize the enforcement of two designpolicies related to the ErcQuery subclasses. We use anaspect to implement caching for functions that calculateelectrical properties of objects in the ErcChecker. Theoriginal code had caching functionality scattered in eachof these functions to improve performance.

The PowerAnalyzer is a C++ application containing12,000 LOC that is used to estimate power dissipation ofelectrical circuits. It consists of three smaller tools and alibPower library with some common code. Althoughthe PowerAnalyzer uses an object-oriented framework,and defines and uses C++ classes, much of it is writtenas procedural functions rather than classes and methods.

Both the PowerAnalyzer and ErcChecker makecalls to the object-oriented framework API to create anin-memory graph of instances of classes from the frame-work. The graph represents circuit elements (e.g. transis-tors and capacitors) and the connectivity between thoseelements (called nets or nodes).

5.2. ErcChecker policies

The ErcChecker has two policies that each electricalcheck must implement. The policies represent a set of fea-tures that each electrical check is supposed to provide,which are implemented as scattered code in the create-Queries() method of each ErcQuery subclass.

The first policy aspect, QueryConfigAspect, pro-vides run-time configuration, which allows users to disablequeries at run-time via a configuration file that users canedit. Each createQueries() method has similar codewith the following structure:

static void CLASS::createQueries() {if

(ErcFet::getQueryConfig("CLASS")==eOff){//run-time user config disabled this

query

return;

}//create and evaluate query objects. . .

Calls to ErcFet::getQueryConfig() are almostidentical in each subclass, with the word CLASS above

being replaced by the actual name of each subclass.Because C++ lacks run-time reflection, the createQuer-ies() method uses the class name as a literal string whencalling getQueryConfig().

This policy is always implemented as scattered codewithin the createQueries() method of each ErcQue-

ry subclass. Hence, the pointcut should just be %::cre-

ateQueries(), with the AspectC++ wildcard (%) usedto match createQueries() in all subclasses. The advicecan use the scattered call (the call to getQueryCon-

fig()) and either proceed to the createQueries()

body or return without executing it.The second policy aspect, QueryPolicy, implements

three of the six conceptual steps needed by each query, butwith significant variation between the queries. These steps are:

(1) Call frameworkmethodstoidentifyneededcircuitdata.(2) For each relevant part of the circuit, create an

instance of the query class associated with the check.(3) Call the executeQuery() method on the query

object from step two.(4) Add queries that result in a failure or warning to a

container class.(5) Write the results of executeQuery() to a log file.(6) Delete queries that did not result in a failure or

warning.

Although the first three steps vary significantly betweenthe different subclasses, steps four through six use the sameset of method calls and always follow a call to execute-

Query(). Thus, a single aspect can implement steps fourthrough six as after advice to provide the same function-ality. Since steps four through six always follow a call toexecuteQuery(), the aspect uses executeQuery()

as the pointcut.

5.2.1. Using the mock system for aspect creation and testing

Since both policy aspects use the same class hierarchy,the mock system models the ErcQuery base class andits subclasses. We created a mock ErcQuery class andfour subclasses with method stubs based on different typesof checks, such as transistor-based checks and net-basedchecks. In addition, a driver file (main.cc) creates queryobjects, calls the createQueries() and executeQue-

ry() methods, and reports success or failure. The Level-Manager singleton class stores all objects related tofailures and reports this information, so we need a mockclass for the LevelManager.

The subclasses in the mock system contain only themethod call to be advised and the system methods usedby that method and the advice. In the mock system, thesubclasses of ErcQuery emulate both types of querybehavior: failing due to circuit errors and passing due toerror-free circuits.

With the mock system in place, we created and testedthe QueryConfigAspect and QueryPolicy aspects.The QueryConfigAspect advice executes around each


call to the createQueries() method, and extracts theclass name from the joinpoint information available inAspectC++. The QueryConfigAspect implementationis shown below:

aspect QueryConfigAspect {pointcut createQuery()=execution("%;

%%::createQueries(. . .)");advice createQuery() : around() {string jpName = JoinPoint::signature();

int first_space = jpName.find(’ ’);

int scope_operator = jpName.find("::");

string className=jpName.substr(

first_space+1, scope_operator-first_space-1);

if(ErcFet::getQueryConfig(class-

Name)== eOff)

return; //user config exists, SKIP

tjp->proceed();}

};

The QueryConfigAspect prevents the call to create-

Queries() by only calling proceed() when a configu-ration does not disable a query.

The QueryPolicy aspect uses after advice to imple-ment the last three steps of the query policy for each sub-class. Its AspectC++ implementation is shown below:

aspect QueryPolicy {pointcut exec_query(ErcQuery *query) =

execution("%%::executeQuery(. . .)")&& that(query);

advice exec_query(query) : after(ErcQue-

ry *query)

{if(gReportAll || query->errorGenerat-

ed()) {LevelManager::addQuery(query);

gLog->log()<< "Query error: "

<< " type: "

<< query->getName()<< " start element: "

<< query->getStartName()<< query->getSummary()<< endmsg;

query->logQueryDetails();}else {gLog->log()<< "Query ok: "

<< query->getName()<< endmsg;

query->logQueryDetails();delete query;

}}

};

The QueryPolicy aspect uses the errorGenerated()method to determine if the query that called execute-

Query() found an error. If errorGenerated() returnstrue, then the query is added to the LevelManager,which stores all circuit failures so that the user can viewthem. If errorGenerated() returns false, the advicedeletes the query.

Unit testing for both aspects was driven by code in themock system that created electrical query objects usingour ErcQuery mock classes. We annotated the create-Queries() method of each ErcQuery subclass to checkthat the pointcut matched. Statement coverage of the mocksystem found dead code and an unused mock class method,enabling us to make changes to achieve 100% statementcoverage of the mock system.

5.2.2. Refactoring and integration testing

Introducing the aspects requires removing all code thatis duplicated by the aspect. Since the pointcuts matchedmethods (executeQuery() and createQueries())that are already in the real system, we did not rename orrestructure the code to provide targets for aspects weaving.We encountered three challenges when refactoring to usethe query behavior policy.

The first challenge was that replacing custom text (scat-tered in each query) with an aspect changed the output ofthe program. Regression tests that rely on output logs faildue to the now standardized output. Although the stan-dardization should improve the maintainability of theErcChecker, it does require a one-time update of theexpected test output files.

The second challenge results from the asymmetric natureof aspect-oriented refactoring: removing the scattered codemust be done for each subclass (typically manually), whilethe aspect is woven automatically into all matching sub-classes. The QueryPolicy aspect deletes query objectsthat do not detect electrical errors (step 6 in Section 5.2).During refactoring, if the object deletion code is notremoved from the core concern, both the core concernand the aspect try to delete the same object, resulting in amemory fault. When we manually removed scattered code,we failed to remove the deletion code from one ErcQuerysubclass. Finding the root cause of this defect in the realsystem was difficult because the defect results from aninteraction between the aspect and underlying system,and the woven code can be hard to understand. Once theroot cause was suspected, we created another ErcQueryclass in the mock system that deliberately called delete

outside the aspect to recreate the memory fault.The third challenge was that we did not anticipate some

necessary changes to the real system and aspect when cre-ating the mock system and the aspect. During refactoring,we realized that 18 of the 59 ErcQuery subclasses printedout some additional information between steps five and six,which were implemented by the advice [31]. In order for theaspect to work with all subclasses of ErcQuery, we (1)added an empty method to the base class, (2) refined the


method to contain the logging statements in the subclassesthat needed this feature, and (3) modified the advice to callthe new method. We made these change to the ErcQueryclass hierarchy and aspect in the mock system. We testedthe changes in the mock system, made the changes to thereal system, and continued refactoring the real system.

5.3. ErcChecker caching aspect

Caching is a common example in the AOP literature of acandidate aspect since its implementation is similar acrossall cached functions [21,25]. We can identify cached func-tions since they use a local static set or static map. TheErcChecker contains 38 functions that implement similarcaching code, but are in various classes and do not have acommon naming convention. The aspect pointcut specifiesa list of all the functions to be cached, while the advice pro-vides the caching functionality.

5.3.1. Using mock systems for aspect creation and testing

We created one mock system to test the caching aspect’sfunctionality, and another mock system to evaluate perfor-mance. The first mock system contains methods that havethe same types of parameters and return values as the func-tions to be cached in the real system. The mock systemmethods are short (1–4 lines) and return a value based onthe argument. For example, to test caching of methodswhose argument is a bcmNet pointer, we can use the Get-NetValue() method below.

int GetNetValue(bcmNet *n) /*AOP=ADVISED*/

{return n->GetName().length();

}

In the mock system, we can call GetNetValue() withdifferent bcmNet instances and check for the correct returnvalue. Then, with caching added, we can check that we stillget the correct return values.

For aspect-oriented caching, we had several require-ments that we wanted to check using the mock systems.First, the cache needed to function properly. Second, wewanted our caching aspect to work correctly with differentdata types. Third, we did not want the cache to introduceany noticeable performance penalty; in fact, cachingshould improve performance. Fourth, we needed a wayto measure if a cached function was actually using previ-ously stored values (i.e. being called repeatedly with thesame value), since unnecessary caching adds overheadwithout improved performance.

The first mock system focused on functional behaviorand modeled pointers to complex data types and differentscalar types. The mock system imported the BlockData

component from the ErcChecker. The BlockData

component populates the framework with data, enablingcaching to be tested with framework pointers. We explored

a number of alternative caching implementations [30] usingC++ templates and inheritance.

We created caching aspects for procedural functions andobject-oriented methods. For methods, the hash key storedis the object invoking the method, while for proceduralfunctions the hash key is the function parameter. The cach-ing aspect for procedural functions is shown below. Itstores the first argument to the cached function (tjp->arg(0)) and the return value (tjp->result()). Thestatic map defined in the aspect uses AspectC++ type def-initions. For example, JoinPoint::Arg<0>::Type isthe data type for the first argument to the parameter ofthe function that matched the pointcut.

aspect AbstractFunctionCache {pointcut virtual ExecAroundArgToRe-

sult() = 0;

advice ExecAroundArgToResult() :

around()

{JoinPoint::Result *result_ptr = NULL;

static map <typename JoinPoint::Arg<0>::Type,typename JoinPoint::Result >

theResults;

JoinPoint::Arg<0>::Type *arg_ptr =

(JoinPoint::Arg<0>::Type*) tjp-

>arg(0);JoinPoint::Arg<0>::Type arg = *arg_ptr;if( theResults.count( arg ) ) {//already have the answer, return it

result_ptr = tjp->result();*result_ptr = theResults [ arg ];

}else {//proceed and store the answer

tjp->proceed();result_ptr = tjp->result();theResults [arg ] = *result_ptr;

}}

};

The AbstractFunctionCache aspect defines a virtualpointcut. To use the cache, a concrete aspect extends theAbstractFunctionCache and defines the pointcut as alist of functions to be cached. In the mock system we verifiedthat the pointcut matched intended functions. We verifiedthat the advice avoided recomputation when calls used thesame arguments. The mock system contained math func-tions (e.g. Square() and SquareRoot()) for which aconcrete aspect was created that cached their values.Although the pointcut was not the same in the mock systemand real system, the abstract aspect with its virtual pointcut isthe same in the mock and real systems.

Because C++ supports an object-oriented style and aprocedural style, the mock system had class-based methodcalls and procedure calls, and the aspects were developed to


provide both types of caching. Our approach enableddevelopers to easily switch between a simple cache or aslightly slower cache that reported on cache usage for eachfunction so we could measure if caching was actually sav-ing computation [30].

We also created a second mock system to compare theperformance overhead of the AspectC++ approach tothe original C++ caching code. We used mock statementcoverage to check that the cached functions in the mocksystem were called. Joinpoint coverage checked that thefunction and method caching aspects were executed at allmatching join points.


The only change needed to weave the caching aspectswith the full system was to expand the pointcut of the con-crete caching aspects to match all cached functions. Wechanged the pointcut by using the names of the previouslyidentified caching functions.

When we removed the original caching code from meth-ods in the real system, we added an annotation to indicatethat the method should be advised and added it to the listof functions in the pointcut. The weave analyzer checkedthat the pointcuts defined when refactoring matched theintended functions.

5.4. PowerAnalyzer debugging aspect

The first aspect used in the PowerAnalyzer was adevelopment aspect to aid in debugging a case of abnormaltermination. During one user’s run, the PowerAnalyzeraborted a run with a message from a framework class thata null pointer had been encountered. Unfortunately, theframework method called exit(), which forced the Pow-erAnalyzer to exit without creating a core file that storesprogram state and stack trace information.4 Callingexit() limits visibility when using a debugger such asgdb.

The error message listed the name of the framework iter-ator method name. However, the method was in a baseclass that was inherited by several subclasses, so there weremany candidate calls in the application that may have trig-gered the error. These calls represented possible locationsof the defect and cross-cut 18 locations in four files.

The prior approach to debugging such problemsinvolved adding print statements around all calls that couldhave triggered the error. This required modifying all 18locations in four files, finding the defect and fixing it, andremoving the 18 modifications from the four files. This pro-cess is tedious and error prone. A single aspect can auto-matically provide the same tracing, using the frameworkiterator initialization as the pointcut. The advice can use

4 By contrast, using assert also exits a program, but creates a core filewith the state of the program so that the call stack and program state canbe analyzed.

AspectC++ features to print the context of each iteratorcall.


The mock system for the debug tracing aspect calls dif-ferent types of framework iterators as well as similarlynamed methods that should not be matched by the Cad-Trace aspect pointcut. We checked that the aspect printsout tracing statements only before the intended iteratorcalls. We also reused the BlockData component fromthe PowerAnalyzer to load framework data so that wecould call framework iterators in the mock system. Weused our annotations to indicate which methods in themock system should have advice and which should not.The aspect was created, and the weave analyzer and join-point coverage data checked that the aspect matched onlythe desired framework calls.

Since all the iterators initially call a Reset() method,the aspect used before advice associated with Reset()

iterator methods.

aspect CadTrace {advice call("% %Iter::Reset(. . .)): before() {cerr << "call Iter::Reset for"

<< JoinPoint::signature() << " at

jpid: "

<< JoinPoint::JPID << endl;

}};

The CadTrace aspect uses the AspectC++ method,JoinPoint::signature(), to print out which iteratoris called. The JoinPoint::JPID value is used with theXML weave file to determine the callsite context – the loca-tion in the core concern that called the iterator.


A development aspect for tracing calls does not requirerefactoring the core concerns, so integration only requiresweaving the aspect into the application code. The aspectworked correctly with the libPower library on the firsttry and the call that triggered the framework error waslocated. After weaving the aspect with the PowerAnalyz-er, we ran the test that was producing the program exitfailure.

5.5. PowerAnalyzer timing aspect

The second PowerAnalyzer aspect modularizes codethat reports the status of the application and writes to alog file. Because run-times for VLSI CAD software canbe long (hours or even days), a common extra-functionalconcern is to write time stamps and elapsed time to a logfile. The PowerAnalyzer uses a Timer class, which con-tains a method to reset the elapsed time and a method to

5 This refactoring step states: ‘‘Turn the fragment into a method whosename explains the purpose of the method.’’


return the elapsed time as a string suitable for writing to alog file.

The aspect encapsulates the Timer within the advicebody and uses the AspectC++ joinpoint API to print thecontext in which the Timer is being used. Since the Timeris used within different functions, function names must beused as pointcut targets. In order to avoid enumeratingall functions that should be associated with the Timer,we decided to rename methods to begin with tmr if theyshould have the timing functionality. This enables theaspect to use a pointcut with a wildcard to indicate ‘‘allfunctions beginning with tmr’’.

Modularizing the code for capturing and recordingtimer information into a single aspect provides flexibilityif the the Timer interface changes. In addition, if a differ-ent timing module were substituted only the aspect wouldneed to change, rather than scattered code in thePowerAnalyzer.


The mock system for the TimeEvent aspect has twomethods beginning with tmr to match the pointcut andtwo other methods that do not match this pattern. Thetwo methods that begin with the pointcut pattern haveADVISED annotations, while the other two have NOT_AD-VISED annotations. One tmr method calls the other to testthat timing works correctly with nested calls. The methodbodies contain only print statements to show program flowand calls to a system function (sleep()) to insert delaysthat are measured by the Timer class. The mock systemdoes not rely on framework components, but uses theTimer module, which already existed in thePowerAnalyzer.

The aspect for timing, TimeEvent, uses around advice.The aspect instantiates a Timer object to record the time,proceeds with the original function call, and then accessesthe Timer object to calculate and write the elapsed time.

aspect TimeEvent {pointcut tmr() = call("% tmr%(. . .)");advice tmr() : around() {Timer timer; //set up timer

timer.Reset();

tjp->proceed(); // execute advised

method

//write out the time used

PrintI(911, "Time around %s: (%s) nn",JoinPoint::signature(),

timer.CheckTime());

PowerMessage::WriteBuffers();

}};

The mock system allowed us to quickly make changes tothe pointcut (changing it twice) as we corrected problemswe encountered when advising nested calls. We also usedthe mock system to test how the advice instantiated the

Timer module and how timer log messages wereformatted.


AspectC++ relies on name-based pointcuts to weave inadvice. Even though similar code to instantiate and useTimer objects exists at many locations, there was no com-mon structure or naming convention for the pointcut tomatch. To refactor the PowerAnalyzer, functions thatused the Timer class had the Timer instance and callsremoved, and were renamed from FunctionName totmrFunctionName to match the pointcut specification.

One challenge was that some of the application code waswritten as large, procedural functions, including a 500 linefunction with 15 separate uses of the Timer module. Theseseparate uses were either loop statements or conceptuallyseparate code blocks. For this function, we first usedExtract Method refactoring [11].5 Creating a function witha name that begins with tmr allowed capturing the join-point in AspectC++. By using a meaningful functionname, we could pass a single signature to the Timer mod-ule instead of a separate descriptive argument for eachTimer call. For consistency, we applied the same aspectacross all three executables of the PowerAnalyzer.Using name-based pointcuts results in tight coupling thatcan cause problems during maintenance due to namechanges in functions [35]. There is tight coupling betweenthe TimeEvent aspect and the naming convention ofmethods. If a new function is added that should use thetimer, it must begin with tmr or it will not have the Timerfunctionality woven in. In addition, if someone changesone of the names of the functions so that it no longerbegins with tmr, time logging will no longer occur for thatfunction. If a function that does not need timing informa-tion is created with a name that begins with tmr, that func-tion will match the pointcut and have TimeEvent adviceassociated with it. Since PowerAnalyzer regression testsfocus on functionality and not the time taken by systemfunctions, an error associated with timing might not beimmediately detected. Our annotations can be used in thereal system to report when a change in the system or apointcut change causes a pointcut to not match theintended joinpoint.

We refactored the application so that the Timer mod-ule is only directly called from the advice of the Time-

Event aspect. To enforce this design decision, we alsoadded additional advice to the TimeEvent aspect so thata direct use of the Timer will result in an error when thewoven code is compiled. AspectC++ does not have adeclare error statement like AspectJ. However, Alex-andrescu [2] shows how to create compile-time assertionsin C++ by defining a C++ template that is instantiatedwith a boolean value, and only defined for only one bool-


ean value (e.g. true), so that a compile-time error occurswhenever the template is instantiated with a false

value. We created additional advice [30] for the Power-

Analyzer that uses a C++ template that fails wheneverit is woven around core concern calls to the Timer class,ensuring that the Timer is only called from our Time-Event advice.

6. Mock system creation

A key feature of our approach is the use of a mock sys-tem. In the ideal case, a mock system will have a structurethat allows aspects to be moved without change from themock system to the real system for integration testing.Thus, an important question is how to create a mocksystem.

Based on our experience with legacy applications, wedeveloped a preliminary list of mock system creational pat-terns that can aid the developer of a mock system. As moreexperience is gained with using mock systems, we expectthe catalog of patterns to grow.

The patterns are based on characteristics of both theaspects and the real system. The mock system must providean environment that emulates the structure and functional-ity for pointcuts, advice, and other aspect-based features tofunction.

6.1. Create mock methods for spectator aspects

Spectator aspects are defined by Clifton and Leavens [7]as aspects that do not change the behavior of advised mod-ules. Faults in spectators result in incorrect system behav-ior (e.g. missing or incorrect logging), but do not changethe advised core concern.

Motivation: Because spectators do not rely on the inter-nal state of the methods and classes they advise, we usemethod stubs in the mock system. Stubs are methods withempty or trivial bodies. Spectators are validated by ensur-ing that the pointcut matches the expected joinpoints andthat the advice functionality executes correctly.

Step:

(1) Create method stubs with naming conventions suchthat the pointcut will match in the mock systemand the real system.

Example: The TimeEvent aspect in the PowerAna-

lyzer is a spectator that adds timing information withoutaffecting the power analysis. An error in the aspect mayresult in incorrect times and pointcut strength faults mayresult in the wrong methods being timed, but the function-ality of the PowerAnalyzer is not affected.

For the TimeEvent aspect, methods to be timed mustbegin with tmr to match the pointcut: call("%tmr%(. . .)"). We created the mock system by writingmethod stubs that match this calling convention; the stubsare called in main().

6.2. Create simple functional mock methods for non-

functional concerns

Non-functional aspects [26] modularize cross-cuttingconcerns that improve non-functional characteristics suchas performance or dependability without changing theexisting functionality. Unlike spectators, faults in non-functional aspects can change the observed behavior ofthe advised concerns.

Motivation: We use mock methods to provide simplefunctionality when validating a non-functional aspect. Thisdiffers from the motivation in Section 6.1 because non-functional concerns, such as caching, must not only advisethe right joinpoints but also must implement the cross-cut-ting concern without changing the existing functionality.

Steps:

(1) Create mock class methods with the same parametertypes and return types as the methods in the real sys-tem, but with simpler functionality.

(2) Invoke the mock method with several differentparameter values from the main() function to vali-date the non-functional property.

A mock system for the caching aspect can use a functionthat operates on the same data types used in the real sys-tem. Joinpoint coverage checks that the advice is used.Statement coverage of the woven mock system can be usedto check that all advice statements are executed. For cach-ing, we want to test that the advice executes correctly: onthe first call it should use proceed() and store the result,while subsequent calls with the same parameter shouldreturn the cached value without calling proceed() tore-execute the method. Unit tests can call a function withthe same value multiple times and check for the correctoutput.

Example: The caching aspect in the ErcChecker shouldimprove performance without affecting functionality, butfaulty advice can affect program modules.

In the mock system, we created functions that work onthe same types, but are simple to compute and validate.For example, rather than calculating fanout of an electricalnet, we created a function (GetNetLength()) thatreturns the length of the net’s signal name.

int GetNetLength(bcmNet *n)

{return n->GetName().length();

}

We also create a similar function (GetWrongNet-Length()) with a different value, that is cached:

int GetWrongNetLength(bcmNet *n)

{return n->GetName().length()+10;

}


These functions were called in an interleaved fashion tovalidate that the aspect created separate caches for each,and that the advised functions returned the correct valuein each case. An example from the mock system is shownbelow:

//code that sets up the framework context

bcmCell *cell = GetTopCell();

//find 3 net objects. . .bcmNet *net1 = FindNet( cell, "VDD" );

bcmNet *net2 = FindNet( cell, "GND" );

bcmNet *net3 = FindNet( cell, "clock" );

//make sure GetNetLength works,

//when not cached (first call)

//and when cached (second call)

assert ( GetNetLength(net1) == 3);


//interleave calls to GetNetLength and

// GetNetLength to make sure they are not

// ’mixing’ caches from different functions

// together


assert ( GetWrongNetLength(net3) == 10);

assert ( GetWrongNetLength(net3) == 10);


In the mock system, we created functions and methodsusing other framework pointers, such as bcmCell andbcmInstance. We also tested caching of built in types(e.g. float) using mathematical functions includingSquare() and SquareRoot().

6.3. Reuse real system components

Components needed in the mock system can sometimesbe directly obtained from the existing real system.

Motivation: Often there is code in a large system, suchas framework code, that is necessary to establish theinitial state of the system before any advised methodsare called. For example, a graphical system might havea common set of methods to create an environment forOpenGL or for a GUI windowing system. Our CADapplications require reading a netlist into memory beforemost framework methods may be called. We can importsystem components that are necessary for system initial-ization and copy in the small code sections that mustbe called to use these components. This avoids creatingmock classes for large or complex components but stillenables the mock system to have some actualfunctionality.

Steps:

(1) Identify components methods and classes in the realsystem that provide essential functionality in themock system.

(2) In the mock system, import the necessary compo-nents. In C++, this can be done by including a headerfile and linking against a system or framework library.

(3) Copy small code sections that contain boilerplatecode for using imported components.

Example: To use framework calls in mock systems forthe ErcChecker and PowerAnalyzer, we reused a sin-gleton class, BlockData, that handled initialing and load-ing framework design data. In the mock system, weincluded the BlockData class header and copied the codethat uses it to initialize framework data in the mock system.

6.4. Emulate the callsite context for joinpoints

The developer creates callsite contexts in the mock sys-tem that are similar to the expected joinpoints in the realsystem. Callsite context includes information that theaspect uses from the joinpoint, including method parame-ters and call flow information.

Motivation: Changes to the control flow such as excep-tions, method calls, and recursive calls should be identifiedand tested in the mock system. Creating appropriate callsiteinformation for method calls in the mock system includesusing a similar number of arguments and argument types(e.g. simple scalar types, user-defined types, pointers, andtemplatized types such as STL containers).

In emulating the control flow context of the real system,particular attention should be given to potential causes ofinfinite recursion, which Laddad identifies as a commonmistake in adopting AOP [21]. For example, an aspectwhose pointcut may match a call within its own advicemay lead to unintended infinite recursion unless the point-cut is constrained (e.g. through a more restrictive patternor using AspectC++ directives such as within orcflow). In addition, aspects may advise recursive methodsin the real system. Developers can create intra-method callsand recursive calls in the mock system to test the advicewith existing recursion.

Aspects that throw or catch exceptions may be changingthe resulting control flow and the exceptions seen by call-ers. Throwing and catching exceptions can be tested inthe mock system.

Steps:

(1) Identify callsite context passed in from the joinpoint,including parameter values and parameter types,especially templates and user-defined types. Createand advise mock methods with the same parametertypes.

(2) If advice catches exceptions thrown by the real sys-tem, throw these exceptions in the mock system.


(3) If advice throws exceptions, catch these exceptions inthe mock system.

(4) Identify call flow information (such as cflow) andrecursion that exists in the real system and emulateit in the mock system.

Example: In the PowerAnalyzer, functions that weretimed were nested, calling other functions that were alsotimed. We modeled this structure in the mock system tocheck that (1) the timing information for each functionwas correct, (2) the nested timed calls reported correct tim-ing information, and (3) the nested calls did not lead to infi-nite recursion. In the caching aspect, we used the mocksystem to verify that the templatized cache used by theadvice worked with a wide variety of built-in and user-defined data types.

6.5. Provide functionality used by advice

System functionality used by advice is imported into oremulated by the mock system.

Motivation: To test the advice, the mock system mustprovide the methods called by the advice and data struc-tures used by the advice. A Logging or Tracing aspect,for example, may instantiate and use a Logger object,which must be present in the mock system. To test anaspect that modularizes a system policy, the mock systemmust provide functionality that the advice depends upon.We can use existing system components in the mock systemor create new mock classes for components that are largeor difficult to import.

Steps:

(1) Identify any system components called from advice.(2) Identify any data structures (classes, pointers to cer-

tain object types) used by the advice.(3) Create mock components or reuse components so

that advice functionality can be validated.

Example: The advice of the ErcChecker’s Query-

Policy aspect performs logging of ErcQuery informa-tion, deletes ErcQuery objects that did not findelectrical errors, and adds ErcQuery objects that detectelectrical failures to a container class (LevelManager).In order for the mock system to have enough functionalityto validate the advice, the mock system needs to (1) createErcQuery objects, (2) provide a Logging class that theadvice uses, and (3) provide a mock LevelManager class.We created mock classes for all three of these requirementsin the ErcChecker mock system.

By using the same names for the Logging class and themock container class (LevelManager), we used theaspect in the ErcChecker without changing the methodscalled. During system refactoring, we identified an addi-tional method that needed to be called from the advice.We first emulated the changes in the mock system, and thencontinued refactoring the real system.

6.6. Use annotations in the mock system to check potential

pointcut strength faults

Faulty pointcuts that match too many or too few loca-tions can be difficult to debug. By creating annotations inthe mock system for methods that should and should notmatch a pointcut, we check the weave results for incorrectpointcuts.

Motivation: Pointcut strength faults [1] are particularlydifficult to test for. The mock system is created with anno-tated methods that are intended to be matched by an aspectas well as annotated methods that should not be matched.If multiple aspects are woven with a mock system, ourannotation approach (see Sections 3.2 and 4.1) would allowus to specify the specific aspect that should or should notadvise a method. By choosing the class and method namesin the mock system based on those in the real system, weincrease our confidence that the pointcuts will choose cor-rect joinpoints in the real system.

Steps:

(1) Create namespaces, classes, and names that shouldnot match the pointcut but are similar (e.g. same pre-fix to class names or namespace names).

(2) Create namespaces or user-defined types that havesimilar naming conventions as pointcuts.

(3) Model class hierarchies in the mock system to vali-date pointcut matching in base classes and subclasses.

(4) Add annotations to indicate methods that should beadvised and which should not be advised.

Example: For regular expression types of pointcuts such as

call("% %Iter::Reset(. . .)")

we should create multiple method calls that we intend tomatch (e.g. InstIter::Reset(), NetIter::Reset()).In addition, namespaces can affect whether pointcutsmatch, since % in AspectC++ only matches one level (allclasses) and not two levels of naming (all namespaces andall levels).

Calls to the Reset() method of an framework iteratorwere annotated to indicate the name of the aspect thatshould advise them:

while( (n=

netIterPtr->Next()) ) {/*AOP=ADVISED_ BY(PowerOnlyFilter)*/

The weave analyzer checks that the ADVISED_BY(PowerOnlyFilter) annotation did have an associ-ated advice joinpoint from the PowerOnlyFilter

aspect. We also used annotations to indicate functions thatshould not have any advice:

void lookAtInsts(bcmCell *cell) /* AOP=

NOADVICE */


6.7. Emulate aspect–aspect interactions

When multiple aspects are used in a system, we can emu-late the ways that multiple aspects interact.

Motivation: Aspects may interact with one another bymany means, including advising the same method andintroducing members or methods to the same class [10].These intended interactions should be modeled in a mocksystem by creating the conditions (e.g. overlapping join-points) that are anticipated in the real system. For example,we can create a mock class method that will match twoaspects and test the combined behavior.

Although the real system may contain unanticipatedaspect–aspect interactions, the mock system tests thatthe aspects work together correctly in at least some sit-uations. Like unit testing, this provides an environmentto validate basic functionality before large-scaleintegration.

Steps:

(1) Identify joinpoints in the real system that will bematched by more than one aspect.

(2) Create the mock system to contain joinpoints advisedby these aspects.

(3) After weaving aspects with the real system, use anal-ysis of weave results to identify any unexpectedshared joinpoints that should also be tested withinthe mock system.

Example: Although our aspects for these systems werenon-overlapping, we did consider implementing cachingwith two overlapping aspects: one for function cachingand one for hit/miss analysis of the cache. The two aspectswere tested together in the first caching mock system. Theaspects had identical pointcuts to advise the same methods.Because the pointcuts were the same, we did not have tochange the mock system to test the interaction of multipleaspects. Both aspects were woven with the mock system.During testing, we found that order of execution wasimportant because both aspects used proceed(). If thecaching aspect executed first and had stored the valuealready, it returned without calling proceed(), whichprevented the other aspect from advising the call as well.We chose not to use this two aspect version of caching;thus, it was not tested in the performance-oriented mocksystem.

One benefit of using a mock system for testing aspectinterference is that a small system can be set up with spe-cific call orders. One drawback is that there may be manycomplex scenarios that are not anticipated in the mocksystem.

7. Evaluation

In Section 5, we describe the process of creating aspectsand mock systems to aspectualize two legacy systems. Inthis section we evaluate the costs and benefits of using

mock systems in terms of our experiences. We evaluatethe process in terms of four evaluation questions. Thenwe examine threats to validity.

7.1. Evaluation questions

The goal of the evaluation is to answer the followingresearch questions:

(1) Can mock systems be developed for aspects that willbe woven with legacy systems?

(2) What costs are incurred in creating a mock system?(3) Does using mock systems save time when creating an

aspect requires multiple iterations of our approach?(4) Did the aspects created using the mock system

require changes to work with the real system?

We use version 1.0pre3 of AspectC++, which is asource-to-source weaver: weaving C++ code is followedby compiling the woven code. Our development environ-ment for our tools is based on Linux and uses version3.2.3 of the g++ compiler. We use version 3.2.3 of gcov(which depends on features of the g++ compiler) for mea-suring statement coverage.

Since we were able to create a mock system for eachaspect, the answer to the first question was always ‘‘yes’’.For each aspect, we answer the second question by report-ing the lines of code and time required to create it. Lines ofcode includes only new code created for the mock system,not components reused from the real systems. We reporttime spent creating the mock system, either by writingnew code or reusing existing components.

For the third question, we compare the time spent oncreating the mock system to the compilation and weavetime saved by using the mock system when multiple itera-tions were needed to create an aspect. We answer thefourth question by describing any changes made to point-cuts or advice when moving the aspects from the mock sys-tem to the real system.

7.2. ErcChecker policy aspects

7.2.1. What costs are incurred in creating a mock system?

We created the mock system in one hour by inspectingthe classes and components called by the ErcQuery hier-archy. The mock system had a small class hierarchy basedon the ErcQuery class hierarchy. The mock hierarchycontained four classes and had a depth of inheritance oftwo. The mock system also implemented classes that areused by the mock system hierarchy or by advice. For theErcChecker policy aspects, the mock system we createdcontained 160 LOC.

7.2.2. Does using mock systems save time when an aspect

requires repeated cycles to create?Weaving takes 15 min. Compiling the woven code takes

10 min. Thus, making and testing small changes in point-


cuts or advice requires 25 min. The mock system can becompiled and woven in one minute.

Due to the wide scope of refactoring (59 subclasses toconsider) [31] and errors in the initial aspect advice, andbecause several faults were encountered doing refactoring[32], 10 iterations were needed during the creation of theaspect. Since the time saved when weaving and compilingby using a mock system is 24 min, the compilation andweave savings were 240 min. The mock took 60 min to cre-ate, so the total savings of the mock systems approach was180 min.

7.2.3. Did the aspects created in the mock system require

changes to work in the real system?

We discovered a required change in the ErcQuery hier-archy for the aspect to work with all 59 subclasses. Thisalso required a one line addition to the advice. A morethorough inspection of the ErcChecker could have iden-tified this before creating the mock system. The pointcutdid not have to be changed when the aspect was wovenwith the real system.

7.3. ErcChecker caching aspects


We created two mock systems. The first mock systemfocused on functional behavior and modeled pointers tocomplex data types and different scalar types. The mocksystem consisted of 400 lines of C++ code and alsoimported the BlockData component. Creating it took45 min. Using the mock system, a prototype caching aspectcould be woven, compiled, and run in less than a minute.

Once we developed the caching aspect, we created a sec-ond mock system for measuring performance. We com-pared the performance overhead of the AspectC++caching using around advice to the overhead of the scat-tered C++ caching code. This mock system contained200 lines of C++ code and did not import the BlockDatacomponent. Creating it took 20 min.


requires repeated cycles to create?

We used 15 iterations to create the caching aspect toevaluate different approaches. Weaving and compiling theErcChecker would have dramatically slowed down ourability to test and evaluate the aspect since compiling andweaving the ErcChecker requires 25 min. For 15 itera-tions to create the caching aspect, using mock systemssaved 24 min per iteration, for a total of 360 min, minusthe mock development time (80 min). Thus, total savingswas 280 min (4.67 h).



The only changed needed in the aspect was in the point-cut definition. In the concrete aspect, it listed all functionsto be cached. Changing the pointcut was done by using the

names of caching functions we had identified previously.The abstract aspect that contained the caching advice codedid not change.

7.4. PowerAnalyzer tracing aspect

7.4.1. What costs are incurred in creating a mock system?We reused the BlockData component and created 60

lines of C++ code that made calls to different types offramework iterators, and similarly named methods thatshould not match. Creating the mock system took 30 min.



Once the aspect was created, weaving and compiling itwithin the mock system took less than a minute. The Cad-Trace aspect was woven with the libPower component ofthe PowerAnalyzer. Weave time and compilation timetotal 4 min.

Since this aspect worked correctly on the first iteration,there was no time savings from compiling and weaving theaspect with a smaller system during development. Usingthe mock system introduced a 30 min cost.



The aspect was woven with the PowerAnalyzer with-out changes to the pointcut or advice.

7.5. PowerAnalyzer timing aspect


The mock system provided similar naming conventionsas the PowerAnalyzer. We created two methods thatmatched the proposed pointcut naming convention andtwo that did not, and had one advised method call theother. The mock system contained 50 LOC and was createdin 30 min.



Each of PowerAnalyzer executables takes three min-utes to weave and compile, so nine minutes are required toweave the aspect with the full system. Weaving the aspectwith the mock system, compiling and running togethertook under a minute.

Iterative aspect development was important because wechanged the pointcut twice as we experimented with point-cuts and advice to handle nested calls advised by theTimeEvent aspect. The advice body also went throughtwo iterations to finalize the format and informationlogged. Making these changes using the mock system pro-vided feedback in less than 1 min.

The four iterations we used to create the aspect tookonly four minutes of run time in the mock system. Hadthe full system been used, these iterations would have taken36 min. The compile/weave time savings (32 min) minus


the mock creation time (30 min) means that the total timesaved was 2 min.



No, the aspect was woven without change with thePowerAnalyzer because we did not find any issues thatrequired going back to the mock system for evaluating fur-ther changes.

7.6. Discussion

The mock systems for the four aspects were all small,with the compilation and weave times being dramaticallyless (one minute versus up to 25 min) than in the real sys-tem. None of the mock systems were difficult to create,with all taking an hour or less. The total time spent creat-ing mock systems for the ErcChecker’s caching aspectwas 65 min, but this was because two mock systems werecreated.

Table 1 summarizes our data for each aspect. The ‘Iter-ations’ column is the number of iterations used to createthe aspect. The ‘Mock LOC’ shows the size (lines of code)of the mock system, while ‘Mock Creation Time’ is thetime (in minutes) spent creating the mock systems. The‘Changes’ column indicates if changes had to be made inthe aspects when moving them from the mock system tothe real system. The ‘Time saved’ column is the time savedin the aspect creation iterations minus the time to create themock system. The negative value for the CadTrace aspectindicates a net cost to use the mock system.

For the ErcChecker, which used 10–15 iterations tocreate aspects, there was a clear time savings. For the Pow-erAnalyzer, the time savings is 2 min for the TimeEventaspect and negative (a cost) for the CadTrace aspect.

Use of the mock system did not save time when aspectu-alizing the PowerAnalyzer. However, the use of a mocksystem to aspectualize the larger ErcChecker did savesignificant time. This savings was due to the longer compiletimes and the increased number of iterations. For caching,this was due to many different caching strategies being con-sidered and evaluated. For the QueryPolicy aspects, thenumber of iterations results from the large number of clas-ses involved in the refactoring and faults encountered dur-ing the refactoring. One hypothesis that we propose ismock systems will provide a greater time savings whenaspectualizing large systems. In addition, mock systemswill provide greater cost benefits for aspects that use more

Table 1Summary of mock systems data for each aspect

Aspect Iterations Mock creationtime (min)

MockLOC

Changes Timesaved

QueryPolicy 10 60 160 Advice 3 hCaching 15 65 600 Pointcut 4.67 hCadTrace 1 30 60 None �0.5 hTimeEvent 4 30 50 None 2 min

complex advice and hence require more iterations to createand validate. Even when mock systems do not save devel-opment time, they provide a more controlled environmentfor testing the aspect, just as traditional unit testing canfocus more on a function or class before integration testing.For example, using a mock system for evaluating cachingfocuses solely on caching rather than testing the cachingaspect as part of the full system. Other types of testing,such as performance or stress testing, can be done withmock systems, such as our testing of caching behaviorand performance.

One additional cost of mock systems is that as an aspectevolves during development, any changes need to be mir-rored and validated in the mock system or the mock systembecomes stale.

We do not have tools that help automate the creation ofmock systems. Although tools can potentially extract clas-ses or interfaces from the real system, engineering judge-ment is required when deciding what classes and methodsare needed in the mock system. In our work, we quicklycreated mock systems and were not motivated to developautomated tools.

7.7. Threats to validity

The evaluation of the new approach demonstrates that itcan be applied to legacy systems. However, like most casestudies, it is difficult to generalize from a small-scale study.Thus, there are threats to external validity.

This study applied the aspectualization process to onlytwo legacy systems. The legacy systems were not selectedrandomly, which limits external validity. Certainly, differ-ent results are likely when applying the process to othersystems. Still this study demonstrates that the process canwork, and the use of mock systems can lower costs andhelp to find errors.

Because of the limited nature of the evaluation, there arethreats to internal validity, which is concerned withwhether the new approach is actually responsible for thetime savings and for revealing faults. One concern is thatall of the aspect development and refactoring was per-formed by the same subject. This subject is also one ofthe developers of the approach, and clearly understandsand believes in the approach. Others would not be biased,and might choose different aspects or implement them dif-ferently. In addition, the subject had development experi-ence with the ErcChecker, and this potentially sped upaspect identification, refactoring, and mock systems devel-opment. For the PowerAnalyzer, although the devel-oper did not participate in the design or development ofthe system, he did have some limited knowledge of the codebased on making changes during maintenance.

Construct validity focuses on whether the measures usedrepresent the intent of the study. We reported on whetheror not aspect pointcuts or advice changed when movingfrom the mock system to the real system, since this is oneway of measuring if the mock structure is similar enough


to the real system. Other approaches might use structuralcode metrics or defects found to measure how effectivemock systems are at providing an adequate environmentfor developing aspects. Time savings is a key dependentvariable; it is based on compilation and weave times andhow many iterations were used in the mock system to cre-ate an aspect. This is a reasonable way to measure effort.However, all iterations may not require an equal amountof time to complete.

8. Conclusions and future work

We developed a test driven approach for creating andunit testing aspects with mock systems, and for performingintegration testing with these same aspects in the context oflarge legacy systems. We built tools for advice instrumenta-tion, weave analysis, and coverage measurement that sup-port our approach. Similar tools could be developed forother aspect-oriented languages, such as AspectJ.

We demonstrate our approach by refactoring two largelegacy C++ applications. We also provide guidelines forthe creation of mock systems. We show how using mocksystems helps overcome the challenges of long compilationand weave times when refactoring large legacy systems. Forthe larger of the two systems, using a mock system savedbetween three and five hours for each aspect. Using mocksystems and the tools helps validate aspects, explore differ-ent implementations, and identify pointcut and advicefaults.

The aspects enable cross-cutting concerns, such as spe-cific design policies, caching, debug tracing, and timing tobe implemented in a more modular way. A developmentaspect that is not a permanent part of the program sup-ports a pluggable approach, in which weaving, not manualcode changes, is used to enable or disable tracing.

We continue to evaluate our test driven approach asthese programs are refactored. We are studying how mocksystems can also be used to test other advice features, suchas introductions, class hierarchy changes, exception soften-ing, and advice precedence. We expect that introductionsand hierarchy changes can be unit tested on mock systemsthat will then be modified by the aspect. We are exploringother legacy C++ systems within Hewlett-Packard that usethe same framework as these applications do.

One goal of mock systems is to create aspects that donot require change when woven with the real system. IfAspectC++ supported annotation-based weaving, thecaching aspect pointcut change could have been avoided.Weaving based on annotations is different from our ownannotations, which are used to check the weave results.Instead, languages such as AspectJ allow developers touse annotations as weave targets. While this requires theannotations to be inserted at all join points, it avoidsdepending on function names or naming conventions. IfAspectC++ supported annotations, we could use annota-tion-based pointcuts for some aspects, and the mock sys-tem and real system could both contain annotations.

Testing more complex aspects leads to an open question:are there criteria or measures that should be used to vali-date that a mock system is similar enough to the actual sys-tem? This is an important question, since unit testing with amock system assumes the mock system provides a usefulabstraction of the real system.

Another interesting question is the effect of cross-cuttinginterfaces [14] on mock systems. Cross-cutting interfaces(XPIs) use a semantic description of intent and a pointcutdesignator signature to specify the dependencies betweencore concerns and aspects. Clearly defined interfaces foraspects might allow mock systems to be created to matchthe same XPI.

Our existing coverage-based approach could beextended to consider statement coverage within advicebodies. Since we gather statement coverage informationfrom woven code, we would have to reverse-engineer theweaving process to match it to the original advice body.In addition, even if we knew that all advice statements wereexecuted, we might want to know if all advice statementswere executed at each join point.

Although mock systems are beneficial during refactoringof legacy systems, mock systems will need to be maintainedwith the aspects and system in order to remain relevant.Understanding the costs and benefits of a mock systemover time is an important extension of this work.

More studies are also needed on using mock systems toevaluate adding many aspects to a system, particularlywhen there will be intended aspect–aspect interactions. Inaddition, strategies for effectively detecting or mitigatingunintended aspect–aspect interactions need to be devel-oped. In our preliminary studies we saw that mock systemscan help isolate aspect–aspect interactions by easily creat-ing structures based on method names and class structureswhere multiple aspects interact in the small. Our weaveanalyzer could be extended to report joinpoints advisedby multiple aspects so that developers are aware of themand test aspect interactions in a mock system.

References

[1] Roger T. Alexander, James M. Bieman, Anneliese A. Andrews,Towards the systematic testing of aspect-oriented programs. Techni-cal Report CS-4-105, Department of Computer Science, ColoradoState University, March 2004.

[2] Andrei Alexandrescu, Modern C++ Design: Generic Programmingand Design Patterns AppliedAW C++ in Depth Series, AddisonWesley, 2001.

[3] AspectJ project. http://www.eclipse.org/aspectj/.[4] Dave Astels, Test Driven development: A Practical Guide. Prentice

Hall Professional Technical Reference, 2003.[5] Ira D. Baxter, Andrew Yahin, Leonardo Moura, Marcelo Sant’Anna,

Lorraine Bier, Clone detection using abstract syntax trees, in: ICSM’98: Proceedings of the International Conference on SoftwareMaintenance, IEEE Computer Society, Washington, DC, USA,1998, p. 368.

[6] Magiel Bruntink, Arie van Deursen, Remco van Engelen, TomTourwe, On the use of clone detection for identifying crosscuttingconcern code, IEEE Transactions on Software Engineering 31 (10)(2005) 804–818.

http://www.eclipse.org/aspectj/


[7] Curtis Clifton, Gary T. Leavens, Obliviousness, modular reasoning,and the behavioral subtyping analogy, in: AOSD 2003 Workshop onSoftware-Engineering Properties of Languages for Aspect Technol-ogies, March 2003.

[8] Yvonne Coady, Gregor Kiczales, Back to the future: a retroactivestudy of aspect evolution in operating system code, in: Mehmet Aks�it(Ed.), Proceedings 2nd International Conference on Aspect-OrientedSoftware Development (AOSD-2003), ACM Press, March 2003, pp.50–59.

[9] Remi Douence, Pascal Fradet, Mario Sudholt, Composition, reuseand interaction analysis of stateful aspects, in: Karl Lieberherr (Ed.),Proceedings of the 3rd International Conference on Aspect-OrientedSoftware Development (AOSD-2004), ACM Press, March 2004, pp.141–150.

[10] Pascal Durr, Tom Staijen, Lodewijk Bergmans, Mehmet Aksit,Reasoning about semantic conflicts between aspects, in: Kris Gybels,Maja D’Hondt, Istvan Nagy, Remi Douence (Eds.), 2nd EuropeanInteractive Workshop on Aspects in Software (EIWAS’05), Septem-ber 2005.

[11] Martin Fowler, Refactoring: Improving the Design of Existing Code,Addison-Wesley, 1999.

[12] Andreas Gal, Wolfgang Schroder-Preikschat, Olaf Spinczyk,AspectC++: language proposal and prototype implementation, in:Kris De Volder, Maurice Glandrup, Siobhan Clarke, Robert Filman(Eds.), Workshop on Advanced Separation of Concerns in Object-Oriented Systems (OOPSLA 2001), October 2001.

[13] Sudipto Ghosh, Robert France, Devond Simmonds, Abhijit Bare,Brahmila Kamalakar, Roopashree P. Shankar, Gagan Tandon, PeterVile, Shuxin Yin, A middleware transparent approach to developingdistributed applications, Software Practice and Experience 35 (12)(2005) 1131–1159.

[14] William G. Griswold, Kevin Sullivan, Yuanyuan Song, MacneilShonle, Nishit Tewari, Yuanfang Cai, Hridesh Rajan, Modularsoftware design with crosscutting interfaces, IEEE Software 23 (1)(2006) 51–60.

[15] Jan Hannemann, Gregor Kiczales, Overcoming the prevalent decom-position in legacy code, in: Peri Tarr, Harold Ossher (Eds.),Workshop on Advanced Separation of Concerns in Software Engi-neering (ICSE 2001), May 2001.

[16] Jan Hannemann, Gregor Kiczales, Design pattern implementation inJava and AspectJ, in: Proceedings of the 17th ACM conference onObject-oriented programming, systems, languages, and applications,ACM Press, 2002, pp. 161–173.

[17] Jan Hannemann, Gail Murphy, Gregor Kiczales, Role-based refac-toring of crosscutting. Role-based refactoring of crosscutting con-cerns, in: Peri Tarr (Ed.), Proceedings of the 4th InternationalConference on Aspect-Oriented Software Development (AOSD-2005), ACM press, 2005, pp. 135–146.

[18] Toshihiro Kamiya, Shinji Kusumoto, Katsuro Inoue, CCFinder: amultilinguistic token-based code clone detection system for large scalesource code, IEEE Transactions on Software Engineering 28 (7)(2002) 654–670.

[19] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda,Cristina Lopes, Jean-Marc Loingtier, John Irwin, Aspect-orientedprogramming, in: Mehmet Aks�it, Satoshi Matsuoka (Eds.), 11thEuropean Conference on Object-Oriented Programming, vol. 1241 ofLNCS, Springer Verlag, 1997, pp. 220–242.

[20] Ramnivas Laddad, Aspect-oriented refactoring. Technical report,The ServerSide.com, 2003.

[21] Ramnivas Laddad, AspectJ in Action: Practical Aspect-OrientedProgramming, Manning (2003).

[22] Otavio Augusto Lazzarini Lemos, Fabiano Cutigi Ferrari, PauloCesar Masiero, Cristina Videira Lopes, Testing aspect-orientedprogramming pointcut descriptors, in: WTAOP ’06: Proceedings of

the 2nd workshop on Testing aspect-oriented programs, New York,NY, USA, ACM Press, 2006, pp. 33–38.

[23] Otavio Augusto Lazzarini Lemos, Jose Carlos Maldonado, PauloCesar Masiero, Structural unit testing of AspectJ programs, in: 2005Workshop on Testing Aspect-Oriented Programs (held in conjunctionwith AOSD 2005), March 2005.

[24] Nick Lesiecki, Unit test your aspects. Technical report, JavaTechnology Zone for IBM’s Developer Works, November 2005.

[25] Daniel Lohmann, Georg Blaschke, Olaf Spinczyk, Generic advice: Onthe combination of AOP with generative programming inAspectC++, in: Gabor Karsai, Eelco Visser (Eds.), Proceedings ofthe Generative Programming and Component Engineering: ThirdInternational Conference, vol. 3286 of Springer-Verlag Lecture Notesin Computer Science, Springer, October 2004, pp. 55–74.

[26] Daniel Lohmann, Olaf Spinczyk, Wolfgang Schroder-Preikschat, Onthe configuration of non-functional properties in operating systemproduct lines, in: David H. Lorenz, Yvonne Coady (Eds.), ACP4IS:Aspects, Components, and Patterns for Infrastructure Software,March 2005.

[27] Cristina Videira Lopes, Trung Chi Ngo, Unit testing aspectualbehavior, in: 2005 Workshop on Testing Aspect-Oriented Programs(held in conjunction with AOSD 2005), March 2005.

[28] Marius Marin, Leon Moonen, Arie van Deursen, An approach toaspect refactoring based on crosscutting concern types, in: MartinRobillard (Ed.), MACS ’05: Proceedings of the 2005 workshop onModeling and analysis of concerns in software, ACM Press, May2005, pp. 1–5.

[29] Michael Mortensen, Roger T. Alexander, An approach for adequatetesting of AspectJ programs, in: 2005 Workshop on Testing Aspect-Oriented Programs (held in conjunction with AOSD 2005), March2005.

[30] Michael Mortensen, Sudipto Ghosh, Creating pluggable and reusablenon-functional aspects in AspectC++, in: Proceedings of the FifthAOSD Workshop on Aspects, Components, and Patterns forInfrastructure Software, Bonn, Germany, March 20 2006, pp. 1–7.

[31] Michael Mortensen, Sudipto Ghosh. Using aspects with object-oriented frameworks, in: AOSD ’06: 5th International Conference onAspect-oriented Software Development Industry Track, March 2006,pp. 9–17.

[32] Michael Mortensen, Sudipto Ghosh, James Bieman, Testing duringrefactoring: adding aspects to legacy systems, in: 17th InternationalSymposium on Software Reliability Engineering (ISSRE 06), Novem-ber 2006.

[33] Olaf Spinczyk and pure-systems GmbH. Documentation:AspectC++ Compiler Manual, May 2005. http://www.aspectc.org/fileadmin/documentation/ac-compilerman.pdf.

[34] Paolo Tonella, Mariano Ceccato, Refactoring the aspectizableinterfaces: an empirical assessment, IEEE Transactions on SoftwareEngineering 31 (10) (2005) 819–832.

[35] Tom Tourwe, Johan Brichau, Kris Gybels, On the existence of theAOSD-evolution paradox, in: AOSD 2003 Workshop on Software-engineering Properties of Languages for Aspect Technologies, March2003.

[36] Dianxiang Xu, Wiefing Xu, State-based incremental testing of aspect-oriented programs, in: Proceedings of the 5th International Confer-ence on Aspect-Oriented Software Development (AOSD 2006),March 2006.

[37] Jianjun Zhao, Unit testing for aspect-oriented programs. TechnicalReport SE-141-6, Information Processing Society of Japan (IPSJ),May 2003.

[38] Yuewei Zhou, Debra Richardson, Hadar Ziv, Towards a practicalapproach to test aspect-oriented software, in: TECOS 2004: Work-shop on Testing Component-Based Systems, Net.Object Days 2004,September 2004.

http://www.aspectc.org/fileadmin/documentation/ac-compilerman.pdf

http://www.aspectc.org/fileadmin/documentation/ac-compilerman.pdf

a test driven approach for aspectualizing legacy software using mock systems

Documents