The AutoProof Verifier: Usability by Non-Experts and on Standard Code

Furia, Carlo A.; Poskitt, Christopher M.; Tschannen, Julian

doi:10.4204/eptcs.187.4

Cited by 11 publications

(9 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The case study analyzed in this paper presented good results in term of automatic discharge of verification conditions, though not comparable to others seen in literature [13]. In total there were 38 generated proof.…”

Section: Resultsmentioning

confidence: 42%

“…Of these, 22 (58%) were discharged automatically, 8 (21%) could not be satisfied, and the rest (21%) failed due to internal errors, which in our case were basically caused by the attempt to create objects in the contract, and that is not allowed by the tool. As observed before, the success of verification is unsurprisingly linked to the complexity of programs [13]. Previous literature mostly dealt with students users and university projects.…”

Section: Resultsmentioning

confidence: 94%

See 1 more Smart Citation

Usability of AutoProof: a case study of software verification

Khazeev¹,

Rivera²,

Mazzara³

et al. 2016

Proceedings of ISP RAS

View full text Add to dashboard Cite

Many verification tools come out of academic projects, whose natural constraints do not typically lead to a strong focus on usability. For widespread use, however, usability is essential. Using a well-known benchmark, the Tokeneer problem, we evaluate the usability of a recent and promising verification tool: AutoProof. The results show the efficacy of the tool in verifying a real piece of software and automatically discharging nearly two thirds of verification conditions. At the same time, the case study shows the demand for improved documentation and emphasizes the need for improvement in the tool itself and in the Eiffel IDE.

show abstract

Section: Resultsmentioning

confidence: 42%

Section: Resultsmentioning

confidence: 94%

Usability of AutoProof: a case study of software verification

Khazeev¹,

Rivera²,

Mazzara³

et al. 2016

Proceedings of ISP RAS

View full text Add to dashboard Cite

show abstract

“…In [12], AutoProof tool aiming verification of object-oriented programs based on concepts of the Hoare logic was presented with promising results. It offers a prover based on the Boogie verifier aiming Eiffel programs annotated with full-fledged functional specifications in the form of contracts that consist of pre-and postconditions, class invariants, and other kinds of annotations.…”

Section: Hoare Logicmentioning

confidence: 99%

Semantic Approach to Smart Contract Verification

Petrović

Tošić

2020

FU Aut Cont Rob

View full text Add to dashboard Cite

Vulnerabilities of smart contract are certainly one of the limiting factors for wider adoption of blockchain technology. Smart contracts written in Solidity language are considered due to common adoption of the Ethereum blockchain platform. Despite its popularity, the semantics of the language is not completely documented and relies on implicit mechanisms not publicly available and as such vulnerable to possible attacks. In addition, creating formal semantics for the higher-level language provides support to veriﬁcation mechanisms. In this paper, a novel approach to smart contact verification is presented that uses ontologies in order to leverage semantic annotations of the smart contract source code combined with semantic representation of domain-specific aspects. The following aspects of smart contracts, apart from source code are taken into consideration for verification: business logic, domain knowledge, run-time state changes and expert knowledge about vulnerabilities. Main advantages of the proposed verification approach are platform independence and extendability.

show abstract

“…Autoproof, an autoactive prover for the Eiffel specification language and a part of the EVE IDE [12], has been targeted towards non-expert student users, where they provide specifications and loop invariants to complete a student project. Similarly, FoCaLiZe is an IDE used to teach discrete mathematics and formal reasoning [13].…”

Section: Introduction and Related Workmentioning

confidence: 99%

Tool-Assisted Loop Invariant Development and Analysis

Priester

Sun

Sitaraman

2016

2016 IEEE 29th International Conference on Software Engineering Education and Training (CSEET)

View full text Add to dashboard Cite

Identification of an adequate invariant is valuablefor reasoning about the correctness of code involving a loop, informally or formally. Almost every modern system for automated verification demands that programmers annotate their code with assertions, such as invariants to facilitate automation. But many learners struggle to grasp how to arrive at an assertion that remains an invariant and is sufficiently strong to prove subsequent assertions reliant on the outcome of the loop. The objective of this research is to present a method to help understand the difficulties students face in developing suitable loop invariants, and assist them in the process. We describe results from an experimentation in a software engineering classroom where students were charged with developing verified component-based code using a web-based front end for a verifying compiler. We collected data in the background as students attempted to produce verified code with loop invariants in in-class activities and take-home projects.Initial results show what kinds of information we can expect to see and what kinds of feedback might be useful.

show abstract

The AutoProof Verifier: Usability by Non-Experts and on Standard Code

Cited by 11 publications

References 18 publications

Usability of AutoProof: a case study of software verification

Usability of AutoProof: a case study of software verification

Semantic Approach to Smart Contract Verification

Tool-Assisted Loop Invariant Development and Analysis

Contact Info

Product

Resources

About