1 / 40

Formal Methods

Formal Methods. CIS 376 Bruce R. Maxim UM-Dearborn. 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

nora
Download Presentation

Formal Methods

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

More Related