Formal methods l.jpg
Sponsored Links
This presentation is the property of its rightful owner.
1 / 40

Formal Methods PowerPoint PPT Presentation

  • Updated On :
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Formal Methods

CIS 376

Bruce R. Maxim


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

Necessary Mathematics

  • Set builder notation

  • Set operations

  • Logic operators

  • Sequence properties

    • order, domain, range

  • Sequence operators

    • concatenation, head, tail, front, last

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

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

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

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

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

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

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

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

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

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

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

Formal Specification Methods

  • Formal specifications

  • Formal Proofs

  • Model Checking

  • Abstraction

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

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

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


  • 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

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

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

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

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

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

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

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

Algebraic Specification Example

5 language primitives (Guttag & Liskov)

  • Functional composition

  • Equality relation

  • Constants

  • "true and false"

  • infinite set of free variables

Queue Specification - part 1

Syntactic specification

  • structure queue

  • newQ = queue

  • addQ(queue, item) = item

  • delQ(queue) = queue

  • frontQ(queue) = item

  • isNew(queue) = boolean

Queue Specification - part 2

Semantic specification

  • declare

    q : queue

    i : item

  • delQ(addQ(q, i)) =

    if isNewQ() then newQ()

    else addQ(delQ(q), i)

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)

Queue Specification - part 4

Restriction specification

  • delQ(newQ()) = error

  • frontQ(newQ()) = error

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)

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

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

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

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)

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

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

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

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

  • Login