Abstract
Verification tools are often the result of several years of research effort. The development happens as a distributed effort inside academic institutes relying on the ability of senior investigators to ensure continuity. Quality attributes such as usability are unlikely to be targeted with the same accuracy required for commercial software where those factors make a financial difference. In order for such tools to become of widespread use, it is therefore necessary to spend an extra effort and attention on users' experience, and allow software engineers to benefit out of them without the necessity of understanding the mathematical machinery in full detail. In order to put the spotlight on usability of verification tools we chose an automated verifier for the Eiffel programming language, AutoProof, and a well-known benchmark, the Tokeneer problem. The tool is used to verify parts of the implementation of the Tokeneer so to identify AutoProof's strengths and weaknesses, and finally propose the necessary updates. 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.
Highlights
Tools for software verification allow the application of theoretical principles in practice, in order to ensure that nothing bad will ever happen
This paper reports on the use of AutoProof to verify an Eiffel implementation of Tokeneer and reports on how easy/difficult is for users to use the tool, e.g. the burden of helping the tool by means of annotations in the code
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]
Summary
Tools for software verification allow the application of theoretical principles in practice, in order to ensure that nothing bad will ever happen (safety). NSA carried out this challenge to prove that it is possible to develop secure systems rigorously in a cost effective manner Since its development, it became a testing range for different software development methodologies and verification tools. In 2002, with the aim to prove/disprove the common believe in industry that development of software of high level of assurance is too expensive and not feasible, the National Security Agency (NSA) asked Altran to undertake a research project to develop part of an existing secure system, the Tokeneer System, in accordance with Altran's Correctness by Construction development process. The project was successfully delivered in 2003 within 260 days of effort, and later, in 2008, all the results were made available by NSA to the software development and security communities in order to demonstrate the possibility to develop secure systems in a cost effective manner.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
