Transparency Masters for Software Engineering: A Practitioner's Approach, 4/e

Lecture 16March 22, 2011Formal MethodsCS 315 Spring 20111Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)Requirements vs. SpecificationsRequirements definitionIntended for customers in addition to software developersInformal descriptions are necessary

SpecificationFor use by members of a software development teamFormal (mathematical) descriptions are necessaryInterface SpecificationServes as a contract between component users (clients) and developers (implementers)

Typically describes the demands on users and responsibilities for implementers

Should present the essentials in user-oriented terms (abstraction) and hide the inessentials (information hiding)Informal Specification:ExamplesC++ STL Template specificationsJava util component specificationshttp://doc.java.sun.com/DocWeb/api/java.util.Stackhttp://doc.java.sun.com/DocWeb/api/java.util.Queue

Questions for discussionDo they support information hiding?Do they support abstraction?Can they generalize?Is it possible to make them unambiguous?Informal SpecificationsStraightforward descriptionsPush pushes an object on a stackHow much do they help?

Use of metaphorsA Queue is like a line at a fast food restaurantDo they generalize?

Use of implementation detailsPush behaves like AddElement method on VectorIs this appropriate for a user-oriented cover story?CS 315 Spring 20115Informal SpecificationsSee Bertrand Meyers article on Formal Specifications in IEEE Computer

Problems with even very carefully designed informal specsContradictionNoiseCS 315 Spring 20116Formal Interface SpecificationCommunicates precisely the demands and responsibilities to component users and developers

Allows for independent development of client and implementation components in parallel in a team environment

Minimizes integration costsCS 315 Spring 20117Reasoning BenefitsFormal Specifications make it possible to formally reason about correctness of software

Such reasoning may be manual or mechanical (i.e. with automate support)CS 315 Spring 20118Languages for Formal SpecificationANNA (and SPARK) for AdaJML for JavaLarch/C++ for C++Spec# for C3EiffelRESOLVEVDMZCS 315 Spring 20119Specification Language SummarySome specification languages are designed for particular programming languages

Some are general purpose

Some specification languages are integrated with programming constructs

A few additionally integrate the ability to perform formal mathematical reasoningCS 315 Spring 201110Introduction to Mathematical ReasoningCS 315 Spring 201111Motivating ExampleWhat does the following code do to Integer I, where Foo1 and Bar1 are functions that modify their argument?

I = Foo1(I);I = Bar1(I);CS 315 Spring 201112Motivating ExampleOr, what does this code do to integers I and J?

I = Foo2(I,J);J = Bar2(I,J);I = Bar2(I,J);CS 315 Spring 201113Motivating ExampleNow, what does this code do to Integer I?

I = Next(I);I = Prev(I);

How sure are we?

Have to account for bounds in our analysis

Summary: Need formal descriptions beyond just namesCS 315 Spring 201114Motivating ExampleWhat does this code do to Integers I and J?

I = Sum (I,J);J = Difference (I,J);I = Difference (I,J);

How sure are we?CS 315 Spring 201115Specification of Integer OperationsThink of ints as integers in math

Constraints, for all Integers I:Min_Int Min_IntDecrement (I);2I2 I1 - 1I2 = I0CS 315 Spring 201130More assertions to be confirmed (Why?)Basics of Mathematical ReasoningSuppose you are verifying code for some operation PAssume its required clause in state 0Confirm its ensures clause at the end

Suppose that P calls QConfirm the requires clause of Q in the state before Q is called. Why? Because caller is responsibleAssume the ensures clause of Q in the state after Q. Why?Because Q is assumed to work

Prove assertions to be confirmedCS 315 Spring 201131Mathematical Reasoning:Example 2 Prove CorrectnessSpec:Operation Do_Nothing (updates I: Integer);ensures I = #I;

Code:If (I < Max_Int()) thenIncrement(I);Decrement(I);end;CS 315 Spring 201132Mathematical Reasoning:Example 2 Prove CorrectnessThese specs are the same

Spec:Operation Do_Nothing (updates I: Integer);ensures I = #I;

Spec:Operation Do_Nothing (restores I: Integer);

CS 315 Spring 201133Mathematical Reasoning:Example 2 Prove CorrectnessConditionAssumeConfirm0If (I < Max_Int())1 Increment (I);2 Decrement (I);3End;4I4 = I0CS 315 Spring 201134Establish the goals in state-oriented terms using a tableMathematical Reasoning:Example 2 Prove CorrectnessConditionAssumeConfirm0If (I < Max_Int())1I0 < max_int Increment (I);2I0 < max_int Decrement (I);3I0 < max_intEnd;4I4 = I0CS 315 Spring 201135Establish the conditionsMathematical Reasoning:Example 2 Prove CorrectnessConditionAssumeConfirm0If (I < Max_Int())1I0 < max_int Increment (I);2I0 < max_int Decrement (I);3I0 < max_intEnd;4.1not(I0 < max_int)I4 = I0I4 = I04.2I0 < max_intI4 = I3I4 = I0CS 315 Spring 201136Establish sub-goals for different conditionsMathematical Reasoning:Example 2 Prove CorrectnessConditionAssumeConfirm0If (I < Max_Int())1I0 < max_intI1 = I0 Increment (I);2I0 < max_intI2 = I1 + 1 Decrement (I);3I0 < max_intI3 = I2 - 1End;4.1not(I0 < max_int)I4 = I0I4 = I04.2I0 < max_intI4 = I3I4 = I0CS 315 Spring 201137Fill in other assumptions and obligations as beforeMathematical Reasoning:Example 2 Prove CorrectnessProve the subgoal(s)

4.1 Case: not(I0 < max_int)Prove I4 = I0True from assumption

4.2 Case: (I0 < max_int)Prove I4 = I0Prove: I3 = I0(assumption in state 4)Prove: (I2 1) = I0(assumption in state 3)CS 315 Spring 201138Mathematical Reasoning:Example 2 Prove CorrectnessFor the condition (I0 < max_int), additional proofs are needed

These proofs of assertion to be confirmed in States 1 and 2 are left as exercises.CS 315 Spring 201139