Using History Invariants to Verify Observers

Leino, K. Rustan M.; Schulte, Wolfram

doi:10.1007/978-3-540-71316-6_7

Cited by 21 publications

(18 citation statements)

References 22 publications

(21 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The two most common forms of monotonicity are initialization (a variable goes from the uninitialized state to the initialized state but never back) [Fähndrich and Xia 2007] and immutability (a variable is not updated at all after its initialization) ]. More general forms of monotonicity are explored in type states [Fähndrich and Leino 2003;Pilkiewicz and Pottier 2009], object relations [Leino and Schulte 2007;Cohen et al 2010], and concurrency [Jones 1983;Cohen et al 2010]. …”

Section: Module Invariantsmentioning

confidence: 99%

Behavioral interface specification languages

et al. 2012

Self Cite

View full text Add to dashboard Cite

Behavioral interface specification languages provide formal code-level annotations, such as preconditions, postconditions, invariants, and assertions that allow programmers to express the intended behavior of program modules. Such specifications are useful for precisely documenting program behavior, for guiding implementation, and for facilitating agreement between teams of programmers in modular development of software. When used in conjunction with automated analysis and program verification tools, such specifications can support detection of common code vulnerabilities, capture of light-weight application-specific semantic properties, generation of test cases and test oracles, and full formal program verification. This article surveys behavioral interface specification languages with a focus toward automatic program verification and with a view towards aiding the Verified Software Initiative-a fifteen-year, cooperative, international project directed at the scientific challenges of large-scale software verification.

show abstract

Section: Module Invariantsmentioning

confidence: 99%

Behavioral interface specification languages

et al. 2012

Self Cite

View full text Add to dashboard Cite

show abstract

“…Several more recent specification languages are now making their way into practical and educational use, including JML [31], Spec [5], Dafny [32] and Whiley [51]. Our approach builds upon these fundamentals, particularly Leino & Shulte's formulation of two-state invariants [33], and Summers and Drossopoulou's Considerate Reasoning [58]. In general, these approaches assume a closed system, where modules can be trusted to cooperate.…”

Section: Related Workmentioning

confidence: 99%

Holistic Specifications for Robust Programs

Drossopoulou

Noble

Mackay

et al. 2020

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Functional specifications describe what program components can do: the sufficient conditions to invoke a component's operations. They allow us to reason about the use of components in the closed world setting, where the component interacts with known client code, and where the client code must establish the appropriate pre-conditions before calling into the component. Sufficient conditions are not enough to reason about the use of components in the open world setting, where the component interacts with external code, possibly of unknown provenance, and where the component itself may evolve over time.In this open world setting, we must also consider the necessary conditions, i.e. what are the conditions without which an effect will not happen. In this paper we propose a language Chainmail for writing holistic specifications that focus on necessary conditions (as well as sufficient conditions). We give a formal semantics for Chainmail, and the core of Chainmail has been mechanised in the Coq proof assistant.

show abstract

“…These patterns often make use of complicated aggregate structures. Class invariant-based approaches, such as Spec , require significant extensions to handle these structures and their use (Leino and Schulte 2007). Early experiments suggest that our approach-using separation logic and abstract predicate familiesrequires no extensions to handle aggregate structures.…”

Section: Conclusion and Related Workmentioning

confidence: 99%

Separation logic, abstraction and inheritance

Parkinson

Bierman

2008

SIGPLAN Not.

View full text Add to dashboard Cite

Inheritance is a fundamental concept in object-oriented programming, allowing new classes to be defined in terms of old classes. When used with care, inheritance is an essential tool for objectoriented programmers. Thus, for those interested in developing formal verification techniques, the treatment of inheritance is of paramount importance. Unfortunately, inheritance comes in a number of guises, all requiring subtle techniques.To address these subtleties, most existing verification methodologies typically adopt one of two restrictions to handle inheritance: either (1) they prevent a derived class from restricting the behaviour of its base class (typically by syntactic means) to trivialize the proof obligations; or (2) they allow a derived class to restrict the behaviour of its base class, but require that every inherited method must be reverified. Unfortunately, this means that typical inheritance-rich code either cannot be verified or results in an unreasonable number of proof obligations.In this paper, we develop a separation logic for a core objectoriented language. It allows derived classes which override the behaviour of their base class, yet supports the inheritance of methods without reverification where this is safe. For each method, we require two specifications: a static specification that is used to verify the implementation and direct method calls (in Java this would be with a super call); and a dynamic specification that is used for calls that are dynamically dispatched; along with a simple relationship between the two specifications. Only the dynamic specification is involved with behavioural subtyping. This simple separation of concerns leads to a powerful system that supports all forms of inheritance with low proof-obligation overheads. We both formalize our methodology and demonstrate its power with a series of inheritance examples.

show abstract

Using History Invariants to Verify Observers

Cited by 21 publications

References 22 publications

Behavioral interface specification languages

Behavioral interface specification languages

Holistic Specifications for Robust Programs

Separation logic, abstraction and inheritance

Contact Info

Product

Resources

About