000 04123nam a22005775i 4500
001 978-3-540-69061-0
003 DE-He213
005 20160624102053.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 _aTJ210.2-211.495
072 7 _aUYQ
_2bicssc
072 7 _aTJFM1
_2bicssc
072 7 _aCOM004000
_2bisacsh
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.
260 1 _aBerlin, Heidelberg :
_bSpringer Berlin Heidelberg,
_c2007.
264 1 _aBerlin, Heidelberg :
_bSpringer Berlin Heidelberg,
_c2007.
300 _aXXIX, 658 p. Also available online.
_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 Computer Science,
_x0302-9743 ;
_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 _aComputer science.
650 0 _aSoftware engineering.
650 0 _aLogic design.
650 0 _aArtificial intelligence.
650 1 4 _aComputer Science.
650 2 4 _aArtificial Intelligence (incl. Robotics).
650 2 4 _aLogics and Meanings of Programs.
650 2 4 _aMathematical Logic and Formal Languages.
650 2 4 _aProgramming Languages, Compilers, Interpreters.
650 2 4 _aSoftware Engineering.
700 1 _aBeckert, Bernhard.
_eeditor.
700 1 _aHähnle, Reiner.
_eeditor.
700 1 _aSchmitt, Peter H.
_eeditor.
710 2 _aSpringerLink (Online service)
773 0 _tSpringer eBooks
776 0 8 _iPrinted edition:
_z9783540689775
786 _dSpringer
830 0 _aLecture Notes in Computer Science,
_x0302-9743 ;
_v4334
856 4 0 _uhttp://dx.doi.org/10.1007/978-3-540-69061-0
942 _2EBK7112
_cEBK
999 _c36406
_d36406