1
play

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

Aug 18, 2023 •109 likes •176 views

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

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

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

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

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

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

Recommend

More recommend