Verification of Object-Oriented Software. The KeY Approach [electronic resource] : Foreword by K. Rustan M. Leino / edited by Bernhard Beckert, Reiner Hähnle, Peter H. Schmitt.

Contributor(s): Beckert, Bernhard [editor.] | Hähnle, Reiner [editor.] | Schmitt, Peter H [editor.] | SpringerLink (Online service)Material type: TextTextSeries: Lecture Notes in Computer Science ; 4334Publisher: Berlin, Heidelberg : Springer Berlin Heidelberg, 2007Description: XXIX, 658 p. Also available online. online resourceContent type: text Media type: computer Carrier type: online resourceISBN: 9783540690610Subject(s): Computer science | Software engineering | Logic design | Artificial intelligence | Computer Science | Artificial Intelligence (incl. Robotics) | Logics and Meanings of Programs | Mathematical Logic and Formal Languages | Programming Languages, Compilers, Interpreters | Software EngineeringAdditional physical formats: Printed edition:: No titleDDC classification: 006.3 LOC classification: Q334-342TJ210.2-211.495Online resources: Click here to access online
Contents:
A New Look at Formal Methods for Software Construction -- A New Look at Formal Methods for Software Construction -- I: Foundations -- First-Order Logic -- Dynamic Logic -- Construction of Proofs -- II: Expressing and Formalising Requirements -- Formal Specification -- Pattern-Driven Formal Specification -- Natural Language Specifications -- Proof Obligations -- From Sequential Java to Java Card -- III: Using the KeY System -- Using KeY -- Proving by Induction -- Java Integers -- Proof Reuse -- IV: Case Studies -- The Demoney Case Study -- The Schorr-Waite-Algorithm -- Appendices -- Predefined Operators in Java Card DL -- The KeY Syntax.
In: Springer eBooksSummary: Long gone are the days when program veri?cation was a task carried out merely by hand with paper and pen. For one, we are increasingly interested in proving actual program artifacts, not just abstractions thereof or core algorithms. The programs we want to verify today are thus longer, including whole classes and modules. As we consider larger programs, the number of cases to be considered in a proof increases. The creative and insightful parts of a proof can easily be lost in scores of mundane cases. Another problem with paper-and-pen proofs is that the features of the programming languages we employ in these programs are plentiful, including object-oriented organizations of data, facilities for specifying di?erent c- trol ?ow for rare situations, constructs for iterating over the elements of a collection, and the grouping together of operations into atomic transactions. These language features were designed to facilitate simpler and more natural encodings of programs, and ideally they are accompanied by simpler proof rules. But the variety and increased number of these features make it harder to remember all that needs to be proved about their uses. As a third problem, we have come to expect a higher degree of rigor from our proofs. A proof carried out or replayed by a machine somehow gets more credibility than one that requires human intellect to understand.
Item type: E-BOOKS
Tags from this library: No tags from this library for this title. Log in to add tags.
    Average rating: 0.0 (0 votes)
Current library Home library Call number Materials specified URL Status Date due Barcode
IMSc Library
IMSc Library
Link to resource Available EBK7112

A New Look at Formal Methods for Software Construction -- A New Look at Formal Methods for Software Construction -- I: Foundations -- First-Order Logic -- Dynamic Logic -- Construction of Proofs -- II: Expressing and Formalising Requirements -- Formal Specification -- Pattern-Driven Formal Specification -- Natural Language Specifications -- Proof Obligations -- From Sequential Java to Java Card -- III: Using the KeY System -- Using KeY -- Proving by Induction -- Java Integers -- Proof Reuse -- IV: Case Studies -- The Demoney Case Study -- The Schorr-Waite-Algorithm -- Appendices -- Predefined Operators in Java Card DL -- The KeY Syntax.

Long gone are the days when program veri?cation was a task carried out merely by hand with paper and pen. For one, we are increasingly interested in proving actual program artifacts, not just abstractions thereof or core algorithms. The programs we want to verify today are thus longer, including whole classes and modules. As we consider larger programs, the number of cases to be considered in a proof increases. The creative and insightful parts of a proof can easily be lost in scores of mundane cases. Another problem with paper-and-pen proofs is that the features of the programming languages we employ in these programs are plentiful, including object-oriented organizations of data, facilities for specifying di?erent c- trol ?ow for rare situations, constructs for iterating over the elements of a collection, and the grouping together of operations into atomic transactions. These language features were designed to facilitate simpler and more natural encodings of programs, and ideally they are accompanied by simpler proof rules. But the variety and increased number of these features make it harder to remember all that needs to be proved about their uses. As a third problem, we have come to expect a higher degree of rigor from our proofs. A proof carried out or replayed by a machine somehow gets more credibility than one that requires human intellect to understand.

There are no comments on this title.

to post a comment.
The Institute of Mathematical Sciences, Chennai, India

Powered by Koha