1. Formal Methods CIS 376 Bruce R. Maxim UM-Dearborn

2. Levels of Rigor for Formal Methods Informal –manual reviews, inspections Low –modeling using logical and discrete mathematics Medium –formal specification language with type checking High –fully formal specification language with rigorous semantics and proof checking

3. Necessary Mathematics Set builder notation Set operations Logic operators Sequence properties –order, domain, range Sequence operators –concatenation, head, tail, front, last

4. Weaknesses of Less Formal Approaches - part 1 Contradictions –statements do not agree with one another Ambiguities –statements have more than one interpretation Vagueness –specifications in large documents are often not written precisely enough

5. Weaknesses of Less Formal Approaches - part 2 Incompleteness –e.g. failing to list limitations and error handling required of a function Mixed levels of abstraction –occurs when very abstract statements are intermixed randomly with statements written at lower levels of detail

6. Why Consider Formal Methods? Systems are increasingly dependent on software components –fault protection and safety are no longer allocated solely to hardware –software must be able to detect and isolate failures and then execute recovery scenarios –software systems fail in way different than hardware systems Complexity of systems with embedded software has increase rapidly

7. Reliability and Traditional Methods Maintaining reliability in software intensive systems is very difficult Quality ceilings are encountered using traditional measures (which means that reliability asymptotically approaches some level considerably less than 100%) New approaches seem to be needed to achieve increases in quality measures

8. Limitations to Formal Methods Use formal methods as supplements to quality assurance methods not a replacement for them Formal methods can increase confidence in a product’s reliability if they are applied skillfully Useful for consistency checks, but formal methods cannot guarantee the completeness of a specifications Formal methods must be fully integrated with domain knowledge to achieve positive results

9. Ten Commandments of Formal Methods - part 1 Choose the appropriate notation Do not over-formalize Estimate costs Have a formal methods guru on call Do not abandon traditional development methods Document sufficiently

10. Ten Commandments of Formal Methods - part 2 Do not compromise quality standards Do not be dogmatic in assuming formal specifications are flawless Use of formal methods does not eliminate the need to test products Reuse is still important

11. Choosing a Life Cycle Phase Formal methods can be applied to all phase of the life cycle The benefit-to-cost ratio seems highest for the specification and design phases The makes sense because the earlier defect is removed the cheaper it will be to correct

12. Formal Methods and Specification Phase This phase is the least automated and is not tightly coupled to specific languages or notations Specification work products are less effectively analyzed that products from later phases Using formal methods in this phase does not interfere much with other existing processes and can dramatically improve analysis capability

13. Benefits of Formal Specification - part 1 Higher level of rigor leads to better problem understanding Defects are uncovered that would be missed using traditional specification methods Allows earlier defect identification Formal specification language semantics allow checks for self-consistency Enables the use of formal proofs to establish fundamental system properties and invariants

14. Benefits of Formal Specification - part 2 Repeatable analysis allows reasoning to be checking by colleagues Encourages and abstract view of the system, focusing on what a system should do rather than how to accomplish it An abstract view of the system helps separate specification from design Enhances existing processes by adding rigor

15. Formal Specification Methods Formal specifications Formal Proofs Model Checking Abstraction

16. Formal Specification The translation of non-mathematical description (diagrams, table, natural language) into a formal specification language It represents a concise description of high-level behavior and properties of a system Well-defined language semantics support formal deduction about the specification

17. Formal Proofs Provide a complete and convincing and convincing argument for validity of some system property description Proofs are constructed as a series of small steps, each of which is justified using a small set of rules Eliminates the ambiguity and subjectivity inherent when drawing informal conclusions Proofs can be done manually, but they usually constructed with some automated assistance

18. Model Checking Checking is operational rather than analytic The finite state machine model of a system is expressed in a suitable language A model checker determines if the finite state model satisfies the requirements expressed as formulas in a given logic The basic method is to derive a computational tree from the finite state machine model and explore all plausible execution paths

19. Abstraction The process of simplifying or ignoring irrelevant details Allows you to focus on and generalized the most important central properties and characteristics Helps to avoid premature commitment to design and implementation choices

20. Using Formal Methods Define the data invariant, state, and operations for each system function Specification is represented in some set theoretic type notation from some formal language Specification correctness can be verified using mathematical proofs

21. Review of Terms data invariant –a condition true throughout execution of function that contains a collection of data state –defined by the stored data accessed and altered by a particular function operations –system actions that take place when data are read or written to the state –precondition and post condition is associated with each operation

22. Formal Specification Properties Unambiguous –formal syntax used by formal methods has only one interpretation (unlike natural language statements) Consistency –ensuring through mathematical proof that initial facts can be mapped (using inference rules)into later statements within the specification Completeness –difficult to achieve in a large system even using formal methods

23. Writing Formal Specifications Begin by defining state in terms of abstract items to be manipulated by the function (similar to variable declaration in a programming language) Define the data invariant by writing the data relations that will not change during the execution of the function using mathematical notation Write the precondition and post-condition for the function using mathematical notation to show the system state before and after function execution

24. Formal Specification Language Components Syntax –defines the specific notation used to represent a specification Semantics –help to define the objects used to define the system Set of relations –define the rules that indicate which objects properly satisfy the specification

25. Algebraic Specification Particularly appropriate from sub-system interface specification Involves specifying operations for abstract data types or objects in terms of their interrelationships Contains a syntax part which defines its signature and a semantic part defined by axioms Algebraic specifications may be developed by defining the semantics of each inspection operation for each constructor operation Display operations are hard to define algebraically and need to be defined informally instead

26. Specification Operations Constructor operations –create entities of the type specified Inspection operations –evaluate entities of the type being specified Behavior specification is created by defining the inspector operations for each constructor operation

27. Algebraic Specification Example 5 language primitives (Guttag & Liskov) –Functional composition –Equality relation –Constants –"true and false" –infinite set of free variables

28. Queue Specification - part 1 Syntactic specification structure queue newQ = queue addQ(queue, item) = item delQ(queue) = queue frontQ(queue) = item isNew(queue) = boolean

29. Queue Specification - part 2 Semantic specification declare q : queue i : item delQ(addQ(q, i)) = if isNewQ() then newQ() else addQ(delQ(q), i)

30. Queue Specification - part 3 Semantic specification (continued) isNewQ(addQ(q, i)) = false isNewQ(newQ()) = true frontQ(addQ(q, i)) = if isNewQ(q) then i else FrontQ(q)

31. Queue Specification - part 4 Restriction specification delQ(newQ()) = error frontQ(newQ()) = error

32. Error Specification It is important to define the behavior of an operation under both normal and abnormal conditions This might be done using one of these approaches –Use a special flag constant like “error” or “undefined” that conforms to the operation return type –Define the return type to be a tuple with an element that indicates success or failure of the operation –Include a special failure or exception section in the specification (this may need to be defined informally)

33. Primitive Constructors Sometimes is it useful to introduce additional constructors to simplify a specification This allows other constructors to be specified using these more primitive constructors For example, adding a node constructor to simplify the specification of other list operators

34. Structured Specification Whenever possible specifications should be reused in the construction of other specifications Similar to work in object-oriented design, a generic specification is instantiated to yield a particular specification For example a generic specification may call for a sorted list and this might later be instantiated with a particular list node type and representation

35. Incremental Specification This involves developing a simple specification and then using this in more complex specifications The development of a library reusable specification building blocks would be useful For example, the specification of a Cartesian coordinate might be useful in the specification of screen objects in a GUI

36. Specification Enrichment Starting with a reusable specification definition, new operations are added to create a more complex type Similar to the process of inheritance in object- oriented programming Can be carried on for several levels Enrichment creates a new type which is not the same as import/export which more like macro expansion (can only use an definition literally)

37. Multi-value Operations Some operations return more than one entity (for example pop may return an element and a modified stack in some specifications) One solution is to define the operation using multiple operations A more natural approach would be to extend our notation to allow operations to return tuples (e.g. structs or records) rather than just a single values

38. Establishing Formal Methods The use of formal methods is not an all or nothing proposition The level of rigor employed can be tailored to fit –budgets –schedules –technical environments Formal methods can be modified and integrated into existing processes

39. Process Prerequisites To make use of formal method a development process must be mature –has discrete phases –work products are defined for each phase –analysis procedures should be in place for work products –scheduled review of work products is present The preferred type of analysis will be strongly influenced by the level of rigor needed by the project objectives

40. Process Modifications with Formal Specification Methods If the requirements analysis procedures are well- defined then few changes to the process will be required to integrate formal methods Initial modeling activity employees finite-state machines, object diagrams, etc. Model would be formalized by converting it to a formal language representation