Formal Methods

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