An Abstract Interpretation Framework for Refactoring with Application to Extract Methods with Contracts Patrick Cousot
Radhia Cousot
Francesco Logozzo
ENS, CNRS, INRIA & NYU CNRS, ENS, INRIA
[email protected] {cousot, rcousot}@ens.fr
Abstract
Microsoft Research {logozzo,mbarnett}@microsoft.com Keywords Abstract interpretation, Design by contract, Method extraction, Program transformation, Refactoring, Static analysis.
Method extraction is a common refactoring feature provided by most modern IDEs. It replaces a user-selected piece of code with a call to an automatically generated method. We address the problem of automatically inferring contracts (precondition, postcondition) for the extracted method. We require the inferred contract: (a) to be valid for the extracted method (validity); (b) to guard the language and programmer assertions in the body of the extracted method by an opportune precondition (safety); (c) to preserve the proof of correctness of the original code when analyzing the new method separately (completeness); and (d) to be the most general possible (generality). These requirements rule out trivial solutions (e.g., inlining, projection, etc.) We propose two theoretical solutions to the problem. The first one is simple and optimal. It is valid, safe, complete and general but unfortunately not effectively computable (except for unrealistic finiteness/decidability hypotheses). The second one is based on an iterative forward/backward method. We show it to be valid, safe, and, under reasonable assumptions, complete and general. We prove that the second solution subsumes the first. All justifications are provided with respect to a new, set-theoretic version of Hoare logic (hence without logic), and abstractions of Hoare logic, revisited to avoid surprisingly unsound inference rules. We have implemented the new algorithms on the top of two industrial-strength tools (CCCheck and the Microsoft Roslyn CTP). Our experience shows that the analysis is both fast enough to be used in an interactive environment and precise enough to generate good annotations.
1.
Introduction
In their everyday activity, professional programmers heavily rely on the use of refactoring tools to improve, simplify, clean up, document, and modularize their code. Modern Integrated Development Environments (IDE) such as Eclipse, IntelliJ IDEA, or Visual Studio offer simple user interfaces to automate very tedious and error-prones activities. Method extraction is used at design time to avoid code-bloat, to improve code readability, to emphasize reuse, and to simplify methods. Method extraction consists in selecting a piece of code and asking the IDE refactoring engine to produce a new version of the program where: (i) the selected code is replaced by a call to a newly generated method (the extracted method); and (ii) the extracted method’s parameters are the variables used (read/written) in the selected code and its body is the selected code. The engine must guarantee that the new program is a syntactically legal program, i.e., if the original program compiled with no errors, then the new one compiles successfully, too. Furthermore, the concrete semantics of the original program (up to the additional method call) should be preserved in the new version. The problem of generating a syntactically correct refactored program (e.g., [21, 24, 31]) is now considered a solved problem. However, the interaction between refactoring and static program analysis and verification has received minimal, if any, attention. We are interested in the interaction between method extraction and static analysis and verification in a Design by Contract context (DbC) [35]. We focus our attention on the inference of good contracts (preconditions and postconditions) for the extracted method. Contracts are useful for the automatic generation of documentation and for the separate modular analysis and verification.In DbC, contracts are used to reason across method boundaries. Our static analysis is based on an assume/guarantee reasoning where the correctness proof is split between the callee and the caller. During the analysis of a method body, its precondition is assumed and the postcondition should be proved. Dually, when the caller is analyzed, the precondition of the callee should be proven and its postcondition can be assumed.
Categories and Subject Descriptors D. Software [D.1 Programming Techniques]: D.1.0 General, D.2.1 Requirements/Specifications, D.2.2 Design Tools and Technique, D.2.4 Software/Program Verification, D.2.5 Testing and Debugging General Terms Design, Documentation, Experimentation, Human Factors, Languages, Reliability, Verification.
[Copyright notice will appear here once ’preprint’ option is removed.]
Paper
Michael Barnett
1
2013/10/25
Currently, refactoring tools bind the programmer to manually add the contracts in order to prove the modified method with its call to the extracted method (e.g., by adding postconditions to the extracted method). Our goal is not only to infer the contracts automatically, but also to have good contracts. Intuitively, a good inferred contract should: (a) be valid for the extracted method (validity); (b) guard the language and programmer assertions in the body of the extracted method by an opportune precondition (safety); (c) preserve the proof of correctness of the original code when analyzing the new method separately (completeness); and (d) be the most general possible (generality). In particular, the generality requirement allows the new method to be called in contexts other than the original refactoring context, and it rules out trivial solutions such as, e.g., projecting the abstract states at the beginning and the end of the selected text.
2.
wise the execution will definitely fail later. The precondition is not sufficient to ensure that NewMethod is correct, though. It reports that it cannot prove that the postcondition of Decrement holds on exit (messages #2, #3) and that the decrement of x does not underflow (message #4). The imprecision is caused by the modular reasoning perfomed by CCCheck: it analyzes each method in isolation, using method contracts as summaries for all called methods. So when analyzing Decrement, since NewMethod has no contracts, it assumes the worst case: the return value of NewMethod can be any integer. And when analyzing NewMethod, since it has no contracts, x is unconstrained: the decrement may underflow (e.g., for an initial negative value of x). Our work is motivated by the weaknesses of the following state-of-the-art strawman solutions. First solution: Method Inlining One way to solve the problem is to perform the inverse operation of method extraction: method inlining. In general, inlining makes the analysis more precise. Nevertheless, we reject this solution. We want the analysis to be modular, and to use only boundary annotations to reason on method calls. Boundary annotations have many advantages. First, they provide documentation for the method. Accurate documentation and early error-checking (e.g., by means of defensive programming) are crucial aspects of robust programming. Second, they make the analysis more scalable: a method can be analyzed once and its results/specification can be used many times. Conversely, inlining may cause code bloat, with the same piece of code analyzed again and again. Third, boundary annotations provide check gates, which help in quickly understanding regressions and make the analysis results easier to understand for the end-user. For example, let us suppose that a method m returns a positive value, and that this fact is used by the callers to infer some complex property φ which eventually is used to discharge the assertion a. Now, let us suppose in the next version of the program the implementation of m is changed so to return a non-negative value. The value is propagated to the callers (i.e., by inlining m), φ is no more inferred, and a cannot be proven anymore, so the analyzer issues a warning for a. For the user, it is in general very hard to trace back the cause of the problem to the change in m, in particular if she does not own m. However, with explicit postconditions, m would have the postcondition that it returns a positive value, so the static verifier can immediately spot the problem where it occurs, and provide better error messages to the user. Fourth, the extracted method may be later moved to another module, so that, e.g., its body will no longer be available for inlining.
Informal introduction of the problem
Imprecision induced by refactoring We illustrate the problem with some C# examples. We use the CodeContracts API [4] to specifiy contracts1 . Example 1. Let us consider the simple code snippet below. We assume the C# compiler is invoked with the -checked+ switch, to generate overflow/underflow checks. public int Decrement(int x) { Requires(x >= 5); Ensures(Result() >= 0); while (x != 0) x--; return x; } Assuming the precondition holds, CCCheck proves that: (i) no arithmetic overflow/underflow happens; and (ii) that the method exit is reached with x = 0, validating the (weaker user-provided) postcondition. Let us now select the loop and apply the extract method refactoring provided by Visual Studio. The new program public int Decrement(int x) { Requires(x >= 5); Ensures(Result() >= 0); x = NewMethod(x); }
return x;
private int NewMethod(int x) { while (x != 0) x--; return x; } can no longer be proved correct by CCCheck:
Second solution: Isolated analysis Analyzing only the extracteded method in isolation does not take into account the context of the refactored code. It would result in the trivial method precondition true, which is in general too
The analyzer suggests a necessary precondition for NewMethod (message #1), i.e., a precondition that should hold otherPaper
2
1
In CodeContracts, contracts are specified as opportune method calls of static members of the .NET type Contract. In the examples, for the sake of readibility, we omit the explicit reference to the type Contract.
2013/10/25
automatic contract refactoring, which automatically infers good contracts for the extracted method. Forth solution: Abstract states projection An immediate idea to solve the problem consists in projecting the relevant variables from the original abstract proof so as to get the required modular proof. Such a solution is unsatisfactory for three main reasons. First, it does not work when refactoring unreachable code: the abstract state is empty, so the generated precondition is false. Second, too much information may be lost (e.g., for relational analyzes) or too much information may be preserved (e.g., not related to the method correctness). For instance, in Ex. 1, the projection of the abstract state produces the too strong precondition 5 ≤ x for the extracted method. Ideally we’d love to infer the precondition 0 ≤ x. Third, programs evolve over time so a refactoring might work when performed but no longer work with later program modifications.
Figure 1. A screenshot of the extract method with contracts. The suggested contract for the extracted method is valid, safe, complete and the most general one. imprecise. In particular, some information present in the original code (programmer assertions, runtime errors, etc) is lost when the refactored code is statically analyzed separately. This can be avoided by using the method safety contract suggested by CCCheck. When the safety precondition is violated, the execution of the extracted method will either not terminate or definitely yield a run-time error [18]. So the safety precondition is necessary for avoiding runtime errors. As shown by our example, the safety precondition is in general not sufficient to guarantee the absence of runtime errors: when the safety precondition is satisfied, the execution of the extracted method may or may not fail/terminate 2 . Once the necessary safety precondition is inferred [18], it can be used to get a safety post-condition by isolated reachability analysis of the method body [11, 13]. In general, an independent separate safety static analysis of the extracted method which does not take into account the pre-invariant and post-invariant of the selected code is too weak. It might not be strong enough to guarantee that the refactored code invariant is still provable separately. Our main motivation for this work was that the isolated analysis raised numerous (and self-evident) complaints from end-users of CCCheck.
Example 2. Suppose that we want to extract a method MakeRoom from (*)...(**) in the code below. Insert(string[] list, ref int count, string newElement) { Requires(list != null && // in bounds 0 x < * 0 x = = x < x x x > 0 xecution of ¯ ¯ ¯ ¯ in Fig. rule (∨) and conjunction rule (∧) = 0 x = -x false ¯ x f= tial 2 o n0o¯itxucγe=1x( B0 ni noxitin c= nuB-jex s⇥ A T riodf* eebh/is nxγo1it(=) idxno> cts, o0p eλ htand eta0 nimret seod S tnemetats eht ion/beforethe postcondition/before,ylralimiSimilarly, S⊥ !ecution B. . B !.Kv~ ,v~J P ⇥ Kv~JS ⇥ Kv~since J P 2they •derive • •from the other rules, by induction on the Similarly, d n a l a i t i n i e h t s e t a l e r d n a s d l o h K v ~ , v ~ J P 2 Q n o i t a l e r r e t f a nd relatesand the initial ¯¯ and γ1x(>) x0 tx1 x>>0 0 ¯ ¯¯0x>0 x>¯after 0¯xx> 0= xn0¯o¯i¯xx x0hAJxK, < .and xx¯ x*the *x execution x= =x x ¯ > x0 2 x > tuxc=e*= xxγe x e*(⊥) ht* rentfo, a> danz00afi> e˙ar¯ ofoeibx.v~a slealcbiasisraavlceh e and ¯ 1 atization i t t ethfTo sestructure suelaluvrlacnifigoof l eprograms. raoH etercnoC vi alse 1 >¯ 0 ¯ x ¯n=ae¯loxo¯B*saxdootxs¯re> 0em and ¯ x * as ¯ 0 ¯x ¯ ¯> ¯ ¯ ¯ d n u b n a c s e l p i r t e r a o H e t e r c n o C . S f o easexecution understood Boolean x x = x < x x e 0x . ro0f la. citeroeht-tes n2 i Predicate x * x = xthat e u is r t the d unsound n u o s n u s i * x > shown o s s a m d i l a v s n i a m e r cigol eraoH fo The disjunction is¯ is interpreted ¯ to the0definition ¯ xin=Bxof⇥*γA ¯ :snoitcnuf transformers We use a generalization of the asrule According 1 ,xAJxK BBoolean )^ (x el> ur n0oit.cnujnocindthe na )_( elu r n o i t c n u j s i d ehTstrongest .2 .giF ni postconditions predicate trans.i(^) A ⇥ B ni noitcnujsidxeh< T disjunction The in B ⇥ A is !¯ Kv~values ,v~Jfor P ⇥ Kv~∈Jto S~⇥ Kv~J Pvariable 2 • • •usual J~vK ⇥ rPJ~ ¯ohs toDijkstra’s the sign of of¯vy, ~vtiKsconcrete s! eThe cB en. Ex. ehas t¯¯1sspecifying wshows o< hs01¯t2the .xx E .> necessity eB hT matization n=oitxaxz2i* tamVJxK opreserve i¯x¯axof ci> gol0efinite rt a1 ox H n> i n0wformer n[19] yllauto su sets era 2(instead .giF ni of logical formulas). The set2 x 0 x x ¯ ¯ x = x 0 >xx [13]. t 0 ⇥ 0 A x is = x * x x>0tx>0 tization uron nB othe itc.naxiomatization ujnocconjunction tcartsba ehtfor rofthe noiabstract tnconiutajnziotcaconjunction on tcTudto nseilbe yrbsound evired yepredicate ht ecnis transformer post ∈ SJ~vK → moixa elahctisnsoarule ln c oeih(^) u c,isgeolluerrraeohHtotheoretic eteehrtcnmoo Crfforward classical ! ¯ eurt ¯ dnuosnu eht si t¯ ¯lacxit¯erx=oe=hxt-xte*s*nixxd¯¯i¯lxavx>sn> =yshown tunsound is true 0ia¯m0 . er¯ sr¯osfatrue mr¯of¯ c.igo(PJ~ l erav shown is the sfomaPJ~ rgovr,p~vK) fo of eru[9] tcuprovides rts sheoretical lrxalim iSform .snoas for itThe cthat nfinite ujnpostcondition ocabstract tcaahthat rx tsb< aconjunctions. ethe nt2ounsound fihx Similarly, (_) is not 2x sound 1 x > such a generalization. The 0)nt^iwabstract > 0 x = x * x > 0 t 0.goi¯HKF.→ domain hBJ~ v , ~ v K, vi is an ( e l u r n o i t c n u j n o c d n a ) _ ( e l u r n o i t c n u j s i d e h T . 2 ni and conjunction rule (^) matization eneg(^) eroM .gabstraction nwhen ivreserp1-is nof ionot jthe tojoin-preserving. ncomplete si 1 nehw More generally: rule transformer post verifies the two properties: lattice soare r a l i m i s s i e l p i r t e r a o H t c a r t s b a n A s e l p i r t e r a o H t c a r t s b A tissimilar selogic cen eaxiomatization ht swohs 1 .xE ehThe T Ex.no1itashows zitam¯oithe xa cinecessity gol eraoH for ni nw2ohto s t¯ opreserve n yllausufinite era 2 .giF ni the unsound true ¯˙nconjunction x i˙ltu=idrfor *2pehxetto 0dc¯xy.eehefinite m 1cK, =⇒, shows necessity preserve atization (2) hPJ~ ˙ ehft alse, ¬i jnas oc by tshown cainduction rtsba eht roThe f nthe othat itcEx. nuvis j,n~v oconjunction n˙for othe nthe oitctrue, ud˙ndinyab∨, ,soe∧, eohcteorrule rafto et be vtipresound tlpecirntiseraoH etercnoP ition and nr˙x hm t otx h> c a oSt post JSKP , abstract (^) ules, on itarule terpre(^) tni tcTheorem artsba dnu2oS (Sound ( 2 meabstract roehT interpretation). The abstract . s m a r g o r p f o e r u t c u r t s on d, e.g., by y b , . g . e , d e s u s a s n i a m o d t c a t s b a n i n e s o h c e r a n o i t i d n o c t s o p conjunction for the abstract conjunction rule (^) to be sound n.son noitthe cnujnoc of tcabinary rtsba etipredicates, nfi rofor f finitee.g., abstract conjunctions. Similarly, (_) is not sound ∀Q ∈ PJ~v, ~vK : P S Q =⇒ (post JSKP =⇒ Q) . relating the h.gtinw itasThe itam iw xwhen a e1 lpirshows t isernot aopostconditions Hjoin-preserving. ofthe Fig.necessity 3, without (^) andinitial (_) ispreserve ivr,3 es.egrpiF-nfand io oHoare jntoonfinal iztriple neoEx. haxiomatization for volH ost-cTaM ezylana citats a More generally: 1 values matization 2of 1 of variables. The meaning γ (Q) an r a l i m i s s i e l p i r t e r a o H t c a r t s b a n A s(_) elto pthe irtis e:rreanot rforward tsSfinite bAa ro rpredicate ct Hoare triple is similar 2 The transformer post JSK is join-preserving. for abstract sound sound .)1( finite fin o ethe snesense s eht nofi d(1). nconjunctions. uoMoreover s if 1Similarly, is increasing, 1 fi revoeroM ¯ ¯ ¯•¯ ndafinite-meet-preserving nthe olivgti,dabstract erpgiven ehBtconjunction t! ahby t Ktv p~and ea,cv~xfinite-meeteBel⇥ pisirule rKfinite tv~eJrS ao(^) H Kev t~eto rTherefore, cnbe oc2sound a ot • it •has conjunction for hat the and ion onsprecondition thenabstract ∈ois BJ~ ~vnKocis ! J ⇥ J A f a unique adjoint preJSK such that vi rteB tiwhen sm i relation dehnis aTheorem and ,not tsQ ixe2djoin-preserving. s b More generally: 2ro1 csaerrtp b-taeedm u-oeglbs S (nfi2do eexist, T yb ,2.g.(Sound e ,desu sabstract a sniamointerpretation). d tcartsba ni nesoThe hc erabstract a noitidnoctsop domains as used, e.g., by concretization similar preserving pf reJSK c a r t s b a e h n e of h t g n i v is r e meet-preserving s e r p t e e m s i f then o the abstract conjunction (^) F f o n o i t a z i t a m o i x a e l p i r t e r a o H for finite abstract conjunctions. Similarly, (_) is not sound Hoare triple axiomatization of Fig. 3, without (^) and (_) is f abstract tcartsba fo:reesvalcosr-aTlM ucSitararpo areezryalasnealpciirttatesraaoH etevrK, cno=⇒i c˙ ehT←−−−−− hPJ~v, ~vK, =⇒i 2 2 hPJ~ ˙ (3) −−−−−→ ion vo,2~in v K,othe vi →of hPJ~ ~vPK,= =⇒i, ruolM tsinγ i22dn∈fuIohBJ~ s.dIfnis sound (1). the bPJ~ also neihwhen sound. u s is sincreasing, l2asense siabstract exists, isThe veand ,h.~v)t1K,(,gfnoiseasneisercsTheorem ,Kthe v~ ,vMoreover v~,interpretation). Jlub K˙ v~if,v~J1and Bis ,increasing, Kv~¯1J P =¯Kv~abstract J¯A gnisoohc yb selpirt eraopostJSK H not join-preserving. More generally: ¯ 2 (Sound 1 B ! K v ~ , v ~ J B ⇥ K v ~ J S ⇥ K v ~ J A 2 • • • v K ⇥ BJ~ v , ~ v K ! B eSJ~ is similar 0 m-ertoinby na d,tn siaxegγ ondiv(Q sblglbs ge2 rpQ-do finite efitisnifi2 ssatifying idfinite-join-preserving n0 )ioexist, jand -eγti2nand fi is 2∧ finite ˙ isγe2finite-meet-preserving = (Q) ).1tcis cte.g., r(Q aor oH artjoin sba preserving na tahand t yas iseW .is ytiatnGalois edi eht connection, eb ot 2 dnai.e., 1 Hoare vK : ∀Q ∈ PJ~v, ~vK : 2 resu 1 ∀P ∈ PJ~ (_) is t lnaeshit )g_nand verleusreofrn pabstract tietcen m fof oartsaxiomatization esac(_) raof luthen ciFig. talso rathe p a3, eabstract rawithout selpirtconjunction erao(^) H eteand rcn(^) o c e h T 2 tc particular dition (icase then o-Hoare the ujssiabstract idtriple disjunction b2 aistecmeet-preserving hatrtnsbeahtforule is sound. f i y l n o d n a f i dnuQ) os si⇐⇒ elpirt (P =⇒ preJSKQ). f Intuitively, (post JSKP =⇒ The hypothesis is(1). 2,sound. abstract interpretation). isvaK, erBJ~ cnivs,i~v2K =fIPJ~ .sound dvn,uTheorem s osin la sthe isi also increasing, K(Sound v~ ,v~Jof PIf= K2needed v~is,v~Moreover J B ,to Kv~Javoid P =the Kthe v~Jlub Aproblems nis isooincreasing, hcand ybThe se1lpis irtabstract erthe aoH PJ~ ~vofinite-meet K, sense if 1gexists, ¯ ¯ ¯ ¯ f ed, e.g., by preJSK is a generalization to sets of Dijkstra’s weakest liberal ) sthat )n1The S P i (1) dnaabstract gnivexposed reseHoare rp-Hoare nioin j-ethe tinfinite-join-preserving fiforthcoming Ex. finite-meet 2or.yt1iS 1t eb ot = is is eh rtaonwill H artsb5. aand aa( taversion hof t yfinite a)sQe(of W thypothnabstract ejoin d)iPe(hpreserving dnaQ ay 2and 1 ! axiomatization Fig. 3, (^) preconditions (_) is predicate transformer. srB ev aanem ussa llglbs iw In ethe wdo gfollowing nexist, iwtriple ollofand ewe I2 tcisassume thewithout finite-meet-preserving and is finite lur noitcnujsidesis tcarimplies tsba eht nthat ehthen t γ2theisabstract i yislnsound. omeetdna fi dnuos si elpirt disjunction rule (_) isγfalso increasing. The function .)_state( htiw tonHoare tub sound )^ logic ( htiw with ig(^) ol sense erbut aoHnot am -eta(_). tMoreover sm aIn rgabstract ofact, rp ,t2cenforcing artsb1conjunction a is ehtincreasing, nI seluR(^) cigthe oL eraoH tcartsbA incthe ofwith (1). if of then the ¯ ¯ ¯ P ¯ Abstract abstract 2 isif meet-preserving Hoare triples An abstract Hoare triple is similar preserving and only if it preserves infinite meets hence ) 1 ( ) Q ( S ) P ( = Q S (1) 2 1 2 (Q) tss! es)ar lyliSB rabe v a s i s n i o to j ) e preserve t i n fi n i ( e (infinite) v r e s e r p o joins t is a very restrictive hypothesis K(P nding b a g n i d n o p s e r r o c e h T . ] 8 [ n o i t c a r t s b a y b deldnah era stnem 1ollofglbs 1 2 is w ew gnisiwthe eht nsound. I exist, do and finite-meet-preserving and finite In the weconnection will assumethe a version of the abstract is also If is increasing, lub exists, and is to ais1concrete Hoare triple except that the precondition and upper-adjoint offollowing a 2Galois [13]. A meetPJ~ v , ~ v K, otabstract, n o i t a m i x o r p essentially p a e h t g n i d forbidding d i b r o f y l l a i the t n e s approximation s e of joins which is the ghefcounterr e t n u o c g n i w o l l o f e h t , y l g n i s i r p r u S . 3 . g i F ni era selur tcarts on tub )program ^( preserving htiw statecigof ol efunction raois H -logic etrivially tats m argofinite-meet rp ,tbut carthen tsnot ba epreserving. hthe t nI (_). seluInR fact, cigoL eraoHpostcondition tcartsbA(^) Hoare with (^) with enforcing are chosen in abstract domains as used, e.g., by meet-preserving abstract conjunction is of abstract 2 finite-join-preserving and is finite or is join preserving t sHoare syrtpltstatic aoonntanot analysis. tthe aitnspreserve r-eobdaf tsguinsbiad(infinite) bnopsQ ay be bB gaeirrFta1sbofaoHysebeteldhypothesis urecrlndtnocaachrA tesrbaasseetnlheptm pnm axe iSThe sninounj n)eotiitncfin nuibasis (jnedefinitely sieh ein rr-on crestrictive 8]. ab1ycl1ie A icorresponding but ovcr.esis efor tto ficonjunction Acjoins Q Sue⇥heT Pis.y]8aa[m every lnpo3iirt.tthe ianalyzer rtat heistrasowHohor esteaerlcSMT-solver oC a static [17]: also sound. If is increasing, lub exists, and v v 2 1 oversion rthe pPJ~ pafollowing eh,t~ gnK,idExample dicounterbthen rof yllathe i4. tnesabstract sAssume e al= n o i s r e v l a c i s s a l c e h t e s u a c e b s i i h T . ) 1 ( f o e s n e s e h t n i d n r e t n u o c g n i w o l l o f e h t , y g n i r p r u S . 3 . g i F n i e r a s e l u r t c a r t s disjunction rule (_) is also sound. essentially forbidding the approximation of joins which is the ly, that ~v ¯, tnxem isetreduced tement ats m0a¯r⇥ gto orB pa asingle fo ssentcerroc lai trap eh t s etoneudos ¯ x- =but ¯x x¯definitely ¯x x¯the ¯ ¯ ¯ ¯ 2 S 1 u 1 0 2 xin A not conjunction Q 0 x 0 0 x u x 0 = -x x 0 u vK × SJ~vK × BJ~v, ~vK → B avariable na5.fcbe tuns orx. oitf a sLet izsaibasis -~v nF ustatic b .y5the am 3lattice .giF focsais elufinite rt tnco artsubor a eht tais ht join wohspreserving elpmiaxseka•m c•igo•l erao∈H fAJ~ analysis. finite-join-preserving and ules of Fig. e acceptract sthat tcHoare a.rstisn3yolmay C oitan Formalization lbaBJ~ mvrfor of Contracts ,o K ebe act ta-htpt etccwith af eehhthe t setpordering onesndotiI1tp.m v~v2 usesslbaatiircaivlpm margorp no Kv~JS 2 S o (1)classical nhociishrw e¯ v lacissalchechih t¯ewsusan ceobitsriessishaT/s.)e1ta( cfoide¯esrnpesleahctig niodl nfuoossnoitaterpretni elba cause the version ement ¯ ns which which is s i defined by following Hasse diagram: The nconcrete disjunction rule (_) sound. 2t x of tsafe fnooitspx eu lavsa0 etversion hcontracts fpisomalso sdl0o hm Kthe v~J Pabstract cHoare erp ehtriples t fi are a particular case of abstract In we of uh1abstract xht will u m ethe ffaos upon dnoaitdathe ilWe ailvacceptfdefine othen othe ithe tthe othe n0following txen- fi d0 W and method in t¯p¯eeof ccethe avalid e¯ n= oephu,-x sassume e2rtayoP foeovirtiedsneo mptions ofor C rsx ondefinitely F 5.enotions Formalization but not conjunction StrunFQ ¯.selspzlterms ¯a¯em ¯ixax.r¯5 ,P (^), )nof ^ (itContracts ruoc˙fm ,xu.gesin .eeahwe ,tA eiccdidefine nnl⇥ ias ,B niSosteitwo tkceaam rtesctbiagatosleHoare h bHcedtriples repbchoosing esbeltboaniryaavAJ~ m vK = PJ~vK, BJ~v, ~vK = PJ~v, ~vK, ct that by tion of f o o e n g n i t u x e e r o f a f x x = = 0 0 = = -x x false m r e h i r t r a of o H Algebraic c b e g l A Hoare f o s m r triples. e t Furthermore, ⊥ γs2n(>) d hcihw obut itress, anot /setrue tawith ciderp (_). lacigolIn fo fact, snoitateenforcing rpretni elbaV dicates/assertions which logic with Hoare (^) m state˙ Q) (1) d i l a v f o s n o i t o n e h t e n fi e d e W We define the notions of valid and safe method contracts in which is 1 tatement nHoare is i/orders w ytBneeded vditnertvnifor teputabetnbγe)ir1tm ) ieP ¯oIn and be the io beforeeos-x bH n1eix, o¯iranx tcix o⇥ pssy20erbelx r(eoy1tCasm eγo2dtoS) t˙n=em taidentity. ts eh(t1 We say that an abstract Hoare of dcrn1outhe itcraehpte.g., etP aQrfitorders sdefinitely r,efollowing dlu a(i rP af0 p2The jlnatriple oinohnTpartial y.Slsettci(^), n tcubut bnoon Q Silm l.peconjunction i-rpartial e, cx ph ereteroha0 or,¯ H cP n not ^ oγ ,the .eg¯we ,eet c-rwill nλ oassume re0dntA sh.onare b acAe6 snteof a0shloetversion the abstract ction x =nonraifistriples. xu (≤) ycontracts. rr1(infinite) a,o)lx itrS toefnodpreserve joins is anteciin very restrictive hypothesis selpirsince, taberaoH cSimilarly, iarfor be1 gl¯A sx mrthe eterms t ¯0 ding 2i 2i if of Algebraic Hoare Furthermore, we define two V d ¯ ¯ triple is sound if and only ial and d n a l a i t i e h t s e t a l e r d n a s d l o h K v ~ , v ~ J P 2 Q n o i t a l e r fact that ˙ t n e m e t a t s m a r g o r p f o s s e n t c e r r o c l a i t r a p e h t s e t o n e d ¯ ¯ 0 0 i w d o h t e m t c a the r t x e formalization e h t f o n o i t a z i l of a m the r o f extract e h t method with contracts. a program statement ¯ ¯ ¯ ¯ ion =n¯0with false iu s-x i x¯1γon e0¯ h)wxybut l=es-x reλ vnx, ixtpartial n.0tuxu b6= )x(_). )˙= )for (1 tgram in.gnriestafearc x( 10joins (6the = , xo -einversely = of 0rtwhen xnuo10¯ iP iP hT .x ststateca¯ noc¯ srisedHoare rx¯x o l= aitra0partial plogic 2n ¯xx0x-orders contracts. The orders are needed (^) not with In fact, enforcing essentially forbidding approximation of which is the counter d n a 0 > x x > x 0 * x x = = x x * > x x > 0 and taht tcaf eht setnoonietu dcteI x.ev~ esh e0 lt.braeirtfaav dm0naargeor2o rpifenbov~Kv~sJeS ecution lba22iriaSv eht ¯fo se¯ula¯v lan which is t denotes the fact that ¯fi = γ (P ) S γ (Q) (4) es tcaof rtxthe ethe eht fo noitazislai m roihfw ehthe t formalization beforeof the, extract method with contracts. xP.> xirestrictive γu2l(≥) λeddlx, x P S Q . g n i s a e r c h c 1 2 which is sider e h t r i s n o C ) n o t a t e r p r e t n i t c a r t s b a d n u o s n U ( 1 e l p m to preserve (infinite) joins is a very hypothesis onding abe h t f o s e a v e h t f o s o h K v ~ J 2 P n o i t i d n o c e r p e h t f i ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ s be of the values ofbasis the static oolean aeloo¯ B sa 0d.ootsred0nu eb nac selpirt eraoH etercnoC .S afoxE ycution un. of 0 > xSimilarly, he 2it(=) idto tc⇥ artntKsev~bm aP cution teitrawtseW arSimilarly, cmodified We tp~postcondition/beforen|.Semebe mThe gtcox eV fi⊥ dnstatic ouBby eT ,rp ytor lnraaoly imiSimilarly, Sfor B . BS|! ~ , v ~ J P ⇥ K v ~ J S J 2 • • • \acceptments are handled by abstraction [11]. The corresponding abbasis analysis. = A = B ~p\~g Kv e u r t e u r t may undn¯¯ amodified laitiγn2i (>) ehby tof saetprogram a¯Contracts ler λ d¯ nx, a statement sxd0l.ohx K> v~ ,x v~S P 2 Q either noitaletor retfa 5. dm and , ¯J0ewritten o¯eand rtrue pthe be=rda~pexfip~ i¯ d¯n¯o m> rFormalization ox dat eit¯ ux nitial ¯ ¯ used or belong lrelates l>aa¯irxtgn tx* oap*x(yinitial or i ~ g . s e The l b r variables a v e h T . g ~ in r o ~ p p ~ are (potentially) or 2¯ 2s 1 read oolean ¯ ¯ ¯ x x 0 x < 0 0 < > x 0 x = x * x x > 0 t x > 0 = A = B e u r t u r t stract rules are in Fig. 3. Surprisingly, the following counter.and x = x ¯x0 < > x0 x¯x>2 0=noixx xa> tuc=e*variables xxγe x e*htx¯ rx entfo d~apnz00af e˙ar¯ o(potentially) foeib0x.v¸~a sxlealcbiasisraaread vlceh th∙fTowritten version and after the x sesuel0a scal ization t> i0talse m e0or l¸uvrxlacnifigol0=|exra0o∙Hx etercnoC nin suey lexecution blaeitwhereas rianvfieedhhBJx, Ter.> g~g~r0 oxK, ,i> vi ~ip~in or ~gare . sThe in are 2 (⊥) x x = x * x x and eewhich firaid¯po~ m a those n e s o ~ g h t a definitely e r e h w unmodified by any execution execution We define the notions of valid and safe method contracts in | example shows that the abstract rules of Fig. 3 may be un¯ ¯ 0 = x ¯ ¯ ¯ ¯ 0 ¸ x eraoH et0e∙ x ¯ 0 x understood Boolean ¸ xrzax0ithat =~l¯anof x . ∙rao0 yxlet*iacceptn:xfisxead*d g h5. reT hsS. w the =xeeas ei ueris ros0tofthe oFormalization nSuxThis h¯enm t0atrue seis iltoxtaB aot¯hB x *ras: > unmodified shown nw ohnsu¯Contracts s0ex abm f slea.lcpiitretrby oeany ht-teexecution s n2rci ndo0ilC>avx.Ssnfoiamer c0ig x 0 < x 0 = x According the definition γ , BJx, xK is interpreted in : s n o i t c n u f sound in the sense of (4). This is because the classical version Boolean 2istriples. Algebraic Furthermore, we edefine zilaA mwhich r0⇥ of B si sii0hnToi.tSterms etof tsThe fof o0 disjunction xg~ ,~Sp=( xHoare *B0(~x .c.x n~guj= B statement S.inThis formalized 0el> ule (x u(~ rpn0 og0 oxc0d >) x0^ 0=n x a )_(0 < 0 s.i(^) cntnuej(~ sm id,x eae h< T ons ⇥ A is . . ~p(is ,) ing~, ~v,x0K>~pn! ( the S p ~ g ) u r true t ) p , ~ g ), , ~ ~ g . (2) | | concrete as specifying a relation between the values x of Hoare logic makes implicit assumptions upon the accept. B ! K v ~ , v ~ J P ⇥ K v ~ J S ⇥ K v ~ J P 2 • • • vKp,1(⇥ PJ~ v B . 0 0 0 ¯ x Sn= ¯o(2) laf ~ .e\0)hp~We the of method .fa1~goxH= ecuernpartial tg~Ex. g~t¯,~p1 (wdefine orders contracts. partial orders are tSisseThe sx shows o< hs01¯t2the .(~ xon necessity ep\~ h.gT for preserve pE, ~g> )notions true (~ pxoand ,i¯ ~gx¯ax ),csafe ~g¯i needed .contracts |o ization iThe txfavalid z2i* tato m i(~ gpeso,la~gfl0)eefinite n> n0w hs toesnfor yllain usu era 2 .giF ni 2 rof¯g~\y x 0before > slrat p~| ¯and ~p\~ eslag = for x false0(^), > xand t0< xof¯ variable g., x < 0 t x > 0 x = x * x x > 0 t x > 0 x x (e.g., after executing a piece able interpretations of logical predicates/assertions which The disjunction in B ⇥ A is zation onhaB eittm w ifrthe ontoAlgebraic ciaabstract eiointo h aixanew method p of otothe ujenn|oScaconjunction tnocWhen rotitscbg~aterms rhnoW tncfSoerefactoring n|~rip\~ utajngnzof conjunction to sound |erShntgefor on elahctiinto oenew ih(^) tcTm(~ uFurthermore, dmethod nse){ ilbe ywith s~gp\~ eolpgcontracts. hrtcnmooCrftwo evired yeht ecnis tcaW m oHoare sntriples. soarule ln camethod u rbS c,i|m(~ lu){ er}, rraeS ohwe Htoetedefine e}, assical the the ! \a p~ nc.inaxiomatization gof iatcode rn fformalization erefactoring When Sextract | | to be refactored). ¯ ¯ ¯ ¯ ¯ ¯ may not be preserved by the abstraction since, e.g., for (∧), g ~ \ p ~ ¯ ¯ ¯ ¯ ~ p\~ g ~ p\~ g een hsixx W .> tn> et0ieaem eHehd ihewnarsgeovrrpesfoerV euris tWe danopas uiotscthat sshown ud ehpartial ittce¯ ahthat tunsound inis true xtereov srosefatrue m rparameters oahf¯ leaW cxite.srx= oeThe ee=hm -(_) de¯ vrx shorders m c.nriare rjaBor¯ eoretical form the xtwhile *s*partial 0. estrer1ovvariables .rsfetom ep˙ruBtceurreths w tas nanx inot oilx jaxwhile essound nthe egsso> enlriepo annp~finite staacsipabstract sare bntpassed ant i2ounsound rhaon v has tev0 variables shown r arx meets. orders needed for usejvariables ths~p aeconjunctions. elthe iw fi Similarly, isnthe paslsrim ae1tdeiS em ss.asarnphave efor rathe enslis bo ravararex tb< 0 x > x = x * > 0 x 0 the variables ~pcontracts. are passed parameters 1 γ ( P ) =⇒ ˙ ) but not inversely when γ is inγ (P ¯aen-gconjunction ¯.gdlannwhen 1 ^ ransound nu¯ jn0 oover-approximate c dnxa ¯)_x¯(-el= urno¯i tc0n~p uj¯sx id ¯ehdTna.2¯¯.1g0iFnix¯¯ix- = x ¯ 0 1 xi¯ nd ¯ l(0n ¯generally: ee0vsrthe usrule global. w .slisiab)1always o geelehurw ~oisxit-cMore ¯oos0M atization ider xur(^) o yxoatw o-is ejsritaot~join-preserving. iConcrete vio~gr¯tseIxare ss.(^) elyarapbthe nl¯lgHoare iaonot n are gI~It global. always sound to ule xIt¯g =rto x 0issi xetriple diover-approximate ntae¯rxP 0o xtcand xt-contracts. =a~pnxand 0 i∈∆ xpirt eraoHi∈∆ 10 x =sw -x formalization of the extract method with triples A concrete Hoare S Q similar a l i m l p r a H a r s b A s e l t c a r t s b A s e c e n e h t o h s 1 . x E e h T The Ex. 1 shows the necessity for to preserve finite itdanmu¯oixa cigo¯l eraoH ni nw2ohs t¯ on yllausu e¯ra 2 .giF ni re logic axiomatization under-approximate eretadthe xounsound rpnpo~gia.t-arzethe .g~ etaThe m ixthat orp.pg~a-is nunder-approximate uishows ~g. S x =for but not join-preserving. true xhctmean xetto 0dcxyvariables .eehcreasing as 1cm preserve We all zation 2p | the partial correctness a,~p\~ cooby tshown caatefinduction rtem srbeadheethrtotadenotes rhcoton feValid nm oruitescEx. nassume uejtcontract nW ohconjunction eshthe tn orefactored nthe oithat twrite cnecessity udthe ndiof soeiprogram ltguid r to reomethod ehstatement rafto et be vtip resound tlpecirntiseraoH etercnoc a ot on and nlymethod abcin n eio* rnrule him t othat tx h> efinite for abstract conjunction (^) es, the r t c s a d h t a f e We h t a t e m that u s a e W and the contracts We assume refactored and contracts f o n o i t a t e r p r e t n i r a u t r a p a g n i r e d s o c n oftnthe fo noitaterpretThe ni raluabstract citsrtaspisnthe aogc nw ireeivdifsontoncionpi ssithsTisn2 oc weiv fo tniop sihT 2 gretation ate particular interpretation ofnu a r p r e i t c Theorem a r t s b a d 2 o S (Sound ( 2 m e abstract r o e h T interpretation). onsider Example abstract interpretation). Consider the .S so(^) m aaerrnot rptnseobe fhboetahoeither etn non SJ~ denotes fact that e.g., derSimilarly, aindm om dsbelong trggcooocato iingtncoidelunserorotaspto hosHcerreo5rca(Unsound for the abstract conjunction orule itthe cby nu(^) j:nslanguage owcotlcloS afrconjunction tsemantics. sa∈ badspecified fi offor fitiincov elpK. efItsras a finite .abstract se cip tnby athe mas ersa econjunctions. gprogram augy nab l g,cn.ig itm gsethe os pis ,rcgu used or modified afollows: ogramming are specified semantics. are :eestriple lrosaxiomatization n.eamif m,astatement ergpuaeushprecondition gat nosrule at n lggni(_) inm rpesound tsound en nooiethitd,nciogcotlseorapoH inw iw tav m xwhen aae1 ldfollows: peof ifirshows tiiscethe rnot aosvalues Hejoin-preserving. of Fig.of 3,.sthe without (^) and (_) is following abstractions ivr,3 es.egrpiF-nfio oHoare jPntooni∈tasThe izPJ~ nKeoEx. hiholds w the necessity for to preserve finite : r e v l o s T M S a r o r e z y l a n a c i t a twhere s a A is the pre-condition abstract variables before exMore generally: Valid contract We write S to mean that all variables 1 matization 2 elpiread 1 |ais riald(1). im ssi elpin irt ~ oH tSimilarly, c(potentially) rtsincreasing, rtis eranot oor H tsound cwritten artsbA p( or ~gs.neThe peraare Hoare issound similar ~p\~ gba nA s(_) for finite abstract fi revtriple oeroM .)~ 1 fin o statement ethe sense s eht variables nof nconjunctions. uisoMoreover if the 1 of domain ecuting S, and the execution the statement S ¯ ¯ ¯ ¯ ndafinite-meet-preserving ndefinitely ocaerprogram p ehBtconjunction t! ahunmodified t Ktv p~and e,cv~xJeBel⇥ pisirule rKfinite tv~eby aSo(^) H rA cnbe oc2 a roetpa•P to conjunction abstract sound t eB the and on onsprecondition thenu-oeglbs 5for statement belong either ! JrS ⇥ Ke2012/4/13 vt~eto Jexecution • • 5 naor whereas those ~gsnthe any tiwhen sm iused and ,not tsmodified ixe2djoin-preserving. oin is boare ligtidby 5 2012/4/13 repaP More generally: 2rod tcsaerrtp b-taeed5m S (nfi 2do eexist, ehis T Theorem then ybthe ,2.g.(Sound epostcondition/before-after ,desu sabstract a sniamointerpretation). d tcartsba ni nrelation esoThe hc erabstract a noitid3noThis ctsoppoint of view consists in considering a particular interpretation of omains as used,does e.g., terminate, by 1 imilar ~p ~g in ~ p are (potentially) read or written neoof hQ iPJ~ is -holds t.eeThe mS. sand i variables fthen oconjunctions. abstract conjunction (^) frotsnboaitaezhitam ixt ag∈of en pv istatement rrtevmeet-preserving esor r,e~ avroKpH finite abstract Similarly, (_) is not sound Hoare triple axiomatization of Fig. 3, without (^) and (_) is This is the formalized as: abstract t c a r t s b a f o e s a c r a l u c i t r a p a e r a s e l p i r t e r a o H e t e r c n o c e h T 2lfor 2 relates the initial and :revfinal los-Tvalues MS a roof rezylanaHoare citatslogic, a the one corresponding to the programming language semantics. onlMveand tsinwhereas i2dnfuIosound s.dIfnis in sense of (1). is ,increasing, the also neihwhen sound. uthose o2not s isothe sincreasing, lain s~ ig isThe 0exists, PJ~ ,h.~v)t1K,(,gfnoiseasneisercsTheorem ,definitely Kthe v~ ,Moreover v~interpretation). Jlub Pp = Kunmodified v~0if), ,v~J1and B K~ v~¯)1J P =¯= Kany v~abstract J~ A0 execution gn.iso(2) ohc yb selpirt eraoH are by join-preserving. More generally: ¯ ¯ 2 (Sound abstract 1 (~ p , ~ g ) true S (~ , ~ g (~ p , g ~ g g B ! Kisv~|~2p\~ ,v~isJgB ⇥ Kv~JSis⇥join Kv~JApreserving 2 and• •is finite • ~.g., v-Kersimilar ⇥ is toinby fitisnvifi,2~vsKid! na dB ,tn siaxegondivsrbelsglbs gerp-do exist, and finite-meet-preserving eBJ~ finite-join-preserving n i o j and e t i n fi finite or Hoare e r a o H t c a r t s b a n a t a h t y a s e W . y t i t n e d i eht eb ot 2 dna 1 1 of statement S. This is formalized as: triple eshit )g_nand verleusreofrn pabstract tietcen m ssiabstract fof oartsaxiomatization Paper 2013/10/25 atrtnsbeahtforule esac(_) raof luthen ciFig. talso rathe p a3, eabstract r0awithout selp0 irtconjunction erao(^) H ete7and rcn(^) ofci(_) ehlnT0ois 2 tc rticular 2 aistecmeet-preserving ition (icase then o-Hoare the u j i d disjunction b h is sound. y d na fi dnuos si elpirt S ~p\~ into a new method S ~~egp\~ 2),sound. interpretation). The , ~gsense (~ pthe glub ,m(~ gcand )ypb){ ge1lp= .},(2) erBJ~ cnivs,i~v2K =fIPJ~ .sound dvnWhen s osin larefactoring sthe i palso is(~ is,|v~~ increasing, is K(Sound v~ true ,v~Jof PIf|= K2gabstract v~S J Bg ,Kv~J P = Kif v,~J~ A 1), gexists, nis i(~ sp ooincreasing, h~ s~ irt|abstract rthe agoH ~vaK, ,uTheorem ~voK, (1). Moreover p\~ ¯ ¯ ¯ ¯ d, e.g., by )n1aas ( hparameters S P i (1) dnaabstract gnivreseHoare rthe p-niovariables j-etinfinite-join-preserving fi 2or.yt1iS 1t ethe is join pehaxiomatization variables rtaare onwill H cassume artsbaand t yfinite a)sQe(of W tis nabstract ewhile d)iPe(hpreserving b ot = dnaQ that 2and 1 B of Fig. 3, (^) (_) is ev aanem ussa llglbs iw In Hoare ethe wdo gfollowing nexist, iwtriple ollofand e~ we I2 tpassed ataversion thewithout is finite-meet-preserving and is finite cart~ sbaare eht nglobal. ehthen t refactoring When S|~p\~gsound into new }, i method ylnsound. o dna fim(~ dnupo){ s si p eS lp|irt ¯)rx_no(ithctn0iuwj¯sitdontHoare theItabstract disjunction ruleato (_) is falso ~p\~ tug b sound )^ logic ( htiw with ig(^) ol sense eis rbut aoalways Hnot m state-eta(_). tMoreover s maIn rgofact, rpover-approximate ,tcenforcing artsba is ehtincreasing, nI selu~ R cand igthe ogL eraoH tcartsbA incthe ofwith (1). if 1
1
2
2
2
1
1
2
1
2
2
.
1
1
.
.
.
false ˙ S Q ˙ P S true P skip λ ~v , ~v 0 . P (~v ) ∧ ~v 0 = ~v P assert(E) λ ~v , ~v 0 . P (~v ) ∧ JEK~v ∧ ~v 0 = ~v P x = E λ ~v , ~v 0 . P (~v ) ∧ ~v 0 = ~v [x 7→ JEK~v ] P S1 Q , λ ~v 0 . ∀~v : P (~v ) =⇒ Q(~v , ~v 0 ) S2 R P S1 ; S2 λ ~v , ~v 00 . ∃~v 0 : Q(~v , ~v 0 ) ∧ R(~v 0 , ~v 00 ) λ ~v . P (~v ) ∧ JEK~v S1 Q1 , λ ~v . P (~v ) ∧ J¬EK~v S2 Q2 P if(E) S1 else S2 Q1 ∨˙ Q2
(⊥)
∀~v : P (~v ) =⇒ I(~v , ~v ), 0. λ ~ v ∀~ v : I(~v , ~v 0 ) assert(E); S J , (>) ∀~v , ~v 0 , ~v 00 : I(~v , ~v 0 ) ∧ J(~v 0 , ~v 00 ) =⇒ I(~v , ~v 00 ), (s) ∀~v , ~v 0 : I(~v , ~v 0 ) ∧ J¬EK~v 0 =⇒ Q(~v , ~v 0 ) (w) (a) P while(E) S Q (=) P =⇒ ˙ P 0 ∧ { P 0 } S { Q0 } ∧ Q0 =⇒ ˙ Q (⇒) P S Q (;) ∀i ∈ ∆ : { Pi } S { Qi } (∨) ˙ ˙ ∈ ∆ : Qi } { ∃i ∈ ∆ : Pi } S { ∃i (i) ∀i ∈ ∆ : { Pi } S { Qi } (∧) ˙ ˙ ∈ ∆ : Qi } { ∀i ∈ ∆ : Pi } S { ∀i
Figure 2. Concrete Hoare triples axiomatization.
If AJ~vK has an infimum ⊥A such that γ1 (⊥A ) = false ˙ then for all Q ∈ B, ¯ ⊥A ¯ S ¯ Q ¯ = true ˙ then for all P ∈ A, ¯ P ¯ S ¯ > ¯ = true If BJ~v, ~vK has a supremum > such that γ (> ) = true B
2
γ1 (P ) S γ2 (Q) ¯S ¯Q ¯ ¯P
B
B
(>)
∀i ∈ ∆ : ¯ P i ¯ S ¯ Qi ¯ (∨) F ¯ F 1 P i ¯ S ¯ 2 Qi ¯
(S)
i∈∆
P v P ∧ ¯ P 0 ¯ S ¯ Q 0 ¯ ∧ Q 0 v2 Q ( ⇒) ¯P ¯S ¯Q ¯ 0
1
(⊥)
i∈∆
∀i ∈ ∆ : ¯ P i ¯ S ¯ Qi ¯ d (∧) ¯ d 1 P i ¯ S ¯ 2 Qi ¯ i∈∆
i∈∆
Figure 3. Abstract Hoare triple axiomatization. Without additional hypotheses, the rules (∨) and (∧) are unsound.
A= x∙0 x0
x0
false
false
and the post-condition abstract domain B preserves neither joins nor meets. We have ¯x ≥ 0 ¯ x = -x ¯x ≤ 0 ¯ and ¯x ≤ 0 ¯ x = -x ¯x ≥ 0 ¯
but definitely not the conjunction in A × B ¯ x ≥ 0 u1 x ≤ 0 ¯ x = -x ¯ x ≤ 0 u2 x ≥ 0 ¯
which is ¯ x = -x ¯ false ¯ ¯x = 0
Similarly, ¯x > 0 ¯ x = x*x ¯x > 0 ¯ and ¯x < 0 ¯ x = x*x ¯x > 0 ¯.
The disjunction in B × A is ¯ x < 0 t2 x > 0 ¯x = x * x ¯ x > 0 t1 x > 0 ¯ that is the unsound ¯ true ¯ x = x * x ¯ x > 0 ¯ . Paper
8
The Ex. 5 shows the necessity for γ2 to preserve finite conjunction for the abstract conjunction rule (∧) to be sound for finite abstract conjunctions. Similarly, (∨) is not sound when γ1 is not join-preserving. More generally: Theorem 6 (Sound abstract interpretation). The abstract Hoare triple axiomatization of Fig. 3, without (∧) and (∨) is sound in the sense of (4). Moreover if γ1 is increasing, the glbs do exist, γ2 is finitemeet-preserving and ∆ is finite then the abstract conjunction (∧) is also sound. If γ2 is increasing, the lub exists, and γ1 is finite-join-preserving and ∆ is finite or γ1 is join preserving then the abstract disjunction rule (∨) is also sound. The notion of Algebraic Hoare Logic developped in this Sec. 5 and the issues with the unsoundness of the (∧) and (∨) rules of the abstract Hoare logic of Fig. 3 as well as the discussion for when they are sound in Th. 6 are applicable beyond the specific problem of method re-factoring. Example 7. Concurrent separation logic [38] is an example of algebraic Hoare logic where abstract domains are predicates over a separation algebra [27]. Because of the conjunction rule, the logic is unsound unless resource invariants are precise, i.e., unambiguously carve out an area of the heap. For example, the separation logic assertion x 7→ 0, denoting a cell 2013/10/25
at the address x storing 0, is precise; however, the assertion x 7→ 0 ∨ emp, denoting either the cell or the empty heap, is not. In particular, imprecise resource invariants allow the two premisses of the conjunction rule to make conflicting choices about how to partition the heap. For imprecise predicates, the concretization may not preserve intersection [27, Def. (14)]. As stated in Th. 6, one solution is to restrict the abstract domain (i.e., the predicates over a separation algebra) to be finite-meet-preserving, which is the case for precise resource invariants, as in [6]. The second solution is to exclude the conjunction rule, as in [27].
private void m(~p) { Requires( PR (~p) ); Ensures( QR (OldValue(~p), ~p) );
(6)
Ensures( ∀x 6∈ ~p : OldValue(x) == x );
}
S|~p\~g
where OldValue(~p) denotes the values of the actual parameters when calling method m. The precondition PR (~ p) is checked when the method is called on the values p~ of the actual parameters ~p. The postcondition QR (~ p, p~ 0 ) relates the initial values p~ (denoted OldValue(~p) in (6)) of the parameters ~p on method entry to their final values p~ 0 (denoted ~p in (6)) on method exit. The postcondition is checked at runtime on exit. In the case of a contract failure, the execution halts. The fact that none of the variables other than ~p can be modified by a method call is either specified explicitly, if allowed by contract specifications, or recorded together with the method contract, or else assumed implicitly. This assumption will be needed to guarantee the soundness of the separate method call proof rules of Sec. 7 and Sec. 11. We let the set of all the contracts for the method m to be CJmK , PJ~pK × PJ~p, ~pK .
Abstract Hoare Logic Rules for Static Analysis In the following we will use a sound version of the abstract Hoare logic with the conjunction rule (∧) but not with disjunction rule (∨). Abstract conjunction rule The conjunction rule (∧) is of interest for static analyzers using reduced products [13]. Reduced products allow the automatic combination of separately designed analyzes so as to express conjunctions of different abstract properties. Classical abstract domains such as intervals [10], octagons [36], subpolyhedra [30], or polyhedra [16] do satisfy the hypotheses of Th. 6 ensuring the soundness of the conjunction rule (∧) since in those cases γ2 is finite-meet-preserving (although not infinite meet-preserving since e.g., for polyhedra [16] the concretization is not the upper-adjoint of a Galois connection).
Definition 8. A contract hP, Qi ∈ CJmK is a valid m contract if and only if P S|~p,~g Q . In absence of valid contracts, we can always use the trivial ˙ ˙ true , htrue, truei . cc
Abstract disjunction rule For the disjunction rule, enforcing γ1 to preserve (infinite) joins for (∨) is a very restrictive hypothesis essentially forbidding the approximation of joins which is the basis for static analysis. However, the disjunction rule (∨) is not needed in static analyzers since disjunctions are usually handled specifically in each abstract domain.
6.
Safety pre-condition A property Pm ∈ PJ~pK is a safety precondition for a method “void m { S|~p\~g }” if and only if ¬˙ Pm S|~p\~g false ˙ .
Intuitively, if Pm does not hold then the execution of the method body S|~p\~g is doomed to fail either because of nontermination or because of a runtime error causes the program to stop. By (2), we have post JS|~p\~g K ¬˙ Pm =⇒ false, ˙ which, by
Formalization of Contracts
We define the two notions of valid and safe method contracts in terms of Algebraic Hoare triples. We also introduce two partial orders needed for the formalization of the extract method with contracts.
f |~p\~g Kfalse (3), is equivalent to ¬˙ preJS ˙ =⇒ ˙ Pm . In practice
f |~p\~g Kfalse the strongest precondition Pm∗ , ¬˙ preJS ˙ is not
computable and so will have to be over-approximated by a weaker precondition Pm such that Pm∗ =⇒ ˙ Pm . Any one of the backward static analyses in [18] can be used to effectively compute an abstract version of Pm . It follows that ¬˙ Pm underapproximates ¬˙ Pm∗ in that ¬˙ Pm =⇒ ˙ ¬˙ Pm∗ and so, by (⇒), ¬˙ Pm satisfies ¬˙ Pm S|~p\~g false ˙ .
Valid contract We write S|~p\~g to mean that all variables used or modified by a program statement S belong either to ~p or ~g. The variables in ~p are (potentially) read or written whereas those in ~g are definitely unmodified by any execution of statement S. This is formalized as: λ (~ p, ~g ) . true S|~p\~g λ (~ p 0 , ~g 0 ), (~ p, ~g ) . ~g = ~g 0 . (5)
When refactoring S|~p\~g into a new method m(~p){ S|~p\~g }, the variables ~p are passed as parameters while the variables ~g are global. It is always sound to ⊆-over-approximate the set ~p and ⊆-under-approximate the set ~g. We assume that the extracted method and the contracts are specified as follows: Paper
Safety post-condition Once a safety pre-condition Pm ∈ PJ~pK has been inferred, a safety post-condition Qm ∈ PJ~p, ~pK, relating the initial values p~ of the parameters ~p and their final values p~ 0 must be inferred satisfying Pm S|~p\~g Qm
9
2013/10/25
f |~p\~g KQm . Again the strongest or equivalently, Pm =⇒ ˙ preJS Qm is not computable and so will have to be over-approximated in the abstract by a relational reachability analysis [11].
cc on precondition to get more on postcondition). The order =⇒ will be used in Sec. 8 to define the most general extracted method contracts. cc cc cc cc cc The set hCJmK, =⇒, ⊥, >, ∨, ∧i of all contracts for a cc method m is a complete lattice for partial order =⇒ where cc cc ˙ ˙ falsei ˙ is the infimum, > , hfalse, ˙ truei is ⊥ , htrue, cc W V ˙ hPi , Qi i , h Pi , the supremum, the (infinitary) join is
Safety contract The pair of a method safety pre-condition and post-condition yields a safety contract. Definition 9. A method safety contract for the method “void m ( ~p ) { S|~p\~g }” is a pair hPm , Qm i ∈ CJmK such that ¬˙ Pm S|~p\~g false ˙ and Pm S|~p\~g Qm .
i∈∆
cc W ˙ Qi i. The definition of V is dual.
i∈∆
7.
The intuition is that either the safety pre-condition Pm does not hold and the method call is doomed to fail, so on exit of S (which never happens) Qm does hold. Otherwise the safety pre-condition Pm does hold in which case the post-condition Qm describes the effect of the call, if it ever terminates. In the abstract, over-approximations are inferred by the static analysis. By Def. 9, this abstract safety contract will always be valid but it may not be precise enough to ensure completeness or generality. For example, in absence of precise method safety contract, we can always choose hPm , cc Qm i , true.
Callee/covariant partial order on contracts We define the callee/covariant partial order on concrete contracts × hP, Qi =⇒ hP 0 , Q0 i , P =⇒ ˙ P 0 ∧ Q =⇒ ˙ Q0 . ˙
The intuition is that stronger is better for the callee (assuming more on the precondition to guarantee more on the postcon˙ × dition). The order =⇒ will be used in Sec. 8 to define the safety of the extracted method contract. The set of concrete contracts for method m is the complete lattice ˙ ×
˙ ×
˙ ×
˙ ×
hCJmK, =⇒, ⊥, >, ∨ , ∧ i ˙ ×
˙ ×
where ⊥ is the infimum, > is the supremum, ∨ is the lub, ˙ ×
and ∧ is the glb for the partial order =⇒ on the set CJmK. ˙ ×
~ p\~ g
P
. S λ (~ p, ~g ), (~ p 0 , ~g 0 ) . P (~ p, ~g ) ∧ Q((~ p, ~g ), (~ p 0 , ~g 0 )) ∧ ~g 0 = ~g
The two rules (8) and (9) can be combined via the conjunction rule (∧) to provide the concrete separate method call proof rule.
8.
Caller/contravariant partial order on contracts We define cc the contract caller/contravariant partial order =⇒ on CJmK as cc hP, Qi =⇒ hP 0 , Q0 i , (P 0 =⇒ ˙ P) ∧ (7) (λ p~ 0 , p~ . P 0 (~ p 0 ) ∧ Q(~ p 0 , p~) =⇒ ˙ Q0 ) .
cc The intuition behind this order is that a =⇒-stronger contract cc is more general and a =⇒-weaker contract is more specific, cc 0 0 since 0Qi =⇒ hP , Q i and P S Q hold then 0 if hP, P S Q does hold. Concretely it means that from the caller point of view all proofs done with the contract hP 0 , Q0 i can also be done with hP, Qi. This intuition is therefore that stronger is better for the caller (assuming less
Paper
As the global values ~g are unaffected by the call, the information available on them before the call is still valid after the call: (9) P S| Q
˙ ×
10
Separate method verification
In order to formalize the problem of extract method with contracts, we need to reason about method calls. We now formalize what we mean by separate verification of the correctness of the callee and the method caller. We assume the simplifying hypotheses of Sec. 6 for the variables modified by a method call. In general, e.g., to handle the heap or concurrency, more complex rules are needed to express the frame conditions. The problem is orthogonal to this paper, and so we assume sequential programs with only scalar variables. Let m(~p){ S } be a method definition with contract hP, Qi and let m(~q) be a method call where the actual parameters ~q ~ qK = VJ~ ~ pK. are variables such that VJ~ We define the separate method call proof rule. First, the contract hP, Qi of m should be valid, i.e., P S|~p\~g Q . Second, the call precondition P 0 should imply the method precondition P when projecting away the unmodified global ˙ g : P0 =⇒ variables: ∃~ ˙ P. If the two conditions hold then the caller can assume the postcondition Q: ˙ g : P 0 =⇒ P S|~p\~g Q , ∃~ ˙ P (8) . P 0 m(~q) λ ((~q, ~g ), (~q 0 , ~g 0 )) . Q(~q, ~q 0 )
Safety versus validity For contracts, validity and safety are two different concepts. Any safety contract is valid but may some valid contracts not be safe. For example is valid but not safe since x = 1 x=1/x x = 1 does not hold. However x 6= x = 6 1 x=1/x false 0 x=1/x x 6= 0 is safe hence valid.
˙ ×
i∈∆
Extract Method with Contracts
We devise a two-step algorithm for the extract method with contracts. The classical syntactic extract method is first applied to the user selection. If it succeeds (e.g., a syntactically correct program is generated), we apply our algorithm EMC in Alg. 5 to infer good contracts for the new method. In order to formalize (and solve!) the problem both in the concrete and in the abstract, we need first to make explicit the assumptions on the underlying syntactic refactoring engine and on the analysis. These assumptions are formulated in the concrete but should also hold in the abstract, up to concretization, as considered in Sec. 12. 2013/10/25
Assumptions When the end-user selects a piece of code S, the refactoring engine produces a new program with the refactored code only if this is a syntactically valid program. Otherwise stated, we rule out syntactically ill-formed programs. We only consider in-out parameters and procedures for simplicity, but we handle the general case in our implementation. The new method appears in the same class of the selected code. The method is marked as private — so there is no need to ensure that the class invariant is preserved 4 . We assume the extracted method to be in the form of: private void m(~p) {
Contract.Ensures( ∀x 6∈ ~p : Contract.OldValue(x) == x));
S|~p\~g
}.
We explicitly record in the contract which variables are neither read nor written by the method (otherwise the assumption remains implicit, or guaranteed by the semantics of the language, e.g., for parameters of struct type). At the call site, the selected code S|~p\~g is refactored into a method call m(~p), where ~p is the vector of actual parameters. We assume that a pre-invariant PS ∈ PJ(~p, ~g)K and a postinvariant QS ∈ PJ(~ ), (~p, ~g)K are available for the selected p, ~g code S such that PS S QS . The pre-(post-)invariants can be derived by projecting the abstract state of the analyzer in the program point just before (after) S (formally followed by a concretization when reasoning in the concrete). Othercc wise, it is always possible to use true. These assumptions can be summarized as PS S|~p\~g QS .
The projection of hPS , QS i for S on the read/written variables ~p is hPS. , Q. S i. It satisfies the following conditions:
~ gK : PS (~ PS. (~ p 0 ) , ∃~g ∈ VJ~ p 0 , ~g ) and . 0 00 0 00 00 ~ QS (~ p , p~) , ∃~g ∈ VJ~gK : QS ((~ p , ~g ), (~ p, ~g )) . (10)
From what said above and (10), it immediately follows that the following triples are valid, stating that the extracted method does not modify the globals and that the projected pre- and post-invariants are still valid contracts: λ (~ p, ~g ) . true m(~p) λ (~ p 0 , ~g 0 ), (~ p, ~g ) . ~g = ~g 0 and . . PS S|~p\~g QS .
(s) – validity Assuming the refactored contract precondition, the post-condition must hold. Formally: PR S|~p\~g QR . (b) – safety The refactored contract hPR , QR i is stronger than the method safety contract hPm , Qm i: × hPR , QR i =⇒ hPm , Qm i . ˙
The refactored contract requires more (so that PR implies Pm which ensures the absence of runtime errors when executing the extracted method) and ensures more (so QR implies Qm and so takes at least into account on method exit what can be learned from the method precondition Pm followed by the execution of the method body). (c) – completeness The refactored code is still provable with the same precision as the original code. The triple PS m(~p) QS is provable by the separate method call proof rule (8) using the extracted method contract hPR , QR i.
(d) – generality The refactored contract hPR , QR i is the most general possible: the pre-condition of the refactored contract hPR , QR i is the weakest possible (so that the extracted method applicability is as general as possible) and its post-condition is the strongest possible (so that calls to the extracted method get as much information as possible on its effect). However we do not consider type generalization [42], which is a separate problem.
Independent requirements The validity, safety, completeness and generality requirements are all mutually independent. For example, false S true is always safe, invalid for reachable code, validity for unreachable code but (in general) incomplete and not general.
We assume that a safety contract hPm , Qm i (cf. Def. 9) for the extracted method m can be inferred by running an isolated analysis for m (formally followed by a concretization when cc reasoning in the concrete). At worst, true is always a safe choice. The problem of method extraction with contract (EMC) We want to generate a contract hPR , QR i ∈ CJmK for the (new) extracted method m. The extracted method will then be
Consequences We report some consequences of our requirements and definitions. From the requirement (a) – validity and (8) it follows that the (opportunely instantiated) refactored contract is valid at the call site:
{ λ (~q0 , ~g 0 ) . PR (~q0 ) }m(~q) (11) { λ ((~q0 , ~g 0 ), (~q, ~g )) . QR (~q0 , ~q) ∧ ~g = ~g 0 } After refactoring, PS m(~q) QS can be proved using (11) if and only if
4
The situation is slightly different for public methods, and orthogonal to our problem.
Paper
analyzed separately (to prove its contract hPR , QR i correct) and the contract hPR , QR i will be used to derive the postinvariant QS from the pre-invariant PS in a forward analysis of the method call (and/or the pre-invariant PS from the postinvariant QS in case of backward analysis). The contract hPR , QR i for extracted method m must guarantee that the proof/analysis that succeeded before the refactoring still succeeds after the refactoring. Differently stated, the problem is to find an appropriate refactored contract hPR , QR i with pre-condition PR and post-condition QR of the form (6). We put the following requirements on this refactored contract hPR , QR i:
11
2013/10/25
∀~ p0 , ~g : PS (~ p0 , ~g ) =⇒ PR (~ p0 ) 0 0 0 ∀~ p , p~, ~g : QR (~ p , p~) =⇒ QS ((~ p , ~g ), (~ p, ~g )) .
(12)
The conditions in (12) can be strengthened to take run-time errors into account. Although mathematically useless, this is useful to minimize the loss of information in abstract in terpretation. Therefore, after refactoring, PS m(~q) QS can be proved if and only if ∀~ p 0 , ~g : PS (~ p 0 , ~g ) ∧ Pm (~ p 0 ) =⇒ PR (~ p 0) (13) ∀~ p 0 , p~, ~g : PS (~ p 0 , ~g ) ∧ Pm (~ p 0 ) ∧ QR (~ p0 , p~) =⇒ (14) 0 QS ((~ p , ~g ), (~ p, ~g )) .
Please note that if the method pre-condition Pm does not hold, then the selected code S would have definitely failed on some language or programmer assertion while the refactored code will also definitely fail, but earlier, when calling method m. So it is possible that PS (~ p, ~g ) does hold and the execution goes on (until definitely failing later somewhere within S) whereas Pm does not hold on method call so that execution just fails right on call. However, this changes nothing as far as the post-condition QS is concerned. Finally, the most general contract refactoring requirement (d) – generality can be equivalently restated as “if hPR0 , Q0R i satisfies (a) – validity, (b) – safety, and (c) – completeness, then cc hPR , QR i =⇒ hPR0 , Q0R i”.
9.
(15)
Exact method refactoring
We show that the EMC problem has a unique solution, and we give two equivalent formulations of the solution. The first one is nicer from a mathematical point of view, but less suitable for abstraction. The second one involves a combination of backwards and forwards iterations, and it will be the base for our static analysis.
Iterated solution of EMC We propose a solution to EMC based on the combination of a forward and a backward analysis, inspired by [8]. The idea is to compensate for the loss of information in the abstract by an iterated forward/backward analysis. Starting with the projection of the pre- and postconditions hPS. , Q. S i at the original call site on the relevant variables, the contract is iteratively generalized by successive forward fixpoint propagations strengthening the postcondition and backwards fixpoint propagations weakening the precondition. The iteration of these fixpoint computations ultimately stabilize, in general after infinitely many decreasing iterations in the concrete, which we express as a greatest fixpoint (which is therefore a fixpoint of fixpoints). The method contract transformer FR JSK ∈ CJmK → CJmK refines the safety contract hPm , Qm i with the precondition and postcondition transformers: (16) ˙ ˙ f FR JSK(hX, Y i) , hPm ∧ preJS|~p\~g KY, Qm ∧ postJS|~p\~g KXi.
cc
hPm , post JS|~p\~g KPm i = gfp=⇒.
. hPS , QS i
Theorem 10 (Exact contract refactoring). The unique contract satisfying (a) – validity, (b) – safety, (c) – completeness, and (d) – generality is: (16)
In an ideal world (e.g., finite and small enough) where everything is exactly computable, EMC is very simple: compute the safety precondition and then propagate it forwards to get the postcondition (as in model checking). In practice post JS|~p\~g KPm is not effectively computable — the set of states is infinite or extremely large. Therefore an approximation is needed — all the fully automatic static analysis methods for infinite state systems are necessarily approximate. An abstract version of Th. 10 is essentially useless: Paper
Greatest fixpoints We write gfpv a f for the v-greatest fixpoint of f ∈ L → L v-less than or equal to a ∈ L, if any (e.g., hL, vi is a dual cpo, f is increasing and a ∈ L is a post-fixpoint of f , i.e., f (a) v a). Otherwise, gfpv a f is the limit, if any, of the iterates of λ x . x u f (x) from a (which yield the same definition with the previous hypotheses), see [14].
f |~p\~g KY and postJS|~p\~g KX both involve Observe that preJS fixpoint computations [11, 13]. The fixpoint of the descending iterations of FR from hPS. , . QS i is the solution to EMC: Theorem 11 (Iterated contract refactoring). Under the assumptions of this paper,
Concrete solution of EMC We devise a solution to EMC as follows. The precondition PR for the method is the safety precondition Pm — all the internal safety checks are made explicit to the caller. The postcondition is the strongest postcondition from Pm .
hPR , QR i , hPm , post JS|~p\~g KPm i.
static analyses compute an over-approximation of post and this over-approximation may easily cause the requirement (c) – completeness not to be satisfied. We propose a solution to EMC nicer to abstract than (16). First we need to recall some facts on greatest fixpoints.
12
FR JSK
(17)
and, by Th. 10, is the unique solution to (a) – validity, (b) – safety, (c) – completeness, and (d) – generality. The fixpoint formulation of the solution to EMC, (17), is the concrete solution to our problem. As stated earlier, in the general case, the computation is unfeasible and we need to perform some approximation. Next we provide abstract counterparts to the separate method analysis rules of Sec. 7 and the formulation in the abstract of EMC.
10.
Abstract Contracts
Abstract domain primitives In addition to the requirements of Sec. 5, we assume the precondition abstract domain A and the postcondition abstract domain B to define: (i) a predicate for the unchanged variables; (ii) an embedding from A to B; (iii) a variable projection; and, (iv) a variable 2013/10/25
4 Observe thatconcrete. if 2 is We not assume meet-preserving then the property that an abstract co than another one may notRemark be preserved in the Here isthat counter-example. Remark 4a Observe that if that Remark 4 Observe is not meet-prese 2 isifnot meet-preserving
2 than another one may not be preserved in the concrete. Here is a counter-example. Remark 4 Observe that if 2 is 1. notThe meet-preserving then the property that anthe abstract than another one may not be preserved in concret than another one may not preserved in unary theco c abstract domain hA, vi is anbe abstraction of thanmeet-preserving another one maythen notthe be property preserved in the concrete. Here isisa more counter-example. Remark 4 Observe that if 2 is not that an abstract contract precise an increasing concretization 2 A ! PJ~ v K; 1 Remark 4 Observe that if is not meet-preserving then the property that an abstract co 2 Remark Observe thatbeifpreserved that an abstract2 contract is more precise 2 2 is not meet-preserving than another4one may not in the concrete. then Herethe is aproperty counter-example. another oneconcrete. be in theabstract concrete. Here is is a precise counter-example. Remark 4 isObserve if 2 is not meet Remark Observe ifthan meet-preserving thenHere thepreserved property that an contract more than another one44may not that bethat preserved in the is2.a The counter-example. 2 is not abstract domain hB, vi anthat abstraction of binar Remark Observe if then the property that an abstract contract is more precise P’may not 2 is not meet-preserving than another one may not be preserved in the concrete. Here is a counter-example. Q thanP’ another one may not beanpreserved in! 2 P’ Remark 4 Observe that if is not meet-preserving then the property that abstract by an finite-meet-preserving concretization 2 Bco than another one may preserved in the concrete. Hereproperty is a counter-example. 2 2 Q Qthe Remark 4 Observe thatnot if be then abstract contract is more precise 2 meet-preserving 2 is not meet-preserving 4 the Observe thatthat if an then prop 2 2 is not P’mayRemark 2Q’be preserved than another one not in the Here is a Q’ counter-example. implies thatconcrete. Q’ 2 is increasing); Q than another one may not be preserved in the concrete. Here is a counter-example. 2 than another one may not be preserved in the concrete. Here is a c γan22abstract P’ 2 4 Observe that if 2 is not meet-preserving Q then the property that contract is more precise P’counter-example. anti-projection. Please note that those assumptions are in no Remark is noteasy to inobserve that γcc2Q’ is increasing. However, if γ2P 2 A can be embedde P’may than another It one the concrete. Here is a P 3. abstract predicates 2 P’be preserved Q 2 The unary Q’ Q P Q P 2 0 is more ~precise Remark 4 Observe that if 2 is not meet-preserving then the propertyγthat an abstract contract P’ 2 2 (P))(~ Q’ 8~ v , ~v 2the V J~property v K : 2 2(" v 0 , ~v ) = 1 (P)(~v 0 ). 22 measure restrictive, we just make them explicit — all static isanother increasing but innot meet-preserving then that Q’ than one mayP’ not be Q’ preserved the concrete. Here P is a counter-example. 1 2 1
γ
γ γγ Q γ γ Q’ γγ γ γ γ γ P γ γ γ γ γ2 γ2 γ Q P’ γ precise γRemark Q’ 2 than PP’ P’P contract Q’Q γis γmore P’ an abstract another one may Q 2γ 3 This amounts to the use of only one abstrac γ Q P Q’ Q 2 γ22 γ2 straction P Q’ Q’ 0, ~ γ2 ~v the ofby v . P(~ v2 0 ) into B. γ Q’ not beP’preserved inQ the concrete, as shown following P 2 γ γ2 γ γ P P 2 Q’ counter-example. γγ2 is extended to contracts γγ abstraction γ2 hC J~v γ P 2γ2 γ2 This predicate PP P 2 γ 2 Qi) , and h 1 (P), 2 (Q)i Example 12. Let us consider the two domains γ2 abstract(hP, γ 0 0 0 0 0 Qi v hP , Qγi2 ,0 P0 v P ^ "21 (P ) u Q v Q 0 v P ^ "2 (P0 ) uγQ v Q0hP, the concrete domain We have Pbelow: and so hP, Qi v hP , Q not0 γ(hP, Qi) =) 2 1 2 0 2i but 0 2 0 0 0 We have P v P ^ " (P ) u Q v Q and so hP, Qi P’
analyzers implement those primitives, e.g., the projection to remove variables when they go out of scope. The predicate :J·K denotes the unmodified variables. Given a set of variables ~g ⊆ ~v, then :J~gK ∈ BJ~v, ~vK is the abstract statement that none of the values of the variables ~g has changed, that is
2
2
2
2
2
2
cc
2
2
cc cc
2
1
2
cc
1
2
2
2
cc
cc
1 2 0 ˙ We have P ccv1 1P ^ "21 (P )2 u2 Q v2 Q and so cch ˙2 cc 0 2 (Q0 ). cc 6 =) 2 ("1 (P )0 ^ 2 (Q) cc cc 0 v 0 and 0 , 0 Q0 i0 but 0 ). 0 not 0 ) u Q2v Q 0 and so 0 , 2Q0 i) 0since0˙ 10 2 0 We 0 iv 2 WeWe havehave P0 v P P 0^ v "1 21 (P hP, QiPand v hP , P Q0hP, i^ but" not =) have (P )hPu20Qi) Q so hP, Qi v6 =) hP ˙ =) ccQ 2 Q (" (P )) ^ (Q) cc (hP, cc (hP ˙ P ^ " (P ) u v Q so Qi v , Q but not Qi) =) since ˙ , 2Q(Q (P ) ^ ). cccc (hP, Qi) 0=) 2 2 cc (hP, cc 6 (hP 1 2 2 (Q) 2i)(Q 2 1 1 0 0 0 0 0 0 cc cc 20 2 Q 6 =) (P0 ) ^˙ 2 2 (Q) =) 01) 6 ^ 0 2) ^ 0 ). 2 (Q 2 0 ).=) 0 (P 0 ,(Q 0 i but cc (hP0 , Q02 ˙"˙ 2 (P 1 ˙ hP, 22 (Q ˙ (" (P^ ). 1 (" 2 ˙Q v cc (Q) cc not 0 2v 2 (Q))2 6 u cc We have P2 0 We P Q and so Qi v hP Q (hP, Qi) =) i) since cc cc 2 2 2 1 0 0 0 0 0 0 cc cc Lemma 22 is increasing. 1 2 cc0 cc2(hP, Qi)2 =) 0 cc (hP , Q i) cc 0Qiv have P v1P ^2 "1 (P ) u Q We v Q and so hP, since Qi v hP cc 0 , Q0 i but 1v hP , Q i but not 2 0 0 have P P ^ " (P ) u Q v Q and so hP, not0 cc (hP, Qi) =) 0 0 0 0 0 0 2 0 ^ 02). Q2 v 0v We have ^˙contract "˙1 (P )0).u Q and so hP, Qi1 v hP , Q i but not cc (hP, ˙ P2Abstract )1 ^˙ P 6 =) (Q 221 (P 226 (Q) cc (hP , Q i) since =) 2 Qi) =) 1 )14 2 (" 2(P(Q) 22(Q 2 2 0 ˙ refactoring 0 ). 2 0 0 0 ˙ 1 2 cc (" (P ) ^ (Q) 6 =) (Q 0 0 2 Q v Q 2 1 2 2 We have P v Pcc^ "1 (P ) u an ˙ 142have ˙0 v1 P (Q)Abstract 6 =) 2 (P ) ^ 2 (Q 2 refactoring contract We PTh. ^ ").2 (P0 ) u Q v2 Q0 and so hP, Qi vProof hP0 , Q0 i but ccnot 2cc (hP, Qi) =) cc (hP0 , Q0 20 i) sincecc We now 4, which is, in1 general, more precise than abstracting Th. 3. cc 00 0 (P ˙0 2cc(Q) 14 0abstract Abstract contract refactoring ˙not0 2Th. 2 which 6 =) (Q ). Qi) =) 0 v 0) u 0 and somore cc is,2 in general, 2 (" 0now 1 We 4, precise than 2 Q 1Q cc(hP, have P P Th. ^ "hP, (PQi v00 ,Q hP, Qi v2 i)) hP^ , =) Q0abstracting i but 0 and 0hP, 0 i)3. ˙"2 (P02We Qi v0 hP , (PTODO: ) ^˙P0 2v1(Q) 6 =) (Q ). v2 abstract cc 2abstract 0 0 0 2 Q 1We We 2We have P ^ ) u Q so v hP Q i but not (hP, Qi) (hP , Q since 1We now Th. 4, which is, in general, more pr cc have v P ^0 Th. "1 (P ) u2ccabstract Q0 v Q Th. and4,0so hP, Qi v general, hP , Q i2 We which is, in mb 14, which nowabstract abstract is, in0more general, more precise than abstracting 3.now 2 TODO: 0 ).P Th. Th. 4, which is, in (" general, than6 =) abstracting Th. 3. 2We now ^˙ precise (Q 0 ^ 2 (Q 2 (Q) 0 ).) u 1 ˙ 2 (Q) 6 =) 10(P ˙ We ). )abstract 2 Q Th. ˙4,2which is,^ precise than () P 6v ^ TODO: "221(Q (P v2 Qabstracting Th. 3. 2 ˙in general, TODO: 2 ("1 (P )) 2 now TODO: TODO: ˙Pmore ("221 (P0 )) =) 2 (Q) 0 0 0 TODO: 2 We now abstract Th. 4, which is, in general, more precise than abstracting Th. =) 3.˙ 2 ˙ 3. 2 (Q ) =) 1 (P )more 1 (P) ^than 2 ("abstracting 1 (P ) u Q) Th. now abstract Th.precise 4, which is,=) in general, precise We0 now abstract Th. 4, whichWe is, in general, more than abstracting TODO: 0 Th. 3. 2 ˙ TODO: ˙ ˙gene () ( (P ) =) (P)) ^ ( (" (P)) ^ (Q) We now 1 1 abstract2 Th. 2 is, in=) TODO: 1 4, which We now abstract Th. 4, which is, in general, more precise than abstracting Th. 3. 0 0 0 0 TODO: ˙ ~ ~ () ( (P ) =) (P)) ^ ( v , v (P )(~ v ) ^ 2 We now abstract Th. 4, which is, in general, more precise than abstracting Th. 3. 1 2 (Q 0 0 precise than abstracting 0 Th. 13. 2 1 1 is, in general, more abstract Th. 4, which 0 We now TODO: general,0 more precise than abs 0 1 We now2 abstract Th. 4, which is, in cc TODO: () h (P), (Q)i =) h (P ), (Q )i TODO:cc 1 2 1 2 TODO: cc 0 0 0 0 0 0 cc cc cc
γ2 (:J~gK) , λ ~v 0 , ~v . ∀x ∈ ~g : ~v 0 (x) = ~v (x).
1
2
2
We have P v P ^ " (P ) u Q v Q and so hP, Qi v hP , Q i but not ˙ 14 (" (P ) ^˙ (Q) 6 =) (Q ).Abstract contract refactoring 1
2
(hP, Qi) =)
(hP ,
2
14 14 Abstract contract refactoring Abstract contract refactorin
The embedding ↑ 21 ∈ AJ~vK → BJ~v, ~vK embeds unary 14 Abstract contract refactoring 1414 Abstract contract refactoring predicates into binary predicates. It respects the soundness Abstract contract refactoring Abstract contract refactoring 14 Abstract contract14refactoring condition: 14 Abstract contract refacto 14 Abstract contract refactoring We now abstract Th. 4, which is, in general, more precise than abstracting Th. 3. 14 Abstract contract refactoring 2 0 0 ~ 14 Abstract contract refactoring 14 Abstract contract refactoring ∀P ∈ AJ~vK : ∀~v , ~v ∈ VJ~vK : γ2 (↑ 1 (P ))(~v , ~v ) = γ1 (P )(~v ) . TODO: . We have P v P ∧ ↑ (P ) u Q v Q and so hP, We assume that the embedding is increasing, i.e., if P v1 P 0 Qi v hP , Q i but not γ (hP, () Qi) =⇒ γ (hP , (hP Q ,i)Q i) then ↑ 21 (P ) v2 ↑ 21 (P ). (hP, Qi) =) 2 0 0 ˙ since γ (↑ (P )) ∧ γ (Q) =⇒ 6 ˙ γ (Q ). So even if in the 2 2 2 1 The abstract projection ↓~p\~g projects onto the parameters abstract the contract hP, Qi is more precise that the contract 44 and global variables. It satisfies the following soundness 0 hP , Qi, this is not true in the concrete. So in this case, criteria: (P ∈ AJ~p, ~gK and Q ∈ BJ(~p, ~g), (~p, ~g)K) improving the precision of a contract in the abstract does not P v1 ↓~p\~g (P ) guarantee that the concretization also improves. ˙∃~g : γ1 (P )~p, ~g = γ1 (↓~p\~g (P )) We now have two45 reasons for assuming γ2 to be finite ˙∃~g : γ2 (Q) =⇒ meet-preserving. One 45is to ensure the soundness of the ˙ γ2 (↓~p\~g (Q)) abstract conjunction rule (∧), i.e., the reduced product (Th. 6) ↓~p\~g is increasing . and the other to preserve the precision relation between abstract contracts in the concrete. Global variables can be reintroduced by the abstract an45 tiprojection ↑~p\~g ∈ BJ~p, ~pK → BJ(~p, ~g), (~p, ~g)K. It satisfies 11. Abstract separate method analysis the soundness requirement: (Q ∈ BJ~q, ~qK) We are now ready to formalize the rule in the abstract 45 Hoare ˙ γ2 ↑~p\~g (Q) . logic to handle the method call. We abstract the corresponding λ ((~q 0 , ~g 0 ), (~q, ~g )) . γ2 (Q)(~q 0 , ~q) ∧ ~g = ~g 0 =⇒ 45 rules for method call of Sec.457. 45 In the following, we leave variable renaming implicit, 45 We obtain the abstract separate method call analysis ~ ~ 45 identifying AJ~pK and AJ~qK whenever VJ~qK = VJ~pK. rule by replacing the concrete Hoare triples, implications, 45 45 45 projection etc. of (8) with their abstract counterparts defined Abstract contracts In analogy to what was done in Sec. 6 0 above: (P ∈ AJ~p, ~gK, P ∈ AJ~pK, and45Q ∈ BJ~p, ~pK): for the concrete contracts, we define abstract contracts and 0 a covariant and contravariant order on those. An abstract ¯ ¯ P0 ¯S ¯ ↓~p\~g (P ) v1 P |~p\~g Q , contract is an element of AJ~pK × BJ~p, ~pK. . (19) ¯P ¯ m(~q) ¯ ↑ (Q) ¯ The callee/covariant partial order on abstract contracts is cc
~p\~g
defined as
0
0
0
The abstract version of (9) propagates the properties of the unmodified variables ~g through the call. ¯P ¯S ¯ ¯ |~p\~g Q (20) ¯P ¯S ¯ 2 ¯ . |~p\~g ↑ 1 (P ) u2 Q u2 :J~gK
0
˙ × hP , Qi v hP , Q i , P v1 P ∧ Q v2 Q .
The meaning is given by the concretization function γ× ∈ ˙ × ˙ × hAJ~pK × BJ~p, ~pK, vi → hCJmK, =⇒i defined as γ× (hP , Qi) , hγ1 (P ), γ2 (Q)i.
Theorem 13 (Soundness of the abstract separate method call analysis rule). Abstract rules (19) and (20) are sound in the sense of (4).
The caller/contravariant partial order on abstract contracts is defined as cc
0
0
0
0
0
12.
hP , Qi v hP , Q i , P v1 P ∧ ↑ 21 (P ) u2 Q v2 Q .
γcc (hP , Qi) , hγ1 (P ), γ2 (Q)i .
Extract Method with Abstract Contracts
We define the problem of the Approximate Extract Method with Contracts EMC, by providing the abstract counterparts for the definitions and requirements of Sec. 8. We prove that the EMC implies EMC, but that the converse does not hold.
The meaning is given by the concretization function γcc ∈ cc cc hAJ~pK × BJ~p, ~pK, vi → hCJmK, =⇒i defined as Paper
cc
(18)
13
2013/10/25
Assumptions The assumptions on code and invariant selection are similar to the concrete ones in Sec. 8, but now relative to abstract predicates. We assume the variable decomposition is ~v = ~p, ~g and ¯P ¯ ¯ ¯ S S|~p\~g QS so that the analysis of the selected code is sound. Those hypotheses essentially ensure the correctness of the code to be extracted. The next two hypotheses are completeness hypotheses requiring the abstraction to be expressive enough. We assume that the post-condition of the selected code is strong enough in that QS v2 (↑ 21 (P S ) u2 :J~gK). This implies that the information known on the initial values of the parameters and the fact that variables ~g are unchanged is not lost, that is for all p~0 , ~g 0 , p~, ~g , p0 , ~g 0 ), (~ p, ~g )) =⇒ γ1 (P S )(~ p0 , ~g 0 ) γ2 (QS )((~ 0 0 0 γ2 (QS )((~ p , ~g ), (~ p, ~g )) =⇒ (~g = ~g ) .
(21)
Furthermore, we assume that the analysis of the selected code is independent of the unread/unwritten variables, viz. ↑~p\~g ↓~p\~g (↑ 21 (P S ) u2 QS u2 :J~gK) u2 :J~gK v2 QS (22) The following contrived example shows why we need this hypothesis. Even if the selected code S does not depend upon the variables ~g the analysis of this code might nevertheless depend upon these neither used nor modified variables ~g.
... { g in [11, 11] } NewMethod(p); { p in [10, 11] } ... private static void NewMethod (int p) { { Pr(p’) = true } p = 0; while (p < 10) p = p + 1; { Qr(p’, p) = p in [10, +oo] } }
(b) – safety The abstract refactored contract hP R , QR i is stronger than the abstract method safety contract hP m , Qm i: P m is a necessary but possibly not sufficient condition for the absence of run-time error when the method is called [18]. Qm over-approximates the post-condition resulting from the execution of the method body assuming P m on entry. The abstract refactored contract requires more, so that P R implies P m which is necessary (but possibly not sufficient) for the absence of runtime errors when executing the extracted method. The abstract refactored contracts ensures more, so QR implies Qm . It takes at least into account on method exit what can be learned in the abstract from the method pre-condition P m followed by the execution of the method body, which can be summarized by: (23)
(c) – completeness The refactored code is still provable inthe abstract with the same precision as the original ¯ ¯ ¯ code: P S m(~p) QS ¯ is provable by the abstract separate method call analysis rule of Th. 13 using the extracted method abstract contract hP R , QR i. (d) – generality Optionally, the abstract refactored contract hP R , QR i is the most general: The pre-condition of the refactored contract hP R , QR i is the weakest possible (so that the extracted method applicability is as general as possible) and its post-condition is the strongest possible (so that calls to the extracted method get as much information as possible on its effect) for the considered abstract 0 0 domains. It can be shown that if hP R , QR i satisfies requirements (a) – validity, (b) – safety, and (c) – completeness cc 0 0 then hP R , QR i v hP R , QR i.
We assume that the static analysis is an interval analysis with a widening using thresholds. The thresholds are assumed to be obtained by looking at all visible variables with a constant interval. So the analysis of the selected code uses the threshold 11 from the value of g while the analysis of the extracted method has no threshold at all so widen to +∞. Then the method post-condition is too weak to prove the selected code post-invariant. Of course the constants of the program (e.g., 10) could also be used as thresholds or a narrowing could improve the result but we assume that this is not the case in this contrived example.
Theorem 15 (Correctness of the abstract requirements). The abstract requirements (a) – validity, (b) – safety, and (c) – completeness respectively imply the concrete requirements (a) – validity, (b) – safety, and (c) – completeness for the concretization of the abstract predicates. Therefore, by Th. 13, method extraction with abstract contracts is sound.
Finally, we assume that the abstract safety contract for the extracted method: hP m |~p , Qm |~p,~p i is such that ¯ P m ¯ S ¯ Qm ¯ .
Notice that Th. 15 does not state that abstract completeness implies concrete completeness for any concrete contract. It states that abstract completeness implies concrete completeness for the concretization of abstract contracts. So it should be understood as meaning that properties of abstract contracts hold in the concrete up to their concretization. The intuition is that the separate method call analysis rule is more
The safety precondition P m is first obtained by a backward analysis of the method body S [18] and then Qm is derived form P m by a forward reachability analysis of S [11]. Paper
(a) – validity The abstract refactored contract hP R , QR i is valid: assuming the refactored abstract contract precondition, the post-condition must hold: ¯. ¯P ¯ ¯ R S|~p\~g QR
˙ × hP R , QR i v hP m , Qm i .
Example 14. Let us consider the following syntactic refactoring: ... { g in [11, 11] } p = 0; while (p < 10) p = p + 1; { p in [10, 11] }
Method extraction with abstract contracts, EMC We provide abstract counterparts for the requirements of EMC of Sec. 8. We call the problem EMC.
14
2013/10/25
powerful in the concrete than in the abstract. Of course, some concrete contracts are not the concretization of any abstract contract and Th. 15 states nothing on these contracts. Th. 10 and 11 are stronger than Th. 15 since Th. 15 is only valid in the concrete for concrete contracts expressible in the abstract without any loss of information while Th. 10 and 11 hold for any concrete contract. Impossibility of complete abstract refactoring Approximations introduce new difficulties. In practice, the abstract requirement (c) – completeness can only be optional — the concretization of the best abstract refactored contract, if any, might not be the best concrete refactored contract considered in (c) – completeness. The following counter-example proves that abstract refactoring is necessarily incomplete. Example 16 (Impossibility of complete abstract refactoring, I). Consider the following refactoring ... { Ps(p, g) = (g == 0) } while (1) p = 0; { Qs(p, g, p’, g’) = (g == g’ == 7) } ... { Ps(p, g) = (g == 0) } NewMethod(p); { Qs(p, g, p’, g’) = (g’ == g+1 == 7) } ... private static void NewMethod (int p) { { Pr(p) = true } while (1) p = 0; { Qr(p, p’) = (p’ == p-2 == 17) } }
13.
Approximate iterated method refactoring
We want a static analysis to effectively solve EMC. The main idea is to abstract the iterated exact refactoring of Th. 11. We see under which hypotheses the computed solution is the best one and how we can derive an approximated solution.
The loop does not terminate so the exit invariant is false which is over-approximated by QS (p, g, p0 , g 0 ) , (g = g 0 = 7) in the original code and by QR (p, p0 ) , (p0 = p − 2 = 17) in the extracted method. QS and QR are a perfectly correct partial-correctness invariants/post-conditions since false ˙ =⇒ ˙ QS and false ˙ =⇒ ˙ QR . However, assuming PS (p, g) , (g = 0) and QR (p, p0 ) , (p0 = p − 2 = 17), and ignoring the method body, it is impossible to prove that QS (p, g, p0 , g 0 ) , (g = g 0 = 7) does hold. This proves that abstract refactoring is necessarily incomplete (since termination is undecidable). Please note that this is not in contradiction with the fact that there is no problem (except incomputability) with exact refactoring, since the method body exact post-condition QR shall be false. ˙ Example 17 (Impossibility of complete abstract refactoring, II). Consider the following situation where the selected code S does not read or modify g. ... { Ps(p, g) = (g == 10) } while (1) do { p = p }; { Qs(p, g, p’, g’) = ( g == g’ == 1 ) }
Initial state When the user selects a piece of code S, the underlying static analyzer extracts a pair hP S , QS i containing the pre-state and the post-state for S. The pre-state (resp. the post-state) is the semantic information known to the analyzer at the program point just before (resp. after) the selected code: PS , γ1 (P S ) and QS , γ2 (QS ). (24) The pre-state and the post-state are projected onto the parameters of the extracted method: P S , ↓~p\~g (P S ) and QS , ↓~p\~g (QS ) .
.
(25)
The initial abstract state for the (greatest) fixpoint computation soundly approximates the initial concrete state: Lemma 18. Equations (25) and (24) imply that hPS. , Q. Si . . cc =⇒ γcc (hP S , QS i). The underlying static analyzer may infer an approximated safety condition P m , in which case we let Pm , γ1 (P m ). Otherwise we assume Pm to be the strongest safety precondition. In both cases Qm = post JS~p KPm is the corresponding strongest relational post-condition. Abstract transformer An abstract contract transformer F R JSK has to be designed that soundly overapproximates the concrete contract transformer (16). The specification of F R JSK is therefore: cc ˙ (26) FR JSK ◦ γcc =⇒ γcc ◦ F R JSK
... { Ps(p, g) = (g == 10) } NewMethod(p); { Qs(p, g, p’, g’) = ( g == g’ == 1 ) } ... private static void NewMethod (int p) { { Pr(p) = true } while (1) do { p = p }; { Qr(p, p’) = true } } Paper
The separate analysis of the extracted method cannot prove the post-condition QS despite the fact that QR (p0 , p) =⇒ ∃g, g 0 : QS ((p, g), (p0 , g 0 )) (choose g = g 0 = 1). The problem comes from the fact that false, which is the strongest post-condition for the selected code, was over-approximated by QS (p, g, p0 , g 0 ) , (g = g 0 = 1) and by QR (p, p0 ) , true after the body of the refactored procedure. Since g 0 is not available in the procedure body, it is impossible to make the same over-approximation of false in the method body as it was done in the selected code. The counter-example is based on the fact that, in case of non-termination, since QS can state properties of g which are completely different form those stated by PS although g is not modified by the loop body. This situation can hardly happen in practice since abstract transformers and widening/narrowing will leave g abstract properties unchanged since the selected code neither reads nor writes g. Examples 16 and 17 are based on non-termination, in which case false can be approximated differently in the selected and refactored code.
In practice this means that we have, for a program statement S, either a forward static analysis, or a backwards static 15
2013/10/25
˙ which ¯ ¯ #consequence ¯v K, vi2is an the abstract rule of domain Lem. 31I Hypotheses 1. The abstract hAJ~ abstraction of unary predicates v K,abstract =)i cc . The hPJ~ unary predicates v.Kabstraction can be embedded into BJ~v , ~vccK hPJ~ as "v21,(P) =) ¯ # is (P (Q 21 u1 " (P g K) ~v K, abstract domain hBJ~ v , ~v K, P vi2 isAJ~ an of binary predicates 2 v. K ! PJ~ meaning given increasing concretization AJ~ v K;. 2.4. The S ) Sby an S ) u :J~
. gmeaning S is¯ given 1u ~g R✓i~vand 3. Given variables then :J~ gQ 2S iBJ~ v conse, ~v K2def. is the 0(11-b) abstract statement that nob (" QRvQ ) S˙vby QHsince by hyp. , #Q hP ,2concretization ofv, v by an concretization AJ~ vK)Kv !v K; 0 , and "Q~p~pS\~ (" Q :J~ gHsince K) 1¯u :J~ g Hyp. abstract ¯gvi###~pis~p\~an ¯ ¯¯S R8P ~K Hyp. 112(P Swhich ¯¯ggHsince ¯u ~v~~ppSSK,\~ S )) binary 2. The abstract domain hBJ~ v ¯, #P viqqS )is an abstraction predicates v K,PJ~ =)i isv,:1(1), ~vmeaning P M(~ )hAJ~ BJ~ v 15.2(1-1d) ,Q K hP and 2analysis 8~ v 0) ,~ vSby V J~ v of K :and ("3(a)I (P))(~ v v,~,v~v) K=!10PJ~ (P)(~ \~g abstraction S u ~v).K one given by a finite-meet-preserving 2. BJ~ (i.e. abstr =) (P ,has 234I 2 (Q M(~ ) ("S121)(P (Pof Qincreasing :J~ Habstract separate method rule uvhPJ~ :J~ g Hby ˙ SK, ~ Remark 4 SThe hypotheses 1(2), andLem. 1(4)2Th. amount to 2the of vonly Hypotheses 1 1. The abstract domain K, of unary hPJ~ K, =)i which ~pAJ~ \~ \~gv K(Q S u ~gcall ~g use variables changed thatS is v 10 ,~ v 7I 8x : ~v (x) = ~v (x); ~p \~ g ~p ~p\~g\~g(Q S upredicates 2 (:J~ 2 g K) 13 g K) , ~ 0 0 ⇣v"rule ⌘rule 02(c) 0 increasing) of Lem. 0 ) into BJ~ 2 2is which implies isis Hby Hyp 15.2(1c-1) soK31I that QK;,hBJ~ )consequence u~v K:J~ gof K), bypredicates Hyp. that #meaning increasing, .AJ~ 13 Contract abstraction ˙Contract ~vabstracting 2. Lem. The abstract domain vv, ~v (" K, vi is an abstraction binary hPJ~ v ,31I K,so =)i which unary predicates P by abstraction ofand P(~ v , ~v K. Moreov Sv We assume that "g is increasing that is; for all P,~vP0 ,~v2by vv K, P v P implies that "21 ~pthat \~ S~ quence of 13 abstraction 2vK, 1 (P is given by anabstract increasing concretization 2 AJ~ ! PJ~ v 1(Q ˙ ⌅ 1 2 given by ameaning finite-meet-preserving concretization 2 BJ~ v v K ! PJ~ , (i.e. (Q u Q ) = (Q) ^ ) ˙ . 0 0 ~ ~ ¯ ¯ ¯ 2. The domain hBJ~ v , v vi is an abstraction of binary predicates hPJ~ v , v K, =)i which meaning is 2 2 2 2 ¯ ¯ ¯ ¯ ""Q~p~pS\~ ##~p~p~p\~g\~ (" (P u Q u :J~ gg K) u :J~ g KK~v K !v(Q Q by Hyp. 15.2(1-1d) and abstract 4. The unary abstract predicates P Hby 2 of AJ~ v KLem. canconsebevariables, embedded into BJ~ vthe , ~v case K as "of21 (P) ¯ ¯ ¯ ¯ ˙~gexpress (P ) S # (Q u " ) u :J~ g K) SS))1 (P abstract domain can equality values of which is mo ~v given by a finite-meet-preserving concretization 2 BJ~ v , PJ~ v , K (i.e. (Q u Q ) = (Q) ^ (Q ) g g S S =) #P~pS\~gHsince M(~ q ) (" (P u Q u :J~ K) u :J~ g 34I S S 2 2 2 2 1 S # =) # (P ) S ) Hsince Q , # (Q ) ~ ~ 3. Given variables ✓ v , then :J~ g K 2 BJ~ v , v K is the abstract statement that \~ g \~ g S the abstract consequence rule of Lem. ~p \~g ~p13\~g31IS ~p \~g 0 0 S Sno 1 that 2 ~p ~ J~v K : at2 (" Wewhich assume 13 BJ~v , ~vproduct K and 8P 2 AJ~v K domains : 8~v 0 ,~v 2including V (P))(~ v 0abstract ,~v ) =S 1domain. (P)(~v 0 ). reduced of changed abstract least implies that 2 is increasing) .(Q ˙amount which implies that domain is increasing) ˙2 ¯2 Remark 4 that The and to 2the of only one abstr ~g has ~g) use 2. The abstract hBJ~ v , ~vaK, vi is an¯⇣;abstraction of binary predicates hPJ~v¯2, ~v K,; =)i which is PJ~ ~v 10 ,~v2one variables that K)1(4) ,^ 8x : ~v 0 (x) = ~v (x); concretization vmeaning v⌘ K ! v2 , ~vWe Kassume (i.e. (Q ) is=1(2), 2 (:J~ 2given quence rule 2g(Q) 2hypotheses ¯by ¯ finite-meet-preserving 2 31I ¯ BJ~ ¯, ~ ¯ u Q1(1), 0 ⌅ 0 ¯ of Lem. 2
2
2
2 2
2
1
2 2
2
2
2
2 2
2 2
2
2 2
2 2
2 2
2
2
2
2
1
2
2
2
2
0Hyp. 0 ) into BJ~ 2(Q 2 "2(c) Hby so1K that v(i.e. (":J~ )(P u02 u g that #K)=)i is increasing, and M(~ qHyp ) "Q =) In P Habstract separate method rule ofofvi Th. 7I .AJ~ =) #(P S:J~ #^˙K~p by u (P )so u2 assume :J~ 22 Q 2:J~ ~vP0 ,~ predicates P byabstract abstraction v2by P(~ v , ~v K. predica Moreov #3.Hypotheses ("v 1variables Q u22domain :J~ g K) gK), Q by Hyp. 15.2(1-1d) and conseS2u S Hsince We that "abstract is increasing that is for P, vv K, P v Pof implies that "21 Sabstracting 1. hAJ~ v abstraction of hPJ~ vunary K,call which ~p˙The ~p15.2(1c-1) ~p2\~ \~ g21analysis gBJ~ \~ g \~ gv S unary S!)The 1predicates ~(Q) Hypotheses 1g 1. abstract hAJ~ v K,all is S\~g is pthe Sthe general the abstract refactoring hP Q Th. will not most refacgiven by a finite-meet-preserving concretization , ~v(P PJ~ vabstract QK,vS),)vi )be ~u ~v=10 Given g13 ✓ ,K,then Kin BJ~ Kisis2an abstract that none of values of the RS 2 (Q statement Remark 5theNotice also that thedomain abstract BJ~ van, ~vabstraction K caninto alsoBJ~ beunary usin R1i2g~p(Q ~v case 4. Theprecise unary abstract predicates Pcontract 2 of AJ~ vdomain K canofbe embedded ,encoded K as "of21 (P) which implies that ;,S~v~vincreasing 2 2increasing) abstract domain canbyexpress equality values variables, isv vK; the mo meaning is~g given by an concretization v K; 0 (x) 13 ; ¯⇣ meaning an increasing concretization Kwhich ! PJ~ .28xAJ~2v ~Kg⌘¯!: ~vPJ~ 2is given ~v 0 , ~v1 15.2(1c-1) variables has changed thatLem. is 2 (:J~ g31I K) , Hyp = ~v that (x); Q 2 1 2 AJ~ the consequence rule of 0 ,~ 0v auxiliary variables, is: often analyzing withv 0a).is relational ~ when ¯increasing) ¯ M(~ which implies ~vproduct quence of Lem. 31I BJ~ ,concrete K 1and 2which v:J~ Kand 8~vK), vdone 2by V J~ vLem. K :11.4(4), vprocedures ,~vthat ) = 1domain. Hby so v2v 15.2(1-1d) (" (P8P )abstract u2AJ~ g Hyp. 2(c) so #(P)(~ incr ~g that ~v2 ,isthen ~vg (" 3. Given variables ✓toring. :J~ K "2rule BJ~ v ,\~ K 21is(P the statement that none of the values the 2 (" 2version theqgabstract requirement 15.3(4), isK) the of the requirement S reduced ofof domains including atconseleast one abstract =) PSo )abstract Hby 34I ~ponly ⌅ 1 (P))(~ \~ g S 22abstract 22 that 22 abstract # ) u Q u :J~ g u :J~ g K v Q by Hyp. abstract S Hsince ~ ~ p \~ g p S Remark 4 The hypotheses 1(1), 1(2), and 1(4) amount to the use of one S Sthe assumption x 2= meaning x0 abstract for allisformal parameters x where is an auxiliary variableabstr sym 2 0 ofx0binary 0 ˙ In general the abstract refactoring hP , Q i in Th. 10 will not be most precise contract refac¯ ¯ ¯ ¯ ~ ~ 2. The abstract domain hBJ~ v , v K, vi is an abstraction of binary predicates hPJ~ v v K, =)i which 2,2. ~ ~ The abstract domain hBJ~ v , v K, vi is an abstraction predicates hPJ~ v , v 2 R R 0 0 2 2 ~ The unary abstract P:J~ AJ~ Kthe can abstract be embedded into BJ~ v , v K as "rule such that "call 231I AJ~ visK increasing ! 0 ,1~ 02(x) M(~ q(:J~ )2general. "BJ~ #v4.is~p,There (" (P =) Pthen )several uKpredicates Q2~gS BJ~ uthat gvKK) Habstract separate method rule ofall .AJ~ We "1analysis that is for P,~vPof vv K,) Pinto v PBJ~implies that "K,21 consequence ofofassume abstracting unary predicates Psee bythe abstraction ofTh. ,~v27I P(~ v , ~v K. Moreov 0Lem. 0 of S hold S8x 1 (P) 1that ~ p \~ g \~ g value the actual parameter, [20]. ~ ~ ~ 3. Given g ✓ then :J~ g v , v is the abstract statement that none values the does in are possible reasons. ~g hasvariables ~g ✓ that ~v¯not ~ ~ ~ ~ variables changed is g K) , v v 2 : v = v (x); 3. Given , variables :J~ g K v , v K the abstract statement none of the values of the ˙ ¯ ¯ ¯ ~v⌅ also that domain BJ~ Kv can be ,encoded given a31I finite-meet-preserving concretization PJ~v2v, ~v0 ).K (i.e. 2Remark (Q u Q by )5=aNotice ) the abstract 2q ) 2 2 2 BJ~ ~v case quence of Lem. given finite-meet-preserving concretization 2 ,BJ~ , ~vwhich K also ! PJ~ K (i.e.of usin (Q 2 (Q) ^ 2 (Q ~ J~v K :the 2v 2mo =) PSo Qrule BJ~v , ~vbyK and 8P0 215.3(4), AJ~v K : 8~v 0 , ~vthat V (P))(~v 0v, ~,v~v) K=!version abstract domain can express equality of values of variables, is vthe 2 ("1¯abstract 1 (P)(~ ¯ 2P ¯requirement toring. the abstract of the concrete 11.4(4), S M(~ S ~v 0requirement 13 ;¯is 2 auxiliary 2 variables, 13 ;when . M(~ q ) " # (" (P =) ) u Q u :J~ g K) separate method call 0, ~ 01(x) 2is which isHabstract often done analyzing procedures with analysis a relational which implies that isg increasing) ~ S S ~ ~ ~ variables ~g has variables changed that is (:J~ g K) , , v 8x 2 g : v (x) = v (x); ¯ ¯ ¯ ¯ cc which implies that is increasing) ~ ~ p \~ g p \~ g S 2 2 2 cc ⇣ ⌘ 0 0 0 ~ ~ 2 2 2 ~ ~ ~ g has changed that (:J~ K) , v v 8x 2 g : v = v (x); general refactoring i in Th. 10 2will be the most precise abstract contract reduced product of abstract domains including at refacleast one =) In P M(~qthe ) "abstract QRS, uQR:J~ gfor K) gv KK, not Hby Lem. 2 hP ~vsym This abstraction extended toand contracts hC34I J~ vxK,toabstract as domain. hAJ~ K variable ⇥ BJ~ K, The 1(1), 1(2), 1(4) amount the of vonly onev ,abstr S hold S.)2several .2 ~p \~g #~pThere \~ g (" We assume that "u that is all u P, P:J~ AJ~ P v P implies that Remark "21 (P)predicate v "421 (P ). hypotheses 1 (P assumption x = x0 for all2isformal parameters x where is=)i an use auxiliary 1 is increasing does notabstract inAJ~ general. are possible reasons. 2 2 ¯:J~ .0P(~ "can #embedded ("Sembedded Q u K)BJ~ :J~ g2AJ~ K(P) v2 ! Q21 (P Hyp. 15.2(1-1d) abstract 1. The projection ,(P Q the selected abstract contract abstracting unary predicates Psee by v 0 ) intostatement BJ~v , ~v K. that Moreov ~u 3. Given gof then gSKg¯v 2is ,u is statement that none the values of✓u 2 3. 22 2the ~g K ~vand ~v K~vis0 ,~vthe ~the SS)iBJ~ 2P Given variables , :J~ then :J~ g¯ K 2 BJ~11.4(4), vof,conseabstract no 4. The unary abstract predicates PPthe be BJ~ ,code vqvthat K~v2 K¯0as such "S21ofofu AJ~ ! ~pK\~g¯can ~p \~ M(~ ) (" u Q :J~ gv K) gabstract Kabstraction ghP S by 1variables value the actual parameter, [20]. S )that \~ toring. So¯Hsince abstract 15.3(4), that abstract of the concrete requirement 4. The unary abstract predicates 22AJ~ v¯Kv be requirement into v✓ , ~v~v=) KS,into asQ ":J~ (P) such ""2~pthe 2"gabstract v~p \~ Kgversion 1# ¯P Remark 52 Notice also that the domain BJ~ v , ~v K can also encoded usin (hP, Qi) , equality h (P), 0variables, In general the abstract refactoring hP , in be precise abstract abstract domain can express of2 (Q)i values isbethe =) q ) Q ~g has changed variables that is1R2i(:J~ g K)Th. , ~v10 , ~v 1.will 8x 2 ~gnot : ~v 0 (x) = ~vthe (x); most ~gcc has variables changed that 1is contract g2 K) , of~vrefac,~v . 8x 2 ~which g : ~v 0 (x) = ~vcase (x); of mo R 2 (:J~ S0 0 M(~ S 2 ~ . . 4. The unary abstract predicates P 2 AJ~ v K can be embedded into BJ~ v , v K as " (P) such that " 2 AJ~ v K ! 0 0 ~ 2 Remark 4 The hypotheses 1(1), 1(2), and 1(4) amount to the use of only one abstract domain BJ~ v , v K by 0 ~ auxiliaryproduct variables, which is often done 2when procedures with a relational ~V rule Lem. 31I ¯ P(P)(~ ¯ M(~ ¯ cc cc ~J~ 0 abstract 0 0 0 analyzing 0⌅ ~v K and ~v )are BJ~v ,8P 2 v: K8~ : v8~ v hold 22V vgeneral. Kv : K2 (": of (P))(~ v ,(P))(~ = iv (P)(~ ). =possible ⇣J~ reduced of least one 1several does not in There reasons. q0 ). ) ¯abstract BJ~v , ~v K and 2 8P AJ~v K The ,,~v~vquence (" vvthe )=) vcode 1 abstracting predicate abstraction extended contracts hC vx.K, abstract =)i auxiliary as domain. hAJ~v K ⇥ BJ~v2 , ~vsym K, 0 ,Q hP, Qi1xv 2= hP i requirement ,isdomains P v P including ^to" 1 (P )11.4(4), uxatQ v ccQJ~ 12 SAJ~vis 1.AJ~ The abstract projection hP Q of,predicates abstract contract . P(~v 0 )⌘ into2version 2 This 1SR20, JSK ~v S unary P selected by Pthat abstraction of be~v⇣embedded BJ~ 1(3) that the toring. So the abstract requirement 15.3(4), the the concrete x, Q for where 2. abstract transformer Funary S predicates 4. The unary abstract 2⌘ AJ~v1 K can be embedded into BJ~v , ~v Kvariable as "1 (P) s 4.02The abstract K can BJ~ vv, ,~v~vKK.asMoreover (P) such thatexpress vpredicates Kall !formalP parameters 0 is an 0" 2 0assumption 1 2 0AJ~ 0 0 gvK)into 20~ Q 2 Hsince (" (P ) P2u K) u22variables, :J~ Q by"of 15.2(1-1d) abstract conse2 v,~ 2gvalues ~vPS.8P v K and 8P 2"~pall AJ~ v#PKabstract v~vdomain 2 V J~v 8~Ku :, ~v:J~ (P))(~ =vis(P)(~ vu1Hyp. ).QBJ~v0relational ~p :\~ \~gP, g8~ S0case 2 v). , 0~ 0 ,~ 0 ). express of which most domains orand 0that value of actual parameter, 12v(P)(~ ~v ~(" We assume2that "BJ~ that is for 2BJ~ AJ~ v1KK, vcan implies 0,and 2J~ ~v2 the ,u and 8P 2also AJ~ v2that K, ::J~ 8~ v[20]. 2V vdomain KQ: 2 by ("21BJ~ (P))(~ v )15.2(1-1d) =also 5K :J~ Notice the abstract v , ~vv K0 ,~can bevencoded usina 2 the v ,. AJ~ v K S: equality vpossible 22" V J~ v1K reasons. :v of vg , ~v# )~p=\~g21(" ).S ) of 2 Remark 1 (P)(~ 2"(" Qi) hvsee Hsince " (P g K) u g K Hyp. and 1 is increasing 10(P) 1 (P cc (hP, 1 (P), 2 (Q)i 1 (P))(~ 2 does not hold in general. There are several ~ p \~ S S 1 1 2 reduced product of abstract domains including least0abstract one abstract cc We assume that thatthe isabstract for all P, 2that AJ~ vishP K, P Qvthat implies that "v1domain. (P) "most (P(P)assume ).precise 2is often done 0when analyzing 0 0with a relational 0 0 R "1 is increasing variables, which procedures 1. In general projection hPassume Q the code contract 2 rule of Lem. 31I 0at P, 0v that ccthat0 "2abstract cc P v P implies that "2 ( 2. abstract transformer FSP 0 increasing 0 contract 0 0 AJ~ 1auxiliary refactoring iPin Th. 10 will not the refacS i"21of R, JSK is for P ccQ2J~ K, We increasing is for all P rule 2of AJ~v of P1be implies "21We v 27 "21 (P ). is,2increasing. Rv, selected RDef. 2 1 quence 3. The The is noquence most abstraction for (11-a) This predicate abstraction isformal hC vx⌅ as hAJ~v K variable ⇥ BJ~v , ~vsym K, hP, Qi hP i all, P "v2that P(P ^tois "21contracts (P )all ux P, Q v .0K,vis=)i Lemma assumption xvcc= where an auxiliary We assume that "21precise is increasing that forinabstract all P, P 2BJ~ AJ~ vK can K,K,ccPPLem. v P31Iimplies that "x011Qfor (P) v2extended ). 2 . alsois 1parameters Remark Notice that the domain v , ~vBJ~ be encoded using AJ~ vthe K 1by introducing Remark 4 The hypotheses 1(1), 1(4) amount to.5the use of only one abstract domain v , ~valso K version by toring. So 1(2), the and abstract requirement 15.3(4), that is the abstract of the requirement 11.4(4), value ofconcrete actual parameter, see [20]. 1. The abstract projection hP , Q i of the selected code abstract contract cc Qi) , 1(1), h 1 (P), Proof Sv4R Shypotheses cc (hP, 2 (Q)i 0, ~ 0JSK auxiliary variables, which isK. often doneand when analyzing procedures with a relational domain with the initial Remark 4 The hypotheses 1(2), and 1(4) amount to the use of only one abstra 2. The abstract transformer F . ~ Remark The 1(1), 1(2), 1(4) amount to the use of only one abstract domain BJ~ v , v K by ~ ~ abstracting unary predicates P by abstraction of v v P(~ ) into BJ~ v , v Moreover 1(3) express that the 3. The ishold no most precise abstraction for v, possible in Def. (11-a) of 0 0 ccnot cc 0 ccv 0. P(~ 0 ) into BJ~ Theorem 11 (Most precise abstract Assume hypotheses 10 moreover, 0an 0predicates 0 and, 0 ofthe does not in general. There several reasons. In general theand abstract refactoring hP Q irefactoring) Th. 10 be most precise abstract contract refacassumption xare = xpredicates forcontract all R formal parameters x the where x.0P(~ isvabstract auxiliary variable symbolically the abstracting unary by vv, abstract K. BJ~ Moreove 0to In refactoring hP ,1(3) Q ivcccc denoting in 10 will be most precise ~v 0one ~v will abstracting unary Puse by abstraction of ,abstract ) into BJ~ v , ~vthe K. Moreover express that the hP, QiR hP Q Rgeneral This predicate abstraction as hAJ~ K~v ⇥ v , ~v K, ~v,,Th. Remark 4 abstract The hypotheses 1(1), 1(2), 1(4) amount the ofin only domain BJ~ v ,isof K0Th. RhP, Qi v hP Q ii by ,is Pextended P vabstraction P not ^to"21contracts (P ) u Q~vhC v,~ QJ~v.K, v=)i Lemma 27 increasing. domain can express equality of values of variables, which is the case of most relational domains or 2 cc domains 0 domain 0 value of theJSK actual parameter, see [20].ofamount can0 express equality of values of which is the case of mos 2 domain ccequality abstract domain can express of variables, which is theof caseonly of abstract most relational ~vthe Remark 4 abstract The hypotheses 1(1), 1(2), and 1(4) toisthe use one abstract BJ~ vvariables, ,of Ktheby R 2. transformer Fabstract R () P v that P then ^ "21 (P )the u requirement Qor vabstract Q Q i satisfies 0, ~ 0 )toring. Sovalues the abstract requirement 15.3(4), isabstract version concrete require toring. So the abstract requirement 15.3(4), is the abstract version of the concrete 11.4(4), thatThe F JSK isincluding the most precise abstract transformer, that satisfies Hyp. 3(b’) hP , of abstract domains at least one . .ofdomain. 2 Rby R Qi) , h 10(P), reduced product of domains including at least one abstract domain. 3. The is no most precise abstraction for vinto inthat Def. (11-a) of ~ R ~ abstractingreduced unaryproduct predicates P abstraction of v v P(~ v BJ~ v , v K. Moreover 1(3) express that the cc (hP, 2 (Q)i Proof reduced product abstract domains including at least one abstract domain. Theorem 11 (Most precise abstract contract refactoring) Assume the hypotheses of Th. 10 and, moreover, cc 0 0 2 cc 0code 0 ) into cc 2 ccabstract ˙ ˙ 1. The abstract projection hP , Q i of the selected contract =) (P ) =) (P) ^ (" (P ) u Q) =) (Q ) H ~ 1 1 2 2 ~ ~ cc abstracting unary predicates P by abstraction of v , v P(~ v BJ~ v , v K. Moreover 1(3) express that the ~ 0 0 This predicate abstraction is extended to contracts hC J~ v K, =)i as hAJ~ v K ⇥ BJ~ v , v K, vi where does not holdreasons. in general. There are several possible 1 0 cc S are S several 0 reasons. 0 0 0 does equality not requirement hold in general. There cc possible abstract 15.3(4). hP,domains Qi0Notice vcchPis,also Q i that , the P 2abstract v P ^ "21domain (P ) u QBJ~ v Q, ~v0 .2 abstract domain express ofdomain values which is the of most encoded relational Lemma increasing. Remark 527 ~vintroducing ˙ introducing ˙ 2v(Q Remark 5 Notice that domain v ,of K can using K )3by () (AJ~ (P =) ^or ))K can also be encoded using ~vequality Remarkcan 5 Notice also that abstract BJ~ vof ,abstraction Kvariables, can also also befor encoded using AJ~vcase K BJ~ by that F JSKno ismost the most precise abstract transformer, that is satisfies Hyp. 3(b’) then hP i^˙ satisfies the 3. The is precise vthe inabstract Def. (11-a) 10(P)) 2 (" 2 (Q) =) 01v 0Q 1 (P)) Rthe Risv( ,10 cc also be is abstract domain can express of values of variables, which the case of domains or Theorem 11 (Most precise abstract contract refactoring) Assume hypotheses of Th. and, ,is often h 1 (P), . the . () P vvariables, P ^ most "12 (P ) (11-a) u Qrelational Q0 R auxiliary which often done when analyzing procedures with cc (hP, Qi) 2 (Q)i 0 with 0 moreover, 0 a relational auxiliary variables, which done when analyzing procedures with a relational domain the initial 0 0 . with a ˙ 1 (P)) ˙ 2 (Q )) auxiliaryof variables, which is often done when analyzing procedures relational domainprojection with the initial ~v ,~v0 . 1 (P contract () ^ ( abstract )(~v ) ^ 02 (Q)(~v ,~v ) =) 2. The abstract transformer F.R, JSK Proof 1. The abstract hP the( selected code 1 (P0 ) =) reduced product abstract domains including atdomains least one abstract domain. S, Q S i of abstract requirement 15.3(4). cc assumption x ˙=denoting x01 (P) for all 22 formal parameters where auxiliary variable sym 0 for 0 all 0 0x is an auxiliary ˙ x2 (Q 2 0 code 1. The abstract projection hP Q of contract assumption xv = formal x one where variable symbolically =) ("21 (P ) x02is an H 0Q 0 ) u Q)0 =) 1 (P ) =) cc cc 0 0 ^ the reduced product of abstract SQian Sxi,including hP i the ,variable Pselected v parameters Pat ^symbolically "least v Qabstract .0is satisfies (11-b) 2 assumption x = x0 Theorem for allF formal parameters xprecise where xhP,abstract is auxiliary denoting the domain. 1 (P ) u Q that is(Most theabstract most precise abstract transformer, that Hyp. then hP Q the () hhP, (P), (Q)i ),2 [20]. (Q satisfies )i moreover, Qi vcc2hP , Q=) i hR1,(P value of1the parameter, see 2i contract Assume the hypotheses of Th. 10 and, 0 actual 0 R JSK11 R Lemma 27 cc value 0of the0actual parameter, see [20].refactoring) ...3(b’) 2 ... ˙ is 1ccincreasing. ˙ 2 (Q )) () ( 01 (P ) =) ^˙ 2 (Q) =) cc 65 0 0(P)) ^ ( 20(" 0 1 (P)) 2 value of the actual parameter, see [20]. 2. The abstract transformer F JSK 2R v () Pcc v(hP, =)) u ccQ(hP P "1 (P v Q, 0 Q i) 0 ^Qi) 0 0 abstract requirement 15.3(4). 3. The is no most precise abstraction for v in Def. (11-a) of 0 0 cc ˙ cc cc ... 2 cc . cc Proof ˙ ~v2 Q () ( where (P0 )then =) ^R ,~v0 i1to (P )(~v ) ^ hC ) =)as hAJ~ predicate abstraction is( ,extended contracts J~ vvK,,~v=)i K ⇥ BJ~v , ~v K, v 2. R The transformer F RvJSK 1introducing 1 (P)) 2 (Qv )) F JSK is the most precise abstract transformer, satisfies 3(b’) hP satisfies the 02 (Q)(~ ~v K canisdomain Remark 5 Notice the abstract domain BJ~ ,abstraction also tobe encoded using vvencoded K, ~vThis This the predicate extended contracts hC K, =)i as hAJ~v KAJ~ ⇥Hyp. BJ~ K,by vi cc ... ˙ introducing 13 . also . that ~vccKJ~v is =) ) =) (P )Ruisby Q) =) ) H cc˙ Remark 5Rabstract Notice also that BJ~ v65 ,that can also be using 01 (P)cc 0 ^ AJ~ 0 K 2 ("1v 2 (Q cc The1 (P finite meet-preserving to0 avoid the problems explained in the forthcoming examp ccabstract Lemma increasing. cc Qi v 2hP , Q=) i h 2hypothesis () cc (P), (Q)i (P ),2 2 (Q )i 0 Def. 0 ThishP predicate abstraction extended to contracts hCanalyzing J~v K, 27 =)icc asis procedures hAJ~ vK ⇥ v , ~v is K,with vi S ,Q S i abstract 3.ccBJ~ The no where most precise abstraction vh(hP,01in (11-a) (hP, Qi) ,(1 hof requirement 15.3(4). ˙2 (Q)i cc^ ˙ initial ˙ auxiliary variables, which is isoften done when a relational domainfor with 2 () (P the )cc=) ("01 (P), (P)) (Q) =) (Q )) 0(P)) ^ 2
1
2
.
analysis, or, preferably, both of them. Knowing the concrete transformer FR JSK defined by structural induction on S, the design of an abstract transformer F JSK is classical in abstract interpretation [11].
hPS , QS i
2
2
.
1
1
2
1
2
1
2
2
1
2
2
2
2
2
2
2
1
Best iterated solution The iterations of F JSK provide a sound appoximation of the concrete fixpoint: Theorem 19. Equations (25) and(26) imply that cc cc =⇒ gfp . . FR JSK =⇒ γ gfp F JSK .
1
1
.
2
1
1
.
1
1
2
2
2
1
1
2
2
1
2
2
2
2
2
2
(hP, Qi)contract , h 1 (P), 1 1 (11-a) 20 1 0and, 2 moreover, 2 (Q)i Theorem 11 most (Most precise abstract refactoring) Assume with the hypotheses of Th. auxiliary which isabstraction often done when analyzing procedures a relational domain the2 initial P v(hP, P "21 (P Q(hP v 10 Q, 0 Q i) with () =))0 u 0 ^Qi) 0 00 0 Proof 0 0 3. Thevariables, is no precise (11-a) of cc 0 for v 0in Def. 0 0 ˙ 0 , 1Q(P)) ˙ ()hP, ( 1 (P ^,( ~P v ,~ )(~v ) )u^Q 02v(Q)(~ (Q )) Qi0 )v=) hP i the vv0 .P ^1 (P "21 (P Q51v. ,~v ) =) 0i , 65 assumption x = x0ccfor all parameters where x00,, QQis an variable symbolically denoting hP, hP Pauxiliary vx P ^where "21 (P Qx v Q is . an (hP, Qi) formal (Q)i (11-a) ˙ symbolically ˙ the2the =) (P ) ω =) ^ 2hypothesis ("21 (P uisQ) =) (Q ) hypotheses H 1x(P), 1 (P)(11-b) assumption =is 2xthe allxprecise formal parameters auxiliary variable denoting the in the2 forthcoming 0Q) Assume Theorem 11) u(Most abstract contract refactoring) of Th. 10 hP, Qi Qiωv v hP 0 i The1 finite then meet-preserving to0satisfies avoid problems explained exampa 0 for 0 precise that ,F RhJSK most abstract transformer, that is satisfies Hyp. 3(b’) hP , i the R () h (P), (Q)i =) h (P ), (Q )i R 0 0 1 2 1 2 2 cc ˙ 1Hdef. ˙ 2 (Q )) 0 0 0 [20]. 2 0 0 0 v P ^ "2 (P0 ) u Q v Q0 () ( 1 (P ) =) ^vI( 20("1 (P)) ^˙ 2 (Q) =) 0 of theover-approximation actual see In general F R JSK may value be any of Theorem abstract contract the hypotheses of(P))Th. moreover, 210 actual [20]. 1 hP, Qiparameter, v value hP , Q iof,the P requirement v11 P ^(Most "1parameter, (P ) uprecise Q v() Q .Psee (11-b) abstract that0 F Rrefactoring) JSK is 65 the mostAssume precise Hyp. 3(b’) ()transformer, (hP, (hP , 0is Q and, i)satisfies 2 then0 hPR , QR 0 Qi) =) that 0 abstract 15.3(4). 0 0 2 0 0 . ˙ is increasing. ˙ 2 (Q )) () ( 127 (P )are =) v ,~v 1 (P )(~v ) ^ 2 (Q)(~ 51v ,~v ) =) 1 (P)) ^ ( ~ ˙ 1 (P) ^ 2 ("21 (P ) u Q) =) ˙ 2 (Q ) Lemma =) 1 (P ) =) H 1 and increasingI 2 Lemma 270 abstract is increasing. abstract requirement 2 The finite meet-preserving hypothesis avoid the problems explained in the forthcoming examp that F R JSK is the most precise transformer, that0 is15.3(4). satisfies Hyp.() 3(b’) then hP , 0Q isi to0satisfies the FR JSK. Therefore it may not ensure that 1 (P), 2 (Q)i =) cc cc hR1 (P ), R2 (Q )i ˙ 1 (P)) cc ˙ 2 (Q )) cc () ( 1 (Pcc ) =) ^ ( 2 ("12 (P)) ^˙ 2 (Q) cc =) H h2 is meet-preservingI Proof 0 0 Proof ~ 0 J~ 0 0 This predicate abstraction is extended to contracts hC v K, =)i as hAJ~ v K ⇥ BJ~ v , v K, vi where ~ This predicate abstraction is extended to contracts hC J~ v K, =)i as hAJ~ v K ⇥ BJ~ v , v K, vi where () (hP, Qi) =) (hP , Q i) 2 0 0 abstract requirement 15.3(4). cc ˙ 0 1 (P)) ˙ 2 (Q )) () ( 1 (P ) =) v 0 , ~v . 1 (P )(~v 0 ) ^ 2 (Q)(~v 0 , ~v ) =) 0 ^( ~ hP, Qi v hP , Hdef. Q i "1 I 51 2 65 Lemma 27 cc is increasing. hP, Qi v hP , Q i 2 0 0 0 0 0 ˙ is to avoid the problems explained in the forthcoming examp ˙ Q i, × () h 01 (P), 2 (Q)i0 =) h 1 (P0 ), 2 (Q )i Hdef. 65 () The P vfinite P ^meet-preserving "21 (P ) u =)I Q vhypothesis Q h>, gfpv . . F R JSK v () Ph v P(P), ^ "21 (P ) u (Q)i QvQ Hdef. vI m 0 0 0 0 0 (hP, Qi) , (11-a) 2 , h 1 (P), Proof (hP, (hP , Q0 i) cc 10 Qi) =) Figure 4.2 Absence of0 most precise abstraction of ˙Hdef.1(11-a) ˙ concc (hP, Qi) 2 (Q)i () =) 1 (P ) =) (P) ^I 2⌅ (" (P )the u Q) =) H 1 hP S , QS i 2 (Q ) ˙ 1 (P) ^ 2 ("21 (P ) u Q) =) ˙ 2 (Q ) =) 1 (P ) =) H 1 and 02 are increasingI 1 51 cc 0 0 0 65 0explained in the forthcoming example ˙ 1 (P)) ^ ( 2 ("21 (P)) ^˙ 2 (Q) =) ˙ 2 (Q )) () (20.1 (P ) =) H 0 meet-preserving hypothesis The finite the problems 0 0 cc hP, Qi 0 v hP 0 , Qi 0 cc 0˙ 1 (P)) ^2 ( 2 ("0 21 (P))is ^to˙ avoid ˙ 0 2 (Q )) ( 10(P ) contract. =) H 2 is meet-preservingI 2 (Q) =) crete 2 i 0 ,() 0 0 0 0 0 0 hP, Qi v hP , Q P v P ^ " (P ) u Q v Q . (11-b) cc 0 0 0 . ˙ (11-b) ˙ 2 (Q )) () ( 1 (P ) =) v ,~v 1 (P )(~v ) ^ 2 (Q)(~v ,~v ) =) hP, requirement Qi v hP , Q 2i (b) , – P safety. v P ^ " (P ) u Q v 0Q . 1 0 0 0 1 (P)) ^ 2( ~ i.e., it does not satisfy the abstract 0 0 cc
cc
cc cc
1
2
1
2
2
cc
2
cc
2
cc
1
13
2
2
2
cc
cc
1
2
1
2
2
cc
cc
cc
2
cc
13
cc
cc
cc
cc
cc
cc
cc
cc
cc
13
1
1
cc
cc2
2
2
2
cc
cc
cc
2
2
13
() P v P ^ "1 (P ) u Q v Q 1
1
2
1
2
2
2
1
2
2
˙ () ( 1 (P ) =)
1 (P))
^ ( ~v , ~v
.
1 (P 0
)(~v ) ^
v 2 (Q)(~ 51
˙ vI , ~v Hdef. ) =) 2 (Q ))
() h 1 (P),
Hdef. 0 cc "1 I =) cch 1 (P ),
2 (Q)i
2 (Q
0
)i
0 0 0 Hdef. =)I ˙ 1 (P) ^ 2 ("21 (P ˙ 2 (Q ) () h (P), (Q)i =) h (P ), (QH )i1 and 2 are increasingI ) u the Q) =) In order to guarantee that the limit =) of the iterations of 1 (P ) =) () (hP, Qi) =) (hP , Q i) 0 0 Hdef. I ˙ 1 (P)) ^ ( 2 ("21 (P)) ^˙ 2 (Q) =) ˙ 2() () ( 1 (P ) =) (Q )) (hP, Qi) =) (hP , Q i) H 2 is meet-preservingI abstract transformer is a correct solution to 0EMC we need the 0 0 F R JSK satisfying (26) ˙Lemma ˙ 2 (Q )) the abstract transformer ~v 0 , ~v .cc 1 (P ~v ) =) () ( (P ) =) v 0 ) ^ 2 (Q)(~v 0 , Second, Hdef. "21 I is )(~ increasing. 1 (P)) ^ (27 Lemma 27 cc 1 is increasing. 2 0 0 additional requirement: 51 () h 1 (P), 2 (Q)i =) h 1 (P ), 2 (Q )i Hdef. =)I one. This situation can be 51 might not be the most precise 0 0 Proof ˙ (hP,˙ Qi) () =) (hP , Q i) Hdef. I × ⌅ Proof Y i) v h>, Q i ∀hX, Y i : F R JSK(hX, (27) avoided by requiring the abstract transformer F JSK to be 1
2
cc
2
0
1
cc
cc
cc
0
2
0
cc
cc
cc
13
13
0
cc
0
⌅
The finite meet-preserving hypothesis is to avoid the problems explained in the forthcoming exampl The finite meet-preserving hypothesis is to avoid the problems explained in the forthcoming example 20.
cc
2
cc
cc
cc
m
cc
0
cc
cc
0
R
hP, Qi v hP , Q i
0 meet-preserving 0 The finite hypothesis is to avoid the problems explained in the forthcoming example 20.
13cc
the0 most precise abstract transformer, in which case (26) must cc This requirement can always a given 2 0 cc Q Hdef. vI 0 2 0 () P v0 P ^ "1 (P ) u Q v 51 strengthened into: be () P v P ^ " (P ) u Q v Q Hdef. vI abstract transformer F R such that the postcondition 0 is no 0 1 2 0 ˙ ˙ =) 1 (P ) =) (P) ^ (" (P ) u Q) =) (Q ) H and are increasingI 0 0 0 1 2 2 1 2 ˙ 1 (P) ^ 2 ("21 (P0 ) u Q) =) ˙ 2 (Q1)F2R JSK ◦ γcc = γcc0 ◦ F R =) 1 (P ) =) H JSK weaker than Qm : (30) 1 and 2 are increasingI ˙ hP, met Qi v by hP , refining Qi be 0 1
1
2
2
2
2
2
2
0
˙ () ( 1 (P 2) =)
1 (P))
^ ( 2 ("1 (P)) 0 ^
2 (Q)
˙ =)
2 (Q
))
H
2
is meet-preservingI
0 1˙ 2 2 2 0 0 ˙ 1 (P)) ˙ 2 (Q projection hP))S , QS i (cf. (25)) might λ hX, Y i . F R JSK(hX, 1Y i) Qm(i.12(P01) =) (28) ^ ( ~v 0Third, , ~v . 1 (Pthe )(~v abstract ) ^ 2 (Q)(~ v 0 , ~v ) =) Hdef. "21 I 0 u h>,() 0 0 ˙ 1 (P)) ^ ( ~v 0 , ~v . 1 (P )(~ ˙ 2 (Q )) () ( 1 (P ) =) v 0 ) ^ 2 (Q)(~ v 0 , ~v0 ) =) Hdef. "21 I 0 cc cc be too approximated. This can be excluded by requiring the () h (P), (Q)i =) h (P ), (Q )i Hdef. =)I 1 0 2 1 2 With the extra requirement (27), the iterative application 0 cc cc 0 0 cc () h (P), (Q)i =) h (P ), (Q )i Hdef. =)I 1 2 2 . . abstract projection ↓~p\~g to be the most precise possible.Hdef. cc I ⌅ () 1cc 0(hP,0 Qi) cc of F R from hP S , QS i provides a correct solution to EMC:=) cc (hP , Q i) () cc (hP, Qi) =) 13cc (hP , Q i) Hdef. cc I ⌅ The finite meet-preserving hypothesis is to 21 avoid(Most the problems explained in the forthcoming 20. Theorem precise abstract contractexample refactoring). UnTheorem 20. Let F R be an13 abstract transformer satisfyThe finite meet-preserving hypothesis is to avoid the der problems explained in the forthcoming example 20. the hypotheses of Th. 20 and of this subsection (including (25), (26) and (27). Then cc ing (30)), hP R , QR i51also satisfies the abstract requirement (29) hP R , QR i , gfpv . . F R JSK (d) –51 generality. hP , Q i ˙ × ˙ () ( (P ) =)
S
(P)) ^ ( (" (P)) ^˙
˙ (Q) =)
cc
Equation (29) ensures that hP R , QR i v hP S , QS i, i.e., the result of the fixpoint computation is a more precise contract than the trivial solution consisting of projecting the pre-state and post-state of the selected code. .
.
Most general abstract contract refactoring In general the abstract refactoring hP R , QR i in Th. 20 is not the most precise abstract contract refactoring — the abstract requirement (d) – generality does not hold in general. There are three possible reasons for that. First, there is no most precise abstraction of the concrete cc solution of Th. 10 or 11 for v in Def. (18) of γcc a case illustrated in Fig. 4. This can be remedied, e.g., by requiring: (i) γcc to be the upper-adjoint of a Galois connection — equivalently γcc is a complete meet morphism; and (ii) the α is to be surjective — equivalently γcc is injective — to avoid a redundant representation in the abstract of the same concrete property: γ1 1 −−→ − −− hAJ~vK, vi hPJ~vK, =⇒i ˙ ← −− −→ α1 γ
Paper
H
. is . meet-preservingI
S
satisfies the abstract requirements (a) – validity, (b) – safety, and (c) – completeness.
2 −−→ −2−− hBJ~v, ~vK, vi hPJ~v, ~vK, =⇒i ˙ ← −− α−→ 2
(Q ))
16
The best abstract transformer condition of (30) is rarely met in practice. A consequence is that the abstract requirement (d) – generality is mostly of theoretical interest. However, experience in Sec. 14 shows that abstract completeness is achieved in many cases.
Iterated Solution with Convergence Accelerators The underlying abstract domains A, B may not satisfy the Ascending/Descending chain conditions. As a consequence a narrowing operator [11] should be used to enforce the convergence of the greatest fixpoint computation of (29) to an (over-) approximate solution hP R , QR i. The greatest fixpoint iteration with narrowing ensures that cc
cc
hP R , QR i v hP R , QR i v hP S , QS i . .
.
(31)
We need to prove that hP R , QR i is effectively a solution of EMC, and therefore it can be used in practice. This is guaranteed by the following theorem: Theorem 22 (Correctness of the approximate abstract contract refactoring). In addition to the hypotheses of Th. 20, let hP R , QR i be satisfying (31) and QR v2 Qm . Then hP R , QR i satisfies the abstract requirements (a) – validity and (b) – safety. 2013/10/25
Roslyn exposes the (C# and VB) compiler internals (syntax trees, object model, data-flow analyses, refactoring, etc.) to external developers, so that they can develp new plugins (code analyses, refactorings) on top of it. CCCheck is a static contract verifier for CodeContracts. It analyzes each method in isolation, assuming the precondition and asserting the postcondition. CCCheck can also do backward analyses to infer a precondition from the postcondition. CCCheck is based on abstract interpretation and hence has more advanced inference capabilities than similar tools. For instance, it infers loop invariants and it suggests method preconditions and postconditions (the hP m , Qm i in this paper). CCCheck contains several abstract domains for the heap, non-nullness, numerical properties, array contents, enums, but also to track (simple) existential and quantified properties [20]. Most of these abstract domains use widenings so completeness cannot be guaranteed in the theoretical sense for tortuous counter-examples and the contracts cannot technically be the most general. The benchmarks ran with the default settings show that the inferred contracts can hardly be improved manually for the abstraction used by the static analyzer.
/* P S : pre-state, S:refactored code, ~p: variables potentially used in S, ~g: variables definitely unmodified by S, QS :post state such that ¯ P S ¯ S|~p\~g ¯ QS ¯ holds. */ RefactorContract(P S , S, ~p, ~g, QS ) {
1 use hAJ~pK, u, ∆1 i // precondition abstract domain 2 hBJ~p, ~pK, u, ∆2 i // postcondition abstract domain post // forward analyser with widening/narrowing
f // backward analyser with widening/narrowing pre
// abstract projection on potentially used variables ~p hP S , QS i = h↓~p\~g (P S ), ↓~p\~g (QS )i; .
.
// infer a correct safety abstract contract Let P m be the abstract safety pre-condition for S computed by the static analysis [18]; Qm = postJS~p KP m ; // forward abstract static analysis // ¯ P m ¯ S|~p\~g ¯ Qm ¯ holds hP R , QR i = hP S , QS i; do // compute hX, Y i = F R JSK(hP R , QR i) .
.
f ~p KQR ; // backward analysis X = P m u1 P R u1 preJS Y = Qm u2 QR u2 postJS~p KP R ; // forward analysis
hP R , QR i = hP R ∆1 X, QR ∆2 Y i; // narrowing while hP R , QR i = 6 hX, Y i; cc
// gfpv
. . hP S , QS i
}
cc
cc
F R JSK v hP R , QR i v hP S , QS i holds .
.
return hP R , QR i; // (a) – validity & (b) – safety hold
Algorithm 5. Algorithm EMC (Extract Methods with Abstract Contracts) computing an approximation of a greatest fixpoint with convergence acceleration. Th. 22 states that all the abstract contracts included between the best solution (29) and the abstract projections of the abstract states are a solution of our problem. A natural way to compute hP R , QR i is to perform the downwards iterates of . . F R JSK from hP S , QS i with narrowing. The algorithm EMC is given in Alg. 5. An optimization using chaotic iterations with memory [8] would have Y = Qm u2 QR u2 postJS~p KX; // forward analysis This is the solution we implemented, with more details given in the next section.
14.
Experience
The underlying tools We implemented the algorithms of the previous section on top of two industrial-strength tools, Roslyn and CCCheck. Paper
17
The implementation We preferred not to implement ourselves the syntactic extract method from scratch. We used Roslyn, which takes care of both the user interface (e.g., code selection, right click, previews, etc.) and the basic refactorings. Furthermore, we did not wanted to try our examples on toy implementations or abstract domains, hence we (modified and) used CCCheck to implement the EMC algorithm. CCCheck runs as a background service in Roslyn. While Roslyn provides syntactic, source-level, ASTs, CCCheck analyzes bytecode. Therefore there is some (non-trivial) glue code connecting the two. The extract method with contracts is implemented as a Visual Studio extension for C#. When the user selects a piece of code S, Roslyn in the background (and concurrently), invokes the extension asking it to provide a refactoring, if any. Our extension first forwards the call to the refactoring engine of Roslyn. If no method is extracted from the selection (e.g., not all the branches of S are terminated by a return statement), the extraction fails, and we stop there. If the extraction succeeds, then we generate a contract for the new method. . . The first step of the algorithm EMC is to deduce hP S , QS i, the starting point for the greatest fixpoint computation. In theory, this information can be obtained by fetching the program points corresponding to the user selection, and then asking CCCheck for the corresponding invariants and Roslyn for S|~p\~g . Unfortunately there are some practical issues that complicate the theoretical schema. First, CCCheck does not keep an explicit map from source locations to bytecode offsets, but only the inverse map, used to report warnings and suggestions. Second, for memory consumption reasons, CCCheck throws away the inferred invariants once it is done with the 2013/10/25
analysis of a method. So at the time the refactoring is invoked, that information is already gone. Third, because of the heap analysis, the mapping between source level variables and internal variables used by the abstract domains in CCCheck is pretty complex (e.g., the same syntactic variable may have different internal names at different program points). Luckily, the refactoring engine of Roslyn indirectly provides the partition h~p, ~gi and the information on modified variables via the parameters. Roughly, the actual parameters are the variables read/written in S, and the actual parameters passed by ref are those that may be modified in S and whose value may be used in the callers. Our solution is then to use two dummy method calls as markers for the precondition and the postcondition, inserted, respectively, at the beginning and at the end of the selection. The first marker, the precondition marker, is a fresh method call whose actual parameters are the variables in ~p that can be modified inside S. For the other variables in ~p, we have the guarantee that their value either does not change or does not affect the method on return (i.e., they are dead variables). The second marker, the postcondition marker, is a fresh method call whose actual parameters are as above plus an extra one denoting the return value. Example 23 (Markers). For the initial example in Sec. 2, the annotated code is: __PreconditionMarker(); while (x != 0) x--; __PostconditionMarker(x, true); The Boolean flag indicates whether or not the next-to-last parameter is the variable the return value is assigned to (refactoring may generate void methods, in which case the flag is false). When the Boolean flag is set, then all the . occurrences of the next-to-last variable in QS are replaced by Contract.Result, i.e., the return value of the method is made explicit in the postcondition. We then analyze the annotated method with a switch to . . trigger the generation of hP S , QS i: CCCheck analyzes the method, collects at the marked points hP S , QS i, and then uses the actual parameters to project them onto the variables . . of interest to emit hP S , QS i. The second step of the algorithm, inserts hP S , QS i for the extracted method, and then runs CCCheck to infer hP m , Qm i. In the third step, we add hP m , Qm i (to enforce (27)) to the extracted method and we iterate the forward/backwards schema until we reach a fixpoint, or we run out of stamina, in which case we return the current approximation — this never happened in our experience, though. Finally, we instrument the extracted method with hP R , QR i, and we propose it as a refactoring to the user, e.g., Fig. 1. Benchmarks It is very hard, if not impossible, to evaluate automatically the effect of the extract method, as it depends on user interaction. A random selection of S is not very meaningful either. It is very likely to generate ill-formed programs, and it may not be representative of the effective use. Furthermore, in order to evaluate our analysis, we Paper
should first fix what we evaluate. Our goal is to have the extract method with contracts integrated in a continuous verification (or semantic) IDE. As such, two metrics are relevant: (i) performance (the analysis should happen in real time); and (ii) precision and generality of the results (no new warning should be introduced, and the result should be as general as possible). We evaluated those two aspects on some benchmarks (randomly) extracted from the CCCheck regression suite. The CCCheck regression test suite contains many corner cases and small, yet tricky, bug repros reported by users in order to stress the analyzer. We report the experimental results in Fig. 6. The first column is the name of the test. The second column contains the time required for Roslyn to extract the method. The third . . column is the cost of step one (inference of hP S , QS i) and the fourth column is the combined cost of steps 2 and 3 (inference of hP m , Qm i and hP R , QR i). The last column is the total time taken by the extract with contracts refactoring. Note that the total is slightly larger than the sum of the other three columns because it also includes the cost of annotating the syntax trees, context switching, etc., due to multithreading. The tests are not very long per se, but rather complex, as can be noticed by the raw time spent by the optimized refactoring engine to perform the syntactic method extraction. In general, the cost of our analysis is comparable with that of the extract method alone. In most of the cases, the total time remains well below one second, meeting the first requirement (real time). The only real slow-down is in the Loop-2 test, which is caused by the overhead of using exceptions as control flow in the analysis for certain corner cases. This idiom causes an extreme slowdown while running with the debugger attached, which was the easiest way for us to record the timings. Without the debugger attached, the wall-clock time improved dramatically. In all of the tests we succeeded in extracting a contract which was both precise enough to not break the verification of the caller and general enough to be used elsewhere. We were positively impressed by the inferred invariants. For instance, for BeyerEtAl (Fig. 1 of [5]), we selected the body of the loop. The extract method with contracts was able to infer the right pre- and post-conditions (3*i = a + b), generalizing it for non-negative values of i, a, and b but also restraining i to be less than 231 − 1 (otherwise an overflow may occurr). In the PeronHalbwachs example — computing the max of an array (Fig. 1(a) of [28]): int Max(int[] a) { Requires(a != null && a.Length > 0); Ensures(ForAll(0, a.Length, j => Result() Result() == a[j])); var max = a[0]; for(var i = 1; i < a.Length; i++) if(a[i] > max) max = a[i]; return max; }
CCCheck infers the loop invariant ∀j ∈ [0, i).a[j] ≤ max and ∃j ∈ [0, i).a[j] = max, and uses it to prove the postcondition. 18
2013/10/25
Test Decrement Generalize BinarySearch Abs Arithmetic Rem Guard Loop Exp Main Karr Loop-2 Loop-3 SankaEtAl [40] McMillan [33] BeyerEtAl [5] PeronHalbwachs [28]
Extraction 0.18 0.20 0.23 0.23 0.20 0.20 0.17 0.18 0.34 0.20 0.35 0.28 0.21 0.24 0.24 0.34 0.47
Step 1 0.10 0.09 0.14 0.07 0.07 0.09 0.07 0.07 0.18 0.14 0.09 0.18 0.10 0.09 0.18 0.18 0.33
Steps 2/3 0.12 0.14 0.32 0.12 0.28 0.20 0.14 0.10 0.24 0.20 0.14 1.99 0.14 0.00 0.43 0.28 0.31
Total 0.42 0.45 0.70 0.43 0.56 0.49 0.40 0.37 0.79 0.56 0.71 2.43 0.46 0.35 0.93 0.82 1.13
Figure 6. The experimental results (in seconds). The additional
cost is of the same order of magnitude as the syntactic method extraction. The precision was good enough in all tests to preserve the verification of the caller and generalize the precondition of the extracted method.
In the benchmark, we selected the body of the loop, and got the following contract: Requires(a != null && 0 max == a[j])); Ensures(Exists(0, a.Length, j => Result() == a[j])); Ensures(a[i]
