formal methods
Download
Skip this Video
Download Presentation
Formal Methods

Loading in 2 Seconds...

play fullscreen
1 / 40

Formal Methods - PowerPoint PPT Presentation


  • 247 Views
  • Uploaded on

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

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

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

Formal Methods

CIS 376

Bruce R. Maxim

UM-Dearborn

levels of rigor for formal methods
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
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
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
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
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
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
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
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
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
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
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
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
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 Specification Methods
  • Formal specifications
  • Formal Proofs
  • Model Checking
  • Abstraction
formal specification
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Queue Specification - part 4

Restriction specification

  • delQ(newQ()) = error
  • frontQ(newQ()) = error
error specification
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
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
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
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
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
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
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
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
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
ad