AutoFrame: Automatic Frame Inference for Object-Oriented Languages

AutoFrame: Automatic Frame Inference for Object-Oriented Languages


Automatic program verification has made tremendous strides, but is not yet for the masses. How do we make it less painful? This article addresses one of the obstacles: the need to specify explicit “frame clauses”, expressing what properties are left unchanged by an operation. It is fair enough to ask the would-be (human) prover to state what each operation changes, and how, but the (mechanical) prover also requires knowledge of what it does not change. The process of specifying and verifying these properties is tedious and error-prone, and must be repeated whenever the software evolves. it is also hard to justify, since all the information about what the code changes is in the code itself.

The AutoFrame tool presented here performs this analysis entirely automatically. It applies to object-oriented programming, where the issue is compounded by aliasing: if x is aliased to y, any update to x.a also affects y.a, even though the updating instruction usually does not even mention y. This aspect turns out to be the most delicate, and is addressed in AutoFrame by taking advantage of a companion tool, AutoAlias, which performs sound and sufficiently precise alias analysis, also in an entirely automatic way.

Some practical results of AutoFrame so far are: (1) the automatic reconstruction (in about 25 seconds on an ordinary laptop) of the exact frame clauses, a total of 169 clauses, for an 8,000-line data structures and algorithms library which was previously (with the manually written frame clauses) verified for functional correctness using a mechanical program prover; and (2) the automatic generation (in less than 4 minutes) of frame conditions for a 150,000-line graphical and GUI library. The source code of AutoFrame and these examples are available for download.


1 Introduction

The “frame problem” is the following question: in specifying an operation, aside from stating what properties it affects and how, e.g. depositing 100 euros into a bank account increases its balance by 100, how do we avoid the tedious, error-prone and fleeting specification of what it does not change, such as the bank account’s number, the bank’s address or, for that matter, the number of butterflies flapping their wings in Brazil?

Any tool for the verification of functional correctness must address this issue, since proving the correctness of an operation requires a full specification of its effect. In the deposit (sum) example, we may expect that the programmer will write a postcondition clause stating balance = old balance + sum, but cannot require explicit clauses owner = old owner, account_number = old account_number and so on (plus, under inheritance, new clauses for new properties introduced in descendant classes). The usual approach is to equip every operation with a “frame clause”: an exhaustive list of the properties that it is permitted to change. The operation’s specification is then understood to include p = old p for every property p not listed. For example the frame clause for deposit will just list balance. While this technique is a major improvement over the naïve approach of writing explicit postconditions for all non-changed properties, this article considers that it is still an undue burden on programmers, and proposes to remove it.

Automatic program verification tools such as AutoProof Autoproof2015 () and Dafny Leino:2013 () successfully rely on frame clauses. But even if the specification is simpler, a human must still write it; the process is still tedious and error-prone; and it must still be repeated or at least re-checked after every program update.

The present work proposes to avoid this process entirely by inferring the frame clauses automatically from the program text. Indeed the implementation contains all the information needed to determine what changes. The basic rule is that an assignment x := e changes x. In the absence of pointers/references and aliasing, this observation would suffice for frame inference. References and paths complicate the matter: in an object-oriented language, this assignment will also change x.a, x.a.b etc.; in addition, it will also change y.a, y.a.b etc. if y is aliased to (is a reference to) the current object (“this”). As a consequence, frame inference in an OO context, as presented in this article, fundamentally relies on alias analysis. What makes our results possible is AutoAlias, a new alias analysis tool based on the theory of “duality semantics”, an application of ideas from Abstract Interpretation Cousot:1977 (); Nielson:1999 (). A companion paper Autoalias2018 () describes AutoAlias.

AutoFrame is a practical tool, implemented as an addition to the EiffelStudio development environment. Its principal application so far have been to two Eiffel libraries with different scopes:

  • EiffelBase 2, for a total of 169 clauses and about 8000 lines of code and 45 classes, is a formally specified library, where the specifications (contracts) define full functional correctness, which has been proved mechanically Polikarpova2015 (); Polikarpova2010 () using the AutoProof automatic program prover. The proof, reflecting the current state of program proving technology, required manually written frame clauses. Beyond our expectations, AutoFrame infers, in a fully automatic fashion and in about 25 seconds, the exact frame clauses of EiffelBase 2, opening a promising avenue for simplification and practicality of modern verification technology.

  • EiffelVision 2 is a powerful and widely used (including by the EiffelStudio IDE itself for its user interface) graphical and UI library. It contains about 1141 classes and 150K LOC. AutoFrame infers all the frame clauses of EiffelVision in a little less than 4 minutes, an encouraging sign for the scalability of the approach.

These examples, as well as the source code of AutoFrame, are available for download at AutoAlias:Impl ().

AutoFrame takes over from previous work Kogtenkov:2015 (); Meyer:Alias:14 (); BM:2010 (), which had been applied to EiffelBase+, a precursor to EiffelBase 2. Beyond an order-of-magnitude improvement in speed (the EiffelBase+ frame inference took 420 seconds), the principal difference is that the AutoFrame inference process is now entirely automatic. The previous work still required manual intervention for matching the modification of concrete class attributes (denoting object fields), as deduced from the code, with the abstract model queries, as used in the specification (section 4). AutoFrame performs this task automatically. In particular, the exact reconstruction of EiffelBase 2 frame clauses, mentioned above, involves no manual intervention.

Some elements of this article, particularly in section 3, will at first sight look similar to the corresponding presentations in the earlier work just cited. One of the reasons is simply to make the presentation self-contained rather than requiring the reader to go to the earlier work. More fundamentally, however, while the general approach is superficially similar, the mathematical model has been profoundly refined, and the implementation is completely new including, as noted, full automation where the previous version involved a manual step. That previous work is best viewed as a prototype for the present version.

Section 2 analyzes previous work addressing automatic frame analysis. Section 3 explains the framing problem and introduces the Change Calculus, the basis for AutoFrame. Section 4 describes the AutoFrame tool and the two case studies mentioned above. Section 5 discusses the potential benefits of automatic frame inference and examines an important conceptual objection, the Assertion Inference Paradox.

It is not uncommon for articles about framing (such as Kogtenkov:2015 ()) to cite an extract of McCarthy and Hayes’s 1969 explanation of the problem Mccarthy69somephilosophical (). Their description is so apposite as to justify that we cite it once more (with the word “property” replacing the more dated “effluent”) to set the stage for the rest of the discussion:


1cm1cm “In proving that one person could get into conversation with another, we were obliged to add the hypothesis that if a person has a telephone he still has it after looking up a number in the telephone book. If we had a number of actions to be performed in sequence we would have quite a number of conditions to write down that certain actions do not change the values of certain properties. In fact with n actions and m properties we might have to write down mn such conditions.”

2 Related Work

There is an abundant literature on the general theme of automatic code verification, and another on the aliasing issue, which plays an important role in the approach of the present work; we concentrate on references specific to frame specification, analysis and inference.

Marvin Minsky first described the frame problem in the context of artificial intelligence Minsky:1974 (). Indeed it has been discussed in diverse areas including philosophy sep-frame-problem (). For the area of interest here, software verification, the classic paper is by McCarthy and Hayes, as already cited Mccarthy69somephilosophical ().

Many verification tools provide ways to express frame properties.“Modify” clauses were present as early as LARCH in 1993 Guttag93larch:languages (). “Modifies” clauses are used in a routine contract to specify which parts of the system may change as the result of the routine execution. This mechanism has been adopted by many other languages and verification tools with various names: JML Leavens:2006:PDJ:1127878.1127884 () a modeling language for Java programs, uses the “assignable” annotation. Tools like ESC/Java2 assignable-jml:06 (), a static verifier for JML-Java programs, and Krokota marche03krakatoa (), that translates Java programs to COQ coq-refman-09 () and WHY why:2003 (), use the assignable clause to verify frame properties; Spec# Barnett:2004 () and Dafny Leino:2013 () use modifies. They use Boogie this-is-boogie-2-2 (), an automatic program verifier that checks specifications statically; Eiffel define the modifies clause and uses Autoproof Autoproof2015 (), a static verifier for Eiffel based on Boogie, to prove frame conditions.

In all of these approaches programmers must write the clauses manually. This differs from the work presented in the current paper as AutoFrame automatically analysis source code and yields the set of frame conditions.

Rakamaric:08 () presents a technique for automatically inferring frame axioms of procedures and loops using static analysis. This work goes in the same direction as this paper, however our work is done in the context of a safe object-oriented language. Kogtenkov:2015 (), based on Meyer:Alias:14 () and BM:2010 (), is a precursor to the present work.

3 The Framing Problem

The frame problem is the problem of determining and verifying what properties an operation does not change.

Typically, notations for formal specification include ways of defining how properties change. For example, in specification-based programming using Design by Contract Meyer:2009:TCL (); Meyer:1997:OSC (), every routine is equipped with a specification of its effect, called its contract. The contract includes the postcondition, which states the expected effects on class variables; for example an operation deposit (s) will have the postcondition (in Eiffel syntax Meyer:1988 ()):

             balance = old balance + sum

Such notations can also express frame conditions:

             bank = old bank
             branch = old branch

The impracticality of this approach is obvious, but it is still useful to list its three separate disadvantages:

  • It is tedious, since typically an operation will only change a few class variables (such as balance for deposit), but you have to write something for all the others.

  • It is fragile, since every addition of a property (a class variable) to a class will force updating all routines.

  • It does not work well with inheritance, since addition of new properties in descendant classes requires updating routines in the ancestor classes, including those that the descendants do not redefine.

To address the problem, many notations include explicit support for frame properties, such as the proposed Eiffel syntax

only balance

which states that the routine cannot change anything else than balance and is hence semantically equivalent to a whole sequence of x = old x clauses, without the disadvantages. Other possible keywords are modify in AutoProof Autoproof2015 (), modifies in Dafny Leino:2013 () and assignable in JML assignable-jml:06 ().) A frame clause specifies that the operation may not modify any other properties than the ones listed, here balance.

The definition of such a notation must include a precise specification of its semantics, in particular its relation to inheritance. An example of frame clauses allowing mechanical program verification is the AutoProof system which, with the help of frame clauses, can automatically prove the full functional correctness of a 8000-line data structures and algorithms library, EiffelBase 2 Polikarpova2015 ().

The alternative solution pursued in the present work, freeing the programmer from the obligation to specify the modifies close, is to infer the frame conditions through automatic analysis of the routine implementation, which determines which values may change. The basis of the solution is the Change Calculus.

3.1 Change calculus

The Change Calculus is actually a “may-change” calculus, which for an instruction and a change set (empty in the initial state), the value of yields the set of expressions whose value may change as a result of executing . + is an over-approximation: for soundness must include anything that changes, but conversely an expression might appear in and not change in some executions of p. For example, the Change calculus yields the change set as a result of executing the following instruction

if Cond then
         a := c
         b := c

This change set expresses that the instruction may change a and may change b. “May”: there is no implication that any particular element of this set will change in a particular execution.

The following is the specification of the change calculus as used for this work. The target language is a common-core subset of the mechanisms present in all modern object-oriented languages such as Java, Eiffel, C# and C++; it is essentially the same as used for the Alias Calculus Kogtenkov:2015 (); Meyer:Alias:14 (); Autoalias2018 (), on which we rely.

The principal difference with actual OO languages is the ignoring of conditions: the conditional instruction is actually a non-deterministic choice, then p else q end, without the initial “if c” found in ordinary languages; and similarly for the loop construct. This simplification causes a potential loss of precision, which has not, however, had visible consequences in our examples so far. (For the Change Calculus proper, the problem is in fact not significant, since we have to expect that both p and q can be executed; otherwise the program contains dead code. Change analysis could still suffer from a loss of precision in the underlying alias analysis. The Alias Calculus, however, now addresses this problem, at least in part, by including some support for conditions, as detailed in Autoalias2018 ().)

The principal rules (assignment is explained later on), improved from the original version, are as follows.

Rule Name Rule Semantics
CC-Comp c + (p;q) = (c + p) + q

c + (create t) =

c + (then p else q end) = (c + p) (c + q)

c + (loop p end) = c + p

c + (call f (l)) = (c + )

c + ( f (l)) = c + f (x’.l)

The rule for instruction composition, CC-Comp, states that the set of locations is calculated by performing the analysis to the first instruction and then to the second one. The rule for creation of a class variable t, CC-New, adds t to the set since after the execution of the instruction, the location of t is changed. Conditionals and loops statements (rules CC-Cond and CC-Loop) do not take into consideration boolean conditions since in the general case it is an undecidable problem. The Change Calculus is an over-approximation (may-change).

In rules CC-UQCall and CC-QCall, l and are the lists of actual and formal arguments of feature f, respectively. its body and is the set with every element of the formal arguments list substituted for its counterpart in the actual arguments list.

The most fundamental rule for the calculus is the assignment rule as this is the instruction that defines what should change. A naive version of the rule is

Rule Name Rule Semantics
CC-Assg(Naive) c + t := s =

However, this rule is unsound in the presence of aliasing. As an example, lets assume that before the instruction a.b := x, a is aliased to an expression f. The calculus should yield the set since f will also change its value due the aliasing between a and f. To cope with this situation, rule CC-Assg is improved using the Alias Calculus Autoalias2018 (). The alias calculus is a set of rules defining the effect of executing an instruction on the aliasing that may exist between expressions. The calculus builds an alias Object Diagram, a graph whose nodes represent possible objects and edges represent possible calls between objects. Each of the rules defining the alias calculus, it gives, for an instruction of a given kind and an alias diagram that holds in the initial state, the value of , the alias diagram that holds after the execution of . The rule for assignments in the Change Calculus can then be re-written as

Rule Name Rule Semantics
CC-Assg c + (t := s) =


  • is the set of roots in , the Current object (a.k.a. this or self);

  • yields the set of paths aliased to in (defined in Autoalias2018 ());

  • is a dot distribution over lists Meyer2014 (); and

  • is the completion paths of in (defined in Autoalias2018 ()).

In words, the assignment rule works as follows. Consider the instruction t := s being applied to a change set . First, execute the instruction t := s on the alias diagram (). Then get all expressions that are aliased to Current (). Then dot-distribute it to () and compute its completion paths (). Finally, union the result to .

As an example, we compute c + (b := x) for on the following initial alias diagram

shows the Current object as having three class attributes , , and . Initially, expression a is aliased to b. First, we compute , obtaining

Then we compute

Next, dot-distribution (). Finally, all completion paths . This set is union to .

A more interesting example is when an aliased expression is the one being modified. We compute c + (b.d := x) for on the same initial alias diagram (above). b.d := x is a syntactic sugar for b.set_d (x) where set_d is a routine available to b that sets the class attribute d to the argument being passed. To execute such assignment, we transfer the context of the computation to object b, in other words, we make the object attached to b the root of (consult Autoalias2018 () for detailed information on how this process is carried out).

Then, we compute . First, we compute , obtaining

Then we compute

Since the context was transferred, Current, the root of , is node . Next, dot-distribution . Finally, all completion paths . This set is union to . The context is transferred back (see dot-distribution on Alias Graphs Autoalias2018 ()). Notice that not just b and b.d are added to the set, but also a and a.d since a was initially (before the instruction) aliased to b.

3.2 A previous approach

An initial attempt to define the rule for conditionals was for the rule to have the same effect as the rule for compound statements. The following is the first attempt to defining those rules (from Kogtenkov:2015 ()):

Rule Name Rule Semantics
Init-CC-Comp p;q = ()
Init-CC-Cond (then p else q end) = ()

where is the change set resulting from executing . We realized, and proved by counterexample, that this definition is unsound in the presence of aliasing. Consider and , the rule Init-CC-Comp would correctly yield the set . However, rule Init-CC-Cond would yield the same set but it should not be the case. Notice that after executing the instruction then a:=b;a.v:=c else a.x := d end there is no a computational path that makes the expression b.x changed. This happens because the information on the change set in rule Init-CC-Cond for is available when is executed. This error is taken care by the CC-Cond rule. Applying rule CC-Cond to and would yield:

4 AutoFrame: a tool for automatically synthesizing frame conditions

AutoFrame is an implementation of the Change Calculus described in the previous section. It relies on the implementation of the Alias Calculus (as shown by rule CC-Assg). AutoFrame statically analyzes the source code of a routine and yields the set of class attributes that are allowed to be changed. Such a set is a suggestion of Frame Conditions to programmers. The tool is implemented in Eiffel and integrated in EiffelStudio. Sources of the tool are available in AutoAlias:Impl () and results can be checked in AutoAliasAutoFrame:results ()

4.1 Using AutoFrame

We used AutoFrame as part of a validation process on two libraries for Eiffel, EiffelVision and EiffelBase.


EiffelVision 2 is the basic library for building graphical and GUI (Graphical User Interface) applications in the Eiffel programming language. It has around 150K Lines of Code (LOC) and 1141 classes. We ran AutoFrame on this library to automatically suggest Frame Conditions. AutoFrame performed the analysis in around 232 seconds.

The EiffelVision library is not equipped with modify clauses (as the EiffelBase 2 library described in Section 4.1.2). Hence, we cannot be sure about the soundness of the result. However, we manually checked random analyzed features finding no inconsistencies.

EiffelBase 2

EiffelBase 2 is a formally specified and verified library Polikarpova:2013 (). It contains a set of classes that implement common data structures and algorithms. One of the main advantages to work with this library is that all classes are equipped with contracts (pre, postconditions and class invariants) that specify classes behavior. The specification of the classes are fully verified against its implementation.

The specification style of the library relies on mathematical “model queries” Polikarpova2010 (). Each class in EiffelBase 2 declares its abstract state through a set of model attributes. Figure 1 is an excerpt of class V_LINKED_LIST. Its model attribute is a sequence of list elements: sequence. Its type MML_SEQUENCE is from a Mathematical Model Library (MML). Each command (method) with observable side effects, such as extend_back in Figure 1, defines a “modifies” clause that lists the model attributes that are allowed to be changed by the command. There are a total of 169 modify clauses in the library. Since AutoFrame automatically infers those clauses, we ran the tool on the library and compared the results.

Figure 1: Excerpt from EiffelBase 2 class V_LINKED_LIST

AutoFrame was able to suggest frame conditions to all features of the library. It automatically generated the 169 modify clauses. The tool analyzed a total of 45 classes containing 513 features (around 8K LOC). It does so in around 25 seconds. This timing outperforms the previous relation-based implementation of Change Calculus Kogtenkov:2015 () that takes around 420 seconds to analyze a precursor to EiffelBase 2 library.

Figure 2 depicts the general execution of the validation. Each feature f in EiffelBase 2 is passed to two processes, each process yields a set of class attributes, the validation consists in checking whether both sets are the same: in the first process, AutoFrame automatically infers the modify clause of the routine f by applying the rules described in an early section; in the second process, autoModifyClause, a helper tool, retrieves all information from the “modify” clause that comes with EiffelBase. The specification style of the library relies on mathematical “model queries”, hence the “modifies” clauses list such queries, not the program attributes directly. Since AutoFrame analyzes the source code of routines, it only yields class attributes, hence it was necessary to implement another tool that maps model queries to actual class attributes. The result of autoModifyClause is passed to MapMQ_ClassAttributes to get the actual class attributes being listed. This tool performs a data dependency analysis yielding for each model query the class attributes that are associated to it.

AutoFrame suggests exactly the same set of class attributes as the ones listed by the modify clause of the library. EiffelBase 2 has been formally verified so we were not expecting to find discrepancies, what it is interesting is that AutoFrame is able to infer all Frame Conditions automatically.

Figure 2: AutoFrame validation

4.2 Verification of Frame conditions

AutoFrame can be used for the verification of frame conditions if the code being analyzed is equipped with contracts. An informal review performed on publicly available JML code revealed that in practice queries mentioned in a modifies (“assignable”) clause for a command also appear in the postcondition of that command. In other words, it seems that whenever JML programmers state that something can be modified they also say how it will be modified. They do not necessarily say it in exact terms, as in q = some_value, but may just state some_property (q). Either way, however, the postcondition names q. It then seems a waste of effort to require writing a special clause listing such queries.

The analysis of the postcondition should only consider query occurrences outside of an old clause: a clause q1 = some_function (old q2) indicates that q1 can be modified, but says nothing about q2. This yields the notion of frame specification inference (FSI): instead of requiring programmers to write modifies clauses, the verification tools infer them from the postcondition. This is only one kind of “frame inference”, not to be confused with the one presented in this paper that infers frame conditions from the body of each feature (frame implementation inference – FII).

The verification of Frame Conditions becomes trivial having the set of queries being modified by the command (FII) and the set of queries being named in the postcondition (FSI), the Frame Condition holds if

Figure 3 depicts the process followed to achieve the verification of frame conditions of the EiffelBase 2 library. We take advantage of the contracts that come with the library. Each routine f in EiffelBase 2 is passed to two processes yielding sets FII and FSI, the verification consists in checking whether FII is a subset of FSI: in the first process, AutoFrame automatically infers the set of class attributes that f is allowed to change; For the second process, we implemented a helper tool (autoSpecFrame) that statically analyzes the postcondition of each feature and lists all queries being named in it. Since the specification style of the library relies on mathematical “model queries” contracts, the result of autoSpecFrame is passed to MapMQ_ClassAttributes to get the actual class attributes being named in the postcondition.

Figure 3: AutoFrame verification

We were able to verify the frame conditions of all features in the EiffelBase 2 library. For each feature of each class, the set of class attributes being modified by the feature is indeed a subset of the set of class attributes being named in the postcondition of the feature. In fact, the sets are the same. The results about the process of verifying the library are not surprising – as the library is fully equipped with contracts, modify clauses and has been fully verified. What it is interesting is that AutoFrame is able to perform the verification automatically.

5 Questioning the benefits

In assessing the potential of AutoFrame, we should consider the “Assertion Inference Paradox”, which Furia2010 () introduced in the following words (abridged):


1cm1cm “Any verification technique that infers specification elements from program texts faces a risk of vicious circle: the Assertion Inference Paradox. A program is correct if its implementation satisfies its specification; to talk about correctness we need both elements, implementation and specification. But if we infer the specification from the implementation, does the exercise not become vacuous?”

The technique presented in Furia2010 () was for inferring loop invariants from program texts, as pioneered by such tools as Daikon Ernst:01 (). Invariant inference has to address the Assertion Inference Paradox: if we infer the specification from the implementation, aren’t we just “documenting the bugs”? Furia2010 () analyzes and answers that objection. For the inference of frame conditions as discussed in this article, the risk is much less significant. The frame properties (the specification of what can change) are not typically something that programmers will want to specify explicitly.

In particular, if we want to perform full functional verification, requiring that we work with programs equipped with full contracts (as for EiffelBase 2 with AutoProof, or programs in JML or Spec#), the frame conditions involve no surprise: typically, no command, such as deposit has an effect on a query unless it lists it explicitly in its postcondition:

  • If the postcondition talks about a certain query, for example by stating balance = old balance + sum, the query can change as a result of executing the command.

  • If it does not list a query, such as bank, the query does not change.

All full-functional specifications that we have seen satisfy this rule, which Meyer:Alias:14 () analyzes further under the name “implicit convention”. It conforms to intuition: if you are going to prove the full functional correctness of a program and state that a query will change, you will also specify how it changes. Our experience with proofs of full functional correctness has shown no counter-example: in all formally verified software that we have seen, relying on a formal notation such as JML and Eiffel used with AutoProof that provides modifies clauses or equivalent, every query appearing in a modifies clause also appear in the postcondition.

In other words AutoFrame, does not on its own make up any crucial specification property: it simply documents properties that the specifiers would have to write anyway. It removes the tedium and possible errors.

In discussions with us, the authors of AutoProof and of the fully verified EiffelBase 2 library Polikarpova:14 () tended to downplay this benefit, stating that writing the modifies clauses was “not such a big deal”. We respect this view, but note that these colleagues are pioneers in software verification. As the verification community strives to make the technology mainstream, it is essential to remove any hurdle that, while not critical for researchers, may turn away a broader audience.

Perhaps even more importantly, we should take into account, as always in software engineering, the role of change. Even if we granted that the initial effort of writing frame clauses is manageable, both the implementations and the specifications will change, making it necessary to update the frame clauses and raising the possibility of errors. Automatic frame inference removes that risk.


We are indebted to colleagues who collaborated on the previous iterations of the Alias Calculus work, particular Sergey Velder for many important suggestions regarding the theory, and Alexander Kogtenkov who implemented an earlier version of the Change Calculus. During a talk by one of us (Meyer) at an IFIP WG1.9 meeting in Paris in 2016, Jean-Christophe Filliâtre uncovered a conceptual oversight of that earlier approach. We thank members of the Software Engineering Laboratory at Innopolis University, particularly Manuel Mazzara and Alexander Naumchev, for many fruitful discussions.


  1. journal: Journal of Systems and Software


  1. J. Tschannen, C. A. Furia, M. Nordio, N. Polikarpova, Autoproof: Auto-active functional verification of object-oriented programs, in: C. Baier, C. Tinelli (Eds.), Tools and Algorithms for the Construction and Analysis of Systems, Springer Berlin Heidelberg, Berlin, Heidelberg, 2015, pp. 566–580.
  2. K. R. M. Leino, Developing verified programs with dafny, in: Proceedings of the 2013 International Conference on Software Engineering, ICSE ’13, IEEE Press, Piscataway, NJ, USA, 2013, pp. 1488–1490.
  3. P. Cousot, R. Cousot, Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints, in: Proceedings of the 4th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, POPL ’77, ACM, New York, NY, USA, 1977, pp. 238–252. doi:10.1145/512950.512973.
  4. F. Nielson, H. R. Nielson, C. Hankin, Principles of Program Analysis, Springer-Verlag, Berlin, Heidelberg, 1999.
  5. V. Rivera, B. Meyer, Autoalias: Automatic variable-precision alias analysis for object-oriented programs, Submitted to Journal of Systems and Software, 2018.
  6. N. Polikarpova, J. Tschannen, C. A. Furia, A fully verified container library, in: N. Bjørner, F. de Boer (Eds.), FM 2015: Formal Methods, Springer International Publishing, 2015, pp. 414–434.
  7. N. Polikarpova, C. A. Furia, B. Meyer, Specifying reusable components, in: G. T. Leavens, P. O’Hearn, S. K. Rajamani (Eds.), Verified Software: Theories, Tools, Experiments, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, pp. 127–141.
  8. V. Rivera, Autoalias and autoframe implementations, commit: 25d20fc529151d19760f12a3566681fd0c79b1ed (2018).
  9. A. Kogtenkov, B. Meyer, S. Velder, Alias calculus, change calculus and frame inference, Sci. Comput. Program. 97 (P1) (2015) 163–172. doi:10.1016/j.scico.2013.11.006.
  10. B. Meyer, Framing the frame problem, in: lexander Pretschner, M. Broy, M. Irlbeck (Eds.), Dependable Software Systems, Springer, 2014, pp. 174–185.
  11. B. Meyer, Towards a theory and calculus of aliasing, Journal of Object Technology 9 (2) (2010) 37–74, (column). doi:10.5381/jot.2010.9.2.c5.
  12. J. Mccarthy, P. J. Hayes, Some philosophical problems from the standpoint of artificial intelligence, in: Machine Intelligence, Edinburgh University Press, 1969, pp. 463–502.
  13. M. Minsky, A framework for representing knowledge, Tech. rep., Cambridge, MA, USA (1974).
  14. M. Shanahan, The frame problem, in: E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy, spring 2016 Edition, Metaphysics Research Lab, Stanford University, 2016.
  15. J. V. Guttag, J. J. Horning, S. J. Garland, K. D. Jones, A. Modet, J. M. Wing, Larch: Languages and tools for formal specification, in: TEXTS AND MONOGRAPHS IN COMPUTER SCIENCE, Springer-Verlag, 1993.
  16. G. T. Leavens, A. L. Baker, C. Ruby, Preliminary design of jml: A behavioral interface specification language for java, SIGSOFT Softw. Eng. Notes 31 (3) (2006) 1–38. doi:10.1145/1127878.1127884.
  17. P. Chalin, J. R. Kiniry, G. T. Leavens, E. Poll, Beyond assertions: Advanced specification and verification with jml and esc/java2, in: F. S. de Boer, M. M. Bonsangue, S. Graf, W.-P. de Roever (Eds.), Formal Methods for Components and Objects, Springer Berlin Heidelberg, Berlin, Heidelberg, 2006, pp. 342–363.
  18. C. Marche, P. C. Mohring, X. Urbain, The Krakatoa Tool for Certification of Java/JavaCard Programs Annotated in JML, Journal of Logic and Algebraic Programming 58 (1-2) (2004) 89–106.
  19. mboxThe Coq development team, The Coq proof assistant reference manual, LogiCal Project (2009).
  20. J.-C. Filliâtre, Why: a multi-language multi-prover verification tool, Tech. rep., Universitá Paris Sud (March 2003).
  21. M. Barnett, K. R. M. Leino, W. Schulte, The spec# programming system: An overview, in: Proceedings of the 2004 International Conference on Construction and Analysis of Safe, Secure, and Interoperable Smart Devices, CASSIS’04, Springer-Verlag, Berlin, Heidelberg, 2005, pp. 49–69. doi:10.1007/978-3-540-30569-9_3.
  22. R. Leino, This is boogie 2, Microsoft Research, 2008.
  23. Z. Rakamaric, A. J. Hu, Automatic inference of frame axioms using static analysis, in: 2008 23rd IEEE/ACM International Conference on Automated Software Engineering, 2008, pp. 89–98. doi:10.1109/ASE.2008.19.
  24. B. Meyer, Touch of Class: Learning to Program Well with Objects and Contracts, 1st Edition, Springer Publishing Company, Incorporated, 2009.
  25. B. Meyer, Object-oriented Software Construction (2Nd Ed.), Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1997.
  26. B. Meyer, Eiffel: A language and environment for software engineering, J. Syst. Softw. 8 (3) (1988) 199–246. doi:10.1016/0164-1212(88)90022-2.
  27. B. Meyer, A. Kogtenkov, Negative Variables and the Essence of Object-Oriented Programming, Springer Berlin Heidelberg, Berlin, Heidelberg, 2014, pp. 171–187. doi:10.1007/978-3-642-54624-2_9.
  28. V. Rivera, Autoalias and autoframe results., Accessed (August 2018).
  29. N. Polikarpova, C. A. Furia, Y. Pei, Y. Wei, B. Meyer, What good are strong specifications?, in: Proceedings of the 2013 International Conference on Software Engineering, ICSE ’13, IEEE Press, Piscataway, NJ, USA, 2013, pp. 262–271.
  30. C. A. Furia, B. Meyer, Inferring Loop Invariants Using Postconditions, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, pp. 277–300. doi:10.1007/978-3-642-15025-8_15.
  31. M. D. Ernst, J. Cockrell, W. G. Griswold, D. Notkin, Dynamically discovering likely program invariants to support program evolution, IEEE Transactions on Software Engineering 27 (2) (2001) 99–123. doi:10.1109/32.908957.
  32. N. Polikarpova, Specified and verified reusable components, Ph.D. thesis, ETH ZURICH (2014).
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description