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

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

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 5 ABAB

6 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

7 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 model that has been developed

8 Formal techniques 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”

9 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 , DOI /WESCON (available from IEEE Xplore) /WESCON Potentially useful for systems in domains such as: --security --avionics --medical devices

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 for 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: Intel Pentium Processor

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: – / –The answer is , while the Pentium returns (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 Example Continued

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 Reason for the Error

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) Consequences

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 Why is this Important

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 Intel Today

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 Other Examples of Industrial Usage of Formal Methods

18 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 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 Engineering1 V. George,and R. Vaughn, Crosstalk, The Journal of Defense Engineering accessed august 12, 2010

19 "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, test, …. 10. Reuse

20 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

21 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’

22 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)

23 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) Unused (free) blocks Queued for entry into Unused Blocks released to queue when files deleted Used blocks

24 Z example (2) Z specification: BlockHandler used,free:  BLOCKS BlockQueue: seq P BLOCKS used  free =   used  free = AllBlocks   i: dom BlockQueue. BlockQueue i  used   i,j : dom BlockQueue. i  j  BlockQueue i  BlockQueue j = 

25 Some Z notation Z specification: BlockHandler used,free:  BLOCKS BlockQueue: seq P BLOCKS used  free =   used  free = AllBlocks   i: dom BlockQueue. BlockQueue i  used   i,j : dom BlockQueue. i  j  BlockQueue i  BlockQueue j =  set contained in and implies “then” in intersection for all empty set intersection union sequence

26 Z example (3) RemoveBlock  BlockHandler #BlockQueue > 0, used’ = used \ head BlockQueue  free’ = free  head BlockQueue  BlockQueue’ = tail BlockQueue AddBlock  BlockHandler Ablocks? : BLOCKS Ablocks?  used, used’ = used  free’ = free  BlockQueue’ = BlockQueue ^ (Ablocks?)

27 Modifications 1. What if BlockQueue is replaced by BlockStack? 2. What are postconditions for the operations?

28 Additional Z Notation

29 Z Sequence Notation

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

31 Modifying the example Examples: 1. Change BlockQueue to BlockStack: 2. Output size of BlockQueue in AddBlock or RemoveBlock 3. Make BlockQueue part of “free” instead of “used”

32 Modifying the example

33 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?