- 210 Views
- Updated On :
- Presentation posted in: General

Formal Methods

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

Formal Methods

CIS 376

Bruce R. Maxim

UM-Dearborn

- 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

- Set builder notation
- Set operations
- Logic operators
- Sequence properties
- order, domain, range

- Sequence operators
- concatenation, head, tail, front, last

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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 specifications
- Formal Proofs
- Model Checking
- Abstraction

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

5 language primitives (Guttag & Liskov)

- Functional composition
- Equality relation
- Constants
- "true and false"
- infinite set of free variables

Syntactic specification

- structure queue
- newQ = queue
- addQ(queue, item) = item
- delQ(queue) = queue
- frontQ(queue) = item
- isNew(queue) = boolean

Semantic specification

- declare
q : queue

i : item

- delQ(addQ(q, i)) =
if isNewQ() then newQ()

else addQ(delQ(q), i)

Semantic specification (continued)

- isNewQ(addQ(q, i)) = false
- isNewQ(newQ()) = true
- frontQ(addQ(q, i)) =
if isNewQ(q) then i

else FrontQ(q)

Restriction specification

- delQ(newQ()) = error
- frontQ(newQ()) = error

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

- 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

- 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

- 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

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

- 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

- 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

- 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

- 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