Formal Methods

1 / 40

# Formal Methods - PowerPoint PPT Presentation

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

## PowerPoint Slideshow about 'Formal Methods' - nora

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

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
• 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()

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