A. AOP and Revision Control Systems

Many RC systems follow the tradition of Source Code Control System (SCCS) [25] in managing revisions of programs as (text) documents organized in files (e.g., RCS [26]). They store and display (textual) differences between successive revisions. They also offer facilities for merging parallel revisions by reconciling the differences. However, AOP by nature defies these principles. First, concerns crosscut the file structure. Second, obliviousness [16] leaves certain crosscutting effects undetected in the (textual) display of files and changes. Third, quantification [17] may escape version dependency management.

For example, let $C$ be a versioned class, and let $A$ be a versioned aspect that advises $C$. Let $C^{\prime}$ and $A^{\prime}$ be newer versions of $C$ and $A$, respectively. Assume that revision $v_{1}$ comprises the set of files $\{C,A\}$; and that revision $v_{2}$ comprises the set of files $\{C, A^{\prime}\}$. Assume that revision $v_{2}^{\prime}$ comprises the set of files $\{C^{\prime}, A\}$, modified in parallel to revision $v_{2}$; and that revision $v_{3}$ comprises the files $\{C^{\prime}, A^{\prime}\}$, by merging revisions of $v_{2}$ and $v_{2}^{\prime}$. Let $\Delta(v_{1}, v_{3})$ denote the “delta” between the two revisions $v_{1}$ and $v_{3}$.

In RC systems, inspecting $\Delta(v_{1}, v_{3})$ typically amounts to displaying $diff(C, C^{\prime})$ and $diff(A, A^{\prime})$, where diff is an external tool for comparing two text files. However, thanks to obliviousness, $A^{\prime}$ may have an effect on (the woven behavior of) $C^{\prime}$ that is not visible in $diff(C, C^{\prime})$. Similarly, thanks to quantification, $A^{\prime}$ may have an effect on $C^{\prime}$ that is not visible in $diff(A, A^{\prime})$. Let $eff(A, C)$ denote the “invisible” crosscutting effect that $A$ has on $C$. Since neither $eff(A, C)$ nor $eff(A^{\prime}, C^{\prime})$ are observable in code, the difference between $eff(A, C)$ and $eff(A^{\prime},C^{\prime})$ is, too, not observable. In addition, $eff(A^{\prime},C)$ and $eff(A, C^{\prime})$ may be of interest but are also “invisible.”

B. Contribution

This work introduces XRC, which stands for Crosscutting Revision Control. XRC is an approach (backed up by a prototyped tool) for better supporting revision control of AOP programs. Intuitively, the core idea of XRC is to persist to the RC system the otherwise transient $eff(A, C)$, as crosscutting metadata (XMD) associated with $C$. This, combined with new RC and IDE capabilities for displaying and comparing the XMD, provides crosscutting revision control for AOP programs that is currently lacking.

The general problem of applying RC to XMD may be broken down into four sub-problems: metadata persistence, metadata comparison, versioned metadata display (viewing a previous version and displaying the differences), and integration with the software development process.

As a proof-of-concept, we prototyped an XRC Eclipse plug-in for AspectJ and Subversion (SVN). Specifically, the plug-in provides:

• Persistent representation of metadata. The XRC plugin maintains the XMD and checks it in with the source code files.

• Diff engine for metadata comparison. Since the crosscutting effect is often not visible in the code, the plug-in introduces a semantic diff that is XMD-aware.

• Visual means for versioned metadata display. Markers and hint messages are currently ignored by the RC system and by the IDE compare tool. The XMD plugin introduces new visual markers and new means to visually display a comparison and present the XMD differences with the compared files.

• RC-IDE Integration. A traditional RC system treats the file as the unit of revision. However, XMD by essence crosscuts the file structure. For example, the XMD may change, while the code in the file remains unchanged. This requires adapting the RC-IDE processes for save, build, check-in, display version, compare versions, etc.

The inherent difficulty in bridging RC and IDE services for AOP stems from their respective biases. Traditional IDE support for AOP is associated with the build process (compilation) in order to provide the necessary weaving information, while RC systems are associated with the storing and retrieving of unwoven files and are ignorant of any weaving information.

We provide a solution for AOP-related XMD. However, the solution can be generalized to handle metadata that represents other kinds of markers. Support for save, compare, and display of metadata might be useful for errors and warnings as well, or any other metadata that is associated with the source code.

A. Being Unaware of an Aspect (Scenario II-A)

Suppose that another developer notices the typo and in the next revision, Account’, corrects the spelling everywhere, except for an occurrence in the code of an aspect (named BlackListAdvice), a reasonable oversight when using the rename refactoring tool in Eclipse. This oversight will often go unnoticed. On comparing the class source code to its previous versions, diff(Account, Account’), the only visual difference is the spelling correction. Figure 1 depicts the Compare view, comparing Account with Account'. There is no indication that the crosscutting effect has changed. Actually, there is no visible reason to expect a different behavior when executing the method.

Figure 1: diff between [Rev:413] and [Rev:412]. No markers are shown despite the existence of an aspect that advises “withdrow” in [Rev:412].

View All

Hopefully, if we were to use JUnit or the like, a test might now fail and yield an error (otherwise this bug would be very hard to discover). In Figure 2a, Account is shown with the typo:

1. AJDT markers indicate the aspect's crosscutting effect.

2. JUnit runs successfully, indicated by a green bar. A limited user was identified, and the account has $50.

In Figure 2b, Account is shown after correcting the typo:

1. There is no indication of the aspect's effect. Seemingly, everything is fine. Note that also the Project view shows no warnings or errors, since it is perfectly legal for an aspect not to advise any method.

2. JUnit fails, indicated by a red bar. A withdraw that should have been rejected was committed successfully.

Figure 2: Account code displayed in Eclipse with the AJDT plug-in.

View All

Listing 1 LimitedUserTester class after the fix

However, inspecting the test code (Listing 1) provides no indication as to why the test has failed, or, for that matter, as to why the test passed in the first place. We only see that a user was added to the black-list, and somehow withdraw should have been blocked with an error. There is nothing to assist the developer in finding and fixing the bug. There is no indication (in the IDE) of any aspect advising the code. Should we discover the aspect that ceased to advise, only then the mysterious bug might be revealed.

B. Fixing Only the Aspect (Scenario II-B)

Alternatively, suppose that the typo was fixed in the BlackListAdvice aspect (but not in the advised classes), and that the aspect was checked in. Consequently, BlackListAdvice ceases to advise Account, resulting in an error that, similarly to the previous scenario, is not observed when inspecting the class Account or its revisions.

A similar scenario could occur in concurrent development. Assume two developers, Sagi and Dave, participate in a project. Sagi works on a Logic domain that is not a crosscutting concern, while Dave is responsible for the Security domain, which is a crosscutting concern. Dave deletes an aspect or changes a pointcut that causes some target in the Logic domain to stop being advised. Dave checks-in his code. Sagi might then find out that his code is broken. It could be difficult for him to discover the reason for the problem, since he does not have a way to identify aspects that advised the previous version but stopped advising the current version of his class.

C. Consequences

RC systems play an important role in supporting a healthy software development process. Loss of RC support has negative consequences on the entire software development processes.

A. Crosscutting Metadata (XMD)

In Section I we denoted by $eff(A,C)$ the crosscutting effect of $A$ on $C$. Since $C$ might be advised by multiple aspects, its XMD sums to:

View SourceXMD(C)={\displaystyle\bigcup_{A}}eff(A, C)

$$XMD(A)={\displaystyle\bigcup_{C}}eff(A,C)$$ View SourceXMD(A)={\displaystyle\bigcup_{C}}eff(A,C)

1) AJDT metadata

The AJDT plug-in displays XMD information visually using markers and hint messages in the Eclipse editor. Internally, AJDT represents the XMD with a map ADT:

$$Map< int, List<IRelationship>>$$ View SourceMap< int, List<IRelationship>>

A key in this map represents a line number in the source code. A value in this map is a list of IRelationship objects, where IRelationship is an interface defined in AJDT. An implementation of IRelationship contains the relevant data of a single piece of advice: source, target list, name, and kind of the advice. This map is the XMD in AJDT.

B. Diff Engine

The diff engine takes the XMD of two class versions, compares them, and returns a data structure with the differences. Comparing only the markers is obviously not good enough, because the same icon might represent different kinds of advice or advice from different aspects.

A simple straightforward comparison would be to compare the pieces of advice per line, and mark the differences. However, this solution gives false positive results. For example, adding a single empty line at a beginning of a class, checking it in, and comparing it with its previous version will flag all the advice as being different from the previous version. A developer will have to inspect each one of them just to conclude that the crosscutting effect stayed the same.

Comparing the pieces of advice sorted according to their line number may still give false positive results, e.g., for a piece of advice that is moved before another piece of advice. In order to avoid such false positives, a piece of advice that has moved from one line to another with the same content is considered unchanged. This is adapted from ldiff [4], [5], an enhanced line differencing tool that is capable of tracking text that was moved to another line, thereby distinguishing line additions and deletions from line modifications.

Each line has a list of IRelationship, each comprising multiple targets that the piece of advice affects. The XRC diff engine compares $XMD(C)$ with $XMD(C^{\prime})$ by first “flattening” the data, then computing the differences, and finally “inflating” the result back into a format that Eclipse understands:

View Sourcediff \ (XMD(C),XMD(C^{\prime}))=\lceil\Delta(\lfloor XMD(C)\rfloor, \lfloor XMD(C^{\prime})\rfloor)\rceil

• flatten: $XMD \longrightarrow Set< IRelationship>$, denoted $\lfloor. \rfloor$, takes an XMD object, and returns a $Set <IRelationship>$ based on the IRelationship objects in the XMD. It breaks each IRelationship with multiple targets into single-target IRelationship objects, and removes the line numbers.

• inflate: $(XMD,Set < IRelationship>)\longrightarrow XMD$, denoted $\lceil. \rceil$, takes an XMD object, and a $Set < IRelationship>$. It constructs and returns a new XMD with the IRelationship objects from the input set restored to their original structure and line numbers, accumulating targets of the same line to a list in order for Eclipse to be able to use the data for displaying the XMD.

C. Visual Enhancements

1) AJDT Markers and Rulers

AJDT displays the mark- ers in the editor, via a ruler to the left of the source, as shown in Figure 2a. Table I summarizes the AJDT marker types, sub-types, and their icons. A marker represents a relationship between the class being edited in the editor and the aspects that advise it (or vice versa, a relationship between the aspect being edited in the editor and the classes it advises). Since one implies the other, the table reflects a symmetry in both the marker types and their icons. AJDT also provides navigation from the aspect to the class and vice versa via a pop-up menu, by clicking on a marker. AJDT markers are created and updated on build.

Table I: AJDT Markers.

Marker type on Class	Marker type on Aspect	Subtype	on Class	Icon on Aspect
Marker type on Class	Marker type on Aspect	Subtype	on Class	Icon on Aspect
before		before_advice		source_before_advice
Advised by	Advises	after		after_advice		source_after_advice
around		around_advice		source_around_advice
advice		advice		source_advice
extension		itd		source_itd
implementation		itd		source_itd
Aspect declarations	Declared on	declare a member		itd		source_itd
declare a method		itd		source_itd
warning		warning		source_itd
error		error		source_itd
Annotated by	Annotates	N/A		itd		source_itd
Soften by	Soften	N/A		itd		source_itd

2) XRC Markers and Rulers

In order to display the differences in a Compare view, we use rulers similar to the one used in the editor. For this, we extended the Eclipse JDT infrastructure to provide support for rulers in a Compare view. A side benefit of this effort is that these rulers can also be used for other tasks that involve displaying markers in the Compare view. On a ruler, named advice-ruler, we display the AJDT markers, and use a changed advice highlight marker (Table II) to emphasize the differences. This marker changes the background of a marker that has changed, and can thus be visually superimposed over existing markers.

Table II: XRC Markers.

Marker type on Class	Subtype	Icon on Class
Changed advice highlight	N/A		changedadvice
add		add2
Changed advice	remove		remove2
modified		modified2f

On a second ruler, named diff-ruler, inspired by the obsolete AJDT Crosscutting Comparison view [6] (reviewed in Section V-B1), we mark the nature of the change. Two addition markers, add and remove (Table II), are used to indicate advice addition and removal, respectively. A fourth marker, named modified (Table II), is used to warn the programmer that the advising aspect (for the marked advice) is not a versioned one, but its state was nonetheless modified when the advised class was checked in.

To understand the need for the modified marker consider the following scenario. Let $C$ be a versioned class. Let $A$ be a versioned aspect that advises $C$. Let $A^{\prime}$ be a modified version of $A$ that was not checked in yet, but advises $C$ differently than $A$. Suppose $C$ is being reviewed and checked-in as $C^{\prime}$, with the metadata that represents $eff(A^{\prime}, C)$. Let $A^{\prime \prime}$ be a modified version of $A^{\prime}$ that advises $C$ differently than $A$ or $A^{\prime}.A^{\prime \prime}$ is checked in, while $A^{\prime}$ was never checked in. This scenario leads to a situation that the metadata of $C$ is allegedly deceptive. $diff(C,C^{\prime})$ will display the modified marker, since $A^{\prime}$ is unattainable, and it can only hint on $A$ as its predecessor. The modified marker helps distinguishing between the situation where the version of the aspect is known and trusted, and the situation where it is unknown and only the previous version of the aspect that has been checked in is known.

D. RC-IDE Integration

XRC is integrated with the IDE and modifies its save, build, check-in, history, and compare processes.

A. Comparing Two Advised Versions

Revisiting the scenarios presented in Section II but this time with the Eclipse plug-in for XRC, comparing the Account to its previous version immediately reveals that something is different with the advice (Figure 3). Rolling the mouse cursor over the marker shows a hint message stating that the BlackListAdvice aspect ceased to advise.

Figure 3: diff between [Rev:413] and [Rev:412] with XRC. In comparison with Figure 1, markers are displayed and compared.

View All

B. Viewing an Advised Revision from SVN History

With the Eclipse plug-in for XRC, markers are displayed also for old versions of Account. In Figure 4, the selected title tab confirms that we are looking at [Rev:320] of MyClass. The figure displays a variety of markers that represent XMD. Note that without the XRC plug-in, none of these markers would have been displayed in the left toolbar.

Figure 4: Viewing an old version [Rev:320] of a class retrieves the XMD from SVN and displays the AJDT markers in the left toolbar.

View All

C. Regaining RC Support for SW Development Processes

D. Threats to Validity

While the findings in Ferrari et al.'s study [14] indicate a need for a tool like XRC, a user study would be needed to assess the effectiveness of the XRC plug-in as a productivity tool in practice. Analyzing what percentage of the faults reported in the study [14] could supposedly be avoided had XRC been used is also a topic for future work.

The XRC tool was built and tested to work with a specific RC system and IDE, namely: SVN version 1.6.3, Eclipse version 3.7 (Indigo), and AJDT version 2.1.3. However, the approach should be applicable in general, and plug-ins can be implemented for other RC systems or for persisting other sorts of metadata.

A limitation of the approach is that the change control provided via XRC depends on the build process to keep the XMD up-to-date. Recall that AJDT updates its markers on build, and XRC is based on AJDT. Consequently, build must be done before check-in. Eclipse requires to perform team > cleanup for a project or a folder in order to synchronize changes with the SVN. This should be done after build, and before code reviews, in order to gain the XRC change control.

However, this limitation can be minimized by setting auto-build in the Eclipse configuration (which is also the default setting in Eclipse). XRC does not require saving the woven classes. For each file, it only persists the source and its relevant XMD, so it is efficient in terms of space requirements. Getting the metadata requires a single read from the RC system. The recommended development process is thus: save, build (if auto-build configuration is not set), review all the changes, and check in all the files that have been changed.

A. AspectJ Development Toolkit

The AJDT Eclipse plug-in adds to the IDE new capabilities for visualizing crosscutting effects. It computes the crosscutting metadata and introduces markers that hint about $eff(A,C)$ when editing $C$ or $A$. Eclipse uses a vertical ruler in the editor in order to display these markers. Additional hint messages are displayed when rolling the mouse cursor over the markers. However, these markers are not saved with the file and thus not checked-in with revisions of $C$ or $A$. AJDT displays this information only for the current version. When viewing previous versions of $C$ and $A$, the markers (which are likely to be different, since different versions of aspect could advise different versions of classes) are not shown.

AJDT uses advice markers in order to display crosscutting metadata in the current version. We reuse the AJDT markers in order to display the same kind of metadata also for viewing a previous version and for displaying the diff of two versions. We added in the Compare view a ruler and designated markers for the purpose of displaying the essence of the change.

B. Obsolete Features of AJDT

Interestingly, early versions of AJDT did include facilities for crosscutting comparison and changes, which were eventually removed.

C. Specialized Differencing Tools

Many semantic differencing tools enhance the simple diff textual comparison tool for the purpose of tracking software evolution. Some analyze the RC repository to better detect high level structural changes (e.g., UMLDiff [27]), infer systematic changes (e.g., LSdiff [22], [23]), or even recommend adaptive changes for keeping up with the software evolution (e.g., SemDiff [8], [9]). In contrast, XRC adds to the RC system repository new XMD information, which is readily available in the IDE but not tracked. This extra information may help mining tools and programmers detect more crosscutting inconsistencies and avoid potential bugs.

D. Crosscutting Configuration Management

TOFRA [1] is a tool that addresses the problem of configuration management (CM) in the context of Crosscutting Frameworks (CFs) [3]. CFs are aspect-oriented frameworks that handles a single crosscutting concern. One or more CFs may be weaved with the application, and CFs might be reused across different applications. TOFRA's support for version control in CF-based development focuses on managing the dependencies among versioned CFs and versioned applications. In comparison, XRC provides actual RC support for developing AOP applications, integrated with the IDE and the RC system.