An abstract interpretation framework for refactoring with application to extract methods with contracts

Cousot, Patrick; Cousot, Radhia; Logozzo, Francesco; Barnett, Mike

doi:10.1145/2384616.2384633

Cited by 16 publications

(9 citation statements)

References 46 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As future work, we think that proving completeness of static analyses could be also beneficial to: (i) automatically apply abstract code repairs [18]-if the analysis of the original and the repaired programs can both be proven complete, then the repair is very likely to have fixed a concrete bug; (ii) validate refactorings [8]-among different program refactorings one may only keep the one(s) for which she can prove it preserves the completeness of the analysis; (iii) provide a better understanding of why over-approximating analyses of arrays [7] works well in practice even without performing under-approximations, argued as necessary in [15].…”

Section: Discussionmentioning

confidence: 99%

“…Also, one could reason as follows: the assignment x := 9 with a constant is precise with intervals; both Boolean guards x > 0 and x ≤ 0 can be exactly represented with intervals, resp. by [1, +∞) and (−∞, 0]; the decrement operation x := x − 1 on intervals is precise, e.g., [3,9] − [1, 1] = [2,8]. Therefore, one may conclude that this is why the analysis of Dec with intervals is complete.…”

Section: Introductionmentioning

confidence: 99%

“…. , (1,8), (0, 9)}. It is worth remarking that this incompleteness does not originate from a perceived imprecision in the abstract join of intervals: in fact, the abstract lub A of any abstraction A is always complete, meaning that α(X ∪ Y ) = α(X) A α(Y ) always holds-since abstraction functions in Galois connections always preserve joins [3].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Analyzing Program Analyses

2015

Self Cite

View full text Add to dashboard Cite

We want to prove that a static analysis of a given program is complete, namely, no imprecision arises when asking some query on the program behavior in the concrete (ie, for its concrete semantics) or in the abstract (ie, for its abstract interpretation). Completeness proofs are therefore useful to assign confidence to alarms raised by static analyses. We introduce the completeness class of an abstraction as the set of all programs for which the abstraction is complete. Our first result shows that for any nontrivial abstraction, its completeness class is not recursively enumerable. We then introduce a stratified deductive system to prove the completeness of program analyses over an abstract domain A. We prove the soundness of the deductive system. We observe that the only sources of incompleteness are assignments and Boolean tests --- unlikely a common belief in static analysis, joins do not induce incompleteness. The first layer of this proof system is generic, abstraction-agnostic, and it deals with the standard constructs for program composition, that is, sequential composition, branching and guarded iteration. The second layer is instead abstraction-specific: the designer of an abstract domain A provides conditions for completeness in A of assignments and Boolean tests which have to be checked by a suitable static analysis or assumed in the completeness proof as hypotheses. We instantiate the second layer of this proof system first with a generic nonrelational abstraction in order to provide a sound rule for the completeness of assignments. Orthogonally, we instantiate it to the numerical abstract domains of Intervals and Octagons, providing necessary and sufficient conditions for the completeness of their Boolean tests and of assignments for Octagons.

show abstract

Section: Discussionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Analyzing Program Analyses

2015

Self Cite

View full text Add to dashboard Cite

show abstract

“…A proof-preserving approach for the Extract Method refactoring was presented by Cousot et al [3]. It can be used if the old and the extracted method have to be verified.…”

Section: Related Workmentioning

confidence: 99%

Change-Driven Consistency for Component Code, Architectural Models, and Contracts

Kramer

Langhammer

Messinger

et al. 2015

Proceedings of the 18th International ACM SIGSOFT Symposium on Component-Based Software Engineering

View full text Add to dashboard Cite

During the development of component-based software systems, it is often impractical or even impossible to include all development information into the source code. Instead, specialized languages are used to describe components and systems on different levels of abstraction or from different viewpoints: Component-based architecture models and contracts, for example, can be used to describe the system on a high level of abstraction, and to formally specify component constraints. Because models, contracts, and code contain redundant information, inconsistencies can occur if they are modified independently. Keeping this information consistent manually can require considerable effort, and can lead to costly errors, for example, when security-relevant components are verified against inconsistent contracts. In this paper, we present an approach for keeping componentbased architecture models and contracts specified in the Java Modeling Language (JML) consistent with Java source code. We use change-driven incremental transformations and the Vitruvius framework to automate the consistency preservation where this is possible. Using two case studies, we demonstrate how to detect and propagate changes and refactoring operations to keep models and contracts consistent with the source code.

show abstract

“…We use function calls to model unknowns from the environment and imprecision in the static analysis. To simplify the theoretical development, we assume that function calls are (i) black boxes -we cannot inspect their bodies, so they can return any value, and (ii) side effect-free, otherwise do as in [13]. If s ∈ Σ is the state corresponding to a function call (that is, πs(s) = ret = f(arg 0 .…”

Section: Small-step Operational Semanticsmentioning

confidence: 99%

Verification modulo versions

et al. 2014

Self Cite

View full text Add to dashboard Cite

We introduce Verification Modulo Versions (VMV), a new static analysis technique for reducing the number of alarms reported by static verifiers while providing sound semantic guarantees. First, VMV extracts semantic environment conditions from a base program P. Environmental conditions can either be sufficient conditions (implying the safety of P) or necessary conditions (implied by the safety of P). Then, VMV instruments a new version of the program, P , with the inferred conditions. We prove that we can use (i) sufficient conditions to identify abstract regressions of P w.r.t. P; and (ii) necessary conditions to prove the relative correctness of P w.r.t. P. We show that the extraction of environmental conditions can be performed at a hierarchy of abstraction levels (history, state, or call conditions) with each subsequent level requiring a less sophisticated matching of the syntactic changes between P and P. Call conditions are particularly useful because they only require the syntactic matching of entry points and callee names across program versions. We have implemented VMV in a widely used static analysis and verification tool. We report our experience on two large code bases and demonstrate a substantial reduction in alarms while additionally providing relative correctness guarantees.

show abstract

An abstract interpretation framework for refactoring with application to extract methods with contracts

Cited by 16 publications

References 46 publications

Analyzing Program Analyses

Analyzing Program Analyses

Change-Driven Consistency for Component Code, Architectural Models, and Contracts

Verification modulo versions

Contact Info

Product

Resources

About