Formal Specification Methods What Are Formal Methods? Objectives Of

Home , Bertrand Meyer, Formal specification

ICS 221 Winter 2001 Formal Specification Methods

! Use of formal notations … Formal Specification Methods ! first-order logic, state machines, etc. ! … in software system descriptions …

! system models, constraints, specifications, designs, etc. David S. Rosenblum ! … for a broad range of effects … ICS 221 ! correctness, reliability, safety, security, etc. Winter 2001 ! … and varying levels of use ! guidance, documentation, rigor, mechanisms

Formal method = specification language + formal reasoning

Objectives of Formal Methods Why Use Formal Methods?

! Verification ! Formal methods have the potential to

! “Are we building the system right?” improve both software quality and development productivity ! Formal consistency between specificand (the thing being specified) and specification ! Circumvent problems in traditional practices ! Promote insight and understanding ! Validation ! Enhance early error detection ! “Are we building the right system?” ! Develop safe, reliable, secure software-intensive ! Testing for satisfaction of ultimate customer intent systems ! Documentation ! Facilitate verifiability of implementation ! Enable powerful analyses ! Communication among stakeholders ! simulation, animation, proof, execution, transformation

! Gain competitive advantage

Why Choose Not to Use Desirable Properties of Formal Formal Methods? Specifications

! Emerging technology with unclear payoff ! Unambiguous

! Lack of experience and evidence of success ! Exactly one specificand (set) satisfies it ! Lack of automated support ! Consistency ! Lack of user friendly tools ! A specificand exists that satisfies it ! Ignorance of advances ! Completeness ! High learning curve ! All aspects of specificands are specified ! Requires perfection and mathematical sophistication ! Inference ! Techniques not widely applicable ! Consequences of the specification and properties ! Techniques not scalable of its satisfying specificands are discovered ! Too many in-place tools and techniques

Different Kinds of Formal Tool Support for Specification Languages Specification Languages

! Axiomatic specifications ! Modeling ! Defines system in terms of logical assertions ! Editors and word processors ! State transition specifications ! Analysis ! Defines system in terms of states & transitions ! Syntax checking ! Abstract model specifications ! Model checking

! Defines system in terms of mathematical model ! Proving and proof checking ! Algebraic specifications ! Property checking ! deadlock, reachability, data flow, liveness, safety, … ! Defines system in terms of equivalence relations ! Runtime checking ! Temporal logic specifications ! Synthesis ! Defines operations in terms of time-ordered assertions ! Refinement ! Concurrency specifications ! Code generation ! Defines operations in terms of concurrent event occurrences ! Test case and test oracle generation

A Closer Look: History of Axiomatic Axiomatic Specification Specification

! Formal specification in which statements in ! Attempts to put program development on a first-order predicate logic are used to define formal basis date at least to John McCarthy’s the semantics of a system and its constituent 1962 paper (w.r.t recursive functions) elements (statements, functions, modules) ! Floyd’s 1967 paper presented the first worked-out approach (in terms of flowcharts) ! Usually taken to mean specification with ! Hoare’s 1969 paper formed the basis for ! Pre-conditions much of the later work in formalized ! Post-conditions development ! Invariants ! Formal specification languages

! Point Assertions ! Formal verification

! Axiomatic semantics of programming languages

Axiomatic Specification of Hoare’s Basic Approach Programs

P {S} Q (nowadays written {P} S {Q}) {P} S {Q} ! One typically specifies (components of) whole ! If environment of S makes assertion P true programs ! And if S terminates ! S is a program, module, method, etc. ! Then assertion Q must be true ! P is the desired pre-condition of S ! But ! Q is the desired post-condition of S ! If the environment doesn’t establish P, Q need not be true ! The axiomatic semantics of the language of S ! If S doesn’t terminate, Q need not be true comprises Hoare-style axiom schemas for the ! Proving {P} S {Q} establishes partial correctness constituent statements of S ! To establish total correctness, one must also prove that S terminates, which in general is undecidable ! assignments, conditionals, loops, etc.

! Used for verifying S with respect to P and Q

A Simple Example of an Axiomatic Specification Hoare’s Axiom Schemas (I) class BankAccount is { public Amount Balance() { … } ! Axiom of Assignment public void Deposit(Amount a) {P[f/x]} x := f {P} // PRE: a > 0; // POST: Balance() = (in Balance()) + a; ! { … } Rules of Consequence ⇒ ⇒ public void Withdraw(Amount a) {P}S{Q} and Q Q’ {P}S{Q} and P’ P // PRE: a > 0 and Balance() >= a; {P}S{Q’} {P’}S{Q} // POST: Balance() = (in Balance()) – a; { … } }; ! Rule of Composition

! Can embellish with open/close, interest, {P}S1{Q} and {Q}S2{R} credit limit, ID/PIN, etc. {P}S1;S2{R}

An Example Verification: Hoare’s Axiom Schemas (II) Integer Square Root

procedure sqrt(N : Integer; R : out Integer); ! Rule of Iteration P and {C}S{P} S, T : Integer; begin {P}while C do S{not C and P} R := 0; ! P is the loop invariant, which typically must S := 1; be supplied by the specifier T := 1; ! Rules have been defined for other while S <= N loop R := R + 1; common language features T := T + 2; ! arrays, do-until, if-then, if-then-else, S := S + T; subprogram calls, … end loop; end sqrt;

Specifying the Specifying the Pre- and Post-Conditions Loop Invariant

{ pre: N >= 0 } { pre: N >= 0 } begin begin R := 0; R := 0; S := 1; S := 1; T := 1; T := 1; while S <= N loop while S <= N loop { I: (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) R := R + 1; and (R >= 0) } T := T + 2; R := R + 1; T := T + 2; S := S + T; S := S + T; end loop; end loop; end; end; { post: (R2 <= N < (R+1)2) and (R >= 0) } { post: (R2 <= N < (R+1)2) and (R >= 0) }

Verification Via Backward Verification Via Backward Substitution (I) Substitution (II) Apply Rule of Iteration and Rule of Consequence: Apply Axiom of Assignment and Rule of Consequence:

begin begin R := 0; R := 0; S := 1; S := 1; T := 1; T := 1; while S <= N loop while S <= N loop 2 2 { I: (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) { I: (T = 2*R + 1) and (S = (R+1) ) and (R <= N) and (R >= 0) } and (R >= 0) } R := R + 1; I implies { ((T+2) = 2*(R+1) + 1) T := T + 2; and ((S+(T+2)) = ((R+1)+1)2) S := S + T; 2 end loop; and ((R+1) <= N) and ((R+1)>=0) { (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) and ((S+(T+2)) > N) } ? R := R + 1; and (R>=0) and (S > N) } implies post? T := T + 2; end; S := S + T; { post: (R2 <= N < (R+1)2) and (R >= 0) } end loop; end;

Verification Via Backward Anthony Hall’s Seven Myths of Substitution (III) Formal Methods (I) Apply Axiom of Assignment and Rule of Consequence: 1) Formal methods can guarantee that { pre: N >= 0 } software is perfect begin pre implies { (1 = 2*0 + 1) and (1 = (0+1)2) ! How do you ensure the initial spec is perfect? and (02 <= N) and (0>=0) } ? 2) Formal methods are all about program R := 0; proving S := 1; T := 1; ! They’re also about modeling, communication, while S <= N loop analyzing, demonstrating { I: (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) and (R >= 0) } 3) Formal methods are only useful for safety- R := R + 1; T := T + 2; critical systems S := S + T; ! Can be useful in any system end loop; end;

Anthony Hall’s Seven Myths of Anthony Hall’s Seven Myths of Formal Methods (II) Formal Methods (III)

4) Formal methods require highly trained 7) Formal methods are not used on real, mathematicians large-scale software ! Many methods involve nothing more than set theory and logic ! They’re used daily in many branches of 5) Formal methods increase the cost of industry development

! There is evidence that the opposite is true 6) Formal methods are unacceptable to users

! When properly presented, users find them helpful

Bertrand Meyer’s Seven Sins Bertrand Meyer’s Seven Sins of the Specifier (I) of the Specifier (II)

1) Noise 4) Contradiction

! the presence in the specification text of an ! the presence in the text of two or more elements element that does not carry information relevant that define a feature of the system in an to any feature of the problem incompatible way ! Includes redundancy and remorse 5) Ambiguity

2) Silence ! the presence in the text of an element that

! the existence of a feature of the problem that is makes it possible to interpret a feature of the not covered by any element of the text problem in at least two different ways 3) Overspecification 6) Forward reference

! the presence in the text of an element that ! the presence in the text of an element that uses corresponds not to a feature of the problem but features of the problem not defined until later in to features of a possible solution the text

Bertrand Meyer’s Seven Sins Limits to the Notion of of the Specifier (III) “Correctness”

7) Wishful thinking ! Correctness of a program is always relative ! It’s relative to assumption that compiler is correct, ! the presence in the text of an element which is relative to that defines a feature of the problem in ! Assumption that hardware architecture is correct, such a way that a candidate solution which is relative to ! Assumption that digital approximations of cannot reasonably be validated continuous electromagnetic phenomena are correct, which is relative to ! Assumption that the laws of physics are correct ! In other words, correctness is always a matter of demonstrating consistency of one spec with another, where the latter is assumed to be correct