ICATPN'06 Proceedings of the 27th international conference on Applications and Theory of Petri Nets and Other Models of Concurrency
| Hi-index | 0.00 |
There are a few standard approaches to constructing verified programs. The original approach, by Floyd, Naur and Hoare, assumes that the program code is given, together with an informal description of what the program is supposed to do. Program verification amounts to expressing the requirements as precise pre- and postconditions, finding the appropriate loop invariants, constructing the verification conditions and proving them correct. This is known as a posteriori verification. Dijkstra popularized an alternative approach, correct-by-construction, where we also start by formulating precise pre- and postconditions. Program code and loop invariants are then derived at the same time, hand in hand, and verification conditions are proved as they arise. The third possibility, invariant based programming (Reynolds, van Emden, Back, see [1]), moves the construction of program code to an even later stage. Pre- and postconditions are formulated first, as in the other approaches. The next step is then to formulate the loop invariants, before any code is written. The code is constructed last, as transitions between the different situations (precondition, postcondition, loop invariants) that can occur during program execution. The verification conditions corresponding to these transitions are verified as they arise. Traditionally, program structure is based on flow of control (conditional statements, while loops, procedures), complemented with data encapsulation (abstract data types, classes). This does not work for invariant based programming, because the transitions that describe the flow of control are introduced only late in the programming process. Nested invariant diagrams provide a graphical notation for invariant based programs where the program structure is determined by the information that we have in the different situations. The situations are expressed as sets of states, and program code as transitions between these sets. Nesting of invariants provides an extension hierarchy that allows us to express the program invariants in a very compact manner.