| D. I. Good. Mechanical proofs about computer programs. In C. A.R. Hoare and J. C. Shepherdson, editors, Mathematical Logic and Programming Languages, chapter 3, pages 55--75. PrenticeHall, 1985. |
....to be verified is relatively simple. And it is very easy to make little mistakes which may lead to not being able to show that the program meets its specifications. Because of the tedious nature of manual proofs, there have been many efforts in trying to mechanize program verification [5] [13], 14] Unfortunately, it has been shown that it is impossible in principle to design a decision procedure which decides automatically the truth or falsehood of an arbitrary (mathematical) statement [41] However, the non existence of a general decision procedure only shows that one cannot prove ....
D.I. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages. Prentice-Hall, 1985.
....a result of the hypothesising of loop invariants. We cannot guarantee that P will be the weakest possible precondition, ie, wp(cmd # Q) but any complete execution of cmd , commencing in a state satisfying P , will produce a state satisfying Q . Message passing constructs are handled as in Gypsy [Goo84], by regarding potential blockage at a RECEIVE or SEND statement as another form of process exit, and simultaneously deriving preconditions for required conditions to hold at these exit points, in addition to exit at the logical end of a process. Thus perpetual processes can be validated. 3.2 ....
Good D.I., Mechanical proofs about computer programs, Phil. Trans. Royal Society, London, A 312, 1984, 389--409.
....determining the value of some array position respectively. Each step involves generalizing the original problem presented by the user. Related Work in Automatic Programming The approach taken in PLEESE draws on existing automatic programming methods including automatic theorem proving (e.g. [Good84, Manna86]) and program specification using traces (e.g. Bauer75, Phillips77] or examples [Summers77] PLEESE addresses a number of the problems encountered by these methods. The PLEESE approach is most like automatic theorem proving in that both involve deriving a proof (explanation) for an algorithm ....
D. Good, "Mechanical Proofs About Computer Programs," Philosophical Transactions of the Royal Society of London 312, 1522 (1984), pp. 389-409. (Also appears in Readings in Artificial Intelligence and Software Engineering, C. Rich (ed.), Morgan-Kaufmann)
....of trustworthiness of the underlying distributed programs. In practice, the correctness of a program is justified by testing it with various inputs. For complicated programs however, it soon becomes impossible to exhaustively test them. In his paper in Mathematical Logic and Programming Language [Goo85], a computer scientist, D.I. Good, sadly said the following about the practice of software engineering: So in current software engineering practice, predicting that a software system will run according to specification is based almost entirely on subjective, human judgement rather than on ....
D.I. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Sheperdson, editors, Mathematical Logic and Programming Languages, pages 55--75. Prentice-Hall, 1985.
....as semantically thorough and automatic as ours, but many systems have solved pieces of the puzzle. Full scale, but not automatic, program verifiers include the early systems of James King [26, 25] and Peter Deutsch [6] the Stanford Pascal Verifier [32] the 36 Gypsy Verification Environment [14] for developing programs by iterative refinement of specifications, the Penelope [15] verification system for a subset of Ada, and the coalgebra based Java verifier LOOP [22] Automatic static checkers that are based on conventional compiler flow analysis rather than program verification are not ....
Donald I. Good. Mechanical Proofs about Computer Programs. In C. A. R. Hoare and J. C. Shepherdson, editors, Mathematical Logic and Programming Languages, pages 55--75. International Series in Computer Science. Prentice Hall, 1985.
.... natural deduction as used in Mural [JJLM91] and in LCF [GMW79] and its descendants; proof theories tailored to various constructive logics , such as the constructive type theory used in NuPRL [CAB 86] and inductionbased strategies such as those used in the Boyer Moore prover [BM79] and Gypsy [Goo84] A proof style that is particularly effective uses term rewriting [HKLR92] In term rewriting approaches, one constructs a sequence of formal objects that starts with the formula to be proved, in which every object is related to the one before it by some validity preserving relation (typically, ....
D. Good. Mechanical proofs about computer programs. Technical Report 41, Institute for Computing Science, University of Texas at Austin, 1984.
....about designs and design choices, while hiding lowerlevel verification aspects. We plan to further investigate a closer integration of these different approaches. The Care method is informed, and partly inspired [15] by the Verification Condition Generation approach to program verification [4, 5] and could be combined with such approaches. In particular, we have purposefully left open the range of techniques used for verification of primitive (target language implemented) types and fragments. We have also left open the kinds of theorem prover that could be used with Care. Our project is ....
D. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages, pages 55-- 75. Prentice Hall International, 1985.
....developments structure which is useful for raising the level at which one reasons about designs and design choices, while hiding lower level verification aspects. The CARE method is informed, and partly inspired [16] by the Verification Condition Generation approach to program verification [4, 6] and could be combined with such approaches. In particular, we have purposefully left open the range of techniques used for verification of primitive (target language implemented) types and fragments. We have also left open the kinds of theorem prover that could be used withCARE. Our project ....
D. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages, pages 55--75. Prentice Hall International, 1985.
.... as used in Otter [McC90] natural deduction as used in Mural [JJLM91] and in LCF [GMW79] and its descendants; proof theories tailored to various constructive logics as used in NuPRL [CAB 86] and induction based strategies such as those used in the Boyer Moore prover [BM79] and Gypsy [Goo84] A particularly effective proof style is term rewriting [HKLR92] With this approach, a sequence of formal objects is constructed, starting with the formula to be proved, in which each object is related to the preceding one by some validity preserving relation (typically, but not essentially, ....
D. Good. Mechanical proofs about computer programs. Technical Report 41, Institute for Computing Science, University of Texas at Austin, 1984. 28
....by formal methods involves two major tasks: program development and theorem proving. Over the last two decades, many prototype tools for program development and theorem proving have been developed to investigate computeraided support for formal methods. These include: HDM [17] EHDM [16] Gypsy [9], Affirm [8, 12, 13] EVES [7] several assistants for the refinement calculus [4, 18, 2] Mural [11] RAISE [14] B [19] Demo2 [15] HOL [10] LF [1] and Nuprl [6] Most of these tools concentrate on the semantic checking and calculation involved in the development steps. Limited attention is ....
D. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages, Prentice-Hall International Series in Computer Science, pages 55--75. PrenticeHall International, London, 1985.
.... specifications into concrete, implementationlevel specifications: e.g. VDM [16] the Refinement Calculus [23] Larch [10] B [18] Deva [30] and Cogito [5] and ffl methods for reasoning directly about programs in (subsets of) certain programming languages: e.g. Spark Examiner [6] Gypsy [9] and EVES [7] 1 However full program verification is rare in industry. Program verification requires good tool support since proofs are just as errorprone as programs and indeed may be even more so, since they are typically orders of magnitude larger than the programs they purport to prove. ....
D. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages, pages 55--75. Prentice Hall International, 1985.
....and design choices, while hiding lower level verification aspects. We plan to further investigate a closer integration of these different approaches. The Care method is informed and partly inspired [26] by the Verification Condition Generation (VCG) approach to program verification [11, 12], and could be combined with such approaches. In particular, we have purposefully left open the range of 7 techniques used for verification of primitive (target language implemented) types and fragments. We have also left open the kinds of theorem prover that could be used with Care. Our project ....
D. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages, pages 55-- 75. Prentice Hall International, 1985.
....programs. Discovering a loop invariant is typically seen as a eureka step in the process of verifying an imperative program. This is reflected in the fact that some of the major contributions in this area rely to a large extent upon user interaction, e.g. in the gypsy verification environment [6] all loop invariants are supplied by the user. A common strategy for discovering invariants is to start with a desired post condition from which the invariant is derived by a process of weakening. The notion of a tail invariant [12] represents one such way of deriving an invariant. The search for ....
D.I. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages, chapter 3, pages 55--75. Prentice-Hall, 1985.
....and outputs a list of logical conditions. These conditions are supposed to be proved manually or mechanically (using a theorem prover) and their satisability ensures the correctness of the program. As examples of tools that work this way we can cite the Stanford Pascal Verier [ILL75] Gypsy [Goo85] EVES [KPS 92] or Penelope [GMP90] Verication condition generators are also used in formal methods based on stepwise renement like VDM [Jon86] or B [Abr95] as each renement step has to be validated by proving the corresponding set of verication conditions. However, if one verication ....
D.I. Good. Mechanical Proofs about Computer Programs. In C.A.R. Hoare and J.C. Sheperdson, editors, Mathematical Logic and Programming Languages. Prentice Hall, 1985.
....of a loop invariant is typically The research reported in this paper was supported by EPSRC grant GR L 11724 and arc grant 438. y A.Ireland hw.ac.uk z jamie cee.hw.ac.uk seen as a eureka step. This is reflected in the fact that some of the foremost verification environments, e.g. gypsy [12] and penelope [17] rely on the user to supply all loop invariants. We build upon proof plans [3] a meta level reasoning technique for automating proof search. The technique is implemented in the clam theorem proving system [5] Given a conjecture, clam attempts to automatically generate a lcf ....
D. I. Good. Mechanical proofs about computer programs. In C. A.R. Hoare and J. C. Shepherdson, editors, Mathematical Logic and Programming Languages, chapter 3, pages 55--75. Prentice-Hall, 1985.
....3.3.5 Implementation There has been considerable work on formal treatment of the final stage of development, that is formally relating a program to a low level specification. Techniques include the so called constructive approach, eg [ Bac86] and program verification environments, eg Gypsy [ Goo84] The constructive techniques are methods based on the idea of deriving the program from low level specifications, and are intended to be applied manually. The verification environments are based on similar mathematical bases [ Hoa69] to the constructive techniques but typically are more ....
D Good. Mechanical proofs about computer programs. Technical Report 41, Institute for Computing Science, The University of Texas at Austin, 1984.
....and F49620 93 I 0409 and, in part, by a grant from the University of Missouri Research Board. 2 This work was performed while the authors were at the University of Missouri Rolla in the Department of Computer Science. been many efforts in trying to mechanize program verification [2] 4] [5], 6] 7] 8] 14] etc. Unfortunately, it has been shown that it is impossible, in principle, to design a decision procedure which decides automatically the truth or falsehood of an arbitrary (mathematical) statement [13] Sadly, this also applies to program verification. Simply providing a ....
D.I. Good. Mechanical proofs about computer programs. In C.A.R. Hoare and J.C. Shepherdson, editors, Mathematical Logic and Programming Languages. Prentice-Hall, 1985.
....and outputs a list of logical conditions. These conditions are supposed to be proved manually or mechanically (using a theorem prover) and their satis ability en sures the correctness of the program. As examples of tools that work this way we can cite the Stanford Pascal Veri er [ILL75] Gypsy [Goo85] EVES [KPS 92] or Penelope [GMP90] Veri cation condition generators are also used in formal methods based on stepwise re nement like VDM [Jon86] or B [Abr95] as each re nement step has to be validated by proving the corresponding set of veri cation conditions. However, if one veri cation ....
D.I. Good. Mechanical Proofs about Computer Programs. In C.A.R. Hoare and J.C. Sheperdson, editors, Mathematical Logic and Programming Lan guages. Prentice Hall, 1985.
....a result of the hypothesising of loop invariants. We cannot guarantee that P will be the weakest possible precondition, ie, wp(cmd ; Q) but any complete execution of cmd , commencing in a state satisfying P , will produce a state satisfying Q . Message passing constructs are handled as in Gypsy [Goo84], by regarding potential blockage at a RECEIVE or SEND statement as another form of process exit, and simultaneously deriving preconditions for required conditions to hold at these exit points, in addition to exit at the logical end of a process. Thus perpetual processes can be validated. 3.2 ....
Good D.I., Mechanical proofs about computer programs, Phil. Trans. Royal Society, London, A 312, 1984, 389--409.
....the assertion Q will be true on its completion. 1 Since 1969, research into Hoare logics has been a major topic in the theory of programming. Numerous variations and extensions of Hoare s original ideas have been developed. These have both been studied theoretically [1] and put into practice [3, 9]. This tradition is continued here. An interpretation of Hoare logic is described that is intended for the analysis of programs implementing realtime reactive systems. Versions of Hoare s original rules have been derived and form the basis for a prototype computer assisted program verifier. The ....
....use in reasoning about machine instructions is described elsewhere [6] To make this paper self contained, a simplified version of the theory is outlined in 1.7. The general idea of mechanising Hoare logics by generating verification conditions and then feeding them to a theorem prover is standard [3, 5, 13]. The particular approach used here was originally developed for non timed Hoare logics [4] Verification conditions are described in 1.6. The main contribution of this paper is to make the use of STAs for reasoning about data processing algorithms much easier by defining a Hoare logic on top of ....
[Article contains additional citation context not shown here]
Good, D.I., `Mechanical proofs about computer programs', in Hoare, C.A.R. and Shepherdson, J.C. (Eds), Mathematical Logic and Programming Languages, Prentice Hall, 1985.
....substrate of the tool allows the postcondition and intermediate assertions to be initially unspecified, and refined automatically as the verification proceeds. This is an advantage in comparison with the similar tools from [CP90] for example. Message passing constructs are handled as in Gypsy [Goo84], by regarding potential blockage at a RECEIVE or SEND communication statement as another form of process exit, and simultaneously deriving preconditions for required conditions to hold at these exit points, in addition to the exit at the logical end of a process. Thus even perpetual processes can ....
Good D.I., Mechanical proofs about computer programs, Phil. Trans. Royal Society, London, A 312, 1984, 389--409.
....levels) addresses design proofs, an activity in which the line is drawn somewhere above the highest level executable code in the system. Some verification work addresses code proofs, where traditionally the line has been drawn at the definition of a high level programming language like Gypsy [6, 7, 8], Pascal [19] Fortran [2] and others [20, 5, 13, 17, 4] There has been some work on compiler verification, notably the work of Polak [15] in which a compiler for a Pascal subset is verified. Finally, there has been some recent work closer to the bottom of the system stack. For example, Gordon ....
Donald I. Good. Mechanical Proofs about Computer Programs. In C. A. R. Hoare and J. C. Shepherdson, Ed., Mathematical Logic and Programming Languages, Prentice-Hall International Series in Computer Science., 1985, pp. 55-75.
....Kunen. 1.11.6 Program Verification and Natural Language In 1974 Bledsoe began to contribute to the field of mechanical program verification. The IMPLY prover that he developed was incorporated into a verification system for Pascal [52] and was later utilized in the verification system for Gypsy [53, 54, 63], which has been used to verify several significant computing systems. See also [35] In 1990, Bledsoe s student Don Simon finished a Ph. D. thesis [62] about a program that could proof check number theory proofs directly from a textbook ( 67] typeset in L a T E X. 24 Anne Olivia Boyer and ....
D. I. Good (1985): Mechanical Proofs about Computer Programs. In: C. A. R. Hoare and J. C. Shepherdson, eds.: Mathematical Logic and Programming Languages. Prentice-Hall. 55--75.
....shown to be an applied methodology built on this foundation. Another methodology built on the same foundation is the post hoc verification of already completed programs. Such verification can either be based on traditional forward proof , or via backward reasoning using verification conditions [15, 9] (which is closely related to weakest preconditions [7] The architecture of a traditional verification condition based program verifier is described and its operation is justified with respect to Floyd Hoare logic. Partial correctness is treated first. It is then shown how total correctness can ....
Good, D.I., `Mechanical proofs about computer programs', in Hoare, C.A.R. and Shepherdson, J.C. (eds), Mathematical Logic and Programming Languages, Prentice Hall, 1985.
....a result of the hypothesising of loop invariants. We cannot guarantee that P will be the weakest possible precondition, ie, wp(cmd ; Q) but any complete execution of cmd , commencing in a state satisfying P , will produce a state satisfying Q . Message passing constructs are handled as in Gypsy [Goo84], by regarding potential blockage at a RECEIVE or SEND statement as another form of process exit, and simultaneously deriving preconditions for required conditions to hold at these exit points, in addition to exit at the logical end of a process. Thus perpetual processes can be validated. 3.2 ....
Good D.I., Mechanical proofs about computer programs, Phil. Trans. Royal Society, London, A 312, 1984, 389--409.
No context found.
D. I. Good. Mechanical proofs about computer programs. In C. A.R. Hoare and J. C. Shepherdson, editors, Mathematical Logic and Programming Languages, chapter 3, pages 55--75. PrenticeHall, 1985.
No context found.
Good, D.I., `Mechanical proofs about computer programs', in Hoare, C.A.R. and Shepherdson, J.C. (eds), Mathematical Logic and Programming Languages, Prentice Hall, 1985.
No context found.
Good, D. (1986). Mechanical Proofs About Computer Programs, Artificial Intelligence and Software Engineering, Eds Charles Rich, R.C. Waters, Morgan Kaufmann 1986.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC