000 04395nam a22006255i 4500
001 978-3-540-69061-0
003 DE-He213
005 20240423125629.0
007 cr nn 008mamaa
008 100301s2007 gw | s |||| 0|eng d
020 _a9783540690610
_9978-3-540-69061-0
024 7 _a10.1007/978-3-540-69061-0
_2doi
050 4 _aQ334-342
050 4 _aTA347.A78
072 7 _aUYQ
_2bicssc
072 7 _aCOM004000
_2bisacsh
072 7 _aUYQ
_2thema
082 0 4 _a006.3
_223
245 1 0 _aVerification of Object-Oriented Software. The KeY Approach
_h[electronic resource] :
_bForeword by K. Rustan M. Leino /
_cedited by Bernhard Beckert, Reiner Hähnle, Peter H. Schmitt.
250 _a1st ed. 2007.
264 1 _aBerlin, Heidelberg :
_bSpringer Berlin Heidelberg :
_bImprint: Springer,
_c2007.
300 _aXXIX, 658 p.
_bonline resource.
336 _atext
_btxt
_2rdacontent
337 _acomputer
_bc
_2rdamedia
338 _aonline resource
_bcr
_2rdacarrier
347 _atext file
_bPDF
_2rda
490 1 _aLecture Notes in Artificial Intelligence,
_x2945-9141 ;
_v4334
505 0 _aA 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.
520 _aLong 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.
650 0 _aArtificial intelligence.
650 0 _aComputer science.
650 0 _aMachine theory.
650 0 _aCompilers (Computer programs).
650 0 _aSoftware engineering.
650 1 4 _aArtificial Intelligence.
650 2 4 _aComputer Science Logic and Foundations of Programming.
650 2 4 _aFormal Languages and Automata Theory.
650 2 4 _aCompilers and Interpreters.
650 2 4 _aSoftware Engineering.
700 1 _aBeckert, Bernhard.
_eeditor.
_4edt
_4http://id.loc.gov/vocabulary/relators/edt
700 1 _aHähnle, Reiner.
_eeditor.
_4edt
_4http://id.loc.gov/vocabulary/relators/edt
700 1 _aSchmitt, Peter H.
_eeditor.
_4edt
_4http://id.loc.gov/vocabulary/relators/edt
710 2 _aSpringerLink (Online service)
773 0 _tSpringer Nature eBook
776 0 8 _iPrinted edition:
_z9783540689775
776 0 8 _iPrinted edition:
_z9783540834335
830 0 _aLecture Notes in Artificial Intelligence,
_x2945-9141 ;
_v4334
856 4 0 _uhttps://doi.org/10.1007/978-3-540-69061-0
912 _aZDB-2-SCS
912 _aZDB-2-SXCS
912 _aZDB-2-LNC
942 _cSPRINGER
999 _c180048
_d180048