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

2. 2 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

3. 3 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

4. 4 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”

5. 5 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 *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) 10.1109/WESCON.1994.403628 Potentially useful for systems in domains such as: --security --avionics --medical devices

6. 6 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 Engineering1 V. George,and R. Vaughn, Crosstalk, The Journal of Defense Engineering http://www.stsc.hill.af.mil/crosstalk/2003/01/george.html accessed august 12, 2010

7. 7 "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

8. 8 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

9. 9 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’

10. 10 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)

11. 11 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) 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117 Unused (free) blocks Queued for entry into Unused Blocks released to queue when files deleted Used blocks

12. 12 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 =  1 3 4 6 9 2 5 7 8 10 11 12 25 8 117

13. 13 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 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117

14. 14 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?) ------------------------------------------------------ 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117

15. 15 Modifications 1. What if BlockQueue is replaced by BlockStack? 2. What are postconditions for the operations? 1 3 4 6 9 2 5 7 8 10 11 12 25 8 117

16. 16 Additional Z Notation

17. 17 Z Sequence Notation

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

19. 19 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”

20. 20 Modifying the example

21. 21 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?