Show simple item record

Files in this item

Thumbnail

Item metadata

dc.contributor.authorSlama, Franck
dc.contributor.editorAichernig, Bernhard K.
dc.contributor.editorFuria, Carlo A.
dc.date.accessioned2018-11-13T16:30:05Z
dc.date.available2018-11-13T16:30:05Z
dc.date.issued2016
dc.identifier.citationSlama , F 2016 , Automatic predicate testing in formal certification : you’ve only proven what you’ve said, not what you meant! in B K Aichernig & C A Furia (eds) , Tests and Proofs - 10th International Conference, TAP 2016 Held as Part of STAF 2016 . Lecture Notes in Computer Science , vol. 9762 , Springer-Verlag , pp. 191-198 , 10th International Conference on Tests and Proofs, TAP 2016 and Held as Part of Software Technologies: Applications and Foundations, STAF 2016 , Vienna , Austria , 5/07/16 . DOI: 10.1007/978-3-319-41135-4_12en
dc.identifier.citationconferenceen
dc.identifier.isbn9783319411347
dc.identifier.isbn9783319411354
dc.identifier.issn0302-9743
dc.identifier.otherPURE: 256566008
dc.identifier.otherPURE UUID: 5eb52260-1fcb-4890-9699-d147d7171389
dc.identifier.otherScopus: 84977514107
dc.identifier.urihttp://hdl.handle.net/10023/16442
dc.description.abstractThe use of formal methods and proof assistants helps to increase the confidence in critical software. However, a formal proof is only a guarantee relative to a formal specification, and not necessary about the real requirements. There is always a jump when going from an informal specification to a formal specification expressed in a logical theory. Thus, proving the correctness of a piece of software always makes the implicit assumption that there is adequacy between the formalised specification -written with logical statements and predicates- and the real requirements -often written in English-. Unfortunately, a huge part of the complexity lies precisely in the specification itself, and it is far from obvious that the formal specification says exactly and completely what it should say. Why should we trust more these predicates than the code that we’ve first refused to trust blindly, leading to these proofs? We show in this paper that the proving activity has not replaced the testing activity but has only changed the object which requires to be tested. Instead of testing code, we now need to test predicates.We present recent ideas about how to conduct these tests inside the proof assistant on a few examples, and how to automate them as far as possible.en
dc.format.extent8en
dc.language.isoeng
dc.publisherSpringer-Verlag
dc.relation.ispartofTests and Proofs - 10th International Conference, TAP 2016 Held as Part of STAF 2016en
dc.relation.ispartofseriesLecture Notes in Computer Scienceen
dc.rights© Springer International Publishing Switzerland 2016. This work has been made available online in accordance with the publisher’s policies. This is the author created accepted version manuscript following peer review and as such may differ slightly from the final published version. The final published version of this work is available at https://doi.org/10.1007/978-3-319-41135-4_12en
dc.subjectFormal certificationen
dc.subjectPredicate testingen
dc.subjectProof assistanten
dc.subjectQA75 Electronic computers. Computer scienceen
dc.subjectTheoretical Computer Scienceen
dc.subjectComputer Science(all)en
dc.subjectDASen
dc.subject.lccQA75en
dc.titleAutomatic predicate testing in formal certification : you’ve only proven what you’ve said, not what you meant!en
dc.typeConference itemen
dc.description.versionPostprinten
dc.contributor.institutionUniversity of St Andrews. School of Computer Scienceen
dc.identifier.doihttps://doi.org/10.1007/978-3-319-41135-4_12


This item appears in the following Collection(s)

Show simple item record