1,964 research outputs found
Multilevel Contracts for Trusted Components
This article contributes to the design and the verification of trusted
components and services. The contracts are declined at several levels to cover
then different facets, such as component consistency, compatibility or
correctness. The article introduces multilevel contracts and a
design+verification process for handling and analysing these contracts in
component models. The approach is implemented with the COSTO platform that
supports the Kmelia component model. A case study illustrates the overall
approach.Comment: In Proceedings WCSI 2010, arXiv:1010.233
Integrated Reasoning and Proof Choice Point Selection in the Jahob System ā Mechanisms for Program Survival
In recent years researchers have developed a wide range of powerful automated reasoning systems. We have leveraged these systems to build Jahob, a program specification, analysis, and verification system. In contrast to many such systems, which use a monolithic reasoning approach, Jahob provides a general integrated reasoning framework, which enables multiple automated reasoning systems to work together to prove the desired program correctness properties.
We have used Jahob to prove the full functional correctness of a collection of linked data structure implementations. The automated reasoning systems are able to automatically perform the vast majority of the reasoning steps required for this verification. But there are some complex verification conditions that they fail to prove. We have therefore developed a proof language, integrated into the underlying imperative Java programming language, that developers can use to control key choice points in the proof search space. Once the developer has resolved these choice points, the automated reasoning systems are able to complete the verification. This approach appropriately leverages both the developerās insight into the high-level structure of the proof and the ability of the automated reasoning systems to perform the mechanical steps required to prove the verification conditions.
Building on Jahobās success with this challenging program verification problem, we contemplate the possibility of verifying the complete absence of fatal errors in large software systems. We envision combining simple techniques that analyze the vast majority of the program with heavyweight techniques that analyze those more sophisticated parts of the program that may require arbitrarily sophisticated reasoning. Modularity mechanisms such as abstract data types enable the sound division of the program for this purpose. The goal is not a completely correct program, but a program that can survive any remaining errors to continue to provide acceptable service
An Exercise in Invariant-based Programming with Interactive and Automatic Theorem Prover Support
Invariant-Based Programming (IBP) is a diagram-based correct-by-construction
programming methodology in which the program is structured around the
invariants, which are additionally formulated before the actual code. Socos is
a program construction and verification environment built specifically to
support IBP. The front-end to Socos is a graphical diagram editor, allowing the
programmer to construct invariant-based programs and check their correctness.
The back-end component of Socos, the program checker, computes the verification
conditions of the program and tries to prove them automatically. It uses the
theorem prover PVS and the SMT solver Yices to discharge as many of the
verification conditions as possible without user interaction. In this paper, we
first describe the Socos environment from a user and systems level perspective;
we then exemplify the IBP workflow by building a verified implementation of
heapsort in Socos. The case study highlights the role of both automatic and
interactive theorem proving in three sequential stages of the IBP workflow:
developing the background theory, formulating the program specification and
invariants, and proving the correctness of the final implementation.Comment: In Proceedings THedu'11, arXiv:1202.453
COSMICAH 2005: workshop on verification of COncurrent Systems with dynaMIC Allocated Heaps (a Satellite event of ICALP 2005) - Informal Proceedings
Lisboa Portugal, 10 July 200
An Approach to Invariant-based Program Refactoring
Refactoring tools include checking of an object-oriented program for the
fulfillment of preconditions, for ensuring correctness. However, program invariants
Ć¢ semantic information about classes and fields assumed valid during program execution
Ć¢ are not considered by this precondition checking. As a result, applicability
of automated refactorings is constrained in these cases, as refactorings that would be
applicable considering the invariants get rejected, usually requiring manual changes.
In this paper, we describe initial work on the use of program invariants (declared as
code annotations) to increase applicability of automated refactoring. We propose an
approach that uses primitive program transformations that employ the invariant to
make the program syntactically amenable to the desired refactoring, before applying
the refactoring itself
Refactoring Functional Programs
Refactoring is the process of redesigning existing code without changing its functionality. Refactoring has recently come to prominence in the OO community. In this paper we explore the prospects for refactoring functional programs. Our paper centres on the case study of refactoring a 400 line Haskell program written by one of our students. The case study illustrates the type and variety of program manipulations involved in refactoring. Similarly to other program transformations, refactorings are based on program equivalences, and thus ultimately on language semantics. In the context of functional languages, refactorings can be based on existing theory and program analyses. However, the use of program transformations for program restructuring emphasises a different kind of transformation from the more traditional derivation or optimisation: characteristically, they often require wholesale changes to a collection of modules, and although they are best controlled by programmers, their application may require nontrivial semantic analyses. The paper also explores the background to refactoring, provides a taxonomy for describing refactorings and draws some conclusions about refactoring for functional programs
- ā¦