Lecture 2 Specifications The paper is Newcombe et

Lecture 2: Specifications The paper is: Newcombe et al, How Amazon Web Services Uses Formal Methods, Comm. ACM 58, 4 (April 2015), pp 66 -73. (The paper on the course web page is an informal version dated 29 September 2014, but it appears to have the same content as the published version). The paper refers to the TLA home page. Its current link is http: //lamport. azurewebsites. net/tla. html

What are specs for? In this course n Modularity: decouple code from client n Insight: what is the module doing for me o Should be much simpler than its code n Proof o o Coq specs, proofs, extracted code Other mechanized formal methods n Model checking o o Systematically explore part of the state space Amazon does this. We don't do it in this course

What is a spec? How to model a system n

External and internal state n op OK val 10 [3, q 10]

TLA: Two-state predicate to describe actions n

Safety and liveness n

Operations vs. states n

Stages of design and verification: Write the spec “If your system doesn’t have a spec it cannot be wrong, it can only be surprising” n 1. Write down the state. n 2. Write down the interface (possible state transitions). o Name and specification. Ex: FIFO buffer n How do you know the spec is correct? Keep it simple. o o One kind of “simple” is just some property, such as memory safety By contrast, functional correctness gives all the allowed behaviors n Now it’s time to consider the code that satisfies the spec

Is the code correct? n

Stages of design and verification: Abstraction and proof n 1. Write down the state. n 2. Write down the interface (possible state transitions). o Name and specification. Ex: FIFO buffer n 3. Write the abstraction function/relation from the code. o o This gives insight into why the code works Is it right? Unfortunately, need the proof to decide. n 4. Do a simulation proof. o A lot of work: consider every action from every reachable state ▬ ▬ This is seldom worthwhile: by far the most work, for the least payoff. But it’s the only way to know that you got abstraction function right.

Model checking. n Amazon: For us, model checking dramatically beats proof. o o Why? It’s automatic, and it finds most bugs, which show up on small examples. n This is very different from formal correctness proofs in Coq. o It’s less conclusive, but much cheaper. n We don’t do model checking in this course