1 FM does not replace testing! Why Use Formal Methods Reduces - PDF document

Topics ● Introduction and terminology Overview of Formal Methods ● FM and Software Engineering ● Applications of FM ● Propositional and Predicate Logic ● Program derivation ● Intuitive program verification ● Algebraic Specifications ● Overview of Specification languages 12-FormalMethods 1 2 12-FormalMethods Components of a Formal Terminology Method ● Methods: ● Formal systems. ■ general guidelines governing an activity ■ formal languages with well-defined syntax ■ well-defined semantics ■ rigorous, systematic, and may be formal ■ proof systems ● Techniques: ● Development technique. ■ are technical, mechanical, approaches ■ implementation produced from specification ■ may have restricted applicability ■ application of development steps ● Methodologies: combine methods. techniques ■ refinement process ● Verification technique. ● Tools: can be built to support methodology ■ verify implementation satisfies specification ■ verify each development step 3 4 12-FormalMethods 12-FormalMethods Important characteristics of FM Formal vs. Rigorous ● Abstraction ● Formal ● Proof obligations ■ based on mathematics (including logic) ● Tool support ■ validity of statements can be mechanically checked ● Rigorous ● Systematic process ■ strictly follows the rules ■ compliance can be audited 5 6 12-FormalMethods 12-FormalMethods 1

FM does not replace testing! Why Use Formal Methods ● Reduces burden on testing phases to detect all ● Improve quality of software system critical errors ● Fitness for purpose ● Facilitates more effective allocation of testing ● Maintainability resources ● Ease of construction ● Higher confidence in software product ● Can guide the selection of test cases ● Reveal ambiguity, incompleteness, and inconsistency in system ● Detect design flaws ● Determine correctness 7 8 12-FormalMethods 12-FormalMethods V&V and Traceability V&V and Traceability The Real World The Real World Validation Validation Formal Specification Formal Specification Verification Verification Traceability Code Code 9 10 12-FormalMethods 12-FormalMethods Traditional verification Potential solutions?: techniques not successful. ● Need experimental evidence on large projects. Why not? ● Construction of support tools ● Too much like math? (proofs, ugh!) ● Early education!?!? ● Notation too hard to use ● Integration of formal methods in more than one phase of ● Notation too hard to write out software engineering ● Improved (automated) theorem proving strategies ● "Simple" things take a lot of effort ● Handle more than just functional properties ● "Complex" things seem impossible ● MOST IMPORTANTLY: do not verify "after the fact" ● Program verification is an undecidable problem ● "If it works, why mess with it?" 11 12 12-FormalMethods 12-FormalMethods 2

Rushby’s “Levels of Rigor” When and Where? ● Introduce FM into existing systems ● Level 0: No use of formal methods. ■ structured walk throughs, ‘formal’ inspections ■ Verify critical properties ● Level 1: Use of concepts and notation from discrete mathematics. ■ Facilitate maintenance and reimplementation ● Introduce FM into new systems ■ cleanroom, SCR (software cost reduction) ● Level 2: Use of formalized specification languages with some ■ Capture requirements precisely mechanized support tools. ■ Reduce ambiguity ■ specification languages, ‘rigorous’ proofs ■ Guide software development process ● Level 3: Use of fully formal specification languages with ■ Basis for testing comprehensive support environments, including mechanized ■ Formalize requirements analysis and design theorem proving or proof checking . 13 14 12-FormalMethods 12-FormalMethods Purpose of Formal Formal Semantics Specification ● Formal semantics provide precise, machine-independent ● The purpose of a formal specification is to state what a system should do without describing how concepts to do it ● Provide unambiguous specification techniques and a rigorous theory to support reliable reasoning. ● A formal specification may define a system as an ● A formal definition of a language can suggest a method for abstract datatype. constructing programs guaranteed to conform to their specifications. ● A formal specification should avoid ● So, the purpose of formal specification is ... implementation bias. 15 16 12-FormalMethods 12-FormalMethods Formal Specifications Too Little and Too Much ● Formal specifications serve as a ● There exists a balance between saying enough ■ contract in a specification and saying too much. ■ documentation ■ say enough so that implementers do not choose ■ means of communication between client, specifier, and unacceptable implementations implementer ■ specifications should capture the requirements ● Formal specifications are amenable to machine completely analysis and manipulation ■ avoid implementation-bias by not restricting freedom of later designers 17 18 12-FormalMethods 12-FormalMethods 3

Operational Approach Operational Approach con’t ● Define an abstract machine having states, possibly several ■ The semantic description of the programming language components, and some set of primitive instructions. specifies a translation into this code. ● Define the machine by specifying how the components of the state are ■ Trace through the translated program step-by-step to changed by each instruction. determine its precise effect. ● Define the semantics of a particular programming language in terms of states. ■ Languages defined in this way include PL/I (by the VDM method) ● Abstract machines may be unrealistic from a practical point of view, but the simplistic definition prevents misunderstanding code later. 19 20 12-FormalMethods 12-FormalMethods The Axiomatic Approach Another View ● Associate an "axiom" with each kind of statement ● Model-Oriented: define system behavior by constructing model of system in terms of mathematical structures in the programming language ■ tuples, functions. sets, or sequences ■ state what may be asserted after execution of that ■ languages include VDM, Z, CSP, and Petri Nets statement in terms of what was true before ● Property-Oriented: define system behavior indirectly by ■ an example is the use of pre- and postconditions. stating a set of properties that the system must satisfy 21 22 12-FormalMethods 12-FormalMethods Two Types of Property- Obvious Applications Oriented Approaches ● Computer Security ● Fault-tolerant systems (e.g. Nuclear reactors) ● Axiomatic: use first-order predicate logic (pre- and ● Safety-critical system (e.g. diagnostic X-ray machine) postconditions) ● Gain insight into hardware/software systems (e.g. oscilloscope) ● Basically, wherever the cost of failure is high: ● including systems that are critical in some way ● Algebraic: use axioms in equational form to ● replicated many times describe properties ● fixed into hardware, or ● dependent on quality for commercial reasons 23 24 12-FormalMethods 12-FormalMethods 4

Relevant Areas of Research ● Programming environments ● Formal methods in software development ● Tools that support construction of formal specifications ● Design tools that will generate formal specifications ● Problem/specification decomposition ● Procedural and data abstraction ● Synthesis of efficient code ● "Smart" user interfaces (user-friendly ones!!) ● Methods for determining reuse (of design/specifications/code) 25 12-FormalMethods 5