Lecture 18 March 29, 2011 Formal Methods 3 CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)

Example Specification Operation Do_Nothing (restores S: Stack) Goal: Same as ensures S = #S Code: (Same as S.Push(S.Pop()) in Java) Procedure Do_Nothing (restores S: Stack) Var E: Entry Pop(E,S); Push(E,S); end Do_Nothing; CS 315 Spring

Exercise: Complete Table and Prove AssumeConfirm 0…… Pop(E, S); 1…… Push(E, S); 2…… CS 315 Spring Not Yet …

General Stack Template Specification Instead of IntStacks, we will use general stacks for this example reasoning Suppose Stack_Template is parameterized by type Entry and Integer Max_Depth Mathematical Modeling Type Stack is modeled by Str(Entry); exemplar S; constraints |S| <= Max_Depth; initialization ensures S = empty_string CS 315 Spring

Specification of Stack Operations Operation Push (alters E: Entry; updates S: Stack) requires |S| < Max_Depth; ensures S = o #S; Operation Pop (replaces R: Entry; updates S: Stack) requires |S| > 0; ensures #S = o S; Operation Depth (restores S: Stack): Integer ensures Depth = |S|; CS 315 Spring

Exercise: Complete Table and Prove AssumeConfirm 0…… Pop(E, S); 1…… Push(E, S); 2…… CS 315 Spring

Exercise: Complete Table and Prove AssumeConfirm 0…|S0| > 0 Pop(E, S); 1S0 = o S1|S1| < Max_Depth Push(E, S); 2S2 = o S1S2 = S0 CS 315 Spring Answers

Discussion Can you explain why there are three confirm assertions? Is the code Correct? If not, fix it! Two options for the Fix: Rewrite the code with an “if” statement Add the following clause to Do_Nothing requires |S| > 0; CS 315 Spring

Key Ideas Reasoning table can be filled out mechanically Can be done automatically by a computer Principles of reasoning about all objects and operations are the same Need mathematical models and specifications CS 315 Spring

Automated Reasoning The assume and confirm assertions we wrote in the table can be generated automatically Each confirm assertion becomes a “goal” The assumptions that can be used to prove a goal are called “givens” A goal along with the givens is called a verification condition (VC) For the Do_Nothing example, three VCs need to be proved, because ther are three assertions to be confirmed CS 315 Spring

Web Interface Demo Google “clemson resolve” Click on the Web Interface Link Select Stack_Template under Concepts Select Do_Nothing_Capability under the Tab Enhancements Select Do_Nothing_Realiz under the Tab Enhancement Realizations CS 315 Spring

Web Interface Demo Click on the Generate VCs Tab You should see 3 VCs. See if you can prove the goals from the givens! It should be easy … Note #1: The VC generation process minimize the needs for new names such as s1, s2, s3, etc., so there are fewer names Note #2: VC generator uses s’, s’’, etc., instead of s1, s2, etc. Also don’t assume that s1 corresponds to s’, etc. CS 315 Spring

A Second Web Interface Demo Select Queue_Template under Concepts Notice that queues also happen to be modeled using mathematical strings How does the specification of Enqueue differ from Push, if any? How does the specification of Dequeue differ from Pop, if any? CS 315 Spring

A Second Web Interface Demo Select Queue_Template under Concepts Select Append_Capability under Enhancements Select Iterative_Realiz under Enhancement Realizations The loop is annotated with two assertions for verification An invariant (maintaining clause) A progress metric (decreasing clause) CS 315 Spring

A Second Web Interface Demo Select Queue_Template under Concepts Select Append_Capability under Enhancements Select Iterative_Realiz under Enhancement Realizations Click on Generate VCs Prove each VC CS 315 Spring

Wrong Code Demo Go back to Recursive_Realiz by clicking on the RESOLVE tab to the left Click the Edit button Do each of the following and see if the VCs are provable in each case Comment out the Dequeue operation (use -- at the front of the line) Change the decreasing metric from |Q| to |P|; now our termination reason is wrong CS 315 Spring

Iterative Code Demo Select Queue_Template under Concepts Select Append_Capability under Enhancements Select Iterative_Realiz under Enhancement Realizations Loops are annotated with invariants, progress metrics Click on the Verify button The VCs here turn out to be provable automatically CS 315 Spring

Iterative Code Demo Select Queue_Template under Concepts Select Append_Capability under Enhancements Select Iterative_Realiz under Enhancement Realizations Loops are annotated with invariants, progress metrics Click on the Verify button The VCs here turn out to be provable automatically CS 315 Spring

Web Interface Help Click the Help tab on the right top corner You should see Screencasts. They illustrate “how to” for various web interface activities; more use cases continue to be added. You should see Tutorials. The help learn specific principles; more tutorials are under development. CS 315 Spring