General Terms
A Program Analysis for Tool-supported Refactoring of
Aspect-oriented Programs
Jan Wloka
Fraunhofer FIRST
Kekulstr.7
Berlin,Germany
jan.wloka@?rst.fraunhofer.de
Stefan J¨ahnichen T echnical University Berlin Franklinstr.28/29
Berlin,Germany jaehn@cs.tu-berlin.de
Categories and Subject Descriptors
D.2.7[Software Engineering]:Distribution,Maintenance, and Enhancement;F.3.2[Logics and Meanings of Pro-grams]:Semantics of Programming Languages—program analysis;D.3.3[Programming Languages]:Language Con-structs and Features—patterns,classes and objects
General Terms
Algorithms,Measurement,Languages,Reliability
Keywords
Software refactoring,Aspect-oriented programming,Change impact analysis,Static program analysis,Code generation 1.PROBLEM&MOTIV ATION
Aspect-oriented programming(AOP)has been proposed for improving the modularity of implementations that can-not be encapsulated with traditional means,so called cross-cutting concerns.It introduces new adaptation concepts that allow the structural extension of implementation mod-ules and the adaptation of existing program behavior.
The adaptation concepts are often achieved by new language mechanisms and constructs,such as pointcut and advice.A pointcut speci?es where and when an advice is executed by selecting well-de?ned points in the program execution,so called join points.Every time a join point is executed,some runtime support looks for matching pointcuts.If a matching pointcut is de?ned,every bound advice is executed.With this complex but powerful mechanism,aspects can declare an adaptation without modifying the source of the adapted implementation module.
For selecting a set of join points,a pointcut can specify structural and behavioral properties that have all desired join points in common.These properties are anchored in internal program structures,such as the program’s name space,code containment,inheritance relationships or the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro?t or commercial advantage and that copies bear this notice and the full citation on the?rst page.To copy otherwise,to republish,to post on servers or to redistribute to lists,requires prior speci?c permission and/or a fee.
Doctoral Symposium FSE14,2006Portland,Oregon USA
Copyright2006ACM X-XXXXX-XX-X/XX/XX...$5.00.control?ow.A pointcut expresses a join point property by referencing the anchor structures and elements,and thereby ties the advice execution closely to these implementation in-ternals.For example,the pointcut
call(public int A.bar())
&&withincode(public void A.foo())
selects all method calls of method bar()that are de?ned within method foo().Additionally,it references the decla-rations of class A and method foo(),although these ele-ments does not belong to the selected join point set.Hence, any modi?cation of class A or method foo(),e.g.,by a refactoring,does not modify selected join points,but may break the pointcut and therefore the speci?ed advice execu-tion.
Refactorings for aspect-oriented programs have to preserve the anchor structures and elements but also still allow to im-prove the program’s design.A refactoring tool that is able to identify these structures,can allow safe modi?cations(even if they a?ect the set of selected join points),identify and adjust a?ected pointcuts and prevent the programmer from breaking a pointcut.
2.RESEARCH PROPOSAL
A classi?cation of the change impact of object-oriented refactorings on pointcuts is investigated to cope with the fragile pointcut problem in tool-supported refactoring. 3.BACKGROUND&RELATED WORK Various approaches have been proposed to cope with the issues arisen by the tight coupling between aspects and the base program.The most related results provide extensions to object-oriented refactorings,new IDE support for deter-mining altered pointcut matches and more expressive point-cut languages,making a pointcut less coupled to brittle im-plementation details.This section describes the refactoring and program analysis related approaches in more detail. 3.1Aspect-oriented Refactoring
In[4,1,2,7,3,9]new refactorings for aspect-oriented programs has been identi?ed which allow the improvement of object-oriented programs by using AO-modlarization,the refactoring of aspect language constructs or the refactoring of base code while existing AO adaptations are preserved. In particular,Monteiro et al.have published in[4]a cata-logue of new refactorings and bad smells for AspectJ pro-grams.
Ceccato et al.present in[1]an AOPMigrator which supports the extraction of class members and statements into aspects. They propose a speci?c refactoring work?ow that generates a single pointcut for every extracted program element. Hannemann et al.present in[2]also a tool for extracting crosscutting concerns into aspects.The tool supports a spe-ci?c work?ow for migrating design patterns implemented in Java to an AspectJ implementation.
All these refactoring approaches have to cope with base code changes that may a?ect existing pointcuts.Our ap-proach reveals altered join point selections,proposes suit-able pointcut updates and generates rephrased pointcuts. Thus it can be seen as fundamental to AO refactoring in general.
3.2Behavior Preservation in AO Refactoring Hanenberg et al.describe in[9]initial ideas on how to treat pointcuts within a refactoring work?ow.They ex-tended the refactoring constraints to preserve the number of selected join points,the position of a selected join point within the program’s control?ow and the information pro-vided at a selected join point for every pointcut.Based on these additional constraints,the previous program behavior is reestablished by updating a?ected pointcuts.
Two problems are not considered in this approach:(i)a pointcut may intentionally select additional join points after a refactoring and(ii)join points are points in the program execution which have to be statically approximated.
Rura and Lerner advance the AO-speci?c refactoring con-straints in[7].They present a”pointcut pattern equiva-lence”constraint,that reduces the rule”each advice must apply at semantically equivalent join points”to a more sim-ple determinable but stronger requirement”signature pat-terns used in a pointcut must match semantically equivalent program elements”.In cases where the signature patterns do not match the same elements as before the refactoring, the patterns are broadened/narrowed in a way that new and lost pattern matches are prevented.
However,additional and lost matches are always excluded or included,which makes,on the one hand,pointcuts un-recognizable and worse readable,and,on the other hand, it does not consider the programmer’s intention behind a pointcut.
Our approach can be seen as an extension to this work. We explicitly consider the change impact of a refactoring by assigning atomic changes with a distinct impact on a pointcut to referenced program structures(i.e.,pointcut ex-pressions).Rura and Lerner’s approach is limited to pattern matches,which e.g.,does not allow to move a program ele-ment if its matching pattern is restricted by a certain loca-tion(i.e.,intersected with a within expression).We distin-guish if a referenced program element is the actual join point shadow or used to specify one of its properties.With this distinction,we can ensure semantically equivalent matches not only of signature patterns,but also of every program structure used to express a join point property.
3.3Change Impact Analysis
Another possibility to cope with fragile pointcuts is tool support that assesses changes between two program ver-sions.Such an assessment can be done either by comparing to di?erent program versions or by analyzing the applied changes.
An approach that detects di?erently bound advices by com-paring two program versions is presented by St¨o rzer and Graf in[10].The proposed pointcut delta analysis approxi-mates the bound join points for every pointcut and compares the pointcut matches between two program versions.New, lost and modi?ed(in terms of match quality)matches are discovered.
Our change impact analysis extends this approach in sev-eral ways.The computed match delta is extended to a so called pointcut selection delta that contains matches of ev-ery referenced program structure,rather than only complete pointcut matches.The selection delta entries are directly associated with the responsible change.This direct associa-tion allows the automated calculation of pointcut updates. Similar to Ryder et al.in[6,8]we divide program edits (performed by a refactoring)into their constituent atomic changes amenable to program analysis.Atomic changes have syntactic dependencies,denoting prerequisite relation-ships and represent a distinct impact on the program’s source. Based on the atomic change model Ryder et al.have devel-oped di?erent change classi?cations that indicate the likeli-hood of a change to be failure-inducing.Every change can be labeled,as red(highly likely to be failure-inducing),yel-low(somewhere in between)or green(highly unlikely to be failure-inducing).
In contrast to Ryder et al.we do not employ the atomic changes to identify a?ected unit tests,but a?ected point-cuts.Our change classi?cation indicates the likelihood of a change to break the program structures a pointcut relies on.
A combination of both approaches allows to separate changes that just alter the set of pointcut matches from changes that break the pointcut.With this separation a tool can be enabled to deny critical transformations while it safely performs all others.
4.HYPOTHESIS
In aspect-oriented programs,a pointcut de?nes where and when advices are executed by selecting a set of join points. It can specify some structural and behavioral properties that have all join points in common.A set of selected join points can be unintentionally altered through various(even local) source code changes.In order to decide if a certain change actually breaks a pointcut,two di?erent kinds of changes have to be distinguished:changes that a?ect a program ele-ment that possesses speci?ed properties(join point shadows) and changes that a?ect a structure or element that is ref-erenced by the pointcut for expressing a certain property (pointcut anchor).
This distinction allows a refactoring tool to decide whether a certain transformation alters the resulting join point set (no pointcut update),modi?es a referenced structure or ele-ment(adjust the pointcut)or breaks a referenced structure or element(cancel the refactoring).
5.A CHANGE IMPACT CLASSIFICATION
FOR POINTCUTS
A refactoring tool for aspect-oriented programs has to preserve structural and behavioral adaptations de?ned in aspects.Extended preconditions ensure that de?ned struc-
tural adaptations are considered in behavior preservation checks and additional transformations adjust new and addi-tional references in aspect modules.
The preservation of behavioral adaptations,however,needs quite more tool support to achieve a similar result.Point-cuts refer to program structures and elements,but they dif-fer in several ways from”traditional”symbolic references.
A pointcut can be seen as
?a multi reference,as it can bind multiple join points,?a fuzzy reference,as it binds join points by specifying some of their common properties,and
?a meta-level reference,as it refers to program struc-tures and elements from the meta-level.
The major di?erence is that a pointcut can intend the bind-ing of newly created join points,such as the pointcut call(*) selects all method calls in a program,regardless how many will be added in the future.
Consequently,the preservation of pointcuts during a refac-toring can follow two di?erent strategies:(i)the preserva-tion of the existing program behavior,i.e.,the advices are invoked in exactly the same situations as before the refactor-ing,or(ii)the preservation of the pointcut’s meaning,i.e., the advice execution can be altered in situations where the execution conditions are not modi?ed by the refactoring. Some of the above presented approaches follow the?rst strategy.In the following we will describe how the second strategy can be achieved and how a tool can decide which strategy has to be applied.
5.1Modeling Refactoring Changes
A refactoring(if applied)always performs the same trans-formations.We are interested in changes of program ele-ments that can generally be referenced by a pointcut.Thus, we model every edit done by a refactoring’s transformation at the level of join points as so called atomic changes.The atomic changes comprise addition and deletion of program elements,such as classes,methods,?eld and expressions. The atomic change model combines every atomic change with its change reason represented by the code transforma-tion.Figure1shows the extract method refactoring,de?ned in a similar way as by Opdyke in[5].Two low-level refac-torings are performed for a given list of statements(L)and a given method(M)name are mapped to three transforma-tions that are provided by the refactoring tool.Every trans-formation causes its speci?c atomic changes:added method (AM),deleted expression(DE),added expression(AE). Every atomic change has a distinct impact on the join point space,smaller changes are ignored(because of no im-pact on pointcuts)and bigger changes are composed of other atomic changes.Since more complex refactorings are com-posed of low-level refactorings,the change of every refactor-ing can be represented in terms of atomic changes.
5.2Decomposition of Pointcuts
A pointcut can select a set of join points by specifying their properties, e.g.,the AspectJ pointcut call(public void foo())&&withincode(public void bar()),selects all calls of method foo()that are located within the method bar().The pointcut expresses this property by referring to the
ExtractMethod(L,M):=
CreateMethodDeclaration(M)
+ReplaceStatementListW ithMethodCall(L,M) ExtractMethod(L,M):=
CreateMethodDeclaration(M)
+MoveStatementList(L)
+CreateMethodCall(M)
ExtractMethod(L,M):=
{(AM,CREAT E),(AE,MOV E),
(DE,MOV E),(AE,CREAT E)}
Figure1:Atomic changes of the extract method refactoring
?signatures of method foo()and bar(),
?calls of method foo(),i.e.,join points must be method
calls and calls of method foo()
?containment of method bar()’s body,i.e.,join points
must be in there.
We have developed a model for decomposing AspectJ-like pointcuts into elementary pointcut expressions.If we con-sider the AspectJ pointcut again,it can be decomposed in within(
call(method({public},type(void),”foo”,{type(void)})), method({public},type(void),”bar”,{type(void)})) Every pointcut expression,like type,method,call and within, speci?es a single reference to a program structure,e.g.,method refers to the signature of method declarations,call to calls of a method and within(target,anchor)to the containment between target and anchor.
We gain three major bene?ts from decomposition of point-cuts:
?(i)we know which join point property is speci?ed,by
referring to which program structures,
?(ii)we know the speci?cation quality,i.e.,whether a
reference to a structure or element is partially(using
*,or..)or completely speci?ed,and
?(iii)we represent the e?ects of an atomic change di-
rectly as association to pointcut expressions.
5.3Change Impact Analysis
Based on the atomic change model and the decomposed pointcuts we have developed a change impact analysis that determines new and lost pointcut matches and associates them with the responsible atomic change.
The?rst step decomposes every pointcut into elementary pointcut expressions as described above.The decomposed representation is normalized into a disjunctive normal form (DNF),expressing commonly speci?ed join point properties within a logical formula combined by”||”operators.
In a second step,a static program analysis calculates the pointcut matches by computing the matches for every point-cut expression(PCE).The resulting structure holds all match-ing program structures and elements.The so called pointcut selection(PCS)is calculated twice,for the original and the
CI :AC ×P CS ?→P CD ×P CE ×T RANS AC ={added,deleted }P CD =S
{+matches,?matches }
T RANS ={CREAT E,REMOV E,RENAME,
MOV E }Figure 2:Change impact representation P CUP :SQ ×CI ×T RANS ?→
{NoUp,ExM,InM,Ask,Err }
Figure 3:Pointcut update proposition
refactored program.
In the third step ,a comparison of both pointcut selec-tions computes a delta (PCD)and augments every delta entry with the change reasons (TRANS)from the atomic change model (AC).The resulting impact structure (CI)holds only deltas which actually a?ect a pointcut,e.g.,a renamed method that causes additions and removals of the ”same”(semantically equivalent)matches is ignored.The resulting impact structure is shown in Figure 2.
5.4Pointcut update Computation
For a reasonable update decision the speci?cation quality (SQ)is taken into account in addition to the change impact.Every modi?ed program structure or element that is ref-erenced by a partially speci?ed pointcut expression cannot simply be updated.Especially if a pointcut anchor (element)is modi?ed in a way that the pointcut matches di?erently,the tool has to consult the programer.Partially speci?ed pointcut anchor make the update calculation often impossi-ble.The analysis ?nally proposes either to keep the original pointcut (NoUp),to include lost matches (InM)or exclude additional matches (ExM),to ask for the programmer’s de-cision (Ask)or to cancel the refactoring (Err).
6.RESULTS &CONTRIBUTIONS
The following contributions are expected from this work.An atomic change model is developed for representing typi-cal changes done by refactorings.Every atomic change rep-resents a distinct e?ect on program structures that can be referenced by pointcuts and relates it the responsible trans-formation (change reason).
A model for decomposing pointcuts into elementary pointcut expressions is de?ned,that makes every referenced program structure and element explicit and distinguishes between ref-erences to join point shadows (pointcut matches)and other references used for expressing a certain join point property (pointcut anchors).
De?nition and evaluation of a change classi?cation .The atomic changes done by typical refactorings are classi?ed regarding their e?ects on pointcut matches.If a change re-sults in altered pointcut matches,the classi?cation de?nes the e?ects on a pointcut in terms of speci?cation quality (of a?ect pointcut expression),match impact (pointcut match or anchor)and change reason (create,remove,rename,move etc.).
A change impact analysis for pointcuts is developed,which
allows the computation of an update proposal.Considering the de?ned change classi?cation any a?ected pointcut ex-pression is either not adjusted,broadened (to include lost matches),narrowed (to exclude new matches)or labeled as broken or unresolvable.
De?nition of pointcut update patterns (as extensions to refac-torings).In speci?c circumstances an a?ected pointcut ex-pression can be completely replaced by an adjusted expres-sion.A few patterns are de?ned that to replace a pointcut expression,rather than broadening or narrowing it.
A small impact visualization is developed depicting reasons and e?ects in terms of how many new,lost and equal matches are caused by which change.The bene?t of this simple visu-alization metaphor is evaluated especially for partial speci-?cations.
A prototype refactoring tool is developed as extension to the Eclipse JDT refactoring support.It appends two additional refactoring steps,pointcut impact review and pointcut up-date,to the refactoring work?ow.The tool implements the proposed analysis and pointcut update approach as well as the impact visualization.It will be the foundation for eval-uating the change classi?cation and pointcut update propo-sition strategy.
The current state of this work encloses the atomic change model,the decomposition into elementary pointcut expres-sions,a preliminary change classi?cation,the change impact analysis as well as extended refactoring patterns and the def-inition of an aspect-aware refactoring process.Furthermore,the implementation of the impact analysis works for some pointcuts and few refactorings.The impact visualization and pointcut update proposition is currently under develop-ment.A pre-release of the prototype was already presented.
7.EV ALUATION STRATEGY
Existing AOP programs,probably implemented in As-pectJ,will be augmented with unit tests.Every unit test does not test the aspect,rather than its e?ects on a certain base code functionality.As a result,whenever an advice binding is altered the tests will fail.
Change impact analysis.Several adapted refactorings that a?ect either the pointcut anchors,the pointcut matches or none of them will be applied.The tests will help to val-idate our expectations.In every case,the analysis should determine the correct impact.
Pointcut update https://www.wendangku.net/doc/d216061888.html,binations of four di?er-ent kinds of pointcuts (simple,complex,partial and com-plete)will be speci?ed and refactorings which either modify a pointcut matches or an anchor will be applied.Again the unit tests are used to check if the proposed pointcut update is correct.
Pointcut update patterns.In many cases the extended pointcut expressions (if broadened or narrowed)can be sim-pli?ed by just replacing the original expression.We validate for several situations whether the proposed simpli?cation is valid.
Acknowledgments
This work has been supported by the German Federal Min-istry for Education and Research under the grant 01ISC04A (Project TOPPrax).
8.REFERENCES
[1]David Binkley,Mariano Ceccato,Mark Harman,
Filippo Ricca,and Paolo Tonella.Automated
refactoring of object oriented code into aspects.In
ICSM,pages27–36.IEEE Computer Society,2005. [2]Jan Hannemann,Gail Murphy,and Gregor Kiczales.
Role-based refactoring of crosscutting concerns.In
Tarr[11],pages135–146.
[3]Masanori Iwamoto and Jianjun Zhao.Refactoring
aspect-oriented programs.In Omar Aldawud,
Mohamed Kand′e,Grady Booch,Bill Harrison,
Dominik Stein,Je?Gray,Siobh′a n Clarke,
Aida Zakaria Santeon,Peri Tarr,and Faisal Akkawi,
editors,The4th AOSD Modeling With UML
Workshop,October2003.
[4]Miguel Monteiro and Joao Fernandes.Towards a
catalog of aspect-oriented refactorings.In Tarr[11],
pages111–122.
[5]William F.Opdyke.Refactoring Object-Oriented
Frameworks.PhD thesis,University of Illinois at
Urbana-Champaign,Urbana-Champaign,IL,1992. [6]Xiaoxia Ren,Barbara G.Ryder,Maximilian Stoerzer,
and Frank Tip.Chianti:a change impact analysis tool for java programs.In ICSE’05:Proceedings of the
27th international conference on Software engineering, pages664–665,New York,NY,USA,2005.ACM
Press.
[7]Shimon Rura and Barbara Lerner.A basis for AspectJ
refactoring.In Third International Conference on
Generative Programming and Component Engineering (GPCE’04).ACM,2004.
[8]Barbara G.Ryder and Frank Tip.Change impact
analysis for object-oriented programs.In PASTE’01: Proceedings of the2001ACM SIGPLAN-SIGSOFT
workshop on Program analysis for software tools and
engineering,pages46–53,New York,NY,USA,2001.
ACM Press.
[9]Rainer Unland Stefan Hanenberg,
Christian Oberschulte.Refactoring of aspect-oriented
software.In Rainer Unland,editor,NetObjectDays,
volume2591of Lecture Notes in Computer Science.
Springer,2003.
[10]Maximilian St¨o rzer and J¨u rgen https://www.wendangku.net/doc/d216061888.html,ing pointcut
delta analysis to support evolution of aspect-oriented
software.In ICSM,pages653–656.IEEE Computer
Society,2005.
[11]Peri Tarr,editor.Proc.4rd Int’Conf.on
Aspect-Oriented Software Development(AOSD-2005).
ACM Press,March2005.