Scalability of Deductive Verification Depends on Method Call Treatment

Knüppel, Alexander; Thüm, Thomas; Padylla, Carsten; Schaefer, Ina

doi:10.1007/978-3-030-03427-6_15

Cited by 6 publications

(5 citation statements)

References 36 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Definition 6) and the metaproduct with KeY and trace the number of open (i.e., failed) proofs. We further measure the required verification effort with commonly used metrics, namely the number of KeY-internal proof steps/branches and the required time [1,22]. We perform our evaluation with 5 repetitions (plus JVM warm up) on a quad-core 2.3 GHz CPU with 12 GB of RAM and were able to reproduce the results on another machine.…”

Section: Discussionmentioning

confidence: 99%

Verification Strategies for Feature-Oriented Software Product Lines

Kuiter

Knüppel

Bordis

et al. 2022

Proceedings of the 16th International Working Conference on Variability Modelling of Software-Intensive Systems

Self Cite

View full text Add to dashboard Cite

Highly-customizable software systems in form of software product lines are becoming increasingly relevant for safety-critical systems, in which the correctness of software is a major concern. To ensure the correct behavior of a software product line, each product can be verified in isolation-however, this strategy quickly becomes infeasible for a large number of products.In this paper, we propose proof plans, a novel strategy for verifying feature-oriented software product lines based on partial proofs. Our technique splits the verification task into small proofs that can be reused across method variants, which gives rise to a wider spectrum of verification strategies for software product lines. We describe applications of our technique and evaluate one of them on a case study by comparing it with established verification strategies. CCS CONCEPTS• Software and its engineering → Software product lines; Formal software verification.

show abstract

Section: Discussionmentioning

confidence: 99%

Verification Strategies for Feature-Oriented Software Product Lines

Kuiter

Knüppel

Bordis

et al. 2022

Proceedings of the 16th International Working Conference on Variability Modelling of Software-Intensive Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…The use of contracts, rather than inlining, can greatly speed up time required for running the automated verification, as witnessed by experiments in KeY done by Knüppel et al [15]. Obviously, using inlining for program verification can avoid the need of even having to write contracts.…”

Section: Fig 3 Methods Without a Contractmentioning

confidence: 99%

“…This makes static verification with JML highly modular: implementations can be changed freely as long as the contract remains provable, and the rest of the verification effort will remain valid. For a detailed analysis on the benefits of using contracts for verification (over inlining), see the work by Knüppel et al [15], which includes experiments in KeY.…”

Section: Background: Static Verification With Key and Openjmlmentioning

confidence: 99%

Reasoning About JML: Differences Between KeY and OpenJML

Boerman

Huisman

Joosten

2018

Lecture Notes in Computer Science

View full text Add to dashboard Cite

To increase the impact and capabilities of formal verification, it should be possible to apply different verification techniques on the same specification. However, this can only be achieved if verification tools agree on the syntax and underlying semantics of the specification language and unfortunately, in practice, this is often not the case. In this paper, we concentrate on one particular example, namely Java programs annotated with JML, and we present a case study in understanding differences in the treatment of these specifications. Concretely, we take a collection of JML-annotated programs, that we tried to reverify using KeY and OpenJML. This effort led to a list of syntactical and semantical differences in the JML support between KeY and OpenJML. We discuss these differences, and then derive some general principles on how to improve interoperability between verification tools, based on the experiences from this case study.

show abstract

“…The implementation of that method can either be in CorC or in Java. For the verification of a method call, CorC supports inlining and contracting [28] (i.e., inserting its implementation or using its contract as defined in the CbC method call refinement rule). When contracting is used, it is assumed that the contract holds for that method, however, this is not specifically verified in this step.…”

Section: Object-oriented Concepts In Corc 20mentioning

confidence: 99%

Re-CorC-ing KeY: Correct-by-Construction Software Development Based on KeY

Bordis

Cleophas

Kittelmann

et al. 2022

The Logic of Software. A Tasting Menu of Formal Methods

Self Cite

View full text Add to dashboard Cite

Deductive program verification is a post-hoc quality assurance technique following the design-by-contract paradigm where correctness of the program is proven only after it was written. Contrary, correctness-by-construction (CbC) is an incremental program construction technique. Starting with the functional specification, the program's correctness is guaranteed by application of a small set of refinement rules. Even though CbC is supposed to lead to code with a low defect rate and improve the traceability of errors, it is not widespread. One of the main reasons is insufficient tool support which we addressed with our tool CorC. CorC provides support for CbC-based program construction with the KeY program verifier as backend prover for checking correctness of refinement rule applications. However, CorC was limited to constructing single method bodies restricting its applicability. In this work, we introduce and discuss CorC 2.0, which extends CorC's programming model with objects as used in object-oriented programming. We integrate CorC into a development process that allows to use posthoc verification and CbC interchangeably to construct correct programs, and scale the applicability of CbC on the architectural level in our tool extension ArchiCorC. We developed three object-oriented case studies and evaluated the verification effort and the usability of CorC in comparison to post-hoc verification.

show abstract

Scalability of Deductive Verification Depends on Method Call Treatment

Cited by 6 publications

References 36 publications

Verification Strategies for Feature-Oriented Software Product Lines

Verification Strategies for Feature-Oriented Software Product Lines

Reasoning About JML: Differences Between KeY and OpenJML

Re-CorC-ing KeY: Correct-by-Construction Software Development Based on KeY

Contact Info

Product

Resources

About