making mathematical reasoning fun: a workshop for educators

Computer Science School of Computing Clemson University

Making Mathematical Reasoning Fun: A Workshop for Educators

Jason Hallstrom (Clemson)Joan Krone (Denison)

Joseph E. Hollingsworth (IU Southeast)Murali Sitaraman(Clemson)

This workshop is funded in part by NSF grant DUE-1022941


Part I: Overview

School of Computing Clemson University

Goals

Reasoning Across the Curriculum Not just in Discrete Math Fundamental part of CS Motivating example: binary search

“proven” correct Supporting Tools Supporting Methods Applicable to both large universities and

small colleges Students who can write reliable

software 3


Continuing List of Partners

Alabama Clemson Cleveland State Denison Depauw IU Southeast NC State Ramapo College Virginia Tech NVC Western Carolina 4


What reasoning skills are necessary?Concept Inventory

Boolean Logic Standard Logic Symbols, Standard Proof Techniques

Discrete Math Structures Sets, Strings, Numbers, Relations, and other mathematical theories as needed

Precise Specifications Mathematical Descriptions of Software interfaces for clients and implementers.Math models for structuresPre and Post conditions for operations.

Modular Reasoning Each Module needs to be proven correct only once.

Verification Conditions Mathematical Assertions equivalent to the correctness of the program.

Correctness Proofs Application of Proof Techniques to the program

http://www.cs.clemson.edu/resolve/teaching/inventory.html


Why?

Current software is too large for one person to understand.

Students need tools for dealing with all sizes of projects.

Maintenance makes up the majority of jobs.

Students need to separate specifications from implementations.


Courses at All Levels

Beginning level: CS110 – Intro to Programming, CS174 – Discrete math at Denison Use of collaborative approach Use of specifications Reasoning assistant tool

7


Intermediate level: CPSC215 – Software Foundations at Clemson Contract specifications – comparing

informal specs with formal specs Mathematical modeling – abstraction Generating test data from specs Reasoning assistant tool

8


Advanced level: CS373 –Programming Languages and CS349 – Software Engineering at Denison, CP372 – Software Engineering at Clemson Formal specifications Proofs VC generator tool Contract-based team development using

RESOLVE compiler

9


All Levels

Collaborative Approach Pairs or small groups In class or homework

10


Collaborative Method

Pairs or small groups With or without tools Each team presents their findings Collaboration both within teams and

among teams

11


Selective Adaptation

Pick and choose appropriate reasoning concepts and/or tools

Faculty expertise Student background

12


13

One Example: Software Engineering Course

Usual Topics Requirements analysis Design and specification Component-based implementation Quality assurance

Formal Reasoning


14

Objectives

Read formal specifications Create test points from the specs

Use component specifications to build larger systems Work in teams

Carry out formal verification of components Use automated rules


15

Methods

Collaborative learning Teams of 2 to 4 members Read specs Implement specs Verify implementations Build larger systems.


Using the Tools

http://resolve.cs.clemson.edu/interface

16


Summary

Importance of Reasoning across the Curriculum

Tools to Support Reasoning Collaborative Pedagogy includes

collaboration between students and between students and faculty

17


Part II: Introduction to Reasoning


Mathematical Reasoning

Goal: To prove correctness Method: Use a reasoning technique

from the logic & proofs section of discrete math

Prove correctness on all valid inputs


Simple Example: Prove Correctness

Code:…i := i – 1;Confirm i = 17;

What should i be prior to the assignment statement so that we can confirm that i = 17 after the assignment?


Sweep Confirm Backwards

…i := i – 1;Confirm i = 17;

• Drive the Confirm statement backwards through the code, using substitution.

• In this case substitute for variable i in the Confirm statement, then simplify• …

Confirm i - 1 = 17;


Simplify

Confirm i – 1 = 17;Becomes:

Confirm i = 18


Final Result

…Confirm i = 18i := i – 1;Confirm i = 17;


2nd Example: Prove Correctness

Spec: Operation Do_Nothing (i: Integer);

ensures i = #i;

Code:i := i + 1;i := i – 1;

Note:• #i represents the incoming value• i represents the outgoing value

School of Computing Clemson UniversityProof Setup

Assume i = #i;i := i + 1;i := i – 1;

Confirm i = #i;

School of Computing Clemson UniversitySweep Backward Through Decrement

Assume i = #i;i := i + 1;

Confirm ???i := i – 1;

Confirm i = #i;

After sweep:Assume i = #i;

i := i + 1;Confirm i – 1 = #i

School of Computing Clemson UniversitySweep Backward Through Increment

Assume i = #i; Confirm ???

i := i + 1; Confirm i - 1 = #i;

After sweep:Assume i = #i;

Confirm (i + 1) – 1 = #i

School of Computing Clemson UniversitySimplify & Use Logic

Assume i = #i; Confirm (i + 1) – 1 = #iAfter simplification:

Assume i = #i; Confirm i = #i

Rewrite using logical implication:Implication statement format: p -> qp – represents Assume statementq – represents Confirm statement

Result:i = #i -> i = #i

School of Computing Clemson UniversityProof

The following implication is always true:p -> p

Therefore this logical expression is true:i = #i -> i = #i

Or, do the proof using the facts:•Use facts from left hand side of implication•Substitute into the right hand side

Fact from left hand side:i = #i

Substitute so the right hand side becomes:#i = #i

School of Computing Clemson UniversityWhat did we just prove?

We proved that the implementation for the Do_Nothing operation satisfied its ensures clause

Operation Do_Nothing (i: Integer);ensures i = #i;

Code:i := i + 1;i := i - 1;


3rd Example: Prove Correctness

Spec: Operation Do_Nothing (i: Integer);

requires (i >= min_int) and (i < max_int);ensures i = #i;

Code:i := i + 1;i := i – 1;

School of Computing Clemson UniversityProve it is OK to subtract 1 from i

Assume (i >= min_int) and (i < max_int);i := i + 1;

Confirm i > min_int;i := i – 1;

•We must confirm that i > min_int just prior to subtracting 1 from i•So we introduce a “Confirm” statement just prior to the line of code: i := i – 1;


Assume (i >= min_int) and (i < max_int);Confirm ???

i := i + 1; Confirm i > min_int;

i := i – 1;

•Use backwards sweep method again


Assume (i >= min_int) and (i < max_int);Confirm i + 1 > min_int;

i := i – 1;

Rewrite using logic’s implication: p -> q

(i >= min_int) and (i < max_int) -> i + 1 > min_int

Use left hand side facts to prove right hand side:•Fact: i >= min_int •Therefore: i + 1 > min_int

School of Computing Clemson UniversityProve it is OK to add 1 to i

Assume (i >= min_int) and (i < max_int); Confirm i < max_int;

i := i + 1;i := i – 1;

•We must confirm that i < max_intjust prior to adding 1 to i•So we introduce a “Confirm” statement just prior to the line of code: i := i + 1;

School of Computing Clemson UniversityProve it is OK to add 1 to i

Assume (i >= min_int) and (i < max_int);Confirm i < max_int;

i := i + 1;

Rewrite using logic’s implication: p -> q

(i >= min_int) and (i < max_int) -> i < max_int

Use left hand side facts to prove right hand side:•Fact: i < max_int•Therefore: i < max_int


Part II: Mathematical Modeling


Some mathematics is implicit

We view programming integers as though they are mathematical integers (subject to bounds, of course)

We associate mathematical operators (e.g., +) with operations we can do on integers in programs (e.g., +)

This can be made explicit


Mathematical modeling

Type Integer is modeled by Z; Constraints for all i: Integer,

min_int <= i <= max_int;


Alternatively…

Type Integer is modeled by Z; Let i be an example Integer; Constraints

min_int <= i <= max_int;


Initial value specification…

Type Integer is modeled by Z; exemplar i; Constraints

min_int <= i <= max_int; initialization ensures i = 0;


Specification of operations …

Type Integer is modeled by Z; …

specification of operations, e.g., i++ Operation Increment

(updates i: Integer); requires i < max_int; ensures i = #i + 1;


More examples …

What is a suitable way to model the state of a light bulb? …


More examples …

Type Light_Bulb_State is modeled by B;

exemplar b; Initialization ensures b = false;

Exercises: specification of operations Turn_On, Turn_Off, and Is_On


More examples …

How would you model the state of a traffic light? …

Alternative models and discussion


Data abstraction examples …

How would you mathematically model a the contents of a stack? Is a set model appropriate? Why or why not?

What about a queue?


Mathematical Modeling Summary

To write formal specifications, we need to model the state mathematically

Some objects we use in programming, such as Integers and Reals, have implicit models

For others, such as stacks, queues, lists, etc., we need to conceive explicit mathematical models


Part IV: Mathematical Reasoning with Objects


Example

Specification:Operation Do_Nothing (restores S: Stack);

Goal: Same as ensures S = #S;Code:

Procedure Do_Nothing (restores S: Stack);

Var E: Entry;Pop(E, S);Push(E, S);

end Do_Nothing;


Mathematical Modeling of Stacks

Concept Stack_Template(type Entry; Max_Depth: Integer);

uses String_Theory;

Type Family Stack is modeled by …

Operation Push…Operation Pop……

end Stack_Template;


Concept Stack_Template(type Entry; Max_Depth: Integer);

uses String_Theory;

Type Family Stack is modeled by Str(Entry);

exemplar S;constraints |S| <= Max_Depth;initialization ensures S = empty_string;

…

end Stack_Template;

Mathematical Modeling of Stacks


Specification of Stack Operations

Operation Push (alters E: Entry; updates S: Stack);requires |S| < Max_Depth;ensures S = <#E> o #S;

Operation Pop (replaces R: Entry; updates S: Stack);requires |S| > 0;ensures #S = <R> o S;

Operation Depth (restores S: Stack): Integer;ensures Depth = |S|;

…


Alternative Specifications of Pop

Operation Pop (replaces R: Entry; updates S: Stack);requires |S| > 0;ensures #S = <R> o S;

Operation Pop (replaces R: Entry; updates S: Stack);requires |S| > 0;ensures R = First(#S) and S = Rest(#S);


Example

Specification:Operation Do_Nothing (restores S: Stack);

Goal: Same as ensures S = #S;Code:

Procedure Do_Nothing (restores S: Stack);

Var E: Entry;Pop(E, S);Push(E, S);

end Do_Nothing;


Establishing ensures clause of Do_Nothing

Given: S = #S and |S| ≤ Max_Depth;Pop(E, S);Push(E, S);

Goal: S = #S;


Effect of Push

Given: S = #S and |S| ≤ Max_Depth;Pop(E, S);S <E> o <S>;

Goal: S = #S;


Given: S = #S and |S| ≤ Max_Depth;Pop(E, S);Push(E, S);

Goal: S = #S;


Effect of Push

Given: S = #S and |S| ≤ Max_Depth;Pop(E, S);S <E> o <S>;

Goal: S = #S;


Given: S = #S and |S| ≤ Max_Depth;Pop(E, S);

Goal: <E> o S = #S;


Effect of Pop

Given: S = #S and |S| ≤ Max_Depth;E First(S) S Rest(S)

Goal: <E> o S = #S;


Example


Goal: <E> o S = #S;


Effect of Pop


Goal: <E> o S = #S;


Example

Given: S = #S and |S| ≤ Max_Depth;

Goal: < First(S) > o Rest(S) = #S;



Given: S = #S and |S| ≤ Max_Depth;

Goal: S = #S;



true;


Establishing requires clause of Push


Goal: |S| < Max_Depth;Push(E, S);




Goal: |S| < Max_Depth;



Given: S = #S and |S| ≤ Max_Depth;Goal: |Rest(S)| < Max_Depth;



true;


Establishing requires clause of Pop

Given: S = #S and |S| ≤ Max_Depth;Goal: |S| > 0;

Pop(E, S);


Establishing requires clause of Pop



Not provable without a requires clause for Do_Nothing



Discussion

Is the code Correct? If not, fix it Important Idea: The reasoning can be

done mechanically Principles of reasoning about all

objects and operations are the same Need mathematical specifications

VC generation and automated verification demo


More Mathematical Reasoning

Create the example using the web interface, generate VCs, and prove them

For recursive implementations Recursive calls are handled just as

any other call Need to show termination using a

programmer-supplied decreasing “metric”

For iterative implementations, invariants and decreasing metrics are used


Reasoning with RESOLVE Web IDE

Murali SitaramanClemson University


A Second Web Interface Demo

Select Queue_Template under components 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?



Select Queue_Template under Concepts

Select Append_Capability under the tab Enhancements

Select Iterative_Realiz under the Tab Enhancement Realizations

The loop is annotated with two assertions for verification an invariant (maintaining clause) A progress metric (decreasing clause)





Select Reursive_Realiz under the Tab Enhancement Realizations

Click on Generate VCs Prove each VC


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!


Iterative Code Demo



Select Iterative_Realiz under the Tab Enhancement Realizations Loops are annotated with invariants,

progress metrics Click on Verify button The VCs here turn out to be provable

automatically

making mathematical reasoning fun: a workshop for educators

Documents

current software

reliable software

cp372 software engineering

cs349 software engineering

cpsc215 software foundations

clemsoncontract specifications

mathematical reasoning

levelsbeginning level