FM FM Topics in Formal Methods for Software

FM FM Topics in Formal Methods for Software Development FM Dr. Cheng CSE 914 Fall 2002 FMSD-Overview 1

FM FM FM Topics u Introduction u FM and terminology and Software Engineering u Applications u Overview FMSD-Overview of FM of Specification languages 2

FM FM FM Terminology Methods: l general guidelines governing an activity l rigorous, systematic, and may be formal u Techniques: l are technical, mechanical, approaches l may have restricted applicability u Methodologies: combine methods. techniques u Tools: can be built to support methodology u FMSD-Overview 3

FM FM FM u u u Components of a Formal Method Formal systems. l formal languages with well-defined syntax l well-defined semantics l proof systems Development technique. l implementation produced from specification l application of development steps l refinement process Verification technique. l verify implementation satisfies specification l verify each development step FMSD-Overview 4

FM FM Formal vs. Rigorous FM u Formal l based on mathematics (including logic) l validity of statements can be mechanically checked u Rigorous l strictly follows the rules l compliance can be audited FMSD-Overview 5

FM FM FM Important characteristics of FM u Abstraction u Proof obligations u Tool support u Systematic process FMSD-Overview 6

FM FM does not replace testing! u Reduces burden on testing phases to detect all critical errors u Facilitates more effective allocation of testing resources u Can guide the selection of test cases FMSD-Overview 7

FM FM FM Why Use Formal Methods u Improve quality of software system u Fitness for purpose u Maintainability u Ease of construction u Higher confidence in software product u Reveal ambiguity, incompleteness, and inconsistency in system u Detect design flaws u Determine correctness FMSD-Overview 8

FM FM FM V&V and Traceability The Real World Validation Formal Specification Verification Code FMSD-Overview 9

FM FM FM V&V and Traceability The Real World Validation Formal Specification Verification Traceability Code FMSD-Overview 10

FM FM FM Traditional verification techniques not successful. Why not? u Too much like math? (proofs, ugh!) u Notation too hard to use u Notation too hard to write out u "Simple" things take a lot of effort u "Complex" things seem impossible u Program verification is an undecidable problem u "If it works, why mess with it? " FMSD-Overview 11

FM FM FM Potential solutions? : Need experimental evidence on large projects. u Construction of support tools u Early education!? !? u Integration of formal methods in more than one phase of software engineering u Improved (automated) theorem proving strategies u Handle more than just functional properties u MOST IMPORTANTLY: do not verify "after the fact" u FMSD-Overview 12

FM FM FM When and Where? u Introduce FM into existing systems l Verify critical properties l Facilitate maintenance and reimplementation u Introduce FM into new systems l Capture requirements precisely l Reduce ambiguity l Guide software development process l Basis for testing l Formalize requirements analysis and design FMSD-Overview 13

FM FM Rushby’s “Levels of Rigor” FM u u Level 0: No use of formal methods. l structured walk throughs, ‘formal’ inspections Level 1: Use of concepts and notation from discrete mathematics. l cleanroom, SCR (software cost reduction) Level 2: Use of formalized specification languages with some mechanized support tools. l specification languages, ‘rigorous’ proofs Level 3: Use of fully formal specification languages with comprehensive support environments, including mechanized theorem proving or proof checking. FMSD-Overview 14

FM FM FM Formal Semantics u Formal semantics provide precise, machineindependent concepts u Provide unambiguous specification techniques and a rigorous theory to support reliable reasoning. u A formal definition of a language can suggest a method for constructing programs guaranteed to conform to their specifications. FMSD-Overview 15

FM FM FM Potential Methods Pre- and Post-conditions for specifications u Vienna Development Method (VDM) u Rewriting techniques and transformational u Object-Oriented analysis, design and u programming u Integration of the construction of program and its proof of correctness u FMSD-Overview 16

FM FM FM Obvious Applications u Computer Security u u Fault-tolerant systems (e. g. Nuclear reactors) Safety-critical system (e. g. diagnostic X-ray machine) Gain insight int hardware/software systems (e. g. oscilloscope) Basically, wherever the cost of failure is high: l critical in some way l replicated many times l fixed into hardware, or l dependent on quality for commercial reasons FMSD-Overview 17

FM FM FM Relevant Areas of Research u Programming environments u Formal methods in software development u Tools that support construction of formal specifications u Design tools that will generate formal specifications u Problem/specification decomposition u Procedural and data abstraction u Synthesis of efficient code u "Smart" user interfaces (user-friendly ones!!) u Methods for determining reuse (of design/specifications/code) u Specifying and verifying security properties FMSD-Overview 18

FM FM FM Formal Specifications FMSD-Overview 19

FM FM FM Purpose of Formal Specification u The purpose of a formal specification is to state what a system should do without describing how to do it u A formal specification may define a system as an abstract datatype. u A formal specification should avoid implementation bias. FMSD-Overview 20

FM FM FM Formal Specifications u Formal specifications serve as a l contract l documentation l means of communication between client, specifier, and implementer u Formal spefications are amenable to machine analysis and manipulation FMSD-Overview 21

FM FM FM Too Little and Too Much u There exists a balance between saying enough in a specification and saying too much. l say enough so that implementers do not choose unacceptable implementations l specifications should capture the requirements completely l avoid implementation-bias by not restricting freedom of later designers FMSD-Overview 22

FM FM FM u u Operational Approach Define an abstract machine having states, possibly several components, and some set of primitive instructions. Define the machine by specifying how the components of the state are changed by each instruction. Define the semantics of a particular programming language in terms of states. Abstract machines may be unrealistic from a practical point of view, but the simplistic definition prevents misunderstanding code later. FMSD-Overview 23

FM FM FM Operational Approach con’t l The semantic description of the programming language specifies a translation into this code. l Trace through the translated program stepby-step to determine its precise effect. l Languages defined in this way include PL/I (by the VDM method) FMSD-Overview 24

FM The Denotational Approach FM FM l “Semantic valuation functions” map syntactic constructs in the program into the abstract values that they denote. l These valuation functions are usually recursively defined: u The value denoted by a construct is specified in terms of the values denoted by its syntactic subcomponents, and u It is this emphasis on the values denoted by all these constructs that gives the approach its name FMSD-Overview 25

FM FM FM The Axiomatic Approach u Associate an "axiom" with each kind of statement in the programming language l state what may be asserted after execution of that statement in terms of what was true before l an example is the use of pre- and postconditions. FMSD-Overview 26

FM FM FM Another View u Model-Oriented: define system behavior by constructing model of system in terms of mathematical structures l tuples, functions. sets, or sequences l languages include VDM, Z, CSP, and Petri Nets u Property-Oriented: define system behavior indirectly by stating a set of properties that the system must satisfy FMSD-Overview 27

FM FM FM Two Types of Property-Oriented Approaches u Axiomatic: use first-order predicate logic (preand postconditions) u Algebraic: use axioms in equational form to describe properties FMSD-Overview 28

FM FM FM Intuitive Program Verification FMSD-Overview 29

FM FM FM Program Verification and Proofs of Correctness u Reasoning about the behavior of programs is an old idea. One of the first modern approaches was Floyd’s flowchart annotation scheme. u Idea: Use logic to make assertions about the functionality of program statements. u In other words: Formally specify the desired functionality, then verify that the program is a correct implementation of the specification. FMSD-Overview 30

FM FM FM Two Questions u We know that the execution of some programs does not terminate. What specification(s) does a nonterminating program satisfy? u Verifying programs using only paper and pencil is tedious. How could a Verification Condition Generator (VCG) be built to automatically process code and logical assertions? FMSD-Overview 31

FM FM FM Rushby on Formal Verification u “Formal verification is often equated with ‘proof of correctness, ’ but this simultaneously over- and underestimates the benefits that formal verification can provide. It overestimates the benefits because ‘correctness’ suggests an absolute guarantee that is impossible for any enterprise that uses modeling to predict the behavior of real-world artifacts. ” u - J. Rushby, 1993 FMSD-Overview 32

FM FM FM Partial and Total Correctness u Partial correctness: If the precondition is true, and the program terminates, then the postcondition is satisfied. u Total correctness is partial correctness, plus a proof of termination. FMSD-Overview 33

FM FM FM Hoare’s Rules u. Program fragments and assertions are composed into triples {P} S {Q} u where u u FMSD-Overview P is the precondition assertion, Q is the postcondition assertion, and S is program statements. 34

FM FM FM Hoare’s Rules {P} S {Q} u u Interpretation: If P is true before S is executed, then when S terminates, Q is satisfied. u Triples can be used to define the semantics of programming languages. C. A. R. Hoare. An axiomatic basis of computer programming. Communications of the ACM, October 1969. S. Igarashi, R. L. London, and D. C. Luckham. Automatic program verification I: A logical basis and its implementation. Acta Informatica, 1975. FMSD-Overview 35

FM FM FM You Aren’t Going To Do The Proofs? l Syntax and type checking are simple and important. l The formalized process improves quality. l Use specifications as the basis for prototypes. FMSD-Overview 36

FM FM FM Guidelines 1. Prioritize desired properties and formalize critical correctness requirements at the same level of abstraction as your specification. 2. Record between-level mappings. 3. Know your limitations, that is, know what is not formally defined. 4. Don’t have to prove theorems - symbolic execution or specification-dervied test cases are valuable. FMSD-Overview 37

FM FM FM Real-world Issues Andrew Topper states criteria for a method to be formal l Documented; if already documented it should be reviewed for improvement l Taught to new development staff l Used widely and commonly in the organization l Measured, both the artifacts or deliverables, and the process itself. Source: A. Topper, Who’s afraid of formal methods? Object Magazine, February 1994. FMSD-Overview 38

FM FM FM Topper’s FM Myths Myth #1: Using formal methods means following a thick arduous document with every detail and task spelled out to the nth degree. Myth #2: Using a formal method means abruptly stopping what we are doing so we can study the process until hell freezes over and we won’t get any work done until then. Myth #3: Using a defined development process means we all have to agree on the “best” method and apply it rigorously without question. FMSD-Overview 39

FM FM FM Rushby on Why Use Formal Methods “The general advantages claimed for all formal methods are that they enable faults to be detected earlier than would otherwise be the case. This is because they allow greater precision and explicitness to be achieved earlier in the lifecycle than otherwise, and because they can support more systematic analyses than informal methods. Stronger forms of this claims are that formal methods cause faults to be detected with greater certainty than would otherwise be the case, and that in certain circumstances, subject to certain caveats, they can guarantee the absence of certain faults. These stronger claims are generally associated with formal methods that undertake “rigorous” or mechanicallychecked proofs” - J. Rushby, 1993. FMSD-Overview 40