As programs evolve, newly added functionality sometimes does no
longer align with the original design, ending up scattered across the
software system. Aspect mining tries to identify such cross-cutting
concerns in a program to support maintenance, or as a first step
towards an aspect-oriented program. Previous approaches to aspect
mining applied static or dynamic program analysis techniques to a
single version of a system.We leverage all versions from a system\u27s
CVS history to mine aspect candidates with our Eclipse plug-in
HAM: when a single CVS commit adds calls to the same (small)
set of methods in many unrelated locations, these method calls are
likely to be cross-cutting. HAM employs formal concept analysis to
identify aspect candidates. Analysing one commit at a time makes
the approach scale to industrial-sized programs. In an evaluation we
mined cross-cutting concerns from Eclipse 3.2M3 and found that
up to 90% of the top-10 aspect candidates are truly cross-cutting
concerns

Breu, Silvia

Lindig, Christian

Zimmermann, Thomas

Dagstuhl Research Online Publication Server

HAM: Cross-cutting Concerns in EclipseSilvia BreuUniversity of CambridgeComputer LaboratoryCambridge, UKsilvia@ieee.orgThomas ZimmermannSaarland UniversityDept. of Computer ScienceSaarbru¨cken, Germanytz@acm.orgChristian LindigSaarland UniversityDept. of Computer ScienceSaarbru¨cken, Germanylindig@cs.uni-sb.deAbstractAs programs evolve, newly added functionality sometimes does nolonger align with the original design, ending up scattered across thesoftware system. Aspect mining tries to identify such cross-cuttingconcerns in a program to support maintenance, or as a first steptowards an aspect-oriented program. Previous approaches to aspectmining applied static or dynamic program analysis techniques to asingle version of a system.We leverage all versions from a system’sCVS history to mine aspect candidates with our Eclipse plug-inHAM: when a single CVS commit adds calls to the same (small)set of methods in many unrelated locations, these method calls arelikely to be cross-cutting. HAM employs formal concept analysis toidentify aspect candidates. Analysing one commit at a time makesthe approach scale to industrial-sized programs. In an evaluation wemined cross-cutting concerns from Eclipse 3.2M3 and found thatup to 90% of the top-10 aspect candidates are truly cross-cuttingconcerns.Categories and Subject Descriptors D.2.7 [Software Engineer-ing]: Distribution, Maintenance, and Enhancement—Restructuring,reverse engineering, and re-engineeringGeneral Terms Algorithms, Measurement, Documentation, Per-formance, Design, Experimentation,Keywords Aspect Mining, Aspect-Oriented Programming, CVS,Eclipse, Formal Concept Analysis, Java, Mining Version Archives1. IntroductionAs a program evolves it is easy to overlook that certain functionalityis not or no longer properly encapsulated but scattered over manymethods. Aspect mining aims at identifying such cross-cutting con-cerns, also referred to as aspects. Aspects constitute structural prob-lems that either have to be takes care of manually, through object-oriented refactoring, or by moving towards aspect-oriented pro-gramming (AOP). However, we believe that aspects do not neces-sarily exist from the beginning but may be introduced over time toa system. Motivated by dynamic approaches for aspect mining thatinvestigate execution traces of programs [2, 3], we build our anal-ysis on CVS commits that insert method calls. We are working onan Eclipse plug-in called HAM that will identify such cross-cuttingconcerns and will inform the programmer unobtrusively when sheis about to add more such functionality. She might then go on asplanned, or think about introducing an abstraction to encapsulatethis functionality properly. HAM employs formal concept analysisto compute all potential aspects fromwhich we filter the most likelyones. Aspects from a CVS commit may not be independent but forma hierarchy. Besides showing all instances of an aspect candidate,HAM also visualises this hierarchy to inform the user about poten-tially conflicting aspects.2. Examples from EclipseIn Eclipse, we found numerous aspect candidates, of which a feware presented in more detail in the following.Locking Mechanism. Calls to both methods lock and unlockwere inserted in 1 284 method locations. Here is such a location:public static final native void _XFree(int address);public static final void XFree(int /*long*/ address) {lock.lock();try {_XFree(address);} finally {lock.unlock();}}The other 1 283 method locations look similar. First lock is called,then a corresponding native method, and finally unlock. It is atypical example of a cross-cutting concern which can be easily re-alised using AOP. Note that this lock/unlock concern cross-cutsdifferent platforms. It appears in both the GTK and Motif versionof Eclipse. Typically such cross-platform concerns are recognisedincompletely by static and dynamic aspect mining approaches un-less the platforms are analysed separately and results combined.Bytecode Visitor. Another example for a cross-cutting concernis the call to method dumpPcNumber which was inserted to 205methods in the class DefaultBytecodeVisitor. This class im-plements a visitor for bytecode, in particular one method for eachbytecode instruction; the following code shows the method for in-struction aload 0./*** @see IBytecodeVisitor#_aload_0(int)*/public void _aload_0(int pc) {dumpPcNumber(pc);buffer.append(OpcodeStringValues.BYTECODE_NAMES[IOpcodeMnemonics.ALOAD_0]);writeNewLine();}Dagstuhl Seminar Proceedings 06302Aspects For Legacy Applicationshttp://drops.dagstuhl.de/opus/volltexte/2007/884(A)(B)(C)(D)Figure 1. The HAM plug-in. The Aspect Candidates view (A) lists cross-cutting concerns that can be investigated with other views (B,C,D).View (B) shows the hierarchy of aspect candidates.The call to dumpPcNumber can obviously be realised as an aspect.However, in this case aspect-oriented programming can even gen-erate all 205 methods (including comment) since the methods differonly in the name of the bytecode instruction.Abstract Syntax Trees. Eclipse represents nodes of abstract syn-tax trees (ASTs) by the abstract class ASTNode and several sub-classes. These subclasses fall into the following simplified cate-gories: expressions (Expression), statements (Statement), andtypes (Type). Additionally, each subclass of ASTNode has proper-ties that cross-cut the class hierarchy. An example for a propertyis the name of a node: There are named (QualifiedType) andunnamed types (PrimitiveType), as well as named expressions(FieldAccess). Additional properties of a node include the type,expression, operator, or body.This is a typical example of a role super-imposition concern [8].As a result, every named subclass of ASTNode implements methodsetName which results in duplicated code. With AOP the concerncould be realised via the method-introduction mechanism.public void setName(SimpleName name) {if (name == null) {throw new IllegalArgumentException();}ASTNode oldChild = this.methodName;preReplaceChild(oldChild, name, NAME_PROPERTY);this.methodName = name;postReplaceChild(oldChild, name, NAME_PROPERTY);}Our mining approach revealed this cross-cutting concern withseveral aspect candidates. The methods preReplaceChild andpostReplaceChild are called in the aforementioned setNamemethod; the methods preLazyInit and postLazyInit guaranteethe safe initialisation of properties; and the methods preValue-Change and postValueChange are called when a new operator isset for a node.Cloning. Another cross-cutting concern was surprising because itinvolved two getter methods getStartPosition and getLength.These are always called in clone0 of subclasses of ASTNode andwere also identified by our approach.ASTNode clone0(AST target) {BooleanLiteral result = new BooleanLiteral(target);result.setSourceRange(this.getStartPosition(),this.getLength());result.setBooleanValue(booleanValue());return result;}3. The HAM Plug-inSo far we have implemented a prototype of HAM that identifiescross-cutting concerns from CVS archives and presents the resultsin Eclipse. In our future work, we will inform the programmer un-obtrusively when she is about to change cross-cutting functionality.Figure 1 shows a screenshot when analysing ArgoUML [1](a UML modelling tool) for cross-cutting concerns. In the leftpane (A), the view ”Aspect Candidates” lists all transactions2of the CVS repository for which we found aspect candidates.For the transaction on April 4 2004 HAM finds five candidates:illegalArgument(1) (for which a call was inserted into 45locations), illegalArgument(2) (101 locations), illegal-ArgumentObject(1) (75 locations), illegalArgumentBoolean(1) (27 locations), and illegalArgumentCollection(1)(72 locations).Double clicking a transaction opens the corresponding latticein view ”Concept Lattice” (B) on the lower right hand side. Thisview allows to explore the relationship between candidates. Themiddle layer of five nodes represent the five aspect candidates thatwe found in this particular transaction. In this case, there is no pathfrom the top to the bottom node that visits two aspect candidates.Thus, the locations of the candidates are disjoint and unlikely tointerfere.Double clicking an aspect candidate (in any view) opens the”Search” view (C) of Eclipse in the lower left pane. This viewlists all locations where a candidate was inserted. In our example,illegalArgumentBoolean was called in 27 location—amongthem equalsPseudostateKind. We can now inspect the codein the editor on the upper right hand side (D) and verify that thecandidate is actually cross-cutting.4. Underlying TechniqueIn the following, we describe in more detail what our prototypeHAM and approach builds upon.4.1 PreprocessingOur approach can be applied to any version control system. How-ever, we based our implementation on CVS since most open sourceprojects currently use it. First, we reconstruct CVS commits with asliding time window approach [10]. A reconstructed commit con-sists of a set R of revisions where each revision r ∈ R is the resultof a single check-in.Additionally, we compute method calls that have been insertedwithin a commit operation R. A commit R is a set of changedlocations—in our case locations are method bodies but could beclasses or packages as well. For every location l that was changedinR we compute the setM(l) of added method calls by comparingthe abstract syntax tree of l before and after commit R. As a resultwe obtain a set T (R) = {(l,m) | l ∈ R,m ∈M(l)} of new callsfrom location l to method m. We call a set T (R) of new calls atransaction; transactions serve as main input for our aspect mining.Here is an example from the Eclipse project:{(DefaultBytecodeVisitor. aaload(int), dumpPcNumber(1)),(DefaultByteCodeVisitor. aastore(int), dumpPcNumber(1)),(DefaultByteCodeVisitor. aload(int, int), dumpPcNumber(1))}Into three locations aaload, aastore, and aload a call tomethod dumpPcNumber(1) was inserted. In order to reduce com-putational cost, we analyse only the differences between single re-visions but not between the resulting programs before and after arevision. Therefore we cannot resolve signatures for called meth-ods. Instead we use their names (e.g., dumpPcNumber) and numberof arguments (e.g., 1). For more details on our preprocessing, werefer to the APFEL plug-in [9].4.2 Mining TransactionsFor our analysis, history (of a program) is a sequence of transac-tions. Each transaction is a set of added method calls (l,m) fromlocation l to methodm1. A transaction T is formally a relation andcan be depicted as a cross table between locations L and methodsM—cf. Figure 2 .1We ignore changes and deletions of calls as we are only interested inaspects emerging over time.Methodscomplex aspectcandidatesimple aspectcandidatelog lockunlockLocationsTFigure 2. A transaction T ⊆ L×M is a relation between locationsL and methods M. The maximal (rectangular) blocks of T areaspect candidates, which form a hierarchy.Simple Aspects. When a transaction inserts calls to a loggingmethod log in 10 locations these calls show up in the cross table asa block of size 1× 10 (given an appropriate order of locations). Weconsider adding a call to be an aspect candidate when it cross-cutsat least 8 locations. At each location where a call to log was added,calls to other methods may have been added as well. Still, aspectswhere a call to a single method (like log) is added are simple todetect in a transaction by sorting calls (l,m) by the called methodm. We call these simple aspect candidates. Obviously a candidateis more likely to be a genuine aspect when the number of locationsit cross-cuts is high.Complex Aspects. Some aspects come as pairs of function calls:a call to lock for locking a resource is typically followed by a callto unlock. Given an appropriate order of rows and columns, theaddition of calls to lock and unlock in 10 locations also showsup as a (2 × 10) block in the cross table. We call the addition ofcalls to two or more methods a complex aspect candidate. Again,we consider such a block only a candidate if it cross-cuts at least8 locations. Unlike simple aspect candidates, it is not obvioushow to detect such complex aspect candidates in a transactionefficiently.4.3 Formal Concept AnalysisThe problem of identifying all blocks is the subject of formal con-cept analysis, an algebraic theory for binary relations [6], whichalso provides efficient algorithms [7]. A maximal block in a trans-action T ⊆ L × M is a pair (L,M) of locations and methodswhere the following holds:L = {l ∈ L | (l,m) ∈ T for allm ∈M}M = {m ∈M | (l,m) ∈ T for all l ∈ L}Formal concept analysis considers all blocks in a relation, not justthose exceeding certain limits. The definition of blocks in particularallows for blocks with one empty component and subsumes simpleand complex aspect candidates. We therefore compute all blocksand filter them later for aspect candidates.Interestingly, blocks and therefore aspects form a lattice, de-fined by the partial order (L,M) ≤ (L′,M ′) ⇔ L ≤ L′. How-ever, typically the aspect candidates of a transaction are incompara-ble. Figure 3 shows the lattice of blocks for such a transaction fromthe Eclipse project.5. Experience and ResultsBecause a cross table of size n × n may have up to 2n blocks,concept analysis is potentially expensive. This has not been a prob-lem so far: for 43 270 transactions in the Eclipse CVS repository,the average transaction adds 5.4 calls in 3.8 locations and has3.7 blocks. However, the largest transaction had 1235 blocks. Onaverage, computing all blocks for a transaction took less than 1 sec.31132 511 121415 17 18193 4 7 16 20 2122 6 89102324 2526027Figure 3. Hierarchy of blocks from an Eclipse transaction. Block 6is an aspect candidate, cross-cutting 14 locations.Aspect Candidates in Eclipse 3.2M3methods 1 2 3 ≥ 4candidates 1878 363 88 24Table 1. Aspect candidates mined from 43 270 CVS transactionsfor Eclipse 3.2M3. There are 88 candidates that added exactly 3method calls.The 43 270 transactions of the Eclipse CVS archive constitute159 448 blocks. From these we mined 2353 aspect candidates,with the distribution shown in Table 1. We found 1878 simple and363 + 88 + 24 = 475 complex candidates.In [4] we had previously mined Eclipse for simple and com-plex aspect candidates, albeit with a less general approach. Therewe reported 31 unique complex candidates that cross cut at least20 locations (out of which we found 6 to be true aspects and ad-ditional 3 to be partial aspects). With our new approach we found64 unique aspect candidates, including all 31 aspect candidates re-ported in [4]. This confirms our two claims: formal concept anal-ysis provides the right formal and algorithmic framework to mineaspects, and aspects can be mined efficiently from large projects byanalysing code additions over time.6. ContributionsWe are the first to leverage version history to mine aspect can-didates. The underlying hypothesis and motivation is that cross-cutting concerns may emerge over time. Our work shows that ver-sion archives are indeed useful for aspect mining.HAM adds a new dimension to aspect mining. Previous work onaspect mining considered only a particular version of a pro-gram. Our approach uses project history as additional input.This enables a new view on the evolution of aspects.HAM scales and is platform independent. HAM is the first as-pect mining approach that scales to industrial-sized projectslike Eclipse. Furthermore, it recognises cross-cutting concernsacross code for different platforms.HAM comes with high precision. We thoroughly evaluated 405aspect candidates returned by HAM [4]. The precision increaseswith project size and history, for Eclipse up to 90% for the top-10 candidates. For small projects, HAM suffers from the muchfewer data available, resulting in lower precision (about 60%).For for more information on HAM, log on to:http://www.st.cs.uni-sb.de/softevo/References[1] ArgoUML. ArgoUML project homepage. http://argouml.tigris.org/.[2] S. Breu. Aspect Mining Using Event Traces. Master’s thesis,University of Passau, Germany, March 2004.[3] S. Breu and J. Krinke. Aspect Mining Using Event Traces. In Proc. of19th Intl. Conf. on Automated Software Engineering (ASE), pp. 310–315. IEEE Press, 2004.[4] S. Breu and T. Zimmermann. Mining Aspects from Version History.In 21st IEEE/ACM International Conference on Automated SoftwareEngineering (ASE), Tokyo, Japan, September 2006.[5] S. Breu and T. Zimmermann and C. Lindig. Mining Eclipse forCross-Cutting Concerns. In Proc. Intl. Workshop on Mining SoftwareRepositories (MSR), Shanghai, China, May 2006.[6] B. Ganter and R. Wille. Formal Concept Analysis: MathematicalFoundations. Springer, Berlin, 1999.[7] C. Lindig. Fast concept analysis. In G. Stumme, editor, Working withConceptual Structures – Contributions to ICCS 2000, pages 152–161,Germany, 2000. Shaker Verlag.[8] M. Marin, L. Moonen, and A. van Deursen. A Classification ofCrosscutting Concerns. In ICSM, pp. 673–676. IEEE ComputerSociety, 2005.[9] T. Zimmermann. Fine-grained Processing of CVS Archives withAPFEL. Technical Report, Saarland University, Saarbru¨cken, Ger-many, 2006. Available online at: http://www.st.cs.uni-sb.de/softevo/[10] T. Zimmermann and P. Weißgerber. Preprocessing CVS data forfine-grained analysis. In Proc. Intl. Workshop on Mining SoftwareRepositories (MSR), Edinburgh, Scotland, May 2004.4

HAM: Cross-cutting Concerns in Eclipse

http://drops.dagstuhl.de/opus/volltexte/2007/884/pdf/06302.BreuSilvia.Paper.884.pdf

HAM: Cross-cutting Concerns in Eclipse

Abstract

Similar works

Full text

Available Versions

Dagstuhl Research Online Publication Server