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

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

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