000 04494nam a22006255i 4500
001 978-3-540-69061-0
003 DE-He213
005 20240730183116.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.
_93407
650 0 _aComputer science.
_99832
650 0 _aMachine theory.
_9130533
650 0 _aCompilers (Computer programs).
_93350
650 0 _aSoftware engineering.
_94138
650 1 4 _aArtificial Intelligence.
_93407
650 2 4 _aComputer Science Logic and Foundations of Programming.
_942203
650 2 4 _aFormal Languages and Automata Theory.
_9130534
650 2 4 _aCompilers and Interpreters.
_931853
650 2 4 _aSoftware Engineering.
_94138
700 1 _aBeckert, Bernhard.
_eeditor.
_4edt
_4http://id.loc.gov/vocabulary/relators/edt
_9130535
700 1 _aHähnle, Reiner.
_eeditor.
_4edt
_4http://id.loc.gov/vocabulary/relators/edt
_9130536
700 1 _aSchmitt, Peter H.
_eeditor.
_4edt
_4http://id.loc.gov/vocabulary/relators/edt
_9130537
710 2 _aSpringerLink (Online service)
_9130538
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
_9130539
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 _cELN
999 _c91675
_d91675