Automated Formal Static Analysis and Retrieval of Source Code - JKU

2.1. BACKGROUND 11
A program is seen as a black-box and from here the big advantage of DART: it does not require
any information about the termination of the modules involved.
An important practical applicability of symbolic execution for verifying safety-critical software
systems ([CPDGP01]) is SAVE (Symbolic execution Aided Verification Environment). It
handles with programs written in Safer-C ([Hat95]) programming language, a subset of C. SAVE
has the following components:
1. Execution Model Generator takes as input a program written in Safer–C and builds the corresponding
execution model, with the user intervention. The module is basically a symbolic
executor with features similar to EFFIGY and the model is, actually, a symbolic execution
tree that can be visualized due to a publicly available graph layout tool, Dotty. The nodes
of the tree represent states.
2. PDL Property Checker takes as input is an expression in PDL (Path Description Language)
language which is tested over the model generated by the Execution Model Generator. It
generates all paths of the execution model that satisfy the input specification.
3. Execution Model Inspector is used by the symbolic executor each time the symbolic states
are updated and has the role of updating the data memorized by the symbolic execution tree:
symbolic values associated to the program variable and the path condition.
SAVE was used for industrial applications; it managed to prove some important properties of
TCAS (Traffic Alert and Collision Avoidance System) – an on–board aircraft conflict detection and
resolution system used by all US commercial aircraft.
The drawback of the SAVE system (as mentioned in [KPV03]) is that it uses dedicated tool
(e.g. PDL) in order to perform the program analysis and also does not handle analysis of concurrent
programs.
The authors of [KPV03] exploit this drawback in their system, defining a translator which
allows symbolic execution to be performed using a model checker without the aid of a dedicated
tool. The translator’s output can be symbolically executed by any model checker that supports
nondeterministic choice. Program analysis is performed then by manipulating logical formulae
on program data values (using a decision procedure).
The system operates as follows: the original program is translated such that it can be executed
using any model checker that supports backtracking and nondeterministic choice to perform
symbolic execution. Code instrumentation and was done on top on Korat ([BKM02]). Then,
the model checker used, Java PathFinder ([VHBP00]), checks the translated program using its
state (heap configuration, path condition on primitive fields and thread scheduling) exploration
approaches. A path condition is checked for satisfiability each time it is updated using appropriates
decision procedures from the Omega library ([Pug92]). If the path condition is unsatisfiable,
the model checker backtracks. The translated program can be supplied with specification in a
language known by the model checker or a predicate abstraction upon which is checked the correctness.
Counterexamples that violate the specification are provided while the correctness is
checked. Test data are generated for the program paths that are witnesses of the specification criteria.
Recent progress of this work was made in [PV04] by dealing with automatically generation
of loop invariants for programs dealing also with arrays and dynamically allocated structures.