Introduction to Formal Methods Preconditions Postconditions and Invariants

Introduction to Formal Methods; Preconditions, Postconditions, and Invariants Revisited; Z language Example (Pressman) 1

“engineering” hardware vs “engineering” software: example —a simple flipflop D Q 1 clock reset well-defined “part” with datasheet -- VHDL description of flipflop entity DFF is port (D, clock, reset: in std_logic; Q 1: out std_logic; ) end DFF: architecture behavior of DFF is begin process (reset, clock) begin if reset = ‘ 1’ then Q 1 <= 0; elseif (clock ‘event and clock=‘ 1’) then Q 1 <= D; endif; end process; Just change one character…. . end behavior; 2

Software: ---is an abstract layer ---must be translated to hardware ---is very easily modified ---is often developed by a group ---often consists of multiple processes sharing resources What tools has “classical” software engineering developed to deal with the difficulties of producing robust software? 3

Some useful concepts: --“software life cycle” requirements specifications design implement test maintain --well-defined development process matching project and resources --process maturity level: “CMM”—well-defined, improve each cycle --independence of testing, design for test, automated test --levels of development: system, unit (black box), code (glass box) --the object-oriented paradigm: promotes modularity, reuse, information hiding --design languages, e. g. , Unified Modeling Language (UML) --”contracts”: preconditions, postconditions, invariants, “assert” precondition to divide: denominator is not zero postcondition to push onto stack: stack is not empty 4

But none of these “informal” tools or methods can guarantee fault-free software. For one thing, in most cases there is not enough time in the universe to test all possible states of a system and it may even be difficult to determine what “all possible states” are (“combinatorial explosion”: e. g. , if there are n boolean inputs, there are 2 n possible states). Therefore, to increase the quality of software, we need to resort to “formal” methods, which are based on mathematics and are expressed in formal languages having well-defined syntax and semantics. The two main mathematical areas we need are Set theory: A ∩ B, A ∪ B, a ∉ X, ∅ Logic: ∄ n ∈ ℕ such that 0 × n = 2 A B 5

What are formal methods? Formal methods are mathematically based. They are an attempt to deal with contradictions, ambiguities, vagueness, incomplete statements, and mixed levels of abstraction. They are most valuable for systems which have: --safety concerns (e. g. , airplane systems, medical devices) --security concerns 6

When are formal methods useful? Formal methods can be used to: --Mathematically PROVE correctness of a system --Reduce faults Formal methods can provide: --program specification: define program is supposed to do --program verification: PROVE program does what the specification says it will do Possible automated verification techniques: --automated theorem proving --model checking: exhaustively check all possible “states” of the 7 model that has been developed

Formal techniques: --use set theory, logic to specify systems --increase probability of complete, consistent, unambiguous specifications --require specialized training for developers --have high start-up costs; may require high overhead; some concepts (e. g. , timing, reliability) difficult or impossible to capture in formal systems --may be difficult for the customer to understand --do not replace more traditional approaches --may be “heavyweight” or “lightweight” 8

When are formal methods useful? Some examples*: --diagnosing subtle problems in a LAN recovery protocol --developing an aircraft collision avoidance system --developing process control systems --[hardware] verifying correct execution of Intel floating point hardware (formal methods adopted after the infamous Pentium division error incident) *G. Huling, Introduction to use of formal methods in software and hardware, WESCON/94, Sep 1994, pp. 48 -52, DOI 10. 1109/WESCON. 1994. 403628 (available from IEEE Xplore) Potentially useful for systems in domains such as: --security --avionics --medical devices 9

Example: Intel Pentium Processor • in 1994, Intel launched the first Pentium CPU, for use in personal computers • this processor was the first Intel processor to incorporate a math coprocessor floating-point arithmetic, or FPU – before that programs had to tell processors how to divide floating point numbers via integer arithmetic • this was accomplished by providing instructions that were built into the FPU – much faster for numerical calculations

Example Continued • this also makes the CPU more complex and expensive • Intel produced these chips for almost a year before the error was caught and corrected • the problem was that the FPU would incorrectly divide certain pairs of numbers – famous example is Coe’s numbers: – 4195835 / 3145727 – The answer is 1. 33382, while the Pentium returns 1. 33374 (to 6 sig. figs)

Example Continued • the error was discovered by Professor Nicely of Lynchburg College – he got values back from his Pentium machine which did not match his theoretical values, but his theoretical values matched values computed on a 486 machine. • the probability of hitting input combinations to produce the error was tiny, but these inputs gave the wrong answer every time

Reason for the Error • the divider in the FPU uses a radix 4 SRT algorithm – can compute two binary digits for a quotient every step, rather than one like other FPU’s • this requires a stored division table, similar to a multiplication table – five values out of about a thousand were omitted from the table

Consequences • because the error was discussed in the academic community and the findings were posted on the web, this became a large story for the media – this subsequently caused bad publicity for Intel • IBM halted the manufacture and sale of personal computers using the Pentium processor • Intel was eventually forced to replace all bad Pentium chips for customers who wanted them replaced – this, along with having to perform changes to the hardware of the chip, cost Intel hundreds of millions of dollars (approx. $500 million)

Why is this Important • just performing standard verification and testing of the system was not enough to catch this error – probability is very small and it is not possible to test all inputs to the chip • if formal methods had been used from the beginning this error would have been caught – formal specifications and proofs would have shown which values should not have been allowed to be set to zero – this would have saved Intel money and corrected the error before it could ever become in error

Intel Today • today Intel uses formal specification and formal verification in their hardware design process – write all specifications in a formal language and then prove these specifications using an automated proof checker called HOL Light – incorporate verification algorithms such as square root and reciprocal algorithms which weed out errors like the one found in the Pentium FPU • though this method is more tedious, it provides strict validation of the system, catching errors in the design before they become costly

Other Examples of Industrial Usage of Formal Methods • used by NASA to verify the software on the Deep Space 1 – spacecraft designed to test high risk technologies in deep space to lower costs and risks on future missions – formal methods verified the Remote Agent software • found 5 concurrency errors in LISP that would not have been found otherwise and would have been fatal to the spacecraft • an error occurred 24 hours after launch in software only tested using NASA’s test benchmark suite • used in the development of Mondex – an electronic purse stored on a smart card – stores financial data for use in making transactions wirelessly

When are formal methods useful? “Heavyweight” formal methods vs “lightweight” formal methods (which use partial specification and focused application): “Many factors influence deciding when and where to use lightweight and heavyweight formal methods. For large complex projects, the application of a heavyweight formal method is virtually impossible thus the lightweight formal method is a good candidate. When we are dealing with safety-critical systems or even, perhaps, trusted systems (in the ISO 15408 sense), using the lightweight formal method is debatable. In these cases, it may be better to use a heavyweight formal specification and analysis if time and cost permit. ” Application of Lightweight Formal Methods in Requirement Engineering 1 V. George , and R. Vaughn, Crosstalk, The Journal of Defense Engineering http: //www. stsc. hill. af. mil/crosstalk/2003/01/george. html 18 accessed august 12, 2010

"Ten Commandments" of formal methods (Pressman, Software Engineering, A Practitioner's Approach): 1. Choose the appropriate notation 2. Formalize but don't overformalize 3. Estimate costs 4. Have a formal methods "guru" on call 5. Do not abandon traditional development methods 6. Document sufficiently 7. Don't compromise quality standards 8. Do not be dogmatic 9. Test, test, …. 19 10. Reuse

Preconditions, postconditions, invariants Earlier we looked at adding statements to ensure correct program behavior: precondition: logical condition that a caller of an operation guarantees before making the call postcondition: logical condition that an operation guarantees upon completion invariant: logical condition that is preserved by transformations These conditions are all expressed as logical statements --they can be quantified: --they can be used to support testing at different levels 20

We will also be concerned with how the STATE of a system or component changes: e. g. , if the system or a component is in state S, it can be modified to a new state S’ 21

What is Z? A complete formal system We will use an example formal specification language: Z system described through a set of "schemas”, which have data invariant(s) state(s) S: represents change is state S; changed entity r is denoted by r’ operations-- with precondition(s) / postcondition(s) 22

Example (from Pressman, Software Engineering, A Practitioner’s Approach): “Block Handler” (note: this is just a simple example to demonstrate Z syntax, it is not meant to represent a “safety-critical system” which would be appropriate for strict formal specification) Used blocks Unused (free) blocks 2 5 7 8 10 11 12 13469 2 5 8 11 7 Blocks released to queue when files deleted Queued for entry into Unused 23

Z example (2) 2 5 7 8 10 11 12 13469 Z specification: -------Block. Handler-----------2 5 8 11 used, free: BLOCKS Block. Queue: seq P BLOCKS -----------------------used free = All. Blocks i: dom Block. Queue i used 7 i, j : dom Block. Queue. i j Block. Queue i Block. Queue j = 24

Some Z notation 2 5 7 8 10 11 12 13469 Z specification: set -------Block. Handler-----------2 5 8 11 intersection used, free: BLOCKS Block. Queue: seq P BLOCKS union ------------------------ sequence used free = contained in “then” used free = All. Blocks and. i: dom Block. Queue i used i, j : dom Block. Queue. i j Block. Queue i Block. Queue j = in for all 7 implies empty set intersection 25

Z example (3) 13469 2 5 8 11 7 -----Remove. Block------------- Block. Handler --------------------------#Block. Queue > 0, 2 5 7 8 10 11 12 used’ = used head Block. Queue free’ = free head Block. Queue’ = tail Block. Queue -------------------------------Add. Block--------------- Block. Handler Ablocks? : BLOCKS --------------------------Ablocks? used, used’ = used free’ = free Block. Queue’ = Block. Queue ^ (Ablocks? ) --------------------------- 26

Modifications 1. What if Block. Queue is replaced by Block. Stack? 2. What are postconditions for the operations? 2 5 7 8 10 11 12 13469 2 5 8 11 7 27

Additional Z Notation 28

Z Sequence Notation 29

Z example revisited (1) Example (from Pressman, Software Engineering, A Practitioner’s Approach): “Block Handler” Unused (free) blocks 2 5 7 8 10 11 12 13469 2 Used blocks 5 8 11 7 Blocks released to queue when files deleted Queued for entry into Unused 30

Modifying the example Examples: 1. Change Block. Queue to Block. Stack: 2. Output size of Block. Queue in Add. Block or Remove. Block 3. Make Block. Queue part of “free” instead of “used” 31

Modifying the example 32

Formal methods in project (exercise) Class exercise: --Describe a priority queue in Z notation --Are there operations you need which have not yet been defined in these slides on the Z notation? 33