Formal Methods CIS 376 Bruce R Maxim UMDearborn
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 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 • new. Q = queue • add. Q(queue, item) = item • del. Q(queue) = queue • front. Q(queue) = item • is. New(queue) = boolean
Queue Specification - part 2 Semantic specification • declare q : queue i : item • del. Q(add. Q(q, i)) = if is. New. Q() then new. Q() else add. Q(del. Q(q), i)
Queue Specification - part 3 Semantic specification (continued) • is. New. Q(add. Q(q, i)) = false • is. New. Q(new. Q()) = true • front. Q(add. Q(q, i)) = if is. New. Q(q) then i else Front. Q(q)
Queue Specification - part 4 Restriction specification • del. Q(new. Q()) = error • front. Q(new. Q()) = 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 objectoriented 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 welldefined 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
- Slides: 40