1 / 21

Understanding Formal Methods: A Comprehensive Overview

Explore the world of formal methods - mathematically based approaches to address system contradictions, ambiguities, and safety & security concerns, with examples, benefits, and best practices.

erino
Download Presentation

Understanding Formal Methods: A Comprehensive Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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 When are formal methods useful?

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

  5. 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)  Potentially useful for systems in domains such as: --security --avionics --medical devices When are formal methods useful?

  6. “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 Engineering1V. 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 When are formal methods useful?

  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. 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 Preconditions, postconditions, invariants

  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. 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) What is Z?

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

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

  13. 1 3 4 6 9 2 5 7 8 10 11 12 2 5 8 11 7 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 intersection union sequence contained in “then” and implies in empty set for all intersection

  14. ---------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 2 5 8 11 7 Z example (3)

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

  16. Additional Z Notation

  17. Z Sequence Notation

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

  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. Modifying the example

  21. 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? Formal methods in project (exercise)

More Related