280,689 research outputs found

    Proof assistance for refnement in type theory

    Get PDF
    In this paper, we represent in type theory a proof system for refinement of algebraic specifications. . The representation is not adequate but full because the use of proof obligations to represent side-conditions. Using this representation, we can develop a proof tactic to help the development of proofs of refinement.Postprint (published version

    Ideas for a high-level proof strategy language

    Get PDF
    ABSTRACT Finding ways to prove theorems mechanically was one of the earliest challenges tackled by the AI community. Notable progress has been made but there is still always a limit to any set of heuristic search techniques. From a proof done by human users, we wish to find out whether AI techniques can also be used to learn from a human user. AI4FM (Artificial Intelligence for Formal Methods) is a four-year project that starts officially in April 2010 (see www.AI4FM.org). It focuses on helping users of "formal methods" many of which give rise to proof obligations that have to be (mechanically) verified (by a theorem prover). In industrial-sized developments, there are often a large number of proof obligations and, whilst many of them succumb to similar proof strategies, those that remain can hold up engineers trying to use formal methods. The goal of AI4FM is to learn enough from one manual proof, to discharge proof obligations automatically that yield to similar proof strategies. To achieve this, a high-level (proof) strategy language is required, and in this paper we outline some ideas of such language, and towards extracting them. * During this work Gudmund Grov has been employed jointly by University of Edinburgh and Newcastle University. and constrained use of Z [FW08] -is the so-called "posit and prove" approach: a designer posits development steps and then justifies that they satisfy earlier specifications by discharging (often automatically generated) proof obligations (POs). A large proportion of these POs can be discharged by automatic theorem provers but "some" proofs require user interaction. Quantifying "some" is hard since it depends on many factors such as the domain, technology and methodology used -it could be as little as 3% or as much as 40%. For example, the Paris Metro line 14, developed in the Bmethod, generated 27, 800 POs (of which around 2, 250 required user-interaction) [Abr07] -the need for interactive proofs is clearly still a bottleneck in industrial application of FM, notwithstanding high degree of automation. THE FORMAL METHODS PROBLE

    Proof obligations for monomorphicity

    Get PDF
    In certain applications of formal methods to development of correct software one wants the requirement specification to be monomorphic, i.e. that every two term-generated models of it are isomorphic. Consequently, the question arises how to guarantee monomorphicity (which is not decidable in general). In this paper we show that the task of proving monomorphicity of a specification can be reduced to a task of proving certain properties of procedures (with indeterministic constructs). So this task can be directly dealt with in the KIV system (Karlsruhe Interactive Verifier) which was originally designed for software verification. We prove correctness and completeness of our method

    Practical Theory Extension in Event-B

    No full text
    Abstract. The Rodin tool for Event-B supports formal modelling and proof using a mathematical language that is based on predicate logic and set theory. Although Rodin has in-built support for a rich set of operators and proof rules, for some application areas there may be a need to extend the set of operators and proof rules supported by the tool. This paper outlines a new feature of the Rodin tool, the theory component, that allows users to extend the mathematical language supported by the tool. Using theories, Rodin users may define new data types and polymorphic operators in a systematic and practical way. Theories also allow users to extend the proof capabilities of Rodin by defining new proof rules that get incorporated into the proof mechanisms. Soundness of new definitions and rules is provided through validity proof obligations.

    Event Systems and Access Control

    Get PDF
    We consider the interpretations of notions of access control (permissions, interdictions, obligations, and user rights) as run-time properties of information systems specified as event systems with fairness. We give proof rules for verifying that an access control policy is enforced in a system, and consider preservation of access control by refinement of event systems. In particular, refinement of user rights is non-trivial; we propose to combine low-level user rights and system obligations to implement high-level user rights

    LSB - Live and Safe B: Alternative semantics for Event B

    Get PDF
    We define two lifted, total relation semantics for Event B machines: Safe B for safety-only properties and Live B for liveness properties. The usual Event B proof obligations, Safe, are sufficient to establish Safe B refinement. Satisfying Safe plus a simple additional proof obligation ACT REF is sufficient to establish Live B refinement. The use of lifted, total relations both prevents the ambiguity of the unlifted relational semantics and prevents operations being clairvoyant

    Reasoned modelling critics: turning failed proofs into modelling guidance

    No full text
    The activities of formal modelling and reasoning are closely related. But while the rigour of building formal models brings significant benefits, formal reasoning remains a major barrier to the wider acceptance of formalism within design. Here we propose reasoned modelling critics — an approach which aims to abstract away from the complexities of low-level proof obligations, and provide high-level modelling guidance to designers when proofs fail. Inspired by proof planning critics, the technique combines proof-failure analysis with modelling heuristics. Here, we present the details of our proposal, implement them in a prototype and outline future plans
    corecore