An Exercise in Invariant-based Programming with Interactive and Automatic Theorem Prover Support

Invariant-Based Programming (IBP) is a diagram-based correct-by-construction programming methodology in which the program is structured around the invariants, which are additionally formulated before the actual code. Socos is a program construction and verification environment built specifically to support IBP. The front-end to Socos is a graphical diagram editor, allowing the programmer to construct invariant-based programs and check their correctness. The back-end component of Socos, the program checker, computes the verification conditions of the program and tries to prove them automatically. It uses the theorem prover PVS and the SMT solver Yices to discharge as many of the verification conditions as possible without user interaction. In this paper, we first describe the Socos environment from a user and systems level perspective; we then exemplify the IBP workflow by building a verified implementation of heapsort in Socos. The case study highlights the role of both automatic and interactive theorem proving in three sequential stages of the IBP workflow: developing the background theory, formulating the program specification and invariants, and proving the correctness of the final implementation.

💡 Research Summary

The paper presents Socos, an integrated development and verification environment designed to support Invariant‑Based Programming (IBP), a methodology that places program invariants at the heart of software construction. IBP requires that invariants be formulated before any executable code, and that the program be built around these correctness conditions. Socos implements this philosophy through a two‑layer architecture. The front‑end is a graphical diagram editor where developers draw state‑transition diagrams, annotate each node with pre‑ and post‑conditions, and specify loop invariants. The back‑end automatically extracts verification conditions (VCs) from the diagram, dispatches them to an SMT solver (Yices) for fast, fully‑automatic discharge, and forwards any remaining VCs to the theorem prover PVS for interactive proof.

The authors first describe the user workflow: (1) constructing a diagram, (2) defining the background theory, (3) writing the specification and invariants, and (4) invoking the checker. From a systems perspective they detail how the diagram is translated into an intermediate representation, how VCs are generated for each transition, and how a pipeline of solvers is orchestrated. Yices handles arithmetic, array indexing, and simple Boolean constraints, while PVS is employed for higher‑order reasoning, inductive proofs, and properties that SMT solvers cannot resolve automatically.

To demonstrate the approach, the paper walks through a complete case study: a verified implementation of heapsort. The case study is divided into three sequential stages that mirror the IBP workflow.

1. Background Theory Development – The authors formalize heaps, partial orders, array slices, and the exchange operation in PVS. They prove essential lemmas such as the preservation of the heap property under the heapify operation and the correctness of the swap primitive. Because these lemmas involve inductive arguments over array indices, they are proved interactively in PVS.

2. Specification and Invariant Formulation – Using the Socos diagram editor, the heapsort algorithm is decomposed into two major phases: heap construction and repeated extraction of the maximum element. For each loop, a loop invariant is written that captures (a) the heap property on the unsorted portion of the array, (b) the sorted suffix, and (c) bounds on the loop counter. The diagram visually links each invariant to its corresponding program fragment, allowing immediate feedback when an invariant is too weak or inconsistent.

3. Implementation Verification – The concrete code (written in a Socos‑compatible language) is attached to the diagram edges. The verification engine generates roughly 150 VCs. Yices automatically proves the majority—mostly simple arithmetic constraints and array bounds checks. The remaining VCs, which involve the heap property and the relationship between the sorted suffix and the unsorted heap, are sent to PVS. Here the authors conduct inductive proofs that the heap invariant is maintained after each heapify call and that the extraction loop correctly moves the maximum element to the sorted suffix. Once all VCs are discharged, the heapsort implementation is formally verified to meet its specification.

The key insight highlighted by the authors is the complementary role of automatic and interactive theorem proving. SMT solving provides rapid, scalable discharge of low‑level conditions, whereas a higher‑order prover like PVS is indispensable for reasoning about recursive data structures and inductive invariants. Socos’s seamless integration of both tools lets developers focus on the “hard” proof obligations while delegating the routine ones to automation. Moreover, the diagrammatic front‑end makes the relationship between invariants and code explicit, reducing the likelihood of specification errors early in the development cycle.

The paper concludes with a discussion of future work: expanding the library of reusable background theories, supporting user‑defined proof tactics, and scaling the approach to larger software systems. By combining a visual IBP workflow with a hybrid verification back‑end, Socos demonstrates a practical pathway toward correct‑by‑construction software development.