A formal software verification concept based on automated theorem proving and reverse engineering

Abstract

Formal software verification typically involves some level of static theorem proving which is a mathematical process of proving that the function computed by a program match the function specified. A theorem prover, such as THEO automates this process. On the other hand, reverse engineering is a process inverse to traditional engineering. An example is extracting software specification from its source code. Both subjects have been widely addressed in literature but there is still the need for additional research efforts in this area. In this paper we present a formal software verification concept, which is based on automated theorem proving and reverse engineering.We are mainly concerned with communications software and with software for families of communication protocols in particular. In the paper we describe how to: (i) model a group of finite state machines using predicate calculus, (ii) extract axiomatic software specification from the source code and log files, and (iii) formally verify software for a given operational profile (set of test cases). The concept has been successfully applied to a call processing software for systems, which are installed and fully operational in Moscow and Saint Petersburg, Russia.

Critical Embedded Systems Development Using Formal Methods and Statistical Reliability Metrics

“…The first is the use of model checking with software, and the second is the improvement of ATPs. One area of use for model checking is for reverse engineering a system [34]. Since automated implementation is not available yet for specifications written in formal methods, the reverse engineering process uses the implementation to move back to a specification, verifying it is correct with model checking, and then verifying the original specification and reverse engineering specification are correct with respect to each other.…”

A case for alloy annotations for efficient incremental analysis via domain specific solvers

“…are we building the right system [2] [3][4] [5]. Some techniques rely on formal specifications to describe structural properties [3] [6] or define runtime behaviour [7][8] of software systems. A benefit of using formal specifications is they are amenable to automated analysis which is faster, consistent, and less error prone.…”

A concept of an integrated development environment for reactive systems

“…The specification of FSM as a set of WFFs is used as axiom for a set of theorems, corresponding to individual test cases, used for formal verification of the software implementing an individual FSM or a group of FSMs [17]. In the beginning those theorems were written manually, in the perspective they will be generated automatically from the source code of a FSM, or a group of FSMs.…”